Recommendations and Risk Mitigation

Recommendations are really part of the assessment summary, not a separate phase in the assessment process, but they are so important we put them in a separate section. Developing recommendations is probably the most challenging part of the assessment, but it can also be the most beneficial part for the project.

There is no magic formula for developing recommendations. Just as the problems you identify will probably be unique for every assessment you do, so will the solutions and recommendations. However, reviewing good project management and risk mitigation techniques is useful for developing recommendations. A good understanding of the findings of software assessments and best practices in the industry will be helpful (for example, see Jones, 2000). Can dependency management help to resolve the potential for late test completion that you identified? Is more detailed planning required to successfully implement a new beta program? Can resources be shared across component teams of the project? If you are the project manager assessing the quality status of your project, this is the time to put your project manager hat back on. If you are the quality expert on the project team who is responsible for quality assessments, at this phase you need to think like a project manager.

Identification of risks and risk management is an important aspect of any assessment. It is akin to making a recommendation on a project checkpoint and is useful in determining the impact, consequences, or probable outcome of findings. Risk mitigation techniques include containing, reducing, or eliminating the risk. Table 15.2 shows risk management strategies as defined by the Project Management Institute, along with several examples. Brainstorming ideas for each type of strategy can help you to surface a viable solution to a risk or problem.

Table 15.2. Risk Mitigation Strategies





Minimize the occurrence of effect of the risk.

Establish and enforce a checklist for code integration (into the system library) to minimize problems during the driver build process.


Create an action plan in case the risk occurs.

Develop an incentive program for additional defect removal at "development complete" that involves testers, developers, and service specialists who have good customer perspectives in the event that defect arrival during the system test phase is higher than desirable (an indication of more latent defects in the product).


Transfer all or part of the risk to another party.



Accept the consequences if the risk occurs.


Avoid the risk as in

  • Use a different type of process.
  • Eliminate the feature.

Identify functions that can be removed if schedule pressures occur.

What Is Software Quality?

Software Development Process Models

Fundamentals of Measurement Theory

Software Quality Metrics Overview

Applying the Seven Basic Quality Tools in Software Development

Defect Removal Effectiveness

The Rayleigh Model

Exponential Distribution and Reliability Growth Models

Quality Management Models

In-Process Metrics for Software Testing

Complexity Metrics and Models

Metrics and Lessons Learned for Object-Oriented Projects

Availability Metrics

Measuring and Analyzing Customer Satisfaction

Conducting In-Process Quality Assessments

Conducting Software Project Assessments

Dos and Donts of Software Process Improvement

Using Function Point Metrics to Measure Software Process Improvements

Concluding Remarks

A Project Assessment Questionnaire

Metrics and Models in Software Quality Engineering
Metrics and Models in Software Quality Engineering (2nd Edition)
ISBN: 0201729156
EAN: 2147483647
Year: 2001
Pages: 176 © 2008-2020.
If you may any questions please contact us: