Chapter 2

Linear Software Project

Estimation
 Contents
2.1 Different methods of Cost estimation
2.1.1 COCOMO-I & II model (Problem Statement)
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

Note: Case studies/Numerical Problems based on COCOMO-I and

FPA
 Overview

What is Estimation
• “The single most important task of a project: setting realistic expectations.
Unrealistic expectations based on inaccurate estimates are the single largest
cause of software failure.”
• Estimation is a process to predict the time and the cost that a
project requires to be finished appropriately.
Definition of Estimation:-
Estimation is the approximation of a result that one can use even if
they are using information that is not clear or is incomplete. It is like
making an educated, reasonable guess based on the information
given. If an estimate is more than the actual amount, then it is
called an overestimate.
 Why its important to you?
• Program development of large software systems normally experience 200-300%
cost overruns and a 100% schedule slip
• 15% of large projects deliver…NOTHING!
• Key reasons…poor management and inaccurate estimations of development cost
and schedule
• If not meeting schedules, developers often pay the price!
The Problems-
• Predicting software cost
• Predicting software schedule
• Controlling software risk
• Managing/tracking project as it progresses
 In order to accurately estimate the project the common
questions that come into the mind of a project manager at
the start of the project are–

• How much work is to be estimated (scope).

• How to estimate the project (techniques).
• How much time it will require to complete the
project (Schedule).
• Who will be doing the project (resources)?
• What is the budget required to deliver the project
(cost)?
• Any intermediary dependencies that may delay or
impact the project (Risks).
 The 3 Major Parts to Project Estimation
• Effort estimation:- In software development, effort estimation is the
process of predicting the most realistic amount of effort (expressed in
terms of person-hours or money) required to develop or maintain
software based on incomplete, uncertain and noisy input.
• Cost estimation:- Cost estimation in project management is the
process of forecasting the financial needs to complete a project within
a defined scope.
• Once the project is in motion, the cost estimate is used to manage all
of its affiliated costs in order to keep the project on budget.
• Resource estimation:- resource estimation is a process in which the
project team carefully compiles a systematic listing of the resources
that will be needed in completing a project.
• The successful utilization of activity resource estimates will help
assure that enough resources are acquired without waste and
excessive expenditure.
 2.1 Different methods of Cost estimation
2.1.1 COCOMO-I & II model:-
COCOMO-I :-
• In modern software development practice, it is crucial to know the cost and time
required for the software development before establishing new software projects.
One of the efficient cost estimation models which are extensively applied to many
software projects is called “Constructive Cost Model (COCOMO)”.
• COCOMO is a procedural software cost estimation model proposed by Barry
W. Boehm in 1981.
• This cost estimation model is extensively used in predicting the effort,
development time, average team size and effort required to develop a
software project.
• The uniqueness of this strategy is that COCOMO estimates the cost based on
the number of lines of source code and sets of subjective assessment
(cost drivers) of product, hardware, personnel and project attributes.
• Before jumping to the core concepts of the COCOMO itself, It is necessary for readers to
recognize the characteristics of software project types before applying it to the model.

• A project with 50,000 LOC would be represented as 50 KLOC in the COCOMO model, making it easier
to manage and estimate.

• Software projects under COCOMO model strategies are classified to 3 categories

including, organic, semi-detached, and embedded.
Organic
• This suits a small software team since it has a generally stable development environment.
The problem is well understood and has been solved in the past.
Semi-detached
• The software project which requires more experience and better guidance and creativity. For
example, Compiler or different Embedded System
Embedded
• The project with operating tight constraints and requirements is under this category. The
The table below indicates the criteria for selecting the type of software
project to be applied for further calculation in the model.
 Types of COCOMO model
• COCOMO model allows software manager to decide how detailed they would like to conduct
the cost estimation for their own project. COCOMO can show the efforts and schedule of a
software product based on the size of the software in different levels. There are basic
COCOMO, Intermediate COCOMO, and Detailed/Completed COCOMO.
Basic COCOMO model
• The basic COCOMO is used for rough calculation which limits accuracy in calculating
software estimation. This is because the model uniquely considers based on lines of source
code together with constant values obtained from software project types rather than other
factors which have major influences to Software development process as a whole. Used in
Organic Mode
Intermediate COCOMO model
• Intermediate COCOMO model is an extension of the Basic COCOMO model which includes a
set of cost drivers in order to enhance more accuracy to the cost estimation model as a result.
Used in Semi-Detached Mode
Complete/detailed COCOMO model
• The model incorporates all qualities of both Basic COCOMO and Intermediate COCOMO
strategies on each software engineering process. The model accounts for the influence of the
individual development phase (analysis, design, etc.) of the project. Used in Embedded Mode
 Calculation steps:-
