1

Chapter 1: Introduction to
Software Engineering
Chapter 1 in Software Engineering Book
 2

Overview

 Learning Objectives.

What is software engineering?

 Why is software engineering important?

 3

By the end of this chapter, you will...

Understand what software engineering is.

 Understand why software engineering is important.
Know answers to key questions related to the software
engineering discipline.
 4

Activity
Virtually all countries
depend on complex
Think about all the devices and systems computer-based
.systems
that you encounter in your everyday
life which have software controlling
…them

List as many as you can

 5

Why is Software Engineering important?

Complex systems need a disciplined approach for designing,

developing and managing them.
 6

Software Development Crises

Projects were:
• Late.
• Over budget.
• Unreliable.
• Difficult to maintain.
• Performed poorly.
 7

Software errors….the cost

Errors in computer software can have

devastating effects.
 8

Software Crisis
Example 1: 2009,Computer glitch delays flights

Saturday 3rd October 2009-London, England (CNN)

•Dozens of flights from the UK were delayed Saturday after

a glitch in an air traffic control system in Scotland, but the
problem was fixed a few hours later.
•The agency said it reverted to backup equipment as
engineering worked on the system.
•The problem did not create a safety issue but could cause
delays in flights.
•Read more at:
http://edition.cnn.com/2009/WORLD/europe/10/03/uk.flig
hts.delayed
 9

Software Crisis
Example 2: Ariane 5 Explosion

•European Space Agency spent 10 years and $7 billion

to produce Ariane 5.

•Crash after 36.7 seconds.

•Caused by an overflow error. Trying to store a 64-bit

number into a 16-bit space.

•Watch the video:

http://www.youtube.com/watch?v=z-r9cYp3tTE
 10

Software Crisis
Example 3: 1992, London Ambulance Service

•Considered the largest ambulance service in the

world.

•Overloaded problem.

•It was unable to keep track of the ambulances and

their statuses. Sending multiple units to some
locations and no units to other locations.

•Generates many exceptions messages.

•46 deaths.
 11

Therefore…
A well-disciplined approach to software
development and management is
necessary. This is called engineering.
 12

Software Engineering

 The term software engineering first appeared in the 1968 NATO

Software Engineering Conference and was meant to provoke
thought regarding what was then called the “software crisis”..

 “.. An engineering discipline that is concerned with all aspects of

software production from the early stages of system specification
to maintaining the system after it has gone into use.” Sommerville,
pg.7
 13

What is Software?

System
Documentation

User
Documentation
 14

Types of Software

• 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;
CAD software; software for specific markets such as appointments systems for
dentists.
• 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 or bespoke 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.
• 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.
 15

Software Engineering vs. Computer Science

“Computer science is no more about computers than

astronomy is about telescopes.” Edsger Dijkstra
 16

Software Engineering vs. Systems Engineering

Systems Engineering:
Interdisciplinary engineering field (computer, software, and process eng.).
Focuses on how complex engineering projects should be designed and managed.
Frequently asked questions about software
engineering
Question Answer

What is software? Computer programs 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 are the fundamental software Software specification, software development, software
engineering activities? validation and software evolution.
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.
17
Frequently asked questions about software
engineering
Question Answer
What are the key challenges facing software Coping with increasing diversity, demands for reduced delivery
engineering? times and developing trustworthy software.
What are the costs of software engineering? Roughly 60% of software costs are development costs, 40% are
testing costs. For custom software, evolution costs often
exceed development costs.
What are the best software engineering While all software projects have to be professionally managed
techniques and methods? and developed, different techniques are appropriate for
different types of system. For example, games should always
be developed using a series of prototypes whereas safety
critical control systems require a complete and analyzable
specification to be developed. You can’t, therefore, say that
one method is better than another.
What differences has the web made to The web has led to the availability of software services and the
software engineering? possibility of developing highly distributed service-based
systems. Web-based systems development has led to
important advances in programming languages and software
reuse.
18
 19

