Software Engineering

(MCA-403)
Prepared By:
Mr. Sujit Kumar Singh
skrsingh1@gmail.com
A.P in M.C.A department

MCA

1/338

Unit -1
Software Engineering Paradigms: Software Characteristics, Software myths,
Software Applications,
Software Engineering Definitions, Software Process Models, Process iteration,
Process activities,
Computer-aided software engineering (CASE) and CASE Tools.
Software Project Management: Management activities, Project planning,
Project scheduling, Risk management and activities.

MCA

2/338

Objectives
To introduce software engineering and to
explain its importance
To set out the answers to key questions about
software engineering
To introduce ethical and professional issues
and to explain why they are of concern to
software engineers

Software Engineering
The economies of ALL developed nations are
dependent on software.
More and more systems are software controlled
Software engineering is concerned with
theories, methods and tools for professional
software development.
Expenditure on software represents a
significant fraction of GNP in all developed
countries.

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.

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.
Computer science theories are still insufficient
to act as a complete underpinning for software
engineering (unlike e.g. physics and electrical
engineering).

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.
System engineers are involved in system
specification, architectural design, integration
and deployment.

Engineering
Engineering is
The application of scientific principles and methods to the
construction of useful structures & machines

Examples

Mechanical engineering
Computer engineering
Civil engineering
Chemical engineering
Electrical engineering
Nuclear engineering
Aeronautical engineering

Software Engineering
The reality is it is finally beginning to arrive
Computer science one the scientific basis
Years of studies/experience/statistics provide basis too
Many aspects have been made systematic
Methods/methodologies/techniques
Languages
Tools
Processes

Why Engineer
Software ?
The problem is complexity
Many sources, but size is a key:
Mozilla contains 3 Million lines of code
UNIX contains 4 million lines of code
Windows 2000 contains 108 lines of code
Second is role and combinatories of state
Third is uncertainty of inputs and their timing
Fourth is the continuing changing environment and demands.
Software engineering is about managing all the sources of complexity to
produce effective software.

Software Engineering
in a Nutshell

Development of software systems whose size/complexity warrants

team(s) of engineers
multi-person construction of multi-version software [Parnas 1987]

Scope
study of software process, development/management principles,
techniques, tools and notations

Goal
production of quality software, delivered on time, within budget,
satisfying customers requirements and users needs

What does a software

engineer do?
Software engineers should
adopt a systematic and organised approach to all aspects of
software development.
use appropriate tools and techniques depending on
the problem to be solved,
the development constraints and
the resources available
Understand and communicate processes for improved software
development within their organization
Be effective team members and/or leaders.
Can be very technical or more managerial depending on
organizational need.

What is the difference between

software engineering and system
engineering?

Software engineering is part of System engineering

System engineering is concerned with all aspects of computer-based
systems development including
hardware,
software and
process engineering
System engineers are involved in
system specification,
architectural design,
integration and deployment

Difficulties?

SE is a unique brand of engineering

Software is malleable
Software construction is human-intensive
Software is intangible and generally invisible
Software problems are unprecedentedly complex
Software directly depends upon the hardware
It is at the top of the system engineering food chain
Software solutions require unusual rigor
Software state means behaviors can depend on history.
Software has discontinuous operational nature

Software Engineering
Software Programming
Software engineering

Teams of developers with multiple roles

Complex systems
Indefinite lifespan
Numerous stakeholders
Architect Developer Manager Tester Customer User

System families
Reuse to amortize costs
Maintenance accounts for 60%-80% of overall
development costs

Software
Engineering
Objectives
Objectives
To introduce software process models
To describe three generic process models and
when they may be used
To describe outline process models for
requirements engineering, software
development, testing and evolution
To explain the Rational Unified Process model
To introduce CASE technology to support
software process activities

The
software
process
Software
Process
A structured set of activities required to develop a
software system

Specification;
Design;
Validation;
Evolution.

A software process model is an abstract representation of a

process. It presents a description of a process from some
particular perspective.

Topics covered
Software
Process

Software process models

Process iteration
Process activities
The Rational Unified Process
Computer-aided software engineering

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

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.

Generic Software process

Generic software process models
Models
The waterfall model
Separate and distinct phases of specification and development.

Evolutionary development
Specification, development and validation are interleaved.

Component-based software engineering

The system is assembled from existing components.

There are many variants of these models e.g. formal

development where a waterfall-like process is used but the
specification is a formal specification that is refined through
several stages to an implementable design.

WaterfallModels
model
Waterfall
Requirements
defi nition
System and
software design
Implementa
tion
and unit testing
Integration and
system testing
Operation and
maintenance

Phases of
Waterfall
Waterfall
model
phases
Models

Requirements analysis and definition

System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
The main drawback of the waterfall model is the difficulty of
accommodating change after the process is underway. One
phase has to be complete before moving onto the next phase.

Waterfall model
problems
Inflexible partitioning of the project into distinct stages makes
it difficult to respond to changing customer requirements.
Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly
limited during the design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large systems
engineering projects where a system is developed at several
sites.

Evolutionary
Evolutionary
Model
development
Exploratory development
Objective is to work with customers and to evolve a final
system from an initial outline specification. Should start
with well-understood requirements and add new features as
proposed by the customer.
Throw-away prototyping
Objective is to understand the system requirements. Should
start with poorly understood requirements to clarify what is
really needed.

Evolutionary
Evolutionary
development
Development
Concurrent
activities

Specifi ca
tion

Outline
description

Development

Validation

Initial
version

Intermediate
versions

Final
version

Evolutionary
Evolutionary development
Development
Problems
Lack of process visibility;
Systems are often poorly structured;
Special skills (e.g. in languages for rapid
prototyping) may be required.
Applicability
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.

Component-based
software engineering
Based on systematic reuse where systems are integrated from
existing components or COTS (Commercial-off-the-shelf)
systems.
Process stages
Component analysis;
Requirements modification;
System design with reuse;
Development and integration.
This approach is becoming increasingly used as component
standards have emerged.

Reuse-oriented
development

Requirements
specifi cation

Component
analysis

Requirements
modifi cation

System design
with reuse

Development
and integ
ration

System
validation

Process iteration
System requirements ALWAYS evolve in the course of a
project so process iteration where earlier stages are reworked
is always part of the process for large systems.
Iteration can be applied to any of the generic process models.
Two (related) approaches
Incremental delivery;
Spiral development.

Incremental delivery
Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments
with each increment delivering part of the required
functionality.
User requirements are prioritised and the highest priority
requirements are included in early increments.
Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.

Incremental development

Defi ne outline
requirements

