2. Agenda
The role of sw architecture in the
development process
What is a software development
process and how it is described
Traditional vs iterative process models
Characteristics and benefits of
architecture-centric sw development
Agile Processes and Architecture
5. Short History of Development Methods
AGILE e.g. XP
(Kent Beck)
RUP (Rational) user
Incremental,
driven, low process
RAD Object oriented,
(James Martin)iterative, time-boxed,
user driven
Prototyping, RUP
iterative, time-boxed,
SPIRAL MODEL user driven RAD
WATERFALL (Royce) (Barry Boehm)
V-MODEL (Anon)
Requirements, design Iterative Spiral Model
implementation, Aligns testing to
verification & Waterfall
maintenance development V-Model
Waterfall
1960 1970 1980 85 91 98 99
6. Traditional process
Waterfall
Requirements Review
Design Review
Code Review
Test Review
Deploy
7. Waterfall characteristics
Delays confirmation of
critical risk resolution
Waterfall Process Measures progress by
Requirements assessing work-products
analysis
that are poor predictors
Design
of time-to-completion
Code and unit test
Subsystem integration
Delays and aggregates
integration and testing
System test
Precludes early
deployment
Frequently results in
major unplanned
iterations
8. V Model
Level of Detail
Requirements Acceptance
Low Elicitation Testing
System
Analysis
Testing
Design Integration Testing
Object Design Unit Testing
High
Project Time
9. The spiral model
Determine objectives, Evaluate alternatives,
alternatives, & constraints identify & resolve risks
Risk
analysis
Risk
analysis
Risk
analysis
P1
Prototype3
Prototype2
Prototype1
Requirements Concept of
plan operation Software
System
Requirements Product Detailed
Design Design
Development Requirements
plan validation
P2
Code
Integration Design Unit Test
plan validation Develop & verify
Plan next phase next level product
Integration & Test
Acceptance
Test
10. The spiral model: phases
Determine objectives
Each phase has specific objectives
Evaluate alternatives, reduce risks
Each risk has to be identified and managed
Develop and verify
The process model can be generic
Each phase includes development and verification
Plan next phase
Review the project and plan its future
11. Exercise
Name the pros and cons of each of the
following software process models
waterfall model
v-model
spiral model
Specifically focus on their ability to solicit and
react to customer requirement approval and
changes
12. Iterative Development
Requirements
Analysis & Design
Planning
Implementation
Initial
Planning Management
Environment
Test
Evaluation
Deployment
Each iteration
results in an
executable release
15. Iterative Development
Phase - the time between two major project milestones,
during which a well-defined set of objectives is met,
artifacts are completed, and decisions are made to
move or not into the next phase. A phase includes one
or more iterations.
Iteration – a time period in which a number of
predefined tasks are performed and results are
evaluated to feedback to the next iteration. An iteration
results in a release.
Release (external) – a coherent set of completed
functionalities (code and other artifacts) that is useful to
the stakeholders of the system
Release (internal) - a coherent set of completed
functionalities that is used only by the development
organization, as part of a milestone, or for a
demonstration to users
16. Risk: waterfall vs iterative
Waterfall Risk
Risk
Risk Reduction
Iterative Risk
Time
17. Test each iteration
Iteration 1 Iteration 2 Iteration 3 Iteration 4
UML Model
and
Implementation
Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4
Tests
21. Benefits of Iterative Development
A software project evolves in iterations to:
Mitigate risk
Accommodate change
Learn along the way
Improve the quality of the artifacts
Exploit reuse thus increasing productivity
22. Problems with iterative processes
How iterative? How many rounds?
Agile or rigid?
Heavy weight (many rules, practices
and documents) vs. lightweight (few
rules and practices)
Disciplined vs ad hoc (or chaotic)
23. A story
A pig and a chicken are walking down a road.
The chicken looks at the pig and says, "Hey, why don't
we open a restaurant?" The pig looks back at the
chicken and says, "Good idea, what do you want to call
it?" The chicken thinks about it and says, "Why don't we
call it 'Ham and Eggs'?" "I don't think so," says the pig,
"I'd be committed but you'd only be involved."#
24. Committed vs involved
The core roles in development teams
are those committed to the project in
the process - they are the ones
producing the product: product owner,
team, project manager
The ancillary roles in teams are those
with no formal role and infrequent
involvement in the process - and must
nonetheless be taken into account
26. Agile developments methods
Some agile sw development methods
Dynamic System Development Methodology and
RAD (www.dsdm.org, 1995)
Scrum (Sutherland and Schwaber, 1995)
XP - eXtreme Programming (Beck, 1999)
Feature Driven Development (DeLuca, 1999)
Adaptive Sw Development (Highsmith, 2000)
Lean Development (Poppendieck, 2003)
Crystal Clear (Cockburn, 2004)
Agile Unified Process (Ambler, 2005)
27. Agile ethics
www.agilemanifesto.org
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we prefer the items on the left.
Management can tend to prefer the things on the
right over the things on the left
29. Agile development
Agile development uses feedback to make
constant adjustments in a highly collaborative
environment
There are many agile development methods;
most minimize risk by developing software in
short amounts of time#
Software developed during one unit of time is
referred to as an iteration, which typically
lasts from hours or few days#
Each iteration passes through a full software
development cycle
34. Architectural Effort During the Lifecycle
Inception Elaboration Construction Transition
time
Majority of architectural design activities
35. Little dedicated architectural effort
Inception Construction Transition
time
Minimal pure
Ideal realm of agile
Architectural
practices
Activities
36. Iterations and Phases
Inception Elaboration Construction Transition
Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition
Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration
Internal Releases with Releases with main
focus on architecture focus on features
An architectural iteration focuses on major architectural elements,
resulting in a baseline architectural prototype at the end of elaboration
37. SCRUM
Daily Scrum Meeting:
15 minutes
Team-Level Each teams member answers 3 questions:
1) What did I do since last meeting?
Planning Every 24hrs 2) What obstacles are in my way?
3) What will I do before next meeting?
Every Iteration
4-6 weeks
Working Software
Prioritised Delivered
Iteration
Scope Requirements
Requirements
Prioritised Requirements &
Requirements Features Backlog
Requirements
Requirements
Applying Agile:
Continuous integration; continuously monitored progress
38. Agile: eXtreme Programming
The ethic values of eXtreme Programming
Communication
Simplicity
Feedback
Courage
Respect (added in the latest version)
39. eXtreme Programming (XP)
“Extreme Programming is a discipline of software
development based on values of simplicity,
communication, feedback, and courage” Kent Beck
Proponents of XP and agile methodologies regard
ongoing changes to requirements as a natural and
desirable aspect of sw projects
They believe that adaptability to changing requirements
at any point during the lifecycle is a better approach than
attempting to define all requiremenmts at the beginning
and then expending effort to control changes to the
requirements
! ! !www.extremeprogramming.org!
40. The 12 Practices of XP
1. Metaphor
2. Release Planning
3. Testing
4. Pair Programming
5. Refactoring
6. Simple Design
7. Collective Code
Ownership
8. Continuous Integration
9. On-site Customer
10. Small Releases
11. 40-Hour Work Week
12. Coding Standards
41. Metaphor
Programmers define a handful of classes and
patterns that shape the core business problem
and solution, like a primitive architecture
Gives the team a consistent picture of
describing the system, where new parts fit, etc.
Example: payroll . . . The paycheck goes down
an assembly line and pieces of information are
added
Sometimes, you just can’t come up with a
metaphor
43. Release Planning
• Requirements via User Stories
• Short (index-card length) natural language
description of what a customer wants
• A commitment for further conversation
• Prioritized by customer
• Resource and risk estimated by developers
• “The Planning Game”
• Highest priority, highest risk user stories
included in early “time boxed” increments
• Play the Planning Game after each
increment
44. User stories: examples
Good:
A user can post her cv
A user can search for jobs
A company can post new job openings
A user can limit who can see her resume
Bad:
The software will be written in C++
The program will connect to the database
through a connection pool
47. Testing
Test-Driven
Development (TDD)
Write tests before code
Tests are automated
Often use xUnit
framework
Must run at 100% before
proceeding
Acceptance Tests
Written with the
customer
Act as “contract”
Measure of progress
48. Pair Programming
• Two software engineers work on
one task at one computer
• One engineer, the driver, has
control of the keyboard and
mouse and creates the
implementation
• The other engineer, the navigator,
watches the driver’s
implementation to identify defects
and participates in on-demand
brainstorming
• The roles of driver and observer
are periodically rotated between
the two software engineers
49. Simple Design
• No Big Design Up Front (BDUF)
• “Do The Simplest Thing That Could Possibly
Work”
• Including documentation
• “You Aren’t Gonna Need It” (YAGNI)
• CRC cards (optional)
50. Refactoring
Refactoring: as you write code, there are
times when you need to change its structure -
usually to conform to a pattern, to facilitate
extensibility, or just because your code got
long and messy
Improve the design of existing code without
changing functionality
Simplify code, remove duplicate code
Search actively all opportunity for abstraction
Relies on testing to ensure nothing breaks in
the process of refactoring
51. Collective Code Ownership
Code to belongs to the project, not to an
individual engineer
As engineers develop required
functionality, they may browse into and
modify any class
52. Continuous Integration
Each pair writes up its own unit test cases and
code for a task (part of a user story)
Pair tests units of code to 100%
Pair integrates
Pair runs ALL integrated unit test cases to
100%
Pair moves on to next task with clean slate and
clear mind
Should happen once or twice a day; prevents
“Integration Hell”
53. On-Site Customer
Customer available on site to clarify
stories and to make critical business
decisions
Developers don’t make assumptions
Developers don’t have to wait for
decisions
Face to face communication minimizes
the chances of misunderstanding
54. Small Releases
• Timeboxed
• As small as possible, but still delivering
business value
• No releases to ‘implement the database’
• Get customer feedback early and often
Do the planning game after each iteration
• Do they want something different?
• Have their priorities changed?
55. 40h work per week (sustainable pace)
• Kent Beck says, “ . . . fresh and eager every
morning, and tired and satisfied every night”
• Burning the midnight oil kills performance
• Tired programmers write poor code and make
more mistakes, which slows you down more in
the long run
• If you mess with people’s personal lives (by
taking it over), in the long run the project will
pay the consequences
56. Coding standards and conventions
Use Coding Conventions
Considering Pair Programming, Refactor Mercilessly,
and Collective Code Ownership . . . need to easily find
your way around (other people’s) code
Method Commenting
Priority placed on intention-revealing code
If your code needs a comment to explain it, rewrite it
If you can't explain your code with a comment, rewrite it
57. The 13th Practice: The Stand Up Meeting
Start day with 15-minute meeting
• Everyone stands up (so the meeting stays
short) in circle
• Going around the room everyone says
specifically:
• What they did the day before
• What they plan to do today
• Any obstacles they are experiencing
• Can be the way pairs are formed
58. Research findings on XP
Strong anecdotal evidence from industry
“We can produce near defect-free code in less than
half the time.”
Empirical Study
Pairs produced higher quality code
15% more test cases passed (difference statistically significant)
Pairs completed their tasks in about half the time
58% of elapsed time (difference not statistically significant)
Most programmers reluctantly embark on pair
programming
Pairs enjoy their work more (92%)
Pairs feel more confident in their work products (96%)
59. Agile Misconceptions
Agile means: “letting the programming team do whatever they
need to with no project management, and no architecture, allowing a
solution to emerge, the programmers will do all the testing necessary
with Unit Tests…”
60. Process control variables
Time – duration of the project
Quality – the requirements for ‘correctness’
Resources – personnel, equipment, etc.
Scope – what is to be done; the features to
be implemented
These process control variables are very
difficult to control all; the simplest and most
effective to control is scope
61. Self-test questions
What are the advantages of an iterative
process?
What is an agile process?
Which are the potential problems and
risks with user involvement?
What is the planning game?
What is a user story?
What are the major best practices in XP?
62. References
Ambler, Agile Modern Driven Development with
UML2 (The Object Primer 3ed.), Cambridge Univ.
Press, 2004
Beck and Fowler, Planning Extreme Programming,
Addison Wesley, 2000
Cockburn, Agile Software Development, 2000
Larman, Agile and Iterative Development: a
managers’ guide, Addison Wesley, 2003
Schwaber, Agile Project Management with Scrum,
Microsoft Press, 2004
Shore and Warden, The Art of Agile Development,
O’Reilly, 2007
