Will Tracz, our esteemed editor and Used-Program salesman, has written an entertaining, non-technical book dealing with the practice (and lack of) of software reuse. Its a collection of essays, mostly rehashed (reused?) and updated from various columns and papers published over the years.. Its a short (a bit over 200 pages) easy reading and enjoyable book (I read most of it in one sitting). Some of the essays discuss what was printed in the past and a discussion of the current status of the points.

Safeware: System Safety and Computers

This paper summarizes the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation.

Software engineering economics

Arguments for and against the deployment of formal methods in system design are rarely supported by evidence derived from experiments that compare a particular formal approach with conventional methods [2]. We illustrate an approach to the use of formal methods for secure code synthesis in safety-critical Avionics applications. The technique makes use of code components and uses sound introduction rules for the components to ensure constraints on their use are enforced. The approach we describe is the subject of a controlled experiment where it is running in parallel with the conventional approach. We describe the experiment and report some preliminary findings.

/pdf/secure-synthesis-of-code-a-process-improvement-experiment-3rvt1qmkmt.pdf

Secure Synthesis of Code: A Process Improvement Experiment

Exposing inconsistencies can uncover many defects in software specifications. One approach to exposing inconsistencies analyzes two redundant specifications, one operational and the other property-based, and reports discrepancies. This paper describes a "practical" formal method, based on this approach and the SCR (software cost reduction) tabular notation, that can expose inconsistencies in software requirements specifications. Because users of the method do not need advanced mathematical training or theorem-proving skills, most software developers should be able to apply the method without extraordinary effort. This paper also describes an application of the method which exposed a safety violation in the contractor-produced software requirements specification of a sizable, safety-critical control system. Because the enormous state space of specifications of practical software usually renders direct analysis impractical, a common approach is to apply abstraction to the specification. To reduce the state space of the control system specification, two "pushbutton" abstraction methods were applied, one which automatically removes irrelevant variables and a second which replaces the large, possibly infinite, type sets of certain variables with smaller type sets. Analyzing the reduced specification with the model checker Spin uncovered a possible safety violation. Simulation demonstrated that the safety violation was not spurious but an actual defect in the original specification.

/pdf/using-abstraction-and-model-checking-to-detect-safety-1wdiubepg6.pdf

Using abstraction and model checking to detect safety violations in requirements specifications

The paper describes three case studies in the lightweight application of formal methods to requirements modeling for spacecraft fault protection systems. The case studies differ from previously reported applications of formal methods in that formal methods were applied very early in the requirements engineering process to validate the evolving requirements. The results were fed back into the projects to improve the informal specifications. For each case study, we describe what methods were applied, how they were applied, how much effort was involved, and what the findings were. In all three cases, formal methods enhanced the existing verification and validation processes by testing key properties of the evolving requirements and helping to identify weaknesses. We conclude that the benefits gained from early modeling of unstable requirements more than outweigh the effort needed to maintain multiple representations.

/pdf/experiences-using-lightweight-formal-methods-for-1fys5zuvmf.pdf

Experiences using lightweight formal methods for requirements modeling

In an effort to improve the quality of software and system requirements, formal methods (FM) is being investigated by NASA because evidence existed that FM is useful in creating consistent and verifiable specifications. This investigation of FM consists of trial projects that are used to gather data on FM's cost-effectiveness and to demonstrate this effectiveness to prospective users. These trial projects were specifically constructed to maximize the likelihood that requirements analysts will recognize the benefits of FM and integrate it into their existing approaches. A key aspect of these trial-projects is the make-up of the teams which influenced the planning, execution, and evaluation of results. Through these projects, much has been learned about the use of FM and its potential for being accepted as a viable way to improve requirements analysis.

J. Kelly

Papers

Experiences using lightweight formal methods for requirements modeling

Experiences in applying formal methods to the analysis of software and system requirements