Configuration management

11/6/2020 1
Terms in CM

11/6/2020 2
 Deviations and Waivers
• Deviation: An authorization to depart from a provision
before the development of an item
• Eg: Some provisions in the specification might not be satisfied by
the development

• Waiver: An authorization to use an item, following its

development, that departs from the provision in some
way
• Eg: Non satisfied provisions in the specifications can be “waived
of” by the customers with extended time period agreed by
developers to complete

11/6/2020 3
 1. Change Initiation
• CR can be initiated by  Developer, QA personnel, a
reviewer, or a user
• In the form of Change Request

Problem Report (PR) Software Change Notice (SCN)

• A special kind of CR
• Cause of change is defect or
bug
• Follows same procedures as
CR
• Cause of change is modifications
to features, source code, design or
in general any implementation
events
• Follows same procedures as CR

• Each Project should have a CR form  to document

proposed change and its disposition

11/6/2020 4
 1. Escalation and Notification
• Escalation
“ The process of increasing the intensity or magnitude of an
issue”
• Applicable for most of the CM processes
• Change Evaluation, Impact analysis, Change implementation

11/6/2020 5
1. Escalation and Notification
• Ex 1: Keeping track of deferred CRs and
bringing them back for review after a
specified time period
• Ex 2: Reminding a CCB member who
have not submitted the Evaluation report
to convey a decision for the CR in the
Evaluation report.
• If nothing happens after this, then the
problem is reported to senior member of
CCB to take corrective actions

11/6/2020 6
 1. Escalation and Notification
• Notification:
“The process of reminding the concerned
person to complete their task once the
specified time is elapsed / reached”

11/6/2020 7
1. Escalation and Notification
• CM tools for Escalation and Notification
• Performs based on predefined rules and criteria
• Tools can be programmed to escalate an issue after
specified number of days
• Eg: Failure to convey the decision on CR to the Originator

11/6/2020 8
1. Escalation and Notification
• Multiple levels of Escalation
• Happens in Ex.2 when CCB member fails to respond to
the reminders, then issue is escalated to the superior,
if no response the issue is escalated to next person in
the Organization hierarchy
• Time period before escalation, the levels of escalation,
the people to be notified are predefined in tools
11/6/2020 9
 2. Emergency fixes
• Efforts to correct the following difficulties are
Emergency fixes
• Problem reports that need immediate action and will not
allow enough time to follow all change management and
control procedures
• Major target is to sort out the difficulties irrespective of
cost / time

11/6/2020 10
 3. Problem Reporting & Tracking
• PR/ Software Problem Report  type of CR
• It is the result of anomaly in the system

“Errors/ Fault/Flaw/Gripe/ Glitch/defect,

Problem/Bug”

11/6/2020 11
What is anomaly?
• An anomaly
• A condition that deviates from expectations based on SRS,
design documents, user documents, perceptions or
experiences of some people
• Anomaly is found during
• Review
• Test
• Compilation
• Use of software products
• Applicable documentation

11/6/2020 12
 4. Problem Reports & Change Requests
• Why SPR usually gets immediate attention than a CR
?
• Because it is result of a problem and it has to be fixed
• Can be result of faults in two different subsystems with
two different skills and needs two different people/teams
to fix it
“An SPR can create or result in one or more CR”

11/6/2020 13
Problem reporting and tracking Process
• Disposition of SPR/PR
• follows same procedure as that for
enhancement requests
• How PR differs from CR?
• Before the creation of CR and after Change
management process is set into motion,
some activities are done
• To prevent the same type of mistakes
• To create the knowledge base of
anomalies
11/6/2020 14
Problem Reporting & Tracking Process

11/6/2020 15
 5. Problem Identification
• How to identify a defect/anomaly in software
system?
• Know the following:
• When something goes wrong?
• When the system starts misbehaving?
• When the performance of the system is not what it is
supposed to do?
• When the system stops performing?

Identify the Problem

11/6/2020 16
5. Problem Identification
• Once the problem is identified
• Report and fix it, review, approve and baseline the
fixed version
• 100 % defect free s/w system is not possible but
• Try to reduce the number of defects in the system
• Try to spot and reduce the number of critical defects in
the system