• In COCOMO, the general calculation steps of COCOMO-based cost
estimation are the following:
1. Get an initial estimate of the development effort from evaluation
of thousands of delivered lines of source code (KDLOC).
2. Determine a set of 15 cost factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all
the multiplying factors i.e., multiply the values in previous steps.
Now, let’s apply these steps to the real example in Basic COCOMO first.

Question statement: Suppose the project was estimated to be 400 KDLOC

, calculate the effort, development time, and time of each of the 3 modes.
Note: the basic COCOMO is used in Organic mode by default.
 Basic COCOMO model
• The basic COCOMO is used for rough
calculation which limits accuracy in calculating
software estimation. This is because the model uniquely
considers based on lines of source code together with
constant values obtained from software project types
rather than other factors which have major influences to
Software development process as a whole. Used in
Organic Mode
• The arithmetic formula of Basic COCOMO is
Each of the constant a, b, c, d can be defined as show
in the Table
The calculations of Basic COCOMO corresponding to
each of software project types are shown here
 2. The Intermediate COCOMO
• The basic COCOMO model assumes that effort and development time are
functions of the product size alone. However, a host of other project
parameters besides the product size affect the effort required to develop the
product as well as the development time. Therefore, in order to obtain an
accurate estimation of the effort and project duration, the effect of all
relevant parameters must be taken into account.
• The intermediate COCOMO model recognizes this fact and refines the
initial estimate obtained using the basic COCOMO expressions by using a
set of 15 cost drivers (multipliers) based on various attributes of software
development.
• Boehm requires the project manager to rate these 15 different parameters
for a particular project on a scale of one to three. Then, depending on these
ratings, he suggests appropriate cost driver values which should be
multiplied with the initial estimate obtained using the basic COCOMO.
• The intermediate model estimates software development effort
in terms of size of the program and other related cost drivers
parameters (product parameter, hardware parameter, resource
parameter, and project parameter) of the project. The estimated
effort and scheduled time are given by the relationship:
• Effort (E) = a*(KLOC)b *EAF MM
Scheduled Time (D) = c*(E)d Months(M)
• Where,
• E = Total effort required for the project in Man-Months (MM).
• D = Total time required for project development in Months (M).
• KLOC = The size of the code for the project in Kilo lines of code.
• a, b, c, d = The constant parameters for the software project.
EAF = It is an Effort Adjustment Factor, which is calculated by
multiplying the parameter values of different cost driver
parameters. For ideal, the value is 1.
Cost Driver Parameters and Values
 Example:
• For a given project was estimated with a size of 300 KLOC. Calculate
the Effort, Scheduled time for development by considering developer
having high application experience and very low experience in
programming.
Ans:
• Given the estimated size of the project is: 300 KLOC
Developer having highly application experience: 0.82 (as per above
table)
Developer having very low experience in programming: 1.14(as per
above table)
• EAF = 0.82*1.14 = 0.9348

Effort (E) = a*(KLOC)b *EAF = 3.0*(300)1.12 *0.9348 = 1668.07 MM

Scheduled Time (D) = c*(E)d = 2.5*(1668.07)0.35 = 33.55 Months(M)

 3. Detailed COCOMO
