A Risk Management Framework for Software Engineering Practice

Geoffrey G. Roy
School of Engineering Science,
Murdoch University, Perth, Australia 6150.
Email: [email protected]

Abstract management – since both are primarily concerned with

Formal risk analysis and management in software process. It should be clear to a close observer that the foci
engineering is still an emerging part of project of the two management tasks are diametrically opposed.
management. This paper provides a brief introduction to Quality assurance is concerned with adopting a process
the concepts of risk management for software development that will minimize that chances that the project can deviate
projects, and then an overview of a new risk management from the set development pathway. Risk management is
framework. Risk management for software projects is concerned with identifying what might go wrong, and how
intended to minimize the chances of unexpected events, or these events will impact on the project. While the outcome
more specifically to keep all possible outcomes under tight goals are similar, the strategies to be followed are quite
management control. Risk management is also concerned different. We can thus expect to see distinctive theories
with making judgments about how risk events are to be and models being developed and applied in each case. The
treated, valued, compared and combined. role of the risk manager is much more that of a devils
The ProRisk Management Framework is intended to advocate compared with the quality manager.
account for a number of the key risk management Formal risk analysis is built on probability theory. Vose
principles required for managing the process of software [3], for example, provides a detailed coverage of the
development. It also provides a support environment to subject, in the context of risk analysis, including the
operationalize these management tasks. theoretical foundations. Most software development
projects will, however, involve a (large) number of risk
1. Introduction factors. Apart from trivially small cases, it is extremely
difficult to obtain detailed (quantitative) estimates of the
Risk analysis and management is, or should be, a core required probabilities. The challenge is therefore to devise
requirement of most project management tasks, especially useful methodologies that can be applied to practical-sized
in those situations where well-laid plans do not always problems. These methods should impose a level of
come to fruition. Software development is one of those theoretical integrity that makes them to be both generally
areas, but formal risk analysis is rarely an integrated part of acceptable and practically useful.
the project management task. While Boehm [1] has laid In the context of software development there is a
the foundations and Charette [2] outlined the applications, relatively short history of experience to build upon. In
there have been few widely developed formal risk other, more established, design-based disciplines
methodologies that are tailored for the software (especially in most of the more traditional engineering
development industry. areas) there are well-established bodies of knowledge,
Risk management for software development is primarily codes of practice and professional standards. Software
concerned with the process and less with the final product. Engineering, as a discipline, is still coming to terms with
While software products may not meet the specified these issues. As a result there is still a lot to learn about
functional requirements, it is rare that they fail in use. how the risks can be modeled and managed in software
Most often software products work exactly as built, much development projects.
to the frustration of users of many popular software
products. 2. Risk in Software Development
The primary concern is therefore with ensuring the
integrity of the software development process. If it goes Risk is concerned with uncertainty. This naturally
well there should be minimal unforeseen negative impacts includes uncertainty about the occurrence of known events,
on the conduct of the development project and, by but also events that are not initially identified as impacting
inference, on the resulting product. At very least the goal on the project. Risk management must therefore be an
is to have all identified risk factors under effective evolving and learning process, adapting to new and
management control. changing knowledge as the project proceeds.
There is still considerable confusion about the roles of
quality assurance/management processes and risk

Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04)

1530-0803/04 $ 20.00 © 2004 IEEE
 Risk value is generally defined as the product of the within the SERIM [4] model, and one based on a product
