Course Title:

BIT401: Software Project Management

Unit 8: Monitoring and Control

Unit 8: Monitoring and Control

Introduction;
Creating the Framework;
Collecting the Data;
Visualizing Progress;
Earned Value Analysis ;
Change Control;
Software Configuration Management
 Unit 8: Monitoring and Control

Monitoring and Control:

After publishing work schedules and initiating a project, "Monitoring and Control“
activities start.
 "Monitoring and Control" refers to the processes and activities undertaken to
track project performance, identify deviations from the plan, and take corrective
action when necessary.
Monitoring - involves systematically observing the project's progress, comparing it
against the planned objectives, schedule, budget, and quality standards. It includes
collecting data, measuring performance metrics, and assessing how well the project is
meeting its goals.
Control - Once deviations or variances are identified through monitoring, control
involves taking corrective actions to bring the project back on track. This may include
adjusting plans, reallocating resources, revising schedules, or making other changes
to mitigate risks and ensure project success.
“Monitoring and Control” are crucial aspects of project management as they enable project
managers to stay informed about project status, anticipate challenges, and proactively manage
issues to achieve desired outcomes efficiently.

Unit 8: Monitoring and Control

OBJECTIVES:

When you have completed this chapter you will be able to:
 monitor the progress of projects;
 assess the risk of slippage;
 visualize and assess the state of a project;
 revise targets to correct or counteract drift;
 control changes to a project’s requirements.
 Unit 8: Monitoring and Control

Introduction

Unit 8: Monitoring and Control

Introduction:

After publishing work schedules and initiating a project, it is crucial to shift attention
towards monitoring progress. This involves comparing actual achievements with the
established schedule and, if necessary, adjusting plans to realign the project with its
targets. Emphasizing the importance of creating monitorable plans with clearly
defined completion points.
 This chapter explores the gathering of information on project progress and
outlines actions necessary to ensure goal attainment.
 Additionally, it addresses strategies for managing external changes, specifically
alterations in project requirements.
 Unit 8: Monitoring and Control

Creating the Framework

Unit 8: Monitoring and Control

Creating the Framework:
Exercising control over a project involves regular monitoring to
compare actual progress with planned targets. Deviations may
occur, such as delays, quality shortfalls, inadequate
functionality, or exceeding costs.
The project control cycle, illustrated in Figure, emphasizes
continuous monitoring and, if necessary, re-planning to realign
the project with its goals.
After project completion, it's crucial to analyze the experience
gained, learning from mistakes to enhance future project
planning.
This chapter primarily focuses on delays in meeting target
dates and costs going over target in project management.
Few terminologies - we define following terms
 Responsibility
 Assessing progress
 Setting checkpoints
 Taking snapshots
 Unit 8: Monitoring and Control
Responsibility:
The overall responsibility for project progress lies with the project steering
committee, project management board, or Project Board in PRINCE2. The project
manager has day-to-day responsibility, delegating tasks to team leaders in larger
projects. Small projects involve direct reporting to the project manager, while team
leaders collate progress reports for incorporation into project-level reports for the
steering committee and client. Reporting methods vary in formality, frequency, and
medium, emphasizing the need for a balance between informal and formal
communication in project progress reporting.

Categories of reporting

Project reporting structures

Unit 8: Monitoring and Control

Assessing progress:
Project progress assessment involves routine collection of some information and event-
triggered data. Emphasis is placed on objective and tangible metrics, such as the delivery
of reports. However, in certain cases, assessments may rely on estimates regarding the
completion proportion of ongoing activities.
Setting checkpoints:
It is essential to set a series of checkpoints in the initial activity plan. Checkpoints may
be:
 regular (monthly, for example);
 tied to specific events such as the production of a report or other deliverable.
