Chapter 6-Configuration Control

8/8/2019 Chapter 6-Configuration Control

1/63

Software Configuration Management


2/63

` Configuration control as an element of

configuration management, consisting of the

evaluation, coordination, approval or disapproval,

and implementation of changes to configurationitems after formal establishment of their

configuration identification.

` Once the configuration items are selected, then

some degree of control has to be brought in.


3/63

` To control the changes the following activities

need to be done: Procedures have to be established

Guidelines have to be implemented Roles and authorities have to be defined

All workflow processes of the change management

system- change identification, change requisition, change

approval/disapproval, change implementation, testing-

have to be designed, documented and implemented.


4/63

` Out of all the SCM activities, configuration control

is done most frequently.

` Change control activity is automated by manytools which makes this heavy task quite easy.


5/63

` Software development is a continuously evolving

process. You cannot freeze one phase and go to

another.

` There is an overlap between various phases

because lot of changes are occurring.

` Changes have to be managed, else uncontrolledchanges causes chaos.


6/63

` Changes affects the customers agreement with thedeveloper.

` Major changes can affect the terms and conditions ofa contract or purchase order related to cost, delivery

schedules, or other milestones.` Other changes can affect statement of work,

specifications or other docs which developer issupposed to adhere to.

` Thus, to make the changes, a change request isprepared and submitted to the customer for approval.


7/63

` Once the customer gives the approval, the

procedure for processing the change starts.

` The developers contract statement needs to bechanged.

` The customer normally pays for the cost of

preparing the changes and incorporating them inthe system and conducting the tests for the same.


8/63

` Deviations : Developers may run in situation whenthey must deviate from the prescribed specificationbecause of a temporary inability to meet a givenrequirement.

` The customer may approve such deviations up to anagreed on point in time or some instances manyapprove a permanent deviation without requiring amajor change to be submitted.

` A deviation is an authorization to depart from aprovision before the development of an item.


9/63

` Waiver is an authorization to use an item, following its development,that departs from the provision in some way.

` In these cases formal process, a formal process is required to obtain anapproval for deviation to, or waiver of, the provision.

` Waivers may be granted to cover temporary problems in meeting thespecifications or contract requirements.

` This includes instances without having completed all the prescribedtesting or delivery of the product without certain units or modulesincluded, due to delayed action.

` A waiver has a specified time period that must be met to satisfy thecontractual agreement.


10/63

` Changes to software can be both internal and external External: originate from users, from evolution of operational

environments

Internal : from improved design, incremental development,correction of errors etc.

` Change control is a process which ensured thatchanges that have been initiated are classified andevaluated, approved or denied, and that those are

approved are implemented, documented, tested,verified, and incorporated into the new baseline.


11/63

` Configuration control is a set of techniques used to ensurethat the components in a system achieve and maintain adefinite structure (relationships maintained) throughout thelife cycle.

` Change management and control provides the necessaryprocedures, documentation, and organizational structure tomake sure that all items marked as CIs, the details of thechanges made to them, and other related information areavailable to all who needs to see it, throughout the lifecycle.

` It is a process which provides necessary mechanism toorchestrate change, but in a controlled manner.


12/63

` Change mgmt and control solves four mostcommon problems in software development :communication breakdown, shared data, multiplemaintenance, and simultaneous update problems.

` In any development environment, source codeand data is shared by different programmers.

` In change mgmt system, all the changes are madeafter proper analysis and approval by a separate

entity.


13/63

` Thus effort of one getting overridden by another or

effort getting duplicated is not there.

` Thus if a person is making changes, then all

people in the project know that the change isbeing made on a particular item.

` Thus change mgmt brings discipline to the

development process, improves productivity,

because lot of time is wasted in debugging andreworking.


14/63

` An orderly change process is required to ensurethat the only approved changes are implementedinto a baselined document or software.

` Various steps involved are: Change initiation ;change classification; change evaluation orchange analysis; change disposition; changeimplementation, change verification, baselinechange control.

