A Visualization Tool For Risk Assessment In Software Development

Nurazlina Md Sanusi 1, Nuridawati Mustafa 2

Faculty of Information and Communication Technology
Universiti Teknikal Malaysia Melaka
Locked Bag 1200, Hang Tuah Jaya,
75450 Ayer Keroh, Melaka
{1 nurazlina, 2nuridawati }@utem.edu.my

Abstract
Software risk management is the practice
of assessing and controlling risks that affects the
software projects, process or products. Those who
practice risk management agreed that it is must be
performed regularly throughout the lifecycle of a
software system. But one of the main challenges in
dealing with software risks is to provide a visual
risk assessment tool. This paper intends to report on
the visualization tool development based on a
traditional software development process model
Waterfall Model. This paper also shows the
proposed framework and structured approach for
this tool. The objective of this research is to
construct a visualization tool for software risk
assessment for all phases in software development
processes.

1.

Introduction

The risk assessment model, methods and

techniques are widely used to control risk in a
software development. Effective decision making
required a clearly defined risk assessment and
analysis that could show any possible outcomes.
The bad outcomes are risks and good outcomes are
possibilities to produce good software. One of the
challenges to accurately manage risk analysis is to
use automated tools to store, organize and process
data into meaningful knowledge[1].
Nowadays, software community are striving to
develop commercial software in order to stay viable.
Many software projects when deployed displayed
an excessive error and very low reliability. Yet,
while software industry is actively using software
risk management techniques to improve their risk
management practices, only few reports on
designing visualization tools are available for
managing software risks[2].
The main challenge in dealing with
software risk management is to provide the user

978-1-4244-2328-6/08/$25.00 2008 IEEE

with meaningful visual tool[2]. Although, the

current decision makings and risk assessment
methodologies include visualizations, not all phases
in software development are included. As a result,
the risk assessment from one phase to another can
be significantly complicated. A significant way to
show the relationship of risk assessment from one
phase to another is to integrate all phases in
software development.
By doing this, software developers can discover
the risks earlier and help them to determine the
execution of their risk plan. With the knowledge of
risk management, software developers will be ready
to define a standard process and methods when
developing software.
In this paper, we will discuss on the traditional
software development process model - Waterfall
Model. The waterfall model has a clear objective
where each process takes the input from the
previous step. The visualization tool that we want to
construct is based on this traditional software
development process model.

2. Related Work
The traditional software development
process model Waterfall Model was introduced
by Royce in year 1970. Later, this model is
expanded by Boehm in 1981 by adding additional
steps. This waterfall model, illustrated in Figure
1[3], allowed to steps back to the previous stages if
necessary and has become the basis of most
software acquisition standards in governments and
industry[11].

Figure 1: Waterfall Model 1

According to [4], the basic problem of waterfall
model is that this model remains a high risks
throughout the development lifecycle. This is
because a waterfall process assumes that each stage
can be fully defined without the need for feedback
from the subsequent stages.

Figure 2: Waterfall Project Profile

Figure 2 illustrates a typical waterfall
software development approach [4]. The X-axis
showed the time and Y-axis plots the functionality
and the level of project risk. As shown in the graph
above, the risk remains high until the last phase of
the software development. The risk is gradually
decreasing as the coding built, integrated and been
testing.
In order to produce good software, it is
important to take risk into account. The basic
problem is that in waterfall model the project risk
remains higher throughout the software process
development. As stated by [2], others risk
analysis techniques and tools such as decision
trees, causal analysis, gap analysis, Pareto
analysis, sensitivity analysis are very well defined
but used only limited visualization tools. Ease of
use is required to construct visualization tools
which represent the interconnected of stages in
software development projects.

978-1-4244-2328-6/08/$25.00 2008 IEEE

As research conducted by [2], the analysis of

