Unit 5
Risks and Configuration Management
Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty. Many problems can plague a software project.
A risk is a potential problem—it might happen, it might not.
In software engineering, Risk management is a technique or mechanism that is carried out during the development process to define, handle, and monitor threats that have formed before and throughout the development process.
Steps of Risk Analysis and Management:
● Recognizing what can go wrong is the first step, called “risk identification.”
● Each risk is analyzed to determine the likelihood that it will occur and the damage that it will do if it does occur.
● Risks are ranked, by probability and impact.
● Finally, a plan is developed to manage those risks with high probability and high impact.
In short, the four steps are:
● Risk identification
● Risk Projection
● Risk assessment
● Risk management
Key takeaway :
- Risk management is a technique or mechanism that is carried out during the development process to define, handle, and monitor threats that have formed before and throughout the development process.
- A risk is a potential problem—it might happen, it might not.
Risk always involves two characteristics: a set of risk information sheets is produced.
● Uncertainty—the risk may or may not happen; that is, there are no 100% probable risks.
● Loss—if the risk becomes a reality, unwanted consequences or losses will occur.
It is necessary to measure the level of uncertainty and the associated degree of loss when assessing risks.
Types of Risks -
Implementation can become challenging and impossible if a technological risk becomes a reality.
Key takeaway :
- Software risk includes the likelihood of occurrence within an enterprise of uncertain events and their potential for failure.
- The risk of software is seen in the system as a combination of robustness, performance reliability, protection, and transactional risk.
Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary.
One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic categories:
● Product size—risks associated with the overall size of the software to be built or modified.
● Business impact—risks associated with constraints imposed by management or the marketplace.
● Customer characteristics—risks associated with the sophistication of the customer and the developer's ability to communicate with the customer promptly.
● Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organization.
● Development environment—risks associated with the availability and quality of the tools to be used to build the product.
● Technology to be built—risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.
● Staff size and experience—risks associated with the overall technical and project experience of the software engineers who will do the work.
Key takeaway :
- Risk identification is a systematic attempt to specify threats to the project plan.
- One method for identifying risks is to create a risk item checklist.
Risk projection, also called risk estimation, attempts to rate each risk in two ways—the likelihood or probability that the risk is real and the consequences of the problems associated with the risk, should it occur. The project planner, along with other managers and technical staff, performs four risk projection activities:
● Establish a scale that reflects the perceived likelihood of a risk,
● Delineate the consequences of the risk,
● Estimate the impact of the risk on the project and the product, and
● Note the overall accuracy of the risk projection so that there will be no misunderstandings.
Risk prediction seeks two ways to score each risk -
- a possibility that the danger is true.
- the result, should it occur, of the problems associated with the risk.
Four risk projection measures are undertaken by the project planner, manager, and technical personnel.
These measures are intended to consider risks in a way that contributes to prioritization.
The software team will assign limited resources to prioritize hazards where they will have the most effect.
Risk impacts on risk components:
Factors affecting impacts of risk:
Key takeaway :
- The effect of risk on the project and the product is calculated.
- The risk table is used for calculation.
A possibility may be indicated very commonly during the early stages of project planning. As time passes and more about danger is understood, it could be possible to simplify the risk into a collection of more detailed hazards that are easy to track and handle everywhere.
One way to do this is to reflect the risk in the format of the condition transition effect:
Given that <condition> then there is concern that <consequence>
Key takeaway :
- Refining allows the underlying threats to be isolated and leads to easier analysis and response.
An effective strategy must consider three issues:
● Risk avoidance
● Risk monitoring
● Risk management and contingency planning
High staff turnover in any organization will have a critical impact on project cost and schedule.
To mitigate risk, project management must develop a strategy for reducing turnover. Among the possible steps to be taken are:
● Meet with current staff to determine causes for turnover. Mitigate those causes that are under our control before the project starts.
● Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave.
● Organize project teams so that information about each development activity is widely dispersed.
● Define documentation standards and establish mechanisms to be sure that documents are developed promptly.
● Conduct peer reviews of all work
● Assign a backup staff member for every critical technologist.
Risk Mitigation:
● Risk reduction means avoiding the incidence of risk (Risk Avoidance). The steps to be taken for risk reduction are as follows.
● To find a probable danger, interact with the employees concerned.
● Before the project begins, find out and remove all those triggers that can generate risk.
● In an organization, create a strategy that will help to continue the project even if certain workers leave the company.
● The present development activity should be acknowledged by everyone in the project team.
● Maintain the necessary records promptly. This report should be strictly consistent with the organization's standards.
● Conduct timely evaluations to accelerate the work.
● Provide additional personnel if necessary, to perform any essential task during software development.
Risk Monitoring:
● The project manager must control the following things in the risk tracking process.
● The approach of the team members varies as the project pressure varies.
● The type of collaboration between the members of the team. The kinds of issues that arise. Work availability inside and outside the company.
● Certain mitigation measures should be monitored by the project manager. For instance, if the current development activity is constantly monitored, everyone in the team can become familiar with the current development activity.
● Risk monitoring aims to verify whether or not the expected risks occur. To ensure that the step identified to prevent the risk is properly implemented or not. To obtain information that could be useful for risk analysis.
Risk Management:
● When risk becomes a reality, the project manager performs this role. If the project manager is efficient in successfully applying project reduction, risk management becomes very straightforward.
● For example, consider a situation where several individuals leave the company if adequate additional workers are available if current development activity is known to anyone in the team, if current and systematic documentation is available, then every 'newcomer' will easily understand current development activity. Eventually, this would assist in continuing the work without any interval.
Fig 1: Risk management
Key takeaway :
- Risk Reduction is an operation for problem avoidance,
- Risk Monitoring is an operation to track programs,
- Risk Management entails contingency measures that can result in risk.
- The purpose of the risk mitigation, management, and monitoring strategy is to recognize as many potential threats as possible.
The software project plan may include a risk management approach or organize the risk management measures into a separate Risk Reduction, Tracking, and Management Plan. As part of risk analysis, the RMMM plan documents all work done and is used as part of the overall project plan by the project manager.
A structured RMMM document is not established by such software teams. Instead, using a risk information sheet, each risk is personally reported. In most cases, using a database system, the RIS is retained, so that development and entry of information, priority orders, searches, and other analysis can be done easily.
Risk reduction and monitoring measures begin once RMMM has been recorded and the project has begun. Risk reduction is an operation for problem avoidance, as we have already discussed. Danger monitoring is a project tracking operation with three main goals:
● Assessing whether expected risks occur;
● Ensuring that the risk aversion measures identified for the risk are properly implemented; and
● To gather the information that can be used for the prediction of potential risks.
Key takeaway :
- The process of developing options and actions to maximize prospects and mitigate risks to project goals is risk reduction planning.
- The RMMM plan documents all work done and is used as part of the overall project plan by the project manager.
Software configuration management (SCM) is an umbrella activity that is applied throughout the software process because change can occur at any time.
SCM activities are developed to
● Identify change,
● Control change,
● Ensure that change is being properly implemented, and
● Report changes to others who may have an interest.
It is important to make a clear distinction between software support and software configuration management. Support is a set of software engineering activities that occur after the software has been delivered to the customer and put into operation. Software configuration management is a set of tracking and control activities that begin when a software engineering project begins and terminate only when the software is taken out of operation.
A primary goal of software engineering is to improve the ease with which changes can be accommodated and reduce the amount of effort expended when changes must be made.
The output of the software process is information that may be divided into three broad categories:
● Computer programs (both source-level and executable forms);
● Documents that describe the computer programs (targeted at both technical practitioners and users), and
● Data (contained within the program or external to it).
The items that comprise all information produced as part of the software process are collectively called a software configuration.
As the software process progresses, the number of software configuration items (SCIs) grows rapidly. A System Specification spawns a Software Project Plan and Software Requirements Specification (as well as hardware related documents). These in turn spawn other documents to create a hierarchy of information.
If each SCI simply spawned other SCIs, little confusion would result. Unfortunately, another variable enters the process—change. Change may occur at any time, for any reason. The First Law of System Engineering states: “No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.”
There are four fundamental sources of change:
Software configuration management is a set of activities that have been developed to manage change throughout the life cycle of computer software. SCM can be viewed as a software quality assurance activity that is applied throughout the software process.
In certain situations, more than one risk can be traced to the issues that arise during a project. The attempt to assign origin (what risk(s) caused the problems in the project) is another risk monitoring mission.
Key takeaway :
- Software configuration management is a set of activities that have been developed to manage change throughout the life cycle of computer software.
- The number of software configuration items (SCIs) grows rapidly.
The SCM repository is a collection of processes and data structures that make it possible for a software team to efficiently handle changes.
Software Configuration Management(SCM) is a method used during the Software Development Life Cycle to routinely handle, coordinate, and monitor changes in documents, codes, and other entities.
Fig 2: Automated SCM repository
The role SCM Repository:
Entries are validated, accuracy ensured, cascades changed.
Shares data manages and controls multi-user access between production and tools.
Establishes a data model that several software engineering tools can use, restricting access to the data.
It enables different SCM tasks to be performed on one or more CSCMs.
Defines an object - relationship model for the repository that suggests a particular software engineering process model
Defines structures in the repository to guarantee a typical software engineering document creation approach
Key takeaway :
- The SCM repository is a collection of processes and data structures
- The primary objective is to improve efficiency with minimal errors.
- SCM is part of the cross-disciplinary configuration management area and will decide precisely who revised it.
Fig 3: the content of SCM repository
A disciplined framework for smooth control of work items is provided by configuration management. It requires the following operations:
Identification and Establishment –
Identification of configuration elements from goods composing baselines in time at given points (a baseline is a set of mutually consistent Configuration Items, which has been formally reviewed and agreed upon, and serves as the basis of further development).
Establishing relationships between objects, establishing a framework for managing multiple levels of control, and change management system processes.
Version control –
Using the SCM framework to construct versions/specifications of an existing product to develop new products.
Suppose the configuration object's version moves from 1.0 to 1.1 after some changes. Minor corrections and adjustments occur in the 1.1.1 and 1.1.2 versions, which are followed by a significant update to 1.2.
Object 1.0's growth continues through 1.3 and 1.4, but a notable update to the object ultimately results in a new evolutionary direction, version 2.0.0. It currently supports both models.
Fig 4: version control
Change control –
Controlling changes to Configuration items (CI).
To determine technical merit, possible side effects, the overall impact on other configuration artefacts and device functions, and the estimated cost of the update, a change request (CR) is submitted and assessed.
The assessment results are viewed as a change report used by a change control board (CCB)-a an individual or body that makes a final decision on the change's status and priority. For each approved change, and engineering change request (ECR) is created.
If the modification is refused for good reason, CCB often notifies the creator. The ECR outlines the improvements to be made, the constraints that need to be met, and the evaluation and audit criteria.
Fig 5: change control
The object to be altered is "checked out" from the database of the project, the alteration is made, and the object is reviewed again. The object is then 'checked in' to the database and the next version of the program is generated using acceptable version control mechanisms.
Configuration auditing –
Complementing the structured technical analysis of the process and product is a program configuration audit. It focuses on the functional correctness of the configuration object that has been modified
The audit checks the completeness, accuracy, and continuity of items from audit to closure in the SCM framework and monitors action items.
Reporting –
Providing developers, testers, end-users, customers, and stakeholders with accurate status and current configuration information through admin guides, user guides, FAQs, release notes, memos, installation guide, setup guide, etc.
Key takeaway :
- In the SCM method, the tasks need to be understood.
- Configuration detection, change control, version control, configuration auditing, and reporting are the five tasks of the SCM process.
- These tasks relate to software configuration items (SCIs) and as the project progresses, they can be seen as concentric layers that contribute to SCIs.
Configuration Management of Software Engineering Software is the role of monitoring and managing changes in the software aspect of the wider Configuration Management discipline.
In developing benchmarks, SCM activities provide vision controls. If something goes wrong, what was altered and who modified it can be decided by SCM.
Configuration, Detection, Configuration idioms and baselines, configuration monitoring, execution of a control change mechanism are usually the objectives of Software Configuration Management.
This is typically done by setting up a change control board with the primary purpose of approving or denying all requests for changes submitted against any baseline. Accounting, monitoring, and documentation of configuration status for all relevant details on the status of the development phase.
Fig 6: configuration management
5.11.1 CFEngine Configuration Tool
CFEngine is a configuration management platform that offers automatic configuration, including centralized management of servers, applications, users, embedded networked devices, mobile devices, and systems for large computer systems.
Developed By: Mark Burgess, Northern
Type: Open Source
Initial Release: 1993
Stable Release: 3.12
Operating System: Cross-Platform, UNIX, Windows
Company: Europe and USA
Adoption: >10,000,000 servers, >10,000 companies, >100 countries
Users: Intel, AT&T, LinkedIn, Amazon, State Farm, SalesForce, etc.
Revenue: Approx. $3.3 Million
Employees: Around 100 employees working currently
Website: CFEngine
CFEngine Tool images:
Fig 7: CFEngine tool images
5.11.2 Puppet Configuration Tool
Puppet is a configuration management tool for open-source applications. It is used to deploy servers, configure, and to operate them. It uses the architecture of master-slaves.
Configurations are pulled by the nodes from the master.
Fig 8: puppet works
Developed By: Luke Kanies.
Type: Open Source
Head Quarters: Portland, USA
Initial Release: 2005
Stable Release: 5.5.3 version
Based on Language: C++ and Clojure
Operating Systems: Linux, Unix, Windows
Annual Revenue: Approx. $100 Million
Employees: Around 600 employees working
Users: JP Morgan Chase, OnxyPoint, CBSButler, Heart Land, AT&T, Smart School, etc.
Website: Puppet SCM
Advantages -
● For automating and monitoring software, Puppet has strict compliance.
● Active group support through development tools is provided by Puppet.
● Puppet offers an intuitive web UI to handle various tasks, including monitoring and control of real-time nodes.
Disadvantages -
● There is a lack of sufficient error message when installing the Puppet system.
● Puppet support over pure Ruby versions is more of a priority for Puppet DSL.
● The mechanism is reversed by Puppet Lacks, so no immediate action on improvements is taken.
Fig 9: Screenshot of puppet works
Key takeaway :
- The SCM activities provide vision controls, in developing benchmarks.
- If something goes wrong, what was altered and who modified it can be decided by SCM.
- CFEngine is a configuration management platform that offers automatic configuration
- Puppet is a configuration management tool for open-source applications.
References:
2. S K Chang, ―Handbook of Software Engineering and Knowledge Engineering‖, World Scientific, Vol I, II, ISBN: 978-981-02-4973-1
