TK2013

Software Engineering Methodology

Topic 2:
Software Process (I)

Contents
Software Process
Software Process Model
Generic Software Process Models:
The Waterfall Model
Incremental Development
Reuse-oriented (component-based) Software Engineering

Other Process Models:

Software Prototyping
Incremental Delivery
Boehms Spiral Model
Rational Unified Process
Formal Methods

Introduction
Software Engineering is a layered technology.
It encompasses a process, methods and tools, and
based on a quality aspect.

Tools
How to build the
software (i.e. tasks)

Automated or semi-automated
support for the process &
methods

Methods
Process
A Quality Aspect
Organisations
commitment on quality

The GLUE

RECAP
What are the attributes of good software?
Quality Aspect
The software should deliver the required functionality and
performance (efficient) to the user and should be maintainable,
dependable and acceptable.
Efficiency (Performance)
Software should not make wasteful use of system resources

Maintainability
Software must evolve to meet changing needs

Dependability (Reliability)
Software must be trustworthy

Acceptability (Usability)
Software must be accepted by the users for which it was designed:
understandable, usable and compatible with other systems
(portability).

What is Software Process?

A set of activities that leads to the production of a
software product or system.
Scratch (from nothing to something)
Evolutionary (portion-by-portion)

Most software is developed by:

Extending and modifying existing systems.
Configurating and integrating off-the-shelf software or
components.

What is Software Process?

Software processes are intellectual and creative practice.
Thus, they are complex.
Rely on people making good judgments and decisions.

No ideal software process.

Processes are exploited to meet the capabilities of people in
an organisation and the specific characteristics of the
system.
E.g. Critical systems need robust processes; Business systems may
need quick and dirty or agile process.

The objective of any software processes is high quality (i.e.

on time, less cost, error-free product, less rework etc.)

What is Software Process?

Fundamental (common) activities in any software
processes:
Specification
Define the functionality & constraints of the software.

Design & Implementation (Development)

Propose the structure/architecture and develop the software
based on the specification.

Validation
Developed software is checked to ensure it does what customer
wants.

Evolution
Running software must evolve eventually to meet the changing
customer needs.

What is Software Process?

Supporting activities
Software project management
Assess progress against the project plan; take actions to maintain schedule.

Formal technical reviews

Assess intermediate products to uncover and remove errors.

Software quality assurance

Define and conduct activities to ensure software quality.

Software configuration management

Manage the effect of changes throughout the process.

Work product preparation and production

Create work products such as models, documents, logs etc.

Reusability management
Defines criteria and strategy to reuse components.

Measurement
Define and collect process, product and project measures for improvement.

Risk management
Assess risks that may affect the outcomes of the project or quality of the
product.

What is Software Process?

Plan-driven processes are processes where all of the process
activities are planned in advance and progress is measured
against this plan.
In agile processes, planning is incremental and it is easier to
change the process to reflect changing customer
requirements.
In practice, most practical processes include elements of both
plan-driven and agile approaches.
There are no right or wrong software processes.

What is a Software Process Model?

A software process model is an abstract
representation of a process.
It presents a description of a process from some
particular perspectives (i.e. engineering-oriented;
user-oriented; reusability etc.).
There are 3 generic process models:
Waterfall (the oldest)
Incremental/Iterative/Evolutionary Development
Reuse-oriented/Component-based software engineering

What is a Software Process Model?

The waterfall model
Plan-driven model. Separate and distinct phases of specification and
development.

Incremental development
Specification, development and validation are interleaved. May be
plan-driven or agile.

Reuse-oriented software engineering

The system is assembled from existing components. May be plandriven or agile.

In practice, most large systems are developed using a process

that incorporates elements from all of these models.

What is a Software Process Model?

There are many variants of these generic models.
E.g. Formal development (waterfall-like) produces a formal
specification that is refined through several stages
(incremental), which later can be executed directly as
code.

The models are not mutually exclusive.

In practice, they are combined and used together
especially for large projects.

The Waterfall Model

