Chapter 03는 소프트웨어 구축을 준비하기 위해 수행해야 하는 작업을 설명하고 있습니다.

“Measure Twice, Cut Once”라는 목수의 용어는 “두 번 측정하고, 한 번 자르세요”라는 뜻으로, 실행에 옮기기 전에 철저히 준비하라는 의미입니다. 이유는 간단합니다. 다시 하면 시간과 비용이 추가되기 때문입니다.

설계도가 중요한 이유

건물을 짓는 도중에 문제가 발생하면 건물을 처음부터 다시 지어야 할 수도 있고, 예상하지 못한 일정이 추가됩니다. 이 모든 것은 결국 비용 증가로 이어집니다.

3.1 선행 조건의 중요성

준비의 가장 중요한 목표는 위험을 줄이는 것입니다.
프로젝트에서 가장 일반적인 위험은 다음과 같습니다:

  • 부실한 요구 사항
  • 부실한 프로젝트 계획

따라서 준비는 요구 사항 및 프로젝트 계획을 개선하는 데 중점을 둡니다.

불안전한 준비를 하게 되는 이유

  1. 빨리 코딩을 시작하고 싶어서
  2. 관리자들이 준비 단계를 소프트웨어 개발의 일부로 생각하지 않아서

상대를 완전히 설득할 수 있는 주장

  1. 논리에 호소
  2. 비유에 호소

데이터로 설명하기

결함 발생 시점과 비용 관계
결함 발생 시점과 확인 시점이 늦어질수록 비용은 급격히 높아집니다.

3.2 작업 중인 소프트웨어의 종류를 결정하라

반복적 접근 방식이 필수 구성 요소에 미치는 영향

반복적인 접근 방식은 부적절한 초기 작업의 영향을 줄일 수 있지만, 완전히 제거하지는 못합니다.

반복적 접근 방식의 특징

반복적 접근 방식과 순차적 접근 방식의 차이

  1. 결함 수정 비용 감소
    • 결함이 삽입된 시점에 더 가까운 단계에서 감지됨.
    • 하지만 여전히 결함 수정에는 재설계, 재코딩 및 재테스트 비용이 필요함.
  2. 비용 분산
    • 비용이 프로젝트 전반에 걸쳐 분산되므로 마지막에 클러스터링되지 않음.
    • 하지만 최종 비용은 순차적 접근 방식과 비슷할 수 있음.

반복적/순차적 접근 비교

반복적 접근 방식과 순차적 접근 방식 중 선택

순차적 접근 방식 선택 시

  • 요구 사항이 안정적일 때
  • 설계가 명확할 때
  • 개발팀이 익숙한 분야일 때
  • 리스크가 적을 때
  • 장기적인 예측 가능성이 중요할 때

반복적 접근 방식 선택 시

  • 요구 사항이 불안정할 때
  • 설계가 복잡하거나 도전적일 때
  • 개발팀이 익숙하지 않은 분야일 때
  • 리스크가 클 때
  • 장기적인 예측 가능성이 중요하지 않을 때
  • 요구 사항 변경 비용이 낮을 때

3.3 문제 정의 선행 조건

문제 정의는 가능한 솔루션에 대한 언급 없이 문제가 무엇인지 정의하는 것입니다.

좋은 예나쁜 예
“We can’t keep up with orders for the Gigatron”“We need to optimize our automated data-entry system to keep up with orders for the Gigatron”

나쁜 예가 더 자세한데 왜 나쁘냐? : 더 자세한게 안 좋은 겁니다. 문제 정의는 지금의 문제가 무엇인지만 알리는게 목적입니다. 해결책을 원하는게 아닙니다.

문제 정의 작성 시 주의점

문제 정의 작성 시 주의점

  1. 사용자 언어로 작성 (컴퓨터 용어 사용 금지)
  2. 사용자 관점에서 문제를 설명

문제를 정의하지 못했을 때의 불이익

  • 잘못된 문제를 해결하는 데 많은 시간을 낭비하게 됨.

3.4 요구 사항 선행 조건

요구 사항 활동은 솔루션을 향한 첫 번째 단계입니다.

공식 요구 사항의 중요성

  1. 사용자로부터 시스템 기능을 구동하도록 도움을 받음.
  2. 논쟁을 피할 수 있음.
  3. 개발 후 시스템 변경을 최소화.
  4. 비용 절감 가능.

예: 표 3-1에 따르면 대규모 프로젝트에서 오류 감지 시점에 따라 수정 비용이 다릅니다:

  • 아키텍처 단계: 3배
  • 코딩 중: 5-10배
  • 릴리스 후: 10-100배

요구 사항 변경 처리

  1. 요구 사항 검사 목록 사용.
  2. 요구 사항 변경 비용을 고객도 이해하도록 함.
  3. 변경 관리 절차 설정.
  4. 변경 사항을 수용하는 개발 접근 방식 사용.
  5. 프로젝트 취소를 가정해 계획 수립.
  6. 프로젝트의 비즈니스 사례에 집중.

3.5 아키텍처 필수 구성 요소

소프트웨어 아키텍처는 소프트웨어 설계의 상위 수준 요소로, 설계의 세부 사항을 포함하는 프레임워크입니다.
설계의 제약 조건을 정의하며, 전체 시스템에 적용됩니다.

효율적인 아키텍처의 조건

  • 주요 요구 사항을 조기에 식별
  • 설계 제약을 명확히 정의
  • 프로젝트 요구 사항에 따라 반복적 또는 순차적 접근 방식을 선택

3.6 업스트림 필수 구성 요소에 소요되는 시간

  • 문제 정의, 요구 사항 및 소프트웨어 아키텍처에 소요되는 시간은 프로젝트의 요구 사항에 따라 다름.
  • 일반적으로 잘 운영되는 프로젝트는 노력의 약 10-20%와 일정의 약 20-30%를 요구 사항, 아키텍처 및 사전 계획에 투자함.