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 1
 Why worry about SW Engineering?
 History of SW failures from http://www.wired.com/software/coolapps/news/2005/11/6935
5
 “…Toyota announced a recall of 160,000 of its Prius hybrid vehicles
following reports of vehicle warning lights illuminating for no reason,
and cars' gasoline engines stalling unexpectedly.”
 1985-1987 -- Therac-25 medical accelerator. Software replaces
electromechanical safety controls. Operating system race condition kills
5 people.
 November 2000 -- National Cancer Institute, Panama City. Doctors
“work-around” software problem that wouldn’t allow them to use 5
radiation shields. Their work-around had unintended consequences
that killed 8 patients. Doctor’s indicted for murder.
 Many more incidents…

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
 Why is it so hard?
 Lots of “parts”. Many more than mechanical devices
 Dishwasher - 128 parts
 Car - 14,000 parts
 Space shuttle - 2.5 million parts
 Red Hat Linux 7.1 - 30 million source lines of code (SLOC)
 Mac Office - 30 million SLOC
 Using 70 programmers = 428,000 SLOC / programmer
 But those are big… what about “normal size programs”?
 Average programmer SLOC (Source lines of code) / day = 100
 5 days/week * 52 weeks/year = 26,000 SLOC / year
 15 programmer team = 390,000 SLOC / year
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
 Why is it so hard? (continued)
 We’re a young field
 ENIAC/ MARK-I in 1946
 FORTRAN - 1957
 But giant - As of 2004, the U. S. Bureau of Labor Statistics counts 760,840 software
engineers holding jobs in the U.S.; for comparison, in the U.S. there are some 1.4
million practitioners employed in all other engineering disciplines combined.
- http://en.wikipedia.org/wiki/Software_engineering
 Still more art than science
 Everything we do is “new”. (We don’t build the exact same house
30 times.)
 Need to have more reproducible results
 Need to have more measurements

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
 Why do projects fail?
Why do projects fail so often?
 Unrealistic or unarticulated project goals
 Inaccurate estimates of needed resources
 Badly defined system requirements
 Poor reporting of the project's status
 Unmanaged risks
 Poor communication among customers, developers, and users
 Use of immature technology
 Inability to handle the project's complexity
 Sloppy development practices
 Poor project management
 Stakeholder politics
 Commercial pressures
List from: http://www.spectrum.ieee.org/sep05/1685

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
 How do we fix it?
 Need to have more reproducible results
 Standard processes / procedures to produce good outcomes
 Design patterns
 Object oriented programming (reuse)
 More measurements of both the software and the process
 More testing at all stages of development
 By creating a better understanding of the process we use to create
software, we’ll create better software faster.

“Software engineering is the application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance
of software.” - IEEE Standard Glossary of Software Engineering Terminology

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 Engineering: A Practitioner’s Approach, 7/e

Chapter 1
Software and Software Engineering
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

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’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 8
 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 9
 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 10
 Wear vs. Deterioration

Hardware System

Software System
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 Applications
 system software - OS, file management, networking, drivers, etc…
 application software - data processing, point of sale, other business
functions…
 engineering/scientific software - CAD, stress analysis, orbital
mechanics
 embedded software - microwave oven keypad, automobile control, cell phone
software, etc…
 product-line software - word processing, inventory control, etc…
 WebApps (Web applications) - many different things today
 AI software - robotics, data mining, expert systems

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
 Software—New Categories
 Ubiquitous 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!)
 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 13
 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 14
 Software Engineering Practice
David Hooker proposed seven principles that focus on software engineering
practice
 The First Principle: The Reason It All Exists: A software system exists for one
reason: to provide value to its users. All decisions should be made with this in mind.
Before specifying a system requirement, before noting a piece of system
functionality
 The Second Principle: Keep It Simple, Stupid: Software design is not a haphazard
process. There are many factors to consider in any design effort. All design should
be as simple as possible, but no simpler

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 15
 Software Engineering Practice
 The Third Principle: Maintain the Vision: A clear vision is essential to the success of a software
project. Without one, a project almost unfailingly ends up being “of two [or more] minds” about
itself.
 The Fourth Principle: What You Produce, Others Will Consume: Seldom is an industrial-strength
software system constructed and used in a vacuum. In some way or other, someone else will use,
maintain, document, or otherwise depend on being able to understand your system.
 The Fifth Principle: Be Open to the Future: A system with a long lifetime has more value. In
today’s computing environments, where specifications change on a moment’s notice and
hardware platforms are obsolete just a few months old, software lifetimes are typically measured
in months instead of years.
 The Sixth Principle: Plan Ahead for Reuse: Reuse saves time and effort.15Achieving a high level
of reuse is arguably the hardest goal to accomplish in developing a software system. The reuse of
code and designs has been proclaimed as a major benefit of using object-oriented technologies.
 The Seventh principle: Think!: This last principle is probably the most overlooked. Placing clear,
complete thought before action almost always produces better results. When you think about something,
you are more likely to do it right.

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 16
 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 17
 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 18
 Software Myths
 Selected myths
 If we get behind schedule we can add more programmers to
catch up
 A general statement of objectives is sufficient to begin writing
programs - we can fill in the details later
 Project requirements change, but change can be easily
accommodated because software is flexible
 Once we write the program and get it working our job is done
 Software engineering will make us create unnecessary
documentation and will invariably slow us down

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 19
 Communication
A Generic Framework
 Heavy collaboration with the customer, other stakeholders and
encompasses requirements gathering and related activities
 Planning
 Establish a plan for the work. Technical task to be conducted, risks, needed
resources, work products to be created, and a schedule
 Modeling
 Creation of models to allow the customer and the developer to better
understand the requirements and design that will achieve those
requirements
 Construction
 Combines code generation and testing required to uncover errors in the
code
 Deployment
 The software (as a complete entity or partially complete increment) is
delivered to the customer who evaluates it and provides feedback.

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 20