Journal of Computing and Information Technology - CIT 23, 2015, 2, 123–139 123

doi:10.2498 /cit.1002457

Modelling and Evaluating Software

Project Risks with Quantitative
Analysis Techniques in Planning
Software Development

Abdelrafe Elzamly1,2 and Burairah Hussin1

1 Information and Communication Technology, Universiti Teknikal Malaysia Melaka (UTeM), Malaysia
2 Department of Computer Science, Faculty of Applied Sciences, Al-Aqsa University, Gaza, Palestine

Risk is not always avoidable, but it is controllable. The as a solution to preserve the quality and in-
aim of this paper is to present new techniques which use tegrity of a project by reducing cost escalation
the stepwise regression analysis to model and evaluate the
risks in planning software development and reducing risk [1]. Due to the involvement of risk manage-
with software process improvement. Top ten software ment in monitoring the success of a software
risk factors in planning software development phase and project, analyzing potential risks, and making
thirty control factors were presented to respondents. This decisions about what to do about potential risks,
study incorporates risk management approach and plan-
ning software development to mitigate software project the risk management is considered the planned
failure. Performed techniques used stepwise regression control of risk. Integrating formal risk manage-
analysis models to compare the controls to each of the ment with project management is a new phe-
risk planning software development factors, in order to
determine and evaluate if they are effective in mitigating nomenon in software engineering and product
the occurrence of each risk planning factor and, finally, management community. In addition, risk is
to select the optimal model. Also, top ten risk planning an uncertainty that can have a negative or posi-
software development factors were mitigated by using tive effect on meeting project objectives. Risk
control factors. The study has been conducted on a
group of software project managers. Successful project management is the process of identifying, ana-
risk management will greatly improve the probability of lyzing and controlling risk throughout the life
project success. of a project to meet the project objectives.
Keywords: software project management, risk mana- However, an intelligent performance analysis
gement, planning software development, software risk
factors, risk management techniques, stepwise regression approach is adapted for decision making to se-
analysis techniques, quantitative techniques lect the optimization techniques to apply in real
world problem solving approach particularly re-
lated to industrial engineering problems [2]. In
addition, the goal of risk management is early
1. Introduction identification and recognition of risks and then
actively changing the course of actions to miti-
Despite much research and progress in the area gate and reduce the risk [3]. In the process
of software project management, software de- of understanding the factors that contribute to
velopment projects still fail to deliver accept- software project success, risk is becoming in-
able systems on time and within budget. Much creasingly important. This is a result of the size,
of the failure could be avoided by managers’ complexity and strategic importance of many of
pro-active maintenance and dealing with risk the information systems currently being develo-
factors rather than waiting for problems to oc- ped. Today, we must think of risk as a part of
cur and then trying to react. Project manage- software project lifecycle which is important for
ment and risk management have been proposed a software project survival. On the other hand,
124 Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . .

risk management aims to read risks as improve- identification, analysis, prioritization, and miti-
ment opportunities and provide inputs to growth gation [8].
plans [4].
In our paper, we identified software planning
risk factors and risk management techniques 2. Literature Review
that guide software project managers to under-
stand and mitigate risks in software analysis Previous studies had shown that risk mitiga-
development projects. However, Software De- tion in software projects are classified into three
velopment Life Cycle, according to [5], is the categories – namely, qualitative, quantitative
process of creating or altering systems, and the and mining approaches. Firstly, quantitative
models and methodologies that people use to risk is based on statistical methods that deal
develop these systems. Also, it includes the with accurate measurement about risk or lead to
following phases: planning, analysis, design, quantitative inputs that help to form a regression
implementation, and maintenance. In addition, model to understand how software project risk
we focused on the planning phase. During this factors influence project success. Furthermore,
phase, the group that is responsible for crea- qualitative risk techniques lead to subjective
ting the system must first determine what the opinions expressed or self-judgment by soft-
system needs to do for the organization (new ware manager using techniques, namely sce-
requirements gathering) and evaluate existing nario analysis, Delphi analysis, brainstorming
system/software. Risk management is a prac- session, and other subjective approaches to miti-
tice of controlling risk and the practice consists gate risks. Elzamly and Hussin [9] improved
of processes, methods and tools for managing quality of software projects of the participat-
risks in a software project before they become ing companies while estimating the quality –
problems [6]. affecting risks in IT software projects. The re-
sults show that there were 40 common risks in
This study will guide software managers to ap-
software projects of IT companies in Palestine.
ply software risk management practices with
The amount of technical and non-technical dif-
real world software development organizations
ficulties was very large. Khanfar, Elzamly, et al.
and verify the effectiveness of the modelling
techniques on a software project. We hope [10], the new technique used the chi-square ( 2 )
that the approaches will succeed in the soft- test to control the risks in a software project.
ware risk management methodology, which will However, we also used new techniques which
improve the probability of software project suc- are the regression test and effect size test pro-
cess. The objectives of this study are: to iden- posed to manage the risks in a software project
tify the software risk factors of planning soft- and reduce risk with software process improve-
ware development in the Palestinian software ment [11]. Furthermore, we used the new step-
development organizations, to rank the soft- wise regression technique to manage the risks
ware risk factors in planning software develo- in a software project. These tests were per-
pment according to their importance, severity formed using regression analysis to compare
and occurrence frequency based on data source, the controls to each of the risk factors to de-
to identify the activities performed by software termine if they are effective in mitigating the
project managers, to model and evaluate the occurrence of each risk factor implementation
identified risks in the planning of software de- phase [12]. In addition, we proposed the new
velopment. mining technique that use the fuzzy multiple re-
gression analysis techniques to manage the risks
According to Taylor, we should apply tech- in a software project. However, these mining
niques consistently throughout the software pro- tests were performed using fuzzy multiple re-
ject risk management process [7] Risk manage- gression analysis techniques to compare the risk
ment is a practice of controlling risk and the management techniques to each of the software
practice consists of processes, methods, and risk factors to determine if they are effective in
tools for managing risks in a software project mitigating the occurrence of each software risk
before they become problems [6]. Therefore, factor [13]. Further, the fuzzy regression ana-
Boehm talked about value-based risk manage- lysis modelling techniques are used to manage
ment, including principles and practices for risk the risks in a planning software development
Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . . 125

