1. 요구사항 확인

1. 요구사항 확인
◆ 소프트웨어 생명주기 (SDLC): 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

◆ 비용산정 모형 분류
하향식 산정방법: 경험이 많은 전문가에게 비용산정 의뢰 또는 전문가와 조정자를 통해 비용산정, 전문가 판단
델파이 기법: 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법
상향식 산정방법: 세부적인 요구사항과 기능에 따라 필요한 비용 산정
코드 라인 수(LoC: Lines of Code): 원시 코드 라인수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구해 비용산정
Man Month: 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 비용산정
(Man Month) = (LoC) / (프로그래머의 월간 생산성)
(프로젝트 기간) = (Man Month) / (프로젝트 인력)

COCOMO 모형: 보헴이 제안한 모형으로 프로그램의 규모에 따라 비용산정
조직형(Organic Mode): 5만(50KDSI)라인 이하
반 분리형(Semi-Detached Mode): 30만(300KDSI)라인 이하
임베디드형(Embedded Mode): 30만(300KDSI)라인 이상
푸트남(Putnam) 모형: 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
기능점수(FP) 모형: 소프트웨어 기능을 증대시키는 요인별로 가중치를 부여하여 비용산정

◆ 소프트웨어 아키텍처: 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체

◆ 소프트웨어 아키텍처 4+1 뷰: 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

유스케이스 뷰: 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰
논리 뷰: 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
프로세스 뷰: 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
구현 뷰: 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰, 컴포넌트 구조와 의존성을 보여주고 부가적인 정보 정의
배포 뷰: 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

◆ 디자인 패턴 종류

생성패턴: Builder, Prototype, Factory Method, Abstract Factory, Singleton
구조패턴: Bridge, Decorator, Facade, Flyweight, Proxy, Composite, Adapter
행위패턴: Mediator, Interpreter, Iterator, Template Method, Observer, State, Visitor, COmmand, Strategy, Memento, Chain of Responsibility

◆ 요구공학(Requirements Engineering): 사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 호가인 및 검증하는 구조화된 활동

◆ 요구사항의 분류
기능적 요구사항: 시스템이 제공하는 기능, 서비스에 대한 요구사항
특정 입력/상황에 대해 시스템이 어떻게 반응/동작 해야 하는지에 대한 기술
특성: 기능성, 완전성, 일관성
비기능적 요구사항: 시스템 구축에 대한 제약사항에 관한 요구사항
품질 속성에 관련하여 시스템이 갖춰야할 사항에 관한 기술, 시스템이 준수해야 할 제한 조건에 관한 기술
특성: 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항

◆ 요구공학 프로세스: 도출 → 분석 → 명세 → 확인 및 검증

◆ 요구사항 도출 단계 주요 기법
인터뷰, 브레인스토밍, 델파이기법, 롤 플레잉, 워크숍, 설문조사

◆ 요구사항 도출
주요기법
- 인터뷰(Interview) : 이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집 방법
- 브레인스토밍(Brainstorming) : 말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판없이 수용할 수 있도록 하는 회의
- 델파이 기법(Delphi Method) : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 방법
- 롤 플레잉(Role Playing) : 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법
- 워크숍(Workshop) : 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법
- 설문조사(Survey) : 설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집하는 방법

◆ 요구사항 확인 및 검증 단계의 주요 기법
요구사항 검토: 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토
정형 기술 검토 활용
동료 검토: 2~3명 리뷰 진행, 요구사항 명세서를 설명하고 이해관계자들이 들으면서 결함을 발견하는 형태로 진행
워크 스루: 검토 자료를 회의 전에 배포하여 짧은 시간동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화
인스펙션: 소프트웨어 요구, 설계 원시 코드 등의 저작자 외의 다른 전무가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토방법

◆  CCB(Configuration Control Board; 형상통제 위원회): 형상 관리에 대하여 주요 방침을 정하고 산출물을 검토하며, 단계별 의사결정을 수행하는 조직

◆ 유스케이스 모델 검증
시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해서 액터, 유스케이스, 유스케이스 명세서 점검