Lecture 04: 계획 (프로젝트 관리와 계획) - 1

경희대학교 김정욱 교수님의 소프트웨어 공학 수업을 기반으로 정리한 글입니다.

계획

계획

• 누가 무엇을 어느 기간동안 어떻게 개발해야 하는지 예측하는 작업
• 구현해야 할 기능과 요구하는 성능 및 인터페이스 성능에 따라 개발범위를 정함
• 구현할 프로젝트 특징과 자원 및 생산성에 따라 비용을 예측

계획의 부재

• 높은 불확실성
• 일정의 차질, 경비 초과, 저품질, 높은 유지보수 비용
• 프로젝트의 실패

체계적이고 명확한 계획을 위한 6가지

1. 문제 정의

2. 타당성 분석

3. 소프트웨어 개발 비용 산정

4.소프트웨어 개발 비용 산정 기법

5. 일정 계획

6. 위험 분석

 

이러한 계획이 완료 되면 산출물로 계획서를 만들게 된다.

문제 정의

1. 문제 정의

• 소프트웨어 개발의 첫 작업
• 무엇을 개발할 것인지 명확히 정의 ex) 모바일 게임, PC 게임
• 개발 범위 설정

문제 정의시 필요한 것

• 개발하고자 하는 영역의 배경 지식 ex) 주식 SW개발 - 차트 등 배경 지식
• 기존에 존재하는 유사 시스템을 사용해 보고 분석 

타당성 분석

2. 타당성 분석

• 경제적 타당성: 개발할 시스템에 대해 투자 효율성이 얼마나 높은지, 시장성은 얼마나 큰지 등을 검토해야 한다.
• 기술적 타당성: 사용자가 원하는 수준으로 개발하기 위해 기술적인 어려움은 없는지 검토해야 한다.
• 법적 타당성: 개발 과정에서 사용하는 프로그램 등에 대해 소유권 등의 법적 문제는 없는지 검토해야 한다.                           ex) 라이센스가 있는 오픈소스 -> 출시하면 걸림

경제적 타당성

• 경영자: 기업에 얼마나 많은 이윤을 남겨줄지, 투자 효율성 분석
• 분석가: 투자 대비 효과를 검토 후, 경영자에게 정확한 정보 제공
• 시장 분석을 통해 시장성을 확인
• 이를 통해 개발 여부를 판단

기술적 타당성

• 현재의 기술로 사용자가 요구하는 기능을 구현할 수 있는지 검토
• 하드웨어 성능이 개발에 지장은 없는지 검토
• 개발자의 기술력에 문제가 없는지 검토

법적 타당성

• 개발용 소프트웨어와 도구의 사용이 법적으로 문제가 없는지 검토
• 지적 소유권과 프로그램 보호법이 강화되었기에 법적 문제 꼭 검토해야 함

※ 학생용 버전(교육용)을 사용해 이윤을 추구하면 안 되기에 기업은 개발용 소프트웨어의 도구 사용이 법적으로 문제가 없는지 꼭 검토해야 한다. ex) MATLAB

개발 비용 산정

3. 소프트웨어 개발 비용 산정

개발 비용 산정의 어려움

하드웨어

• 제품의 형상이 명확하고 투입되는 부품이 정해짐
• 생산 공정이 표준화, 자동화되어 개발 비용 산정이 쉬움

소프트웨어

• 사람(개발자)이 중심이어서 개발 인력의 능력에 따라 품질의 차이가 큼
• 개발 프로세스가 다양해서 표준화나 자동화가 어려움
• 체계적인 개발 비용 산정 방법이 중요함

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

• 프로그래머 능력 (초급 vs. 경험자)
• 소프트웨어 복잡도 (단순 어플리케이션 개발 vs. 시스템 프로그램 개발)
• 소프트웨어 크기 (간단한 SW vs. 복잡한 SW)
• 가용 시간 (소프트웨어 사용 시간 ex) 24시간 구동, 10초 구동)
• 요구되는 신뢰도 수준 (작은 게임에서의 오류 vs. 금융 시스템에서의 오류)
• 기술 수준 (고급 언어(ex) C, C++) 개발자 vs. 저수준(Low-level) 언어 개발자)

개발 비용 산정 기법 

4. 소프트웨어 개발 비용 산정 기법

1) 하향식 산정 기법

• 전문가 판단 기법
• 델파이 기법

2) 상향식 산정 기법

• 원시 코드 라인 수 (Line of Code, LOC) 기법
• 개발 단계별 노력 (Effort per Task) 기법

3) 수학적 산정 기법

• COCOMO 방법
• 기능 점수 산정 방법

개발 비용 산정 기법 - 하향식 산정 기법

1) 하향식 산정 기법

위에서 아래로, Top-Down 방식으로, 윗사람 말을 잘 듣는 기법이라고 생각하면 된다.

즉, 전문가(윗사람)의 말을 토대로 비용(소요 인력, 기간)을 산정한다. (경험에 의존하는 방법)

▶ 하향식 산정 기법

 

