구현에 들어가기 앞서 완료해야 하는 선행 조건

1. 문제 정의

시스템이 해결해야 하는 문제를 명확하게 기술하기.

해결책에 대해서는 언급하지 않고 문제가 무엇인지를 정의한다. 한 두 장 분량의 간단한 문서이며 반드시 문제점에 대해서 언급해야 한다.

좋은 예시 - 생산량을 기가트론의 주문 수량에 맞출 수 없다.

나쁜 예시 - 기가트론의 주문 수량에 맞추기 위해 자동화된 데이터 입력 시스템을 최적화 해야한다.

 

2. 요구사항

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

요구사항 개발, 요구사항 분석, 분석, 요구사항 정의, 소프트웨어 요구사항, 명세화, 기능명세, 명세라고 한다.

요구사항은 명시적이어야 한다. 명시적 요구사항은 사용자가 원하는 것이 무엇인지 알 수 있게 해주며, 논쟁을 피하게 해준다. 또한 개발을 시작한 후 변경 사항을 최소화하는데 도움을 준다.

요구사항을 제대로 명시하는 것은 프로젝트 성공에 있어 효과적인 구현 기술보다 더 중요하다.

요구사항이 견고하면 아키텍처부터 설계, 코드 작성, 테스트까지 순서에 따라 예상한대로 차분하게 프로젝트를 진행할 수 있다. 

프로젝트가 진행되면서 프로젝트에 더 많이 이해하듯, 고객도 마찬가지로 프로젝트가 진행될수록 요구사항에 대해 더 잘 이해하게 된다. 그래서 개발과정에서 요구사항의 변경이 일어나기도 한다. 그렇기에 엄격하개ㅔ 요구사항을 따른다는 계획은 사실 고객의 요구에 대응하지 않는다는 계획이다.

구현 중 발생하는 요구사항의 변경을 잘 다루기 위한 방법은 다음과 같다.

- 요구사항이 충분하지 않다면 작업을 멈추고 백업한 다음 요구사항을 제대로 수정한 후 일을 진행한다. 이 단계에서 코드 작성을 중단하면 뒤처지는 듯한 느낌을 받을 수 있지만 잘못된 방향으로 가는것 보다 일단 멈추고 앞으로 나아갈 방향을 확인하는게 더 결과적으로 좋다.

- 모든 사람이 요구사항 변경 비용에 대해서 알게 한다. 종종 고객은 요구사항 문서에 대해 이야기 나눴던 회의는 전부 잊어버린 채 새로운 기능을 요구하기도 한다. 이럴땐 이 기능을 추가함으로써 생기는 추가"일정" 혹은 추가"비용"에 대해 알게해주면 된다. 그러면 반드시 구현해야 한다라고 했던 기능은 이내 구현했으면 좋겠다라는 말로 바뀐다. 또한 현재 속한 조직에게 요구사항 단계에서 변경하는 것이 나중에 변경하는 것보다 훨씬 비용이 적게 든다는 점을 강조하라.

- 요구사항 변경 절차를 구축한다. 고객이 계속 새로운 기능을 넣고 싶어 한다면 고객이 제안한 변경 사항을 검토할 수 있는 형식적인 변경 관리 위원회를 만들어 보는 것을 고려해 본다.

- 변경 사항들을 수용하는 개발 접근 방법을 사용한다.진화적 프로토타이핑 접근 방법을 사용하면 기능을 구현할 인력을 투입하기 전에 시스템의 요구사항을 살펴볼 수 있다. 진화적 출시는 시스템을 단계별로 출시하는 접근 방법이다. 작게 구축하여 사용자로부터 약간의 피드백을 받고 설계를 약간만 수정한 다음, 약간의 변경을 거친 후에 조금 더 만들어 나간다. 핵심은 사용자에게 빠르게 응답할 수 있도록 개발 주기를 짧게 가져가는 것이다.

- 프로젝트를 취소한다. 요구사항이 매우 형편없거나 변하기 쉽고 앞에서 제안한 어떤 사항도 사용할 수 없다면 그 프로젝트는 취소해야 한다. 

- 프로젝트의 사업성을 주시한다. 좋은 생각으로 보였던 요구사항도 "기능"으로서 "점진적인 사업 가치"를 평가해 보면 터무니없는 아이디어로 보일 수 있다. 자신이 내린 결정이 사업에 미치는 영향을 고민하는 개발자라면 전문가에게 자문을 구할 것이다.

 

3. 아키텍처