Taking snapshots(frequency of report):
Progress reports frequency depends on project size and risk. Team leaders may assess
daily, while project managers may prefer weekly or monthly reports. Higher levels
require less frequent and detailed reporting. Individual developers benefit from weekly
reports to capture fresh information and facilitate reflection. Major progress reviews
occur at project review points, such as PRINCE2's End Stage Assessment at the end of
each project stage, consideration of its future are undertaken.
 Unit 8: Monitoring and Control

Collecting the Data

“Collecting the Data” refers to the process of gathering information or facts
from various sources to be used for analysis, decision-making, or further
study. Data collection can happen in many forms, depending on the context.
From our text book, two types:
1. Partial completion reporting
2. Traffic-light (Red/Amber/Green (RAG) reporting)

Unit 8: Monitoring and Control

Collecting the Data:
Managers typically break down lengthy tasks into manageable one to two-week activities. Gathering
information on partially completed tasks and forecasting remaining work is challenging. Estimating
progress is easier with a series of products, where counting specifications or screen layouts provides a
measure of advancement. In some cases, intermediate products can be used as in-activity milestones.
The first “successful compilation of a program”, for example, might be considered a milestone even
though it is not a final product.
1. Partial completion reporting
2. Red/Amber/Green (RAG) reporting

A traffic-light assessment A weekly timesheet and progress review form

 Unit 8: Monitoring and Control
Collecting the Data - Partial completion reporting
Organizations commonly utilize standard accounting systems with weekly timesheets to allocate staff
time to specific projects. While such systems track work hours and associated charges, they may lack
details about project progress and task scheduling. To address this, organizations often modify existing
accounting systems, such as weekly timesheets, by breaking down jobs to the activity level. This
adaptation includes gathering information about the work done, in addition to tracking time. For
enhanced project control, reporting forms like the one in Figure below may be employed, seeking details
on completion date slippage and estimates of task completeness. Various reporting templates exist, and
some managers may prefer obtaining information on hours worked and estimates for task completion
instead of percentage completion.

A weekly timesheet and progress review form

Unit 8: Monitoring and Control

Collecting the Data - Red/Amber/Green (RAG) reporting
The traffic-light method addresses objections to partial completion reporting by replacing estimated
completion dates with team members' estimates of meeting the planned target date. It involves using a
traffic-light system to indicate the likelihood of meeting the deadline.
One way of doing this is the traffic-light method. This consists of the following steps:
 identify the key (first level) elements for assessment in a piece of work;
 break these key elements into constituent elements (second level);
 assess each of the second-level elements on the scale green(G) for ‘on target’, amber(A) for ‘not
on target but recoverable’, and red(R) for ‘not on target and recoverable only with difficulty’;
 review all the second-level assessments to arrive at first-level assessments;
 review first- and second-level assessments to produce an overall assessment.
The traffic-light assessment focuses on identifying the risk of non-
achievement in project activities, without estimating progress or
quantifying delays. After assessing all activities, the project
manager evaluates the overall project status. Critical activities
marked as amber or red prompt further consideration and may lead
to schedule revisions. Non-critical activities become concerning if
classified as red, particularly if their entire float is at risk of being
consumed. A traffic-light assessment
 Unit 8: Monitoring and Control
Review:
From a managerial standpoint, reviewing work products is crucial for monitoring
project progress and ensuring quality. Projects involve numerous iterations of work
products like requirements, design, and code, each prone to defects. While testing is
effective for executable code, non-executable work products need defect removal too.
Reviews are highly effective, more cost-efficient than testing, and have evolved from
focusing on code to encompassing various work products.
1. Utility of review
2. Candidate work products for review
3. Review roles
4. Review process
5. Reviewers data collection

Unit 8: Monitoring and Control

