1. Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1

2. © 2010 John Wiley & Sons Ltd. Chapter 1. Introduction 2

3. © 2010 John Wiley & Sons Ltd. Goal of Software Engineering Creation of software systems that are –Reliable –Efficient –Maintainable –Meet the needs of customers Production of system meets –Schedule –Budget 3

4. © 2010 John Wiley & Sons Ltd. What is Software Engineering? Engineering discipline –the design, analysis and construction of an artifact for some practical purpose IEEE definition: –“the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software.” 4

5. © 2010 John Wiley & Sons Ltd. NATO Study Group NATO Study Group on Computer Science (1968) –one of the first uses of the phrase software engineering “Programming management will continue to deserve its current poor reputation for cost and schedule effectiveness until such time as a more complete understanding of the program design process is achieved.” 5

6. © 2010 John Wiley & Sons Ltd. NATO Study Group (cont.) “Today we tend to go on for years, with tremendous investments to find that the system, which was not well understood to start with, does not work as anticipated. We build systems like the Wright brothers built airplanes — build the whole thing, push it off the cliff, let it crash, and start over again.” 6

7. © 2010 John Wiley & Sons Ltd. Software Disasters Numerous examples of software disasters –Ariane Project –1990 AT&T Disaster –Radiation Overdose 7

8. © 2010 John Wiley & Sons Ltd. Software Failure What is it? –Failure to meet expectations What expectations are not achieved? –Over budget –Exceeds schedule and/or misses market window –Doesn’t meet stated customer requirements –Lower quality than expected –Performance doesn’t meet expectations –Too difficult to use 8

9. © 2010 John Wiley & Sons Ltd. Software Failure (cont.) Reasons for failure: –Unrealistic or unarticulated project goals –Poor project management –Inaccurate estimates of needed resources –Badly defined system requirements –Poor reporting of the project's status –Unmanaged risks –Poor communication among customers, developers, and users –Inability to handle the project's complexity –Poor software design methodology –Wrong or inefficient set of development tools –Inadequate test coverage –Inappropriate (or lack of) software process 9

10. © 2010 John Wiley & Sons Ltd. Software Engineering Activities 10

11. © 2010 John Wiley & Sons Ltd. People 11

12. © 2010 John Wiley & Sons Ltd. The Software Product Artifacts Project documentation Documents produced during software definition and development Code Source and object Test documents Plans, cases, and results Customer documents Documents explaining how to use and operate product Productivity measurements Analyze project productivity 12

13. © 2010 John Wiley & Sons Ltd. Project 13

14. © 2010 John Wiley & Sons Ltd. Project (cont.) Development paradigm –e.g. object-oriented 14

15. © 2010 John Wiley & Sons Ltd. Process Framework for carrying out the activities of a project in an organized and disciplined manner. Imposes structure Waterfall or Iterative 15

16. © 2010 John Wiley & Sons Ltd. Waterfall Process Simplest process Sequential Basis for others 16

17. © 2010 John Wiley & Sons Ltd. Iterative Process Software projects rarely follow strict waterfall Some iteration between specifications, design, implementation and test Requires discipline –e.g. update specifications when design changes 17

18. © 2010 John Wiley & Sons Ltd. Chapter 2. Software Quality 18

19. © 2010 John Wiley & Sons Ltd. Software Quality The more closely a software product meets its specified requirements, and those requirements meet the wants and needs of its customers, the higher its quality. 19

20. The Meaning of “Software Quality” 100% 0% Graphics courtesy Corel Requirements (explicit and implicit) Typical quality focus © 2010 John Wiley & Sons Ltd. 20

21. © 2010 John Wiley & Sons Ltd. Software Quality (cont.) Software will contain defects Defect: deviation from requirement Software quality concerns the severity and extent of defects 21

22. © 2010 John Wiley & Sons Ltd. Software Quality (cont.) Quality goals: 1.Remove as many defects as is reasonably possible before project is completed 2.Remove as many of these defects as early in the development process as possible  Cost to repair increases the later a defect is discovered 22

23. © 2010 John Wiley & Sons Ltd. Software Quality (cont.) Moral of the story: –Finding defects early is easier and saves $$$ 23

24. Defect Repair Cost Requirements Design ImplementationTest Maintenance © 2010 John Wiley & Sons Ltd. 24

25. © 2010 John Wiley & Sons Ltd. Phases Requiring Quality and Metrics Design Integration and System Testing Planning Requirements Analysis Maintenance Implementation and Unit Testing Process 25

26. © 2010 John Wiley & Sons Ltd. Verification and Validation (V&V) Verification: Ensuring that each artifact is built in accordance with its specifications - “Are we building the product right?” -Mostly inspections and reviews Validation: Checking that each completed artifact satisfies its specifications - “Are we building the right product?” - Mostly testing 26

27. © 2010 John Wiley & Sons Ltd. Creation, Verification and Validation Partially completed artifact Artifact under construction Completed artifact creationvalidation process verification Software engineer Graphics courtesy of Corel 27

28. © 2010 John Wiley & Sons Ltd. Quality Documentation  Software Quality Assurance Plan (SQAP) –IEEE Std 730-2002 –Overall approach to quality  Software Verification and Validation Plan (SVVP) –IEEE Std 1012-2004 –V &V practices 28

29. © 2010 John Wiley & Sons Ltd. Metrics  Numerical measures that quantify the degree to which software or a process possesses a certain attribute –e.g. Defects/KLOC –e.g. Average module size  Collected and analyzed throughout software project 29

30. © 2010 John Wiley & Sons Ltd. Metrics (cont.)  Benefits and uses: –Measure software quality level –Estimate project schedules –Track schedule progress –Measure software size and complexity –Determine project cost –Process improvement 30