` If one uses a tool, then most of these processeswill be done automatically be done.


15/63

` A change request (CR) may be submitted by thedeveloper, a member of the QA team, a reviewer, or auser.

` Each project should set up a CR form for documentingthe proposed change and its disposition.

` Each project should have an individual- theconfiguration management officer (CMO) or a memberfrom the SCM team to receive the SCM form, assign atracking no. and route it for analysis.

` The person receiving the CR form will check for its

completeness, and may return back to the originator ifit is incomplete.


16/63

` Once the form is complete, it is given a uniqueidentifier (tracking no.) and the CR is recorded in thechange request tracking database or files.

Change Classification

` Changes to software and associated documentationare classified according to its impact of the changeand the approval authority needed.

` Depending on the criticality, impact, and cost involved,there will be a hierarchy of people who can approve

the changes.


17/63

` At the top of the hierarchy is the CCB.

` Major changes are made by the CCB and minor

changes by the project manager.

` The exact mechanism of change classification andthe approval should be defined in the SCM plan.

` Classification of changes are based on severity,

importance, impact, cost involved, or any other

priority factor.` Diagram : Change request process diagram


18/63

` The individual who proposes the change may

suggest a classification for that change.

` The CMO or the receiving authority receivessuggested classes and assigns a tentative

classification.

` After the assessment of the impact of the CR, theCCB or the approving authority will assign the final

class.


19/63

CHANGE REQUEST CR

No._________________

Analysis Document No.__________

System/project_______________ Item to be changed_____________

Classification: Enhancement / Bug fixing / Other:____________________

Priority: Immediate/Urgent / As soon as possible / desirableChange Disposition

Status Date By Remarks

Initiated

Received

Analyzed

Action(A/R/D)*

Assigned

Checked out

Modified and tested

Reviewed

Check-in

Baselined

Remarks

*A- Approved, R-Rejected, D-Deferred


20/63

` Configuration control process provides adequate

analysis of changes in terms of impact to system

functionality interfaces, utility, cost, schedule, and

contractual requirements.

` Each change should be analyzed for impact on

software safety, reliability, maintainability,

transportability, and efficiency.

` The project CMO routes the CR to the software

engineering staff for evaluation.


21/63

` In some cases project procedures require that the

CR be screened before it is analyzed. Some

changes will not have a chance of approval due to

some considerations (cost or schedule).

` This situation : mgmt decides not to take any

action if the changes lies in some category. In this

case the pre-evaluation screening will reject suchCRs.


22/63

` The analysis produces documentation whichdescribes the changes that will have to be madeto implement the CR, the CIs and the documentsthat will have to be changed, and other resources

required to make the change.

` This document becomes part of change packagewhich is sent along with the CR.

` After completion the change package is sent tothe CCB.


23/63

` Disposition of changes to baselined items isusually done by a CCB.

` The CCB evaluates the desirability of changeversus the cost of the change (as per the analysisdone). The CCB may approve, deny or defer achange request.

` Rejected items are sent back to the originator,along with the CCBs rationale for rejection.


24/63

` CCB may have to request more information andadditional analysis. These CRs are sent back to theanalysis group with the CCBs questions attached.

` Deferred CRs are filed, to be sent back to the board atthe proper time.

` In all cases CCB may not be the change approvingauthority. In some cases, the project leader, TheCMO, or another designated person could also makethe decision.


25/63

` The CMO sends the approved items to the

development team. The CMO also distributed the

meting minutes and also records the current

status of the CR.

` This information is recorded in the tracking

database or files.


26/63

Change Analysis Document

No.__________________

CR

No._______________

Date_________________

System/Project__________________ Item to be

analyzed_________________

Analyzed by

:_________________________________________________________

Items affected

Estimated

effort:______________________________________________________

Impact onschedule:__________________________________________________

Implementation alternatives:

Recommendations:


27/63

` Now with tools, physical CCB meetings are rare. E-mail basically is used for sending Cr and relateddocuments amongst the stakeholders.

Change Implementation:` Approved CRs are used as authorization form.

` The development team schedules the resources tomake the change.

`