11/6/2020 17
 Steps to handle Problem Reports
1. Problem is identified
2. Fill the PR Form
3. PR form is received by CMO
4. Checked for clarity and completeness
5. Assign a PR number or identifier
6. Report to Qualified professionals for analysis
7. Create CRs for fixing the problem
8. Prepare the Problem Analysis document for casual
analysis
9. Process the CRs

11/6/2020 18
 PR form Analysis
• Team constitution:
• Project team member
• QA personnel with technical knowledge and Problem
analysis methodologies
• Factors analysed
• Objective determining the severity of the problem
• Its nature, impact, the cause, the category, its place of
origin
• Items affected, cost, time, skills to fix the problem
• Classifies the defects based on severity

11/6/2020 19
11/6/2020
oblem Report Form

20
11/6/2020
blem Report Analysis Form

21
 6.Defect Classification
• Based on the project phases in which it occurs
• Requirement phase
• Design phase
• Coding and Testing phase
• A defect classification system must be designed that
focuses on
• Nature of the project
• Degree of detail required or severity

11/6/2020 22
 Defects in Requirement phase
S.No Phase Defects Description
1. Incorrect • A requirement or its part is incorrect
Requirements • Due to misunderstanding of user
expectations
2. Undesirable • Requirements stated are correct but not
Requirements desirable
• Because of technical feasibility, design or
implementation
3. Requirements • User does not stated this feature
not needed • Adding this does not increase the utility of
Requirement the project
1.
Analysis
4. Inconsistent • Contradict some other requirement
Requirements
5. Ambiguous/ • A requirement or its part is ambiguous
incomplete • This cannot be implemented
requirements
6. Unreasonable • Requirement cannot be implemented
requirements • Because of cost, h/w or s/w considerations
7. Standards • Standards Set for analysis have not been
11/6/2020 23
violation followed
 Defects in Design , Coding and testing phase
S.No Phase Defects Description
2. Design The defects may relate to: Each of these may be
1. Data definition • Incorrect
2. The UI • Incomplete
3. The module interface • Inconsistent
4. Processing logic • Inefficient
• Undesirable
• Violate standards

3. Coding and The defects may relate to: Each of these may be
Testing 1. Logic • Incorrect
2. Boundary conditions • Incomplete
3. Exception handling • Inconsistent
4. Performance • Inefficient
5. Documentation • Undesirable
• Violate standards

11/6/2020 24
 7. Defect Severity
Severity:
“The measure of the impact of the defect”
• Members of the problem analysis classifies the defect
and decides on its severity and recorded in the
problem analysis document

11/6/2020 25
How the defects are classified based on
severity?
• Defects can be classified as:
• Major defects
• Substantial impact on several subsystems/ processes
• Corrective action: changes to all the processes or subsystems affected
• Minor defects
• Has impact only on one process or subsystem
• Corrective action: local to the process/ subsystem
• Suggestions towards improvement

11/6/2020 26
Defect Severity
• Eg: Defect severity in testing phase
• Critical : Errors causing s/m failures
• Fatal : Fatal errors resulting in erroneous output
• Nonfatal : Errors that are not fatal but affects the
performance of the s/m
• Cosmetic : Typo errors in texts, screens,
documentation or cryptic errors

11/6/2020 27
 8.Defect Prevention
• Defect Prevention:
“ Preventing the faults from recurring by identifying and
tracking the problem“
• Objective of PR
• Identifying the defects and fixing it
• Defect prevention
• Methods
• Cause Analysis
• Creating defect Knowledge base and Help desks

11/6/2020 28
 Cause Analysis
• Takes Problem analysis document as basis
• Analyses the defects and problems to determine and
record the cause
• Initiates the corrective action to prevent it from
recurring
• Cause analysis team comes up with cause patterns
“Reveals the reason for the defects”

11/6/2020 29
 Some of the causes for the defects and
