1. ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Set 2 Partially based on lecture notes written by Richard N. Taylor, André van der Hoek, Dan Frost, Doris Tonne & Sommerville. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited.

2. Topic 2 Summer 2003 2 The goal of Software Engineering n Overcoming the Software Crises = “often late, over budget and not what the customer wanted” (Brooks) n “ High quality software” -- what does that mean??? n There are many qualities - –Which to choose?

3. Topic 2 Summer 2003 3 Software Qualities n Correctness - behaves according to specifications n Reliability – Statistical property –i.e. Mean time between failures n Robustness - behaves “reasonably” in unanticipated circumstances. n Performance - uses resources economically (efficient) n Usability – easy to use –Keep in mind the intended audience

4. Topic 2 Summer 2003 4 More Qualities n Maintainability - conducive to corrective, adaptive, and perfective maintenance –Corrective – removal of bugs –Adaptive – adjust to changing enviornment –Perfective – change to improve qualities n Repairability - conducive to correction of defects (which area of maintainability does this address?) n Evolvability – easy to add functionality or modify existing functions (which area of maintainability does this address?)

5. Topic 2 Summer 2003 5 … and More qualities n Reusability – how easily can you use it for another application (minor modifications allowed) n Portability – how easily can it run on different environments n Safety – deals with the absence of unsafe conditions n Verifiability – satisfaction of desired properties can easily be determined

6. Topic 2 Summer 2003 6 Why Not Implement Them All? n So many qualities… so little time? n How do you choose?

7. Topic 2 Summer 2003 7 The essence of software engineering n Or, What makes software engineering difficult?

8. Topic 2 Summer 2003 8 Visibility vs…

9. Topic 2 Summer 2003 9 …Invisibility n Software as is cannot be viewed meaningfully –Stack of paper –Set of files n Software cannot be interpreted easily –How to read source code? –How to read a million lines of source code? –How to read a part of source code? n Invisibility affects process –How to measure progress? Is a bigger stack of paper closer to the end-result than a smaller stack of paper?

10. Topic 2 Summer 2003 10 Manageable Complexity vs…

11. Topic 2 Summer 2003 11 …Unmanageable Complexity n Software cannot be easily abstracted –Formulas Only in very few domains –Diagrams, graphs, and other representations Typically non-hierarchical Far too many cross-references n Tension between high-level understanding and low-level detailed specification –High-level understanding leaves out important details –Aggregation often does not work

12. Topic 2 Summer 2003 12 Environment Can Be Changed vs…

13. Topic 2 Summer 2003 13 …Environment Cannot Be Changed n Software has to adhere to the “world” it is placed in –Cannot change the hardware –Cannot change the way people do business n The “world” is often not clearly specified –How can you change something that you cannot specify? –Leads to many software changes n Perception is that software is easier to change (malleability)

14. Topic 2 Summer 2003 14 No Major Changes vs…

15. Topic 2 Summer 2003 15 …Major Changes n Software is remarkably easy to change –Change the source code, recompile, rerun –“One line here, one line there” n Unfortunately, even small changes can have disastrous consequences –A single wrong character can surreptitiously change the behavior of the software The effects of most changes are only visible in certain circumstances n Sometimes, the environment does change –Software is used in different organizations –Software is used for different purposes

16. Topic 2 Summer 2003 16 Drastic Consequences n Deceased patients –X-ray machine delivered very high doses because of a timing problem in its control software n Crashed planes –Software prevented pilots from performing emergency maneuvers n Decreased national security –NSA computers down for four days due to a “software problem” Peter Neumann’s Risks Forum: http://catless.ncl.ac.uk/Risks

17. Topic 2 Summer 2003 17 Analysis 2% Specification 5% Module Coding 5% Module Testing 7% Integration 8% Maintenance 67% High Cost [Schach] Design 6%

18. Topic 2 Summer 2003 18 Cost of Change Progressively Higher [Schach]

19. Topic 2 Summer 2003 19 Processes as a Remedy n Institute processes through which software is engineered –Cover all steps from initial idea and requirements to delivery, maintenance, and final retirement –Make sure we do the right things/things right –Make sure we do not forget to do anything –Different processes for different kinds of software n Not a silver bullet [Brooks “No Silver Bullet”] –Software is still intrinsically difficult to deal with –Processes help, but cannot guarantee anything Remember: People + Processes + Tools  Product

20. Topic 2 Summer 2003 20 Software Process n “A set of activities and associated results which lead to the production of a software product.” n Four fundamental activities: –Software specification –Design and implementation –Validation (Testing) –Evolution (Maintenance) n Think about differences for “generic” (shrink- wrapped) and “bespoke” (custom-made).

