Ch 2 – Linear Software Project Estimation

(20 marks)

Monalisa Bhinge
2. Linear Software Estimation
2.1 Different methods of cost estimation
2.1.1 COCOMO-I & II model
2.1.2 Delphi cost estimation
2.2 Function point analysis
2.3 The SEI capability Maturity Model CMM
2.4 Software configuration management

Monalisa Bhinge
Introduction
 Estimation is the process is finding an estimate or
approximation which is a value that can be used for some
purpose even if input data may be incomplete, uncertain,
or unstable.
 Estimation is a process to predict the time and the cost
that a project requires to be finished appropriately.
 Effective software project estimation is one of the key
activity in software development.
 Proper project planning & control is not possible without a
sound & reliable estimation.
 Over estimation, Under estimation.
 Estimation is based on the past data, experience, available
documents/knowledge, assumptions & identified risks.
 Project estimation includes: size estimation, effort
estimation, time or schedule estimation and cost
estimation.
3
 The error margin is, consequently, guaranteed possibly
around 5-10%. Monalisa Bhinge
Project Estimation
In order to complete a successful project, following
parameters of the project are considered
o Scope of the work to be done
o The risk to be incurred
o The resources required
o The task to be accomplished
o The cost to be expended
o The schedule to be followed

Elements of an Estimate
To generate a good estimate, a project manager must have:
o A work breakdown structure (WBS), or a list of tasks which need to be
completed.
o An effort estimation is required for each task
o A list of assumptions which are necessary for making the estimate
o Consent among the project teams that the estimate will accurate
4

Monalisa Bhinge
Project Estimation Process

Monalisa Bhinge
Size Estimation
 One program can be written in C, C++, Java, or any high
level or low level languages.
 The estimation of size is very critical and difficult area of the
project planning.
 It is very difficult to find out the size of the software.
 Programs are written line by line which is called size of the
program.
 Two methods
 Lines of Code (LOC)
 Function count (FPA)

Effort estimation
 Based on size, we can estimate how big team is required.
 Total project can be breakdown into related activities.
 Divide activities into tasks and measure it.
 Estimate the effort required to complete each task. 6
Size-Activity-Task-Effort-(Person hours/day) Monalisa Bhinge
Schedule Estimation
 Number of people working on the project.
 Activity divided
 Start and Finish time
Rule of thumb-
Schedule in months= 3.0*(effort-month)1/3

Cost Estimation
 Labor, hardware & software purchase or rentals, travel,
telecommunication, training courses, office space, etc.

Monalisa Bhinge
Work Breakdown structure
“A hierarchical decomposition of the total scope of work to
be carried out by the project team to accomplish the project
objectives and create the required deliverables.”

Monalisa Bhinge
WBS Design Principles
• 100% rule
• Mutually exclusive elements
• Plan outcomes, not actions
• Level of detail
• Coding scheme
• Terminal element

Example

Monalisa Bhinge
Different methods of estimation
 COCOMO Model

 Delphi cost estimation Model

 Function Point analysis

 Gantt Chart

 PERT Chart

 Critical Path Method

10

Monalisa Bhinge
 11

Monalisa Bhinge
COCOMO Model
 Constructive Cost Model
 Developed by Barry Boehm in 1981
 It predicts the efforts & schedule of a software product
based on the size of the software.
 It estimates the number of man-months it will take to
develop the software product.
 It is an algorithmic model which uses a basic regression
formula.
 Fundamentally it uses LOC for estimation.

Hierarchy of cost estimation model

 Basic model
 Intermediate model
 Detailed model
12

Monalisa Bhinge
Three modes (classes) of software development
projects
Software development project can be classified into one of the
following three categories based on the development
complexity: organic, semidetached, and embedded.
In order to classify a product into the identified modes, Boehm
not only considered the characteristics of the product but also
those of the development team and development
environment.
 Organic
‘small teams’, ‘good experience’ ‘familiar’ environment(s/w,
h/w, operational, etc. ), ‘less’ innovation, ‘no tight’ deadlines.

Eg. Payroll system, Inventory system, Data Processing systems

A development project can be treated of the organic type, if

