Software Project

Management
Organization of this Lecture:

 Introduction to Project Planning

 Software Cost Estimation
 Cost Estimation Models
 Software Size Metrics
 Empirical Estimation
 Heuristic Estimation
 COCOMO
 Staffing Level Estimation
 Effect of Schedule Compression on Cost
 Summary
Introduction
 Many software projects fail:
 due to faulty project management practices:
It is important to learn different aspects of
software project management.

 Goal of software project management:

 enable a group of engineers to work
efficiently towards successful
completion of a software project.
Responsibility of project
managers
 Project proposal writing,
 Project cost estimation,
 Scheduling,
 Project staffing,
 Project monitoring and control,
 Software configuration management,
 Risk management,
 Managerial report writing and
presentations, etc.
Introduction
 A project manager’s activities are varied.
 can be broadly classified into:
project planning,
project monitoring and control
activities.

 Once a project is found to be feasible,

 project managers undertake project planning.
Project Planning Activities
 Project planning consists of the following
essential activities:

 Estimating the following attributes of the project:

 Project size: What will be problem complexity
in terms of the effort and time required to
develop the product?
 Cost: How much is it going to cost to develop
the project?
 Duration: How long is it going to take to
complete development?
 Effort: How much effort would be required?
Project Planning Activities
 The effectiveness of the subsequent
planning activities is based on the
accuracy of these estimations.
 Scheduling manpower and other resources
 Staff organization and staffing plans
 Risk identification, analysis, and moderation
planning
 Miscellaneous plans such as quality
assurance plan, configuration management
plan, etc.
Project planning

Requires utmost care and attention ---

commitments to unrealistic time and
resource estimates result in:
 irritating delays.
 customer dissatisfaction
 adverse affect on team morale
poor quality work
 project failure.
Sliding Window Planning
 Planning a project over a number of stages protects
managers from making big commitments too early. This
technique of staggered planning is known as Sliding
Window Planning.

 In the sliding window technique, starting with an initial

plan, the project is planned more accurately in
successive development stages.

 At the start of a project, project managers have incomplete

knowledge about the details of the project.

 Their information base gradually improves as the project

progresses through different phases.

 After the completion of every phase, the project managers

can plan each subsequent phase more accurately and with
increasing levels of confidence.
 Organization of SPMP Document
 After planning is complete:
 Document the plans in a Software Project
Management Plan(SPMP) document.
 Introduction (Objectives, Major Functions, Performance
Issues, Management and Technical Constraints)
 Project Estimates (Historical Data, Estimation Techniques,
Effort, Cost, and Project Duration Estimates)
 Project Resources Plan (People, Hardware and Software,
Special Resources)
 Schedules (Work Breakdown Structure, Task Network, Gantt
Chart Representation, PERT Chart Representation)
 Risk Management Plan (Risk Analysis, Risk Identification,
Risk Estimation, Abatement Procedures)
 Project Tracking and Control Plan
 Miscellaneous Plans(Process Tailoring, Quality Assurance)
Software Project Size Estimation

 The project size is a measure of the problem

complexity in terms of the effort and time
required to develop the product.

 Two metrics widely used to estimate size:

 lines of code (LOC)
 function point (FP).
Software Project Size Estimation

Effort Cost
Estimation Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling
Software Cost Estimation

Three main approaches to

estimation:
 Empirical
 Heuristic
 Analytical
Software Project Size/Cost Estimation

Empirical techniques:
 an educated guess based on past
experience.
Heuristic techniques:
 assume that the characteristics to be
estimated can be expressed in terms of
some mathematical expression.
Analytical techniques:
 derive the required results starting from
certain simple assumptions.
Software Size Metrics
LOC (Lines of Code):
 Simplest among all metrics available to
estimate project size.

 Using this metric, the project size is estimated

by counting the number of source instructions
in the developed program.

 While counting the number of source

instructions, lines used for commenting the
code and the header lines should be ignored.
LOC
 Accurate estimation of the LOC count at the
beginning of a project is very difficult.

 To estimate project managers usually divide the

problem into modules, submodules until the sizes
of the different leaf-level modules can be
approximately predicted.

 Past experience in developing similar products is

helpful.

 By using the estimation of the lowest level

modules, project managers arrive at the total size
estimation.
Disadvantages of Using LOC
 Size can vary with coding style.
 Focuses on coding activity alone.
 Correlates poorly with quality and efficiency of
