[품질] 소프트웨어 프로젝트 생존 테스트

 

ChatGPT를 사용하지 않습니다.

 

목차

 

 

1. 개요

 

소프트웨어 프로젝트 생존 전략. 스티브 맥코넬 저. 인사이트

에서 발취한 내용입니다.

 

프로젝트는 성공, 실패 가 아니라 

프로젝트 = 생존

이라고 말하고 있습니다.

왜? 소프트웨어 본질 자체가 실패할 확률이 높기 때문입니다.

 

이 책은 바로 '생존'을 기준으로 해서 프로젝트 주요 활동을 체크할 수 있도록

생존 진단표(Survival Check)를 제시하고 있습니다.

 

프로젝트 관리자라면

또는 최고 경영자, 고위 관리자, 고객, 투자자, 최종 사용자 대표, 프로젝트 관리자, 전문 개발자, 독학 프로그래머 등이

이책을 읽어봐야 합니다.

이 책을 한마디로 '해설이 있는 프로젝트 계획서' 라고 할 수 있습니다.

프로젝트 관리 기법을 한권으로 끝내버리시길 바랍니다.

이 책은 프로젝트가 성공하는 데 도움이 되도록 문제의 핵심만을 제시하고 있습니다.

 

추후에 꼭 책을 한번 읽어보시길 추천드립니다.

 

2. 생존 테스트 시작

오늘 이야기를 할 것은 

책 속에 있는 내용중에 일부분입니다.

'소프트웨어 프로젝트 생존 테스트' 입니다.

과연 프로젝트를 생존할 수 있을것인가?

성공적인 프로젝트를 위해서 무엇을 체크해야 하지?

현재 우리 프로젝트의 수준은 어떠한가?

이 프로젝트를 계약을 해야 할까? 말아야 할까?

 

프로젝트를 시작하기전이나

프로젝트를 진행하는 단계별로 체크를 해볼 수 있습니다.

각 항목별로 점수를 부여합니다.

부여하는 점수는 

그렇다 3점 대체로 그렇다 2점 그렇지 않다 1점

총 33개 항목입니다.

 

33개 항목을 3점식으로 부여했을때 = 33 x 3 = 99점이 최고 점입니다.

최고점은 99점입니다.

 

3. 생존 테스트 5개 항목

각 항목이 존재하며, 총 5개의 큰 항목으로 구분되어 있습니다.

주 항목내에 하위 항목이 존재합니다.

 

5개 활동 단계라고 할수 있는 구분 항목은 다음과 같습니다.

1) 요구사항(Requirements) 2) 계획 (Planning) 3) 프로젝트 통제 (Project Control) 4) 리스크 관리 (Risk Management) 5) 인력 (Personnel)

 

4. 생존 테스트 체크 항목

