Software Metrics

The quality movement in the last years has a dramatic impact on all industrial sectors, reaching recently the systems and software industry. Reuse of products, processes and experiences originating from the system life-cycle is seen today as a feasible solution to the problem of developing higher quality systems at a lower cost. Managers and developers have to decide among different approaches to improve productivity and software quality. This paper relates the experiences in introducing., establishing and validating a goal-oriented approach to measurement and control of the quality and productivity in an industrial environment. Firstly, we will describe the basic quality methods applied like QIP and software metrics, then the main characteristics of the environment at the Daimler-Benz Aerospace AG (DASA) in Ulm. Finally, we present the experiences gained with the improvement of the industrial object-oriented systems development.

XOOM, a tool framework to support language independent experimentation with metrics measuring object-oriented product attributes on source-code level is presented. The framework consists of three layers: The frontend is responsible for parsing different object-oriented languages, establishing a repository of program structure information which represents the core layer. The backend of the tool consists of an extensible set of measurement routines operating on the repository.

The efficiency in the software development can only be keept by quantification of the software development components (of the software product and the software process itself). The quantification as software measurement needs a unified strategy, methodology or approach to guarantee the goals of quality assurance, improvement and controlled software management. Presently, plenty of methods such as measurement frameworks, maturity models, goal-directed paradigms, process languages etc. exist to support this idea.

This paper gives an overview about the measurement framework methodologies and describes an object-oriented approach of a software measurement framework. The presented framework was applied to the object-oriented software metrics area and leads to really object-oriented software metrics. The usability of this approach was described in some object-oriented software development examples.

The Function Point software measure does not require the use of a particular development technique. However, the high-level concepts of object-oriented development methods cannot be mapped directly to the concepts of Function Point Analysis. In order to apply this software measure early in the development process, the object-oriented concepts corresponding to transactional and data function types have to be determined.

Object-oriented methods differ, especially in their early development phases. The Object-Oriented Software Engineering method of Jacobson et al. is based on so-called use cases. The viewpoint of this method is similar to Function Point Analysis in the sense that it concentrates on the application’s functionality from the user’s perspective.

The OO-Jacobson approach identifies the functionality of an application with the requirements use case model. Data types are described with a domain or analysis object model on the requirements level. Our work proposes rules to map these models to the Function Point counting procedures. With the proposed rules, it is possible to count software developed with the OO-Jacobson method. Experimental counts have been conducted for three industry projects.

In order to apply the software metrics for the JAVA software development we use a general metrics classification of the University of Magdeburg in our Software Measurement Laboratory [DuFo96].

In the current trend towards the globalization of markets and the evolution of information and communication technologies, there is an inherent problem of privacy protection: it can be said that at the present there is a growing social preoccupation with the protection of privacy.-particularly with respect to personal data collection. The results of a recent study ([Wes95]) on consumers and privacy show that “three quarters (76%) of Canadians worry a lot over intrusions into their privacy.” Scepticism and fear with respect to technology explain this preoccupation, with 43% of Canadians thinking that technology is out of control. It is not surprising to learn, therefore that a great majority of Canadians (more than 70%) say that they will consider a company’s policies towards privacy and personal data protection before doing business with that company. From results of this study it should be expected that this preoccupation also exists in the United States and Europe.

A requirement for productivity models and productivity analysis is to know the size of the product, or the output, of a work process. In software engineering, the product is the software itself. Function Points Analysis (FPA) has been designed to measure the functional size of software applications from a user’s perspective. While it is being used extensively to measure either medium or large software development or enhancement projects, it has not been used to measure very small functional enhancements: its current measurement structure does not allow it to discriminate small size increments. This paper describes an extended version of FPA which is proposed to address this measurement issue of lack of sensitivity to small size changes. It also presents the design and the results of an empirical study carried out using this extended version.

Our Paper deals with the application of linear factor analytic models on software metrics. The model statement is interesting because it delivers an essential contribution for the discussion about the complexity of program systems from our view point. We show, that it is important, to consider the degrees of freedom of the transformability allowed for factor loading matrices in interpreting correlations. Moreover we suppose that investigations with the principal component model are too roughly designed for a better utilization of factor analysis in this field of applica­tion.

Managing software development and maintenance projects requires early knowledge about quality and effort needed for achieving this quality level. Effort estimations and staffing decisions are often based on productivity knowledge of the software development process. Quality-based productivity management is introduced as one approach for achieving and using such process knowledge. Fuzzy rules are used as a basis for constructing quality models that can identify outlying software components that might cause potential quality problems. This provides us with a fuzzy expert system tailored to the corresponding development environment. The value of any knowledge-based system is determined by the accuracy and cost of such predictions which are used to improve life-cycle productivity. Using the self-learning capability of neural networks, prestructured with genetic algorithms, the fuzzy rules can be automatically generated from example data to reduce the cost and improve the accuracy. The premises of the found rules consist of metrics drawing conclusions on the desired quality factors. The generated quality model - with respect to changes 2D provides both quality of fit (according to past data) and predictive accuracy (according to ongoing projects).

In this paper we identify main problems in packaging experience — insufficient structure, unsuitable classification and missing technical support — and introduce an approach in order to overcome these deficits. Main characteristic of this approach is a reprocessing of information beyond a problem-solution strategy. Other elements are classification schemes and a technical support by an experience base. An example and a conclusion complete this paper.

Benchmarking¹ studies based on actual data supplied by many industrial sites require two types of validation: validation of the collection process as well as validation of the data supplied to the researchers. The former validation will be referred to as a priori validation and the later one as a posteriori validation. The a priori validation will review all the steps and procedures of the data collection process within benchmarking data. The a posteriori validation will establish the degree of quality of the data collected and, wherever required, will eliminate from the comparative studies the data deemed not reliable. Both types of validation are required to ensure the quality and the integrity of the data for meaningful benchmarking studies in software engineering due the current immaturity of both software metrics and software engineering processes at industrial sites as assessed the maturity model developed by the Software Engineering Institute (USA).

Managing software development and maintenance projects requires predictions about components of the software system that are likely to have a high error rate or that need high development effort. Fuzzy knowledge-based techniques are introduced as a basis for constructing ruelbased quality models that can identify outlying software components that might cause potential quality problems. The suggested approach and ist advantages towards common classification and decision techniques is illustrated with experimental results. A module quality model — with respect to changes — provides both quality of fit (according to past data) and predictive accuracy (according to ongoing projects). Its portability is showed by applying it to industrial real-time projects.

As a flat steel producer situated in Linz/Upper Austria our core business does not include software development. Software is only produced inhouse for business processes where competitive advantages can be realized. That is the reason why in the past the software development process was not so well tuned as the steel production and order entry processes. Consequently we decided to introduce process improvement in software development. Beginning to migrate part of our organisation from traditional to object-oriented development style was the chance to show the benefits of a measurement program. We expected to overcome problems with the new OO technology at a very early stage of the project.