전문가 판단 기법

조직 내 경험이 많은 2명 이상의 전문가들의 의견을 듣고 결정하는 방법이다.

 

장점

• 경험이 많은 전문가가 판단을 내리기 때문에 신뢰성 있고 편리하다.
• 짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우 유리하다.

단점

• 경험에만 의존하는 경우, 부정확할 수 있다.
• 새로운 프로젝트도 이전과 비슷하다고 쉽게 생각하여 과소평가할 수 있다.

이러한 전문가 판단 기법의 단점을 보완한 것이 델파이 기법이다.

 

델파이 기법

1명의 조정자와 다수의 전문가 의견을 종합해 결정하는 방법이다.

 

전문가의 경험을 중요시하여 비용을 산정하는 것은 전문가 판단 기법과 같지만,

추가로, 전문가의 편경이나 분위기에 영향을 받지 않도록 조정자를 둔다.

▶ 델파이 기법

 

※ 델파이 기법도 조정자가 있긴 하지만, 전문가가 주를 이루기에, 경험에 너무 의존한다는 단점이 있다.

개발 비용 산정 기법 - 상향식 산정 기법

2) 상향식 산정 기법

프로젝트의 세부 작업 단위별로 비용을 산정한 후 전체 비용을 합산하는 방법이다.

▶ 상향식 산정 기법

 

원시 코드 라인 수 (Line of Code, LOC) 기법

원시 코드(소스 코드) 라인 수의 낙관치, 비관치, 중간치를 측정 후 예측치를 구해 비용을 산정하는 기법이다.

때문에 코드가 길면 길수록 비용이 많고, 코드가 짧으면 짧을수록 비용이 작다고 (빠르다) 생각하는 원시적인 방법이다.

• 낙관치: 한 모듈의 라인 수를 가장 적게 생각할 때의 예상 라인 수 (가중치 1 부여)
• 비관치: 한 모듈의 라인 수를 가장 많게 생각할 때의 예상 라인 수 (가중치 1 부여)
• 중간치: 한 모듈의 라인 수를 보통이라고 생각할 때의 예상 라인 수 (가중치 4 부여)
• 예측 LOC: (낙관치 + (4 × 중간치) + 비관치) / 6

※ 원시 코드 라인 수 기법은 코드 줄로만 판단하는 방법인데, 여기서 코드 수를 측정하는 것도 예측일 뿐이다.

 

LOC 기법은 개발 소프트웨어의 총 코드 라인 수를 예측한다.

하지만, 실제 소프트웨어 개발에는 코딩뿐만 아니라 요구분석, 설계 등에서도 인력과 자원이 많이 필요하다.

 

이렇게 코딩 외에 다른 단계는 고려하지 못하는 LOC 기법의 단점을 보완한 것이 개발 단계별 노력 기법이다.

 

개발 단계별 노력 (Effort per Task) 기법 

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

 

M/M: Man Month(person Month), 프로젝트에 투입되는 월 인원으로, 프로젝트 기간이 1달일 때 필요한 인원이다.

ex) 1 M/M: 1명이 한 달간 하면 끝낼 수 있다/ 2명이면 보름(15알)에 끝낼 수 있다.

 

LOC가 코드 줄로 본다고 하면, 개발 단계별 노력 기법은 인건비라고 보면 된다. (한 달 월급)

 

전체적인 설계, 테스트, 유지 보수 단계를 세세하게 구분하기보다는, 해당 기간 동안 수행할 전체적인 작업을 고려해 포괄적으로 비용을 계산한 것이라고 보면 된다. 결국, 해당 작업에 대해 월급을 받을 것이므로, 정확한 업무 시간 산정보다는 전체적인 인건비를 산정한 것이다.

 

그래서 단점으론 월급만 생각하게 된다는 점이 있다. ex) 인터뷰에 드는 기프티콘 비용

 

ex 1) 소프트웨어 개발 기간: 전체 개발 기간 12개월 중, 5명의 개발자는 12개월, 7명의 개발자는 5개월 동안 참여

 

5명의 개발자가 12개월 동안 참여했다는 것은 1명이서 하면 12 × 5 = 60개월 소요된다는 의미이고,

7명의 개발자가 5개월 동안 참여했다는 것은 1개월 만에 끝내려면 35명의 개발자가 투입되어야 한다는 의미이다.

 

노력 M/M: (5 × 12) M/M + (7 × 5) M/M = 95 M/M

 

즉, 한 달 안에 끝내려면 95명이 필요한 것이고, 만약 12개월 안에 끝내려면 95 / 12으로, 약 8명 정도가 필요하다.

또 만약, 혼자 개발한다면 95개월, 약 8년 동안 만들어야 한다.

 

ex 2) 소프트웨어 개발 기간: LOC 기법에 의해 예측한 총 라인 50,000, 개발자 10명 참여, 개발자들이 월 평균 500라인 코딩

 

개발자들이 월 평균 500라인을 코딩한다는 것은 한 명당 한 달에 500줄을 짠다는 의미이다.

 

