LECTURE 2

SOFTWARE PROCESSES

Software Engineering

Objectives
2

To introduce software process models

To describe generic process models and when they may
be used
To explain how an iterative, incremental development
process leads to faster delivery of more useful software
To discuss the essence of agile development methods
To explain the principles and practices of extreme
programming
To explain the roles of prototyping in the software process

Generic Software Process Models

1.0 The Waterfall Model

2.0 Evolutionary Process Models

3.0 Incremental Process Models

3.1 The Incremental Model

3.2 The RAD Model

4.0 Specialised Process Models

2.1 Prototyping Model

2.2 The Spiral Model

4.1 Component-Based Development

5.0 Unified Process Model

6.0 Software Process Improvement

1.0 Waterfall Model

Requirements
specification

Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing

Operation and
maintenance

Waterfall Model
Requirements analysis and definition: The functionalities to be provided by
the system (e.g a search engine, a password-protected login) are
established through consultation with end-users.
System and software design: During this phase, an overall system architecture
is established so that the developer can get an idea how the different subsystems interact together.
Implementation and Unit testing: During this stage, the software is
implemented as a set of programs or program units, using an appropriate
programming platform. After the software has been implemented, the
software is tested to ensure that it is working properly.

Waterfall Model
6

Integration and system testing: The individual program

units or programs are integrated and tested as a complete
system to ensure that the software requirements have been
met.
Operation and maintenance: The system is installed at the
customers site and end-users are trained to use the system.
Maintenance involves correcting errors that were not
discovered in earlier stages of the life cycle, in order to
improve the performance of the system.

Characteristics of Waterfall Life

Cycle Model

The project activities are divided into discrete, isolated stage.

The following phase should not start until the previous phase
has finished. Each stage relies on the information produced by
the previous stage.
It enforces a disciplined approach as each step should be
completed.
A project plan can be constructed, based on milestones,
represented by the completion of each stage. Result of each
phase is one or more documents which must be approved or
signed-off.

Drawbacks of Waterfall Life Cycle

Model
8

Inflexible partitioning of the project into distinct stages. Does

not support parallel activity.
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.
Commitments made at an early stage in the process. This
makes it difficult to respond to changing customer
requirements.

Drawbacks of Waterfall Life Cycle

Model
9

Distinct stages may become blocking states where team

members must wait for other members to complete dependent
tasks.

It is difficult for customer to state all requirements

explicitly at the very beginning of the project.
The model has trouble accommodating the uncertainty
associated with incomplete requirements at the start of the
project.
Does not support reuse and does not maintain customer
involvement.

Activity 1
10

Give an example
(1) where it is advisable to use waterfall model as a
software process (with justifications).
(2) where it is not advisable to use waterfall model
as a software process (with justification)

2.0 Evolutionary Process Models

2.1 Prototyping Model
2.2 The Spiral Model

2.1 Prototyping Model

12

A prototype is a simplified subset of the proposed system that simulates the actual processing
that will be done by the real system. Typically it consists of a few screen designs and reports
that provide just sufficient functionality to allow users to experience how the proposed system
might look and feel.

It is used in cases where,

the customer defines a general set of objectives for software but does not provide detailed
requirements,

OR, the developer may be unsure about the efficiency of an algorithm, the adaptability of an
operating system, the form of human-machine interaction.

The objective of the prototyping model is to develop a throwaway prototype to understand

the customer requirements and experiment with parts of the customer requirements that are
poorly understood.

Prototypes should be discarded after development

The end-product should be better requirements definition for the final software.

Prototyping Model
13

The process of prototype development is as follows:

Prototyping Model
14

Begins with requirements gathering. Developer and customer meet to

define the overall objectives for the software,

Identify whatever requirements are known, and

outline areas where further definition is mandatory

Define the functionality. A quick-design is made. Quick-design focuses on

those aspects of the s/w that are visible to the user.

Construction of throw-away prototype from quick-design.

Prototype is evaluated by customer/user and used to refine requirements

for the s/w to be developed.

Note: Iteration occurs as the prototype is tuned to satisfy the needs of the
customer and the developer better understands what needs to be done.

Benefits of Prototypes
15

A prototype can quickly resolve misunderstanding

between business managers and analysts.
A prototype makes an ideal tool for defining and
discussing user interaction.
Users can understand a prototype far more easily
than most of the standard way of communicating
requirements in the form of models.

Drawbacks of Prototypes
16

The customer may want to adopt the prototype which he/she sees as a
working version of the software. He may be unaware that the prototype is
a quick-and-dirty solution.

