Software

Process

SOFWARE PROCESS 1
Topics
Process models
Waterfall
Prototype
Incremental/iterative/ evolutionary
Spiral
RUP
Process activities

SOFWARE PROCESS 2
Software Engineering
We have specified the problem domain – industrial strength software
◦ Besides delivering the software, cost, quality, and schedule are drivers

Software engineering is defined as the systematic approach for

development of (industrial strength) software

SOFWARE PROCESS 3
Process, People,
Technology
Q&P is an essential goal
Q&P depends on people, process, and technology
◦ Processes help people become more productive and create fewer errors
◦ Tools help people execute some tasks in the process more efficiently and
effectively
◦ So, process forms the core

SOFWARE PROCESS 4
Software Process
Process is distinct from product – products are outcomes of executing a
process on a project
SW Engg. focuses on process
Premise: Proper processes will help achieve project objectives of high
QP

SOFWARE PROCESS 5
The software
Development Problem

SOFWARE PROCESS 6
Project and Process
A software project is one instance of the development problem
Development process takes the project from user needs to software
There are other goals of cost schedule and quality, besides delivering
software
Need other processes

SOFWARE PROCESS 7
Software Process…
Process: A sequence of steps performed to achieve
some goal
Software Process: The sequence of steps
performed to produce software with high quality,
within budget and schedule
Many types of activities performed by diff people in
a software project
Better to view software process as comprising of
many component processes

SOFWARE PROCESS 8
Component Software
Processes
Two major processes
◦ Development – focuses on development and quality
steps needed to engineer the software
◦ Project management – focuses on planning and
controlling the development process
Development process is the heart of software
process; other processes revolve around it
These are executed by different people
◦ developers execute engg. Process
◦ project manager executes the mgmt proces

SOFWARE PROCESS 9
Component
Processes…
Other processes
◦ Configuration management process: manages the evolution of artifacts
◦ Change management process: how changes are incorporated
◦ Process management process: management of processes themselves
◦ Inspection process: How inspections are conducted on artifacts

SOFWARE PROCESS 10
Process Specification
Process is generally a set of phases
Each phase performs a well defined task and generally produces an output
Intermediate outputs – work products
At top level, typically few phases in a process
How to perform a particular phase – methodologies have been proposed

SOFWARE PROCESS 11
ETVX Specification
ETVX approach to specify a step
◦ Entry criteria: what conditions must be satisfied for initiating this phase
◦ Task: what is to be done in this phase
◦ Verification: the checks done on the outputs of this phase
◦ eXit criteria: when can this phase be considered done successfully

A phase also produces info for mgmt

SOFWARE PROCESS 12
ETVX approach

SOFWARE PROCESS 13
Development
Process and
Process
Models

SOFWARE PROCESS 14
Software Project
Project – to build a sw system within cost and schedule and with high
quality which satisfies the customer
Suitable process needed to reach goals
Process should not just help produce the software but help achieve the
highest Q&P

SOFWARE PROCESS 15
Project’ s process and
Process Models
For a project, the project’s process to be followed is specified during
planning
A process model specifies a general process that is optimal for a class of
problems
A project may select its process using one of the process models

SOFWARE PROCESS 16
Development Process
A set of phases and each phase being a sequence
of steps
Sequence of steps for a phase - methodologies for
that phase.
Why have phases
◦ To employ divide and conquer
◦ each phase handles a different part of the problem
◦ helps in continuous validation

SOFWARE PROCESS 17
Development Process
Commonly has these activities: Requirements analysis, architecture,
design, coding, testing, delivery
Different models perform them in different manner

SOFWARE PROCESS 18
Process Models
A process model specifies a general process, usually as a set of stages
This model will be suitable for a class of projects
I.e. a model provides generic structure of the process that can be
followed by some projects to achieve their goals

SOFWARE PROCESS 19
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.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 20

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.

In practice, most large systems are developed using a process that

incorporates elements from all of these models.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 21

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

The main drawback of the waterfall model is the difficulty of

accommodating change after the process is underway. In principle, a
phase has to be complete before moving onto the next phase.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 22

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.
◦ In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 23

Waterfall Model
Linear sequence of stages/phases
Requirements – HLD – DD – Code – Test – Deploy
A phase starts only when the previous has completed; no feedback
The phases partition the project, each addressing a separate concern

SOFWARE PROCESS 24
SOFWARE PROCESS 25
Waterfall…
Linear ordering implies each phase should have some output
The output must be validated/certified
Outputs of earlier phases: work products
Common outputs of a waterfall: SRS, project plan, design docs, test plan and
reports, final code, supporting docs

SOFWARE PROCESS 26
Waterfall Advantages
Conceptually simple, cleanly divides the problem into distinct phases
that can be performed independently
Natural approach for problem solving
Easy to administer in a contractual setup – each phase is a milestone

SOFWARE PROCESS 27
Waterfall
disadvantages
Assumes that requirements can be specified and frozen early
May fix hardware and other technologies too early
Follows the “big bang” approach – all or nothing delivery; too risky
Very document oriented, requiring docs at the end of each phase

SOFWARE PROCESS 28
Waterfall Usage
Has been used widely
Well suited for projects where requirements can be understood easily
and technology decisions are easy
I.e. for familiar type of projects it still may be the most optimum

