[정보처리기사] 실기 정리 - 1과목 (2)

🧀 요구 사항

1. 개념

문제의 해결 또는 목적 달성을 위하여 고객에 의해 요구되거나 표준이나 명세 등을 만족하기 위하여 시스템이 가져야 하는 서비스 또는 제약 사항

• 기능적 요구 사항
  • 개념 : 시스템이 제공하는 기능 및 서비스에 대한 요구 사항
  • 특성 : 기능성, 완전성, 일관성

• 비기능적 요구 사항
  • 개념 : 시스템이 수행하는 기능 이외의 사항, 시스템 구출에 대한 제약사항에 관한 요구 사항
  • 특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성

2. 개발 프로세스

(1) 요구 사항 도출

요구 사항이 어디에 있고, 어떻게 수집할 것인지를 파악하는 단계

• 인터뷰 : 1:1로 사용자 및 사용자 측 의사 결정권자와 시스템에 대한 요구 사항을 추출

• 설문 조사 : 설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집

• 브레인스토밍 : 말을 꺼내기 쉬운 분위기에서 회의 참석자들이 내놓은 아이디어들을 비판 없이 수용할 수 있도록 하는 회의

• 워크숍 : 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법

(2) 요구 사항 분석

상충되는 요구 사항을 해결하고, 소프트웨어의 범위 파악 및 소프트웨어가 환경과 어떻게 상호 작용하는지 이해하는 단계

• 자료 흐름 지향 분석 : 데이터 흐름으로부터 소프트웨어 구조를 유도하는 방법

• 객체지향 분석 : 시스템의 기능과 데이터를 함께 분석

(3) 요구 사항 명세

체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계

• 자연어에 의한 방법 : 사용자와 개발자의 이해가 용이

• 정형화 기법 사용 방법 : 명확성 및 검증이 용이

(4) 요구 사항 확인

요구 사항 문서가 표준에 적합하고 이해 가능하며, 일관성이 있고 완전한지 검증하는 단계

• 동료 검토 : 요구사항 명세서 작성자가 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태

• 워크 스루 : 검토 자료를 회의 전에 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태

• 인스펙션 : 소프트웨어 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 형태

3. 관리 프로세스

• 요구 사항 협상
  가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능을 협상하기 위한 기법
  ex. 우선순위 설정, 시뮬레이션

• 요구 사항 기준선
  공식적으로 검토되고 합의된 요구 사항 명세서
  ex. 공식 회의, 형상 관리

• 요구 사항 변경 관리
  요구 사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법
  ex. CCB, 영향도 분석

• 요구 사항 확인 및 검증
  구축된 시스템이 이ㅐ관계자가 기대한 요구 사항에 부합하는지 확인하기 위한 방법
  ex. 확인 및 검증

4. 분석 기법

• 요구 사항 분류
  요구 사항이 기능인지 비기능인지 확인

• 개념 모델링
  시나리오로 나타내기 위해 유스케이스 다이어그램을 주로 사용

• 요구 사항 할당
  요구 사항을 만족시키기 위한 아키텍처 구성요소를 식별하는 활동

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

• 정형 분석
  형식적으로 정의된 의미를 지닌 언어로 요구 사항을 표현

5. 확인 기법

• 요구 사항 검토
  여러 검토자가 에러, 잘못된 가정, 불명확성, 표준과의 차이를 검토

• 프로토타이핑
  새로운 요구 사항을 도출하기 위한 수단 및 소프트웨어 요구 사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 사용

• 모델 검증
  분석 단계에서 개발된 모델의 품질 검증

• 인수 테스트
  요구 사항의 중요한 속성은 최종 제품을 기준으로 요구 사항을 만족시키는지 확인이 가능해야 함

6. 확인 프로세스

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

• 요구 사항 정의서 작성 여부 확인
  요구 사항 목록 중 수용인 경우, 요구 사항 정의서가 작성되었는지 확인

• 비기능적 요구 사항의 확인
  시스템 특정, 품질, 제약사항 등 비기능적 요구 사항이 명확하게 도출되었는지 검토

• 타 시스템 연계 및 인터페이스 요구 사항 확인
  타 시스템 또는 하위 시스템 등과의 모든 인터페이스 요구 사항이 정의되어 있는지 확인

🧀 요구 사항의 타당성 분석

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

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

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

• IT 시장 성숙도 및 트렌드 부합성
  시스템 구축 시 요구되는 영역별 기술들의 시장 성숙도 및 발전 방향을 파악하고 요구 사항이 이에 부합하는지 판단

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

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

• 타당성 분석 결과 기록
  요구 사항 목록에 타당성 분석을 위한 속성을 추가하고 타당성 분석 결과를 기록

• 타당성 분석 결과 검증
  요구 사항의 시스템화 타당성 분석 결과를 관련 이해관계자에게 배포하여 사전 검토를 요청

• 타당성 분석 결과 확인 및 배포, 공유
  이해관계자 검증을 거친 타당성 분석 결과를 의사 결정자가 확인

🧀 비용 산정 모델

1. 개념

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

2. 하향식 모델

경험이 많은 전문가에게 비용 산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식

(1) 전문가 판단

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

(2) 델파이 기법

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

3. 상향식 모델

세부적인 요구 사항과 기능에 따라 필요한 비용을 계산하는 방식

(1) Lines of Code

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

• 예측치 : $\frac{(o+4m+p)}{6}$ ($o$ : 비관치, $m$ : 중간치, $p$ : 낙관치)

(2) Man Month

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

• Man Month : LoC / 프로그래머의 월간 생산성

• 프로젝트 기간 : Man Month / 프로젝트 인력

(3) COCOMO

보헴이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 기법

• 단순형
  5만 라인 이하의 소프트웨어를 개발하는 유형

• 중간형
  30만 라인 이하의 소프트웨어를 개발하는 유형

• 임베디드형
  30만 라인 이상의 소프트웨어를 개발하는 유형

(4) 푸트남 모형

소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 모형

• 자동화 추정 도구 : SLIM

(5) 기능점수 모형

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

• 정규법
  각 기능의 속성을 정의하여 기능별 복잡도 매트릭에 의한 기능 점수를 산정하는 방식

• 간이법
  개략적인 사용자 요구 사항을 바탕으로 기능 점수를 도출하여 평균 복잡도에 의한 기능 점수를 산정하는 방식

🐭 참고문헌

• NCS 정보처리기술사 연구회. (2020). 수제비 정보처리기사 실기 (2판). 건기원.