Software Process and Models

Chifundo Polska Mlangeni

Sofware Process 1
Software Process and Models
◼ 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 Q&P

Sofware Process 2
Software Process…
◼ Process: A particular method, generally
involving a number of steps
◼ Software Process: A set of steps, along with
ordering constraints on execution, to produce
software with desired outcome
◼ 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 3
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 4
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 5
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 6
Summary so far
◼ Process – method for doing something
◼ Process typically has stages, each stage
focusing on an identifiable task
◼ Stages have methodologies
◼ Software process is the methods for
developing software
◼ Best to view it as comprising of multiple
processes
Sofware Process 7
Summary so far
◼ Goal is to produce software with high
quality and productivity
◼ Process is the means
◼ Development process is central process
◼ Mgmt process is for controlling dev
◼ Other supporting processes
◼ Sw process should have high Q&P, and
support for change
Sofware Process 8
Development Process and
Process Models

Sofware Process 9
Software Project
◼ Project – to build a sw system within
cost and schedule and with high quality
which satisfies the customer
◼ Project goals – high Q and high P
◼ Suitable process needed to reach goals
◼ For a project, the process to be
followed is specified during planning

Sofware Process 10
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 11
Development Process
◼ Commonly has these activities:
Requirement analysis, architecture,
design, coding, testing, delivery
◼ Different models perform them in
different manner

Sofware Process 12
Requirement Analysis

◼ To understand state the problem precisely

◼ Forms the basis of agreement between user
and developer
◼ specifies “ what “ , not “ how “.
◼ Not an easy task, as needs often understood.
◼ Requirement specifications of even medium
systems can be many hundreds of pages
◼ Output is the sw req spec (SRS) document

Sofware Process 13
Design

◼ A major step in moving from problem domain

to solution domain; three main tasks
◼ Architecture design – components and connectors
that should be there in the system
◼ High level design – modules and data structures
needed to implement the architecture
◼ Detailed design – logic of modules
◼ Most methodologies focus on architecture or
high level design
◼ Outputs are arch/des/logic design docs
Sofware Process 14
 Coding
◼ Converts design into code in specific language
◼ Goal: Implement the design with simple and
easy to understand code.
◼ Code should be simple and readable.
◼ The coding phase affects both testing and
maintenance. Well written code can reduce
the testing and maintenance effort.
◼ Output is code

Sofware Process 15
Testing
◼ Defects are introduced in each phase
◼ They have to be found and removed to
achieve high quality
◼ Testing plays this important role
◼ Goal: Identify most of defects
◼ Is a very expensive task; has to be properly
planned and executed.
◼ Outputs are Test plans/results, and the final
tested (hopefully reliable) code
Sofware Process 16
Effort Distribution
◼ Distribution of effort :
◼ Req. - 10-20%
◼ Design - 10-20%
◼ Coding - 20-30%
◼ Testing - 30-50%
◼ Coding is not the most expensive.

Sofware Process 17
Distribution of effort…

◼ How programmers spend their time

◼ Writing programs - 13%
◼ Reading programs and manuals - 16%
◼ Job communication - 32%
◼ Others - 39%
◼ Programmers spend more time in reading
programs than in writing them.
◼ Writing programs is a small part of their
lives.
Sofware Process 18
 Defects
◼ Distribution of error occurrences by phase is
◼ Req. - 20%
◼ Design - 30%
◼ Coding - 50%
◼ Defects can be injected at any of the major
phases.
◼ Cost of latency: Cost of defect removal
increases exponentially with latency time.
◼ Latency is a time interval between the
injection and detection of errors
Sofware Process 19
Defects…

Cost to fix
Error ( log scale)

Time

◼ Cheapest way to detect and remove defects

close to where it is injected.
◼ Hence must check for defects after every
phase.

Sofware Process 20
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 21
Projects Process
◼ If a project chooses a model, it will generally tailor it
to suit the project
◼ This produces the spec for the projects process
◼ This process can then be followed in the project
◼ I.e. process is what is actually executed; process
spec is plan about what should be executed; process
model is a generic process spec
◼ Many models have been proposed for the
development process

