Chapter 2

 Software Engineering
Slide Set to accompany
Software Engineering: A Practitioner’s
Approach, 8/e
by Roger S. Pressman and Bruce R. Maxim

Slides copyright © 1996, 2001, 2005, 2009, 2014 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, 8/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, 8/e (McGraw-Hill 2014). Slides copyright 2014 by
Roger Pressman. 1
Software Engineering
 Some realities:

a concerted effort should be made to understand
the problem before a software solution is developed
 design becomes a pivotal activity

 software should exhibit high quality

 software should be maintainable

2
Software Engineering
 What is it?
Software engineering encompasses a process, a
collection of methods (practice) and an array of
tools that allow professionals to build high-
quality computer software.
 Who does it?

Software engineers apply the software engineering

process.
3
Software Engineering
 Why is it important?
Software engineering is important because it
enables us to build complex systems in a timely
manner and with high quality. It imposes
discipline to work that can become quite
chaotic, but it also allows the people who build
computer software to adapt their approach in a
manner that best suits their needs.
4
Software Engineering
What are the steps?
You build computer software like you build any
successful product, by applying an agile,
adaptable process that leads to a high-quality
result that meets the needs of the people who
will use the product. You apply a software
engineering approach.

5
Software Engineering
 What is the work product?
From the point of view of a software engineer,
the work product is the set of programs,
content (data), and other work products that
are computer software. But from the user’s
viewpoint, the work product is the resultant
information that somehow makes the user’s
world better.
6
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).

7
A Layered
Technology
tools

methods

process model

a “quality” focus

Software Engineering

8
The Quality
 Any engineering approach (including software
engineering) must rest on an organizational
commitment to quality.
 Quality management is a continuous process
improvement culture, and it is this culture that
ultimately leads to the development of
increasingly more effective approaches to
software engineering. The bedrock that supports
software engineering is a quality focus.
9
Process Model
 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 that must be established for
effective delivery of software engineering technology.
 The software process forms the basis for management control of
software projects and establishes the context in which technical
methods are applied, work products (models, documents, data,
reports, forms, etc.) are produced, milestones are established,
quality is ensured, and change is properly managed

10
Methods
 Software engineering methods provide the technical
how-to’s for building software.
 Methods encompass a broad array of tasks that
include communication, requirements analysis, design
modeling, program construction, testing, and support.
 Software engineering methods rely on a set of basic
principles that govern each area of the technology and
include modeling activities and other descriptive
techniques.

11
Tools
 Software engineering tools provide automated or
semi-automated support for the process and the
methods.
 When tools are integrated so that information created
by one tool can be used by another, a system for the
support of software development, called computer-
aided software engineering , is established.

12
A Process
Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by
Roger Pressman. 13
The Software Process
 A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.
 An activity strives to achieve a broad objective (e.g.,
communication with stakeholders) and is applied regardless of the
application domain, size of the project, complexity of the effort, or
degree of rigor with which software engineering is to be applied.
 An action (e.g., architectural design) encompasses a set of tasks
that produce a major work product (e.g., an architectural model).
 A task focuses on a small, but well-defined objective (e.g.,
conducting a unit test) that produces a tangible outcome.

14
Framework
Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment

15
Umbrella
Activities
 Software project tracking and control
allows the software team to assess progress against the project plan
and take any necessary action to maintain the schedule.
 Risk management
assesses risks that may affect the outcome of the project or the quality
of the pro duct
 Software quality assurance
defines and conducts the activities required to ensure software quality.
 Technical reviews
assess software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity .
16
Umbrella
Activities
 Measurement
defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders’ needs.
 Software configuration management
manages the effects of change throughout the software process.
 Reusability management
defines criteria for work product reuse (including software components) and
establishes mechanisms to achieve reusable components.
 Work product preparation and production
encompass the activities required to create work products such as models,
documents, logs, forms, and lists.

17
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).

18
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 compartmentalized? 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?

19
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?

20
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?

21
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?

22
Hooker’s General
Principles
 1: The Reason It All Exists
A software system exists for one reason: to provide value to its users
 2: Keep It Simple, Stupid!
All design should be as simple as possible. This facilitates having a more easily understood and easily maintained
system.
 3: Maintain the Vision
 4: What You Produce, Others Will Consume
 5: Be Open to the Future
A system with a long lifetime has more value
 6: Plan Ahead for Reuse
 7: Think!
Placing clear, complete thought before action almost always produces better results

23