What is Risk Analysis in SDLC?

 

Risk Analysis is one of the important concepts in Software Product Life Cycle. Risk analysis is broadly defined to include risk assessment, risk characterization, risk communication, risk management, and policy relating to risk.Risk Assessment is also known as Security risk analysis.

 

Risk Analysis: A risk analysis involves identifying the most probable threats to an organization and analyzing the related vulnerabilities of the organization to these threats.

 

Risk Assessment: A risk assessment involves evaluating existing physical and environmental security and controls, and assessing their adequacy relative to the potential threats of the organization.

 

Business Impact Analysis: A business impact analysis involves identifying the critical business functions within the organization and determining the impact of not performing the business function beyond the maximum acceptable outage. Types of criteria that can be used to evaluate the impact include: customer service, internal operations, legal/statutory and financial.

 

Business Impact Risks:

 

The following risk item issues identify some generic risks associated with business impact:

1.Affect of this product on company revenue?

2.Reasonableness of delivery deadline?

3.Number of customers who will use this product and the consistency of their needs relative to the product?

4.Number of other products/systems with which this product must be interoperable?

5.Amount and quality of product documentation that must be produced and delivered to the customer?

6.Costs associated with late delivery or a defective product?

 

Customer-Related Risks:

 

Different Customers have different needs. Customers have different personalities. Some customers accept what is delivered and some others complain about the quality of the product. In some other cases, customers may have very good association with the product and the producer and some other customers may not know. A bad customer represents a significant threat to the project plan and a substantial risk for the project manager.

 

The following risk item checklist identifies generic risks associated with different customers:

 

1.Have you worked with the customer in the past?

2.Does the customer have a solid idea of what is required?

3.Will the customer agree to spend time in formal requirements gathering meetings to identify project scope?

4.Is the customer willing to participate in reviews?

5.Is the customer technically sophisticated in the product area?

6.Does the customer understand the software engineering process?

 

Process Risks:

 

If the software engineering process is ill-defined or if analysis, design and testing are not conducted in a planned fashion, then risks are high for the product.

 

1.Has your organization developed a written description of the software process to be used on this project?

2.Are the team members following the software process as it is documented?

3.Are the third party coders following a specific software process and is there any procedure for tracking the performance of them?

4.Are formal technical reviews are done regularly at both development and testing teams?

5.Are the results of each formal technical review documented, including defects found and resources used?

6.Is configuration management used to maintain consistency among system/software requirements, design, code, and test cases?

7.Is a mechanism used for controlling changes to customer requirements that impact the software ?

 

Technology Risk:

 

1.Is the technology to be built new to your organization?

2.Does the software interface with new hardware configurations?

3.Does the software to be built interface with a database system whose function and performance have not been proven in this application area?

4.Is a specialized user interface demanded by product requirements?

5.Do requirements demand the use of new analysis, design or testing methods? 6.Do requirements put excessive performance constraints on the product?

 

Development Environment Risks:

 

1.Is a software project and process management tool available?

2.Are tools for analysis and design available?

3.Do analysis and design tools deliver methods that are appropriate for the product to be built?

4.Are compilers or code generators available and appropriate for the product to be built?

5.Are testing tools available and appropriate for the product to be built?

6.Are software configuration management tools available?

7.Does the environment make use of a database or repository?

8.Are all software tools integrated with one another?

9.Have members of the project team received training in each of the tools?

 

Risks Associated with Staff Size and Experience:

 

1.Are the best people available and are they enough for the project?

2.Do the people have the right combination of skills?

3.Are staffs committed for entire duration of the project?

 

 

 

FRAP analyzes one system, application or segment of business processes at time. FRAP assumes that additional efforts to develop precisely quantified risks are not cost effective because:

 

such estimates are time consuming, risk documentation becomes too voluminous for practical use specific loss estimates are generally not needed to determine if controls are needed. After identifying and categorizing risks, a team identifies the controls that could mitigate the risk. The decision for what controls are needed lies with the business manager. The team's conclusions as to what risks exists and what controls needed are documented along with a related action plan for control implementation.

 

Three of the most important risks a software company faces are unexpected changes in revenue and costs from those budgeted and amount of specialization of the software planned. Risks that affect revenues can be unanticipated competition, privacy, intellectual property right problems, and unit sales that are less than forecast; unexpected development costs also create risk that can be in the form of more rework than anticipated, security holes, and privacy invasions.

 

 

The risk management master plan (RMMP) is a critical part of risk management. The RMMP is a powerful tool which offers organizations a framework and processes for implementing risk management within their system structure. It is capable of protecting many of the resources which are most important to organizations, including their communication equipment, computers, and networking systems.

 

At the same time, the RMMP is very versatile and can be used whenever software is being developed. It can be used with both the new legacy systems and the older ones. The goal of this plan is to make sure that both risk assessment and the control that comes with it can be utilized in a manner which is both efficient and consistent.

 

To understand why organizations need to make use of an RMMP, it is first important to consider the things that the RMMP can assist you with. For example, it provides you with an approach to risk management which is structured. It also shows who in the organization has the responsibility of carrying out specific tasks. It is also useful to think of the contents which are connected to the project plans.

 

RMMP allows you to measure both probability and severity. It gives you the ability to think of the factors which could dramatically contribute to assessing the many risks you face, but it will do this at a very high level. It also offers a number of steps which are detailed when it comes to risk management.

 

The RMMP is designed to work with the infrastructure of your network, along with the computer systems, the spreadsheet programs, and the legacy systems as well. One thing that you must keep in mind is that the elements of the Risk Management Master Plan may be broken down into a number of goals and categories.