UNIT V

Risks and Configuration Management

 What is Risk?
 "Tomorrow problems are today's risk."
 Hence, a clear definition of a "risk" is a problem that could cause some loss or threaten the progress of the
project, but which has not happened yet.
 These potential issues might harm cost, schedule or technical success of the project and the quality of our
software device, or project team morale.
 Risk Management is the system of identifying addressing and eliminating these problems before they can
damage the project.
 We need to differentiate risks, as potential issues, from the current problems of the project.
 Different methods are required to address these two kinds of issues.
 For example, staff storage, because we have not been able to select people with the right technical skills is a
current problem, but the threat of our technical persons being hired away by the competition is a risk.
 Risk Management
 A software project can be concerned with a large variety of risks.
 In order to be adept to systematically identify the significant risks which might affect a software project, it
is essential to classify risks into different classes.
 The project manager can then check which risks from each class are relevant to the project.
 There are three main classifications of risks which can affect a software project:
 Project risks
 Technical risks
 Business risks
 1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource, and
customer-related problems.
 A vital project risk is schedule slippage.
 Since the software is intangible, it is very tough to monitor and control a software project.
 It is very tough to control something which cannot be identified.
 For any manufacturing program, such as the manufacturing of cars, the plan executive can recognize the
product taking shape.
 2. Technical risks: Technical risks concern potential method, implementation, interfacing, testing, and
maintenance issue.
 It also consists of an ambiguous specification, incomplete specification, changing specification, technical
uncertainty, and technical obsolescence.
 Most technical risks appear due to the development team's insufficient knowledge about the project.
 3. Business risks: This type of risks contain risks of building an excellent product that no one need, losing
budgetary or personnel commitments, etc.
 Schedule Risk :
Schedule related risks refers to time related risks or project delivery related planning risks.
 The wrong schedule affects the project development and delivery.
 These risks are mainly indicates to running behind time as a result project development doesn’t progress
timely and it directly impacts to delivery of project.
 Finally if schedule risks are not managed properly it gives rise to project failure and at last it affect to
organization/company economy very badly.
 Some reasons for Schedule risks –
 Time is not estimated perfectly
 Improper resource allocation
 Tracking of resources like system, skill, staff etc
 Frequent project scope expansion
 Failure in function identification and its’ completion
 Budget Risk :
Budget related risks refers to the monetary risks mainly it occurs due to budget overruns.
 Always the financial aspect for the project should be managed as per decided but if financial aspect of
project mismanaged then there budget concerns will arise by giving rise to budget risks.
 So proper finance distribution and management are required for the success of project otherwise it may lead
to project failure.
 Some reasons for Budget risks –
 Wrong/Improper budget estimation
 Unexpected Project Scope expansion
 Mismanagement in budget handling
 Cost overruns
 Improper tracking of Budget
 Operational Risks :

Operational risk refers to the procedural risks means these are the risks which happen in day-to-day operational activities during
project development due to improper process implementation or some external operational risks.
 Some reasons for Operational risks –
 Insufficient resources
 Conflict between tasks and employees
 Improper management of tasks
 No proper planning about project
 Less number of skilled people
 Lack of communication and cooperation
 Lack of clarity in roles and responsibilities
 Insufficient training
 Technical Risks :
Technical risks refers to the functional risk or performance risk which means this technical risk mainly
associated with functionality of product or performance part of the software product.
 Some reasons for Technical risks –
 Frequent changes in requirement
 Less use of future technologies
 Less number of skilled employee
 High complexity in implementation
 Improper integration of modules
 Programmatic Risks :
Programmatic risks refers to the external risk or other unavoidable risks.
 These are the external risks which are unavoidable in nature. These risks come from outside and it is out of
control of programs.
 Some reasons for Programmatic risks –
 Rapid development of market
 Running out of fund / Limited fund for project development
 Changes in Government rules/policy
 Loss of contracts due to any reason
 Other risk categories
 1. Known risks: Those risks that can be uncovered after careful assessment of the project program, the
