New 병아리 개발자

*분석 모델 검증

- 분석 모델 검증이란 요구사항 도출 기법을 활용하여 업무 분석가가 제시한 분석 모델에 대해 확인하는 활동이다.

1. 분석 모델 검증 방법

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

- 개념 수준의 분석 클래스 검증 : 시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하므로, 개념 수준의 주요 분석 클래스를 적절히 도출하였는지, 관련 정보가 명확한지 점검한다. 주요 클래스 도출 여부, 도출된 클래스 이름과 속성의 적절성, 올바른 클래스들 간의 관계 여부 점검

- 분석 클래스 검증 : 유스케이스 실현에 필요한 분석 클래스 도출 확인. 유스케이스 별로 도출된 분석 클래스들이 스테레오 타입으로 표시되었는지 확인. 경계와 제어 클래스의 도출 여부 및 상세화 정도 확인. 클래스 간의 관계, 클래스 정보의 상세화 정도를 확인 한다.

1-1. 분석 클래스의 스테레오 타입

- 경계 (Boundary) : 시스템과 외부 액터와의 상호작용을 담당하는 클래스

- 엔티티 (Entity) : 시스템이 유지해야 하는 정보를 관리하는 기능을 전담하는 클래스

- 제어 (Control) : 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스

- 스테레오 타입을 통해 분석 클래스 검증을 한다.

2. 분석 모델 검증 프로세스

- 검토의견 컬럼 추가 : 분석 모델까지 요구사항 추적표를 작성하고 검토의견 컬럼 추가

- 검토의견 작성 : 요구사항 목록을 참조하여 요구사항 ID와 요구사항명 입력. 유스케이스 모델에 대한 검토의견 작성. 개념 수준의 분석 클래스 모델에 대한 검토의견 작성. 분석 클래스 모델에 대한 검토의견 작성

- 검토의견 정제 : 요구사항 추적표에서 요구사항에 대한 검토의견 정제. 누락된 유스케이스 모델/개념 수준 분석 클래스/분석 클래스가 존재하는 경우, 검토의견 추가

*비용산정 모델

1. 비용산정 모델이란

- 소프트웨어 규모 파악을 통한 투입자원, 소요 시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 기법이다.

2. 비용산정 모델의 분류

- 하향식 산정방법 : 경험이 많은 전문가에게 비용산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식이다. 종류에는 전문가 판단, 델파이 기법이 있다.

- 상향식 산정방법 : 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식이다. 종류에는 코드 라인 수(Loc), Man Month, COCOMO 모형, Putnam 모형, FP(Function Point) 모형이 있다.

3. 하향식 비용산정 모델

3-1. 전문가 판단

- 조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용산정을 의뢰하는 기법이다.

3-2. 델파이 기법

- 전문가의 경험적 지식을 통한 문제해결 및 미래 예측을 위한 기법이다.

- 전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성한다.

- 전문가들은 익명으로 의견을 제출 및 비용을 산정하고, 조정자는 전문가들의 의견을 요약하여 배포하면, 전문가들은 조정자가 요약한 의견을 보고 다시 익명으로 의견을 제출 및 비용을 산정ㅎ한다. 전문가들 간의 의견과 산정된 비용이 거의 일치할 때까지 과정을 반복한다.

4. 상향식 비용산정 모델

4-1. LoC (Lines of Code)

- 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정한다.

- 측정이 쉽고 이해하기 쉬워 많이 사용되며, 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정한다.

- 예측치 = (낙관치 + (4 * 중간치) + 비관치) / 6

(비관치 : 가장 많이 측정된 코드 라인 수 / 중간치 : 측정된 모든 코드 라인 수의 평균 / 낙관치 : 가장 적게 측정된 코드 라인 수)

4-2. Man Month

- 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 기법

- Man Month = LoC / 프로그래머의 월간 생산량

- 프로젝트 기간 = Man Month / 프로젝트 인력

4-3. COCOMO (COnstructive COst MOdel)

- 보헴이 제안, 프로그램 규모에 따라 비용을 산정한다.

- 개발 노력 승수를 결정한다.

