1. 2003 Mateusz Żochowski, Marcin Borzymek Software Life Cycle Analysis

2. 2003 Mateusz Żochowski, Marcin Borzymek Why Planning? Streamline project Streamline project Improve development speed Improve development speed Improve quality Improve quality Improve project tracking and control Improve project tracking and control Improve client relations Improve client relations

3. 2003 Mateusz Żochowski, Marcin Borzymek Inappropriate or Lack of a Lifecycle Model Slow work Slow work Repeated work Repeated work Unnecessary work Unnecessary work Frustration Frustration

4. 2003 Mateusz Żochowski, Marcin Borzymek Lifecycle Models Pure Waterfall Pure Waterfall Modified Waterfalls Modified Waterfalls Spiral Spiral Code-and-Fix Code-and-Fix Evolutionary Prototypes Evolutionary Prototypes Staged Delivery Staged Delivery Design-to Schedule Design-to Schedule Extreme Programming Life Cycle Extreme Programming Life Cycle

5. 2003 Mateusz Żochowski, Marcin Borzymek Pure Waterfall Orderly sequence of steps Orderly sequence of steps Review at the end of each phase Review at the end of each phase Discontinuous phases Discontinuous phases

6. 2003 Mateusz Żochowski, Marcin Borzymek Waterfall Rapid Development, 1996

7. 2003 Mateusz Żochowski, Marcin Borzymek Waterfall Benefits Finds errors in early stages Finds errors in early stages Minimizes planning overhead since it can be done up front Minimizes planning overhead since it can be done up front Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff

8. 2003 Mateusz Żochowski, Marcin Borzymek Waterfall Disadvantages No tangible results until the end No tangible results until the end Inflexible Inflexible Excessive documentation Excessive documentation Backing up to address mistakes is difficult Backing up to address mistakes is difficult

9. 2003 Mateusz Żochowski, Marcin Borzymek Waterfall Summary - performs well for products with clearly understood requirements -it's weaknesses frequently make it inadvisable when rapid development is needed. In those cases, modified models may be more effective.

10. 2003 Mateusz Żochowski, Marcin Borzymek Modified Waterfalls Waterfall with Subprojects Waterfall with Subprojects Waterfall with Risk Reduction Waterfall with Risk Reduction

11. 2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Subprojects Subprojects Subprojects Rapid Development, 1996

12. 2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Subprojects Benefits Logically independent subsystems Logically independent subsystems Each subproject can proceed at own pace Each subproject can proceed at own pace

13. 2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Subprojects Disadvantages Unforeseen interdependencies Unforeseen interdependencies

14. 2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Risk Reduction Risk-reduction spiral at top Risk-reduction spiral at top Rapid Development, 1996

15. 2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Risk Reduction Benefits Reduce risk Reduce risk Best of Waterfall and Risk Reduction models Best of Waterfall and Risk Reduction models Not limited to requirements Not limited to requirements

16. 2003 Mateusz Żochowski, Marcin Borzymek Spiral (Cinnamon Roll) Risk-oriented Risk-oriented Miniprojects Miniprojects Iterations Iterations Determine objectives, alternatives, and constraints Determine objectives, alternatives, and constraints Identify and resolve risks Identify and resolve risks Evaluate alternatives Evaluate alternatives Develop deliverables Develop deliverables Plan the next iteration Plan the next iteration Commit to an approach for the next iteration Commit to an approach for the next iteration

17. 2003 Mateusz Żochowski, Marcin Borzymek Spiral (Cinnamon Roll) Rapid Development, 1996

18. 2003 Mateusz Żochowski, Marcin Borzymek Spiral Benefits Management control Management control Early indication of fatal risks Early indication of fatal risks Flexible Flexible

19. 2003 Mateusz Żochowski, Marcin Borzymek Spiral Disadvantages Complicated Complicated Requires attentive, and knowledgeable management Requires attentive, and knowledgeable management

20. 2003 Mateusz Żochowski, Marcin Borzymek Possible Applications High risk projects High risk projects Poorly understood requirements Poorly understood requirements Poorly understood architecture Poorly understood architecture Potential performance problems Potential performance problems Problems in the underlying technology Problems in the underlying technology Combine with other lifecycle models Combine with other lifecycle models Terminate with waterfall or other lifecycle Terminate with waterfall or other lifecycle Incorporate other lifecycle models as iterations Incorporate other lifecycle models as iterations

21. 2003 Mateusz Żochowski, Marcin Borzymek Spiral Summary -it's beneficial to run a series of risk-reduction iterations which can be followed by a waterfall or other non-risk-based lifecycle

22. 2003 Mateusz Żochowski, Marcin Borzymek Code-and-Fix Informal Informal Unstructured Unstructured Rapid Development, 1996

23. 2003 Mateusz Żochowski, Marcin Borzymek Code-and-Fix Benefits No overhead No overhead Requires little expertise Requires little expertise

24. 2003 Mateusz Żochowski, Marcin Borzymek Code-and-Fix Disadvantages No means of assessing progress No means of assessing progress No quality management No quality management No risk management No risk management

25. 2003 Mateusz Żochowski, Marcin Borzymek Possible Applications Small proof-of-concept programs Small proof-of-concept programs Short-lived demos Short-lived demos Throwaway prototypes Throwaway prototypes

26. 2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Prototyping Develop system concept as the project progresses Develop system concept as the project progresses Begin with the most visible aspects Begin with the most visible aspects Prototype Prototype Rapid Development, 1996

27. 2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Prototyping Benefits Steady, visible signs of progress Steady, visible signs of progress Less documentation Less documentation

