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
Slide 2
Slide 1.2 Copyright 2011 by The McGraw-Hill Companies, Inc. All
rights reserved. CHAPTER 1 THE SCOPE OF SOFTWARE ENGINEERING
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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)
Slide 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
Slide 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 clients
requirements l Analysis (specification) phase Analyze the clients
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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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]
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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 clients
computer(s)
Slide 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
Slide 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)
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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!!!!
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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,
Jacksons method); But not both
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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)
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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
Slide 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)
Slide 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
Slide 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