Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

8 - Architetture Software - Architecture centric processes

Nächste SlideShare
Wird geladen in …3

Hier ansehen

1 von 64 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)


Ähnlich wie 8 - Architetture Software - Architecture centric processes (20)

Weitere von Majong DevJfu (20)


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 Waterfall 1960 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 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
  7. 7. V Model Level of Detail Requirements Acceptance Low Elicitation Testing System Analysis Testing Design Integration Testing Object Design Unit Testing High Project Time
  8. 8. 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
  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 Initial Planning 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 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
  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 Risk Risk Risk Reduction Iterative Risk Time
  16. 16. 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
  17. 17. Original RUP
  18. 18. RUP is iterative http://www-306.ibm.com/software/rational/sw-library/
  19. 19. Discussion Evaluate the pros and cons of iterative processes
  20. 20. 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
  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 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."#
  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 Spectrum Source: B. Boehm “Get Ready For Agile Methods, With Care”, IEEE Computer, Jan 2002
  25. 25. 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)
  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 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
  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 Requirements Requirements Prioritised Requirements & Requirements Features Backlog Requirements Requirements Applying Agile: Continuous integration; continuously monitored progress
  37. 37. Agile: eXtreme Programming The 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 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
  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: 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
  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 can't explain your code with a comment, rewrite it
  56. 56. 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
  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?