See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/341398340

Risk Assessment on Software Development using Fishbone Analysis

Conference Paper · May 2020

DOI: 10.1109/ICoDSE48700.2019.9092727

CITATIONS READS

12 1,398

4 authors:

Muhammad Talha Riaz Muhammad Shah Jahan

National University of Sciences and Technology Hitec University
8 PUBLICATIONS 51 CITATIONS 9 PUBLICATIONS 75 CITATIONS

SEE PROFILE SEE PROFILE

Khawaja Sarmad Arif Wasi Haider

National University of Sciences and Technology National University of Sciences and Technology
10 PUBLICATIONS 147 CITATIONS 109 PUBLICATIONS 1,384 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Muhammad Shah Jahan on 15 May 2020.

The user has requested enhancement of the downloaded file.

 Risk Assessment on Software Development using
Fishbone Analysis
Muhammad Talha Riaz Muhammad Shah Jahan
Department of Computer & Software Engineering Department of Computer & Software Engineering
College of Electrical & Mechanical Engineering (CEME), College of Electrical & Mechanical Engineering (CEME),
National University of Science & Technology (NUST) National University of Science & Technology (NUST)
Islamabad, Pakistan Islamabad, Pakistan
[email protected] [email protected]

Khawaja Sarmad Arif Wasi Haider Butt

Department of Computer & Software Engineering, Department of Computer & Software Engineering,
College of Electrical & Mechanical Engineering (CEME), College of Electrical & Mechanical Engineering (CEME),
National University of Science & Technology (NUST) National University of Science & Technology (NUST)
Islamabad, Pakistan Islamabad, Pakistan
[email protected] [email protected]

Abstract— Risks are intrinsic part of any software project. A. Schedule Risk
Most software projects face severe risk during the development
These risks affect and lead the projects behind the schedule
process, but some finds minor risks. Vulnerabilities of these
and a time related risks results in a late delivery of software
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
product [3]. Some schedule risks are defined below,
to perform risk assessment due to lack of knowledge about risk 1) Time Estimation
factors. The objective of this paper is to identify, classify and Wrong time estimation is a sever risk during software
assess the risks that may cause negative impact to software development [4]. Unfamiliar of project task and time required
project. We first analyze the root cause which may lead to
to complete these project task also allowed time uncertainties.
terrible risk. Then we classified and prioritized the risks
according to their nature. For this purpose, Fishbone Analysis is 2) Resource Allocation
used. To find out risk factors probability and severity we have If resources are not allocated properly it will also affect the
done questionnaire-based survey and interviews from various time required for software development [5]. Over allocation of
organizations. We collect data from different organization and resources also burnout the experience of the team and their
perform Quantitative and Qualitative Risk Assessment. productivity will significantly drop.
Through this assessment we find likelihood, severity and Risk
Exposure (r). Finally, some future direction is discussed to 3) Project Complexity
control overall risk factors. Unfamiliar with complex functionalities of software
project causes wrong time estimation for software project [6].
Keywords— Risk Assessment on Software Development, These complexities involve lack of technical knowledge.
Software Development Risk, Risk Assessment, Risk Identification,
Risk Management, Fishbone Analysis. 4) Project Scope
Schedule risk can be arise due to unexpected expansion
I. INTRODUCTION occurs in project scope without adjustment to time, resources
Risk management process begin with the identification of and cost [7].
hidden, possible and dormant risk. After identification, risks
are then analyzed and a risk assessment plan is made to B. Budget Risk
recognize the action that will reduce the risk and its impact if Budget forecast for the software project should be planned
a problem is occur [1]. to keep in mind all the uncertainties. Some of the budget risks
are defined below.
Software failure risk express as the expected loss due to
unexpected results of the output [2]. In software development, 1) Budget Estimation
risks are undesireable factors that may lead to the failure of the Budget estimation is approximation of monetary cost for
project. Possibility of suffering from loss in software the software project. Sometimes very basic direct cost to the
development process is called software risk. It can be of any project is estimated by financial analysts but indirect cost is
type, production cost overrun, developing low quality completely ignored [8].
software, not meeting user requirement and overrun project
schedule. 2) Cost Overrun
Cost Overrun occurs due to underutilization of resources.
Classification of Software Risks Resources are utilized in an undisciplined manner that lead to
utilization of more resources which may not be scheduled [9].
Classification of risk is significantly important for the
identification of risk origin. 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 applied to inform security risk evaluation and Management
These risks are associated with operational activities of [14].
software project. This type of risks happen due to following of According to another method uses 11 linguistic values for
improper process standards [11]. ranking the grades of risk. Whereas the linguistic values are
1) Improper Process Implementation represented by triangular fuzzy numbers [15] [16].
Although process models have been proposed for many Identification of risks is considered the very significant
years, but due to lack of project management expertise, activity of risk management and widely used in both Agile and
process model are used poorly to software development that traditional software development methods. There is direct
may lead to failure of project. relation between risk management and success or
improvement of performance of software development project
2) Conflicting Priorities
[19].
Priorities are defined in planning phase of software project
development. Due to poor project planning and lack of Another author finds the risk factors of software
technical expertise sometimes priorities may conflict with development process using expert interviews, risk factor
each other. assumption and question distribution and then identify the key
factor who have significant impact on project performance
3) Insufficient Training which may lead to risk. [20].
When there is no proper training of software project
development team then they do not understand how to do their III. METHODOLOGY
jobs and achieve project goals.
As the primary name of our study is assessment
4) Lack of Communication of software development risk factors. For this purpose, we do
Lack of proper communication between project team may literature review of many research papers. Mostly risks are
causes uncertainties during project development.equation. occurring at root levels which can result an immense effect on
software development process. We analyze if we remove root
D. Technical Risk cause risk factor earlier it might be possible that we avoid the
Technical risks are associated with the functionality of the immense risk problem. For this purpose, we use Fishbone
software or the performance of the software [12]. Analysis. A basic tool to achieve quality product. Fishbone
analysis is also known as cause and effect diagram, it is a tool
1) Changing Requirement for categorizing the possible causes of a problem in order to
Requirements are continuously changing that may lead to identify the root causes. It Allows us to identify and classify
addition of a new feature to a project and also leads towards the risks according to their nature. The potentials Risk in
excessive budget and schedule overrun. software development process are identified and then traced
2) Lack of Technology back to find root cause.
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 Fig 1 Fishbone Sample Diagram

