Given the central role that software development plays in the delivery and application of information technology, managers are increasingly focusing on process improvement in the software development area. This demand has spurred the provision of a number of new and/or improved approaches to software development, with perhaps the most prominent being object-orientation (OO). In addition, the focus on process improvement has increased the demand for software measures, or metrics with which to manage the process. The need for such metrics is particularly acute when an organization is adopting a new technology for which established practices have yet to be developed. This research addresses these needs through the development and implementation of a new suite of metrics for OO design. Metrics developed in previous research, while contributing to the field's understanding of software development processes, have generally been subject to serious criticisms, including the lack of a theoretical base. Following Wand and Weber (1989), the theoretical base chosen for the metrics was the ontology of Bunge (1977). Six design metrics are developed, and then analytically evaluated against Weyuker's (1988) proposed set of measurement principles. An automated data collection tool was then developed and implemented to collect an empirical sample of these metrics at two field sites in order to demonstrate their feasibility and suggest ways in which managers may use these metrics for process improvement. >

/pdf/a-metrics-suite-for-object-oriented-design-539bycjzzb.pdf

A metrics suite for object oriented design

The problems of designing large software systems were studied through interviewing personnel from 17 large projects. A layered behavioral model is used to analyze how three of these problems—the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication bottlenecks and breakdowns—affected software productivity and quality through their impact on cognitive, social, and organizational processes.

http://www.cs.rug.nl/search/uploads/Teaching/RE2009Fall/paper/1988_Curtis_ACMC_A%20Field%20Study%20of%20the%20Software%20Design%20Process%20for%20Large%20Systems.pdf

A field study of the software design process for large systems

This paper presents the findings of an empirical study into two organizations' experiences with the adoption and use of CASE tools over time. Using a grounded theory research approach, the study characterizes the organizations' experiences in terms of processes of incremental or radical organizational change. These findings are used to develop a theoretical framework for conceptualizing the organizational issues around the adoption and use of these tools-issues that have been largely missing from contemporary discussions of CASE tools. The paper thus has important implications for research and practice. Specifically, the framework and findings suggest that in order to account for the experiences and outcomes associated with CASE tools, researchers should consider the social context of systems development, the intentions and actions of key players, and the implementation process followed by the organization. Similarly, the paper suggests that practitioners will be better able to manage their organizations' experiences with CASE tools if they understand that such implementations involve a process of organizational change over time and not merely the installation of a new technology.

CASE tools as organizational change: investigating incremental and radical changes in systems development

This paper aims to provide a basis for the improvement of software-estimation research through a systematic review of previous work. The review identifies 304 software cost estimation papers in 76 journals and classifies the papers according to research topic, estimation approach, research approach, study context and data set. A Web-based library of these cost estimation papers is provided to ease the identification of relevant estimation research results. The review results combined with other knowledge provide support for recommendations for future software cost estimation research, including: 1) increase the breadth of the search for relevant studies, 2) search manually for relevant papers within a carefully selected set of journals when completeness is essential, 3) conduct more studies on estimation methods commonly used by the software industry, and 4) increase the awareness of how properties of the data sets impact the results when evaluating estimation methods

/pdf/a-systematic-review-of-software-development-cost-estimation-4p2ftti9uq.pdf

A Systematic Review of Software Development Cost Estimation Studies

Case studies help industry evaluate the benefits of methods and tools and provide a cost-effective way to ensure that process changes provide the desired results. However, unlike formal experiments and surveys, case studies do not have a well-understood theoretical basis. This article provides guidelines for organizing and analyzing case studies so that they produce meaningful results. >

Case studies for method and tool evaluation

Defect causal analysis offers a simple, low-cost method for systematically improving the quality of software produced by a team, project, or organization. DCA takes advantage of one of the most widely available types of quality information, the software problem report. This information drives a team-based technique for defect causal analysis. The analysis leads to process changes that help prevent defects and ensure their early detection. The paper discusses the three principles that drive the DCA approach. It considers the impact of DCA on an organization.

Learning from our mistakes with defect causal analysis

Measuring software design complexity

Results of an empirical study of software design practices in one specific environment are reported. The practices examined affect module size, module strength, data coupling, descendant span, unreferenced variables, and software reuse. Measures characteristic of these practices were extracted from 887 Fortran modules developed for five flight dynamics software projects monitored by the Software Engineering Laboratory. The relationship of these measures to cost and fault rate was analyzed using a contingency table procedure. The results show that some recommended design practices, despite their intuitive appeal, are ineffective in this environment, whereas others are very effective.

/pdf/an-empirical-study-of-software-design-practices-38dgwd36b1.pdf

An empirical study of software design practices

Many new software development practices, tools, and techniques have been introduced in recent years. Few, however, have been empirically evaluated. The objectives of this study were to measure technology use in a production environment, develop a statistical model for evaluating the effectiveness of technologies, and evaluate the effects of some specific technologies on productivity and reliability. A carefully matched sample of 22 projects from the Software Engineering Laboratory database was studied using an analysis-of-covariance procedure. Limited use of the technologies considered in the analysis produced approximately a 30 percent increase in software reliability. These technologies did not demonstrate any direct effect on development productivity.

Evaluating Software Engineering Technologies

Most businesses outside the software-engineering community, like hardware manufacturers and service suppliers, have made statistical process control part of their development regimen. Does this mean we can ultimately expect the technique to penetrate the software world? Although a few pioneers (mostly practitioners) have attempted to use statistical process control in software-engineering applications, the opinion of many academics and practitioners is that it simply doesn't fit in the software world. These objections probably stem from an unfamiliarity with the technique and how to use it to best advantage. Many tend to dismiss it simply on the grounds that software can't be measured, but properly applied, statistical process control can flag potential process problems, even though it cannot supply absolute scores or goodness ratings. >

David N. Card

Papers

Learning from our mistakes with defect causal analysis

Measuring software design complexity

An empirical study of software design practices

Evaluating Software Engineering Technologies

Statistical process control for software