디자인 4 - 결정에 대한 비교

나름대로 생각해왔다는 디자인이 많이 수정되었다.

Top-down으로 내려보면서, 이슈가 되는 것들을 모아놓고, 그 역할에 해당하는 모듈을 결정하는 방법을 택했다.
하지만, 선임자로부터 다시 한번 생각하여, Bottom-up으로 올라가서 보라는 말에 다시 한번 생각하게 되었다.
빠지는 부분들을 발견하게 되었고, 작은 단위의 모듈을 묶어놓고, 작은 모듈을 다시 상위 모듈로 묶어 보니, Top-down 방법으로 보이지 못했던 일부 기능 및 이슈가 좀더 확실히 지는 것을 발견하였다.

또한 이슈를 제기하여 이슈에 대한 모듈 및 기능을 정하였다.

이런 작업중에 중요한 것들을 발견하였는데, 바로 "Constraint", 제약조건이다. 즉 이는 규격에 맞는 것, 혹은 요구사항 분석시 반드시 염두해야 하는 것으로 말할 수 있는데, 이 부분들을 계속 발견이 되었다. 미처 발견되지 못해서 구현상에서 문제가 될 수 있는 부분들이었다.

그렇다면 어떤 부분을 잘 염두를 해야하는 것일까??

2005년 3/4월 IEEE Software의 "아키텍처의 미스터리를 푼다"에서는 다음의 내용을 염두해야 한다고 하였다.

Issue, Decision, Status, Group, Assumptions, Constraints, Positions, Argument, Implications, Related decisions, Related requirements, Related principles, Notes 등을 요소로 뽑았다.
(개인적으로 중요하다라고 하는 것은 Bold체로 강조를 했다.)

설계를 할 때, 다양한 Approach들을 제시할 수 있는데 이를 테이블을 이용하여 주어진 Approach들에 대해서 여러가지의 문제 해결 능력에 대해서 구현할 수 있는지를 yes/no로 구분하여 제시하였다. 이렇게 함으로서, 문서화 및 결정단계에서의 근거를 마련하였고, 무엇이 가장 최선에 가까운 구현인지를 찾는 것인지를 알리고 있다.

또한, 상기 주어진 요소들에 대해서 가장 최선에 가까운 구현 시스템에 대해서 해당사항에 맞춰 그 내용을 기입하여 문서화, 분석화, 결정을 적도록 하였다. 그래서 구현할 때 요구사항 및 참조사항으로 하여 아키텍쳐의 기반 내용으로 삼을 수 있도록 하였다.

해당 Article의 내용을 디딤돌로 삼아 분석한 내용을 기반으로 하는 문서화를 통해서, 문제점을 일찍 파악하고 그 문제를 해결할 수 있는 것이 중요하는 것을 깨달았다.

잘 써먹어야지.