The emerging discipline of software risk management is described. It is defined as an attempt to formalize the risk-oriented correlates of success into a readily applicable set of principles and practices. Its objectives are to identify, address, and eliminate risk items before they become either threats to successful software operation or major sources of software rework. The basic concepts are set forth, and the major steps and techniques involved in software risk management are explained. Suggestions for implementing risk management are provided. >

Software risk management: principles and practices

Despite the introduction and use of a wide variety of system development methods and tools, software projects are still plagued by time and cost overruns, and unmet user requirements. To avoid these problems, it is frequently recommended that the risk associated with a software project be managed. A task that is critical to the proper management of software development risk is the assessment of the risks facing the project. Based on previous research, this paper proposes a definition and a measure of software development risk. Subsequently, data collected in a survey of 120 projects is used to assess the reliability and validity of the instrument.

Toward an assessment of software development risk

In this research, a study of the effects of coordination mechanisms and risk drivers such as project uncertainty on the performance of software development projects was conducted. Two types of coordination mechanisms were considered: vertical and horizontal. The former refers to the extent to which coordination between users and IS staff is undertaken by authorized entities such as project managers or steering committees. The latter refers to the extent to which coordination is undertaken through mutual adjustments and communications between users and IS staff. A new research model was developed by synthesizing research using the structural contingency perspective from Organization Theory and the risk-based perspective in Software Engineering. The model suggests that residual performance risk, i.e., the difficulty in estimating performance-related outcomes during the later stages of the project, can clarify the relationship between project uncertainty, coordination mechanisms and performance. Eight hypotheses were derived from the model for empirical testing. Data were collected from 64 software development projects in the banking and other industries. The results provide considerable support for a revised research model. As expected, project uncertainty increases residual performance risk. Both in turn have a direct negative effect on performance. Vertical coordination significantly reduces both project uncertainty and residual performance risk. However, horizontal coordination does not have any significant effect on residual performance risk. Instead, it has a direct positive effect on project performance. Moreover, higher levels of both vertical and horizontal coordination lead to higher levels of overall performance. Their differential impacts on residual performance risk are interesting areas of future research.

The Effect of Coordination and Uncertainty on Software Project Performance: Residual Performance Risk as an Intervening Variable

Current software cost estimation models, such as the 1981 Constructive Cost Model (COCOMO) for software cost estimation and its 1987 Ada COCOMO update, have been experiencing increasing difficulties in estimating the costs of software developed to new life cycle processes and capabilities. These include non-sequential and rapid-development process models; reuse-driven approaches involving commercial off-the-shelf (COTS) packages, re-engineering, applications composition, and applications generation capabilities; object-oriented approaches supported by distributed middleware; and software process maturity initiatives. This paper summarizes research in deriving a baseline COCOMO 2.0 model tailored to these new forms of software development, including rationale for the model decisions. The major new modeling capabilities of COCOMO 2.0 are a tailorable family of software sizing models, involving Object Points, Function Points, and Source Lines of Code; nonlinear models for software reuse and re-engineering; an exponentdriver approach for modeling relative software diseconomies of scale; and several additions, deletions and updates to previous COCOMO effort-multiplier cost drivers. This model is serving as a framework for an extensive current data collection and analysis effort to further refine and calibrate the model's estimation capabilities.

Cost models for future software life cycle processes: COCOMO 2.0

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.

/pdf/a-view-of-20th-and-21st-century-software-engineering-1vqtumhb11.pdf

A view of 20th and 21st century software engineering

In mature engineering disciplines, risk management has been de rigeur for centuries. When Michelangelo set out to raise the dome of St. Peters in 1547, he was well aware of the potential collapse zones under the staging, the possibility of materials failure, and the human capacity for error. For each of these major risks he prepared a mitigation plan: a fallback, a safety factor, or an alternative. Today, we routinely practice risk management in our stewardship of the environment, in planning financial strategy, in construction engineering, and in medicine. But how do we apply it to the ultimate risky business, software development?

https://csse.usc.edu/TECHRPTS/1991/usccse91-500/usccse91-500.pdf

T. DeMarco

Papers

Software Risk Management