risk management

While the test organization is normally considered the "Subject Matter Expert" within a software company, it is rarely charged with leading a software development effort. In fact, with the increased popularity of Extreme Programming and specifically the concept of Test-Driven Development (TDD), many testers are working to expand their skill sets so that they can adapt to a changing test culture where they will be viewed as part of the development organization. In this article, Scott Lazenby details some of the ways testers infuse the development mentality into their project management.

The glitter and power of new technology can blind the eyes of those not fully cognizant of its true function. In Peter Clark's article "Captain Composite," he says, "The tool (technology) can become the product rather than a means to the project's goal." Enthusiasm born of this fascination for novelty tends to overpower one's ability to accurately assess the technology's limitations and risks. As a result, risk management is lost in the hype. Peter's tale of the fallible, almost quixotic, "Captain Composite" warns us that disregarding risk management inevitably leads to the pitfall of any project.

No matter how well we plan and execute software development, defects are generated and can escape to the customers. Failure to quickly resolve software problems leads to negative consequences for our customers and increases internal business costs. A quick deterministic
method to prioritize problems and implement their solution helps to reduce cycle time and costs. Achieving this goal requires several steps. The first is to determine a model that links problem resolution performance to institutional variables and problem characteristics. Statistical Design of
Experiments (DOE) is a tool that provides data requirements for estimating the impacts of these variables on problem resolution. Once data has been gathered, the results of statistical analysis can be input into a mathematical optimization model to guide the organization.
This paper describes such an analysis.

This presentation re-emphasizes that requirements are important. The difference between functional and nonfunctional requirements will be covered. Then, Product Risk Analysis will be described, along with the elements of the analysis and steps toward performing the analysis.