Sofware Process 22
Typical Student Process Model
◼ Get problem stmt – Code – do some
testing – deliver/demo
◼ Why this process model cannot be used
for commercial projects?
◼ Produces student-software, which is not
what we are after
◼ Cannot ensure desired quality for
industrial-strength software
Sofware Process 23
Common Process Models
◼ Waterfall – the oldest and widely used
◼ Prototyping
◼ Iterative/Incremental Model
◼ currently used widely
◼ RUP
◼ Timeboxing
◼ Boehm’s Spiral Model
Sofware Process 24
Waterfall Model
◼ Linear sequence of stages/phases
◼ Feasibility-Requirements – Design–
Implementation – 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 25
Waterfall Model

Sofware Process 26
Improved Waterfall Model

27
 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 28
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 29
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 30
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 31
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 32
Prototyping

Sofware Process 33
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 34
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 35
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 36
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 37
Iterative Enhancement

Sofware Process 38
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 39
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 40
 Rational Unified Process(RUP)
◼ An iterative process model that was designed by
Rational, now part of IBM
◼ Designed for object-oriented development (OOD)
using the Unified Modeling Language (UML)
◼ Development of software divided into cycles, each
cycle delivering a fully working system
◼ each cycle is executed as a separate project whose
goal is to deliver some additional capability to an
existing system (built by the previous cycle)
41
 Rational Unified Process(RUP)
◼ Each cycle itself is broken into four consecutive
phases:
◼ Inception phase

◼ Elaboration phase

◼ Construction phase

◼ Transition phase

◼ Each phase has a distinct purpose

◼ Completion of each phase is a well defined
milestone in the project with some clearly defined
outputs. 42
The RUP model

Sofware Process 43
 Inception phase
◼ Establishes the goals and scope of the project.
◼ completion of this phase is the lifecycle objectives
milestone
◼ specifies the vision and high-level capability of the
eventual system, including:
◼ business benefits, key use cases, key risks of the

project, basic plan of the project (cost and schedule).

◼ A go/no-go decision is taken.
◼ this milestone represents a shared vision among the
stakeholders that they agree to the project, its vision,
benefits, cost, usage, etc. 44
 Elaboration Phase
◼ The architecture of the system is designed
◼ Completion of this phase is the lifecycle
architecture milestone
◼ By the end of this phase, the critical
engineering decisions regarding the choice of
technologies, architecture, have been taken,
and a detailed understanding of the project
exists
Sofware Process 45
Construction phase,
◼ The software is built and tested.
◼ This phase results in the software
product to be delivered, along with
associated user manuals
◼ Successfully completing this phase
results in the initial operational
capability milestone being achieved

Sofware Process 46
Transition phase
◼ Moves the software from the
development environment to the client’s
environment
◼ This requires additional testing,
conversion of old data for this software
to work, training of personnel etc
◼ The successful execution of this phase
results in achieving the milestone
product release 47
 Iterations
◼ Each phase itself may have multiple
iterations, with each iteration delivering to a
customer some output which is often a part of
the final deliverable of that phase’s milestone
◼ The construction phase will be broken into
multiple iterations, each iteration producing a
working system which can be used for
feedback, evaluation, beta-testing, etc
Sofware Process 48
 Iterations
◼ in the elaboration phase,
◼ the first iteration may just specify the overall
architecture and high-level requirements, while
the second iteration may be done to thrash out
the details.
◼ In the transition phase,
◼ there may be multiple iterations to transition the
developed software, with each iteration “making
live” some part or some feature of the developed
software Sofware Process 49
 Core process workflows
(subprocesses)
◼ RUP has carefully chosen the phase names so as not
to confuse them with the engineering tasks
◼ in RUP the engineering tasks and phases are separate
◼ Engg Tasks such as requirements analysis, design,
implementing the design, testing, project management
are called core process workflows or
subprocesses
◼ RUP allows, for example, during construction,
execution of the requirements process, something the
waterfall did not allow. This captures the reality of the
situation in projects. 50
 Core process workflows
