Introduction to Software Engineering

Software Engineering: A Practitioner’s Approach, 7/e

by Roger S. Pressman

Software Process

1
Software Engineering
A Layered Technology
tools

methods

process model

a “quality” focus
 Any engineering approach must rest on organizational commitment to quality which fosters a
continuous process improvement culture.
 Process layer as the foundation defines a framework with activities for effective delivery of
software engineering technology. Establish the context where products (model, data, report, and
forms) are produced, milestone are established, quality is ensured and change is managed.
 Method provides technical how-to’s for building software. It encompasses many tasks including
communication, requirement analysis, design modeling, program construction, testing and
support.
2
 Tools provide automated or semi-automated support for the process and methods.
Software Process

 A process is a collection of activities, actions and tasks

that are performed when some work product is to be
created. It is not a rigid prescription for how to build
computer software. Rather, it is an adaptable approach
that enables the people doing the work to pick and
choose the appropriate set of work actions and tasks.
 Purpose of process is to deliver software in a timely
manner and with sufficient quality to satisfy those who
have sponsored its creation and those who will use it.

3
 Communication: communicate with customer to understand objectives and
gather requirements
 Planning: creates a “map” defines the work by describing the tasks, risks
and resources, work products and work schedule.
 Modeling: Create a “sketch”, what it looks like architecturally, how the
constituent parts fit together and other characteristics.
 Construction: code generation and the testing.
 Deployment: Delivered to the customer who evaluates the products and
provides feedback based on the evaluation.

 These five framework activities can be used to all software development

regardless of the application domain, size of the project, complexity of the
efforts etc, though the details will be different in each case.

 For many software projects, these framework activities are applied

iteratively as a project progresses. Each iteration produces a software
increment that provides a subset of overall software features and
functionality.

Five Activities of a Generic

Process framework 4
 Umbrella Activities
Complement the five process framework activities and help team manage and
control progress, quality, change, and risk.
 Software project tracking and control: assess progress against the plan and
take actions to maintain the schedule.
 Risk management: assesses risks that may affect the outcome and quality.
 Software quality assurance: defines and conduct activities to ensure quality.
 Technical reviews: assesses work products to uncover and remove errors
before going to the next activity.
 Measurement: define and collects process, project, and product measures to
ensure stakeholder’s needs are met.
 Software configuration management: manage the effects of change throughout
the software process.
 Reusability management: defines criteria for work product reuse and
establishes mechanism to achieve reusable components.
 Work product preparation and production: create work products such as
models, documents, logs, forms and lists.

5
Adapting a Process Model
The process should be agile and adaptable to problems. Process adopted for one
project might be significantly different than a process adopted from another
project. (to the problem, the project, the team, organizational culture). Among the
differences are:

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
6
Prescriptive and Agile Process
Models

The prescriptive process models stress detailed definition,

identification, and application of process activates and tasks. Intent is
to improve system quality, make projects more manageable, make
delivery dates and costs more predictable, and guide teams of
software engineers as they perform the work required to build a
system.
Unfortunately, there have been times when these objectives were
not achieved. If prescriptive models are applied dogmatically and
without adaptation, they can increase the level of bureaucracy.

Agile process models emphasize project “agility” and follow a set

of principles that lead to a more informal approach to software
process. It emphasizes maneuverability and adaptability. It is
particularly useful when Web applications are engineered.

7
The Essence of Practice
 How does the practice of software engineering fit in the process
activities mentioned above? Namely, communication, planning,
modeling, construction and deployment.
 George Polya outlines the essence of problem solving, 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).

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?

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?

10
Carry Out the Plan

 Does the solutions 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?

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?

12
Hooker’s General Principles for Software
Engineering Practice: important underlying
law

Help you establish mind-set for solid software engineering practice (David
Hooker 96).
1: The Reason It All Exists: provide values to users
2: KISS (Keep It Simple, Stupid! As simple as possible)
3: Maintain the Vision (otherwise, incompatible design)
4: What You Produce, Others Will Consume (code with concern for those
that must maintain and extend the system)
5: Be Open to the Future (never design yourself into a corner as
specification and hardware changes)
6: Plan Ahead for Reuse
7: Think! Place clear complete thought before action produces better results.

13
 Software Myths
Erroneous beliefs about software and the process that is used to
build it.
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 …
Insiston reality as you navigate your way through software
engineering

14
 Software Myths Examples
 Myth 1: Once we write the program and get it to work, our job is done.
 Reality: the sooner you begin writing code, the longer it will take you to get done. 60% to
80% of all efforts are spent after software is delivered to the customer for the first time.

 Myth 2: Until I get the program running, I have no way of assessing its quality.
 Reality: technical review are a quality filter that can be used to find certain classes of
