Chapter 2-3: 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. 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
 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, 8/e
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 2
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, 8/e
(McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 3
 A Layered

Technology
Quality focus is the
bedrock that supports
SE tools
 The process layer
is the foundation methods
for SE
process model

a “quality” focus
 Methods provides the
technical “how to’s” for
building software
Software Engineering
 Tools provides
automated or Simi
automated
These slides are designed support
to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4
 A Process
Framework
It establishes the foundation – by identifying a
number of framework activities
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, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5
 Framework
Activities
 Communication –
requirements gathering
 Planning – establishes a plan,
likely risks, resources required etc
 Modeling – to better understand
software requirements
 Analysis of requirements
 Design
 Construction
Code generation

 Testing
 Deployment – for evaluation

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6
 Umbrella
Activities
 Software project management – to asses
progress against the project plan
 Formal technical reviews – to uncover and
remove errors
 Software quality assurance – to ensure quality
 Software configuration management – to
manage change
 Work product preparation and production –
includes activities required to create models,
documents, forms, etc.
 Reusability management – how to achieve
reusable components
 Measurement – measures that assist the team
in delivering software that meet the
customer's needs
 Risk management – asses risk that may affect
(McGraw-Hill 2009). Slidesthe outcome
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
copyright 2009 by Roger Pressman. 7
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. 8
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?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9
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. 10
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. 11
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. 12
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! The more you think about it
the more you are likely to do it right

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13
The process
“software development is a social learning process.
The process is a dialogue in which the knowledge
that must become the software is brought together
and embodied in the software. The process provides
interaction between users and designers, between
users and evolving tools, and between designers and
evolving tools [technology].”

 building computer software is an iterative social

learning process
 A process is defined as a collection of work
activities, actions, and tasks that are performed
14
when some work product is to be created
Software Process
 Defines the approach that is taken as software is
engineered
 Different types of projects require different
software processes
 Software processes are adapted to meet the needs
of software engineers and managers
 Software processes provide a framework for
managing activities
 It is a roadmap that helps you create high quality
product

15
 A Generic Process Model

A process includes
activities, actions and
work tasks

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

Describes
how
activities,
actions
and task
that occur
within
each frame
work
activities
are
organised

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
Identifying a Task Set
 A task set defines the actual work to be done to accomplish the
objectives of a software engineering action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be applied
 The goal is to understand what various stakeholders want.
 For small projects – requirements gathering can be done by just
a phone call P33-34

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18
Process Patterns
 Every software team encounters problems as it moves through
the software process so it would be useful if:
 Proven solutions to the encountered problems are readily available to the
team so that the problems could be addressed and resolved quickly
 A process pattern
 describes a process-related problem that is encountered during software
engineering work,
 identifies the environment in which the problem has been encountered,
and
 suggests one or more proven solutions to the problem.
 Stated in more general terms, a process pattern provides you
with a template [Amb98] eg, page 37

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 19
Process Pattern Types
 Stage patterns—defines a problem associated with a framework
activity for the process.
 Task patterns—defines a problem associated with a software
engineering action or work task and relevant to successful
software engineering practice
 Phase patterns—define the sequence of framework activities that
occur with the process, even when the overall flow of activities
is iterative in nature.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e
(McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 20
 Process
Patterns

 A template is used to define a pattern

 A template should include:
 Pattern name –meaningful
 Intent – objective of the pattern
 Type[ Task pattern – defines engineering action or work
task
Stage Pattern - defines frame work activity for
the process
Phase pattern – defines sequence or flow of
framework activity
 Initial context – describe conditions that must be present
 Problem – describe the problem to be solved
 Solution – how to implement the pattern correctly
 Resulting context – conditions that result after
implementation
 Related patterns – links to patterns directly related
 Known uses/examples – instances in which pattern is
applicable
 Example of a Pattern (Page 37)
21
Example

22