[SW 아키텍처 개요] 아키텍처 정의/중요성/활용/품질속성/평가모델

1. SW 아키택처 개요

1.1  SW 아키텍처 정의

1.1.1  정의

-시스템의 SW 아키텍처는 소프트웨어 요소와 요소간의 관계 그리고 각각의 속성으로 구성된 시스템에 필요한 구조의 집합이다.

-모든 SW 시스템은 SW 아키텍처를 가지고 있다

-시스템에 관계되는 여러 이해관계자의 관심사항과 이에 따른 관점을 반영한

 다양한 모델의 집합이다.

 

1.2  아키텍처 고려사항

(1) 원칙적으로 로직은 어플리케이션 서버에만 구현한다

(2) 시스템 간에 데이터는 직접 공유하지 않는다

(3) 데이터 복제 시 기준정보를 관리 한다

(4) 보안에 대한 요구사항은 별도 영역으로 분석 단계부터 관리한다

(5) 어플리케이션 실행 로그 관리 대상을 명확히 하여 설계한다

(6) 서버에서 사용하는 트랜잭션 layout은 전사 차원에서 표준화 한다

(7) 프로그램 실행에 따라 사용하는 메시지는 구분하여 메시지 코드를 설계한다

 

1.3  아키텍처의 중요성

(1) 시스템 품질 속성을 실현하게 해준다

(2) 아키텍처의 의사결정이 시스템의 진화에 따라 변경 타당성을 파악하고 관리하게 도와준다

(3) 시스템 품질 예측에 도움을 준다

(4) 이해당사자간 의사소통이 가능하다

(5) PM과 아키텍트가 비용 및 일정을 예측하도록 도와준다

(6) 설계 대안을 제한하여 설계와 시스템 복잡도를 줄여준다

 

1.4  아키텍처의 활용 (또는 기대효과)

-품질특성 추론: 다양한 모델을 통한 사전 품질 특성 추론 가능

-의사소통: 여러 이해관계자의 다양한 관점을 충족시키는 일관된 내용 제공

-기술변화대처: 기술,플랫폼에 독립적인 모형에 기반하여 변경되는 IT환경 변경 유연성 확보

-개발용이: 구현단계서 발생하는 설계문제에 대한 합리적 의사결정 및 문제해결 여건제공

 

2. 품질 속성

-품질속성은 시스템 기능과 함께 아키텍처에 영향을 준다

-품질 속성 분석은 아키텍트로서 가져야 할 핵심 스킬이다.

 

 

2.1  가용성

-소프트웨어가 필요할 때 작업을 수행할 준비가 되었는지를 판단한다.

-합법적인 사용자에게 서비스를 제공하는 것.

-오류 발생 시 시스템의 반응을 판단하는 척도이다.

-가용성은 보안, 성능, 안전과 밀접한 관련이 있다.

-시스템 오류를 완화시켜 서비스 중단 시간을 최소화 하는 것이다.

 

2.2  상호운영성

-2개 이상의 시스템이 업무를 위해 인터페이스를 통하여 정보를 교환하는 정도를 뜻한다

 

2.3  변경용이성

-전형적으로 SW 시스템 비용의 대부분은 운영을 시작한 후에 발생한다

-이때, 변경이랑 새로운 기능 추가, 안 쓰는 기능 제거, 오류 수정, 보안 강화, 성능 개선,

UX반영, 프로토콜 및 표준 적용, 타 시스템 연동 등의 이유가 있다.

 

2.4  성능

-시간 요구사항을 SW 시스템이 충족시키는 능력

-시스템 이벤트에 정해진 시간 내에 응답해야 한다

-성능은 확장성과 밀접하게 연관이 되어있다. à 아키텍처에 문제가 있을 경우 H/W 증설로 해결이 어려울 수도 있다.

 

2.5  보안

-인증되지 않은 접근으로부터 데이터와 정보를 보호하는 시스템의 능력

-비밀성 및 무결성(인가 받지 않은 데이터 및 서비스 접근 통제) 과 가용성의 특징을 지님

 

2.6  테스트 용이성

-테스팅을 통하여 결함을 발견하는 것

-산업계 추정에 의하면 SW개발 비용의 30~50%가 테스팅에 사용된다.

 

2.7  사용성

-사용자가 얼마나 쉽게 쓰는지에 대한 척도이다.

-시스템 기능 학습, 시스템의 효율적 사용, 오류의 영향 최소화, 사용자 요구에 따른 시스템의 적응, 신뢰와 만족 증가 등

 

3. 아키텍처 구축 프로세스

단계	액티비티	내용
요구사항 분석	요구사항 분석	요구사항 취득, 식별, 명세, 분류, 검증 기능적/비기능적 요구사항 분류 및 명세
아키텍처 분석	품질요소식별	기능성, 신뢰성, 효율성, 유지보수성, 이식성
	품질요소 우선순위결정	Utility Tree(품질요소의 목표 및 영향도 식별), 품질시나리오 작성
	전술개발(Tactic Develop)	품질속성별 전술 개발 및 명세
아키텍처 설계	관점 및 View 정의	이해당사자 파악 및 이해당사자 별 관점, View정의 (Module view, Component Connector View,  Allocation view, Code View)
	아키텍쳐스타일선택	Pipe-Filter, MVC, Layer등 스타일 혼용 적용
	후보아키텍처 도출	Context Diagram, 및 각종 View별로 다이어그램작성, SAD(Software Architecture Description)기술
검증 및 승인	아키텍처 평가	아키텍처의 요구사항 만족 적합성 평가 품질속성간 tradeoff관계 평가(ATAM)
	아키텍처 상세화(반복)	설계 매커니즘 도출 (Persistency, Transaction등) 디자인 패턴 고려
	아키텍처 승인	고객 및 이해당사자 최종 승인

 

4. 아키텍처 평가와 역량

4.1  아키텍처 평가 정의

- 아키텍처 접근법이 품질속성에 미치는 영향을 판단하여 아키텍처의 적합성을 판단 및 평가하는 표준절차를 뜻한다.

 

4.2  목적 및 필요성

-시스템과 프로젝트의 위험요소 조기 발견 및 제거

-비기능적 요소의 소프트웨어 반영도에 따른 영향도 평가

-아키텍쳐는 프로젝트의 성패를 좌우하는 핵심요소

 

4.3  관점별 평가 유형

관점	유형	내용 및 기법
평가의 가시성	가시적 평가	Inspection, review, validation/verification
	비가시적 평가	SAAM,ATAM,CBAM,ARID,ADR
평가의 시점	이른평가	아키텍쳐 구축과정중 어느때나 평가 검증, 비용 및 평가부담이 적다
	늦은평가	기존시스템의 요구사항 적합성을 판단할 때 사용

 

4.4  평가모델

(1) ATAM (Architecture Tradeoff Analysis Method)

- 아키텍처가 품질속성을 만족시키는지 판단 및 품질속성들이 이해상충관계(trade-off)까지 평가

- 잘 정의된 분석 및 평가 절차

- 레거시 시스템의 아키텍쳐 평가도 가능

 

(2) ADR (Architectural Design Review)

- SW아키텍쳐 구성요소간 응집도 평가

 

(3) SAAM (Software Architecture Analysis Method)

- Modifiability와 Functionality에 집중

- 평가용이: 평가 경험이 없는 조직에서도 활용가능

 

(4) ARID(Active Reviews for Intermediate Designs)

- 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중

 

(5) CBAM (Cost Benefit Analysis Method)

- 비즈니스 품질속성인 경제성에 중점