ABSTRACT

An increasing range of industries have a growing dependence on software-based systems,many of which are safety-critical,real-time applications that require extremely high dependability.Multi-version programming has been proposed as a method for increasing the overall dependability of such systems -however,the increased cost of using this approach may mean that this increase in dependability is not worth the extra expense involved.We describe an experiment undertaken in order to establish for the first time whether or not the multi-version method can offer increased dependability over the traditional single-version development approach when given the same level of resources.Three programs were developed independently to control a real-time,safety-critical system,and were put together to form a decentralized multi-version system.Three functionally equivalent single-version systems were also implemented,each using the same amount of development resources as the combined resources of the multi-version system.The analytic results from this experiment show that 1)a single-version system is much more dependable than any individual version of the multi-version system,and 2) despite the poor quality of individual versions,the multi-version method still results in a safer system than the single-version solution.Although these results could not be considered conclusive in the general sense and the experiment itself needed to be improved in several areas, it is evident that regarding the single-version method as a “seem-to-be “safer design decision for critical applications is not generally justifiable.We conclude by describing plans for a follow up study based on our initial findings.Key words -Critical software and systems,fault tolerance,industrial embedded systems,multi-version software,reliability and safety

Read Full Article

Abstract:

Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest. The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet–something to make software costs drop as rapidly as computer hardware costs do. But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. In this article, I shall try to show why, by examining both the nature of the software problem and the properties of the bullets proposed. Skepticism is not pessimism, however. Although we see no startling breakthroughs–and indeed, I believe such to be inconsistent with the nature of software–many encouraging

Read Full Article

Abstract: The ?rst and most important step in solving any problem is understanding the problem well enough to create e?ective solutions. To this end, several software-related space- craft accidents were studied to determine common systemic factors. Although the details in each accident were di?erent, very similar factors related to ?aws in the safety culture, the management and organization, and technical de?ciencies were identi?ed. These factors include complacency and discounting of software risk, di?usion of responsibility and authority, limited communication channelsand poor information ?ow, inadequate system and software engineering (poor or missing speci?cations, unnecessary complexity and software functionality, software reuse without appropriate safety analysis, violation of basic safety engineering practices in the digital components), inadequate review activities, ine?ective system safety engineering, ?awed test and simulation environments, and inadequate human factors engineering. Each of these factors is discussed along with some recommendations on how to eliminate them in future projects.

Read Full Article

ABSTRACT: George Santayana’s statement, “Those who cannot remember the past are condemned to repeat it,” is only half true. The past also includes successful histories. If you haven’t been made aware of them, you’re often condemned not to repeat their successes.In a rapidly expanding field such as software engineering, this happens a lot. Extensive studies of many software projects such as the Standish Reports offer convincing evidence that many projects fail to repeat past successes.This paper tries to identify at least some of the major past software experiences that were well worth repeating, and some that were not. It also tries to identify underlying phenomena influencing the evolution of software engineering practices that have at least helped the author appreciate how our field has gotten to where it has been and where it is.A counterpart Santayana-like statement about the past and future might say, “In an era of rapid change, those who repeat the past are condemned to a bleak future.” (Think about the dinosaurs, and think carefully about software engineering maturity models that emphasize repeatability.)This paper also tries to identify some of the major sources of change that will affect software engineering practices in the next couple of decades, and identifies some strategies for assessing and adapting to these sources of change. It also makes some first steps towards distinguishing relatively timeless software engineering principles that are risky not to repeat, and conditions of change under which aging practices will become increasingly risky to repeat.

Read Full Article

ABSTRACT:

Methodological guidelines for object-oriented software construction that improve the reliability of the resulting software systems are presented. It is shown that the object-oriented techniques rely on the theory of design by contract, which underlies the design of the Eiffel analysis, design, and programming language and of the supporting libraries, from which a number of examples are drawn. The theory of contract design and the role of assertions in that theory are discussed.

Read Full Article