Chapter 1. 소프트웨어 개발방법론 활용

[1] 소프트웨어 개발방법론 선정 

 

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

종류	설명
폭포수 모델 (Waterfall Model)	˙ 소프트웨어 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델 ˙ Bohem이 제시한 고전적 생명주기 모형으로서 선형 순차적 모델이라고 함 ˙ 가장 오래된 모델로 적용 경험과 성공 사례가 많음 ˙ 단계별 정의와 산출물이 명확 ˙ 요구사항 변경이 어려움 절차) 타당성 검토→계획→요구사항 분석→설계→구현→테스트→유지보수
프로토타이핑 모델 (Prototyping Model)	˙ 고객이 요구한 주요 기능을 프로토타입으로 구현, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델 ˙ 프로토타입은 발주자나 개발자 모두에게 공동의 참조 모델을 제공 ˙ 프로토타입은 구현 단계의 구현 골격
나선형 모델 (Spiral Model)	˙ 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델 ˙ 비교적 대규모 시스템에 적합 ˙ 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적 ˙ 계획 및 정의, 위험 분석, 공학적 개발, 고객 평가의 개발 주기를 반복해서 수행 절차)  타당성 계획 및 정의→위험분석→개발→고객 평가
반복적 모델 (Iteration Model)	˙구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델 ˙ 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델

 

#. 소프트웨어 개발 방법론 종류

종류	설명
구조적 방법론 (Structure Development)	˙ 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론 ˙ 프로세스 중심의 하향식 방법론 ˙ 구조적 프로그래밍 표현을 위해 나씨-슈나이더만 차트 사용 ˙ 정형화된 분석 절차에 따라 사용자 요구사항을 파악, 문서화하는 체계적인 분석 방법으로 자료흐름도, 자료 사전, 소단위명세서의 특징을 갖는 방법론 나씨-슈마이더만 차트 특징 - 논리의 기술에 중점을 둔 도형식 표현 장법 - 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현 - 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합
정보공학 방법론 (Information Engineering Development)	˙ 정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론 ˙ 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론 ˙ 정보 시스템의 개발을 위해 개발, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료 중신의 방법론
객체 지향 방법론 (Object-Oriented Development)	˙ 객체라는 기본 단위로 시스템을 분석 및 설계하는 방법론 ˙ 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론 ˙ 객체, 클래스, 메시지를 사용 ˙ 현실 세계의 개체를 하나의 객체로 만들어서 소프트웨어를 개발할 때 조립하듯이 객체들을 조립해서 소프트웨어를 구현하는 방법론
컴포넌트 기반 방법론 (CBD; Component Based Development)	˙ 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론 ˙ 생산성과 품질을 높이고 유지보수 비용을 최소화 할 수 있음 ˙ 컴포넌트 제작 기법을 통해 재사용성을 향상 ˙ 독립적인 컴포넌트 단위의 고나리로 복잡성 최소화 ˙ 소프트웨어 재사용이 가능
애자일 방법론 (Agile Development)	˙ 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발방법론 ˙ 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론
제품 계열 방법론 (Product Line Development)	˙ 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론 ˙ 임베디드 소프트웨어를 작성하는 데 유용한 방법론 ˙ 영역 공학와 응용 공학으로 구분 - 영역 공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역 - 응용 공학 : 제품 요구분석, 제품 설계, 제품을 구현하는 영역

 

#. 비용 산정 모델

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

 

#. 비용산정 모델 분류

분류	설명	종류
하향식 산정방법	경험이 많은 전문가에게 비용산정을 의뢰, 혹은 여러 전문가와 조정자를 통해 산정	전문가 감정 기법 델파이 기법
상향식 산정방법	세부적인 요구사항과 기능에 따라 필요한 비용을 계산	LOC, Man Month, COCOMO, Putnam FP 개발 단계별 노력 기법

 

① 하향식 비용 산정 모델

모델	설명
전문가 감정 기법	˙ 조직 내에 있는 경험이 많은 2명 이상의 전문가에게 비용 산정을 의뢰하는 기법 ˙ 편리하고 신속하게 비용을 산정할 수 있지만, 개인적이고 주관적.
델파이 기법	˙ 전문가 감정 기법의 주관적인 판단을 보완하기 위해 많은 전문가의 의견을 종합하여 비용을 산정하는 기법 ˙ 1명의 조정자와 여러 전문가로 구성됨

 