Requirements
Requirements
definition
definition
System
System
andand
software design
software
design
Implementa tion
Implementation
and
and unit
unittesting
testing
Integ
rationand
and
Integration
systemtesting
testing
system
Oper ationand
and
Operation
maintenance
maintenance

The Waterfall Model

Requirements analysis and definition

Establish systems services, constraints and goals.
They are defined in detail as a system specification.

System and software design

Establish an overall system architecture.
Distinguish hardware and software requirements.
Describe the system abstractions and their relationships.

Implementation and unit testing

Realise the design as a set of programs.
Verify each program whether it meets the specification.

Integration and system testing

Individual programs are integrated and tested as a complete system.

Operation and maintenance

The developed system is installed and put into use.
Errors found are corrected; improve the implementation; enhance the system when new
requirements are discovered.

The Waterfall Model

The stages are overlap and feed information to each
other.
Design stage may start when the specification is almost
complete.
Specifications are used for design and testing etc.
Specification errors can be found in design; design problems
can be detected during coding etc.

Involves a sequence of iterations of activities.

Making changes may involve repeating/revisiting
previous stages.

The Waterfall Model

PRO:
Clear-cut (defined) stages.
Design should not start if specification is not ready etc.

Each phase produces one or more documents that

must be signed-off.
It fits with other engineering process models.
Managers can view progress and react accordingly.

The Waterfall Model

CON:
Inflexible partitioning of the project into distinct
stages (i.e. one phase has to complete before moving
onto the next phase)
Commitments must be made at early stages.

Customers will not see the product until it is

complete - may contain errors.
Requirements must be stated explicitly.
Difficult to respond to changing customer requirements.

The Waterfall Model

When to use?
It is only appropriate when:
The product development starts from scratch and full-blown.
The requirements are well-understood.
Changes are fairly limited during the design process.

Few business systems have stable requirements (e.g.

government-related projects).
The waterfall model is mostly used for large systems
engineering projects (i.e. different teams work on different
modules, developed at several sites).
The plan-driven nature of the waterfall model helps coordinate the
work , thus more control and manageable process.

The Waterfall Model V-Model

A variation of the
waterfall model.
Emphasises quality
assurance actions.

Incremental Development
The idea:
1) Develop an initial implementation.
2) Expose it to users for review and comments.
3) Refining it through many versions until complete.
Concurrent
acti vities

Specification

Outline
description

Development

Validation

Initial
version

Intermedia
te
Intermediate
versions
versions

Final
version

Incremental Development
PRO:
The cost of accommodating changing customer
requirements is reduced.
The amount of analysis and documentation that has to be redone is
much less than is required with the waterfall model.

It is easier to get customer feedback on the development

work that has been done.
Customers can comment on demonstrations of the software and see
how much has been implemented.

More rapid delivery and deployment of useful software to

the customer is possible.
Customers are able to use and gain value from the software earlier
than is possible with a waterfall process.

Incremental Development
CON:
Lack of process visibility.
Too quickly means not effective to produce documents so
often - Managers normally need reports/deliverables to
measure progress.

Systems are often poorly structured.

Continual changes tends to corrupt the system structure.
Incorporating further software changes becomes
increasingly difficult and costly.

Special skills (e.g. languages for rapid prototyping)

may be required.

Incremental Development
When to use?
For small or medium-size interactive systems:
Customers feedback is important;
Increments are easier to manage.

For parts of large systems:

Critical parts of the system (which requirements are normally well
understood) may still need conventional approaches such as waterfall.
Can be used for parts which requirements are difficult to specify in
advance (e.g. the user interface).

For short-lifetime systems.

Small and homogeneous teams.

Reuse--oriented SE
Reuse

Reuse--oriented SE
Reuse
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.

Reuse is now the standard approach for building

many types of business system.

Reuse--oriented SE
Reuse
Types of software components
Web services that are developed according to service
standards and which are available for remote
invocation.
Collections of objects that are developed as a
package to be integrated with a component
framework such as .NET or J2EE.
Stand-alone software systems (COTS) that are
configured for use in a particular environment.

Coping with Change

Change is inevitable in all large software projects.
Business changes lead to new and changed system
requirements
New technologies open up new possibilities for improving
implementations
Changing platforms require application changes

