Supplementary Slides for

Software Engineering:
A Practitioner's Approach, 6/e
Part 1
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

Instructor: Dr. Lawrence Y. Deng

[email protected]
Grading : attendance 15%, Mid Test 25%, Final Test 25%, Project 35%

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
 Software Engineering: A Practitioner’s Approach, 6/e

Chapter 1
Software and Software Engineering

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
 Software’s Dual Role
 Software is a product
 Delivers computing potential

 Produces, manages, acquires, modifies, displays, or transmits

information
 Software is a vehicle for delivering a product
 Supports or directly provides system functionality

 Controls other programs (e.g., an operating system)

 Effects communications (e.g., networking software)

 Helps build other software (e.g., software tools)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
 What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
 What is Software?

 software is engineered
 software doesn’t wear out
 software is complex

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
 Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
 Software Applications
 system software
 application software
 engineering/scientific software
 embedded software
 product-line software
 WebApps (Web applications)
 AI software

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
 Software—New Categories
 Ubiquitous computing—wireless
computing—wireless networks

 Netsourcing—the Web as a computing engine

 Open source—”free” source code open to the computing community (a blessing, but
also a potential curse!)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
  Also … (see Chapter 32)
 Data mining

 Grid computing

 Cognitive machines

 Software for nanotechnologies

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
 Legacy Software
Why must it change?
 software must be adapted to meet the needs
of new computing environments or
technology.
 software must be enhanced to implement
new business requirements.
 software must be extended to make it
interoperable with other more modern
systems or databases.
 software must be re-architected to make it
viable within a network environment.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
 Software Evolution
 The Law of Continuing Change (1974): E-type systems must be continually adapted else they become
progressively less satisfactory.
 The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases unless work is
done to maintain or reduce it.
 The Law of Self Regulation (1974): The E-type system evolution process is self-regulating with distribution of
product and process measures close to normal.
 The Law of Conservation of Organizational Stability (1980): The average effective global activity rate in an
evolving E-type system is invariant over product lifetime.
 The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with it, developers, sales
personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution.
 The Law of Continuing Growth (1980): The functional content of E-type systems must be continually increased to
maintain user satisfaction over their lifetime.
 The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining unless they are
rigorously maintained and adapted to operational environment changes.
 The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, multi-agent
feedback systems and must be treated as such to achieve significant improvement over any reasonable base.

Source: Lehman, M., et al, “Metrics and Laws of Software Evolution—The Nineties View,”
Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997, can be
downloaded from: http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
 Software Myths
 Affect managers, customers (and other non-technical
stakeholders) and practitioners
 Are believable because they often have elements of truth,

but …
 Invariably lead to bad decisions,

therefore …
 Insist on reality as you navigate your way through
software engineering

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12