스티브 맥코넬의 SPSG(Software Project Survival Guide)에 나오는
"생존 테스트" 이다.
소프트웨어 개발에 몸담고 계시는 분들은 한번씩 해보고
자신이 속한 프로젝트가 과연 살아남을 수 있을까 고민해보시는 것도 좋을 듯 하다.
1. Requirements
1.1. 프로젝트에 명확한 Vision 혹은 Mission 이 있는가?
1.2. 프로젝트 팀원 모두가 제시된 비전을 현실성있다고 생각하는가?
1.3. 고객이 그 프로젝트의 성공으로 얻게 될 비즈니스적인 이점과 그것에 대한 측정방법이 기술되어 있는 Business Case가 있는가?
1.4. 실제 시스템이 가지는 기능을 명확하게 보여줄 User Interface Prototype이 있는가?
1.5. Software Specification 은 상세하게 문서화되어 있는가?
1.6. 팀원들이 프로젝트 초기에 실제 사용자들과 미팅을 했는가? 또 실제 사용자들이 프로젝트에 지속적으로 참여하는가?
2. Planning
2.1. 소프트웨어 개발 계획이 문서화되어 있는가?
2.2. 작업 리스트에 인스톨러 개발, 이전 버전의 데이터 마이그레이션, 고객과의 회의 등 사소한 일까지 포함되어 있는가?
2.3. 일정과 예산 추정치를 최근에 공식적으로 업데이트했는가?
2.4. 아키텍처와 설계를 상세하게 문서화했는가?
2.5. 시스템 테스트, 코드 리뷰를 포함하는 상세한 품질 보증 계획이 문서화되어 있는가?
2.6. 각 단계별로 어떤 버전이 구현되고 납품되는지 상세히 설명한 단계별 납품 계획이 있는가?
2.7. 프로젝트 일정에 휴일, 휴가, 병가, 교육 등의 기간이 모두 포함되어 있는가? 또 인원 할당은 100퍼센트가 안되도록 버퍼가 잡혀있는가?
2.8. 일정을 포함한 모든 계획은 개발팀, 품질 보증팀 등의 모든 관련된 사람들의 승인을 받았는가?
3. Project Control
3.1. 권한이 있는 임원 한명이 프로젝트를 책임지는가? 그리고 그 임원은 프로젝트를 적극 후원하는가?
3.2. PM이 프로젝트에 몰두할 여건이 되어 있는가?
3.3. 프로젝트의 진척 여부를 파악하기 위한 상세한 마일스톤이 정의되어 있는가?
3.4. 프로젝트 이해 관계자들이 마일스톤의 달성 여부를 쉽게 파악할 수 있는가?
3.5. 팀원들이 무기명으로 상급자들에게 문제를 보고할 수 있고, 그 결과를 피드백 받을 수 있는가?
3.6. Software Specification의 변경을 통제하는 계획이 문서화되어 있는가?
3.7. 변경 요청 사항을 수용하거나 거부할 수 있는 권한을 가진 변경 통제 위원회(Change Control Board)가 구성되어 있는가?
3.8. 작업량, 예상 일정, 업무 분장, 계획 대비 진도 등의 현황을 모든 팀원들이 알 수 있는가?
3.9. 소스 코드의 버전 통제는 자동화되어 있는가?
3.10. 버그 트래킹, 소스 코드 통제, 프로젝트 관리 소프트웨어 등 프로젝트 수행 환경에 대한 기초적인 자동화 도구가 준비되어 있는가?
4. Risk Management
4.1. 프로젝트를 완료하는 데 필요한 모든 기술력을 확보했는가?
4.2. 팀원들은 소프트웨어가 운영될 업무 환경에 대한 전문지식을 보유하고 있는가?
4.3. 프로젝트를 이끌 기술 리더가 있는가?
4.4. 인력 자원은 충분한가?
4.5. 팀워크는 좋은가?
4.6. 팀원들이 프로젝트에 전념하고 있는가?
점수 계산 방법
-- 예비 점수: 각 항목별 점수 합산
-- 규모 가중치: 프로젝트 팀에 개발책임자, 품질 보증팀 리더, 최종 책임자를 포함하는 전담 인원이 3명 혹은 그 이하에는 1.5, 4-6명일 때는 1.25, 그 외에는 1.0
-- 최종 점수: 예비 점수 * 규모 가중치
점수에 따른 해석
90점 이상: 성공이 보장되는 프로젝트
80-89: 평균보다 훨씬 좋다. 일정, 예산, 품질 목표에 근접하게 소프트웨어를 납품할 확률이 매우 높다.
60-79: 평균보다 조금 나은 정도. 일정이나 예산을 충족시킬 확률이 어느 정도 있으나 두 가지를 모두 충족시키기는 어렵다.
40-59: 일반적인 수준. 상당한 수준의 스트레스와 불안한 팀워크를 경험할 확률이 높으며, 결국 비용 초과와 일정 지연으로 기대보다 품질이 떨어지는 소프트웨어를 납품하게 될 것이다.
40미만: 모든 부분이 취약하다. 프로젝트를 끝내는 것이 최대 목표가 된다.
'Software Engineering' 카테고리의 다른 글
| [Article]MSF(Microsoft Solutions Framework) Foundational Principles (0) | 2006.04.08 |
|---|---|
| [번역]프로그래밍의 즐거움 (0) | 2006.03.06 |
| [번역]프로그래밍에서 힘든 부분들 (0) | 2006.03.06 |
| [Article]타당하지 않은 입력으로부터 프로그램을 보호하기 (0) | 2006.03.06 |
| [번역]The Mythical Man-Month (0) | 2006.03.06 |
