[S/W Engineering] Chapter 03_계획

Chapter 03_계획

 

"계획"의 "역할"

 - 계획을 제대로 세우지 않고 수행하는 소프트웨어 개발은 일정 지연, 비용 초과, 품질 저하라는 결과를 낳게 됨.

 

"계획"의 "중요성"

 - 소프트웨어 개발의 성패는 비용, 기간, 인력과 같은 자원을 토대로 초기에 얼마나 계획을 잘 세우느냐에 달려있음.

 

"문제 정의"

 - 문제를 정의하려면 개발하고자 하는 영역의 배경 지식이 필요

 - 유사한 프로젝트를 개발한 경험이 있는 분석가가 참여하는 것이 도움이 됨

 - 문제를 파악하기 위해 현재 운영중인 시스템을 사용해 실무 담당자와 면담해 자료를 수집한 후 면밀히 분석해보는 것이 필요

 

{ 타당성 분석 }

"경제적 타당성"

 - 경영자의 입장에서 의사 결정을 하는 데 매우 중요한 요소

 - 시장 분석을 통해 시장성을 확인

 - 경제적 타당성 분석으로 투자 효율성과 시장성을 검증한 후 개발 여부를 판단

"기술적 타당성"

 - 사용자가 요구하는 프로젝트가 최신 기술이 필요하다면 기술적 타당성을 먼저 검토

 - 요구하는 기술을 회사가 가지고 있는지 확인

 - 부족하다면 필요한 기술을 갖고 있는 소프트웨어 개발자를 채용하거나 외주 개발로 해결

"법적 타당성"

 - 오픈소스는 소프트웨어 개발에서 분쟁 발생 소지가 높음

 - 소프트웨어 개발에서 오픈소스를 사용하는 것은 비용 절감 측면에서 매우 효율적

 - 오픈소스는 원시 코드가 개방되어 있다는 것이지, 아무렇게나 가져다 사용할 수 있는 것은 아님

 - 법적인 문제가 발생하지 않으려면 오픈 소스를 사용할 때 어디까지 무료로 사용할 수 있는지 확인해야 함

 

"개발 비용에 영향을 주는 요소"

 - 프로그래머 자질   (초급 프로그래머와 경험이 많은 프로그래머의 생산성에는 큰 차이가 있음)

 - 소프트웨어 복잡도   (브룩스의 법칙 : 애플리케이션을 개발하는 것보다 유틸리티를 개발하는 것이 세 배 어렵고, 그보다 시스템 프로그램을 개발하는 것이 세 배 어렵다)

 - 소프트웨어 크기   (개발하려는 소프트웨어의 규모가 클수록 개발 인력과 개발 기간, 복잡도가 늘어남)

 - 가용 시간   (관리자의 잘못된 생각 中 하나 : 개발 기간을 단축하려면 인력과 자원을 늘리면 된다. )

                  (보엠 : "정상적인 계획에서 최대 75%가 줄일 수 있는 한계")

 - 요구되는 신뢰도 수준   (사고나 오류 발생 시 재산에 큰 손실을 끼치거나, 인명 피해가 발생할 수 있는 S/W들은 개발 시 높은 신뢰도를 요구)

 - 기술 수준   (소프트웨어 개발 시 고급 언어를 사용하면 저수준 언어를 사용할 때보다 프로그래머의 생산성이 5~10배 높아짐)

 

{ 비용 산정 기법 : 1. 하향식 산정 기법 }

>> 전문가 판단 기법

- 경험이 많은 여러 전문가가 프로젝트를 수행하는 데 비용이 어느 정도 들어가는지 평가한 금액을 개발 비용으로 산정

- 경험이 많은 전문가가 판단을 내린 만큼 신뢰성 있고 편리하다는 장점

- 짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우 많이 사용

수학적 계산에 의해 산정하지 않고 경험에만 의존할 경우 부정확할 수 있음

 

>> 델파이 기법

- 전문가의 경험을 중요시해 비용을 산정하는 것은 같으나, 전문가들의 편견이나 분위기에 영향을 받지 않도록 “조정자”를 둠.

- 여러 전문가가 모여 각자의 의견대로 비용을 산정 후 결과를 공유하고 의견을 조율하여 개발 비용을 산정

1) 조정자는 전문가가 모여 비용 산정을 하는 회의에서 간사 역할을 수행

2) 전문가는 비용을 산정할 수 있는 자료를 충분히 검토, 필요하다면 의견을 나눌 수 있음

3) 전문가 각자가 비용을 산정한다. 이때 계산된 결과를 조정자에게 익명으로 제출

4) 조정자는 각 전문가가 제출한 자료를 요약 정리

5) 조정자는 각 전문가가 제출한 자료에서 산정 내용에 차이가 크면 이 문제를 해결하기 위해 회의를 소집

6) 전문가는 다시 익명으로 비용 산정 작업을 실시

 

{ 비용 산정 기법 : 2. 상향식 산정 기법 }

>> 원시 코드 라인 수 기법

- 소프트웨어 각 기능의 원시 코드 라인 수 LOC의 비관치, 낙관치, 중관치를 측정해서 예측치를 구하고 이를 이용해 노력, 개발 비용, 개발 기간, 생산성 등의 비용을 산정하는 기법

 

>> 개발 단계별 노력 기법

- 각 기능을 구현하는 데 필요한 M/M을 소프트웨어 개발 생명주기의 각 단계에 적용해 단계별로 산정

 

 

{ 비용 산정 기법 : 3. 수학적 산정 기법 }

{ COCOMO 방법 }

>> COCOMO 방법의 “개요”

- 소프트웨어 개발 비용을 산정할 때 원시 코드의 크기, 즉 “라인 수”를 중심에 두는 방법