What is a Software Process?

 Activities and results that produce a software product:

SW Process Activity What is going on there?

What does the customer need?

Specification
What are the constraints?

Development Design & programming.

Validation Checking whether it meets requirements.

Evolution Modifications (e.g. customer/market).

 20

What is a Software Process Model?

 Description of the software process that represents one view, such

as the activities, data or roles of people involved.

Examples of views Focus on…

Activities = human actions.

Workflow
What is input, output, and dependencies.

Activities = transformations of information.

Dataflow
How the input is transformed into output.
What is the role of people involved in each step of
Role/Action
the process?
 21

Some Software Process Models

Component-Based
Waterfall approach Iterative development
Software Engineering CBSE

assembled form existing

components
 22

The Cost of Software Engineering

 Depends on:
 The process used, and
 The type of software being developed.

 Each generic approach has a different profile of cost distribution.

 Roughly 60% of costs are development costs, 40% are testing

costs.

 For custom software, evolution costs often exceed development

costs.
 23

Cost distribution
Custom software development (Bespoke)
Software Model Waterfall Model
Cost units 0 25 50 75 100
Cost distribution
Software development activity Specification Design Development Integration and testing

Iterative Development
0 25 50 75 100

Specification Iterative Development System testing

Component-based Software Engineering

0 25 50 75 100

Specification Development Integration and testing

Development and evolution costs for long-lifetime systems

0 100 200 300 400

System development System evolution

 24

Cost distribution
Generic software development

0 25 50 75 100

Specification Development System testing

Product development costs

 25

Attributes of good software

 Functional attributes (performance; what the system does).

 Non-functional attributes (quality; how the system does it).

Product Characteristic Description

Maintainability Evolution qualities such as Testability, extensibility.
Dependability Reliability, security, safety.
Efficiency Response time, processing time, memory utilization.
Usability Easy to learn how to use the system by target users.
Efficient to use the system by users to accomplish a task.
Satisfying to use by intended users.
 26

Activity
 What are the key attributes for..
Cardiac monitor in an ICU
Interactive game Banking system
unit
Players, score, scenes, Client accounts, stocks heart rate, temperature,
theme. bonds, money transfers. blood pressure.
 Software Lifecycle Definition
• Software lifecycle:
– Set of activities and their relationships to each other
to support the development of a software system

• Typical Lifecycle questions:

– Which activities should I select for the software
project?
– What are the dependencies between activities?
– How should I schedule the activities?
 Engineering Process Model
• Specification: Set out the requirements and
constraints on the system.
• Design: Produce a model of the system.
• Manufacture: Build the system.
• Test: Check the system meets the required
specifications.
• Install: Deliver the system to the customer and
ensure it is operational.
• Maintain: Repair faults in the system as they
are discovered.
 Generic Software Process Models
• Waterfall
– Separate and distinct phases of specification and
development
• Evolutionary
– Specification and development are interleaved
• Formal Transformation
– A mathematical system model is formally transformed to
an implementation
• Reuse-based
– The system is assembled from existing components
 1. The Waterfall Model

• The waterfall model is the classic lifecycle

model – it is widely known, understood
and (commonly?) used.
• In some respect, waterfall is the ”common
sense” approach.
• Introduced by Royce 1970.
 phase
User Requirements output User Requirements Document

Software Requirements Software Requirements

Document

Architecture Design Architectural Design

Document

”Swimming Detailed design & Coding Detailed

upstream” Design
& Code
The Waterfall Testing
Lifecycle Workflow
Delivery
Time
 Waterfall Model Documents

Activity Output documents

Requirements analysis Feasibility study, Outline requirements
Requirements definition Requirements document
System specification Functional specification, Acceptance test plan
Draft user manual
Architectural design Architectural specification, System test plan
Interface design Interface specification, Integration test plan
Detailed design Design specification, Unit test plan
Coding Program code
Unit testing Unit test report
Module testing Module test report
Integration testing Integration test report, Final user manual
System testing System test report
Acceptance testing Final system plus documentation
 Software Lifecycle Activities
