정보시스템 구축관리 2강. 비용 산정과 일정 관리
늦어지는 프로젝트에 사람을 더 투입하면 더 늦어집니다. 브룩스가 남긴 이 한 문장이 소프트웨어 공학에서 가장 자주 인용되는 경고입니다.
풀고 시작
사람과 달로 크기를 잽니다
프로젝트를 시작할 때 가장 먼저 답해야 할 질문은 얼마나 걸리고 얼마나 드는가입니다. 그런데 소프트웨어는 눈에 보이지 않아서 크기를 재기가 어렵죠. 그래서 여러 기법이 나왔습니다.
산정 방식은 크게 둘로 나뉩니다. 하향식은 경험 많은 전문가가 전체를 보고 추정하는 방식으로, 한 사람이 판단하는 전문가 감정 기법과 여러 전문가의 의견을 조정자가 익명으로 모아 수렴시키는 델파이 기법이 있습니다. 델파이가 나온 이유는 회의실에서 목소리 큰 사람의 의견에 나머지가 끌려가는 현상을 막기 위해서였습니다.
상향식은 작은 단위를 세어 합치는 방식입니다. LOC 기법은 코드 라인 수를 낙관치와 기대치와 비관치로 추정한 뒤 가중 평균을 냅니다. 이 값으로 노력과 개발 기간과 인원을 차례로 계산하죠. 개발 단계별 인월수 기법은 LOC를 각 생명주기 단계에 배분해 더 정밀하게 계산합니다.
수학 모형으로 넘어갑니다
경험적 추정을 수식으로 다듬은 것이 수학적 산정 기법입니다. 대표는 보엠이 만든 COCOMO입니다. 예상 코드 라인 수를 입력하면 노력과 기간이 나오는데, 프로젝트 유형에 따라 계수가 달라집니다.
| 유형 | 규모 기준 | 성격 |
|---|---|---|
| 조직형 | 5만 라인 이하 | 사무 처리나 소규모 업무용 |
| 반분리형 | 30만 라인 이하 | 컴파일러나 운영체제 등 중간 규모 |
| 내장형 | 30만 라인 초과 | 실시간 제어나 초대형 시스템 |
규모 경계인 5만과 30만이 그대로 문제가 됩니다. 그리고 이름이 헷갈리기 쉬운데, 조직형은 organic 즉 유기적이라는 뜻이고 내장형은 embedded 즉 하드웨어에 박혀 있다는 뜻입니다.
푸트남 모형은 개발 기간에 따른 인력 투입을 레일리 곡선으로 가정합니다. 처음에는 적게, 중반에 최대로, 후반에 다시 줄어드는 그 모양이죠. 이 모형을 자동화한 도구가 SLIM입니다.
기능 점수(FP) 모형은 접근이 다릅니다. 코드가 아니라 사용자가 보는 기능을 셉니다. 자료 입력과 정보 출력과 조회, 내부 파일과 외부 인터페이스 다섯 가지를 세고 복잡도로 가중치를 매기죠. 언어에 무관하게 산정할 수 있다는 점이 LOC 대비 장점이고, 그래서 요즘 공공 사업에서 더 널리 쓰입니다. 이를 자동화한 도구가 ESTIMACS입니다.
일정은 순서와 여유의 문제입니다
비용을 정했으면 언제 무엇을 할지 정해야 합니다. 먼저 할 일을 잘게 나눈 작업 분해 구조(WBS)를 만들고, 작업 사이의 선후 관계를 따집니다.
PERT는 작업 시간을 낙관치와 기대치와 비관치로 추정해 불확실성을 반영합니다. 처음 해 보는 프로젝트에 어울리죠. CPM은 작업 사이의 의존 관계를 네트워크로 그려 가장 오래 걸리는 경로, 즉 임계 경로를 찾습니다. 임계 경로의 길이가 곧 프로젝트의 최소 기간이며, 이 경로 위의 작업은 하루만 늦어도 전체가 늦어집니다. 여유 시간이 0이라는 뜻이죠.
간트 차트는 작업을 막대로 그려 기간과 진행 상황을 한눈에 보여 줍니다. 직관적이지만 작업 사이의 의존 관계는 드러나지 않아서, CPM과 함께 쓰는 것이 보통입니다.
여기서 브룩스의 경고가 다시 나옵니다. 지연된 프로젝트에 인력을 더 넣으면 교육과 의사소통 비용이 늘어 오히려 더 늦어진다는 것이죠. 인원이 늘면 소통 경로는 제곱에 가깝게 늘어나니까요. 다음 강에서는 이렇게 관리되는 시스템이 어떤 기술 위에 세워지는지, 신기술 동향을 봅니다.
인출 문제
생각해볼 질문 (정답 없음)
모든 산정 기법은 과거의 데이터로 미래를 추정합니다. 한 번도 해 본 적 없는 일에 대해서는 무엇을 근거로 기간을 약속해야 할까요.
이전: 1강 개발 방법론과 프로세스 개선 · 다음: 3강 신기술 동향과 시스템 구축