[Code Complete] CH3: Measure Twice, Cut Once: Upstream Prerequisites(2)

3. Problem-Definition Prerequisite

 이 장은 프로젝트 수행에서 가장 선행되는, Problem-Definition에 대해 서술한다. 이 책이 Construction이기 때문에 어떻게 definition 할지보다는, Problem-definiton의 중요성에 대해 설명한다. problem definition은 우리가 지향해야 할 목표를 제시하고, 이는 programming process의 가장 기저(foundation)에 해당한다.

무엇보다 problem definition에서 명심할 점은, 문제점을 기술적으로 접근하는 게 아니라, 이 기술을 사용할 사용자들의 관점에서 서술하는 것이다. 즉 간단히, 기획을 잘 해야한다는 것이다. "어떤 불편함" 때문에 이 기술을 개발해야 하고, 이 기술이 개발되었을 때 "누구"에게 좋은 영향을 주고 기꺼이 소비하려고 할 것인지를 스스로에게 물어봐야 한다. 이 단계가 제대로 이루어지지 않는다면 "잘못된 문제"를 해결하는 것이므로 다시 되돌리려면 처음부터 다시해야한다.

과녁(problem)을 제대로 보고 쏴야 한다.

 

4. Requirements Prerequisite

 Requirements란 SW 개발에 필요한 detail들을 의미한다. 예를 들자면, "requirements analysis", "software requirements", "specification" 등이 있다. 프로그래머들에게는 익숙한 단어들이다. 즉, 이 단계는 유저들이 아니라 프로그래머들이 향후 프로젝트 진행에 차질이 없도록 적절한 환경구성을 해주는 것이다. 만약 이 단계가 미비하다면, 개발(development)이 시작되고 시스템을 바꿔야 하는 무지막지한 cost가 발생할 수 있으므로 주의해야 한다.

프로그래머들에게 환경에 맞는 무기(requirements)를 주지 않았을 때 발생하는 일

 

 -Stable Requirements는 가능한가?

 SW개발에 있어 stable requirements는 꿈의 환경이다. stable requirements가 조성된다면 모든 절차가 예측 가능하고 트러블 없이 진행될 수 있는 이상적인 requirements 구조에 해당한다. 그러나, 대부분의 프로젝트에서는 읽어나기 어렵다. 왜냐하면, customer들은 개발에 대해서 모르기 때문이다. customer가 계획서를 완벽히 이해하고 본인의 환경에 맞게 수정을해서 stable requirements가 되면 좋겠지만, 개발 내용을 이해할 수 없는 경우가 대다수이기 때문에 보통의 프로젝트는 requirements의 프로젝트를 진행시키면서 수정을 iterative하게 해야 한다.

 

-Handling Requirements Changes During Construction

 앞서 설명했듯, construction 도중에 requirements를 바꿔야 하는 상황은 반드시 온다. 그러면 어떻게 이를 준비해야할까? 저자는 다음과 같이 설명한다.

• Use the requirements checklist at the end of the section to assess the quality of your requirements.
• Make sure everyone knows the cost of requirements changes(특히, client들에게)
• Set up a change-control procedure
• Use the development approaches that accomodate changes 
• Dump the project - 때로는 프로젝트를 취소하는 것도 방법이다.
• Keep your eye on the business case for the project - 반대로 programmer들도 이것이 적용될 business에 대해 이해한다면 requirements 설정에 더 도움이 된다.

Checklist는 다음과 같다.

 

 

