 |
이 체크리스트를 사용하면 소프트웨어 아키텍처 문서가 안정적이고, 올바르고, 완료되었는지를 확인할 수 있습니다. |
|
관계
기본 설명
검사 항목
일반
시스템은 전반적으로 다음과 같은 이유로 인해 아키텍처를 기반으로 합니다.
-
아키텍처는 안정적입니다.
안정성에 대한 요구는 구현/구축(Construction) 단계의 특성에서 알 수 있습니다. 구현/구축(Construction) 단계에서는 일반적으로 병렬 작업을 수행하는 개발자가 추가되고 제품 생산
중 다른 개발자와의 느슨한 커뮤니케이션을 통해 프로젝트가 확장됩니다. 아키텍처가 불안정한 경우 구현/구축 시 필요한 독립성 및 병렬성 정도를 달성할 수 없습니다.
안정적인 아키텍처의 중요성은 아무리 설명해도 지나치지 않습니다. '어느 정도의 안정성으로 충분할 수 있다'고 생각해서는 안됩니다. 불안정한 것은 어디까지나 불안정한 것이므로 그냥 진행하는 것보다
생성을 지연시키고 아키텍처를 바로잡는 것이 바람직합니다. 개발자가 기반을 구축하려는 동안 아키텍처를 복구하려는 조정 문제점이 생기면 스케줄 단축의 명백한 이점이 상쇄될 수 있습니다.
구현/구축(Construction) 과정에서 아키텍처 변경이 생기면 큰 영향을 미칩니다. 비용도 많이 필요하고 여러 가지 혼란이 발생할 수 있습니다.
아키텍처 안정성을 평가하는 데 있어 실질적인 어려움은 사용자가 "알지 못하는 내용은 스스로 알기 어렵다"는 것입니다. 안정성은 예상 변경에 상대적으로 측정됩니다. 결과적으로 안정성은 주관적인
척도입니다. 그러나 이러한 주관성은 단순한 추측 이상을 기반으로 할 수 있습니다. 아키텍처는 '구조적으로 중요한' 시나리오(시스템이 지원해야 하는 기술적으로 가장 어려운 동작을 나타내는 유스 케이스의
서브세트)를 고려하여 개발됩니다. 아키텍처의 안정성을 평가하는 작업에는 아키텍처에 예상치 못한 내용이 없게 하기 위해 아키텍처가 넓은 적용 범위를 갖도록 하는 작업이 포함됩니다.
아키텍처에 대한 과거의 경험도 휼륭한 지표가 될 수 있습니다. 아키텍처의 변경률이 낮고 새 시나리오가 적용될 때에도 계속 낮은 상태인 경우 아키텍처가 안정적인 것으로 볼 수 있습니다. 반대로, 각각의
새 시나리오에서 아키텍처의 변경이 발생하는 경우 아키텍처가 계속 변하고 있으며 기준선 작성이 아직 허가되지 않은 것입니다.
-
시스템의 복잡도는 시스템이 제공하는 기능과 일치합니다.
-
개념적 복잡도는 다음 스킬 및 경험이 제공되는 경우에 적절합니다.
-
시스템이 일관적이고 일치하는 단일 아키텍처를 가집니다.
-
컴포넌트의 수 및 유형이 합리적입니다.
-
시스템에 일관된 전체 시스템의 보안 기능이 있습니다. 모든 보안 컴포넌트가 함께 작업하여 시스템을 보호합니다.
-
시스템이 가용성 목표를 충족시킵니다.
-
실패 이벤트 시 필요한 시간 내에 시스템이 복구될 수 있도록 아키텍처에서 허용합니다.
-
시스템이 기반으로 하는 제품 및 기법이 예상 수명과 일치합니까?
-
수명이 짧은 임시(전술적) 시스템은 곧 사용하지 않을 이전 기술을 사용하여 안전하게 빌드할 수 있습니다.
-
예상 수명이 긴 대부분의 시스템은 최신 기술 및 메소드를 기반으로 빌드해야 향후 요구사항을 지원하도록 유지보수 및 확장할 수 있습니다.
-
제공되는 아키텍처는 병렬 팀 개발을 위한 파티션을 사용할 수 있도록 명확한 인터페이스를 정의합니다.
-
모델 요소의 디자이너는 모델 요소를 디자인 및 개발할 만큼 아키텍처를 잘 이해할 수 있습니다.
-
패키징 접근 방식은 복잡도를 줄이고 이해도를 개선합니다.
-
패키지는 패키지 내부적으로는 매우 높은 결합력을 가지도록 정의된 반면 패키지 자체의 결합력은 낮습니다.
-
공통 응용프로그램 도메인 내의 유사한 솔루션이 고려되었습니다.
-
문제점 도메인에서 일반적으로 지식이 있는 사용자가 제안된 솔루션을 쉽게 이해할 수 있습니다.
-
모든 팀 구성원은 소프트웨어 설계자에서 제시한 것과 동일한 아키텍처 보기를 공유합니다.
-
소프트웨어 아키텍처 문서는 최신입니다.
-
디자인 가이드라인을 준수했습니다.
-
모든 기술 위험성이 이주되었거나 비상사태 계획에서 다뤄졌습니다. 새로 발견된 위험성은 문서화하여 잠재적 영향이 분석되었습니다.
-
주요 성능 요구사항(확정된 예산)이 충족되었습니다.
-
테스트 케이스, 테스트 하니스 및 테스트 구성이 식별되었습니다.
-
아키텍처가 "너무 복잡하게 디자인"되지 않습니다.
-
적절한 메커니즘이 사용하기에 충분히 단순한 형태입니다.
-
메커니즘의 수가 적당하고 시스템의 범위 및 문제점 도메인의 요구와 일치합니다.
-
현재 반복에 대해 정의된 모든 유스 케이스 실현(realization)은 아키텍처에서 다음 다이어그램에서 설명하는 대로 실행됩니다.
-
-
오브젝트 간 상호작용
-
타스크와 프로세스 간 상호작용
-
실제 노드 간 상호작용
|
모델
전체
-
서브시스템 및 패키지 파티션과 계층화가 논리적으로 일관됩니다.
-
모든 분석 메커니즘이 식별 및 설명되었습니다.
서브시스템
-
상위 레벨 계층에 있는 서브시스템의 서비스(인터페이스)가 정의되었습니다.
-
서브시스템과 패키지 간의 종속성은 포함된 클래스 간의 종속성 관계에 해당합니다.
-
서브시스템의 클래스는 서브시스템에 대해 식별되는 서비스를 지원합니다.
클래스
-
키 엔티티 클래스 및 해당 관계가 식별되었습니다.
-
키 엔티티 클래스 간의 관계가 정의되었습니다.
-
각 클래스 이름 및 설명이 클래스가 수행하는 역할을 정확히 반영합니다.
-
각 클래스의 설명이 클래스의 책임을 정확히 캡처합니다.
-
엔티티 클래스가 적절한 분석 매커니즘으로 맵핑되었습니다.
-
집계 및 연관의 역할 이름이 관련 클래스 간의 관계를 정확히 설명합니다.
-
관계의 다중성이 올바릅니다.
-
키 엔티티 클래스 및 해당 관계가 비즈니스 모델(있는 경우), 도메인 모델(있는 경우), 요구사항 및 용어집 항목과 일치합니다.
-
모델이 주어진 모델 목표에 대해 적절한 세부사항 레벨에 있습니다.
-
정제(Elaboration) 단계 중의 비즈니스 모델, 요구사항 모델 또는 디자인 모델에 대해 구현 문제를 지나치게 강조하지 않습니다.
-
구현/구축(Construction) 단계의 디자인 모델에 대해, 상대적으로 간단한 요소의 구성을 사용하여 보다 복잡한 디자인을 빌드함으로써 모델 요소 간 기능성의 밸런스를 조절합니다.
-
모델은 문제점 도메인에 적용 가능한 모델링 개념의 전체 범위를 사용하여 친숙성과 역량을 나타냅니다. 모델링 기법은 현재 문제점에 적절히 사용됩니다.
-
개념이 가능한 간단한 방법으로 모델링됩니다.
-
모델이 쉽게 전개되며 예상 변경사항을 쉽게 수용할 수 있습니다.
-
동시에 단순성 및 이해도를 저하시키면서 발생할 가능성이 적은 변경사항을 처리할 만큼 모델이 지나치게 구성되지 않았습니다.
-
모델의 주요 가정이 문서화되어 모델 검토자가 볼 수 있습니다. 이 가정을 주어진 반복에 적용할 수 있는 경우, 모델은 가정 밖이 아닌 안에서 발전하게 됩니다. 가정을 문서화하면 디자이너는 가능한
"모든" 요구사항을 확인하지 않아도 됩니다. 반복 프로세스에서 가능한 모든 요구사항을 분석하거나 모든 향후 요구사항을 처리할 모델을 정의할 수는 없습니다.
|
다이어그램
-
다이어그램의 목적이 명확히 설명되어 쉽게 이해할 수 있습니다.
-
그래픽 레이아웃이 명확하며 원하는 정보를 정확하게 제공합니다.
-
다이어그램이 해당 목표를 달성할 수 있는 정도의 정보만을 제공합니다.
-
캡슐화를 효과적으로 사용하여 세부사항을 숨기고 명확성을 개선합니다.
-
추상을 효과적으로 사용하여 세부사항을 숨기고 명확성을 개선합니다.
-
모델 요소를 배치함으로써 관계를 효과적으로 제공합니다. 유사하거나 밀접하게 결합된 요소는 함께 그룹화됩니다.
-
모델 요소 간의 관계를 쉽게 이해할 수 있습니다.
-
모델 요소의 레이블로 쉽게 이해할 수 있습니다.
|
문서화
-
각 모델 요소에 고유한 목적이 있습니다.
-
불필요한 모델 요소가 없으며 각 요소가 시스템에서 중요한 역할을 수행합니다.
|
오류 복구
-
각 오류 또는 예외에 대해, 정책은 시스템이 "정상" 상태로 복원되는 방법을 정의합니다.
-
사용자의 입력 오류 또는 외부 시스템의 잘못된 데이터로 인해 가능한 모든 유형에 대해, 정책은 시스템이 "정상" 상태로 복원되는 방법을 정의합니다.
-
예외 상황을 처리하기 위해 일관적으로 적용되는 정책이 있습니다.
-
데이터베이스의 데이터 손상을 처리하기 위해 일관적으로 적용되는 정책이 있습니다.
-
데이터의 비가용성을 처리하기 위해 일관적으로 적용되는 정책이 있습니다(시스템에 계속 데이터를 입력하고 나중에 저장할 수 있는지 여부 포함).
-
시스템 간에 데이터를 교환하는 경우, 해당 데이터 보기를 동기화하는 방법에 대한 정책이 있습니다.
-
시스템이 여분의 프로세스 또는 노드를 활용하여 결함 허용 또는 고가용성을 제공하는 경우, 동시에 두 개의 프로세서 또는 노드에서 자신을 1차 프로세서 또는 노드로 인식하지 못하게 하거나 프로세서 또는
노드가 1차가 되지 못하게 하는 전략이 있습니다.
-
분산 시스템의 실패 모드가 식별되었으며 실패를 처리하기 위한 전략이 정의되었습니다.
|
전이 및 설치
-
데이터 또는 운용 능력의 손실 없이 기존 시스템을 업그레이드하기 위한 프로세스가 정의되어 테스트되었습니다.
-
이전 릴리스에서 사용된 데이터를 변환하기 위한 프로세스가 정의되어 테스트되었습니다.
-
제품을 업그레이드 또는 설치하는 데 필요한 시간 및 자원 양이 적절히 문서화되어 있습니다.
-
시스템 기능성이 한 번에 하나의 유스 케이스로 활성화될 수 있습니다.
|
관리
-
시스템을 실행하면서 동시에 디스크 공간을 재구성 또는 복구할 수 있습니다.
-
시스템 형상에 대한 책임 및 프로시저가 식별 및 문서화되었습니다.
-
운영 체제 또는 관리 기능에 대한 액세스가 제한됩니다.
-
라이센스 부여 요구사항이 충족됩니다.
-
시스템을 실행하면서 동시에 진단 루틴을 실행할 수 있습니다.
-
시스템이 운영 성능(예: 용량 임계값, 중요 성능 임계값, 자원 사용) 자체를 모니터합니다.
-
임계값에 도달할 때 수행하는 조치가 정의됩니다.
-
알람 처리 정책이 정의됩니다.
-
알람 처리 메커니즘이 정의되고 프로토타입 생성 및 테스트되었습니다.
-
알람 처리 메커니즘을 '조정'하여 잘못되거나 불필요한 알람을 방지할 수 있습니다.
-
네트워크(LAN, WAN) 모니터링 및 관리를 위한 정책 및 프로시저가 정의됩니다.
-
네트워크 결함을 분리할 수 있습니다.
-
문제점 해결을 돕기 위해 사용할 수 있는 이벤트 추적 기능이 있습니다.
-
기능 오버헤드를 이해할 수 있습니다.
-
관리 인력은 기능을 효과적으로 사용할 수 있는 지식을 소유하고 있습니다.
-
악의적인 사용자는 다음 작업을 수행할 수 없습니다.
-
시스템 진입
-
중요 데이터 삭제
-
모든 자원 이용
|
성능
-
성능 요구사항이 합리적이며 문제점 도메인의 실제 제한조건을 반영합니다. 해당 스펙은 임의적이지 않습니다.
-
시스템 성능의 예상이 존재하며(워크로드 분석 모델을 사용하여 필요한 대로 모델링됨) 이러한 예상은 성능 요구사항이 중요한 위험성이 아님을 나타냅니다.
-
시스템 성능 예상이 아키텍처 프로토타입을 사용하여 유효성 검증되었습니다(특히 성능에 민감한 요구사항의 경우).
|
메모리 활용
-
응용프로그램에 대한 예상 메모리 사용량이 정의되었습니다.
-
메모리 누수를 발견 및 방지하기 위한 조치가 수행되었습니다.
-
가상 메모리 시스템의 사용, 모니터 및 조정 방법을 정의하며 일관적으로 적용되는 정책이 있습니다.
|
비용 및 스케줄
-
지금까지 개발된 코드의 실제 행 수가 현재 이정표의 예상 코드 행 수와 일치합니다.
-
예상 가정에 대한 검토를 마쳤으며 현재 올바른 상태입니다.
-
최신 실제 프로젝트 경험 및 생산성 성능을 사용하여 비용 및 스케줄 예상을 다시 계산했습니다.
|
이식성
-
이식성 요구사항이 충족되었습니다.
-
프로그래밍 가이드라인은 이식 가능한 코드 작성에 대한 특정 안내를 제공합니다.
-
디자인 가이드라인은 이식 가능한 응용프로그램 디자인에 대한 특정 안내를 제공합니다.
-
'포트 테스트'를 수행하여 이식성 문제를 확인했습니다.
|
신뢰성
-
품질 척도(MTBF, 미해결 결함 수 등)가 충족되었습니다.
-
재난 또는 시스템 장애 시 복구를 위한 아키텍처를 제공합니다.
|
보안
조직 문제
-
팀이 올바르게 구성되었습니까? 팀 간에 책임이 올바르게 분배되었습니까?
-
팀의 능력을 제한하는 정치적, 조직적 또는 관리적 문제가 있습니까?
-
개성 면에서 충돌하는 경우가 있습니까?
|
유스 케이스 보기
소프트웨어 아키텍처 문서의 유스 케이스 보기 섹션의 내용은 다음과 같습니다.
-
각 유스 케이스는 다음과 같은 이유로 구조적으로 중요하게 식별됩니다.
-
고객에게 매우 중요합니다.
-
다른 보기의 핵심 요소를 자극합니다.
-
하나 이상의 주요 위험성을 완화하기 위한 구동 요소입니다(중요한 비기능적 요구사항 포함).
-
해당 아키텍처 문제가 다른 유스 케이스에 이미 포함되는 유스 케이스가 없습니다.
-
구조적으로 중요한 유스 케이스 측면이 명확하며 세부사항에 설명됩니다.
-
유스 케이스가 명확하며 아키텍처에 영향을 주는 방식으로 변경되지 않거나, 해당 명확성 및 안정성을 달성하는 방법에 대한 계획이 존재합니다.
-
구조적으로 중요한 유스 케이스가 누락되지 않습니다(이 보기에 대해 선택되지 않은 유스 케이스를 일부 분석해야 함).
|
논리 보기
소프트웨어 아키텍처 문서의 논리 보기 섹션의 내용은 다음과 같습니다.
-
구조적으로 중요한 디자인 요소의 개요를 정확하고 완전하게 표시합니다.
-
디자인에서 사용하는 전체 아키텍처 메커니즘 세트를 해당 선택 시 사용된 근거와 함께 표시합니다.
-
디자인 계층을 계층을 파티션하는 데 사용된 근거와 함께 표시합니다.
-
디자인에서 사용되는 패턴 또는 프레임워크를 패턴 또는 프레임워크를 선택하는 데 사용된 근거와 함께 표시합니다.
-
구조적으로 중요한 모델 요소 수는 시스템의 범위 및 크기에 비례하며 시스템 작업 시 주요 개념을 이해하기 쉽게 하는 크기입니다.
|
프로세스 보기
자원 활용
-
잠재적 경쟁 조건(중요 자원에 대한 프로세스 경쟁)이 식별되고 회피 및 해결 전략이 정의되었습니다.
-
"입출력 대기열 가득 참" 또는 "버퍼 가득 참" 조건 처리에 대한 전략이 정의되어 있습니다.
-
시스템은 용량 임계값, 중요 성능 임계값 및 자원 사용을 자체적으로 모니터하며 문제점이 발견되면 정정 조치를 수행할 수 있습니다.
성능
-
각 메시지에 대한 응답 시간 요구사항이 식별되었습니다.
-
메시지 응답 시간을 측정할 수 있는 시스템 진단 모드가 있습니다.
-
중요 오퍼레이션에 대한 명목 및 최대 성능 요구사항이 지정되었습니다.
-
성능 요구사항의 충족 여부를 측정할 수 있는 성능 테스트 세트가 있습니다.
-
성능 테스트에서 시스템의 "비정상" 동작도 처리합니다(시스템 시작 및 종료, 유스 케이스의 대체 및 예외 이벤트 플로우 및 시스템 장애 모드).
-
잠재적 성능 병목 현상을 가져오는 아키텍처 취약성이 식별되었습니다. 특히 다음에 초점을 맞춥니다.
-
-
세마포어, 파일 처리, 잠금, 래치, 공유 메모리와 같은 일부 한정 공유 자원(이 자원에 한정되지는 않음) 사용
-
프로세스 간 통신. 일반적으로 프로세스 경계를 가로지르는 통신이 프로세스 간 통신보다 많은 비용이 듭니다.
-
프로세서 간 통신. 일반적으로 프로세스 경계를 가로지르는 통신이 프로세스 간 통신보다 많은 비용이 듭니다.
-
실제 및 가상 메모리 사용. 시스템이 실제 메모리를 모두 사용하고 가상 메모리를 사용하기 시작하면 일반적으로 성능이 현저히 저하됩니다.
결함 허용
-
주요 백업 프로세스가 있는 경우, 충돌을 해결하기 위해 자신을 주요 프로세스로 인식하는 프로세스가 두 개 이상 있을 가능성(또는 자신을 주요 프로세스로 인식하는 프로세스가 없을 가능성)을 고려하여
특정 디자인 조치를 수행했습니다.
-
프로세스 장애와 같은 이벤트로 시스템이 일관되지 않는 상태가 되는 경우 시스템을 일관된 상태로 복원하는 외부 프로세스가 있습니다.
-
시스템의 오류 및 예외에 대한 허용. 즉 오류 또는 예외가 발생하면 시스템이 일관된 상태로 전환될 수 있습니다.
-
시스템을 실행하면서 동시에 진단 테스트를 실행할 수 있습니다.
-
필요한 경우 시스템(하드웨어 및 소프트웨어)을 계속 실행하면서 업그레이드할 수 있습니다.
-
시스템에 알람을 처리하기 위한 일관된 정책이 있으며 이 정책이 일관적으로 적용되었습니다. 알람 정책에서 다루는 내용은 다음과 같습니다.
-
-
알람 보고 메커니즘의 "민감도":
-
잘못되거나 불필요한 알람 예방
-
알람 보고 메커니즘을 사용할 인원의 훈련 및 사용자 인터페이스 요구사항
-
알람 보고 메커니즘 성능이 평가되었으며 해당 성능이 성능 요구사항에 작성된 허용 가능한 성능 임계값 범위 내에 있습니다.
-
워크로드/성능 요구사항이 점검 및 충족되었습니다. 성능 요구사항이 비현실적인 경우 다시 협상되었습니다.
-
가능한 예상 메모리 사용량을 식별했으며 소프트웨어가 해당 요구사항을 충족시키는지 확인했습니다. 메모리 누수를 발견 및 방지하기 위한 조치가 수행되었습니다.
-
가상 메모리 시스템의 사용 모니터 및 조정 방법을 포함한 사용 정책이 존재합니다.
모듈화
-
프로세스가 충분히 독립적이어서 필요 시 프로세서 및 노드 간에 분배될 수 있습니다.
-
프로세스 간 통신 메커니즘이나 성능 및 처리량 요구사항으로 인해 공존해야 하는 프로세스(예: 세마포어 또는 공유 메모리)가 식별되었으며 이 워크로드를 분배할 수 없을 경우의 영향이 고려되었습니다.
-
비동기여서 자원 가용성이 보다 높을 때 처리할 수 있는 메시지가 식별되었습니다.
|
배치 보기
-
노드 간의 처리 분배로 처리량 요구사항을 충족시켰으며 잠재적인 성능 병목 현상을 처리했습니다.
-
여러 노드 간에 정보를 분배하여 잠재적으로 복제함으로써 정보 무결성이 보장됩니다.
-
메시지의 신뢰할 수 있는 전송을 위한 요구사항이 충족되었습니다(있는 경우).
-
메시지의 안전한 전송을 위한 요구사항이 충족되었습니다(있는 경우).
-
일관성 및 자원 제한조건에 따라 네트워크 트래픽 및 응답 시간을 최소화하는 방식으로 처리량이 노드에 분배되었습니다.
-
시스템 가용성 요구사항 범위가 충족되었습니다.
-
서버 또는 네트워크 장애 시 최대 시스템 중단 시간이 판별되었으며 해당 시간이 요구사항이 정의하는 허용 가능한 한계 범위 내에 있습니다.
-
둘 이상의 서버를 "1차" 서버로 지정할 수 없는 방식으로 여분의 대기 서버가 정의되었습니다.
-
모든 잠재 장애 모드가 문서화되었습니다.
-
네트워크 결함을 분리, 진단 및 해결할 수 있습니다.
-
CPU 활용에서의 "머리 공간(headroom)" 양이 식별되고 측정 방법이 정의되었습니다.
-
최대 CPU 활용량이 초과될 때 수행되는 조치에 대한 명확한 정책이 있습니다.
|
|
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|