[Code Complete 2] 프로젝트 절차 (architecture 설계에서 할일)

프로젝트의 절차 

1. 문제 정의

    - 해결책에 대해서는 언급하지 않고 문제가 문엇인지 정의한다. 

    - 사용자의 언어로 작성 한다. 

2. 요구 사항

    -  소프트웨어 시스템이 무엇을 수행해야 하는지에 대해서 상세하게 기술한다. 

    - 해결책을 구현하기위한 첫 번째 과정 이다. 

    - 명시적 요구사항의 필요성. 

        - 사용자가 시스템의 기능을 주도하게 하는데 도움이 된다.

        - 요구사항을 명시적으로 정의함으로써 사용자가 원하는 것이 무엇인지를 알 수 있다. 

3. 아키텍쳐

    - 시스템 전반에 적용되는 설계상의 제약 사항을 명시한다. 

    - 모든 설계에는 타당한 이유가 있어야 한다.

    - 모든 주요 결정사항에 대한 동기를 기술 해야한다. 

    - 아키텍쳐에서 해야 할 일

        1) 프로그램 구조 설계

            - 프로그램 내의 중요한 빌딩 블록 을 정의 해야한다

        2) 주요 클래스 설계 

            - 각각의 중요한 Class 맡은 역활과 Class사이의 상호작용을 어떻게 할 것 인지를 규명해야 한다. 

            - 모든 Class를 정의할 필요는 없다. 시스템 기능의 80%를 담당하는 20%정도의 클래스만 명시한다.

        3) 데이터 설계 

            - 중요한 파일과 테이블 설계를 기술 해야한다. 

            - 데이터는 일반적으로 하나의 서브시스템이 나 클래스에서만 직접 적근해야 한다.

            - 모든 데이터베이스의 고수준 구조와 내용에 대해서 명시해야 한다. 

        4) 비즈니스 규칙 

            - 특정한 비즈니스 규칙을 따른 다면 반드시 이를 규명하고 그러한 규칙들이 시스템 설계에 미친 영향을 기술
              해야한다. 

        5) 사용자 인터페이스 설계 

            - 웹 페이지 형식, GUI, Command Line Interface 등 주요 요소를 명시해야 한다. 

            - 인테페이스는 상호간 대체가 쉽게 설계 되어야 한다. (GUI <-> CLI)

        6) 자원관리 

            - 데이터 베이스 연결과 Thread, Handle과 같이 부족한 자원을 관리하기 위한 계획을 기술 해야한다. 

        7) 보안

            - 설계 단계와 코드 단계의 보안에 대한 접근 방법을 기술 해야한다.

        8) 성능

            - 원하는 성능을 명시해야 한다. 

            - 추정치를 제공해야하며 설계자가 그러한 목표에 도달 할 수 있다고 믿는 이유를 설명해야한다.

        9) 확장성

            - 추후의 요구를 충족시키기 위해 시스템이 확장할 수 있는 능력이다. 

       10) 상호운용성

            - 시스템이 다른 소프트웨어나 하드웨어와 함께 데이터나 자원을 공유할 거라고 예상된다면 아키텍처는
              그러한 기능을 어떻게 구현 할 것인지 명시 해야 한다. 

       11) 국제화와 지역화 

            - 프로그램이 여러 나라를 지원하기위한 기술적인 준비 작업

       12) 입력/출력

            - 아키텍처는 입력 체계가 선행인지 후행인지, 아니면 상황에 따라서 선택되는지 명시 해야 한다.

       13) 오류 처리 

            - 오류를 처리하기 위한 일관된 방법이 명시 되어야한다. 

            - 오류처리 방법은 너무 많기 때문에 기준을 정하지 않으면 가장 어렵다. 

       14) 장애 허용

            - 예상되는 장애 허용의 종류 또한 지정해야한다. 

            - 장애 허용은 오류를 검출하고 가능한 경우에 오류로부터 복구하고 그렇지 않은 경우에는 시스템에 미치는 

              악영향을 방지함으로써 시스템의 신뢰도를 높이는 기술이다. 

       15) 구조적인 실행 가능성

            - 시스템이 기술적으로 실행 가능한지 보여줘야한다. 

            - 특정 분야에서의 실행 불가능 때누에 프로그램 전체가 실행 불가능해 보인다면 아키텍쳐는 기술 검증
              프로토타입이나 조사, 기타 다른 방법을 통해서 그러한 문제점을 어떻게 조사했는지 설명해야한다. 

       16) 과도한 엔지니어링

            -견고함은 시스템이 오류를 발견한 후에도 계속해서 실행 할 수 있는 능력을 말한다.

            - 종종 아키텍처는 요구사항에 명시된 것보다 더견고한 시스템을 명시한다.

       17) 구입과 구현 결정

            - 소프트웨어를 구현하는 가장 급진적인 해결책은 모든 것을 직접 구현하는 대신 사거나 무료로 제공되는
              오프소스 소프트웨어를 내려받는 것이다.

       18) 재사용 결정

            - 기존 소프트웨어나 테스트 케이스, 데이터 형식, 다른 요소들을 사용할 계소기이라면 아키텍처는 재상용된
              소프트웨어가 다른 아키텍쳐 목표에 어떻게 부합할 것인지를 설명해야한다. 

       19) 변경 전략 

            - 변경 처리하기위한 전략을 명확하게 기술해야한다. 

            - 소프트웨어는 계속 변하기 때문에 적은 영향을 미치는 방향으로 변경 적략을 세워야한다. 

       20) 일반적인 아키텍처의 품질

            - 좋은 아키텍처 명세서는 시스템에 있는 클래스와 각 클래스에 숨어있는 정보, 가능한 모든 설계 대안을 포함
              하거나 제외한 근거를 다루고있나든 특정이 있다. 

            - 좋은 아키텍처는 문제 적합해야한다. 

            - 아키텍처를 봤을때 감동적일 만큼 해결책이 자연스럽고 쉬워보여야한다.

