Abstract: This year’s WOW is going away from tradition a little, and is following a new production timeline. While in the past, the newsletter has been completely produced during the conference, this time around, we did most of the production before we arrived here in Edinburgh. Nevertheless, we promise to provide you with the same kind of snappy content that we have in the past. And be warned that we will not hesitate to write new articles while we are in Edinburgh... so watch out for the WOW staffers walking around with notepads (not the Windows kind) and cameras.

Abstract: Persistent software errors-those which are not discovered until late in development, such as when the software becomes operational-are by far the most expensive kind of error. Via analysis of software problem reports, it is discovered that the predominant number of persistent errors in large-scale software efforts are errors of omitted logic..., that is, the code is not as complex as required by the problem to be solved. Peer design and code review, desk checking, and ultrarigorous testing may be the most helpful of the currently available technologies in attacking this problem. New and better methodologies are needed.

Abstract: This paper describes the abstract interface principle and shows how it can be applied in the design of device interface modules. The purpose of this principle is to reduce maintenance costs for embedded real-time software by facilitating the adaptation of the software to altered hardware interfaces. This principle has been applied in the Naval Research Laboratory's redesign of the flight software for the Navy's A-7 aircraft. This paper discusses a design approach based on the abstract interface principle and presents solutions to interesting problems encountered in the A-7 re-design. The specification document for the A-7 device interface modules is available on request; it provides a fully worked out example of the design approach discussed in this paper.

Abstract: The state-of-the-art in software cost estimation is reviewed. The estimated cost of a software system varies widely with the model used. Some variation in cost estimation is attributable to the anomolies in the cost data base used in developing the model. The other variations, it is claimed are due to the presence or absence of certain ‘qualities’ in the final product. These qualities are measures of ‘goodness’ in design, development, and test-integration phases of software. To consider quality as a driver of software cost, we have suggested an association between cost and quality and have proposed a way to use quality metrics to estimate software cost.

Abstract: This paper discusses the necessity of a good methodology for the development of reliable software, especialy with respect to the final software validation and testing activities. A formal specification development and validation methodology is proposed. This methodology has been applied to the development and validation of a pilot software, incorporating typical features of critical software for nuclear power plant safety protection. The main features of the approach indude the use of a formal specification language and the independent development of two sets of specifications. Analyses on the specifications consists of three-parts: validation against the functional requirements consistency and integrity of the specifications, and dual specification comparison based on a high-level symbolic execution technique. Dual design, implementation, and testing are performed. Automated tools to facilitate the validation and testing activities are developed to support the methodology. These includes the symbolic executor and test data generator/dual program monitor system. The experiences of applying the methodology to the pilot software are discussed, and the impact on the quality of the software is assessed.

Abstract: A two-stage strategy, aimed first at understanding the role and characteristics of software environments and then at construction of experimental systems, distinguishes this near-term research plan.

Abstract: This paper reports the results of an experiment in applying large-scale software engineering procedures to small software projects. Two USC student teams developed a small, interactive application software product to the same specification, one using Fortran and one using Pascal. Several hypotheses were tested, and extensive experimenal data collected. The major conclusions were as follows.

Abstract: This paper describes a conceptual framework of software maintainability and an implemented procedure for evaluating a program's documentation and source code for maintainability characteristics. The evaluation procedure includes use of closed-form questionnaires completed by a group of evaluators. Statistical analysis techniques for validating the evaluation procedure are described. Some preliminary results from the use of this methodology by the Air Force Test and Evaluation Center are presented. Areas of future research are discussed.

Abstract: The successful construction of interactive systems requires the utilization of principles of user-centered design, combined with techniques for software engineering, in order to produce systems that are reliable, easy to use, and well adapted to user needs. This paper presents some of these principles and shows how they are achieved in the User Software Engineering (USE) project, which is intended to provide the applications developer with a development environment that supports the systematic specification and implementation of interactive systems.

Abstract: : This document describes the basic organization of NRL's version of the A-7E onboard flight software. The report describes a structure in which modules have been designed in accordance with the Information Hiding Principle. Because of the larger number of modules that result when this principle is applied, the modules are arranged in a hierarchy. The hierarchy should simplify the task of a maintenance programmer assigned to make a specific modification. The document also describes the principles used in the design of the software. It is intended to be useful both as a guide to the A-7E software and as a model for those developing other software systems. (Author)