code.
 Penalizes higher level programming languages,
code reuse, etc.
 Difficult to estimate LOC from problem description.
 So not useful for project planning
Function Point Metric
 Overcomes some of the shortcomings of the LOC
metric

 Estimate the size of a software product directly

from the problem specification.

 Size of a software product is directly dependent on

the number of different functions or features it
supports.
 For example, the issue book feature of a Library
Automation Software takes the name of the book as input
and displays its location and the number of copies
available.
 Thus, a computation of the number of input and the output
data values to a system gives some indication of the
number of functions supported by the system.
 Albrecht postulated that in addition to the number of basic
functions that a software performs, the size is also
dependent on the number of files and the number of
interfaces.
FP calculations

1) Calculate UFP (Unadjusted FP)

2) Refine Parameters
3) Refine UFP based on complexity
 Step1: Calculate UFP
Determine the number of components (EI, EO, EQ, ILF, and ELF)
1. EI − The number of external inputs. These are elementary
processes in which derived data passes across the boundary
from outside to inside. In an example library database system,
enter an existing patron's library card number.

2. EO − The number of external output. These are

elementary processes in which derived data passes across the
boundary from inside to outside. In an example library
database system, display a list of books checked out to a
patron.

3. EQ − The number of external queries. These are

elementary processes with both input and output components
that result in data retrieval from one or more internal logical
files and external interface files. In an example library
database system, determine what books are currently checked
4. ILF − The number of internal log files. These are user
identifiable groups of logically related data that resides
entirely within the applications boundary that are
maintained through external inputs. In an example library
database system, the file of books in the library.

5. ELF − The number of external log files. These are

user identifiable groups of logically related data that are
used for reference purposes only, and which reside
entirely outside the system. In an example library
database system, the file that contains transactions in the
library's billing system.
Some more clarity on factors

 Number of inputs: Each data item input by the user is

counted.
 Data inputs and inquiries are different. Inquiries are user
commands such as print-account-balance.
 Individual data items input by the user are not considered in the
calculation of the number of inputs, but a group of related inputs
are considered as a single input.
 Example, while entering the data concerning an employee to an
employee pay roll software; the data items name, age, address,
phone number, etc. are together considered as a single input.
 Number of outputs: The outputs considered refer
to reports printed, screen outputs, error messages
etc.

 Number of inquiries: user commands which

require specific action by the system.

 Number of files: Each logical file is counted.

 Number of interfaces: Used to exchange

information with other systems. Examples of such
interfaces are data files on tapes, disks,
communication links with other systems etc.
Step1: Unadjusted Function Point (UFP)

(200 + 200 + 140 + 60 + 28) = 628

step2 : Refine parameters
step3 :Refine UFP based on complexity
Summarize FP calculation
1)step1 : Calculate UFP (Unadjusted FP)
UFP=4 * #inputs + 5 * #Outputs + 4 *
#inquiries + 10 * #files + 10 * #interfaces

2) step2 : Refine Parameters - fine tune 5 above

parameters Simple/Avg/Complex

3) Refine UFP based on complexity

a) determine TCF = 0.65 +(0.01*DI)
(assume DI as 42 (14*3) if nothing is mentioned )
b) FP = UFP * TCF
Q1
UFP = 4*50 + 5*40 + 4*35 + 6*10 + 4*10
=628 or 640
step 2 : refine - Not applicable
step 3: calculate TCF
TCF = 0.65 + (0.01 *42) = 1.07

Finally FP = UFP * TCF = 640 * 1.07

Calculate FP problem
Q:2
 EI - INPUT -
1. Registration form fill up.
2. Purchase
 EO - Output
1. Successful registration process, customer data created
2. Update purchase record
3. Entries against CN are reset at the last of the year
 EQ - Queries (only fetch, no updates)
1. Get the annual report of sales against each customer
 Internal files (Data)
1. Customer details
2. Daily purhase details.
 External Interfaces - None

UFP = (2*4) +(3*5) + (1*4)+(2*10) +(0*10)

UFP = (2*4) + {(2*5) +(1*4)} + (1*4)+(2*10) +(0*10) =

46
Calulate tech complexity

Technical Complexity Factor (TCF)