4. 구현

5. 시스템 테스트 

6. 향후 개선

 

좋은 아키텍처 구별법

1. 아키텍처의 개요와 설명을 포함한 전체적인 프로그램의 구조가 명확한가?

2. 책임 분야와 다른 빌딩 블록에 대한 인터페이스를 포함한 주요 빌딩 블록을 잘 정의하였는가?

3. 요구 사항에 나열된 모든 기능들을 적절한 수의 빌딩 블록으로 다루었는가?

4. 가장 중요한 클래스를 기술하고 정당성을 증명하였는가?

5. 데이터 설계를 기술하고 정당성을 증명하였는가?

6. 데이터베이스의 구조와 내용이 명시되었는가?

7. 핵심 비즈니스 규칙을 명시하고 시스템에 대한 영향을 기술하였는가?

8. 사용자 인터페이스 설계를 위한 전략을 기술하였는가?

9 사용자 인테페이스에서의 변경이 프로그램의 나머지 부분에 영향을 미치지 않도록 모듈화했는가?

10. I/O 처리 방법을 기술하고 정당성을 증명하였는가?

11. 스레드와 데이터베이스 연결, 핸들, 네트워크 대역폭과 같이, 부족한 자원에 대해서 리소스 사용예측 및 자원 관리 방법을 기술하였는가?

12. 아키텍처의 보안 요구 사항을 기술하였는가?

13. 아키텍처가 각 클래스, 서브시스템, 또는 기능에 대한 공간과 속도를 고려하였는가?

14. 아키텍처가 확장성을 위한 방법을 기술하였는가?

15. 아키텍처가 상호운영성을 해결하는가?

16. 국제화와 지역화를 위한 방법을 기술하였는가?

17. 일관된 오류 처리 방법을 제공하였는가?

18 장애 허용성에 대한 접근 방법을 정의하였는가? (장애 허용성이 필요한 경우)

19. 시스템의 모든 부분에 대해서 기술적인 구현 가능성을 확인하였는가?

20. 지나친 엔지니어링에 대한 해결책을 명시하였는가?

21. 구입할 것인지 구현할 것인지에 대한 결정을 포함하였는가?

22. 재사용된 코드가 다른 구조적인 목표와 어떻게 부합할 것인지 기술하였는가?

23. 아키텍처는 변경 사항들을 수용할 수 있도록 설계되었는가?

 

일반적인 구조적인 품질

 

1. 아키텍처가 모든 요구 사항을 설명하고 있는가?

2. 어느 부분이 지나치거나 부족한가? 이 부분에 대해서 명확하게 설명하는가?

3. 전체적인 아키텍처가 개념적으로 일치하는가?

4. 최상위 설계가 구현에 사용될 기계와 언어에 독립적인가?

5. 중요한 모든 결정에 대한 근거를 제공하는가?

6. 시스템을 구현할 당사자로써 여러분은 아키텍처에 만족하는가?