Abstract: Within the past decade Computer Science researchers have begun to use controlled experimentation to address questions of human factors in the programming process. However, some of this work has been criticized for lack of experimental controls, insufficient sample sizes, and questionable generality. In a study of 160 student and professional programmers, several key biographical factors have been identified which account for a large proportion of performance variation on typical experimental tasks. The study has implications for subject selection and interpretation of results in software experimentation. Our findings should lead to improved experimental design and analysis techniques with increased confidence in the results of software psychology studies.

Abstract: The program complexity measure currently seems to be the most capable measure for both quantitative and objective control of the software project. Five program complexity measures (step count, McCabe's V(G), Halstead's E, Weighted Statement Count and Process V(G)) were assessed from such a viewpoint. This empirical study was done with the data collected through a practical software project. All of these measures have highly significant correlations with the management data. Application of complexity measures to software development management is discussed and a method for the detection of anomalous modules in a program is proposed.

Abstract: Spend your time even for only few minutes to read a book. Reading a book will never reduce and waste your time to be useless. Reading, for some people become a need that is to do every day such as spending time for eating. Now, what about you? Do you like to read a book? Now, we will show you a new book enPDFd quality assurance for computer software that can be a new way to explore the knowledge. When reading this book, you can get one thing to always remember in every reading time, even step by step.

Abstract: There has appeared in the literature a great number of metrics that attempt to measure the effort or complexity in developing and understanding software(1). There have also been several attempts to independently validate these measures on data from different organizations gathered by different people(2). These metrics have many purposes. They can be used to evaluate the software development process or the software product. They can be used to estimate the cost and quality of the product. They can also be used during development and evolution of the software to monitor the stability and quality of the product.Among the most popular metrics have been the software science metrics of Halstead, and the cyclomatic complexity metric of McCabe. One question is whether these metrics actually measure such things as effort and complexity. One measure of effort may be the time required to produce a product. One measure of complexity might be the number of errors made during the development of a product. A second question is how these metrics compare with standard size measures, such as the number of source lines or the number of executable statements, i.e., do they do a better job of predicting the effort or the number of errors? Lastly, how do these metrics relate to each other?

Abstract: An earlier paper presented a model based on software science metrics to give quantitative estimate of the number of bugs in a programming project at the time validation of the project begins. In this paper, we report the results from an attempt to expand the model to estimate the total number of bugs to expect during the total project development. This new hypothesis has been tested using the data currently available in the literature along with data from student projects. The model fits the published data reasonably well, however, the results obtained using the student data are not conclusive.

Abstract: Software is a valuable asset embodying decision processes of an organization and contributing directly to the means of production. Maintenance is the mechanism for combating deterioration of that software asset, which over time tends to become arthritic and inflexible to change. Maintenance, though extremely costly, is essential to insuring the viability of the organization. Both rewrites and purchased software, with ensuing conversions, are usually not a cost-effective solution to software decay. Structured retrofit is an effective alternative, using a software tools-based methodology for combating decay and the high costs of maintenance. The critical tool is the COBOL structured programming engine. With it, spaghetti code software is mechanically transformed to well-structured programs, whose ongoing maintenance reaps the benefits of the structured programming methodologies.

Abstract: The development of quantitative measures to evaluate software development techniques is necessary if we are going to develop appropriate methodologies for software production Data is collected by the Software Engineering Laboratory at NASA Goddard Space Flight Center on developing medium scale projects of up to ten man years effort In this study, cluster analysis was used on this collected data and several measures are proposed These measurements are objective, quantifiable, are the results of the methodology, and most important, seem relevant

Abstract: Algorithms are not the same as user software; which is like saying that pure mathematics is not the same as its application In earlier algebra conferences Risch and Norman (1976) and Norman and Davenport (1979) have described a new method for symbolic indefinite integration This paper is based on the work described there, but considers the process of turning this important area of algorithm research into a module for the REDUCE algebra system, in a form that can be used by the regular REDUCE user in the same way that he would differentiate or perform substitutions The software package that is described is the Utah version (REDUCE INT) of the original Norman and Moore (1976)implementation Rather than describe the method again, the paper concentrates on the software engineering and human engineering aspects of the package, and changes to the procedure that may not be mathematically justified but provide a powerful tool to the end user

Abstract: Experimental estimators are presented relating the expected number of software problem reports (B) in a software development project tothe overall reported professional effort (E) in “man months”the number of subprograms (n)the overall count of thousands of coded source statements of software(S)[equation]These estimators are shown to be consistent with data obtained from the Air Force's Rome Air Development Center, the Naval Research Laboratory, and Japan's Fujitsu Corporation Although the results are promising, more data is needed to support the validity of these estimators

Abstract: Traditionally, Japanese users have defined their own systems, but reliance on software houses is increasing.