• A major shortcoming of both the basic and intermediate COCOMO models is
that they consider a software product as a single homogeneous entity.
However, most large systems are made up of several smaller sub-systems.
These subsystems may have widely different characteristics.
• For example, some subsystems may be considered as organic type, some
semi-detached, and some embedded. Not only that the inherent development
complexity of the subsystems may be different, but also for some subsystems
the reliability requirements may be high, for some the development team
might have no previous experience of similar development, and so on.
• The complete COCOMO model considers these differences in characteristics
of the subsystems and estimates the effort and development time as the sum
of the estimates for the individual subsystems. The cost of each subsystem is
estimated separately. This approach reduces the margin of error in the final
estimate.
• The following development project can be considered as an
example application of the complete COCOMO model.
• A distributed Management Information System (MIS) product for
an organization having offices at several places across the
country can have the following sub-components:
• Database part
• Graphical User Interface (GUI) part
• Communication part
• Of these, the communication part can be considered as
embedded software. The database part could be semi-detached
software, and the GUI part organic software. The costs for these
three components can be estimated separately, and summed up
to give the overall cost of the system.
Advantages and Disadvantages of COCOMO Model
• Advantages
• Easy to estimate the total cost of the project.
• Easy to implement with various factors.
• Provide ideas about historical projects.
• Disadvantages
• It ignores requirements, customer skills, and
hardware issues.
• It limits the accuracy of the software costs.
• It mostly depends on time factors.
 Conclusion:-
• We discuss the project estimation model COCOMO,
which describes the effort and development time of
the software project. It describes the different projects
with an estimate of the effort and scheduled time by
considering multiple factors.
• Refer below link for Checking Difference between
COCOMO1 & COCOMO2-
https://techdifferences.com/difference-between-cocomo-1-and-coco
mo-2.html
 2.1.2 Delphi Cost Estimation
• 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.
• The Delphi Techniques is a human-based estimation technique.
• Human-based estimation techniques use human experience and analytical skills to estimate
the size, productivity, and effort required for a project.
• Delphi technique was used to when many experts arrives the same estimate on the basis of
similar assumptions.
• The technique is an iterative process, and first aims to get a broad range of opinions from the
group of experts.
• Delphi technique has eight basic step:

⮚ Step1: Identify the teams that need to perform the estimation activity.
⮚ Estimation experts
⮚ Estimation coordinator
⮚ Author
⮚ Step2: Author present the project details including client’s needs,
system requirements, expectation, and task to the group of experts.
⮚ Step3: Finalize the acceptable adjustment value.
⮚ Step4: Prepare the list of tasks and distribute to the group of
experts.
⮚ Step5: Experts make their estimates for each task.
⮚ Step6: Coordinator prepares a summary of estimate for each task,
identify the acceptable task.
⮚ Step7: Experts continuously discuss tasks and assumptions where
the percentage of variance is not acceptable.
⮚ Step8: Revert to step 5 and repeat steps until all tasks are assigned
estimate that have an acceptable percentage of variance value.
 Work Breakdown Structure (WBS)
• Dividing into Logical Units/Tasks
• Creating a WBS is a prerequisite for any estimation activity.
• It enables you to conceptualize an abstract entity, such as a project,
into distinct, independent units.
• it gives idea about the size and complexity of the project.
• helps in planning, scheduling, and monitoring a project realistically .
• Work Breakdown Structure (WBS) based techniques are good for
planning and control. WBS was a standard of engineering practice in
the development of both hardware and software. In this technique
the complex project is divided into smallest pieces known as sub-
functionalities (smallest components) which are considered as tasks
 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 participants.
• In Wideband Delphi Technique, the estimation team contain 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
• Kickoff Meeting
• Agenda:
1.Introduction
1.Overview of Wideband Delphi methodology.
2.Importance and goals of the estimation.
2.Project Scope
1.Define and discuss the scope of work.
2.Clarify requirements and assumptions.
3.Roles and Responsibilities
1.Assign participants (moderator, estimators, etc.).
2.Explain individual contributions.Estimation ProcessOutline the iterative
estimation steps.Set timelines for consensus rounds.
Duration: 30–45 minutes]
Attendees: Project team and key stakeholders
• Agenda:
• Review Scope and Assumptions
1. Confirm task details and clarify assumptions.
2. Initial EstimatesEach participant provides individual estimates
anonymously.
3. Discussion of VarianceModerator facilitates discussion on significant
differences in estimates.
4. Revised Estimates
• Participants adjust estimates based on the discussion.
1. Finalize Estimates
• Agree on a consensus estimate for each task.
• Next Steps
 Wideband Delphi Technique – Steps