Project Termination Review:
A manager decides when to terminate a project, and after making the decision, a
project review meeting is recommended. These reviews, applicable to successful,
failed, or prematurely abandoned projects, mark the official closure. They offer
valuable learning opportunities from mistakes and successes, enabling teams to
improve methods. The project termination review summary report benefits not only
the terminated project but also other teams, making dissemination within the
organization crucial. Project termination doesn't necessarily imply failure; it can
occur for various reasons, including successful completion. Recognizing when project
objectives can't be met prompts negotiated closure, showing wisdom in project
management. Even failed projects shouldn't be viewed entirely negatively, as they
offer insights and lessons. Statistics indicate that around 31% of projects are canceled
during the development phase. Deciding when to terminate a project requires wisdom
to prevent it from becoming a resource drain without substantial achievements.
1. Reasons for project termination
2. Project termination process
 Unit 8: Monitoring and Control

Visualizing Progress
"Visualizing progress" refers to the act of using visual tools, techniques, or
representations to track, illustrate, or communicate the advancement of a task,
project, or goal. The idea is to make abstract or complex progress data easier
to understand through charts, graphs, diagrams, dashboards, timelines, or other
visual formats.

Various visualizing progress methods are:

 The Gantt chart
 The slip chart
 The timeline

Unit 8: Monitoring and Control

Visualizing Progress:
After gathering information on the progress of a project, a manager requires an
effective means of project progress data. There are various methods of presenting a
picture of the project and its future. Gantt charts offer a static snapshot and timeline
charts which illustrate the project's evolution and transformations over time.
Various visualizing progress methods are
 The Gantt chart
 The slip chart
 The timeline
 Cost Monitoring
 Unit 8: Monitoring and Control
Visualizing Progress: Various visualizing progress methods are
 The Gantt chart - Gantt chart is a visual tool to represent the timeline of a
project. It displays tasks or activities along with their durations, dependencies,
and deadlines.

Unit 8: Monitoring and Control

Visualizing Progress: Various visualizing progress methods are
 The slip chart - A slip chart is a visual tool used to track and represent delays or
schedule slippages in a project. It helps project managers monitor whether project
tasks or milestones are being completed on time or if they are falling behind
schedule.
It is a visual indication of those activities that are not progressing to schedule – the
more the slip line bends, the greater the variation from the plan. Additional slip lines
are added at intervals and, as they build up, the project manager will gain an idea as
to whether the project is improving (subsequent slip lines bend less) or not. A very
jagged slip line indicates a need for rescheduling.

The slip chart emphasizes the relative position of each activity

 Unit 8: Monitoring and Control
Visualizing Progress: Various visualizing progress methods are
 The timeline - The timeline chart is a method of recording and displaying the
way in which targets have changed throughout the duration of the project.
One disadvantage of the charts described so far is that they do not show clearly the
slippage of the project completion date through the life of the project.
Figure shows a timeline chart at the end of the sixth week. Planned time is plotted
along the horizontal axis and elapsed time down the vertical axis. The lines
meandering down the chart represent scheduled activity completion dates.

Timeline chart at the end of week six.

Unit 8: Monitoring and Control

Earned Value Analysis
Earned Value Analysis (EVA) is a project management technique originating from
the USA's Department of Defence. It assigns a 'value' to each task based on original
expenditure forecasts, akin to the price a contractor might agree to complete the work.
This assigned value is the planned value (PV) or budgeted cost of work scheduled
(BCWS). Tasks not started have an earned value of zero, and upon completion, they
are credited with the original planned value. The total credited value at any point is
the earned value (EV) or budgeted cost of work performed (BCWP). EV serves as
an analogous representation of the agreed price for completed work, and it can be
expressed in monetary terms, staff time, or as a percentage of the PV. Earned Value
Analysis (EVA) is considered a refinement of cost monitoring in project
management.
There are different methods for assigning earned value. Of these, we prefer the 0/100
technique for software development. The 50/50 technique can give a false sense of
security by over-valuing the reporting of activity starts. The milestone technique
might be appropriate for activities with a long duration estimate but, in such cases, it
is better to break that activity into a number of smaller ones.
 Unit 8: Monitoring and Control

Summary of Basic Terms

