2.

LINEAR SOFTWARE PROJECT

ESTIMATION

Dr. Rupali Kalekar

CONTENTS

2.1 Different methods of Cost estimation

2.1.1 COCOMO-I & II model (Problem Statement)

Dr. Rupali Kalekar

2.1.2 Delphi cost estimation

2.2 Function Point Analysis (Problem Statement)

2.3 The SEI Capability Maturity Model CMM

2.4 Software Configuration management

INTRODUCTION

 After completion of SRS estimation is needed.

 Estimation of cost and development time are the key

Dr. Rupali Kalekar

issues during project planning.

 Software planning also involves size estimation, cost

estimation, resources requirement, development time
and project scheduling

 Project managers estimates cost, time and size

estimation
PROJECT ESTIMATION

 Project estimation includes: size estimation, cost

estimation, time estimation, resource requirements, project
scheduling.

Dr. Rupali Kalekar

 In order to complete a successful project, following
parameters of the project are considered
1. Scope of the work to be done
2. The risk to be incurred
3. The resources required
4. The task to be accomplished
5. The cost to be expended
6. The schedule to be followed
ESTIMATION

 The single most important task of a project: setting

realistic expectations.

Dr. Rupali Kalekar

 Unrealistic expectations based on inaccurate
estimates are the single largest cause of software
failure.

-Futrell, Shafer and Shafer, ―Quality Software

Project Management
ACTIVITIES DURING SOFTWARE PROJECT
MANAGEMENT

Size Estimation

Dr. Rupali Kalekar

Cost Estimation Development Time

Resources
Requirements

Project
Scheduling
ELEMENTS OF AN ESTIMATE

 To generate a good estimate, a project manager must

have:

Dr. Rupali Kalekar

 A work breakdown structure (WBS), or a list of tasks which need
to be completed.

 An effort estimation is required for each task

 A list of assumptions which are necessary for making the estimate

 Consent among the project teams that the estimate will accurate
 2.1 DIFFERENT METHODS OF COST ESTIMATION

 Due the requirements for software, hardware and

human resources the cost of software development is
needed. Most cost estimates are measured in person-

Dr. Rupali Kalekar

months (PM)

Cost of a project :

The cost of the project depends on the nature and

characteristics of the project, at any point, the accuracy of
the estimate will depend on the amount of reliable
information we have about the final product.
Dr. Rupali Kalekar
Dr. Rupali Kalekar
2.1.1 COCOMO-I & II MODEL
(PROBLEM STATEMENT)

 The Constructive Cost Model (COCOMO) is the most

widely used software estimation model in the world.

Dr. Rupali Kalekar

 The COCOMO model predicts the effort and duration
of a project based on inputs relating to the size of the
resulting systems and a number of "cost drives" that
affect productivity.
 COCOMO
 Common attribute to estimate software
1. Project scope must be established in advance.
2. Software metrics are used as a basis from which estimates
are made.

Dr. Rupali Kalekar

3. The project is broken into small pieces which are estimated
individually.

 To achieve reliable cost and schedule estimated, number of

options are available
1. Delay estimation until late in project.
2. Use simple decomposition techniques to generate project cost
and schedule estimates.
3. Develop empirical models for estimation.
4. Acquire one or more automated estimation tools.
 COCOMO
 Different models are used to estimate the cost of the software
 Static, Single variable model
 Used to estimate the desired values such as cost, time, effort

Dr. Rupali Kalekar

etc.
 It takes the equation
C = aLb
Where C is the cost (effort expressed in any unit of
manpower, e.g. person-month)
L is the size generally given the no. of lines of code.
a and b are constant derived from historical data of the
application.
COCOMO
 COCOMO is one of the most widely used
software estimation models in the world

Dr. Rupali Kalekar

 It was developed by Barry Boehm in 1981

 COCOMO predicts the effort and schedule for

a software product development based on
inputs relating to the size of the software and
a number of cost drivers that affect
productivity
The necessary steps in this model are:
 Get an initial estimate of the development effort from
evaluation of thousands of delivered lines of source code
(KDLOC).
 Determine a set of 15 multiplying factors from various
attributes of the project.

