1. Slide 1.1 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill, 2011 Stephen R. Schach

2. Slide 1.2 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. CHAPTER 1 THE SCOPE OF SOFTWARE ENGINEERING

3. Slide 1.3 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Outline l Historical aspects l Economic aspects l Maintenance aspects l Requirements, analysis, and design aspects l Team development aspects l Why there is no planning phase

4. Slide 1.4 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Outline (contd) l Why there is no testing phase l Why there is no documentation phase l The object-oriented paradigm l The object-oriented paradigm in perspective l Terminology l Ethical issues

5. Slide 1.5 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.1 Historical Aspects l 1968 NATO Conference, Garmisch, Germany l Aim: To solve the software crisis l Software is delivered – Late – Over budget – With residual faults

6. Slide 1.6 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Standish Group Data l Data on projects completed in 2006 Figure 1.1 l Just over one in three projects was successful

7. Slide 1.7 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Cutter Consortium Data l 2002 survey of information technology organizations – 78% have been involved in disputes ending in litigation l For the organizations that entered into litigation: – In 67% of the disputes, the functionality of the information system as delivered did not meet up to the claims of the developers – In 56% of the disputes, the promised delivery date slipped several times – In 45% of the disputes, the defects were so severe that the information system was unusable

8. Slide 1.8 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Conclusion l The software crisis has not been solved l Perhaps it should be called the software depression – Long duration – Poor prognosis

9. Slide 1.9 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.2 Economic Aspects l Coding method CM new is 10% faster than currently used method CM old. Should it be used? l Common sense answer – Of course! l Software Engineering answer – Consider the cost of training – Consider the impact of introducing a new technology – Consider the effect of CM new on maintenance

10. Slide 1.10 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.3 Maintenance Aspects Life- cycle model The steps (phases) to follow when building software A theoretical description of what should be done Life cycle The actual steps performed on a specific product from concept exploration to retirement

11. Slide 1.11 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.3 Maintenance Aspects l Life-cycle model – The steps (phases) to follow when building software – A theoretical description of what should be done l Life cycle – The actual steps performed on a specific product from concept exploration to retirement

12. Slide 1.12 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Waterfall Life-Cycle Model Requirements Phase Analysis (Specification) Phase Design Phase Implementation Phase Postdelivery maintenance Figure 1.2 Classical model (1970)

13. Slide 1.13 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Waterfall Life-Cycle Model l Classical model (1970) Figure 1.2

14. Slide 1.14 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Typical Classical Phases l Requirements phase – Explore the concept – Refine the concept – Elicit the client’s requirements l Analysis (specification) phase – Analyze the client’s requirements – Draw up the specification document » Describe “What the product is supposed to do” – Draw up the software project management plan » Describe proposed software development in full detail

15. Slide 1.15 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Typical Classical Phases (contd) l Design phase – Architectural design » Product broken down into modules – Detailed design » Each module is designed – Two design documents » Describe “How the product does it” l Implementation phase – Coding – Unit testing – Integration – Acceptance testing Followed By

16. Slide 1.16 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Typical Classical Phases (contd) l Postdelivery maintenance – Corrective maintenance » Specification is NOT changed » Removal of residual faults – Enhancements (software update) » Changes to the specification are implemented –Perfective maintenance »Improve effectiveness of the product »Functionality, response time etc. –Adaptive maintenance »Reacting to the changing environment »Hardware, os, government regulations etc/ l Retirement – Functionality of the product is no longer needed

17. Slide 1.17 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.3.1 Classical and Modern Views of Maintenance Classical maintenance Development-then- maintenance model Classical maintenance Development-then- maintenance model This is a temporal definition Classification as development or maintenance depends on when an activity is performed This is a temporal definition Classification as development or maintenance depends on when an activity is performed

18. Slide 1.18 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.3.1 Classical and Modern Views of Maintenance l Classical maintenance – Development-then-maintenance model l This is a temporal definition – Classification as development or maintenance depends on when an activity is performed

19. Slide 1.19 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Classical Maintenance Defn — Consequence 1 A fault is detected and corrected one day after the software product was installed Classical maintenance The identical fault is detected and corrected one day before installation Classical development

20. Slide 1.20 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Classical Maintenance Defn — Consequence 1 l A fault is detected and corrected one day after the software product was installed – Classical maintenance l The identical fault is detected and corrected one day before installation – Classical development

21. Slide 1.21 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Classical Maintenance Defn — Consequence 2 l A software product has been installed l The client wants its functionality to be increased – Classical (perfective) maintenance l The client wants the identical change to be made just before installation (“moving target problem”) – Classical development

22. Slide 1.22 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Classical Maintenance Definition l The reason for these and similar unexpected consequences – Classically, maintenance is defined in terms of the time at which the activity is performed l Another problem: – Development (building software from scratch) is rare today – Reuse is widespread