of
Earned Value Analysis

 Baseline Budget - Planned Value (PV)

 Earned Value (EV)
 Schedule Variance (SV)
 Time Variance (TV)
 Cost Variance(CV)
 Performance Ratios

Unit 8: Monitoring and Control

Earned Value Analysis

Planned Value (PV) – PV represents the value of the work that was planned to be done by each
activity in the project schedule, based on the project's approved budget and schedule. PV
serves as a baseline against which the actual performance of the project is measured.
Earned Value (EV) - EV is calculated by determining the value of the work that has been
completed at a specific point in time, based on the budgeted cost of the work that was planned
to be done.
Schedule Variance (SV) - Schedule Variance (SV) is: EV−PV
Time Variance (TV) - time variance compare the planned start and end dates of tasks or
activities with their actual start and end dates. The result can be positive or negative.
Positive Time Variance: Indicates that tasks or activities are ahead of schedule, meaning
they have been completed faster than planned.
Negative Time Variance: Indicates that tasks or activities are behind schedule, meaning
they have taken longer to complete than planned.
Cost Variance(CV) - Cost Variance (CV) is: CV=EV−AC
Where: EV = Earned Value (the value of the work actually performed) ;
AC(Actual Cost) - the actual cost incurred to accomplish the work.
 Unit 8: Monitoring and Control

Earned Value Analysis

Performance Ratios: Performance ratios in project management are quantitative
measures used to assess the efficiency, effectiveness, and overall performance of a
project. These ratios help project managers and stakeholders evaluate various aspects
of project execution and make informed decisions to ensure project success. Some
common performance ratios in project management include:
Schedule Performance Index (SPI): SPI compares the earned value (the value of work
completed) to the planned value (the value of work planned to be completed) to
assess schedule efficiency. An SPI value greater than 1 indicates that the project is
ahead of schedule, while a value less than 1 indicates that it is behind schedule.
Cost Performance Index (CPI): CPI compares the earned value to the actual cost to
assess cost efficiency. A CPI value greater than 1 indicates that the project is under
budget, while a value less than 1 indicates that it is over budget.
To-Complete Performance Index (TCPI): TCPI forecasts the required CPI for the
remaining work to meet certain project objectives, such as budget goals. It helps
project managers understand the future performance needed to achieve project
targets.

Unit 8: Monitoring and Control

Earned Value Analysis

Performance Ratios:
Schedule Variance (SV): SV measures the variance between the earned value and the planned
value in terms of schedule. A positive SV indicates that the project is ahead of schedule, while
a negative SV indicates that it is behind schedule.
Cost Variance (CV): CV measures the variance between the earned value and the actual cost
incurred. A positive CV indicates that the project is under budget, while a negative CV
indicates that it is over budget.
Return on Investment (ROI): ROI measures the profitability of a project by comparing the
project's benefits (typically financial) to its costs. It helps stakeholders assess the viability and
success of the project.
Resource Utilization Rate: This ratio evaluates how efficiently project resources (such as
manpower, equipment, and materials) are being utilized. It helps identify over allocation or
under utilization of resources, enabling adjustments to optimize resource allocation.
By regularly monitoring and analyzing these performance ratios, project managers can identify
areas of improvement, make informed decisions, and take corrective actions to keep the
project on track and within its objectives.
 Unit 8: Monitoring and Control

Earned Value Analysis

-
Examples

Unit 8: Monitoring and Control

Earned Value Analysis
 Earned Value(EV) analysis is based on assigning a ‘value’ to each task or work
package (as identified in the WBS) based on the original expenditure forecasts.
One way of looking at this is as the equivalent of the price that might be agreed
by a contractor to do the unit of work.
 The assigned value is the original budgeted cost for the item and is known as the
planned value (PV) or budgeted cost of work scheduled (BCWS).
 A task that has not started is assigned an earned value of zero and when it has
been completed, the project is credited with the original planned value of the
task.
 The total value credited to a project at any point is known as the earned value