Dr. Rupali Kalekar

 Calculate the effort estimate by multiplying the initial
estimate with all the multiplying factors i.e., multiply the
values in step1 and step2.
 The initial estimate (also called nominal estimate) is
determined by an equation of the form used in the static
single variable models, using KDLOC as the measure of the
size. To determine the initial effort Ei in person-months the
equation used is of the type is shown below
Ei=a*(KDLOC)b
 The value of the constant a and b are depends on the
project type.
In COCOMO, projects are categorized into three types:
1. Organic
2. Semidetached
3. Embedded

1.Organic: A development project can be treated of the organic type, if

the project deals with developing a well-understood application
program, the size of the development team is reasonably small, and

Dr. Rupali Kalekar

the team members are experienced in developing similar methods
of projects.
Examples of this type of projects are simple business systems,
simple inventory management systems, and data processing
systems.

2. Semidetached: A development project can be treated with

semidetached type if the development consists of a mixture of
experienced and inexperienced staff. Team members may have finite
experience in related systems but may be unfamiliar with some
aspects of the order being developed.
Example of Semidetached system includes developing a new
operating system (OS), a Database Management System
(DBMS), and complex inventory management system.
 3. Embedded: A development project is treated to be of an
embedded type, if the software being developed is strongly
coupled to complex hardware, or if the stringent regulations
on the operational method exist.
For Example: ATM, Air Traffic control.
 For three product categories, Bohem provides a different set
of expression to predict effort (in a unit of person month)and

Dr. Rupali Kalekar

development time from the size of estimation in KLOC(Kilo
Line of code) efforts estimation takes into account the
productivity loss due to holidays, weekly off, coffee breaks,
etc.

According to Boehm, software cost estimation should be done

through three stages:
 Basic Model
 Intermediate Model
 Detailed Model
COCOMO : THREE MODELS

 COCOMO has three different models that reflect the complexity:

1. The Basic Model

2. The Intermediate Model

Dr. Rupali Kalekar

3. The Detailed Model
COCOMO: SOME ASSUMPTIONS

 Primary cost driver is the number of Delivered

Source Instructions (DSI) developed by the project

Dr. Rupali Kalekar

 COCOMO estimates assume that the project will enjoy
good management by both the developer and the
customer
 Assumes the requirements specification is not
substantially changed after the plans and
requirements phase
1. BASIC COCOMO MODEL
 Basic COCOMO model estimates the software
development effort using only a single

Dr. Rupali Kalekar

predictor variable (size in DSI) and three
software development modes
 Basic COCOMO computes software
development effort (and cost) as a function of
program size. Program size is expressed in
estimated thousands of lines of code
 When to use - Basic COCOMO is good for
quick, early, rough estimates of software
costs
Dr. Rupali Kalekar
THE DEVELOPMENT MODES: PROJECT
CHARACTERISTICS

 Organic Mode
 developed in a familiar, stable environment,

Dr. Rupali Kalekar

 similar to the previously developed projects
 relatively small and requires little innovation
 Semidetached Mode
 intermediate between Organic and Embedded
 Embedded Mode
 tight, inflexible constraints and interface requirements
 The product requires great innovation
 Dr. Rupali Kalekar
BASIC COCOMO:
 BASIC COCOMO EQUATIONS
 The basic COCOMO equations take the form

E = ab(KLOC)bb [ Person-Months]

Dr. Rupali Kalekar

D = cb(E)db [months]

 People required = Effort Applied / Development Time [count]

Where
E=Effort Applied in Person-Months
D= Development Time in Months
BASIC COCOMO COEFFICIENTS
 Coefficients of ab, bb, cb, db are given in following table

Dr. Rupali Kalekar

Project ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

BASIC COCOMO MODEL: EQUATIONS

Dr. Rupali Kalekar

 BASIC COCOMO MODEL: LIMITATIONS

 Its accuracy is necessarily limited because of its lack

Dr. Rupali Kalekar

of factors which have a significant influence on
software costs.

 Quite difficult to find out accurate estimation of cost.

Example1:
Suppose a project was estimated to be 400 KLOC. Calculate
the effort and development time for each of the three model
i.e., organic, semi-detached & embedded.

