설계와 소프트웨어 품질

McGlaughlin[MCG91]은 좋은 설계를 위하여 다음과 같은 지침들 제안했다.

• 분석 모델에 포함된 요구사항을 포함해야 하며, 고객이 기대하는 암시적 요구사항도 수용하여야 한다.

  고객의 암시적 요구사항을 소프트웨어적으로 풀어낼 수 있느냐가 실력의 관건이 아닐까?

• 코딩하거나 시험하는 사람이 쉽게 읽고 이해할 수 있어야 한다.

  개념적, 논리적 구조뿐만이 아니라 pseudocode 를 통해 코딩을 아는 사람이면 이해할 수 있도록 설계되어야 함을 의미

• 구현관점에서 자료, 기능, 행위 영역들을 모두 설명하여야 한다.

좋은 설계의 기술적 기준의 안내지침

1. 설계는 소프트웨어의 구조를 나타내야 한다. 구조는 (1) 설계 패턴을 이용해야 하며 (2) 좋은 설계 특성을 가진 컴포넌트로 구성되어야 하며 (3) 변경될 수 있는 방법으로 구현되어야 한다.

   패턴화하여 누가 보더라도 소프트웨어의 구조를 빠르게 이해할 수 있는 방법으로 설계되어야 한다. 패턴이란 말 그대로 주요한 특성을 담을 수 있는 그릇이 있고 그 그릇 안에서 작성되어야 빠르게 보완/발전이 가능할 것이다.

2. 설계는 모듈 구조를 가져야 한다 : 소프트웨어는 특정 기능을 수행하는 논리적인 요소들로 분리되어야 한다.

   설계에 있어서 논리적인 기능으로 분리하는 것은 굉장히 중요하다. 천리길도 한걸음부터라고 큰 방향과 목적을 가지고 그것을 만들기 위해서 하나 하나 뭐가 있어야 하는지 개발자 입장에서 생각해보고 그런 기능들이 진짜 필요한지, 어떤 아이디어를 통해 구조를 변화/효율화 시킬 수 있을지 생각해야 한다. 또한, 만들고 나서는 사용자 입장에서 무슨 기능이 더 있어야 할지 생각해보는 습관이 필요하다.

3. 설계는 자료, 구조, 인터페이스, 컴포넌트 등을 표현할 수 있어야 한다.

4. 설계는 객체의 구현과 설계 패턴에 적합한 자료 구조를 가져야 한다.

5. 설계는 독립적 기능 특성을 가진 컴포넌트로 구성되어야 한다.

   독립적 기능으로 분리시키는 것은 소프트웨어의 복잡성을 줄이고, 빠르게 디버깅, 발전 시킬 수 있는 가장 기초적인 행위라고 할 수 있다. MECE : Mutually Exclusive Collectively Exhaustive를 잊지말자

6. 설계는 모듈간과 외부개체간의 연결 복잡성을 줄이는 인터페이스를 가져야 한다.

   인터페이스 설계 시 모듈 간, 외부개체 간 엉키게 되면 아무도 손댈 수 없는 나만의 혼종소프트웨어..가 되버리는 대참사가 발생할 수 있다.

7. 설계는 요구사항 분석에서 얻어진 정보를 반복적 방법으로 유도할 수 있어야 한다.