변경 근거와 관리

변경 용이성은 품질 속성 중 하나

기존 아키텍처와 기존 코드의 제약 안에서 작업을 한다

많은 프로그래머와 소프트웨어 설계자들은 결코 새로운 개발 작업을 할 기회를 얻지 못한다

새로운 기능을 수용하고, 새로운 환경에 순응하고, 버그를 수정

* 변경 카테고리

1. 지역 변경 : 하나의 요소를 변경함으로써 수행, 예를 들어, 가격 로직 모듈에 새로운 업무 규칙을 추가

2. 비지역 변경 : 여러 요소를 변경해야 하지만 해당 아키텍처적인 접근 방법은 그대로 둔다

                  예를 들어 가격 로직 모듈에 새로운 업무 규칙을 추가한 다음 이 새로운 업무 규칙에 필요한 새로운 필드를 데이터 베이스에 추가하고, 사용자 인터페이스에 규칙의 결과를 나타내게 한다

3. 아키텍처적 변경 : 요소가 서로 상호작용하는 근본적인 방식에 영향을 주어 시스템 전반에 걸쳐 변경이 필요

                       예를 들어 시스템을 클라이언트-서버에서 피어-투-피어로 바꾼다

- 분명히 지역 변경이 가장 바람직한 방법

- 효과적인 아키텍처는 대부분의 일반적인 변경이 지역에서 이루어지게 하여 변경을 쉽게 할 수 있도록 하는 것

- 변경이 필수적으로 필요한 시점을 결정

- 어느 변경 경로가 가장 위험이 적은지를 결정, 제안된 변경의 결과를 평가 

- 요청된 모든 변경의 순서와 우선순위를 중재하기 위해서는 시스템 소프트웨어 요소의 관계와 성능, 행위에 대한 폭넓은 통찰력이 필요

- 아키텍처에 대한 근거와 아키텍처 분석은 기대한 변경에 대한 결정을 내리는 데 필요한 통찰력을 준다