Solution:
The basic COCOMO equation takes the form:

Dr. Rupali Kalekar

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months

Estimated Size of project= 400 KLOC

(i)Organic Mode
E = 2.4 * (400)1.05
= 1295.31 PM

D = 2.5 * (1295.31)0.38
=38.07 PM
(ii)Semidetached Mode
E = 3.0 * (400)1.12
=2462.79 PM

D = 2.5 * (2462.79)0.35

Dr. Rupali Kalekar

=38.45 PM

(iii) Embedded Mode

E = 3.6 * (400)1.20
= 4772.81 PM

D = 2.5 * (4772.8)0.32
= 38 PM
 Example2:
A project size of 200 KLOC is to be developed.
Software development team has average experience
on similar type of projects. The project schedule is not
very tight. Calculate the Effort, development time,

Dr. Rupali Kalekar

average staff size, and productivity of the project.
 Dr. Rupali Kalekar
SOLUTION
Dr. Rupali Kalekar
2. INTERMEDIATE COCOMO MODEL
The Intermediate Model estimates the software
development effort by using fifteen cost driver
variables besides the size variables used in Basic

Dr. Rupali Kalekar

COCOMO Cost drivers are used to adjust the nominal
cost of the project to the actual project environment.
 It helps to increase the accuracy in project estimation
Cost drivers :
(i) Product Attributes:
 Required s/w reliability

 Size of application database

 Complexity of the product

Dr. Rupali Kalekar

(ii) Hardware Attributes
 Run time performance constraints

 Memory constraints

 Virtual machine volatility

 Turnaround time
(iii) Personal Attributes
 Analyst capability

 Programmer capability

 Application experience

 Virtual m/c experience

Dr. Rupali Kalekar

 Programming language experience

(iv) Project Attributes

 Modern programming practices

 Use of software tools

 Required development Schedule

INTERMEDIATE MODEL:
COST DRIVER CATEGORIES

Dr. Rupali Kalekar

1. Product Attributes
 RELY --- Required Software Reliability
 DATA --- Data Base Size
 CPLX --- Software Product Complexity
INTERMEDIATE MODEL:
COST DRIVER CATEGORIES

2. Computer Attributes

Dr. Rupali Kalekar

 TIME --- Execution Time Constraint
 STOR --- Main Storage Constraint
 VIRT --- Virtual Machine Volatility
 TURN --- Computer Turnaround Time
INTERMEDIATE MODEL:
COST DRIVER CATEGORIES

3. Personnel Attributes

Dr. Rupali Kalekar

 ACAP --- Analyst Capability
 AEXP --- Applications Experience
 PCAP --- Programmer Capability
 VEXP --- Virtual Machine Experience
 LEXP --- Programming Language Experience
INTERMEDIATE MODEL:
COST DRIVER CATEGORIES

Dr. Rupali Kalekar

4. Project Attributes
 MODP --- Modern Programming Practices
 TOOL --- Use of Software Tools
 SCED --- Required Development Schedule
Dr. Rupali Kalekar
Dr. Rupali Kalekar
VALUES OF EFFORT CALCULATION
 The multiplier factors for all 15 cost drivers are
multiplied to get the Effort Adjustment Factor
(EAF)

Dr. Rupali Kalekar

 Typical values of EAF range from 0.9 to 1.4
 The intermediate COCOMO equations take the
form
 E = ai(KLOC)bi * EAF
 D= ci (E)di
 INTERMEDIATE MODEL:
EFFORT MULTIPLIERS
 Tableof Effort Multipliers for each of the Cost
Drivers is provided with ranges depending on
the ratings

Dr. Rupali Kalekar

Coefficients for intermediate COCOMO

Project ai bi ci di
Organic 3.2 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
INTERMEDIATE MODEL:
WHEN SHOULD YOU USE IT

Dr. Rupali Kalekar

 The Intermediate Model can be applied across
the entire software product for easily and
rough cost estimation during the early stage

 it can be applied at the software product

component level for more accurate cost
estimation in more detailed stages
INTERMEDIATE MODEL:
LIMITATIONS

