index.md (4464B)
1 +++ 2 title = 'Architecture & quality' 3 +++ 4 # Architecture & quality 5 ## Quality 6 Architecture is critical for realization of qualities. 7 The implementation details of architecture achieve the qualities. 8 Qualities are not achieved in isolation, but they interact. 9 10 Why not quality attributes? 11 - not testable 12 - concerns of QAs overlap 13 - each QA community has own vocabulary 14 15 Approaches to defining quality: 16 - transcendental: I can't define it, but know it when I like it 17 - product-based: related to attributes of software 18 - user-based: fitness for use, user preferences 19 - manufacturing-based: conformance to specs 20 - value-based: deals with costs and profits 21 22 ISO 25010 ("product characteristics"): functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability 23 24 How do you go from quality to architecture? 25 - decompose QA scenarios into tactics 26 - tactics: design decisions influencing achievement of quality attribute _response_ 27 - one tactic focuses on one QA (no tradeoffs), tactics are packaged in design patterns (which do have tradeoffs) 28 - design pattern: recurring structure of communicating components that solve general design problem in a particular context (like "model-view-controller") 29 - tactics can influence/refine other tactics, can be combined or grouped hierarchically 30 - example: "active redundancy" to increase availability 31 - 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) 32 33 ## Evaluation 34 Why evaluate? The sooner you start testing, the more money you save. 35 36 Two questions: 37 - is this architecture suitable? 38 - which architecture is most suitable? 39 40 Analysis techniques: 41 - questioning: how does system react to various situations, make use of scenarios 42 - measuring: rely on quantitative measures, e.g. architecture metrics and simulation 43 44 ### Architecture documentation review (structured approach) 45 - establish purpose of review (e.g. is arch design ready for dev activity) 46 - establish subject of review (which artifacts are needed) 47 - build/adopt appropriate question set 48 - question set name (e.g. "capturing right stakeholders and concerns") 49 - purpose (e.g. "is list of stakeholders appropriate, are concerns complete, do stakeholders believe their interests have been captured") 50 - stakeholders and concerns (e.g. "all with substantial stake") 51 - questions 52 - respondents 53 - expected answers 54 - criticality 55 - advice 56 - tailor question set 57 - plan review 58 - perform review 59 - analyze and summarize results 60 61 ### ATAM (Architecture Tradeoff Analysis Method) 62 - designed for evaluators not familiar with architecture/goals, system not yet built, many stakeholders 63 - phases: 64 0. partnership, preparation (evaluation team leadership + key decision makers, informally) 65 1. evaluation (evaluation team + decision makers analyse architecture, in one day) 66 1. present method 67 2. present business drivers (project manager) 68 3. present architecture (lead architect) 69 4. identify architectural approaches (patterns, tactics) 70 5. generate quality attribute utility tree (+ priority and difficulty) 71 6. analyze architectural approaches (scenario walkthrough) 72 2. evaluation (evaluation + decision makers + stakeholders, two days) 73 1. brainstorm and prioritize scenarios 74 2. analyze architectural approaches 75 3. present results (including risk themes) 76 3. follow up (evaluation team + client) 77 78  79 80 Important concepts: 81 - sensitivity point: decision/property critical for a quality attribute 82 - tradeoff point: decision/property affecting more than one quality attribute 83 - risk: decision/property that is potential problem 84 - nonrisk: architectural decision that is deemed safe 85 - risk theme: overarching theme (from full set of discovered risks) identifying systemic weakness in architecture/process/team 86 87 ### Architecture metrics 88 Analyzability: 89 - system breakdown: 1 component is bad, too many components is bad. need somewhere in between 90 - uniform size of components: the more, the better 91 - so, component balance metric = (system breakdown) × (component size uniformity)