1. Software Architecture –
Centric Methods and
Agile Development
By
SATHISHKUMAR G
(sathishsak111@gmail.com)

2. The Agile Approach
• Feedback – Not just for stereos anymore
• Adaptable – Just in case you haven’t made
up your mind
• Simplicity – Let’s keep it that way
• Small Groups – Because the boss is cheap

3. The Agile Approach
• Short Development Iterations
• Plan
• Gather Requirements
• Design
• Code
• Test
• Document

4. The Agile Approach
• Iteration’s done – But the software isn’t.
• At least it works…Sort of…
• Resolution is the solution

5. The Agile Approach -
Extreme Programming (XP)
• Planning – User Stories, Prioritizing
• Testing – Test comes before code
• Implementation – Simplest code to fulfill
the test
• Design – System metaphors, spike
solutions, CRC cards

6. Extreme Programming (XP) –
Criticisms
• Doesn’t scale to large dev teams or products
• Success is a function of the dev teams
experience
• Not for critical systems
• Tends to overlook software quality
attributes
• Customer On-Site necessary

7. Software Architecture Centric
Methods to the Rescue!!!!
• Architecture Centric Activities
• Emphasize quality attributes
• Focus early on architecture design decisions

8. The Architecture Centric
Activities
• Quality Attribute workshop
• Attribute Driven Design
• Architecture Trade-off Analysis Method
(ATAM)
• Cost-Benefit Analysis Method

9. Quality Attribute Workshop
• Goal: To identify requirements
• Held early in development
• Includes stakeholders
• Outputs:
• Business Goals
• Quality Attribute Scenarios and Use Cases
• Scenarios are six fold (stimulus, source of the
stimulus, artifact, environment, response, and
response measure)

10. Attribute Driven Design
• Goal: To localize the effects of design changes
• Focuses on the overall system structure that the quality
attributes shape
• Choice of architectural tactics to satisfy quality
scenarios
• Outputs:
• Course Grain Architectural Structure
• Generate and Test architectural design model

11. Architecture Trade-off
Analysis Method (ATAM)
• Goal: Assess architectural decisions’
consequences with respect to requirements
and business goals
• Helps stakeholders ask the right questions
to discover problematic architectural
decisions

12. Cost-Benefit Analysis Method
(CBAM)
• Goal: To make the decisions made during
the ATAM part of the roadmap by
assigning priorities, costs and benefits with
each architectural decision
• Business consequences allow the dev team
to make informed choices among
architectural options

13. Sample Example: Bank ATM
• From XP’s user stories we receive
• Feature requirements
• From the QAW process we identify
additional quality attributes that need to be
satisfied:
• Modifiability
• Extensibility
• Performance

14. Sample Example: Bank ATM
Quality Attribute Workshop
• Modifiability Attribute Scenario I:
• A developer wants to add a new auditing
business rule at design time in 10 person-days
without affecting other functionality
• Modifiability Attribute Scenario II:
• A system administrator wants to employ a new
database in 18 person-months without affecting
other functionality

15. Sample Example: Bank ATM
Quality Attribute Workshop
• Modifiability Attribute Scenario III
• A developer needs to add a Web-based client in
90 person-days without affecting the existing
ATM client’s functionality

16. Modifiability Scenario I
• Stimulus – Adding a Business Rule
• Source – The Developer
• Artifact – Business Rule System
• Environment – New Business Rule
• Response – Business Rule added within 10
Days
• Response Measure – Business Rule is
added and Existing functionality is
unchanged

17. Modifiability Scenario II
• Stimulus – Employing a new Database
• Source – A System Administrator
• Artifact – Data Organization and Storage
• Environment – New Platform
• Response – Database employed within 18 person-
months
• Response Measure – Database Deployed and In
Use. Existing functionality is unchanged

18. Modifiability Scenario III
• Stimulus – Adding an Additional Client
• Source – The Developer
• Artifact – User Interface
• Environment – New Capability
• Response – Business Rule added within 10 Days
• Response Measure – Business Rule is added and
Existing functionality is unchanged

19. Attribute Driven Design Results
• The ADD method localizes the effect of this
design change by using the following tactics:
• Localize Changes – Identifies three separate
components of the system, Business Rules, Client, and
Database
• Use an intermediary
• These components should be separate
• The Business Rules and Database should communicate
through an abstract interface (ODBC)
• There should be a translation layer between the client and the
business rules (XML)

20. Cost-Benefit Analysis Method
• CBAM helps architects consider the return
on investment of any architectural decision
and provides guidance on the economic
trade-offs involved.
• Sample – Performance Quality Attributes in
the Sample Problem

21. Summary
• Architecture-centric methods provide explicit and
detailed guidance on eliciting architectural
requirements, designing those requirements into
the system, and analyzing the resulting design.
The results of which can be tailored to an agile
approach.
• This tactic can help to resolve one of agile
developments largest weaknesses. Improving
overall quality of the final product.

22. Thank you