Search

Software size estimates provide a basis for soft- ware cost estimation during software development. Hence, it is important to measure the system size reliably as early as possible, i.e., during the requirements specification. Two best known specification level metrics are Albrecht's Function Points and DeMarco's Function Bang. One problem in using these metrics has been that there are only few tools that can calculate them during the specification phase. We have built one such tool. Another problem has been that no research data is available how these metrics correlate with one another. The paper compares these two metrics by a simulation study in which automatically generated randomized dataflow diagrams (DED's) were used as a statistical sample to count automatically function points and function bang in a built CASE environment. These value counts were correlated statistically using correlation coefficients and regression analysis. The simulation study permits sufficient variation in the base material to cover most types of system specifications. Moreover, it allows sufficient sampling sizes to make statistical analysis of data. The obtained results show that in certain cases there is a relatively good statistical correlation between these metrics. No overall general correlation exists, however. The paper does not show which one of the two metrics fares better as a size metric. Yet, our study suggests to use in many cases Function Bang metric, because its automatic calculation is simpler and depends less on judgement. Moreover, the study demonstrates that correlations depend upon a system type. This implies that in software projects one must be careful with size estimates while using these metrics. In order to know when one needs to calibrate the size estimate we need to develop algorithms which help to detect logical system types and make adjustments accordingly. The results also point out the need of empirical research in which we can better derive the connection between specification level metrics and the number of lines of code. [ABSTRACT FROM AUTHOR]

This paper discusses the goals and methods of the Toolpack project and in this context discusses the architecture and design of the software system being produced as the focus of the project. Toolpack is presented as an experimental activity in which a large software tool environment is being created for the purpose of general distribution and then careful study and analysis. The paper begins by explaining the motivation for building integrated tool sets. It then proceeds to explain the basic requirements that an integrated system of tools must satisfy in order to be successful and to remain useful both in practice and as an experimental object. The paper then summarizes the tool capabilities that will be incorporated into the environment. It then goes on to present a careful description of the actual architecture of the Toolpack integrated tool system. Finally the Toolpack project experimental plan is presented, and future plans and directions are summarized. [ABSTRACT FROM AUTHOR]

One of the most important problems faced by software developers and users is the prediction of the size of a programming system and its development effort. As an alternative to "size," one might deal with a measure of the "function" that the software is to perform. Albrecht [1] has developed a methodology to estimate the amount of the "function" the software is to perform, in terms of the data it is to use (absorb) and to generate (produce). The "function" is quantified as "function points," essentially, a weighted sum of the numbers of "inputs," "outputs," master files," and "inquiries" provided to, or generated by, the software. This paper demonstrates the equivalence between Albrecht's external input/output data flow representative of a program (the "function points" metric) and Halstead's [2] "software science" or "software linguistics" model of a program as well as the "soft content" variation of Halstead's model suggested by Gaffney [7]. Further, the high degree of correlation between "function points" and the eventual "SLOC" (source lines of code) of the program, and between "function points" and the work-effort required to develop the code, is demonstrated. The "function point" measure is thought to be more useful than "SLOC" as a prediction of work effort because "function points" are relatively easily estimated from a statement of basic requirements for a program early in the development cycle. The strong degree of equivalency between "function points" and "SLOC" shown in the paper suggests a two-step work-effort validation procedure, first using "function points" to estimate "SLOC," and then using "SLOC" to estimate the work-effort. This approach would pro- vide validation of application development work plans and work-effort estimates early in the development cycle. The approach would also more effectively use the existing base of knowledge on producing "SLOC" until a similar base is developed for "function points." The paper assumes that the reader is familiar with the fundamental theory of "software science" measurements and the practice of validating estimates of work-effort to design and implement software applications (programs). If not, a review of [1] -[3] is suggested. [ABSTRACT FROM AUTHOR]

Software productivity has been steadily increasing over the past 30 years, but not enough to close the gap between the demands placed on the software industry and what the state of the practice can deliver [22], [39]; nothing short of an order of magnitude increase in productivity will extricate the software industry from its perennial crisis [39], 1671. Several decades of intensive research in software engineering and artificial intelligence left few alternatives but software reuse as the (only) realistic approach to bring about the gains of productivity and quality that the software industry needs. In this paper, we discuss the implications of reuse on the production, with an emphasis on the technical challenges. Software reuse involves building software that is reusable by design and building with reusable software. Software reuse includes reusing both the products of previous software projects and the processes deployed to produce them, leading to a wide spectrum of reuse approaches, from the building blocks (reusing products) approach, on one hand, to the generative or reusable processor (reusing processes), on the other 1681. We discuss the implication of such approaches on the organization, control, and method of software development and discuss proposed models for their economic analysis. Software reuse benefits from methodologies and tools to: 1) build more readily reusable software and 2) locate, evaluate, and tailor reusable software, the last being critical for the building blocks approach. Both sets of issues are discussed in this paper, with a focus on application generators and OO development for the first and a thorough discussion of retrieval techniques for software components, component composition (or bottom-up design), and transformational systems for the second. We conclude by highlighting areas that, in our opinion, are worthy of further investigation. [ABSTRACT FROM AUTHOR]

Effective management of the software development process requires that management be able to estimate total development effort and cost. One of the fundamental problems associated with effort and cost estimation is the a priori estimation of software size. Function point analysis has emerged over the last decade as a popular tool for this task Following its use over this time, however, a number of criticisms of the method have emerged. These criticisms relate to the way in which function counts are calculated and the impact of the processing complexity adjustment on the function point count. SPQR/20 function points among others are claimed to overcome some of these criticisms. This paper compares the SPQR/20 function point method to traditional function point analysis as a measure of software size in an empirical study of MIS environments. In a study of 64 projects in one organization it was found that both methods would appear equally satisfactory. However consistent use of one method should occur since the individual counts differ considerably. [ABSTRACT FROM AUTHOR]