아키텍처는 시스템 품질을 결정. "시스템 아키텍처", "상위 수준 설계", "최상위 설계"라고도 불린다. 다음은 어떤 상황에도 고려해야 하는 아키텍처의 구성 요소다.

- 프로그램 구조 : 프로그램 내의 중요한 빌딩 블록을 정의한다. 빌딩 블록에 적어도 요구사항에서 명시한 기능이 하나는 들어가 있어야 한다. 각 빌딩 블록이 책임져야 하는 내용은 반드시 명확하게 정의햐야 한다. 한 빌딩 블록은 반드시 한 분야를 책임져야 하며 다른 빌딩 블록에 대해서는 가능한 조금 알아야 한다.

- 주요 클래스 : 주요 클래스 명시(시스템 기능의 80%를 담당하는 20% 정도의 클래스만  명시) 각각의 중요한 클래스가 맡은 역할과 클래스 사이의 상호작용 규명. 클래스 계층 구조와 상태 전이, 객체 지속성에 대한 설명도 포함. 시스템이 꽤 크다면 클래스들의 서브시스템에 대해서도 기술해야함.

- 데이터 설계 : 중요한  파일과 테이블 설계를 기술

- 비즈니스 규칙 : 특정 비즈니스 규칙을 따른다면 반드시 이를 규명하고 그러한 규칙들이 시스템 설계에 미친 영향을 기술해야 한다.

- 사용자 인터페이스 설계 : 관련책 한권 사서 보는게 좋음

- 자원관리 : 데이터베이스 연결, 스레드(thread), 핸들(handle)과 같이 부족한 자원을 관리하기 위한 계획을 기술해야 한다.

- 보안 : 보안에 대한 접근 방법을 기술, 버피 처리 방법, 신뢰할 수 없는 데이터(사용자, 쿠키, 화나경 설정 데이터, 외부 인터페이스로 부터의 데이터 입력) 처리 규칙, 암호화, 오류 메시지에 포함될 내용의 상세험 정도, 메모리에 있는 중요 데이터 포호와 같은 보안 관련 사항을 염두해두고 작성

- 성능 : 성능을 염두한다면 요구사항에 원하는 성능을 명시해야 한다.

- 확장성 : 추후의 요구를 충족시키기 위해 시스템이 확장할 수 있는 능력. 사용자 수와 서버 수, 네트워크 노드 수, 데이터베이스 레코드의 수, 데이터베이스 레코드 크기, 트랜잭션 용량 등의 증가를 어떻게 처리할 것인지를 기술해야 한다.

- 상호운용성 : 다른 소프트웨어나 하드웨어와 함께 데이터나 자원을 공유할 거라고 예상된다면 아키텍처는 그러한 기능을 어떻게 구현할 것인지를 기술해야 한다.

- 국제화와 지역화 : 특정 언어를 지원하기 위한 번역 작업을 고려해야 한다.

- 입력/출력 : 입력 체계가 선행인지 후행인지, 아니면 상황에 따라 선택되는지 명시해야 함. 필드나 레코드, 스트림, 파일 수준에서 어떤 입출력 오류가 검출되는지 명시.

- 오류 처리 : 오류를 처리하기 위한 일관된 방법이 아키텍처에 명시되어 있어야 한다.

- 장애 허용 : 예상되는 장애 허용의 종류를 지정해야 한다.

- 구조적인 실행 가능성 : 시스템이 기술적으로 실행 가능함을 보여줘야 한다. 기술 검증 프로토타입이나 조사, 기타 다른 방법을 통해서 그러한 문제점을 어떻게 조사했는지 설명해야 한다.

- 과도한 엔지니어링 : 개발자가 지나치게 엔지니어링을 수행하는지, 아니면 지나치게 일을 간소화 하는 것인지를 명확하게 지적해야 함.

- 구입과 구현 결정 : 시장에서 판매하는 컴포넌트를 적절하게 사용해야 한다.

- 재사용 결정 : 기존 소프트웨어나 테스트 케이스, 데이터 형식, 다른 요소들을 사용할 계획이라면 아키텍처는 재사용된 소프트웨어가 다른 아키텍처 목표에 어떻게 부합할 것인지를 설명해야 한다.

- 변경 전략 : 소프트웨어 제품을 만드는 일은 개발자와 사용자 모두가 배우는 과저잉기 때문에 제품은 개발 내내 변경될 수 있다. 아키텍처는 변경 사항을 수용할 수 있을 정도로 유연한 아키텍처를 만드는 것이다.