What is a software process?

 A structured set of activities required to develop a

software system.
 Many different software processes but all involve:
 Specification – defining what the system should do;
 Design and implementation – defining the organization of the
system and implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing
customer needs.
 A software process model is an abstract representation of
a process. It presents a description of a process from
some particular perspective.
1
Plan-driven and agile processes

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.

2
Software process models

 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.
 etc: to be treated in more details later
 In practice, most large systems are developed using a
process that incorporates elements from all of these
models.

3
- In any software development project, we have the
Client, Developer, and User.

- Development activities vary from one organization to

another, but broadly speaking they cover:
* Development – All phases of software production
* Maintenance – Revisiting the developed software

- Phases of software life-cycle:

1. Requirement and Test
2. Specification and Test
3. Design and Test
4. Implementation and Test
5. Integration and Test
6. Maintenance and Test
7. Retirement
4
1 (a) Requirements:
* The client approaches the developer and presents
the problem
* After meeting between the client and the
developer, then the developer:
- determines exactly what the client wants
- finds out constraints (deadline, cost, reliability,
security, etc).
- these include the functional and non-functional
requirements
* In subsequent meetings, functionalities are
refined and analyzed in terms of feasibility
(called systems analysis)

5
1 (b) Requirements Test:
* Use of Rapid Prototype – a piece of
software hurriedly designed which
contains most functionality, but omits
aspects invisible to users (e.g. file
format, error handling, etc)
* The client experiments with this, reports
observations, then refined by the
developer, ………, until satisfied.

6
2(a) Specification:
* When the user is satisfied with the requirement,
the developer draws out the specification
document – WHAT to do
* Specification spells out:
- Functionality; precisely what the system
suppose to do
- Constraints to be satisfied
- Input/output (reports)
* Specification represents the contract

7
2(b) Specification Test:
* SQA group is responsible for ensuring that the
delivered product is what the client ordered

* SQA usually carries out Verification & Validation

(V & V) procedures
-Verification: are we developing the system right?
(must conform to specification)
-Validation: are we developing the right system?
(do what the user requires)

* Therefore the SQA group meets with the client’s

representative and the requirement team and
review the specification to ensure correctness of
the specification.
8
3 (a) Design:
* A major step towards achieving what is in the
specification
* Determines the internal structure of the product
* Selection of Algorithm + Data Structures is made
here
* Determines internal data flow
* Breaks down the product into
modules/subsystems;
independent pieces of codes with well defined
interfaces.

9
* Coupling: the strength of dependencies between two
subsystems.
* If two subsystems are loosely coupled, they are
relatively independent, and thus, modifications to
one of subsystems will have little impact on the other.
* If two subsystems are strongly coupled, modifications
to one subsystem are likely to have impact on
the other
* Desirable property of subsystem decomposition: keep
subsystems as loosely coupled as possible
- This minimizes the impact that errors or future
changes have on the correct operation of the
system.
10
* Coherence: the strength of dependencies within
a
subsystem
* Desirable property of subsystem decomposition
is
that it leads to subsystems with high coherence.

11
* The interfaces (signature of functions -
parameters passed and function names - and
values returned by the modules) must be specified
in details.
* Design is two-fold:
1) Architectural Design: description of the
modules as a whole (subsystem)
2) Detailed Design: description of each
module;
which is handed over to the programmer

12
3 (b) Design Test:
* SQA group + Design Team only – no need of
client
* They subject the design to reviews; every part of
the design should link to a statement in the
specification

13
4 (a) Implementation
* Code the various subsystems – by programmers
* Major document here is the source codes, well
commented
* Remember Structured Programming Concept!

14
4 (b) Implementation Test
* Each subsystem is debugged in the process of
development by the programmers
* Tested with test data – by the programmer
* Tested with test data thereafter (by other
programmers) – to reveal more errors
* Then reviewed (in order to detect faults); the
programmer only guides the review team, which
must
include SQA member.

15
5 (a) Integration
* Put the subsystems together to see whether the
product as a whole functions correctly
* Could be all at once or one at a time
– illustration required
* Could be Top-down or Bottom-up
– illustration required
* Stubs and Drivers required, all being dummies – to
be discarded at the end

16
5 (b) (i) Integration Test
* Great care must be placed on testing the
interfaces
(received parameters and returned values)
* Performed by the Linkers and the SQA group
5 (b) (ii) Product Test
* Performed by the SQA group (after integration
test) to check the functionality as a whole against
specification
5 (b) (iii) Acceptance Test
* Final Test, Performed by client
* Software is given to the client
- to test on real environment
- using actual data (as opposed to test data)
* If okayed, the software is delivered to the client.
17
6 (a) Maintenance
* Regarded as an integral part of software life
cycle
* Once the software product is accepted by the
client,
any changes would constitute maintenance,
after the warranty period.

6 (b) Maintenance Test

Two-fold:
1) No unwanted changes are incorporated
2) All required changes are made correctly

