CMPC-204: Software Engineering

• Software & Software Engineering

Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

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

Software Engineering 9/e

By Ian Sommerville

Lecture 1 1

These slides are designed and adapted from slides provided by Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009) by Roger Pressman and Software Engineering 9/e Addison Wesley 2011 by Ian Sommerville
 Nature of
delivering aSoftware
Software functions both as a product and as a vehicle for
product.
•Software as a Product:
•Delivers the computing potential embodied by computer
hardware or networks.
•It acts as an information transformer by producing, managing,
acquiring, modifying, displaying, or transmitting information.
•Can reside in various devices, including mobile phones, tablets,
desktops, or mainframes.
2
 Nature of
• Software
Software as a Vehicle:
• Acts as the basis for the control of the computer (e.g.,
operating systems).
• Facilitates the communication of information (e.g.,
networks).
• Enables the creation and control of other programs (e.g.,
software tools and environments).

3
 What is
Software?
The product that software professionals build and then support
over the long term.
Software encompasses: (1) instructions (computer programs)
that when executed provide desired features, function, and
performance; (2) data structures that enable the programs to
adequately store and manipulate information and (3)
documentation that describes the operation and use of the
programs.

4
Software products
• Generic products
• Stand-alone systems that are marketed and sold to any customer
who wishes to buy them.
• Examples – PC software such as editing, graphics programs,
project management tools; CAD software; software for specific
markets such as appointments systems for dentists.
• Customized products
• Software that is commissioned by a specific customer to meet
their own needs.
• Examples – embedded control systems, air traffic control
software, traffic monitoring systems.

5
 Why Software is
Important?

• The economies of ALL developed nations are dependent on

software.
• More and more systems are software controlled ( transportation,
medical, telecommunications, military, industrial, entertainment,)
• Software engineering is concerned with theories, methods and tools
for professional software development.
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.
 Features of
Software?
• Its characteristics that make it different from other things human being
build.
Features of such logical system:
• Software is developed or engineered, it is not manufactured in the
classical sense which has quality problem.
• Software doesn't "wear out.” but it deteriorates (due to change). Hardware
has bathtub curve of failure rate ( high failure rate in the beginning, then drop to
steady state, then cumulative effects of dust, vibration, abuse occurs).
• Although the industry is moving toward component-based construction
(e.g. standard screws and off-the-shelf integrated circuits), most
software continues to be custom-built. Modern reusable components
encapsulate data and processing into software parts to be reused by
different programs. E.g. graphical user interface, window, pull-down
menus in library etc.
8
Wear vs.
Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve
9
Time
 Software
Applications
• 1. System software: such as compilers, editors, file management utilities
• 2. Application software: stand-alone programs for specific needs.
• 3. Engineering/scientific software: Characterized by “number crunching”algorithms. such
as automotive stress analysis, molecular biology, orbital dynamics etc
• 4. Embedded software resides within a product or system. (key pad control of a
microwave oven, digital function of dashboard display in a car)
• 5. Product-line software focus on a limited marketplace to address mass consumer
market. (word processing, graphics, database management)
• 6. WebApps (Web applications) network centric software. As web 2.0 emerges, more
sophisticated computing environments is supported integrated with remote database and
business applications.
• 7. AI software uses non-numerical algorithm to solve complex problem. Robotics, expert
system, pattern recognition game playing 10
 Software—New
Categories
• Open world computing—pervasive, ubiquitous, distributed computing due to
wireless networking. How to allow mobile devices, personal computer,
enterprise system to communicate across vast network.
• Netsourcing—the Web as a computing engine. How to architect simple and
sophisticated applications to target end-users worldwide.
• Open source—”free” source code open to the computing community (a
blessing, but also a potential curse!)
• Also … (see Chapter 31)
• Data mining
• Grid computing
• Cognitive machines
• Software for nanotechnologies
11

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman.
Software Engineering
Definition
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).
Importance of Software
Engineering

• More and more, individuals and society rely on advanced

software systems. We need to be able to produce reliable and
trustworthy systems economically and quickly.
• It's usually cheaper in the long run to use proper software
methods instead of writing programs like a quick project. Most
of the cost comes from making changes to the software after
it's being used..

13
• It is usually
. cheaper in the long term to follow software
engineering methods instead of writing programs as if it
were a personal project. For most systems, the biggest
costs come from making changes to the software after it's
already in use

14
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
Essential attributes of good
software
Product characteristic Description

Maintainability Software should be written in such a way so that it can evolve to

meet the changing needs of customers. This is important because
software will always need updates as the business changes.

Dependability and Software dependability includes a range of characteristics

security including reliability, security and safety. Dependable software
should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or
damage the system.
Efficiency Software should not make wasteful use of system resources such
as memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilisation, etc.

Acceptability Software must be acceptable to the type of users for which it is

designed. This means that it must be understandable, usable and
compatible with other systems that they use.

15
• Software should be made so it can easily adapt to new
customer needs. This is very important because changes
in software are necessary when businesses change."

16
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
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, testing17and
support.
 Tools provide automated or semi-automated support for the process and methods.
• A process is a set of activities, actions, and tasks done to
create something. It’s not a strict rule for building
software but a flexible way to let people choose the right
tasks for the job. The goal of the process is to deliver
software on time and with good enough quality to satisfy
both the people who funded it and those who will use it.

Software Process 18
• 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
Five Activities of a
subset of overall software features and functionality.

Generic Process
framework 19
 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: It sets rules for reusing parts of the work and creates a
way to make reusable components.
• Work product preparation and production: create work products such as models,
documents, logs, forms and lists.
20
• Sets rules for reusing work and creates a system to make
parts reusable.