visualization tools can be divided into two groups.
The first groups included the diagrams that used
to represent the algorithms, data and associated
events. The second group included the decision
and risk analysis visualization tools. The
visualization technique proposed to minimize the
waterfall model risk exposure in this paper is
categorized in the second group.
With the visualization standards which
consists of all phases in this traditional
development approach, this visualization tool can
be a blueprint which applicable to commonly
problems in software development projects. A
visualization tool should be thought of as a user
control task and not as report component[2].
In actual software development, a project seldom
reaches a situation where the developers cannot
control the software development, or need
considerable help from a senior manager in order
to get the project back on track. The more
complex a system is, the more the numbers of
faults are expected to be in the system.
However,
to
improve
software
quality
management, we must be able to predict early on,
in the development process, those components of
the software system that are likely to have a high
fault rate [4]. As been mentioned earlier, there is
no specific tool that can manage risk for the entire
development. The risk assessment are usually
done in particular phase depend on the purpose
and the type of software produced.
For example, the research is done at the
early phase to determine risk on functional
requirement. According to [5], the objective of
their risk assessment is to classify the system
functional requirements according to their relative
importance in terms of such factors as severity and
complexity. They define heuristic risk factor (hrf)
as a measure of risk.
Besides, one of an interesting risk
assessment research is on source-based. The paper
by [6] reports on a method for software risk
assessments that takes into account primary
facts and secondary facts. Primary facts are
those obtained through automatically analyzing
the source code of a system, and secondary facts
are those facts obtained from people working with
or on the system, and available documentation.
Referring to [7], their research provides
risk assessment based on measures obtained from
Unified Modeling Language (UML) artifacts. This
tool can be used in the design phase of the
software development process. It estimates
dynamic metrics and automatically analyzes the
quality of the architecture to produce architectural
level software risk assessment.
While, [8] is specifically for maintenance phase.
The purpose of their research is to provide a

computer tool for a person deciding about

maintenance activities which would help to evaluate
risks and costs associated with choosing different
maintenance strategies.

3. Proposed Tool
The objective of this research is to
construct a visualization tool for risk assessment for
all phases in software development. Risk
Assessment Visualization Tool (RAVT) is divided
into 5 modules that cover the basic phases according
to Waterfall Model. There are planning, requirement,
design, implementation and integration modules.
The modules of RAVT are shown in Figure 3. Next,
we present the proposed risk assessment methods
used in RAVT modules.

Planning
Requirement
RAVT

Design
Implementation
Integration

Figure 3: RAVT Structured Chart

To begin with, software was developed based on
the project development description. As the first
modules in RAVT, the initial phase of the
development is planning. This phase is planned at
general level and the most detailed level will be
covered in next phase. In RAVT, a risk baseline is
determined in planning modules so that risk
assessed is related to work and not people.
For example, for a project start-up RAVT will use a
method of formal risk assessment where users need
to answer questionnaires based on a risk taxonomy
checklist. It is most useful if the project managers
conduct the risk assessment at the early phase of the
projects. The inputs from questionnaires will be
reserved in a risk repository for future reference.
Once completed the interview-based risk
assessment, RAVT will evaluate identified risks and
categorize the risks. The evaluation will rate at scale
1 -10.
In requirement module of RAVT, the goal for this
phase is to understand the requirements document
and stabilize the requirements as soon as possible.
The primary risks are that wrong software will be
developed if the requirements are not testable. As
a result, the software projects will not complete as

978-1-4244-2328-6/08/$25.00 2008 IEEE

schedule. We proposed RAVT to comply the

requirement metrics as presented [4] the attributes
as shown in Table 1 to assess the risks.
Table 1: Requirement Attributes & Metrics
Requirement
Metrics
Attributes
Ambiguity
Weak Phrase +
Options
Completeness
TBD + TBA + TBS
Understandability
Numbering scheme
+ Readability
Traceability
% Trace up & down
Volatility
#requirements
changed/ total # of
requirements
(#Requirements =
Imperatives
+
Continuances)
Requirement attributes for completeness, is
measured by the items that is not yet to be
specified, for example, TBA To be added, TBD
To be determined, TBS To be supplied. Table
2 shows the specific requirements metrics that can
be used to reduce risk [4].
Table 2: Weak Phrases
Weak Phrases
adequate
Be capable of
as applicable
Not limited to
as appropriate
as a minimum