Develop system
increment

Assign requirements
to increments

Validate
increment

Design system
architectur
e

Integrate
increment

Validate
system
Final
system

System incomplete

Incremental development
advantages
Customer value can be delivered with each increment so
system functionality is available earlier.
Early increments act as a prototype to help elicit
requirements for later increments.
Lower risk of overall project failure.
The highest priority system services tend to receive the most
testing.

Spiral development
Process is represented as a spiral rather than as a sequence of
activities with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the
spiral are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the
process.

Spiral development of
Spiral
model
of
the
software
process
Software Process
Determine objectives,
alternatives and
constraints

Evaluate alternatives,
identify, resolve risks

Risk
analysis
Risk
analysis
Risk
analysis

REVIEW
Requirements plan
Life-cycle plan

Plan ne xt phase

Operational
protoype

Pr ototype 3

Pr ototype 2
Risk
analysis Pr ototype 1

Simulations, models, benchmarks

Concept of
Operation

S/W
requirements

Development
plan

Requirement
validation

Integration
and test plan

Design
V&V
Acceptance
test
Service

Product
design

Detailed
design
Code

Unit test
Integration
test
Develop, verify
next-level product

What are the costs of

Evolutionary development
software engineering?
Problems
Lack of process visibility;
Systems are often poorly structured;
Special skills (e.g. in languages for rapid prototyping) may
be required.
Applicability
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.

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.

What
Whatare
arethe
theattributes
attributesofof
good
software?
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 accepted by the users for which it was designed. This
means it must be understandable, usable and compatible with other
systems.

What are software

What are software engineering

engineering
methods?
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.

Process activities

Software specification
Software design and implementation
Software validation
Software evolution

Software specification
The process of establishing what services are required and the
constraints on the systems operation and development.
Requirements engineering process
Feasibility study;
Requirements elicitation and analysis;
Requirements specification;
Requirements validation.

The requirements
engineering process
Feasibility
study

Requirements
elicitation and
analy sis
Requirements
specifi cation
Requirements
validation

Feasibility
report
System
models
User and system
requirements

Requirements
document

Software design and

implementation
The process of converting the system specification into an
executable system.
Software design
Design a software structure that realises the specification;
Implementation
Translate this structure into an executable program;
The activities of design and implementation are closely related
and may be inter-leaved.

Design process activities

Architectural design
Abstract specification
Interface design
Component design
Data structure design
Algorithm design

The software design

process
Requir
ements
specifi ca
tion
Design acti
vities
Architectur
al
design

Abstract
specifi ca
tion

Interface
design

Component
design

Data
structur
e
design

Algorithm
design

System
architectur
e

Software
specifi ca
tion

Interface
specifi ca
tion

Component
specifi ca
tion

Data
structur
e
specifi ca
tion

Algorithm
specifi ca
tion

Design pr
oducts

Structured methods
Systematic approaches to developing a software design.
The design is usually documented as a set of graphical models.
Possible models
Object model;
Sequence model;
State transition model;
Structural model;
Data-flow model.

Programming and
debugging
Translating a design into a program and removing errors from
that program.
Programming is a personal activity - there is no generic
programming process.
Programmers carry out some program testing to discover
faults in the program and remove these faults in the debugging
process.

The debugging process

Locate
error

Design
error repair

Repair
error

Re-test
program

Software validation
Verification and validation (V & V) is intended to show that a
system conforms to its specification and meets the
requirements of the system customer.
Involves checking and review processes and system testing.
System testing involves executing the system with test cases
that are derived from the specification of the real data to be
processed by the system.

The testing process

Component
testing

System
testing

Ac c eptanc e
testing

Testing stages
Component or unit testing
Individual components are tested independently;
Components may be functions or objects or coherent
groupings of these entities.
System testing
Testing of the system as a whole. Testing of emergent
properties is particularly important.
Acceptance testing
Testing with customer data to check that the system
meets the customers needs.

Testing phases

Requirements
specifi ca
tion

System
specifi ca
tion

System
integration
test plan

Acceptance
test plan

Service

System
design

Acceptance
test

Detailed
design

Sub-system
integration
test plan

System
integration test

Sub-system
integration test

Module and
unit code
and test

Software evolution
Software is inherently flexible and can change.
As requirements change through changing business
circumstances, the software that supports the business must
also evolve and change.
Although there has been a demarcation between development
and evolution (maintenance) this is increasingly irrelevant as
fewer and fewer systems are completely new.

Software Qualities
Qualities are goals in the practice of software engineering, and
directly relate to many of the guiding principles.
External vs. Internal qualities
Product vs. Process qualities

Software Qualities
Critical Quality Attributes

Correctness
Maintainability
Dependability
Usability
Reliability

Other Attributes

Completeness
Compatibility
Portability
Internationalization
Understandability
Scalability
Robustness
Testability
Reusability
Customizability
Efficiency

External vs. Internal

Qualities

External qualities are visible to the user

reliability, usability, efficiency (maybe), robustness, scalability

Internal qualities are the concern of developers

they help developers achieve external qualities
verifiability, maintainability, extensibility, evolvability, adaptability,
portability, testability, reusability

Product vs. Process

Qualities

Product qualities concern the developed artifacts

maintainability, performance, understandability,

Process qualities deal with the development activity

products are developed through process
maintainability, productivity, predictability

Some Software Qualities

Correctness
ideal quality
established w.r.t. the requirements/specification
absolute

Reliability
statistical property
probability that software will operate as expected over a given
period of time/inputs
relative

Some Software Qualities

(cont.)

Robustness
reasonable behavior in unforeseen circumstances
subjective
a specified requirement is an issue of correctness;
an unspecified requirement is an issue of robustness

Usability
ability of end-users to easily use software
extremely subjective

Some Software Qualities

(cont.)

Understandability
ability of developers to easily understand produced artifacts
internal product quality
subjective

Verifiability
ease of establishing desired properties
performed by formal analysis or testing
internal quality

Some Software Qualities

(cont.)

Performance
equated with efficiency
assessable by measurement, analysis, and simulation

Evolvability
ability to add or modify functionality
addresses adaptive and perfective maintenance
problem: evolution of implementation is too easy
evolution should start at requirements or design

Some Software Qualities

(cont.)

Reusability
ability to construct new software from existing pieces
must be planned for
occurs at all levels: from people to process, from requirements to
code

Interoperability
ability of software (sub)systems to cooperate with others
easily integratable into larger systems
common techniques include APIs, distributed programming
interfaces (CORBA, DCOM), plug-in protocols, etc.

Some Software Qualities