Take avg = 3
TCF = 0.65+ 0.01*DI
TCF = 0.65 + 0.01 *(14*3) = 1.07
FP = TCF * UFP
= 46 * 1.07
= 49.22
Function Point Metric (CONT.)

Suffers from a major drawback:

 the size of a function is considered
to be independent of its algorithmic
complexity.
Extend function point metric:
 Feature Point metric:
 considers an extra parameter:
Algorithm Complexity: Greater is the
effort required to develop it and therefore its
size should be larger compared to simpler
functions.
Function Point Metric (CONT.)

Proponents claim:
 FP is language independent.
 Size can be easily derived from
problem description

Opponents claim:
 it is subjective --- Different people
can come up with different
estimates for the same problem.
Software Cost Estimation

Three main approaches to

estimation:
 Empirical
 Heuristic
 Analytical
Empirical Size Estimation Techniques
 Based on making an educated guess of the project
parameters. Prior experience with development of
similar products is helpful.
 Two popular empirical estimation techniques are:
1)Expert judgement technique and
2) Delphi cost estimation.
 Expert Judgement: Estimates the cost of the different
components (i.e. modules or subsystems) of the system
and then combines them to arrive at the overall
estimate. Suffers from individual bias.
 Experts divide a software product into component
units:
e.g. GUI, database module, data communication
module, billing module, etc.
 Add up the guesses for each of the components.
Delphi Estimation:
 Delphi Estimation:
 Overcomes some of the problems of expert
judgement.

 Team of Experts and a coordinator.

 Experts carry out estimation independently:
 mention the unusual characteristic of the
product which has influenced his estimation.
 coordinator notes down any extraordinary
rationale:
circulates among experts.
 Experts re-estimate.
 Experts never meet each other to discuss their
viewpoints as many estimators may easily get
Influenced.
Heuristic Estimation Techniques
Single Variable Model:
 Models provide a means to estimate the desired
characteristics of a problem, using some previously
estimated basic (independent) characteristic of the
software product such as its size, staff etc.
Estimated Parameter=c1*ed1
e= characteristic which already have been calculated.
c1 and d1 are constants- calculated from past projects.

Multivariable Model:
 Assumes that the parameter to be estimated depends on
more than one characteristic.
 Estimated Resources=c1*e1d1+c2*e2d2+----
 e1 and e2 are the basic independent characteristics of the
software already estimated.
 c1, c2, d1, d2, are constants.
 Multivariable Estimation Models are expected to give more
accurate estimate compared to the Single Variable Models.
 COCOMO Model
 COCOMO (COnstructive COst MOdel) is a
Constructive Cost Estimation Model proposed by
Boehm.

 COCOMO Product classes correspond to:

 application, utility and system programs
respectively.
Data processing and scientific programs are
considered to be application programs.
Compilers, linkers, editors, etc., are utility
programs.
Operating systems and real-time system
programs, etc. are system programs.
Elaboration of Product classes
 Divides software product developments into
3 categories:
 Organic:
 Relatively small groups
working to develop well-understood
applications.
 Semidetached:
 Project team consists of a mixture of
experienced and inexperienced staff.
 Embedded:
 The software is strongly coupled to
complex hardware, or real-time systems.
Cocomo product categories
COCOMO Model (CONT.)

 For each of the three product categories:

 From size estimation (in KLOC), Boehm provides
equations to predict:
project duration in months
effort in programmer-months

 Boehm obtained these equations:

 examined historical data collected from a large
number of actual projects.
COCOMO Model (CONT.)

Software cost estimation is

done through three stages:
 Basic COCOMO,
 Intermediate COCOMO,
 Complete COCOMO.
Useful terms
Person months : Person month is a measurement unit
for effort in software engineering. 1 person month
means effort put by a person in one month. But 100
person does not mean, work effort put by 100 person in
one month or 1 person in 100 months.
 Effort: Amount of labor that will be required to
complete a task. It is measured in person-months
units.
 Schedule: Simply means the amount of time required
for the completion of the job, which is, of course,
proportional to the effort put. It is measured in the
units of time such as weeks, months.
 Productivity : Size (KLOC) / Effort (PM) (KLOC per
person-month)
 Avg Staffing : Effort (PM) / Schedule (M)
