Chapter 1

Introduction to Software
Engineering

Software Engineering: A Practitioner’s Approach, 6th

edition
by Roger S. Pressman
 Contents
• What is software ?
• Software Characteristics
• The Changing Nature of Software
• Legacy Software
• Software Myths
 Software - Definitions
Software is a collection of instructions that tell a computer what to do. Software
comprises the entire set of programs, procedures, and routines associated with the
operation of a computer system.
(OR)
A software or computer software essentially a type of programs which enable the users to
perform some particular specific task or actually used to operate their computer.
Finally:
Software is
•(1) Instructions (computer programs) that when executed, provide desired function
and performance,
•(2) Data structures that enable the programs to adequately manipulate information,
and
•(3) Documents that describe the operation and use of the programs.
 Software’s Dual Role
• Software is a product
– Transforms information - produces, manages, acquires,
modifies, displays, or transmits information
– Delivers computing potential of hardware and networks
• Software is a vehicle for delivering a product
– Controls other programs (operating system)
– Effects communications (networking software)
– Helps build other software (software tools &
environments)
 Hardware vs. Software
Hardware Software

• • Developed
Manufactur /Engineered
ed • Deteriorates
• Wears out • Custom built
• Built using • Complex
components
• Relatively
 Software Characteristics
• Software is developed or engineered; it is not
manufactured in the classical sense.
• Software doesn’t “wear out”.
• Although the industry is moving toward
component-based construction, most software
continues to be custom built.
 Manufacturing vs. Development
• Once a hardware product has been manufactured, it is
difficult or impossible to modify. In contrast, software
products are routinely modified and upgraded.

• In hardware, hiring more people allows you to

accomplish more work, but the same does not
necessarily hold true in software engineering.

• Unlike hardware, software costs are concentrated in

design rather than production.
Wear vs. Deterioration
Hardware wears out over time
Wear vs. Deterioration (Cont.)
Software deteriorates over time
Component Based vs. Custom Built
• Hardware products typically employ many
standardized design components.

• Most software continues to be custom built.

• The software industry does seem to be

moving (slowly) toward component-based
construction.
 Software Complexity
I believe the hard part of building software to be the
specification, design, and testing of this conceptual
construct, not the labor of representing it and testing
the reliability of the representation.
If this is true, building software will always be hard.
There is inherently no silver bullet.
-Fred Brooks, “No Silver Bullet”
http://www.computer.org/computer/homepage/misc/Brooks/
The Changing Nature of Software
• System Software
• Application Software
• Engineering/Scientific Software
• Embedded Software
• Product-line software
• Web Applications
• AI software
• Ubiquitous Computing
• Netsourcing
• Open Source
• The “New Economy.”
 Legacy Software
• Legacy software is software that has been
around a long time and still fulfils a business
need and include both the legacy software and
the legacy hardware.
• Legacy systems are everywhere; banks, energy
companies (including nuclear plants),
manufacturing of all types (process control),
the defence industry, transportation, hospitals,
insurance, and more.
 Quality of Legacy Software
Legacy systems often evolve for the following
reasons:
•Must be adapted to meet the needs of new
computing environments or technology.
•Must be enhanced to implement new business
requirements.
•Must be extended to make it interoperable with
other modern systems or databases.
•Must be re-architected to make it viable within a
network environment.
 Software Evolution
Regardless of its application domain, size, or complexity,
computer software will evolve over time. Change drives
this process and occurs (Software Maintenance)
-When errors are corrected - (Corrective Maintenance)
-When the software is adapted to a new environment -
(Adaptive Maintenance)
-When the customer requests new features or functions -
(Enhancement Maintenance) and
-When the application is reengineered to provide benefit in
a modern context (Preventive Maintenance).
E-Type Systems:
Software that has been implemented in a real-world
computing context and will therefore evolve over time.
 E-type systems
• 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.
 E-type systems (Cont.)
• 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.
 Software Myths
– These are misleading attitudes that have caused serious
problems for technical people alike.
– Propagate misinformation and confusion
– 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
 Software Myths (Cont.)
• If we get behind schedule, we can add
more programmers and catch up.
• A general statement about objectives is
sufficient to begin building programs.
• Change in project requirements can be
easily accommodated because software
is flexible.
 Software Myths (Cont.)
• Once we write a working program, we’re done.
• Until I get the program running, I have no way of
assessing its quality.
• The only deliverable work product for a
successful project is the working program.
• Software engineering will make us to create too
much documentation and will slow us down.
• Software myths – Management, Customer and
Practitioner
 Management Myths
• “We already have a book of standards and
procedures for building software. It does provide my
people with everything they need to know …”
• “If my project is behind the schedule, I always can
add more programmers to it and catch up …”
(a.k.a. “The Mongolian Horde
concept”)
• “If I decide to outsource the software project to a
third party, I can just relax: Let them build it, and I
will just pocket my profits …”
 Customer Myths
• “A general statement of objectives is sufficient to
begin writing programs - we can fill in the details
later …”.

• “Project requirements continually change but this

change can easily be accommodated because
software is flexible …”
 Practitioner’s Myths
•“Until I get the program running, I have no way of
assessing its quality …”.

•“The only deliverable work product for a successful

project is the working program …”

•“Software engineering is baloney. It makes us

create tons of paperwork, only to slow us down …”