Dr. Rupali Kalekar

 The Intermediate Model estimates are within 20% of
the actuals 68% of the time
 Its effort multipliers are phase-insensitive

 It can be very tedious to use on a product with many

components
 3. DETAILED COCOMO MODEL:
Detailed COCOMO Model:
 Detailed COCOMO incorporates all qualities of the
standard version with an assessment of the cost
driver’s effect on each method of the software

Dr. Rupali Kalekar

engineering process.
 The detailed model uses various effort multipliers for
each cost driver property.
 In detailed COCOMO, the whole software is
differentiated into multiple modules, and then we
apply COCOMO in various modules to estimate effort
and then sum the effort.
The Six phases of detailed COCOMO are:
 Planning and requirements

 System structure

 Complete structure

 Module code and test

Dr. Rupali Kalekar

 Integration and test

 Cost Constructive model

The effort is determined as a function of program

estimate, and a set of cost drivers are given according
to every phase of the software lifecycle.
 HOW IS IT DIFFERENT?

• Phase-sensitive Effort Multipliers-

The effort multipliers for every cost drivers are
different during the software development

Dr. Rupali Kalekar

phases

• Module-Subsystem-System Hierarchy-
The software product is estimated in the three
level hierarchical decomposition.
The fifteen cost drivers are related to module
or subsystem level .
DETAILED COCOMO MODEL:
MODULE-SUBSYSTEM-SYSTEM
 Module level
 cost drivers tend to vary at the lowest level
 CPLX, PCAP, VEXP, LEXP

Dr. Rupali Kalekar

 Subsystem Level
 cost drivers tend to vary from subsystem to subsystem, but are the
same for modules in a sub-system
 RELY, DATA, TIME, STOR, VIRT

 System Level
 overall project relations such as nominal effort and schedule
equations
 DETAILED COCOMO MODEL:
EQUATIONS

 Detailed Model uses the same equations for

estimations as the Intermediate Model

Dr. Rupali Kalekar

 Detailed Model uses a very complex
procedure to calculate estimation. The
procedure uses the DSIs for subsystems and
modules, and module level and subsystem
level effort multipliers as inputs
 A new project with estimated 400 KLOC embedded
system has to be developed. Project manager has a
choice of hiring from two pools of developers: Very
highly capable with very little experience in the

Dr. Rupali Kalekar

programming language being used Or Developers
of low quality but a lot of experience with the
programming language. What is the impact of
hiring all developers from one or the other pool ?
 Dr. Rupali Kalekar
E = ai(KLOC)bi * EAF
D= ci (E)di
E = AI(KLOC)BI * EAF
D= CI (E)DI

Dr. Rupali Kalekar

COCOMOII (COCOMO 2)
 COCOMO 81 was developed with the assumption that
a waterfall process would be used and that all software
would be developed from scratch.

Dr. Rupali Kalekar

 Since its formulation, there have been many changes in
software engineering practice and COCOMO II is
designed to accommodate different approaches to
software development.
COCOMO-II
 The following categories of applications / projects
are identified by COCOMO-II and are shown

Dr. Rupali Kalekar

below:

Categories of applications / projects

: STAGES OF COCOMO-II

Dr. Rupali Kalekar

STEPS FOR THE ESTIMATION OF EFFORT IN
PERSON MONTHS

Dr. Rupali Kalekar

COCOMO 2 MODELS
 COCOMO 2 incorporates a range of sub-
models that produce increasingly detailed
software estimates.

Dr. Rupali Kalekar

 The sub-models in COCOMO 2 are:
 Application composition model. Used when
software is composed from existing parts.
 Early design model. Used when requirements
are available but design has not yet started.
 Reuse model. Used to compute the effort of
integrating reusable components.
 Post-architecture model. Used once the system
architecture has been designed and more
information about the system is available.
 USE OF COCOMO 2 MODELS
Prototype systems
Number of Based on Application Used for developed using
application points composition model
scripting, DB
programming etc.

Dr. Rupali Kalekar

Based on Used for Initial effort
Number of function estimation based on
Early design model
points system requirements
and design options

Number of lines of Based on Used for Effort to integrate

code reused or Reuse model reusable components
generated or automatically
generated code