18
7 Retirement
* When any further maintenance is not cost-effective,
e.g.,
- The proposed changes in requirement is so
drastic that the design itself changes
- There are changes in the hardware, with new OS
such that the cost of developing new system is
cheaper than maintaining existing one.
- e.t.c.

19
Software Lifecycle
* A Period within which a software is effective and
yielding required results
* With time,
- The # of transactions increase
- # of users increase
- Complexity of data processing multiplies
- Technology improves
* Hence, the system may become obsolete; and, the
need for a new improved system

20
Software Lifecycle – cont’d
The traditional methods of software development were
mainly characterized by:

* Wrong, incomplete and unstable

functional/system requirements;
* Unspecified design strategies;
* Incorrect implementation;
* Poor testing plan;
* Inadequate (but expensive) maintenance
strategies;
* Complex documentation.

21
Software Lifecycle – cont’d
The above mentioned downsides led to the introduction
of software development process which ensures:
* The management of software lifecycle (consisting
of phases).
* What phases are required during system
development?
* The order of the phases.
* What happens in each phase?
* The outcome of each phase.

This,however, brought about the emergence of various

software development models.
22
Software Lifecycle Models
A software lifecycle model is a standardized format
for:
planning

organizing, and
running

a new development project.

23
 Hundreds of different kinds of models are known
and used.
 Many are minor variations on just a small number
of basic models.

We are going to:

 Survey the main types of model, and
 Consider how to choose between them, by
stating their advantages and disadvantages.

24
Project planning is the art of scheduling
the necessary activities, in time and across staff
in order to optimize:

•project risk [low]

•profit [high]

•customer satisfaction [high]

•worker satisfaction [high]

•long-term company goals

25
 A project plan contains much information, but must
at least describe:

•resources needed (people, money, equipment, etc)

•dependency & timing of work (flow graph, work

packages)

•Rate of delivery(reports, code, etc)

It is impossible to measure rate of progress except

with reference to a plan.

26
Project Visibility
Unlike other engineers (e.g. civil, electronic,
chemical… etc.) software engineers do not produce
anything physical.
It is inherently difficult to monitor an SE project
due to lack of visibility.

27
This means that SE projects must produce
additional deliverables (artifacts) which are visible,
such as:

•Design documents/ prototypes

•Reports

•Project/status meetings

•Client surveys(e.g. satisfaction level)

28
What is a Lifecycle Model?
Definition: A (software/system) lifecycle model is a
description of the sequence of activities carried out in
an SE project, and the relative order of these
activities.
It provides a fixed generic framework that can be
tailored to a specific project. Project specific
parameters will include:

1. Size (person-years) 2. Budget 3. Duration.

project plan = lifecycle model + project

parameters
29
 There are hundreds of different lifecycle models
to choose from, e.g:
•waterfall
•code-and-fix
•spiral
•rapid prototyping
•agile methods, extreme programming (XP)
•COTS …
•fountain

 but many are minor variations on a smaller

number of basic models.

30
By changing the lifecycle model, we can improve
and/or tradeoff:
Development speed (time to market)
Product quality
Project visibility
Administrative overhead
Risk exposure
Customer relations, etc, etc.

31
 Note that we can sometimes combine lifecycle
models,

e.g. COTS and waterfall

 We can also change lifecycle model between

releases as a product matures,

e.g. rapid prototyping →waterfall

32
The Waterfall Model
The waterfall model is the classic lifecycle model–
it is widely known, understood and (commonly?)
used.
In some respect, waterfall is the ”commonsense”
approach.
Introduced by Royce 1970.

33
 Changed

Requirement

Verify

Requirement

Verify

Specification

Verify

KEY Design

Development Verify

Maintenance Implmentatn

Test

Integration

Test

Operation

Waterfall Model

34
Advantages

1. Easy to understand and implement.

2. Widely used and known (in theory!)

3. Reinforces good habits: define-before-design,

design-before-code

4. Identifies deliverables and milestones

5. Document driven, Published documentation

standards

6. Works well on mature products and weak teams.

35
Disadvantages

1. Idealized, doesn’t match reality well.

2. Doesn’t reflect iterative nature of exploratory development.

3. Unrealistic to expect accurate requirements so early in project

4. Software is delivered late in project, delays discovery of

serious errors.

5. Difficult to integrate risk management

6. Difficult and expensive to make changes to documents

7. Significant administrative overhead, costly for small teams and

projects.

36
Code-and-Fix
This model starts with an informal general product
idea and just develops code until a product is
”ready” (or money or time runs out).
Work is in random order.
Corresponds with no plan!

37
Advantages
1. No administrative overhead
2. Signs of progress (code) early.
3. Low expertise, anyone can use it!
4. Useful for small “proof of concept” projects, e.g. as part
of risk reduction.
Disadvantages
1.Dangerous!
 No visibility/control
 No resource planning
 No deadlines
 Mistakes hard to detect/correct
