1

Software Process

Sofware Process
Software Process
 Process is distinct from product – products are
outputs of executing a process on a project
 Outputs: Code, docs, test scripts,…
 SW Engg. focuses on process and products
 Goals of a project: High quality and productivity
 Proper processes help achieve them (a top level
strategy for improving P and Q); without proper
processes, hard to ensure these consistently
 This is the foundation of most manufacturing
 Also holds in software, even though it is different from
manufacturing

Sofware Process 2
Software Process…
 Software Process: A set of steps to be executed and their
ordering to produce software with desired outcome
 Two major sub-processes
 Development – focuses on development and quality steps needed
to engineer the software
 Project management – focuses on planning and controlling the
development process
 Other processes
 Configuration and change management process
 Bug/defect management process
 Release management
 Processes for various activities in dev process, e.g. testing, reviews,
..
 Development process is the heart of software process;
other processes revolve around it
 There are other processes for different types of activities in
the project, e.g. bug management process, testing process..
Sofware Process 3
 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 4
Distribution of effort…

 How programmers spend their time (old study)

 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 5
Defects

 Distribution of error occurrences by phase is

 Req. - 10-20%
 Design - 20-30 %
 Coding - 50+%
 Defects can be injected at any of the major phases.

Sofware Process 6
Early Defect Removal
 Cost of a defect increases with latency
 I.e. fixing a req defect in operation can cost a 100
times the cost of fixing it in requirements itself
 Cost of finding a defect in the field is much more
than finding it before release
 Hence, for high Q&P, the process must support
early defect removal

Sofware Process 7
Process Models
 A process model specifies a general process,
usually as a set of stages
 I.e. a model provides generic structure of the
process that can be followed by some projects to
achieve their goals
 Almost all process models have elements of the
major tasks in a project
 Requirements specification, design, coding, testing,
project management
 Different process models give different emphasis on
these major tasks, and suggest different degrees of
formalisms / detail

Sofware Process 8
Common Process Models
 Waterfall – the oldest and widely used
 Prototyping
 Iterative

 Agile
 Open Source processes

Sofware Process 9
Waterfall Model
 Linear sequence of stages/phases
 Requirements – HLD – DD – Code – Test – Deploy
 This is really formalization of approach for solving
a large problem in general
 Problem understanding – approach for a solution –
build the solution – verify/test the solution – use it
 The terms are for software development
 A phase starts only when the previous has
completed; no feedback
 The phases partition the project, each addressing
a separate concern
 A phase must end with some work product

Sofware Process 10
Sofware Process 11
Waterfall Usage
 Has been used widely
 Well suited for projects where requirements can
be understood and stated easily
 I.e. for familiar type of projects it still may be the most
optimum
 E.g. automation of existing system (with some new
capabilities)
 Most other process models are based on this basic
flow of tasks (which are for solving large problems)
 But it has major challenges/issues in current
scenario – not much used now

Sofware Process 12
Waterfall
Advantages Disadvantages

 Conceptually simple,  Assumes requirements

divides the problem can be specified and
into distinct phases frozen early – does not
hold often
 Natural approach for
problem solving  Follows the “big bang”
approach – all or nothing
 Easy to administer and delivery; too risky,
manage – each phase solution comes too late
is a milestone  Very document oriented,
requiring docs at the end
of each phase
13
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 14
Prototyping

Sofware Process 15
Prototyping
 Development of prototype
 Starts with initial requirements
 Only key features needed for understanding are
included
 Feedback taken to improve requirements
understanding
 Cost is to be kept low
 Build only features needing clarification
 “quick and dirty” – quality not important
 Things like exception handling, recovery, are omitted
 Cost can be a few % of the total
 Learning in prototype building will help in building,
besides improved requirements

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

Sofware Process 17
Iterative 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 18
Iterative Enhancement

Sofware Process 19
Iterative Development
 Used commonly in products and also in
customized development
 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 20
Timeboxing
 An iterative approach
 Time boxing – fix an iteration duration, then
determine the specs to build
 Divide iteration in a few equal stages
 Use pipelining concepts to execute iterations in
parallel

Sofware Process 21
Timeboxing Execution

Software

Requirements Build Deploy

TB1

Requirements Build Deploy

TB2

Requirements Build Deploy

TB3

Requirements Build Deploy

TB4

Sofware Process 22
Summary
 Process is a means to achieve project objectives
 Process models define generic process, which can
form basis of project process
 Key development process are: Waterfall,
prototyping, iterative (many variants)

 We will later discuss Agile and OSS processes

Sofware Process 23
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 24
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 25
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 26
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 27
Exercises (~15 mts)

28
Questions
 Generally there is a validation step at the end of
each phase – why are they important (give 3
reasons)

29
Exercise questions
 Which of these is not true (tick all)
a) To control cost, quality and schedule of a project, we
must use a good process
b) Main focus of software engineering is to make people
more efficient using good processes and technology
c) It is best to find a defect as close as possible to the
point of its injection
d) Development process and testing/bug management
are the most important processes in a project

30
Question…
 Which of these is true (tick all that apply)
a) The most time consuming phase is coding
b) If it takes more effort to write code that can be
tested easily, the extra effort is worth it
c) Fixing defects in requirements towards the end
of development is extremely expensive
d) Code should be written so it can easily
understood and can be easily modified
e) Good programming ability is important for doing
requirements analysis

31
Questions…
1. What are the main goals / driving forces of a
project (a few words)
2. If the same number of defects in each phase
remain in the software at delivery, defects in
which phase will be most expensive to remove
3. Which is the most expensive phase / activity in a
software development project
4. Over the life of a software, what is the most
expensive activity

32
Questions…
Which process model is most suitable for (give a
reason also):
1. An office wants to automate its existing manual
process for handling claims
2. A new platform is to be built to enable students
to mentor other students
3. An application where the logic / functionality is
clear, but there is uncertainty about the user
interface
4. For the project you are thinking of, if you have
full freedom (i.e. no SDOS constraints) – give 3
reasons for this

33