Some prototypes are so realistic that they give the impression that the
project is almost finished whilst still at the systems analysis stage. This can
put severe pressure on the development team.

The effort required to produce a prototype may lead to the development

team using it as part of the new system. This can lead to quality problems
with the resulting system.

The developer makes implementation compromises in order to get a

prototype working quickly.

e.g. inappropriate OS, programming language, inefficient algos used just to

demonstrate capability.

There is always the risk that the developer forgets about initial inhibitions and adopt
these as long-term solutions.

Activity 2 (Group)
17

Give the differences between waterfall model and

prototyping model.

2.2 Spiral Model

18

Determine objectives
alternatives and
constraints

Risk
analysis

Evaluate alternatives
identify, resolve risks

Risk
analysis
Risk
analysis

REVIEW
Requirements plan
Life-cycle plan

Development
plan

Plan next phase

Integration
and test plan

Prototype 3
Prototype 2

Operational
protoyp e

Risk
analysis Prototype 1

Simulations, models, benchmarks

Concept of
Operation

S/W
requirements

Requirement
validation

Product
design

Detailed
design

Code
Unit test
Design
V&V
Integr ation
test
Acceptance
test
Develop, v erify
Service
next-level product

Spiral Model
19

Combines iterative nature of prototyping with controlled and systematic aspect of

Waterfall model

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

S/W Engg team moves along the spiral in a clockwise direction.

First circuit might be product specification; subsequent passes might be developing a

prototype and progressively more sophisticated versions of the software model.

Each pass through planning sector results in adjustments to project plan, cost,
schedule, no. of iterations

Spiral Model Sectors

20

1. Objective setting
Specific objectives for the phase are identified
Constraints on the process are identified and a detailed
management plan is drawn up
Identify project risks
Alternative strategies planned
2. Risk assessment and reduction
Risks are assessed and activities put in place to reduce the
key risks E.g. if there is a risk that requirements are
inappropriate, a prototype may be developed

Spiral Model Sectors

21

3. Development and validation

A development model for the system is chosen which can be any of the generic
models

E.g.if user interface risks are dominant, prototyping model is chosen; if safety risks
are considered, Formal Systems Model is chosen

4. Planning

The project is reviewed and the next phase of the spiral is planned

Explicit risk consideration in the spiral model

Risk is something which can go wrong

Risk result in project problems such as schedule and cost overrun

Risk minimization is an important activity.

Explore each alternative path by prototyping.

Choose path combining least risk & best potential payoff.

Risks continually considered throughout process

Drawbacks of Spiral Model

22

Contractual development often specifies process model and

deliverables in advance
Requires risk assessment expertise
Needs refinement for general use
The spiral model does not provide any form of milestones.
There is a tendency for projects to go off track.
Bringing together the effort of all individuals concerned can be
difficult.
Note: Spiral model has been very influential in helping people
think about iteration in software processes and introducing the
risk-driven approach to development.

3.0 Incremental Process Model

3.1 Incremental Model
3.2 Rapid Application Development

3.1 Incremental Model

24

Combines elements of the Waterfall Model with the iterative

feature of the Prototyping Model
Allows reduction of rework (due to changing requirements) in
the development process and gives customers opportunity to
delay decisions on their detailed requirements until they have
some experience with the system
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

Incremental Model
25

User requirements are prioritised and the highest priority

requirements are included in early increments.(core product is first
developed)
Customer evaluation of the first increment helps in formulating a
development plan for the next increment

Incremental Model
26

The plan addresses the modification of the core product to better satisfy
customer needs and the delivery of additional features and functionality

Once the development of an increment is started, the requirements are

frozen though requirements analysis for later increments can continue

Once an increment is completed and delivered, customer can out it into

service i.e. customer takes early delivery of part of the system
functionality, they may experiment with it and clarify requirements for later
requirements.

New increments are integrated with existing increments so that system

functionality improves with each delivered increment.

Advantages of Incremental Model

27

Customer value can be delivered with each increment so

system functionality is available earlier
No need to wait until the entire system is delivered.
First increment satisfy their most critical requirements so the
s/w can be immediately used
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

Problems with Incremental Model

28

Increments should be relatively small

(< 20,000 loc). Increment should at least deliver some system functionality.
Hard to decide on the right size of each increment

Most systems require a basic set of facilities that

are used by all parts.

As requirements are not defined in detail until an increment is to be

developed, it is difficult to identify common facilities that all increments
require.

Problems with Incremental

Development
Management problems
Progress can be hard to judge and problems hard to find because there is
no documentation to demonstrate what has been done.

