Unit – 2

Project Life Cycle and Effort Estimation

Topics :

Software process and Process Models – Choice of Process models – Rapid

Application development – Agile methods – Dynamic System Development
Method – Extreme Programming– Managing interactive processes – Basics
of Software estimation – Effort and Cost estimation techniques – COSMIC
Full function points – COCOMO II – a Parametric Productivity Model.
 Software Process and Process Model
◼ Software Processes are the activities for designing, implementing, and
testing a software system.

◼ A Software Process Model is an conceptual representation of the

development process. The models specify the stages and order of a process
and sequence

◼ The goal of a software process model is to provide guidance for

controlling and coordinating the tasks to achieve the end product and
objectives as effectively as possible.

2
 Type of Software Process Model
` There are many kinds of Process Models for different requirements. We
refer to these as SDLC models (Software Development Life Cycle models).
The most popular and important SDLC/Process Models are as follows:

◼ Waterfall model
◼ V model
◼ Incremental model
◼ Spiral model
◼ Rapid Application Development (RAD) model
◼ Agile model
◼ Iterative model
◼ Prototype model

3
 Factors in choosing a software process
Choosing the right software process model for the project can be difficult. If
you know your requirements well, it will be easier to select a model that
best matches your needs. You need to keep the following factors in mind
when selecting your software process model:

◼ Project requirements
Before you choose a model, take some time to go through the project
requirements and clarify them along with your organization’s or team’s
expectations.

◼ Project size
Consider the size of the project you will be working on Larger projects mean
bigger teams, so you’ll need more broad and project management plans.
4
 Factors in choosing a software process

◼ Project Complexity
Complex projects may not have clear requirements. The requirements
may change often, and the cost of delay is high.

◼ Cost of Delay
Is the project highly time-bound with a huge cost of delay, or are the
timelines flexible?

◼ Customer Involvement
Do you need to consult the customers during the process? Does the
user need to participate in all phases?

5
 Factors in choosing a software process

◼ Familiarity with technology

This involves the developers’ knowledge and experience with the project
domain, software tools, language, and methods needed for
development.

◼ Project resources
This involves the amount and availability of funds, staff, and other
resources.

6
 Software Development Life Cycle (SDLC)
◼ Feasibility study: - The main aim of feasibility study is to determine whether it
would be financially and technically feasible to develop the product.
◼ Requirements analysis and specification: - The aim of the requirements
analysis and specification phase is to understand the exact requirements of the
customer and to document them properly. This phase consists of two distinct
activities, namely Requirements gathering and analysis, this phase ends with the
preparation of Software requirement Specification (SRS)
◼ Design: - The goal of the design phase is to transform the requirements
specified in the SRS document into a structure that is suitable for
implementation in some programming language . Design specification
Document is outcome of this phase.
◼ Coding and Unit Testing:-The purpose of the coding and unit testing phase
(sometimes called the implementation phase) of software development is to
translate the software design into source code. Each component of the design
is implemented as a program module. The end-product of this phase is a set of
program modules that have been individually tested. Code Listings are generated
after this phase. 7
 Software Development Life Cycle (SDLC)

◼ Integration and System Testing: - Integration of different modules is

undertaken once they have been coded and unit tested During each
integration step, the partially integrated system is tested and a set of
previously planned modules are added to it. Finally, when all the
modules have been successfully integrated and tested, system testing is
carried out. The goal of system testing is to ensure that the
developed system conforms to its requirements laid out in the SRS
document. Test Reports are generated after this phase.

◼ Maintenance: - Maintenance of a typical software product requires much

more than the effort necessary to develop the product itself. Many studies
carried out in the past confirm this and indicate that the relative effort of
development of a typical software product to its maintenance effort is
roughly in the 40:60 ratio. This phase continues till the software is in use.
8
 Waterfall Model
◼ The Waterfall Model was the first Process Model to be introduced.
It is also referred to as a linear-sequential life cycle model. It is
very simple to understand and use. In a waterfall model, each
phase must be completed before the next phase can begin and
there is no overlapping in the phases.

9
 Waterfall Model
Waterfall Model – Application

Some situations where the use of Waterfall model is most appropriate are :

•Requirements are very well documented, clear and fixed.

•Product definition is stable.
•Technology is understood and is not dynamic.
•The project is short.
 Iterative Model
In the Iterative model, iterative process starts with a simple implementation of
a small set of the software requirements and iteratively enhances the evolving
versions until the complete system is implemented and ready to be deployed.

This process is then repeated, producing a new version of the software at the
end of each iteration of the model.
 Iterative Model
Iterative Model – Application

Iterative and incremental development has some specific applications in the

software industry. This model is most often used in the following scenarios :

• Requirements of the complete system are clearly defined and understood.

• Major requirements must be defined like hardware requirement and

software specifications etc.

• Resources with needed skill sets are not available and are planned to be
used on contract basis for specific iterations.

• There are some high-risk features and goals which may change in the
future.
 Spiral Model
The Spiral model is a combination of iterative process model and waterfall
model with a high importance on risk analysis. It allows incremental releases of
the product or incremental refinement through each iteration around the spiral.

The following illustration is a representation of the Spiral Model, listing the

activities in each phase.
 Spiral Model
Spiral Model Application

The Spiral Model is widely used in the software industry as it is parallel with
the natural development process of any product, i.e. learning with maturity
which involves minimum risk for the customer as well as the
development firms. The following pointers explain the typical uses of a Spiral
Model :

•When there is a budget constraint and risk evaluation is important.

•For medium to high-risk projects.
•Customer is not sure of their requirements.
•New product line which should be released in phases to get enough customer
feedback.
•Significant changes are expected in the product during the development cycle.
 V-Model
Under the V-Model, the corresponding testing phase of the development
phase is planned in parallel. So, there are Verification phases on side
of the ‘V’ and Validation phases on the other side.

The following illustration depicts the different phases in a V-Model of

the SDLC.
 V-Model
V- Model ─ Application

The following application are suitable to use the V-Model application:

•Requirements are well defined, clearly documented and fixed.

•Product definition is stable.

•Technology is not dynamic and is well understood by the project team.

•There are no uncertain or undefined requirements.

•The project is short.

 Rapid Application Development Model (RAD)

The Rapid Application Development Model (RAD) was first proposed by IBM in 1980’s.
The critical feature of this model is the use of powerful development tools and techniques.

A software project can be implemented using this model if the project can be broken down
into small modules where each module can be assigned independently to separate teams
These modules can finally be combined to form the final product.
 Rapid Application Development Model (RAD)

RAD- Applications :

•RAD Model is suitable for system requirements are known and short
development time.

•It is also suitable for projects requirements can be reusable for development.

•The model also used when already existing system components can be used
in developing a new system with minimum changes.

•This model can only be used if the teams consist of domain experts.

•The model should be chosen when the budget permits the use of automated
tools and techniques required.
 Agile Model

The Agile Model is useful for continuous iterations of development and

testing. Each iteration focuses on implementing a small set of features. Agile
development considers the following:

•Requirements are assumed to change.

•The system evolves over a series of short iterations.
•Customers are involved during each iteration.
•Documentation is done only when needed.

Though agile provides a very realistic approach to software development. It can

also present challenges during transfers as there is very little documentation.
Agile Model
 Agile Model
Some commonly used agile methodologies include:

Scrum: One of the most popular agile models, Scrum consists of iterations
called sprints. Each sprint is between 2 to 4 weeks long and is preceded by
planning. You cannot make changes after the sprint activities have been
defined.

Extreme Programming (XP): With Extreme Programming, an iteration can

last between 1 to 2 weeks. XP uses pair programming, continuous integration,
test-driven development and test automation, small releases, and simple
software design.

Kanban: Kanban focuses on visualizations, and if any iterations are used they
are kept very short. You use the Kanban Board that has a clear representation
of all project activities and their numbers, responsible people, and progress.
 Dynamic Systems Development Method (DSDM)

•Dynamic systems development method (DSDM) is an agile project

delivery framework. First released in 1994, DSDM originally sought to provide
some discipline to the rapid application development (RAD) method.

•The DSDM Agile Project Framework covers a wide range of activities across
the whole project lifecycle and includes strong foundations and control, which
set it apart from some other Agile methods.

• The DSDM Agile Project Framework is an iterative and incremental approach

that holds principles of Agile development, including continuous involvement of
developer and customer.
Dynamic Systems Development Method (DSDM)
 Dynamic Systems Development Method (DSDM)

DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of
scope into musts, shoulds, coulds and will not haves to adjust the project deliverable to
meet the stated time constraint.

DSDM is one of a number of agile methods for developing software and non-IT
solutions, and it forms a part of the Agile Alliance.

In 2014, DSDM released the latest version of the method in the 'DSDM Agile Project
Framework'. At the same time the new DSDM manual recognised the need to operate
alongside other frameworks for service delivery (esp. ITIL) PRINCE2, Managing
Successful Programmes, and PMI.[6] The previous version (DSDM 4.2) had only
contained guidance on how to use DSDM with extreme programming.
 Prototype Model
Prototype Model
Prototyping is used to allow the users evaluate developer proposals and try them out before
implementation. It also helps understand the requirements which are user specific and may not
have been considered by the developer during product design. Following is a stepwise approach
explained to design a software prototype.

Software Prototyping - Application

Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems. Systems which need users to fill out forms or go
through various screens before data is processed can use prototyping very effectively to
give the exact look and feel even before the actual software is developed.
 Evolutionary Model
The Evolutionary development model divides the development cycle into smaller, incremental
waterfall models in which users are able to get access to the product at the end of each cycle.

Feedback is provided by the users on the product for the planning stage of the next cycle and the
development team responds, often by changing the product, plan or process. Therefore, the
software product evolves with time.
 Comparison of Various SDLC Models
Properties of Model Water-Fall Model Iterative model, Spiral Model RAD Model
Planning in early stage Yes Yes Yes No
Handle Large-Project Not Appropriate Not Appropriate Appropriate Not Appropriate

Detailed Documentation Necessary Yes but not much Yes Limited

Cost Low Low Expensive Low

Requirement Specifications Beginning Beginning At the end of every iteration Time boxed release

Flexibility to change Difficult Easy Easy Easy

User Involvement Only at beginning Intermediate High Only at the beginning
Duration Long Very long Long Short
Risk Involvement High Medium Low Low
After completion of coding At the end of the engineering
Testing After every iteration After completion of coding
phase phase

Yes (As parallel development is

Overlapping Phases No No Yes
there)
Maintenance Least Maintainable Maintainable Yes Easily Maintainable
Re-usability Least possible To some extent To some extent Yes

Working software availability At the end of the life-cycle At the end of every iteration At the end of every iteration At the end of the life cycle

Customer control over

Very Low Yes Yes Yes
administrator
 Managing Interactive Processes
Managing People
•Act as project leader
•Liaison with stakeholders
•Managing human resources
•Setting up reporting hierarchy etc.

Managing Project
•Defining and setting up project scope
•Managing project management activities
•Monitoring progress and performance
•Risk analysis at every phase
•Take necessary step to avoid of problems
•Act as project spokesperson
 Software Project Estimation
For an effective management accurate estimation of various measures is a must.
With correct estimation managers can manage and control the project more
efficiently and effectively. Software Project estimation may involve the following:

◼ Software size Estimation

Software size may be estimated either in terms of KLOC (Kilo Line of Code) or
by calculating number of function points in the software. Lines of code depend
upon coding practices and Function points vary according to the user or
software requirement.

◼ Effort Estimation
The managers estimate efforts in terms of personnel requirement and man-
hour required to produce the software. For effort estimation software size
should be known. This can either be derived by managers’ experience,
organization’s historical data or software size can be converted into efforts by
using some standard formulae.
 Software Project Estimation
◼ Time Estimation
Once size and efforts are estimated, the time required to produce the
software can be estimated. Efforts required is segregated into sub categories
as per the requirement specifications and interdependency of various
components of software. Software tasks are divided into smaller tasks,
activities or events by Work Breakthrough Structure (WBS). The tasks are
scheduled on day-to-day basis or in calendar months.

◼ Cost Estimation
This might be considered as the most difficult of all because it depends on
more elements than any of the previous ones. For estimating project cost, it is
required to consider :
◼ Size of software , Software quality, Hardware
◼ Additional software or tools, licenses etc.
◼ Skilled personnel with task-specific skills
◼ Travel ,Communication ,Training and support
 Software Project Estimation Techniques
Various parameters involving project estimation such as size, effort, time and
cost. Broadly two techniques are using for software project estimation:
1. Decomposition Technique : Before an estimate can be made and
decomposition techniques applied, the planner must Understand the scope of
the software to be built Generate an estimate of the software’s size . There
are two main models :
◼ Line of Code : Estimation is done on behalf of number of line of codes in
the software product.
◼ Function Points : Estimation is done on behalf of number of function points
in the software product.
 Software Project Estimation Techniques

Empirical Estimation Technique : : Estimation models for computer software use

empirically derived formulas to predict effort as a function of LOC (line of code) or
FP(function point). Resultant values computed for LOC or FP are entered into an
estimation model ) These formulae are based on LOC or FPs.

◼ COSMIC is an international standard for measuring software size: ISO/IEC

19761:2011

◼ Putnam Model : This model is made by Lawrence H. Putnam, which is based on

Norden’s frequency distribution (Rayleigh curve). Putnam model maps time and
efforts required with software size.

◼ COCOMO :COCOMO stands for COnstructive COst MOdel, developed by Barry W.

Boehm. It divides the software product into three categories of software: organic,
semi-detached and embedded.
 Software Project Estimation Techniques
COSMIC function points are a unit of measure of software functional
size. The size is a consistent measurement (or estimate) which is very useful for
planning and managing software and related activities. The process of measuring
software size is called functional size measurement (FSM). COSMIC functional size
measurement is applicable to business, real-time and infrastructure software at any
level of decomposition. It is independent of the technology or processes used to
develop the system. It is an ISO standard. The unit of size is the COSMIC Function
Point or CFP. Once you have measured (or estimated) the size in COSMIC Function
Points we can then use this as the base metric to :
◼ Estimate development effort
◼ Estimate project duration
◼ Estimate project quality achievement
◼ Estimate test effort
◼ Assess the value a software asset
◼ Estimate maintenance and replacement costs
◼ Assess the achievement of quality (defect removal rates)
◼ As the basis for fixed price contracts and more.
 The Constructive Cost Model (COCOMO)
It is a hierarchy of software costs estimation models, which include Basic,
Intermediate & Detailed models.
 BASIC MODEL

It aims at estimating small to

medium sized software
projects.

Three modes of development

are considered in this model:
Organic, Semidetached
and Embedded.
Comparison of Three COCOMO models
Basic Model
◼ Basic COCOMO model takes the form :

where
E is effort applied in Person-Months
D is the development time in months and the coefficients ab, bb, cb, db are
given in table.
Basic Model
Example

Solution
Example

Solution
 Intermediate Model
◼ The basic model allowed for a quick and rough
estimate, but it resulted in a lack of accuracy.

◼ Boehm introduced an additional set of 15 predictors

called cost drivers in the intermediate model to take
account of the software development environment.

◼ Cost drivers are used to adjust the nominal cost

of a project to the actual project environment,
hence increasing the accuracy of the estimate.
The cost drivers are grouped into four categories:
-
Multiplier Values for Effort Calculation

The multiplying factors for all 15 cost drivers are multiplied to get the effort adjustment factor(EAF).
 Detailed COCOMO Model
◼ It offers a means for processing all the project characteristics to construct a s/w
estimate. The detailed model introduces two more capabilities:

◼ Phase sensitive effort multiplier: Some phases are more affected than others by
factors defined by the cost drivers. The detailed model provides a set of phase
sensitive effort multipliers for each cost driver. This helps in determining the
manpower allocation for each phase of the project.

◼ Three-level product hierarchy: Three product levels are defined. These are
module, subsystem and system levels. The ratings of the cost drivers are done
at appropriate level, i.e the level at which it is most susceptible to variation.
 Detailed COCOMO Model
COCOMO-II is the revised version of the original Cocomo (Constructive Cost
Model) and is developed at University of Southern California. It is the model that
allows one to estimate the cost, effort and schedule when planning a new software
development activity. It consists of three sub-models:
1. End User Programming:
Application generators are used in this sub-model. End user write the code by using
these application generators. Example – Spreadsheets, report generator, etc.
2. Intermediate Sector:
◼ (a) Application Generators and Composition Aids –
This category will create largely prepackaged capabilities for user programming. Their
product will have many reusable components. Typical firms operating in this sector
are Microsoft, Lotus,
Oracle, IBM, Borland, Novell.
◼ (b) Application Composition Sector –
This category is too diversified and to be handled by prepackaged solutions. It
includes GUI, Databases, domain specific components such as financial, medical or
industrial process control packages.
◼ (c). System Integration –
This category deals with large scale and highly embedded systems.
 Detailed COCOMO Model
3. Infrastructure Sector:
This category provides infrastructure for the software development like
Operating System, Database Management System, User Interface
Management System, Networking System, etc.
◼ Stages of COCOMO II:
◼ Stage-I:
It supports estimation of prototyping. For this it uses Application Composition
Estimation Model. This model is used for the prototyping stage of application
generator and system integration.
◼ Stage-II:
It supports estimation in the early design stage of the project, when we less
know about it. For this it uses Early Design Estimation Model. This model is
used in early design stage of application generators, infrastructure, system
integration.
◼ Stage-III:
It supports estimation in the post architecture stage of a project. For this it
uses Post Architecture Estimation Model. This model is used after the
 Detailed COCOMO Model
◼ It offers a means for processing all the project characteristics to construct a s/w
estimate. The detailed model introduces two more capabilities:

◼ Phase sensitive effort multiplier: Some phases are more affected than others by
factors defined by the cost drivers. The detailed model provides a set of phase
sensitive effort multipliers for each cost driver. This helps in determining the
manpower allocation for each phase of the project.

◼ Three-level product hierarchy: Three product levels are defined. These are
module, subsystem and system levels. The ratings of the cost drivers are done
at appropriate level, i.e the level at which it is most susceptible to variation.