Based on Used for Development effor t

Number of lines of Post-architecture based on system
source code model
design specification
DELPHI METHOD
 Delphi Method was developed in the 1950-1960s at the RAND
Corporation.
 Delphi Method is a structured communication technique,
originally developed as a systematic, interactive forecasting
method which relies on a panel of experts.
 The experts answer questionnaires in two or more rounds.

Dr. Rupali Kalekar

After each round, a facilitator provides an anonymous
summary of the experts’ forecasts from the previous round with
the reasons for their judgments.
 Experts are then encouraged to revise their earlier answers in
light of the replies of other members of the panel.
 It is believed that during this process the range of answers will
decrease and the group will converge towards the "correct"
answer.
 Finally, the process is stopped after a predefined stop
criterion
(e.g. number of rounds, achievement of consensus, and stability of
results) and the mean or median scores of the final rounds
determine the results.
WIDEBAND DELPHI
 In the 1970s, Barry Boehm and John A. Farquhar
originated the Wideband Variant of the Delphi Method.
 The term "wideband" is used because, compared to the
Delphi Method, the Wideband Delphi Technique involved
greater interaction and more communication between the

Dr. Rupali Kalekar

participants.
 In Wideband Delphi Technique, the estimation team
comprise the project manager, moderator, experts, and
representatives from the development team, constituting a
3-7 member team. There are two meetings −
 Kickoff Meeting
 Estimation Meeting

 Wideband Delphi is a process that a team can use to generate an

estimate

 The project manager chooses an estimation team, and gains consensus

among that team on the results
 Wideband Delphi is a repeatable estimation process because it consists of a
straightforward set of steps that can be performed the same way each time
STEPS IN DELPHI

Step 1: Choose the team

Step 2: Kickoff Meeting

Dr. Rupali Kalekar

Step 3: Individual Preparation
Step 4: Estimation Session
Step 5: Assemble Tasks
Step 6: Review Results
THE WIDEBAND DELPHI PROCESS
Step 1: Choose the team
 The project manager selects the estimation team
and a moderator. The team should consist of 3 to 7
project team members.

Dr. Rupali Kalekar

The moderator should be familiar with the
Delphi process, but should not have a stake in the
outcome of the session.
If possible, the project manager should not be the
moderator because he should ideally be part of
the estimation team.
 THE WIDEBAND DELPHI PROCESS
Step 2: Kickoff Meeting

 The project manager must make sure that each team

Dr. Rupali Kalekar

member understands the Delphi process, has read the
vision and scope document and any other documentation,
and is familiar with the project background and needs.
 The team brainstorms and writes down assumptions.
 The team generates a WBS with 10-20 tasks.
 The team agrees on a unit of estimation.
Step 3: Individual Preparation

 Each team member independently generates a

set of preparation results.

Dr. Rupali Kalekar

 For each task, the team member writes down
an estimate for the effort required to complete
the task, and any additional assumptions he
needed to make in order to generate the
estimate.
Dr. Rupali Kalekar
Step 4: Estimation Session

 During the estimation session, the team comes to a

consensus (agreement) on the effort required for each task
in the WBS.

Dr. Rupali Kalekar

 Each team member fills out an estimation form which
contains his estimates.
 The rest of the estimation session is divided into rounds
during which each estimation team member revises her
estimates based on a group discussion.
 Individual numbers are not discussed.
Step 4: Estimation Session (continued)

 The moderator collects the estimation forms and plots

the sum of the effort from each form on a line
 The team resolves any issues or disagreements that are brought
up.
 Individual estimate times are not discussed.
 Disagreements are often resolved by adding assumptions.
 The estimators all revise their individual estimates.
 The moderator updates the plot with the new total.
 The moderator leads the team through several rounds of
estimates to gain consensus on the estimates.
 The estimation session continues until the estimates converge
or the team is unwilling to revise estimates.

Dr. Rupali Kalekar

Step 5: Assemble Tasks
 The project manager works with the team to collect
the estimates from the team members at the end of
the meeting and compiles the final task list,

Dr. Rupali Kalekar

estimates and assumptions.

Step 6: Review Results

 The project manager reviews the final task list with