(cont.)

Scalability
ability of a software system to grow in size while maintaining its
properties and qualities
assumes maintainability and evolvability
goal of component-based development

Software Lifecycle
Models

Waterfall Model
V Model
Phased Development Model
Incremental Model
Prototyping Model
Spiral Model

Software Development Lifecycle

Water Fall Model

RequirementsPlan/Schedule
Design

Replan/Reschedule

Implementation
Integration
Validation
Deployment

V Model
OPERATION
& MAINTENANCE

Validate requirements

REQUIREMENTS
ANALYSIS

ACCEPTANCE
TESTING
SYSTEM
DESIGN
Verify design

PROGRAM
DESIGN

SYSTEM
TESTING

UNIT & INTEGRATION TESTING

CODING

Prototyping Model

Listen to

Build/Revis
e

Customer

Mock-Up
Customer
Test-drives
Mock-up

Prototyping Model
LIST OF
REVISIONS

revise
prototype

LIST OF
REVISIONS

LIST OF
REVISIONS

user/
customer
review

PROTOTYPE
REQUIREMENTS

SYSTEM
REQUIREMENTS
(sometimes informal
or incomplete)

PROTOTYPE
DESIGN

PROTOTYPE
SYSTEM

TEST

DELIVERED
SYSTEM

Spiral development

Process is represented as a spiral rather than as a sequence of activities

with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral are
chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the process.

Spiral development
Spiral model of the software process
Determine objectives,
alternatives and
constraints

Evaluate alternatives,
identify, resolve risks

Risk
analysis
Risk
analysis
Risk
analysis

REVIEW
Requirements plan
Life-cycle plan

Plan ne xt phase

Operational
protoype

Pr ototype 3

Pr ototype 2
Risk
analysis Pr ototype 1

Simulations, models, benchmarks

Concept of
Operation

S/W
requirements

Development
plan

Requirement
validation

Integration
and test plan

Design
V&V

Service

Product
design

Detailed
design
Code

Unit test

Acceptance
test

Integration
test
Develop , verify
next-level product

Spiral model sectors

Objective setting
Specific objectives for the phase are identified.
Risk assessment and reduction
Risks are assessed and activities put in place to reduce the key
risks.
Development and validation
A development model for the system is chosen which can be any
of the generic models.
Planning
The project is reviewed and the next phase of the spiral is planned.

Component-based
software engineering

Based on systematic reuse where systems are integrated from

existing components or COTS (Commercial-off-the-shelf)
systems.
Process stages
Component analysis;
Requirements modification;
System design with reuse;
Development and integration.
This approach is becoming increasingly used as component
standards have emerged.

Reuse-oriented
development

Requirements
specifi cation

Component
analysis

Requirements
modifi cation

System design
with reuse

Development
and integ
ration

System
validation

Component-Based
Development
Develop generally applicable components of a reasonable size
and reuse them across systems
Make sure they are adaptable to varying contexts
Extend the idea beyond code to other development artifacts
Question: what comes first?
Integration, then deployment
Deployment, then integration

Different Flavors of
Components

Third-party software pieces

Plug-ins / add-ins
Applets
Frameworks
Open Systems
Distributed object infrastructures
Compound documents
Legacy systems

Process iteration
System requirements ALWAYS evolve in the course of a
project so process iteration where earlier stages are reworked
is always part of the process for large systems.
Iteration can be applied to any of the generic process models.
Two (related) approaches
Incremental delivery;
Spiral development.

Incremental delivery

Rather than deliver the system as a single delivery, the

development and delivery is broken down into increments
with each increment delivering part of the required
functionality.
User requirements are prioritised and the highest priority
requirements are included in early increments.
Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.

Incremental development

Defi ne outline
requirements

Develop system
increment

Assign requirements
to increments

Validate
increment

Design system
architectur
e

Integrate
increment

Validate
system
Final
system

System incomplete

Incremental development
advantages
Customer value can be delivered with each increment so
system functionality is available earlier.
Early increments act as a prototype to help elicit requirements
for later increments.
Lower risk of overall project failure.
The highest priority system services tend to receive the most
testing.

Extreme programming
An approach to development based on the development and
delivery of very small increments of functionality.
Relies on constant code improvement, user involvement in the
development team and pairwise programming.
Covered in Chapter 17

Software Development Lifecycle

Waterfall Model

RequirementsPlan/Schedule
Design

Replan/Reschedule

Implementation
Integration
Validation
Deployment

The requirements
engineering process
Feasibility
study

Requirements
elicitation and
analy sis
Requirements
specifi cation
Requirements
validation

Feasibility
report
System
models
User and system
requirements

Requirements
document

Software design and

implementation

The process of converting the system specification into an

executable system.
Software design
Design a software structure that realises the
specification;
Implementation
Translate this structure into an executable program;
The activities of design and implementation are closely
related and may be inter-leaved.

Design process activities

Architectural design
Abstract specification
Interface design
Component design
Data structure design
Algorithm design

The software design

process
Requir
ements
specifi ca
tion
Design acti
vities
Architectur
al
design

Abstract
specifi ca
tion

Interface
design

Component
design

Data
structur
e
design

Algorithm
design

System
architectur
e

Software
specifi ca
tion

Interface
specifi ca
tion

Component
specifi ca
tion

Data
structur
e
specifi ca
tion

Algorithm
specifi ca
tion

Design pr
oducts

Structured methods

Systematic approaches to developing a software design.

The design is usually documented as a set of graphical
models.
Possible models
Object model;
Sequence model;
State transition model;
Structural model;
Data-flow model.

Architecture vs. Design

Architecture is concerned with the selection of architectural
elements, their interactions, and the constraints on those
elements and their interactions necessary to provide a
framework in which to satisfy the requirements and serve as a
basis for the design.
Design is concerned with the modularization and detailed
interfaces of the design elements, their algorithms and
procedures, and the data types needed to support the
architecture and to satisfy the requirements.

Architecture/Design
Requirements/Specification Architecture/Design
architecture: decompose software into
modules/objects/components with interfaces
design: develop module/object/component specifications
(algorithms, data types) and communication details
maintain a record of design decisions and traceability
specifies how the software product is to do its tasks

Difficulties
miscommunication between module designers
design may be inconsistent, incomplete, ambiguous
How to achieve a requirement may be unknown

Planning/Scheduling
Before undertaking cost of development, need to estimate the
costs/sizes of various steps
Estimate Code size
Estimate tools needed
Estimate personnel
Often Done after Architecture and before rest of design, but
revised again after full design.
Develop schedule for aspects of project lifecycle
If doing predictive/quantitative SE, build on past experience,
considering how to improve process.

