1. Software Development and Lifecycles CS201 Fall 2004 Week 11

2. Reading for today Extreme Software Engineering Extreme Software Engineering chapter 8 – acceptance testing chapter 8 – acceptance testing skim part about fit framework skim part about fit framework Questions Questions be prepared to talk about how your team has dealt with acceptance testing be prepared to talk about how your team has dealt with acceptance testing bring in a concrete example bring in a concrete example

3. What’s the Problem? Software costs are increasing as hardware costs decline. Software costs are increasing as hardware costs decline. Many software development disasters: Many software development disasters: Many failures attributed to software Many failures attributed to software Cost of failure becoming very high: Cost of failure becoming very high:

4. Software Failures or Disasters Shuttle launch anomaly Shuttle launch anomaly

5. Software Failures or Disasters Outages of AT&T Long Distance switches Outages of AT&T Long Distance switches

6. Software Failures or Disasters Ariane 5 launch explosion, 4 June 1996 Ariane 5 launch explosion, 4 June 1996 http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ari ane5rep.html http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ari ane5rep.html

7. Software Failures or Disasters « ESA « ESA The page you are looking for is not present anymore or is temporarily unavailable. Please choose one of the topics below and update your bookmarks accordingly.

8. Software Failures or Disasters (cont’d) Social Security disaster Social Security disaster

9. We have a “software crisis” (1968) “Software Engineering” “Software Engineering” An “early” study of “problem” DOD projects An “early” study of “problem” DOD projects 47% unusable 47% unusable 29% never delivered 29% never delivered ONLY 19% of software useful after extensive rework ONLY 19% of software useful after extensive rework

10. Definition of Software Engineering Fairley’s: Fairley’s: technological and managerial discipline technological and managerial discipline concerned concerned systematic production systematic production maintenance software products maintenance software products developed and modified on time developed and modified on time within cost estimates. within cost estimates.

11. Definition of Software Engineering Engineering versus science: Engineering versus science: Production, Production, practical practical quality quality maintenance maintenance reuse reuse standards standards teams teams management management etc etc

12. SW Engineering Is and Is Not... It is (or should be): It is (or should be): Engineering Engineering Building Building Modifying Modifying A systematic, careful, disciplined, scientific activity A systematic, careful, disciplined, scientific activity

13. SW Engineering Is and Is Not... It is not: It is not: Just building Just building small systems small systems new systems. new systems. Hacking/debugging until it works. Hacking/debugging until it works. Easy, simple, boring or pointless Easy, simple, boring or pointless

14. One Way to Think About It Build a bridge to cross a small creek Build a bridge to cross a small creek Build a bridge across the Golden Gate Build a bridge across the Golden Gate What’s different? What’s different? project size project size number of people number of people length length risk risk economics economics

15. "Writing Programs" “Programming in the small” “Programming in the small” “Programming in the large” “Programming in the large”

16. Software Lifecycle and Phases birth to death birth to death Phases might include: Phases might include: Requirements phase Requirements phase Specification phase Specification phase Design phase Design phase Implementation phase Implementation phase Integration or “testing” phase Integration or “testing” phase Maintenance phase Maintenance phase

17. Analogy: SE is like Construction Think about how buildings come to be: Think about how buildings come to be: Requirements Requirements Architecture Architecture Construction Construction Differences? Differences? Maintenance Maintenance Design Design

18. Requirements, Design, and Implementation Requirements Requirements what what Who Who not "here is the solution" not "here is the solution" Design Design how how model model evaluation evaluation

19. Three Key Elements in SE Process: Process: life-cycle, management, assessment, quality assurance life-cycle, management, assessment, quality assurance Method: Method: Problem solving approaches Problem solving approaches Tools: Tools: Software that supports methods and/or processes Software that supports methods and/or processes

20. Example: Process, Method, Tools Unit testing Unit testing Process: How it’s to be done? When, who, etc.? Process: How it’s to be done? When, who, etc.? Documents: Documents: Who? Who? How do we verify (check) that its been done? How do we verify (check) that its been done?

21. Example: Process, Method, Tools (cont’d) Method: What approach to be used? Method: What approach to be used? Example: Black box testing Example: Black box testing Tools: Software approach for process and methods Tools: Software approach for process and methods

22. SE Can’t Ignore Economic Aspects New techniques, tools, etc. must be worth it New techniques, tools, etc. must be worth it Example: Coding method CM new is 10% faster than currently used method CM old. Should it be used? Example: Coding method CM new is 10% faster than currently used method CM old. Should it be used? Common sense answer Common sense answer Software Engineering answer Software Engineering answer

23. Risk and SW Engineering Many problems arise because of risk Many problems arise because of risk Example problems Example problems Good SEs work to manage and reduce risk Good SEs work to manage and reduce risk

24. Managing Risk Risk areas Risk areas How to identify, manage and reduce risk How to identify, manage and reduce risk Prototyping,... Prototyping,...

25. Reminder: Lifecycle, Phases Phases might include: Phases might include: Requirements phase Requirements phase Specification phase Specification phase Design phase Design phase Implementation phase Implementation phase Integration or “testing” phase Integration or “testing” phase Maintenance phase Maintenance phase

