[소프트웨어설계] 1. 요구사항 확인

악으로 깡으로 벼락치기중

---

목차

001. 소프트웨어 생명 주기 002. 스크럼 기법 003. XP 기법 004. 현행 시스템 파악 005. 개발 기술 환경 파악 006. 요구사항 정의 007. 요구사항 분석 008. 요구사항 분석 CASE와 HIPO 009. UML 010. 주요 UML 다이어그램

---

001. 소프트웨어 생명 주기 (★★★)

• 소프트웨어 공학 : 소프트웨어 위기 극복하기 위한 방안 / 현대적인 프로그래밍 기술 적용 / 개발된 SW의 품질 유지되도록 지속 검증 / 개발 관련 사항, 결과에 대한 명확한 기록 유지
• 폭포수 모형 : 한 단계가 완전히 끝나야 다음 단계로 넘어(선형 순차적) / 가장 오래되고 폭 넓게 사용 / 성공사례 多 / 각 단계가 끝난 후에는 다음 단계 수행을 위한 결과물 명확히 산출 되어야 함. / 두 개 이상 과정 병행 수행 X
  • 타당성 검토 → 계획 → 요구분석 → 설계 → 구현(코딩) → 시험(검사) → 유지보수
• 프로토타입(원형) 모형 : 견본품을 만들어 최종 결과물 예측 / 시제품의 경우, 사용자와 시스템 사이의 인터페이스에 중점 / 폭포수 모형 단점 보완
  • 요구 수집 → 빠른 설계 → 프로토타입 구축 → 고객평가 → 프로토타입 조정 → 구현 (과정이 원형모형)
• 나선형(점진적) 모형 : 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어 개발하는 것... 보헴이 제안 / 개발 시 발생 가능한 위험 관리, 최소화 목적 / 개발과정 반복 → 유지보수 필요 X(추가로 첨가 가능해서)
  • 계획수립 → 위험분석 → 개발 및 검증 → 고객평가 (이 과정을 반복)
• 애자일 모형 : 요구사항에 유연히 대응할 수 있도록 일정한 주기 반복하며 개발과정 진행 / 소통초점 / 스프린트(sprint), 이터레이션(iteration)이라는 짧은 개발 주기 반복... 주기마다 만들어지는 결과물에 대한 고객 평가&요구 적극 수용 / 소규모 프로젝트, ㅆㅅㅌㅊ 개발자, 급변 요구사항에 적합
  • 개발 모형) 스크럼, XP, 칸반, Lean, 크리스탈, ASD, 기능 중심 개발, DSDM 등
  • 전략 수립 => [설계&테스트&개발] → [설계&테스트&개발] → ... → [설계&테스트&개발] (반복하면서 유지보수)
  • 애자일 선언
    • 핵심가치) 개인 상호작용에 큰 가치 / 실행되는 SW에 큰 가치 / 고객 협업에 더 가치 / 계획보단 변화 반응에 큰 가치
    • 12가지 실행 지침) 빠르고 지속적 제공... 고객 만족 / 막바지여도 요구사항 적극 수용 / 몇 주 단위로 실행되는SW 제공 / 고객&개발자가 프로젝트 기간에 함께 일 함 / 신뢰 / 대면으로 의견 나눔 / 개발 진척도 1차 기준 - 작동하는 SW / 기술적 우수성&좋은 설계 → 민첩성 ↑ / 단순화 / 일 주도하는 조직적인 팀 / 팀 행동 조정

---

002. 스크럼(Scrum) 기법 (★★☆)