(EV) or budgeted cost of work performed (BCWP) and this can be represented as
a money value, an amount of staff time or as a percentage of the PV.
Note: EV is thus analogous to the agreed price to be paid to the contractor once the
work is completed.
 Unit 8: Monitoring and Control
Earned Value Analysis
When tasks are initiated but remain incomplete, it is essential to apply a consistent method for
assigning Earned Value(EV). Typical approaches in software projects include:
 the 0/100 technique: where a task is assigned a value of zero until such time that it is completed
when it is given a value of 100% of the budgeted value;
 the 50/50 technique: where a task is assigned a value of 50% of its value as soon as it is started and
then given a value of 100% once it is complete – this matches some contractual arrangements
where a contractor is given half the agreed price when starting the work, perhaps to help pay for
raw materials, and the remainder on successful completion;
 the 75/25 technique: where the task is assigned 75% on starting and 25% on completion – this is
often used when a large item of equipment is being bought: 75% is paid when the equipment is
actually delivered and the remainder when installation and testing has been satisfactorily
completed;
 the milestone technique: where a task is given a value based on the achievement of milestones that
have been assigned values as part of the original budget plan;
 percentage complete: in some cases there may be a way of objectively measuring the amount of
work completed – for example, as part of the implementation of an information system, a number
of data records have to be manually typed into a database and the actual number so far completed
can be objectively counted.

Unit 8: Monitoring and Control

The baseline budget:
The first stage in setting up an Earned Value analysis is to create the baseline budget. The
baseline budget is based on the project plan and shows the forecast growth in earned value
through time. Earned value may be measured in monetary values but, in the case of staff-
intensive projects such as software development, it is common to measure earned value in
person-hours or workdays. Baseline budget is based on workdays and is using the 0/100
technique for crediting earned value to the project.

Earliest Finish date

34/237 *100
Arrange the Task based on the Earliest Finish date

64+20

79

Precedence network showing scheduled start Total project duration

and completion dates Baseline budget
 Unit 8: Monitoring and Control
Monitoring Earned Value:
Having created the baseline budget, the next task is to monitor earned value as the project
progresses. This is done by monitoring the completion of tasks (or activity starts and milestone
achievements in the case of the other crediting techniques).

Figure shows earned value analysis at the start of week 12 of the project. Note that here both
PV and EV are measured in ‘work-days’ and that the 0/100 rule is being applied. The earned
value (EV) is clearly lagging behind the baseline budget, indicating that the project is behind
schedule. By studying Figure, can you tell exactly what has gone wrong with her project and
what the consequences might be?

Unit 8: Monitoring and Control

Schedule Variance (SV):
The Schedule Variance is measured in cost terms as EV – PV and indicates the
degree to which the value of completed work differs from that planned.
For example, that work with a PV of Rs 40,000 should have been completed
by now. In fact, some of that work has not been done so that the EV is only Rs
35,000.
The SV would therefore be Rs 35,000 – Rs 40,000 = – Rs5,000.

A negative SV means the project is behind schedule.

 Unit 8: Monitoring and Control
Time Variance (TV):
This is the difference between the time when the achievement of the current
earned value was planned to occur and the time now. In this case, the current
EV should have been achieved in the early part of month 9 and as the time
now is the end of month 11, the TV is about –1.75 months.
Figure indicates the time variance (TV).

An earned value tracking chart

Unit 8: Monitoring and Control

Cost Variance (CV):

This indicates the difference between the earned value or budgeted cost and
the actual cost of completed work.

Cost Variance (CV) = Earned Value(EV) – Actual Value(AC)

Say that when the SV above was calculated as –£5,000, £55,000 had actually
been spent to get the EV. The CV in this case would have been £35,000 –
£55,000 or –£20,000.
It can also be an indicator of the accuracy of the original cost estimates. A
negative CV means that the project is over cost.
 Unit 8: Monitoring and Control