Implementation &
Integration
Design Implementation
implement modules; verify that they meet their
specifications
combine modules according to the design
specifies how the software design is realized

Difficulties
module interaction errors
order of integration may influence quality and
productivity

Programming and
debugging
Translating a design into a program and removing errors from
that program.
Programming is a personal activity - there is no generic
programming process.
Programmers carry out some program testing to discover
faults in the program and remove these faults in the debugging
process.

The debugging process

Locate
error

Design
error repair

Repair
error

Re-test
program

Software validation

Verification and validation (V & V) is intended to show that a

system conforms to its specification and meets the
requirements of the system customer.
Involves checking and review processes and system testing.
System testing involves executing the system with test cases
that are derived from the specification of the real data to be
processed by the system.

Verification and
Validation
Analysis

Static
Science
Formal verification
Informal reviews and walkthroughs

Testing

Dynamic
Engineering
White box vs. black box
Structural vs. behavioral
Issues of test adequacy

The testing process

Component
testing

System
testing

Ac c eptanc e
testing

Testing stages

Component or unit testing

System testing

Individual components are tested independently;

Components may be functions or objects or coherent
groupings of these entities.
Testing of the system as a whole. Testing of
emergent properties is particularly important.

Acceptance testing

Testing with customer data to check that the system

meets the customers needs.

Testing phases

Requirements
specifi ca
tion

System
specifi ca
tion

System
integration
test plan

Acceptance
test plan

Service

System
design

Acceptance
test

Detailed
design

Sub-system
integration
test plan

System
integration test

Sub-system
integration test

Module and
unit code
and test

Quality Assurance

Done as part of each step

Reduce costs by catching errors early.
Help determine ambiguities/inconsistencies
Help ensure quality product.
200

30
1

Requirements Specification

Planning

4
Design

10
ImplementationIntegration

Maintenance

Deployment
Completed End-User Documentation
Separate from Developer documentation
Installation Process(es)
Customer test procedures
Support Processes (help desk, etc)
Trouble Tracking
Repair/rework to address bugs
Regression testing (as bugs are fixed)

Maintenance &
Evolution
Operation Change
maintain software during/after user operation
determine whether the product still functions correctly
Difficulties
Rigid or fragile designs
lack of documentation
personnel turnover

Software evolution
Software is inherently flexible and can change.
As requirements change through changing business
circumstances, the software that supports the business must
also evolve and change.
Although there has been a demarcation between development
and evolution (maintenance) this is increasingly irrelevant as
fewer and fewer systems are completely new.

System evolution

Defi ne system
requirements

Assess existing
systems

Existing
systems

Propose system
changes

Modify
systems

New
system

Why I include CASE

Tools

Computer Aides Software

Engineering tools support good
SE processes (e.g. UML)
Some tools absolute requirement
for scaling e.g. build and
configuration management.
Integrated CASE (ICASE) tools
embody good processes and
improve productivity (E.g.
Rational tool set)
Some tools (e.g. debuggers,
Purify) do almost impossible for
humans.

But.. Tools change

No SE tools from my first 3
jobs exist (except Fortran/C
languages)
I use regularly use 3 SE tools
from my next set of jobs.
Other tools I learned have
been replaced with similar but
expanded concepts..
Understanding today;s tools
gives a basis for learning
future ones.

ICASE Design Tools

Rational Rose and
Rational Unified
Development.
From UML drawing to
code and back.
Generates stubs and
eventually testing code.
Supports multiple
languages

Car

Driver

Configuration
Management
CM is a discipline whose goal is to control
changes to large software through the
functions of

Component identification
Change tracking
Version selection and baselining
Managing simultaneous updates (team work)
Build processes with automated regression
testing
Software manufacture

CM in Action

1.0
1.1
1.2

2.0

1.3

2.1

1.4

2.2

1.5

4.0

3.0
3.1

Build Tools
Necessary for large projects. Keep track of what depends upon
on what, and what needs recompiled or regenerated when
things change.
Important even for small 1-person projects as soon as you have
multiple files.
Can do much more than just compile, can generate document
(if using code-based docs), generate manufactured code (e.g.
SOAP interfaces), even send emails or suggest alternatives.
E.g. in our IUE project, edit some files compile was one in
seconds, edit another and a rebuild taking days would be
needed. If more than 30 files impacted, our make process
recommend a new branch to avoid conflicts!

Debugging Tools
How do you see what the code is really doing (not what it
seems it should do)?
How to you see what happened to code during compiler
optimization?
How do you find/track down the cause of Segfault/GFP in
code youve never seen before?
How can you test various possibilities without generating
special code or recompiling.
How do you track down a memory leak?

Debugging Tools
Tools, workbenches, environments
CASE
technology

Workbenches

Tools

Editors

Compilers

File
comparators

Analysis and
design

Multi-method
workbenches

Integrated
environments

Programming

Single-method
workbenches

Environments

Process-centr
ed
environments

Testing

General-purpose
workbenches

Language-specifi c
workbenches

Static workflows
Workflow

Description

Businessmodelling

The business processes are modelled using business use cases.

Requirements

Actorswhointeractwiththesystemareidentifiedandusecasesare
developedtomodelthesystemrequirements.

Analysisanddesign

Adesignmodeliscreatedanddocumentedusingarchitectural
models,componentmodels,objectmodelsandsequencemodels.

Implementation

Thecomponentsinthesystemareimplementedandstructuredinto
implementationsubsystems.Automaticcodegenerationfromdesign
modelshelpsacceleratethisprocess.

Test

Testingisaniterativeprocessthatiscarriedoutinconjunctionwith
implementation.Systemtestingfollowsthecompletionofthe
implementation.

Deployment

Aproductreleaseiscreated,distributedtousersandinstalledintheir
workplace.

Configurationand
changemanagement

Thissupportingworkflowmanagedchangestothesystem(see
Chapter29).

Projectmanagement

Thissupportingworkflowmanagesthesystemdevelopment(see
Chapter5).

Environment

Thisworkflowisconcernedwithmakingappropriatesoftwaretools
availabletothesoftwaredevelopmentteam.

Computer-aided
software engineering

Computer-aided software engineering (CASE) is software to

support software development and evolution processes.
Activity automation
Graphical editors for system model development;
Data dictionary to manage design entities;
Graphical UI builder for user interface construction;
Debuggers to support program fault finding;
Automated translators to generate new versions of a
program.

