Software Engineering HT05

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

2. Lecture part Traditional lectures 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

3. Contents • L1: Introduction • L2: Requirements engineering • L3: Project management • L4: Software design • L5: Detailed design and coding • L6: Quality assurance • L7: Maintenance

4. Introduction • What is software engineering • Software development processes • Software quality • Approaches to improve quality

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 • ...

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

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

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

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]

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

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

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

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

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

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

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

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

18. Rup Organisation along context

19. eXtremeProgramming project

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

21. Component-based software engineering • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Process stages • Component analysis; • Requirements modification; • System design with reuse; • Development and integration. • This approach is becoming increasingly used as component standards have emerged.

22. Relative Costs of Development Phases Compiled data from 1976-1981, see [Schach 97].

23. Relative Costs of an Error See [Schach 97].

24. ?! can lead to can lead to failure human error fault Fault vs Failure

25. Causes of Errors Study from 1978, see [GoRu 95].

26. Introduction • What is Software Engineering • Software Development Processes • Software Quality • Approaches to Improve Quality

27. 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

28. 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

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

30. How Companies Pursue Software Quality A survey from the CASE Research Corporation (1990), see [Yourdon 92].

31. 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

32. 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

33. 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

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

35. 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

36. CMM: Levels

37. 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

38. 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].

39. CMM Process Maturity Profileof Software Organizations Source: http://www.sei.cmu.edu/sema/profile.html

40. Goal Question Metric The paradigm helps an organisation to focus on its goals. It consists of three steps: • Specify a set of goals • Generate a set of quantifiable questions • Define a set of metrics

41. GQM Template Purpose: Analyse some (objects: processes, products, other experience models) for the purpose of (why: characterisation, evaluation, prediction, motivation, improvement) Perspective: with respect to (focus: cost, correctness, defect removal, changes, reliability, user friendliness,...) from the point of view of (who: user, customer, manager, developer, corporation,...) Environment: in the following context (problem factors, people factors, resource factors, process factors,...)

42. GQM Example Goal:Analyze the final product for the purpose ofcharacterisationwith respect to the various defect classes from the point of view of the organization Question: What is the error distribution by phase of entry Metric: Number of Requirements Errors, Number of Design Errors, ...

43. Level 5 KPA Metric Level 4 KPA Metric Question CMM Level 3 Metric KPA Goal Question Level 2 Metric KPA Goal Question Metric Goal Question Metric CMM and GQM

44. 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.” [Pfleeger 98] S.L. Pfleeger, Software Engineering, Theory and Practice, Prentice Hall, 1998. [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.