- 먼저 완성될 소프트웨어의 크기(라인 수 LOC)를 추정하고 이를 준비된 식에 대입해 개발에 필요한 M/M을 예측

 

>> COCOMO 방법의 “고려 사항”

- 프로그램 유형에 따른 가중치를 두어야 함

- 개발하려는 소프트웨어를 제품, 컴퓨터, 개발자, 프로젝트의 4가지 특성에 따라 총 15가지로 분류한 후 인건비를 더 보정

 

>> 가중치 반영하기

1) “단순형” 프로젝트

- 복잡도와 난이도가 비교적 높지 않은 업무용 소프트웨어가 이에 해당

- 중소 규모 정도이고, 크기는 50KDSI 이하

 

2) “중간형” 프로젝트

- 일반 업무용 소프트웨어보다 복잡하고 규모가 더 큰 운영체제, 데이터베이스 관리 프로그램 등이 이에 해당

- 규모나 복잡도가 중간 정도, 크기는 300KDSI 이하

 

3) “내장형(임베디드형)” 프로젝트

- 자동화 기기나 전자 제품과 같은 하드웨어와 밀접하게 관련있는 내장형 소프트웨어가 이에 해당

- 크기는 300KDSI 이상

 

>> 개발 인건비 초기 예측

- 규모가 같은 소프트웨어일 경우 [ 기본형 < 중간형 < 내장형 ] 순으로 M/M이 더 필요

 

{ COCOMO II 방법 }

>> 애플리케이션 합성 모델

- 1단계에서는 입출력 화면 중심의 사용자 인터페이스 개수 등을 계산해 다음의 객체 점수를 산출

- 개발 범위에 속한 객체(입출력 화면 등)를 찾음

- 객체가 제공하는 기능의 복잡도를 3가지(단순형, 보통형, 복잡형)로 분류

- 객체의 개수에 가중치(단순형, 보통형, 복잡형)를 부여해 결괏값을 산출

 

>> 초기 설계 모델

- 2단계는 초기 설계 단계에서 예측값을 구함

- 초기 설계 단계쯤 되면 1단계보다는 시스템의 구조와 기능을 좀 더 상세히 알 수 있어 1단계보다 더욱 정확한 예측이 가능

 

>> 구조 설계 이후 모델

- 3단계에서는 이미 기능 점수가 나왔기 때문에 노력을 추정하는게 어렵지 않음

- 기능 점수를 바탕으로 한 LOC를 추정해 소프트웨어 규모를 산정

 

{ 기능 점수 산정 방법 }

>> 기능 점수 산정 방법의 “개요”

- 사용자 관점에서 소프트웨어의 기능을 정량화해 소프트웨어 개발 비용 산정에 활용

- 소프트웨어의 기능이 얼마나 복잡한가를 상대적인 점수로 표현

- 사무용 또는 관리용 소프트웨어에서 매우 유용한 방법

 

>> 기능 점수 산정 방법의 “용도”

- 소프트웨어 개발 시 비용을 산정하는 데 사용

- 소프트웨어 유지보수 비용을 산정하는 데 사용

- 소프트웨어 개발 시 필요한 자원을 산정하는 데 사용

 

>> 기능 점수 산정 방법의 “특징”

- 소프트웨어 규모를 측정하는 방법

- 기능적 요구사항이 중심이 되는 측정 방법

- 소프트웨어의 요구사항 복잡도를 측정

- 구현 관점(물리적 파일, 화면, 프로그램 수)이 아닌 사용자 관점의 요구 기능을 정량적으로 산정

- 측정의 일관성을 유지하기 위해 개발 기술, 개발 방법, 품질 수준 등은 고려하지 않음

- 소프트웨어 개발에 사용하는 언어와 무관

- 소프트웨어 개발 생명 주기의 전체 단계에서 사용 가능

 

>> 기능 점수 산정 방법의 구분

- 기능 점수의 기준이 되는 소프트웨어 기능은 크게 데이터 기능과 트랜잭션으로 구분

- SW사업 대가산정 가이드에서 제시하는 기능 점수 산정 방법 구분

 

>> 기능 점수 산정 방법의 “장점”

- 사용자의 요구사항만으로 기능을 추출해 측정

- 객관적인 요구사항만으로 측정

- 모든 개발 단계에서 사용

 

>> 기능 점수 산정 방법의 “단점”

- 높은 분석 능력 필요

- 기능 점수 전문가 필요

- 내부 로직 위주의 소프트웨어에는 다소 부적합

- 개발 공수보다 개발 규모 측정에 적합

 

{ 간이 기능 점수법을 이용한 점수 산정 방법 }

- 간이 기능 점수법 : 프로젝트 초기 단계에서 각 기능의 요소를 모르는 경우, 평균 복잡도 가중치를 사용해 소프트웨어 기능의 크기를 측정

- 평균 복잡도 가중치 : 과거에 수행한 소프트웨어의 기능 점수 산정 결과를 분석해 5가지 유형에 적용된 복잡도를 계산한 가중치의 평균값

- 사업 초기에는 기능 점수를 산정할 수 있을 만큼 자료가 충분하지 않으므로 평균 복잡도 가중치에 의존해 기능 점수를 산정

- 정상적인 기능 점수 산정 결과를 검증할 때도 평균 복잡도 가중치를 적용해 기능 점수를 산정

 

>> 측정 유형 결정

- 개발 프로젝트 기능 점수(개발 규모 측정)

- 개선 프로젝트 기능 점수(변경 규모 측정)

- 애플리케이션 기능 점수(응용 규모 측정)

 

>> 애플리케이션 경계

- 기능 점수를 계산하는 대상을 제외한 다른 애플리케이션이나 외부 사용자를 구분한 경계

- 경계를 지을 때 “사용자” 관점에서 구분해야 함. (개발자 관점에서 구분 X)