SOFWARE PROCESS 29
Coping with changing
requirements
System prototyping, where a version of the system or part of the
system is developed quickly to check the customer’s requirements and
the feasibility of design decisions. This approach supports change
anticipation.
Incremental delivery, where system increments are delivered to the
customer for comment and experimentation. This supports both
change avoidance and change tolerance.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 30

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;
◦ In the testing process to run back-to-back tests.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 31

Benefits of prototyping
Improved system usability.
A closer match to users’ real needs.
Improved design quality.
Improved maintainability.
Reduced development effort.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 32

The process of prototype
development

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 33

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

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 34

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

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 35

Prototyping
Prototyping addresses the requirement specification limitation of
waterfall
Instead of freezing requirements only by discussions, a prototype is
built to understand the requirements
Helps alleviate the requirements risk
A small waterfall model replaces the requirements stage

SOFWARE PROCESS 36
Prototyping

SOFWARE PROCESS 37
Prototyping
Development of prototype
◦ Starts with initial requirements
◦ Only key features which need better understanding are included in
prototype
◦ No point in including those features that are well understood
◦ Feedback from users taken to improve the understanding of the
requirements

SOFWARE PROCESS 38
Prototyping
Cost can be kept low
◦ Build only features needing clarification
◦ “quick and dirty” – quality not important, scripting etc can be used
◦ Things like exception handling, recovery, standards are omitted
◦ Cost can be a few % of the total
◦ Learning in prototype building will help in building, besides improved
requirements

SOFWARE PROCESS 39
Prototyping
Advantages: req will be more stable, req frozen later, experience helps
in the main development
Disadvantages: Potential hit on cost and schedule
Applicability: When req are hard to elicit and confidence in reqs is low;
i.e. where reqs are not well understood

SOFWARE PROCESS 40
41
Iterative/Incremental
Development
Counters the “all or nothing” drawback of the
waterfall model
Combines benefit of prototyping and waterfall
Develop and deliver software in increments
Each increment is complete in itself
Can be viewed as a sequence of waterfalls
Feedback from one iteration is used in the future
iterations

SOFWARE PROCESS 42
Iterative Enhancement

SOFWARE PROCESS 43
Iterative Development
Products almost always follow it
Used commonly in customized development also
◦ Businesses want quick response for sw
◦ Cannot afford the risk of all-or-nothing

Newer approaches like XP, Agile,… all rely on iterative development

SOFWARE PROCESS 44
Iterative Development
Benefits: Get-as-you-pay, feedback for improvement,
Drawbacks: Architecture/design may not be optimal, rework may
increase, total cost may be more
Applicability: where response time is important, risk of long projects
cannot be taken, all req not known

SOFWARE PROCESS 45
Incremental
development

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 46

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

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 47

Incremental
development problems
The process is not visible.
◦ Managers need regular deliverables to measure progress. If systems are
developed quickly, it is not cost-effective to produce documents that reflect
every version of the system.

System structure tends to degrade as new increments are added.

◦ Unless time and money is spent on refactoring to improve the software,
regular change tends to corrupt its structure. Incorporating further software
changes becomes increasingly difficult and costly.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 48

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.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 49

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

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 50

Incremental delivery

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 51

Incremental delivery
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.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 52

 Incremental delivery
problems
◦ Most systems require a set of basic facilities that are used by different parts of the
system. until an increment is to be implemented, it can be hard to identify common
facilities that are needed by all increments.

The essence of iterative processes is that the specification is developed in

conjunction with the software.

◦ As requirements are not defined in detail However, this conflicts with the
procurement model of many organizations, where the complete system
specification is part of the system development contract.

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 53

PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 54
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 55
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 56
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 57
RUP Model
Rational Unified Process is another iterative model
Software development is divided into cycles, each
cycle delivering a fully working system
Each cycle executed as separate project
Execution of a cycle is broken into four consecutive
phases, each phase ending with a milestone
achievement

SOFWARE PROCESS 58
Phases in a Project
Phases in a project
◦ Inception phase: ends with Lifecycle Objectives milestone;
vision and high level capability of system defined
◦ Elaboration phase: Lifecycle architecture milestone; most
requirements defined and architecture designed
◦ Construction phase: Initial operational capability
milestone
◦ Transition phase: Product release; transition product
from development to production

SOFWARE PROCESS 59
Phases and Milestones

SOFWARE PROCESS 60
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 61
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 62
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 63
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 64
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 65
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 66
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 67
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 68
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 69
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 70
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 71
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 72
PSE 101 SOFTWARE ENGINEERING AND CONCEPTS 73
Execution of phases
Each phase itself can be done in multiple iterations, each iteration
having an external/internal customer
Generally construction has multiple iterations; elaboration can also be
meaningfully done in multiple iterations

SOFWARE PROCESS 74
Core workflows and
phases
Engineering tasks are called core process workflows
These sub processes correspond to tasks of requirements, design,
implementation, testing, proj mgmt, etc
Many sub processes may be active in a phase, the volume of activity
generally differs depending on the project

SOFWARE PROCESS 75
Sub processes and
phases

SOFWARE PROCESS 76
RUP
Sub processes are active in all phases
Volume of activity in each phase differs depending
on the project
Hence, a project can use RUP to implement
waterfall by having requirements process be active
only in the elaboration phase
Or prototyping by having a lot of construction
activity in the elaboration phase
RUP is therefore a flexible framework

SOFWARE PROCESS 77