요구사항 (Requirements) 1.프로젝트에 대한 명확한 비전이나 임무(mission)가 있는가? 2.팀 구성원 모두가 제시된 비전을 현실적이라고 생각하는가? 3.고객의 입장에서 얻게 되는 비즈니스적인 이점과 그 이점에 대한 측정 방법이 상세하게 제시되어 있는 사업계획서(business case)가 있는가? 4.실제 시스템이 갖는 기능을 실질적으로 명확하게 보여줄 사용자 인터페이스 프로토타입(user interface prototype)이 있는가? 5.소프트웨어 명세(software specification)는 상세하게 문서화 되어 있는가? 6.팀원들은 소프트웨어의 실제 사용자(end user)와 프로젝트 초기에 면담을 했는가? 또 이들이 프로젝트 전반에 걸쳐 지속적으로 참여하는가? 계획 (Planning) 7. 소프트웨어 개발 계획이 상세하게 문서화 되어 있는가? 8. 작업(task) 목록에 설치용 프로그램 개발, 이전 버전에서 신 버전으로의 데이터 변환(conversion), 제3자 소프트웨어와 통합, 고객과 회의, 기타 사소한 일까지 모두 포함되어 있는가? 9. 일정과 예산 추정치를 가장 최근에 완료한 단계에 공식적으로 업데이트(update)했는가? 10. 프로젝트의 아키텍처와 설계를 상세하게 문서로 만들었는가? 11. 시스템 테스트는 물론이며 설계 및 코드 리뷰(review)까지 요구하는 상세한 품질 보증 계획(QAP, Quality Assurance Plan)이 문서화 되어 있는가? 12. 각 단계(stage)별로 어떤 소프트웨어가 구현되고 납품될지 상세히 설명한 단계별 납품 계획이 있는가? 13. 프로젝트 계획에 휴일, 휴가, 병가, 교육 등의 기간을 포함시켰는가? 자원의 할당은 100퍼센트가 안 되도록 하였는가? 14. 일정을 포함한 프로젝트 계획은 개발팀, 품질 보증팀, 기술 문서화팀(technical writing team) 같이 관련된 모든 사람들의 승인을 얻었는가? 프로젝트 통제 (Project Control) 15. 의사결정 권한을 가진 임원 1명이 프로젝트를 챔임지는가? 또 그 임원은 프로젝트를 적극 지원하는가? 16. PM이 프로젝트에 열중할 여건이 조성되어 있는가? 17. 일의 완성(100퍼센트) 여부를 파악하기 위한 명확하고도 상세한 마일스톤(binary milestones)이 정의되어 있는가? 18. 프로젝트 이해 관계자들이 마일스톤 완성 여부를 쉽게 파악할 수 있는가? 19. 팀원들이 무기명으로 직속상사나 상급 관리자에게 문제점을 보고하고, 그 결과를 피드백(feedback) 받을 수 있게 되어 있는가? 20. 소프트웨어 명세서 변경을 통제하는 계획이 문서화 되어 있는가? 21. 변경 요청 사항을 수용하거나 거부할 수 있는 최종 권한을 가진 변경통제위원회(CCB, Change Control Board)가 있는가? 22. 작업량(effort, 공수)과 예상 일정, 업무 분장(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. 팀원들이 프로젝트에 전념하고 있는가? 출처: 소프트웨어 프로젝트 생존전략. 스티브 맥코넬 저. 인사이트

 

5. 결론

소프트웨어 개발 프로젝트의 성공을 위해서

아니 생존을 위해서

프로젝트 관리 는 정말 중요합니다.

프로젝트 관리를 하기 위해서는 프로젝트 계획이 필요합니다.

프로젝트 계획서 작성은 필수가 됩니다.

프로젝트 계획서가 없다면 

프로젝트를 같은 방향을 바라 볼 수 없습니다.

누가 무슨 일을 해야하는지?

일정은 어떠한지?

참여 인력,

개발 환경,

용어 정리,

리스크 관리..

등 프로젝트 성공을 위한 요소 요소 들을 계획서에 담아내고

프로젝트를 지속적으로 관리하면서

완료될때까지 나아가야 합니다.

 

프로젝트 계획서를 어떻게 작성해야지? 하고 궁금해하시는 분이 계시다면

이 책이 도움이 되지 않을까 생각합니다.

프로젝트 생존을 위해서~~~~~

 

 

김영찬 (소프트웨어 품질 전문가)

(재)전주정보문화산업진흥원(JICA)

소프트웨어 개발자로 10년간 발로 코딩 하다가 한계를 느끼고, 

2015년부터 소프트웨어 품질에 몸을 담고 기업을 돕고 있음

email.  sweng@jica.or.kr  / tel. 063-281-4113

주업무 : 소프트웨어 품질 컨설팅, 테스팅,  KOLAS 기술책임자, 개발자 네트워크 운영

자격

  - SP, CMMI, VSE(ISO 29110), ISMS(ISO 27001) 인증 심사원

  - AIT, ISTQB FL, CSTS, 29119 외 다수