21. Topic 2 Summer 2003 21 Product and Process n Products: can be sold, bring in revenue n Process: retained by company –Company culture –Determines key properties of your products –A key factor in the cost / reliability / up-to- dateness of the product –E.g.: Just-in-time, “Quality is job 1” n Which is the more important: product or process?

22. Topic 2 Summer 2003 22 Process and Product n Which is possible? –Good process --> good product –Good process --> bad product –Bad process --> good product –Bad process --> bad product n In studying Software Engineering, we focus on both process and product

23. Topic 2 Summer 2003 23 Software Life Cycle Models n Build-and-fix n Waterfall n Rapid prototyping n Incremental n Synchronize-and-stabilize n Spiral A software life cycle model is a high-level process

24. Topic 2 Summer 2003 24 What is a Software Lifecycle Model? n “A software life cycle model is either a descriptive or prescriptive characterization of how software is or should be developed. “ [scacchi] n “abstract representation of a process”[sommerville]

25. Topic 2 Summer 2003 25 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

26. Topic 2 Summer 2003 26 Stage-wise Development [Benington, late 1950s] n operation plan n machine and operational specifications n program specifications n coding specifications n coding n testing specifications n system evaluation

27. Topic 2 Summer 2003 27 Waterfall [Royce, 1970s] Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

28. Topic 2 Summer 2003 28 Rapid Prototyping Operations mode Retirement Build and discard simple prototype Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

29. Topic 2 Summer 2003 29 Spiral [Boehm] Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify Full spiral model is discussed in Sommerville

30. Topic 2 Summer 2003 30 Boehm’s Top Ten Software Risks 1. Personnel shortfalls 2. Unrealistic schedules and budgets 3. Developing the wrong software functions 4. Developing the wrong user interface 5. “Gold plating” 6. Continuing stream of requirements changes 7. Shortfalls in externally furnished components 8. Shortfalls in externally performed tasks 9. Real-time performance shortfalls 10. Straining computer- science capabilities

31. Topic 2 Summer 2003 31 FOR EACH BUILD Perform detailed design, implementation, and integration. Test. Deliver to client. Incremental [Mills] Operations mode Retirement Requirements phase Verify Specification phase Verify Architectural design Verify Development Maintenance

32. Topic 2 Summer 2003 32 Synchronize-and-Stabilize (AKA Daily build and smoke test) Specifications Implementation, Integration Deliver to client (version 1) SpecificationsDesign Implementation, Integration Deliver to client (version 2) SpecificationsDesign Implementation, Integration Deliver to client (version 3) SpecificationsDesign Implementation, Integration Deliver to client (version n) Specification teamDesign teamImplementation/integration team Design

33. Topic 2 Summer 2003 33 A Comparison of Approaches ModelStrengthsWeaknesses Build-and-Fix (not a model) Fine for small programs that do not require much maintenance Totally unsatisfactorily for nontrivial programs – lacks in forethought Leads to bad Design WaterfallDisciplined approach Document driven Delivered product may not meet client’s needs Does not scale down – its difficult to go back up Rapid Prototyping Ensures that delivered product meets client’s needs A need to build twice Cannot always be used SpiralIncorporates features of all the above models Adds risk assessment Can be used only for large-scale products Developers have to be competent at risk-analysis IncrementalMaximizes early return on investment Lower risk of project failure Requires open architecture May degenerate into build-and-fix Synchronize- and-stabilize Future user’s needs are met Ensures components can be successfully integrated Has not been widely used other than in Microsoft

34. Topic 2 Summer 2003 34 SEI's Capability Maturity Model Initial(1) Repeatable (2) Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Defined (3) Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus Managed (4) Software quality management Quantitative process management Optimizing (5) Process change management Technology change management Defect prevention Disciplined Process Standard, consistent process Predictable process Continuously improving process

35. Topic 2 Summer 2003 35 ICS 52 Software Life Cycle n Requirements specification –Interview customer (TA) –Focus on “what”, not “how” n Architectural and module design –Based on provided “official” requirements specification –Focus on interfaces n Implementation –Based on provided “official” design –Focus on good implementation techniques n Testing –Based on provided “official” implementation –Focus on fault coverage and discovery

36. Topic 2 Summer 2003 36 Your Tasks 1. Read and study slides of this lecture 2. Read and study Chapters 4.4, 8 and 5 of Sommerville –Make sure to study the details of the complete spiral model 3. Visit Peter Neumann’s Risks Forum –Spend two hours (or more) reading the articles