Contractual problems
The normal contract may include a specification; without a specification,
different forms of contract have to be used.

Validation problems
Without a specification, what is the system being tested against?

Maintenance problems
Continual change tends to corrupt software structure making it more
expensive to change and evolve to meet new requirements.

08/06/11

3.2 Rapid Application

Development
3.2.1 Agile methods
3.2.2 Extreme programming

31

The Rapid Application Development

Model

RAD is used since it is unacceptable to for some projects to run

for several years without delivering usable products.

It is an incremental software process model that is based on an

extremely short development cycle.
High-speed adaptation of the Waterfall Model and rapid
development is achieved by component-based construction.
If requirements are well-understood and project scope is constrained,
the RAD process enables the development team to create a fully
functional system within a short period of time. (typically 60 to 90
days)

32

The Rapid Application Development

Model

Four Phases of RAD

1. Requirements Planning phase combines
elements of the system planning and systems
analysis phases of the System Development Life
Cycle (SDLC). Users, managers, and IT staff
members discuss and agree on business needs,
project scope, constraints, and system requirements.
It ends when the team agrees on the key issues and
obtains management authorization to continue.

Four Phases of RAD

2. User design phase during this phase, users
interact with systems analysts and develop models
and prototypes that represent all system processes,
inputs, and outputs. The RAD groups or subgroups
typically use a combination of Joint Application
Development (JAD) techniques and CASE tools to
translate user needs into working models. User
Design is a continuous interactive process that
allows users to understand, modify, and eventually
approve a working model of the system that meets
their needs.

Four Phases of RAD

3. Construction phase focuses on program and
application development task similar to the SDLC. In
RAD, however, users continue to participate and
can still suggest changes or improvements as actual
screens or reports are developed. Its tasks are
programming and application development,
coding, unit-integration and system testing.

Four Phases of RAD

4. Cutover phase resembles the final tasks in the
SDLC implementation phase, including data
conversion, testing, changeover to the new system,
and user training. Compared with traditional
methods, the entire process is compressed. As a
result, the new system is built, delivered, and
placed in operation much sooner. Its tasks are data
conversion, full-scale testing, system changeover,
user training.

Drawbacks of RAD
37

For large but scalable projects, RAD requires sufficient human

resources to create right number of RAD teams
Requires commitment from developers and customers to the
rapid-fire activities necessary to get the software completed in
a short time. Lack of commitment from any party will cause the
RAD project to fail.
Not appropriate if application makes heavy use of new
technology or new software requires a high degree of
interoperability with existing computer programs.

3.2.1 Agile Modelling Approach

38

Agile software development refers to a group of

software development based on iterative development,
where requirements and solutions evolve through
collaboration between self-organizing cross-functional
teams.
Agile Modelling (AM) approach to developing softwarebased systems aims to improve system modelling process
by combining best practices of selected modelling
methods in a context of a particular project.

Agile Modelling Approach

39

Characteristics of Agile Software

Development
40

Agile development methods promote development, teamwork,

collaboration, and process adaptability throughout the life-cycle of the
project.

Agile methods break tasks into small increments with minimal planning, and
do not directly involve long-term planning.

Iterations are short time frames known as timebox that typically last from
one to four weeks.

Each iteration involves a team working through a full software development

cycle including planning, requirements analysis, design, coding, unit testing
and when a working product is demonstrated to stakeholders.

This helps minimize overall risk, and lets the project adapt to changes
quickly.

Characteristics of Agile Software

Development
41

Team composition in an agile project is usually cross-functional and selforganizing without consideration for any existing corporate hierarchy or the
corporate roles of team members.

Team members normally take responsibility for tasks that deliver the
functionality an iteration requires.

They decide individually how to meet an iteration's requirements.

Agile methods emphasize face-to-face communication over written

documents when the team is all in the same location.

When a team works in different locations, they maintain daily contact

through videoconferencing, voice, e-mail, etc.

Agile Methods
Dissatisfaction with the overheads involved in design methods
led to the creation of agile methods. These methods:

Focus on the code rather than the design;

Are based on an iterative approach to software

development;

Are intended to deliver working software quickly and

evolve this quickly to meet changing requirements.

Agile methods are probably best suited to small/mediumsized business systems or PC products.

Principles of Agile Methods

Principle

Description

Customer involvement

The customer should be closely involved throughout the

development process. Their role is provide and prioritise new
system requirements and to evaluate the iterations of the system.

Incremental delivery

The software is developed in increments with the customer

specifying the requirements to be included in each increment.

People not process

The skills of the development team should be recognised and

