Software Engineering HT04

1. Software Engineering HT04 Annabella Loconsole bella@cs.umu.se http://www.cs.umu.se/~bella http://www.cs.umu.se/kurser/TDBB12/HT04/

2. Lecture part Traditional lectures Guest lecture 3 Group exercises 2 Assignments Written examination Project part Teamwork Prototype development Team meetings Oral presentation of results Written reports Course Organisation Examination: Assignments + Exam+ Project bella@cs.umu.se

3. Contents • L1: Introduction • L2: Requirements engineering • L3: Project management • L4: Guest Lecture - System engineering • L5: Software design • L6: Detailed design and coding • L7: Quality assurance • L8: Maintenance bella@cs.umu.se

4. Introduction • What is software engineering • Software development processes • Software quality • Approaches to improve quality bella@cs.umu.se

5. Software Problems • Software becomes more and more complex • Software permeates our daily life • Software failures may harm our lives • Software does not meet expectations • Software projects exceed budgets and schedules • ... bella@cs.umu.se

6. Ariane 5 Failure (in ’96 and ’02) Inertial Reference computer (SRI-1) tried to convert 64-bit float value to 16-bit signed integer. Value too large, raised exception. SRI-1 computer shut down. Redundant SRI-2 computer performed same conversion, produced same exception. SRI-2 sent bad data to flight control computer, which then put the launcher into an unstable flight trajectory. Result: Self-destruct mechanism was activated. Failure Cause: improperly constrained computation. http://news.bbc.co.uk/2/hi/science/nature/2565387.stm http://www.esa.int/export/esaCP/ESACVS7708D_index_0.html bella@cs.umu.se

7. Undeliverable software Incorrect software Unsound software Major redesign needed Usable after change OK as delivered The Software Crisis is not Over 2% 3% 19% 29% 21% 26% Study from Study from Medvits C et al “SAIC common approach guidance for CMMI”, GAO report on software results bella@cs.umu.se

8. COMPUTER SCIENCE ENGINEERING PRINCIPLES CUSTOMER Proven Techniques Computer Functions Theories Problem SOFTWARE ENGINEERING What is Software Engineering? “The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.” Definition proposed by Fritz Bauer at the NATO conference ‘68 in Garmisch [NRB 76] Tools and Techniques to Solve Problem bella@cs.umu.se

9. But ... “ ... we all tell each other and ourselves that software engineering techniques should be improved considerably, because there is a crisis. But there are a few boundary conditions which apparently have to be satisfied. I will list them for you: 1. We may not change our thinking habits. 2. We may not change our programming tools. 3. We may not change our hardware. 4. We may not change our tasks. 5. We may not change our organizational set-up in which the work has to be done. Now under these five immutable boundary conditions, we have to try to improve matters. This is utterly ridiculous. ...” Comment by Edsger Dijkstra at the NATO conference ‘69 in Garmisch [BuRa 70] bella@cs.umu.se

10. Elements of Software Engineering Methods Technical “how tos” to support software development tasks • Languages Notations to support methods Tools (Semi-) automated support for (the usage of) methods and languages Processes Coordination and management of software development tasks supported by methods, languages, and tools Economically produce quality software bella@cs.umu.se

11. Require- ments Build first version Modify until client is satisfied Operation maintenance development Software Development Processes • Does this scale up? bella@cs.umu.se

12. The Waterfall Model (‘70) Requirements Analysis Specification Require- ments Planning Design Coding Testing Installation Operation and Maintenance bella@cs.umu.se

13. The V model (‘92) Operation and Maintenance Validate requirements Requirements Analysis Acceptance Testing System Design System Testing Verify design Program Design Unit & Integra- tion Testing Coding bella@cs.umu.se