23. Slide 1.23 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Maintenance Definition l In 1995, the International Standards Organization and International Electrotechnical Commission defined maintenance operationally l Maintenance is nowadays defined as – The process that occurs when a software artifact is modified because of a problem or because of a need for improvement or adaptation

24. Slide 1.24 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Modern Maintenance Definition (contd) l In terms of the ISO/IEC definition – Maintenance occurs whenever software is modified – Regardless of whether this takes place before or after installation of the software product l The ISO/IEC definition has also been adopted by IEEE and EIA

25. Slide 1.25 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance Terminology in This Book l Postdelivery maintenance – Changes after delivery and installation [IEEE 1990] l Modern maintenance (or just maintenance) – Corrective, perfective, or adaptive maintenance performed at any time [ISO/IEC 1995, IEEE/EIA 1998]

26. Slide 1.26 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.3.2 The Importance of Postdelivery Maintenance l Bad software is discarded l Good software is maintained, for 10, 20 years, or more l Software is a model of reality, which is constantly changing

27. Slide 1.27 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Time (= Cost) of Postdelivery Maintenance (a) Between 1976 and 1981 (b) Between 1992 and 1998 Figure 1.3

28. Slide 1.28 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. The Costs of the Classical Phases l Surprisingly, the costs of the classical phases have hardly changed Figure 1.4

29. Slide 1.29 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Consequence of Relative Costs of Phases l Return to CM old and CM new l Reducing the coding cost by 10% yields at most a 0.85% reduction in total costs – Consider the expenses and disruption incurred l Reducing postdelivery maintenance cost by 10% yields a 7.5% reduction in overall costs l The earlier we detect and correct a fault, the less it costs us

30. Slide 1.30 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Requirements, Analysis, and Design Aspects (contd) Figure 1.5  The cost of detecting and correcting a fault at each phase

31. Slide 1.31 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Requirements, Analysis, and Design Aspects (contd) l The previous figure redrawn on a linear scale Figure 1.6

32. Slide 1.32 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Requirements, Analysis, and Design Aspects (contd) l To correct a fault early in the life cycle – Usually just a document needs to be changed l To correct a fault late in the life cycle – Change the code and the documentation – Test the change itself – Perform regression testing – Reinstall the product on the client’s computer(s)

33. Slide 1.33 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Requirements, Analysis, and Design Aspects (contd) l Between 60 and 70% of all faults in large-scale products are requirements, analysis, and design faults l Example: Jet Propulsion Laboratory inspections – 1.9 faults per page of specifications – 0.9 per page of design – 0.3 per page of code

34. Slide 1.34 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Conclusion l Improve – Requirements techniques, – Analysis techniques – design techniques l Find faults as early as possible l Reduce the overall number of faults => Reduce the overall cost)

35. Slide 1.35 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.5 Team Programming Aspects l Hardware is cheap – We can build products that are too large to be written by one person in the available time l Software is built by teams – Interfacing problems between modules » Parameters, function calls etc. – Communication problems among team members » Specs change => Design change => distribute to all members » Miscommunications, conferences

36. Slide 1.36 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.6 Why There Is No Planning Phase l We cannot plan at the beginning of the project — we do not yet know exactly what is to be built

37. Slide 1.37 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Planning Activities of the Classical Paradigm l Preliminary planning of the requirements and analysis phases at the start of the project l The software project management plan is drawn up when the specifications have been signed off by the client l Management needs to monitor the SPMP throughout the rest of the project

38. Slide 1.38 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Conclusion l Planning activities are carried out throughout the life cycle l There is no separate planning phase

39. Slide 1.39 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.7 Why There Is No Testing Phase l It is far too late to test after development and before delivery l Fault in specification document will be carried out to design and implementation!!!!

40. Slide 1.40 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Testing Activities of the Classical Paradigm l Verification – Testing at the end of each phase (too late) l Validation – Testing at the end of the project (far too late) There should never be times where there is no testing

41. Slide 1.41 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Conclusion l Continual testing activities must be carried out throughout the life cycle l This testing is the responsibility of – Every software professional, and – The software quality assurance group l There is no separate testing phase

42. Slide 1.42 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.8 Why There Is No Documentation Phase l It is far too late to document after development and before delivery l At all times documentation must be – Up to date – Complete – Correct

43. Slide 1.43 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Documentation Must Always be Current l Large turnover in sw industry => Key individuals may leave before the documentation is complete l We cannot perform a phase without having the documentation of the previous phase – Incomplete specs document => Incomplete design l We cannot test without documentation – Must know what the product is supposed to do. l We cannot maintain without documentation – Must know what the current version of the product does

44. Slide 1.44 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Conclusion l Documentation activities must be performed in parallel with all other development and maintenance activities l There is no separate documentation phase

45. Slide 1.45 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.9 The Object-Oriented Paradigm l The structured paradigm was successful initially – It started to fail with larger products (> 50,000 LOC) l Postdelivery maintenance problems (today, 70 to 80% of total effort) l Reason: Structured methods are – Action oriented (e.g., finite state machines, data flow diagrams); or – Data oriented (e.g., entity-relationship diagrams, Jackson’s method); – But not both

