코드컴플리트 - 챕터 3 선행조건 (준비는 철저하게) - Part 1 기초수립

내용

• 3.1 선행조건의 중요성
• 3.2 소프트웨어 종류 결정
• 3.3 문제-정의 선행 조건
• 3.4 요구 사항 선행 조건
• 3.5 아키텍처 선행 조건
• 3.6 선행 조건에 소요되는 시간

3.1 선행 조건의 중요성

Q.왜 선행 조건이 중요한가?

→ 프로젝트 마지막에 테스트 만으로는 문제점을 발견할 수 없다. 이를 위해 구현 시작 전에 문제점을 발견하여 계획, 요구사항 수집 및 설계를 진행 하고, 구현 도중에도 현재 상황을 파악하여 작업을 되돌려야 하는지 여부를 결정하기 위해 선행 조건이 중요하다.

• 좋은 품질의 소프트웨어를 구축하기 위해서는 프로젝트 마지막의 테스트를 통해 품질을 결정 할 수 있다.
• 하지만 테스트 만으로는 제품이 원하는 방향 대로 만들어 졌는지 문제점을 발견할 수 없다.
• 그렇기 때문에 구현 시작 전에 문제점을 발견해야 한다.
• 이 문제점을 발견하기 위해 선행 조건이 중요
  • 고급 제품을 계획하고, 요구 사항을 수집, 설계해야 한다.
    • 문제 정의와 이에 대한 해결책 명시 그리고 해결책 설계와 이에 대한 계획 작업을 수행
• 구현 도중 현재 상황 파악
  • 작업을 되돌려야 할지 여부 등

현대적인 소프트웨어에 적용되는가?

→ 1970년대 이후 자료를 보면 선행 조건 작업 수행 시 프로젝트가 훌륭하게 진행 될 수 있음을 보여줌

• 선행 조건의 가장 큰 목표 : 위험 절감
  • 초기에 위험 요소를 제거
    • 위험요소 : 불충분한 요구사항, 잘못된 프로젝트 계획

불완전한 준비의 원인

• 개발자들이 작업 수행을 할 정도의 전문 지식을 갖고 있지 않을 때
  • 프로젝트 계획, 비즈니스 케이스, 요구사항 개발, 아키텍처를 만들기 위해 기술이 필요
• 빨리 코드를 구현하고자 할때
• 관리자들이 구현에 필요한 선행 조건 수행을 위한 시간 투자를 싫어할 때

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

• 비-기술자들에게 개발 과정에 대해 교육하는 것 또한 기술자의 일이다.

논리적 설득

• 만들고자 하는 것이 무엇인지 정확하게 이해해야한다.
  • 프로젝트 계획 수립 → 잘못된 작업으로 인한 시간 낭비를 막기 위해 필요
  • 어떻게 구축할 것인가에 대한 내용들을 미리 생각해 보는 것 또한 중요

비유적 설득

• 프로그래머는 소프트웨어 먹이 사슬의 최종 소비자
  • 아케텍트는 요구사항을 먹음
  • 디자이너는 아키텍처를 먹음
  • 코더는 다자인을 먹음
  • 각 먹이사슬의 단계가 건강하다면, 결과적으로 훌륭한 코드를 얻을 수 있음.

자료적 근거

(상사의) 준비 테스트

• 다음 문장을 목표로 해야한다.
  • 코드를 작성하고 디버깅을 수행할 때 중요한 문제점들이 발견되지 않을 만큼 요구사항과 설계에 신중을 기했다.

3.2 소프트웨어 종류 결정

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

• 반복적인 접근 방법은 선행 작업을 여러 단계에 걸쳐 확증하고 전체적인 비용을 감소시키는 역할을 한다.
• 대부분의 프로젝트는 완벽하게 순차적이지도 반복적이지도 않다.
  • 요구사항과 설계를 처음부터 100% 기술할 수 없지만, 가장 중요한 요구 사항과 설계상의 요소들은 초기에 정의하는것이 중요하다.

반복 Vs. 순차적인 방법의 선택

• 다음의 경우에 순차적 방법 선호

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

• 다음의 경우에 반복적인 접근 방법 선호

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

• 반복적인 방법이 순차적인 방법보다 훨씬 유용한 경우가 많다.

3.3 문제-정의 선행 조건

문제정의는 전체 프로그래밍 프로세스를 위한 기초공사임

• 구현에 앞서 시스템이 해결 해야하는 문제를 명확하게 기술 해야 함.

  → 문제정의 라고 함

• 문제정의

  • 문제가 무엇인지를 정의함
    • 해결책에 대해서는 언급하지 않아야함.
  • 반드시 사용자의 언어로 작성되야 함. 그리고 사용자 관점에서 정의되야 함.
  • 단, 문제가 컴퓨터와 관련된 사항인 경우, 컴퓨터 용어나 프로그래머 용어로 기술해야 하는것이 적당.

3.4 요구 사항 선행 조건

