Software Project Management

Chapter Four
Risk and Configuration Management Plan

Sem. I – 2023
SITE-AAiT

1
 Risk Management Plan

What is a risk?
Factors or Aspects which are likely to have a negative impact on the projects
performance. It is possibility of a loss or an injury.
Uncertainties which affect the project performance: budget, schedule, quality

Types of Risk
Schedule Risks
Schedule Compression (customer, marketing, etc.)
Cost Risks
Unreasonable Budgets
Requirement Risks
Incorrect
Operational Risks
Incomplete
Validity of assumptions
Unclear or Inconsistent
Performance Risk
Volatile

2
 Risk Management Plan

Risk Management
Any project involves certain risks
We need to manage risks
Purpose of risk management
Ensure that the impact of risk on project’s performance is minimized
Deals with identifying the undesirable events that can occur, the probability of
their occurring, and the loss if an undesirable event does occur
So risk management revolves around risk assessment and risk control

3
 Risk Management Plan

Risk Identification
Produces a list of risks with potential to disrupt your project’s schedule
Sub-activities of risk identification
Checklist
Decision Driven analysis
Assumption analysis
Decomposition analysis

Risk Identification-Check List

1. Personnel shortfalls
Management techniques:
Staffing with top talent
Pre-scheduling key people
Training
2. Unrealistic schedules and budget
Management techniques:
Detailed schedule and cost estimation 4
 Risk Management Plan

Risk Identification-Check List

3. Developing the wrong software functions
Management Techniques:
User Surveys
Prototyping
4. Developing the wrong user interface
Management Techniques:
Prototyping
5. Gold Plating – refers to adding features that are only marginally useful. It consumes
resources and time.
Management techniques:
Requirements scrubbing
Prototyping
Cost-Benefit analysis
6. Stream of Requirement Changes
Management techniques
Incremental development
5
High change threshold
 Risk Management Plan

Risk Identification-Check List

7. Dependency on externally furnished components
Management techniques:
Compatibility analysis
Benchmarking
Cost-benefit analysis
8. Dependency on technology
Management Techniques:
Technical analysis
Cost-benefit analysis

Risk Identification-Decision Driven Analysis

Analyze all decisions taken
Look for decisions derived by non-technical or non- management reasons
Such decisions might be driven by politics, marketing or the desire for short term gain

6
 Risk Management Plan

Risk Identification-Assumption Analysis

Look for optimistic assumptions such as:
Nothing goes wrong
There will be enough rain
No team member will quit
People will put in extra hours if required
External components will be delivered on time

Risk Identification- Decomposition Analysis

20% of the modules cause 80% of the problem
Analyze the modules of the project

7
 Risk Management Plan

Risk Analysis
Estimating size of loss
Loss is easier to see than probability; You can break this down into “chunks” (like
WBS)
Estimating probability of loss
Is subjective, Use team member estimates and have a risk-estimate review
Use Delphi or group-consensus techniques
Use’ gambling analogy’ “how much would you bet”
Use “Adjective Calibration”: highly, likely, probably, improbable, unlikely, highly
unlikely
Other approaches of risk analysis include
Decision Analysis - studying the probability and the outcome of possible decisions
Network Analysis - understanding the task dependencies to decide critical
activities and the probability and cost of their not being completed on time.
Quality Factor Analysis - risks on the various quality factors like reliability and
usability
Performance Analysis- evaluating the performance early through simulation, etc.,
if there are strong performance constraints on the system 8
 Risk Management Plan

Risk Prioritization
Determine impact of each risk
One approach for prioritization is RE
Risk Exposure (RE)
Is expected value of loss due to a particular risk
RE = Probability of Loss * size of loss
Ex: risk is “Facilities not ready on time”
Probability is 25%, size is 4 weeks, RE is 1 week
Ex: risk is “Inadequate design – redesign required”
Probability is 15%, size is 10 weeks, RE is 1.5 weeks
Sum all RE’s to get expected overrun
The higher RE, the higher the priority

9
 Risk Management Plan

Risk Control
Unlike risk assessment, risk control involves active measures taken by PM to minimize
impact.
Has three sub-activities:
Risk management planning
Risk resolution
Risk monitoring

Risk Management Planning

Plans are developed for each risk
The plan for a particular risk needn’t be extensive or elaborate
The plan has five components:
Why it is important and why should it be managed
What should be delivered
Who is responsible for risk management activities
How the risk be abated / minimized
How many resources are needed 10
 Risk Management Plan

Risk Management Planning

Risk management planning strategy:
Risk avoidance
Don’t do it
Ex: shifting the site of a building to earthquake free zone if location is a risk
Risk reduction
Risk transfer
Causing another party to accept, typically by contract or hedging
Ex: Insurance, outsourcing, …
Risk retention
Accept its occurrence
Don’t do anything about it

11
 Risk Management Plan

Risk resolution and Monitoring

Risk resolution is essentially risk management planning implementation
For each risk, specify its risk monitoring- how the measures described in resolution are
executed.

Risk Control Example

Suppose wrong product development is identified as a risk. Identify its strategy,
resolution and monitoring
Solution:
Risk Management planning strategy: reduction
Risk resolution
elicit as much requirement as possible
clarify vague requirements
prepare prototype
Risk Monitoring
dev’pt team leader monitors changes according to the new understanding
PM checks whether the new requirements are addressed
12
 Risk Management Plan

Risk Management Document Template

1. Introduction
2. Risk assessment
2.1 Risk identification
2.2 Risk analysis
2.3 Prioritization
3. Risk Control
3.1 Planning strategies
3.2 Resolution
3.3 Monitoring
Assignment
Prepare RMD for your project

13
 Software Configuration Management

