This section introduces how to use the measurement program to control the daily software development. The goal is to provide useful knowledge on the quality of software system development process and/or product.
| Guideline | Description |
|---|---|
| Tools selection | Tools used directly by software developers are good candidates for collecting data without putting an extra burden on the developers. |
| The use of automation | Project members should primarily concentrate on the development project, and spend as little time as possible on reporting data. One should strive for automatic measurement wherever possible. |
| The use of data collection forms | What cannot be recognized cannot be monitored. The easiest situation is when the desired quality indicators can be measured by numeric metrics. If direct and objective quantitative measurement cannot be found for the indicator, it might still be possible to evaluate the indicator by human assessment. If the desired indicator cannot be measured with specific metrics, it might still be able to collect subjective estimates or assessments. |
| Consider who will use the measurement results and when that happens. | In order to save project member (and other actors) time, the forms should be as few as possible, and easy to fill in. The forms should also hold all information necessary to understand how to fill it in. It should not be necessary to fill in data that could be automatically added. The fields in forms need to indicate what unit and accuracy level is to be used. Finally, there should be a field for comments. |
| Useful quality knowledge | The “useful quality knowledge” refers to the reactiveness of daily software development activities, but also to the proactiveness of making these things better in the future. The related analyses include efficient and effective
|
Employees must participate in all phases of the measurement program. Lack of project member involvement quickly leads to less internal support of the activity. It is also important to integrate measurements seamlessly with the ordinary project activities. Management also needs to have an active and visible role. They must commit themselves to actively supporting the changes that are suggested as a consequence of the measurement results.
Many types of data can help describe the status and quality of a project. You will probably find that tools that project members use as part of their projectrelated activities already collect some of the measurement data you want. Using tools for data collection makes it easier to get a consistent data collection, enabling comparison.
While automatic collection of data is preferred, some data can only be gathered by manual collection. You should use existing forms if such are present. You can extend these existing forms if you want to collect further information on the same subject.
| Guideline | Description |
|---|---|
| Automated measurements | In terms of process quality, the most important automated quality control measurement is the test coverage, also known as code coverage. In terms of product quality, the most important automated quality control measurement is the technical debt, which divides into subtopics of defect debt, requirements debt, documentation debt, and architectonic debt. |
| Expert judgements | Considering the state of the ongoing project with experts (e.g. architects, senior developers, project managers, quality assurance personnel, etc.) results to indepth understanding about the project. The automated measurement results regarding the quality goals provide a good starting point for such discussions. Conclude what goes well in the project and what needs to be improved. The aim is to create a bridge between the quality goals and the product and process quality. |
Quality control represents the reactive QA approach, which is used to support the decision making regarding the ongoing project. Its goal is to assure that the process and product quality goals are both reached. This goal divides into two methodological topics. The first topic covers automated analyses, which include calculations technical debt , test coverage analyses, and the use of prediction models. The second topic covers expert judgement methodologies, which include the estimations of defect dependencies and their priorities in terms of “what to do next?”
In terms of product quality, the most important automated quality control measurement is the technical debt, which divides into subtopics of defect debt, requirements debt, documentation debt, and architectonic debt. The key is to improve the product just in time and from correct aspects.In terms of process quality, the most important automated quality control measurement is the test coverage, also known as code coverage. It states the degree to which the source code is tested.
Expert judgement analyses are based on the perceptions of professionals, e.g., Daily StandUp meetings. Despite the fact that many of the quality control analyses can be automated (e.g. a correlation analysis can be automatically conducted as a part of the prediction models), the expert judgement is crucial to consolidate and prioritize the “real situation” in the project. The expert judgement analyses start by considering the state of the ongoing project, e.g., a Daily StandUp meeting defines what have been done, what to do next, and are there any open issues. The automated measurement results regarding the quality goals provide a good starting point for such discussions.
After understanding the state of the project, the open issues need to be prioritized in order to express what needs to be improved. Respectively, the things that go well needs to be compared with the open issues, in order to consider whether the used effort is aimed correct.