Chapter 2

Software Processes

1
• We have seen
• Software engineering focuses on process
• Proper processes will help achieve project
objectives of high Q&P

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
(high P&Q)
3
• Many types of activities performed by
different people in a software project

• Better to view software process as

comprising of many component processes

4
• A process is a means to reach the goals of
high quality, low cost, and low cycle time,
and a process model provides generic
guidelines for developing a suitable process
for a project.

5
• A process model specifies a general
process, usually as a set of stages in which a
project should be divided, the order in
which the stages should be executed, and
any other constraints and conditions on the
execution of stages.
6
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

7
Development process
• Development process is the heart of software
process; other processes revolve around it

• These are executed by different people

• developers execute engineering process

• project manager executes the management process

8
• 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

9
ETVX Approach for Process
Specification
• Process is generally a set of phases
• Each phase performs a well defined task and generally
produces an output

• Output of development process, which are not the

final output, are frequently called the work products.

• a work product can be the requirements

document, design document, code, prototype, an1d0
the like.
• Output must be a formal and tangible entity.
• Output of each step must be some work product that can be

verified

• process should have a small number of steps.

• Due to this, at the top level, a process typically consists

of a few steps

• How to perform the activity of the particular step or phase is

11
generally addressed by methodologies for that activity.
• (Entry-Task-Verification-Exit)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 management
12
13
Characteristics of Software
Process
• Predictability and repeatability
• Predictability of a process determines how accurately
the outcome of following that process in a project can
be predicted before the project is completed.

• Process should repeat its performance when used on

different projects

• outcome of using a process should be predictable

14
• Without predictability, cannot estimate, or say
anything about quality , cost or productivity

• With predictability, past performance can be

used to predict future performance

15
• Predictable process is said to be under
statistical control
• Repeatedly using the process produces similar
results

• To consistently develop sw with high Q&P,

process must be in control

16
• Support Change
• Software changes for various reasons

• Requirements change is a key reason

• Requirement changes cannot be wished away or
treated as “bad”

• They must be accommodated in the process for

17
sw development
• Support Testability and Maintainability
• In the life of software the maintenance costs generally
exceed the development costs.

• Objective of development
• to produce software that is easy to maintain. And the process
used should ensure this maintainability

• Support testability as testing is the most expensive task

18
• Early Defect Removal
• Errors can occur at any stage during
development.

• Cost of correcting errors of different phases is

not the same and depends on when the error is
detected and corrected.
19
• The greater the delay in detecting an error
after it occurs, the more expensive it is to
correct it.

• Attempt to detect errors that occur in a

phase during that phase itself and should not
wait until testing to detect errors.
20
• A process should have quality control
activities spread through the process and in
each phase.

21
Software life cycle and process
models
• Due to the importance of the development
process, various models have been
proposed.
• Waterfall Model
• Prototyping
• Iterative Development
• Timeboxing Model
• Spiral model
• Agile model 22
Waterfall Model

• In this model,
• Feasibility analysis requirements analysis
and project planning system design 
coding  testing  system installation
• After system installation, the regular operation
and maintenance of the system takes place.
23
24
• advantages of this model is:
• its simplicity.
• divides the large task of building a software
system into a series of cleanly divided phases,
each phase dealing with a separate logical
concern.
25
• It is also easy to administer
• Limitations
• It assumes that the requirements of a system can be
frozen (i.e., base lined) before the design begins.

• This is possible for systems designed to

automate an existing manual system.

• But user requirements are usually unknown and can

be changed
26
• Freezing the requirements usually requires
choosing the hardware (because it forms a part
of the requirements specification).
• Large projects can take few years to complete by
then the hardware specified might be obsolete.

27
• The entire software is delivered in one shot at
the end. This entails heavy risks, as the user
does not know until the very end what they are
getting.

• It is a document-driven process that requires

formal documents at the end of each phase.

28
Prototyping
• Instead of freezing the requirements before
any design or coding can proceed
• a throw-away prototype is built to help
understand the requirements.

29
• Based on known requirement design,
coding, and testing of the prototype is done.

• The user interact with prototype and give

feedback

• Final results in more stable requirements

that change less frequently. 30
31
• Suitable for
• complicated and large systems for which there
is no manual process or existing system to help
determine the requirements.