Activity level of subprocesses in different phases of RUP

• The volume of work or the effort being spent on the

subprocess varies with phases
51
RUP Summary
◼ RUP provides a flexible process model,
which follows an iterative approach not
only at a top level (through cycles), but
also encourages iterative approach
during each of the phases in a cycle.

Sofware Process 52
Timeboxing Process Model
◼ What if we have multiple iterations
executing in parallel
◼ Can reduce the average completion
time by exploiting parallelism
◼ For parallel execution, can borrow
pipelining concepts from hardware
◼ This leads to Timeboxing Process Model

Sofware Process 53
 Timeboxing Execution
Software

Requirements Build Deploy

TB1

Requirements Build Deploy

TB2

Requirements Build Deploy

TB3

Requirements Build Deploy

TB4

Sofware Process 54
Timeboxing Model – Basics
◼ Development is done iteratively in fixed
duration time boxes
◼ Each time box divided in fixed stages
◼ Each stage performs a clearly defined task
that can be done independently
◼ Each stage approximately equal in duration
◼ There is a dedicated team for each stage
◼ When one stage team finishes, it hands over
the project to the next team

Sofware Process 55
Timeboxing
◼ With this type of time boxes, can use
pipelining to reduce cycle time
◼ Like hardware pipelining – view each
iteration as an instruction
◼ As stages have dedicated teams,
simultaneous execution of different
iterations is possible

Sofware Process 56
Example
◼ An iteration with three stages –
Requirements, Build, Deploy
◼ These stages are appx equal in many
situations
◼ Can adjust durations by determining the
boudaries suitably
◼ Can adjust duration by adjusting the team
size for each stage
◼ Have separate teams for R, B, and D
Sofware Process 57
 Timeboxing Execution
Software

Requirements Build Deploy

TB1

Requirements Build Deploy

TB2

Requirements Build Deploy

TB3

Requirements Build Deploy

TB4

Sofware Process 58
Pipelined Execution
◼ RT starts executing TB1
◼ RT finishes, hands over to BT, starts
executing TB2
◼ RT finishes TB2, hands over to BT; BT
finishes TB1, hands over to DT; RT
starts TB3, BT starts TB2 (and DT, TB1)
◼ …

Sofware Process 59
 Timeboxing execution
◼ First iteration finishes at time T wks
◼ Subsequent ones finishes at T/3 wks;
◼ In steady state, delivery every T/3 time
◼ If T is 9 weeks (stage duration =3wks),
first delivery after 9 wks, 2nd after 12
wks, 3rd after 15 wks,…
◼ In linear execution, delivery times will be
9 wks, 18 wks, 27 wks,…
Sofware Process 60
Timeboxing execution
◼ Duration of each iteration still the same
◼ Total work done in a time box is also
the same
◼ Productivity of a time box is same
◼ Yet, average cycle time or delivery time
has reduced to a third

Sofware Process 61
Team Size
◼ In linear execution of iterations, the
same team performs all stages
◼ If each stage has a team of S, in linear
execution the team size is S
◼ In pipelined execution, the team size is
three times (one for each stage)
◼ I.e. the total team size in timeboxing is
larger; and this reduces cycle time

Sofware Process 62
Team Size
◼ Merely by increasing the team size we
cannot reduce cycle time
◼ Timeboxing allows structured way to
add manpower to reduce cycle time
◼ Note that we cannot change the time of
an iteration
◼ Work allocation different to allow larger
team to function properly
Sofware Process 63
 Work Allocation of Teams

Requirements Requirements Requirements Requirements Requirements

Team Analysis for TB1 Analysis for TB2 Analysis for TB3 Analysis for TB4

Build Team Build for TB1 Build for TB2 Build for TB3 Build for TB4