the project deals with developing a well-understood application 13
program, the size of the development team is reasonably
small, and the team members are experienced in developing
Monalisa Bhinge
 Semi-detached
‘medium teams’, ‘mixed experience’ ‘less familiar’
environment, ‘medium’ innovation, ‘medium’ deadlines.
Eg. Operating System, DBMS, Compilers, Utility programs

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.

 Embedded
‘large teams’, ‘very little previous experience’ ‘new’
environment (significant changes), ‘major’ innovation’, ‘tight’
deadlines.
Eg. ATM, Air traffic Control, Real time system programs

A development project is treated to be of an embedded type, if the 14

software being developed is strongly coupled to complex
Monalisa Bhinge
hardware, or if the stringent regulations on the operational
Basic Model
 It is static model
 It provides an accurate size of the project
 It deals with LOC
Estimated effort (E) = a*(KLOC)b person month
Development time (D) = c*(effort)d month
People required = E person
D
Productivity = KLOC KLOC/person month
E
where,
KLOC-is the estimated size in Kilo Lines of Code
a,b,c,d– constant parameter for software project
Project a b c d

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

15
Embedded 3.6 1.20 2.5 0.32
Monalisa Bhinge
Q. Suppose a project was estimated by 400KLOC. Calculate the effort required &
development time for each of the three classes.
Sol.
E= a*(KLOC)b person month Project a b c d
D = c*(effort) d
month
Size = 400 KLOC Organic 2.4 1.05 2.5 0.38
 Organic
Semidetache 3.0 1.12 2.5 0.35
E= 2.4*(400)1.05 = 1295.31 PM d
D= 2.5*(1295.31)0.38 = 38.07 M
 Semidetached Embedded 3.6 1.20 2.5 0.32
E= 3.0*(400)1.12 = 2462.79 PM
D= 2.5*(2462.79)0.35 = 38.45 M
 Embedded

E= 3.6*(400)1.20 = 4772.81 PM
D= 2.5*(4772.81)0.32 = 37.5 M

Q. A project size of 200 KLOC is to be developed. Software development team has average
experience in similar type of projects. The project schedule is not very tight. Calculate the
effort & development time of the project.
Sol.
Semidetached…..(average experience, not very tight schedule)
E= 3.0(200)1.12 = 1133.12 PM 16
D= 2.5(1133.12)0.35= 29.3 M
Monalisa Bhinge
Intermediate Model
 Recognize & estimate effort in terms of size and fifteen
cost driver.
 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
Four areas for drivers
 Product Attributes
 Computer Attributes
 Personnel Attributes
 Project Attributes
These 15 attributes receives a rating on a six point scale as
very low, low, nominal, high, very high and extra high.

17

Monalisa Bhinge
1. Product Attributes
 RELY --- Required Software Reliability
 DATA --- Data Base Size
Cost Very Low Nomin Hig Very
 CPLX --- Software Product Complexity Driver Low al h High
Product attribute
2. Computer Attributes RELY 0.75 0.88 1.00 1.15 1.40
 TIME --- Execution Time Constraint DATA - 0.94 1.00 1.08 1.16
 STOR --- Main Storage Constraint
CPLX 0.70 0.85 1.00 1.15 1.30
Computer Attribute
 VIRT --- Virtual Machine Volatility
TIME - - 1.00 1.11 1.30
 TURN --- Computer Turnaround Time STOR - - 1.00 1.06 1.21
VIRT - 0.87 1.00 1.15 1.30
3. Personnel Attributes TURN - 0.87 1.00 1.07 1.15
 ACAP --- Analyst Capability Personnel Attribute
 AEXP --- Applications Experience ACAP 1.46 1.19 1.00 0.86 0.71
AEXP 1.29 1.13 1.00 0.91 0.82
 PCAP --- Programmer Capability
PCAP 1.42 1.17 1.00 0.86 0.70
 VEXP --- Virtual Machine Experience
VEXP 1.21 1.10 1.00 0.90 -
 LEXP --- Programming Language Experience LEXP 1.14 1.07 1.00 0.95 -