Performance Ratios:
Two ratios are commonly tracked:
Cost Performance Index (CPI) = EV/AC
Schedule Performance Index (SPI) = EV/PV
Using the examples above, CPI would be £35,000/£55,000, that is, 0.64, and
SPI would be £35,000/£40,000, that is, 0.88. The two ratios can be thought of
as a ‘value-for-money’ indices. A value greater than one indicates that work is
being completed better than planned, whereas a value of less than one means
that work is costing more than and/or proceeding more slowly than planned.

Unit 8: Monitoring and Control

Performance Ratios:
Cost Performance Index (CPI) can be used to produce a revised cost estimate for the project
(Estimate At Completion – EAC).
Estimate At Completion(EAC) = BAC/CPI ; where Budget At Completion (BAC) is the
current projected budget for the project.
If the BAC was £100,000 then a revised Estimate At Completion (EAC) would be
£100,000/0.64 or £156,250.
Similarly, the current Schedule Performance Index (SPI) can be used to project the possible
duration of the project given the current rate of progress. Say the planned total duration for the
project is 23 months – in earned value terminology this is the Schedule At Completion (SAC).
A Time Estimate At Completion(TEAC) = SAC/SPI.
In this case it would be 23/0.88, that is, 26.14 months. This is only an approximate guide:
where there are several parallel chains of activities being carried out concurrently – the project
duration will depend on the degree to which the activities that have been delayed are on the
critical path.
 Unit 8: Monitoring and Control
Performance Ratios:
In the same way that Tracking cumulative expenditure to show revised expenditure forecasts,
we can augment the simple earned value tracking chart with forecasts as illustrated in Figure
9.14.
Earned value analysis has not yet gained universal acceptance for use with software development
projects because a half-completed software project has virtually no value at all. This is to misunderstand
the purpose of earned value analysis, which, as we have seen, is a method for tracking what has been
achieved on a project – measured in terms of the budgeted costs of completed tasks or products.

Tracking cumulative expenditure

FIGURE 9.14 An earned value chart with revised forecasts

Unit 8: Monitoring and Control

Software Configuration Management (SCM)

Change Control
 Change Control Procedures
 Changes in Scope of a System
 Unit 8: Monitoring and Control
Change Control
Change control refers to the process of managing and controlling changes to a
project's scope, schedule, and resources. Change is inevitable in any project, but
effective change control ensures that modifications are carefully evaluated, approved,
and implemented to minimize negative impacts on the project's success.

Unit 8: Monitoring and Control

Change control procedures
A simple change control procedure might have the following steps:
1. One or more users might perceive a need for a modification to a system and ask for a
change request to be passed to the development staff.
2. The user management would consider the change request and, if they approve it, pass it to
the development management. There is a single authorized channel for requests for
change (RFCs) between the client community and the management of the developers.
3. There would be one person within the development area who would receive and process
RFCs. They would delegate a member of staff to look at the request and to report on the
practicality and cost of carrying out the change. The developer would, as part of this,
assess the products that would be affected by the change.
4. The development representative would report back to the user management on the
findings and the user management would decide whether, in view of the cost quoted, they
wish to go ahead.
 Unit 8: Monitoring and Control
Change control procedures
A simple change control procedure might have the following steps:
5. There would be some individual or group who represented the major stakeholders, both users and
developers and also the project sponsor, who would have the authority to prioritize the RFCs for
action. Project managers would allow them accept minor changes as long as they do not exceed
planned cost and delivery targets. There is thus a general principle that the larger the amendment the
higher in the control hierarchy it would have to be reported. A very large number of seemingly
small changes could have a serious accumulative effect on project progress which may call for the
attention of higher management.
6. Once an RFC has been approved for action, one or more developers are authorized to take copies of
the master products that are to be modified. This would need to be done through the Configuration
librarian who update the master copy of requirement specification document.
7. The copies are modified. In the case of software components this would involve modifying the code
and recompiling and testing it.
8. When the development of new versions of the product has been completed the user management
will be notified and copies of the software will be released for user acceptance testing.
9. When the user is satisfied that the products are adequate they will authorize their operational
release. The master copies of configuration items will be replaced.