21
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
The process should be flexible and able to adjust to different
problems. The process used for one project might be very different
from the process used for another. Some key differences include:

- How activities, actions, and tasks flow and connect

- How detailed the tasks are for each part of the project
- What work products need to be created and used
- How quality checks are done
- How the project is tracked and controlled
- How detailed and strict the process is
- How much the customer and others are involved
- How much freedom the software team has

Adapting a Process
- How the team is organized and what roles they have

Model 22
•Flow of Activities: How tasks are organized and connected.
•Task Definitions: How clearly tasks are outlined in each stage of the project.
•Work Products: What deliverables are needed and how they are identified.
•Quality Assurance: How quality checks are implemented.
•Project Tracking: How the project's progress is monitored and controlled.
•Process Detail: How thorough and detailed the project process is.
•Stakeholder Involvement: How much the customer and other stakeholders are involved.
•Team Autonomy: How much freedom the team has to make decisions.
•Team Organization: How roles and structure within the team are defined.

23
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
•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.

Prescriptive and
Agile Process Models 24
• Prescriptive process models focus on defining tasks and activities in detail. Their
goal is to improve system quality, make projects easier to manage, predict
delivery dates and costs, and guide teams in building a system. However, if these
models are followed too strictly without flexibility, they can lead to unnecessary
paperwork and slow things down.

• Agile process models focus on being flexible and adaptable. They follow
principles that allow for a more informal and quick approach, which is especially
helpful when developing web applications.

25
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
• 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).

The Essence of
Practice 26
• 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?

Understand the
Problem 27
• 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?

Plan the Solution 28

• Here's the simplified version with the same meaning:

• Have you dealt with similar problems before? Are there patterns you recognize that
could help solve this? Is there any existing software that already does what you need?

• Has a similar problem been solved before? If yes, can parts of that solution be reused?

• Can the main problem be broken down into smaller ones? If so, are the solutions to
these smaller problems easy to find?

• Can you describe the solution in a way that makes it easy to build? Can a design plan
be made?

29
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
• 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?
• Here’s a simpler version with the same meaning:

• - **Is each part of the solution guaranteed to be correct?**

• - **Has the design and code been carefully reviewed by others?**
• - **Even better, has the algorithm been proven to always work correctly using formal methods?**

Carry Out the Plan 30

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

Examine the
Result 31
 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/Always lead to bad decisions,
therefore …
•Insist on reality as you navigate your way through
software engineering 32
 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.
33
How It all Starts
• SafeHome:
• Every software project is precipitated by some
business need/ Every software project starts
because of a 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.

34
A patient information system
for mental health care

• A patient information system for mental health care is a system

that stores details about people with mental health problems
and the treatments they've received. Most patients don't need to
stay in hospitals but visit special clinics regularly to meet
doctors who know their issues well. These clinics are not only
in hospitals but also in local clinics or community centers to
make it easier for patients to attend.

35
MHC-PMS

• The MHC-PMS (Mental Health Care-Patient Management

System) is a system used in clinics to manage patient
information. It has a central database where all patient details
are stored. However, it can also run on a regular computer, so
it can be used in places without a secure internet connection.
When the system is connected to the network, it uses the
central database, but when it’s offline, it can still work by
downloading and using copies of patient records.

36
• It uses a main database with patient information and is set
up to run on a PC. This means it can be used at places
without a secure internet connection. When the local
systems have a secure connection, they access the main
database, but they can also download and use patient
records locally if they lose the connection.

37
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
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.

38
• Here’s a simpler version with the same meaning:

• - To create reports that help health service managers

check if performance meets local and government goals.
• - To give medical staff up-to-date information to help
with patient care.

39
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
MHC-PMS key
features
• ### Individual Care Management
• - Clinicians can create, update, and view patient records.
• - The system provides summaries of key issues and treatments for
quick review by doctors.

• ### Patient Monitoring

• - The system tracks patients' records and alerts clinicians if any
potential problems are detected during treatment.

• ### Administrative Reporting

• - The system produces monthly reports showing the number of
patients treated, those entering or leaving care, patients under
special care (sectioned), drugs prescribed, and their costs.
40
• The system creates monthly reports that show how many
patients were treated at each clinic, how many started or
left care, how many were hospitalized, what medicines
were given, and the cost of those medicines.

41
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
MHC-PMS concerns
• ### Privacy
• - Patient information must remain private and only be shared
with authorized medical staff and the patient.

• ### Safety
• - Some patients may be suicidal or dangerous to others. The
system should alert medical staff about these risks whenever
possible.
• - The system must always be available so that doctors can
safely prescribe the right medications without delay.

42
•Privacy: Patient information must stay private and only be shared
•with authorized doctors or medical staff and the patient.
•Safety: Some mental illnesses can make patients want to harm
•themselves or others. The system should alert medical staff
• when patients might be a danger.
•The system needs to be working when needed, or it could affect
•patient safety and make it hard to give the right medication.

43
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
 Additional software
functionality
• - Keep track of instruments, power, and communication
hardware, and report any issues to the management system.
• - Manage power by charging batteries when conditions are
good, and shutting down generators during bad weather (e.g.,
high winds) to avoid damage.
• - Support system updates by allowing parts of the software to
be replaced with new versions and switch to backup
instruments if the system fails.

44
•- Keep an eye on the equipment, power, and
communication systems and report any problems to
management.
•- Manage the power by charging batteries when conditions
are good and shutting down generators during bad weather,
like strong winds.
•- Allow changes to the system, like updating software or
switching to backup equipment if something goes wrong.

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