- COCOMO 유형에는 규모에 따라 단순형, 중간형, 임베디드형으로 나뉜다.

- 단순형 (Organic Mode) : 기관 내부에서 개발된 중, 소규모의 소프트웨어로 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리 개발에 적용된다. 5만( 50 KDSI : 소스 코드를 1,000라인으로 묶은 단위 ) 라인 이하의 소프트웨어를 개발하는 유형

- 중간형 (Semi-Detached Mode) : 단순형과 임베디드형의 중간형이다. 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 개발에 적용한다. 30만( 300KDSI ) 라인 이하의 소프트웨어를 개발하는 유형

- 임베디드형 (Embedded Mode) : 초대형 규모의 트랜잭션 처리 시스템이나 운영체제 개발에 적용한다. 30만( 300KDSI ) 라인 이상의 소프트웨어를 개발하는 유형

4-4. 푸트남 (Putnam) 모형

- 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 모형이다. 자동화 추정 도구로 SLIM이 있다.

4-5. 기능점수 (FP : Function Point) 모형

- 요구 기능을 증가시키는 인자별로 가중치를 부여하여 기능 점수를 계산하여 비용을 산정하는 방식이다.

- 입력, 출력, 질의, 파일, 인터페이스의 개수로 소프트웨어의 규모를 표현한다.

- 원시 코드의 구현에 이용되는 프로그래밍 언어에 독립적이다.

- 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여한다.

- 프로젝트의 영향도와 가중치의 합을 이용하여 기능점수를 계산한다.

- 정규법 : 각 기능의 속성을 정의하여 기능별 복잡도 매트릭에 의한 기능 점수를 산정하는 방식으로 상세한 기능점수 측정이 가능하다.

- 간이법 : 개략적인 사용자 요구사항을 바탕으로 기능점수를 도출하여 평균 복잡도에 의한 기능점수를 산정하는 방식으로 프로젝트 초기에 개발 비용 측정이 가능하다.

*요구사항의 시스템화 타당성 분석

- 업무 분석가가 수집하고 분석한 요구사항이 개발하고자 하는 응용 소프트웨어에 미칠 영향에 대해 검토하고 확인해야 한다.

1. 요구사항의 기술적 타당성 검토

- 성능 및 용량 산정의 적정성 :  목표 시스템의 용량이 산정되면, 과거 유사 프로젝트 경험치를 적용하여 필요시 재조정한 후, 성능 관련 비기능 요구사항과 비교하여 적정성 여부를 판단한다.

- 시스템 간 상호 운용성 : 요구사항 중에서 목표 시스템이 조직 내외 타 시스템과의 연동을 요구하는 경우, 상호 운용이 가능한지 여부를 판단한다.

- IT 시장 성숙도 및 트렌드 부합성 : 시스템 구축 시 요구되는 영역별 기술들의 시장 성숙도 및 발전 방향을 파악하고, 요구사항이 이에 부합하는지 판단한다. 향후 사용되지 않을 가능성이 높은 시스템들은 향후 유지보수가 어려운 상황이 발생된다.

- 기술적 위험 분석 : 요구사항을 만족시키기 위해 적용한 기술의 복잡성, 검증 여부, 의존성 등에 대하여 위험 발생 가능성, 영향도 파악을 진행한다.

2. 요구사항의 기술적 타당성 분석 프로세스

- 타당성 분석 결과 기록 : 요구사항 목록에 타당성 분석을 위한 속성을 추가하고 타당성 분석 결과를 기록한다. 타당성 분석을 위한 속성에는 성능/용량, 시스템 간 상호 운용성, 시장 성숙도 및 트렌드 부합성, 기술 복잡성, 기술 검증 여부, 기술 의존성이 있다.

- 타당성 분석 결과의 이해관계자 검증 : 요구사항의 시스템화 타당성 분석 결과를 요구사항 관련 이해관계자에게 배포하여 사전 검토 요청을 한다. 관련 이해관계자가 모여 시스템화 타당성 분석 결과를 검증한다. 타당성 분석 결과에 이견이 있는 경우 프로젝트 관리자의 중재 하에 합의를 도출한다.

