Slide 1.1

CHAPTER 1

INTRODUCTION TO SOFTWARE ENGINEERING

Slide 1.2

Outline

Historical aspects Economic aspects Maintenance aspects Specification and design aspects Team programming aspects The object-oriented paradigm Terminology

Slide 1.3

Scope of Software Engineering

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)

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

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

Software Engineering is not “Engineering” – Not as the same way viewed in other engineering

disciplines

Slide 1.6

Economic Aspects

Computer scientists investigate a variety of ways to produce software but software engineers are interested in economically viable techniques

Coding method CMnew is 10% faster than currently used method CMold. Should it be used?– Common sense answer

» Of course!

– Software Engineering answer must consider» the cost of introducing CMnew into an organization

» the effect of CMnew on maintenance

Slide 1.7

Maintenance Aspects

Software Life Cycle– The way we produce software, including

» The life-cycle model» The individuals» CASE tools

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

1976–1981 data Maintenance constitutes 67% of total cost

Slide 1.10

Comparative Relative Cost of Each Phase

Slide 1.11

Good and Bad Software

Good software is maintained—bad software is discarded

Different types of maintenance– Corrective maintenance [about 20%]– Enhancement

» Corrective (Perfective) maintenance [about 60%]» Enhancement (Adaptive) maintenance [about 20%]

Effect of CMnew on maintenance

Slide 1.12

Specification and Design Aspects

60 to 70 percent of faults are specification and design faults [Boehm, 1979]

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)

Data of Bhandari et al. [1994] 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

Faults must be found and corrected early in the development stage, otherwise it will cost a lot!

Slide 1.15

Team Programming Aspects

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

Large product must be developed by a team But team programming leads to

– Interface problems– Communication problems

Good team organization and management is essential

Slide 1.16

The Object-Oriented Paradigm

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)

Maintenance problems (today, up to 80% of effort)

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)

Both data and actions are of equal importance Object:

– Software component that incorporates both data and the actions that are performed on that data

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

Conceptual independence– Encapsulation

Physical independence – Information hiding

Impact on development– Physical counterpart

Impact on maintenance– Independence effects: only changes that need be

made are within the object itself Increased reusabilty

– Can be utilized in the future products

Slide 1.20

Responsibility-Driven Design

Also called “Design by Contract” 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

Object-oriented paradigm– “Send a message to a method [action] of an object“

Slide 1.21

Transition From Analysis to Design

Structured paradigm:– A sharp transition between analysis (what) and design

(how) Object-oriented paradigm:

– Objects enter from very beginning

Slide 1.22

Analysis/Design “Hump”

Systems analysis– Determine what has to be done

Design– Determine how to do it– Architectural design—determine modules– Detailed design—design each module

Slide 1.23

Removing the “Hump”

Object-oriented analysis– Determine what has to be done– Determine the objects

Object-oriented design– Determine how to do it– Design the objects

Slide 1.24

In More Detail 

Objects enter here

Slide 1.25

Warning

Do not use the object-paradigm to enhance a product developed using the structured paradigm– Water and oil do not mix

Exception: if the new part is totally disjoint– Example: adding a GUI (graphical user interface)

Slide 1.26

Terminology

Program, system Software: program + documentation Product

– a nontrivial piece of software– The end result of software production

Software production: development + maintenance 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

Data component of an object– State variable– Instance variable (Java)– Field (C++)– Attribute (generic)

Action component of an object– Member function (C++)– Method (generic)

Slide 1.28

Object-Oriented Terminology (contd)

C++: A member is either an– Attribute (“field”), or a– Method (“member function”)

Java: A field is either an– Attribute (“instance variable”), or a– Method

Read Chapter 1 Do Problems 1.1-1.11