• 개요) 팀원 스스로가 스크럼 팀 구성&개발 작업에 관한 모든 것을 스스로 해결 / 제품책임자, 스크럼 마스터, 개발팀으로 구성
  • 제품 책임자(PO) : 이해관계자 中, 이해도 ↑&요구사항 책임자고 의사결정할 사람... 개발의뢰자 or 사용자 / 요구사항 작성하는 주체 / 백로그 작성 및 우선순위 지정(제품 테스트 하면서 주기적으로 우선순위 갱신)
  • 스크럼 마스터(SM) : 객관적 시각에서 조언해주는 가이드 / 진행사항 점검, 장애 요소 공론화
  • 개발팀(DT) : PO, SM 제외한 모든 팀원 / 7~8명이 적당
• 개발 프로세스) 제품 백로그 → 스프린트 계획 회의 → 스프린트 → 일일 스크럼 회의 → 스프린트 검토 회의&회고
  • 제품 백로그 : 요구사항을 우선순위에 따라 나열... 지속적으로 업데이트 됨
  • 스프린트 계획 회의 : 수행 작업 대상으로 단기 일정 수립 / 태스크 작업 단위로 분할 후 스프린트 백로그(수행작업목록) 작성
  • 스프린트 : 실제 개발 작업 진행
  • 일일 스크럼 회의 : 짧은 시간동안 진행 상황 점검
  • 스프린트 검토 회의 : 사용자 앞에서 테스팅 수행 / PO가 피드백 정리&제품 백로그 업데이터
  • 스프린트 회고 : 개선점 등 확인하고 기록 / 해당 스프린트가 끝나거나 일정 주기로 수행

---

003. XP(eXtreme Programming) 기법 (★★★)

• XP : 고객의 요구사항에 유연하기 대응하기 위한 고객 참여&개발과정 반복 극대화 → 개발 생산성 향상 / 짧고 반복적인 개발 주기, 단순 설계, 고객 적극 참여 → 빠르게 개발하는 것 목적 / 비교적 소규모 인원 개발 프로젝트에 좋음
  • 핵심가치 : 의사소통, 단순성, 용기(Courage), 존중, 피드백
• 개발 프로세스
  • 사용자 스토리) 요구사항 간단히 시나리오로 표현
  • 릴리즈 계획 수립) 일부 스토리 적용... 부분적으로 기능 완료된 제품 제공 / 부분 or 전체 개발 완료 시점에 대한 일정 수립
  • 스파이크) 요구사항 신뢰성 높이고 위험 감소시키기 위한 별도 간단한 프로그램 만드는 것 / 처리할 문제 외 다른 조건 모두 무사하고 작성
  • 이터레이션) 릴리즈를 더 세분화한 단위 / 1~3주, 새로운 스토리가 작성 될 수도 있음
  • 승인검사(인수테스트)) 하나의 이터레이션 안, 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트 / 고객이 직접 수행 / 오류사항 → 다음 이터레이션에 포함 / 요구사항 상대적 우선순위 변경 될 수 있음
  • 소규모 릴리즈) 릴리즈를 소규모로 하면 곡객 요구사항에 좀 더 유연히 대응 가능 / 계획된 릴리즈 기간에 진행된 이터레이션이 끝나면 최종 결과물을 고객에게 전달 / 최종 완제품이 아니면 일정에 맞게 릴리즈 계속 진행
• XP 주요 실천 방법
  • Pair Programming(짝 프로그래밍) : 다른 사람과 함께 프로그래밍 수행 → 책임 공동
  • Collective Ownership(공동 코드 소유) : 개발 코드에 대한 권한&책임 공동 소유
  • Test-Driven Development(테스트 주도 개발) : 저신이 뭐 해야되는지 정확히 파악
  • Whole Team : 모든 구성원은 각자 자신의 역할이 있고 책임 가짐
  • Continuous Integration(계속적인 통합) : 작업 마무리될 때마다 지속적으로 통합
  • Design Improvement, Refactoring(디자인 개선, 리팩토링) : 프로그램 기능 변경 없이 단순화, 유연성 강화 통해 시스템 재구성
  • Small Releases : 릴리즈 짧게 반복 ~> 고객 요구 변화에 신속 대응

---

004. 현행 시스템 파악 (★★☆)

