Software Engineering
Lecture1 - Introduction
CSc 461/561
Contact Information
• Website: CS450.wikispaces.com
CSc 461/561
Required Textbook
• “ Software Engineering”, by Ian Sommerville, The international
Computer Science Series, The Latest Edition (9 th).
CSc 461/561
Grading
Mid Term 1
Week 7
20 %
Mid Term2
Week 12
20 %
Assignments
Week 5, 10
10 %
Final Exam
After Week 15
50 %
Total
CSc 461/561
100 %
Lecture Format
• Help you understand important and hard Media and Multimedia
Systems concepts
• Lectures do not cover everything
• Students responsibility:
o Attend lectures
o Read textbooks
o Download lectures
o Assignments, Exams
CSc 461/561
Course Content
• Introduction to software engineering.
• Software processes and software process models.
• Distinct between software validation and software verification.
• Principal requirements of engineering activities.
• Concepts of system modeling.
• Decisions about the system architecture during the architectural
design process.
• Use and apply Unified Modeling Language (UML).
CSc 461/561
Topics Covered
• Professional software development
– What is meant by software engineering.
• Software engineering ethics
– A brief introduction to ethical issues that affect software
engineering.
• Case studies
– An introduction to three examples that are used in later
chapters in the book.
CSc 461/561
Professional Software Development
CSc 461/561
Why Software Engineering?
• The economies of ALL developed nations are
dependent on software.
• More and more systems are software controlled.
• Software development is hard.
• Important to distinguish between:
• “Easy” systems (one developer, one user, experimental use
only) and
• “Hard” systems (multiple developers, multiple users,
products)
CSc 461/561
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.
CSc 461/561
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 graphics programs, project
management tools;
• 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.
CSc 461/561
Product specification
• Generic products
– The specification of what the software should do is owned
by the software developer and decisions on software
change are made by the developer.
• Customized products
– The specification of what the software should do is owned
by the customer for the software and they make decisions
on software changes that are required.
CSc 461/561
FAQs about software engineering
• What is software?
• What is software engineering?
• What is the difference between software engineering
and computer science?
• What is the difference between software engineering
and system engineering?
• What is a software process?
• What is a software process model?
CSc 461/561
FAQs about software engineering
• What are the costs of software engineering?
• What are software engineering methods?
• What is CASE (Computer-Aided Software
Engineering)
• What are the attributes of good software?
• What are the key challenges facing software
engineering?
CSc 461/561
What is software?
• Computer programs and associated documentation such as
requirements, design models and user manuals.
• Software products may be developed for a particular customer
or may be for a general market.
• Software products may be
– Generic - developed to be sold to a range of different
customers (e.g. PC software such as Excel or Word).
– Bespoke (custom) - developed for a single customer
according to their specification.
• New software can be created by developing new programs,
configuring generic software systems or reusing existing
software.
CSc 461/561
What is software engineering?
• Software engineering is an engineering discipline that
is concerned with all aspects of software production.
• Software engineers should adopt a systematic and
organised approach to their work and use appropriate
tools and techniques depending on the problem to be
solved, the development constraints and the resources
available.
CSc 461/561
What is the difference between software
engineering and computer science?
• Computer science is concerned with theory and
fundamentals;
• Software engineering is concerned with the
practicalities of developing and delivering useful
software.
CSc 461/561
What is the difference between software
engineering and system engineering?
• System engineering is concerned with all aspects of
computer-based systems development including
(hardware, software and process engineering).
• Software engineering is part of this process concerned
with (developing the software infrastructure, control
applications and databases) in the system.
CSc 461/561
What is a software process?
• A set of activities whose goal is the development or
evolution of software.
• Generic activities in all software processes are:
– Specification - what the system should do and its
constraints
– Development - production of the software system
– Validation - checking that the software is what the
customer wants
– Evolution - changing the software in response to
changing demands.
CSc 461/561
What is a software process model?
• A simplified representation of a software process,
presented from a specific perspective.
• Examples of process perspectives are
– Workflow perspective - sequence of activities;
– Data-flow perspective - information flow;
– Role/action perspective - who does what.
• Generic process models
– Waterfall;
– Iterative development;
– Component-based software engineering.
CSc 461/561
What are the costs of software engineering?
• Roughly 60% of costs are development costs, 40% are
testing costs. For custom software, evolution costs
often exceed development costs.
• Costs vary depending on the type of system being
developed and the requirements of system attributes
such as performance and system reliability.
• Distribution of costs depends on the development
model that is used.
CSc 461/561
What are software engineering methods?
• Structured approaches to software development which include
system models, notations, rules, design advice and process
guidance.
• Model descriptions
– Descriptions of graphical models which should be produced;
• Rules
– Constraints applied to system models;
• Recommendations
– Advice on good design practice;
• Process guidance
– What activities to follow.
CSc 461/561
What is CASE (Computer-Aided Software
Engineering)
• Software systems that are intended to provide
automated support for software process activities.
• Upper-CASE
– Tools to support the early process activities of
requirements and design;
• Lower-CASE
– Tools to support later activities such as
programming, debugging and testing.
CSc 461/561
What are the attributes of good software?
The software should deliver the required functionality and
performance to the user and should be maintainable, dependable
and acceptable.
• Maintainability
– Software must evolve to meet changing needs;
• Dependability
– Software must be trustworthy;
• Efficiency
– Software should not make wasteful use of system resources;
• Acceptability
– Software must be acceptable to the type of users for which it is designed.
CSc 461/561
What are the key challenges facing
software engineering?
• Heterogeneity
– Developing techniques for building software that can cope
with heterogeneous platforms and execution environments;
• Delivery
– Developing techniques that lead to faster delivery of
software;
• Trust
– Developing techniques that demonstrate that software can be
trusted by its users.
CSc 461/561
Software Engineering Diversity
• There are many different types of software system
and there is no universal set of software techniques
that is applicable to all of these.
• The software engineering methods and tools used
depend on the type of application being developed,
the requirements of the customer and the background
of the development team.
CSc 461/561
Application Types
• Stand-alone applications
– These are application systems that run on a local computer, such as a
PC. They include all necessary functionality and do not need to be
connected to a network.
• Interactive transaction-based applications
– Applications that execute on a remote computer and are accessed by
users from their own PCs or terminals. These include web
applications such as E-commerce applications.
• Embedded control systems
– These are software control systems that control and manage hardware
devices.
CSc 461/561
Application Types
• Batch processing systems
– These are business systems that are designed to process data
in large batches. They process large numbers of individual
inputs to create corresponding outputs.
• Entertainment systems
– These are systems that are primarily for personal use and
which are intended to entertain the user.
• Systems for modelling and simulation
– These are systems that are developed by scientists and
engineers to model physical processes or situations, which
include many, separate, interacting objects.
CSc 461/561
Application Types
• Data collection systems
– These are systems that collect data from their
environment using a set of sensors and send that
data to other systems for processing.
• Systems of systems
– These are systems that are composed of a number
of other software systems.
CSc 461/561
Software engineering fundamentals
• Some fundamental principles apply to all types of software
system, irrespective of the development techniques used:
– Systems should be developed using a managed and understood
development process.
– Dependability and performance are important for all types of
system.
– Understanding and managing the software specification and
requirements (what the software should do) are important.
– Where appropriate, you should reuse software that has already
been developed rather than write new software.
CSc 461/561
Software Engineering Ethics
CSc 461/561
Professional and ethical responsibility
• Software engineering involves wider responsibilities
than simply the application of technical skills.
• Software engineers must behave in an honest and
ethically responsible way if they are to be respected as
professionals.
• Ethical behaviour is more than simply upholding the law
but involves following a set of principles that are
morally correct.
CSc 461/561
Professional and ethical responsibility
• Confidentiality
– Engineers should normally respect the
confidentiality of their employers or clients
irrespective of whether or not a formal
confidentiality agreement has been signed.
• Competence
– Engineers should not misrepresent their level of
competence. They should not knowingly accept
work which is out with their competence.
CSc 461/561
Professional and ethical responsibility
• Intellectual property rights
– Engineers should be aware of local laws governing the use
of intellectual property such as patents, copyright, etc. They
should be careful to ensure that the intellectual property of
employers and clients is protected.
• Computer misuse
– Software engineers should not use their technical skills to
misuse other people’s computers. Computer misuse ranges
from relatively trivial (game playing on an employer’s
machine) to extremely serious (dissemination of viruses).
CSc 461/561
ACM/IEEE Code of Ethics
• The professional societies in the US have cooperated to
produce a code of ethical practice.
• Members of these organisations sign up to the code of practice
when they join.
• The Code contains eight Principles related to the behaviour of
and decisions made by professional software engineers,
including practitioners, educators, managers, supervisors and
policy makers, as well as trainees and students of the
profession.
CSc 461/561
Ethical principles
1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of
their profession and shall promote an ethical approach to the practice of the profession.
CSc 461/561
Case Studies
CSc 461/561
Case studies
1. A personal insulin pump
– An embedded system in an insulin pump used by
diabetics to maintain blood glucose control.
2. A mental health case patient management system
– A system used to maintain records of people
receiving care for mental health problems.
3. A wilderness weather station
– A data collection system that collects data about
weather conditions in remote areas.
CSc 461/561
1-A personal insulin pump
• A personal insulin pump is an external device that mimics
the function of the pancreas.
• It uses an embedded sensor to measure the blood sugar
level at periodic intervals and then injects insulin to
maintain the blood sugar at a ‘normal’ level.
• I will draw on this example at various points in the course
to illustrate aspects of critical systems engineering
CSc 461/561
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.
CSc 461/561
Insulin pump hardware architecture
CSc 461/561
Activity model of the insulin pump
CSc 461/561
Concept of operation
• Using readings from an embedded sensor, the system
automatically measures the level of glucose in the
sufferer’s body.
• Consecutive readings are compared and, if they indicate
that the level of glucose is rising (see next slide) then
insulin is injected to counteract this rise.
• The ideal situation is a consistent level of sugar that is
within some ‘safe’ band.
CSc 461/561
Sugar Levels
• Unsafe
– A very low level of sugar (arbitrarily, we will call this 3 units) is
dangerous and can result in “hypoglaecemia” which can result in
a diabetic coma and ultimately death.
• Safe
– Between 3 units and about 7 units, the levels of sugar are ‘safe’
and are comparable to those in people without diabetes. This is
the ideal band.
• Undesirable
– Above 7 units of insulin is undesirable but high levels are not
dangerous in the short-term. Continuous high-levels however can
result in long-term side-effects.
CSc 461/561
System Specification
• Functional specification
– How to carry out the computation to determine if
insulin should be administered
• Dependability specification
– Requirements to ensure safe operation of the pump
CSc 461/561
Functional Specification
• If the reading is below the safe minimum, no insulin shall
be delivered.
• If the reading is within the safe zone, then insulin is only
delivered if the level of sugar is rising and the rate of
increase of sugar level is increasing.
• If the reading is above the recommended level, insulin is
delivered unless the level of blood sugar is falling and the
rate of decrease of the blood sugar level is increasing.
CSc 461/561
Dependability Specification
• Availability
– The pump should have a high level of availability but the nature
of diabetes is such that continuous availability is unnecessary
• Reliability
– Intermittent demands for service are made on the system
• Safety
– The key safety requirements are that the operation of the system
should never result in a very low level of blood sugar. A fail-safe
position is for no insulin to be delivered
• Security
– Not really applicable in this case
CSc 461/561
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.
CSc 461/561
2- 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.
CSc 461/561
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.
CSc 461/561
The organization of the MHC-PMS
CSc 461/561
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.
CSc 461/561
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.
CSc 461/561
Concern decomposition
• Concerns are decomposed into sub-concerns:
Information integrity
Information quality
Information accuracy
Information timeliness
CSc 461/561
The safety concern
Accidental self-harm
Patient safety
Deliberate self-harm
Staff safety
Incorrect treatment
Public safety
Adverse reaction to medication
Safety
Mental Health Act
CSc 461/561
MHCPMS requirements
• The system shall provide fields in each patient record
that allow details of incidents or threats of deliberate
self-harm to be maintained
• The records of patients with a record of deliberate
self-harm shall be highlighted to bring them to the
attention of clinical system users
• The system shall only permit the transmission of
personal patient information to accredited staff and to
the patient themselves
CSc 461/561
3- 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.
CSc 461/561
The weather station’s environment
CSc 461/561
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.
CSc 461/561
Essential system functionality
• Collect weather information from instruments at regular
intervals
• Transmit this information, on request, to the weather
information system over the satellite link
• Store information if communications are not available
• Monitor external conditions and shut down power
generation/instruments if threat of damage from extreme
weather
• Run regular diagnostic tests to assess overall health of system
CSc 461/561
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.
CSc 461/561
The End
CSc 461/561