14. The Spiral Model (‘88) DETERMINE GOALS, ALTERNATIVES, CONSTRAINTS EVALUATE ALTERNATIVES AND RISKS Constraints4 Risk analysis4 Constraints3 Risk analysis3 Alternatives4 Constraints2 Risk analysis2 Alternatives3 Risk analysis1 Alternatives2 Constraints1 Proto- type2 Proto- type3 Proto- type4 Alternatives1 Budget4 Budget3 Budget2 Budget1 Prototype1 start Simulations, models Requirements, life-cycle plan Concept of operation Software requirements Detailed design Development plan Software design Validated requirements Code Integration and test plan Validated, verified design Unit test System test Plan next phase DEVELOP AND TEST PLAN Acceptance test bella@cs.umu.se

15. Waterfall vs. Spiral Model Waterfall Model Spiral Model Complex, iterative model; many integrated tasks Model Complexity Simple, linear sequence of phases Management Document driven Risk driven Continuous evaluation, integrated into the model Quality Control Natural milestone after each phase Customer interaction Prototypes are built and evaluated by customers in every iteration No Low (risk analysis is integrated in the model) Risk High (late feedback) Usability Small and/or low risk projects Large projects bella@cs.umu.se

16. Version- and Confi- guration Control Maintenance Iterations Requirements Engineering Requirements Engineering Requirements Engineering Design Design Design Reuse Documentation Implemen- tation Implemen- tation Implemen- tation Project Management Quality Assurance Incremental and Iterative Processes bella@cs.umu.se

17. Rational Unified Process • RUP is a method of managing OO Software Development • It can be viewed as a Software Development Framework which is extensible and features: • Iterative Development • Requirements Management • Component-Based Architectural Vision • Visual Modelling of Systems • Quality Management • Change Control Management bella@cs.umu.se

18. Rup Organisation along context bella@cs.umu.se

19. eXtremeProgramming project bella@cs.umu.se

20. Rules and Practices of Extreme Programming User Stories Release Plan Make frequent small releases Iterative Development iteration Planning Move People Around Daily Stand Up Meeting Simplicity is the Key CRC Cards Create a Spike Solution Never Add Functionality Early • The Customer is Always Available • Coding Standards • Code the Unit Test First • Pair Programming • Sequential Integration • Integrate Often • Collective Code Ownership • Optimise Last • No Overtime • Unit Tests • Acceptance Tests bella@cs.umu.se

21. Relative Costs of Development Phases Compiled data from 1976-1981, see [Schach 97]. bella@cs.umu.se

22. Relative Costs of an Error See [Schach 97]. bella@cs.umu.se

23. ?! can lead to can lead to failure human error fault Fault vs Failure bella@cs.umu.se

24. Causes of Errors Study from 1978, see [GoRu 95]. bella@cs.umu.se

25. Introduction • What is Software Engineering • Software Development Processes • Software Quality • Approaches to Improve Quality bella@cs.umu.se

26. Quality is ... • … I know it when I see it • … it suits the client/user • … it conforms to the specification • … it has some inherent quality • … it depends on the price bella@cs.umu.se

27. And Quality is … Sponsor User Low costs Functionality Easy to learn Increased productivity Efficiency Easy to remember Short time of delivery Easy to use Flexibility Reliability Few errors Maintainer/ modifier Good design Readable code Good documentation bella@cs.umu.se

28. Functionality Reliability Usability Understandability Efficiency Resource behavior Maintainability Portability Maturity Security Interoperability Time behavior Suitability Replaceability Fault tolerance Accuracy Recoverability Changeability Operability Analyzability Stability Testability Adaptability Installability Conformance Learnability Quality Factors (ISO 9126) bella@cs.umu.se

29. How Companies Pursue Software Quality bella@cs.umu.se A survey from the CASE Research Corporation (1990), see [Yourdon 92].

30. How To Measure Quality? Quality Factor Efficiency • Metrics are (objective) measurements to determine (subjective) quality factors depends on Property/ Criteria Property/ Criteria Property/ Criteria Speed Size determined by Response time LOC ... Metric Metric Metric bella@cs.umu.se

31. To measure efficiency Time behaviour Transactions per second Response time Screen refresh time Resource behaviour KBytes of executables LOC Number of processors To measure usability Training time Number of help frames To measure reliability MTTF (Mean Time To Failure) Availability To measure robustness Time to restart after a failure Probability of data corruption on failure To measure portability Number of target systems Percentage of target dependent statements Some Example Metrics • Measurement is necessary bella@cs.umu.se