• 절차
  
  1. 시스템 구성 파악(주요 업무를 담당하는 기간 업무와 지원 업무 구분) / 시스템 기능 파악(주요 기능, 하부 기능, 세부 기능 구분 후 계층형으로 표시) / 시스템 인터페이스 파악(단위 업무 시스템 간 주고받는 데이터 종류, 형식, 프로토콜, 연계유형 등 명시)
  2. 아키텍처 구성 파악(최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성) / 소프트웨어 구성 파악
  3. 하드웨어 구성 파악 / 네트워크 구성 파악

---

005. 개발 기술 환경 파악 (★★☆)

• OS 관련 요구사항 식별 시 고려사항
  
  • 장기간 운영으로 발생 가능한 OS 고유의 장애 발생 가능성
    메모리 누수로 인한 성능 저하, 재가동
    지속적인 패치 설치로 인한 재가동
  • 대규모 동시 사용자 요청에 대한 처리 / 대용량 파일 작업에 대한 처리 / 지원 가능한 메모리 크기
  • 제작업체 안정적 기술 지원 / 사용자들 간 정보 공유 / 오픈소스 여부
  • 설치 가능한 하드웨어 / 주변기기 지원 여부
  • 지원 가능한 하드웨어 가격 / 라이선스 정책 및 비용 / 유지 관리 비용 / 총 소유 비용
• DBMS) 사용자-DB 간 사용자 요구에 따라 정보 생성, DB관리 SW / 오라클, MySQL, DB2, MS SQL Server 등
• DBMS 관련 요구사항 식별 시 고려사항
  • 가용성) OS 고유의 장애 발생 가능성 / 패치 설치를 위한 재가동 / 백업, 복구의 편의성 / 이중화 및 복제 지원
  • 성능) 대규모 데이터 처리 / 대용량 트랜잭션 처리 / 튜닝 옵션의 다양한 지원 / 최소화된 설정, 비용 기반 질의 최적화 지원
  • 기술지원) 제작업체의 안정적 기술 지원 / 사용자들 간 정보공유 / 오픈소스 여부
  • 상호 호환성) 설치 가능한 OS 종류 / JDBC(자바), ODBC(응용프로그램)와 호환 여부
  • 구축비용) 라이선스 정책 및 비용 / 유지관리 비용 / 총 소유 비용(TCO)
• 웹 애플리케이션 서버(WAS)) 동적 콘텐츠 처리하기 위한 미들웨어 / 데이터 접근, 세션관리, 트랜잭션 관리 등을 위한 라이브러리 제공 / 주로 DB서버와 연동해 사용 / 톰캣, Glass Fish, JBoss, Jetty, Jeus, Resin, WebLogic, WebSphere 등
• WAS 관련 요구사항 식별 시 고려사항
  • 고유의 장애 발생 가능성 / 패치 설치 위한 재가동 / 안정적인 트랜잭션 관리 / 이중화 지원
  • 대규모 트랜잭션 처리 성능 / 다양한 설정 옵션 지원 / 가비지 컬렉션의 다양한 옵션
  • 다른 것과 동일

---

006. 요구사항 정의 (★★★)

• 요구사항 유형 (기능&비기능/시스템&사용자)
  
  • 기능 요구사항) 시스템이 뭐 하는지 / 입출력에 뭐가 포함되어야 하는지 / 반드시 수행하는 기능 / 시스템을 통해 제공받고 싶어하는 기능
  • 비기능 요구사항) 시스템 장비 구성 요구사항 / 성능 요구사항(처리속도 등) / 인터페이스 요구사항(다른 시스템과 정보 교환에 사용되는 프로토콜 연계도 포함) / 데이터 요구사항 / 테스트 요구사항 / 보안 요구사항 / 품질 요구사항 / 제약사항 / 프로젝트 관리&지원 요구사항
  • 사용자 요구사항) 사용자 관점에서 본 시스템이 제공해야 할 요구사항 / 친숙한 표현
  • 시스템(SW) 요구사항) 개발자 관점에서 본 시스템 전체가 다른 시스템에 제공해야 할 요구사항 / 기술적 용어 표현