It must get the official copies of the baselinedcomponent to be changes from the program library.


28/63

` For code changes, design has to be developed, code

has to be written and testing has to be done and the

correctness of the changes verified.

` Also associated documentation has to be revised to

reflect the change.

` Once the change has been made and local testing

completed, the revised component and documents are

returned to the control of the program library.

` After verification, the new version takes its place in thesequence of baselines.


29/63

` The implementation that has been tested at the unit level,must be verified at the system level.

` Regression testing will be usually done to ensure that thereare no errors by adding a functionality.

` After the verification is complete, the reviewing teamsubmits evidence of it to the program library.

` The changed items will be included in the new version ofthe baseline.

` After this the CMO will record the occurrence of thisprocess in the change tracking database or file.


30/63

` These details also are recorded in the change history. Thechange history records : originator and receiving authority,date received, analysis done by, date of analysis,approving authoritys name, date, names of the personswho affected the change, testing, review and audit, reasons

for change, and a short description of change.

` In case a tool is used, then the process of recording thechange implementation information, task of changing thestatus of the change request, etc can be doneautomatically.

` Complete automation of SCM processes is available onlyin advance tools.


31/63

ChangeIdentification(Change

Originator)

Change Request (CR) Changerequest form, Problem request

form)

CR submitted to CMO/

receiving authority)

CR and Analysis (AD) send to

CCB/approving authority)

CR analysis (impact,skills, costs, etc.)

(sofwtare engineeringstaff)

CCB/ approving authority evaluates the CRand AD

CR approved CR rejected CR deferred

The CR is given to a qualifiedprofessional orTeam for

implementation

Change Originator isinformed about the rejection

giving the reason for

rejection

Deferred Cr andassociated

documentation is filed forlater resolution

Items to be checked out fromthe configuration library

Changes are made to items as perthe CR and testing is done

Changes and tested items arereturned, where they are

reviewed, tested (system andregression testing) and validated

Changed items are promoted tothe new baseline and the

changes are included in the new

version

New version of thesoftware is released

Change management and control process


32/63

` To minimize the number of versions and frequency of

delivery of the software components, changes to the

software are usually grouped into releases.

` Product release is the act of making the product

available to its intended customer.

` Each release contains software and documentation

that has been tested and controlled as a totalsoftware system.


33/63

` Customer specific release: another reason for release

is to satisfy the customer by customizing the software

system to meet the specific needs of the customer.

` For incorporating changes due to emergency fixes

properly, a release might be made immediately after the

emergency fix has been incorporated.

` Alpha and beta release is also done for alpha and betatesting.


34/63

` Company also does major and minor release.

` Major releases are done : when there is a

significant increase in the products functionality,

whereas minor releases are done when therelease is to correct a bug or fault in the program or

system.

` T

he CCB decides when and how to make releasesbecause it is the ultimate authority for making

decisions about configuration control.


35/63

Software Configuration Management


36/63

` In file based change mgmt system, in order to make achange The file(s) is identified which is to be changed. The required file is then checked out and necessary changes are

made. The file is tested, verified and checked in.

` Drawback: It fails to capture the relationship between the items that are

changed as a result of a change request. Usually, more than one file is changed to implement a CR.

`

` In file based system there is no way to determine thechanged files.

` This results in build failures.


37/63

` To avoid the limitation of file-based change mgmt

system.

` All the files which perform a particular task are treated

as one entity.

` Here logical changes are tracked instead of individual

file changes.

` All the files which are logically connected for making a

CR are packaged together.

` They are checked out together, tested together,

reviewed together and approved as a group and they

are checked in and promoted together.


38/63

` Other terms used for this are: change set,

package, task, activity, work package.

` Two different implementations for this :

Change set: systems that treat logical change as lines ofcode typically refer to the unit of change as a change set.

Change package: system that treat logical change as

the set of file versions that contain the code changes are

called change packages.

(Reading exercise)


39/63

` Some change request or problem reports needimmediate action and will not allow enough time tofollow all change management and controlprocesses.

