3/6/2016

Outline
Slide 1.1

Object-Oriented and
Classical Software
Engineering

Slide 1.3

Historical aspects
Economic aspects
Maintenance aspects
Requirements, analysis, and design aspects
Team development aspects
Why there is no planning phase

Eighth Edition, WCB/McGraw-Hill, 2011

Stephen R. Schach
Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

CHAPTER 1

Outline (contd)
Slide 1.2

Slide 1.4

THE SCOPE OF
SOFTWARE
ENGINEERING

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Why there is no testing phase

Why there is no documentation phase
The object-oriented paradigm
The object-oriented paradigm in perspective
Terminology
Ethical issues

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

3/6/2016

1.1 Historical Aspects

Cutter Consortium Data

Slide 1.5

1968 NATO Conference, Garmisch, Germany

Aim: To solve the software crisis

Software is delivered

Slide 1.7

78% have been involved in disputes ending in litigation

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

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

Late
Over budget
With residual faults

Standish Group Data

2002 survey of information technology

organizations

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Conclusion
Slide 1.6

Data on
projects
completed
in 2006

Slide 1.8

The software crisis has not been solved

Perhaps it should be called the software

depression
Long duration
Poor prognosis

Figure 1.1

Just over one in three projects was successful

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

3/6/2016

1.2 Economic Aspects

Waterfall Life-Cycle Model

Slide 1.9

Coding method CMnew is 10% faster than currently

used method CMold. Should it be used?

Common sense answer

Slide 1.11

Classical model (1970)

Of course!

Software Engineering answer

Consider the cost of training
Consider the impact of introducing a new technology
Consider the effect of CMnew on maintenance
Figure 1.2
Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

1.3 Maintenance Aspects

Typical Classical Phases

Slide 1.10

Life-cycle model

Slide 1.12

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

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Requirements phase
Explore the concept
Elicit the clients requirements

Analysis (specification) phase

Analyze the clients requirements

Draw up the specification document
Draw up the software project management plan
What the product is supposed to do

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

3/6/2016

Typical Classical Phases (contd)

1.3.1 Classical and Modern Views of Maintenance

Slide 1.13

Design phase

Architectural design, followed by

Detailed design
How the product does it

Slide 1.15

Development-then-maintenance model

This is a temporal definition

Classification as development or maintenance depends
on when an activity is performed

Implementation phase

Classical maintenance

Coding
Unit testing
Integration
Acceptance testing

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Typical Classical Phases (contd)

Classical Maintenance Defn Consequence 1

Slide 1.14

Postdelivery maintenance

Slide 1.16

Corrective maintenance
Perfective maintenance
Adaptive maintenance

Classical maintenance

Retirement

A fault is detected and corrected one day after the

software product was installed

The identical fault is detected and corrected one

day before installation
Classical development

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

3/6/2016

Classical Maintenance Defn Consequence 2

Modern Maintenance Definition

Slide 1.17

A software product has been installed

The client wants its functionality to be increased

Slide 1.19

In 1995, the International Standards Organization

and International Electrotechnical Commission
defined maintenance operationally

Maintenance is nowadays defined as

Classical (perfective) maintenance

The process that occurs when a software artifact is

modified because of a problem or because of a need for
improvement or adaptation

The client wants the identical change to be made

just before installation (moving target problem)
Classical development

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Classical Maintenance Definition

Modern Maintenance Definition (contd)

Slide 1.18

The reason for these and similar unexpected

consequences

Slide 1.20

Maintenance occurs whenever software is modified

Regardless of whether this takes place before or after
installation of the software product

Classically, maintenance is defined in terms of the time

at which the activity is performed

Another problem:
Development (building software from scratch) is rare
today
Reuse is widespread

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

In terms of the ISO/IEC definition

The ISO/IEC definition has also been adopted by

IEEE and EIA

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

3/6/2016

Maintenance Terminology in This Book

Time (= Cost) of Postdelivery Maintenance

Slide 1.21

Slide 1.23

Postdelivery maintenance
Changes after delivery and installation [IEEE 1990]

Modern maintenance (or just maintenance)

Corrective, perfective, or adaptive maintenance
performed at any time [ISO/IEC 1995, IEEE/EIA 1998]

