Software Processes
Russell Lock
1
Topics covered
Feasibility Studies
Software process models
Process activities
Coping with change
Background Reading
Chapter 2 of the course textbook
Feasibility Studies
Feasibility study overview
A feasibility study decides whether or not the
proposed system is worthwhile. (go/no go)
Determines obvious constraints, facts and
assumptions
A short focused study that checks
Contribution
Engineering & Budget
Integration
Feasibility study implementation
Produces a short report
Explores the risks associated with a potential project
Independently produced if at all possible
Potential questions for people in the organisation
What if the system wasn’t implemented?
What are current process problems?
How will the proposed system help?
What will be the integration problems?
Is new technology needed? What skills?
What facilities must be supported by the proposed system?
Should not get bogged down in implementation
details
The software process
6
The software process
A structured set of activities
Many different software processes but all
involve:
Specification
Design and implementation
Validation
Evolution
A software process model is an abstract
representation of a process.
7
Plan-driven and Agile processes
Plan-driven vs Agile
In practice, most practical processes include
elements of both plan-driven and agile
approaches.
No right, no wrong, just context and
environment
8
Plan-Driven Software process models
9
Plan-Driven Software process models
The waterfall model
Plan-driven model. Separate and distinct phases of
specification and development.
V Model
Plan-driven. Waterfall with added emphasis on testing
Iterative Development
May be plan-driven or agile
Incremental development
May be plan-driven or agile.
Integration and configuration
The system is assembled from existing configurable
components. May be plan-driven or agile.
In practice, most large systems are developed using a
process that incorporates elements from all of these
models.
10
The waterfall model
11
Waterfall model phases
There are separate identified phases in the
waterfall model:
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
Signoff mechanism for stages
12
Waterfall model problems
Inflexible partitioning (affects modification)
Appropriate when the requirements are well-
understood and changes are limited
Few business systems have truly stable
requirements.
Mostly used for large systems engineering
projects where a system is developed at
several sites.
Plan driven makes large-scale coordination
easier.
13
V-Model of development)
Wikipedia commons: Image is within
the public domain and is not subject to
copyright
V-Model Advantages & disadvantages
Advantages
Helps ensure legitimacy of testing (leading to
higher chance of success than waterfall)
Disadvantages
Changes to specification midway require
changes to past phases (same as waterfall)
and testing documentation
15
Incremental development
Develop system in parts, each part providing
some useful function to the customer
Could be imagined as multiple mini waterfalls
if plan driven
16
Incremental Advantages &
Disadvantages
Advantages
Reduced cost of change for future increments
Debugging easier for each increment
Easier to get ongoing feedback.
Rapid delivery and deployment possible.
Customers are able to use and gain value from the
software earlier than is possible with a waterfall
process.
Disadvantages
Increased cost of change for past increments
Inevitably more complex for management
Costs will be higher
17
Iterative Development
Works from a high level design
Builds parts of the system iteratively
Could include developing some parts multiple times to
improve them
Can be used within phases of a rigid system such as
waterfall (but not across them…)
Common for HCI design
Sourced from:
[Link]
uk/2015/11/you-cannot-
iterate-upon-
[Link]
18
Iterative Advantages and
Disadvantages
Advantages
Good for prototyping risky or badly understood
functionality
Potential for ongoing feedback
Disadvantages
More flexible than the waterfall model, but still rigid
between iterations
Expensive if system was well understood
It is not cost-effective to produce documents that
reflect every version of the system.
System structure can degrade
Structure can become impenetrable
and chaotic
19
Building iteration into existing models
Waterfall
Iterate within a given stage. Common for
requirements, and HCI design
V-Model
Effectively prevents prototyping by largescale
iteration due to the more fine detailed nature
of the model
20
Integration and configuration
Based on software reuse where systems are
integrated from existing components or
application systems (COTS Commercial-off-
the-shelf systems).
Reused elements are configured / adapted
Reuse is now very common
Sharepoint, SAP solutions etc are all COTS
21
Types of reusable software
Stand-alone application systems (sometimes
called COTS) that are configured for use in a
particular environment.
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.
22
Reuse-oriented software engineering
No need to draw diagram for exam
23
Key process stages for reuse
Requirements specification
Software discovery and evaluation
Requirements refinement
Application system configuration
or
Component adaptation and integration
24
Advantages and disadvantages
Reduced costs and risks as less software is
developed from scratch
Faster delivery and deployment of system
But requirements compromises are inevitable
so system may not meet real needs of users
Loss of control over evolution of reused
system elements
25
Generic process activities
26
Process activities
Real software processes are:
Inter-leaved sequences of technical,
collaborative and managerial activities
The four basic process activities of
specification, development, validation and
evolution are organized differently in
different development processes.
For example, in the waterfall model, they are
organized in sequence, whereas in
incremental development they are
interleaved.
27
Software specification
Establishing services required and constraints on the
system’s operation and development.
Requirements engineering process (not necessarily
sequential)
Requirements elicitation and analysis
What do the system stakeholders require or expect from
the system?
Requirements specification
Defining the requirements in detail
Requirements validation
Checking the validity of the requirements
Produces descriptions, requirement documentation
28
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;
Closely related activities, may be inter-
leaved.
29
Common design activities
Architectural design
Database design
Interface design
Component selection and design
30
System implementation
Implemented or configured?
Often interleaved with design
Programming is an individual activity with no standard
process.
In industry debugging is a more robust and key process
1. Identify bug
2. Find code
3. Analyze code
4. Prove cause
5. Gather unit tests
6. Fix code
7. Run tests
31
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 derived from real data.
Testing is the most commonly used V & V
activity.
32
Testing stages
Component 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.
Customer testing
Testing with customer data to check that the
system meets the customer’s needs.
33
Software evolution
The world changes => Software changes
Software should be inherently flexible and
support change.
COBOL
Although there has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer
systems are completely new.
34
System evolution
35
Coping with change during projects
36
Coping with change
Change is inevitable
Business changes lead to new and changed
system requirements
New technologies, Changing platforms etc
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
37
Reducing the costs of rework
Change can be anticipated
For example, a prototype system may be
developed to show some key features of the
system to customers.
Prototyping and Incremental developments
are more change tolerant
38
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 UI design;
Range from Low Fidelity to High
39
Benefits of prototyping
Improved system usability
A closer match to users’ real needs
Improved design quality
Improved maintainability
Reduced development effort
So, what do you think the disadvantages are?
40
Prototype development
May be based on rapid prototyping languages
or tools
May involve leaving out functionality….
We prototype for a reason!
Error checking and recovery may not be
included in the prototype;
Focus on functional rather than non-functional
requirements such as reliability and security
41
Throw-away prototypes
Prototypes should be discarded after
development as they are not a good basis for
a production system:
42
Throw-away prototypes
It may be impossible to tune the system to
meet non-functional requirements;
Prototypes are normally undocumented;
The prototype structure is usually degraded
through rapid change;
The prototype probably will not meet normal
organisational quality standards.
43
Key points
Feasibility studies are a potential way of
reducing project risks
There are many approaches to software
development
Use depends on project context
Change and evolution have to be planned for
44
