Chapter 3

3.1 선행 조건의 중요성

품질이 좋은 소프트웨어를 개발하기 위해서는 프로젝트의 시작과 중간, 끝 단계에서 품질을 중요시해야한다.

프로젝트의 시작 단계라면 고급 제품을 계획하고 요구사항을 수집하고 설계한다.
프로젝트의 중간 단계라면 구현 방법에 역점을 둔다.
프로젝트의 마무리 단계라면 시스템 테스트에 중점을 둔다.

준비 작업의 가장 중요한 목표는 위험 축소다.
훌륭한 프로젝트 기획자는 프로젝트가 매끄럽게 진행될 수 있도록 가능한 한 초기에 위험 요소를 제거한다.

불완전한 준비의 원인

개발자들이 개발을 하는 데에 있어서 불완전한 준비를 하는 것은 크게 3가지 이유로 나눌 수 있다.

1. 불완전한 준비의 일반적인 원인은 선행 작업에 투입되는 개발자가 충분한 전문 지식을 갖고 있지 않다는 것이다.
2. 선행 작업을 수행하는 법을 알지만, 코드를 작성하는 데에 급급해 선행 작업을 하지 않는 개발자도 있다.
3. 관리자들이 구현에 필요한 선행 조건에 시간을 쓰는 개발자들을 못마땅하게 보기 때문이다.

프로젝트 관리자가 당장 코드를 작성하라고 명령할 때의 대응 방법이 몇 가지 있다.

1. 효과적이지 않은 순서로 작업할 수 없다고 단호하게 거절하기(상사와 관계가 돈독하거나 통장 잔고가 두둑할 때에만..)
2. 좀 꺼림칙하긴 하지만 코드를 작성하는 척하는 것
3. 상사에게 기술 프로젝트의 미묘한 차이에 대해 가르쳐주는 것

구현 전에 선행 조건을 수행하기 위한 필수적인 논의

• 논리적 설득
  • 사용자가 원하는 것이 무엇인지 알아내기 위해 많은 노력을 쓰더라도 처음부터 다시 만드는 것보다는 낫다.
  • 시스템도 같은 이유로 실제로 구축하기 전에 어떻게 구축할 것인지 생각해 보는 것이 중요하다.
• 비유적 설득
  • 개발자들은 소프트웨어 먹이 사슬의 최종 소비자다.
    아키텍트는 요구사항을 먹고 설계자는 아키텍처를 먹고 코더(Coder)는 설계를 먹는다.
  • 반복적 프로젝트를 계획한다면 각 부분의 핵심 요구사항과 아키텍처 요소를 규명해야 한다.
• 데이터에 근거한 설득

  • 처음부터 작업을 제대로 수행해야 한다. 불필요하게 변경할 경우 추가 비용이 든다.
    아래의 표는 결함이 추가된 시기와 발견 시기에 따른 상대적 해결 비용을 보여준다.

    			검출 시기
    발생 시기	요구사항	아키텍처	구현	시스템 테스트	출시 후
    요구사항	1	3	5 ~ 10	10	10 ~ 100
    아케텍처	-	1	10	15	25 ~ 100
    구현	-	-	1	10	10 ~ 25

  • 많은 회사가 초기에 결함을 고치기 위해 노력한다면 비용과 일정을 두 배 이상 줄일 수 있다.

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

소프트웨어 프로젝트의 종류가 다르면 선행 작업과 구현 사이의 비율도 달라야 한다.
일반적으로,
비즈니스 시스템 프로젝트에서는 반복적인 접근 방법을 사용하는 것이 좋고,
안전 필수 시스템은 신뢰성을 높이기 위해 요구사항이 변경되지 않아야 하므로 순차적 접근 방법이 좋다.

선행 조건에서 반복적 접근 방법이 갖는 효과

반복 기법을 사용하든, 순차적인 기법을 사용하든 상관 없이 선행 조건은 중요하다.

선행 조건에 신경을 쓰면 어느 기법이든 상관 없이 비용을 줄일 수 있다.
선행 조건을 무시한 반복적 접근 방법은 선행 조건을 다룬 순차적 접근 방법보다 훨씬 많은 비용이 들 수 있다.

대부분의 프로젝트는 완전히 순차적이지도, 반복적이지도 않다.
요구사항과 설계를 처음부터 완벽히 기술할 수는 없지만, 적어도 필수 요구사항과 설계상 요소는 초기에 정의하는 것이 좋다.
저자는 저자의 경험에 기반하여 한 가지 방법을 추천하고 있다.