Project Attribute
4. Project Attributes MODP 1.24 1.10 1.00 0.91 0.82
 TOOL 1.24 1.10 1.00 0.91 0.83
MODP --- Modern Programming Practices
SCED 1.23 1.08 1.00 1.04 1.10
 TOOL --- Use of Software Tools
 SCED --- Required Development Schedule
18

Monalisa Bhinge
E= a (KLOC)b * EAF
D = c (E)d

Where,
E- total effort
D- development time
KLOC- size
a,b,c,d- constant parameters
EAF- Effort Adjustment Factor

EAF is the effort which is adjusted with the use of reusable

components i.e. the effort is not required again (adjusted) to
write the code because it is already present in the reusable
component.
(calculated by multiplying the parameter values of
different cost drivers) 19

Monalisa Bhinge
Q. You as a project manager are required to give efforts estimation for a
project of size 240 KLOC for all classes of project. In addition project also
requires: Project a b c d
Storage constraint is high (1.06)
Organic 3.2 1.05 2.5 0.38
Programmer capability is low(1.17)
Database size is low(0.94) Semidetache 3.0 1.12 2.5 0.35
d
Remaining all drivers are treated as Nominal
Sol: Embedded 2.8 1.20 2.5 0.32
EAF= 1.06*1.17*0.94*1.00=1.16
Organic – E= 3.2(240)1.05 * 1.16 = 1171.72 PM
Semidetached - E= 3.0(240)1.12 * 1.16 = 1611.24 PM
Embedded - E= 2.8(240)1.20 * 1.16 = 2332.75 PM
Q. For a given project estimated size of 300 KLOC. Calculate the effort,
schedule time for development by considering developer having very high
application experience and very low programming experience.
Sol:
Size 300KLOC
AEXP- 0.82 & LEXP – 1.14 (refer attribute table)
Mixed experience so Semidetached mode
20
EAF= 0.82*1.14 = 0.9348
E = 3.0 * (300)1.12 * 0.9348 = 1668.07 PM Monalisa Bhinge

D = 2.5 * (1668.07)0.35 = 33.55 M

Q. You as a project manager are required to give efforts estimation for a project
of size 240 KLOC for all classes of project. For development project also
requires:
Execution time constraint is high -1.11
Database size is high – 1.08
Programmer capability is very high – 0.70
Modern programming practices very low – 1.10
Remaining factors/ drivers are Nominal
Q. A new project with estimated 400 KLOC system has to be developed. For the
development project also requires:
Software reliability is high
Product complexity is high
Analyst capability is high
Programming experience is low
Storage capacity is high
Remaining all driver are treated as Nominal. Calculate the effort, development
time, Average staff size and productivity of the project.
Q. A new project with estimated 400 KLOC embedded system has to be
developed. Project manager has a choice of hiring from 2 pools of developers.
Very highly capable with very little experience in programming language. OR 21
Developer of low quality but lot of programming experience. Which is the
Monalisa Bhinge
better choice.
Q. A project 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, average staff size of the
project by using semi-detached mode of COCOMO model.
Q. You as a Project Manger are required to give efforts estimation for a project
of size 240 KLOC for all classes of project. In addition it also reqires-
a) Storage constraint is High(1.06)
b) Programmer capability of Low(1.17)
c) Database size is low (0.94)
d) Remaining all drivers are treated as Nominal

22

Monalisa Bhinge
Detailed Model
Phase sensitive development
A software development process typically consists of the
following stages:
 Requirements Analysis
 Design (High Level + Detailed)
 Implementation & Coding
 Testing (Unit + Integration)

The following table gives the recommended percentage

distribution of Effort and Development Time for these stages:

Req Design, Implementation Testing

Analysis HLD + DD

Effort 23% 29% 22% 21% 100%

TDEV 39% 25% 15% 21% 100%

23

Monalisa Bhinge
Delphi Cost Estimation
 Delphi method was developed in 1950 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.
Wideband Delphi Technique
 In 1970 Barry Boehm & John Farquher originated the
Wideband Variant of the delphi method.
 The term wideband means it involves greater interaction &
more communication between the participants.
 The team comprises the project manager, moderator,