business and technical environment in which the plan is being developed, and more reliable data sources
(e.g., unrealistic delivery date)
 2. Predictable risks: Those risks that are hypothesized from previous project experience (e.g., past turnover)
 3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to identify in advance.
 Principle of Risk Management
 Global Perspective: In this, we review the bigger system description, design, and implementation. We look
at the chance and the impact the risk is going to have.
 Take a forward-looking view: Consider the threat which may appear in the future and create future plans
for directing the next events.
 Open Communication: This is to allow the free flow of communications between the client and the team
members so that they have certainty about the risks.
 Integrated management: In this method risk management is made an integral part of project management.
 Continuous process: In this phase, the risks are tracked continuously throughout the risk management
paradigm.
  Risk Management Activities
 Risk management consists of three main activities, as shown in fig:

Risk Assessment
The objective of risk assessment is to division the risks in the condition of their loss, causing potential.
For risk assessment, first, every risk should be rated in two methods:
•The possibility of a risk coming true (denoted as r).
•The consequence of the issues relates to that risk (denoted as s).
Based on these two methods, the priority of each risk can be estimated:
          p=r*s
Where p is the priority with which the risk must be controlled, r is the probability of the risk becoming true, and s is
the severity of loss caused due to the risk becoming true. If all identified risks are set up, then the most likely and
damaging risks can be controlled first, and more comprehensive risk abatement methods can be designed for these risks.
 The Risk Management Method

It is a simple four step method which is repeated continuously through the project lifecycle.
Once a risk is identified, it is assessed, responses to manage the risk are agreed, and progress is monitored:

Identify – risks are identified on an ongoing basis, through formal risk identification workshops as well as during
day to day activities.
Assess – once identified a risk is assessed to establish the likelihood of it occurring and the impact it will have if
it occurs.
Respond – there several possible actions that can be taken to reduce the likelihood of a risk occurring or the
impact of the risk, for example transferring, avoiding, and mitigating. In this step suitable responses are agreed,
and budget approved if needed.
Monitor - progress of the risk responses needs to be monitored and controlled, with corrective action taken if
needed. Typically, progress is assessed via project team meetings.
 1. Risk Identification: The project organizer needs to anticipate the risk in the project as early as possible
so that the impact of risk can be reduced by making effective risk management planning.
 A project can be of use by a large variety of risk. To identify the significant risk, this might affect a project.
It is necessary to categories into the different risk of classes.
 There are different types of risks which can affect a software project:
 Technology risks: Risks that assume from the software or hardware technologies that are used to develop
the system.
 People risks: Risks that are connected with the person in the development team.
 Organizational risks: Risks that assume from the organizational environment where the software is being
developed.
 Tools risks: Risks that assume from the software tools and other support software used to create the system.
 Requirement risks: Risks that assume from the changes to the customer requirement and the process of
managing the requirements change.
 Estimation risks: Risks that assume from the management estimates of the resources required to build the
system
 2. Risk Analysis: During the risk analysis process, you have to consider every identified risk and make a
perception of the probability and seriousness of that risk.
 There is no simple way to do this. You have to rely on your perception and experience of previous projects
and the problems that arise in them.
 It is not possible to make an exact, the numerical estimate of the probability and seriousness of each risk.
Instead, you should authorize the risk to one of several bands:
 The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate (25-50%),
high (50-75%) or very high (+75%).
 The effect of the risk might be determined as catastrophic (threaten the survival of the plan), serious (would
cause significant delays), tolerable (delays are within allowed contingency), or insignificant.
 Risk Control
 It is the process of managing risks to achieve desired outcomes.
 After all, the identified risks of a plan are determined; the project must be made to include the most harmful
and the most likely risks.
 Different risks need different containment methods.
 In fact, most risks need ingenuity on the part of the project manager in tackling the risk.
 There are three main methods to plan for risk management:
 Avoid the risk: This may take several ways such as discussing with the client to change the requirements to
decrease the scope of the work, giving incentives to the engineers to avoid the risk of human resources
turnover, etc.
 Transfer the risk: This method involves getting the risky element developed by a third party, buying