exploited. The team should be left to develop their own ways of
working without prescriptive processes.

Embrace change

Expect the system requirements to change and design the system

so that it can accommodate these changes.

Maintain simplicity

Focus on simplicity in both the software being developed and in

the development process used. Wherever possible, actively work
to eliminate complexity from the system.

Problems with Agile Methods

It can be difficult to keep the interest of customers who are
involved in the process.
Team members may be unsuited to the intense involvement
that characterises agile methods.
Prioritising changes can be difficult where there are multiple
stakeholders.
Maintaining simplicity requires extra work.
Contracts may be a problem as with other approaches to
iterative development.

08/06/11

Contrasted with other iterative

development methods
45

Most agile methods share other iterative and incremental

development methods' emphasis on building releasable
software in short time periods.
Agile development differs from other development models: in
this model, time periods are measured in weeks rather than
months and work is performed in a highly collaborative
manner.
Most agile methods also differ by treating their time period as
a timebox.

3.2.2 Extreme Programming

Perhaps the best-known and most widely used
agile method.
Extreme Programming (XP) takes an extreme
approach to iterative development.
New versions may be built several times per day;
Increments are delivered to customers every 2
weeks;
All tests must be run for every build and the build
is only accepted if tests run successfully.

08/06/11

The XP Release Cycle

Select user
stories for this
release

Evaluate
system

Break down
stories to tasks

Release
software

Plan release

Develop/integ
rate/
test software
08/06/11

Extreme Programming Practices 1

Incremental planning

Requirements are recorded on Story Cards and the Stories to be

included in a release are determined by the time available and
their relative priority. The developers break these Stories into
development Tasks.

Small Releases

The minimal useful set of functionality that provides business

value is developed first. Releases of the system are frequent and
incrementally add functionality to the first release.

Simple Design

Enough design is carried out to meet the current requirements

and no more.

Test first development

An automated unit test framework is used to write tests for a new

piece of functionality before that functionality itself is
implemented.

Refactoring

All developers are expected to refactor the code continuously as

soon as possible code improvements are found. This keeps the
code simple and maintainable.

Extreme Programming Practices 2

Pair Programming

Developers work in pairs, checking each others work and

providing the support to always do a good job.

Collective Ownership

The pairs of developers work on all areas of the system, so that

no islands of expertise develop and all the developers own all the
code. Anyone can change anything.

Continuous Integration

As soon as work on a task is complete it is integrated into the

whole system. After any such integration, all the unit tests in the
system must pass.

Sustainable pace

Large amounts of over-time are not considered acceptable as the

net effect is often to reduce code quality and medium term
productivity

On-site Customer

A representative of the end-user of the system (the Customer)

should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.

Requirements Scenarios
In XP, user requirements are expressed as
scenarios or user stories.
These are written on cards and the development
team break them down into implementation tasks.
These tasks are the basis of schedule and cost
estimates.
The customer chooses the stories for inclusion in the
next release based on their priorities and the
schedule estimates.

Story card for Document Downloading

Downloading and printing an article
First, you select the article that you want from a displayed list.You
then have to tell the system how you will pay for it - this can either
be through a subscription, through a company account or by credit
card.
After this, you get a copyright form from the system to fill in and,
when you have submitted this, the article you want is downloaded
onto your computer.
You then choose a printer and a copy of the article is printed. You
tell the system if printing has been successful.
If the article is a print-only article, you can
t keep the PDF version
so it is automatically deleted from your computer.

XP and Change
Conventional wisdom in software engineering is to
design for change. It is worth spending time and
effort anticipating changes as this reduces costs
later in the life cycle.
XP, however, maintains that this is not worthwhile
as changes cannot be reliably anticipated.
Rather, it proposes constant code improvement
(refactoring) to make changes easier when they
have to be implemented.

Note: Code refactoring is "disciplined technique for restructuring an

existing body of code, altering its internal structure without changing its
external behavior".
08/06/11

Testing in XP
Test-first development.
Incremental test development from scenarios.
User
involvement in test development and
validation.
Automated test harnesses are used to run all
component tests each time that a new release is
built.

08/06/11

Pair Programming
In XP, programmers work in pairs, sitting together to develop
code.
This helps develop common ownership of code and spreads
knowledge across the team.
It serves as an informal review process as each line of code is
looked at by more than 1 person.
It encourages refactoring as the whole team can benefit from
this.
Measurements suggest that development productivity with
pair programming is similar to that of two people working
independently.

08/06/11

Activity 3
55

List the 5 principles of agile methods

What are the barriers to introducing agile methods
into large companies?

