Software Engineering HT 03 Annabella Loconsole bella cs umu

Software Engineering HT 03 Annabella Loconsole bella@cs. umu. se http: //www. cs. umu. se/~bella http: //www. cs. umu. se/kurser/TDBB 12/HT 03/ PVK--Ht 03 bella@cs. umu. se

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

Contents Introduction Requirements engineering Project management Software design Detailed design and coding Quality assurance Maintenance PVK--Ht 03 bella@cs. umu. se 3

Introduction What is software engineering History of Software Engineering Software development processes Software quality Approaches to improve quality PVK--Ht 03 bella@cs. umu. se 4

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. . . PVK--Ht 03 bella@cs. umu. se 5

Ariane 5 Failure 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. PVK--Ht 03 bella@cs. umu. se 6

The Software Crisis is not Over 3% 2% 19% 29% Undeliverable software Incorrect software Unsound software Major redesign needed 21% Usable after change 26% OK as delivered Study from. . . PVK--Ht 03 bella@cs. umu. se 7

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] COMPUTER SCIENCE Theories ENGINEERING PRINCIPLES Computer Functions Proven Techniques CUSTOMER Problem SOFTWARE ENGINEERING Tools and Techniques to Solve Problem PVK--Ht 03 8

But. . . we all tell each other and ourselves that software engineering techniques should be improved considerably, because there is a crisis. But there 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 [Bu. Ra 70] PVK--Ht 03 bella@cs. umu. se 9

A Little History (1) 1940 Construction of the first computers Hardware dominates 1950 Single batch programs 1960 More complex programs Software crisis More application domains Not enough educated programmers No common programming languages No special project management No quality assurance Quality = efficiency. . . 1968 NATO conference in Garmisch gives “birth” to Software Engineering approach to software production Systematic production of large software systems of high quality PVK--Ht 03 bella@cs. umu. se 10

A Little History (2) 1970 1980 Many new methods, languages, and tools First programming environments Project management support 1985 Object-orientation, GUIs Reuse, Re-engineering, . . . Process modeling Distributed computing 1990 OOA/D, Software architecture, CORBA Patterns, Internet computing, CMM, PSP 1995 PVK--Ht 03 Life-cycle models Structured programming and design General purpose languages Requirements definition languages Modularization Java, UML T-PSP, . . . bella@cs. umu. se 11

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 PVK--Ht 03 bella@cs. umu. se 12

Types of Software Custom: for a specific customer Generic: often called COTS (commercial off the shelf) Embedded: built into hardware Real time: e. g. control and monitoring systems Data processing: accuracy and security of data are key PVK--Ht 03 bella@cs. umu. se 13

Software Development Processes Requirements Build first version Modify until client is satisfied development Operation maintenance è Does this scale up? PVK--Ht 03 bella@cs. umu. se 14

Software engineering activities 1. 2. 3. 4. 5. 6. 7. 8. 9. PVK--Ht 03 Determining and analysing requirements Producing and documenting the design Detailed specifications Identifying and designing components Building components Testing components Integrating components Making final modifications Continuing maintenance bella@cs. umu. se 15

The Waterfall Model (‘ 70) Requirements Analysis Specification Planning Design Coding Testing Installation Operation and Maintenance PVK--Ht 03 bella@cs. umu. se 16

The V model (‘ 92) Requirements Analysis Validate requirements Acceptance Testing System Design Verify design Program Design PVK--Ht 03 Operation and Maintenance System Testing Unit & Integration Testing Coding bella@cs. umu. se 17

The Spiral Model (‘ 88) DETERMINE GOALS, ALTERNATIVES, CONSTRAINTS s 3 a rn es 2 te Al lte Budget 4 iv at rn Budget 3 lopm e plan nt Inte g and ration test plan PVK--Ht 03 Plan next p hase Risk analy sis 3 raints 2 Risk analy sis ns Risk analysis 1 Const Co tra Alte A int rna Budget 2 Budget 1 tives s 1 1 start Requirements, life-cycle plan Deve PLAN 4 ts 3 e tiv EVALUATE ALTERNATIVES AND RISKS Risk analysis rain Const s 4 ive t na r te Al aints 4 r Const 2 Prototype 1 Prototype 2 Prototype 3 Simulations, models ts re en a w m ft ire e ar So qu e tw gn Validated ts r of esi n e S d requirem Concept of operation Validated, sign verified de Acceptance test bella@cs. umu. se Prototype 4 Detailed design Code Unit test System test DEVELOP AND TEST 18

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

