The document discusses architecture-centric software development processes. It describes traditional waterfall and iterative development models, and notes that iterative models allow for more flexibility to changing requirements. Agile development methods like eXtreme Programming (XP) are discussed, which emphasize iterative development, collaboration, and rapid delivery of working software. Key practices of XP are outlined, including user stories, testing, pair programming, refactoring, and continuous integration. The role of architecture in agile processes is also addressed.

1. Architecture-centric
processes
Paolo Ciancarini

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

3. The role of architecture in sw lifecycle

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

13. Iterative process
 Iterative
Requirements Requirements Requirements
Design Design Design
Code Code Code
Testing Testing Testing
Deploy Deploy Deploy
Assess Assess Assess
Iteration 1 Iteration 2 Iteration 3

14. Waterfall vs. iterative
Requirements Requirements Requirements
Design Design Design
Code Code Code
Requirements
Review
Testing Testing Testing
Deploy Deploy Deploy
Design
Review
Assess Assess Assess
Iteration 1 Iteration 2 Iteration 3
Code
Review
Test
Review
Deploy

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

18. Original RUP

19. RUP is iterative
http://www-306.ibm.com/software/rational/sw-library/

20. Discussion
Evaluate the pros and cons of iterative processes

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

25. The Planning Spectrum
Source: B. Boehm “Get Ready For Agile Methods, With Care”, IEEE Computer, Jan 2002

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

28. Traditional vs agile team

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

30. Agile development: architecture-centric

31. The Generic Agile Lifecycle

32. Agile practices

33. Agile Unified Process

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

42. Exercise
 Find other useful metaphors

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

45. User story: example

46. User story testing: example

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

63. Useful sites
 www.agilemanifesto.org!
 www.agilemodeling.com!
 www.agilejournal.com!
 www.agilealliance.org!
 www.agilekiwi.com!
 www.extremeprogramming.org!
 www.controlchaos.com!
 www.implementingscrum.com!

64. Questions?