commit c268b7d57667e1b89b943f2982f7e666dd54d71b
parent 39dd31aeb45a9e06d9f9fe48e0d4f779f6fc2c41
Author: Alex Balgavy <alex@balgavy.eu>
Date: Tue, 24 Nov 2020 17:15:50 +0100
Updated software arch notes
Diffstat:
3 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/content/software-architecture/Architecture & quality/763b9ad1accc441f86cd948bc2e76a21.png b/content/software-architecture/Architecture & quality/763b9ad1accc441f86cd948bc2e76a21.png
Binary files differ.
diff --git a/content/software-architecture/Architecture & quality/index.md b/content/software-architecture/Architecture & quality/index.md
@@ -0,0 +1,91 @@
++++
+title = 'Architecture & quality'
++++
+# Architecture & quality
+## Quality
+Architecture is critical for realization of qualities.
+The implementation details of architecture achieve the qualities.
+Qualities are not achieved in isolation, but they interact.
+
+Why not quality attributes?
+- not testable
+- concerns of QAs overlap
+- each QA community has own vocabulary
+
+Approaches to defining quality:
+- transcendental: I can't define it, but know it when I like it
+- product-based: related to attributes of software
+- user-based: fitness for use, user preferences
+- manufacturing-based: conformance to specs
+- value-based: deals with costs and profits
+
+ISO 25010 ("product characteristics"): functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability
+
+How do you go from quality to architecture?
+- decompose QA scenarios into tactics
+ - tactics: design decisions influencing achievement of quality attribute _response_
+ - one tactic focuses on one QA (no tradeoffs), tactics are packaged in design patterns (which do have tradeoffs)
+ - design pattern: recurring structure of communicating components that solve general design problem in a particular context (like "model-view-controller")
+ - tactics can influence/refine other tactics, can be combined or grouped hierarchically
+ - example: "active redundancy" to increase availability
+- verify achievement of qualities using "design checklists", systematically consider each category of decisions for an attribute (allocation of responsibilities, coordination model, data model, management of resources, mapping among architectural elements, binding time decisions, choice of technology)
+
+## Evaluation
+Why evaluate? The sooner you start testing, the more money you save.
+
+Two questions:
+- is this architecture suitable?
+- which architecture is most suitable?
+
+Analysis techniques:
+- questioning: how does system react to various situations, make use of scenarios
+- measuring: rely on quantitative measures, e.g. architecture metrics and simulation
+
+### Architecture documentation review (structured approach)
+- establish purpose of review (e.g. is arch design ready for dev activity)
+- establish subject of review (which artifacts are needed)
+- build/adopt appropriate question set
+ - question set name (e.g. "capturing right stakeholders and concerns")
+ - purpose (e.g. "is list of stakeholders appropriate, are concerns complete, do stakeholders believe their interests have been captured")
+ - stakeholders and concerns (e.g. "all with substantial stake")
+ - questions
+ - respondents
+ - expected answers
+ - criticality
+ - advice
+- tailor question set
+- plan review
+- perform review
+- analyze and summarize results
+
+### ATAM (Architecture Tradeoff Analysis Method)
+- designed for evaluators not familiar with architecture/goals, system not yet built, many stakeholders
+- phases:
+ 0. partnership, preparation (evaluation team leadership + key decision makers, informally)
+ 1. evaluation (evaluation team + decision makers analyse architecture, in one day)
+ 1. present method
+ 2. present business drivers (project manager)
+ 3. present architecture (lead architect)
+ 4. identify architectural approaches (patterns, tactics)
+ 5. generate quality attribute utility tree (+ priority and difficulty)
+ 6. analyze architectural approaches (scenario walkthrough)
+ 2. evaluation (evaluation + decision makers + stakeholders, two days)
+ 1. brainstorm and prioritize scenarios
+ 2. analyze architectural approaches
+ 3. present results (including risk themes)
+ 3. follow up (evaluation team + client)
+
+
+
+Important concepts:
+- sensitivity point: decision/property critical for a quality attribute
+- tradeoff point: decision/property affecting more than one quality attribute
+- risk: decision/property that is potential problem
+- nonrisk: architectural decision that is deemed safe
+- risk theme: overarching theme (from full set of discovered risks) identifying systemic weakness in architecture/process/team
+
+### Architecture metrics
+Analyzability:
+- system breakdown: 1 component is bad, too many components is bad. need somewhere in between
+- uniform size of components: the more, the better
+- so, component balance metric = (system breakdown) × (component size uniformity)
diff --git a/content/software-architecture/_index.md b/content/software-architecture/_index.md
@@ -7,3 +7,4 @@ title = 'Software Architecture'
- [Requirements](requirements/)
- [Architecture representation](architecture-representation/)
- [Architecture design](architecture-design/)
+- [Architecture & quality](architecture-quality/)
