'management'에 해당하는 글 1건

프로젝트 생존 관련 테스트입니다.

우리도 이와 비슷한 방법으로 사전에 또는 프로젝트 진행 중에 테스트를 해보는 것이 도움이 되리라 생각 하여 장문의 테스트를 올립니다.

프로젝트를 결정하기전에 확인해보는 것도 좋은 방안이라고 생각합니다.

과연 이프로젝트가 성공가능한것인가> 아닌가를... 'ㅡ'

소프트웨어 프로젝트 생존 테스트


점수

@ 그렇다 3점

@ 대체로 그렇다 2점

@ 그렇지 않다 1점


프로젝트 초반에 테스트시 프로젝트 수행 계획서(SOW) 및 WBS를 근거로 테스트하고,

진행중일 시는 실제 일어난 결과를 바탕으로 테스트 한다.


생존 테스트


요구사항 (Requirement)


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 Paln)이 문서화 되어 있는가?

12. 각 단계(Stage)별로 어떤소프트웨어가 구현되고 납품될지 상세히 설명한 단계별 납품 계획이 있는가?

13. 프로젝트 계획에 휴일, 휴가, 병가(sick days), 교육등의 기간을 포함시켰는가? 자원의 할당은 100%가 안되도록 하였는가?

14. 일정을 포함한 프로젝트 계획은 개발팀, 품질보증팀, 기술 문서화팀(technical writing team) 같이 관련된 모든 사람들의 승인을 얻었는가?


프로젝트 통제 (Project Control)


15. 의사결정 권한을 가진 임원 1명이 프로젝트를 책임지는가? 또 그임원은 프로젝트에 적극 지원하는가?

16. PM이 프로젝트에 열중할 여건이 조성되어 있는가?

17. 일의 완성 (100%)여부를 파악하기 위한 명확하고도 상세한 마일스톤(binary milestone)이 정의되어 있는가?

18. 프로젝트 이해관계자들(stakeholders)이 마일스톤 완성여부를 쉽게 파악할수 있는가?

19. 팀원들이 무기명으로 직속상상나 상급 관리자에게 문제점을 보고하고, 그결과를 피드백(feedback) 받을수 있게 되어 있는가?

20. 소프트웨어 명세서 변경을 통제하는 게획이 문서화 되어 있는가?

21. 변경 요청사항을 수용하거나 거부할수 있는 최종 권한을 가진 변경통제위원회(CCB: Change Control Board)가 있는가?

22. 작업량(efoort)과 예상일정, 업무 분장(task assignment), 계획대비 진도 등 프로젝트 현황을 팀원들이 알수 있는가?

23. 소스코드의 개정통제(revision control)는 자동화되어 있는가?

24. 오류 추적(defect tracking) 소프트웨어, 소스코드 통제(control), 프로젝트 관리 소프트웨어등 프로젝트 수행환경(Project environment)에 대한 기초적인 자동화 도구가 준비되어 있는가?


리스크 관리 (Risk Management)


25. 계획서에 리스크 목로기 명확하게 제시되어 있으며, 최신상태로 업데이트 되고 있는가?

26. 리스크 식별 책임이 있는 리스크 관리 책임자가 있는가?

27. 하도급이 필요한 경우 협력업체 고나리 계획과 담당자가 있는가? (협력업체가 없다면 만점을 준다.)


인력 (Personnel)


28. 프로젝트를 완료하는데 필요한 모든 기술력(technical expertise)을 보유하고 있는가?

29. 팀원들은 소프트웽어가 운영될 업무 환경에 대한 전문지싯을 보유하고 있는가?

30. 프로젝트를 성공적으로 이끌 기술 리더가 있는가?

31. 요구된 모든 과업을 수행할 인력이 충분한가?

32. 팀워크는 좋은가?

33. 팀원들이 프로젝트에 전념하고 있는가?


총점(Total)


----- 예비점수: 각 항목별 점수를 합산한다.

----- 규모 가중치(size multiplier) : 프로젝트 팀에 개발 책임자, 품질보증 담당자, 최종(first-level) 책임자를 포함한 전담인원이 3명 또는 그이하로 구성된경우에는 1.5를 4~6명의 전담자가 있는 경우에는 1.25를 그외경우에는 1.0을 준다.

----- 최종점수 : 예비점수 와 규모 가중치를 곱한다.



생존 테스트 점수

---------------------------------------------------------------------------
점수                              해석

---------------------------------------------------------------------------

90점이상(최우수)            이수준의 프로젝트는 프로젝트 일정, 에산, 품질목표등 모든 방면에서

                                    성공이 보장된 프로젝트다.

                                    이같은 프로젝틑 완전한 프로젝트 자아실현(Self-actualized)을 이룬것

                                    으로 볼수 있다.

---------------------------------------------------------------------------

80-89점 (우수)               이수준의 프로젝트는 평균보다 훨씬 좋게 수행되고 있음을 보여준다.

                                   이러한 프로젝트는 일정, 예산,
                                   품질 목표에 근접하게 소프트웨어를 납품할 확율이 매우 높다.

---------------------------------------------------------------------------

60-79점 (좋음)               이수준의 프로젝트는 평균보다 조금 나은 정도로 수행되고 있음을

                                   보여준다.

                                   이러한 경우 일정이나 예산을 충족시킬 확률이 어느정도 있으나 두가지

                                   를 모두 충족시키기는 어렵다.

---------------------------------------------------------------------------

40-59점 (적당)               일반적인 수준이다. 이 프로젝트는 상당한 수준의 스트레스와 불안한

                                   팀워크를 경험할 확률이 높으며,

                                   결국 비용 초과와 일정 지연으로 초기에 기대했던 것보다 품질이

                                   떨어지는 소프트웨어를 납품하게 될것이다.

                                   이런 프로젝트는 전반적인 계획을 수정하여 효과를 증대시켜야 한다.

---------------------------------------------------------------------------

40 미만 (위험)               이런 프로젝트는 요구사항, 계획, 프로젝트 통계, 리스크 관리, 인력등

                                  주요부분이 많이 취약하다.

                                   이런 범주의 프로젝트는 "프로젝트를 끝낼수있을까?가 최대 현안이다.

---------------------------------------------------------------------------


발취 - 스티브 맥코넬의 소프트웨어 프로젝트 생존 전략 (Software Project Survival Guide)

Powered By Brainchaos™

728x90
반응형

WRITTEN BY
bca (brainchaos)
언저리 - 블로그 = f UN + b LOG #BigData, #GrapDB, #Ani, #Game, #Movie, #Camping, 보드, 술먹고 떠들기, 멍때리기, 화장실에서 책읽기, 키스, 귀차니즘, 운동싫어, 버럭질 최고, 주경야독, May The Force be With You

,