1. 1 Development Methodologies zRational Unified Process zExtreme Programming (XP) zDSDM zSCRUM zEVO

2. 2 Agile Methods zIn the 1908os and early 1990s there was a widespread view that the best way to achieve better software was through ycareful project planning yformalised quality assurance ythe use of analysis and deign methods supported by CASE tools ycontrolled and rigorous software development

3. 3 Agile Methods Contd. zThis view came from software engineers who were developing large, long-lived software systems zWhen heavy weight, plan-based development approaches were applied to small and medium size systems ythe overhead sometimes dominated the software development process

4. 4 Agile Methods Contd. zMore time was spent on how the system should be developed than on program development and testing zIn the 1990s new agile methods were formulated which yrelied on an iterative approach yallowed for changing requirements ydelivered software quickly to customers

5. 5 Agile Methods Contd. zAgile methods such as extreme programming, Scrum, DSDM and the rational unified process share principles ycustomer involvement yincremental delivery ya focus on people, not the process yembracing of change and maintaining simplicity ybest suited for small or medium sized systems

6. 6 Root Causes of Software Development Problems zSymptoms that characterise failed projects yInaccurate understanding of end-user needs yInability to deal with changing requirements yModules that do not fit together ySoftware that is hard to maintain or extend yLate discovery of serious project flaws yPoor software quality yunacceptable software performance yuntrustworthy build-and-release processes

7. 7 Root Causes of Software Development Problems zMany projects fail because there is yAd hoc requirements management yAmbiguous and imprecise communication yBrittle architectures yOverwhelming complexity yUndetected inconsistencies in requirements, designs and implementations yinsufficient testing ysubjective assessment of project status

8. 8 Best Practices zBest practices to develop and maintain quality software include: ydeveloping software iteratively yManaging requirements yThe use of component-based architectures yVisually modelling software yContinuously verifying software quality yControlling changes to software

9. 9 Rational Unified Process zThe Rational Unified process (RUP) has two structures (dimensions) yThe horizontal axis, which represents time and shows the life cycle aspects of the process as it unfolds yThe vertical axis, which represents core process workflows, which group activities logically by nature

10. 10 Rational Unified Process Contd. zThe first dimension represents the dynamic aspect of the process as it is enacted ythis is expressed in terms of cycles, phases, iterations and milestones zThe second dimension represents the static aspect of the process yits description is in terms of process components, activities, workflows, artefacts and workers

11. 11 Rational Unified Process Contd.

12. 12 Extreme Programming zThis is probably the best known and most widely used agile method zIn extreme programming (XP) all scenarios are represented as scenarios (user stories) yimplemented as a series of tasks zProgrammers work in pairs and develop tests for each task before writing code

13. 13 Extreme Programming Contd. zAll tests must be successfully executed when new code is integrated into the system zNew versions of the software may be created several times a day zIncrements are delivered to customers roughly every two weeks

14. 14 Extreme Programming Contd. zTraditional software development suggests that you should design for change zXP discards this principle on the basis that anticipated changes often never materialise and is therefore wasted effort

15. 15 Extreme Programming Contd. Select user stories for this release Breakdown stories into tasks Plan release Develop/integrate/ test software Release software Evaluate System XP release cycle

16. 16 Extreme Programming Contd. zXP practices include yIncremental planning ySmall releases and simple design yTest-first development and Refactoring yPair programming yCollective ownership yContinuous integration ySuitable pace yAn on-site customer

17. 17 Extreme Programming Contd. zIn an XP process the customer is involved in specifying and prioritising requirements zThe customer is part of the development team and discusses scenarios with the team zA story card is created which is broken down into tasks and implementation estimates determined zThe customer prioritises the stories zThe software is continually refactored

18. 18 DSDM zThe dynamic systems development method (DSDM) is a non-proprietary rapid application (RAD) development framework zIt is owned, promoted and continuously updated by the DSDM consortium zDSDM is characterised by projects that are delivered on-time and to budget

19. 19 DSDM zDSDM describes yProject management yEstimating yPrototyping yTime boxing yConfiguration management yTesting yQuality assurance yRoles and responsibilities yTeam structures yTools environments yRisk management yBuilding for maintainability yReuse and vendor/supplier relationships

