Lessons learnt from the analysis of large-scale corporate databases

Abstract

This paper presents the lessons learnt during the analysis of the corporate databases developed by IBM Global Services (Australia). IBM is rated as CMM level 5. Following CMM level 4 and above practices, IBM designed several software metrics databases with associated data collection and reporting systems to manage its corporate goals. However, IBM quality staff believed the data were not as useful as they had expected. NICTA staff undertook a review of IBM's statistical process control procedures and found problems with the databases mainly due to a lack of links between the different data tables. Such problems might be avoided by using M 3 P variant of the GQM paradigm to define a hierarchy of goals, with project goals at the lowest level, then process goals and corporate goals at the highest level. We propose using E-R models to identify problems with existing databases and to design databases once goals have been defined.

An empirical investigation of software reuse benefits in a large telecom product

“…Goals: As discussed by Kitchenham et al [2006], databases should support a hierarchy of goals for corporate, project, and software processes. Reuse in this case was a corporate decision, but RUP and the project metrics were not updated to collect data to evaluate reuse costs or benefits.…”

“…We have observed such problems with industrial data in other studies as well (see Mohagheghi et al [2006]). Kitchenham et al [2006] reported several problems when analyzing large corporate databases developed by IBM Global Services in Australia, to the extent that defect data were not useful for analysis. However, the impact of missing data or ill-defined goals and processes on the studies is not discussed in the papers in Table I.…”

Issues and effort in integrating data from heterogeneous software repositories and corporate databases

“…While each repository and database has its specific purpose it serves well, a unified view nevertheless requires coordinated design based on defined information requirements. This problem has been found by Kitchenham et al even when analyzing large-scale databases of a CMM level 5 company [6]. The resulting issues we encountered in integrating the data from these heterogeneous software repositories and corporate databases are manifold.…”

A Framework for Defect Prediction in Specific Software Project Contexts

“…Despite the success reported by many studies, the prediction of defects in a particular project may not be possible. Typical reasons are the poor quality of the available data [6] or the effort required to extract and collect the necessary data [23]. Most published studies report solely successful cases of defect prediction.…”