② 상향식 비용 산정 모델

모델	설명
LOC (Lines of Code)	˙ 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정 ˙ 측정이 쉽고 이해하기 쉬워 많이 사용 ˙ 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정 ˙ 예측치 = (o+4m+p)/6  (o : 낙관치, m : 중산치, p : 비관치)
Man Month	˙ 한 사람이 1개월 동안 할 수 잇는 일의 양을 기준으로 프로젝트 비용을 산정하는 기법 - (Man Month) = (LOC)/(프로그래머의 월간 생산성) - (프로젝트 기간) = (Man Month)/(프로젝트 인력)
COCOMO (COnstructive COst MOdel)	˙ 보헴(Bohem)이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방법 ˙ 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력으로 산정 ˙ 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용 ˙ 규모에 따라 유형을 조직형, 반 분리형, 임베디드 형으로 나뉨 - 조직형(Organic) : 5만 라인 이하 - 반 분리형(Semi-Detached) : 30만 라인 이하 - 임베디드(Embedded) : 30만 라인 이상
푸트남(Putnam) 모형	˙ 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 모형 ˙ 푸트남이 제안, 생명주기 예측 모형이라고 함 ˙ 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함 ˙ 개형 프로젝트의 노력 분포 산정에 이용 ˙ 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소됨 ˙ 푸트남 예측 모델을 기초로 하여 개발된 자동화 추정 도구로서 SLIM이 있음
기능점수 모형 (FP; Function Point)	˙ 요구 기능을 증가시키는 인자별로 가중치를 부여, 요인별 가중치를 합산하여 총 기능의 점수를 계산하는 비용을 산정하느 방식 ˙ 기능점수(FP) = 총 기능점수 X [0.65 + (0.1 X 총 영향도)] ˙ 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여 - 자료 입력, 자료 출력, 명령어, 데이터 파일, 외부루틴과의 인터페이스 등 ˙ 다양한 프로젝트와 개인별 요소를 수용하도록  FP 모형을 기초로 하여 개발된 자동화 추정 도구인 ESTIMACS가 있음
개발 단게별 노력 기법 (Effort Per Task)	˙ LOC 기법을 확장한 기법으로, LOC 기법을 코딩 단계뿐 아니라 SW개발 생명주기 단계별로 적용시켜 모든 단계에서 비용을 산정하는 기법

 

#. 일정관리 모델 종류

- 주 공정법 (CPM)

- PERT

- 중요 연쇄 프로젝트 관리

 

#. CPM에서 임계 경로 기간 계산

- CMP 네트워크를 그려서 가장 긴 경로를 찾는다.

 

 

[2] 소프트웨어 개발방법론 테일러링

 

#. ISO/IEC 12207 표준

- ISO/IEC 12207 표준은 소프트웨어 생명주기 프로세스이다.

- 소프트웨어와 관련된 조직과 사람, 소프트웨어 획득자, 공급자, 개발자 등의 이해관계자들이 각자의 입장에서 수행해야 할 일을 정의하고 지속적으로 개선시키기 위한 활동이다.

 

▼ ISO/IEC 12207 구성

구성	주요 프로세스
기본 공정 프로세스	획득 프로세스, 공급 프로세스, 개발 프로세스, 운영 프로세스, 유지보수 프로세스
조직 공정 프로세스	기반 구조 프로세스, 관리 프로세스, 개선 프로세스, 훈련 프로세스
지원 공정 프로세스	문서화 프로세스, 품질 보증 프로세스, 형상 관리 프로세스, 검증 프로세스, 확인 프로세스, 문제 해결 프로세스, 활동 검토 프로세스, 감사 프로세스

​

① CMMI 개념

- CMMI는 기존 능력 성숙도 모델(CMM)을 발전시킨 것으로, 기존에 소프트웨어 품질 보증 기준으로 사용되던 SW-CMM과 시스템 엔지니어링 분야의 품질 보증 기준으로 사용되던 SE-CMM을 통합하여 개발한 품질 개선 모델이다.

 

