Seja a primeira pessoa a gostar disto
Wouldn’t it be nice if you could have more insight into the quality of a product, while it is developed, and not afterwards? To be able to estimate how many defects are inserted in the product in a certain phase, and how effective a (test) phase is in capturing these defects? The simple but effective model described in this paper makes it possible. It describes the model used in projects at Ericsson in the Netherlands. The model supports controlling the project (putting quality next to planning and budget data), evaluating risks, and taking decisions regarding product release and support.
To get more insight into the quality of the product during development, it is needed to measure the processes with two views: Introduction of defects, and detection of defects. Introduction is done during the requirements, architecture, design and coding phases; defects are either introduced into documents or into the actual product. Detection is done in test phases, and in the previously mentioned phases with inspections and reviews. By using these two measurements, a project can determine if and what the quality risk is: Too many defects in the product, or insufficient testing done.
To able to use the model in a broad set of projects, a template was made, including parts that are applicable in most projects in a configurable way. Also a user guide, with industry reference data, and training material and an overview presentation has been made.
The organization learned a lot from the model. Initially focus was on earlier defect detection, e.g. function- iso system test and inspection iso test. With the increase of data, more insight is acquired in design and coding activities, providing means for defect prevention. Now that data is available from a larger set of projects, processes can be compared enabling decisions about best practices from one project that can be spread towards future projects. Frequent estimation & feedback sessions with the design & test teams show that it is initially difficult to provide reliable estimates, but defect data that is acquired during the project enables early action taking, and better defect estimates resulting in early release quality predictions.
The presentation will focus upon:
• Goals: What is the purpose of the model, why developed, what do we want to reach?
• How: The definition of the model and implementation and application are highlighted.
• Tools: The tool that was developed to implement the model, how it works, strengths.
• Results: How does the model and tool help projects? Does it live up to its purpose?
• Success factors: What are the key issues that we are dealing successfully with? Why do we focus on them, and how? BTW: This includes searching for experiences with defect modeling, and applying available techniques like ODC and test matrices.
• Future: How is this model used in future projects, what could increase benefits?
The presentation will show many examples of actually using the model and tool and the benefits that it has brought to the project and organization. Furthermore it will show possibilities to manage process & product quality, and support decisions, based on data collected in the project and industrial data, i.e. without having to build up historical data in previous projects.
Additional the presentation will show what we have learned using this model, and how we have been able to apply available theories on defect prevention into a working model and tool. Of course there will be room for questions during the presentation