Case technology
Case technology has led to significant improvements in the
software process. However, these are not the order of
magnitude improvements that were once predicted
Software engineering requires creative thought - this is not
readily automated;
Software engineering is a team activity and, for large
projects, much time is spent in team interactions. CASE
technology does not really support these.

CASE classification

Classification helps us understand the different types of

CASE tools and their support for process activities.
Functional perspective
Tools are classified according to their specific function.
Process perspective
Tools are classified according to process activities that
are supported.
Integration perspective
Tools are classified according to their organisation into
integrated units.

Functional tool
classification
Tool type

Examples

Planning tools

PERT tools, estimation tools, spreadsheets

Editing tools

Text editors, diagram editors, word processors

Change management tools

Requirements traceability tools, change control systems

Configuration management tools

Version management systems, system building tools

Prototyping tools

Very h igh-level languages, user interface generators

Method-support tools

Design editors, data dictionaries, code generators

Language-processing tools

Compilers, interpreters

Program analysis tools

Cross reference generators, static analysers, dynamic analysers

Testing tools

Test data generators, file comparators

Debugging tools

Interactive debugging systems

Documentation tools

Page layout programs, image editors

Re-engineering tools

Cross-reference systems, program re-structuring systems

CASE integration

Tools
Support individual process tasks such as design
consistency checking, text editing, etc.
Workbenches
Support a process phase such as specification or design,
Normally include a number of integrated tools.
Environments
Support all or a substantial part of an entire software
process. Normally include several integrated
workbenches.

Software Process
Qualities
Process is reliable if it consistently leads to high-quality
products
Process is robust if it can accommodate unanticipated
changes in tools and environments
Process performance is productivity
Process is evolvable if it can accommodate new
management and organizational techniques
Process is reusable if it can be applied across projects
and organizations

Assessing Software
Qualities
Qualities must be measurable/quantifiable
Measurement requires that qualities be precisely defined
Improvement requires accurate and consistent
measurements
For most SD groups, qualities are informally defined and are
difficult to assess

Characteristics of
Software Products
General characteristics
Usability
Maintainability
Dependability
Efficiency
Good software products require good programming,

Software as a
Product
Software is expensive!!
Every software project has a trade-off
between:
Functionality
Resources (cost)
Timeliness

Risk Management
What can go wrong in a software project?
How can the risk be reduced?

System and Software

Design
System design: Partition the requirements to hardware or
software systems. Establishes an overall system
architecture
Software design: Represent the software system
functions in a form that can be transformed into one or
more executable programs
Unified Modeling Language (UML)

Programming and
Unit Testing
The software design is realized as a set of
programs or program units. (Written
specifically, acquired from elsewhere, or
modified.)
Individual components are tested against
specifications.

Integration and
System Testing
The individual program units are:
integrated and tested as a complete system
tested against the requirements as specified
delivered to the client

Operation and
Maintenance
Operation: The system is put into practical use.
Maintenance: Errors and problems are
identified and fixed.
Evolution: The system evolves over time as
requirements change, to add new functions or
adapt the technical environment.
Phase out: The system is withdrawn from
service.

Projects
Teams that are planning to carry out the
Internet Butler project, please meet with me
after the lecture.

Documentation
Reasons for documentation:
visibility (e.g., project plan, interim report)
user support (e.g., user manual)
team communication (e.g., interface specifications)
maintenance and evolution (e.g., requirements)
Characteristics of documentation:
accurate and kept current
appropriate for audience
maintained online (usually)
simple but professional in style and appearance
Documentation is expensive --> Quality not volume

Form of
Documentation
External
Printed
Web site
Internal
Program documentation
Program context (e.g., copyright notices)

Requirements
Analysis
1. Understand the requirements in depth:
Domain understanding
Examples: Tote Investors, Philips light bulbs
Stakeholders
Example: Andrew project

Interviews with
Clients
Clients may have only a vague concept of requirements.
Prepare before you meet with them
Keep full notes
If you don't understand, delve further
Small group meetings are often most effective
Clients often confuse the current system with the underlying
requirement.

Requirements
Analysis
2. Organize the requirements:
Classification into coherent clusters
(e.g., legal requirements)
Recognize and resolve conflicts
(e.g., functionality v. cost v. timeliness)
Example: Dartmouth general ledger system

Copyright
A copyright gives the owner the exclusive right to:

reproduce

distribute

perform

display

license

Gradually extended to cover text, music, photographs, designs,

software, ...

Copyright
Copyright at creation

Works for hire

Contracts and licenses

First sale

Fair use

Infringement (contamination)

International differences

Moral rights

Copyright registration

S/W Project
Objectives
Management
To explain the main tasks undertaken by project managers
To introduce software project management and to describe its
distinctive characteristics
To discuss project planning and the planning process
To show how graphical schedule representations are used by
project management
To discuss the notion of risks and the risk management process

S/W Project
Topics covered
Management

Management activities
Project planning
Project scheduling
Risk management

S/W
Project
Software
project
Management
management
Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.
Project management is needed because software development
is always subject to budget and schedule constraints that are
set by the organisation developing the software.

S/W Project Management

Software
management
Distinction

distinctions

The product is intangible.

The product is uniquely flexible.
Software engineering is not recognized as an
engineering discipline with the sane status as
mechanical, electrical engineering, etc.
The software development process is not
standardised.
Many software projects are 'one-off' projects.

Management Activities
Management
activities

Proposal writing.
Project planning and scheduling.
Project costing.
Project monitoring and reviews.
Personnel selection and evaluation.
Report writing and presentations.

Project Staffing
Project
staffing
May not be possible to appoint the ideal people to work on a
project
Project budget may not allow for the use of highly-paid staff;
Staff with the appropriate experience may not be available;
An organisation may wish to develop employee skills on a
software project.

Managers have to work within these constraints especially

when there are shortages of trained staff.

Project Planning
Project
planning
Probably the most time-consuming project management
activity.
Continuous activity from initial concept through
to system delivery. Plans must be regularly revised as new
information becomes available.
Various different types of plan may be developed to support
the main software project plan that is concerned with schedule
and budget.

Types of
of Project
Types
projectPlan
plan
Plan

Description

Quality plan

Describes the quality procedures and standards that will be

used in a project. See Chapter 27.

Validation plan

Describes the approach, resources and schedule used for

system validation. See Chapter 22.

Configuration
management plan

Describes the configuration management procedures and

structures to be used. See Chapter 29.

Maintenance plan

Predicts the maintenance requirements of the system,

maintenance costs and effort required. See Chapter 21.

Staff
plan.

development Describes how the skills and experience of the project team
members will be developed. See Chapter 25.

The project plan