Unit : Persons
Development Effort
Estimation
Organic :
 Effort = 2.4 (KLOC)^1.05 PM
 Semi-detached:
 Effort = 3.0(KLOC)^1.12 PM
 Embedded:
 Effort = 3.6 (KLOC)^1.20PM
Development Time Estimation

Organic:
 Tdev = 2.5 (Effort)^0.38
Months
Semi-detached:
 Tdev = 2.5 (Effort)^0.35
Months
Embedded:
Basic COCOMO Model (CONT.)

 Development time
 sublinear(slope<1)
me
function of product
size.
b i
 When product size 18 Em Sem

increases two 14

times,
 development time 30K
60K
does not double.
Si
 Time taken:
 almost same for all
the three product
categories.
Basic COCOMO Model (CONT.)

Development time does not

increase linearly with product
size:
 For larger products more
parallel activities can be
identified:
can be carried out
simultaneously by a number of
Basic COCOMO Model (CONT.)

Development time is roughly the

same for all the three categories of
products:
 For example, a 60 KLOC program can be
developed in approximately 18 months
regardless of whether it is of organic, semi-
detached, or embedded type.
 There is more scope for parallel activities
for system and application programs,
than utility programs.
Basic COCOMO Model (CONT.)

Effort is
somewhat
super-
linear(slope
>1) in
problem size.
Basic COCOMO Example
 Example
 The size of an organic software product has been
estimated to be 32,000 lines of source code. Assume
that the average salary of software engineers
be Rs. 15,000/- per month. Determine the effort
required to develop the software product and the
nominal development time and cost.

 Effort = 2.4*(32)^1.05 = 91 PM
 Nominal development time = 2.5*(91)^0.38 = 14
months
 Cost required to develop the product = 91 х
15,000 = Rs. 1365,000/-
Intermediate COCOMO

Basic COCOMO model assumes

 effort and development time depend on
product size alone.
However, several parameters affect
effort and development time:
Reliability requirements
Availability of CASE tools and modern
facilities to the developers
Size of data to be handled
Intermediate COCOMO

For accurate estimation,

 the effect of all relevant parameters
must be considered:
 Intermediate COCOMO model
recognizes this fact:
refines the initial estimate obtained by
the basic COCOMO by using a set of
15 cost drivers (multipliers).
Classification of Cost Drivers and their attributes:
Intermediate COCOMO (CONT.)

If modern programming

practices are used,
 initial estimates are scaled
downwards.
If there are stringent
reliability requirements on the
product :
 initial estimate is scaled
Intermediate COCOMO (CONT.)

 Cost driver classes:

 Product: characteristics of the product that include
inherent complexity of the product, reliability
requirements of the product, etc.

 Computer: Execution time, storage requirements,

etc.

 Personnel: Experience of personnel, programming

capability, analysis capability, etc.

 Development Environment: Sophistication of the

tools used for software development.
Intermediate COCOMO (CONT.)

 Effort Adjustment Factor

 The Effort Adjustment Factor in the effort equation is simply
the product of the effort multipliers corresponding to each of
the cost drivers for your project.
 For example, if your project is rated Very High for Complexity
(effort multiplier of 1.34), and Low for Language & Tools
Experience (effort multiplier of 1.09), and all of the other cost
drivers are rated to be Nominal (effort multiplier of 1.00), the
EAF is the product of 1.34 and 1.09.
 Effort Adjustment Factor = EAF = 1.30 * 1.10 = 1.43
Intermediate Model: An Example

DSI = Delivered Source Instructions/LOC

Shortcoming of basic and
intermediate COCOMO models

Both models:
 consider a software product as a single
homogeneous entity:
 However, most large systems are made
up of several smaller sub-systems.
Some sub-systems may be considered as
organic type, some may be considered
embedded, etc.
for some the reliability requirements may be
high, and so on.
Complete COCOMO
 Cost of each sub-system is estimated separately.
 Costs of the sub-systems are added to obtain total
cost.
 Reduces the margin of error in the final estimate.

 Example: A Management Information System (MIS) for

an organization having offices at several places across
the country:
 Database part (semi-detached)
 Graphical User Interface (GUI) part (organic)
 Communication part (embedded)
 Costs of the components are estimated separately:
 summed up to give the overall cost of the system.
Analytical Estimation Techniques
 Analytical estimation techniques derive the
