Category Archives: Articles

No Silver Bullet: Essence and Accidents of Software Engineering

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

The Role of Software in Spacecraft Accidents

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

A view of 20th and 21st century software engineering

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

Applying “Design by Contract”

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

Zend Framework Authorization component

In this article we will consider usage of one of the Zend Framework components as usual, except for a small deviation from the plan: up to this point there was an archive with the source code of the demo application (this is what was made in result by working with components) which was attached to each article filled under “Developing applications using ZF” heading (i mean russian version of the site). It will not be done that way now – we will consider components separately from each other, because, as it turned out, within the bounds of 2Developers it’s been needed to a little of people. Concerning Zend Framework CMS I should say that we started an open project of its development, so details will be covered later in the following articles.

Read Full Article