The project plan sets out:
The resources available to the project;
The work breakdown;
A schedule for the work.

Project Plan
plan Structure
structure
Project

Introduction.
Project organisation.
Risk analysis.
Hardware and software resource requirements.
Work breakdown.
Project schedule.
Monitoring and reporting mechanisms.

Project Scheduling
scheduling
Project
Split project into tasks and estimate time and resources
required to complete each task.
Organize tasks concurrently to make optimal
use of workforce.
Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.
Dependent on project managers intuition and experience.

The project scheduling

process

Identify
activities

Software
requirements

Identify activity
dependencies

Estimate resources
for activities

Allocate people
to activities

Create project
charts

Activity char
ts
and bar char
ts

Risk management
Risk management is concerned with identifying risks and
drawing up plans to minimise their effect on a project.
A risk is a probability that some adverse circumstance will
occur
Project risks affect schedule or resources;
Product risks affect the quality or performance of the
software being developed;
Business risks affect the organisation developing or
procuring the software.

The risk management

process
Risk identification
Identify project, product and business risks;
Risk analysis
Assess the likelihood and consequences of these risks;
Risk planning
Draw up plans to avoid or minimise the effects of the risk;
Risk monitoring
Monitor the risks throughout the project;

The risk management

process

Risk
identifi cation

Risk analysis

Risk planning

Risk
monitoring

List of potential
risks

Prioritised risk
list

Risk avoidance
and contingency
plans

Risk
assessment

Risk identification

Technology risks.
People risks.
Organisational risks.
Requirements risks.
Estimation risks.

Risks and risk types

Risktype

Possiblerisks

Technology

Thedatabaseusedinthesystemcannotprocessasmanytransactionspersecond
asexpected.
Softwarecomponentsthatshouldbereusedcontaindefectsthatlimittheir
functionality.

People

Itisimpossibletorecruitstaffwiththeskillsrequired.
Keystaffareillandunavailableatcriticaltimes.
Requiredtrainingforstaffisnotavailable.

Organisational

Theorganisationisrestructuredsothatdifferentmanagementareresponsiblefor
theproject.
Organisationalfinancialproblemsforcereductionsintheprojectbudget.

Tools

ThecodegeneratedbyCASEtoolsisinefficient.
CASEtoolscannotbeintegrated.

Requirements

Changestorequirementsthatrequiremajordesignreworkareproposed.
Customersfailtounderstandtheimpactofrequirementschanges.

Estimation

Thetimerequiredtodevelopthesoftwareisunderestimated.
Therateofdefectrepairisunderestimated.
Thesizeofthesoftwareisunderestimated.

Risk analysis
Assess probability and seriousness of each risk.
Probability may be very low, low, moderate, high or very high.
Risk effects might be catastrophic, serious, tolerable or
insignificant.

Risk analysis (i)

Risk

Probability

Effects

Organisationalfinancialproblemsforcereductionsin
theprojectbudget.

Low

Catastrophic

Itisimpossibletorecruitstaffwiththeskillsrequired
fortheproject.

High

Catastrophic

Keystaffareillatcriticaltimesintheproject.

Moderate

Serious

Softwarecomponentsthatshouldbereusedcontain
defectswhichlimittheirfunctionality.

Moderate

Serious

Changestorequirementsthatrequiremajordesign
reworkareproposed.

Moderate

Serious

Theorganisationisrestructuredsothatdifferent
managementareresponsiblefortheproject.

High

Serious

Risk analysis (ii)

Risk

Probability

Effects

Thedatabaseusedinthesystemcannotprocessas
manytransactionspersecondasexpected.

Moderate

Serious

Thetimerequiredtodevelopthesoftwareis
underestimated.

High

Serious

CASEtoolscannotbeintegrated.

High

Tolerable

Customersfailtounderstandtheimpactof
requirementschanges.

Moderate

Tolerable

Requiredtrainingforstaffisnotavailable.

Moderate

Tolerable

Therateofdefectrepairisunderestimated.

Moderate

Tolerable

Thesizeofthesoftwareisunderestimated.

High

Tolerable

ThecodegeneratedbyCASEtoolsisinefficient.

Moderate

Insignificant

Risk planning
Consider each risk and develop a strategy to manage that risk.
Avoidance strategies
The probability that the risk will arise is reduced;
Minimisation strategies
The impact of the risk on the project or product will be
reduced;
Contingency plans
If the risk arises, contingency plans are plans to deal with
that risk;

Risk monitoring
Assess each identified risks regularly to decide whether or not
it is becoming less or more probable.
Also assess whether the effects of the risk have changed.
Each key risk should be discussed at management progress
meetings.

RiskObjectives
monitoring
To introduce the concepts of user and system requirements
To describe functional and non-functional requirements
To explain how software requirements may be organised in a
requirements document.

Software
Requirement
Objectives
Objectives
To introduce the concepts of user and system requirements
To describe functional and non-functional requirements
To explain how software requirements may be organised in a
requirements document.

Objectives
Risk
monitoring
To introduce the concepts of user and system requirements
To describe functional and non-functional requirements
To explain how software requirements may be organised in a
requirements document.

The Aim of Project

Management
To complete a project:
On time
On budget
With required functionality
To the satisfaction of the client
Without exhausting the team

Role of Project
Manager
Create and maintain the schedule
Should track progress against schedule
Keep some slack in the schedule
Be continually making adjustments:
Start activities before previous activity complete
Sub-contract activities
Renegotiate deliverables
Keep senior management informed

Project Planning
Methods
The Critical Path Method, Gantt charts, Activity bar charts, etc.
are roughly equivalent.
These methods are best when:
Model is updated regularly (e.g., monthly)
The structure of the project is well understood
The time estimates are reliable
Activities do not share resources
[Critical Path Method is excellent for large construction
projects

.]

Scheduling: Critical
Path Method
An activity

A dummy activity

An event

A milestone

Critical Path Method

Other
activities
START

Revise
Unit 3

Edit
Unit 3

Print
Unit 3

Mail
Unit 3
END

Critical Path Method

Other
activities

Revise
Unit 3

Edit
Unit 3

START

Other
activities

Revise
Unit 4

Edit
Unit 4

Type set
Unit 3

Print
Units 3/4

Type set
Unit 4

Mail
Units 3/4

Critical Path Method

Script
TV 2

Make
Edit
Unit 3

TV 2

Delivery

START
Edit
Unit 4

Document
Computer 1

Prototype Computer 1

Mail

Program
Computer 1

Time Estimates for

Activities (Weeks)
4
1
12
12

3
3

6
2

3
2

4
4

1
1

3
2

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.

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