Unit 8: Monitoring and Control

Software Configuration Management (SCM)

 Unit 8: Monitoring and Control
Software Configuration Management (SCM):
SCM is concerned with tracking and controlling changes to the software. In any
systematic development and maintenance environment, various work products (code,
design document, etc.) associated with the software continually change during the
development as well as the maintenance phase. In a team development environment,
each member of the development or maintenance team would be assigned to handle
some modification requests. Therefore every work product would have to be accessed
and modified by several members. In such a situation, unless a proper configuration
management system is deployed, several problems can appear.
We discuss on following:
 Context in which configuration management is necessary
 Investigate the different problems that a development team might face if it does
not deploy an effective configuration management system
 Configuration management process.

Unit 8: Monitoring and Control

Software Configuration Management (SCM):
Context in which configuration management is necessary - During the
development phase, the work products get modified as development activities are
carried out. During the maintenance phase, the work products change due to various
types of enhancements and adaptations that are carried out including bug fixes. Thus,
the state of the work products continually change both during the development as
well as maintenance phase.
The state of all work products at any point of time is called the configuration of the
software product.
Software configuration management deals with effectively tracking and controlling
the configuration of a software product during its entire life cycle. For effective
configuration management, it is necessary to deploy a configuration management
tool. Thus, we can say that the different concepts associated with configuration
management are carried out in a project with the help of a tool. There are many
configuration management tools available, some are open software that is free of any
licensing fees and others are commercial tools.
 Unit 8: Monitoring and Control
Software Configuration Management (SCM):
Context in which configuration management is necessary - Configuration
management practices include version control and the establishment of baselines.

We must clearly understand terms like:

 Configuration
 Version
 Revision
 Variant
 Baseline

Unit 8: Monitoring and Control

Software Configuration Management (SCM):
Context in which configuration management is necessary - Configuration
management practices include version control and the establishment of baselines.
We must clearly understand terms like configuration, version, revision, variant, and
baseline.
Configuration - The configuration of software is the state of various work products
that are under configuration control. The work products that are under configuration
control are usually referred to as the configuration items. It is convenient to think of a
configuration as a set of fi les representing various work products.
 Unit 8: Monitoring and Control
Software Configuration Management (SCM):
Context in which configuration management is necessary - Configuration
management practices include version control and the establishment of baselines.
We must clearly understand terms like configuration, version, revision, variant, and
baseline.
Version –As development and maintenance activities are carried out on a software
product, its configuration (that is, one or more configuration items) keeps changing. It
often becomes necessary to refer to the configuration that existed at certain point of
time.
Therefore, a version is a configuration that existed at certain point in time. More
technically, versioning is a numbering scheme that helps us identify a specific
configuration at a certain point in time. This is achieved by a configuration
management tool by tagging the files resenting the configuration items with the
version name.

Unit 8: Monitoring and Control

Software Configuration Management (SCM):
Context in which configuration management is necessary - We must clearly
understand terms like configuration, version, revision, variant, and baseline.
Revision –A revision system is a numbering scheme that is used to identify the state
of a configuration item at any time. Each time a work product is updated its state
changes. Thus, we can think of a work product going through a series of updates till it
reaches a desired state. The successive states of a work product are its successive
revisions. Thus each time a configuration item is updated, a new revision gets formed.
It becomes possible to refer to a specific state of a work product by using its revision
number.
Baseline - A baseline is a software configuration that has been formally reviewed and
agreed upon, and serves as a basis for further development.
 Unit 8: Monitoring and Control