• 요구사항 개발 프로세스) 도출 → 분석 → 명세 → 확인
  • 요구공학) 요구사항 정의, 분석, 관리하는 프로세스를 연구하는 학문(요구사항개발 ⊂ 요구사항관리 ⊂ 요구공학)
• 요구사항 도출) 요구사항 수집 / SW가 해결해야 할 문제 이해하는 것 / 이해관계자 식별되는 단계 / SW개발 생명 주기동안 지속적으로 반복 / 청취, 인터뷰, 설문, 브레인스토밍, 워크샵, 유스케이스, 프로토타이핑 등
• 요구사항 분석) 요구사항 중 명확하지 않거나 모호해 이해되지 않는 부분 발견하고 이를 걸러내는 과정 / 타당성 조사 및 비용과 일정에 대한 제약 설정 / 상충되는 요구사항 중재 / 요구사항 토대로 SW범위 파악 / 자료흐름도(DFD), 자료 사전(DD) 등 도구 사용
• 요구사항 명세) 모델 작성 및 문서화 / 기능 요구사항-빠짐없이 명확히 기술 / 비기능-필요한 것만 명확하게 / 설계 과정에서 잘못된 부분 있으면 그 내용을 정의서에서 추적할 수 있어야 함 / 구체적 명세를 위해 소단위 명세서 사용될 수 있음
  • SW 요구사항 명세서(SRS)) SW가 반드시 제공해야 하는 기능, 특징, 제약조건 등 명시

	정형 명세 기법	비정형
기법	수학적 원리 기반, 모델 기반	상태, 기능, 객체 중심
작성방법	수학적 기호, 정형화된 표기법	자연어 기반 서술 or 다이어그램
특징	정확하고 간결 / 완전성 검증 가능 / 표기법 어렵... 사용자 이해하기 어렵	일관성 떨어짐(해석이 달라져서) / 쉬워서 의사소통 용이
종류	VDM, Z, Petri-net, CSP 등	FSM, Decision Table, ER모델링, State Chart(SADT) 등

• 요구사항 확인) 요구사항 검증 / 개발 자원을 요구사항에 할당하기 전 명세서가 정확&완전하게 작성됐는지 검토 / 이해관계자들이 검토 / 형상관리 수행

---

007. 요구사항 분석 (★★★)

• 개요) 요구 타당성 조사, 비용과 일정에 대한 제약 설정 / 목표 정하고 어떤 식으로 해결할지 정함 / 정확하고 일관성 있게 문서화 / UML, 자료흐름도(DFD), 자료사전(DD), 소단위 명세서, 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등 도구 이용
• 구조적 분석 기법) 도형 중심 분석용 도구와 분석 절차 이용
• 자료흐름도(DFD)) 버블차트 / 구조적 분석 기법에 이용 / 단계적으로 세분화
  • 프로세스 : 자료 변환시키는 시스템의 한 부분 / 처리, 기능, 변환, 버블 // 원 or 둥근 사각형
  • 자료 흐름 : 이동이나 연관관계 // →
  • 자료 저장소 : 파일, DB 나타냄 / =(사이에 이름 기입) or id 노드
  • 단말 : 시스템과 교신하는 외부 개체... 입력 데이터 만들어지고 출력 데이터 받음 // 도형 안에 이름 기입
• 자료사전(DD)) DFD에 있는 자료를 더 자세히 정의, 기록 / 데이터의 데이터, 메타데이터 라고도 함
  • = : 자료의 정의(~ 로 구성되어 있다)
  • + : 자료의 연결(and)
  • ( ) : 자료의 생략(생략 가능한 자료)
  • [|] : 자료의 선택(or)
  • { } : 자료의 반복( { }vi : i번 이상 반복 / { }^n : 최대 n번 반복 / 둘이 동시에 쓰면? i 이상 n 이하 반복)
  • * * : 자료의 설명(주석)

