생각하며, 꾸준하게

앞서 과정까지 우리는 분석을 위해 requirements를 기반으로 여러 Analysis 모델을 iterative/incremental하게 만들었다. 분석에서 business needs를 정했다면, 디자인에선 어떻게 system을 만들지에 집중한다. 분석 과정을 통해 우리가 만들/보완할 system이 어떤 기능을 어떤 흐름으로 해야하는지, 내부구조가 어떻게 되는지, 각 class/object들이 어떻게 상호작용하는지를 알았다면,, 이제는 구현으로 넘어갈 수 있도록 Analysis 모델을 Design 모델로 발전시켜나가야한다. (특히 Class D를...) 이 글에선 그런 Design 과정의 전체적인 흐름을 보도록 하겠다. Design 과정의 특징은 다음과 같다. 1. 구현을 위한 청사진을 제공한다. 2...

(설계과목이니 planning을 주로 다루는 chapter 2는 건너뛰겠다고 하심) SDLC 중 Analysis 단계에 해당한다. 용어 as-is system == current system to-be system == new system Requirement Determination Requirement : system이 해야하거나 가져야하는 특성을 문장으로 기술한 것으로, 나중엔 어떻게 구현될지 technical description으로 자세하게 바뀌어야한다. Requirement는 use-case를 파악하는 것은 물론, 이후 다양한 분석 과정에서 기반이 되는 자료이다. 아래 설명하는 다양한 방식으로 Requirements를 최대한 많이 자세하게 수집하고, 나머지 analysis 과정은 모두 이 re..

과거 프로그래머들은 큰 계획없이 바로바로 프로젝트에 착수했다. 그만큼 규모도 작았고, 필요성을 크게 못느끼던 시기였다. 지금은 규모가 매우 크니 구현전 설계는 필수이다. 그리고 설계를 하더라도 (책의 자료에 의하면) 1996년 조사에서 53퍼센트의 IS project가 완성전에 버려졌다. 완성되더라도 계획보다 비용이 커지거나 시간이 길어지거나 구현이 덜 되었을 수 있다. 등등등... 즉, 지금은 제대로 설계를 해도 모자랄판이다. system analyst는 이런 프로그램 설계를 총괄하기도하지만, 그 외적인 요소도 신경쓰는 사람이다. 고객과 제대로 의사소통해 원하는 것을 파악해야하고, 시스템 설계도 당연히 잘 해야하며, 무엇보다 본인이 속한 조직에 가치있는 것을 만들어야한다. 여기서 가치있는 것이란, 사기..