Figure 1.3

(a) Between 1976 and 1981

(b) Between 1992 and 1998
Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

The Costs of the Classical Phases

1.3.2 The Importance of Postdelivery Maintenance

Slide 1.22

Bad software is discarded

Good software is maintained, for 10, 20 years, or

more

Software is a model of reality, which is constantly

changing

Slide 1.24

Surprisingly, the costs of the classical phases

have hardly changed

Figure 1.4

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

3/6/2016

Requirements, Analysis, and Design Aspects (contd)

Consequence of Relative Costs of Phases

Slide 1.25

Return to CMold and CMnew

Reducing the coding cost by 10% yields at most a

0.85% reduction in total costs

Slide 1.27

Consider the expenses and disruption incurred

Reducing postdelivery maintenance cost by 10%

yields a 7.5% reduction in overall costs

The cost of
detecting and
correcting a
fault at each
phase

Figure 1.5
Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Requirements, Analysis, and Design Aspects (contd)

1.4 Requirements, Analysis, and Design Aspects

Slide 1.26

The earlier we detect and correct a fault, the less it

costs us

Slide 1.28

The
previous
figure
redrawn
on a
linear
scale

Figure 1.6
Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

3/6/2016

Requirements, Analysis, and Design Aspects (contd)

Conclusion

Slide 1.29

To correct a fault early in the life cycle

Slide 1.31

Usually just a document needs to be changed

To find faults as early as possible

To reduce the overall number of faults (and, hence, the
overall cost)

To correct a fault late in the life cycle

It is vital to improve our requirements, analysis,

and design techniques

Change the code and the documentation

Test the change itself
Perform regression testing
Reinstall the product on the clients computer(s)

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

1.5 Team Programming Aspects

Requirements, Analysis, and Design Aspects (contd)

Slide 1.30

Slide 1.32

Between 60 and 70% of all faults in large-scale

products are requirements, analysis, and design
faults

Example: Jet Propulsion Laboratory inspections

1.9 faults per page of specifications

0.9 per page of design
0.3 per page of code

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Hardware is cheap
We can build products that are too large to be written by
one person in the available time

Software is built by teams

Interfacing problems between modules
Communication problems among team members

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

3/6/2016

Conclusion

1.6 Why There Is No Planning Phase

Slide 1.33

We cannot plan at the beginning of the project

we do not yet know exactly what is to be built

Slide 1.35

Planning activities are carried out throughout the

life cycle

There is no separate planning phase

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Planning Activities of the Classical Paradigm

1.7 Why There Is No Testing Phase

Slide 1.34

Preliminary planning of the requirements and

analysis phases at the start of the project

The software project management plan is drawn

up when the specifications have been signed off
by the client

Management needs to monitor the SPMP

throughout the rest of the project

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Slide 1.36

It is far too late to test after development and

before delivery

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

3/6/2016

Testing Activities of the Classical Paradigm

1.8 Why There Is No Documentation Phase

Slide 1.37

Verification

Slide 1.39

Testing at the end of each phase (too late)

It is far too late to document after development

and before delivery

Validation
Testing at the end of the project (far too late)

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Conclusion

Documentation Must Always be Current

Slide 1.38

Slide 1.40

Continual testing activities must be carried out

throughout the life cycle

Key individuals may leave before the

documentation is complete

This testing is the responsibility of

We cannot perform a phase without having the

documentation of the previous phase

We cannot test without documentation

We cannot maintain without documentation

Every software professional, and

The software quality assurance group

There is no separate testing phase

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

10

3/6/2016

Conclusion

The Object-Oriented Paradigm (contd)

Slide 1.41

Documentation activities must be performed in

parallel with all other development and
maintenance activities

Slide 1.43

Both data and actions are of equal importance

Object:
A software component that incorporates both data and
the actions that are performed on that data

There is no separate documentation phase

Example:
Bank account
Data:
account balance
Actions: deposit, withdraw, determine balance

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Structured versus Object-Oriented Paradigm

1.9 The Object-Oriented Paradigm

Slide 1.42

Slide 1.44

The structured paradigm was successful initially

