Conference PaperPDF Available

Risk Assessment on Software Development using Fishbone Analysis

Authors:

Abstract and Figures

Risks are intrinsic part of any software project. Most software projects face severe risk during the development process, but some find minor risks. Vulnerabilities of these risks are a threat to the 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 a 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 a 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
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
AbstractRisks 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
Severity
Time Estimation
Catastrophic
Resource
allocation
Moderate
Project
Complexity
High
Project Scope
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
... This can be an offset for researchers in the domain of power system stability. Contemporary research [48][49][50][51][52][53][54][55][56][57][58][59][60][61][62][63][64][65] reveals that there is a lot of work which needs to be done in the domain of RBTS. [34] To develop a riskbased security assessment method in an operating environment considering any kind of security violation. ...
Article
Full-text available
Power systems are getting more complex than ever and are consequently operating close to their limit of stability. Moreover, with the increasing demand of renewable wind generation, and the requirement to maintain a secure power system, the importance of transient stability cannot be overestimated. Considering its significance in power system security, it is important to suggest a different methodology for enhancing the transient stability, considering uncertainties. Current deterministic industry practices of transient stability assessment ignore the probabilistic nature of variables (fault type, fault location, fault clearing time, etc.). These approaches typically provide a cautious principle and can result in high-priced expansion projects or operational limits. With the increasing system uncertainties and widespread electricity market deregulation, there is a strong inevitability to incorporate risk in the traditional transient stability analysis. Accurate assessment of transient stability in a modern power network is becoming a strict requirement both in planning and in real-time operation, due to the increasingly intricate dynamics of a power system. Further, increasing sources of uncertainty in forecast state and in the reaction to faults highly implies the implementation of risk-based approach in assessing transient stability. Thus, this paper aims to provide a comprehensive review of risk-based transient stability in power networks and the accompanying research. It is believed that this review can be an inception for investigators in the field of power system planning and security.
... Risk assessment is carried out by considering two types of threats, the number of late requirements (T1) and the number of requirements that are bug/error (T2). Risk assessment is assessed based on possible threats from skills possessed by each team member [12], [13], [14], [15]. The number of late requirements seen from the number of unfinished issues does not match the schedule of the previous project, while the number of requirements that are bugs/errors is seen from the number of issues that have a category of bugs/errors in the previous project of each candidate team. ...
Article
Full-text available
The lack of skills of the development team is one factor the failure of software development project team. Interdependency based selection that is considered can increase the chances of team success does not consider skills in the calculation of total disruption of performance. Improvement total disruption of performance formula by adding skill variables can reduce the risk of project failure, in terms of the number of requirements that are delays and bugs/ errors
... Risks are an intrinsic part of any IT/software projects and most IT/ software projects face severe risks in the development processes (Masso et al., 2020;Riaz et al., 2019). Recognizing the above importance of risks in IT/software projects, authors identified top risks and classified them into different categories. ...
Article
Configurators have the potential to revolutionize the business processes of Engineering-to-order (ETO) companies. Despite their positive impacts on ETO companies' operations and strategies, there is a paucity of empirical investigations examining the development processes and practices of configurators, in particular integrated configurators. We, thus, carry out a longitudinal case study in a large ETO company to study and compare the characteristics and dynamics of the development process of an integrated sales and technical (ST) configurator with these of a sales configurator and a technical configurator. First, the findings uncover the nature of the integrated ST configurator development process in terms of development team formation, development planning activities, processes and activities that went wrong, and unplanned events and their handling. Second, performance evaluation with respect to several criteria contributes to a holistic picture of the development process of the integrated ST configurators. Based on the findings, we further shed light on managerial implications including the business processes changes associated with the application of the integrated ST configurator and the need of having a clear, comprehensive project plan before development. To conclude, our study is expected to broaden ETO companies’ understanding of the development processes of integrated configurators and to guide them to make wise decisions in developing configurators.
... El proceso de búsqueda de artículos se realizó en septiembre de 2020. La búsqueda arrojó 784 artículos y luego de aplicar el proceso de selección por dos de los autores de este artículo, se seleccionaron 12 artículos: [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [20], y [21]. ...
Article
In this complex world, where evolving systems communicate independently to achieve a common goal, the ability for an engineer to develop systems with traceability to requirements, using one integrated architecture model that enables all types of automated analysis (e.g., impact analysis, gap analysis, trade study analysis, and simulation) is becoming more and more vital. Today, the core enabler for automated analysis is the application of model‐based systems engineering practices. Model‐based systems engineering is used to capture system or systems of systems architecture as descriptive and analytical system models, which relate text‐based requirements to the architecture and provide an infrastructure to support trade study analysis. One of the core techniques to perform such analysis is requirements verification. This paper proposes an approach for an automated trade study analysis based on dynamic requirements verification in the model‐based systems engineering environment, with a goal to support trade of analysis both in the system of systems and systems engineering domains.
Article
Full-text available
Risks are an inherent part of any software project. The presence of risks in environments of software development projects requires the perception so that the associated factors do not lead projects to failure. The correct identification and monitoring of these factors can be decisive for the success of software development projects and software quality. However, in practice, risk management in software development projects is still often neglected and one of the reasons is due to the lack of knowledge of risk factors that promoted a low perception of them in the environment. This paper aims to identify and to map risk factors in environments of software development projects. We conducted a systematic literature review through a database search, as well as we performed an assessment of quality of the selected studies. All this process was conducted through a research protocol. We identified 41 studies. In these works, we extracted and classified risk factors according to the software development taxonomy developed by Software Engineering Institute (SEI). In total, 148 different risk factors were categorized. The found evidences suggest that risk factors relating to software requirements are the most recurrent and cited. In addition, we highlight that the most mentioned risk factors were the lack of technical skills by the staff. Therefore, the results converged to the need for more studies on these factors as fundamental items for reduction of failure level of a software development project.
Conference Paper
Full-text available
Software development risk is one of the major factors that affect the software cost, reliability and deadlines. Risk analysis begins with the very presentation of software proposal. Risk factors are added with software cost at each successive step. Other then this some other factors like availability of resources, software duration also affect the software risk. In this work we will provide a model using soft computing technique like Fuzzy Logic to efficiently evaluate the software aggregative risk based on some of these factors (risk items) in order to minimize risks in software development and enhance quality and reliability of software.
Book
Effective risk management is essential for the success of large projects built and operated by the Department of Energy (DOE), particularly for the one-of-a-kind projects that characterize much of its mission. To enhance DOE's risk management efforts, the department asked the NRC to prepare a summary of the most effective practices used by leading owner organizations. The study's primary objective was to provide DOE project managers with a basic understanding of both the project owner's risk management role and effective oversight of those risk management activities delegated to contractors. © 2005 by the National Academy of Sciences. All rights reserved.
Chapter
While organizations face many different types of risks, the increasing reliance on computer systems introduces new elements of risk. Some risks, such as physical destruction of hardware, are managed with the same techniques as other risks in our society. Risks associated with the development and use of software, however, pose some special problems. Software is often unique; little historical information is available to analyze its risk. The complex interrelationships found in software complicate risk measurement. Moreover, the introduction of software can change an organization’s environment, making it difficult to both analyze and manage risk. While there is always the risk that the software will not be developed effectively, there is also the risk that, once developed, the software may not meet the needs of the organization.
Chapter
This chapter deals with the economic significance of software malfunction by presenting a framework for measuring software failure risk followed by a detailed examination of components of that methodology to assess software failure risk.
Article
On the basis of analyzing small and medium-sized software enterprise's characteristics of project development, proposing the project development key risk factors for small and medium-sized software enterprise, investigating the risk factors by questionnaires and expert interviews, using factor analysis method to analyze the questionnaire, and summarizing 5 classes 12 key risk factors in small and medium-sized software enterprise project development.
Conference Paper
In order to realize the transformation of information security risk evaluation from qualitative analysis to quantitative analysis to achieve an information security risk management of dynamic cycle. In this paper, Professor Saaty's (T.L. Saaty) AHP (Analytic Hierarchy Process, AHP) method was used for information security risk evaluation to realize the transformation from qualitative analysis to quantitative analysis getting the weight of risk factors. After sorting in accordance with weight of risk factors, Dr. Deming's (W. Edwards. Deming) PDCA (Plan-Do-Check-Action, PDCA) cycle method was used for risk management of these risk factors, which was applied to the S company for an empirical research. The results show that the method can be effectively applied to information security risk evaluation and management, which also can afford experience and references for information security risk evaluation and management of domestic and foreign small and medium enterprises.