Introduction to 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

Lecture 1: Chapter
By Ian Sommerville

1
 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.
2
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.

3
 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.
• Expenditure on software represents a significant fraction of GDP in
all developed countries.

4
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.

5
 Features of
Software?
• Its characteristics that make it different from other things
human being build.
• 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.

6
 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. WebApps (Web applications) network centric software. As web 2.0 emerges, more
sophisticated computing environments is supported integrated with remote database
and business applications.
6. AI software uses non-numerical algorithm to solve complex problem. Robotics,
expert system, pattern recognition game playing

7
 Software—New
Categories
• Paid Source (Proprietary): Software with restricted access to its source code,
typically requiring a license or subscription fee to use. Examples include
Microsoft Office, Adobe Photoshop, and MATLAB.
• Open source—”free” source code open to the computing community (a
blessing, but also a potential curse!). Examples include Linux, Python, and
WordPress.

8
Software Engineering
Definition
The important 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).

9
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 is usually cheaper, in the long run, to use software
engineering methods and techniques for software systems
rather than just write the programs as if it was a personal
programming project. For most types of system, the majority
of costs are the costs of changing the software after it has gone
into use.

10
FAQ about software engineering

Question Answer

What is software? Computer programs, data structures and associated

documentation. Software products may be developed for
a particular customer or may be developed for a general
market.
What are the attributes of good software? Good software should deliver the required functionality
and performance to the user and should be
maintainable, dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What is the difference between software Computer science focuses on theory and fundamentals;
engineering and computer science? software engineering is concerned with the practicalities
of developing and delivering useful software.
What is the difference between software System engineering is concerned with all aspects of
engineering and system engineering? computer-based systems development including
hardware, software and process engineering. Software
engineering is part of this more general process.

11
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.

12
Five Activities of a
Generic Process
framework
• 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.
• 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.

13
 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.
• 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.

14
 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

15
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.

MORE TO COME LATER

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

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

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

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

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

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

22
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 …
•Insist on reality as you navigate your way through software
engineering

23
Software Myths -
Programmers
• 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 reviews 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 .

24
Software Myths Examples -
Managers

• Myth 1: We have already have a lot of materials and books for building software. This should
provide my people everything they need to know.
• Reality: They may exist but are they used and reflect modern engineering.

• Myth 2: If we add more programmers, we can catch up with the schedule.

• Reality: Software Engineering is not a manufacturing process. It makes things worse.

• Myth 3: We can outsource the project to a third party and relax.

• Reality: If you do not know how to manage and control software projects, you will struggle when
you outsource them

25
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.

26
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.

27
Insulin pump hardware
architecture

28
Activity model of the
insulin pump

29
 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.

30
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.

31
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.

32
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.

33
The organization of the MHC-
PMS

34
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.

35
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.

36