Deliverable 0
Deliverable 1 Deliverable 2 Deliverable 3 Deliverable 4 Deliverable 5 Deliverable 6

Requirements Requirements System Object Implemen-

Testing
Elicitation Analysis Design Design tation

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class....?
Use Case Application Solution
Domain SubSystems Source Test
Model Domain
Objects Code Cases
Objects

Each activity produces one or more models

 Advantages
1. Easy to understand and implement.
2. Widely used and known (in theory!)
3. Reinforces good habits: define-before- design,
design-before-code
4. Identifies deliverables and milestones
5. Document driven, URD, SRD, … etc. Published
documentation standards, e.g. PSS-05.
6. Works well on mature products and weak
teams.
 Disadvantages I
1. Idealised, doesn’t match reality well.
2. Doesn’t reflect iterative nature of
exploratory development.
3. Unrealistic to expect accurate requirements
so early in project
4. Software is delivered late in project, delays
discovery of serious errors.
 Disadvantages II
5. Difficult to integrate risk management
6. Difficult and expensive to make changes
to documents, ”swimming upstream”.
7. Significant administrative overhead,
costly for small teams and projects.
 Evolutionary Process Model
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
 Process Model Problems
• Waterfall
– High risk for new systems because of specification and
design problems.
– Low risk for well-understood developments using familiar
technology.
• Prototyping
– Low risk for new applications because specification and
program stay in step.
– High risk because of lack of process visibility.
• Transformational
– High risk because of need for advanced technology and
staff skills.
 Hybrid Process Models
• Large systems are usually made up of several
sub-systems.
• The same process model need not be used for

all subsystems.
• Prototyping for high-risk specifications.
• Waterfall model for well-understood
developments.
 2. Code-and-Fix
This model starts with an informal general
product idea and just develops code until a
product is ”ready” (or money or time runs
out). Work is in random order.

Corresponds with no plan! (Hacking!)

 Advantages
1. No administrative overhead
2. Signs of progress (code) early.
3. Low expertise, anyone can use it!
4. Useful for small “proof of concept” projects,
e.g. as part of risk reduction.
 Disadvantages
1. Dangerous!
1. No visibility/control
2. No resource planning
3. No deadlines
4. Mistakes hard to detect/correct
2. Impossible for large projects,
communication breakdown, chaos.
 3. Spiral Model
Since end-user requirements are hard to
obtain/define, it is natural to develop software
in an experimental way: e.g.
1. Build some software
2. See if it meets customer requirements
3. If no goto 1 else stop.
This loop approach gives rise to structured
iterative lifecycle models.

In 1988 Boehm developed the spiral model as

an iterative model which includes risk
analysis and risk management.

Key idea: on each iteration identify and solve

the sub-problems with the highest risk.
 Spiral Process Model
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analy sis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
Each cycle follows a waterfall model by:
1. Determining objectives
2. Specifying constraints
3. Generating alternatives
4. Identifying risks
5. Resolving risks
6. Developing next-level product
7. Planning next cycle
 Advantages
1. Realism: the model accurately reflects the
iterative nature of software development on
projects with unclear requirements
2. Flexible: incoporates the advantages of the
waterfal and rapid prototyping methods
3. Comprehensive model decreases risk
4. Good project visibility.
 Disadvantages
• Needs technical expertise in risk analysis to
really work
• Model is poorly understood by non-technical
management, hence not so widely used
• Complicated model, needs competent
professional management. High
administrative overhead.
 4. Rapid Prototyping

Key idea: Customers are non-technical and

usually don’t know what they want/can have.

Rapid prototyping emphasises requirements

analysis and validation, also called:
• customer oriented development,
• evolutionary prototyping
Requirements Capture

Iterate
Quick Design

Build Prototype

Customer Evaluation of
Prototype

The Rapid Engineer Final