` Efforts to correct these difficulties are calledemergency fixes.

` These fixes are done when there are not enoughresources or time to process.

` Whenever time permits the emergency fixes willbe taken through proper change mgmt process,and required task be completed.


40/63

` An anomaly is any condition that deviates fromexpectations based on RDD, design docs, user docs,etc.

` The SPR (software problem report), PR (problemreport) is the type of change request that is the result

of and anomaly in the system.` A PR gets more priority than a CR (because a problem

needs to be fixed).` A PR may lead to one or more CR.` Disposition ofPR is same as that of enhancement

request.` But in case ofPR, before the creation of the CR and

after motion, some activities need to be done


41/63

` These activities need to be done to avoid the same mistaketo happen again and create a knowledge base.

` Try to reduce the number of defects

` Problem identified -> should be reported and fixed. Fixed

problem should be reviewed and baselined .

` Various steps involved Detection of an anomaly or defect. Create the report for the same (PR).

Check theP

R for its correctness and completeness. The PR is assigned a PR number. Give the report to the technical knowledge (QA or project team)


42/63

o Analyze the impact, the cause, the category, place of origin,

items affected, cost, time, skill required to fix it.

o The analysis will also classify the defect and create the CR for

fixing it.

o

AP

R can result in one or more CR.o The CR created are processed as discussed in the previous

slides.

` Diagram: problem analysis form


43/63

Problem Analysis Document No.________________PR No._____________

Date:_______________

System/Project:________________________________________________________

___Analyzed

by:______________________________________________________________

Classification:__________________________________________________________

___

Items affected

Impact on cost:________________________Time:______________________

Skills required in fixing the problem:________________________________

Cause of the problem

Item ID Item Description Version No. Nature of change

Implementation alternatives:

Recommendations:


44/63

Problem Identification

Problem analysis

Problem Classification

Cause identification

Change request

creation

Change

management

activities

Causal analysis

Documentation

Figure : Problem reporting

and tracking process


45/63

` Defect classification is done on the basis of the phasein which the defect has occurred.

` Requirement analysis phase: Incorrect requirement Undesirable requirement : the requirement is correct but not

desirable due to the technical feasibility, design, orimplementation cost consideration.

Requirement not required: req. does not add value to the utilityto the customer.

Inconsistent requirement: the req. contradicts some other

requirement Ambiguous/incomplete requirement Standard violation: standard set for analysis have not been

followed.


46/63

` Design Phase: defect may be related to data

definition, user interface, module interface,

processing logic. These may be incorrect,

incomplete, inconsistent, inefficient, undesirable or

violate standards.


47/63

` Coding and Testing Phase: defects related to logic,boundary conditions, exception handling,performance, documentation, standard violations.

` Defect Severity: is a measure of the impact of thedefect. The defects may be classified as : Major defects: which have substantial impact on several

processes or subsystems. The correction activity involveschanging the design of one or more processes.

Minor defect: that impact only one process or subsystem. Thecorrection activity is local to that process or subsystem.

Suggestion towards improvement.


48/63

` During the testing phase, the defects may be

classified as follows: Critical: Errors that cause system failure

Fatal: Fatal errors that cause that result I erroneous

output

Nonfatal: errors that are not fatal but that will affect the

performance or smooth functioning of the system

Cosmetic: Minor errors such as cryptic error messages or

types of in messages, screens, or user documentation.


49/63

` The main objective ofPR is to identify faults and

fix it.

` The secondary objective is to prevent faults from

occurring again, i.e.D

efectP

revention` There are two ways to do the same:

Causal analysis

Knowledge base


50/63

` Causal analysis: analyze the defects and problems todetermine and record the cause and initiate correctiveactions so defects will not occur again.

` The problem analysis document is used to analyze thecauses of defect, why they occurred, the severity etc.

` The output of causal analysis will be a cause patterne.g. : inadequate standard, lack of communication,lack of training, inappropriate methodology.

` Corrective actions can be taken according to thecausal pattern observed.


51/63

` The PR, CR and the causal analysis can be used