Change leads to rework so the costs of change

include both rework (e.g. re-analysing requirements)
as well as the costs of implementing new
functionality.

Coping with Change

Change avoidance, where the software process includes
activities that can anticipate possible changes before
significant rework is required.
E.g. A prototype system may be developed to show some key features
of the system to customers.

Change tolerance, where the process is designed so that

changes can be accommodated at relatively low cost.
This normally involves some form of incremental development and
delivery.
Proposed changes may be implemented in increments that have not yet
been developed.
Else, then only a single increment (a small part of the system) may have
be altered to incorporate the change.

Software Prototyping
A prototype is an initial version of a system used
to demonstrate concepts and try out design
options.
A prototype can be used in:
The requirements engineering process to help with
requirements elicitation and validation;
In design processes to explore options and develop a
user interface design;
In the testing process to run back-to-back tests.

Software Prototyping
May be based on rapid prototyping languages or
tools.
May involve leaving out functionality.
Prototype should focus on areas of the product that
are not well-understood;
Error checking and recovery may not be included in
the prototype;
Focus on functional rather than non-functional
requirements such as reliability and security.

Software Prototyping
Advantages:

Improved system usability.

A closer match to users real needs.
Improved design quality.
Improved maintainability.
Reduced development effort.

Software Prototyping
Process
Establish
prototype
objecti ves

Define
prototype
functionality

Develop
prototype

Evalua te
prototype

Prototyping
plan

Outline
definition

Executa b le
prototype

Evalua tion
repor t

Software Prototyping
Throw-away prototypes
Prototypes should be discarded after development
as they are not a good basis for a production system:
It may be impossible to tune the system to meet nonfunctional requirements;
Prototypes are normally undocumented;
The prototype structure is usually degraded through rapid
change;
The prototype probably will not meet normal
organisational quality standards.

Incremental Delivery
An iterative approach of the waterfall model.
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 Delivery

increment # n
Com m un ic a t i on
Pla n ni ng
M o de li ng
a nal y s is
d es i gn

Co n s t r u c t i o n
c od e
t es t

De p l o y m e n t
de liv e ry
fe e db a c k

deliv ery of
nt h increment

increment # 2
Com mu ni c a t i on
Pla n ni ng
M o de li ng
a naly s is
d es ig n

Co n s t ru c t i o n
c ode

De p l o y m e n t

t es t

d e l i v e ry
fe e db a c k

increment # 1
Com mu ni c a t i on
Pla n ni ng
M o de li ng
a naly s is
d es ig n

Co n s t ru c t i o n
c ode

De p l o y m e n t

t es t

d e l i v e ry
fe e db a c k

deliv ery of
1st increment

project calendar t ime

delivery of
2nd increment

Incremental Delivery

Incremental Development & Delivery

Incremental development
Develop the system in increments and evaluate each increment before
proceeding to the development of the next increment;
Normal approach used in agile methods;
Evaluation done by user/customer proxy.

Incremental delivery
Deploy an increment for use by end-users;
More realistic evaluation about practical use of software;
Difficult to implement for replacement systems as increments have
less functionality than the system being replaced.

Incremental Delivery
PRO:
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.

Incremental Delivery
CON:
Increments should be relatively small (<20,000 lines of code).
Or else, problems would arise.

Each increment should deliver a functionality.

Difficult to map customer requirements into increments of the right
size.

Requirements are not defined in detail until an increment is to

be implemented.
Difficult to identify common facilities that are needed by all
increments.

The specification is developed in conjunction with the

software.
In many organisations, the complete system specification is part of
the system development contract.

Incremental Delivery
When to use?
It is particularly useful when staffing is limited/unavailable.
Early increments can be developed with fewer people.
When satisfactory, more additional staff can be added for later stages.

When certain parts of the system are under development.

Increments are planned based on the availability of the parts.

Incremental Development/Delivery
versus Prototyping
Incremental development/delivery
Aim: To work with customers and evolve a final system from an initial
outline specification.
Should start with well-understood requirements and add new features
as proposed by the customers.