What is CASE (ComputerAided Software

Engineering)
Software systems that are intended to provide automated
support for software process activities.
CASE systems are often used for method support.
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.

The software process

A structured set of activities required to develop a
software system

Specification;
Design;
Validation;
Evolution.

A software process model is an abstract representation of a

process. It presents a description of a process from some
particular perspective.

Generic software process models

The waterfall model
Separate and distinct phases of specification and development.

Evolutionary development
Specification, development and validation are interleaved.

Component-based software engineering

The system is assembled from existing components.

There are many variants of these models e.g. formal

development where a waterfall-like process is used but the
specification is a formal specification that is refined through
several stages to an implementable design.

Computer-aided software
engineering
Computer-aided software engineering (CASE) is software to
support software development and evolution processes.
Activity automation

Graphical editors for system model development;

Data dictionary to manage design entities;
Graphical UI builder for user interface construction;
Debuggers to support program fault finding;
Automated translators to generate new versions of a program.

CASE classification
Classification helps us understand the different types of CASE
tools and their support for process activities.
Functional perspective
Tools are classified according to their specific function.

Process perspective
Tools are classified according to process activities that are
supported.

Integration perspective
Tools are classified according to their organisation into
integrated units.

CASE integration
Tools
Support individual process tasks such as design
consistency checking, text editing, etc.

Workbenches
Support a process phase such as specification or design,
Normally include a number of integrated tools.

Environments
Support all or a substantial part of an entire software
process. Normally include several integrated
workbenches.

Objectives
Project
Management
To explain the main tasks undertaken by project managers
To introduce software project management and to describe its
distinctive characteristics
To discuss project planning and the planning process
To show how graphical schedule representations are used by
project management
To discuss the notion of risks and the risk management process

TopicsManagement
covered
Project

Management activities
Project planning
Project scheduling
Risk management

Software project
Project
Management
management
Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.
Project management is needed because software
development is always subject to budget and
schedule constraints that are set by the
organisation developing the software.

Software management distinctions

Project Management
The product is intangible.
The product is uniquely flexible.
Software engineering is not recognized as an
engineering discipline with the sane status as
mechanical, electrical engineering, etc.
The software development process is not
standardised.
Many software projects are 'one-off' projects.

Management
Managementactivities
Activities

Proposal writing.
Project planning and scheduling.
Project costing.
Project monitoring and reviews.
Personnel selection and evaluation.
Report writing and presentations.

Management
Management
commonalities
Commonalities
These activities are not peculiar to software
management.
Many techniques of engineering project
management are equally applicable to software
project management.
Technically complex engineering systems tend
to suffer from the same problems as software
systems.

Project
Projectstaffing
Staffing
May not be possible to appoint the ideal people to work on a
project
Project budget may not allow for the use of highly-paid staff;
Staff with the appropriate experience may not be available;
An organisation may wish to develop employee skills on a
software project.

Managers have to work within these constraints especially

when there are shortages of trained staff.

Project
Projectplanning
Planning

Probably the most time-consuming project management activity.

Continuous activity from initial concept through
to system delivery. Plans must be regularly revised as new information
becomes available.
Various different types of plan may be developed to support the main
software project plan that is concerned with schedule and budget.

Types
Typesof
ofproject
Projectplan
Plan
Plan

Description

Quality plan

Describes the quality procedures and standards that will be

used in a project. See Chapter 27.

Validation plan

Describes the approach, resources and schedule used for

system validation. See Chapter 22.

Configuration
management plan

Describes the configuration management procedures and

structures to be used. See Chapter 29.

Maintenance plan

Predicts the maintenance requirements of the system,

maintenance costs and effort required. See Chapter 21.

Staff
plan.

development Describes how the skills and experience of the project team
members will be developed. See Chapter 25.

Establish the project constraints

Make initial assessments of the project parameters

Project planning process

Define project milestones and deliverables

while project has not been completed or cancelled loop

Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise ) then
Initiate technical review and possible revision
end if
end loop

The project plan

The project plan sets out:
The resources available to the project;
The work breakdown;
A schedule for the work.

Project
Projectplan
Planstructure
Structure

Introduction.
Project organisation.
Risk analysis.
Hardware and software resource requirements.
Work breakdown.
Project schedule.
Monitoring and reporting mechanisms.

Activity organization
Activities
Organization

Activities in a project should be organised to produce tangible outputs for

management to judge progress.
Milestones are the end-point of a process activity.
Deliverables are project results delivered to customers.
The waterfall process allows for the straightforward definition of progress
milestones.

Milestones in the RE
Milestone
Re Project
process
ACTIVITIES
Feasibility
study

Requirements
analy sis

Prototype
development

Design
study

Requirements
specifi ca
tion

Feasibility
report

User
requirements

Evaluation
report

Architectur
al
design

System
requirements

MILESTONES

Project
Projectscheduling
Scheduling

Split project into tasks and estimate time and resources required to
complete each task.
Organize tasks concurrently to make optimal
use of workforce.
Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.
Dependent on project managers intuition and experience

The project scheduling

process

Identify
activities

Software
requirements

Identify activity
dependencies

Estimate resources
for activities

Allocate people
to activities

Create project
charts

Activity char
ts
and bar char
ts

Scheduling
Schedulingproblems
Problem

Estimating the difficulty of problems and hence the cost of developing a

solution is hard.
Productivity is not proportional to the number of people working on a task.
Adding people to a late project makes it later because of communication
overheads.
The unexpected always happens. Always allow contingency in planning.

Bar chartBar charts and

Bar Charts
& Activity
activity
networkss
and
Network
activity
networks

Graphical notations used to illustrate the project schedule.

Show project breakdown into tasks. Tasks should not be too
small. They should take about a week or two.
Activity charts show task dependencies and the the critical
path.
Bar charts show schedule against calendar time.

BarTask
Charts
& Activity
durations
and
Network
dependencies

Activity
Network
Activity network
14/7/03

15 days

M1

T3

8 days

T9

T1

25/7/03

4/7/03
start

15 days

5 days

4/8/03

T6

M4

M3

25/8/03
M6
7 days

20 days

15 days

T7

T2
25/7/03

10 days

M2

T4

T11

10 days
T5

5/9/03

11/8/03
M7

T10

18/7/03

M8

15 days

10 da
ys
T12

M5
25 days

Finish

T8
19/9/03

Activity
Timeline
Activity timeline
4/7

11/7

18/7

25/7

1/8

8/8

15/8

22/8

29/8

5/9

12/9

19/9

Start
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Finish

Activity
Timeline
Staff allocation
4/7
Fred

