Dinu House

소프트웨어 프로젝트 생존전략

- 지은이 : 스티브 맥코넬 / 옮긴이 : 김덕규외 / 정가 : 19,800원

- 392쪽 / 판형 : A5 / 1판

- 출간일 : 2003년 08월 05일

- ISBN-10 : 8995300957 / ISBN-13 : 9788995300954

[저자소개]

스티브 맥코넬(Steve McConnell)

Construx Software Builders사의 수석 소프트웨어 엔지니어며, 마이크로소프트를 포함한 소프트웨어 선도 기업에 대한 컨설팅을 하고 있다. 저서로 Code Complete(1993)와 Rapid Development(1996)가 있고, 이 책은 모두 Software Development 잡지가 수여하는 Jolt 상(우수한 소프트웨어개발 서적 부문)을 수상했다. IEEE Software 잡지의 “Best Practices” 칼럼 편집장이기도 하다.

최근 전문 소프트웨어 개발자가 되기 위해서는 뭘 해야 하는지에 대한 내용을 담은 Professional Software Development(After the Gold Rush의 2/E, Addison-Wesley)을 집필했다.

Steve는 워싱턴의 Walla Walla에 위치한 Whitman College에서 학위를, 그리고 Seattle University에서 소프트웨어 공학으로 석사학위를 획득했다. 그는 IEEE Software와 Software Practitioner의 편집위원이며, IEEE Computer 잡지의 수석 평론가이자, IEEE Computer Society and ACM의 일원이다. 이 책에 관해 질문이나 의견이 있다면 Microsoft Press사의 메일인 stevemcc@construx.com를 통해 연락할 수 있다. [출처: 인사이트]

[목 차]

1부 생존을 위한 사고방식

1장 살아남기 위한 방법

소프트웨어 프로젝트 생존 훈련에 참가하게 된 여러분을 환영한다. 소프트웨어 프로젝특에서 생존할 가능성이 매우 낮기는 하지만 사실 꼭 그렇게 낮아야 할 필요는 없다. 소프트웨어 프로젝트에서 살아남으려면 우선 문명화된 방식(Civilized way)으로 프로젝트를 시작하면 된다. 그러면 출발점부터 단순히 생존하는 것 이상이 가능할 것이다.

고객 권리 장전

프로젝트에 대한 목표를 세우고 이를 따르게 할 권리
소프트웨어 프로젝트에 소요되는 기간과 비용을 알 권리
소프트웨어가 가져야 할 기능을 결정할 권리
프로젝트가 수행되는 동안 요구사항을 합리적으로 변경할 권리와 이 같은 변경 작업에 드는 비용을 알 권리
프로젝트 현황을 명확하고 확실하게 알 권리
비용, 일정, 품질 등에 영향을 줄 수 있는 리스크(risk)를 정기적으로 평가하고, 이 같은 문제에 대처할 수 있는 방안을 제공받을 권리
프로젝트 수행기간 동안 프로젝트 산출물을 열람(access)할 권리

프로젝트 팀의 권리장전

프로젝트의 목표를 알고 우선순위를 명확히 할 권리
어떤 제품을 만들어야 하는지 숙지한 후 제품의 정의를 명확히 할 권리
소프트웨어 기능과 관련된 결정 권한을 가진 고객, 관리자, 마케터, 기타 사람들을 자유롭게 만날 권리
프로젝트의 각 단계(Phase)를 기술적으로 책임 있게 수행하며, 특히 프로젝트 초기에 조기 코딩을 강요당하지 않을 권리
할당된 작업량(effort)과 일정을 승낙할 권리. 프로젝트 각 단계(stage)에서 이론적인 방식으로 비용과 일저ㅇ을 추정할 수 있으며, 이같은 추정치를 내기 위해 시간을 충분히 가질 수 있다. 요구사항이 변경될 때마다 추정치를 수정하고 검토할 수 있다.
프로젝트 현황을 고객과 상위 관리자에게 정화하게 보고할 권리
생산적인 환경에서 일하기 위해 업무(특히, 프로젝트의 아주 중요한 부분) 수행 시 잦은 간섭으로 산만해지지 않을 권리

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