• 요구 사항
  • 소프트웨어 시스템이 무엇을 수행하는지 상세 기술하고 해결책을 구현하기 위한 첫번째 과정.
  • 요구사항 개발, 요구사항 분석, 요구사항 정의 등으로 불림

왜 공식적인 요구사항 필요한가?

• 명시적인 요구사항이 필요한 이유
  • 사용자가 시스템의 기능을 주도한다는 것을 보장함
  • 사용자가 요구사항들을 살펴볼 수 있다.
    • 그렇지 않은 경우, 프로그래머가 프로그래밍 도중 요구사항을 결정해 버리는 경우가 있음
  • 사용자가 원하는 것이 무엇인지 알 수 있음
  • 논쟁을 피할 수 있음
  • 프로그래밍 시작 전 시스템의 기능을 결정함
• 요구사항의 오류 발견 시, 변경된 요구 사항을 충족 시키기 위해 설계를 변경해야한다.
  • 때에 따라 설계의 일부를 버려야하며,
  • 요구사항 변경에 영향 받는 코드와 테스트 케이스를 버리고, 새로운 코드와 테스트 케이스를 작성해야함.

견고한 요구 사항에 대한 미신

• 프로젝트를 진행할 수록 프로젝트에 대해 더 많이 이해하게 되고, 개발과정에서 고객의 요구사항 또한 더 잘 이해하게 되어 이것이 요구 사항 변경으로 이어진다.
• 따라서 요구사항이 바뀌지 않을 것이란 믿음은 버리고, 요구사항 변경으로 부터 영향을 최소화 하기 위한 여러 조치를 취하라.

구현중에 요구 사항 변경 다루기

요구 사항 체크 리스트로 요구 사항을 평가

• 요구사항이 충분치 않다면, 작업을 멈추고 백업 후, 요구사항을 수정해야한다.

모든 사람이 요구 사항 변경 비용에 대해 알아야 함

• 일정과 비용추정을 다시해야한다는 것을 고객에게 인지 시켜야한다.

요구 사항 변경 절차 구축하기

• 변경 사항 제어를 위한 절차를 구축하여, 변경사항이 언제 처리되는지 적용되는지를 공유하라.

변경 사항들을 수용하는 개발 접근 방법을 사용

• 작은 크기를 빌드하여, 사용자로 부터 적은 수의 피드백을 받고 설계를 약간만 수정하여 변경한 다음, 약간의 변경을 거친 후 조금 더 작성해 나간다.

프로젝트를 취소한다

• 요구사항이 매우 형편없거나 변하기 쉽고, 앞에서 제안한 어떠한 사항도 충족하지 못한다면, 그 프로젝트는 취소해야한다.

프로젝트의 사업 계획을 경계

3.5 아키텍처 선행 조건

• 소프트웨어 아키텍처는 소프트웨어 설계의 상위 부분에 속하면 설계중에서 보다 상세한 부분들을 담기 위한 틀이다.
• 아키텍처는 요구사항이라기보다 구현에 가깝다.
• 왜 아키텍처가 선행조건에 포함되는가?
  • 아키텍처 품질이 시스템의 개념적인 무결성을 결정하기 때문
  • 좋은 아키텍처는 구현을 쉽게 만들고, 나쁜 아키텍처는 구현을 거의 불가능하게 한다.

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

프로그램의 구조

• 시스템을 일반적인 말로 기술하는 개요가 필요
• 최종적인 구조를 선택했을 때 생각했던 대안 자료와 다른 대안들 대신 왜 지금의 구조를 선택했는지 이유를 찾아야함.
  • 시스템에서의 클래스 역할이 명확하지 않은 것처럼 보이면 클래스를 작성할 수 없게 된다.
• 프로그램 내 중요 빌딩 블록을 정의해야 함
  • 블록 → 상위 수준의 기능들을 처리하는 클래스나 루틴의 집합
    • 하나의 클래스
    • 사용자와 상호작용
    • 비즈니스 규칙을 캡슐화
    • 데이터 접근 등
  • 각 블록이 책임져야하는 내용 반드시 명확히 정의 되어야 함

중요한 클래스들

• 중요 클래스들을 명시해야 함
  • 클래스가 맡은 부분과 다른 클래스 간 상호작용을 규명해야 함
  • 클래스 계층 구조와 상태전이
  • 객체 지속성에 대한 설명도 포함

데이터 설계

• 중요 파일과 테이블 설계를 기술해야 함.

비즈니스 규칙

• 아키텍처가 특정 비즈니스 규칙을 따른 다면, 이를 규명하고 규칮이 설계에 미친 영향을 기술 해야함

사용자 인터페이스 설계

• 사용자 인터페이스가 요구사항 작성시에 명시 되지 않았다면, 아키텍처 작성시에 명시되어야 함
  • 웹 페이지 형식
  • GUI
  • 명령줄 인터페이스 등

자원 관리

• 부족한 자원들을 관리하기 위한 계획을 기술 해야 함
  • 데이터 베이스 연결, 스레드(thread), 핸들(handle) 등