• Outsourced To find out risk factor we have done questionnaire-based

II. LITERATURE REVIEW survey among various software development organization of
Pakistan. These software development organization mostly
Organization faces many types of risk and increasing worked on software projects of different organization across
dependence on computer system introduced new types of risk. the world.
These includes actual loss, future loss business disruption and
extra personnel work [2, 13]. After getting the results from our surveys, we perform
qualitative and quantitative risk assessment on resulted values.
Software risks in software projects can be appraised using The detailed result analysis is explained in next section.
AHP (Analytical Hierarchy Process) method. AHP method is
the union of both qualitative and quantitative risk analysis. IV. QUESTIONNAIRE
This method possesses systematization and hierarchy. In this The questionnaire was consisting of five classification of
method risk factors are sorted according to their weight, then risks. In which each risk has further root causes. The
PDCA (Plan-Do-Check-Action) cycle method was used for questionnaire was sent to different software organization of
risk management of these factors. This method is effectively 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 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.

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 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.

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 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 After this they identify the probability level and severity of
identify the “lack of communication” as root cause. 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.

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 29% of people identify the “gold plating” as
More than 69% of people response to schedule risk is Yes root cause, 54.8% people identify the “changing customer
and 30.2% of people response is No. priority” as root cause, 54.8% people identify the
“competition” as root cause and 35.5% people identify the
“outsourced development” as root cause.

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 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 Project Scope Likely Severe

From survey result we perform qualitative and quantitative Table 2 Second Level Risk Assessment-- Scheduled
risk assessment on risk factors and its root causes.
Classify of Likelihood Severity
1) Qualitative Risk Assessment
Budget Risk
We classify the risks than specify the probability and
severity level of risk. For qualitative risk assessment we use Budget Very Likely Catastrophic
qualitative estimates (level). For likelihood: (very likely, Estimation
likely, possible, and unlikely). For severity: (catastrophic,
severe, high, moderate) On the basis of above survey across Cost Overrun Likely High
the different software development organization we obtained Project Scope Very Likely Severe
the given result. Expansion
Table 3 Second Level Risk Assessment-- Budget
Classify of Risks Likelihood Severity
Classify of Likelihood Severity
Operational Risk
Scheduled Possible Moderate
Risk Improper Process Very Likely Catastrophic
Implementation
Budget Risk Very likely Severe
Conflicting Very Severe
Operational Likely Severe Priorities Likely
Risk
Insufficient Possible Moderate
Technical Risk Very Likely Catastrophic Training
Other Likely High Lack of Likely High
Unavoidable Risk Communication
Table 1 First Level Risk Assessment Table 4 Second Level Risk Assessment-- Operational

Classify of Likelihood Severity Classify of Likelihood Severity

Scheduled Risk Technical Risk

Time Estimation Very Likely Catastrophic Changing Very Likely Catastrophic

Requirement
Resource Possible Moderate
allocation Lack of Very Likely Severe
Technology
Project Possible High
Complexity Trade-Off Possible Moderate
Table 5 Second Level Risk Assessment-- Technical
 Classify of Other Likelihood Severity [2] S. A. Sherer, Software failure risk: measurement and