software defects from the inception of a project.

 Myth 3: software engineering will make us create voluminous and unnecessary

documentation and will invariably slow us down.
 Reality: it is not about creating documents. It is about creating a quality product. Better
quality leads to a reduced rework. Reduced work results in faster delivery times.

 Many people recognize the fallacy of the myths. Regrettably, habitual attitudes
and methods foster poor management and technical practices, even when
reality dictates a better approach.

15
How It all Starts

 SafeHome:
 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.

16
Case studies

 A personal insulin pump

 An embedded system in an insulin pump used by diabetics to maintain blood
glucose control.
 A mental health case patient management system
 A system used to maintain records of people receiving care for mental health
problems.
 A wilderness weather station
 A data collection system that collects data about weather conditions in remote
areas.

17
Insulin pump control system
 Collects data from a blood sugar sensor and calculates the amount of
insulin required to be injected.
 Calculation based on the rate of change of blood sugar levels.
 Sends signals to a micro-pump to deliver the correct dose of insulin.
 Safety-critical system as low blood sugars can lead to brain
malfunctioning, coma and death; high-blood sugar levels have long-term
consequences such as eye and kidney damage.

18
Insulin pump hardware
architecture

19
Activity model of the
insulin pump

20
Essential high-level requirements
 The system shall be available to deliver insulin when required.
 The system shall perform reliably and deliver the correct amount of
insulin to counteract the current level of blood sugar.
 The system must therefore be designed and implemented to ensure that
the system always meets these requirements.

21
A patient information system for
mental health care
 A patient information system to support mental health care is a medical
information system that maintains information about patients suffering
from mental health problems and the treatments that they have received.
 Most mental health patients do not require dedicated hospital treatment
but need to attend specialist clinics regularly where they can meet a
doctor who has detailed knowledge of their problems.
 To make it easier for patients to attend, these clinics are not just run in
hospitals. They may also be held in local medical practices or community
centres.

22
MHC-PMS

 The MHC-PMS (Mental Health Care-Patient Management System) is an

information system that is intended for use in clinics.
 It makes use of a centralized database of patient information but has also
been designed to run on a PC, so that it may be accessed and used from
sites that do not have secure network connectivity.
 When the local systems have secure network access, they use patient
information in the database but they can download and use local copies of
patient records when they are disconnected.

23
MHC-PMS goals

 To generate management information that allows health service managers

to assess performance against local and government targets.
 To provide medical staff with timely information to support the treatment
of patients.

24
The organization of the MHC-PMS

25
MHC-PMS key features

 Individual care management

 Clinicians can create records for patients, edit the information in the system,
view patient history, etc. The system supports data summaries so that doctors can
quickly learn about the key problems and treatments that have been prescribed.
 Patient monitoring
 The system monitors the records of patients that are involved in treatment and
issues warnings if possible problems are detected.
 Administrative reporting
 The system generates monthly management reports showing the number of
patients treated at each clinic, the number of patients who have entered and left
the care system, number of patients sectioned, the drugs prescribed and their
costs, etc.

26
MHC-PMS concerns

 Privacy
 It is essential that patient information is confidential and is never disclosed to
anyone apart from authorised medical staff and the patient themselves.
 Safety
 Some mental illnesses cause patients to become suicidal or a danger to other
people. Wherever possible, the system should warn medical staff about
potentially suicidal or dangerous patients.
 The system must be available when needed otherwise safety may be
compromised and it may be impossible to prescribe the correct medication to
patients.

27
Wilderness weather station

 The government of a country with large areas of wilderness decides to

deploy several hundred weather stations in remote areas.
 Weather stations collect data from a set of instruments that measure
temperature and pressure, sunshine, rainfall, wind speed and wind
direction.
 The weather station includes a number of instruments that measure weather
parameters such as the wind speed and direction, the ground and air
temperatures, the barometric pressure and the rainfall over a 24-hour period.
Each of these instruments is controlled by a software system that takes
parameter readings periodically and manages the data collected from the
instruments.


28
The weather station’s
environment

29
 Weather information system
 The weather station system
 This is responsible for collecting weather data, carrying out some initial data
processing and transmitting it to the data management system.
 The data management and archiving system
 This system collects the data from all of the wilderness weather stations, carries
out data processing and analysis and archives the data.
 The station maintenance system
 This system can communicate by satellite with all wilderness weather stations to
monitor the health of these systems and provide reports of problems.

30
 Additional software functionality
 Monitor the instruments, power and communication hardware and report
faults to the management system.
 Manage the system power, ensuring that batteries are charged whenever
the environmental conditions permit but also that generators are shut
down in potentially damaging weather conditions, such as high wind.
 Support dynamic reconfiguration where parts of the software are replaced
with new versions and where backup instruments are switched into the
system in the event of system failure.

31