---

008. 요구사항 분석 CASE와 HIPO (★★☆)

• 분석을 위한 CASE) 자동화 도구... 요구사항 자동 분석, 명세서 기술 / 장점 - 표준화&문서품질개선, 결함 발견 용이성, 추적 용이성, 비용 축소
• 종류
  • SADT(Structured Analysis and Design Technique) : SoftTech / 시스템 정이, SW 요구사항 분석, 시스템&SW 설계를 위한 구조적 분석 및 설계 도구 / 블록 다이어그램 채택
  • SREM(Software Requirements Engineering Methodology/RSL, REVS) : TRW에서 실시간 처리 SW 시스템에서 요구사항 명확히 기술하도록 할 목적으로 개발 / RSL(요소, 속성, 관계, 구조 기술), REVS(RSL로 기술된 요구사항 자동 분석 ~> 요구사항 분석 명세서 출력) 사용
  • PSL/PSA : 미시간 대학 / PSL(문제 기술 언어) / PSA(PSL로 기술한 요구사항을 자동 분석해 다양한 보고서 출력)
  • TAGS(Technology for Automated Generation of Systems) : 개발 주기의 전 과정에 이용할 수 있음 / 구성 - IORL(요구사항 명세 언어), 요구사항 분석 및 IORL 처리 위한 도구, 기초적인 TAGS 방법론
• HIPO) 시스템의 분석, 설계, 문서화 할 때 사용되는 기법 / 기본 시스템 모델 : 입력, 처리, 출력으로 구성... 하향식 SW 개발 위한 문서화 도구 / 체계적인 문서 관리 가능 / 기호, 도표 활용... 이해하기 쉬움 / 기능, 자료 의존관계 동시 표현 / 변경, 유지보수 용이
  • HIPO Chart) 시스템의 기능을 여러 개 고유 모듈들로 분할... 인터페이스를 계층 구조로 표현한 것 / 가시적 도표(도식목차, 전체적인 기능과 흐름을 보여주는 계층 구조도) / 총체적 도표(총괄도표or개요도표, 구성 기능들 기술... 입력&처리&출력에 대한 전반적 정보 제공) / 세부적 도표(상세도표, 총체적 도표에서 표시된 기능을 구성하는 기본 요소들을 상세히 기술)

---

009. UML (★★★)

• 개요) 객체지향 모델링 언어(OMT, Booch, Jacobson등 객체지향 방법론 장점 통합) / OMG(뉴진스아님)에서 표준 지정 / 6개 구조 다이어그램(시스템 구조) - 7개 행위 다이어그램(시스템 동작)을 작성 가능 / 구성요소 - 사물, 관계, 다이어그램 등
• 사물) 구조 / 행동(시공간에 따른 요소들의 행위) / 그룹 / 주해(Annotation, 부가설명 or 제약조건)
• 관계) 사물-사물 연관성 표현
  • 연관(Association) : 2개 이상 사물이 서로 관련 됨 / 화살표 표현... 하지만 쌍방일 땐 실선으로만 / 다중도를 선 위에 표기
    • 0..1 : 연관 객체 없거나 하나만 존재
      0..* or * : 연관 객체 없을수도 많을수도
      n..* : 적어도 n개 이상
      n..m : n~m개
  • 집합(Aggregation) : 포함되어 있는 관계 / 포함하는 쪽(전체)과 포함되는 쪽은(부분) 서로 독립
  • 포함(Composition) : 집합의 특수 형태... 포함하는 사물의 변화가 포함되는 사물에 영향을 미치는 관계 / 서로 독립 X, 생명주기를 함께 함
  • 일반화(Generalization) : 하나의 사물이 다른 사물에 비해 더 일반적 or 구체적인지 표현
  • 의존(Dependency) : 서로 연관은 있는데 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관 유지하는 관계
  • 실체화(Realization) : 사물이 할 수 ㅣㅇㅆ거나 해야하는 기능으로 서로 그룹화 할 수 있는 관계