5. Architecture Prerequisite

 이제 high-level에서의 software architecture를 설계할 것이다. 이는 top-level design과 같은 단어이다. high-level design은 전체 시스템을 상세히 기술하기보다는, 핵심 로직을 중심으로 subsystem이나 multiple-class level을 기술해서 전체적인 view를 제공한다.

 

 왜 Architecture도 Prerequisite일까? 왜냐하면, 아키텍처는 시스템에서 conceptual integrity를 이루기 때문이다. 따라서, 전체적이고, 궁극적인 성능을 아키텍처가 결정한다. 아키텍처를 통해 top-level에서 bottom까지 시스템 통합을 이룰수 있고, 프로그래머들이 어떻게 구체적인 설계를 해야 할지를 제시하기 때문에 construction을 쉽고, 오류 없이 만들 수 있다.

 

 

 아키텍처를 변경하는 것은 코드 일부를 변경하는것처럼 쉬운 일이 아니다. 아주 많은 비용이 발생한다. 아키텍처를 변경한다는 것은 그 세부적인 detail을 다시 조정해서 아키텍처에 맞춰야 하기 때문에, 가능한 한 프로젝트의 초반부에 아키텍처의 변경이 이루어져야 한다. 아키텍처의 "중요한" 구성 요소들은 다음과 같다.

 

• Program Organization : 전체 시스템의 overview에 해당한다. 퍼즐을 만드는 것에서 시작하자면, 퍼즐이 직사각형 형태인지, 동그라미 형태인지를 정하고(overview), 해당하는 퍼즐의 갯수(block)를 구체적으로 정하는 것에서 시작한다. 그래야 세부적인 퍼즐의 형태나 그림들을 조정할 수 있기 때문이다. 즉 각각의 퍼즐들은 subsystem에 해당한다. 그리고 block 간의 통신을 어떻게 할 지도 생각해 놔야 한다. 그림으로 생각하면 Block Diagram에 해당한다.

Block Diagram(simple computer)

• Major Classes: architecture에서 사용되는 major class에 대해서 정의를 하고, 다른 class끼리의 interact 방식을 기술해야 한다. hierarchy라던가, state transition 등을 표현해서 class끼리 어떤 역할과 행동을 하는지를 정해두어야 한다.
• Data Design: major file과 table design에 대해서 표현해 놔야 하고, 이 데이터들이 어느 block, class에서 접근할 수 있는지, 또한 database를 어떻게 구성해서 데이터 처리를 할지 등을 생각해야 한다.
• Business Rules:
• User Interface Design
• Resource Management: database, thread에서 리소스 활용 계획을 잡아야 한다. 특히 memory-constrained application의 경우나 embedded device의 경우에서 극한의 상황을 설정하고, 리소스가 잘 처리되도록 디자인해야한다.
• Security
• Performance
• Scability: 서비스를 유저들이 얼마나 이용할지, 그에 따라서 computation과 memory bound를 다시 고려해봐야 한다.
• Interoperability: 다른 소프트웨어와 하드웨어끼리 데이터, 리소스를 주고받는 과정을 고민해야한다.
• Internationalization/Localization: 다양한 프롬프트, 메시지 등에서 통신이 가능해야한다.
• Input/Output
• Error Processing
• Fault Tolerance: error를 detect하고, 가능하면 recover할 수 있는 아키텍처를 구상해야한다.
• Architectural Feasibility: 기술적으로 가능한가?
• Overengineering
• Buy-vs.-Build Decisions: software를 살 것인가? 오픈소스를 활용할 것인가?

6. Amount of Time to Spend on Upstream Prerequisites

 그러면 problem definition, requirements, sw architecture 구성에 얼마나 시간을 사용해야 할까? 일반적으로, 잘 구성된 프로젝트에서는 10~30%의 시간을 투자한다고 한다. 만약 프로젝트가 unstable하고, 너무 크다면 requirements가 수시로 바뀌므로, requirements analyst와 함께 construction 과정에서 발생하는 problem들을 해결해야 한다. 그러나 대기업에 근무하지 않는다면, programmer들이 상황에 맞춰서 requirements를 수정해야 하고, 많은 비용이 발생할 것이다.

 

 이러한 상황을 방지하기 위해서는, client들에게 SW design에 대해서 이해할 수 있도록 설명하는 능력이 중요하고, 무엇보다 더 좋은 requirements, architecture를 설계하는 시간을 아끼지 말라고 조언한다.