insurance cover, etc.
 Risk reduction: This means planning method to include the loss due to risk. For instance, if there is a risk
that some key personnel might leave, new recruitment can be planned.
 Risk Leverage: To choose between the various methods of handling risk, the project plan must consider the
amount of controlling the risk and the corresponding reduction of risk. For this, the risk leverage of the
various risks can be estimated.
 Risk leverage is the variation in risk exposure divided by the amount of reducing the risk.
 Risk leverage = (risk exposure before reduction - risk exposure after reduction) / (cost of reduction)
 1. Risk planning: 
 The risk planning method considers each of the key risks that have been identified and develop ways to
maintain these risks.
 For each of the risks, you have to think of the behavior that you may take to minimize the disruption to the
plan if the issue identified in the risk occurs.
 You also should think about data that you might need to collect while monitoring the plan so that issues can
be anticipated.
 Again, there is no easy process that can be followed for contingency planning.
 It rely on the judgment and experience of the project manager.
 2. Risk Monitoring: Risk monitoring is the method king that your assumption about the product, process,
and business risks has not changed.
 In this stage, risk assessment is done continuously and the risk reduction plan is revised as more information
about risk is available.
 RMMM Plan : 
 A risk management technique is usually seen in the software Project plan.
 This can be divided into Risk Mitigation, Monitoring, and Management Plan (RMMM).
 In this plan, all works are done as part of risk analysis.
 As part of the overall project plan project manager generally uses this RMMM plan. 
 In some software teams, risk is documented with the help of a Risk Information Sheet (RIS).
 This RIS is controlled by using a database system for easier management of information i.e creation, priority
ordering, searching, and other analysis.
 After documentation of RMMM and start of a project, risk mitigation and monitoring steps will start. 
 Risk Mitigation : 
It is an activity used to avoid problems (Risk Avoidance). 
Steps for mitigating the risks as follows. 
 Finding out the risk. 
 Removing causes that are the reason for risk creation. 
 Controlling the corresponding documents from time to time. 
 Conducting timely reviews to speed up the work.
 Risk Monitoring : 
It is an activity used for project tracking. 
It has the following primary objectives as follows. 
 To check if predicted risks occur or not. 
 To ensure proper application of risk aversion steps defined for risk. 
 To collect data for future risk analysis. 
 To allocate what problems are caused by which risks throughout the project.
 Risk Management and planning : 
It assumes that the mitigation activity failed and the risk is a reality.
 This task is done by Project manager when risk becomes reality and causes severe problems.
 If the project manager effectively uses project mitigation to remove risks successfully then it is easier to
manage the risks. This shows that the response that will be taken for each risk by a manager.
 The main objective of the risk management plan is the risk register.
 This risk register describes and focuses on the predicted threats to a software project.
 Software Configuration Management
 In Software Engineering, Software Configuration Management(SCM) is a process to systematically
manage, organize, and control the changes in the documents, codes, and other entities during the Software
Development Life Cycle.
 The primary goal is to increase productivity with minimal mistakes.
 SCM is part of cross-disciplinary field of configuration management and it can accurately determine who
made which revision.
 Why do we need Configuration management?
The primary reasons for Implementing Technical Software Configuration Management System are:
 There are multiple people working on software which is continually updating
 It may be a case where multiple version, branches, authors are involved in a software config project, and the
team is geographically distributed and works concurrently
 Changes in user requirement, policy, budget, schedule need to be accommodated.
 Software should able to run on various machines and Operating Systems
 Helps to develop coordination among stakeholders
 SCM process is also beneficial to control the costs involved in making changes to a system
Any change in the software configuration Items will affect the final product.

Therefore, changes to configuration items need to be controlled and managed.

SCM Process

Tasks in SCM process

•Configuration Identification
•Baselines
•Change Control
•Configuration Status Accounting
•Configuration Audits and Reviews
1. Configuration Identification:
 Configuration identification is a method of determining the scope of the software system.
 With the help of this step, you can manage or control something even if you don’t know what it is.
 It is a description that contains the CSCI type (Computer Software Configuration Item), a project identifier
