[정보처리기사] 실기 1단원 '요구사항 확인' 정리

소프트웨어 생명주기(SDLC) 모델 

: 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

 

소프트웨어 생명주기 모델 프로세스 (요설구테유)

1) 요구사항 분석

: 다양한 이해관게자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계

2) 설계

: 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계

3) 구현

: 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계

4) 테스트

: 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계

5) 유지보수

: 시스템이 인수되고 설치된 후

 

 

소프트웨어 생명주기 모델 종류

1) 폭포수 모델

- 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어가는 모델

- 고전적 생명주기 모형

- 요구사항 변경이 어려움

 

2) 프로토타이핑 모델

- 발주자나 개발자 모두에게 공동의 참조 모델을 제공

 

3) 나선형 모델

- 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해가는 모델

- 계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가

 

 

애자일 방법론 유형 

1) XP(eXtreme Programming)

: 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

2) 스크럼

: 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

3) 린

: 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론

 

 

XP의 12가지 기본원리

- 짝 프로그래밍

: 개발자 둘이서 짝으로 코딩하는 원리

- 공동 코드 소유

: 시스템에 있는 코드는 누구든지 언제라도 수정 가능

- 지속적인 통합(CI)

: 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다.

- 계획 세우기

- 작은 릴리즈

:  작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 한다

- 메타포어

: 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원할히 한다는 원리

- 간단한 디자인

- 테스트 기반 개발(TDD : test driven develop)

: 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다

- 리팩토링

: 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리

- 40시간 작업

- 고객 상주

- 코드 표준

 

 

비용산정 모형 종류

1) LoC(Lines of Code)

: 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정

- 비관치 : 가장 많이 측정된 코드 라인 수

- 중간치 : 측정된 모든 코드 라인 수의 평균

- 낙관치 : 가장 적게 측정된 코드 라인 수 

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

 

2) Man Month 모형

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

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

 

3) COCOMO 모형

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

- 조직형(5만 라인 이하) -> 반 분리형(30만 라인 이하) -> 임베디드형(30만 라인 이상)

 

4) 푸트남(Putnam) 모형

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

- 생명주기 예측 모형

 

5) 기능점수(FP) 모형

: 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식

 

 

일정관리 모델 종류

1) 주 공정법 (CPM)

- 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법

2) PERT

- 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리

3) 중요 연쇄 프로젝트 관리(CCPM)

- 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 방법

 

 

소프트웨어 아키텍처 프레임워크

: 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준

 

 

소프트웨어 아키텍쳐 4+1 뷰 (유논프구배)

(1)

유스케이스 뷰

: 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는 데 사용되는 뷰

(4)

논리 뷰

: 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰

프로세스 뷰

: 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현하는 뷰

구현 뷰

: 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰

배포 뷰

: 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

 

 

소프트웨어 아키텍처 패턴

: 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식

 

 

소프트웨어 아키텍처 패턴 유형

1) 계층화 패턴

- 각 하위 모듈들은 특정한 수준의 추상화를 제공하고, 각 계층은 다음 상위 계층에 서비스를 제공

- 서로 마주 보는 두 개의 계층 사이에서만 상호 작용이 이루어짐

 

2) 클라이언트-서버 패턴

- 사용자가 클라이언트를 통해서 서버에 서비스를 요청하면 서버는 클라이언트에게 서비스를 제공

 

3) 파이프-필터 패턴

- 데이터 스트림을 생성하고 처리하는 시스템에서 사용가능한 패턴

- 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복

 

4) 브로커 패턴

- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용

- 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리다이렉션

 

5) 모델 - 뷰 - 컨트롤러 패턴 (MVC)

- 모델 : 핵심 기능과 데이터 보관

- 뷰 : 사용자에게 정보 표시

- 컨트롤러 : 사용자로부터 요청을 입력받아 처리

 

 

소프트웨어 아키텍처 비용 평가 모델 종류

- SAAM

: 변경 용이성과 기능성에 집중

- ATAM

: 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델

- CBAM

: ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델

- ADR

: 구성요소 간 응집도를 평가

- ARID

: 전체가 아닌 특정 부분에 대한 품질요소에 집중

 

 

요구공학

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

 

요구사항 프로세스 (도분명확)

1) 요구사항 도출

- 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계

2) 요구사항 분석

- 도출된 요구사항에 대해 완전성과 일관성을 확보하는 단계

3) 요구사항 명세

- 문서를 작성하는 단계

4) 요구사항 확인 및 검증

- 분석가가 요구사항을 이해했는지 확인하고, 요구사항 문서가 완전한지 검증하는 단계

 

 

 

럼바우 모델링 (객동기)

객체 모델링 (Object Modeling = Information Modeling)	- ER 다이어그램을 만드는 과정까지의 모델링 - 객체 다이어그램을 활용하여 표현
동적 모델링 (Dynamic Modeling)	- 시간 흐름에 따라 동적인 행위를 표현 - 상태 다이어그램을 활용하여 표현
기능 모델링 (Functional Modeling)	- 자료 흐름도(DFD를 활용하여 표현

 

 

 

~ 해당 포스팅은 언데이트 중 ~