impact (or effect) of a risk event and the probability of the form is used within the risk extensions to the COCOMO II
event occurring, i.e. (see Madachy [5]) estimation framework.
V ( A) P( A) * C ( A) Eq 1
3. Risk Models for Software Development
where P(A) is the probability that event A will occur, C(A)
is the cost/impact or risk effect, and V(A) is the risk value A taxonomy of software project risks has been
for event A. The risk value is interpreted to be the average developed at the Software Engineering Institute (Higuera
expected loss (in some measure) of the event occurring. and Haimes [6]). This taxonomy defines a tree-structured
This is also referred to as utility loss. hierarchy of risk areas, appropriately classified to define
This form of risk valuation has some intuitive appeal, as clusters of risk factors. The top three levels are shown in
the impact of a risky event will be higher if either the Table 1. The 4th level (Level 3) corresponds to sets of
probability increases or the cost increases. As a result, a questions that probe for potential risks, and thus defines
low cost event with a high probability can have the same the risk factors for the risk model.
risk value as a high cost event with a low probability. For The contributions of each cluster of risk factors to the
commensurate risk factors this is not unreasonable. project risk can be estimated by accumulating the risk
Commensurate risk factors that those that: values up the tree. The relative contribution of each risk
x are measured on the same cost/value scale, and factor, and cluster, is described by weighting factors that
x are not extreme events, i.e. risk the factors do not have measure the risk effect of each. These weighting
substantially different (e.g. many orders of magnitude) coefficients have been estimated from a number of case
probabilities and/or costs. studies, and could provide a starting point for a project-
For a small number of possible events this product wide risk model.
model is simple enough and can provide a useful basis for
ranking and comparing risky events. As the complexity Table 1: The SEI Taxonomy (upper levels)
increases it is necessary to consider: Root Node [Level 1] [Level 2]
[Level 0]
x the independence, or otherwise, of the risk events, and Requirements
x the need to combine risk events to enable effective Software
Design
Code and Unit Test
management, assessment and control. Development Risk
Integration and Test
It may be necessary to elicit, from the project Engineering Specialties
management team, a number of probability values or even Development Process
Project Risk Development System
probability distributions. It may also be necessary to Development
Management Process
estimate conditional probabilities amongst selected events, Environment
Management Methods
given that some will not be totally independent of others. Work Environment
Resources
These tasks are complex, if not intractable, for practical- Program
Contract
sized projects. Constraints
Program Interfaces
If some assumptions about the conditional probabilities
amongst the risk factors can be made then it is possible to The SEI taxonomy is comprehensive, though still quite
suggest some workable strategies. For example, the informal. It requires a detailed analysis of the project and
combined impact of a set (cluster) of risk factors may be its operating organization, and from this process much of
estimated by: the required detailed knowledge and appreciation of the
VI ¦ wi ˜ Vi risks are elicited and exposed. It thus forms the basis for a
iI Eq 2 comprehensive awareness-raising exercise. This is, of
for events that are substantially independent, or course, an essential part of the risk management process.
Karolak [4] has proposed a more formal modeling
VI – w ˜V
i I
i i Eq 3 framework, similar to the SEI taxonomy but providing a
more quantitative, and more detailed approach. In
for events that are essentially mutually exclusive events, or particular this (SERIM) model offers the risk manager four
VI max^wi ˜ Vi ` Eq 4 interconnected risk trees based on 81 risk factors. These
i I
are referred to as risk perspectives and the top three levels
for a fuzzy model of the union of the event outcomes (i.e. are shown in Table 2.
Murphy’s Law: if anything can go wrong the event with As with the SEI model, the Level 3 nodes (not shown
the largest risk value will be the one!). The weighting here) are expressed as a set of questions that probe the risk
coefficient (wi) is taken as the risk effect of the event factors for their likelihood of occurrence. The risk factors
occurring and hence scales the impact of the event into an are shared in each perspective, with different sets of
appropriate utility measure. weighting factors applied in each case.
Various interpretations of these model primitives have
been used. For example: an additive formulation is used

Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04)

1530-0803/04 $ 20.00 © 2004 IEEE
 The SERIM model is more complex in that is it really x A process by which these risk elements can be
four models (i.e. four root nodes) with each one organized into groups of related risk factors and
corresponding to a different risk perspective. These might ultimately into risk perspectives that match
also be aligned with different stakeholders that are stakeholder views.
associated with the project (e.g. different parts of the x A model representation that enables formal risk
management team). analysis to be performed using a quantitative approach
The SERIM model requires the user (risk manager) to while keeping the data requirements to a minimum,
provide estimates of the likelihood for each risk event. x A process of analysis that assists in the identification
The SERIM modeling tool then computes the combined of key risk factors, outcomes and reactions, and the
risk values at each level of the risk tree using a simple creation of action plans to mitigate these risks, i.e. to
additive formulation like Equ 1. The risk manager is then target resources where the payoffs are expected to be
able to compare the risk value contributions from each part the greatest.
of the risk tree and within each risk perspective to identify x An ongoing re-assessment to ensure continuous
the key risk factors. monitoring and review of the risk elements as the
Table 2: The SERIM Risk Perspectives project proceeds towards completion.
Root Node [Level 1] [Level 2]
[Level 0] Establish the context
(a) Organization
(b) Estimation
(c) Monitoring
Identify risks

Communicate and consult

(d) Development

Monitor and review

Methodology
Technical (e) Tools
Risk Elements (f) Risk Culture Analyse risks

(g) Usability
(h) Correctness
Evaluate risks
(i) Reliability
(j) Personnel Assess risks
Cost (a) to (j) as above
Schedule (a) to (j) as above Treat risks
Risk Process (a) to (j) as above
Categories Product (a) to (j) as above
Pre-requirements (a) to (j) as above
Requirements (a) to (j) as above
Development Design (a) to (j) as above Figure 1: The AS/NZS 4350:1999 Risk Management
Phases Coding (a) to (j) as above Framework
Testing (a) to (j) as above
Delivery and Maintenance (a) to (j) as above Business Domain
Identification (a) to (j) as above Organization
Strategy and Planning (a) to (j) as above
Assessment (a) to (j) as above
Risk Activities
Mitigation and Avoidance (a) to (j) as above
Reporting (a) to (j) as above Project Domain

Prediction (a) to (j) as above

4. A Risk Management Framework Model Structure

Risk management must be an integrated part of the

project management framework if it is to be effective. Operational Domain
Risk Value
Much has been written in this area, for example see Measurement
Risk Assessment

Charette [7, 8] for a comprehensive coverage. In addition,

various codes of practice offer generic guidelines, for Risk Mitigation Action Plans
example AS/NZS 4360:1999 [9] provides the essential
guidelines to establish appropriate management practices,
as shown in Figure 1. Figure 2: The ProRisk Management Framework
The steps shown in Figure 1 must be wrapped in a
The proposed framework, in the context of typical software
process that appropriately identifies roles and
development projects, is shown in Figure 2.
responsibilities within the organization and the project
This framework focuses attention on primary project
team. The ProRisk Management Framework follows these
components, i.e. the business domain in which the project
steps with operational extensions. The goals of these
is created, and the operational domain when the project is
extensions are intended to provide:
actually carried out.
x A set of guidelines to assist in the analysis of a project
for risk elements.

Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04)

1530-0803/04 $ 20.00 © 2004 IEEE
 The business domain is a necessary part of the risk example, offers a rather complete (perhaps definitive) set
management process as it provides opportunities to: of risk factors for the software development project. This
x Identify the economic environment in which the taxonomy has some 194 risk factors classified in a four
project is being undertaken, and the susceptibility of level hierarchy. As defined, the SEI taxonomy does not
the organization to the performance of the project offer explicit stakeholder perspectives; these may be
team and the exposure to external risk factors. implied in the way the risk factors are clustered to form the
x Estimate the knowledge and experience of the intermediate nodes in the risk tree.
organization for the project, and the level of Collofello [13] offers a simplified version of the SEI
confidence that the project can be successfully model, reducing its size to some 36 risk factors. While this
concluded. model has been proposed for classroom use, it may still
These two factors define the components of the framework provide (with some minor changes) a suitable starting
that allow a formal model of the risks to be described. point for a first-time user for practical software
The operational domain contains the formal modeling development projects. There are also other models that are
aspects of the project: promoted by proprietary risk management
x Undertake the necessary measurement of risk values tools/methodologies that may also provide useful starting
as guided by organizational views and policies. points.
x Complete detailed assessments to identify the key risk An important aspect of risk factor identification is to
factors within the assumed modeling framework. minimise, as far as possible, the dependencies between risk
x Identify and describe the action plans aimed at factors. The assumptions made (e.g. Eqs 2, 3 and 4) may
reducing key risk values. ignore these dependencies. Ideally risk factors should be
x Implement these plans and then re-assess the effected orthogonal to each other; that is, each should attempt to
risk factors. measure a unique risk element within the project. Where
this is not possible special care must be exercise to choose
x Wrap these steps in a continuous cyclic process that
appropriate modeling tools that allow conditional
must be applied for the duration of the project.
The ProRisk Management Framework is also built on probabilities to be adequately represented. The ProRisk
Framework does not support these types of models.
an hierarchical model structure along the lines as described
in the SEI taxonomy of risk [6, 10] and Karolak [4], and 4.3. Risk Tree Model Construction
requires the following activities:
Building a complete risk tree model is an iterative, and
4.1. Stakeholder Identification learning, process requiring the involvement of all
stakeholders and the risk management team who will be
The stakeholders in a project are those individuals,
groups of people, or organizations that benefit from the responsible for the overall integrity of the model. From the
initial list of risk factors (perhaps from an existing
outcome of the project (and by inference suffer a loss if
template) the first task is to develop the risk clusters to
something goes wrong). A stakeholder may have one or
more perspectives, and these perspectives may have their collect together sets of commensurate risk factors that
align with the stakeholder perspectives. All risk factors in
own measurement units. To be effective in representing
a cluster should relate to a similar aspect of the project.
the interests of stakeholders the methodology must be able
to support both a range of stakeholders and different ways This is just common sense good management practice. A
risk cluster can be represented by the simplest of tree
of valuing their interests.
models.
4.2. Risk Factor Identification In practice, clusters can be formed from shared subsets
The initial stakeholder identification will assist in risk of risk factors like that shown in Figure 3. The separate
factor identification; but more information is needed. clusters may be measured in the same, or different, units as
Stakeholders, by themselves, are probably unable to required.
Risk Factor A
produce a complete set of risk factors that describe their
own perspective of interest. The aim is to identify all the
Risk Cluster 1 Risk Factor B
things that can go wrong, and this is the task of the risk
manager. It is possible to start from scratch, perhaps using Risk Factor C
a brainstorming session or a Delphi process [11, 12], to
elicit a complete set of risk factors for the stakeholders and Risk Factor D
Risk Cluster 2
the project. This is likely to be a time consuming process,
but may be justified in some circumstances. Risk Factor E
Given that a number of well-developed sets of risk
factors have been published it is reasonable to start with Figure 3: Risk Clusters
one of these models and modify it, as necessary, to suit the
particular project needs. The SEI taxonomy [10], for

Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04)

1530-0803/04 $ 20.00 © 2004 IEEE
 The complete risk tree will be formed by further x Schedule Perspective: the weighting factor will be a
aggregations of the clusters until each perspective has a time value (days, weeks, etc); taken as the average
single root node representing the whole project (at least as delay the event will cause to the completion of the
defined for the respective stakeholder). A complete project project.
may be represented by one or more risk trees, or
perspectives to match stakeholder requirements. For
example, one perspective may represent the total cost risk
and the other the total schedule risk.
An example risk tree model is shown in Figure 4 and
Figure 5. This model has two risk perspectives: cost and
schedule, based on a shared set of risk factors (the leaf
nodes). The descriptions of the risk factors are given in
Table 3. This model is based on a model developed and
implemented by Strategic Systems [14] for a trial of the
ProRisk Framework.

Figure 5: Sample Risk Tree Model: Schedule

Perspective
Other risk perspectives (e.g. like quality and reputation)
must also be measured if they are to be used. The process
for these more qualitative perspectives is not as
straightforward, but approximations can be made using
simple normalized scales to define relative values. Within
the ProRisk Framework these perspectives can co-exist in
the overall model.
The use of simple normalized values for risk is not
uncommon. This approach is used in the SERIM Model
Figure 4: Sample Risk Tree Model: Cost Perspective [4] and for the sets of weighting values that have been
4.4. Calibrating the Model derived from surveys undertaken from within the SEI [6].
In these cases the risk values provide a relative value
The primary risk value calculation requires values for estimate that can be used for comparing risk values
the probability that a risk event will occur, and its (identifying the top ten, for example) without requiring a
cost/impact (in appropriate measures) for each risk absolute value interpretation. So far only “average” values
perspective to which it belongs. Obtaining these values is
for the weighting coefficients have been referred to. In
not trivial and may well test the limits to which a reality the cost/impact of a risk event is likely to be
quantitative model can be developed. uncertain, perhaps following a probability distribution. In
The calibration of the model begins with the estimation
some circumstances it may possible to provide the
of the weighting factors (for example, as included in Eqs 2, probability data for a risk event. For example, if the cost
3 and 4). Each risk perspective must be treated impact of an event can be described by a worst-case, a
independently, for example:
most-likely case and a best-case value. In this way an
x Cost Perspective: the weighting factor will be a dollar attempt can be made to describe a probability distribution,
value; perhaps taken as the average cost the event will albeit from just three data values (e.g. using triangular or
add to the project, if the event occurs. BetaPERT distributions).

Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04)

1530-0803/04 $ 20.00 © 2004 IEEE
 Table 3: The Risk Factors 4.6. Computing Combined Risk Values
Within the ProRisk Management Framework a number of
Group: Complexity
AlgDif: Real-time processing algorithm in software difficult to develop -
combination models are provided:
several iterations, increased complexity, etc| x Summation: combines risk values by summing values
AlgLtd: Real-time processing algorithm limited - may need different at each risk cluster according to Eq 2.
algorithms for different configurations, etc
x Product: combines risk values by multiplying risk
Group: Work Environment values at the lowest level cluster (Eq 3), then summing
OS: Operating System to be used - development environment,
compilers, delivery system costs at higher levels (Eq 2).
Micro: Microcontroller to be used - test environment and production x Max: based on Murphy’s Law (Eq 4) that says that if
costs...
Space: Infrastructure (network, phones, etc) and lack of available space anything can go wrong the event with the largest risk
for new team members value will occur, i.e. taking the most pessimistic
Equip: Suitable test equipment
outcome. This corresponds to a fuzzy logic approach
Group: Deliverables [15] for the union of the possible events.
LowV: Sourcing and delivery of suitably low voltage embedded micro-
controller for the on-board real-time processing
Cable: High tension fibre-optic cabling delivered on time (late May)
Mech: Mechanical engineering - all offsite - delays, quality check, etc
Bat: Supply and transportation of lithium batteries
Sens: Sensors - source and supply of suitable components
EMI: EMI/EMC testing (need to send off-site, will they be ready when we
need it, etc)

Group: Environmental
Trans: Transport of Lithium batteries - held in customs, time for shipping,
etc
Imp: Impact on environment - objection to system install due to potential
for negative environmental impact
DisLi: Disposal of Lithium batteries

Group: Resources
Dom: Availability of an suitable Domain Expert throughout the entire
project
Lack: Resources and the lack thereof
Learn: Learning curve for new resources
Key: Assignment of key staff to the project in the timeframe required Figure 6: Exploring the Risk Tree
Once built and calibrated (with organizational or project
specific values) the model can be used to assist with the
A risk model developed with this level of detail can
identification of the key risk factors. Figure 6 shows the
provide the risk manager with a much richer view of the
view of the model within the risk tree; in this case, from
project risks. The risk manager will be able to observe the
the root node for the schedule perspective. Similar graphs
likely range of risk values (rather than just having an
are available to explore the children nodes, their children
average), and thus be able to judge whether the extreme
and so on. Naturally, risk factors can also be ranked
values require further attention (for mitigation purposes).
according to their contributions to the various risk
It is, however, unlikely that this level of information will
perspectives built into the model. Figure 7 shows the top
be available for most software development projects.
10 set of risk factors in order of their contribution to the
4.5. Estimating the Risk Event Probabilities project as a whole.
This is the final step in the model building phase, and
necessary before the model can be used for anything
useful. Each risk factor must be assessed for its likelihood
of occurrence and a probability allocated. Generally these
are represented by values on a 0 to 1 scale.
Adjective scale values using a Likert scale (e.g. XLow,
VLow, Low, Med, High, VHigh, XHigh) can allow users
to think in more descriptive terms rather than numeric
values (which is accepted as being difficult for some
people). In this latter case there must be an underlying
risk-value function that maps the chosen scale to numeric
values. The default mapping will probably be linear (over Figure 7: The Top 10 Risk Factors
the chosen range of values), but nonlinear mappings can be
developed where sufficient knowledge and experience is
available.

Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04)

1530-0803/04 $ 20.00 © 2004 IEEE
 4.7. Developing Action Plans subsequent reviews of risk values. We also can observe
Within the ProRisk Management Framework, the the cumulative costs incurred, i.e. the mitigation costs.
Action Plan provides support for the documentation, 4.9. Operationalizing the Framework
management and re-evaluation of risk events during the
To be useful the framework must be operationalized in
progress of the project. An action plan requires:
a management support tool. There are a number of risk
x A delegation of responsibility, i.e. who is responsible
management tools available, but few that have a particular
for carrying it out.
focus on software development projects and fewer match
x A description of what will be done to reduce the the requirements of the framework described here. To be
impact of a risk factor. effective:
x An allocation of resources to enable the work to be x The tool should be transparent and its internal
done. structure clearly exposed to the users (risk manager)
x A time scale describing when the work will be done. and peers (stakeholders).
The completion (or anticipated completion) of an action x The underlying modelling framework should be as
plan should lead to a re-evaluation of a risk factor, simple as possible and not clouded by complex
normally a change (hopefully a reduction) in the estimated computations and/or data requirements.
probability for the risk event, or a revised estimate of the
x All the parameters should be clearly exposed to the
risk impacts. With a revised probability level inserted into
user, with options to adjust to suit project and
the model, the effects of the change will be immediately
organization needs.
observable. The gains in risk reduction must be valued
x All assumptions must be made explicit.
against the costs involved, perhaps by using a risk-
reduction leverage value (Boehm [1]) that may indicate x The user/risk manager should be able to tailor and
whether the gains in risk reduction are justified by the specialize the model to suit local contexts and project-
costs incurred. specific needs.
x The tool should support “what if” analyses to allow
4.8. Monitoring the Progress the user to experiment with the model, firstly to prove
As a project proceeds the risk values will change from the integrity of the model, and secondly to provide a
time to time. These changes will come from natural means of exploring its behaviour under parameter
stochastic events as well as management interventions variations.
resulting from mitigation actions. To enable appropriate x The tool should facilitate a continuous monitoring and
management this temporal behaviour must be recorded so documentation of the risk properties, and provide
that the progress of the risk properties can be monitored. support for risk mitigation and management on a
The ProRisk Management Framework allows a risk continuing basis.
model to evolve over time, maintaining a snapshot of the
state of the model at each time epoch (that should align 5. Summary
with normal project milestones), allowing the temporal Software development projects are particularly
changes in the model to be recorded and monitored. demanding for risk analysis. They encompass a wide
Figure 8 shows a summary of part of the cost perspective range of risk factors across a number of stakeholder-
over three project milestones. determined perspectives. Most of the currently available
tools are either not scalable to large problems, hide many
of the key assumptions built into the modeling framework,
or are very demanding on the quantity of information
required to set up and calibrate the models.
The proposed framework can be readily applied to both
small scale and quite complex projects, with manageable
levels of data requirements. It is also a relatively open
system, allowing users to develop their own specialized
models, and to calibrate these to suit the needs of the
operating organization and the domain of the project.
Models can be defined and refined as experience grows.
The ProRisk Management Framework requires a
detailed analysis of the organization and project domains
Figure 8: Risk Monitoring with Mitigations Costs to develop a complete set of risk factors and to ensure they
In this figure we can observe the changing risk values are appropriately organized to reflect all the stakeholders
(following the implementation of Action plans and and the various risk perspectives that are required.
Building a complete risk model from scratch can be a

Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04)

1530-0803/04 $ 20.00 © 2004 IEEE
 substantial task, but it is also possible to use, or build on, [4] D. W. Karolak, Software Engineering Risk
one of the published models (templates). In this way Management: IEEE Computer Society, 1997.
considerable experience is obtained at minimal cost. This [5] R. J. Madachy, "Heuristic Risk Assessment Using Cost
would be the normal starting point. ProRisk is provided Factors," IEEE Software, vol. 14, pp. 51-59, 1997.
with a number of these templates. [6] R. P. Higuera and Y. Y. Haimes, "Software Risk
The framework covers the complete life cycle of the Management," Software Engineering Institute, Carnegie
project and provides support to allow the risk analysis to Mellon University CMU/SEI-96-TR-012, June 1996.
run in parallel with the conventional project management [7] R. N. Charette, Software Engineering Risk Analysis
activities. and Management, vol. 1: Cutter Consortium/ITABHI
The integrity of the ProRisk models can only be assured Corporation, 2001.
if the key underlying assumptions are maintained, these [8] R. N. Charette, Applications Strategies for Risk
include: Analysis, vol. 1: Cutter Consortium/ITABHI Corporation,
x the risk factors are largely independent or mutually 2001.
exclusive, [9] Standards Australia, AS/NZS 4360:1999, Risk
x the appropriate methods are used for computing Management, 1999.
combined risk values, [10] M. J. Carr, S. L. Konda, I. Monarch, F. C. Ulrich, and
x the risk perspectives are constructed from C. F. Walker, "Taxonomy-Based Risk Identification,"
commensurate risk values, and Software Engineering Institute, Carnegie Mellon
x extreme risk events are excluded from the model. University CMU/SEI-93-TR-6, June 1993.
Given these requirements then the ProRisk Management [11] N. Dalkey and O. Helmer, "An Experimental
Framework offers a range of new capabilities for the risk Application of the Delphi Method to the Use Of Experts,"
management of software development projects. The Management Science, vol. 9, pp. 458-467, 1963.
framework has been implemented with the ProRisk [12] H. A. Linstone and M. Turoff, The Delphi Method:
support tool [16]. A demonstration version of ProRisk can Techniques and Applications: Addison-Wesley, 1975.
be found at http://eng-sun3.murdoch.edu.au/~geoff [13] J. Collofello, "Questions List for Software Risk
Identification in the Classroom," Arizona State University
6. References Software Risk Management Home Page,
http://www.eas.asu.edu/~riskmgmt, 2000.
[1] B. W. Boehm, Tutorial: Software Risk Management: [14] Strategic Systems, "Project Risk Case Study,"
IEEE Computer Society, 1989. http://www.ss.com.au, 2002.
[2] R. N. Charette, Software Engineering Risk Analysis [15] R. E. Bellman and L. A. Zadeh, "Decision-making in
and Management. New York: McGraw-Hill, 1989. a fuzzy environment," Management Science, vol. 17, pp.
[3] D. Vose, Risk Analysis: A quantitative guide, 2 ed: 141-164, 1970.
John Wiley & Sons, 2001. [16] G. G. Roy, ProRisk User Guide: Murdoch University,
School of Engineering Science, 2003.

Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04)

1530-0803/04 $ 20.00 © 2004 IEEE