Risk Analysis

Risk Analysis is one of the concepts of key importance in Software Product Life Cycle. It generally includes areas like risk assessment, risk characterization, risk communication, risk management, and policies relating to the risk. It is also known as Security Risk Analysis.

Following terms related to Risk Analysis need to be understood clearly

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.  

Few of the Risks associated with software product are described as under:

1) Product Size Risks:

Few generic risks associated with the size of the product are:

• Estimated size of the product and confidence in estimated size?
• Estimated size of product?
• Size of the database created or used by the product?
• Number of users of the product?
• Number of projected changes to the requirements for the product?

Risk will be high, when a large deviation is observed between expected results and the results from the past experience. As a best practice, expected information must be compared with previous experience for carrying out the analysis of risk.

2) Business Impact Risks:

Few generic risks associated with the business impact are:

• Effect of the software product on revenue of the company?
• Reasonability of target dates for delivery?
• Number of customers expected to use the product
• Consistency in the needs of the customers relative to the product?
• Number of other products / systems with which the concerned product is expected to be nteroperable?
• Amount and quality of product documentation which must be produced and delivered to the customer?
• Costs associated with delayed delivery or a defective product?

3) Customer-Related Risks:

Following Checklist can be helpful in identifying generic risks associated with different types of customers:

• Have you worked with the customer in the past?
• Does the customer have a good idea of what is required?
• Will the customer agree to spend time in formal requirements gathering meetings to identify project scope?
• Is the customer willing to participate in reviews?
• Is the customer technically knowledgeable in the product area?
• Does the customer understand the software engineering process?  

4) Process Related Risks:

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

• Whether the organization has a documented software development process planned for the concerned project?
• Whether the team members are following the documented software development process?
• Whether the third party programmers are also following the defined software development.
• Is there any mechanism for keeping a track on the performance of third party programmers?
• Whether the development teams and testing teams are conducting formal technical reviews at regular intervals?
• Whether results of every formal technical review (covering information on defects found and resources used) are properly documented?
• Whether configuration management is used to maintain consistency among system / software requirements, design, code, and test cases?
• Is there any mechanism for controlling changes to customer requirements which have impact on the software product?

5) Technology Related Risks:

• Whether the technology being built is new to the organization?
• Whether the software has proper interface with new hardware configurations?
• Whether the software has proper interface with the database system whose function and performance have not been proven in the concerned application area?
• Whether any specialized user interfaces have been demanded by product requirements?
• Do requirements demand the use of any new analysis, design or testing methods?
• Do requirements put excessive performance constraints on the product?

6) Technical Risks:

• Are specific methods used for software analysis?
• Are specific conventions for code documentation defined and used?
• Are any specific methods used for test case design?
• Are software tools used to support planning and tracking activities?
• Are configuration management tools used to control and track change activity throughout the software development process?
• Are tools used to create software prototypes?
• Are tools used to support the testing process?
• Are tools used to support the production and management of documentation?
• Are quality metrics collected for all software projects?
• Are productivity metrics collected for all software projects?  

7) Environmental Risks:

• Whether a software project and process management tool available in the organization?
• Whether tools for analysis and design are available in the organization?
• Do analysis and design tools deliver methods which are appropriate for the product to be built?
• Whether compilers or code generators are available and are appropriate for the product to be built?
• Whether testing tools are available and are appropriate for the product to be built?
• Whether software configuration management tools are available in the organization?
• Does the environment make use of a database or repository?
• Whether all software tools are properly integrated with each another?
• Whether all members of the project team have received training on every tools?  

8) Team Associated Risks :

• Whether best people are available and are they enough in numbers for the project?
• Do the people have the right combination of skills?

        Whether all team members are committed for the entire duration of the project?

Testing is the means used in software development to reduce risks associated with a system. By testing, we hope to identify many of the problems before they get to the customer, thereby reducing the system’s risk. Unfortunately, testing alone can’t find all of the bugs and with the rapid pace of application development in the today’s world, testing has become a challenging proposition and often just doesn’t get done.

Trying to meet even tighter deadlines while still delivering products that meet customer requirements is the greatest challenge testers face today. Formulating answers to age-old questions like “What should we test?” and “How long do we test?” requires different strategies in fast-paced environments.

• Does the product meet our quality expectations?
• Is the application ready for users?
• What can we expect when 2,000 people hit the site?
• What are we risking if we release now?

This one day course focuses on identifying, prioritizing risks and developing the right test strategy to help testers provide the input that management needs to make informed product release decisions.