Hubert E. Dunsmore

Software Science Revisited: A Critical Analysis of the Theory and Its Empirical Support

The theory of software science was developed by the late M. H. Halstead of Purdue University during the early 1970s. It was first presented in unified form in the monograph Elements of Software Science published by Elsevier North-Holland in 1977. Since it claimed to apply scientific methods to the very complex and important problem of software production, and since experimental evidence supplied by Halstead and others seemed to support the theory, it drew widespread attention from the computer science community.

An analysis of several software defect models

Results are presented of an analysis of several defect models using data collected from two large commercial projects. Traditional models typically use either program matrices (i.e. measurements from software products) or testing time or combinations of these as independent variables. The limitations of such models have been well-documented. The models considered use the number of defects detected in the earlier phases of the development process as the independent variable. This number can be used to predict the number of defects to be detected later, even in modified software products. A strong correlation between the number of earlier defects and that of later ones was found. Using this relationship, a mathematical model was derived which may be used to estimate the number of defects remaining in software. This defect model may also be used to guide software developers in evaluating the effectiveness of the software development and testing processes. >

Analysis of the effects of programming factors on programming effort

Programming effort appears to be related to choices of programming language features which we call programming factors. A series of experiments was conducted investigating program construction, comprehension, and modification. Ease of construction seemed related to average nesting depth, percentage of global variables used for data communication, average variables referenced, and average live variables per statement. Data communication and live variables were shown to be related to ease of modification as well.

A study of several metrics for programming effort

As the cost of programming becomes a major component of the cost of computer systems, it becomes imperative that program development and maintenance be better managed. One measurement a manager could use is programming complexity. Such a measure can be very useful if the manager is confident that the higher the complexity measure is for a programming project, the more effort it takes to complete the project and perhaps to maintain it. Until recently most measures of complexity were based only on intuition and experience. In the past 3 years two objective metrics have been introduced, McCabes cyclomatic number v(G) and Halsteads effort measure E. This paper reports an empirical study designed to compare these two metrics with a classic size measure, lines of code. A fourth metric based on a model of programming is introduced and shown to be better than the previously known metrics for some experimental data.

Software metrics: An overview of an evolving methodology

Abstract A direct, algorithmic software metric is a rule for assigning a number or identifier to software. It is calculated algorithmically from the software alone. This paper describes (with examples) lines of code, cyclomatic complexity v(G), average nesting depth , and the software science length, effort , and time metrics. Software metrics that are to be used for time, cost, or reliability estimates should be validated statistically via data analyses that take into consideration the application, size, implementation language, and programming techniques employed. Such research should concentrate on metrics useful for large programs. Those that work for some languages may work for similar languages as well, i.e., those in the same “family”. Observing and measuring the work of professional programmers constructing software is probably the best means to conduct this type of analysis. We propose that this be a true joint effort, with early involvement between researchers and practitioners to establish what to measure and how to measure them. The critical need is for software metrics that can be calculated early in the software development cycle to estimate the time and cost involved in software construction.

Designing an interactive facility for non-programmers

This paper describes research (which is in its early stages) to investigate the best way of designing an interactive problem-solving computer system for people who are not programmers. The research is empirical and involves subjects solving problems on a representative system. Features of interest (which will become experimental treatments) include the means of sign-on and sign-off, the means of communication with the non-programmer, the process of matching a user with the appropriate package, the execution of such packages, and enhancements to such packages. This paper concludes with a description of a pilot experiment using a prototype system in which subjects with written documentation and those with no documentation at all were more productive than subjects with online system documentation. No performance differences were found in the factors of information display and single vs. multiple response capabilities.

Software Effort Estimation and Productivity

Publisher Summary This chapter is concerned about effort and cost estimation models which are appropriate for software project development. Project development is meant to include life cycle phases from project design, through system integration, to testing and software delivery. It discusses and evaluates several models for software effort estimation and performance of these models is compared on sets of projects for which some information is available. The models are categorized into (1) historical-experiential models, (2) statistically-based models, (3) theoretically-based models, and (4) composite models. There is some hope that effort and cost models so restricted can be developed which are transportable from one organization to another. The chapter concludes that further experimentation, the gathering of more data, and the combining and enhancing of models will be necessary in order to allow computer scientists to explain and better control the software development process.

Cognitive issues in the process of software development: review and reappraisal

The current information age has brought about radical changes in workforce requirements just as did the industrial revolution of the 1800s. With the presence of new technology, jobs are requiring less manual effort and becoming more Cognitiveoriented. With this shift, new techniques in job design and task analysis are required. One area which will greatly benefit from effective task analysis procedures is software development. This paper attempts to lay a groundwork for developing such procedures by discussing important methodological issues, and examining current theories and research findings for their potential to identify the cognitive tasks of computer programming. Based on the review, this paper suggests guidelines for development of a methodology suitable for knowledge elicitation of the programming process.

The effect of indentation on program comprehension

Abstract An experiment was conducted to study how different methods of indentation affect the ability of programmers to understand programs. The subjects were 72 students from an intermediate programming course. Each subject received one of three implementations of a short Pascal program. Each implementation used a different method of source code indentation: no indentation, “excessive indentation”, and Purdue University Department of Computer Science standard (moderate indentation). The subjects answered a 10-question test about the program. The scores of those subjects who received the program written in the departmental standard were better than the scores of the other two groups.

Back-to-front programming effort prediction

Abstract This paper considers metrics for estimating software development effort. We are attempting to develop a family of metrics that will explain effort after the completion of a project and predict remaining effort when applied at some milestone prior to completion. We suggest that a milestone is meaningful only if it is early enough so that effort prediction is worthwhile and only if it is clearly identifiable. We analyzed the construction process for twenty-seven Fortran programs. The total programming time for each program was divided into two components, the design/coding time and the debug time. We chose the FCC (first clean compiled, i.e. first syntax-error-free) version as a meaningful milestone. In our data we found that the actual effort spent before this milestone was about 70% of the total effort, with 30% remaining thereafter. Furthermore, our results suggest that if an effort model performs well in estimating total programming effort at the end of development, it will also perform well at milestone FCC. But, the metrics we examined were not very useful in predicting the amount of effort remaining after the FCC milestone-even though each predicted total effort accurately enough. More work must be done order to find or create such an estimator.