프로그램, 제품, 시스템, 시스템 제품

코드의 줄 수와 팀 크기만이 프로젝트의 크기에 영향을 미치는 것은 아니다. 최종적인 소프트웨어의 품질과 복잡성이 보다 미묘한 영향을 미친다. 원래의 기가트론은 작성하고 디버깅하는 데 한 달이 걸렸을 뿐이었다. 그 프로그램은 한 사람에 의해서 작성되고 테스트되고 문서화된 단일 프로그램이었다. 만약 2,500줄짜리 기가트론이 한 달 걸렸다면, 왜 25,000줄로 확장된 기가트론은 스무 달이 걸렸을까?

가장 간단한 소프트웨어의 종류는 그 프로그램을 작성한 한 사람 또는 몇 사람에 의해서 사용되는 단일 "프로그램"이다.

보다 정교한 프로그램의 종류는 원래의 개발자가 아닌 다른 사람들에게 의해서 사용될 목적으로 만들어진 프로그램, 즉 소프트웨어 "제품"이다. 소프트웨어 제품은 제품이 작성된 것과는 다른 환경에서 사용된다. 따라서 제품이 릴리즈되기 전에 광범위하게 테스트되고 문서화되며, 다른 사람에 의해서 유지 보수될 수 있다. 소프트웨어 제품은 소프트웨어 프로그램보다 개발하는데 약 3배의 비용이 든다.

함께 작동하는 프로그램 그룹을 개발할 때에는 또 다른 정교함이 요구된다. 그런 그룹을 소프트웨어 "시스템"이라고 부른다. 시스템 개발은 통합되는 부분들 사이의 인터페이스를 개발하는데에 따른 복잡성과 주의가 요구되기 때문에 간단한 프로그램을 개발하는 것보다 좀 더 복잡하다. 전체적으로, 시스템도 간단한 프로그램을 개발하는 것보다 3배 정도의 비용이 든다.

"시스템 제품"이 개발될 때에는, 제품과 시스템의 여러 부분들을 다듬어야 한다. 따라서 시스템 제품은 간단한 프로그램보다 9배 정도의 비용이 든다.(Brooks 1995, Shull 외. 2002)

프로그램과 제품, 시스템, 시스템 제품 간의 매끄러움과 복잡성 간의 차이를 제대로 평가하지 못하는 것이 견적 오류의 일반적인 원인이다. 예를 들어, 프로그램을 작성해 본 경험이 있는 프로그래머가 자신의 경험을 토대로 시스템 제품을 작성하기 위한 일정을 추정하게 되면 거의 10배 정도 낮게 추정할 수 있다. 만약 2K 프로그램을 개발하기 위해서 걸리는 시간을 추정하기 위하여 2K줄짜리 코드를 작성했던 경험을 사용한다면, 여러분이 예상한 시간은 실제로 프로그램을 개발하면서 들어가는 모든 활동들을 수행하기 위해서 필요한 전체 시간의 65%일 뿐이다.

2K줄짜리 코드를 작성하는 것은 2K줄을 포함하고 있는 전체적인 프로그램을 작성하는 것 만큼 오랜 시간이 걸리지 않는다. 만약 구현이 아닌 활동 등에 걸리는 시간을 고려하지 않는다면, 구현은 여러분이 예측한 것보다 50% 정도의 시간이 더 걸릴 것이다.

크기가 커질수록, 구현은 프로젝트에 들어가는 전체적인 노력에서 보다 작은 부분이 된다. 만약 여러분의 견적을 구현에서의 경험에만 기초한다면, 견적 오류는 증가할 것이다. 만약 32K 프로그램을 개발하는 데 걸리는 시간을 추정하기 위해서 2K 구현 경험을 사용했다면, 여러분의 견적은 단지 필요한 전체 시간의 50%가 되고, 개발은 추정한 것보다 100%의 시간이 더 걸릴 것이다.

여기서의 견적 오류는 전적으로 더 큰 프로그램을 개발하는 데 있어서 크기가 미치는 영향을 이해하지 못했기 때문일 것이다. 또한, 만약 단일 프로그램이 아닌 제품에 요구되는 추가적인 섬세함 정도를 고려하지 못한다면, 오류는 3배 이상으로 증가할 수 있다.

FROM. CODE COMPLETE 2/E, Chapter27. 프로그램의 크기가 구현에 미치는 영향.

일정.
아무래도 가장 중요한 듯 싶다.
나는 항상 일정에 쫓기 업무는 싫어서
항상 내 일정을 내 스스로 잘 조정할려고 노력하는 타입이다.

항상 퇴근 시간이 되면 그 전에 했던 일들을 정리하고
내일 그리고 이번주에 해야할 일 전체적인 진행상황들을
달력을 보면서 머릿속으로 정리한다.