Metrics and Reporting
A crucial dimension of managing projects is the use of progress and status reporting. A key element of such reporting is quality reporting, which covers both progress versus plan and quality status, normally covered by defect reports. This is all covered in the Metisure© framework.
The assembly of all this data at a portfolio level and the maintenance of an historic base of data are a vital input to overall software quality measures. The set of measures or metrics are used to identify what elements of the software quality model need to be improved and why. These are all defined and used in the Metisure© Process Improvement Process.
Software metrics can be classified into three categories: product metrics, process metrics and project metrics. Product metrics describe the characteristics of the product such as size, complexity, design features etc. and are covered by definitions, specifications, estimates etc. Project metrics describe the project characteristics and execution e.g. team size, duration, and are covered by project plans and progress reports. Process metrics can be used to improve software development and maintenance.
Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process and project. Software quality metrics are used in two ways. The first links to product and project metrics in that reporting progress and status of software quality and testing is a key part of programme reporting and governance. The second dimension focuses on the use of software quality metrics to continually assess the effectiveness of the software Quality and Testing Operating model and take actions to improve the quality of the process of developing software through the full development lifecycle.
Standard Programme reporting is normally aligned to programme/project overall plans and governance, and covers progress reports, defect metrics, both point in time and trend analysis. It is also used to support impact analysis of proposed changes and to input to “early warning” of major quality threats to project success. A Risk and issue register is held for the software Quality Assurance and Testing element of the programme/project and aligned with the overall risk and issue management governance process of the programme/project.
All of the base data used to support Programme reporting is a key input to overall Software Quality Metrics. These measures are used as the “in-process” metrics. Added to these in-process metrics are project characteristics, e.g. team size and structure, schedule pressure, change level and volatility, and measures of end product quality. The end product quality measures are normally derived from help desk/user support data and problem and incident reporting data. It seeks to identify the level of customer satisfaction/issues with the final product, the severity of the issues and the time to failure.
The focus of the Process Improvement Process is to investigate the relationship between the sets of metrics at a portfolio level and to put in place improvements in the overall development life cycle. A crucial element of this is the ability to identify the “root cause” of failure in order to direct improvement action in the correct area of the operating model. A full scale Process Improvement Process requires sustained focus, commitment and energy so our PIP is scalable to meet client needs.