the estimation team.
ADVANTAGES AND DISADVANTAGES
Advantages
 Wideband Delphi Technique is a consensus-based estimation
technique for estimating effort.
 Useful when estimating time to do a task.
 Participation of experienced people and they individually
estimating would lead to reliable results.

Dr. Rupali Kalekar

 People who would do the work are making estimates thus
making valid estimates.
 Anonymity maintained throughout makes it possible for
everyone to express their results confidently.
 A very simple technique.
 Assumptions are documented, discussed and agreed.

Disadvantages
 Management support is required.
 The estimation results may not be what the management
wants to hear.
2.2 FUNCTION POINT ANALYSIS (PROBLEM
STATEMENT)
 Function Point Analysis was initially developed by
Allan J. Albercht in 1979 at IBM and it has been

Dr. Rupali Kalekar

further modified by the International Function Point
Users Group (IFPUG).
Initial Definition given by Allan J. Albrecht:
 PA provides standardized method to functionally size
the software work product.
 This work product is the output of software new
development and improvement projects for

Dr. Rupali Kalekar

subsequent releases.
 It is the software which is relocated to the production
application at project implementation.
 It measures functionality from the users point of view
i.e. on the basis of what the user requests and receives
in return.
 Function Point Analysis (FPA) is a method or set of
rules of Functional Size Measurement.
 It assesses the functionality delivered to its users,
based on the user’s external view of the functional

Dr. Rupali Kalekar

requirements.
 It measures the logical view of an application not
the physically implemented view or the internal
technical view.
 The Function Point Analysis technique is used to
analyze the functionality delivered by software
and Unadjusted Function Point (UFP) is the unit of
measurement.
Dr. Rupali Kalekar
OBJECTIVES OF FPA:

 To measure functionality that the user

requests and receives.
 To measure software development and
maintenance independently of technology used

Dr. Rupali Kalekar

for implementation.
 To minimize the overhead of the measurement
process.
 It should be a consistent measure among various
projects and organizations.
ELEMENTARY PROCESS (EP)

Elementary Process is the smallest unit of

functional user requirement that −

Dr. Rupali Kalekar

 Is meaningful to the user.

 Constitutes a complete transaction.

 Is self-contained and leaves the business of the

application being counted in a consistent state.
TYPES OF FPA:
Transactional Functional Type –
(i) External Input (EI): The EI is an elementary process.
EI processes data or control information that comes
from outside the application’s boundary.
(ii) External Output (EO): EO is an elementary process

Dr. Rupali Kalekar

that generates data or control information sent
outside the application’s boundary.
(iii) External Inquiries (EQ): EQ is an elementary
process made up of an input-output combination that
results in data retrieval.

Data Functional Type –

(i) Internal Logical File (ILF): A user identifiable
group of logically related data or control
information maintained within the boundary of the
application.
 (ii) External Interface File (EIF): A group of
user recognizable logically related data allusion
to the software but maintained within the
boundary of another software

Dr. Rupali Kalekar

Dr. Rupali Kalekar
BENEFITS OF FPA:
 FPA is a tool to determine the size of a purchased
application package by counting all the functions
included in the package.

Dr. Rupali Kalekar

 It is a tool to help users discover the benefit of an
application package to their organization by counting
functions that specifically match their requirements.

 It is a tool to measure the units of a software product

to support quality and productivity analysis.

 Its a vehicle to estimate cost and resources required

for software development and maintenance.
Dr. Rupali Kalekar
2.3 THE SEI CAPABILITY MATURITY
MODEL CMM
What is Capability Maturity Model?

Dr. Rupali Kalekar

 The Software Engineering Institute (SEI) Capability
Maturity Model (CMM) specifies an increasing
series of levels of a software development
organization.

 The higher the level, the better the software

development process, hence reaching each level is an
expensive and time-consuming process.
 Dr. Rupali Kalekar
LEVELS OF CMM
Level One :Initial -
 The software process is characterized as inconsistent,
and occasionally even chaotic.
 Defined processes and standard practices that exist
are abandoned (Out of control) during a crisis.

Dr. Rupali Kalekar

 Success of the organization majorly depends on an