• Step 1 − Choose the Estimation team and a moderator.
• Step 2 − The moderator conducts the kickoff meeting, in which the team is
presented with the problem specification and a high level task list, any
assumptions or project constraints. The team discusses on the problem and
estimation issues, if any. They also decide on the units of estimation. The
moderator guides the entire discussion, monitors time and after the kickoff
meeting, prepares a structured document containing problem specification, high
level task list, assumptions, and the units of estimation that are decided. He then
forwards copies of this document for the next step.
• Step 3 − Each Estimation team member then individually generates a detailed
WBS, estimates each task in the WBS, and documents the assumptions made.
• Step 4 − The moderator calls the Estimation team for the Estimation
meeting. If any of the Estimation team members respond saying that
the estimates are not ready, the moderator gives more time and
resends the Meeting Invite.
• Step 5 − The entire Estimation team assembles for the estimation
meeting.
• Step 5.1 − At the beginning of the Estimation meeting, the moderator
collects the initial estimates from each of the team members.
• Step 5.2 − He then plots a chart on the whiteboard. He plots each
member’s total project estimate as an X on the Round 1 line, without
disclosing the corresponding names. The Estimation team gets an
idea of the range of estimates, which initially may be large.
• Step 5.3 − Each team member reads aloud the detailed task list that
he/she made, identifying any assumptions made and raising any
questions or issues. The task estimates are not disclosed.
• The individual detailed task lists contribute to a more complete task
list when combined.
• Step 5.4 − The team then discusses any doubt/problem they have
about the tasks they have arrived at, assumptions made, and
estimation issues.
• Step 5.5 − Each team member then revisits his/her task list and
assumptions, and makes changes if necessary. The task estimates
also may require adjustments based on the discussion, which are
noted as +N Hrs. for more effort and –N Hrs. for less effort.
• The team members then combine the changes in the task estimates
to arrive at the total project estimate.
• Step 5.6 − The moderator collects the changed estimates
from all the team members and plots them on the Round 2
line.
• In this round, the range will be narrower compared to the
earlier one, as it is more consensus based.
• Step 5.7 − The team then discusses the task modifications they have made
and the assumptions.
• Step 5.8 − Each team member then revisits his/her task list and
assumptions, and makes changes if necessary. The task estimates may also
require adjustments based on the discussion.
• The team members then once again combine the changes in the task
estimate to arrive at the total project estimate.
• Step 5.9 − The moderator collects the changed estimates from all the
members again and plots them on the Round 3 line.
• Again, in this round, the range will be narrower compared to the earlier one.
• Step 5.10 − Steps 5.7, 5.8, 5.9 are repeated till one of the following criteria
is met −
• Results are met to an acceptably fine range.
• All team members are unwilling to change their latest estimates.
• The allotted Estimation meeting time is over.
• Step 6 − The Project Manager then assembles the results
from the Estimation meeting.
• Step 6.1 − He compiles the individual task lists and the
corresponding estimates into a single master task list.
• Step 6.2 − He also combines the individual lists of
assumptions.
• Step 6.3 − He then reviews the final task list with the
Estimation team.
All Steps in One Flowchart
Individual Preparation forms
• After kickoff meeting, moderator writes down
assumptions and tasks generated by team &
distributes them.
•
TMs independently generates a set of preparation
results, thatfor
– Estimate contains
each of the tasks
– Any additional tasks that should be included in WBS
missed by Team during kickoff meeting.
–
Any assumptions that TM made in order to create the
– estimates
Any effort related to project overhead (status meetings,
reports, vacation, etc) should NOT be taken into account.
– Should be added to the “Project overhead tasks”
section.
Potential delays, (like certain tasks can’t start until after
• specific dates) NOT be taken into account. Should be
Eachadded to theshould
estimate “Calendar waitingintime”
be made section.
terms of effort, not
calendar time.
Estimation Form
Summarized Estimation Results sheet
Advantages and Disadvantages of Wideband Delphi Technique
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.
• People who would do the work are making estimates thus making valid estimates.
• Anonymity(invisibility) 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.
 Functional Point (FP) Analysis
• Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it
has been further modified by the International Function Point Users Group
(IFPUG).
• FPA is used to make estimate of the software project, including its testing in terms
of functionality or function size of the software product. However, functional point
analysis may be used for the test estimation of the product.
• The functional size of the product is measured in terms of the function point,
which is a standard of measurement to measure the software application.
Objectives of FPA:
The objective of FPA is to measure functionality that the user requests and receives.
The objective of FPA is to measure software development and maintenance
independently of technology used for implementation.
It should be simple enough to minimize the overhead of the measurement process.
It should be a consistent measure among various projects and organizations.
 Types of FPA:
1. Transactional Functional Type –
1. (i) External Input (EI): EI processes data or control information that comes
from outside the application’s boundary. The EI is an elementary process.
2. (ii) External Output (EO): EO is an elementary process that generates data
or control information sent outside the application’s boundary.
3. (iii) External Inquiries (EQ): EQ is an elementary process made up of an
input-output combination that results in data retrieval.
2. Data Functional Type –
1. (i) Internal Logical File (ILF): A user identifiable group of logically related
data or control information maintained within the boundary of the application.
2. (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.
Following are the points regarding FPs
• 1. FPs of an application is found out by counting the
number and types of functions used in the
applications. Various functions used in an application
can be put under five types, as shown in Table:
Types of FP Attributes:-
Measurements Parameters Examples
1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and shared routines.

• 2. FP characterizes the complexity of the software
system and hence can be used to depict the project
time and the manpower requirement.
• 3. The effort required to develop the project depends on
what the software does.
• 4. FP is programming language independent.
• 5. FP method is used for data processing systems,
business systems like information systems.
• 6. The five parameters mentioned above are also
known as information domain characteristics.
• 7. All the parameters mentioned above are assigned
some weights(values) that have been experimentally
determined and are shown in Table
Weights of 5-FP Attributes

Function
Low Avg High
Units

EI 3 4 6

EO 4 5 7

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10
 Calculation of Function Point (FP)
• Function Point (FP) is an element of software development which helps to approximate the cost
of development early in the process. It may measures functionality from user’s point of view.
Counting Function Point (FP):
Step-1:
F = 14 * scale
(General system characteristics are 14 parameters that’s why F=14)
Scale varies from 0 to 5 according to character of Complexity Adjustment Factor (CAF). Below table
shows scale:

0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential
Step-2: Calculate Complexity Adjustment Factor (CAF).
CAF = 0.65 + ( 0.01 * F )
Step-3: Multiply each individual function point to corresponding values in
TABLE.
Step-4: Calculate Unadjusted Function Point (UFP). TABLE (Required)

Step-5: Calculate Function Point. FP = UFP * CAF

Example:
Given the following values, compute function point when all complexity adjustment factor (CAF)
and weighting factors are average.
User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4
Explanation:
Step-1: As complexity adjustment factor is average (given in question), hence,
scale = 3.
F = 14 * 3 = 42
Step-2: CAF = 0.65 + ( 0.01 * 42 ) = 1.07 (CAF is also known as VAF-Value Adjustment Factor)
Step-3: As weighting factors are also average (given in question) hence we will multiply each
individual function point to corresponding values in TABLE.
Step 4: UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628
Step-5: Function Point = 628 * 1.07 = 671.96
Problem Statement:- Example 2
Calculate the function point of project when the complexity is
average and weighting factors are as follows:-
The number of EI(Avg): 22
The number of EO(Low): 45
The number of EQ(High): 06
The number of ILF(Avg): 05
The number of EIF(Low): 02
 SEI CMM:-
What is CMM:-
• Capability Maturity Model is used as a standard to measure the maturity of an organization's
software process.
• The Capability Maturity Model (CMM) is a procedure used to develop and refine an
organization's software development process.
• The model defines a five-level evolutionary stage of increasingly organized and
consistently more mature processes.
• CMM was developed and is promoted by the Software Engineering Institute (SEI), a
research and development center promote by the U.S. Department of Defense (DOD).
• Capability Maturity Model Integration (CMMI) is a method used for software development and
business processes optimization.
• Capability Maturity Model is used as a benchmark to measure the maturity of an
organization's software process.
•CMM can be used for

• Software process improvement

• Software process assessment
• Software capability evaluations
Capability Maturity Model (CMM) Levels:-
1. Initial 2. Repeatable/Managed 3. Defined 4. Quantitatively Managed 5. Optimizing
 CMM – Level 1 – Initial Level
The organization
•Does not have an established and documented environment for developing
and maintaining software.
• Unplanned activities by the members of the project team
• No systematic project management process
•At the time of crises, projects usually stop using all planned procedures and
revert to coding and testing.
• Adhoc Processes (No formal process)
•Success, if any, depends on successive actions of few members in the team -
Individual dependent outcomes
• KPAs (Key Process Areas) – nil (These are the critical areas of focus that an
organization must address to improve its software development or business
 CMM – Level 2 – Managed/Repeatable level
Effective management process having established which can be
• Practiced
• Documented
• Enforced
• Trained
• Measured
• Improvised
KPAs:
1. Requirements Management (RM)
2. Software Project Planning (PP)
3. Software Project Tracking and Oversight (PT)
4. Software Subcontractor Management (SM)
5. Software Quality Assurance (QA)
6. Software Configuration Management (CM)
 CMM – Level 3 – Defined level
•Standard defined software engineering and management process for
developing and maintaining software.
• These processes are put together to make a systematic whole
– organization-wide understanding of activities, roles, and responsibilities.
KPAs:
7. Organization Process Focus (PF)
8. Organization Process Definition (PD)
9. Training Program (TP)
10. Integrated Software Management (IM)
11. Software Product Engineering (PE)
12. Inter group Coordination (IC)
13. Peer Reviews (PR)
 CMM – Level 4 – Managed level
•Quantitative goals set for both software products and processes.
•The organizational measurement plan involves determining the productivity
and quality for all important software process activities across all projects.

KPAs:
14. Quantitative Process Management (QP)
15. Software Quality Management (QM)
 CMM – Level 5 – Optimizing level
Organizations working at this level not only collect process and product metrics, but analyze
them to identify scopes for improving and optimizing the various development (engineering)
and management activities. Lessons learnt from specific projects are incorporated in relevant
processes.
Emphasis on-
• Process improvement
• Tools to identify weaknesses existing in their processes
• Make timely corrections
•Identification and use of latest tools and technologies including innovative ideas.
KPAs:
16. Defect Prevention (DP)
17. Technology Change Management (TM)
18. Process Change Management (PC)
 Software Configuration Management- SCM
What is meant by software configuration?
To "configure software" means selecting programmable options that make the program
function to the user's liking. To "configure hardware" means assembling desired
components for a custom system as well as selecting options in the user-
programmable parts of the system.
What is SCM?
• In Software Engineering, Software Configuration Management(SCM) is a process to
systematically 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.
What is the purpose of software configuration management?
The software configuration management process identifies the functional and physical
attributes of software at critical points in time, and implements procedures to control
changes to an identified attribute with the objective of maintaining software integrity
and traceability throughout the software life cycle.
Any change in the software configuration Items will affect the final product. Therefore,
changes to configuration items need to be controlled and managed.
 Tasks in SCM process
• Configuration Identification:- Configuration identification is a method of determining the
scope of the software system. With the help of this step, you can manage or control
something even if you don't know what it is. Ex. Identification of configuration Items like
source code modules, test case, and requirements specification.
Example:
• Instead of naming a File login.php its should be 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.
• Baselines:- 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. In simple words, baseline means
ready for release.
• .
• Change Control:- Change control is a procedural method which ensures quality
and consistency when changes are made in the configuration object. In this step,
the change request is submitted to software configuration manager. Ex. Control
ad-hoc change to build stable software development environment. The request
will be checked based on the technical merit, possible side effects and overall
impact on other configuration objects.
• Configuration Status Accounting:- Configuration status accounting tracks each
release during the SCM process. This stage involves tracking what each version
has and the changes that lead to this version. Ex. Keeps a record of all the
changes made to the previous baseline to reach a new baseline
• Configuration Audits and Reviews:- Software Configuration audits verify that all
the software product satisfies the baseline needs. It ensures that what is built is
what is delivered. Configuration auditing is conducted by auditors by checking
that defined processes are being followed and ensuring that the SCM goals are
satisfied
 Key Benefits Of Configuration Management
• Helps in developing coordination amongst involved team members from
all groups
• Assists in managing costs included in updating the system by avoiding
duplication
• Ensures that your business system is well understood and functions
carefully
• Satisfies all requirements of the organization including service, solution,
and product deliverables
• Enhances efficiency, control, and visibility across the system
• Ensures a reliable, fast, and improved process by correcting incorrect
configurations that could influence performance
• Offers effective change management process and quick renewal of
services in case of component failure
Popular Configuration Management Tools
• Puppet
• Chef
• Ansible
• Red Hat Ansible
• CFEngine
Any Questions..?
Thank You….!