project. Top ten software risk factors in plan- methods in software risk management, software
ning phase and thirty risk management tech- development projects have a high rate of risk
niques were presented to respondents [14]. In failure. Thus, if the complexity and size of the
addition, we identified and managed the main- software projects are increased, managing soft-
tenance risks in a software development project ware development risk becomes more difficult
by using fuzzy multiple regression analysis [15]. [23]. There are several software risk manage-
Also, we proposed new mining techniques that ment approaches, models, and frameworks ac-
use the fuzzy multiple regression analysis tech- cording to a literature review.
niques with fuzzy concepts to manage the soft-
ware risks in a software project. Top ten soft-
ware risk factors in analysis phase and thirty 3. Top 10 Software Risk Factors in
risk management techniques were presented to Planning Software Development Phase
respondents. However, these mining tests were
performed using fuzzy multiple regression ana-
lysis techniques to compare the risk manage- We displayed the top ten software risk factors in
ment techniques with each of the software risk planning software development project lifecy-
factors in order to determine if they are effective cle that is most commonly used by researchers
in reducing the occurrence of each software risk when studying the risk in software projects.
factor [16]. Also, the paper aimed to present a However, the list consists of the 10 most se-
new mining technique to identify the risk man- rious risks to a project ranked from one to ten,
agement techniques that are effective in reduc- each risk’s status, and the plan for addressing
ing the occurrence of each software implemen- each risk. These factors need to be addressed
tation risk [17]. In addition, we proposed the and thereafter they need to be controlled. Con-
new quantitative and mining techniques to com- sequently, we presented ‘top-ten’ based on sur-
pare the risk management techniques to each of vey Boehm’s 10 risk items 1991 on software
the software maintenance risks in order to iden- risk management [24], the top 10 risk items ac-
tify and model if they are effective in mitigating cording to a survey of experienced project man-
the occurrence of each software maintenance agers, Boehm’s 10 risk items 2002 and Boehm’s
risk in software development life cycle [18]. 10 risk items 2006-2007, Miler [25], The Stan-
Furthermore, we presented the stepwise mul- dish Group survey [26], Addison and Vallabh
tiple regression analysis technique and Durbin [27], Addison [28], Khanfar, Elzamly et al. [10],
Watson technique to reduce software mainte- Elzamly and Hussin [11], Elzamly and Hussin
nance risks in a software project [19]. [9], Aloini et al. [29], Han and Huang [30] [31],
Aritua et al. [32], Schmidt et al. [33], Mark Keil
The authors continue the effort to enrich the et al. [34], Nakatsu and Iacovou [35], Chen and
managing software project risks considering Huang [36], Mark Keil et al. [37], Wallace et
mining and quantitative approach with large al. [38], Sumner [39], Boehem and Ross [40],
data set. Two techniques are introduced, namely Ewusi-Mensah [41], Pare et al. [42], Houston et
stepwise multiple regression analysis and fuzzy al. [43], Lawrence et al. [44], Shafer and Offi-
multiple regression to manage the software risks cer [45], hoodat and Rashidi [23], Jones et al.
[20]. This paper aims to present new techniques [46], Jones [47], Taimour [48], and other schol-
to determine if fuzzy and stepwise regression ars, researchers in software engineering, to ob-
are effective in mitigating the occurrence of tain software risk factors and risk management
software risk factor in the implementation phase techniques. These software project risks are
[21]. Finally, risk management methodology illustrated in Table 1.
that has five phases: risk identification (plan-
ning, identification, prioritization), risk analysis
and evaluation (risk analysis, risk evaluation), 4. Risk Management Techniques
risk treatment, risk controlling, risk communi-
cation and documentation relied on three cate-
gories or techniques such as risk qualitative ana- Through reading the existing literature on soft-
lysis, risk quantitative analysis and risk mining ware risk management approach and method-
analysis throughout the life of a software project ology, we listed thirty control factors that are
to meet the goals [22]. Although there are many considered important in reducing and modeling
126 Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . .

Dimension No Software risk factors Frequency

1 Low key user involvement 14
Planning software development

2 Unrealistic schedules and budgets 14

3 Unclear / misunderstood / unrealistic / change scope and objectives (goals) 8
4 Insufficient/inappropriate staffing 8
5 Lack of senior management commitment and technical leadership 8
6 Poor /inadequate planning and strategic thinking 7
7 Lack of effective software project management methodology 6
8 Change in organizational management during the software project 5
9 Ineffective communication software project system 3
10 Absence of historical data (templates) 2
Total frequency 75

Table 1. Illustrates top ten software risk factors in software projects according to researchers.

the software risk factors identified in planning quality-factor deliverables and task analysis,
software development; these controls are: C25: Avoiding having too many new func-
tions on software projects, C26: Incremental
C1: Using of requirements scrubbing, C2: Sta-
development (deferring changes to later incre-
bilizing requirements and specifications as early
ments), C27: Combining internal evaluations
as possible, C3: Assessing cost and scheduling
by external reviews, C28: Maintaining proper
the impact of each change on requirements and
documentation of each individual’s work, C29:
specifications, C4: Developing prototyping and
having the requirements reviewed by the client, Providing training in the new technology and
C5: Developing and adhering a software project organizing domain knowledge training, C30:
plan, C6: Implementing and following a com- Participating of users during the entire software
munication plan, C7: Developing contingency project lifecycle.
plans to cope with staffing problems, C8: As-
signing responsibilities to team members and
rotate jobs, C9: Having team-building sessions, 5. Empirical Strategy
C10: Reviewing and communicating progress
to date and setting objectives for the next phase,
C11: Dividing the software project into con- Data collection was achieved through the use
trollable portions, C12: Reusable source code of a structured questionnaire and historical data
and interface methods, C13: Reusable test plans to assist in estimating the quality of software
and test cases, C14: Reusable database and through determining risks that were common
data mining structures, C15: Reusable user to the majority of software projects in the ana-
documents early, C16: Implementing/utilizing lyzed software companies. Top ten software
automated version control tools, C17: Imple- risk factors and thirty control factors were pre-
menting/utilizing benchmarking and tools of sented to respondents. The method of sample
technical analysis, C18: Creating and analyz- selection referred to as ‘snowball’ and distri-
ing process by simulation and modeling, C19: bution of personal regular sampling was used.
Providing scenarios and methods and using the This procedure is appropriate when members of
reference checking, C20: Involving manage- homogeneous groups (such as software project
ment during the entire software project lifecy- managers, IT managers) are difficult to locate.
cle, C21: Including formal and periodic risk as- Seventy six software project managers partici-
sessment, C22: Utilizing change control board pated in this study. The project managers that
and exercising quality change control practices, participated in this survey came from specific,
C23: Educating users on the impact of changes mainly software project management in soft-
during the software project, C24: Ensuring ware development organizations.
Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . . 127

Respondents were presented with various ques- 5.1. Correlation Analysis