Throw-away prototyping
Aim: To understand the system requirements.
Should start with poorly understood requirements to clarify what is
really needed.
Once the requirements are understood, the prototype may be thrownaway and the actual development starts.

The Boehms Spiral 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 stages 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.

Encourage people think about iteration in software processes and
introducing the risk-driven approach to development.

The Spiral Model

Determine objectives,
alternatives and constraints

Plan next phase

Evaluate alternatives,
identify, resolve risks

Develop, verify next level

product

The Spiral Model

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.

The Spiral Model

PRO:
Incorporates prototyping and iterative approach.
Software evolves as the process progresses.
Developers and customers understand better and react to risks at each
evolutionary level.

Can be adapted throughout the life cycle.

One cycle for each phase.

CON:
Difficult to convince users (in contracts) that the process is
controllable.
Require risk managers/experts to succeed.
If a major risk is not uncovered and managed, problems occur.

The Rational Unified Process

A modern generic process derived from the work on the UML
and associated process.
Brings together aspects of the 3 generic process models
discussed previously.
A use-case driven, architecture-centric, iterative and incremental software
process (Jacobson, 1999).
Recognises the importance of customer communication and role of software
architecture.

Normally described from 3 perspectives:

A dynamic perspective that shows phases over time;
A static perspective that shows process activities;
A proactive perspective that suggests good practice.

The Rational Unified Process

In-phase iteration
Each phase is iterative with results developed incrementally.

Cross-phase iteration
The whole set of phases may be enacted incrementally.

The Rational Unified Process

Inception
Establish the business case for the system.

Elaboration
Develop an understanding of the problem domain and the
system architecture.

Construction
System design, programming and testing.

Transition
Deploy the system in its operating environment.

The Rational Unified Process

Good Practice:
Develop software iteratively
Plan increments based on customer priorities and deliver
highest priority increments first.

Manage requirements
Explicitly document customer requirements and keep track
of changes to these requirements.

Use component-based architectures

Organise the system architecture as a set of reusable
components.

The Rational Unified Process

Good Practice:
Visually model software
Use graphical UML models to present static and dynamic
views of the software.

Verify software quality

Ensure that the software meets organizational quality
standards.

Control changes to software

Manage software changes using a change management
system and configuration management tools.

Formal Methods
A set of activities that leads to formal mathematical
specification of software.
It enables engineers to specify, develop and verify a
software by applying a rigorous, mathematical
notation e.g. VDM, Z, B.
Ambiguity, incompleteness and inconsistency can be
discovered and corrected through mathematical
analysis.

Formal Methods
Example: B Method

OPERATIONS

INVARIANT
placeBid(uu,aa,bb) =
PRE uu : USER & aa : AUCTION & bb : NAT1
auction : POW(AUCTION) &
THEN
registered : POW(USER) &
SELECT
reserve : auction --> NAT1 &
aa : auction &
highest_bid : auction --> NAT &
aa : dom(highest_bidder) &
seller : auction --> registered &
uu /= seller(aa) &
uu /= highest_bidder(aa) &
highest_bidder : auction +-> registered &
bb > highest_bid(aa) &
balance : registered --> NAT &
bb <= balance(uu) &
name : registered >-> STRINGS &
auction_state(aa) = bidding &
password : registered --> STRINGS &
user_state(uu) = loggedIn
admin_amount : NAT &
THEN
highest_bidder(aa) := uu ||
auction_state : auction --> AUCTION_STATE &
highest_bid(aa) := bb ||
user_state : registered --> USER_STATE &
balance := balance <+ {uu |-> balance(uu) !(aa).(aa : auction => (seller(aa) /= highest_bidder(aa) ))
bid , highest_bidder(aa) |->
balance(highest_bidder(aa)) +
highest_bid(aa)}
END
END
;

Formal Methods
PRO:
Offers the promise of defect-free software.
CON:
The development of formal models is currently quite
time consuming.
Extensive training is required before applying the
method.
Difficult to use the models as a communication
mechanism for non-technical end users.

THANK YOU
Question?
Next :
Software Process Activities