1. 요구사항 중에서 80%정도를 미리 명시하기
2. 나머지를 위한 추가적으로 기술할 시간을 할당하기
3. 프로젝트를 진행하며 중요하다고 생각되는 새로운 요구사항들만 수용할 수 있도록 실제 구조 변화를 도모하기

반복적인 방법과 순차적인 방법의 선택

순차적인(선행) 접근 방법을 선호할 상황들

• 요구사항이 안정적일 때
• 설계가 직관적이며 이해하기 쉬울 때
• 개발 팀이 해당 응용 분야에 익숙할 때
• 프로젝트의 위험 부담이 적을 때
• 장기적 계획이 중요할 때
• 요구사항, 설계, 코드 변경 비용이 높을 것 같을 때

반복적인 접근 방법을 선호할 상황들

• 요구사항을 이해할 수 없거나 여러 이유 때문에 변경될 가능성이 많을 때
• 설계가 복잡하거나 어려울 때
• 개발 팀이 해당 응용 분야에 대해 잘 모를 때
• 프로젝트의 위험 부담이 높을 때
• 장기적 계획이 중요하지 않을 때
• 요구사항, 설계, 코드 변경 비용이 높지 않을 것 같을 때

구현 시 가장 먼저 할 일은 프로젝트에 가장 적합한 선행 조건이 무엇인가를 결정하는 것이다.
선행 조건에 시간을 얼마나 쓸지를 잘 결정해야 한다.
31p의 표 3-2에 어떤 선행 조건들이 프로젝트에 적합한지 알 수 있다.

3.3 문제-정의 선행 조건

구현에 들어가기에 앞서 완료해야 하는 첫 번째 선행 조건은 시스템이 해결해야 하는 문제를 기술하는 것이다.
문제 정의는 해결책에 대해서는 언급하지 않고, 문제가 무엇인지를 언급해야 한다.

• 사과를 깎을 수 없다.(O: 문제가 있는 것처럼 들린다.)
• 사과를 칼로 깎아야 한다.(X: 문제점에 대한 기술이라기보다는 해결책에 가깝다.)

또한, 문제 정의는 사용자의 언어로 작성해야 한다.
문제를 정의하는 데 실패하면 잘못된 문제를 해결하느라 많은 시간을 낭비한다.

3.4 요구사항 선행 조건

요구사항은 소프트웨어 시스템이 무엇을 수행해야 하는지에 대해 상세하게 기술하고 해결책을 구하기 위한 첫 과정이다.

명시적인 요구사항이 필요한 이유

1. 명시적 요구사항은 개발자 대신 사용자가 시스템의 기능을 주도하게 하는데 도움을 준다.
2. 요구사항에 집중하면 개발 시작 후 변경 사항 최소화에 도움을 준다.
3. 요구사항을 제대로 명시하는 것은 프로젝트 성공에 있어 효과적 구현 기술보다 중요하다.
   구현 시 얼마나 확실한 요구사항을 갖고 있는지 판단하기 위한 척도를 보려면 여기를 클릭.

3.5 아키텍처 선행 조건

전형적 아키텍처의 구성 요소

좋은 시스템 아키텍처에는 공통 요소가 많이 있다.
다음은 어느 상황이든 고려해야 하는 아키텍처의 구성 요소이다. 세부 내용은 본서 45p에서부터 확인할 수 있다.

• 프로그램 구조
• 주요 클래스
• 데이터 설계
• 비즈니스 규칙
• 사용자 인터페이스 설계
• 자원 관리
• 보안
• 성능
• 확장성
• 상호운용성
• 국제화와 지역화
• 입력/출력
• 오류 처리
• 장애 허용
• 구조적 실행 가능성
• 과도한 엔지니어링
• 구입과 구현 결정
• 재사용 결정
• 변경 전략
• 일반적인 아키텍처 품질

훌륭한 아키텍처가 갖추어야 할 항목을 보려면 여기를 클릭.

3.6 선행 조건에 소요되는 시간

일반적으로 제대로 진행되는 프로젝트는 요구사항과 아키텍처, 사전 계획 수립을 위해 전체 노력의 10~20%와 전체 시간의 20~30%를 투자한다.

프로젝트가 형식적이든 비형식적이든 상관없이 요구사항이 불완전하다면 요구사항 수집 자체를 하나의 프로젝트로 다루어야 한다.

아키텍처에 시간을 할당할 때에도 요구사항 개발과 유사한 방법을 사용한다.
필요하다면 아키텍처 작업 역시 별도의 프로젝트로 진행한다.