•
소프트웨어에서 규모를 키우는 것은 단순히 각 부분을 좀 더 크게 만드는 식의 단순한 문제가 아니다.
•
큰 규모의 프로젝트를 개발할 수록 그 결함을 줄이기 위해 더 많은 노력을 필요로 함을 인지하고 있어야 한다.
1. 의사소통과 크기
•
프로젝트가 작다면 의사소통 경로는 보통 고객과 자신이 유일하다.
•
프로젝트에 참여하는 수가 증가할 수록 경로의 수도 증가한다. 그 수치는 증가하는 사람의 수만큼 추가되는 것이 아닌, 사람 수의 제곱에 비하여 증가한다.
•
두 사람이 참여하는 프로젝트는 경로가 하나 뿐이다. 다섯 사람이 참여하면 프로젝트는 10개의 경로를 갖는다.
◦
nCr이다.
•
의사소통 경로가 증가할수록 의사소통에 더 많은 시간을 보내게 되고 의사소통 실수가 발생할 확률도 높아진다. 크기가 큰 프로젝트는 의사소통을 능률적으로 진행하거나 현명한 방법으로 제한하는 기법이 필욯다ㅏ.
◦
전형적인 접근 방법으로는 의사소통을 문서로 기록하는 것이 있다.
2. 프로젝트 크기의 범위
•
프로젝트 크기를 계산하는 한 가지 방법은 프로젝트 팀의 크기를 고려하는 것이다.
3. 프로젝트의 크기가 오류에 미치는 영향
•
오류의 양과 종류는 모두 프로젝트의 크기에 영향을 받는다. 오류의 종류는 영향을 받지 않을 것 같지만 크기가 증가할수록 요구사항과 설계상 실수로 발생할 수 있다.
◦
작은 프로젝트에서는 구현 시 발생하는 오류가 전체 오류의 75%를 차지한다.
◦
큰 프로젝트에서는 구현 시 발생하는 오류가 전체 오류의 약 50%를 차지하고 요구사항과 아키텍처 오류가 나머지를 차지한다.
•
큰 프로젝트에서는 요구사항 개발과 아키텍처 설계가 더 많이 요구되므로 오류가 발생할 가능성이 더 높다.
◦
그럼에도 때때로 규모가 아주 큰 몇몇 프로젝트에서는 여전히 구현 오류의 비율이 높다.
•
결함의 종류가 크기에 따라서 변할 때 결함의 수도 변한다. 당연히 프로젝트의 크기가 두 배인 프로젝트는 오류의 수도 두 배일 것이라고 예상할 것이다.
◦
매우 큰 프로젝트는 작은 프로젝트보다 1,000줄당 오류의 수가 4배나 더 많았다.
•
큰 프로젝트에서는 작은 프로젝트에서와 같은 오류 비율을 달성하기 위해 더 많은 작업을 해야할 것이다.
4. 프로젝트의 크기가 생산성에 미치는 영향
•
팀 크기가 생산성에 영향을 미치기 시작하는 프로젝트 크기는 얼마일까?
•
여기서 설명하는 일반적인 경향은 작은 프로젝트에서의 생산성이 큰 프로젝트보다 2~3배 정도 더 높을 수 있으며 생산성은 가장 작은 프로젝트와 가장 큰 프로젝트 사이에서 5~10배 정도 차이가 날 수 있다.
5. 프로젝트의 크기가 개발 활동에 미치는 영향
활동 비율과 크기
•
간략히 말하자면 프로젝트의 크기가 증가함에 따라 구현이 차지하는 비중은 작아진다.
◦
작은 프로젝트에서는 구현이 개발의 65를 차지하는 가장 두드러진 활동이다.
◦
중간 크기의 프로젝트에서도 여전히 구현이 중요하긴 하지만 전체 개발 시간에선 대략 50% 정도의 비율로 차지하는 비율이 낮아진다.
◦
매우 큰 프로젝트에서는 아키텍처, 통합, 시스템 테스트가 더 많은 시간을 차지하고 구현이 차지하는 비율은 줄어든다.
•
크기에 따라 구현 활동이 영향을 받으므로 활동의 비율도 달라진다.
◦
배리 보엠과 리차드 터너는 아키텍처에 전체 프로젝트 비용의 5% 정도를 투자한다면 1만 줄짜리 프로젝트에서 가장 비용이 적게 든다는 사실을 발견했다.
◦
하지만 10만 줄 프로젝트에서는 아키텍처에 전체 프로젝트 비용의 15%에서 20% 정도 투자하는 것이 가장 좋은 결과를 냈다.
•
프로젝트의 크기와 상관없이 엄격한 코드 컨벤션, 다른 개발자에 의한 설계 및 코드 정밀 검토, 좋은 도구 지원, 고급 언어 사용과 같은 몇 가지 기법은 언제나 유용하다.
프로그램, 제품, 시스템, 시스템 제품
•
프로그램은 작성한 사람이나 비공식적으로 몇몇 사람만 사용하는 단일 프로그램이며 가장 간단한 종류의 소프트웨어다.
•
제품은 정교한 프로그램의 종류로 프로그램 개발자가 아닌 다른 사람들이 사용할 목적으로 만든 프로그램인 소프트웨어다.
•
소프트웨어 시스템은 함께 작동하는 프로그램 그룹을 개발해야할 정도로 정교하다.
•
시스템 제품의 경우, 제품과 시스템 곳곳을 다듬어야 한다. 시스템 제품을 개발할 때는 제품과 시스템을 모두 다듬어야 한다. 시스템 제품은 간단한 프로그램보다 9배 정도 비용이 더 든다.
•
제품과 프로그램은 엄연히 다르다. 시스템 제품은 간단한 프로그램보다 비용이 9배 정도 더 든다.
방법론과 크기
•
프로젝트의 규모에 상관없이 모두 방법론을 사용한다. 작은 프로젝트에서는 방법론이 격식이 없고 본능적이다. 큰 프로젝트의 방법론은 엄격하고 주의깊게 계획한다.
•
형식적인 접근 방법이 항상 즐거울수만은 없다. 그러한 접근 방법이 잘못 적용되면 시간을 낭비하곤 많다. 하지만 큰 프로젝트라면 복잡성 때문에 방법론에 더 주의를 기울여야 한다.
•
방법론에서는 더 많이 한다고 해서 나을 것이 없다.
◦
배리 보엠과 리차드 터너는 포괄적인 방법론으로 시작해 그것을 줄여 작은 프로젝트에 적용하는 것보다는 방법론을 작게 시작해서 큰 프로젝트에 맞게 확장하는게 더 낫다고 충고한다.
◦
소프트웨어 전문가들은 가벼운, 무거운 기법들에 관해 얘기하지만 실무에서 가장 중요한 사항은 프로젝트의 구체적인 크기와 형식을 고려해 적합한 방법론을 찾는 것이다.
요점 정리
•
프로젝트의 크기가 증감하에 따라 의사소통이 뒷받침되어야 한다. 대부분의 방법론의 핵심은 의사소통 문제를 감소시키는 것이며 방법론은 의사소통을 쉽게 해주느냐 아니냐에 따라 살아남거나 사라진다.
•
다른 조건이 같다면 큰 프로젝트의 생산성이 작은 프로젝트의 생산성보다 낮으며 1,000줄 당 오류수도 큰 프로젝트가 더 많다.
•
작은 프로젝트에서 당연한 것으로 받아들이는 활동이 큰 프로젝트에서는 신중하게 도입을 검토해야 한다. 구현은 프로젝트의 크기가 증가함에 따라 전체 개발 활동에서 차지하는 비율이 줄어든다.
•
가벼운 방법론을 확장하는 쪽이 무거운 방법론을 축소하는 것보다 더 잘 작동하는 경향이 있다. 가장 효과적인 접근 방법은 올바른 접근 방법을 사용하는 것이다.