required results starting with basic assumptions
regarding the project.

 Analytical techniques do have scientific basis.

 Halstead’s software science is an example of an

analytical technique.
 Can be used to derive some interesting results
starting with a few simple assumptions.
 Useful for estimating software maintenance efforts.
 In fact, it outperforms both empirical and heuristic
techniques when used for predicting software
maintenance efforts.
Halstead's Software Science
 A computer program is an implementation of an algorithm
considered to be a collection of tokens which can be
classified as either operators or operands.
 An analytical technique to estimate:
 size,
 development effort,
 development time.
 Halstead used a few primitive program parameters
 number of operators and operands (unique, total)
 Derived expressions for:
 over all program length,
 potential minimum volume
 actual volume,
 language level,
 effort, and
 development time.
Staffing Level Estimation
 Once the effort required to develop a software has
been determined, it is necessary to determine the
staffing requirement for the project.

 Number of personnel required during any

development project:
 not constant.

 Norden in 1958 analyzed many R&D projects, and

observed:
 Rayleigh curve represents the number of full-
time personnel required at any time.
Rayleigh Curve

 Rayleigh curve
is specified by
two
parameters:
 td the time at
which the
curve reaches
its maximum
 K the total
area under
the curve.
L=f(K, td)
Rayleigh Curve
 Very small number of engineers are needed at the
beginning of a project
 carry out planning and specification.

 As the project progresses:

 more detailed work is required,
 number of engineers slowly increases and reaches a
peak.
 Putnam observed that:
 the time at which the Rayleigh curve reaches its
maximum value
corresponds to system testing and product release.
 After system testing,
the number of project staff falls till product
installation and delivery.
 Project Scheduling
 It involves deciding which tasks would be taken up
when. In order to schedule the project activities, a
software project manager needs to do the
following task:
 Identify all the tasks needed to complete the project.
 Break down large tasks into small activities.
 Determine the dependency among different activities.
 Establish the most likely estimates for the time
durations necessary to complete the activities.
 Plan the starting and ending dates for various
activities.
 Determine the critical path. A critical path is the chain
of activities that determines the duration of the
project.
Work breakdown structure
 Decompose a given task set recursively into small activities.

 Root of the tree is labelled by the problem name.

 Each node of the tree is broken down into smaller activities

that are made the children of the node.

 Each activity is recursively decomposed into smaller sub-

activities until at the leaf level.
Activity networks and critical path method
 Activity network shows the different activities making up a
project, their estimated durations, and interdependencies.

 Each activity is represented by a rectangular node and the

duration of the activity is shown alongside each task.
Critical Path Method (CPM)
 The Critical Path Method (CPM) can help you keep your
projects on track. Critical path schedules...
 Identify the activities that must be completed on time in order
to complete the whole project on time.
 Show you which tasks can be delayed and for how long without
impacting the overall project schedule.
 Calculate the minimum amount of time it will take to complete
the project.
 The CPM has four key elements...
 Critical Path Analysis
 Float Determination
 Early Start & Early Finish Calculation
 Late Start & Late Finish Calculation
Critical path calculation
Critical path calculation
(contd.)
Float Determination/Slack Time
 Float (slack time) is the amount of time an activity
can slip before it causes your project to be delayed.

 Using the critical path diagram from the previous section,

Activities 2, 3, and 4 are on the critical path so they have a
float of zero.

 The next longest path is Activities 1, 3, and 4. Since Activities

3 and 4 are also on the critical path, their float will remain as
zero.

 For any remaining activities, in this case Activity 1, the float

will be the duration of the critical path minus the duration of
this path. 14 - 12 = 2. So Activity 1 has a float of 2.

 Next longest path is Activities 2 and 5.

Activity 2 is on the critical path so it will have
a float of zero. Activity 5 has a float of 14 - 9,
which is 5.
ES, EF, LS, LF
Early Start and Early Finish
 Indicates the earliest time an activity on a network path
can start and earliest it can finish.
 If you decide to start an activity on its early start (assuming
previous activities on that network path are completed on
their early finishes), that activity can finish on its early
finish (if it does not slip).
 And when the last activity on a network path is completed
by its early finish, you have all the resources of those
activities at your disposal to deploy on other high risk
activities.
Calculate ES and EF
ES and EF
 Late start(LS) and Late finish(LF)
 Indicates the latest time an