Product
Prototype Workflow
 Advantages

1. Reduces risk of incorrect user

requirements
2. Good where requirements are
changing/uncommitted
3. Regular visible progress aids management
4. Supports early product marketing
 Disadvantages I

1. An unstable/badly implemented prototype

often becomes the final product.
2. Requires extensive customer collaboration
– Costs customers money
– Needs committed customers
– Difficult to finish if customer withdraws
– May be too customer specific, no broad market
 Disadvantages II
3. Difficult to know how long project will last
4. Easy to fall back into code-and-fix without
proper requirements analysis, design,
customer evaluation and feedback.
 5. Agile (XP) Manifesto

XP = Extreme Programming emphasises:

• Individuals and interactions
– Over processes and tools
• Working software
– Over documentation
• Customer collaboration
– Over contract negotiation
• Responding to change
– Over following a plan
 Agile Principles (Summary)
• Continuous delivery of software
• Continuous collaboration with customer
• Continuous update according to changes
• Value participants and their interaction
• Simplicity in code, satisfy the spec
 6. XP Practices (Summary)
• Programming in pairs
• Test driven development
• Continuous planning, change , delivery
• Shared project metaphors, coding standards
and ownership of code
• No overtime! (Yeah right!)
 Advantages
• Lightweight methods suit small-medium size
projects
• Produces good team cohesion
• Emphasises final product
• Iterative
• Test based approach to requirements and
quality assurance
 Disadvantages
• Difficult to scale up to large projects where
documentation is essential
• Needs experience and skill if not to
degenerate into code-and-fix
• Programming pairs is costly
• Test case construction is a difficult and
specialised skill.
 7. Unified Process (UP)
• Booch, Jacobson, Rumbaugh 1999.
• Lifetime of a software product in cycles:
• Birth, childhood, adulthood, old-age, death.
• Product maturity stages
• Each cycle has phases, culiminating in a new
release (c.f. Spiral model)
 Inception Elaboration

Transition Construction

UP Lifecycle – single phase workflow

(drawn as a UML Statechart!)
• Inception – identify core use cases, and use
to make architecture and design tradeoffs.
Estimate and schedule project from derived
knowledge.
• Elaboration – capture detailed user
requirements. Make detailed design,
decide on build vs. buy.
• Construction – components are bought or
built, and integrated.
• Transition – release a mature version that
satisfies acceptance criteria.
 Unified Process
Product
Management Software Lifecycle

Environment * * releases
Workflow Cycle

Requirements
Inception
4
Design
Phase Elaboration

Implementation
Construction
*
Assessment Iteration
Transition

Deployment *
Artifact
 UML class diagram!
Use Case Model

specified by
realised by
Analysis Model
deployed by implemented by

Design Model verified by

Deployment Model

Implementation Model

All models are interdepedent

Test Model
but this only shown for use
case model
 8. COTS
• COTS =
Commercial Off-The-Shelf software
• Engineer together a solution from existing
commercial software packages using minimal
software ”glue”.
• E.g. using databases, spread sheets, word
proccessors, graphics software, web browsers,
etc.
Advantages
• Fast, cheap solution
• May give all the basic functionality
• Well defined project, easy to run
Disadvantages
• Limited functionality
• Licensing problems, freeware, shareware,
etc.
• License fees, maintainance fees, upgrade
compatibility problems
 Summary
• Process Visibility
– Software systems are intangible so managers
need documents to assess progress.
– Waterfall model is still the most widely used
model.
 Process Model Visibility
Process model Process visibility
Waterfall model Good visibility, each activity produces some
deliverable
Evolutionary Poor visibility, uneconomic to produce
development documents during rapid iteration
Formal Good visibility, documents must be produced
transformations from each phase for the process to continue
Reuse-oriented Moderate visibility, it may be artificial to
development produce documents describing reuse and
reusable components.
Spiral model Good visibility, each segment and each ring
of the spiral should produce some document.