32. Analysis: Determine current quality Prediction: Predict future quality Not only code can be measured, but also Products Documentation Design Purpose of Measurement • Resources • Personnel • Budget • Processes • Analysis phase • Test phase bella@cs.umu.se

33. Approaches to Improve Quality • Capability Maturity Model (CMM) • Personal Software Process (PSP) • Inspections • Standards (ISO9000, ...) • Cleanroom engineering • Statistical quality control • Goal Question Metrics (GQM) • ….. bella@cs.umu.se

34. CMM • Capability Maturity Model • Developed by SEI 1986 (for the DoD) • Five maturity levels • Initial (ad-hoc process) • Repeatable (repeatable process) • Defined (well-defined, documented process) • Managed (predictable process) • Optimised (continuous process improvements) • The DoD requires level 3 from all contractors bella@cs.umu.se

35. CMM: Levels bella@cs.umu.se

36. Optimized: Process change management Technology innovation Defect prevention 5: CMM Key Process Areas Managed: Quality management Process measurement and analysis 4: 3: Defined: Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus Repeatable: Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management 2: 1: Initial bella@cs.umu.se

37. CMM Results Faults delivered and installed 61 12 7 5 1 CMM level 1 2 3 4 5 Total dev. costs in US$ 5.440.000 1.311.000 728.000 392.000 146.000 Development time 29,8 18,5 15,2 12,5 9,0 Faults detected during dev. 1.348 328 182 97 37 Person months 593,5 143,0 79,5 42,8 16,0 Model predictions for the development of a 200.000 LOC data processing product (1993), see [Schach 97]. bella@cs.umu.se

38. CMM Process Maturity Profileof Software Organizations Source: http://www.sei.cmu.edu/sema/profile.html bella@cs.umu.se

39. Personal Software Process -PSP • A process for individual developers • Well-defined process steps (scripts) • Forms • Instruction for filling in the forms • Standards • Framework for analysis • Tool for individual process improvements • Developers find more errors • Developers improve their estimations • Developers improve productivity • Improvements at “no” costs bella@cs.umu.se

40. Planning Design Coding Compile Testing Post Mortem PSP Overview Requirements Plan Logs Result Logs logging (time / defects guide Scripts Plan & Summary Product Project and Process Data Summary Report bella@cs.umu.se

41. PSP3 Cyclic development PSP2.1 Design templates PSP2 Code reviews Design reviews PSP1.1 Task planning Schedule planning PSP1 Size estimating Test report PSP0.1 Coding standard Size measurement Process improvement proposal (PIP) PSP0 Current process Time recording Defect recording Defect type standard PSP Levels bella@cs.umu.se

42. CMM and PSP Optimized: Process change management Technology innovation Defect prevention 5: 4: Managed: Quality management Process measurement and analysis 3: Defined: Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus 2: Repeatable: Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management 1: PSP key process areas Initial bella@cs.umu.se

43. References [Boehm 81] B.W. Boehm, Software Engineering Economics, Prentice Hall, 1981. “Classical.” [BuRa 70] J.N. Buxton, B. Randell, Proceedings of the 1969 NATO Conference on Software Engineering, NATO Science Committee, 1970. “Historical.” [GoRu 95] A. Goldberg, K.S. Rubin, Succeeding with Objects, Addison-Wesley, 1995. Object-Oriented Software Engineering. [Hump 95] W.S. Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995. Main PSP textbook. [Myers 79] G.J. Myers, The Art of Software Testing, Wiley, 1979. “Classical.” S.L. Pfleeger, Software Engineering, Theory and Practice, Prentice Hall, 1998. [Pfleeger 98] [Schach 97] S.R. Schach, Software Engineering with Java, Irwin, 1997. [Somm 96] I. Sommerville: Software Engineering, Addison-Wesley, 1996. [Yourdon 92] E. Yourdon, Decline and Fall of the American Programmer, Prentice Hall, 1992. Critical Software Engineering textbook. bella@cs.umu.se