(몰랐는데 챌린지에 나온 거랑 책 목차가 다르네요 ^^;;;;;;;;; 6장 숙제날 빼먹어서 목차가 다른걸 TIL 다 쓰고 알았어요...ㅎㅎ)
프로젝트를 시작하기 전에 기본 원칙을 정하는 것이 좋다. 요구사항을 정하거나 제약조건을 관리하고, 적당한 정도의 준비 기간을 가져야 한다. 이런 이슈를 정리해야만 성공적으로 프로젝트를 시작할 수 있다.
36. 요구사항의 구렁텅이
요구사항은 바로 보이는 것이 아니라, 가정과 오해, 정치 속에 숨어 있다. 이를 파헤치면서 진정한 요구사항을 찾아내야 한다. 요구사항은 어떤 것이 성취되어야 한다는 진술이다.
이때, 정책은 요구사항과 분리되어야 한다. 요구사항은 고정된 것이지만 정책은 수시로 변동된다. 정책을 요구사항에서 분리해서 문서화하여 정리해야 한다. 요구사항은 일반적인 진술이어야 한다. 정책은 메타데이터로 전달될 수 있다.
요구사항을 분석할 때 중요한 것은 어떤 작업을 ‘어떻게’ 하느냐가 아니라 ‘왜’ 그걸 하는지에 대한 내재적 이유를 알아내는 것이다. 이것을 알고 있으면 구현과 관련된 의사 결정을 할 때 큰 도움이 된다. 이를 알기 위해서 직접 사용자가 되어 보는 것이 도움이 된다.
알아낸 요구사항은 문서화해야 한다.
유스 케이스
유스 케이스는 시스템의 특정한 사용을 설명한다. 이때 사용자 인터페이스 관점보다는 좀 더 추상적인 관점에 집중한다.
목적 지향성 유스 케이스 템플릿
A. 특징적인 정보
- 맥락 안에서의 목표: 주행위자가 이루고자 하는 목표와 기대하는 결과
- 범위
- 수준
- 선행조건: 유스 케이스가 성공적으로 발동되기 위한 조건
- 성공적인 종료 조건
- 실패로 간주할 종료 조건
- 주행위자: 유스 케이스를 발동시키는 주체
- 발동 조건: 유스 케이스를 실행시키는 방법
B. 주된 성공 시나리오
C. 확장된 경우들: 주된 성공 시나리오의 특정 단계에서 일어날 수 있는 예외 상황
- ex) 물건을 사려고 시도했을 때, 특정 물건의 재고가 없을 수도 있다.
D. 변이된 경우들: 주된 성공 시나리오의 특정 단계를 다르게 수행할 수 있는 방법
- ex) 물건 값을 지불하기 위해서 무통장입금을 할 수도 있고, 신용카드 결제를 할 수도 있다.
E. 관련 정보
- 우선순위
- 수행 목표: 유스 케이스의 성능 등의 목표
- 빈도: 유스 케이스의 발생 기대 횟수
- 상위 유스 케이스
- 하위 유스 케이스들
- 주행위자와 상호작용하는 수단
- 부행위자들
- 부행위자들과 상호작용하는 수단
F. 일정
G. 해결되지 않은 문제
이와 같은 템플릿을 사용하면 발생 가능한 예외와 비기능적인 부분을 한 곳에 모아 관리할 수 있고, 사용자 코멘트를 기록하기에도 좋다. 상위, 하위 유스 케이스를 구분해서 계층적으로 유스 케이스를 관리할 수도 있다.
요구사항 문서
요구사항 문서가 너무 자세해서는 안 된다. 좋은 요구사항 문서는 추상적이다. 의미론적 불변식을 요구사항으로 표현하고, 구체적인 작업은 정책으로 문서화해야 한다.
프로젝트 내에서 사용되는 용어는 용어 사전에 정리한다. 사전에 정리된 용어를 사용하도록 통일하는 것이 좋다.
요구사항과 용어 사전 등에 프로젝트 구성원이 쉽게 접근할 수 있어야 한다. 그리고 유스 케이스 간의 관계를 쉽게 보이기 위해 하이퍼링크 등을 활용할 수 있으면 좋다. 따라서 요구 사항 문서는 웹에 배포해 두면 좋다.
37. 불가능한 퍼즐 풀기
퍼즐을 푸는 비법은 실제의 제약 조건을 알아내고, 그 속에서 해법을 찾는 것이다. 어떤 제약 조건은 절대적이지만, 다른 것들은 단순히 지례 짐작한 것들에 불과하다. p333
모든 선입견을 의심해보고 그것이 명백한 진짜 제약인지 가늠해 봐야 한다. p334
풀리지 않는 문제를 마주쳤다면,
- 생각해 볼 수 있는 모든 가능성을 나열한다.
- 각 가능성이 정말로 불가능한 것인지 생각해 본다.
- 가능성을 불가능하게 만드는 제약을 범주로 나누고 우선순위를 매긴다.
그럼에도 불구하고 문제를 풀 해답을 찾지 못할 수도 있다. 그럴 때는 스스로 질문해봐야 한다.
- 더 쉬운 방법은 없는가?
- 이것이 진짜 중요한 문제인가?
- 왜 이것이 문제인가?
결국 진짜 문제와 제약을 찾는 것이 가장 중요하다.
38. 준비가 되어야만
시작할 준비가 되었을 때 시작해야 한다. 개발을 해오면서 쌓은 경험과 지혜를 토대로, 어떤 작업을 하는 데 마음에 걸리는 것이 있다면 시작을 미루는 것도 좋다.
바로 프로젝트를 시작하는 것 대신에 프로토타이핑을 해보는 것이 도움이 된다. 이런 프로토타입이 시간 낭비처럼 느껴질 수도 있지만, 그렇게 느낌으로써 프로젝트를 정말로 시작할 동기를 얻을 수 있다. 혹은 프로토타이핑을 하던 도중 프로젝트의 틀린 전제를 발견해서 찜찜한 기분을 해소할 수도 있다.
단, 프로토타이핑을 시작할 때는 그 작업이 ‘프로토타입’임을 기억해야 한다. 너무 많은 시간과 노력을 쏟아서는 안된다.
39. 명세의 함정
- 명세서는 시스템의 요구사항과 세부사항을 모조리 담고 있을 수는 없다.
- 어떤 일은 설명을 하면 오히려 복잡해질 수도 있다.
- 명세에 모든 것을 (구현까지도) 작성해버리면, 코드 작성자의 해석의 자유를 뺏는다. 다른 식으로 설계해서 더 나은 성능을 보이거나 추가 기능을 넣을 가능성을 막게 된다.
과잉명세를 피하고, 적절한 명세 정도를 찾아야 한다.
40. 동그라미와 화살표
- 최종 사용자는 대부분 다이어그램을 이해하지 못한다. 차라리 프로토타입을 써보게 해주는 게 낫다.
- 다이어그램은 보통 동적이기 보다는 정적이다. 그러나 우리는 메타데이터를 이용한 동적인 시스템을 구현하고자 하기 때문에 시스템을 나타내기에 다이어그램 방식이 적합하지 않을 가능성이 높다.
실용주의 프로그래머들은 방법론을 비판적인 시각으로 바라본 다음, 각각의 방법론에서 가장 좋은 것만 뽑아 매달 점점 좋아지는 자신의 작업 실천방법의 집합 속에 녹여 넣는다. (…) 여러분은 자신의 공정을 개선하고 다듬기 위해 끊임없이 노력해야 한다. p349
어떤 도구의 결과물을 볼 때 비용이 얼마나 들었을지 생각하지 않도록 노력해라. p349
예전엔 다이어그램 그리는 법을 외워서라도 익혀야 하지 않을까 생각했는데 (하지만 안 외웠다) 지금 생각해 보면 다이어그램을 그리는 방법을 아는 것이 의미가 있는 것은 아닌 것 같다. 진짜로 의미가 있는 것은 어떤 상황에 어떤 다이어그램을 통해 표현하면 보여주고자 하는 내용을 잘 정리해서 표현할 수 있는가를 아는 것이다.
