'그렇다'라고 답한 것에는 3점을 부여한다. 부분적이라고 생각되면 우세한 정도에(most accurate)따라 판단한다. "대체로 그렇다"라고 답한 것에는 2점을 부여하고, '그렇지 않다'라고 했으면 1점을 준다. 프로젝트 초반에 테스트하게 되면 계획서에 근거하여 대답하고, 한창 진행 중에 있다면 실제 일어난 결과에 의하여 대답하면 된다.
요구사항(Requirements)
1)프로젝트에 대한 명확한 비전이나 임무(mission)이 있는가?
2)팀 구성원 모두가 제시된 비전을 현실적이라고 생각하는가?
3)고객 쪽 입장에서 얻게 되는 비즈니스적인 이점과 그 이점에 대한 측정 방법이 상세하게 제시되어 있는 사업계획서(Business case)가 있는가?
4)실제 시스템이 갖는 기능을 실질적으로 명확하게 보여줄 사용자 인터페이스 프로토타입(User Interface Prototype)이 있는가?
5)소프트웨어 명세(Specification)는 상세하게 문서화 되어 있는가?
6)팀원들은 소프트웨어의 실제 사용자(End User)와 프로젝트 초기에 면담을 했는가? 또 이들이 프로젝트 전반에 걸쳐 지속적으로 참여하는가?
계획(Planning)
7)소프트웨어 개발 계획이 상세하게 문서화 되어 있는가?
8)작업(Task) 목록에 설치용 프로그램 개발, 이전 버전에서 신버전으로의 데이타 변환(Conversion), 제3자 소프트웨어와 통합, 고객과 회의, 기타 사소한 일까지 모두 포함되어 있는가?
9)일정과 예산 추정치를 가장 최근에 완료한 단계에 공식적으로 업데이트(Update)했는가?
10)프로젝트의 아키텍처와 설계를 상세하게 문서로 만들었는가?
11)시스템 테스트는 물론이며 설계 및 코드 리뷰(Review)까지 요구하는 상세한 품질 보증 계획서(QAP : Quality Assurance Plan)이 문서화되어 있는가?
12)각 단계(Stage)별로 어떤 소프트웨어가 구현되고 납품될지 상세히 설명한 단계별 납품 계획이 있는가?
13)프로젝트 계획에 휴일, 휴가, 병가(Sick Days), 교육 등의 기간을 포함시켰는가? 자원의 할당은 100 퍼센트가 안 되도록 하였는가?
14)일정을 포함한 프로젝트 계획은 개발팀, 품질보증팀, 기술문서화팀(Technical Writing Team)같이 관련된 모든 사람들의 승인을 얻었는가?
프로젝트 통제(Project Control)
15)의사 결정 권한을 가진 임원 1명이 프로젝트를 책임지는가? 또 그 임원은 프로젝트를 적극 지원하는가?
16)PM이 프로젝트에 열중할 여건이 조성되어 있는가?
17)일의 완성(100 퍼센트) 여부를 파악하기 위한 명확하고도 상세한 마일스톤(Milestone)이 정의되어 있는가?
18)프로젝트 이해 관계자들(StakeHolders)이 마일스톤 완성 여부를 쉽게 파악할 수 있는가?
19)팀원들이 무기명으로 직속상사나 상급 관리자에게 문제점을 보고하고, 그 결과를 피드백(Feedback) 받을 수 있게 되어 있는가?
20)소프트웨어 명세서 변경을 통제하는 계획이 문서화되어 있는가?
21)변경 요청 사항을 수용하거나 거부할 수 있는 최종 권한을 가진 변경통제위원회(CCB : Change Control Board)가 있는가?
22)작업량(Effort)과 예상 일정, 업무 분장, 계획 대비 진도 등 프로젝트 현황을 팀원들이 알 수 있는가?
23)소스 코드의 개정 통제(Revision Control)는 자동화되어 있는가?
24)오류 추적(Defect Tracking) 소프트웨어, 소스 코드 통제, 프로젝트 관리 소프트웨어 등 프로젝트 수행 환경에 대한 기초적인 자동화 도구가 준비되어 있는가?
리스크 관리(Risk Management)
25)계획서에 리스크 목록이 명확하게 제시되어 있으며 최신 상태로 업데이트 되고 있는가?
26)리스크 식별 책임이 있는 리스크 관리 책임자가 있는가?
27)하도급이 필요한 경우 협력 업체 관리 계획과 담당자가 있는가?
인력 (Personnel)
28)프로젝트를 완료하는데 필요한 모든 기술력을 보유하고 있는가?
29)팀원들은 소프트웨어가 운영될 업무 환경에 대한 전문 지식을 보유하고 있는가?
30)프로젝트를 성공적으로 이끌 기술 리더가 있는가?
31)요구된 모든 과업을 수행할 인력은 충분한가?
32)팀워크는 좋은가?
33)팀원들이 프로젝트에 전념하고 있는가?
총점(Total)
- 예비 점수 : 각 항목별 점수를 합산한다
- 규모 가중치 : 프로젝트 팀에 개발 책임자, 품질 보증 담당자, 최종 책임자를 포함한 전담 인원이 3명 또는 그 이하로 구성된 경우에는 1.5를, 4-6명의 전담자가 있는 경우에는 1.25를, 그 외 경우에는 1.0을 준다.
- 최종 점수 : 예비 점수와 규모 가중치를 곱한다
생존 테스트 해석
- 90점 이상 (최우수)
이 수준의 프로젝트는 프로젝트 일정, 예산, 품질 목표 등 모든 방면에서 성공이 보장된 프로젝트이다. 이같은 프로젝트는 완전한 '자아 실현'을 이룬 것으로 볼 수 있다.
- 80~89 점 (우수)
이 수준의 프로젝트는 평균보다 훨씬 좋게 수행되고 있음을 보여준다. 이러한 프로젝트는 일정, 예산, 품질 목표에 근접하게 소프트웨어를 납품할 확률이 매우 높다.
- 60~79 점 (좋음)
이 수준의 프로젝트는 평균보다 조금 나은 정도로 수행되고 있음을 보여준다. 이러한 경우 일정이나 예산을 충족시킬 확률이 어느 정도 있으나 두가지를 모두 충족시키기는 어렵다.
- 40~59 점 (적당)
일반적인 수준이다. 이 프로젝트는 상당한 수준의 스트레스와 불안한 팀워크를 경험할 확률이 높으며, 결국 비용 초과와 일정 지연으로 초기에 기대했던 것보다 품질이 떨어지는 소프트웨어를 납품하게 될 것이다.
- 40점 미만 (위험)
이런 프로젝트는 요구사항, 계획, 프로젝트 통제, 리스크 관리, 인력 등 주요 부분이 많이 취약하다. 이런 범주의 프로젝트는 "프로젝트를 끝낼 수 있을까"가 최대 현안이다.
출처 : 소프트웨어 프로젝트 생존전략, 스티브 맥코넬 저
소프트웨어 프로젝트 생존 테스트 