2. Impossible for large projects, communication breakdown,
chaos.

38
Spiral Model
Since end-user requirements are hard to obtain/
define, it is natural to develop software in an
experimental way: e.g.

1. Build some software

2. See if it meets customer requirements

3. If no goto 1 else stop.

39
 This loop approach gives rise to structured
iterative lifecycle models.
 In 1988 Boehm developed the spiral model as an

iterative model which includes

risk analysis/management.
 Key idea: on each iteration identify and solve
the sub-problems with the highest risk.

40
41
Boehm’s Spiral Model

42
Each cycle follows a waterfall model by:

1. Determining objectives

2. Specifying constraints

3. Generating alternatives

4. Identifying risks

5. Resolving risks

6. Developing next-level product

7. Planning next cycle

43
Advantages
1. Realism: the model accurately reflects the iterative nature
of software development on projects with unclear
requirements
2. Flexible: incorporates the advantages of the waterfall and
rapid prototyping methods
3. Comprehensive model decreases risk
4. Good project visibility.

Disadvantages
1. Needs technical expertise in risk analysis to really work
2. Model is poorly understood by non-technical management,
hence not so widely used
3. Complicated model, needs competent professional
management. High administrative overhead.

44
Rapid Prototyping
Key idea: Customers are non-technical and usually
don’t know what they want/can have.

Rapid prototyping emphasizes requirements

analysis and validation, also called:

•customer oriented development

•evolutionary prototyping

45
46
Advantages
1.Reduces risk of incorrect user requirements
2.Good where requirements are changing/uncommitted
3.Regular visible progress aids management
4.Supports early product marketing

Disadvantages
1.An unstable/badly implemented prototype often becomes the
final product.
2.Requires extensive customer collaboration
–Costs customers money
–Needs committed customers
–Difficult to finish if customer withdraws
–May be too customer specific, no broad market
3.Difficult to know how long project will last
4.Easy to fall back into code-and-fix without proper
requirements analysis, design, customer evaluation and
feedback. 47
Agile (XP) Programming
XP = Extreme Programming emphasizes:
•Individuals and interactions – Over processes and tools
•Working software – Over documentation
•Customer collaboration – Over contract negotiation
•Responding to change – Over following a plan

Agile Principles (Summary)

•Continuous delivery of software
•Continuous collaboration with customer
•Continuous update according to changes
•Value participants and their interaction
•Simplicity in code, satisfy the specification

48
XP Practices (Summary)

•Programming in pairs

•Test driven development

•Continuous planning, change, delivery

•No overtime!

49
Advantages
•Lightweight methods suit small-medium size projects
•Produces good team cohesion
•Emphasizes final product
•Iterative (due to constant consideration for change)
•Test based approach to requirements and quality assurance

Disadvantages
•Difficult to scale up to large projects where documentation is
essential
•Needs experience and skill if not to degenerate into code-
and-fix
•Programming pairs is costly
•Test case construction is a difficult and specialized skill.

50
COTS = Commercial Off-The-Shelf software
Engineer to gather a solution from existing commercial
software packages using minimal software ”glue”.
E.g. using databases, spread sheets, word processors,
graphics software, web browsers, etc.

Advantages
•Fast, cheap solution
•May give all the basic functionality
•Well defined project, easy to run

Disadvantages
•Limited functionality
•Licensing problems, etc.
•License fees, maintenance fees, upgrade compatibility
problems
51
 Fountain Model
Specifically useful for object-
oriented system development; Each
phase is regarded as a complete
entity (to be analyzed, designed,
and implemented separately from
other phases).
Phases overlap – ensuring
parallelism of development
process.

Main disadvantage of this model is

unclear development process; since
it requires “code-a-bit, test-a-bit”
[CABTAB] principle.

Fountain Model
52
 Good practice guidelines for dependable
programming (Dependability Engineering)
Dependable programming guidelines

1. Limit the visibility of information in a program

2. Check all inputs for validity
3. Provide a handler for all exceptions
4. Minimize the use of error-prone constructs
5. Provide restart capabilities
6. Check array bounds
7. Include timeouts when calling external components
8. Name all constants that represent real-world values

53
Exception handling

54
Error-prone constructs
 Parallelism
 Can result in subtle timing errors because of unforeseen
interaction between parallel processes.
 Recursion
 Errors in recursion can cause memory overflow as the
program stack fills up.
 Interrupts
 Interrupts can cause a critical operation to be terminated
and make a program difficult to understand.
 Inheritance
 Code is not localised. This can result in unexpected behaviour when changes
are made and problems of understanding the code.

55
Error-prone constructs
 Aliasing
 Using more than 1 name to refer to the same
state variable.
 Unbounded arrays
 Bufferoverflow failures can occur if no bound
checking on arrays.
 Default input processing
 An input action that occurs irrespective of the
input.
 This can cause problems if the default action
is to transfer control elsewhere in the
program. In incorrect or deliberately malicious
56 input can then trigger a program failure.