activity on a network path
can start and latest it can
finish.
 Knowing how late the last
activity on the network path
can start and still finish within
the time to not impact critical
path, will let you decide how
much of flexibility you want to
exercise on its schedule.
 However, once the last activity
on the network path starts on
its late start day it should not
slip, else it will impact project
completion date.
Calculate LS and LF
 Remember!: Start with the critical path, beginning at the
last activity’s late finish.
 Step 1: Late finish of last activity on the critical
path is same as its early finish. Write this number at
the bottom right corner.
 Step 2: Calculate late start of this activity as the
late finish minus activity duration plus 1. This
calculation has the same reason – start and finish are
both included in the duration. Write this number at the
bottom left corner.
 Step 3: Write this late start of the activity minus 1,
as the late finish of previous activity. Continue this
way all way till you reach the late start of first activity
on the critical path.
 Step 4: Select the network path with second
highest total duration, and write late starts and
LS and LF
Activity network diagram and critical path model
Activity network diagram and critical path model
 Gantt chart
 Named after its developer Henry Grantt. Its a bar chart.
 Gantt charts are mainly used to allocate resources to
activities.
 The resources allocated to activities include staff, hardware,
and software. a special type of bar chart where each bar
represents an activity.
 The bars are drawn along a time line. Each bar is an
activity.
 The length of each bar is proportional to the duration of
time planned for the corresponding activity.
Use:
 Planning and
 resource utilization.
 PERT chart
 PERT (Project Evaluation and Review Technique) charts
consist of a network of boxes and arrows.
 The boxes represent activities and the arrows represent task
dependencies. PERT chart represents the statistical variations
in the project estimates assuming a normal distribution.
 Thus, in a PERT chart instead of making a single estimate for
each task, 1. pessimistic, worst case (W)
 2. most likely estimates (M),
 3. optimistic estimates (O) are made.
 There can be may critical paths, depending on various
permutations of the estimates of each task.
 A critical path in a PERT chart is shown by using thicker arrows.
Draw the Activity Network and Gantt Chart for the
activities tabulated below

Activity Predecessor Duration (days)

A - 10
B - 5
C B 3
D A, C 4
E A, C 5
F D 6
G E 5
H F, G 5

4
F
D 4 6
A 5
1 3 6 7
10 5 H
B 5 3
C E 5
2 G
5
 Gantt Chart
 Critical path-1 A→D→F→H B→C Slack time 2
days
 Critical Path-2 A→E→G→H
 Project Duration = 25 days A
Activity
 GANTT CHART
B
Activity Predecesso Duration (days)
r
A - 10 C
D
B - 5
C B 3
E
D A, C 4
E A, C 5 F

F D 6
G
G E 5
H F, G 5 H
Risk management
Project risks: risks concern varies forms of
 budgetary,
 schedule,
 personnel,
 resource, and
 customer-related problems. An important project risk is
schedule slippage.
 Technical risks: risks concern
 potential design,
 implementation,
 interfacing,
 testing, and
 maintenance problems. Most technical risks occur due to
the development team’s insufficient knowledge about the
project.
 Business risks: risks include risks of
 building an excellent product that no one wants,
 losing budgetary or personnel commitments, etc.
Risk assessment:
 to rank the risks in terms of their damage causing
potential. p = r * s where
p is the priority with which the risk must
be handled,
r is the probability of the risk becoming
true,
s is the severity of damage caused due
to the risk becoming true.
Risk containment
 Risks of a project are assessed, plans must be made to contain
the most damaging and the most likely risks.
 Different risks require different containment procedures. Three
main strategies to plan for risk containment:
 Avoid the risk: discussing with the customer to change the
requirements to reduce the scope of the work, giving
incentives to the engineers to avoid the risk of manpower
turnover, etc.
 Transfer the risk: Involves getting the risky component
developed by a third party, buying insurance cover, etc.
 Risk reduction: Planning ways to contain the damage due to
a risk. For example, if there is risk that some key personnel
might leave, new recruitment may be planned.

Risk leverage
 Different strategies must be considered for handling a risk, the
project manager must consider the cost of handling the risk and
the corresponding reduction of risk. More formally,
risk leverage = (risk exposure before reduction – risk
exposure after reduction) / (cost of reduction)
Software Configuration Management (SCM)

 Configuration of a SW product
 Release, version and revision of SW product
 Necessity of SCM
 Principal activities of SCM
 Configuration identification.
 Configuration control.
 Configuration management tools.
