Architecture-centric    processes     Paolo Ciancarini
Agenda    The role of sw architecture in the     development process    What is a software development     process and h...
The role of architecture in sw lifecycle
Short History of Development Methods                                                                            AGILE e.g....
Traditional process    Waterfall                 Requirements   Review                                 Design   Review   ...
Waterfall characteristics                                              Delays confirmation of                            ...
V Model Level of Detail        Requirements                                    AcceptanceLow      Elicitation             ...
The spiral modelDetermine objectives,                                                                         Evaluate alt...
The spiral model: phases    Determine objectives        Each phase has specific objectives    Evaluate alternatives, re...
Exercise    Name the pros and cons of each of the     following software process models         waterfall model        ...
Iterative Development                      Requirements                                               Analysis & Design   ...
Iterative process    Iterative                  Requirements   Requirements   Requirements                    Design     ...
Waterfall vs. iterative                                                                 Requirements     Requirements    R...
Iterative Development    Phase - the time between two major project milestones,     during which a well-defined set of ob...
Risk: waterfall vs iterative                                         Waterfall RiskRisk                        Risk Reduct...
Test each iteration                  Iteration 1    Iteration 2   Iteration 3    Iteration 4    UML Model          andImpl...
Original RUP
RUP is iterativehttp://www-306.ibm.com/software/rational/sw-library/
DiscussionEvaluate the pros and cons of iterative processes
Benefits of Iterative DevelopmentA software project evolves in iterations to:      Mitigate risk      Accommodate change...
Problems with iterative processes    How iterative? How many rounds?    Agile or rigid?    Heavy weight (many rules, pr...
A storyA pig and a chicken are walking down a road. 
The chicken looks at the pig and says, "Hey, why dontwe open a restau...
Committed vs involved    The core roles in development teams     are those committed to the project in     the process - ...
The Planning SpectrumSource: B. Boehm “Get Ready For Agile Methods, With Care”, IEEE Computer, Jan 2002
Agile developments methodsSome agile sw development methods  Dynamic System Development Methodology and   RAD (www.dsdm.o...
Agile ethics    www.agilemanifesto.org           We are uncovering better ways of developing           software by doing ...
Traditional vs agile team
Agile development     Agile development uses feedback to make      constant adjustments in a highly collaborative      en...
Agile development: architecture-centric
The Generic Agile Lifecycle
Agile practices
Agile Unified Process
Architectural Effort During the Lifecycle         Inception     Elaboration   Construction    Transition                  ...
Little dedicated architectural effort    Inception         Construction         Transition                        time    ...
Iterations and Phases  Inception      Elaboration                 Construction                  Transition Preliminary Arc...
SCRUM                                                                            Daily Scrum Meeting:                     ...
Agile: eXtreme ProgrammingThe ethic values of eXtreme Programming  Communication  Simplicity  Feedback  Courage  Resp...
eXtreme Programming (XP)    “Extreme Programming is a discipline of software     development based on values of simplicit...
The 12 Practices of XP1.     Metaphor2.     Release Planning3.     Testing4.     Pair Programming5.     Refactoring6.     ...
Metaphor    Programmers define a handful of classes and     patterns that shape the core business problem     and solutio...
Exercise    Find other useful metaphors
Release Planning•  Requirements via User Stories  •  Short (index-card length) natural language     description of what a ...
User stories: examplesGood:  A user can post her cv  A user can search for jobs  A company can post new job openings  ...
User story: example
User story testing: example
Testing    Test-Driven     Development (TDD)         Write tests before code         Tests are automated         Often...
Pair Programming•  Two software engineers work on   one task at one computer•  One engineer, the driver, has   control of ...
Simple Design•     No Big Design Up Front (BDUF)•    “Do The Simplest Thing That Could Possibly     Work”     •    Includi...
Refactoring Refactoring: as you write code, there are  times when you need to change its structure -  usually to conform ...
Collective Code Ownership    Code to belongs to the project, not to an     individual engineer    As engineers develop r...
Continuous Integration  Each pair writes up its own unit test cases and   code for a task (part of a user story)  Pair t...
On-Site Customer    Customer available on site to clarify     stories and to make critical business     decisions    Dev...
Small Releases•  Timeboxed•  As small as possible, but still delivering   business value  •  No releases to ‘implement the...
40h work per week (sustainable pace)•  Kent Beck says, “ . . . fresh and eager every   morning, and tired and satisfied ev...
Coding standards and conventions    Use Coding Conventions       Considering Pair Programming, Refactor Mercilessly,    ...
The 13th Practice: The Stand Up MeetingStart day with 15-minute meeting  •  Everyone stands up (so the meeting stays     s...
Research findings on XP    Strong anecdotal evidence from industry         “We can produce near defect-free code in less...
Agile Misconceptions    Agile means:        “letting the programming team do whatever they     need to with no project ma...
Process control variables    Time – duration of the project    Quality – the requirements for ‘correctness’    Resource...
Self-test questions    What are the advantages of an iterative     process?    What is an agile process?    Which are t...
References    Ambler, Agile Modern Driven Development with     UML2 (The Object Primer 3ed.), Cambridge Univ.     Press, ...
Useful sites    www.agilemanifesto.org!    www.agilemodeling.com!    www.agilejournal.com!    www.agilealliance.org! ...
Questions?
8 - Architetture Software - Architecture centric processes
Upcoming SlideShare
Loading in...5
×

8 - Architetture Software - Architecture centric processes

3,408

Published on

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,408
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
107
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

8 - Architetture Software - Architecture centric processes

  1. 1. Architecture-centric processes Paolo Ciancarini
  2. 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. 3. The role of architecture in sw lifecycle
  4. 4. 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 Waterfall1960 1970 1980 85 91 98 99
  5. 5. Traditional process  Waterfall Requirements Review Design Review Code Review Test Review Deploy
  6. 6. Waterfall characteristics   Delays confirmation of critical risk resolutionWaterfall 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
  7. 7. V Model Level of Detail Requirements AcceptanceLow Elicitation Testing System Analysis Testing Design Integration Testing Object Design Unit Testing High Project Time
  8. 8. The spiral modelDetermine 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 & verifyPlan next phase next level product Integration & Test Acceptance Test
  9. 9. 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
  10. 10. 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
  11. 11. Iterative Development Requirements Analysis & Design Planning Implementation InitialPlanning Management Environment Test Evaluation Deployment Each iteration results in an executable release
  12. 12. 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
  13. 13. Waterfall vs. iterative Requirements Requirements Requirements Design Design Design Code Code CodeRequirements Review Testing Testing Testing Deploy Deploy Deploy Design Review Assess Assess Assess Iteration 1 Iteration 2 Iteration 3 Code Review Test Review Deploy
  14. 14. 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
  15. 15. Risk: waterfall vs iterative Waterfall RiskRisk Risk Reduction Iterative Risk Time
  16. 16. Test each iteration Iteration 1 Iteration 2 Iteration 3 Iteration 4 UML Model andImplementation Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 Tests
  17. 17. Original RUP
  18. 18. RUP is iterativehttp://www-306.ibm.com/software/rational/sw-library/
  19. 19. DiscussionEvaluate the pros and cons of iterative processes
  20. 20. Benefits of Iterative DevelopmentA 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
  21. 21. 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)
  22. 22. A storyA pig and a chicken are walking down a road. 
The chicken looks at the pig and says, "Hey, why dontwe open a restaurant?" The pig looks back at thechicken and says, "Good idea, what do you want to callit?" The chicken thinks about it and says, "Why dont wecall it Ham and Eggs?" "I dont think so," says the pig,"Id be committed but youd only be involved."#
  23. 23. 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
  24. 24. The Planning SpectrumSource: B. Boehm “Get Ready For Agile Methods, With Care”, IEEE Computer, Jan 2002
  25. 25. Agile developments methodsSome 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)
  26. 26. 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 toolsWorking 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
  27. 27. Traditional vs agile team
  28. 28. 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
  29. 29. Agile development: architecture-centric
  30. 30. The Generic Agile Lifecycle
  31. 31. Agile practices
  32. 32. Agile Unified Process
  33. 33. Architectural Effort During the Lifecycle Inception Elaboration Construction Transition time Majority of architectural design activities
  34. 34. Little dedicated architectural effort Inception Construction Transition time Minimal pure Ideal realm of agile Architectural practices Activities
  35. 35. 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
  36. 36. 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 RequirementsRequirements Prioritised Requirements & Requirements Features Backlog Requirements Requirements Applying Agile: Continuous integration; continuously monitored progress
  37. 37. Agile: eXtreme ProgrammingThe ethic values of eXtreme Programming  Communication  Simplicity  Feedback  Courage  Respect (added in the latest version)
  38. 38. 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!
  39. 39. The 12 Practices of XP1.  Metaphor2.  Release Planning3.  Testing4.  Pair Programming5.  Refactoring6.  Simple Design7.  Collective Code Ownership8.  Continuous Integration9.  On-site Customer10.  Small Releases11.  40-Hour Work Week12.  Coding Standards
  40. 40. 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
  41. 41. Exercise  Find other useful metaphors
  42. 42. 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
  43. 43. User stories: examplesGood:  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 resumeBad:  The software will be written in C++  The program will connect to the database through a connection pool
  44. 44. User story: example
  45. 45. User story testing: example
  46. 46. 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
  47. 47. 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
  48. 48. 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)
  49. 49. 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
  50. 50. 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
  51. 51. 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”
  52. 52. 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
  53. 53. 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?
  54. 54. 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
  55. 55. 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 cant explain your code with a comment, rewrite it
  56. 56. The 13th Practice: The Stand Up MeetingStart 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
  57. 57. 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%)
  58. 58. 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…”
  59. 59. 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
  60. 60. 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?
  61. 61. 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
  62. 62. 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!
  63. 63. Questions?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×