Slide 1.1 CHAPTER 1 INTRODUCTION TO SOFTWARE ENGINEERING

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

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!

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.

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

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

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

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

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

Slide 1.10 Comparative Relative Cost of Each Phase

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

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

Slide 1.13 Cost to Detect and Correct a Fault

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!

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

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

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

Slide 1.18 Structured versus Object-Oriented Paradigm

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

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

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

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

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

Slide 1.24 In More Detail l Objects enter here

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)

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”

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)

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