Software Configuration Management
 The deliverables of a SW product consist of a number
of objects, e.g.
 source code,
 design document,
 SRS document,
 test document(plan and script),
 user’s manual, etc.
 These objects are modified by many software
engineers through out development cycle.
 The state of each object changes as bugs are detected
and fixed during development .

 The configuration of the software is the state of all

project deliverables at any point of time.
 SCM deals with effectively tracking and controlling the
configuration of a software during its life cycle.
 Release vs. Version vs. Revision of SW

 A new version results from a

significant change in
functionality, technology, or
the platform
 Example: one version of a SW might
be Unix-based, another Windows
based.
 revision refers to minor bug
fix .
 A release results from bug fix,
minor enhancements to the
functionality, usability
 A new release of SW is an
improved system replacing the
old one.
 Systems are described as
Necessity of SCM
 To control access to deliverable objects with a view to
avoiding the following problems
 Inconsistency problem when the objects are replicated.
 Problems associated with concurrent access.
 Providing a stable development environment.
 System accounting and status information.
 Handling variants. If a bug is found in one of the variants, it has to
be fixed in all variants
SCM activities
 Configuration identification :
 deciding which objects (configuration items ) are to be kept track
of.
 Configuration control :
 ensuring that changes to a system happen without ambiguity.
 Baseline
 When an effective SCM is in place, the manager freezes the objects to
form a base line.
 A baseline is the status of all the objects under configuration control.
When any of the objects under configuration control is changed , a new
baseline is formed.
Configuration item identification
 Categories of objects:
 Controlled objects: are under Configuration Control (CC) . Formal
procedures followed to change them.
 Precontrolled objects: are not yet under CC, but will eventually be under
CC.
 Uncontrolled objects: are not subjected to CC
 Controllable objects include both controlled and precontrolled objects;
examples:
SRS document,
Design documents,
Source code ,
Test cases
The SCM plan is written during the project planning phase and it lists
all controlled objects.
 Configuration Control (CC):

 process of managing changes to controlled objects. Allows

authorized changes to the controlled objects and prevents
unauthorized changes .
 In order to change a controlled object such as a module,
a developer can get a private copy of the module by a
reserve operation .
 Configuration management tools allow only one person
to reserve a module at a time. Once an object is
reserved, it does not allow any one else to reserve this
module until the reserved module is restored .
 Changing the Baseline
 When one needs to change an object under configuration
control, he is provided with a copy of the base line item.
 The requester makes changes to his private copy.
 After modifications, updated item replaces the old item and
a new base line gets formed .
Reserve and restore operation in configuration control
 obtains a private copy of the module through a reserve
operation.
 carries out all changes on this private copy.
 restoring the changed module to the baseline requires the
permission of a change control board(CCB).
 Except for very large projects, the functions of the CCB are
discharged by the project manager himself.
summary
 Organization Structure
 Functional Organization:
 Engineers are organized into functional groups, e.g.
 specification, design, coding, testing, maintenance, etc.
 Engineers from functional groups get assigned to different
projects

 Problems of different complexities and sizes require different

team structures:
 Chief-programmer team
 Democratic team
 Mixed organization
Team Organization
Mixed team organization
Chief Programmer Team
 A senior engineer provides technical leadership:
 partitions the task among the team members.
 verifies and integrates the products developed by
the members.

 Works well when

 the task is well understood
also within the intellectual grasp of a single
individual,
 importance of early completion outweighs other
factors
team morale, personal development, etc.

 Chief programmer team is subject to single point

failure:
 too much responsibility and authority is assigned to
the chief programmer.
Democratic Teams
 Suitable for:
 small projects requiring less than five or six engineers
 research-oriented projects
 A manager provides administrative leadership:
 at different times different members of the group
provide technical leadership.
 Democratic organization provides
 higher morale and job satisfaction to the engineers
 therefore leads to less employee turnover.

 Disadvantage:
 team members may waste a lot time arguing about trivial
points:
 absence of any authority in the team.
Mixed Control Team
Organization
Draws upon ideas from both:
 democratic organization and
 chief-programmer team organization.
Communication is limited
 to a small group that is most likely to
benefit from it.
Suitable for large organizations.