② CMMI 모델

모델	설명
단계적 모델	조직의 전체적인 성숙도 확인을 위해 CMMI평가를 5단계의 성숙도 레벨로 정의
연속적 모델	조직의 비즈니스 목적을 충족, 위험 요소를 완화하는 데 중요한 개선사항의 순서를 정하여 적용할 수 있고, 능력 레벨을 이용하여 프로세스 영역별로 성숙도 평가가 가능한 모델

 

③ CMMI 구성

구분	설명
SW-CMM	소프트웨어 능력 성숙도 모델
SE-CMM	시스템 엔지니어링 능력 모델
IPD-CMM	통합 제품 개발 능력 성숙도 모델
Prople-CMM	인력 개발 및 관리 모델
SA-CMM	소프트웨어 획득 모델
SECAM	시스템 엔지니어링 능력 심사 모델

 

④ CMMI 단계적 표현 모델의 성숙도 레벨

수준	레벨	설명
1	초기화 단계 (Initial)	˙ 정의된 프로세스가 없고 작업자 능력에 따라 성과가 좌우되는 단계 ˙ 프로세스 미비/비공식적, 예측 불가
2	관리 단계 (Managed)	˙ 특정한 프로젝트 내의 프로세스가 정의되고 수행되는 단계 ˙ 프로젝트 관리 시스템 정착, 프로젝트 결과의 반복성
3	정의 단계 (Defined)	˙ 조직의 표준 프로세스를 활용하여 업무를 수행하는 상태 표준화, 일관된 프로세스가 존재하는 단계 ˙ 엔지니어링 및 관리 프로세스의 통합
4	정량적 관리 단계 (Quantitatively Managed)	˙ 정량적 기법을 활용하여 핵심 프로세스를 통제하는 단계 ˙ 제품 및 프로세스의 정량적 통제
5	최적화 단계 (Optimized)	˙ 프로세스 역량 향상을 위해 신기술 도입, 프로세스 혁신 활동 수행하는 단계 ˙ 프로세스 개선이 내재화된 조직

 

①  SPICE 모델 개념

- SPICE는 소프트웨어 프로세스에 대한 개선 및 능력측정 기준에 대한 국제 표준이다.

- 소프트웨어 프로세스 평가를 위한 국제 표준이다.

- 미 국방성의 CMM과 비슷한 프로세스 평가를 위한 모델을 제시한다.

 

② SPICE 프로세스 수행 능력 수준

레벨	수준	설명
0	불안정 단계	프로세스가 구현되지 않았거나, 프로세스가 그 목적을 달성하지 못한 단계
1	수행 단계	프로세스의 목적이 전반적으로 이루어진 단계
2	관리 단계	정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도
3	확립 단계	소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행
4	예측 단계	프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행
5	최적화 단계	프로세스 수행을 최적화하고, 지속적으로 업무 목적을 만족

 

#. 테일러링(Tailoring)

- 테일러링은 조직의 표준 프로세스를 커스터마이징하여 프로젝트의 비즈니스적으로 또는 기술적인 요구에 맞게 적합한 프로세스를 얻는 과정이다.

- 프로젝트 상황에 맞게 이미 정의된 개발 방법론의 절차, 기법, 산출물 등을 재활용하여 계획을 수립하는 기법이다.

 

▼ 테일러링 개발 방법론의 기준

1) 내부적 기준

- 목표환경

- 요구사항

- 프로젝트 특성

- 구성원 능력

 

2) 외부적 기준

- 국제 표준 품질 기준

- 법적 규제

 

#. 소프트웨어 개발 프레임워크 적용 시 기대효과

- 개발할 소프트웨어에 대한 품질 보증이 가능

- 소프트웨어 개발 용이성 증가

- 소프트웨어 변경 사항 발생 시 대응이 용이

- 개발하고자 하는 소프트웨어의 복잡도 감소

- 표준화된 연계 모듈 활용으로 상호 운용성 향상

- 개발 표준에 의한 모듈화로 유지보수 용이

- 공통 컴포넌트 재사용으로 중복 예산 절감