노력 M/M: 50,000 / 500 = 100 M/M

 

개발 기간: (100 M/M) / 10명 = 10개

 

100명이 1개월 동안 짜니, 10명이서 짜면 10개월이 걸린다.

개발 비용 산정 기법 - 수학적 산정 기법

3) 수학적 산정 기법

지금까지는 공산주의식으로 무든 사람이 동일한 일을 한다는 식으로 똑같이 분배하는 느낌이었는데,

수학적 산정 기법은 소프트웨어의 난이도에 따라 달라진다는 개념이 첨가된, 이전 것들 보단 디테일한 기법이다.

 

COCOMO 방법

COnstructive COst MOdel의 약자로, PM(M/M)을 계산한다.

▶ PM 계산 1

 

KDSI (Kilo Delivered Source Information): 소프트웨어의 최종 원시 코드 라인 수 (천 단위)

ex) 코드가 3000 줄이면, KDSI는 3이다.

▶ PM - 상수

• 단순형: 복잡도와 난이도가 비교적 높지 않은 업무용 소프트웨어 (크기: 50 KDSI 이하)
• 중간형: 운영체제, 데이터베이스 관리 프로그램 (크기: 300 KDSI 이하)
• 내장형: 하드웨어가 포함된 최상위 규모의 실시간 처리 시스템 (크기: 300 KDSI 이상)

a는 소프트웨어가 어려우면 어려울수록 값이 커진다, 즉 어려우면 어려울수록 사람이 더 많이 필요하다는 걸 의미한다.

b도 마찬가지로 어려우면 어려울 수록, 소스 코드가 길어지면 길어질수록 exponential(지수)한다.

 

하지만 이렇게 코드 숫자만 보는 것은 naive(로직이 없는)한 방법이기에 노력 조정 수치가 추가된다. (가중치)

▶ PM 계산 2

 

EAF (Effort Adjustment Factor): 노력 조정 수치 (프로젝트의 특징 고려)

▶ PM - EAF

 

ex) 1. 요구되는 신뢰도가 높음 (1.15), 2. 매우 복잡 (1.30), 3. 소프트웨어 공학 기술을 거의 사용하지 않음 (1.24), 4. 개발 일정이 매우 촉박 (1.10), 50 다른 요소들은 보통 (1.00)

 

EAF = 1.15 × 1.30 × 1.24 × 1.10 = 2.04

 

즉, 코딩하는 단계만 포함된 것이 아니라, 요구분석, 설계, 테스트 이러한 단계도 포함되어 있는 개념이다.

 

※ 소프트웨어 공학 기술을 사용한다는 것은 얼마나 체계적인지를 나타낸다. 이때, 소프트웨어 공학 기술을 사용하지 않을 수록 숫자가 높은 것은, 체계적이지 않기에, 즉 대충 만들기에 시간이 더 오래 걸리게 되기 때문이다.

 

그리고 COCOMO 방법은 이렇게 구한 PM을 가지고, 총 개발 기간을 계산할 수도 있다.

▶ TDEV 계산

 

TDEV (Total DEVelopment time): 총 개발 기간

▶ TDEV - 상수

 

어려울수록 기간이 짧아지는 이유는, 어려울수록 더 체계적이기에 시간이 짧게 걸린다고 생각하기 때문이다.

 

ex) 개발하려는 KDSI: 60, 소프트웨어 중간형, 노력 조정 수치(EAF): 2.04

▶ PM / TDEV 예시 문제 정답

 

하지만 COCOMO 방법은 계획 단계에서 원시 코드 라인 수를 정확히 예측할 수 없다는 한계가 있다.

이러한 한계를 극복하기 위해 나온 방법이 기능 점수 산정 방법이다.

 

기능 점수 산정 방법

언어의 종류, 개발자의 수준, 알고리즘에 따라 생성되는 코드의 라인 수가 달라지는데,

때문에 라인 수와 무관하게 기능(모듈, 함수, 요)이 많으면 규모도 크고 복잡도도 높다고 판단하는 것이 기능 점수 산정 방법이다.

▶ 기능 점수 산정 방법

• 기능 수(함수의 입출력 수)를 고려

이때, 기능(what의 개념) 수를 고려하기 때문에 소프트웨어 개발에 사용하는  프로그래밍 언어(how의 개) 종류와는 무관하다.

 

※ 박스 하나가 기능 하나를 의미한다. (입력 1개, 출력 1개)

 

장점

• 사용자의 요구사항만으로 기능을 추출해 측정한다. (소프트웨어 공학적임)
• 구현 기술, 구현 언어, 개발자의 능력에 상관없이 소프트웨어의 규모를 일관성 있게 제공한다.
• 객관적인 요구사항만으로 측정한다.

단점

• 요구사항으로부터 기능을 도출하기 위해 높은 분석 능력이 필요하다.
• 이 방법을 잘 도출할 수 있는 기능 점수 전문가가 필요하다.
• 개발 규모를 예측하는 데는 적합하지만, 실제 개발과는 다를 수 있다.