Deployment
Deployment for TB1Deployment for TB2 Deployment for TB3
Team

Sofware Process 64
 Timeboxing
◼ Advantages: Shortened delivery times,
◼ Disadvantages: Larger teams, proj mgmt
is harder, high synchronization needed,
CM is harder
◼ Applicability: When short delivery times v.
imp.; architecture is stable; flexibility in
feature grouping

Sofware Process 65
 Extreme Programming and
Agile Processes
◼ Evolved in the 1990s as a reaction to
documentation and bureaucracy-based
processes particularly the waterfall approach
◼ Based on some common principles:
◼ Working software is the key measure of progress
in a project.
◼ For progress in a project, therefore, software
should be developed and delivered rapidly in small
increments.
Sofware Process 66
 Agile principles cont’d
◼ Even late changes in the requirements should
be entertained (small-increment model of
development helps in accommodating them)
◼ Face-to-face communication is preferred
over documentation.
◼ Continuous feedback and involvement of
customer is necessary for developing good-
quality software.
Sofware Process 67
 Agile principles cont’d
◼ Simple design which evolves and
improves with time is a better approach
than doing an elaborate design up front
for handling all possible scenarios.
◼ The delivery dates are decided by
empowered teams of talented individuals
(and are not dictated).

Sofware Process 68
 Extreme programming (XP)
◼ Is one of the most popular agile methods
◼ it believes that changes are inevitable and
should be embraced
◼ to accommodate change, the development
process has to be lightweight and quick to
respond.
◼ it develops software iteratively, and avoids
reliance on detailed and multiple documents
which are hard to maintain 69
 Extreme programming (XP)
◼ It relies on face-to-face communication,
◼ simplicity, and feedback to ensure that the
desired changes are quickly and correctly
reflected in the programs

Sofware Process 70
 User stories
◼ XP starts with user stories
◼ Short (a few sentences) descriptions of what
scenarios the users would like the system to
support
◼ Different from traditional SRS
◼ Do not contain detailed requirement which are to
be uncovered only when the story is to be
implemented
◼ Each story is written on a separate card, so they
can be flexibly grouped 71
 Release planning
◼ Defines which stories are to be built in which
system release, and the dates of these releases
◼ Frequent and small releases are encouraged,
and for a release, iterations are employed

Sofware Process 72
 iteration
◼ Development is done in iterations, each iteration lasting no
more than a few weeks
◼ Starts with iteration planning in which the stories to be
implemented in this iteration are selected—high-value and
high-risk stories are considered as higher priority and
implemented in early iterations
◼ Failed acceptance tests in previous iteration also have to be
handled.
◼ Details of the stories are obtained in the iteration for doing
the development.

Sofware Process 73
 Iteration phase unique
practices
1. Development is done by pairs of programmers instead of
individual programmers
2. automated unit tests be written first before the actual code is
written
1. Referred to as test-driven development
3. it encourages simple solutions as well as change
1. refactoring be done to improve the design to accomodate
changes
4. it encourages frequent integration of different units
1. only one pair at a time can release their changes and
integrate into the common code base
74
An iteration in XP

Sofware Process 75
Acceptance test
◼ Acceptance tests are also built from the
stories, which are used to test the
software before the release.
◼ Bugs found during the acceptance
testing for an iteration can form work
items for the next iteration.

Sofware Process 76
 Spiral Model

❑ This model of development combines the

features of the prototyping model and
the waterfall model. The spiral model is
intended for large, expensive, and
complicated projects.
 History
❑ The spiral model was defined by Barry
Boehm in 1988 .
❑ It was not the first model to discuss
iterative development, but it was the first
model to explain why the iteration
matters.
❑ the iterations were typically 6 months to 2
years long.
 When to use The spiral Model

❑ The user has experience to refine the

requirements
❑ Some parts of the implementation may
depend on future technology
❑ New user requirements are anticipated
but not yet known
❑ Some user requirements may be
significantly more difficult to meet than
others, and it is decided not to allow
them to delay a usable delivery
 Quadrant 1: Determine objectives,
