[ISAQB] Chapter 5. Software architecture and quality

 

<목차>

 

 

 

🟡 5.1 Evaluating software architecture

 

 

 

✅ 5.1.1 Qualitative evaluation

 

Software project evaluate 'development or operating process' and 'artifact(requirement, source code, other document)'

 

 

🔸 8 quality characteristics

 

 

 

1. Functional suitability: 기능 적합성, 완전성 (제안된 요구사항을 충분히 만족하였는가?)
2. Reliability: 신뢰성 - 회복성, maturity, fault tolerance (정의된 조건 아래의 성능을 유지 하는가?)
3. Usability: 사용성 - 인식성, 학습성, 접근성 (학습하고 사용하기 쉬운가?)
4. Performance efficiency: 성능 효율성 - 시간 효율, 리소스 utilization, capacity (얼마나 경제적인가?)
5. Security: 보안성 - 기밀성, 무결성, 인증, 인가 (데이터 보호 성능이 얼마나 좋은가? 권한이 없는 사용자가 데이터를 읽고 쓰는 것을 허락하지 않고 있는가?)
6. Compatibility: 호환성 (같은 시스템 환경 안에서 정보 교환이 원활한가?)
7. Maintainability: 유지보수성 - 모듈화, 변경 용이, 테스트 가능, 분석 가능, 재사용성
8. Portability: 이식성 - 적용성, 설치 가능 (소프트웨어가 다른 시스템에서도 사용이 가능한가?)
9. Scalability: adaptability to an increasing volume of requirements
10. Traceability: 모든 요구사항이 unique한 identification을 가져야 함

 

 

🔸 Effects of quality characteristics

 

• Simplicity increases comprehensibility
• Security can reduce usability: 특정 기능은 특정 네트워크 안에서만 사용 가능
• Flexibility can reduce testability: 복잡도가 높은 시스템은 테스트 할 것이 더 많음
• Adaptability and flexibility: increased performance -> 시간 내에 완료하는 것에 제약이 있을 수 있음

 

 

🔸 Tactics and practices for fulfilling quality requirements

 

for fulfilling quality requirements

 

 

Adaptability and Flexibility를 높이는 것과 performance를 증가시키는 것은 서로 이해관계가 상충됨!!!

따라서, 어떤 측면(functionality, external software, interfaces, target problem....등)의 Flexibility를 높일 것인지 고려해야 함

 

[Flexibility를 높이는 방법]

- information hiding

- dependency 줄이기

- building block 사용 최소화

- decouple system elements (interface 사용 / adapter, facade, proxy)

- 코드의 가독성 높이기

 

 

 

✅ 5.1.2 Quantative evaluation

 

🔸 Check architecture compliance

Quantitative methods for quality assurance of architectures

 

Static analysis tool can be configured to evaluate the compliance of the code

"architecture standards"

 

 

[Architectural problem area as an aspect of quantitativeness]

1. high coupling of components
2. clusters of erros in certain building block of the system

 

 

 

🔸 Metrics

 

1. Requirements: 요구사항의 갯수
2. Source code: 소스코드 라인 수 / 의존도 / 복잡성 / 각 클래스 별 메소드의 갯수
3. Software production process: implemented/tested feature의 수 / meeting 시간 / manager, tester, developer의 비율 / 새로 추가 될 소스 코드 라인 수 / 산정된 공수
4. Errors: 에러 수정시 소요 시간 / 에러의 갯수
5. Testing: test case의 갯수 / 테스트 커버리지(각 요구사항 당 나오는 테스트 케이스의 수)
6. Design: dependency / 추상도 / 불안정성
7. System(fully or partially complete): performance characteristics(리소스 or use case or 특정 기능이 processing 되는 데에 걸리는 시간)

 

 

 

🔸 Cyclomatic complexity (순환 복잡도)

 

 

복잡도 = 선(edge)의 수 - 마디(node)의 수 + 2

 

 

위의 계산식 만큼 만들어진 TC로 커버할 수 있다는 이론

"낮은 순환 복잡도" = 모듈에 대한 이해, 테스트, 유지보수가 쉬움

"높은 순환 복잡도" = 모듈이 복잡하고 테스트에 불리함

 

 

 

 

 

🟡 5.2 Prototype and technical proof of concept

 

✅ 5.2.1 Technical proof of concept

Theoretical demonstration of a product / process / concept

 

to check feasibility "theorically"

 

 

 

✅ 5.2.2 Prototype

Very early draft of a product / process / concept

장점: 사용자가 중요한 실험적 경험을 할 수 있게 해줌, 미리 피드백 제공 가능, 개발 리스크 감소
단점: 개발 공수 증가, 결국 필요없는 prototype("throwaway prototype")이 될 수 있음, documentation 대안이 될 수 있음

 

