• Agile Manifesto, we have to come value:

o Individuals & interaction over process and tools

o Working software over comprehensive documentation
o Customer collaboration over contract negotiation
o Responding to change over following plan
• Twelve Agile Principles
1. Early and continuous delivery of valuable software
2. Embrace change
3. Frequent delivery
4. Cooperation
5. Autonomy and motivation
6. Better communication - face-to-face conversation
7. Working software is the primary measure of progress
8. Stable work environments - maintain a constant pace
9. Quality assurance - technical excellence and good design
10. Simplicity
11. The best architectures, requirements, and designs emerge from self-
organizing teams
12. Reflection and adjustment
• two activities that can add time to the project schedule
✓ Up-front design work on the architecture and up-front risk
identification, planning, and resolution work
✓ Rework due to fixing defects and addressing modification requests
RM: The bigger the software project, the greater the need for
investing resources on upfront architecture and design; For smaller
projects you gain little from upfront design
• Guidelines for the Agile Architect | Incremental Commitment Model
principles
- Commitment and accountability of success-critical stakeholders
- Stakeholder “satisficing” (meeting an acceptability threshold) based on
success-based negotiations and tradeoffs
- Incremental and evolutionary growth of system definition and
stakeholder commitment
- Iterative system development and definition
• Architecturally Significant Requirement (ASR): is a requirement that will
have a profound effect on the architecture
o If a requirement affects the making of a critical architectural design
decision, it is by definition an ASR
• Systematic means to identifying the ASRs
✓ from requirements documents
✓ by interviewing stakeholders
✓ by understanding the business goals
✓ Capturing ASR in a utility tree
• Quality Attribute Workshop (QAW): a facilitated, stakeholder-focused
method to generate, prioritize, and refine quality attribute scenarios before
the software architecture is completed
• QAW Steps
1. QAW Presentation and Introductions
2. Business/Mission Presentation
3. Architectural Plan Presentation
4. Identification of Architectural Drivers.
5. Scenario Brainstorming.
6. Scenario Consolidation
7. Scenario Prioritization
8. Scenario Refinement
• Business goal scenario, 7 parts
o Goal-source
o Goal-subject
o Goal-object
o Environment
o Goal
o Goal-measure
o Pedigree and value - degree of confidence the person who stated the
goal has in it, goal’s volatility and value
• PALM (Pedigreed Attribute elicitation Method): seven-step lightweight
method based on goal-oriented requirements engineering that begins with
list of business goals and elicits specific business goals
- carried out over a day and a half in a workshop.
- Attended by architect(s) and stakeholders
• PALM Steps
1. PALM overview presentation
2. Business drivers presentation
3. Architecture drivers presentation
4. Business goals elicitation
5. Identification of potential quality attributes from business goals
6. Assignment of pedigree to existing quality attribute drivers
7. Assignment of pedigree to existing quality attribute drivers
8. Exercise conclusion
• An ASR must have the following characteristics
✓ A profound impact on the architecture
✓ A high business or mission value
• Utility Tree: way to record ASRs all in one place; Establishes priority of each
ASR in terms of Impact on architecture Business or mission value; it
captures scenarios
- Root of tree - placeholder node called “Utility”
- Second level of tree - broad QA categories
- Third level of tree - refines those categories
• Attribute-Driven Design Method (ADD): An iterative method. At each
iteration you:
- Choose a part of the system to design
- Organize all the architecturally significant requirements for that part
- Generate and test a design for that part
• Steps of ADD
1. Choose an element of the system to design
2. Identify the ASRs for the chosen element
3. Generate a design solution for the chosen element
4. Inventory remaining requirements and select the input for the next
iteration
5. Repeat steps 1–4 until all the ASRs have been satisfied

• View: a representation of an entire system from the perspective of a

related set of concerns
- used to describe the system from the viewpoint of different
stakeholders
• Principle of architecture documentation: Documenting an architecture is a
matter of documenting the relevant views and then adding documentation
that applies to more than one view
• Documentation package consists of
➢ Views
➢ Documentation beyond views
• Documenting a View
o Section 1: The Primary Presentation
- shows the elements and relations of the view
o Section 2: The Element Catalog
- details those elements depicted in the primary presentation
o Section 3: Context Diagram
- shows how the system or portion of the system depicted in this view
relates to its environment (scope of a view)
 o Section 4: Variability Guide
- shows how to exercise any variation points that are a part of the
architecture shown in this view
o Section 5: Rationale
- explains why the design reflected in the view came to be; why the
design is as it is
• Documenting Information Beyond Views
o Section 1: Documentation Roadmap
- tells the reader what information is in the documentation and where
o Section 2: How a View Is Documented
o Section 3: System Overview
o Section 4: Mapping Between Views
- shows how to exercise any variation points that are a part of the
architecture shown in this view
o Section 5: Rationale
- Documents the architectural decisions that apply to more than one
view
o Section 5: Directory
- Set of reference material that helps readers find more information
quickly

• Four techniques to help keep the code and the architecture consistent
➢ Embedding the design in the code
➢ Frameworks
➢ Code templates
➢ Keeping code and architecture consistent (i.e., avoiding “architecture
erosion”)
• architect should be involved in a wide variety of test activities
✓ Test planning
✓ Test development.
✓ Test interpretation.
✓ Test harness creation