개발을 시작하기 전에

우리는 새로운 제품이나 시스템을 개발해야 할 때 아래 순서대로 개발을 진행하게 됩니다.

분석-설계-구현-실험-배포

개발하고자 하는 것이 단순하다면 이 과정들을 한 번만 거쳐도 되겠지만, 시스템이 복잡한 경우 개발 주기를 몇 회 반복하기도 합니다.

[출처](http://users.ece.utexas.edu/~valvano/Volume1/E-Book/C7_DesignDevelopment.htm/)

분석 단계

분석 단계에서는 아래와 같은 일을 해야 합니다.

• 요구사항 발견하기
  • 요구사항은 시스템이 반드시 갖춰야 할 것들 의미합니다.
  • 제품이 필요한 이유와 어떤 일을 하기를 바라는지가 이 과정에서 드러나게 됩니다.
• 제약사항 발견하기
  • 시스템을 구성하는 과정에서 예상할 수 있는 한계점들을 나열합니다.
  • 어떤 요소의 성능을 높이면 그에 따라서 다른 요소의 성능이 낮아지는 것
• 컨설턴트를 구하거나 잠재 고객과 인터뷰를 통해서 정보 모으기
  • 정말 필요하고 성공할 수 밖에 없다고 생각한 제품이 실제 사용자에게는 별 다른 감흥이 없을 수 있습니다.
  • 개발하고자 하는 제품이 정말로 필요한 것인지, 놓치고 있는 것은 없는지 확인하는 과정입니다.
• 명세서 작성하기
  • 명세서는 시스템이 어떤 식으로 동작하는지 적어놓은 것입니다.
  • 크기, 무게, 반응 시간, 동작 시간 등 분명하게 나타낼 수 있는 것들을 나열합니다.

다음 요소들은 분석 단계에서 결정되는 것들 입니다.

• 안전
• 정확도
• 정밀도
• 분해도
• 응답 시간
• 속도
• 유지보수 가능성
• 검사 가능성: 어떻게 검증할 수 있는지
• 호환성: 현존하는 표준 장치들과 사용 가능성
• 수명
• 크기와 무게
• 소비전력
• 단가
• 프로토타입 제작 일정
• 출시 일정
• 인적 요소: 고객이 제품을 좋아하거나 평가하는 정도

요구사항 명세서는 만들고자 하는 시스템이 무엇을 하게될 지를 적어놓은 문서입니다. 이 문서는 시스템이 어떻게 동작하는지를 설명하는 것이 아닙니다. 요구사항 명세서의 주 목적은 개발자와 클라이언트 사이에서 시스템이 어떤 일을 하게될 것인지 협의하기 위한 것입니다. 이 문서는 법률적인 계약서가 될 수도 있습니다. 따라서 이 문서는 다른 사람이 잘 이해할 수 있도록 쉽게 쓰여져야 합니다.

다음은 IEEE에서 배포하는 요구사항 명세서 표준 문서의 목차입니다.

1. Overview
   1.1. Objectives: Why are we doing this project? What is the purpose?
   1.2. Process: How will the project be developed?
   1.3. Roles and Responsibilities: Who will do what? Who are the clients?
   1.4. Interactions with Existing Systems: How will it fit in?
   1.5. Terminology: Define terms used in the document.
   1.6. Security: How will intellectual property be managed?
2. Function Description
   2.1. Functionality: What will the system do precisely?
   2.2. Scope: List the phases and what will be delivered in each phase.
   2.3. Prototypes: How will intermediate progress be demonstrated?
   2.4. Performance: Define the measures and describe how they will be determined.
   2.5. Usability: Describe the interfaces. Be quantitative if possible.
   2.6. Safety: Explain any safety requirements and how they will be measured.
3. Deliverables
   3.1. Reports: How will the system be described?
   3.2. Audits: How will the clients evaluate progress?
   3.3. Outcomes: What are the deliverables? How do we know when it is done?

짧은 경력이지만 회사에서 개발을 하다보면 이 분석 단계에서 충분한 시간을 갖지 못한 것이 아쉬울 때가 많습니다. 개발이 중반을 넘긴 시점에서 계획에 없던 새로운 기능을 추가되는 일은 다반사이고, 공들였던 것이 나중에 가서는 아무런 쓸모가 없어지는 경우도 있었습니다. 만약 충분히 계획을 세웠더라면 시간과 에너지를 낭비하는 일이 현저히 줄어들었을 것이라 생각합니다. 시간이 없다고 곧바로 구현을 시작하다가는 오히려 개발 기간을 늘어날 위험이 커질 수 있음을 기억해야겠습니다.