Answer Activity 3
56

List the 5 principles of agile methods

Customer involvement,
Incremental delivery,
People not process,
Embrace change,
Maintain simplicity.

Answer Activity 3
57

What are the barriers to introducing agile methods into large companies?
Project managers may be reluctant to accept the risks of a new approach.
The established quality procedures in large companies may be incompatible with
the informal approach to documentation in agile methods.
The existing teams may not have the high level of skills to make use of agile
methods.
There may be cultural resistance if there is a long history of plan-driven
development in the company.

4.0 Specialised Process Models

4.1Component-Based Development

4.1 Component-Based (Re-use)

Development Model
59

Based on systematic reuse where systems are integrated from existing

components or COTS (Commercial-off-the-shelf) systems

This approach is becoming more important but still limited experience with it

Analysis
Specification

Design
Implementation
Testing
Maintenance

60

Component-Based (Re-use)
Development Model

Use of 4GLs can be viewed as an example

Productivity gains at the expense of performance

Problems with interfacing

Few reusable specifications

Little motivations to develop software which can itself be reused

Reuse can be done at several levels

Philosophy:

Used software has least bugs

Advantages:
Reduces the amount of software to be developed and so
reduces cost and risk.
Leads to faster delivery of software

Drawbacks
61

Requirements compromises are inevitable => may

lead to a system which does not meet the real
needs of users
Some control over system evolution is lost as new
versions of the re-used components are not under
the control of the company using them

5.0 Unified Process Modelling

62

The Unified Software Development Process or

Unified Process is a popular iterative and
incremental software development framework. The
best-known and extensively documented refinement
of the Unified Process is the Rational Unified(RUP).

Unified Process Modelling

63

A UP project organizes the work and iterations

across four major phases:
Inception

- Define the scope of project.

Elaboration - Plan project, specify features, baseline
architecture.
Construction - Build the product
Transition - Deploy the system in its operating
environment.

Unified Process Modelling

64

The unified process is an iterative procedure where each iteration

includes work in most stages, though the relative effort and emphasis
change over time. That is early iterations tend to apply greater emphasis
to requirements and design, and later ones less so.

Unified Process Modelling

65

Activities within each phase

Business modeling: Describe structure and dynamics of the organisation

Requirement: Describes the use case based method for eliciting

requirements

Analysis & design: describe the architectural views

Implementation: takes into account software development, testing

Testing: describe test cases & procedures

Deployment: covers the deliverable system configuration

Configuration management: controls changes to artifacts

Environment: covers the necessary infrastructure required

Software Process Improvement

Software process improvement encompasses a set
of activities that will lead to a better software
process, and as a consequence, higher quality
software delivered in a more timely manner.

Need for SPI

Modern technology can help us combat the software

crisis, there is no technological silver bullet to rescue
the software development team.
Talented people are important in any software
organization.
Nevertheless, people need to be supported by a
good working environment.
Software development is hampered by changing
requirements, unpredictable schedules, lack of
standards, and insufficient training more than by a
lack of effort on the part of professionals.

How can a s/w process be

improved?
Product

Customer
Characteristics

Business
Conditions
Process

People

Technology
Development
Environment

How can a s/w process be

improved?
The process is at the centre of the triangle having a
profound effect on software process improvement.
Skill & motivation of people
Complexity of product => impact on quality & team
performance
Technology => software engineering tools & methods
The process triangle also exists within a circle of
environmental conditions that include development
environment (e,g CASE Tools), business conditions (e,g
deadlines, business rules) and customer characteristics
(e,g ease of communication and collaboration).

Summary
1.0 The Waterfall Model
2.0 Evolutionary Process Models
2.1 Prototyping
2.2 The Spiral Model
3.0 Incremental Process Models
3.1 The Incremental Model
3.2 The RAD Model
4.0 Specialised Process Models
4.1 Component-Based Development
5.0 Unified Process Modelling
6.0 Software Process Improvement

Key points
An iterative approach to software development leads to
faster delivery of software.
Agile methods are iterative development methods that aim to
reduce development overhead and so produce software
faster.
Extreme programming includes practices such as systematic
testing, continuous improvement and customer involvement.
The approach to testing in XP is a particular strength where
executable tests are developed before the code is written.
The need for SPI has been pointed out as critical to the success
of a software process.

Acknowledgements

Software Engineering 8th Edition by Ian Sommerville

Software Engineering 6th Edition by Pressman
http://www.rspa.com/spi/spi.html#generic
http://en.wikipedia.org/wiki/Rapid_application_d
evelopment