Software Configuration Management (SCM):
Context in which configuration management is necessary - We must clearly
understand terms like configuration, version, revision, variant, and baseline.
Variants –Variants are versions that are intended to coexist. Different variants may be
needed to run the software on different operating systems or on different hardware
platforms. For example, one variant of a mathematical computation package might
run on Unix-based machines, another on Microsoft Windows machines. Variants may
also be required to be created when the software is intended to be used with different
levels of sophistication of the functionalities (e.g., novice version, enterprise version,
professional version, etc.). Variants are often created during the operation phase
during the development phase, and as and when software products with overlapping
functionalities are required. Even the initial delivery of software might consist of
several versions and more variants may be created later.

Unit 8: Monitoring and Control

Purpose of software configuration management:
There are several reasons why proper configuration management of the work
products in a project is essential. The following are some of the important problems
that can occur if a proper configuration management system is not used.
 Problems Associated with Concurrent Access
 Undoing Changes
 System Accounting
 Handling Variants
 Accurate Determination of Project Status
 Preventing Unauthorized Access to the Work Products
 Unit 8: Monitoring and Control
Configuration management process:
Configuration management is carried out through the following two principal
activities:
 Configuration Identification: This activity involves deciding which parts of the
system should be kept under configuration management.
 Configuration Control: This activity is used to ensure that changes to a system
occur smoothly.
Configuration Identification:
Project managers normally classify the work products associated with a software
development process into three main categories, viz., controlled, pre-controlled, and
uncontrolled. Controlled work products are those that are put under configuration
control. The team members must follow some formal procedures to change these.
Pre-controlled work products are not yet under configuration control, but will
eventually be under configuration control. Uncontrolled work products will not be
subject to configuration control. Controllable work products include both controlled
and pre-controlled work products.

Unit 8: Monitoring and Control

Configuration management process:
Typical controllable work products include the following:
 Requirements specification document
 Design documents
 Tools used to build the system such as compilers, linkers, lexical analysers,
parsers, etc.
 Source code for each module
 Test cases
 Problem reports
 Unit 8: Monitoring and Control
Configuration management process:
Configuration Control:
Configuration control is part of a configuration management system that most directly
affects the day-to-day operations of developers. Configuration control allows only
authorized changes to the controlled objects and prevents unauthorized changes. The
project manager can give permission to some members to be able to change or access
specific work products.
In order to change a controlled work product such as a code module, a developer can
get a private copy of the module through a reserve operation (see Fig. 9.15).
Configuration management tools allow only one team member to reserve a module at
any time. Once a work product is reserved, it does not allow anyone else to reserve
this module until the reserved module is restored. Thus, by preventing more than one
developer to simultaneously reserve a module, the problems associated with
concurrent access are taken care of.

Unit 8: Monitoring and Control

Configuration management process:
Configuration Control:
 Unit 8: Monitoring and Control
Modifications to a work product under configuration control:
 Developers initiate changes by making a reserve request.
 Reserve requests are honored only if authorized by the project manager for
the specific work product.
 Upon successful execution of the reserve command, a private copy of the
work product is created in the developer's local directory.
 Developers can make necessary changes to the work product on their
private copy.
 After completing changes satisfactorily, they need to restore the changes in
the configuration management repository.
 Restoring the changed work product to the system configuration requires
permission from the Change Control Board (CCB).

Unit 8: Monitoring and Control

Modifications to a work product under configuration control:
The CCB is usually constituted from among the development team members. For
every change that needs to be carried out, the CCB reviews the changes made to the
controlled work product and certifies certain aspects about the change such as
 Change is well-motivated
 Developer has considered and documented the effects of the change
 Changes interact well with the changes made by other developers
 Appropriate people (CCB) have validated the change, e.g., someone has tested
the changed code, and has verified that the change is consistent with the need.
The change control board (CCB) is seldom a group of people. Except for very large
projects, the functions of the change control board are normally discharged solely by
the project manager or some senior member of the development team. Once the CCB
reviews the changes to the module, the project manager updates the old configuration
item through a restore operation. A configuration control tool does not allow a
developer to replace a work product in the configuration with his local copy unless he
gets an authorization from the CCB. Therefore, incompletely modified or improperly
modified work products cannot be updated in the configuration.