1. Demonstration prototype: 최종 product의 모습 표현
2. "real" prototype: 실제 개발과 병행 작업을 통해 표현 / analysis purpose
3. Laboratory sample: 실험적인 example
4. Pilot system: core prototype

 

 

 

 

 

 

🟡 5.3 Architecture analysis

 

✅ ATAM method

 

Architecture Tradeoff Analysis Method

아키텍처 품질 속성을 만족시키는지 여부와 품질 속성들 간의 상호작용(trade-off)까지 밝혀 평가하는 아키텍처 평가 방법!

비즈니스 드라이버(business driver)에서 품질 속성(quality attribute)를 도출 -> 시나리오에 적용 -> 분석 -> Architecture decision

"아키텍처가 처음에 의도했던 방향대로 제대로 설계 되었는지를 검증하는 분석 방법론"

 

 

🔸 The evaluation procedure

 

 

1. 아키텍처 이해

- 활동소개와 역할 소개 : 평가 리더가 이해관계자에게 ATAM 을 설명

- 비즈니스/아키텍처 목표 이해 : 프로젝트 결정권자(PM 또는 고객)가 비즈니스 관점에서 시스템 전반을 설명

- 작성된 아키텍처 소개 : 수석 아키텍트가 평가팀에 아키텍처를 설명 

 

2. 아키텍처 분석

- 아키텍처 접근방법 식별 : 현재까지 파악된 아키텍처 접근법를 정리

- 품질속성 시나리오 작성 : 평가팀과 프로젝트 결정권자가 모여 품질속성 요구사항의 우선순위 결정(유틸리티 트리작성)

- 시나리오/아키텍처 상세분석: 아키텍처 접근법이 품질요구사항에 적합한지 검사

 

3. 아키텍처 검증

- 픔질속성 시나리오 검증: 유틸리티 트리의 품질속성, 시나리오 검증(브레인스토밍)

   >> 아키텍처가 이해관계자의 의중을 얼마나 잘 반영했는지 판단

- 아키텍처 접근방법 검증: 도출된 시나리오 중 우선순위가 높은 시나리오의 산출물 작성

- 검증결과 발표와 문서화: 최종 보고서 제공, ATAM 산출물 설명

 

 

[장점]

 

 

[시나리오 분석을 위한 4가지 측면]

1. Risk

2. Sensitivity points

3. Compromises

4. Non-risks

Analysis가 가장 중심이 된다!!!

 

 

시나리오 방식으로 품질 속성 만족 여부를 판단하여 상충 관계 분석 및 평가를 진행

" SW아키텍처가 요구사항, 특히 비기능적 요구사항을 만족하도록 설계되었는지 여부 판단"

" SW아키텍처가 내포하고 있는 위험 판단"

 

 

 

🔸 Creating a quality tree

 

break down quality RQ

 

 

 

🔸 Scenarios

 

 

• Trigger source: 트리거의 근원
• Trigger: 특정 이벤트
• Environment: 시스템 상태
• System artifact: 트리거로 인해 영향 받는 것
• Response: 트리거에 대한 리액션
• Response measure: evaluation model for measurement

 

 

🔸 Sample(Example scenarios)

 

• Application scenarios: 시스템을 배경지식 없이 처음 이용할 때 필요한 기능 사용을 15분 내로 할 수 있도록
• Change scenarios: 새로운 기능 개발이 30일 이내에 가능할 수 있도록
• Stress or limit scenarios: DB에 결함이 있을 때, 시스템은 특정 성능과 capacity를 가지고 동작할 수 있도록
• Performance scenarios: 시스템 실행 동작의 영향성
• Reliability scenarios: 결함 감지 & 수정이 가능하도록

 

 

🔸 Ways of achievement for quality requirements(quality analysis)

 

1. Creating Quality tree
2. Discussing or Writing quality scenarios
3. Quantitative dependency analysis
4. Analyze architecture models
5. Check log files

 

 

 

 

Reference

Mahbouba Gharbi & Arne Koschel & Andreas Rausch - Software Architecture FundamentalsA Study Guide for the Certified Professional for Software Architecture

 

위 책 내용을 챕터별 중요한 포인트 위주로 정리한 자료입니다.

스스로 공부하기 위한 요점정리 노트이므로 상업적인 사용 목적은 전혀 없음을 알려드립니다:)

 

이 시험에 대한 정보 및 각종 자료는 아래 사이트에서 확인하실 수 있습니다. ⬇⬇⬇

https://www.isaqb.org/downloads/

https://isqi.org/en/