28. 2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Prototyping Disadvantages Impossible to schedule release Impossible to schedule release Excuse to use code-and-fix development Excuse to use code-and-fix development

29. 2003 Mateusz Żochowski, Marcin Borzymek Possible Applications Rapidly changing requirements Rapidly changing requirements Customer reluctant to commit to requirements Customer reluctant to commit to requirements Do not understand application area Do not understand application area Strong demand for development speed Strong demand for development speed

30. 2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Delivery Similar to Evolutionary Prototyping Similar to Evolutionary Prototyping Refine version based upon customer feedback Refine version based upon customer feedback Emphasizes core of the system Emphasizes core of the system

31. 2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Delivery Rapid Development, 1996

32. 2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Delivery Benefits Can accommodate customer requests Can accommodate customer requests Allows a degree of midtime changes Allows a degree of midtime changes Provides visible results Provides visible results

33. 2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Delivery Disadvantages Difficult to schedule release Difficult to schedule release May lead to Code-and-Fix development May lead to Code-and-Fix development

34. 2003 Mateusz Żochowski, Marcin Borzymek Design-to-Schedule Prioritize features Prioritize features Unsure if final release will be reached Unsure if final release will be reached Rapid Development, 1996

35. 2003 Mateusz Żochowski, Marcin Borzymek Design-to-Schedule Benefits Ensure product release for a particular date Ensure product release for a particular date Most important features completed first Most important features completed first

36. 2003 Mateusz Żochowski, Marcin Borzymek Design-to-Schedule Disadvantages Wasted effort specifying unfinished stages Wasted effort specifying unfinished stages Could complete one or more stages if time was not wasted specifying several unfinished stages Could complete one or more stages if time was not wasted specifying several unfinished stages

37. 2003 Mateusz Żochowski, Marcin Borzymek Possible Applications Must have product by a specific date Must have product by a specific date Unconfident in scheduling abilities Unconfident in scheduling abilities

38. 2003 Mateusz Żochowski, Marcin Borzymek Design-to-Tools Include functionality only if directly supported by existing software tools Include functionality only if directly supported by existing software tools Rapid Development, 1996

39. 2003 Mateusz Żochowski, Marcin Borzymek Design-to-Tools Benefits Maximum functionality vs. time Maximum functionality vs. time Can be combined with other lifecycle models Can be combined with other lifecycle models Initial spiral Initial spiral Throwaway prototype Throwaway prototype Staged delivery Staged delivery Evolutionary delivery Evolutionary delivery Design-to-schedule Design-to-schedule

40. 2003 Mateusz Żochowski, Marcin Borzymek Design-to-Tools Disadvantages Less control Less control Unable to implement all features Unable to implement all features Unable to implement features as intended Unable to implement features as intended Dependent on commercial software producers Dependent on commercial software producers

41. 2003 Mateusz Żochowski, Marcin Borzymek Possible Applications Exceptionally time-sensitive projects Exceptionally time-sensitive projects

42. 2003 Mateusz Żochowski, Marcin Borzymek Extreme Programming

43. 2003 Mateusz Żochowski, Marcin Borzymek User Stories written by the customers as things that the system needs to do for them written by the customers as things that the system needs to do for them in the format of about three sentences of text in the customers terminology without techno- syntax in the format of about three sentences of text in the customers terminology without techno- syntax

44. 2003 Mateusz Żochowski, Marcin Borzymek Release Plan create iteration plans for each individual iteration. create iteration plans for each individual iteration. estimate each user story in terms of ideal programming weeks estimate each user story in terms of ideal programming weeks estimate user stories velocity estimate user stories velocity

45. 2003 Mateusz Żochowski, Marcin Borzymek Spike solutions is a very simple program to explore potential solutions is a very simple program to explore potential solutions figure out answers to tough technical or design problems figure out answers to tough technical or design problems helps to estimate project velocity helps to estimate project velocity

46. 2003 Mateusz Żochowski, Marcin Borzymek Iteration During an iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests. During an iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests.

47. 2003 Mateusz Żochowski, Marcin Borzymek Acceptance Tests The customer specifies scenarios to test when a user story has been correctly implemented The customer specifies scenarios to test when a user story has been correctly implemented No tests passed = no progress No tests passed = no progress A user story is not considered complete until it has passed its acceptance tests A user story is not considered complete until it has passed its acceptance tests

48. 2003 Mateusz Żochowski, Marcin Borzymek Small Releases Small units of functionality can be released into the customer's environment early in the project - that gives valuable feedback Small units of functionality can be released into the customer's environment early in the project - that gives valuable feedback

49. 2003 Mateusz Żochowski, Marcin Borzymek Choosing An Appropriate Lifecycle How well are requirements understood How well are requirements understood How well is system architecture understood How well is system architecture understood How much reliability is needed How much reliability is needed How likely are future revisions How likely are future revisions How much risk How much risk Need to make midcourse corrections Need to make midcourse corrections

50. 2003 Mateusz Żochowski, Marcin Borzymek Choosing An Appropriate Lifecycle (cont.) Need to provide visible progress to customers Need to provide visible progress to customers Need to provide visible progress to management Need to provide visible progress to management How sophisticated is the model How sophisticated is the model

51. 2003 Mateusz Żochowski, Marcin Borzymek Strengths & Weaknesses Rapid Development, 1996

52. 2003 Mateusz Żochowski, Marcin Borzymek Strengths & Weaknesses (cont.) Rapid Development, 1996

53. 2003 Mateusz Żochowski, Marcin Borzymek Questions?