8 Estimation #1398
Description
제 8 장 예측
최대 개발 속력을 얻으려면 일정을 정확하게 예측해야 한다.
정확한 일정 예측 없이는 계획을 효과적으로 수립할 근거가 없으며, 결국 쾌속 개발을 이루기 어렵다.
8.1 소프트웨어 예측 이야기
사람들은 개별적인 사실보다 이야기를 더 쉽게 기억하며, 여기에 소프트웨어 예측이 어려운 이유를 담은 이야기가 있다.
소프트웨어 예측 이야기에서 핵심은 소프트웨어 개발이란 점진적인 개선 과정이라는 사실이다.
만들 제품에 대한 희미한 사진에서 시작해 프로젝트를 진행하면서 초점을 점점 깨끗하게 맞추어 간다.
만들려는 소프트웨어에 대한 사진이 불분명하기 때문에 만드는 데 드는 시간과 노력 예측값도 불분명하다.
소프트웨어를 만들어 가면서 예측값도 초점을 맞추어 갈 수 있다.
소프트웨어 프로젝트 예측 역시 점진적인 개선 과정이다.
소프트웨어와 건축
건축가에게 침실 3개가 있는 집을 1억원 이하에 지을 수 있는지 물어보면
가능하지만 구체적인 비용은 세부사항에 따라 다르다고 할 수 있다 (그림 8-1)
Figure 8-1. It is difficult to know whether you can build the product that the customer wants in the desired time frame until you have a detailed understanding of what the customer wants.
구체화 과정으로서 소프트웨어 개발
각 기능을 상세하게 이해할 때까지는 프로그램 비용을 정확하게 예측할 수 없다.
소프트웨어 개발은 조금씩 더 상세한 결정을 내려가는 과정이다.
제품 개념에서 요구사항을 기술한 문장으로, 요구사항에서 초기 설계로, 초기 설계에서 상세 설계로, 상세 설계에서 실제 돌아가는 코드로 구체화한다.
각 단계에서 궁극적으로 프로젝트 비용과 일정에 영향을 미치는 결정을 내리게 된다.
구체화가 가능한 정도
프로젝트 각 단계별로 예측값이 가지는 정밀도를 예상할 수 있다는 걸 알 수 있고
예측값 수렴 곡선은 프로젝트를 진행함에 따라 예측값이 정확해지는 과정을 보여준다.
프로젝트 초반에는 광범위한 예측값에서 출발해 프로젝트를 진행하면서 점점 구체화해 가야 한다.
예측 vs. 통제
소프트웨어를 만드는데는 예측 정확성과 프로젝트 통제라는 선택에 직면한다.
기능을 넣을지 말지를 결정해야 할 때마다 넣지 않는 쪽을 선택한다.
더 나은 기능을 구현할지 비용을 더 적게 드는 기능을 구현할지 결정해야 할 때마다 더 나은 기능을 선택하고 어떨 때는 비용이 더 적게 드는 기능을 선택한다면 예산을 맞출 수가 없다.
예산을 맞추는 데 필요한 걸 준수하고 이에 따르는 대가를 감수할 수 없다면, 프로젝트 초기 예측값이 크게 부정확해도 어쩔 수 없다.
협력
정확한 예측값을 요구하는 사람들도 타당한 이유는 있다.
그러므로 개발자는 고객에게 예측 관련 정보를 최대한 제공할 책임이 있다.
고객에게 예측할 수 있는 시기를 알려준다.
지금 단계 마지막에 예측할 수 있다면 그렇게 얘기해준다.
더 나은 예측값을 언제 파악할지 안다면 그 때를 말해준다.
핵심은 고객에게 방향을 잃었다는 느낌을 주면 안된다는 것이다.
고객이 계속해서 정확한 예측값을 요구한다면 아직은 못한다고 말해준다.
하지만 협력은 하겠다는 의사는 분명히 전달해야 한다.
예측값과 현실 간 수렴
실제 최단 일정은 가장 정확하고 계획적인 일정에서 얻어진다. (Symons 1991)
예측값이 너무 낮으면 계획 수립시 비효율성으로 프로젝트 실제 비용이 증가한다.
예측값이 너무 낮으면 파킨슨의 법칙에 따라 프로젝트 실제 비용은 증가한다.
예측 활동은 예측값과 현실이 수렴하는 지점을 찾는 과정이다.
두 궤도가 가까워지면 개발자와 고객은 비즈니스 결단과 제품 결정을 바르게 내릴 수 있다.
예측 이야기 요약
예측 이야기는 다은 요점 네 가지를 설명해야 한다.
- 소프트웨어 구현은 주택 건설과 같다. 무엇인지 정확하게 알기 전까지는 얼마나 필요한지를 정확하게 알 수 없다.
- 이상적인 주택과 예산에 맞는 주책이 있다. 예산에 맞게 짓고 싶다면 제품 특성에 유연성이 있어야 한다.
- 소프트웨어 개발은 점진적인 구체화 과정이다. 어느 정도 부정확성을 피할 수가 없다. 건설과 달리 소프트웨어는 제품 개념을 예측하려면 실제로 소프트웨어를 만들어보는 수 밖에 없다.
- 프로젝트를 진행하면서 예측값을 구체화할 수 있다. 각 단계가 진행될 때 마다 고객에게 더 구체적인 예측값을 알려줄 수 있다고 해야 한다.
8.2 예측 공정 필요
개발 일정을 정확하게 수립하는 과정은 다음 세 단계로 이루어진다.
- 제품 크기(기능 점수) 예측하라. 효율적인 예측을 위해 만들 소프트웨어 크기 부터 예측해야 한다.
- 노력(M/M)을 예측하라. 크기 예측과 유사 프로젝트에 대한 기록이 있다면 노력 예측값은 계산하기 쉽다.
- 일정(M)을 예측하라. 크기와 노력이 나오면 일정 예측은 가능하다. 오히려 현실적인 예측값으로 승인을 받는 과정이 어려운 단계이다.
이 세 단계를 포용하는 일반적인 메타 단계가 있다.
- 예측 범위를 제시하고 프로젝트를 진행하면서 예측을 주기적으로 개선해 정밀도를 높인다.
일반적으로 예측이 뜻하는 의미는 무엇인가
"예측은 실현가능한 예상 중 가낭 낙관적인 예상이다."
그렇다면 '끝내지 못한다고 증명할 수 있는 가장 이른' 날짜를 결정하는 예측법을 쓰는 게 맞다. - 톰 드마르코
8.3 크기 예측
- 기능 점수: 크기 예측
- 프로그램 기능 묘사: 크기 예측 소프트웨어 도구 사용
- 유사 프로젝트에서 유추: 유사한 부분을 비교해서 비율 계산
기능 점수 예측
기능 점수 계산법은 1984 IBM 기법으로 IFPUG(International Function Point User Group)가 사용하는 기법의 기반이 된다. (Jones 1991)
프로그램 크기
크기라는 단어는 프로그램 전체를 광범위하게 표현한다.
기능 집합 뿐 아니라 프로그램의 난이도와 복잡도를 포함한다.
프로젝트 초반에 크기를 측정하는 가장 정확한 방법은 기능 점수이다.
때로 상대적인 용어로 크기를 가늠하기도 한다.
예) Umpty-Fratz 버전 2는 버전 4에 비해 75% 정도 크기이다.
요구사항 단계를 넘어가면 크기 개념은 달라진다.
설계에서는 클래스 수, 모듈 수로 측정하며
구현과 테스트 단계에서는 코드 라인 수가 된다.
프로그램 기능 점수는 다음 각 항목 개수와 난이도를 바탕으로 한다.
- 입력: 프로그램 자료를 추가, 삭제, 변경하기 위해 최종 사용자나 다른 프로그램이 사용하는 화면, 폼, 대화창, 컨트롤, 문자열을 가리킨다.
- 출력: 프로그램이 최종 사용자나 다른 프로그램을 위해 만들어 내는 화면, 보고서, 그래프, 문자열을 가리킨다.
- 조회: 간단한 출력값을 즉시 만들어 내는 입출력 조합을 말한다.
- 내부 논리 파일: 최종 사용자 자료 중 핵심 논리 부분이나 프로그램이 통제하는 제어 정보를 가리킨다.
- 외부 인터페이스 파일: 다른 프로그램이 통제하는 파일로 프로그램 사이 통신을 가능하게 한다.
표 8-2에서 복잡도가 낮으면 3을 곱하고 중간이면 4를 곱하는 방식으로 계산한다.
[표 8-2] 기능-점 승수
| 프로그램 특징 | 낮은 복잡도 | 중간 복잡도 | 높은 복잡도 |
|---|---|---|---|
| 입력 수 | * 3 | * 4 | * 6 |
| 출력 수 | * 4 | * 5 | * 7 |
| 조회 | * 3 | * 4 | * 6 |
| 내부 논리 파일 | * 7 | * 10 | * 15 |
| 외부 인터페이스 파일 | * 5 | * 7 | * 10 |
출처: Applied Software Measurement(Jones 1991)
프로그램에 영향을 미치는 14가지 요인을 고려 '영향 승수'를 계산한다.
요인으로 데이터 통신, 온라인 자료, 계산 복잡도, 설치 용이도 등이 있다.
대체로 영향 승수는 그 범위가 0.65 ~ 1.35 이다.
미조정 기능 점수 합에 영향 승수를 곱해서 최종 기능 점수를 얻는다.
표 8-3에서 계산 과정을 볼 수 있다. 값은 임의로 정한 값이며 영향 승수도 예제용 값이다.
결과 기능 점수는 350점이다.
이 값을 통해 과거 프로젝트 크기와 일정을 이용해 새 일정을 계산할 수 있다.
[표 8-3] 기능-점 계산 예제
| 프로그램 특징 | 낮은 복잡도 | 중간 복잡도 | 높은 복잡도 |
|---|---|---|---|
| 입력 수 | 6 * 3 = 18 | 2 * 4 = 8 | 3 * 6 = 18 |
| 출력 수 | 7 * 4 = 28 | 7 * 5 = 35 | 0 * 7 = 0 |
| 조회 | 0 * 3 = 0 | 2 * 4 = 8 | 4 * 6 = 24 |
| 내부 논리 파일 | 5 * 7 = 35 | 2 * 10 = 20 | 3 * 15 = 30 |
| 외부 인터페이스 파일 | 9 * 5 = 45 | 0 * 7 = 0 | 2 * 10 = 20 |
미조정 기능-점 합: 304
영향 승수: 1.15
조정한 기능-점 합: 350
예측 팁
- 즉흥적인 예측을 피하라
- 예측에 시간을 할당하고 계획하라
- 과거 프로젝트 자료를 이용하라
- 개발자가 도출한 예측값을 사용하라
- 검토 회의를 통해 예측하라
- 범주를 나누어 예측하라
- 상세한 수준에서 예측하라
- 평범한 업무라도 빠뜨리지 마라
- 소프트웨어 예측 도구를 사용하라
- 여러 가지 예측 기법을 사용하고, 결과를 비교하라
- 프로젝트를 진행하면서 예측 기법을 바꿔라
예측값 표현 방식
- 음양 부호: 비현실적인 기간에 몰려 있는 상황이라고 해도 예측값이 음양 부호를 붙여 일정 위험을 파악할 수 있다. 6+0.5M, 6-0.5M는 꽤 정확하고 일정 달성 가능성이 높지만 6+3M, 6-2M은 일정을 달성할 가능성이 적다.
- 범위: 음양 부호에서 음양 부분을 무시할 수 있기 때문에 대안으로 범위를 사용한다. 6+3M, 6-1M의 예측 범위는 5-9M으로 표현하는 식이다.
- 위험 계량화: 음양 부분이 의미하는 부분에 정보를 추가한다.
표 8-4 위험 표시 예측값 예제
| 예측값: 6개월, +3개월 | -2개월 |
|---|---|
| +1개월 - 그래픽 형식지정 하부시스템 출시 지연 | -1개월 - 예상보다 빠른 새 개발자 고용 |
| +1개월 - 기대 이하 성능을 보이는 새 개발 도구 | -1개월 - 기대 이상 성능을 보이는 새 개발 도구 |
| +0.5개월 - 병가 | |
| +0.5개월 - 크기 과소 예측 |
예측값을 통해 고객은 위험 대처 계획과 일정 감소가 가능한 항목을 활용하는 방법을 질문할 수 있다.
이런 질문에 대답할 준비를 해야 한다.
경우: 위험 계량화 예측값을 변형한 방법이 경우 기반 예측값이다. 최선, 최악, 계획, 현재로 표현한다.
베리 뵘은 계획한 경우나 가능한 예측값은 최선으로 기우는데, 실제는 최악의 경우 쪽으로 기운다고 지적한다(Boehm 1981).
경우 예측값을 작성하고 검토할 때는 이 부분을 명심해야 한다.
대략적인 날짜와 기간: 예측값은 개략적이라 1997년 7월 19일이나 520주-인원과 같은 숫자로 오해를 불러일으키지 말고 3Q97이나 10년-인원과 같이 대략적인 숫자를 사용한다.
확신 정도: 예측 일정을 맞출 가능성은 얼마에요? 고 질문한다면 표 8-6과 같은 예측값으로 답할 수 있다.
**표 8-6 확신 정도 예측값 예제
| 출시 날짜 | 일정에 맞게 또는 일정보다 빨리 출시할 확률 |
|---|---|
| 4월 1일 | 5% |
| 5월 1일 | 50% |
| 6월 1일 | 90% |
8.4 노력 예측
일정 예측을 하는 데 반드시 필요한 값은 아니지만, 프로젝트에 투입할 인원 수를 파악하는 데 필요하다.
다음은 크기 예측값을 노력 예측값으로 환산하는 방법이다.
- 크기 -> 노력으로 계산해주는 예측 소프트웨어 사용
- 코드 줄수로 표시한 크기 예측값은 표 8-8, 표 8-10을 이용해 노력 예측값으로 환산
- 유사한 크기 프로젝트에 들어간 노력을 판단
- 베리 뵘의 COCOMO 모델(Boehm 1981)이나 푸트남과 마이어의 생명주기 모델(Putnam and Myers 1992)과 같은 알고리즘을 사용하여 코드 줄 수 예측값을 노력 예측값으로 변환
8.5 일정 예측
공식 8-1을 이용해서 노력 예측값에서 대략적인 일정 근사치를 계산해낼 수 있다.
>> [공식 8-1] 소프트웨어 일정 공식
일정(개월) = 3.0 * Pow(월-인원, 1/3)
65월-인원이라고 예측했다면 공식 8-1을 통해 약 12개월이라는 일정을 얻을 수 있다.
그러면 65월-인원에서 12개월을 나누면 5-6명 정도의 인력 투입이 최적 팀 크기라는 걸 알 수 있다.
다른 소프트웨어 예측 주제와 달리 이 주제에 한정해서는 연구결과가 놀라울 정도로 비슷하다(Boehm 1981).
큰 프로젝트는 오래 걸리는게 당연할 수 있지만 팀 크기도 크기 때문에 그렇다.
큰 팀을 유지하는 데 발생하는 비효율성으로 인해 일정보다 노력이 더 빨리 늘어난다.
팀 크기를 일정하게 유지한다면 일정 범위는 노력 범위만큼이나 변화량이 커질 것이다.
일정 예측값은 그 값이 불확실하기에 오류 여분을 덧붙이게 된다는 문제점이 있다.
여분을 충분히 두는 경우도 있지만 그렇게 하지 못하는 경우도 있다.
공식 8-1과 주기적인 개선 방법을 사용하면 여분을 둘 필요가 없어진다.
약속 기반 일정
개발자 예측값에는 20~30% 정도 낙천성 요인이 있다고 밝혀졌다(van Genuchten 1991).
약속 기반 문화는 이런 낙천성을 장려하며 정상성 정검(sanity check)을 요구하지 않는다.
그 결과로 예측값에는 큰 오류가 생긴다.
약속 기반 계획 수립은 일정 단축에 도움을 주지 못한다.
팀이 성공을 차근차근 쌓아갈 수 있으려면, 약속은 반드시 현실적이고 달성가능해야 한다.
약속 기반이든 아니든 바람직한 일정은 단 한가지, 정확한 일정이다.
존스의 일차 예측 기법
기능 점수 총합에 표 8-7에서 선택한 적절한 지수를 붙여 일차 예측 기법이라는 일정을 계산할 수 있다.
표 8-7 기능-점에서 일정을 계산하는 지수
| 소프트웨어 종류 | 분야 최고 | 평균 | 분야 최하 |
|---|---|---|---|
| 시스템 | 0.43 | 0.45 | 0.48 |
| 비즈니스 | 0.41 | 0.43 | 0.46 |
| 기성품 | 0.39 | 0.42 | 0.45 |
출처: Determining Software Schedules(Jones 1995c)
프로젝트 기능-점수 합을 350으로 예측한다면, 지수 0.42를 적용해( Pow(350, 0.42) ) 12개월이라는 일정 근사치를 얻을 수 있다.
분야 최고 수준의 소프트웨어 화사라면 지수를 0.39로 적용해 10개월이라는 값을 얻을 수 있다.
다른 섬세한 예측 기법 보다는 안좋겠지만 근사치 일정을 얻을 수 있는 점에서 봤을 때는 근거 없는 추측 보다는 훨씬 낫다.
존스의 일차 예측 기법은 기능 집합이나 일정 기대치를 조정할 필요가 있는지를 초기에 파악하는 데 유용하다.
8.6 근사치 일정 예측
사람들이 궁금해 하는 내용은 특정 크기의 프로그램이 얼마나 걸리는지에 대한 근사치 예측값이다.
이는 표 8-8, 8-10을 통해 제시하는 내용이다.
표 내용의 정확도는 과거 회사 내 프로젝트 자료 보다 정확하지는 않겠지만
그런 기록이 없다면 짐작해서 하는 것 보다는 정확할 것이다.
표 8-8 최단 일정
| 시스템 크기 (코드 줄 수 ) | 시스템 제품 일정(M) | 시스템 제품 노력 (M/M) | 비즈니스 제품 일정(M) | 비즈니스 제품 노력 (M/M) | 기성품 제품 일정 (M) | 기성품 제품 노력 (M/M) |
|---|---|---|---|---|---|---|
| 10000 | 6 | 25 | 3.5 | 5 | 4.2 | 8 |
| 15000 | 7 | 40 | 4.1 | 8 | 4.9 | 13 |
| 20000 | 8 | 57 | 4.6 | 11 | 5.6 | 19 |
| 25000 | 9 | 74 | 5.1 | 15 | 6 | 24 |
| 30000 | 9 | 110 | 5.5 | 22 | 7 | 37 |
| ... | ... | ... | ... | ... | ... | ... |
| 200000 | 20 | 1250 | 11 | 250 | 14 | 440 |
| 250000 | 22 | 1650 | 13 | 330 | 15 | 580 |
| 300000 | 24 | 2100 | 14 | 420 | 16 | 725 |
| 400000 | 27 | 2900 | 15 | 590 | 19 | 1000 |
| 500000 | 30 | 3900 | 17 | 780 | 20 | 1400 |
출처:
Software Engineering Economics(Boehm 1981)
An Empirical Validation of Software Cost Estimation Models(Kemerer 1987)
Applied Software Measurement(Jones 1991)
Measures for Excellence (Putnam and Myers 1992)
Assessment and Control of Software Risks(Jones 1994)
표 8-10 명목 일정
| 시스템 크기 (코드 줄 수 ) | 시스템 제품 일정(M) | 시스템 제품 노력 (M/M) | 비즈니스 제품 일정(M) | 비즈니스 제품 노력 (M/M) | 기성품 제품 일정 (M) | 기성품 제품 노력 (M/M) |
|---|---|---|---|---|---|---|
| 10000 | 10 | 48 | 6 | 9 | 7 | 15 |
| 15000 | 12 | 76 | 7 | 15 | 8 | 24 |
| 20000 | 14 | 110 | 8 | 21 | 9 | 34 |
| 25000 | 15 | 140 | 9 | 27 | 10 | 44 |
| 30000 | 16 | 185 | 9 | 37 | 11 | 59 |
| ... | ... | ... | ... | ... | ... | ... |
| 200000 | 35 | 1900 | 20 | 370 | 24 | 610 |
| 250000 | 38 | 2400 | 22 | 480 | 26 | 800 |
| 300000 | 41 | 3000 | 24 | 600 | 29 | 1000 |
| 400000 | 47 | 4200 | 27 | 840 | 32 | 1400 |
| 500000 | 51 | 5500 | 29 | 1100 | 35 | 1800 |
출처: 표 8-8과 동일
배경
표 8-8, 표 8-10은 세 종류 프로젝트를 대상으로 한다.
- 시스템 소프트웨어
- 비즈니스 소프트웨어
- 기성품 소프트웨어
시스템 소프트웨어에서 펌웨어, 실시간 임베디드, 항공 전자 공학 프로세스 관리는 제외한다. 왜냐하면 생산성이 훨씬 낮기 때문이다.
프로젝트 범주가 100% 맞지 않는다면 비율로 조합해도 된다.
60%가 비즈니스 제품이고 40%가 기성품이면 각 비율대로 계산해서 더해 제품 일정을 산출하면 된다.
일정
설계, 구현, 테스트 시간을 포함하지만 요구사항 명세 시간은 제외한다.
노력
Man/Month 단위로 표현한다. 개발팀은 품질보증부서와 관리자가 포함된다.
일정보다 조금 늦게 출시해도 괜찮다면 일정을 늘리고 팀 크기를 줄여서 전체 프로젝트 비용을 낮출 수 있다.
팀이 작을 수록 관리와 의사소통 부하가 줄어들기 때문에 좀더 생산적으로 일할 수 있다. (DeMarco 1982).
일정을 늘렸는데 팀 크기를 유지한다면 절감 효과는 얻지 못한다.
파킨슨의 법칙처럼 늘어난 시간만큼 업무량도 늘어나게 되기 때문이다.
시스템 크기
표에서 말하는 시스템 크기는 공백과 주석이 없는 코드 라인 수이다.
소규모 프로젝트
표에서 나온 최소 코드 라인 수인 10000 이하의 프로젝트는 고려하지 않는다.
이런 프로젝트는 한 사람이 해도 되며 그 사람의 능력에 따라 노력과 일정 예측값이 달라진다.
코드 줄 수
최근에는 코드 줄 수 측정법은 비판을 많이 받아서 대안으로 기능 점수를 권하는 사람들도 있다.
코드 줄 수 측정법은 심각한 문제가 있기는 하지만 기능 점수 보다는 널리 알려진 방법이고
코드 줄 수와 기능 점수 사이에 큰 상관관계가 존재한다고 보고 있다. (Albrecht and Gaffiney 1982, Kemerer 1987)
기능 점수는 사용하는 언어를 모르기 때문에 이를 노력값으로 변환하기 어렵다.
예로 어셈블리에서 50 기능 점수는 C++에서 50 기능 점수보다 구현하는데 몇 배 더 오래 걸리지만 1000 코드 줄 수는 어떤 언어든 비슷한 시간이 걸릴 것이기 때문이다.
예측값 정확도
표가 단순하다고 비판할 수 있지만, 이 단순함이 목적이긴 하다.
분야, 조직, 그룹마다 과거 기록을 통해 정확한 예측값을 얻을 수 있지만 표에 보이는 단순함은 대게 복잡한 예측 모델만큼 비교적 정확한 예측값을 보여준다.
크리스 케머러는 프로젝트 15개를 대상으로 예측 모델 5개를 적용해 노력 예측값을 비교했다.
가장 정확한 예측 모델에서 얻은 노력값이 실제 노력에 비해 평균 100% 오차 범위에 들 뿐이라는 걸 발견했다 (Kemerer 1987).
이 연구가 옳다는 가정하에 가장 정확한 예측 도구보다 표에서 얻는 예측값이 평균 오류가 더 작을 수 있다.
이런 점을 감안하면 표에서 소개한 예측법은 짐작 보다는 나은 근사치 예측값을 제공한다는 점에서 원래 목적을 충분히 달성한다.
최단 일정
표 8-8에 있는 일정은 정상성 점검용으로 사용해야 한다.
최단 일정이기 때문에 이상적인 소프트웨어 개발 조직에서 달성할 수 있는 일정이고 대다수 회사는 달성하지 못할 값이다.
가정
인력:
능력면에서 상위 10%에 드는 인력으로 팀을 구성한다고 가정한다.
분석가 개발자 모두 10% 안에 들어야 한다.
모두 프로그래밍 언어와 개발 환경에서 수년 간 경험이 있어야 하면 응용 프로그래밍 분야에 풍부한 지식이 있어야 한다.
의욕도 넘치고 제품에 대해 비전 공유도 하면서 서로 화합하고, 열심히 일하며 중간에 이직이 없어야 한다.
관리:
프로젝트 관리도 이상적이어야 하며 개발자는 기술적인 업무에만 시간을 쓸 수 있다고 가정한다.
모든 인력이 프로젝트 시작 부터 끝까지 업무를 수행한다.
도구 지원:
최신 소프트웨어 도구 사용이 가능하고 컴퓨터 사용에도 제한이 없다고 가정한다.
프로젝트 팀은 한 곳에 있고 모든 업무 환경 역시 이상적이다.
방법론:
시간 효율이 가장 큰 개발법과 도구를 사용한다.
요구사항은 설계 시점에 모두 파악 가능하고, 이후 요구사항 변화가 없다고 가정한다.
압축:
이런 가정에서 최대한 압축한 일정이며 이 이상 압축은 불가능하다.
두 가지 현실
- 최단 일정은 존재하지만 그 이상 달성할 수는 없다
- 일정을 명목 일정보다 짧게 잡으면 비용은 급속하게 증가한다
개발자수나 초과 근무량을 늘려서 일정을 줄일 수 있는데 이를 일정 압축이라고 부른다.
하지만 개발 기간을 명목 일정보다 줄이려면 엄청난 비용이 든다.
비용과 일정 압축을 예측하는 많은 방법이 있는데, 그 중 찰스 사이몬이 제안한 방법이 일반적인 목적에는 충분하다(Symons 1991).
초기 노력과 초기 일정의 예측해 공식 8-2를 이용해 두 예측값과 원하는 일정에서 일정 압축률을 계산한다.
공식 8-2 일정 압축률
일정 압축률 = 원하는 일정 / 초기 일정
초기 일정이 12개월인데 10개월 안에 압축하고 싶으면 압축률은 0.83이 나온다.
초기 노력 예측값이 78 M/M로 가정했다면 0.83을 공식 8-3에 대입한다.
공식 8-3 압축한 일정 노력
압축한 일정 노력 = 초기 노력 / 일정 압축률
그러면 압축한 일정 노력은 약 94 M/M가 나오는데 초기 노력 예측값보다 17%이고 이를 단축하기 위해서는 노력을 약 20% 증가시켜야 한다는 의미가 된다.
연구 대부분은 0.75나 0.8 이하의 낮은 일정 압축률은 얻기 불가능하다는 결과를 도출했다. (Boehm 1981, Putnam and Myers 1992, Jones 1994)
이 의미는 인력을 추가하고 추가 근무량을 늘려서 단축할 수 있는 일정에는 반드시 한계치가 존재하며 절대 25%를 넘지 못한다는 뜻이다.
0.75 이하의 압축률이라면 일정 압축 보다는 제품 크기를 줄이거나 일정을 늘리는 방법을 써야 한다.
반대로 팀 크기를 불균등하게 감소시키면 프로젝트 비용을 줄일 수 있는 용도로 사용할 수 있다.
효율적인 일정
최단 일정은 매우 이상적인 가정이며 달성하기 불가능한 수준이다.
그 보다는 효율적인 일정이 훨씬 현실적인 대안일 것이다.
가정
문제는 없다는 가정을 전제로 하지만 최단 일정의 이상적인 경우까지 가정하지 않는다.
다른 점은 다음과 같다.
- 팀원 능력은 상위 25%
- 이직률은 6% 미만
- 팀 단결력이 크지 않을 수는 있지만 심각한 마찰 없음
- 레일리 스타일의 인력 준비 패턴으로 효율적인 인력 충원 패턴 사용
*레일리 스타일은 레일리 분포를 따르며, 실제로 필요한 노동력을 산출하는데 훌륭한 근사치를 산출하는 방법이다.
최단 일정과 효율적인 일정 사이 관계
효율적인 일정을 최대한(25%) 압축하면 최단 일정과 비슷한 값을 얻을 수 있다.
하지만 가정이 덜 낙관적이기 때문에 비용은 더 클 것이다.
최단 일정은 단순히 달성하기가 불가능하지만, 효율적인 일정은 거의 모든 상황에 문제만 없다면 달성할 가능성이 있다.
명목 일정
표 8-10의 명목일정을 참고한다.
평균적인 프로젝트에서 사용하려는 목적에 부합한다.
프로젝트 대다수는 평균적이므로 최단 일정, 효율적인 일정 보다는 명목 일정을 사용하는게 맞다.
가정
다른 일정 보다 덜 낙관적인 가정을 전제로 한다.
- 팀원 능력 상위 50%
- 프로그래밍 언어와 개발환경에 익숙하지만 능숙할 필요는 없음
- 응용 프로그래밍 분야에 경험은 있지만 역시 능죽할 필요는 없음
- 팀 단합력이 크지 않을 수 있으며 마찰도 있음
- 이직률 10% ~ 12%
- 쾌속 개발법을 사용할 수 있지만 효율적으로 활용하지 않을 수 있음
- 위험 관리에 적극적이지 않음
- 개발하는 데 좋은 사무실 공간이 아닐 수도 있음
이 일정은 최악의 경우는 아니다. 많은 부분 제대로 수행한다는 가정하에 평균적인 프로젝트에서 명목 일정 달성 가능성은 50% 라고 보면 된다.
효율적인 개발이 필요한 이유
효율적인 일정에 비해 오래 걸리고 비용도 훨씬 크다.
그래서 명목 일정을 압축해 효율적인 일정에 근사치에 도달시켜서 비용을 줄이는 방법을 선택한다.
근사치 일정값으로 가장 먼저 할 일
가장 최근 프로젝트 기록으로 효율적으로 했는지 명목 일정으로 했는지 등의 파악을 한다.
표에 있는 숫자가 했던 프로젝트와 차이가 있다면 다음 프로젝트 예측에 사용하기 전에 조정한다.
8.7 예측값 다듬기
루이즈 라라네이라는 연구를 통해 소프트웨어 예측값의 정확한 정도는 소프트웨어 정의의 구체적인 정도에 달려 있다고 주장한다(Laranjeira 1990).
정의가 구체적이면 예측값이 정확한 건 당연한 말이며, 구체적으로 정의할수록 불확실성이 줄어드는 것도 타당하다.
이 연구는 소프트웨어 정의를 구체화하기 위해 하는 일은 프로젝트 업무 그 자체라는 걸 말해준다.
요구사항 명세, 제품 설계, 상세 설계와 같은 활동이다.
프로젝트를 진행하면서 예측값은 개선할 수 있다.
보통 개발자가 예측값 하나를 내 놓으면 그 값에 책임 추궁을 당한다.
예로 팀 수석이 프로젝트 진행시에 열거한 예측값이 표 8-11과 같다고 하자.
표 8-11 구체적인 예측값 기록 예제
| 프로젝트 시점 | 예측값(M/M) |
|---|---|
| 초기 제품 개념 | 100 |
| 제품 개념 승인 | 100 |
| 요구사항 명세 | 135 |
| 제품 설계 | 145 |
| 상세 설계 | 160 |
| 최종 | 170 |
예측값이 초기에는 100 M/M 였다가 요구사항 명세 단계에서 135 M/M 라고 하면 고객은 예산을 초과했거나 일정보다 늦어진다고 생각한다.
그리고 그 이후에는 프로젝트가 문제가 있다고 여길 것이다.
하지만 이건 비현실적이다.
처음에 100 M/M 로 예측한 시점에서는 프로젝트를 모두 파악하지 못했기 때문에 의미있는 값이라고 보기 어렵기 때문이다.
그리고 최종 170 M/M 로 예측한 것도 팀 수석이 뛰어나서 효율적인 일정의 노력값일 수도 있다.
다른 예로 예측값 범위로 제시하는 경우가 있다.
표 8-12를 보면 예측값 범위는 최대 값 기준으로 점점 줄어드는 양상을 보인다.
표 8-12 범위-예측값 기록 예제
| 프로젝트 시점 | 예측값(M/M) |
|---|---|
| 초기 제품 개념 | 25-400 |
| 제품 개념 승인 | 50-200 |
| 요구사항 명세 | 90-200 |
| 제품 설계 | 120-180 |
| 상세 설계 | 145-180 |
| 최종 | 170 |
예측값 범위이므로 부정확해 보이고, 대부분 고객은 범위를 좁히라고 요구할 것이다.
하지만 이 이상 정밀한 값은 불가능하고 가능하다고 하면 무지하거나 거짓말을 한 것이다.
부정확성이 나쁜 예측값을 의미하지는 않는다.
소프트웨어 개발에서는 자연스러운 것이며, 이걸 받아들이지 못하는 태도가 나쁜 예측값을 만드는 것이다.
재조정
첫 중간 목표를 4주에 달성하기로 했는데 실제 5주가 걸리면 보통 나중에 1주일을 따라잡을 수 있을 거라 생각한다.
1991년 연구에서 300개의 프로젝트를 대상으로 조사한 결과 나중에 따라잡는 프로젝트는 거의 없었으며 상당수 프로젝트는 오히려 더 늦어진다고 밝혀졌다(van Genuchten 1991).
중간 목표를 놓친 후에 올바른 대응책은 지연 비율 25%를 전체 일정에 곱하는 방법을 써야 한다.
이 단계에서 일정을 늘일 준비가 안 되었다면, 결정을 미룬 후 다음 중간목표 달성은 어떤지 살펴보고 자료를 수집한다.
중간 목표도 25% 늦게 달성할거라 예측된다면 그 시점에 재조정은 어려워진다.
처음 기회가 있을 때 정정한 경우보다 효과가 적게 된다.
일정, 제품, 비용 삼각형에서 제품이나 비용을 조정할 수도 있다.
하지만 조정 없이 그대로 유지하면서 프로젝트를 개선하는 건 불가능하다.
일정 지연이 주로 수반하는 문제는 자신감 저하이다.
예측값을 지키겠다고 약속한다면 지연은 실패나 실패할 위험을 의미한다.
계획한 일정을 맞추지 못하고 실제 완료 날짜를 알 근거가 없다.
하지만 프로젝트의 일정 예측이 어떻게 정확해져 가는지를 미리 설명하고 예측값 범위를 제시한다면, 일정 지연 횟수를 줄일 수 있다.
범위 안에 있다면 안전하기 때문이다. 그 범위를 벗어나야 지연이라고 얘기할 수 있기에 지연은 드문 일이 된다.
읽을거리
일반적인 예측
- Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, N.J.: Prentice Hall, 1981
- DeMarco, Tom, Controlling Software Projects. New York: Yourdon Press, 1982
- Putnam, Lawrence H., and Ware Myers. Measures for Excellence: Reliable Software On Time, Within Budget. Englewood Cliffs, N.J.: Yourdon Press, 1992
- Jones, Capers, Assesment and Control of Software Risks. Englewood Cliffs, N.J.: Yourdon Press, 1994.
- Gilb, Tom. Principles of Software Engineering Management. Workingham England: Addison-Wesley, 1988.
기능-점 분석
- Dreger, Brian. Function Point Analysis, Englewood CLiffs, N.J.: Prentice Hall, 1989.
- Jones, Capers. Applied Software MEasurement: Assuring Productivity and Quality. New York: McGraw-Hill, 1991.
- Symons, Charles. Software Sizing and Estimating: Mk 2 FPA (Function Point Analysis). Chichester, England: John Wiley & Sons, 1991.