보안

• 설계 단계와 코드 단계 보안에 대한 접근 방법을 기술해야 한다.
  • 버퍼 처리 방법
  • 신뢰할 수 없는 데이터 처리 규칙
  • 암호화
  • 오류메시지에 포함될 상세함 정도
  • 메모리에 있는 중요 데이터 보호와 같은 보안 관련 사항 등

성능

• 요구 사항이 원하는 성능을 명시해야함
  • 속도, 메모리, 비용과 같은 자원들 간 우선 순위를 명시할 경우 리소스 사용도 포함

확장성

• 확장성 : 추후 요구를 충족하기 위해 확장할 수 있는 능력
  • 사용자와 서버수
  • 네트워크 노드의 수
  • 데이터베이스 레코드의 수
  • 데이터베이스 레코드의 크기
  • 트랜잭션 용량과 같은 데이터의 증가

상호 운영성

• 시스템이 다른 소프트웨어나 하드웨어, 데이터, 리소스를 공유할것이라 예상된다면, 아키텍처는 그러한 기능을 어떻게 구현할 것인지 기술

국제화와 지역화

• 특정 언어를 위한 번역 작업

입력/출력

• 입력/출력(I/O) 또한 아키텍처에서 주의해야 함
  • 선행, 후행, 저스트 인 타임, 판독 스키마를 명시해야함
  • 필드, 레코드, 스트림이나 파일 수준에서 어떤 I/O 오류가 발견되는지를 명시해야 함

오류처리

• 오류를 처리를 위한 일관된 방법이 아키텍처에 명시 되어있어야 함
  • 체크리스트
    • 오류 처리가 수정을 하는가 아니먄 단순히 검출만 하는가?
    • 오류검출이 능동적인가? 수동적인가?
    • 프로그램이 오류를 어떻게 전달하는가?
    • 오류 처리 메시지에 관한 규약이 있는가?
    • 예외가 어떻게 처리될 것인가?
    • 프로그램 내부에서, 어떤 오류가 처리될 것인가?
    • 입력 데이터를 검증하기 위해 각 클래스 수준까지 책임져야 하는가?
    • 사용자의 환경에서 기존에 제공하고 있던 오류 처리 방법을 사용할 것인가?

장애 허용성

• 예상되는 장애 허용의 종류를 지정해야한다.
  • 장애 허용
    • 오류를 검출하고 가능한 경우 오류로 부터 복구
    • 시스템에 미치는 악영향을 제거하여 시스템 신뢰도를 높임

구조적인 실행 가능성

• 시스템이 기술적으로 실행 가능함을 보여야 함
  • 특정 분야에서 실행 불가능 때문에 프로젝트 전체가 실행 불가능 하다고 판단시
    • 아키텍처는 사전 검증 프로토타이핑, 연구 등을 통해 문제점을 어떻게 조사하였는지 설명해야 함.
    • 이는 구현 작업 시작 전에 해결되어야 함.

지나친 엔지니어링

• 아키텍처는 프로그래머가 지나치게 엔지니어링을 수행 했는지, 아니면 지나치게 일을 간소화하여 잘못하고 있는지를 명확하게 지적해야 한다.
  • 요구사항에 명시된 것 이상으로 지나치게 견고한 시스템 명시한 경우
  • 소프트웨어 각 부분들 간 연결 고리 중 가장 약한 고리가 있는 경우
• 특정 클래스 만 지나치게 견고하거나 다른 클래스만 적절한 수준을 유지하는 현상을 피할 수 있다.

구입과 구현 결정

• 소프트웨어 구현시 가장 기본적인 해결책은 기존의 것을 사거나 오픈소스 소프트웨어를 다운로드하는 것이다.

재사용 결정

• 기존 소프트웨어, 테스트 케이스, 데이터 형식 등을 사용할 경우,
  • 아키텍처는 재사용된 소프트웨어가 다른 구조적 목표를 어떻게 달성할 것인지 설명해야 함.

변경 전략

• 변경 사항들을 수용할 수 있을 정도로 유연한 아키텍처를 만들어야 함
• 아키텍처는 변경 처리 전략을 명확하게 기술해야한다.
  • 여러 가능한 상황을 고려 했으며, 선택한 추가기능이 가장 구현하기 쉬울 것 같다는 점을 보여야한다.

일반적인 아키텍처 품질

• 아키텍처는 개념적으로 완전해야한다.
  • 해결책은 자연스럽고 쉬워야 함.
• 아키텍처는 중요한 모든 판단에 대한 동기를 기술해야함.
  • 항상 그래왔다는 식으로 정당화 하면 안됨.

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

• 문제 정의와 요구 사항, 소프트웨어 아키텍처에 소요되는 시간은 프로젝트 필요에 따라 변함.
• 일반적으로 요구사항과 가키텍처, 계획수립에서 전체노력의 1020% 그리고 2030% 시간을 투자함.
  • 이 수치는 상세 설계를 위한 시간은 포함하지 않음