Chapter 2

Software Engineering: A Practitioners Approach

Roger Pressman & Bruce Maxim

Sources:
Prescribed textbook by Pressman &Maxim
Wikipedia
Slides by Ankit Tanna (Google Drive)
Slides by Roger Pressman
 Software Engineering Realities
A concerted effort should be made to understand the
problem before a software solution is developed.
If I had an hour to solve a problem Id spend 55 minutes thinking
about the problem and 5 minutes thinking about solutions. Albert
Einstein
design becomes a pivotal activity
software should exhibit high quality
software should be maintainable

Software in all of its forms an across all of its

application domains should be engineered
24
 Software Engineering Definitions
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.
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).

25
 tools
methods
process model
a quality focus

Software Engineering

These slides are designed to accompany Software Engineering: A Practitioners Approach, 8/e (McGraw-Hill 2014). Slides copyright
2014 by Roger Pressman.
A quality Focus
Quality ensure makes customers come back and reduce effort
in maintenance and changes.
Continuous improvement towards more effective approaches
to software engineering.
The bedrock that supports software engineering is a quality
focus.
Process:
It is the foundation layer for software engineering.
It defines a framework for a set of key process areas (KPA) to
effectively manage and deliver quality software in a cost
effective manner.
The process defines the tasks to be performed and the order
in which they are to be performed
Methods:
It provide the technical how-to's for building software.
Methods encompass a broad array of tasks that include
requirements analysis, design, program construction, testing,
and support.
There could be more than one technique to perform a task
and different techniques could be used in different situations.

Tools:
Provide automated or semi-automated or just capturing
support for the process, methods and quality control.
When tools are integrated so that information created by one
tool can be used by another, a system for the support of
software development.
 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 Practitioners Approach, 8/e (McGraw-Hill 2014). Slides copyright
29
2014 by Roger Pressman.
 Process framework
Why process :
A process defines who is doing what, when and how
to reach a certain goal.
To build complete software process.
Identified a small number of framework activities
that are applicable to all software projects,
regardless of their size or complexity.
It encompasses a set of umbrella activities that
are applicable across the entire software process.
 Generic Process Framework Activities
Communication:
Heavy communication with customers, stakeholders, team
Encompasses requirements gathering and related activities
Planning:
Workflow that is to follow
Describe technical task, likely risk, resources will require, work
products to be produced and a work schedule.
Modeling:
Help developer and customer to understand requirements (Analysis of
requirements) & Design of software
Construction
Code generation: either manual or automated or both
Testing to uncover error in the code.
Deployment:
Delivery to the customer for evaluation
Customer provide feedback
 Umbrella Activities
Software project tracking and control
Assessing progress against the project plan.
Take adequate action to maintain schedule.
Formal technical reviews
Assessing software work products in an effort to uncover and remove errors before
goes into next action or activity.
Software quality assurance
Define and conducts the activities required to ensure software quality.
Software configuration management
Manages the effects of change.
Document preparation and production
Help to create work products such as models, documents, logs, form and list.
Reusability management
Define criteria for work product reuse
Mechanisms to achieve reusable components.
Measurement
Define and collects process, project, and product measures
Assist the team in delivering software that meets customers needs.
Risk management
Assesses risks that may effect that outcome of project or quality of product (i.e.
software)
 The Process Model: Adaptability
The framework activities will always be
applied on every project ... BUT
The tasks for each activity will vary based on:
The type of project (an entry point to the model)
Characteristics of the project
Common sense judgment; concurrence of the
project team
 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 Practitioners Approach, 8/e (McGraw-Hill 2014). Slides copyright
2014 by Roger Pressman.
 Software Engineering Practice
Practice is a broad array of concepts, principles,
methods, and tools that you must consider as
software is planned and developed.

It represents the detailsthe technical

considerations and how tosthat are below the
surface of the software processthe things that
youll need to actually build high-quality
computer software.
 The Essence of Practice
from How to Solve It by George Polya

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 Practitioners Approach, 8/e (McGraw-Hill 2014). Slides copyright
2014 by Roger Pressman.
 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 Practitioners Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
 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 sub-problems be defined? If so, are solutions
readily apparent for the sub-problems?
Can you represent a solution in a manner that leads
to effective implementation? Can a design model be
created?
Design
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman.
 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 Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman.
 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 Practitioners Approach, 8/e (McGraw-Hill 2014). Slides copyright
2014 by Roger Pressman.
David Hookers General Principles
1. The Reason It All Exists
To provide value to its users.
If it does not add value, dont do it.
2. KISS (Keep It Simple, Stupid!)
As simple as possible, but no simpler.
3. Maintain the Vision
Conceptual and architectural integrity
4. What You Produce, Others Will Consume
5. Be Open to the Future
6. Plan Ahead for Reuse
7. Think!
Perfection of means and confusion of goals
seem - in my opinion - to characterize our age
Albert Einstein
 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 slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright
2009 by Roger Pressman.
 Software Myths
Management myths
Managers in most disciplines, are often under pressure to
maintain budgets, keep schedules on time, and improve
quality.

Myth1: We already have a book that's full of standards and

procedures for building software, won't that provide my
people with everything they need to know?
Reality :
Are software practitioners aware of existence standards?
Does it reflect modern software engineering practice?
Is it complete? Is it streamlined to improve time to delivery
while still maintaining a focus on quality?
Myth2: If we get behind schedule, we can add more
programmers and catch up
Reality: Software development is not a mechanistic process like
manufacturing. Adding people to a late software project
makes it later.
People can be added but only in a planned and well-
coordinated manner
(The Mythical Man Month NB)

Myth3: If I decide to outsource the software project to a third

party, I can just relax and let that firm build it.
Reality: If an organization does not understand how to manage
and control software projects internally, it will invariably
struggle when it outsource software projects
Customer Myths
Customer may be a person from inside or outside the company
that has requested software under contract.

Myth1: A general statement of objectives is sufficient to begin

writing programs we can fill in the details later.
Reality: A poor up-front definition is the major cause of failed
software efforts. A formal and detailed description of the
information domain, function, behavior, performance,
interfaces, design constraints, and validation criteria is
essential. These characteristics can be determined only after
thorough communication between customer and developer.
Myth2: Project requirements continually change, but change can
be easily accommodated because software is flexible.
Reality: Customer can review requirements and recommend
modifications with relatively little impact on cost. When changes
are requested during software design, the cost impact grows
rapidly. Below mentioned figure for reference.
Practitioner's myths

Myth1: Once we write the program and get it to work, our job is
done.
Reality: Someone once said that "the sooner you begin 'writing
code', the longer it'll take you to get done." Industry data
indicate that between 60 and 80 percent of all effort expended on
software will be expended after it is delivered to the customer for
the first time.
What impact will this assumption have on the Failure curve of
the software?

Myth2: Until I get the program "running" I have no way of

assessing its quality.
Reality: One of the most effective software quality assurance
mechanisms can be applied from the inception of a projectthe
formal technical review.
Myth3: The only deliverable work product for a successful
project is the working program.
Reality: A working program is only one part of a software
configuration that includes many elements. Documentation
provides a foundation for successful engineering and, more
important, guidance for software support.
What impact will this attitude have on the Failure curve of the
software and the maintenance cost?

Myth4 : Software engineering will make us create voluminous

and unnecessary documentation and will invariably slow us
down.
Reality: Software engineering is not about creating documents.
It is about creating quality. Better quality leads to reduced
rework. And reduced rework results in faster delivery times.
 How It all Starts
Every software project is precipitated 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 Practitioners Approach, 8/e (McGraw-Hill 2014). Slides copyright
50
2014 by Roger Pressman.