solution
1. Insufficient input Proper analysis on inputs
2. Inadequate standards Awareness Programs
3. Inadequate skill levels Skill empowerment Sessions
4. Lack of training Experts to train the team
5. Lack of documentation Soft skills programs
6. Lack of communication 3R testing and improvement
7. Inappropriate tools Training on tools used

11/6/2020 30
 Defect Knowledge base and Help desks
• Knowledge base:
“ stores the defects in organized way, classified
and categorized with better search facility”
• Search facility:
• Search for the defects by
• Category
• Phase of origin
• Cause
• Severity
• KB servers as roadmap and guidebook for:
• analysts, designers, programmers, testing and
maintenance team
11/6/2020 31
 Defect Knowledge base and Help desks
• What details about defects are stored??
• Project
• Defect description
• The cause
• The solution
• How it was fixed

11/6/2020 32
 KB assists the Help desks
• Analysts, designers and Programmers:
• What to do? What to avoid? What mistakes can happen?
• Testing team
• Helps them to create better test cases for escaped defects
with details about the flaws
• Problem fixing team
• Provides similar problems and how they are fixed?

“ KB helps the Help desks and Technical support team”

11/6/2020 33
 9. CCB
• Change Control Board or Configuration Control Board
or Change Control Authority (CCA)
• CCB:
“ Group of people responsible for evaluating, approving
and disapproving proposed changes to CIs, for ensuring
implementation of approved changes”
• Configuration Control purview
• Once the CIs are identified, acquired and baselined come
under CC purview

11/6/2020 34
 CCB Composition
• Can be Single person to highly structured and formal
setup with many people
• Depends on the complexity, size and nature of the project

Large Projects
Small Projects: Defense Projects
• Project leader alone Multiple levels or hierarchies of CCBs
can be CCB handling different types of problems
Governing CCB
• Coordinating the activities of the
CCBs
• Acts as arbitrator to resolve the
conflicts among CCBs

11/6/2020 35
 CCB Composition
• CCB must have strong grasp on project
• Representatives from
• SCM group (CMO)
• Project team (Project leader) • Representatives from
• QA group all the affected
• Company Mgmt. departments/
• Project Mgmt. stakeholders
• Preferably senior
• Functional or user community
people
• Developers
• Ideal size is 7
• Test group • CCB can summon
• DBA anyone like CO,
• Marketing department Experts and so.
• Documentation group
• Client representative
11/6/2020 36
 Functions of the CCB
1. Except emergency fixes nothing should be changed
without CCB’s consent
2. Declare baselines on CIs
3. Review changes to baselined CIs
4. To approve, deny or reject their implementation
5. Ensures that the changes undergone technical
analysis and review are documented for tracking &
auditing purposes
6. Release management
7. CCB Chair Should ensure group dynamics in
cooperative manner
11/6/2020 37
 Functioning of CCB
• CCB should have a chair person
• It can be project Mgmt. representative or fixed on
rotational basis
• CCB should meet at the intervals in SCM plan
• Emergency meeting can also be conducted on need
basis for emergency fixes
• Should specify the minimum No. of people who can
make a decision
• Should formulate the rules for functioning of CCB in
SCM plan or should discuss this in first meeting

11/6/2020 38
 Functioning of CCB
• The rules for functioning of CCB
• How will the CCB decide on an issue?
• Is it by vote and if it is by vote, what has to be done if it is a
tie?
• All Transactions that happened during the meeting
should be recorded
• Should circulate minutes of meeting among CCB

11/6/2020 39
 Check-In & Check -Out
• Check- In:
• process of reviewing,
approving and moving an
item into controlled
environment
• Check out:
• If change request is
approved the
configuration manager will
copy the item from the
controlled library so
modifications can be made

11/6/2020 40
 Version Variant
• Initial release or corelease • Versions can be
of a Configuration item functionally equivalent
but may be designed using
different h/w or s/w
environments
• New versions may have • Unlike Versions variants
additional functionality or are not improvement of
different functionality i.e an item
can be improvement of
prior one
• Eg: Windows 7 , Windows
8 are versions • Eg: McAfee for Windows ,
McAfee for MAC

11/6/2020 41