management: Springer Science & Business Media, 2012.
unavoidable Risk
[3] R. Schmidt, K. Lyytinen, M. Keil, and P. Cule, "Identifying
Government Possible Moderate software project risks: An international Delphi study," Journal of
Policy management information systems, vol. 17, pp. 5-36, 2001.
[4] D. E. Harter, M. S. Krishnan, and S. A. Slaughter, "Effects of
Changing Very Likely Severe process maturity on quality, cycle time, and effort in software
Customer Priority product development," Management Science, vol. 46, pp. 451-
466, 2000.
Competition Very Likely Catastrophic [5] W. W. Royce, "Managing the development of large software
systems: concepts and techniques," in Proceedings of the 9th
Outsourced Likely High international conference on Software Engineering, 1987, pp.
328-338.
Table 6 Second Level Risk Assessment-- Other Unavoidable [6] J. E. Matson, B. E. Barrett, and J. M. Mellichamp, "Software
development cost estimation using function points," IEEE
2) Quantitative Assessment Transactions on Software Engineering, vol. 20, pp. 275-287,
We classify the risks than specify the probability and 1994.
severity level of risk. For quantitative risk assessment we use [7] W. Herroelen and R. Leus, "Project scheduling under uncertainty:
Survey and research potentials," European journal of operational
numerical values. For likelihood: (0, 0.1, 0.2,0.3, ..., 0.9, 1.0). research, vol. 165, pp. 289-306, 2005.
For severity: Scale from (1 to 10) Exposure (r) = Likelihood [8] S. Grimstad, M. Jørgensen, and K. Moløkken-Østvold, "Software
(c) X Severity (c). effort estimation terminology: The tower of Babel," Information
and Software Technology, vol. 48, pp. 302-310, 2006.
We give values of likelihood and severity level to each risk
[9] K. Schwalbe, Information technology project management:
factor using given survey result. Here we perform quantitative Cengage Learning, 2015.
risk assessment only on major classification of risk. [10] L. Wallace and M. Keil, "Software project risks and their effect
Classify of Likelihood Severity Exposure (r) on outcomes," Communications of the ACM, vol. 47, pp. 68-73,
2004.
Risks
[11] A. Watt, Project Management: Blackwell Science.
Scheduled 0.6 5 3 [12] B. W. Boehm, "Software risk management: principles and
Risk practices," IEEE Software, vol. 8, pp. 32-41, 1991.
[13] S. A. Sherer, "Software Failure Risk," in Software Failure Risk,
Budget Risk 0.7 7 4.9 ed: Springer, 1992, pp. 25-52.
[14] M. Meng, "The research and application of the risk evaluation and
Operational 0.7 7 4.9 management of information security based on AHP method and
Risk PDCA method," in 2013 6th International Conference on
Information Management, Innovation Management and
Technical 0.75 8 6 Industrial Engineering, 2013, pp. 379-383.
Risk [15] H.-M. Lee and L. Lin, "Fuzzy Group Evaluating the Aggregative
Risk Rate of Software Development," Berlin, Heidelberg, 2010,
Other 0.6 6 3.6 pp. 438-444.
Unavoidable [16] K. Bansal and H. Mittal, "Analysis and Evaluation of Software
Risk Aggregative Risk Using Soft Computing Techniques," in 2014
Fourth International Conference on Advanced Computing &
Table 7 Quantitative Risk Assessment
Communication Technologies, 2014, pp. 172-176.
[17] H. R. Joseph, "Poster: Software Development Risk Management:
VI. CONCLUSION Using Machine Learning for Generating Risk Prompts," in 2015
Risk assessment is critical process in software IEEE/ACM 37th IEEE International Conference on Software
development project that enable the quality and success of the Engineering, 2015, pp. 833-834.
project. This paper particularly focusses on identification of [18] A. Iftikhar, S. Musa, M. Alam, M. M. Su'ud, and S. M. Ali, "A
survey of soft computing applications in global software
the root cause of the risks factor. In this paper firstly, we development," in 2018 IEEE International Conference on
defined and classified the risk factors that will give negative Innovative Research and Development (ICIRD), 2018, pp. 1-4.
impact to project. We used Fishbone Analysis for categorizing [19] N. R. Council, The owner's role in project risk management:
the potential causes of a problem and then classify the risks. National Academies Press, 2005.
Secondly, we did a survey in which we asked people to [20] T. Zhang and Y. Zhang, "Research on Project Development Key
identify the risk, that they have ever been faced in software Risk Factors of Small and Medium-Sized Software Enterprises,"
development projects and identified the root cause of that risk. in International Conference on Artificial Intelligence and
Computational Intelligence, 2012, pp. 139-146.
After this we did a qualitative and quantitative risk assessment
on the surveyed values. [21] B. Boehm, "A Prioritized Top-Ten List of Software Risk Items,"
Barry Boehm, p. 70, 1988
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.

View publication stats