46. Slide 1.46 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. The Object-Oriented Paradigm (contd) l Both data and actions are of equal importance l Object: – A software component that incorporates both data and the actions that are performed on that data l Example: – Bank account » Data:account balance » Actions: deposit, withdraw, determine balance

47. Slide 1.47 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Structured versus Object-Oriented Paradigm l Information hiding l Responsibility-driven design l Impact on maintenance, development Figure 1.7

48. Slide 1.48 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Information Hiding l In the object-oriented version – The solid line around accountBalance denotes that outside the object there is no knowledge of how accountBalance is implemented l In the classical version – All the modules have details of the implementation of account_balance

49. Slide 1.49 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Strengths of the Object-Oriented Paradigm 1. With information hiding, postdelivery maintenance is safer – If an attribute of an object changes only the object is modified – The chances of a regression fault are reduced 2. Development is easier – Objects generally have physical counterparts – This simplifies modeling (a key aspect of the object- oriented paradigm) – Better quality software

50. Slide 1.50 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Strengths of the Object-Oriented Paradigm (contd) 3. Well-designed objects are independent units – Everything that relates to the real-world item being modeled is in the corresponding object — encapsulation – Implementation details are hidden from everything outside the object — information hiding – Communication is by sending messages – This independence is enhanced by responsibility-driven design (see later)

51. Slide 1.51 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Strengths of the Object-Oriented Paradigm (contd) 4. A classical product conceptually consists of a single unit --even if it is implemented as a set of modules – The object-oriented paradigm reduces complexity because the product generally consists of independent units  hence development and maintenance are simplified 5. The object-oriented paradigm promotes reuse – Objects are independent entities – Development and maintenance time is reduced

52. Slide 1.52 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Responsibility-Driven Design l Also called design by contract – What actions is this object responsible for? – What information does this object share? l Send flowers to your mother in Chicago – Call 1-800-flowers – Where is 1-800-flowers ? – Which Chicago florist does the delivery? – Information hiding – Send a message to a method [action] of an object without knowing the internal structure of the object

53. Slide 1.53 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Classical Phases vs Object-Oriented Workflows l There is no correspondence between phases and workflows Figure 1.8

54. Slide 1.54 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Analysis/Design “Hump” l Structured paradigm: – There is a jolt between analysis (what) and design (how) l Object-oriented paradigm: – Objects enter from the very beginning

55. Slide 1.55 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Analysis/Design “Hump” (contd) l In the classical paradigm – Classical analysis » Determine what has to be done – Design » Determine how to do it » Architectural design — determine the modules » Detailed design — design each module

56. Slide 1.56 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Removing the “Hump” l In the object-oriented paradigm – Object-oriented analysis » Determine what has to be done » Determine the objects – Object-oriented design » Determine how to do it » Design the objects l The difference between the two paradigms is shown on the next slide

57. Slide 1.57 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. In More Detail l Objects enter here Figure 1.9

58. Slide 1.58 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Paradigm l Modules (objects) are introduced as early as the object-oriented analysis workflow – This ensures a smooth transition from the analysis workflow to the design workflow l The objects are then coded during the implementation workflow – Again, the transition is smooth

59. Slide 1.59 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.10 The Object-Oriented Paradigm in Perspective l The object-oriented paradigm has to be used correctly – All paradigms are easy to misuse l When used correctly, the object-oriented paradigm can solve some (but not all) of the problems of the classical paradigm

60. Slide 1.60 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. The Object-Oriented Paradigm in Perspective (contd) l The object-oriented paradigm has problems of its own l The object-oriented paradigm is the best alternative available today – However, it is certain to be superseded by something better in the future

61. Slide 1.61 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.11 Terminology l Client, developer, user l Internal software l Contract software l Commercial off-the-shelf (COTS) software l Open-source software – Linus's Law

62. Slide 1.62 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Terminology (contd) l Software l Program, system, product l Methodology, paradigm – Object-oriented paradigm – Classical (traditional) paradigm l Technique

63. Slide 1.63 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Terminology (contd) l Mistake, fault, failure, error l Defect l Bug  – “A bug  crept into the code” instead of – “I made a mistake”

64. Slide 1.64 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Terminology l Data component of an object – State variable – Instance variable (Java) – Field (C++) – Attribute (generic) l Action component of an object – Member function (C++) – Method (generic)

65. Slide 1.65 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Terminology (contd) l C++: A member is either an – Attribute (“field”), or a – Method (“member function”) l Java: A field is either an – Attribute (“instance variable”), or a – Method

66. Slide 1.66 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. 1.12 Ethical Issues l Developers and maintainers need to be – Hard working – Intelligent – Sensible – Up to date and, above all, – Ethical l IEEE-CS ACM Software Engineering Code of Ethics and Professional Practice www.acm.org/serving/se/code.htm www.acm.org/serving/se/code.htm