Capability of
Capability to

be able to

Easy

Effective
If
practical
Normal
Provide
for
timely

As for the volatility, the number of

requirements is needed [4]. The count of the
requirements is the sum of the number imperatives
and the items that follow continuances shown in
Table 3[4].
Table 3: Imperatives & Continuances
Imperatives
Continuances
Shall
Below
Must
As follows
Is required to
Following
Are applicable
Listed
Are to
In particular
Responsible for
Support
Will
should
For requirement risks, RAVT will indicate
the problems based on the requirement metrics and
attributes used. The higher the ambiguity terms, the
higher the project is at risk. As for requirement

changes, RAVT will still capable to assess the risk.

The problem is the later the changes, the more
resources need to fix them.
As for design, it can be depicted by showing the
data flow, control flow and the functional or nonfunctional structures. In RAVT, we proposed to use
the metrics introduced by [4], shown in Table 4.
Table 4: Design Attributes & Metrics
Design Attributes
Metrics
Ambiguity
Implementation
detail
Completeness
Number of items not
detailed
Structure/Architecture
Logic Paths
Coupling
Fan-in/Fan-out
By using this attributes, ambiguity can be
measured by the amount of the detail, completeness
is by number of modules. Fan-in is the count of
calls to a given module and fan-out is the count of
calls from a given module.
For implementation phase, this is where the coding
is developed to meet the users requirements. For
RAVT, we proposed to use the same model as
presented [9], which computed the risk in every
block of a software application. This model is a
combination of static and dynamic risk model
collected based on the source code.
As for integration phase, RAVT will gather
information from risk repository and evaluate based
on the weight-age determined by users.

4. Conclusion
The purpose of this research is to construct a
visualization tool for risk assessment for all phases
in
software development. Therefore, our future
work is to construct the tool according to the
proposed framework.

5. References
[1] Hall, Elaine M, Managing Risk Methods For
Software Systems Development, Addison Wesley,1998.

978-1-4244-2328-6/08/$25.00 2008 IEEE

[2] Lev Virine, Lisa Rapley, Visualization of

Probabilistics usines Models, 2003, In Proceedings
2003 Winter Simulation Conference
[3] Boehm Barry W, Software Risk Assessment ,
IEEE Computer Society Press, 1989.
[4] Gillian Adens, The Role of Risk in a Modern
Software Development Process, TASSC Technical
Paper, 2004.
[5] H. Ammar, T. Nikzadeh, and J. B. Dugan, A
Methodology for Risk Assessment of Functional
Specifications using Colored Petri nets, Software
Metrics Symposium, Proceedings., Fourth International,
1997, Page(s):108 117.
[6] Van Deursen, A.; Kuipers, Source-based software
risk assessment, Software Maintenance, ICSM
Proceedings.
International
Conference,
2003,
Page(s):385 388.
[7] Wang, T.; Hassan, A.; Guedem, A.; Abdelmoez, W.;
Goseva-Popstojanova, K.; Ammar, H, Architectural
level risk assessment tool based on UML
specifications, Software Engineering, Proceedings.
25th International Conference, 2003, Page(s):808 809.
[8[ Anders, G.J.; Sugier, J.; Risk Assessment Tool
forMaintenance Selection, Dependability of Computer
Systems, DepCos-RELCOMEX '06. International
Conference, 2006, Page(s):306 313.
[9] W.Eric Wong, Yu Qi, Kendra Cooper Source Code
Based Software Risk Assessing, ACM Symposium on
Applied Computing, 2005, Pages: 1485 1490.
[10] Noor Habibah Arshad, An Approach To The
Development of Framework For Software Risk
Management, PhD Thesis, UKM, 2003.
[11] Boehm Barry W, A Spiral Model of Software
Development and Enhancement , IEEE Computer
Society Press, 1988.