3장 준비는 철저하게: 선행조건
3.1 선행 조건의 중요성
품질 좋은 소프트웨어를 개발하기 위한 실천법은 프로젝트의 시작과 중간, 끝 단계에서 품질을 중요시하는 것이다.
- 프로젝트의 마무리 단계에서 품질을 강조하는 경우에는 시스템 테스트에 중점을 둔다.
- 프로젝트 중간 단계에서 품질을 강조하는 경우에는 구현 방법에 역점을 둔다.
- 프로젝트의 시작 단계에서 품질을 강조하는 경우에는 고급 제품을 계획하고 요구사항을 수집하고 설계한다.
구현 전에 선행 조건을 수행하기 위한 필수적인 논의
- 논리적 설득
- 비유적 설득
- 데이터에 근거한 설득
- 프로젝트의 시작 단계에서 발생한 오류를 나중에 고치려하면 많은 비용이 소모된다.
3.2 작업 중인 소프트웨어 종류 결정
순차적 접근 방법을 선호하는 경우
- 요구사항이 상당히 안정적일 때
- 설계가 직관적이며 이해하기 쉬울 때
- 개발 팀이 해당 응용분야에 익숙할 때
- 프로젝트의 위험 부담이 적을 때
- 요구사항, 설계, 코드 변경 비용이 높을 것 같을 때
반복적 접근 방법을 선호하는 경우
- 요구사항을 제대로 이해할 수 없거나 다른 여러가지 이유 때문에 변경될 가능성이 많을 때
- 설계가 복잡하거나 어려울 때
- 개발 팀이 해당 응용 분야에 대해 잘 모를 때
- 프로젝트의 위험 부담이 높을 때
- 장기적인 계획이 중요하지 않을 때
- 요구사항, 설계, 코드 변경 비용이 높지 않을 것 같을 때
소프트웨어의 특성상 반복적인 방법이 순차적인 방법보다 훨씬 유용한 경우가 많다.
3.3 문제-정의 선행 조건
요구사항 작업에 앞서 문제 정의가 수행된다. 문제 정의는 반드시 사용자의 언어로 작성해야 하며 문제는 사용자 관점에서 기술해야 한다.
3.4 요구사항 선행 조건
명시적인 요구사항은 개발자 대신 사용자가 시스템의 기능을 주도하게 하는 데 도움이 된다.
명시적 요구사항은 논쟁을 피하게 해준다.
요구사항에 집중하면 개발을 시작하고 난 후 변경 사항을 최소화하는 데 도움이 된다.
요구사항을 제대로 명시하는 것이 프로젝트의 성공에 있어 효과적인 구현 기술보다 더 중요하다.
구현 중에 요구사항 변경 다루기
모든 사람이 요구사항 변경 비용에 대해서 알게 한다.
요구사항 변경 절차를 구축한다.
변경 사항들을 수용하는 개발 접근 방법을 사용한다.
프로젝트를 취소한다.
프로젝트의 사업성을 주시한다.
3.5 아키텍처 선행 조건
소프트웨어 아키텍처는 소프트웨어 설계의 상위 부분에 속하며 설계 중에서 더 상세한 부분을 담은 틀이다.
80대 20 법칙(시스템의 80%를 담당하는 20% 클래스만 명시한다.)