26. Relative Cost Per Phase

27. Why Is Maintenance Expensive? Good software is maintained. Good software is maintained. Different types of maintenance Different types of maintenance Corrective [20%] Corrective [20%] Perfective [60%] Perfective [60%] Adaptive [20%] Adaptive [20%] Maintenance matters and costs even if released code has zero defects! Maintenance matters and costs even if released code has zero defects!

28. Source of Defects by Phase 60 to 70 % of faults are from specification or design 60 to 70 % of faults are from specification or design Data of Kelly, Sherif, and Hops [1992] Data of Kelly, Sherif, and Hops [1992] 1.9 faults per page of specification 1.9 faults per page of specification 0.9 faults per page of design 0.9 faults per page of design 0.3 faults per page of code 0.3 faults per page of code Data of Bhandari et al. [1994]: Faults at end of design phase of new version of product Data of Bhandari et al. [1994]: Faults at end of design phase of new version of product 13% of faults from previous version of product 13% of faults from previous version of product 16% of faults in new specifications 16% of faults in new specifications 71% of faults in new design 71% of faults in new design

29. Cost to Correct Fault According to Phase

30. Software Development Processes Outline Outline What’s this all about? What’s this all about? Some example models for life-cycle Some example models for life-cycle General principles General principles

31. Life-cycle Process Models Process: Process: done by development organization done by development organization the events or tasks the events or tasks sequence sequence Organizations want process that is: Organizations want process that is: a well-defined a well-defined well-understood well-understood repeatable repeatable

32. Various Models for SW Lifecyles “Historical Models” “Historical Models” Waterfall, Spiral models Waterfall, Spiral models Government Standards Government Standards DoD,FAA DoD,FAA Corporate “Standards” or common practices Corporate “Standards” or common practices roll your own roll your own

33. Why Learn About Process Now? There are general principles of about: There are general principles of about: What we do at various stages of SW development What we do at various stages of SW development How to inject quality into SW How to inject quality into SW How to avoid early problems that cause huge problems later How to avoid early problems that cause huge problems later Recognize that SE is not just writing code Recognize that SE is not just writing code

34. Traditional ‘waterfall’ lifecycle Requirements analysis Design Code Test Maintenance

35. Flaws of the Waterfall Need iteration and feedback Need iteration and feedback Things change (especially requirements) Things change (especially requirements) Change late requires change in earlier results Change late requires change in earlier results Often need to do something multiple times, in stages Often need to do something multiple times, in stages As described, it’s very rigid As described, it’s very rigid Not realistic to freeze results after each phase Not realistic to freeze results after each phase The model does not emphasize important issues The model does not emphasize important issues Risk management Risk management Prototyping Prototyping Quality Quality

36. A Quality- based View

37. The Spiral Model Important features Important features Risk analysis and other management are explicitly shown in the model at each stage Risk analysis and other management are explicitly shown in the model at each stage Prototyping and iterative development “fit” in this model Prototyping and iterative development “fit” in this model Repetition of activities clearly in model Repetition of activities clearly in model Suggests that alternatives can be explored Suggests that alternatives can be explored

38. The Spiral Model

39. Features of the Spiral Process Model Each cycle around the spiral can be like a phase Each cycle around the spiral can be like a phase Each cycle has four stages Each cycle has four stages 1. Determine objectives, constraints (i.e. plan!) 2. Identify and manage risks. Explore alternatives as part of risk management 3. Develop and verify next stage or level of the product Depending on the spiral, “Product” might be a requirements document, a high-level design, code, etc. Depending on the spiral, “Product” might be a requirements document, a high-level design, code, etc. 4. Review results and plan for next stage May include getting client/customer feedback May include getting client/customer feedback

40. Is the Spiral Model the Answer? Maybe Maybe Original study: Original study: Intended for internal development Intended for internal development large systems large systems But, the spiral model is important But, the spiral model is important History History illustrative illustrative

41. Other Process Models The Unified Process The Unified Process A widely-adopted process model in industry A widely-adopted process model in industry Originally developed by Rational (now part of IBM) Originally developed by Rational (now part of IBM) More complicated model that what we’ve seen More complicated model that what we’ve seen Try looking for books on this with Google or at Amazon Try looking for books on this with Google or at Amazon Many light-weight or Agile Process Models Many light-weight or Agile Process Models Best known example: Extreme Programming http://www.extremeprogramming.org Best known example: Extreme Programming http://www.extremeprogramming.org http://www.extremeprogramming.org Look at the diagram. Compare to waterfall and spiral Look at the diagram. Compare to waterfall and spiral

42. Other Model: Agile Process Models Counters "heavyweight" processes Counters "heavyweight" processes XP :“a deliberate and disciplined approach to software development.” XP :“a deliberate and disciplined approach to software development.” good for risky projects good for risky projects Emphasizes Emphasizes pair-programming pair-programming test-first, then code test-first, then code what else? what else?

43. Final Thoughts on Process Models Every organization does have a process Every organization does have a process People have strong feelings on this subject about what works! People have strong feelings on this subject about what works! (IMHO) There is no “silver bullet” here. (IMHO) There is no “silver bullet” here.