11/7 18/7 25/7

1/8

8/8

15/8 22/8 29/8

5/9

12/9 19/9

T4
T8

T11
T12

Jane

T1
T3
T9

Anne

T2
T6

Jim
Mary

T7
T5

T10

Risk management
Risk management is concerned with identifying
risks and drawing up plans to minimise their
effect on a project.
A risk is a probability that some adverse
circumstance will occur
Project risks affect schedule or resources;
Product risks affect the quality or performance of
the software being developed;
Business risks affect the organisation developing or
procuring the software.

Software risks
Risk

Affects

Description

Staff turnover

Project

Experienced staff will leave the project before it is finished.

Management change

Project

There will be a change of organisational management with

different priorities.

Hardware unavailability

Project

Hardware that is essential for the project will not be

delivered on schedule.

Requirements change

Project and
product

There will be a larger number of changes to the

requirements than anticipated.

Specification delays

Project and
product

Specifications of essential interfaces are not available on

schedule

Size underestimate

Project and
product

The size of the system has been underestimated.

CASE tool underperformance

Product

CASE tools which support the project do not perform as

anticipated

Tec hnology change

Business

The underlying technology on which the system is built is

superseded by new technology.

Product competition

Business

A competitive product is marketed before the system is

completed.

The risk management

process
Risk identification
Identify project, product and business risks;
Risk analysis
Assess the likelihood and consequences of these risks;
Risk planning
Draw up plans to avoid or minimise the effects of the risk;
Risk monitoring
Monitor the risks throughout the project;

The risk management

process

Risk
identifi cation

Risk analysis

Risk planning

Risk
monitoring

List of potential
risks

Prioritised risk
list

Risk avoidance
and contingency
plans

Risk
assessment

Risk identification

Technology risks.
People risks.
Organisational risks.
Requirements risks.
Estimation risks.

Risks and risk types

Risktype

Possiblerisks

Technology

Thedatabaseusedinthesystemcannotprocessasmanytransactionspersecond
asexpected.
Softwarecomponentsthatshouldbereusedcontaindefectsthatlimittheir
functionality.

People

Itisimpossibletorecruitstaffwiththeskillsrequired.
Keystaffareillandunavailableatcriticaltimes.
Requiredtrainingforstaffisnotavailable.

Organisational

Theorganisationisrestructuredsothatdifferentmanagementareresponsiblefor
theproject.
Organisationalfinancialproblemsforcereductionsintheprojectbudget.

Tools

ThecodegeneratedbyCASEtoolsisinefficient.
CASEtoolscannotbeintegrated.

Requirements

Changestorequirementsthatrequiremajordesignreworkareproposed.
Customersfailtounderstandtheimpactofrequirementschanges.

Estimation

Thetimerequiredtodevelopthesoftwareisunderestimated.
Therateofdefectrepairisunderestimated.
Thesizeofthesoftwareisunderestimated.

Risk analysis
Assess probability and seriousness of each
risk.
Probability may be very low, low, moderate,
high or very high.
Risk effects might be catastrophic, serious,
tolerable or insignificant.

Risk analysis (i)

Risk

Probability

Effects

Organisationalfinancialproblemsforcereductionsin
theprojectbudget.

Low

Catastrophic

Itisimpossibletorecruitstaffwiththeskillsrequired
fortheproject.

High

Catastrophic

Keystaffareillatcriticaltimesintheproject.

Moderate

Serious

Softwarecomponentsthatshouldbereusedcontain
defectswhichlimittheirfunctionality.

Moderate

Serious

Changestorequirementsthatrequiremajordesign
reworkareproposed.

Moderate

Serious

Theorganisationisrestructuredsothatdifferent
managementareresponsiblefortheproject.

High

Serious

Risk analysis (ii)

Risk

Probability

Effects

Thedatabaseusedinthesystemcannotprocessas
manytransactionspersecondasexpected.

Moderate

Serious

Thetimerequiredtodevelopthesoftwareis
underestimated.

High

Serious

CASEtoolscannotbeintegrated.

High

Tolerable

Customersfailtounderstandtheimpactof
requirementschanges.

Moderate

Tolerable

Requiredtrainingforstaffisnotavailable.

Moderate

Tolerable

Therateofdefectrepairisunderestimated.

Moderate

Tolerable

Thesizeofthesoftwareisunderestimated.

High

Tolerable

ThecodegeneratedbyCASEtoolsisinefficient.

Moderate

Insignificant

Risk planning
Consider each risk and develop a strategy to
manage that risk.
Avoidance strategies
The probability that the risk will arise is reduced;

Minimisation strategies
The impact of the risk on the project or product will be
reduced;

Contingency plans
If the risk arises, contingency plans are plans to deal
with that risk;

Risk management
strategies (i)
Risk

Strategy

Organisational
financialproblems

Prepareabriefingdocumentforseniormanagement
showinghowtheprojectismakingaveryimportant
contributiontothegoalsofthebusiness.

Recruitment
problems

Alertcustomerofpotentialdifficultiesandthe
possibilityofdelays,investigatebuyingin
components.

Staffillness

Reorganiseteamsothatthereismoreoverlapofwork
andpeoplethereforeunderstandeachothersjobs.

Defective
components

Replacepotentiallydefectivecomponentswithbought
incomponentsofknownreliability.

Risk management
strategies (ii)
Risk

Strategy

Requirements
changes

Derivetraceabilityinformationtoassessrequirements
changeimpact,maximiseinformationhidinginthe
design.

Organisational
restructuring

Prepareabriefingdocumentforseniormanagement
showinghowtheprojectismakingaveryimportant
contributiontothegoalsofthebusiness.

Database
performance

Investigatethepossibilityofbuyingahigher
performancedatabase.

Underestimated
developmenttime

Investigatebuyingincomponents,investigateuseofa
programgenerator

Risk monitoring
Assess each identified risks regularly to decide
whether or not it is becoming less or more
probable.
Also assess whether the effects of the risk have
changed.
Each key risk should be discussed at
management progress meetings.

Risk indicators
Risktype

Potentialindicators

Technology

Latedeliveryofhardwareorsupportsoftware,manyreported
technologyproblems

People

Poorstaffmorale,poorrelationshipsamongstteammember,
jobavailability

Organisational

Organisationalgossip,lackofactionbyseniormanagement

Tools

Reluctancebyteammemberstousetools,complaintsabout
CASEtools,demandsforhigherpoweredworkstations

Requirements

Manyrequirementschangerequests,customercomplaints

Estimation

Failuretomeetagreedschedule,failuretoclearreported
defects