alternatives, and constraints:

Objectives: performance,
hardware/software interface ,
functionality, etc.
Alternatives: design, reuse, buy,
etc.
constraints : imposed on
technology, cost, schedule, support,
and risk.
Once the system‘s objectives,
alternatives, and constraints are
understood, Quadrant 2 (Evaluate
alternatives, identify, and resolve
risks) is performed
 Quadrant 2: Evaluate alternatives, identify,
resolve risks
◼ The focus here is on risk study. Each alternative
is investigated and prototyped to reduce the risk
associated with the development decisions

◼ Study alternatives relative to objectives and constraints

◼ Identify risks (lack of experience, new technology, tight
schedules, poor process, etc.
◼ Resolve risks (evaluate if money could be lost by
continuing system development
Quadrant 3: Develop, verify, next-level
product.

Typical activities

 Create a design

 Review design

 Develop code

 Inspect code

 Test product
Quadrant 4: Plan next phases.

Typical activities

◼ Develop project plan

◼ Develop configuration
management plan

◼ Develop a test plan

◼ Develop an installation plan

 Summary of Spiral steps:
◼ Each successive phase in the project as a new spiral
includes a four steps or phases.
◼ Software requirements in the design are gradually
developed through a series of prototypes.
◼ The exact number of spirals necessary for the project is
flexible and depends on the number of prototypes
needed to reach a satisfactory design.
◼ Once a satisfactory design is reached the software is
constructed according the final three process of the
waterfall model (Coding– Integration-Delivery)
 Advantages
◼ Provides early indication of insurmountable risks,
without much cost
◼ Users see the system early because of rapid
prototyping tools
◼ Critical high-risk functions are developed first
◼ The design does not have to be perfect
◼ Users can be closely tied to all lifecycle steps
◼ Early and frequent feedback from users
◼ Cumulative costs assessed frequently
 Disadvantages
◼ Time spent for evaluating risks too large for
small or low-risk projects
◼ Time spent planning, resetting objectives,
doing risk analysis and prototyping may be
excessive
◼ The model is complex
◼ Risk assessment expertise is required
◼ Spiral may continue indefinitely
◼ Developers must be reassigned during non-
 Summary
◼ Process is a means to achieve project
objectives of high QP
◼ Process models define generic process, which
can form basis of project process
◼ Process typically has stages, each stage
focusing on an identifiable task
◼ Many models for development process have
been proposed
Sofware Process 88
Summary – waterfall
Strength Weakness Types of Projects
Simple All or nothing – too Well understood
Easy to execute risky problems, short
Intuitive and logical Req frozen early duration projects,
May chose outdated automation of
Easy contractually existing manual
hardware/tech
systems
Disallows changes
No feedback from
users
Encourages req
bloating

Sofware Process 89
Summary – Prototyping
Strength Weakness Types of Projects
Helps req elicitation Front heavy Systems with novice
Reduces risk Possibly higher cost users; or areas with
Better and more and schedule req uncertainity.
stable final system Encourages req Heavy reporting
bloating based systems can
Disallows later benefit from UI proto
change

Sofware Process 90
Summary – Iterative
Strength Weakness Types of Projects
Regular deliveries, Overhead of For businesses where
leading to biz benefit planning each time is imp; risk of
Can accommodate iteration long projects cannot
changes naturally Total cost may be taken; req not
Allows user feedback increase known and evolve
System arch and with time
Avoids req bloating
Naturally prioritizes design may suffer
req Rework may increase
Allows reasonable
exit points
Reduces risks
Sofware Process 91
Summary – Timeboxing
Strength Weakness Types of Projects
All benefits of PM becomes more Where very short
iterative complex delivery times are
Planning for Team size is larger very important
iterations somewhat Complicated – lapses Where flexibility in
easier can lead to losses grouping features
Very short delivery Arch is stable
times

Sofware Process 92