Intro To Software Engineering
Intro To Software Engineering
Chapter 1
These slides are designed and adapted from slides provided by Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009) by Roger Pressman and Software Engineering 9/e Addison Wesley 2011 by Ian Sommerville
What is
The product
that software professionals build and then support
Software?
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.
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.
Ef ficiency
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).
Wear vs.
Deterioration
Failure
rate
increased failure
rate due to side effects
change
actual curve
idealized curve
Time
Software
Applications
SoftwareNew Categories
Open world computingpervasive, ubiquitous, distributed computing due to
wireless networking. How to allow mobile devices, personal computer,
enterprise system to communicate across vast network.
Netsourcingthe Web as a computing engine. How to architect simple and
sophisticated applications to target end-users worldwide.
Open sourcefree 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
10
12
Answer
What is software?
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.
13
Description
Maintainability
Dependability and
security
Efficiency
Acceptability
14
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-tos for building software. It encompasses many tasks including
communication, requirement analysis, design modeling, program construction, testing15and
support.
Tools provide automated or semi-automated support for the process and methods.
Software Process
16
17
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
stakeholders 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.
18
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
19
20
21
22
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?
23
24
25
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
27
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.
28
SafeHome:
Every software project is precipitated by some
business need
29
Case studies
A personal insulin pump
An embedded system in an insulin pump used by diabetics to
maintain blood glucose control.
30
31
32
33
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.
34
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.
36
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.
37
38
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.
39
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.
40
41
42
43
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.
44