8 - architetture software - architecture centric processes
DESCRIPTION
TRANSCRIPT
Paolo Ciancarini
Architecture-centric processes
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
The role of architecture in sw lifecycle
Short History of Development Methods
WATERFALL (Royce) Requirements, design implementation, verification & maintenance
1960 85 91 1980 1970
V-MODEL (Anon) Aligns testing to Waterfall development
SPIRAL MODEL (Barry Boehm) Iterative
RAD (James Martin) Prototyping, iterative, time-boxed, user driven
RUP (Rational) Object oriented, iterative, time-boxed, user driven
AGILE e.g. XP (Kent Beck) Incremental, user driven, low process
98 99
Waterfall V-Model
Spiral Model
RAD
RUP
Traditional process
Waterfall
Requirements
Design
Code
Test
Review
Review
Review
Deploy
Review
Waterfall characteristics Delays confirmation of
critical risk resolution Measures progress by
assessing work-products that are poor predictors of time-to-completion
Delays and aggregates integration and testing
Precludes early deployment
Frequently results in major unplanned iterations
Code and unit test
Design
Subsystem integration
System test
Waterfall Process Requirements
analysis
V Model Level of Detail
Project Time
Low
High
Acceptance Testing
Requirements Elicitation
Analysis
Design
System Testing
Object Design Unit Testing
Integration Testing
The spiral model Determine objectives,alternatives, & constraints
Evaluate alternatives,identify & resolve risks
Develop & verifynext level productPlan next phase
Requirements
Development
Integration
plan
plan
plan
Requirements
Design
validation
validation
Software SystemProduct
Riskanalysis
Riskanalysis
Prototype1Prototype2
Prototype3
Riskanalysis
Concept ofoperation
RequirementsDesign
Code
Unit Test
Integration & TestAcceptance
DetailedDesign
P1
P2
Test
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
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
Iterative Development
Initial Planning
Planning
Requirements
Analysis & Design
Implementation
Deployment
Test
Evaluation
Management Environment
Each iteration results in an
executable release
Iterative process
Iterative Requirements
Design
Code
Testing
Assess
Requirements
Design
Code
Testing
Assess
Requirements
Design
Code
Testing
Assess
Iteration 1 Iteration 2 Iteration 3
Deploy Deploy Deploy
Waterfall vs. iterative
Requirements
Design
Code
Test
Review
Review
Review
Deploy
Review
Requirements
Design
Code
Testing
Assess
Requirements
Design
Code
Testing
Assess
Requirements
Design
Code
Testing
Assess
Iteration 1 Iteration 2 Iteration 3
Deploy Deploy Deploy
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
Risk Reduction
Time
Ris
k
Waterfall Risk
Iterative Risk
Risk: waterfall vs iterative
UML Model and
Implementation
Tests
Iteration 1
Test Suite 1
Iteration 2
Test Suite 2
Iteration 4
Test Suite 4
Iteration 3
Test Suite 3
Test each iteration
Original RUP
RUP is iterative
http://www-306.ibm.com/software/rational/sw-library/
Discussion
Evaluate the pros and cons of iterative processes
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
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)
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."#
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
The Planning Spectrum
Source: B. Boehm “Get Ready For Agile Methods, With Care”, IEEE Computer, Jan 2002
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)
Agile ethics
www.agilemanifesto.org
Management can tend to prefer the things on the right over the things on the left
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.
Traditional vs agile team
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
Agile development: architecture-centric
The Generic Agile Lifecycle
Agile practices
Agile Unified Process
Architectural Effort During the Lifecycle
time
Inception Elaboration Construction Transition
Majority of architectural design activities
Little dedicated architectural effort
time
Inception Construction Transition
Minimal pure Architectural
Activities
Ideal realm of agile practices
An architectural iteration focuses on major architectural elements, resulting in a baseline architectural prototype at the end of elaboration
Preliminary Iteration
Architect. Iteration
Architect. Iteration
Devel. Iteration
Devel. Iteration
Devel. Iteration
Transition Iteration
Transition Iteration
Inception Elaboration Construction Transition
Internal Releases with focus on architecture
Iterations and Phases
Releases with main focus on features
Working Software Delivered
Requirements Prioritised Requirements & Features “Backlog” Requirements
Requirements Requirements
Requirements
Prioritised Iteration Scope
Daily Scrum Meeting: 15 minutes Each teams member answers 3 questions: 1) What did I do since last meeting? 2) What obstacles are in my way? 3) What will I do before next meeting?
Team-Level Planning Every 24hrs
Every Iteration 4-6 weeks
Applying Agile: Continuous integration; continuously monitored progress
SCRUM
Agile: eXtreme Programming The ethic values of eXtreme Programming Communication Simplicity Feedback Courage Respect (added in the latest version)
eXtreme Programming (XP) “Extreme Programming is a discipline of software
development based on values of simplicity, communication, feedback, and courage”
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!
Kent Beck
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
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
Exercise
Find other useful metaphors
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
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
User story: example
User story testing: example
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
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
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)
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
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
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”
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
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?
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
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
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
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%)
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…”
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
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?
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
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!
Questions?