Why Software Engineering??!!!

0
Chapter 1
● Software & Software Engineering
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
What is
Software?
Software is:
(1) instructions (computer programs) that
when executed provide desired features,
function, and performance; (2) data
structures that enable the programs to
effectively manipulate information and
(3) documentation that describes the
operation and use of the programs.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
 What is Software?
● Software is developed or engineered, it
is not manufactured in the classical
sense.
● Although the industry is moving
toward component-based construction,
most software continues to be custom-
built.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Software
Applications
● system software
● application software
● engineering/scientific
software
● embedded software
● product-line software
● WebApps (Web applications)
is a set of software-intensive systems sharing a
● AI software common, managed set of features that satisfy the
specific needs of a particular market segment or
mission and that are developed from a common set of
core assets in a prescribed way.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Characteristics of WebApps - I
● Network intensiveness. A WebApp on a network must
serve the needs of a diverse community of clients.
● Concurrency. A large number of users may access the
WebApp at one time.
● Unpredictable load. The number of users of the
WebApp may vary from day to day.
● Performance. If a WebApp user must wait too long (for
access, for server-side processing, for client-side
formatting and display), he or she may decide to go
elsewhere.
● Availability. Although expectation of 100 percent
availability is unreasonable, users of popular WebApps
often demand access on a “24/7/365” basis.

0
Characteristics of WebApps - II
● Data driven. The primary function of many WebApps is to
use hypermedia to present text, graphics, audio, and video
content to the end-user.
● Content sensitive. The quality and aesthetic nature of
content remains an important determinant of the quality of a
WebApp.
● Continuous evolution. Unlike conventional application
software that evolves over a series of planned,
chronologically-spaced releases, Web applications evolve
continuously.
● Security. Because WebApps are available via network
access, it is difficult, if not impossible, to limit the population
of end-users who may access the application.

0
Software costs
● Software costs often dominate computer
system costs. The costs of software on
a PC are often greater than the
hardware cost.
● Software costs more to maintain than it
does to develop. For systems with a
long life, maintenance costs may be
several times development costs.
● Software engineering is concerned with
cost-effective software development.
Ideal vs. actual
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
 Standish Group Data

● Data on
9236
projects
completed in
2004
History
● The field of software engineering was
born in 1968 in response to constant
failures of large software projects to
meet schedule and budget constraints
● Recognition of "the software crisis"
● Term became popular after NATO
Conference in Garmisch Partenkirchen
(Germany), 1968

0
 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
portable with other more modern
systems or databases.
● software must be re-architected to
make it viable within a network
environment.
0
Software Engineering
● Some realities:
● a concerted effort should be made to understand the
problem before a software solution is developed
● design becomes a critical activity
● software should exhibit high quality
● software should be maintainable
● The seminal definition:
● [Software engineering is] the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works efficiently
on real machines.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Software Engineering
● The IEEE definition:
● Software Engineering:
(1) The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software; that is,
the application of engineering to software.
(2) The study of approaches as in (1).

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
 Relationships between
SE and other CS disciplines
● Programming languages
● Operating systems
● Data bases
● Artificial intelligence
● Theory

0
0
Relationships between
SE and other disciplines

● Management science
● Systems engineering
● Others

0
 Software process activities

● Software specification, where customers and

engineers define the software that is to be
produced and the constraints on its operation.
● SoftwareText
development, where the software is
designed and programmed.
● Software validation, where the software is
checked to ensure that it is what the customer
requires.
● Software evolution, where the software is
modified to reflect changing customer and
market requirements.

0
 A Layered Technology

tool
s
methods

process
model
Any engineering approach (including software engineering) must rest on an
a “quality”
organizational commitment to quality. The bedrock that supports software engineering
is a quality focus.
focus
● The foundation for software engineering is the process layer. The software
engineering process is the glue that holds the technology layers together and enables
rational and timely development of computer software. Process defines a framework Software
● Software engineering methods provide the technical how-to’s for building software.
Methods encompass a broad array of tasks that include communication, requirements Engineering
analysis, design modeling, program construction, testing, and support.
● Software engineering tools provide automated or semi automated support for the
process and the methods.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
 A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

A process framework establishes the foundation for a complete software engineering

process by identifying a small number of framework activities that are applicable to all
software projects, regardless of their size or complexity.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
 Framework Activities
● Communication
● Planning
● Modeling
● Analysis of requirements
● Design
● Construction
● Code generation
● Testing
● Deployment

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
 Umbrella Activities
● Software project management
● Formal technical reviews
● Software quality assurance
● Software configuration management
● Work product preparation and production
● Reusability management
● Measurement
● Risk management

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Adapting a Process Model
● the overall flow of activities, actions, and tasks and the
interdependencies among them
● the degree to which actions and tasks are defined within
each framework activity
● the degree to which work products are identified and
required
● the manner which quality assurance activities are applied
● the manner in which project tracking and control activities
are applied
● the overall degree of detail and rigor with which the
process is described
● the degree to which the customer and other stakeholders
are involved with the project
● the level of autonomy given to the software team
● the degree to which team organization and roles are
prescribed

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
The Essence of Practice
● Polya suggests:
1. Understand the problem (communication and
analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and
quality assurance).

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Understand the Problem
● Who has a stake in the solution to the problem?
That is, who are the stakeholders?
● What are the unknowns? What data, functions,
and features are required to properly solve the
problem?
● Can the problem be classified? Is it possible to
represent smaller problems that may be easier
to understand?
● Can the problem be represented graphically? Can
an analysis model be created?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Plan the Solution
● Have you seen similar problems before? Are there patterns
that are recognizable in a potential solution? Is there
existing software that implements the data, functions,
and features that are required?
● Has a similar problem been solved? If so, are elements of the
solution reusable?
● Can subproblems be defined? If so, are solutions readily
apparent for the subproblems?
● Can you represent a solution in a manner that leads to
effective implementation? Can a design model be created?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Carry Out the Plan
● Does the solution conform to the plan? Is source
code traceable to the design model?
● Is each component part of the solution provably
correct? Has the design and code been
reviewed, or better, have correctness proofs
been applied to algorithm?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Examine the Result
● Is it possible to test each component part of the
solution? Has a reasonable testing strategy been
implemented?
● Does the solution produce results that conform to
the data, functions, and features that are required?
Has the software been validated against all
stakeholder requirements?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Hooker’s General Principles
● 1: The Reason It All Exists
● 2: KISS (Keep It Simple, Stupid!)
● 3: Maintain the Vision
● 4: What You Produce, Others Will Consume
● 5: Be Open to the Future
● 6: Plan Ahead for Reuse
● 7: Think!

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
 Software Myths
● Affect managers, customers (and
other non-technical stakeholders)
and experts
● Are believable because they often
have elements of truth,
but …
● Always lead to bad decisions,
therefore …
● Insist on reality as you navigate your
way through software engineering

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
How It all Starts
● SafeHome:
● Every software project is caused by some
business need—
• the need to correct a defect in an existing
application;
• the need to the need to adapt a ‘legacy system’ to
a changing business environment;
• the need to extend the functions and features of
an existing application, or
• the need to create a new product, service, or
system.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
 Software Engineering

● Software Engineering is a collection of

techniques, methodologies and tools that help
with the production of
● a high quality software system
● with a given budget
● before a given deadline
while change occurs.