In this paper, an integrated life-cycle model is presented for use in a software maintenance environment. This model, which represents information about the development and maintenance of software systems, emphasizing relationships between different phases of the software life cycle, provides the basis for automated tools to assist maintenance personnel in making changes to existing software systems. This model is independent of particular specification, design and programming languages because it represents only certain "basic" semantic properties of software systems: control flow, data flow, and data structure. The software development processes by which one phase of the software life cycle is derived from another are represented by graph rewriting rules, which indicate how various components of a software system have been implemented. This approach permits analysis of the basic properties of a software system throughout the soft- ware life cycle. Examples are given to illustrate the integrated software life-cycle model during evolution. [ABSTRACT FROM AUTHOR]

Software metric refer only to its more limited definition as a measure derived from the requirements, specification, design, code or documentation of a computer program. These metrics are computed for the purpose of predicting some outcome of the software development process which is believed to be affected by the software characteristics being measured. Problems in statistical analysis have ranged from an inadequate number of data points for detecting a significant effect, to begging the existence of an effect by employing an arbitrarily low significant level.

This paper summarizes our experience in the Programmer's Apprentice project in applying knowledge representation and automated reasoning to support software development. We describe a system, called Cake, that comprises seven layers of knowledge representation and reasoning facilities: truth maintenance, Boolean constraint propagation, equality, types, algebra, frames, and Plan Calculus. We also include sessions with two experimental software development tools implemented using Cake: the Requirements Apprentice and the Debugging Assistant. [ABSTRACT FROM AUTHOR]

This paper describes a computerized environment, SODOS (Software Documentation Support), which supports the definition and manipulation of documents used in developing software. An object oriented environment is used as a basis for the SODOS interface. SODOS is built around a Software Life Cycle (SLC) Model that structures all access to the documents stored in the environment. One advantage of this model is that it supports software documentation independent of any fixed methodology that the developers may be using. The main advantage of the system is that it permits traceability through each phase of the Life Cycle, thus facilitating the test and maintenance phases. Finally the effort involved in learning and using SODOS is simplified due to a sophisticated "user-friendly" interface. [ABSTRACT FROM AUTHOR]

Program structure is designed, redesigned, and develops and changes during the development phase. This paper describes a mini methodology for generation and representation of design and program structures, and structural consistency checking between two successive designs or between a design and a program. The mini methodology is based on the following. 1) The tool: a special Program Design Language (PDL) which is equipped to extract the actual and complete structure information from design documents and programs, or partial structure information—when required. 2) The representation: two matrices, a Call Relationship Matrix (CRM) and a Global References Matrix (GRM), which completely rep- resent the program structure. 3) The consistency criteria: clear definitions when the structures of two successive designs, or a design and a program, are consistent. The PDL extracts structure information, in a controlled way, from the top level program design, through layers of detailed designs, down to the source code itself. It generates an actual, complete, concise, and easily comparable structure representation. Structural consistency between levels can be checked, both at the development phase and at the operation and maintenance phase, ensuring continued structural consistency between the design(s) and the program. The structure representation can also be used for configuration management of the structure of designs and programs. [ABSTRACT FROM AUTHOR]

Shankar and Lam propose a projection method for protocol verification. They claim that the method guarantees the faithfulness of the safety and liveness properties of a protocol system. Although not clearly defined, "faithfulness" (as implied in many places in their article) means "the image protocol system is live (respectively, safe) if and only if the original protocol system is live (respectively, safe)." This paper shows that the "only if" part is not true for certain liveness properties and suggests a remedy. [ABSTRACT FROM AUTHOR]

Evaluating software development environments has become an important concern in recent years. We have per- formed a study that evaluates new-paradigm-oriented software development environments which have been developed in a five- year R&D project. (This project is the FASET (Formal Approach to Software Environment Technology) plan at JSD (Joint System Development Corporation), which was supported by MITI (the Ministry of International Trade and Industry) and WA (Information-Technology Promotion Agency).) For this study, we have developed a software environment evaluation technology based on a software quality evaluation process model defined in ISO/IEC 9126 [1]. The evaluation technology has been applied to the R&D project at the middle and final phase of development. The evaluation results provide useful information to develop a widely acceptable evaluation technology, and to improve those new-paradigm-oriented software development environments which are based on various specification methods: the algebraic specification method, function-oriented specification method, declarative specification method, natural- language-oriented specification method, diagrammatic specification method, state-transition-oriented specification method, and model-based specification method. [ABSTRACT FROM AUTHOR]

Genesis is a software-engineering-based programming environment geared to support big software projects. We first discuss a reusability-driven development methodology that advocates software development based on reusability considerations. Then, we discuss the tools and techniques provided in Genesis to support this methodology. We suggest techniques for improving the retrievability, composability, and understandability of software resources. Retrievability is improved by the use of the Entity Specification Language for tying resources through attributes and relations. Composability is improved through a mechanism called functional composition that provides considerably more generality than Unix® pipes for composing programs. Understandability is improved by the use of program abstractors. [ABSTRACT FROM AUTHOR]

The function point method of measuring application development productivity developed by Albrecht is reviewed and a productivity improvement measure introduced. The measurement methodology is then applied to 24 development projects. Size, environment, and language effects on productivity are examined. The concept of a productivity index which removes size effects is defined and an analysis of the statistical significance of results is presented. [ABSTRACT FROM AUTHOR]