to form a Defect Knowledge Base.

` This knowledge base should have a search facility

to search for defects by category, severity, causeand other criteria.

` This knowledge base is very helpful for the

analyst, designers, programmers and testers.

` As more information is added, it becomes morecomprehensive and useful.


52/63

` CCB is the approving authority for deciding what

changes should be made to a CI, which change

should be rejected, etc.

`

It ensures that all the proposed changes receive atechnical analysis and review and that they are

documented for tracking and auditing purposes.

` The board has final responsibility of release mgmt

also.


53/63

` CCB can vary from a single person to a highly

structured and a formal setup with many people.

` The structure of CCB depends on the size of the

project.

` Or large projects, multiple levels of CCBs (each CCB

is handling different types of projects) may be

required.

` CCB should constitute people having knowledge

about the system (technical, managerial, economicaspects) and the effects and consequences of their

decisions on the system.


54/63

` CCB must be composed of representatives from all

the stakeholders.

` Representatives from SCM group (CMO), project

leader, QA group, company mgmt, marketing

department, functional or user community, developers,test group, design group, operation personnel,

interface group, database administrator,

documentation group.

` In some cases client representative is also included.` Ideal size: 7 members


55/63

` The chair of the board should be a person from projectmgmt who can resolve conflicts and enforce adecision.

` Decisions of CCB should be put in charge whenever

possible.

Functions of CCB

` To evaluate and approve or deny the change requestand problem report that have been initiated.

` A presubmissions evaluation of the change request orPR is done.


56/63

` CCB is composed of senior people, thus facts should bepresented to the CCB clearly and concisely. (due to lack oftime)

` Prior to CCB meeting, the agenda , the issues andsupportive docs can be sent to the members prior to theCCB meeting.

` This helps them to come prepared.

` The concerns and issues discussed by the CCB are:

Operational impact: effect of change on the final project

Customer approval: will the change require customer approval.


57/63

Development effort: impact of change on interfaces andinternal software elements of the final system.

Interface impact: affect the established interfaces of thesystem.

Time schedule: what is the appropriate time forincorporation of the change with minimal impact on thecost and time.

Cost impact: estimate the cost involved.

Resources impact: what resources will be required.


58/63

Schedule impact: how will the processing impact the

current schedule.

Quality impact: how will the change impact the quality

and reliability.

Feasibility: can the change be made economical.What is

the risk in implementing the change. What is the risk in

not implementing the change.


59/63

` The decisions made in the CCB are strategic even though

a good technical understanding is required. E.g.: a change

will delay the release but it will help in better marketing of

the product; so to go or the change or not.


60/63

` The CCB should have a chairperson. Usually the

project management person is assigned this post. Or

may be on rotation basis also.

` The CCB should meet at intervals or emergency

meeting may also be called.

` Minimum number of people to make decisions should

be specified. The rules for functioning of CCB should

be formulated: how is the decision taken (by vote);

what in case of tie.` All the points being discussed in CB are also recorded

(minutes of the meeting)


61/63

` The minutes should contain: Members present

Date of meeting

Agenda of meeting

Action taken report (ATR) by the CMO (status of the CRs

and other SCM activities since the last CCB)

Change request discussed in the meeting

Discussion details and decisions, other issues

Distribution list.


62/63

` Once the meeting of CCB takes place, a decision formaking a change or denying the approval is made.

` The approved changes will be assigned to a qualifiedperson or team to make the changes.

` If the CR is rejected, the change initiator will benotified about the decision and the reason forrejection.

` The initiator can resubmit the request for making thechange.

` The deferred change request are filed for laterdecision and it is conveyed to the initiator.


63/63

` CCB will assign the task of implementing thechange to someone or assign the changemanagement process to the CMO.

` The CMO will assign the task to the qualified

person and perform the change mgmt process.` In the next meeting the CMO will present the ATR

(action taken report) on the change managementapproved and implemented.

` Due to SCM tools the need of CCB meetings isreducing these days.

Documents

Chapter 6-Configuration Control