experts & representatives from the development team.
 Under this method of software estimation, the project
specifications would be given to a few experts & their
opinion is taken.
 Wideband Delphi is a repeatable estimation process
24
because it consists of a straightforward set of steps that
can be performed the same way each time Monalisa Bhinge
Steps in Delphi
Step 1: Choose the team
Step 2: Kickoff Meeting
Step 3: Individual Preparation
Step 4: Estimation Session
Step 5: Assemble Tasks
Step 6: Review Results

25

Monalisa Bhinge
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.
 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.

Step 2: Kickoff Meeting

 The project manager must make sure that each team
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. 26
 The team agrees on a unit of estimation. Monalisa Bhinge
Step 3: Individual Preparation
 Each team member independently generates a set of
preparation results.
 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.
Wide band Delphi estimation Sheet

27

Monalisa Bhinge
Step 4: Estimation Session
 During the estimation session, the team comes to a consensus
on the effort required for each task in the WBS.
 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
 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. These
disagreements are usually about the tasks themselves.
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 28 team is
Monalisa Bhinge

unwilling to revise estimates.

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, estimates and assumptions.
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

29

Monalisa Bhinge
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.

30

Monalisa Bhinge
Step5.6 − The moderator collects the changed estimates from all the
team members and plots them on the Round 2 line.
Inthis round, the range will be narrower compared to the earlier one, as it is more
consensus based.

Step5.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. 31

The team members then once again combine the changes in the task Monalisa
estimate to
Bhinge

arrive at the total project estimate.

Step5.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 converged to an acceptably narrow range.

● All team members are unwilling to change their latest estimates.
● The allotted Estimation meeting time is over.

32

Monalisa Bhinge
Step 6: Review Results
The project manager reviews the final task list with the
estimation team. 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.

33

Monalisa Bhinge
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 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.

34
● The estimation results may not be what the management wants to
Monalisa Bhinge
hear.
Function Point Analysis (FP Analysis)
 Function Point Analysis was initially developed by Allan J. Albercht
in 1979 at IBM and it has been further modified by the
International Function Point Users Group (IFPUG).
 FP Analysis is used to make estimate of the software project,
including its testing in terms of functionality or function size of the
software product.
 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 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.
35
 The functional size of the product is measured in terms of the
Monalisa Bhinge
function point, which is a standard of measurement to measure the
Function counts (Function Points)
 Function point are measures from users point of view that on

the what the user request & receives in return from the
system.
 The principle behind FPA is decomposed into functional

units:
1) Inputs – Information entering into the system.
2) Outputs – information leaving the system.
3) Enquiries – Request for instant access to the
information
4) Internal Logical Files (ILF) – Information held within
system
5) External Interface Files – Information held by other that
is used by the system being analyzed.

36

Monalisa Bhinge
Objectives/Goals of FP Analysis:
1. The objective of FPA is to measure functionality that the user
requests and receives.
2. The objective of FPA is to measure software development and
maintenance independently of technology used for
implementation.
3. It should be simple enough to minimize the overhead of the
measurement process.
4. It should be a consistent measure among various projects and
organizations.
5. To measure & provide the software application functional size to
the client, customer etc. i.e., users point of view(what the user
receives from software & user requests from software).
6. Used to measure software project development(focus on what
functionality is being delivered)
37

Monalisa Bhinge
 USER

ENQUIRIES

INPUTS ILF
USER OTHER
APPLICATION
OUTPUTS SYSTEM EIF

Function Point Analysis ‘s Functional Units system (Relationship of user,

system & functional units)
ILF- Internal Logical Files
EIF- External Interface Files

38

Monalisa Bhinge
Two categories of functional units
1. Data Function Types:
 Internal logical files (ILF): A user identifiable group of
logically related data or control information maintained
within system.
 External Interface files (EIF):A user identifiable group of
logically related data or control information referenced by
system, but maintained within another system .
2. Transactional function Types
 External Input (EI): Process the data or control the

information that comes from the outside of the system.

 External output (EO): Generates the data or control

information to be sent outside of the system.

 External Enquiry (EQ): Elementary process that is made