tions, which used scales 1–7. For presen-
tation purposes in this paper and for effec- Clearly, the preceding analysis states that there
tiveness, the point scale is as follows: For are correlations between determining variables
choices being labeled ‘unimportant’ equals one, besides correlation between risk factors and all
and ‘extremely important’ equals seven. Sim- determining control factors. However, the equa-
ilarly, seven frequency categories were scaled tion of Correlation Coefficient is the following:
into ‘never’ equals one and ‘always’ equals   
seven. All questions in software risk factors n [ (xi , yi )] − ( xi ) ( yi )
r=
were measured on a seven-point Likert scale  2  2   2  2
from unimportant to extremely important and n( xi ) − ( xi ) n( yi ) − ( yi )
software control factors were measured on a
(1)
seven-point Likert scale from never to always.
However, to describe “Software Development
Company in Palestine” that has in-house de-
5.2. Regression Analysis Model
velopment software and a supplier of software
for local or international market, we depended
on Palestinian Information Technology Asso- Regression modeling is one of the most widely
ciation (PITA) Members’ webpage at PITA’s used statistical modeling techniques for fitting
website [PITA 2012 www.pita.ps/], Palestinian a response (dependent) variable Y as a function
investment promotion agency [PIPA 2012 http: of predictor (independent) variables Xi (multi-
//www.pipa.gov.ps/] to select top IT man- ple regression).
agers and software project managers. In order
Y =  0 +  1 X1 + . . . +  n Xn +  (2a)
to find the relation among risks that the soft-
ware projects confront and the counter mea- Indeed, software risk factor is a dependent vari-
sures that should be taken to reduce risks, many able while control factors are independent vari-
researchers used different statistical methods. ables. A linear equation between one depen-
In this paper, we used correlation analysis and dent and many independent variables may be
regression analysis models based on stepwise expressed as:
selection method and Durbin-Watson Statis-
tic. In general, the software risk management Ŷ = b0 + b1 X1 + b2 X2 + . . . + bn Xn (2b)
methodology includes five phases named as risk
identification, risk analysis and evaluation, risk where b0 , b1 , b2 , . . . and bn are regression coef-
treatment, risk controlling, risk communication ficients; X1 , X2 , . . . and Xn are the independent
and documentation that contribute to the suc- variables, and Y is the dependent variable. The
cess of any undertaking software project. We values of b0 , b1 , b2 , . . . and bn of the multiple
started our risk management methodology by regression equation may be obtained by solving
risk identification of all possible software risks the linear equations system [49].
in planning software development. Many risks
possibilities are taken from the past literature;
however, we take into consideration only the 5.3. Stepwise Regression
top ten risk softwares for planning software (Adds and Removes Variables)
development based upon previous work. At
the same time, we also identify the possible According to [50], [51], stepwise regression
risk management techniques from the past lite- method (SRM) combines and alternates be-
rature. Also we finished with 30 risk man- tween forward selection and backward elimi-
agement techniques that come from software nation. At each step, the best remaining vari-
project risk management involving risk analysis able is added, provided it passes the 5% sig-
and evaluation, risk treatment, risk controlling, nificance level, and then all variables currently
risk communication and documentation, in or- in the regression are checked to see if any can
der to incorporate the quantitative approach and be removed, using the greater than 10% signif-
software risk management methodology to miti- icance criterion. In addition [51], the MSRA
gate planning software risks. method is a stepwise optimization process of
128 Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . .

the multiple regression analysis method. Also, system” were the highest software risk factors
a stepwise-regression method is applied which and important ones. In fact, the risk factors
systematically adds and removes model compo- sorted in descending order of respective means
nents based on statistical test to automatically were identified as important which resulted in
identify the risks for a large scale data in oper- the following ranking of importance of the listed
ation [52]. Therefore [50], SRM is particularly risks (in order of importance): Risk 9, Risk 10,
useful when we need to predict a dependent Risk 3, Risk 1, Risk 6, Risk 8, Risk 7, Risk 2,
variable from a (very) large set of independent Risk 4, Risk 5.
variables.

5.4. Coefficient of Determination Risk N Mean Std. Deviation %

R9 76 3.934 0.806 78.684
Coefficient of determination (R2 ) is the propor- R10 76 3.868 0.806 77.368
tion of variation in the observed values of the
R3 76 3.842 0.801 76.842
response variable Y that is explained by the re-
gression Ŷ [49]: R1 76 3.803 0.749 76.053
 R6 76 3.789 0.736 75.789
2 RSS (ŷ − yavg )2
R = = (3) R8 76 3.711 0.877 74.211
TSS (y − yavg )2 R7 76 3.697 0.766 73.947
According to [49], regression sum of squares R2 76 3.684 0.716 73.684
(RSS) is the variation in the observed values of R4 76 3.658 0.946 73.158
the response variable Y that is explained by the
R5 76 3.618 0.848 72.368
regression Ŷ, while total sum of squares (TSS)
is the variation in the observed values of the Total 76 3.761 0.543 75.211
response variable Y.
Table 2. Mean score for each risk factor (planning
software development).
5.5. Durbin-Watson Statistic (D)

Durbin-Watson statistic is an index that tests for 5.7. Ranking of Importance of Risk Factors
autocorrelation (the relationship between values for Project Managers’ Experience
separated from each other by a given time lag) in
the residuals (prediction errors) from a statisti- Table 3 shows the overall ranking of importance
cal regression analysis (http://www.investo- of each planning risk factor for the three cate-
pedia.com/terms/d/durbin-watson-stati- gories of project managers’ experience.
stic.asp/2013/2/26). Consequently, we will
avoid using independent variables that have er-
rors with a strong positive or negative autocor- Phase Risk Experience Experience Experience
relation, because this can lead to an incorrect 2-5 years 6-10 years > 10 years
forecast for the dependent variable. However, R1 R9 R3 R10
the value D always lies between 0 and 4 the
Planning software development

R2 R1 R10 R1
defined D-W statistic as:
 R3 R6 R9 R5
(ei − ei−1 )2 R4 R10 R6 R3
D=  2 , for N and K−1 df (4)
ei R5 R3 R1 R9
where N is the number of observations. R6 R8 R8 R7
R7 R5 R7 R6
5.6. Importance of Risk Factors in Planning R8 R2 R2 R8
Software Development Phase R9 R4 R4 R4
R10 R7 R5 R2
All respondents indicated that the software risks
of “ineffective communication software project Table 3. The overall risk ranking of each risk factor.
Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . . 129

5.8. Frequency of Occurrence of Controls C1 C2 C3 C5 C6

.336** .281* .283* .433** .524**
Table 4 shows the mean and the standard devi-
C10 C7 C8 C9 C11
ation for each control factor. The results of this
paper show that most of the controls are used .373** .323** .438** .460** .384**
most of the time and rather often. C12 C14 C15 C19 C20
.271* .250* .264* .251* .309**

Control Mean Std. Deviation % percent C21 C22 C24

.443** .370** .285*
C29 4.408 0.803 88.15789
C30 4.368 0.907 87.36842 *Correlation is significant at the 0.05 level (2-tailed).
**Correlation is significant at the 0.01 level (2-tailed) .
C20 4.184 0.668 83.68421
Table 5. Illustrates correlations between respective
C27 4.171 0.755 83.42105 controls and R1.
C21 4.171 0.7 83.42105
C19 4.158 0.612 83.15789
Model R R Square Durbin-Watson
C28 4.158 0.767 83.15789
a
1 .524 .275
C25 4.132 0.718 82.63158
b
2 .591 .349 1.729
C26 4.118 0.653 82.36842
C23 4.105 0.741 82.10526 a. Predictors: (constant), C6
b. Predictors: (constant), C6, C21
—– —– —– —–
Table 6. Illustrates multiple correlations R,
C13 3.868 0.754 77.36842 and R square.

Table 4. Mean score for each control factor.

Model Sum of Mean
Squares df Square F Sig.

1 Regression 12.469 1 12.469 28.000 .000a

5.9. Relationships Between Risks Residual 32.952 74 .445
and Control Variables
Total 45.421 75
2 Regression 15.856 2 7.928 19.576 .000b
Regression technique was performed on the data
Residual 29.565 73 .405
to determine whether there were significant re-
lationships between control factors and risk fac- Total 45.421 75
tors. These tests were performed using stepwise a. Predictors: (constant), C6 b. Predictors: (constant), C6, C21
regression analysis model to compare the con- c. Dependent variable: R1
trols to each of the risk planning software de- Table 7. Illustrates an Analysis of Variance (ANOVAc ).
velopment factors to determine and evaluate if
they are effective in mitigating the occurrence
of each risk factor. Significant relationships be- Unstandardized Standardized
tween risks and controls, being important for the Coefficients Coefficients
Model t Sig.
optimal models, are presented in the continua- b Beta
tion. This study presents the model for software 1 (constant) 2.429 5.307 .000
risk management within planning software de- C6 .476 .524 5.292 .000
velopment process.
2 (constant) 1.369 2.403 .019
C6 .381 .419 4.140 .000
R1: Risk of ‘Low Key User Involvement’
compared to controls. C21 .295 .293 2.892 .005
Dependent variable: R1
Table 5, Table 6, Table 7 and Table 8 show
that the obtained significant values (Sig.) are Table 8. Illustrates the model coefficients, respective t
values and their significance
all less than the selected significant level of (coefficientsa , coefficientsb ).
130 Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . .

 = 0.05, so there is a positive correlation Sum of df Mean

Model F Sig.
between controls 1, 2, 3, 5, 6, 7, 8, 9, 10, Squares Square
11, 12, 14, 15, 19, 20, 21, 22, 24 and Risk 1 1 Regression 5.817 1 5.817 13.204 .001a
(Table 5). However, the results show that Con-
Residual 32.604 74 .441
trols 6 and 21 have a positive impact value of
r6 = 0.524 and r21 = 0.443 respectively with Total 38.421 75
Risk 1. The multiple correlation R is 0.591, the a. Predictors: (constant), C1
value of R2 is 0.349 in the best model (stable b. Dependent variable: R2

model, Tables 6 and 7). This means that the Table 11. Illustrates an Analysis of Variance
Model 2 explained 34.9 % of the variability of (ANOVAb ).
dependent variable Risk 1. Furthermore, the
Durbin-Watson statistic (D) is 1.729 and the ta-
ble gives the critical values based on K = 2 Unstandardized Standardized
Coefficients Coefficients
(regressors), N = 76,  = 0.05 (dU = 1.680, Model t Sig.
b Beta
dL = 1.571); there is evidence of no autocorre-
lation (dU < D < 2 + dL : No autocorrelation). 1 (constant) 2.844 5.553 .000
However, we will avoid independent variables C1 .376 .389 3.634 .001
that have errors with a strong positive and nega-
a. Dependent variable: R2
tive correlation in the stepwise multiple regres-
sion model, because this can lead to an incorrect Table 12. Illustrates the model coefficients, respective t
prediction based on independent variables. values and their significance (coefficientsa).

R2: Risk of ‘Unrealistic Schedules and the variability of response Risk 2. Further-
Budgets’ compared to controls. more, Durbin-Watson statistic (D) is 2.227, and
dU = 1.652, dL = 1.598 based on K = 1,
Table 9, Table 10, Table 11, and Table 12 show N = 76,  = 0.05; there is evidence of no
that the obtained significant values are less than autocorrelation (dU < D < 2 + dL : No auto-
the selected significant value of  = 0.05, so correlation).
there is a positive correlation between Controls
1, 3, 5, 6, 7, 8, 9, 10, 11, 24, 25, and Risk 2, R3: Risk of ‘Misunderstood / Unrealistic
respectively. In addition, Control 1 has an im- Scope and Objectives (Goals)’ compared to
pact on Risk 2, and the results show that Con- controls.
trol 1 has a positive impact value of R=0.389
and the value of R2 is 0.151. This means Table 13, Table 14, Table 15, and Table 16 show
that the model (Table 10) explained 15.1% of that the obtained significant values are less than
the selected significant value of  = 0.05, so
there is a positive correlation between Controls
1, 6, 10, 19, 30, and Risk 3, respectively. In ad-
C1 C3 C5 C6 C7 C8
dition, Control 6 has an impact on Risk 3, and
.389** .297** .330** .355** .243* .229*
C9 C10 C11 C24 C25
C1 C6 C10 C19 C30
.232* .349** .251* .331** .238*
.254* .264* .247* .264* .235*
*Correlation is significant at the 0.05 level (2-tailed).
**Correlation is significant at the 0.01 level (2-tailed). *Correlation is significant at the 0.05 level (2-tailed).

Table 9. Illustrates correlations between respective Table 13. Illustrates correlations between respective
controls and R2. controls and R3.

Model R R Square Durbin-Watson Model R R Square Durbin-Watson

1 .389a .151 2.227 1 .264a .070 1.812
a. Predictors: (constant), C1 a. Predictors: (constant), C6

Table 10. Illustrates multiple correlation R, Table 14. Illustrates multiple correlation R,
and R square. and R square.
Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . . 131

Model Sum of df Mean F Sig. Model R R Square Durbin-Watson

Squares Square
a
1 .374 .140 1.745
1 Regression 4.702 1 4.702 5.538 .021a
a. Predictors: (constant), C6
Residual 62.825 74 .849
Total 67.526 75 Table 18. Illustrates multiple correlation R,
and R square.
a. Predictors: (constant), C6 b. Dependent variable: R3

Table 15. Illustrates an Analysis of Variance Sum of df Mean

(ANOVAb ). Model F Sig.
Squares Square
1 Regression 9.898 1 9.898 12.031 .001a
Unstandardized Standardized Residual 60.879 74 .823
Coefficients Coefficients Total 70.776 75
Model t Sig.
b Beta
a. Predictors: (constant), C6 b. Dependent variable: R4
1 (constant) 3.455 5.469 .000
Table 19. Illustrates an Analysis of Variance
C6 .292 .264 3.634 .021 (ANOVAb ).
a. Dependent variable: R3
Unstandardized Standardized
Table 16. Illustrates the model coefficients, respective t Coefficients Coefficients
values and their significance (coefficientsa ). Model t Sig.
b Beta
the results show that Control 6 has a positive 1 (constant) 2.544 4.091 .000
impact value of R=0.264 and the value of R2 C6 .424 .374 3.634 .001
is 0.070. This means that the model (Table 14)
a . Dependent variable: R4
explained 7.0% of the variability of response
Risk 3. Furthermore, Durbin-Watson statistic Table 20. Illustrates the model coefficients, respective t
(D) is 1.812, and (dU = 1.652, dL = 1.598) values and their significance (coefficientsa).
based on K = 1, N = 76,  = 0.05; there is
evidence of no autocorrelation because of the ity of response Risk 4. Furthermore, Durbin-
rule (dU < D < 2 + dL : No autocorrelation). Watson statistic (D) is 1.745, and (dU = 1.652,
dL = 1.598) based on K = 1, N = 76,
R4: Risk of ‘Insufficient / Inappropriate  = 0.05; there is evidence of no autocorre-
Staffing’ compared to controls. lation because of the rule (dU < D < 2 + dL :
No autocorrelation).
Table 17, Table 18, Table 19, and Table 20 show
that the obtained significant values are less than R5: Risk of ‘Lack of Senior Management
the selected significant value of  = 0.05, so Commitment and Technical Leadership’
there is a positive correlation between Controls compared to controls.
1, 3, 5, 6, 7, 8, 9, 10, 11, 24, 28, and Risk 4, re-
spectively. In addition, Control 6 has an impact Table 21, Table 22, Table 23, and Table 24 show
on Risk 4, and the results show that Control 6 that the obtained significant values are less than
has a positive impact value of R = 0.374 and the the selected significant value of  = 0.05, so
there is a positive correlation between Controls
value of R2 is 0.140. This means that the model 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 16, 18, 19,
(Table 18) explained 14.0% of the variabil- 20, 21, 22, 24, 25, 28, and Risk 5, respectively.
Controls 6 and 16 have an impact on Risk 5.
C1 C3 C5 C6 C7 C8
In addition, the results show that Controls 6, 16
have a positive impact value of 0.433, 0.329 re-
.285* .266* .313** .374** .247* .291* spectively, multiple correlation is R=0.498 and
C9 C10 C11 C24 C28 value of R2 is 0.248. This means that the model
.276* .309** .249* .225* .263* (Table 22) explained 24.8% of the variability of
response Risk 5. Furthermore, Durbin-Watson
Table 17. Illustrates correlations between respective statistic is 2.427, and (dU = 1.680, dL = 1.571)
controls and R4.
132 Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . .

C1 C2 C3 C4 C5 based on K = 2, N = 76,  = 0.05; there is ev-

.370** .272* .309** .233* .390** idence of no autocorrelation (dU < D < 2+dL :
No autocorrelation).
C6 C7 C8 C9 C10
.433** .293* .293* .308** .307**
C11 C16 C18 C19 C20
R6: Risk of ‘Poor /Inadequate Software
Project Planning and Strategic Thinking’
.277* .329** .254* .256* .231*
compared to controls.
C21 C22 C24 C25 C28
.294* .243* .232* .286* .283* Table 25, Table 26, Table 27, and Table 28 show
that the obtained significant values are less than
Table 21. Illustrates correlations between respective the selected significant value of  = 0.05, so
controls and R5. there is a positive correlation between Controls
3, 4, 5, 6, 14, and Risk 6, respectively. Con-
trols 5, 14, and 27 have an impact on Risk 6.
Model R R Square Durbin-Watson
In addition, the results show that Controls 5, 14
a
1 .433 .187
b
2 .498 .248 2.427
a. Predictors: (constant), C6
b. Predictors: (constant), C6, C16
C3 C4 C5 C6 C14
.267* .249* .268* .228* .254**
Table 22. Illustrates multiple correlations R,
and R square. Table 25. Illustrates correlations between respective
controls and R6.

Model Sum of Mean

Squares df Square F Sig.
Model R R Square Durbin-Watson
a
1 Regression 10.799 1 10.799 17.045 .000 1 .268a .072
Residual 46.885 74 .634 2 .351 b
.123
Total 57.684 75 3 .423 c
.179 2.006
2 Regression 14.311 2 7.156 12.043 .000b
a. Predictors: (constant), C5 b. Predictors: (constant), C5, C14
Residual 43.373 73 .594 c. Predictors: (constant), C5, C14, C27

Total 57.684 75
Table 26. Illustrates multiple correlations R,
a. Predictors: (constant), C6 and R square.
b. Predictors: (constant), C6, C16
c. Dependent variable: R5

Model Sum of df Mean F Sig.

Table 23. Illustrates an Analysis of Variance (ANOVAc ). Squares Square
1 Regression 3.170 1 3.170 5.740 .019a
Unstandardized Standardized Residual 40.869 74 .552
Coefficients Coefficients Total 44.039 75
Model t Sig.
b Beta 2 Regression 5.411 2 2.705 5.112 .008b
1 (constant) 2.410 4.415 .000 Residual 38.629 73 .529
C6 .443 .443 4.129 .000 Total 44.039 75
2 (constant) 1.077 1.414 .162 3 Regression 7.884 3 2.628 5.234 .003c
C6 .391 .382 3.683 .000 Residual 36.155 72 .502
C16 .319 .252 2.431 .018 Total 44.039 75
Dependent variable: R5 a. Predictors: (constant), C5 b. Predictors: (constant), C5, C14
c. Predictors: (constant), C5, C14, C27 d. Dependent variable: R6
Table 24. Illustrates the model coefficients, respective t
values and their significance Table 27. Illustrates an Analysis of Variance
(coefficientsa , coefficientsb). (ANOVAd ).
Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . . 133

Unstandardized Standardized Model R R Square Durbin-Watson

Coefficients Coefficients
Model t Sig. 1 .394 a
.155 1.933
b Beta
a. Predictors: (constant), C24
1 (constant) 3.499 6.352 .000
C5 .256 .268 2.396 .019 Table 30. Illustrates multiple correlation R,
and R square.
2 (constant) 2.394 3.145 .002
C5 .232 .243 2.201 .031
Model Sum of Mean
C14 .245 .227 2.058 .043 Squares df Square F Sig.
3 (constant) 2.715 3.594 .001 1 Regression 7.387 1 7.387 13.582 .000a
C5 .292 .306 2.750 .008
Residual 40.245 74 .544
C14 .377 .350 2.894 .005 Total 47.632 75
C27 -.247 -.277 -2.219 .030
a. Predictors: (constant), C24 b. Dependent variable: R7
Dependent variable: R6
Table 31. Illustrates an Analysis of Variance
Table 28. Illustrates the model coefficients, respective t (ANOVAb ).
values and their significance (coefficientsa ,
coefficientsb, coefficientsc).
Unstandardized Standardized
Coefficients Coefficients
have a positive impact value of 0.268 and 0.254, Model t Sig.
respectively, multiple correlation is R=0.423 b Beta
and the value of R2 is 0.179. This means that 1 (constant) 2.327 3.566 .001
the model (Table 26) explained 17.9% of the c24 .469 .394 3.685 .000
variability of response Risk 6. Also, Durbin-
Watson statistic (D) is 2.006, and (dU = 1.709, a. Dependent variable: R7

dL = 1.543) based on K = 3, N = 76, Table 32. Illustrates the model coefficients, respective t
 = 0.05; there is evidence of no autocorre- values and their significance (coefficientsa).
lation (dU < D < 2 + dL : No autocorrelation).

R7: Risk of ‘Lack of an Effective Software

R8: Risk of ‘Change in Organizational
Project Management Methodology’
Management During the Software Project’
compared to controls.
compared to Controls.
Table 29, Table 30, Table 31, and Table 32 show
that the obtained significant values are less than
the selected significant value of  = 0.05, so
there is a positive correlation between Controls R C17
24, 25 and Risk 7, respectively. In addition,
R8 .255*
Control 24 has an impact on Risk 7, and the
results show that Control 24 has a positive im- Table 33. Illustrates correlations between respective
pact value of R=0.394 and the value of R2 is controls and R8.
0.155. This means that the model (Table 30)
explained 15.5% of the variability of response Model R R Square Durbin-Watson
Risk 7. Furthermore, Durbin-Watson statistic
(D) is 1.933, and (dU = 1.652, dL = 1.598) 1 .255a .065
based on K = 1, N = 76,  = 0.05; there is 2 .374 b
.140
evidence of no autocorrelation because of the 3 .444c .197
rule (dU < D < 2 + dL : No autocorrelation). d
4 .496 .246 1.883
r C24 C25 a. Predictors: (constant), C17 b. Predictors: (constant), C17, C27
c. Predictors: (constant), C17, C27, C25
R7 .394** .294* d. Predictors: (constant), C17, C27, C25, C6

Table 29. Illustrates correlations between respective Table 34. Illustrates multiple correlations R,
controls and R7. and R square.
134 Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . .

Sum of Mean the selected significant value of  = 0.05, so

Model Squares df Square F Sig.
there is a positive correlation between Control
1 Regression 3.760 1 3.760 5.165 .026a 17 and Risk 8. In addition, Controls 6, 17, 25,
Residual 53.872 74 .728 and 27 have an impact on Risk 8, multiple cor-
Total 57.632 75 relation value R=0.496, and the value of R2 is
0.246. This means that the model (Table 34)
2 Regression 8.075 2 4.037 5.947 .004b
explained 24.6% of the variability of response
Residual 49.557 73 .679 Risk 8. Furthermore, Durbin-Watson statistic
Total 57.632 75 (D) is 1.883, and (dU = 1.543, dL = 1.709)
3 Regression 11.368 3 3.789 5.898 .001c based on K = 4, N = 76,  = 0.05; there is ev-
Residual 46.263 72 .643 idence of no autocorrelation (dU < D < 2+dL :
Total 57.632 75 No autocorrelation).
4 Regression 14.198 4 3.550 5.803 .000d
Residual 43.433 71 .612
R9: Risk of ‘Ineffective Communication Soft-
Total 57.632 75
ware Project System’ compared to Controls.
a. Predictors: (constant), C17
b. Predictors: (constant), C17, C27
c. Predictors: (constant), C17, C27, C25 Table 37, Table 38, Table 39, and Table 40 show
d. Predictors: (constant), C17, C27, C25, C6
e. Dependent variable: R8 that the obtained significant values are less than
the selected significant value of  = 0.05, so
Table 35. Illustrates an Analysis of Variance (ANOVAe ). there is a positive correlation between Controls
24, 27, 25, 5, and Risk 9. Controls 24, 27,
25, and 5 have an impact on the Risk 9. In
Unstandardized Standardized addition, multiple correlation value R=0.500,
Coefficients Coefficients
Model t Sig. and the value of R2 is 0.250. This means
b Beta
that the model (Table 38) explained 25.0% of
1 (constant) 3.269 5.093 .000 the variability of response Risk 9. Further-
C17 .282 .255 2.273 .026 more, Durbin-Watson statistic (D) is 1.687, and
2 (constant) 4.268 5.802 .000 (dU = 1.739, dL = 1.515) based on K = 4,
C17 .389 .352 3.060 .003 N = 76,  = 0.05; there is evidence of incon-
clusive (dL < D < dU : Inconclusive).
C27 -.295 -.290 -2.521 .014
3 (constant) 3.457 4.320 .000
C17 .344 .311 2.741 .008
R C24 C26
C27 -.397 -.391 -3.243 .002
C25 .306 .268 2.264 .027 R9 .272* .233*

4 (constant) 2.723 3.196 .002 Table 37. Illustrates correlations between respective
C17 .320 .290 2.608 .011 controls and R9.
C27 -.441 -.434 -3.637 .001
C25 .287 .251 2.166 .034
Model R R Square Durbin-Watson
C6 .236 .230 2.151 .035
1 .272a .074
Dependent variable: R8 b
2 .387 .150
Table 36. Illustrates the model coefficients, respective t 3 .448c .201
values and their significance (coefficientsa , 4 .500 d
.250 1.687
coefficientsb , coefficientsc, coefficientsd).
a. Predictors: (constant), C24 b. Predictors: (constant), C24, C27
c. Predictors: (constant), C24, C27, C25
d. Predictors: (constant), C24, C27, C25, C5

Table 33, Table 34, Table 35, and Table 36 show Table 38. Illustrates multiple correlations R,
that the obtained significant values are less than and R square.
Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . . 135

Model Sum of Mean C1 C3 C4 C5 C6

Squares df Square F Sig.
.312** .354** .379** .349** .331**
1 Regression 3.819 1 3.819 5.892 .018a
C7 C8 C10 C29
Residual 47.970 74 .648
.370** .253* .234* .256*
Total 51.789 75
2 Regression 7.772 2 3.886 6.445 .003b Table 41. Illustrates correlations between respective
Residual 44.017 73 .603 controls and R10.
Total 51.789 75
3 Regression 10.402 3 3.467 6.032 .001c Model R R Square Durbin-Watson
Residual 41.378 72 .575
1 .379a .143 1.882
Total 51.789 75
a. Predictors: (constant), C4
4 Regression 12.951 4 3.238 5.919 .000d
Residual 38.838 71 .547 Table 42. Illustrates multiple correlations R,
and R square.
Total 51.789 75
a. Predictors: (constant), C24 b. Predictors: (constant), C24, C27
c. Predictors: (constant), C24, C27, C25
d. Predictors: (constant), C24, C27, C25, C5 e. Dependent variable: R9 Model Sum of Mean
Squares df Square F Sig.
Table 39. Illustrates an Analysis of Variance (ANOVAe ).
1 Regression 6.983 1 6.983 12.391 .001a
Residual 41.702 74 .564
Unstandardized Standardized Total 48.684 75
Coefficients Coefficients
Model t Sig. a. Predictors: (constant), C4 b. Dependent variable: R10
b Beta
1 (constant) 3.233 4.539 .000 Table 43. Illustrates an Analysis of Variance
(ANOVAb ).
C24 .338 .272 2.427 .018
2 (constant) 4.090 5.353 .000
C24 .461 .371 3.233 .002 Unstandardized Standardized
Coefficients Coefficients
C27 -.283 -.293 -2.560 .013 Model t Sig.
b Beta
3 (constant) 3.560 4.530 .000
C24 .360 .289 2.448 .017 1 (constant) 3.023 5.690 .000
C27 -.365 -.378 -3.186 .002 C4 .370 .379 3.520 .001
C25 .285 .263 2.139 .036 a. Dependent variable: R10

4 (constant) 2.762 3.245 .002 Table 44. Illustrates the model coefficients, respective t
C24 .275 .221 1.853 .068 values and their significance (coefficientsa).
C27 -.428 -.444 -3.708 .000
C25 .341 .315 2.571 .012
there is a positive correlation between Controls
C5 .249 .241 2.159 .034 1, 3, 4, 5, 6, 7, 8, 10, 29 and Risk 10, respec-
Dependent variable: R9 tively. In addition, Control 4 has an impact on
Risk 10, and the results show that Control 4
Table 40. Illustrates the model coefficients, respective t has a positive impact value R=0.379 and the
values and their significance (coefficientsa ,
coefficientsb , coefficientsc, coefficientsd). value of R2 is 0.143. This means that the model
(Table 42) explained 14.3% of the variability
of response Risk 10. Furthermore, Durbin-
R10: Risk of ‘Absence of Historical Data Watson statistic (D) is 1.882, and (dU = 1.652,
(Templates)’ compared to Controls. dL = 1.598) based on K = 1, N = 76,
Table 41, Table 42, Table 43, and Table 44 show  = 0.05; there is evidence of no autocorre-
that the obtained significant values are less than lation because of the rule (dU < D < 2 + dL :
the selected significant value of  = 0.05, so No autocorrelation).
136 Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . .

5.10. Software Risk Factors Identification project manager’s perspective, whereas all Con-
Checklists and Control Factors trols are used most of the time, and rather often.
(Risk Management Techniques) This study incorporates risk management ap-
proach and planning software development to
Table 45 shows risk factors identification check- mitigate software project failure by using step-
list with risk management techniques based on wise multiple regression technique. These tests
a questionnaire of experienced software project were performed using regression analysis (step-
managers. We can use the checklist in software wise regression), in order to compare the Con-
projects to identify and mitigate risk factors on trols to each of the risk factors, to determine
lifecycle software projects by risk management and evaluate if they are effective in mitigating
techniques. the occurrence of each risk factor, and, finally,
to select the optimal model. Only significant re-
lationships between risks and controls were re-
ported. In addition, we determined the positive
6. Conclusions
correlation between risk factors and risk man-
agement techniques, then measured impact risk
The concern of our paper are the modelling risks in the software project lifecycle. We used cor-
of planning software development. The results relation analysis, regression analysis, models
show that all risk planning software projects based on the stepwise selection method (add and
were very important, and important in software remove), and Durbin-Watson statistic. How-

No Software Risk Factors Risk Management Techniques

C6: Implementing and following a communication
1 Low key user involvement. plan, C21: Including formal and periodic Risk assess-
ment.
2 Unrealistic schedules and budgets. C1: Using of requirements scrubbing.
Misunderstood/unrealistic scope and objec- C6: Implementing and following a communication
3 tives (goals). plan.
C6: Implementing and following a communication
4 Insufficient/inappropriate staffing. plan.
Lack of senior management commitment and C6: Implementing and following a communication
5 technical leadership. plan, C16: Implementing/utilizing automated version
Control tools.
C5: Developing and adhering a software project plan,
6 Poor/inadequate software project planning and C14: Reusable database and data mining structures,
strategic thinking. C27: Combining internal evaluations by external re-
views.
Lack of an effective software project manage- C24: Ensuring that quality-factor deliverables and task
7 ment methodology. analysis.
C17: Implement/utilize benchmarking and tools of
technical analysis, C27: Combining internal evalua-
Change in organizational management during tions by external reviews, C25: Avoiding having too
8 the software project. many new functions on software projects,
C6: Implementing and following a communication
plan.
C24: Ensuring quality-factor deliverables and task
analysis, C27: Combining internal evaluations by ex-
Ineffective communication software project ternal reviews, C25: Avoiding having too many new
9 system. functions on software projects, C5: Developing and
adhering a software project plan.
C4: Develop prototyping and have the requirements
10 Absence of historical data (templates). reviewed by the client.

Table 45. Software risk planning development factors were mitigated by risk management techniques.
Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . . 137

ever, we reported the control factors in risk [2] P. VASANT, Hybrid Mesh Adaptive Direct Search
management approach were mitigated on risk Genetic Algorithms and Line Search Approaches
for Fuzzy Optimization Problems in Production
planning software development factors in Ta- Planning. In Handbook of Optimization Intelli-
ble 45. Through the results, we found out that gent Systems Reference Library, 38, I. ZELINKA, V.
some controls don’t have impact, so the impor- SNÁŠEL, A. ABRAHAM, EDS., Berlin, Heidelberg:
tant controls should be considered by the soft- Springer Berlin Heidelberg, 2013, pp. 779–799.
ware development companies in Palestinian. In [3] J. MILER AND J. GÓRSKI, Supporting Team Risk
addition, we cannot obtain historical data from Management in Software Procurement and Devel-
database before using certain techniques. As opment Projects. In 4th National Conference on
Software Engineering, 2002, pp. 1–15.
future work, we intend to apply these study re-
sults on a real-world software project to ver- [4] C. R. PANDIAN, Applied software Risk management:
ify the effectiveness of the new techniques and A guide for software project managers. Auerbach
Publications is an imprint of the Taylor & Francis
approach on a software project. We can use Group, 2007, pp. 246.
other techniques to manage and mitigate soft-
ware project risks, such as neural network, ge- [5] J. HOFFER, J. GEORGE AND J. VALACICH, Modern
netic algorithm, Bayesian statistics, and other Systems Analysis and Design, 6th ed. Prentice Hall,
2011, pp. 575.
artificial intelligence techniques.
[6] J. SODHI AND P. SODHI, IT Project Management
Handbook. Management Concepts, 2001, pp. 264.
7. Appendix [7] J. TAYLOR, Managing Information Technology
Projects: Applying Project Management Strategies
to Software, Hardware and Integration Initiatives.
Appendix illustrates models with AMACOM 2004,
c pp. 274.
an intercept (from Savin and White)
[8] B. BOEHM, Value-based software engineering. ACM
Durbin-Watson Statistic: 1 Percent Significance Points of dL and dU SIGSOFT Softw. Eng. Notes, 28(2), pp. 1–12, Mar.
and 5 Percent Significance Points of dL and dU . 2003.
[9] A. ELZAMLY AND B. HUSSIN, Estimating Quality-
K 1 2 3 Affecting Risks in Software Projects. Int. Manag.
Rev. Am. Sch. Press, 7(2), pp. 66–83, 2011.
N Significance dL dU dL dU dL dU
75 1% 1.448 1.501 1.422 1.529 1.395 1.557 [10] K. KHANFAR, A. ELZAMLY, W. AL-AHMAD, E. EL-
QAWASMEH, K. ALSAMARA, S. ABULEIL, Managing
75 5% 1.598 1.652 1.571 1.680 1.543 1.709 Software Project Risks with the Chi-Square Tech-
nique. Int. Manag. Rev., 4(2), pp. 18–29, 2008.
K 4 5
N Significance dL dU dL dU [11] A. ELZAMLY, B. HUSSIN, Managing Software
Project Risks with Proposed Regression Model
75 1% 1.368 1.586 1.340 1.617 Techniques and Effect Size Technique. Int. Rev.
75 5% 1.515 1.739 1.487 1.770 Comput. Softw., 6(2), pp. 250–263, 2011.
[12] A. ELZAMLY, B. HUSSIN, Managing Software
Project Risks (Implementation Phase) with Pro-
posed Stepwise Regression Analysis Techniques.
Int. J. Inf. Technol., 1(4), pp. 300–312, 2013.
Acknowledgments
[13] A. ELZAMLY AND B. HUSSIN, Managing Software
Project Risks (Design Phase) with Proposed Fuzzy
This study is supported by Faculty of Informa- Regression Analysis Techniques with Fuzzy Con-
cepts. Int. Rev. Comput. Softw., 8(11), pp. 2601–
tion and Communication Technology, Techni- 2613, 2013.
cal University of Malaysia Malacca (UTeM),
Malaysia and Al-Aqsa University, Palestine. [14] A. ELZAMLY, B. HUSSIN, Managing Software
Project Risks (Planning Phase) with Proposed
Fuzzy Regression Analysis Techniques with Fuzzy
Concepts. Int. J. Inf. Comput. Sci., 3(2), pp. 31–40,
References 2014.
[15] A. ELZAMLY, B. HUSSIN, Identifying and Managing
Software Project Risks with Proposed Fuzzy Re-
[1] K. SCHWALBE, Information Technology Project gression Analysis Techniques: Maintenance Phase.
Management. Sixth. Course Technology, Cengage In 2014 Conference on Management and Engineer-
Learning, 2010, pp. 490. ing (CME2014), 2014(Cme), pp. 1868–1881.
138 Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . .

[16] A. ELZAMLY, B. HUSSIN, Managing Software [31] S. HUANG, W. HAN, Exploring the relationship be-
Project Risks (Analysis Phase) with Proposed Fuzzy tween software project duration and Risk exposure:
Regression Analysis Modelling Techniques with A cluster analysis. Inf. Manag., 45(3), pp. 175–182,
Fuzzy Concepts. J. Comput. Inf. Technol., 22(2), Apr. 2008.
pp. 131–144, 2014.
[32] B. ARITUA, N. J. SMITH, D. BOWER, What Risks are
[17] A. ELZAMLY, B. HUSSIN, Modelling and mitigating common to or amplified in programmes: Evidence
Software Implementation Project Risks with Pro- from UK public sector infrastructure schemes. Int.
posed Mining Technique. Inf. Eng., 3, pp. 39–48, J. Proj. Manag., 29(3), pp. 303–312, Apr. 2011.
2014.
[33] R. SCHMIDT, K. LYYTINEN, M. KEIL, P. CULE, Iden-
[18] A. ELZAMLY, Evaluation of Quantitative and Min- tifying Software Project Risks: An International
ing Techniques for Reducing Software Maintenance Delphi Study. J. Manag. Inf. Syst., 17(4), pp. 5–36,
Risks. Appl. Math. Sci., 8(111), pp. 5533–5542, 2001.
2014.
[34] M. KEIL, P. CULE, K. LYYTINEN, R. SCHMIDT, A
[19] A. ELZAMLY, B. HUSSIN, Mitigating Software Main- Framework for Identifying Software Project Risks.
tenance Project Risks with Stepwise Regression Commun. ACM, 41(11), pp. 76–83, 1998.
Analysis Techniques. J. Mod. Math. Front., 3(2),
pp. 34–44, 2014. [35] R. NAKATSU, C. IACOVOU, A comparative study
of important Risk factors involved in offshore
[20] A. ELZAMLY, B. HUSSIN, A Comparison of Stepwise and domestic outsourcing of software development
And Fuzzy Multiple Regression Analysis Tech- projects: A two-panel Delphi study. Inf. Manag.,
niques for Managing Software Project Risks: Anal- 46(1), pp. 57–68, Jan. 2009.
ysis Phase. J. Comput. Sci., 10(10), pp. 1725–1742,
2014. [36] J. CHEN, S. HUANG, An empirical analysis of the
impact of software development problem factors on
[21] A. ELZAMLY, B. HUSSIN, A Comparison of Fuzzy software maintainability. J. Syst. Softw., 82(6), pp.
and Stepwise Multiple Regression Analysis Tech- 981–992, Jun. 2009.
niques for Managing Software Project Risks: Im- [37] M. KEIL, A. TIWANA, A. BUSH, Reconciling user
plementation Phase. Int. Manag. Rev., 10(1), pp. and project manager perceptions of IT project Risk:
43–54, 2014. A Delphi study. Inf. Syst. J., 12(2), pp. 103–119,
[22] A. ELZAMLY, B. HUSSIN, An Enhancement of 2002.
Framework Software Risk Management Methodol- [38] L. WALLACE, M. KEIL, A. RAI, How Software
ogy for Successful Software Development. J. Theor. Project Risk Affects Project Performance: An
Appl. Inf. Technol., 62(2), pp. 410–423, 2014. Investigation of the Dimensions of Risk and an
Exploratory Model. Decis. Sci., 35(2), 2004.
[23] H. HOODAT, H. RASHIDI, Classification and Analy-
sis of Risks in Software Engineering. Eng. Technol., [39] M. SUMNER, Risk factors in enterprise-wide/ERP
56(32), pp. 446–452, 2009. projects. J. Inf. Technol., 15(4), pp. 317–327, Dec.
2000.
[24] B. BOEHM, Software Risk Management: Principles
and Practices. IEEE Softw., (January), pp. 1–10, [40] B. BOEHM, R. ROSS, Theory-W Software Project
1991. Management: Principles and Examples. IEEE
Trans. Softw. Eng., 15(7), pp. 902–916, 1989.
[25] J. MILER, A Method of Software Project Risk
Identification and Analysis. Gdansk University of [41] KWEKU EWUSI-MENSAH, Software Development
Technology, 2005. Failures: Anatomy of Abandoned Projects. The
MIT Press, p. 276, 2003.
[26] CHAOS, The Standish Group Report. 1995.
[42] G. PARÉ, C. SICOTTE, M. JAANA, D. GIROUARD, Pri-
[27] T. ADDISON, S. VALLABH, Controlling Software oritizing Clinical Information System Project Risk
Project Risks – an Empirical Study of Methods used Factors: A Delphi Study. In Proceedings of the
by Experienced Project Managers. In Proceedings 41st Hawaii International Conference on System
of SAICSIT, 2002, pp. 128–140. Sciences, pp. 1–10, 2008.
[28] T. ADDISON, E-commerce project development [43] D. HOUSTON, G. MACKULAK, J. COLLOFELLO,
Risks: Evidence from a Delphi survey. Int. J. Stochastic simulation of Risk factor potential ef-
Inf. Manage., 23(2003), pp. 25–40, 2003. fects for software development Risk management.
J. Syst. Softw., 59(3), pp. 247–257, Dec. 2001.
[29] D. ALOINI, R. DULMIN, V. MININNO, Risk manage-
ment in ERP project introduction: Review of the [44] B. LAWRENCE, K. WIEGERS, C. EBERT, The Top
literature. Inf. Manag., 44(6), pp. 547–567, Sep. Risks of Requirements Engineering, 2001.
2007.
[45] D. SHAFER AND C. OFFICER, Software Risk: Why
[30] W. HAN, S. HUANG, An empirical analysis of Risk must we keep learning from experience? Where
components and performance on software projects. Does Risk Occur in DP Software Development? In
J. Syst. Softw., 80(1), pp. 42–50, Jan. 2007. Dynamic Positioning Conference, pp. 1–19, 2004.
Modelling and Evaluating Software Project Risks with Quantitative Analysis Techniques. . . 139

[46] C. JONES, G. GLEN, G. ANNA, D. MILLER, Strategies ABDELRAFE ELZAMLY is currently a Ph.D. student of Information
for improving systems development project success. and Communication Technology at the Technical University Malaysia
Issues Inf. Syst., XI(1), pp. 164–173, 2010. Malaka (UTeM). Born on November 30, 1976 in Gaza, Palestine, he
received his B.Sc. degree in 1999 from AI-Aqsa University, Gaza and
his Master degree in Computer Information Systems in 2006 from the
[47] C. JONES, Applied Software Measurement Global University of Banking and Financial Sciences. Since 1999 he has been
Analysis of Productivity and Quality, Third. No. working as a full time lecturer of Computer Science at AI-Aqsa Uni-
Third Edition. McGraw-Hill Companies, 2008, p. versity. Also, from 1999 to 2007 he worked as a part time lecturer at
662. the Islamic University in Gaza. Between 2010 and 2012 he worked as
a Manager in the Mustafa Center for Studies and Scientific Research in
[48] A.-N. TAIMOUR, Why IT Projects Fail, 2005. Gaza. His research interests are in Risk management, quality software,
software engineering and data mining.
[49] C. MARTIN, J. PASQUIER, C. M., A. T., Software
Development Effort Estimation Using Fuzzy Logic:
A Case Study. In Proceedings of the Sixth Mexi- BURAIRAH HUSSIN received his Ph.D. degree in Management Science-
can International Conference on Computer Science Condition Monitoring Modelling, from the University of Salford,UK in
(ENC’05), pp. 113–120, 2005. 2007. Before that, he received a M.Sc. degree in Numerical Analysis
and Programming from the University of Dundee, UK in 1998 and a
B.Sc. degree in Computer Science from the University of Technology
[50] X. JIN, X. XU, Remote sensing of leaf water con- Malaysia in 1996. He currrently works as an Associate Professor at the
tent for winter wheat using grey relational ana- Technical University Malaysia Malaka (UTeM). He also worked as the
lysis (GRA), stepwise regression method (SRM) Deputy Dean (Research and Postgraduate) at the Faculty of Informa-
and partial least squares (PLS). In First Interna- tion and Communiction Technology, Technical University of Malaysia
tional Conference on Agro-Geoinformatics (Agro- Malaka (UTeM). His research interests are in data analysis, data min-
Geoinformatics), pp. 1–5, 2012. ing, maintenance modelling, artificial intelligence, Risk management,
numerical analysis, and computer network advising and development.
[51] Y. LAN, S. GUO, Multiple Stepwise Regression
Analysis on Knowledge Evaluation. In Interna-
tional Conference on Management of E-Commerce
and E-Government, pp. 297–302, 2008.
[52] N. ZHOU, J. PIERRE, D. TRUDNOWSKI, A Stepwise
Regression Method for Estimating Dominant Elec-
tromechanical Modes. IEEE Trans. Power Syst.,
27(2), pp. 1051–1059, 2012.

Received: August, 2014

Revised: October, 2014
Accepted: November, 2014

Contact addresses:
Abdelrafe Elzamly
Department of Computer Science
Faculty of Applied Sciences
Al-Aqsa University P.O.BOX: 4051
Gaza
Palestine
e-mail: abd [email protected]
Burairah Hussin
Fakulti Maklumat & Komunikasi
Universiti Teknikal Malaysia Melaka
Locked Bag 1752, Durian Tunggal
P.O.BOX: 76109 Durian Tunggal
Melaka Malaysia
e-mail: [email protected]