Incremental and Iterative Processes Maintenance Reuse It Version- and Configuration Control er at io Requirements ns Requirements Engineering Requirements Design. Engineering Design Documentation Design Implementation Project Management PVK--Ht 03 Quality Assurance bella@cs. umu. se 20

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: o Iterative Development o Requirements Management o Component-Based Architectural Vision o Visual Modelling of Systems o Quality Management o Change Control Management PVK--Ht 03 bella@cs. umu. se 21

Organisation along context Rup PVK--Ht 03 bella@cs. umu. se 22

e. Xtreme Programming project PVK--Ht 03 bella@cs. umu. se 23

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 PVK--Ht 03 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 28

Relative Costs of Development Phases PVK--Ht 03 Compiled data from 1976 -1981, see [Schach 97]. 29

Relative Costs of an Error See [Schach 97]. PVK--Ht 03 bella@cs. umu. se 30

Fault vs Failure can lead to human error PVK--Ht 03 fault bella@cs. umu. se can lead to ? ! failure 31

Causes of Errors Study from 1978, see [Go. Ru 95]. 32

Introduction What is Software Engineering History of Software Engineering Software Development Processes Software Quality Approaches to Improve Quality PVK--Ht 03 bella@cs. umu. se 33

Quality is. . . … … … PVK--Ht 03 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 34

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

Suitability Functionality Accuracy Interoperabilit y Security Maturity Reliability Quality Usability Factors (ISO Efficiency 9126) Maintainability Fault tolerance Recoverability Understandabili ty Learnability Operability Time behavior Resource behavior Analyzability Changeability Stability Testability Adaptability Installability Conformance Portability Replaceability PVK--Ht 03 bella@cs. umu. se 36

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

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

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

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

Approaches to Improve Quality Capability Maturity Model (CMM) Personal Software Process (PSP) Inspections Standards (ISO 9000, . . . ) Cleanroom engineering Statistical quality control Goal Question Metrics (GQM) …. . PVK--Ht 03 bella@cs. umu. se 41

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

CMM: Levels PVK--Ht 03 bella@cs. umu. se 43

5: 4: 3: 2: 1: Optimized: Process change management Technology innovation Defect prevention Managed: Quality management Process measurement and analysis 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 Initial bella@cs. umu. se CMM Key Process Areas 44

CMM Results Faults CMM Development Person Faults detected delivered Total dev. costs level in US$ time months during dev. and installed 1 29, 8 593, 5 1. 348 61 5. 440. 000 2 18, 5 143, 0 328 12 1. 311. 000 3 15, 2 79, 5 182 7 728. 000 4 12, 5 42, 8 97 5 392. 000 5 9, 0 16, 0 37 1 146. 000 Model predictions for the development of a 200. 000 LOC data processing product (1993), see [Schach 97]. PVK--Ht 03 bella@cs. umu. se 49

Personal Software Process -PSP A process for individual developers o o 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 PVK--Ht 03 bella@cs. umu. se 50

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

PSP Levels PSP 3 Cyclic development PSP 2. 1 PSP 2 Code reviews Design reviews PSP 1. 1 Size estimating Test report PSP 0 Current process Time recording Defect type standard PVK--Ht 03 Design templates Task planning Schedule planning PSP 0. 1 Coding standard Size measurement Process improvement proposal (PIP) bella@cs. umu. se 52

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

References [Boehm 81] B. W. Boehm, Software Engineering Economics, Prentice Hall, 1981. “Classical. ” [Bu. Ra 70] J. N. Buxton, B. Randell, Proceedings of the 1969 NATO Conference on Software Engineering, NATO Science Committee, 1970. “Historical. ” [Go. Ru 95] A. Goldberg, K. S. Rubin, Succeeding with Objects, Addison-Wesley, 1995. Object- [Hump 95] W. S. Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995. Main [Myers 79] G. J. Myers, The Art of Software Testing, Wiley, 1979. “Classical. ” Oriented Software Engineering. PSP textbook. [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. PVK--Ht 03 bella@cs. umu. se 54