up of an input-output combination
The functional complexities are multiplied with the
corresponding weights against each function & the values
are added up, to determine UFP(unadjusted Function Point) of39
the subsystem
Monalisa Bhinge
Counting Function Points: The five function units are ranked according to their
complexity.
(J=3)
(i=5)
Functional Units Weighting Factors
Low Average High
External Inputs (EI) 3 4 6
External Outputs (EO) 4 5 7
External Enquiries (EQ) 3 4 6
Internal Logical Files (ILF) 7 10 15
External Interface Files (EIF) 5 7 10

The procedure to calculate Unadjusted Function

3 Point(UFP) in mathematical
5
form are as follows
UFP = Z ij W ij
i=1 J=1
Where i indicates the row and j indicates the column
Wij is the entry of the ith row and jth column
40
Zij is the count of the number of functional units of type i that
have been classified as having the complexity corresponding Monalisa Bhinge

to column j
 14

 The final no. of functional points is arrived at by multiplying the UFP by

an adjustment factor that isi=1
determined by considering 14 aspects of the
processing complexity.
 FP is calculated as follows:
FP = UFP*CAF
Where CAF is complexity adjustment factor

CAF = [0.65 + 0.01 * fi ]

fi (i=1 to 14) are the degrees for influence and are based on
response to questions noted in table.
41

Monalisa Bhinge
Rate each factor on a scale of 0 to 5
1) 0 – no influence
2) 1 – incidental
3) 2 – Moderate
4) 3 – Average
5) 4 – Significant
6) 5 - Essential
1. Does the system require reliable back-up & recovery?
2. Is data communication required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing heavily utilized operational
environment?
6. Does the on line data entry require the input transaction to be built
over multiple screens or operations?

7. Does the system require on line data entry?

8. Are the master files updated on line?
9. Is the inputs, outputs, files or inquiries complex?
10.Is the internal processing complex?
11.Is the code designed to be reusable?
12.Are conversion and installation included in the
design?
13.Is the system designed for multiple installation in 42
different organizations?
14.Is the application designed to facilitate change andMonalisa Bhinge
ease of use by the user?
 Case Study for FPA
Consider a project with the following functional units:
no. of user inputs =50
no. of user outputs =40
no. of user enquiries =35
no. of user files =06
no. of external interfaces =04
Assume all complexity adjustment factors and weighting factors
are average. Compute the function points for the project
Solution –
UFP = ∑i=1 to 5 ∑j=1to3 ZijWij
UFP = 50*4 + 40*5 + 35*4 + 6*10 + 4*7
= 200+200+140+60+28
= 628
CAF = (0.65 + 0.01 ∑Fi)
= (0.65 + 0.01 (14*3))
= 0.65+0.42
= 1.07
43
FP = UFP * CAF
= 628*1.07 Monalisa Bhinge

= 671.96
 Compute the FP for the following data
User input = 24 – average
User output = 46 – low
EQ = 8 – high
Files = 4 – low
EI = 2 – average
Various processing complexity factors are
4,1,0,3,3,5,4,4,3,3,2,2,4,5
Sol:
14

fi = 4+1+0+3+3+5+4+4+3+3+2+2+4+5= 43
i=1

UFP = 542
CAF = 0.28
FP = UFP * CAF
44
= 151.48
Monalisa Bhinge
Consider a project with following functional units
1) No. of user Inputs-55
2) No. of user outputs- 25
3) No. of user Enquries-30
4) No. of user files-05
5) No of external Interfaces-02
In addition to the above system requires
a) Critical level of data communication(5)
b) Code reusability(4)
c) Performance is significant(4)
d) System is not designed for multiple installations(0)
e) Other complexity factors are treated as average
Compute Function Points for this project when the weighting factors are
average.

45

Monalisa Bhinge
CMM – Capability Maturity Model
 The Capability Maturity Model (CMM) is a methodology used to
develop and refine an organization's software development
process.
 The Capability Maturity Model (CMM) is a registered service
mark of Carnegie Mellon University (CMU)
 It is a development model created after study of data collected
from organizations that contracted with the U.S. Department of
Defense, who funded the research.
 This model became the foundation from which Carnegie Mellon