생존테스트

요구사항(Requirements)

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

계획(Planning)

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

프로잭트 통제(Project Control)

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

리스크 관리(Risk Management)

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

인력(Personnel)

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

총점(Total)

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

3장 생존의 개념

잘 정의된 개발 프로세스는 소프트웨어 프로젝트의 생존에 중요하고, 필수적인 요소다. 이것은 소프트웨어 개발 관련자들이 쓸데없는 데 신경 쓰지 않고 생산적인 업무에 전념하여 프로젝트를 안정적으로 끝낼 수 있도록 한다. 빈약한 프로세스(poorly planned process)는 개발자들이 실수를 수정하는 데 많은 시간을 소비하도록 한다. 프로젝트에서 성공하기 위한 수단 대부분은 상류(upstream) 활동에 있다. 식견 있는 소프트웨어 이해 관계자들은 하류의 문제를 최소화하기 위해 상류 활동에 역량을 집중한다.

4장 생존의 기술

5장 성공적인 프로젝트란?

2부 생존 준비

6장 움직이는 표적 맞추기 – 변경통제(change control)에 대해
7장 사전 계획
8장 요구사항 개발
9장 품질 보증
10장 아키텍처
11장 최종준비

3부 단계에 의한 성공

12장 단계 계획 수립의 시작
13장 상세설계
14장 구축

구축은 개발팀이 소프트웨어 생명을 불어 넣는 흥미로운 시간이다. 구축 이전의 작업들이 효과적으로 완수되었다면 구축은 조화롭고 생산적인 시간이 되어, 개발자는 꾸준히 시스템에 기능을 추가하고 일별 빌드(dairy build) 및 스모크 테스트를 수행할 수 있을 것이다. 성공적인 프로젝트 팀은 구축 단계에서 소프트웨어를 더 간결하게 만들고, 소프트웨어에 가해진 변경을 통제하는 방법을 찾는데 더 많은 주의를 기울인다. 프로젝트 관리자가 상세 마일스톤, 결함, 10대 리스크 목록, 시스템 등을 포함하는 핵심 진척 지표들을 살펴보면 모든 진척 사항이 한눈에 파악된다.

ㅇ Integration Procedure (권장 통합단계)

Developer develops a piece of code.
Developer unit tests the code.
Developer steps through every line of code in an interactive debugger, including all exception and error cases.
Developer integrates this preliminary code with a private version of the main build.
Developer submits code for technical review.
Developer turns code over informally to testing for test case preparation.
Code is reviewed.
Developer fixes any problems identified during the review.
Fixes are reviewed.
Developer integrates final code with the main build.
Code is declared to be "complete" and can be checked off the project activity list.

ㅇ Daily Build and Smoke Test Procedure*

Merge code changes. The developer compares his or her private copy of the source files with the master source files, checking for conflicts and inconsistencies between recent changes made by other developers and the new or revised code to be added. The developer then merges his or her code changes with the master source files. Merging is usually supported by automated source code control tools, which warns the developer of any inconsistencies.
Build and test a private build.The developer builds and tests a private release to be sure that the newly implemented feature still works as expected.
Execute the smoke test.The developer runs the current smoke test against the private build to be sure the new code won’t break the build.
Check in.The developer checks his or her private copies of the source code into the master source files. Some projects establish times during which new code can and can’t be added to the daily build; for example, new code must be added no later than 5:00 p.m. and no earlier than 7:00 am.
Generate the daily build.The build team (or build person) generates a complete build of the software from the master sources.
Run the smoke test.The build team runs the smoke test to evaluate whether the build is stable enough to be tested.
Fix any problems immediately!If the build team discovers any errors that prevent the build from being tested (that break the build), it notifies the developer who checked in the code that broke the build, and that developer fixes the problem immediately. Fixing the build is the project’s top priority.

* This process starts at the point the developer is ready to check in code at Step 10 in Table 14-1’s Recommended Integration Procedure. It assumes that the developer has checked out source code files that need to be changed and possibly created new files.

ㅇ 제1단계의 특수한 고려 사항