individual effort, talent, and heroics.
 The heroes eventually move on to other
organizations taking their wealth of knowledge or
lessons learnt with them.
Level Two: Repeatable -

 This level of Software Development Organization

has a basic and consistent project
management processes to track cost, schedule,

Dr. Rupali Kalekar

and functionality.

 The process is in place to repeat the earlier

successes on projects with similar applications.
 Program management is a key characteristic of a
level two organization.
Level Three: Defined -
 The software process for both management and
engineering activities are documented,

Dr. Rupali Kalekar

standardized, and integrated into a standard
software process for the entire organization.
 All projects across the organization use an
approved, tailored version of the organization's
standard software process for developing, testing and
maintaining the application.
Level Four: Managed -
 Management can effectively control the software
development effort using precise measurements.
 At this level, organization set a quantitative

Dr. Rupali Kalekar

quality goal for both software process and
software maintenance.
 At this maturity level, the performance of
processes is controlled using statistical and other
quantitative techniques, and is quantitatively
predictable.
Level Five: Optimizing -
 The Key characteristic of this level is focusing on

Dr. Rupali Kalekar

continually improving process performance
through both incremental and innovative
technological improvements.
 At this level, changes to the process are to
improve the process performance and at the same
time maintaining statistical probability to
achieve the established quantitative process-
improvement objectives.
2.4 SOFTWARE CONFIGURATION
MANAGEMENT

 In Software Engineering, Software Configuration

Management(SCM) is a process to systematically

Dr. Rupali Kalekar

manage, organize, and control the changes in
the documents, codes, and other entities during the
Software Development Life Cycle.

 The primary goal is to increase productivity

with minimal mistakes.
 SCM is part of cross-disciplinary field of
configuration management and it can accurately
determine who made which revision.
Why do we need Configuration management?
The primary reasons for Implementing Technical
Software Configuration Management System are:
 There are multiple people working on software
which is continually updating
 It may be a case where multiple version,

Dr. Rupali Kalekar

branches, authors are involved in a software
config project, and the team is geographically
distributed and works concurrently
 Changes in user requirement, policy, budget,
schedule need to be accommodated.
 Software should able to run on various machines
and Operating Systems
 Helps to develop coordination among stakeholders
 SCM process is also beneficial to control the costs
involved in making changes to a system
Dr. Rupali Kalekar
TASKS IN SCM PROCESS

 Configuration Identification
 Baselines

Dr. Rupali Kalekar

 Change Control

 Configuration Status Accounting

 Configuration Audits and Reviews

CONFIGURATION IDENTIFICATION:

 Configuration identification is a method of

determining the scope of the software system.

Dr. Rupali Kalekar

 With the help of this step, you can manage or control
something even if you don't know what it is.
 It is a description that contains the CSCI type
(Computer Software Configuration Item), a project
identifier and version information.
ACTIVITIES DURING THIS PROCESS:

 Identification of configuration Items like source code

modules, test case, and requirements specification.
 Identification of each CSCI in the SCM repository,

Dr. Rupali Kalekar

by using an object-oriented approach
 The process starts with basic objects which are
grouped into aggregate objects. Details of what,
why, when and by whom changes in the test are
made
 Every object has its own features that identify its
name that is explicit to all other objects
 List of resources required such as the document, the
file, tools, etc.
Example:
 Instead of naming a File login.php its should be

Dr. Rupali Kalekar

named login_v1.2.php where v1.2 stands for the
version number of the file
 Instead of naming folder "Code" it should be
named "Code_D" where D represents code should
be backed up daily.
Baseline:
 A baseline is a formally accepted version of a software
configuration item.
 It is designated and fixed at a specific time while
conducting the SCM process.
 It can only be changed through formal change control
procedures.

Dr. Rupali Kalekar

Activities during this process:
 Facilitate construction of various versions of an
application
 Defining and determining mechanisms for managing
various versions of these work products
 The functional baseline corresponds to the reviewed
system requirements
 Widely used baselines include functional, developmental,
and product baselines
 In simple words, baseline means ready for release.
 Dr. Rupali Kalekar
Thank You !!!!!!!!