Content uploaded by Muhammad Shah Jahan
Author content
All content in this area was uploaded by Muhammad Shah Jahan on May 15, 2020
Content may be subject to copyright.
Risk Assessment on Software Development using
Fishbone Analysis
Muhammad Talha Riaz
Department of Computer & Software Engineering
College of Electrical & Mechanical Engineering (CEME),
National University of Science & Technology (NUST)
Islamabad, Pakistan
talha.riaz18@ce.ceme.edu.pk
Khawaja Sarmad Arif
Department of Computer & Software Engineering,
College of Electrical & Mechanical Engineering (CEME),
National University of Science & Technology (NUST)
Islamabad, Pakistan
samtime11@ymail.com
Muhammad Shah Jahan
Department of Computer & Software Engineering
College of Electrical & Mechanical Engineering (CEME),
National University of Science & Technology (NUST)
Islamabad, Pakistan
shah.jahan18@ce.ceme.edu.pk
Wasi Haider Butt
Department of Computer & Software Engineering,
College of Electrical & Mechanical Engineering (CEME),
National University of Science & Technology (NUST)
Islamabad, Pakistan
wasi@ce.ceme.edu.pk
Abstract— Risks are intrinsic part of any software project.
Most software projects face severe risk during the development
process, but some finds minor risks. Vulnerabilities of these
risks are threat to a quality of a software product. One of the
main causes that may lead to failure of the project is negligence
to perform risk assessment due to lack of knowledge about risk
factors. The objective of this paper is to identify, classify and
assess the risks that may cause negative impact to software
project. We first analyze the root cause which may lead to
terrible risk. Then we classified and prioritized the risks
according to their nature. For this purpose, Fishbone Analysis is
used. To find out risk factors probability and severity we have
done questionnaire-based survey and interviews from various
organizations. We collect data from different organization and
perform Quantitative and Qualitative Risk Assessment.
Through this assessment we find likelihood, severity and Risk
Exposure (r). Finally, some future direction is discussed to
control overall risk factors.
Keywords— Risk Assessment on Software Development,
Software Development Risk, Risk Assessment, Risk Identification,
Risk Management, Fishbone Analysis.
I. INTRODUCTION
Risk management process begin with the identification of
hidden, possible and dormant risk. After identification, risks
are then analyzed and a risk assessment plan is made to
recognize the action that will reduce the risk and its impact if
a problem is occur [1].
Software failure risk express as the expected loss due to
unexpected results of the output [2]. In software development,
risks are undesireable factors that may lead to the failure of the
project. Possibility of suffering from loss in software
development process is called software risk. It can be of any
type, production cost overrun, developing low quality
software, not meeting user requirement and overrun project
schedule.
Classification of Software Risks
Classification of risk is significantly important for the
identification of risk origin.
A. Schedule Risk
These risks affect and lead the projects behind the schedule
and a time related risks results in a late delivery of software
product [3]. Some schedule risks are defined below,
1) Time Estimation
Wrong time estimation is a sever risk during software
development [4]. Unfamiliar of project task and time required
to complete these project task also allowed time uncertainties.
2) Resource Allocation
If resources are not allocated properly it will also affect the
time required for software development [5]. Over allocation of
resources also burnout the experience of the team and their
productivity will significantly drop.
3) Project Complexity
Unfamiliar with complex functionalities of software
project causes wrong time estimation for software project [6].
These complexities involve lack of technical knowledge.
4) Project Scope
Schedule risk can be arise due to unexpected expansion
occurs in project scope without adjustment to time, resources
and cost [7].
B. Budget Risk
Budget forecast for the software project should be planned
to keep in mind all the uncertainties. Some of the budget risks
are defined below.
1) Budget Estimation
Budget estimation is approximation of monetary cost for
the software project. Sometimes very basic direct cost to the
project is estimated by financial analysts but indirect cost is
completely ignored [8].
2) Cost Overrun
Cost Overrun occurs due to underutilization of resources.
Resources are utilized in an undisciplined manner that lead to
utilization of more resources which may not be scheduled [9].
3) Project Scope Extension
Scope creep of unplanned increment in scope by client is
main cause of cost and scheduled overrun[10].
C. Operational Risk
These risks are associated with operational activities of
software project. This type of risks happen due to following of
improper process standards [11].
1) Improper Process Implementation
Although process models have been proposed for many
years, but due to lack of project management expertise,
process model are used poorly to software development that
may lead to failure of project.
2) Conflicting Priorities
Priorities are defined in planning phase of software project
development. Due to poor project planning and lack of
technical expertise sometimes priorities may conflict with
each other.
3) Insufficient Training
When there is no proper training of software project
development team then they do not understand how to do their
jobs and achieve project goals.
4) Lack of Communication
Lack of proper communication between project team may
causes uncertainties during project development.equation.
D. Technical Risk
Technical risks are associated with the functionality of the
software or the performance of the software [12].
1) Changing Requirement
Requirements are continuously changing that may lead to
addition of a new feature to a project and also leads towards
excessive budget and schedule overrun.
2) Lack of Technology
When no advanced technology is available for software
development or existence technology is in initial state. Having
no idea about the technology and no previous experience or
knowledge about the technology may leads towards a system
level problem.
E. Other Unavoidable Risk
These are the external risk which are unavoidable in
nature. All these uncertain risks are out of control to the
project[12].
• Government Policy
• Changing Customer Priority
• Competition
• Outsourced
II. LITERATURE REVIEW
Organization faces many types of risk and increasing
dependence on computer system introduced new types of risk.
These includes actual loss, future loss business disruption and
extra personnel work [2, 13].
Software risks in software projects can be appraised using
AHP (Analytical Hierarchy Process) method. AHP method is
the union of both qualitative and quantitative risk analysis.
This method possesses systematization and hierarchy. In this
method risk factors are sorted according to their weight, then
PDCA (Plan-Do-Check-Action) cycle method was used for
risk management of these factors. This method is effectively
applied to inform security risk evaluation and Management
[14].
According to another method uses 11 linguistic values for
ranking the grades of risk. Whereas the linguistic values are
represented by triangular fuzzy numbers [15] [16].
Identification of risks is considered the very significant
activity of risk management and widely used in both Agile and
traditional software development methods. There is direct
relation between risk management and success or
improvement of performance of software development project
[19].
Another author finds the risk factors of software
development process using expert interviews, risk factor
assumption and question distribution and then identify the key
factor who have significant impact on project performance
which may lead to risk. [20].
III. METHODOLOGY
As the primary name of our study is assessment
of software development risk factors. For this purpose, we do
literature review of many research papers. Mostly risks are
occurring at root levels which can result an immense effect on
software development process. We analyze if we remove root
cause risk factor earlier it might be possible that we avoid the
immense risk problem. For this purpose, we use Fishbone
Analysis. A basic tool to achieve quality product. Fishbone
analysis is also known as cause and effect diagram, it is a tool
for categorizing the possible causes of a problem in order to
identify the root causes. It Allows us to identify and classify
the risks according to their nature. The potentials Risk in
software development process are identified and then traced
back to find root cause.
Fig 1 Fishbone Sample Diagram
To find out risk factor we have done questionnaire-based
survey among various software development organization of
Pakistan. These software development organization mostly
worked on software projects of different organization across
the world.
After getting the results from our surveys, we perform
qualitative and quantitative risk assessment on resulted values.
The detailed result analysis is explained in next section.
IV. QUESTIONNAIRE
The questionnaire was consisting of five classification of
risks. In which each risk has further root causes. The
questionnaire was sent to different software organization of
Pakistan and to professional software developers across the
world through LinkedIn. In first step we ask them to identify
the risk they have ever find in their software development
project, then they identify the root cause by which the risk is
occur. After that we ask them to answer probability level of
risk and its severity level.
Questionnaire
Q. Have there been any changes in Schedule?
More than 56% of people response to schedule risk is Yes
and 43% of people response is No.
Q. Root cause of Scheduled Risk?
More than 76% of people identify the “wrong time
estimation” as root cause, 16.7% people identify the “resource
allocation” as root cause, 23.3% people identify the “project
complexity” as root cause and 36.7% people identify the
“project scope expand” as root cause.
After this they identify the probability level and severity of
risk due to schedule risk.
Q. Have there been any changes in Budget?
More than 64% of people response to schedule risk is Yes
and 35% of people response is No.
Q. Root cause of Budget Risk?
More than 50% of people identify the “wrong budget
estimation” as root cause, 38.2% people identify the “cost
overrun” as root cause and 41.2% people identify the “project
scope expansion” as root cause.
After this they identify the probability level and severity of
risk due to budget risk.
Q. Have there been any changes in Operational Risk?
More than 62% of people response to schedule risk is Yes
and 37.7% of people response is No.
Q. Root cause of Operational Risk?
More than 57% of people identify the “improper process
implementation” as root cause, 48.5% people identify the
“conflicting priorities” as root cause, 18.2% people identify
the “insufficient training” as root cause and 33.3% people
identify the “lack of communication” as root cause.
After this they identify the probability level and severity of
risk due to operational risk.
Q. Have there been any changes in Technical Risk?
More than 69% of people response to schedule risk is Yes
and 30.2% of people response is No.
Q. Root cause of Technical Risk?
More than 70% of people identify the “changing
requirement” as root cause, 54.1% people identify the “lack of
technology” as root cause, and 18.9% people identify the
“Trade-off” as root cause.
After this they identify the probability level and severity of
risk due to technical risk.
Q. Have there been any other Unavoidable Risk?
More than 58% of people response to schedule risk is Yes
and 41.5% of people response is No.
More than 29% of people identify the “gold plating” as
root cause, 54.8% people identify the “changing customer
priority” as root cause, 54.8% people identify the
“competition” as root cause and 35.5% people identify the
“outsourced development” as root cause.
After this they identify the probability level and severity of
risk due to other unavoidable risk.
V. RESULT ANALYSIS
A. Risk Identification
From the survey result we classify the risk according to
their nature using Fishbone Analysis and identify the root
cause of each risk factor. The design of the diagram looks like
a skeleton of a fish. It helps us to overcome the problem at
early start and to identify the root causes of big problems. In a
software development there is several types of risk including
schedule risk, budget risk, operational risk, technical risk and
other any unavoidable risk. We find the root cause of every
risk using fishbone diagram.
Fig 2 Fishbone Analysis of Risk
B. Risk Assessment
From survey result we perform qualitative and quantitative
risk assessment on risk factors and its root causes.
1) Qualitative Risk Assessment
We classify the risks than specify the probability and
severity level of risk. For qualitative risk assessment we use
qualitative estimates (level). For likelihood: (very likely,
likely, possible, and unlikely). For severity: (catastrophic,
severe, high, moderate) On the basis of above survey across
the different software development organization we obtained
the given result.
Classify of Risks
Likelihood
Severity
Scheduled
Risk
Possible
Moderate
Budget Risk
Very likely
Severe
Operational
Risk
Likely
Severe
Technical Risk
Very Likely
Catastrophic
Other
Unavoidable Risk
Likely
High
Table 1 First Level Risk Assessment
Classify of
Scheduled Risk
Likelihood
Severity
Time Estimation
Very Likely
Catastrophic
Resource
allocation
Possible
Moderate
Project
Complexity
Possible
High
Project Scope
Likely
Severe
Table 2 Second Level Risk Assessment-- Scheduled
Classify of
Budget Risk
Likelihood
Severity
Budget
Estimation
Very Likely
Catastrophic
Cost Overrun
Likely
High
Project Scope
Expansion
Very Likely
Severe
Table 3 Second Level Risk Assessment-- Budget
Classify of
Operational Risk
Likelihood
Severity
Improper Process
Implementation
Very Likely
Catastrophic
Conflicting
Priorities
Very
Likely
Severe
Insufficient
Training
Possible
Moderate
Lack of
Communication
Likely
High
Table 4 Second Level Risk Assessment-- Operational
Classify of
Technical Risk
Likelihood
Severity
Changing
Requirement
Very Likely
Catastrophic
Lack of
Technology
Very Likely
Severe
Trade-Off
Possible
Moderate
Table 5 Second Level Risk Assessment-- Technical
Classify of Other
unavoidable Risk
Likelihood
Severity
Government
Policy
Possible
Moderate
Changing
Customer Priority
Very Likely
Severe
Competition
Very Likely
Catastrophic
Outsourced
Likely
High
Table 6 Second Level Risk Assessment-- Other Unavoidable
2) Quantitative Assessment
We classify the risks than specify the probability and
severity level of risk. For quantitative risk assessment we use
numerical values. For likelihood: (0, 0.1, 0.2,0.3, ..., 0.9, 1.0).
For severity: Scale from (1 to 10) Exposure (r) = Likelihood
(c) X Severity (c).
We give values of likelihood and severity level to each risk
factor using given survey result. Here we perform quantitative
risk assessment only on major classification of risk.
Classify of
Risks
Likelihood
Severity
Exposure (r)
Scheduled
Risk
0.6
5
3
Budget Risk
0.7
7
4.9
Operational
Risk
0.7
7
4.9
Technical
Risk
0.75
8
6
Other
Unavoidable
Risk
0.6
6
3.6
Table 7 Quantitative Risk Assessment
VI. CONCLUSION
Risk assessment is critical process in software
development project that enable the quality and success of the
project. This paper particularly focusses on identification of
the root cause of the risks factor. In this paper firstly, we
defined and classified the risk factors that will give negative
impact to project. We used Fishbone Analysis for categorizing
the potential causes of a problem and then classify the risks.
Secondly, we did a survey in which we asked people to
identify the risk, that they have ever been faced in software
development projects and identified the root cause of that risk.
After this we did a qualitative and quantitative risk assessment
on the surveyed values.
This paper will help the people about the risks occur in
software development projects and help them to identify these
risks. In this paper we only do the identification and
assessment of risks. More research is required to evaluate the
process of risk control. In future we’ll define the
countermeasure in order to evaluate the risk control process.
REFERENCES
[1] J. Menezes, C. Gusmão, and H. Moura, "Risk factors in software
development projects: a systematic literature review," Software
Quality Journal, November 07 2018.
[2] S. A. Sherer, Software failure risk: measurement and
management: Springer Science & Business Media, 2012.
[3] R. Schmidt, K. Lyytinen, M. Keil, and P. Cule, "Identifying
software project risks: An international Delphi study," Journal of
management information systems, vol. 17, pp. 5-36, 2001.
[4] D. E. Harter, M. S. Krishnan, and S. A. Slaughter, "Effects of
process maturity on quality, cycle time, and effort in software
product development," Management Science, vol. 46, pp. 451-
466, 2000.
[5] W. W. Royce, "Managing the development of large software
systems: concepts and techniques," in Proceedings of the 9th
international conference on Software Engineering, 1987, pp.
328-338.
[6] J. E. Matson, B. E. Barrett, and J. M. Mellichamp, "Software
development cost estimation using function points," IEEE
Transactions on Software Engineering, vol. 20, pp. 275-287,
1994.
[7] W. Herroelen and R. Leus, "Project scheduling under uncertainty:
Survey and research potentials," European journal of operational
research, vol. 165, pp. 289-306, 2005.
[8] S. Grimstad, M. Jørgensen, and K. Moløkken-Østvold, "Software
effort estimation terminology: The tower of Babel," Information
and Software Technology, vol. 48, pp. 302-310, 2006.
[9] K. Schwalbe, Information technology project management:
Cengage Learning, 2015.
[10] L. Wallace and M. Keil, "Software project risks and their effect
on outcomes," Communications of the ACM, vol. 47, pp. 68-73,
2004.
[11] A. Watt, Project Management: Blackwell Science.
[12] B. W. Boehm, "Software risk management: principles and
practices," IEEE Software, vol. 8, pp. 32-41, 1991.
[13] S. A. Sherer, "Software Failure Risk," in Software Failure Risk,
ed: Springer, 1992, pp. 25-52.
[14] M. Meng, "The research and application of the risk evaluation and
management of information security based on AHP method and
PDCA method," in 2013 6th International Conference on
Information Management, Innovation Management and
Industrial Engineering, 2013, pp. 379-383.
[15] H.-M. Lee and L. Lin, "Fuzzy Group Evaluating the Aggregative
Risk Rate of Software Development," Berlin, Heidelberg, 2010,
pp. 438-444.
[16] K. Bansal and H. Mittal, "Analysis and Evaluation of Software
Aggregative Risk Using Soft Computing Techniques," in 2014
Fourth International Conference on Advanced Computing &
Communication Technologies, 2014, pp. 172-176.
[17] H. R. Joseph, "Poster: Software Development Risk Management:
Using Machine Learning for Generating Risk Prompts," in 2015
IEEE/ACM 37th IEEE International Conference on Software
Engineering, 2015, pp. 833-834.
[18] A. Iftikhar, S. Musa, M. Alam, M. M. Su'ud, and S. M. Ali, "A
survey of soft computing applications in global software
development," in 2018 IEEE International Conference on
Innovative Research and Development (ICIRD), 2018, pp. 1-4.
[19] N. R. Council, The owner's role in project risk management:
National Academies Press, 2005.
[20] T. Zhang and Y. Zhang, "Research on Project Development Key
Risk Factors of Small and Medium-Sized Software Enterprises,"
in International Conference on Artificial Intelligence and
Computational Intelligence, 2012, pp. 139-146.
[21] B. Boehm, "A Prioritized Top-Ten List of Software Risk Items,"
Barry Boehm, p. 70, 1988