관계 표현법

• 다이어그램) 사물-관계를 도형으로 표현 / 뷰 제공... 의사소통 도움 / 정적 모델링 - 구조적 다이어그램 / 동적 - 행위 다이어그램
  • 구조적 다이어그램) 클래스(속성, 관계) / 객체(인스턴스를 특정 시점의 객체-객체 관계로 표현) / 컴포넌트(컴포넌트 관계 or 컴포넌트 간 인터페이스/ 구현단계) / 배치(물리적요소/ 구현단계) / 복합체 구조 / 패키지(모델 요소들을 그룹화한 패키지들의 관계)
  • 행위 다이어그램) 유스케이스(요구분석... 기능 모델링 작업에 사용) / 순차(상호작용하는 시스템, 객체가 주고받는 메시지) / 커뮤니케이션(객체 주고받는 메시지&객체간 연관) / 상태 / 활동(어떤 기능 수행?) / 상호작용 개요 / 타이밍(상태 변화, 시간 제약 명시적 표현)
• 스테레오 타입) UML에서 표현하는 기본 기능 외 추가적 기능 표현할 때 / 《》
  • 《include》 : 연결된 다른 UML에 포함 관계에 있는 경우 / 《extend》 : 확장 관계에 있는 경우 / 《interface》 : 인터페이스 정의 / 《exception》 : 예외 정의 / 《constructor》 :  생성자 역할 수행

---

010. 주요 UML 다이어그램 (★★★)

• 유스케이스 다이어그램) 사용자 관점에서 표현 / 외부요소-시스템 상호작용 확인 / 요구사항 분석 위한 도구 / 시스템 범위 파악
  • 유스케이스 다이어그램 구성 요소
    • 시스템/시스템 범위 : 유스케이스들을 사각형으로 묶어 범위 표현
    • 엑터(Actor) : 시스템과 상호작용하는 모든 외부 요소 / 주엑터 : 시스템 사용으로 이득 얻는 대상(사람) / 부엑터 : 서비스를 제공하는 외부 시스템(조직, 기관)
    • 유스케이스 : 사용자 관점에서 시스템이 엑터에게 제공하는 서비스 or 기능 표현한 것
    • 관계 : 엑터-유스케이스 / 유스케이스-유스케이스 // 연관, 포함, 일반화, 확정 관계 표현 가능
•  클래스 다이어그램) 시스템 구성 요소 이해 가능한 구조적 다이어그램 / 시스템 구성요소를 문서화하는 데 사용 / 시스템 모델링에 자주 사용(코딩에 필요한 객체 속성, 함수 등 정보 표현)
  • 구성요소
    • 클래스) 각각의 객체들이 갖는 속성, 오퍼레이션 표현 / 이름, 속성, 오퍼레이션을 표기
    • 제약조건
    • 관계) 클래스-클래스 연관성 
  • 접근제어자) public(+) : 모두 접근 가능 / private(-) : 해당 클래스 내부에서만 접근 / protected(#) : 동일 패키지 내 클래스 or 상속받은 외부 패키지 / package(~) : 동일 패키지 내부에 있는 클래스
• 순차 다이어그램) 상호 작용 과정에서 주고받는 메시지 표현 / 수행 기간 확인 가능 / 클래스 내부에 있는 객체들을 기본 단위 ~> 그들의 상호작용 표현
  • 구성요소
    • 엑터) 시스템으로부터 서비스 요청하는 외부 요소
    • 객체) 메시지 주고 받는 주체
    • 생명선) 객체가 메모리에 존재하는 기간
    • 실행상자) 구동되고 있음을 표현
    • 메시지) 주고 받은 메시지