- 타당성 분석 결과 확인 및 배포/공유 : 이해관계자의 검증을 거친 타당성 분석 결과를 의사 결정자가 확인한다. 확정된 타당성 분석 결과를 이해관계자에게 배포하여 공유한다. 

*요구사항 분석/확인

1. 요구사항의 분석

- 요구사항 분석 기법으로 요구사항 분류, 개념 모델, 요구사항 할당, 요구사항 협상, 정형 분석이 있다.

- 요구사항 분석 기법을 활용하여 업무 분석가가 정의한 응용 소프트웨어의 요구사항을 확인할 수 있다.

1-1. 요구사항 분석 기법

- 요구사항 분류 : 요구사항이 기능인지 비 기능인지 확인 하는 것, 요구사항이 소프트웨어에 미치는 영향의 범위를 파악, 요구사항이 소프트우에어 생명주기 동안 변경이 발생하는지를 확인한다.

- 개념 모델링 : 개념 모델은 문제 도메인의 엔티티들과 개별 관계 및 종속성을 반영한다. 시나리오로 나타내기 위해 유스케이스 다이어그램을 주로 사용, 대부분의 모델링 표기법은 UML을 사용한다.

- 요구사항 할당 : 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별하는 활동이다. 다른 구성요소와 어떻게 상호작용하는지 분석을 통해 추가적인 요구사항의 발견이 가능하다.

- 요구사항 협상 : 두 명의 이해관계자가 서로 상충되는 내용을 요구하는 경우 어느 한쪽을 지지하기보다는 적절한 지점에서 합의하기 위한 기법이다.

- 정형 분석 : 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현하는 것, 정확하고 명확하게 표현, 요구사항 분석의 마지막 단계에서 이루어진다.

2. 요구사항의 확인

- 업무 분석가가 요구사항을 이해했는지 확인하는 것이 필요하고, 요구사항 문서가 기업의 표준에 적합하고 이해 가능하고, 일관성이 있고, 완전한지 검증해야 한다.

2-1. 요구사항 확인 기법

- 요구사항 검토 : 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이를 검토, 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자 1명 이상 포함 필요, 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서를 완성한 시점에서 검토한다.

- 프로토 타이핑 : 새로운 요구사항을 도출하기 위한 수단 및 소프트웨어 요구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 사용한다. 요구사항이 잘못된 경우 유용한 피드백 제공, 사용자 인터페이스의 동적인 행위가 문서나 그래픽 모델보다 이해가 용이하다.

- 모델 검증 : 분석단계에서 개발된 모델의 품질 검증 필요, 객체 모델의 경우 객체들 사이의 존재하는 의사소통 경로를 검증하기 위한 정적 분석 수행에 유용하다.

- 인수 테스트 : 요구사항의 중요한 속성은 최종 제품을 기준으로 요구사항을 만족시키는지 확인 가능해야 한다. 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획 수립 후, 요구사항을 확인하는 테스트이다.

3. 요구사항의 확인 프로세스

- 요구사항 목록 확인 : 요구사항 목록에서 업무 기능에 대한 요구사항 반영 여부 확인

- 요구사항 정의서 작성 여부 확인 : 요구사항 목록 중 수용인 경우, 요구사항 정의서(유스케이스 명세서)가 작성되었는지 확인, 요구사항 정의서(유스케이스 명세서)에서 시스템의 동작 방식을 명확하고 구체적으로 기술하고 있는지 검토한다.

- 비 기능적 요구사항의 확인 : 시스템 특성, 품질, 제약사항 등 비 기능적 요구사항이 명확하게 도출되었는지 검토, 성능, 가용성, 사용 용이성, 유지보수 용이성, 안전성, 보안성 등에 대한 요구 사항의 문서화 여부 확인

- 타 시스템 연계 및 인터페이스 요구사항 확인 : 타 시스템 또는 하위 시스템 등과의 모든 인터페이스 요구사항이 정의되어 있는지 확인, 인터페이스 구분(내부/외부), 주기, 방법, 제공자, 요청자 등이 명확하게 정의되어 있는지 확인한다.