established the Software Engineering Institute (SEI) in 1984.
 The term "maturity" relates to the degree of formality and
optimization of processes, from ad hoc practices, to formally
defined steps, to managed result metrics, to active
optimization of the processes.
 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 46
level is an expensive and time-consuming process. Monalisa Bhinge
 Initial (chaotic, ad hoc, individual heroics) - the starting
point for use of a new or undocumented repeat process.
 Repeatable - the process is at least documented
sufficiently such that repeating the same steps may be
attempted.
 Defined - the process is defined/confirmed as a standard
business process, and decomposed to levels 0, 1 and 2
(the latter being Work Instructions).
 Managed - the process is quantitatively managed in
accordance with agreed-upon metrics.
 Optimizing - process management includes deliberate
process optimization/improvement.

47

Monalisa Bhinge
1. Initial –
 No required processes
2. Repeatable –
 Manage requirements
 Plan and track projects
 Manage suppliers
 Manage product configurations
 Measure projects
 Assist and assure policy compliance
3. Defined –
 Establish improvement infrastructure
 Identify required software processes
 Define common software processes
 Deploy and manage processes
 Collect process-level data
 Provide organization-wide training
 Coordinate with non-software groups
4. Quantitatively Managed –
 Manage processes quantitatively
 Establish capability baselines

5. Optimizing –
 Develop change infrastructure 48

 Evaluate and deploy improvements Monalisa Bhinge

 Eliminate causes of defects
Key Process Aera’s in CMM

49

Monalisa Bhinge
Software Configuration management (SCM)
In Software Engineering, Software Configuration Management 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. 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, 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
50
● Helps to develop coordination among stakeholders
Monalisa Bhinge
● SCM process is also beneficial to control the costs involved in making
Any change in the software configuration Items will affect the 51
final product. Therefore, changes to configuration items need to
Monalisa Bhinge
be controlled and managed.
Tasks in SCM process
● Configuration Identification
● Baselines
● Change Control
● Configuration Status Accounting
● Configuration Audits and Reviews

52

Monalisa Bhinge
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. 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, 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 named login_v1.2.php
53
where v1.2 stands for the version number of the file
 Instead of naming folder "Code" it should be named "Code_D"Monalisa
whereBhinge
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.
 A specification that has been formally reviewed and agreed upon, that is

now ready for use in future development, and that can only be changed
through formal change management procedures.

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.

54

Monalisa Bhinge
 CHANGE CONTROL
Need fro change is
recognized
Request is queued for action, ECO Change request from user
generated Developer evaluates
Change report is generated
Assign individuals to configuration objects
Change control authority decides

“check out” configuration items Change request is denied

Make the change
User is informed
Review (audit) the change

“check in” the configuration item that have been changes

Establish a baseline for testing

Perform quality assurance & testing activities

“promote” changes for inclusion in next release

Rebuild appropriate version of software

Review the change to all configuration items

Include changes in new version
Monalisa Bhinge
Distribute the new version
Configuration Status Accounting
 Configuration status reporting sometimes called status accounting is SCM
tasks that answers following questions

1.What happened?
2.Who did it?
3.When did it happen?
4.What else will be affected?

 Output from CSR may be placed in an online database or web site so that
software developers or maintainers can access change information.

56

Monalisa Bhinge
Configuration Audit & Reviews
 Version control & change control help the software developer to maintain
order.
 Most successful control mechanism track a change only until an ECO is
generated.
 Formal technical review & SCM audit focus on proper implementation of
change.
 A SCM audit complements the FTR by addressing following question

1. Has the change specified in ECO been made? Have any modification been
incorporated?
2. Has a FTR been conducted to assess technical correctness?
3. Has the software process been followed, & have software engineering
standards been properly applied?
4. Has the change been highlighted in the SCI? have the change date &
change author been specified? Do the attributes of the configuration
object reflect the change?
5. Have SCM procedures for nothing the change, recording it and reporting
it been followed?
6. Have all related SCI’s been properly updated?
57

Monalisa Bhinge
 IT COULDN’T BE MORE
SIMPLE:

58

Monalisa Bhinge