31. © 2010 John Wiley & Sons Ltd. Quality Metrics  Defect density  Mean time to failure  Customer problems  Customer satisfaction 31

32. © 2010 John Wiley & Sons Ltd. Chapter 3: Software Process 32

33. © 2010 John Wiley & Sons Ltd. Software Process Software project composed of activities  E.g. planning, design, testing, etc. Activities organized into phases A software process:  prescribes the order and frequency of phases  specifies criteria for moving from one phase to the next  defines the deliverables of the project 33

34. © 2010 John Wiley & Sons Ltd. Umbrella Activities Generic activities implemented throughout the life of a project –Project management –Configuration management –Quality management –Risk management 34

35. © 2010 John Wiley & Sons Ltd. Software Process Benefits Process DOES NOT mean –“overhead” – “unnecessary paperwork” – “longer schedules” – etc. Software process has positive effect if applied correctly –Meet schedules –Higher quality –More maintainable 35

36. © 2010 John Wiley & Sons Ltd. Software Process Phases 36

37. © 2010 John Wiley & Sons Ltd. Waterfall Process 37

38. © 2010 John Wiley & Sons Ltd. Waterfall Process – with feedback 38

39. © 2010 John Wiley & Sons Ltd. Waterfall Process - Advantages Simple and easy to use Practiced for many years Easy to manage Facilitates allocation of resources Works well for smaller projects where requirements are very well understood 39

40. © 2010 John Wiley & Sons Ltd. Waterfall Process - Disadvantages Requirements must be known up front Hard to estimate reliably No feedback of system by stakeholders until after testing phase Major problems aren’t discovered until late in process Lack of parallelism Inefficient use of resources 40

41. © 2010 John Wiley & Sons Ltd. Iterative and Incremental Iterative –repeated execution of the waterfall phases, in whole or in part, resulting in a refinement of the requirements, design and implementation Incremental –operational code produced at the end of an iteration –supports a subset of the final product functionality and features Artifacts evolve during each phase Artifacts considered complete only when software is released 41

42. © 2010 John Wiley & Sons Ltd. Iterative and Incremental (cont.) 42

43. © 2010 John Wiley & Sons Ltd. Spiral Model Barry Boehm, TRW Defense Systems,1988 One of the earliest and best known iterative and incremental processes Risk-driven process Project starts at the center, and each cycle of the spiral represents one iteration Goal of each cycle is to increase the degree of system definition and implementation, while decreasing the degree of risk 43

44. © 2010 John Wiley & Sons Ltd. Spiral Model 44

45. © 2010 John Wiley & Sons Ltd. Spiral Model - Iteration Steps 1.Identify critical objectives and constraints 2.Evaluate project and process alternatives 3.Identify risks 4.Resolve (cost-effectively) a subset of risks using analysis, emulation, benchmarks, models and prototypes 5.Develop project deliverables including requirements, design, implementation and test 6.Plan for next and future cycles – update project plan including schedule, cost and number of remaining iterations 7.Stakeholder review of iteration deliverables and their commitment to proceed based on their objective being met 45

46. © 2010 John Wiley & Sons Ltd. Spiral Model - Advantages Risks are managed early and throughout the process – risks are reduced before they become problematic Software evolves as the project progresses - errors and unattractive alternatives eliminated early. Planning is built into the process – each cycle includes a planning step to help monitor and keep a project on track. 46

47. © 2010 John Wiley & Sons Ltd. Spiral Model - Disadvantages Complicated to use - risk analysis requires highly specific expertise. There is inevitably some overlap between iterations. May be overkill for small projects – complication may not be necessary for smaller projects. Does not make sense if the cost of risk analysis is a major part of the overall project cost. 47

48. © 2010 John Wiley & Sons Ltd. Unified Process Developed by Jacobson, Rumbaugh and Booch Major elaboration and refinement of Spiral Use-case driven Commercial product: Rational Unified Process (RUP) 48

49. © 2010 John Wiley & Sons Ltd. Unified Process 49

50. © 2010 John Wiley & Sons Ltd. Inception Establish feasibility Make business case Establish product vision and scope Estimate cost and schedule, including major milestones Assess critical risks Build one or more prototypes 50

51. © 2010 John Wiley & Sons Ltd. Elaboration Specify requirements in greater detail Architectural baseline Iterative implementation of core architecture Refine risk assessment and resolve highest risk items Define metrics Refine project plan, including detailed plan for beginning Construction iterations 51

52. © 2010 John Wiley & Sons Ltd. Construction Complete remaining requirements Iterative implementation of remaining design Thorough testing and preparation of system for deployment 52

53. © 2010 John Wiley & Sons Ltd. Transition Beta tests Correct defects Create user manuals Deliver the system for production Training of end users, customers and support Conduct lessons learned 53

54. © 2010 John Wiley & Sons Ltd. Unified Process Milestones 54

55. © 2010 John Wiley & Sons Ltd. Phases Times 55

56. © 2010 John Wiley & Sons Ltd. Agile Processes 56

57. © 2010 John Wiley & Sons Ltd. Accumulating functionality The Agile Process Time; composed of equal iteration intervals  Implement stories Work incrementally Develop test bank in parallel Demonstrate fulfillment of previous stories Identify stories for this iteration Interact with customer Cement mutual understanding Typical iteration 57

58. © 2010 John Wiley & Sons Ltd. Open Source 58

59. © 2010 John Wiley & Sons Ltd. Open Source (cont.) 59

60. © 2010 John Wiley & Sons Ltd. Open Source (cont.) 60