20. 20 DSDM zDSDM is founded on the following basic principles yUsers must be actively involved in the process yEach DSDM team must have the authority to make decisions yDelivery of functionality must be frequent yA deliverable is accepted on the basis of its fitness for the business purpose

21. 21 DSDM yIterative and incremental development is required in order to converge on the correct business solution yAll development changes are reversible yRequires are base lined at a high level yTesting is done throughout the lifecycle yCollaboration between the development team and stakeholders is essential zThese principles are based on best practices

22. 22 DSDM Lifecycle zAt the start of the project a feasibility study and business study are done xthese determines suitability for DSDM zThree cycles of prototyping follow: yFunctional model Iteration xthe development of tested functional prototypes and supporting documentation yDesign and build Iteration xdevelopment process completed by building in non-functional requirements

23. 23 DSDM Lifecycle yImplementation Iteration xthe system is rolled out into the business. This includes activities such as final acceptance testing, user documentation and project review zSeveral elements are put in place to control the development process including yTime boxing yrisk management yquality and testing principles ydefined end products

24. 24 DSDM zRequirements are prioritised using the MoSCoW rules yMust Have, Should Have, Won’t have zThe time for development is fixed (timebox) zMust have requirements are delivered first (in the time box) if there is a time issue zNo particular development technique is mandated

25. 25 SCRUM zThe Scrum methodology is named after the scrum in rugby zSCRUM is an enhancement to the incremental process zScrum treats large portions of the development process as a black box

26. 26 SCRUM Contd. zSince requirements change, the software development process is unpredictable zSCRUM combines tools and techniques with a loose set of activities in order to build the system zSince there is a loose control of activities, risk management controls have been introduced

27. 27 SCRUM Contd. zScrum is characterised by: yA start (planning and system architecture) process ya sprint phase which comprises the develop, wrap, review and adjust activities yAn end (closure) process

28. 28 SCRUM Contd. zMany of the processes in the sprint phase are unidentified and uncontrolled. Risk management is included to prevent chaos, yet allowing maximum flexibility zSprints are flexible and non-linear. Any available knowledge is used; if no information is available then trial and error is used

29. 29 SCRUM Contd. zThe sprinting process results in the final product zDeliverables may be changed at any time during the planning and sprint phases

30. 30 SCRUM Contd. zThe Scrum development process is summarised in the following diagram Planning and system architecture Closure Develop Wrap Review Adjust

31. 31 SCRUM Contd. zIn the planning phase yrisk are identified yproject teams assembled ydevelopment tools selected ycost estimation completed ydelivery date and functionality of one or more releases determined

32. 32 SCRUM Contd. zIn the system architecture phase, domain models are created which define the system context and requirements zIn the sprint phase: yDomain analysis, designing, developing, implementation, testing and documentation are completed during the develop activity yAn executable version of changes is produced during the wrap activity

33. 33 SCRUM Contd. yDuring the review activity work is reviewed by the teams and issues and problems resolved. Highlighted risks are also reviewed yAnd during the adjust activity the information gathered in the review meeting is compiled

34. 34 SCRUM Contd. zFinally, the closure phase is entered when management believes a new release should occur yIn this phase the product is integrated tested, system tested, user documentation and training material completed, as well as marketing material preparation

35. 35 EVO zEVO is an evolutionary delivery methodology zIt delivers a quality product on-time zIt comprises of many short development cycles (typically one week in length) zEach cycle is a waterfall zPerforms evaluation at the end of each cycle so it is done better next time around

36. 36 EVO Contd. zFeatures to be delivered are in priority order ymost important requirements first yhighest risks first yFeatures that educate users about the domain first zAt the end of each cycle a complete, functioning product is produced

37. 37 EVO Contd. zThe metric(s) associated with each requirement determines whether the functionality has been completed zAt the end of the project even if only 80% of the project is completed a working product, with the most important functionality is available

38. 38 EVO Contd. zComparatively, in the waterfall model if only 80% of the project is completed it is likely that the product will not work

39. 39 Some Methodologies Compared

40. 40 Some Methodologies Compared Contd.

41. 41