Terminology
A configuration item is a work product that is treated as a single entity for the purpose
of configuration.
A composite of configuration items is defined as a configuration management
aggregate.
Eg.:
Serial port device driver is a CI
Linux OS is a CM Aggregate
A version identifies the state of a configuration item or a configuration at a well defined
point in time.
Variants are versions that are intended to coexist.
A system has multiple variants when it is supported on different OSs and different
hardware platforms (eg. Machintosh, Windows or Linux variant)
A system has also multiple variants when it is delivered with different levels of
functionalities (eg., novice, expert or standard version)
A promotion is a version that has been made available to other developers in the project
It denotes a configuration item that has reached a relatively stable state and that
can be used or reviewed by other developers. 14
 Software Configuration Management

Terminology
A release is a version that has been made available to the client or the users
It denotes that a configuration item has met the quality set by the quality control
team and can be used or reviewed by the users.
A workspace is a library of promotions
A repository is a library of releases.
A software library provides facilities to store, label, and identify versions of the Cis.
Three types of libraries:
Developer’s workspace or Dynamic library
used for everyday development by developers
change is not restricted and controlled by the individual developers
Master directory or controlled library
tracks promotions
change needs to be approved
Software Repository or Static library
tracks releases
promotions need to meet certain control criteria before they become releases 15
 Software Configuration Management

Terminology
A baseline is a version of a CI that has been formally reviewed and agreed on and
which can be changed only through a change request.
A change request is a formal report issued by a user or developer requesting a
modification in a configuration item.
Software Configuration Control Item (SCCI)
Source Item (SI)
Anything suitable for configuration control
Source code, documents, diagrams, etc.
Change Control: process of controlling changes
Proposal, evaluation, approval, scheduling, implementation, tracking
Version Control: Controlling software version releases
Recording and Saving releases
Documenting Release differences
Configuration Control: process of evaluating, approving or disapproving, and
managing changes to SCCIs.
16
 Software Configuration Management

Sources of Change
Development
Need for improving the process, functions and features for effectiveness and
efficiency.
Maintenance
Bugs detected while in use
Growth
Need for moving to a new platform
Expanding the scope
Expanding the system to other domain

Software Configuration Management

The baseline product undergoes continuous changes
A process is required to handle these changes in a systematic and controlled manner.
Such a process is called Software Configuration Management
SCM is very important during all phases starting with Requirements to even
maintenance. 17
 Software Configuration Management

SCM Activities
Three main activities:
Identification of CIs
Change Management Control
Configuration Audit and Status Reporting
Identification of CIs
Software Configuration Control Item (SCCI)
Source Item (SI)
Anything suitable for configuration control
Source code, documents, diagrams, etc.
Requires baseline product which is the basis for subsequent changes.
Baseline products can be split as RAD, SDD, etc
Component identification and naming help to locate and know its status
This activity clearly shows the
components affected by the change requirement
the one that is undergoing a change and
the others affected by the change 18
 Software Configuration Management

SCM Activities …
Change Management Control
Change Control: process of controlling changes
Includes
Program code changes
Requirements and design changes
Version release changes
Essential for developed items
Code, Documentation, etc.
CMC processes
Accept change request from user/developer/customer via change request
form that describes:
The configuration item in question, the proposed change, and the impact
of the change (cost, time, quality)
Analyze the request by
Identifying parties affected by the change
Requesting and collecting their assessments 19
 Software Configuration Management

SCM Activities …
Change Management Control …
CMC processes …
Based on cost, quality, time and utility, and received assessment, evaluate the
change needed
If NO, submit for reconsideration, or reject
If YES do the following:
Rename affected components
Execute the change
Incorporate in the baseline
Update to new status
Update baseline and product database
Change Control Board
Depending on the size of the project, there might be CCB or CM Team
Structure: representatives from each stakeholder party
Dev., QA, Marketing, Mgmt., Customer support
Perform CMC process 20
 Software Configuration Management

SCM Activities …
Configuration Audit & Status Reporting
How can we ensure that the change has been properly implemented and reported?
The answer is threefold:
Formal Technical Review
Focuses on the technical correctness of the modified CI
Addresses for its consistency with other CIs
Configuration Audit
Has the change been made as specified?
Have additional modifications been incorporated?
Has a formal review been conducted?
Are the CMC procedures followed?
Have all related CIs been properly updated
Status reporting
Answers What happened, Who did it?, and When did it happen?
Gives information about CR > Decision > Effected > Affected
SR helps improve communication among all involved 21
 Software Configuration Management

Configuration Management Tools

Many in existence but describe 4 here:
RCS(Revision Control System)
a free tool to control a repository storing all versions of the CIs
To optimize storage, RCS only stores the latest version and the differences
between each version
Doesn’t support branch
To obtain a specific version
developers check out a version into their workspace by specifying version
number or date
To change a CI developers need to lock the item to prevent others from changing
the item
When the change is completed, the developer checks the modified item back into
the repository releasing lock.

22
 Software Configuration Management

Configuration Management Tools

CVS(Concurrent Version System)
a free tool, extends RCS with the concept of branch
Instead of a sequence of differences, CVS stores a tree of differences for each CI
Provides tools for merging two branches detecting overlaps.
Its Change control policy:
Instead of locking a CI, CVS considers each developer to be a separate branch
If a single developer modified a CI between two check-ins, CVS merges the
branch onto the main trunk
If CVS detects a concurrent change, it first attempts to merge the two changes and
then, in case of overlap, notifies the last developer to check-in
Perforce: Commercial replacement for CVS
Clear Case:
Commercial, supports CM aggregates and configurations
A CM aggregate is realized as a directory which is managed as a CI.
Allows the specification of configuration with rules, selecting versions of each CI
a version can be specified by referring to a specific version number or to the
latest version number 23