1. Slide 1.1 CHAPTER 1 INTRODUCTION TO SOFTWARE ENGINEERING

2. Slide 1.2 Outline l Historical aspects l Economic aspects l Maintenance aspects l Specification and design aspects l Team programming aspects l The object-oriented paradigm l Terminology

3. Slide 1.3 Scope of Software Engineering l Historical Aspects –A NATO study group in 1967 coined the term software engineering – “building software is similar to other engineering tasks” –Endorsed by the 1968 NATO Conference in Garmisch, Germany –Aim: to solve the “Software Crisis” –Software is delivered »Late »Over budget »Low quality with lots of faults –Software crisis is still present over 35 years later!

4. Slide 1.4 Scope of Software Engineering (contd) l Why cannot bridge-building techniques be used to build operating systems? –Attitude to collapse »Bridge collapse - redesigned and rebuilt from scratch »Operating system crash – reboot! –Imperfect engineering »Bridges are assumed to be perfectly engineered »OSs are assumed to be imperfectly engineered –Complexity is growing faster than we can master –Maintenance »Bridge maintenance – painting, repairing cracks, resurfacing the road »Software maintenance – porting to new hardware, adding more functions, re-write some parts, etc.

5. Slide 1.5 Conclusion l Software engineering is a discipline whose aim is the production of fault-free software that satisfies the user’s needs and is delivered on time within budget l Software Engineering is not “Engineering” –Not as the same way viewed in other engineering disciplines

6. Slide 1.6 Economic Aspects l Computer scientists investigate a variety of ways to produce software but software engineers are interested in economically viable techniques l Coding method CM new is 10% faster than currently used method CM old. Should it be used? –Common sense answer »Of course! –Software Engineering answer must consider »the cost of introducing CM new into an organization »the effect of CM new on maintenance

7. Slide 1.7 Maintenance Aspects l Software Life Cycle –The way we produce software, including »The life-cycle model »The individuals »CASE tools l Until the end of 1970s, most organizations were producing software using the Waterfall Model

8. Slide 1.8 Life-cycle Model 1. Requirements phase - Client’s requirements are elicited 2. Specification phase - what is the software supposed to do? 3. Design phase - how the software does it 4. Implementation phase – coding and testing the components 5. Integration phase - combined and tested 6. Maintenance phase -Corrective (repair) -Enhancement (update) 7. Retirement –Removed from service

9. Slide 1.9 Approximate Relative Cost of Each Phase l 1976–1981 data l Maintenance constitutes 67% of total cost

10. Slide 1.10 Comparative Relative Cost of Each Phase

11. Slide 1.11 Good and Bad Software l Good software is maintained—bad software is discarded l Different types of maintenance –Corrective maintenance [about 20%] –Enhancement »Corrective (Perfective) maintenance [about 60%] »Enhancement (Adaptive) maintenance [about 20%] l Effect of CM new on maintenance

12. Slide 1.12 Specification and Design Aspects l 60 to 70 percent of faults are specification and design faults [Boehm, 1979] l Data of Kelly, Sherif, and Hops [1992] –1.9 faults per page of specification –0.9 faults per page of design –0.3 faults per page of code

13. Slide 1.13 Cost to Detect and Correct a Fault

14. Slide 1.14 Specification and Design Aspects (contd) l Data of Bhandari et al. [1994] l Faults at end of the design phase of the new version of the product –13% of faults from previous version of product –16% of faults in new specifications –71% of faults in new design l Faults must be found and corrected early in the development stage, otherwise it will cost a lot!

15. Slide 1.15 Team Programming Aspects l Hardware is cheap –performance-price factor = time to perform 1 million additions x cost of CPU and main memory –We can build products that are too large to be written by one person in the available time l Large product must be developed by a team l But team programming leads to –Interface problems –Communication problems l Good team organization and management is essential

16. Slide 1.16 The Object-Oriented Paradigm l Structured paradigm had great successes initially –Structured systems analysis, data flow analysis, structured programming, structured testing –It started to fail with larger products (> 50,000 LOC) l Maintenance problems (today, up to 80% of effort) l Reason: structured methods are –Action oriented (finite state machines, data flow diagrams); or –Data oriented (entity-relationship diagrams, Jackson’s method); –But not both

17. Slide 1.17 The Object-Oriented Paradigm (contd) l Both data and actions are of equal importance l Object: –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

18. Slide 1.18 Structured versus Object-Oriented Paradigm

19. Slide 1.19 Key Aspects of Object-Oriented Solution l Conceptual independence –Encapsulation l Physical independence –Information hiding l Impact on development –Physical counterpart l Impact on maintenance –Independence effects: only changes that need be made are within the object itself l Increased reusabilty –Can be utilized in the future products

20. Slide 1.20 Responsibility-Driven Design l Also called “Design by Contract” l Send flowers to your aunt in Iowa City –Call 1-800-FLOWERS –Where is 1-800-FLOWERS? –Which Iowa City florist does the delivery? –Information hiding l Object-oriented paradigm –“Send a message to a method [action] of an object“

21. Slide 1.21 Transition From Analysis to Design l Structured paradigm: –A sharp transition between analysis (what) and design (how) l Object-oriented paradigm: –Objects enter from very beginning

22. Slide 1.22 Analysis/Design “Hump” l Systems analysis –Determine what has to be done l Design –Determine how to do it –Architectural design—determine modules –Detailed design—design each module

23. Slide 1.23 Removing the “Hump” l Object-oriented analysis –Determine what has to be done –Determine the objects l Object-oriented design –Determine how to do it –Design the objects

24. Slide 1.24 In More Detail l Objects enter here

25. Slide 1.25 Warning l Do not use the object-paradigm to enhance a product developed using the structured paradigm –Water and oil do not mix l Exception: if the new part is totally disjoint –Example: adding a GUI (graphical user interface)

26. Slide 1.26 Terminology l Program, system l Software: program + documentation l Product –a nontrivial piece of software –The end result of software production l Software production: development + maintenance l Methodology, paradigm: a collection of techniques for carrying out the software production Bug  –“A bug  crept into the code” instead of –“I made an error”

27. Slide 1.27 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)

28. Slide 1.28 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 l Read Chapter 1 l Do Problems 1.1-1.11