• It is also an effective method of demonstrating

the feasibility of a certain approach.
32
• Exception handling, recovery, and
conformance to some standards and formats
are typically not included in prototypes.

• minimal documentation need (design

documents, a test plan, and a test case
specification are not needed )
33
Iterative Development

• Basic idea
• Software developed in increments, each
increment adding some functional capability to
the system until the full system is implemented

• Combine the benefits of both prototyping

and the waterfall model.
34
• Advantage
• better testing because testing each increment is
likely to be easier than testing the entire system
as in the waterfall model.

• as in prototyping, the increments provide

feedback to the client that is useful for
determining the final requirements of the system
35
The iterative enhancement model
• The iterative enhancement model is an example of this
approach.

• steps
• First create initial implementation & project control list
(tasks that must be performed to obtain the final

implementation.)

• Remove one task at a time and

• design  implement  analysis

36
• The process is iterated until the project control list is empty
37
The spiral model
• It is another iterative model that has been proposed
• Models do not deal with uncertainly which is
inherent to software projects.

• Important software projects have failed because

project risks were neglected & nobody was prepared
when something unforeseen happened.

38
• Barry Boehm recognized this and tired to
incorporate the “project risk” factor into a
life cycle model.

• The result is the spiral model, which was

presented in 1986.

39
40
Agile model
• Agile SDLC model is a combination of iterative
incremental process models with focus on process
adaptability and customer satisfaction by rapid
delivery of working software product.
• Agile model believes that every project needs to be
handled differently and the existing methods need to
be tailored to best suit the project requirements.
• In Agile, the tasks are divided to time boxes (small
time frames) to deliver specific features for a
release.
41
• Iterative approach is taken and working software
build is delivered after each iteration.
• Each build is incremental in terms of features; the
final build holds all the features required by the
customer.
• Every iteration involves cross functional teams
working simultaneously on various areas like −
• Planning
• Requirements Analysis
• Design
• Coding
• Unit Testing and
• Acceptance Testing.
• At the end of the iteration, a working product is
displayed to the customer and important 42

stakeholders.
43
• The advantages of the Agile Model are as follows −
• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and
demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within
an overall planned context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.
44
• The disadvantages of the Agile Model are as follows −
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and
extensibility.
• An overall plan, an agile leader and agile PM practice
is a must without which it will not work.
• Strict delivery management dictates the scope,
functionality to be delivered, and adjustments to meet
the deadlines.
• Depends heavily on customer interaction, so if
customer is not clear, team can be driven in the wrong
direction.
• There is a very high individual dependency, since
there is minimum documentation generated.
• Transfer of technology to new team members may45 be
quite challenging due to lack of documentation.
Timeboxing Model
• Uses parallelism between the different
iterations

• a new iteration commences before the system

produced by the current iteration is released

• Each time box is divided into a sequence of

stages,
41
• Each stage performs some clearly defined
task for the iteration and produces a clearly
defined output.

• duration of each stage is the same

• team for a stage performs only tasks of that

stage 42
43
• Example
• If the time box is of size T days, then the first
software delivery will occur after T days. The
subsequent deliveries, however, will take place
after every T/3 days.

• T is 9 weeks
• first delivery is made on 9th week, then 12th , 15th week 44
• Linear execution of iterations,
• The first delivery will be made after 9 weeks,

• the second will be made after 18 weeks,

• the third after 27 weeks,

45
• Man-power

• Suppose ;

• it takes 2 people 2 weeks to do the requirements for iteration,

• 4 people 2 weeks to do the build for the iteration, and

• it takes 3 people 2 weeks to test and deploy.

• If the iterations are serially executed, then the team for the project will be 4

people (the maximum size needed for a stage)

• If this project is executed using the timeboxing process model separate team is

needed so (2+4+3=9)peoples are needed

• Hence, the timeboxing provides an approach for utilizing additional man-power to reduce
the delivery time. 46
• Timeboxing is well suited for projects that
require a large number of features to be
developed in a short time

47
• Timeboxing is not suitable for
• Projects where it is difficult to partition the overall
development into multiple iterations of approximately
equal duration.

• It is also not suitable for projects where different

iterations may require different stages, and

• for projects whose features are such that there is no

flexibility to combine them into meaningful deliveries.48