It started to fail with larger products (> 50,000 LOC)

Postdelivery maintenance problems (today, 70 to

80% of total effort)

Reason: Structured methods are

Action oriented (e.g., finite state machines, data flow
diagrams); or
Data oriented (e.g., entity-relationship diagrams,
Jacksons method);
But not both
Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Figure 1.7

Information hiding
Responsibility-driven design
Impact on maintenance, development

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

11

3/6/2016

Information Hiding

Strengths of the Object-Oriented Paradigm (contd)

Slide 1.45

In the object-oriented version

Slide 1.47

The solid line around accountBalance denotes that

outside the object there is no knowledge of how
accountBalance is implemented

Well-designed objects are independent units

Everything that relates to the real-world item being
modeled is in the corresponding object
encapsulation
Communication is by sending messages
This independence is enhanced by responsibility-driven
design (see later)

In the classical version

All the modules have details of the implementation of
account_balance

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Strengths of the Object-Oriented Paradigm

Strengths of the Object-Oriented Paradigm (contd)

Slide 1.46

With information hiding, postdelivery maintenance

is safer

Slide 1.48

The chances of a regression fault are reduced

The object-oriented paradigm reduces complexity

because the product generally consists of independent
units

Development is easier
Objects generally have physical counterparts
This simplifies modeling (a key aspect of the objectoriented paradigm)

A classical product conceptually consists of a

single unit (although it is implemented as a set of
modules)

The object-oriented paradigm promotes reuse

Objects are independent entities

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

12

3/6/2016

Responsibility-Driven Design

Analysis/Design Hump
Slide 1.49

Also called design by contract

Slide 1.51

There is a jolt between analysis (what) and design

(how)

Send flowers to your mother in Chicago

Structured paradigm:

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

Object-oriented paradigm:
Objects enter from the very beginning

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Analysis/Design Hump (contd)

Classical Phases vs Object-Oriented Workflows

Slide 1.50

Slide 1.52

In the classical paradigm

Classical analysis
Determine what has to be done

Design

Figure 1.8

Determine how to do it
Architectural design determine the modules
Detailed design design each module

There is no correspondence between phases and

workflows

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

13

3/6/2016

Removing the Hump

Object-Oriented Paradigm
Slide 1.53

In the object-oriented paradigm

Slide 1.55

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

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

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

Again, the transition is smooth

The difference between the two paradigms is

shown on the next slide

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

In More Detail

The objects are then coded during the

implementation workflow

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

1.10 The Object-Oriented Paradigm in Perspective

Slide 1.54

Slide 1.56

The object-oriented paradigm has to be used

correctly
All paradigms are easy to misuse

Objects enter here

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

When used correctly, the object-oriented paradigm

can solve some (but not all) of the problems of the
classical paradigm

Figure 1.9

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

14

3/6/2016

Terminology (contd)

The Object-Oriented Paradigm in Perspective (contd)

Slide 1.57

The object-oriented paradigm has problems of its

own

The object-oriented paradigm is the best

alternative available today

Slide 1.59

Software

Program, system, product

Methodology, paradigm

However, it is certain to be superseded by something

better in the future

Object-oriented paradigm
Classical (traditional) paradigm

Technique

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

1.11 Terminology

Terminology (contd)
Slide 1.58

Slide 1.60

Client, developer, user

Mistake, fault, failure, error

Internal software

Defect

Contract software

Bug

Commercial off-the-shelf (COTS) software

Open-source software

A bug crept into the code

instead of
I made a mistake

Linus's Law
Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

15

3/6/2016

Object-Oriented Terminology

1.12 Ethical Issues

Slide 1.61

Data component of an object

Slide 1.63

State variable
Instance variable (Java)
Field (C++)
Attribute (generic)

Developers and maintainers need to be

Hard working
Intelligent
Sensible
Up to date and, above all,
Ethical

Action component of an object

Member function (C++)
Method (generic)

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

IEEE-CS ACM Software Engineering Code of

Ethics and Professional Practice
www.acm.org/serving/se/code.htm

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

Object-Oriented Terminology (contd)

Slide 1.62

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

Copyright 2011 by The McGraw-Hill Companies, Inc. All rights reserved.

16