The document discusses the evaluation of software architectures, outlining various methods including ATAM, SAAM, and ARID for validating architecture against quality attributes like performance and security. It emphasizes the importance of evaluating architecture early in the design phase to prevent costly errors and to ensure stakeholder alignment. The output of architecture evaluations includes prioritized quality attributes, risk assessments, and improved documentation, ultimately contributing to project success.

1. Evaluating a
Software
Architecture
By Desalegn Bekele

2. Evaluating a Software
Architecture
• How can you be sure whether the architecture
chosen for your software is the right one?
• How can you be sure that it won't lead to
calamity?

3. Outline
• What is an Architecture?
• How to validate a software architecture?
• Why Evaluate an Architecture?
• When Can an Architecture Be Evaluated?
• Who's Involved?
• What Are the Outputs of an Architecture
Evaluation?
• What Are the Benefits and Costs?
• Conclusion

4. What is an Architecture?
• Is the foundation for any software system.
• will allow or preclude just about all of a system's quality
attributes: Modifiability, performance, security, availability,
reliability.

5. How to validate a software
architecture?
• A suite of three methods, all developed at the Software
Engineering Institute.
• ATAM: Architecture Tradeoff Analysis Method
• SAAM: Software Architecture Analysis Method
• ARID: Active Reviews for Intermediate Designs

6. Architecture Tradeoff Analysis
Method (ATAM)
• provides a principled way to evaluate a software
architecture's fitness with respect to multiple competing
quality attributes.
• is a spiral model of design: one of assuming candidate
architectures followed by analysis and risk mitigation,
leading to refined architectures.
• The ATAM process consists of gathering stakeholders
together to analyze business drivers (system
functionality, goals, constraints, desired non-functional
properties) and from these drivers extract quality
attributes that are used to create scenarios

7. Steps of the ATAM Process
1-7
ATAM[2]
formally consists of nine steps, outlined below:
1. Present ATAM – Present the concept of ATAM to the
stakeholders, and answer any questions about the process.
2. Present business drivers – everyone in the process presents
and evaluates the business drivers for the system in
question.
3. Present the architecture – the architect presents the high
level architecture to the team, with an 'appropriate level of
detail’
4. Identify architectural approaches – different architectural
approaches to the system are presented by the team, and
discussed.

8. 1-8
5. Generate quality attribute utility tree – define the core
business and technical requirements of the system, and map
them to an appropriate architectural property. Present a scenario
for this given requirement.
6.Analyze architectural approaches – Analyze each scenario,
rating them by priority. The architecture is then evaluated
against each scenario.
7.Brainstorm and prioritize scenarios – among the larger
stakeholder group, present the current scenarios, and expand.
8.Analyze architectural approaches – Perform step 6 again with
the added knowledge of the larger stakeholder community.
9. Present results – provide all documentation to the
stakeholders.

9. Software Architecture Analysis
Method (SAAM)
• aims to predict the quality of a system before it has been
developed.
• the quality of the architecture is validated by analyzing
the impact of predefined scenarios on architectural
components.
• addresses concerns at the architecture design level
which inherently crosscut multiple architectural
components.

10. SAAM
1-10
• Software Architecture Analysis Method (SAAM) is a
methodology used to determine how specific application
quality attributes were achieved and how possible
changes in the future will affect quality attributes based
on hypothetical cases studies.
• Common quality attributes that can be utilized by this
methodology include modifiability, robustness,
portability, and extensibility.

11. Active Reviews for Intermediate
Designs (ARID)
• method for reviewing preliminary software designs (such as
for a component or a subsystem) for suitability in its intended
usage context and environment.
• result in a high-fidelity design review coupled with high-quality
familiarization with the design.

12. Why Evaluate an Architecture?
• The cost to fix an error found during requirements or
early design phases is orders of magnitudes less to
correct than error found in testing.
• Architecture determines the structure of the project:
schedules and budgets, performance goals, team
structure, documentation organization, and testing and
maintenance activities.

13. When Can an Architecture Be
Evaluated?
• The classical application of architecture evaluation occurs
when the architecture has been specified but before
implementation has begun.

14. When Can an Architecture Be
Evaluated?
• Two useful variations from : early and late.
• Early - at any stage in the architecture creation process
to examine those architectural decisions already made
and choose among architectural options.
• Late - takes place when the architecture is nailed down
and the implementation is complete. Mainly used
when architecture is inherited from legacy system.

15. Who's Involved?
• Evaluation team - these are the people who will conduct the
evaluation and perform the analysis.
• Stakeholders - stakeholders are people who have a vested
interest in the architecture and the system.

16. What Are the Outputs of an
Architecture Evaluation?
• Prioritized Statement of Quality Attribute Requirements.
• Having a prioritized statement of the quality attributes serves as
an excellent documentation record to accompany any
architecture and guide it through its evolution.

17. What Are the Outputs of an
Architecture Evaluation?
• Mapping of Approaches to Quality Attributes.
• produces a mapping that shows how the architectural
approaches achieve (or fail to achieve) the desired quality
attributes.

18. What Are the Outputs of an
Architecture Evaluation?
• Risks and Non-risks.
• Risks are potentially problematic architectural decisions.
• Non-risks are good decisions that rely on assumptions that are
frequently implicit in the architecture.

19. What Are the Benefits and
Costs?
• Forces an Articulation of Specific Quality Goals.
• Results in the Prioritization of Conflicting Goals.
• Puts Stakeholders in the Same Room.
• Improves the Quality of Architectural Documentation.
• Uncovers Opportunities for Cross-Project Reuse.

20. Conclusion
• The average architecture evaluation adds no more than a
few days to the project schedule.
• Architecture created in haste will precipitate disaster:
performance goals not met, Security goals falling,
customer dissatisfaction, system that is too hard to
change, and schedules and budgets through the roof.