7장 : 프로젝트 전에
- 프로젝트 시작시 요구사항
- 상식적인 지혜와 제약조건 관리
- 너무 일찍 시작하는 것은 문제
- 형식적 개발 프로세스와 방법론
- 요구사항 채굴하기
- 대게 요구사항은 분명하게 주어지지 않으므로, 요구사항 분석이 복잡해진다.
- 요구사항, 정책, 구현 간의 구분에 사용자 인터페이스를 논할 때 더 모호해진다.
- 사용자가 왜 그걸 하는지 내제적 이유를 알아내는게 중요하다.
- 사용자가 직접 되어 보는 방법으로 사용자의 요구사항 내면 깊이 파악해 볼 수 있다
- 요구사항 문서화
- 유스 케이스 : 시스템의 특정한 사용을 설명
- 때로는 인터페이스가 바로 시스템이다
- 목적 지향성을 강조하기 위해 계층적으로 구조화
- 유스 케이스 다이어그램
- 지나치게 자세한 명세 : 요구사항은 필요 그 자체이다.
- 더 멀리 보기 : Y2K 문제는 프로그래머가 아니라 시스템분석/설계자의 문제로 봐야 한다.
- 사용하는 서비스에 대한 적극적인 추상화로 다양한 형태로 사용될 수 있도록 하는 요구사항
- 요구사항 증가 관리로 정확하고 완전한 그림을 갖고 있는것이 도움이 된다.
- 용어사전 유지 : 프로젝트 사용 용어와 어휘를 모아 놓고 모든 사람이 일관성 있는 용어 어휘 사용
- 요구사항을 문서나 원하는 형식으로 표현할 수 있게 해줘야 한다.
- 프로젝트 진행에 어려운 부분이 생기면, 실제의 제약 조건을 알아내고 그 속에서 찾는다.
- 그럴싸해 보이는 제약 조건들이 사실은 실질적 제약 조건이 전혀 아닐수도 있다.
- 풀리지 않는 문제가 생긴다면, 생각해 볼수 있는 모든 가능한 해결 경로를 눈앞에 나열해보라.
- 제약들을 범주별로 나누고 우선순위를 매겨라.
- 더 쉬운 방법이 존재하는가?
- 문제를 풀려고 노력하고 있나?
-왜 이것이 문제인가?
- 문제를 풀기 어렵게 만드는 것은 무엇인가?
- 반드시 이 방법으로 해야 되는가?
- 반드시 해야 하는 일이긴 한가?
38) 준비가 되어야만
- 처음 시작하는 일이 두렵고 미루기 쉽다.
- 이럴때 프로토타이핑을 시작하는 것이 좋다.
- 프로토타이핑을 할때 그 목적을 기억하면서 수행해야 한다.
39) 명세의 함정
- 프로그램 명세화 : 요구사항을 자기 기술 작업을 시작할수 있도록 정리하는 과정
- 명세화에 얽매였을때 문제가 발생한다.
- 명세서가 시스템의 요구사항의 모든 세부사항을 찾을수 있다고 생각하는 문제
- 언어 자체의 표현 능력에도 문제
- 고립되어 진행되는 환경을 믿지 말라.
40) 동그라미와 화살표
- 구조적 프로그래밍만이 가장 오래 남은 개발 방법이다.
- 맹목적인 개발 방법에 얽매이지 말자.
- 형식적 방법의 단점
- 실제 시스템의 사용자들이 형식적 확인을 통해 요구사항을 점검하지 못한다.
- 형식적 방법들은 전문화를 권장하는 것처럼 보인다.
- 실행중에 동적으로 연결해야 할 객체들 사이에 정적인 관계를 설정하면서 문제가 발생한다.