기록은 기억이다.

왜(Why) ?
- 관리할 필요가 있는가? 리스크가 발생할 확률과 발생되었을 경우 벌어지는 일은 무엇이며, 심각성은 어떠한지 설명해야 한다.

어떻게(How) ?
- 통상적으로 어떻게 해결하는가? 리스크를 해결하는 특수한 방법이 아닌 통상적인 접근 방법을 제시해야 한다. 고려되고 있는 대안들을 제시하거나 목록을 유지해야 한다.

무엇을(What) ?
- 구체적으로 조치해야 할 사항은 무엇인가? 리스크를 해결하기 위한 구체적인 조치 사항과 작업 산출물이 무엇인지 정해야 한다. 예를 들면, 목표한 날짜까지 리스크가 해결되지 않을 경우 등의 리스크 증가 조건에 대해서도 제시하여야 한다.

누가(Who) ?
- 수행 책임자는 누구인가? 조치 사항별 수행 책임자들을 식별해 놓아야 한다.

언제(When) ?
- 각 조치 사항은 언제까지 완료될 것인가? 각 조치 사항별 완료 일자를 정해야 한다.

얼마나(How much) ?
- 리스크 해결을 위한 예산은 얼마나 배정하였는가? 각 조치 사항별 소요 비용이 얼마나 되는지 계산해야 한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

생존 테스트
요구사항(Requirements)

1. 프로젝트에 대한 명확한 비전이나 임무가 있는가?
2. 팀 구성원 모두가 제시된 비전을 현실적이라고 생각하는가?
3. 고객 쪽 입장에서 얻게 되는 비즈니스적인 이점과 그 이점에 대한 측정 방법이 상세하게 제시되어 있는 사업계획서가 있는가?
4. 실제 시스템이 갖는 기능을 실질적으로 명확하게 보여줄 사용자 인터페이스 프로토타입이 있는가?
5. 소프트웨어 명세는 상세하게 문서화 되어 있는가?
6. 팀원들은 소프트웨어의 실제 사용자와 프로젝트 초기에 면담을 했는가? 또 이들이 프로젝트 전반에 걸쳐 지속적으로 참여하는가?

계획(Planning)

1. 소프트웨어 개발 계획이 상세하게 문서화 되어 있는가?
2. 작업목록에 설치용 프로그램 개발, 이전 버전에서 신 버전으로의 데이터 변환, 제3자 소프트웨어와 통합, 고객과 회의, 기타 사소한 일까지 모두 포함되어 있는가?
3. 일정과 예산 추정치를 가장 최근에 완료한 단계에 공식적으로 업데이트했는가?
4. 프로젝트의 아키텍처와 설계를 상세하게 문서로 만들었는가?
5. 시스템 테스트는 물론이며 설계 및 코드 리뷰까지 요구하는 상세한 품질 보증 계획이 문서화 되어있는가?
6. 각 단계별로 어떤 소프트웨어가 구현되고 납품될지 상세히 설명한 단계별 납품 계획이 있는가?
7. 프로젝트 계획에 휴일, 휴가, 병가, 교육등의 기간을 포함시켰는가? 자원의 할당은 100퍼센트가 안 되도록 하였는가?
8. 일정을 포함한 프로젝트 계획은 개발팀, 품질 보증팀, 기술 문서화팀 같이 관련된 모든 사람들의 승인을 얻었는가?

프로젝트 통제(Project control)

1. 의사결정 권한을 가진 임원 1명이 프로젝트를 책임지는가? 또 그 임원은 프로젝트를 적극 지원하는가?
2. PM이 프로젝트에 열중할 여건이 조성되어 있는가?
3. 일의 완성(100퍼센트)여부를 파악하기 위한 명확하고도 상세한 마일스톤이 정의되어 있는가?
4. 프로젝트 이해 관계자들이 마일스톤 완성 여부를 쉽게 파악할 수 있는가?
5. 팀원들이 무기명으로 직속상사나 상급 관리자에게 문제점을 보고하고, 그 결과를 피드백 받을 수 있게 되어 있는가?
6. 소프트웨어 명세서 변경을 통제하는 계획이 문서화 되어 있는가?
7. 변경 요청 사항을 수용하거나 거부할 수 있는 최종 권한을 가진 변경통제 위원회가 있는가?
   
8. 작업량과 예상일정, 업무 분장, 계획 대비 진도등 프로젝트 현황을 팀원들이 알 수 있는가?
9. 소스코드의 개정 통제는 자동화되어 있는가?
10. 오류 추적 소프트웨어, 소스코드 통제, 프로젝트 관리 소프트웨어 등 프로젝트 수행 환경에 대한 기초적인 자동화 도구가 준비되어 있는가?

리스크 관리(Risk management)

1. 계획서에 리스크 목록이 명확하게 제시되어 있으며 최신 상태로 업데이트 되고 있는가?
2. 리스크 식별 책임이 있는 리스크 관리 책임자가 있는가?
3. 하도급이 필요한 경우 협력 업체 관리 계획과 담당자가 있는가?

인력(Personnel)