and version information.
 Activities during this process:
 Identification of configuration Items like source code modules, test case, and requirements specification.
 Identification of each CSCI in the SCM repository, by using an object-oriented approach
 The process starts with basic objects which are grouped into aggregate objects.
 Details of what, why, when and by whom changes in the test are made
 Every object has its own features that identify its name that is explicit to all other objects
 List of resources required such as the document, the file, tools, etc.
 Example:
 Instead of naming a File login .php its should be named login_v1.2.php where v1.2 stands for the version
number of the file
 Instead of naming folder “Code” it should be named “Code_D” where D represents code should be backed
up daily.
2 Baseline:
 A baseline is a formally accepted version of a software configuration item.
 It is designated and fixed at a specific time while conducting the SCM process.
 It can only be changed through formal change control procedures.
 Activities during this process:
 Facilitate construction of various versions of an application
 Defining and determining mechanisms for managing various versions of these work products
 The functional baseline corresponds to the reviewed system requirements
 Widely used baselines include functional, developmental, and product baselines
 In simple words, baseline means ready for release.
3. Change Control:
 Change control is a procedural method which ensures quality and consistency when changes are made in the
configuration object. In this step, the change request is submitted to software configuration manager.
 Activities during this process:
 Control ad-hoc change to build stable software development environment. Changes are committed to the
repository
 The request will be checked based on the technical merit, possible side effects and overall impact on other
configuration objects.
 It manages changes and making configuration items available during the software lifecycle
 4 Configuration Status Accounting:
 Configuration status accounting tracks each release during the SCM process. This stage involves tracking
what each version has and the changes that lead to this version.
 Activities during this process:
 Keeps a record of all the changes made to the previous baseline to reach a new baseline
 Identify all items to define the software configuration
 Monitor status of change requests
 Complete listing of all changes since the last baseline
 Allows tracking of progress to next baseline
 Allows to check previous releases/versions to be extracted for testing

Configuration Audits and Reviews:

Software Configuration audits verify that all the software product satisfies the baseline needs. It ensures
that what is built is what is delivered.
Activities during this process:
•Configuration auditing is conducted by auditors by checking that defined processes are being followed and
ensuring that the SCM goals are satisfied.
•To verify compliance with configuration control standards. auditing and reporting the changes made
•SCM audits also ensure that traceability is maintained during the process.
•Ensures that changes made to a baseline comply with the configuration status reports
•Validation of completeness and consistency
 Participant of SCM process:
Following are the key participants in SCM

1. Configuration Manager
•Configuration Manager is the head who is Responsible for identifying configuration items.
•CM ensures team follows the SCM process
•He/She needs to approve or reject change requests

2. Developer
•The developer needs to change the code as per standard development activities or change requests. He is
responsible for maintaining configuration of code.
•The developer should check the changes and resolves conflicts
3. Auditor
•The auditor is responsible for SCM audits and reviews.
•Need to ensure the consistency and completeness of release.
 4. Project Manager:
 Ensure that the product is developed within a certain time frame
 Monitors the progress of development and recognizes issues in the SCM process
 Generate reports about the status of the software system
 Make sure that processes and policies are followed for creating, changing, and testing
 5. User
 The end user should understand the key SCM terms to ensure he has the latest version of the software
 Software Configuration Management Plan
 Software Configuration Management Tools
 Any Change management software should have the following 3 Key features:
 Concurrency Management:
 When two or more tasks are happening at the same time, it is known as concurrent operation. Concurrency in context to SCM
means that the same file being edited by multiple persons at the same time.
 If concurrency is not managed correctly with SCM tools, then it may create many pressing issues.
 Version Control:
 SCM uses archiving method or saves every change made to file. With the help of archiving or save feature, it is possible to roll
back to the previous version in case of issues.
 Synchronization:
 Users can checkout more than one files or an entire copy of the repository. The user then works on the needed file and checks
in the changes back to the repository.They can synchronize their local copy to stay updated with the changes made by other
team members.