1. 프로젝트를 완료하는 필요한 모든 기술력을 보유하고 있는가?
2. 팀원들은 소프트웨어가 운영될 업무 환경에 대한 전문지식을 보유하고 있는가?
3. 프로젝트를 성공적으로 이끌 기술 리더가 있는가?
4. 요구된 모든 과업을 수행할 인력은 충분한가?
5. 팀워크는 좋은가?
6. 팀원들이 프로젝트에 전념하고 있는가?
   

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

성공적인 프로젝트를 위해 하지말아야할 8가지

1. 팀구성원이 체계적이지 않은 방법으로 일하게 놔두지 마라.

2. 터무니 없는 목표를 설정하지 말라

3. 미치게 될 영향을 평가해 보지 않거나 변경위원회의 승인없이 수정을 가하지 마라

4. 겉치례 작업을 하지마라

5. 특히 프로젝트 초기에 인원을 과다하게 배정하지 마라

6. 현 단계에서 지연된 일정을 나중에 복구할 수 있다고 가정하지 마라

7. 비용 절감이나 일정단축을 위해 기준을 느슨하게 하지 말라

8. 많은 양의 문서가 성공을 보장한다고 믿지 마라

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

성공적인 프로젝트를 위한 9가지요소

1. 소프트웨어 개발 계획을 만들고 따른다.

2. 프로젝트 인력에게 권한을 부여한다.

3. 권위주의를 최소화한다.

4. 요구사항의 베이스라인을 정의하고 변경사항을 관리한다.

5. 프로젝트의 건강 상태와 진행상황을 주기적으로 점검하고 필요하다면 재계획한다.

6. 시스템규모, 공수, 일정을 주기적으로 다시 추정한다.

7. 단계전이를 정의하고 관리한다.

8. 팀 정신을 키운다.

9. 소수의 고참 개발자로 프로젝트를 시작한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

소프트웨어 프로젝트 생존전략을 읽었다.

프로젝트라는게 조금만 생각하면 프로젝트가 어긋나지 않을거 같은데

사실은 프로젝트에서 조금만 딴생각을 해도 프로젝트는 어긋나기 시작하는거 같다.

아래는 내용중에 다시한번 상기해야하는 내용을 모아봤다.

비전을 수립하는데 가장 중요한 것은 지나친것은 부족함만못하다는 메시지를 전달하는 것이다. 비전은 간단명료한 것이 좋다
- p130

생산성이 뛰어난 프로그래머가 나타날 때까지 기다리는 것이,
능력과 생산성이 떨어지는 프로그래머가 생산성을 갖출 때까지
기다리는 것보다 좋은 방법이다.
- p149

요구사항을 수집하는데 가장 어려운 일은
사용자가 원하는 것을 '기록'하는 활동이 아니다.
그들 자신이 원하는 것을 무엇인지 알 수 있게 도와주는
하나의 탐험적이며 '개발' 차원의 활동이 필요하다.

성공적인 프로젝트를 위한 9가지요소

1. 소프트웨어 개발 계획을 만들고 따른다.

2. 프로젝트 인력에게 권한을 부여한다.

3. 권위주의를 최소화한다.

4. 요구사항의 베이스라인을 정의하고 변경사항을 관리한다.

5. 프로젝트의 건강 상태와 진행상황을 주기적으로 점검하고 필요하다면 재계획한다.

6. 시스템규모, 공수, 일정을 주기적으로 다시 추정한다.

7. 단계전이를 정의하고 관리한다.

8. 팀 정신을 키운다.

9. 소수의 고참 개발자로 프로젝트를 시작한다.

성공적인 프로젝트를 위해 하지말아야할 8가지

1. 팀구성원이 체계적이지 않은 방법으로 일하게 놔두지 마라.

2. 터무니 없는 목표를 설정하지 말라

3. 미치게 될 영향을 평가해 보지 않거나 변경위원회의 승인없이 수정을 가하지 마라

4. 겉치례 작업을 하지마라

5. 특히 프로젝트 초기에 인원을 과다하게 배정하지 마라

6. 현 단계에서 지연된 일정을 나중에 복구할 수 있다고 가정하지 마라

7. 비용 절감이나 일정단축을 위해 기준을 느슨하게 하지 말라

8. 많은 양의 문서가 성공을 보장한다고 믿지 마라

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

모든 요구사항에 대하여 문서화를 보장하는 것
요구사항에 대한 추가와 변경을 통제하기 위하여 체계적인 절차를 적용하는 것
모든 요구사항, 설계, 소스코드를 체계적으로 테크니컬 리뷰하는 것
테스트 계획, 리뷰 계획, 결함 추적 계획 등을 포함하는 체계적인 품질 보증계획을 수립하는 것
소프트웨어 컴포넌트를 개발하고 통합하는 순서가 명시괸 구현 계획을 수립하는 것
자동화된 도구로 소스코드를 관리하는 것
마일스톤이 달성될 때 마다 비용과 일정 추정을 재검토하는 것. 마일스톤을 정할때는 요구사항 분석, 아키텍처 수립, 상세설계에 대한 완성도를 확인해얗낟. 또한 각 구현 단계에 대한 완성 여부 확인

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.