Journal of Computing and Information Technology - CIT 22, 2014, 2, 131–144 131

doi:10.2498 /cit.1002324

Managing Software Project Risks

(Analysis Phase) with Proposed Fuzzy
Regression Analysis Modelling
Techniques with Fuzzy Concepts

Abdelrafe Elzamly1,2 and Burairah Hussin1

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

The aim of this paper is to propose new mining tech- factors rather than waiting for problems to occur
niques by which we can study the impact of different and then trying to react. Project management
risk management techniques and different software risk
factors on software analysis development projects. The and risk management have been proposed as a
new mining technique uses the fuzzy multiple regression solution to preserve the quality and integrity of a
analysis techniques with fuzzy concepts to manage the project by reducing cost escalation (Schwalbe,
software risks in a software project and mitigating risk 2010). Due to the involvement of risk manage-
with software process improvement. Top ten software
risk factors in analysis phase and thirty risk management ment in monitoring the success of a software
techniques were presented to respondents. The results project, analyzing potential risks, and making
show that all software risks in software projects were decisions about what to do about potential risks,
very important from software project manager perspec-
tive, whereas all risk management techniques are used the risk management is consideredthe planned
most of the time, and often. However, these mining tests control of risk. Integrating formal risk manage-
were performed using fuzzy multiple regression analysis ment with project management is a new phe-
techniques to compare the risk management techniques nomenon in software engineering and product
with each of the software risk factors to determine if they
are effective in reducing the occurrence of each software management community. In addition to that,
risk factor. The study has been conducted on a group of risk is an uncertainty that can have a negative
software project managers. Successful software project or positive effect on meeting project objectives.
risk management will greatly improve the probability of
software project success. Risk management is the process of identifying,
analyzing and controlling risk throughout the
Keywords: software risk management, analysis phase, life of a project, to meet the project objectives
software risk factors, risk management techniques, cor- (Schwalbe, 2010).
relation analysis, fuzzy regression analysis techniques
with fuzzy concepts, mining techniques, coefficient of However, an intelligent performance analysis
determination approach is adapted for decision making to se-
lect the optimization techniques to apply in real
word problem solving approach, particularly re-
lated to industrial engineering problems (Vas-
1. Introduction ant, 2013) The mining approach is a new way of
identifying risk from data that creates relation-
Despite much research and progress in the area ships between data and finds the optimum result
of software project management, software de- from them. This includes techniques such as
velopment projects still fail to deliver accept- simulation analysis, fuzzy logic models, fuzzy
able systems on time and within budget. Much multiple regression, neural network models, ge-
of the failure could be avoided by managers’ netic algorithm, and heuristic algorithm. How-
pro-active maintenance and dealing with risk ever, the goal of risk management at early iden-
132 Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling...

tification and recognition of risks and then ac- activities performed by software project man-
tively changes the course of actions to mitigate agers to model and mitigate the identified soft-
and reduce the risk (Miler & Górski, 2002). ware analysis project risks. The organization of
In the process of understanding the factors that this paper will be as follows. Section 2 presents
contribute to software project success, risk is be- an overview of the literature. Section 3 intro-
coming increasingly important. This is a result duces the software risk factors (analysis phase)
of the size, complexity and strategic importance relevant for the study. Section 4 introduces the
of many of the information systems currently common risk management techniques for these
being developed. Today, we must think of risk software risks. Section 5 presents the empiri-
as a part of software project lifecycle which is cal work. Section 6 concludes the article and
important for a software project survival (Pan- glimpses on future work.
dian, 2007) On the other hand, risk management
aims to read risks as improvement opportunities
and provide inputs to growth plans (Pandian, 2. Literature Review
2007).
In our paper, we identified software risk fac- According to (H. Taylor, 2005), the key risks
tors and risk management techniques that guide are identified by a group of Hong Kong project
software project managers to understand and managers working for vendor IT firms who of-
mitigate risks in software analysis development fered package implementation solutions, both
projects. However, Software Development Life locally and overseas. In that study a num-
Cycle according to (Hoffer, George, & Valacich, ber of new risks from the vendor perspective
2011), is the process of creating or altering sys- have been identified, which indicate that ven-
tems, and the models and methodologies that dor project managers typically have a broader
people use to develop these systems. Also, it focus on risks than their in-house counterparts.
includes these phases as follows (Hoffer et al., Addison & Vallabh (Addison & Vallabh, 2002)
2011): Planning, analysis, design, implemen- focused on the experienced project manager’s
tation, and maintenance. In addition to that, perceptions of software project risks and con-
we focused on the analysis phase: It includes trols. This work reports on the more significant
looking at any existing system to see what it is risks and controls that are utilized to reduce the
doing for the organization and how well that sys- occurrence of the risk factors. The effectiveness
tem is doing its job. According to Taylor, we of various controls to reduce the occurrence of
should apply techniques consistently through- risk factors was also identified and discussed.
out the software project risk management pro- We improved quality of software projects of the
cess (J. Taylor, 2004). Risk management is a participating companies while estimating the
practice of controlling risk and the practice con- quality–affecting risks in IT software projects
sists of processes, methods, and tools for man- (Elzamly & Hussin, 2011a). The new tech-
aging risks in a software project before they nique used the chi-square ( 2) test to control
become problems (Sodhi & Sodhi, 2001). the risks in a software project (Khanfar et al.,
2008). However, we also used new techniques
This study will guide software managers to ap- the regression test and effect size test proposed
ply software risk management practices with to manage the risks in a software project and re-
real world software development organizations ducing risk with software process improvement
and verify the effectiveness of the modelling (Elzamly & Hussin, 2011b). Furthermore, we
techniques on a software project. We hope that used the new stepwise regression technique to
the approaches will succeed in the software risk manage the risks in a software project. These
management methodology, which will improve tests were performed using regression analy-
the probability of software project success. The sis to compare the controls with each of the
objective of this study is: To identify the soft- risk factors to determine if they are effective
ware risk factors of software analysis projects in mitigating the occurrence of each risk fac-
in the Palestinian software development orga- tor implementation phase (Elzamly & Hussin,
nizations, to rank the software risk factors ac- 2013). According to (Dash & Dash, 2010) risk
cording to their importance, severity and fre- management consists of the processes, method-
quency, based on data source, to identify the ologies and tools that are used to deal with risk
Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling... 133

factors in the Software Development Life Cy- predicting the reliability of a software project.
cle (SDLC) process of Software Project. Also, Furthermore, there is no integration between
Oracle corporation described risk management the software development life cycle and the
solutions that enable a standardized approach real software risk management phases based on
for identifying, assessing and mitigating risk techniques to manage software risks. There-
throughout the software project lifecycle (Or- fore, previous studies for approach in software
acle, 2010). Risk management methodology risk management limited phases and techniques,
has five phases: Risk identification (planning, thus they do not create the relation between soft-
identification, prioritization), risk analysis and ware risk factors in software development life
evaluation (risk analysis, risk evaluation), risk cycle and risk management techniques to miti-
treatment, risk controlling, risk communication gate risks. This study attempts to propose the
and documentation. These relied on three cat- modelling software risk management for suc-
egories of techniques such as risk qualitative cessful software project, based on fuzzy regres-
analysis, risk quantitative analysis and risk min- sion analysis techniques with fuzzy concepts.
ing analysis throughout the life of a software
project to meet the goals(Elzamly & Hussin,
2014).
3. Top 10 Software Risk Factors in Analysis
Although there are many methods in software Phase
risk management, software development projects
have a high rate of risk failure. Thus, if the com-
plexity and the size of the software projects are This study displays the top ten software risk fac-
increased, managing software development risk tors in software development life cycle (analysis
becomes more difficult (Hoodat and Rashidi, phase) that are common in the literature review
2009). Additionally, the optimization method based on ‘top-ten’ based on Boehm (1991),
was tested with various software project risk Miler (2005). The ‘Top 10 software risk fac-
prediction models that have been developed tors’ lists differ to some extent from author to
(Reyes, Cerpa, Candia, & Bardeen, 2011). There author, but some essential software risk factors
are several software risk management approa- that appear on almost any list can be distin-
ches, models, and framework according to a lit- guished. These factors need to be addressed
erature review, so these models and approaches and thereafter controlled. Consequently, we fo-
are listed in this section. Furthermore (Banner- cus on the work by others, such as Elzamly and
man, 2010), risk management approach prac- Hussin (2011); Aritua et al. (2010); Christo-
tices need to be increased with extra analysis pher Jones et al. (2010); Chen and Huang
to identify, analyze and assess structural risks, (2009); Hoodat and Rashidi (2009); Nakatsu
to mitigate software risks and the delivery of and Iacovou (2009); Caper Jones’s Risk (2008);
software project quality. Büyüközkan and Ruan Khanfar, Elzamly et al. (2008); Pare et al.
(2010) present incorporated multi-criteria to es- (2008); Han and Huang (2007-2008); Aloini
timate the methodology for software managers et al. (2007); Boehm’s 10 risk items (2006-
to mitigate software risks. The method relied on 2007); Taimour (2005); Wallace et al. (2004);
a special fuzzy operator, namely a two-additive Shafer and Officer (2004); Lyons and Skit-
Choquet integral that enables modeling various more (2004); Addison (2003); Kweku (2003);
effects of importance and interactions among Boehm’s 10 risk items (2002); Addison and
software risks. In addition to that, Dhlamini Vallabh (2002); Mark et al. (2002); Mitchell
et al. (2009) demonstrated the need for an in- (2002); Schmidt et al. (2001); Houston et al.
telligent risk assessment and management tool (2001); Lawrence et al. (2001); Sumner (2000);
for either agile or traditional methods in a soft- Mark et al. (1998); The Standish Group sur-
ware development. Therefore, they proposed a vey (1995); a survey of Boehm’s 10 risk items
model which could be investigated for use in de- in 1991 on software risk management; Boehm
veloping intelligent software risk management and Ross (1989); and many other researchers
tools (Dhlamini, Nhamu, & Kachepa, 2009). in software engineering to obtain software risk
Finally, the approaches and methods reviewed factors and risk management techniques. The
above do not focus on modelling software risks next discussions consist of the 10 most serious
based on quantitative and mining techniques for risks of a software project ranked from one to
134 Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling...

ten, each risk’s status, and the plan for address- mining structures, C15: Reusable user docu-
ing each risk as recommended by researchers ments early, C16: Implementing/Utilizing au-
and experts when studying the software risk fac- tomated version control tools, C17: Implement-
tors in software development life cycle. These ing/utilizing benchmarking and tools of techni-
software project risks are illustrated in Table 1: cal analysis, C18: Creating and analyzing pro-
cess by simulation and modeling, C19: Provid-
ing scenarios methods and using of the reference
4. Risk Management Techniques checking, C20: Involving management during
the entire software project lifecycle, C21: In-
Through reading the existing literature on soft- cluding formal and periodic risk assessment,
ware risk management, we listed thirty control C22: Utilizing change control board and ex-
factors that are considered important in reduc- ercising quality change control practices, C23:
ing the software risk factors identified; these Educating users on the impact of changes dur-
controls are: ing the software project, C24: Ensuring that
quality-factor deliverables and task analysis,
C1: Using of requirements scrubbing, C2: Sta- C25: Avoiding having too many new func-
bilizing requirements and specifications as early tions on software projects, C26: Incremental
as possible, C3: Assessing cost and scheduling development (deferring changes to later incre-
the impact of each change to requirements and ments), C27: Combining internal evaluations
specifications, C4: Develop prototyping and by external reviews, C28: Maintaining proper
have the requirements reviewed by the client, documentation of each individual’s work, C29:
C5: Developing and adhering a software project Providing training in the new technology and
plan, C6: Implementing and following a com- organizing domain knowledge training, C30:
munication plan, C7: Developing contingency Participating of users during the entire software
plans to cope with staffing problems, C8: As- project lifecycle.
signing responsibilities to team members and
rotating jobs, C9: Have team-building sessions,
C10: Reviewing and communicating progress
to date and setting objectives for the next phase, 5. Empirical Strategy
C11: Dividing the software project into control-
lable portions, C12: Reusable source code and
interface methods, C13:Reusable test plans and Data collection was achieved through the use
test cases, C14: Reusable database and data of a structured questionnaire and historical data

Dimension No Software risk factors Frequency

1 Unclear, incorrect, continually and rapidly changing software project requirements 19
Failure to incomplete or missing detailed requirements analysis and
2 specification documentation 9
3 Developer software gold-plating 7
4 Lack of software project/IT Management 6
5 Software project requirements not adequately identified and mismatched 6
Analysis 6 Inadequate knowledge about tools and programming techniques 5
Lack of traceability, confidentiality, correctness and inspection of the software
7 project planning 4
8 Major requirements change after software project plan phase 3
9 Changing software project specifications 2
10 Inadequate value analysis and a measurement software project to measure progress 2
Total frequency 63

Table 1. Illustration of top ten software risk factors in software project based on researchers.
Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling... 135

for assisting in estimating the quality of soft- gov.ps/ PIPA 2012] to select top IT manager
ware through determining the risks that were and software project managers. In order to mit-
common to the majority of software projects igate risk, we can use qualitative, quantitative,
in the analyzed software companies. Top ten and mining approaches. In this study, the min-
software risk factors and thirty risk manage- ing approaches are proposed to manage soft-
ment techniques were presented to respondents. ware risk. In order to establish the mining ap-
The method of sample selection referred to as proaches, first we need to model the relationship
‘snowball’ and distribution of personal regular between software risks (analysis phase) and risk
sampling was used. This procedure is appro- management techniques. The model that we
priate when members of homogeneous groups propose a fuzzy multiple regression analysis to
(such as software project managers, IT man- mitigate risks. Indeed, our approaches focused
agers) are difficult to locate. The seventy six on identifying software risk factors, and risk
software project managers participated in this management techniques in software develop-
study. The project managements that partici- ment and how to manage and model the soft-
pated in this survey came from specific, mainly ware risk factors with statistical and mining
software project managements in software de- techniques.
velopment organizations.
The respondents were presented with various 5.1. Correlation Analysis
questions, which used scales 1-7. For pre-
sentation purposes in this paper and for ef- Clearly, the preceding analysis states that there
fectiveness, the point scale was the follow- are correlations between determining variables
ing: For choices, being headed, ‘unimportant’ besides correlation between risk factors and all
equals one and ‘extremely important’ equals determining control factors (Rui-ge & Bing-
seven. Similarly, seven frequency categories rong, 2011). However, the equation of Cor-
were scaled into ‘never’ equals one and ‘al- relation Coefficient is the following (Martin,
ways’ equals seven. All questions in software Pasquier, M., & T., 2005; Marza & Seyyedi,
risk factors were measured on a seven–point 2009):
Likert scale from unimportant to extremely im-   
portant and software control factors were mea- n[ (Xi ·Yi )]−( Xi )( Yi )
sured on a seven–point Likert scale from never R=     
[n( Xi2 )−( Xi )2 ][n( Yi )−( Yi )]
to always. Therefore, the more extreme cate-
gories were combined in a way such that seven- (1)
point scale were reduced to five-point scale as
follows: A category called ‘somewhat impor-
tant’ was created, combining the two ratings 5.2. Regression Analysis Model
‘very slightly important’ and ‘slightly impor-
tant’. Similarly, a category called ‘very impor- Regression modeling is one of the most widely
tant’ combined the two ratings ‘very important’ used statistical modeling techniques for fitting
and ‘extremely important’. Similarly, seven fre- a response (dependent) variable as a function
quency categories were re-scaled into five sub- of predictor (independent) variables (Martin et
categories for presentation purposes. ‘Rarely’ al., 2005). Indeed, software risk factor is a
combined the two ratings: ‘rather seldom’ and dependent variable while control factors are in-
‘seldom’. ‘Never’, ‘sometimes’ and ‘often’ dependent variables. A linear equation between
was unchanged, while ‘most of the time’, com- one and many independent variables (multiple
bined the two ratings: ‘usually’ and ‘always’. regression) may be expressed as:
However, to describe “Software Development Y = b0 + b1x 1 + b2x 2 + . . . + bnx n (2)
Company in Palestine” having in-house devel-
opment software and supplier of software for where b0, b1, b2, . . . and bn are constants;
local or international market, we depended on x1, x2, . . . and xn are the independent variables,
Palestinian Information Technology Associa- and y is the dependent variable. The values of
tion (PITA) Members’ webpage at PITA’s web- b0, b1, b2, . . . and bn of the multiple regression
site [www.pita.ps/ PITA 2012], Palestinian in- equation may be obtained solving the next linear
vestment promotion agency [http://www.pipa. equations system (Martin et al., 2005).
136 Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling...

5.3. Regression Model with Fuzzy a normal distribution membership function as

Concepts follows (Marza & Seyyedi, 2009):
 2
Fuzzy regression analysis is an extension of the 1 − 12 yi − 
Ui = √ e (3)
classical regression analysis in which some ele-  2 
ments of the models are represented by fuzzy
numbers (Dom, Abidin, Kareem, Ismail, & where  is an average of sample points and
Daud, 2012). Additionally, mining algorithms  is square root of variance math. If we add
usually assume that the input data is precise fuzzy domain to regression method, the effect
and clean, which is unrealistic in practical situ- of discrete data points on the fitness result will
ations (Chen & Weng, 2008). In other words, be reduced and the effect of concentrated data
fuzzy multiple regression model in which re- points on the fitness result will be enhanced.
sponse variable is a fuzzy variable and part of Indeed, a membership function is a curve that
the covariates are crisp variables (Lin, Zhuang, defines how each point in the input space is
& Huang, 2012). Therefore, fuzzy regression mapped to a membership value (or degree of
methods have considerably they are helpful or membership) between 0 and 1 (Dom et al.,
widened the field of application of classical re- 2012). Specifically, the simplest membership
gression methods in such a way that in determin- functions are formed using straight lines such as
ing regression relations from fuzzy initial data, triangular membership function (specified by 3
which can be either quantitative and qualitative parameters) and trapezoidal membership func-
(Gu, Song, & Xiao, 2006). Also, the same au- tion (Aali, Parsinejad, & Rahmani, 2009; Dom
thors explained, when one or some data points et al., 2012; Ir. Wahidin, 2009).
are greatly influenced by random factors, there
must be a difference between the result gained
5.5. Fuzzy Parameters
and the actual values. At that time, the classical
regression analysis is not applicable.
A group of equations to obtain the fuzzy param-
Although real data tends to be imprecise, no eters are provided as (Gu et al., 2006; Popescu
previous research has ever developed mining & Giuclea, 2007):
algorithms to find knowledge directly from im-
precise data (Chen & Weng, 2008). However, s11b1 + s12b2+ . . . + s1kbk = s1y
it identifies the various data types that may ap- s21b1 + s22b2+ . . . + s2kbk = s2y
pear in a questionnaire. Then, we introduce the s31b1 + s32b2+ . . . + s3kbk = s3y
questionnaire data mining problem and define s41b1 + s42b2+ . . . + s4kbk = s4y
the rule patterns that can be mined from ques- (4)
tionnaire data. A unified approach is developed s51b1 + s52b2+ . . . + s5kbk = s5y
based on fuzzy techniques so that all different ..
.
data types can be handled in a uniform manner
(Chen & Weng, 2009). Therefore, in order to sk1b1 + sk2b2+ . . . + skkbk = sky
discover rules from a questionnaire dataset, we here
need a brand new approach that can deal with    
different data types occurring (Chen & Weng, sij = u uxixj − uxi ux
2009). Therefore the same authors explained
that all data types could be represented and op- and
erated from fuzzy points of view. Furthermore,    
we must extend the crisp association rules to siy = u uxiy − uxi uy
fuzzy association rules from questionnaire data.
According to this group of equations, first we
can obtain the values of variables b1, b2, . . . , bk
5.4. Fuzzy Concepts with Membership and finally b0 is gained by:
Function    
uy ux1 ux2 uxk
b0 =  −b1  −b2  −. . .−bk 
u u u u
Fuzzy concepts help us to find the deviation of
each data from fitness equation, so we define (5)
Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling... 137

5.6. Coefficient of Determination 5.8. Ranking of Importance of Software Risk

Factors for Project Managers’
Coefficient of determination is used to assess the Experience
quality of estimation models and is expressed by
R2 . The coefficient R2 calculated by (Gu et al., As we see, the results in Table 3 show that most
2006): of the risks are very important and important the
n
overall ranking of importance of each software
(y̌ − y)2
i=1 risk factor for the three categories of project
R2 = n (6) managers’ experience.
 2
(y − y)
n=1
Here, y expresses the mean value of random Phase Risk Experience Experience Experience
2-5 years 6-10 years 10 years
variables. Obviously, the coefficient R2 de- R1 R3 R3 R5
scribes the percentage of variability and the R2 R2 R4 R4
value is between 0 and 1; when an R2 is close to R3 R1 R6 R3
1, it indicates that this model can explain vari- R4 R6 R5 R6
ability in response to the predictive variables, Analysis R5 R8 R7 R7
so called there is a strong relationship between R6 R5 R1 R2
the independent and dependent variables. R7 R4 R9 R10
R8 R9 R8 R9
R9 R10 R10 R6
5.7. Importance of Software Risk Factors R10 R7 R2 R1
in Analysis Phase

Table 2 illustrates all respondents which indi- Table 3. Overall risk ranking of each software risk factor
(analysis phase).
cated that the risk of “developer software gold–
plating” was the highest risk factors and very
important. In fact, the software risk factors
from risk number 3, 4, 5, 6, 1, 8, 2 were identi- 5.9. Frequency of Occurrence of Controls
fied as very important, the software risk factors
from risk number 9, 7, 10 in descending means Table 4 shows the mean and the standard devi-
were identified as important, aggregating the re- ation for each control factor. The results of this
sponses resulted in the following ranking of the paper show that most of the controls are used
importance of the listed risks (in order of im- most of the time and often.
portance): Risk 3, Risk 4, Risk5, Risk 6, Risk
1, Risk 8, Risk 2, Risk 9, Risk 7, Risk 10.
5.10. Relationships between Software Risks
Risk N Mean Std. Deviation % and Risk Management Techniques in
R3 76 4.145 .743 82.895 Analysis Phase
R4 76 4.092 .819 81.842
R5 76 4.079 .796 81.579 Regression technique was performed on the data
R6 76 4.026 .748 80.526 to determine whether there were significant re-
R1 76 4.026 .588 80.526 lationships between control factors and software
R8 76 4.013 .792 80.263 risk factors. These tests were performed using
R2 76 4 .849 80 fuzzy regression analysis, to compare the con-
R9 76 3.947 .728 78.947 trols to each of the software risk factors to de-
R7 76 3.921 .963 78.421 termine if they are effective in reducing the oc-
R10 76 3.895 .793 77.895 currence of each risk factor. Relationships be-
Total 76 4.014 0.544 80.289 tween software risks and controls, which were
significant and insignificant, any control is not
Table 2. Mean score for each software risk factor significant, we are not reported according to the
(analysis phase). best model with fuzzy concepts.
138 Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling...

tween controls 1, 6, 11 and risk 1. Also the con-

Control Mean Std. Deviation % percent trol 1 has an impact on the risk 1. Additionally,
C29 4.408 0.803 88.15789 the results show that the control 1 has positive
C30 4.368 0.907 87.36842 impact value of 0.282, and the value of R2 is
C20 4.184 0.668 83.68421 0.013367. This is interpreted as a percentage
C27 4.171 0.755 83.42105 of 1.33 % from the dependent variable of risk1.
C21 4.171 0.7 83.42105 According to the fuzzy concepts in multiple re-
C19 4.158 0.612 83.15789 gression analysis to produce a fuzzy multiple
C28 4.158 0.767 83.15789 regression model by solving these equations,
C25 4.132 0.718 82.63158 the final fuzzy equation is:
C26 4.118 0.653 82.36842
C23 4.105 0.741 82.10526
FuzzyRisk1 = 4.571930941+0.09074 9888∗C1
C22 4.092 0.786 81.84211
(7)
C18 4.079 0.726 81.57895
C10 4.079 0.726 81.57895
R2: Risk of ‘Failure to Incomplete or
C17 4.066 0.718 81.31579
Missing Detailed Requirements Analysis
C24 4.066 0.639 81.31579
and Specification Documentation’
C8 4.066 0.736 81.31579 Compared to Controls.
C5 4.053 0.728 81.05263
C11 4.039 0.756 80.78947
C15 4.039 0.621 80.78947
C1 C2 C3 C4 C5
C9 4.039 0.756 80.78947
.386** .441** .521** .474** .339**
C14 4.013 0.683 80.26316
C6 C7 C8 C9 C10
C7 4.013 0.721 80.26316
.455** .476** .314** .310** .338**
C16 4 0.693 80
C11 C16 C19 C20 C25
C12 3.987 0.841 79.73684
.304** .241* .286* .251* .349**
C6 3.987 0.739 79.73684
C26 C29 C30
C4 3.987 0.757 79.73684
.233* .274* .291*
C3 3.974 0.783 79.47368
C2 3.934 0.66 78.68421
C1 3.895 0.665 77.89474 Table 6. Illustration of the value of correlation.
C13 3.868 0.754 77.36842

Table 4. Mean score for each control factor. Table 6 shows that the significant value is less
than the assumed value at the  = 0.05 level
of significance, so there is a positive relation
R1: Risk of ‘Unclear, Incorrect, Continually between controls 1, 2, 3, 4, 5, 7, 8, 9, 10, 11,
and Rapid Changing Software Project 16, 19, 20, 25, 26, 29, 30, and risk 2. Controls
Requirements’ Compared to Controls. 3 and 7 have an impact on the risk 2. Addition-
ally, the results show that control 3 and 7 have
a positive impact values of 0.521 and 0.251 re-
C1 C6 C11 spectively; a multiple correlation value is 0.575,
.282* .238* .235* and the value of R2 is 0.1383. This is interpreted
* Correlation is significant at the 0.05 level (2-tailed). as a percentage of 13.83 % from the dependent
**Correlation is significant at the 0.01 level (2-tailed). variable of risk 2. According to the fuzzy con-
cepts in multiple regression analysis to produce
Table 5. Illustration of the value of correlation. a fuzzy multiple regression model by solving
these equations, the final fuzzy equation is:

Table 5 shows that the significant value is less FuzzyRisk2=2.613484124+0.239186282 ∗ C3

than the assumed value at the  = 0.05 level of + 0.246909848 ∗ C7
significance, so there is a positive relation be- (8)
Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling... 139

R3: Risk of ‘Developer Software Gold-Plating’ Table 8 shows that the significant value is less
Compared to Controls. than the assumed value at the  = 0.05 level of
significance, so there is a positive relation be-
tween controls 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
C1 C2 C3 C4 C5 16, 19, 20, 28, 29, 30 and risk 4. Also, controls
.350** .341** .366** .352** .269* 3 and 6 have an impact on risk 4. Additionally,
C6 C7 C8 C9 the results show that controls 3, and 6 have a
.332** .407** .330** .257* positive impact values of 0.448, and 0.534 re-
C10 C11 C15 C19 spectively, also a multiple correlation value of
.317** .306** .258* .284* 0.573, and the value of R2 is 0.14499. This is in-
C21 C23 C25 C28 terpreted as a percentage of 14.499 % from the
.268* .275* .307** .232* dependent variable of risk 4. According to the
fuzzy concepts in multiple regression analysis
to produce a fuzzy multiple regression model by
Table 7. Illustration of the value of correlation.
solving these equations, the final fuzzy equation
is:
Table 7 shows that the significant value is less
than the assumed value at the  = 0.05 level of FuzzyRisk4=3.102883775+0.079997397 ∗ C3
significance, so there is a positive relation be- +0.325755516 ∗ C6
tween controls 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 15, (10)
19, 21, 23, 25, 28, and risk 3. Also, controls 7
and 25 have an impact on risk 3. Additionally,
the results show that controls 7 and 25 have a
positive impact values of 0.407 and 0.307 re- R5: Risk of ‘Software Project Requirements
spectively, also a multiple correlation value of Not Adequately Identified and Mismatched’
0.466, and the value of R2 is 0.1432. This is Compared to Controls.
interpreted as a percentage of 14.32 % from the
dependent variable of risk 3. According to the
C1 C2 C3 C4
fuzzy concepts in multiple regression analysis to
.390** .297** .347** .239*
produce a fuzzy multiple regression model by
C5 C6 C7 C10
solving these equations above, the final fuzzy
.271* .264* .355** .252*
equation is:
C11 C21 C25 C29
FuzzyRisk3=2.707681169+0.239186282 ∗ C7 .279* .285* .231* .249*
+ 0.246909848 ∗ C25
(9)
Table 9. Illustration of the value of correlation.

R4: Risk of ‘Lack of IT Management’

Compared to Controls. Table 9 shows that the significant value is less
than the assumed value at the  = 0.05 level
of significance, so there is a positive relation
C1 C2 C3 C4 C5 between controls 1, 2, 3, 4, 5, 6, 7, 10, 11,
.424** .398** .448** .348** .340** 21, 25, 29 and risk 5. Controls 1 and 21 have
C6 C7 C8 C9 C10 an impact on risk 5. Additionally, the results
.534** .403** .404** .383** .342** show that controls 1, 21 have positive impact
C11 C12 C16 C18 C19 values of 0.390, and 0.285 respectively; a mul-
.308** .240* .229* .322** .238* tiple correlation value is 0.517 and the value of
C20 C28 C29 C30 R2 is 0.0570. This is interpreted as a percentage
.250* .331** .284* 0.236* of 5.70 % from the dependent variable of risk
5. According to the fuzzy concepts in multiple
regression analysis to produce a fuzzy multiple
Table 8. Illustration of the value of correlation. regression model by solving these equations,
140 Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling...

the final fuzzy equation is: C1 C2 C3 C3 C4

.470** .361** .453** .268* .289*
FuzzyRisk5=4.15600521+0.204598689 ∗ C1 C6 C7 C8 C9 C10
− 0.153570292 ∗ C20 .464** .428** .485** .393** .462**
+ 0.149643258 ∗ C21 C11 C12 C14 C16 C18
(11) .289* .316** .264* .321** .259*
C19 C21 C23 C24 C29
.239* .316** .322** .252* .257*
R6: Risk of ‘Inadequate Knowledge about
Tools and Programming Techniques’ Table 11. Illustration of the value of correlation.
Compared to Controls.
Table 11 shows that the significant value is less
C1 C2 C3 C4 C5 than the assumed value at the  = 0.05 level
.483** .369** .430** .345** .346** of significance, so there is a positive relation
C6 C7 C8 C9 C10 between controls 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
.448** .469** .305** .337** .344** 12, 14, 16, 18, 19, 21, 23, 24 , 29 and risk 7.
C11 C14 C16 C17 C18 Also, controls 1 and 8 have an impact on risk
.346** .303** .313** .244* .281* 7. Additionally, the results show that controls 1
C19 C23 C25 C29 C30 and 8 have a positive impact values of 0.470 and
.269* .230* .269* .249* .228* 0.485 respectively; a multiple correlation value
is 0.581, and the value of R2 is 0.0949. This is
interpreted as a percentage of 9.49 % from the
Table 10. Illustration of the value of correlation. dependent variable of risk 7. According to the
fuzzy concepts in multiple regression analysis
Table 10 shows that the significant value is less to produce a fuzzy multiple regression model by
than the assumed value at the  = 0.05 level solving these equations, the final fuzzy equation
of significance, so there is a positive relation is:
between controls 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, FuzzyRisk7=2.745257135+0.225369972 ∗ C1
11, 12, 13, 14, 16, 17, 18, 23, 25, 29, 30, and + 0.228982572 ∗ C8
risk 6. Additionally, controls 1, 7, and 16 have (13)
an impact on risk 6. Besides, the results show
that controls 1, 7, and 16 have a positive impact
values of 0.483, 0.469, and 0.313 respectively, R8: Risk of ‘Major Requirements Change
also a multiple correlation value is 0.594, and After Software Project Plan Phase’
the value of R2 is 0.332048. This is interpreted Compared to Controls.
as a percentage of 33.20 % from the dependent
variable of risk 6. According to the fuzzy con-
cepts in multiple regression analysis to produce C1 C2 C3 C4 C5
a fuzzy multiple regression model by solving .475** .476** .477** .387** .355**
these equations above, the final fuzzy equation C6 C7 C8 C9 C10
is: .460** .501** .396** .423** .557**
C11 C12 C13 C14 C16
FuzzyRisk6=0.751844957+0.26037583 ∗ C1 .456** .333** .257* .297** .241*
+ 0.293694496 ∗ C7 C17 C18 C19 C21 C22
+ 0.302258836 ∗ C16 .226* .400* .394* .267* .240*
(12) C23 C24 C25 C26 C27
.352** .246* .290* .263* .273*
C28 C29 C30
R7: Risk of ‘Lack of Traceability, .339** .374** .306**
Confidentiality, Correctness and Inspection
of the Software Project Planning’
Compared to Controls. Table 12. Illustration of the value of correlation.
Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling... 141

Table 12 shows that the significant value is less solving these equations, the final fuzzy equation
than the assumed value at the  = 0.05 level is:
of significance, so there is a positive relation FuzzyRisk9=3.639559441
between controls 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 16, 17, 18, 21, 22, 23, 24, 25, + 0.091936178 ∗ C3 (15)
26, 27, 28, 29, 30, and risk 18. Also, controls 7 +0.167103717 ∗ C21
and 10 have an impact on risk 8. Additionally,
the results show that controls 7, and 10 have
positive impact values of 0.501, and 0.557 re- R10: Risk of ‘Inadequate Value Analysis to
spectively, also, the multiple correlation value Measure Progress’ Compared to Controls.
is 0.613, and the value of R2 is 0.1060. This is
interpreted as a percentage of 10.60 % from the C1 C2 C3 C7 C10 C12
dependent variable of risk 8. According to the .269* .255* .295* .243* .247* .236*
fuzzy concepts in multiple regression analysis C19 C20 C21 C22 C23
to produce a fuzzy multiple regression model by .284* .305** .284* .276* .337**
solving these equations, the final fuzzy equation
is:
Table 14. Illustration of the value of correlation.
FuzzyRisk8=4.565963809
+ 0.018349831∗C7 (14)
+ 0.080708422 ∗ c10 Table 14 shows that the significant value is less
than the assumed value at the  = 0.05 level of
significance, so there is a positive relation be-
tween controls 1, 2, 3, 7, 10, 12, 19, 20, 21, 22,
R9: Risk of ‘Changing Software Project
23 and risk 10. Also, controls 20 and 23 have
Specifications’ Compared to Controls.
an impact on risk 10. Additionally, the results
show that controls 20 and 23 have a positive
C1 C2 C3 C6 C7 impact values of 0.305 and 0.337 respectively,
.363** .367** .393** .239* .293*
also a multiple correlation value is 0.400, and
C8 C9 C10 C11 C12 the value of R2 is 0.0282. This is interpreted
.284* .296** .337** .277* .301** as a percentage of 2.82 % from the dependent
C13 C14 C16 C19 C21
variable of risk 10. According to the fuzzy con-
.234* .289* .320** .248* .407*
cepts in multiple regression analysis to produce
a fuzzy multiple regression model by solving
C22 C23 C24 C29 C30
these solving these equations, the final fuzzy
.236* .384* .233* .258* .290*
equation is:
FuzzyRisk10=3.728926746
Table 13. Illustration of the value of correlation.
+ 0.124254526 ∗ C20 (16)
+ 0.10610371 ∗ C23
Table 13 shows that the significant value is less
than the assumed value at the  = 0.05 level
of significance, so there is a positive relation
between controls 1, 2, 3, 6, 7, 8, 9, 10, 11, 12, 5.11. Software Risk Factors Identification
13, 14, 16, 21, 22, 23, 24, 29, 30, and risk 9. Checklists and Control Factors
Also, controls 3 and 21 have an impact on risk (Risk Management Techniques)
9. Additionally, the results show that controls 3
and 21 have positive impact values of 0.393 and Table 15 shows a software risk factors identifi-
0.407 respectively; a multiple correlation value cation checklist with control techniques based
is 0.535, and the value of R2 is 0.0414. This is on a questionnaire of experienced software pro-
interpreted as a percentage of 4.14 % from the ject managers. We can use the checklist on soft-
dependent variable of risk 9. According to the ware analysis projects to identify model soft-
fuzzy concepts in multiple regression analysis ware risk factors on software development life
to produce a fuzzy multiple regression model by cycle by risk management techniques.
142 Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling...

No Software Risk Factors (Analysis Phase) Risk Management Techniques

Unclear, incorrect, continual and rapid C1: Using of requirements scrubbing.
1 changing software project requirements.
C3: Assessing cost and scheduling the impact of each
Failure to incomplete or missing detailed change to requirements and specifications,
2 requirements analysis and specification C7: Developing contingency plans to cope with staffing
documentation. problems.
C7: Developing contingency plans to cope with staffing
problems,
3 Developer software gold-plating. C25: Avoiding having too many new functions on software
projects.
C6: Implementing and following a communication plan,
4 Lack of IT Management. C3: Assessing cost and scheduling the impact of each
change to requirements and specifications.
C1: Using of requirements scrubbing,
Software project requirements not adequately C21: Including formal and periodic risk assessment,
5 C20: Involving management during the entire software
identified and mismatched.
project life cycle.
C6: Using of requirements scrubbing,
Inadequate knowledge about tools and C7: Developing contingency plans to cope with staffing
6 programming techniques. problems,
C16: Implementing/Utilizing automated version control
tools.
C8: Assigning responsibilities to team members and
Lack of traceability, confidentiality, correctness rotating jobs,
7 and inspection of the software project planning. C1: Using of requirements scrubbing.
C10: Reviewing and communicating progress to date and
Major requirements change after software setting objectives for the next phase,
8 project plan phase. C7: Developing contingency plans to cope with staffing
problems.
C21: Including formal and periodic risk assessment,
Involving management during the entire software
9 Changing software project specifications. project lifecycle,
C3: Assessing cost and scheduling the impact of each
change to requirements and specifications.
C23: Educating users on the impact of changes during the
Inadequate value analysis to measure progress. software project,
10 C20: Involving management during the entire software
project life cycle.

Table 15. Software risk factors were mitigated by risk management techniques.

6. Conclusions of the importance of the listed risks (in order

of importance): Risk 3, Risk 4, Risk5, Risk 6,
Risk 1, Risk 8, Risk 2, Risk 9, Risk 7, and Risk
The concern of our paper is mitigating soft- 10. The results of this paper show also that most
ware project risks in the analysis phase. The of the top ten controls are used most of the time.
results show that all risks in software projects These tests were performed using fuzzy regres-
were very important and important in software sion analysis, to compare the control techniques
project manager’s perspective, whereas all con- to each of the software risk factors to determine
trols are used most of the time, and often. There- if they are effective in mitigating and modelling
fore, the software risk factors in the analysis the occurrence of each software risk factor. Re-
phase from risk numbers 3, 4, 5, 6, 1, 8, 2 lationships between risks and controls, which
were identified as very important, the risk fac- were significant and insignificant, any control
tors from risk numbers 9, 7, 10 in descending techniques is no significant, we are not reported.
means were identified as important, aggregating However, we determined the positive correla-
the responses resulted in the following ranking tion between software risk factors in the analy-
Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling... 143

sis phase and risk management techniques, then [6] J. DHLAMINI, I. NHAMU, A. KACHEPA, Intelligent
evaluate and estimated the impact software risk Risk Management Tools for Software Development.
In Proceedings of the 2009 Annual Conference of the
in software development life cycle. We used Southern African Computer Lecturers Association,
correlation analysis, fuzzy regression analysis (2009), pp. 33–40.
techniques proposed. However, we referred the
risk management techniques were mitigated on [7] R. DOM, B. ABIDIN, S. KAREEM, S. ISMAIL, N.
DAUD, Determining the Critical Success Factors of
risk factors in Table 15. Through the results, we Oral Cancer Susceptibility Prediction in Malaysia
found out that some control haven’t impact, so Using Fuzzy Models. Sains Malaysiana, 41(5)
the important controls should be considered by (2012), 633–640.
the software development companies in Pales- [8] A. ELZAMLY, B. HUSSIN, Estimating Quality-
tinian. Affecting Risks in Software Projects. Int. Manag.
Rev. Am. Sch. Press, 7(2) (2011), 66–83.
In addition to the above, we cannot obtain his-
torical data form database until using some tech- [9] A. ELZAMLY, B. HUSSIN, Managing Software
Project Risks with Proposed Regression Model
niques. As future work, we will intend to ap- Techniques and Effect Size Technique. Int. Rev.
ply these study results on a real-world soft- Comput. Softw., 6(2) (2011), 250–263.
ware project to verify the effectiveness of the
new techniques and approaches on a software [10] A. ELZAMLY, B. HUSSIN, Managing Software
Project Risks (Implementation Phase) with Pro-
project. We can use more techniques useful posed Stepwise Regression Analysis Techniques.
to manage software project risks such as neural Int. J. Inf. Technol., 1(4) (2013), 300–312.
network, genetic algorithm, and Bayesian statis-
[11] A. ELZAMLY, B. HUSSIN, An Enhancement of
tics and other artificial intelligence approaches Framework Software Risk Management Method-
to improve the models. ology for Successful Software Development. J.
Theor. Appl. Inf. Technol., 62(2) (2014), 410–423.
[12] X. GU, G. SONG, L. XIAO, Design of a Fuzzy
Acknowledgments Decision-making Model and Its Application to Soft-
ware Functional Size Measurement. In International
Conference on Computational Intelligence for Mod-
This work is supported by the Faculty of Infor- elling Control and Automation, and International
mation and Communication Technology, Uni- Conference on Intelligent Agents,Web Technolo-
gies and Internet Commerce (CIMCA-IAWTIC’06),
versiti Teknikal Malaysia Melaka (UTeM) and (2006), pp. 199–205.
Al-Aqsa University, Palestine.
[13] J. HOFFER, J. GEORGE, J. VALACICH, Modern Sys-
tems Analysis and Design, 6th ed. Prentice Hall,
2011.
References
[14] H. HOODAT, H. RASHIDI, Classification and Analy-
sis of Risks in Software Engineering. Eng. Technol.,
56(32) (2009), 446–452.
[1] K. AALI, M. PARSINEJAD, B. RAHMANI, Estimation
of Saturation Percentage of Soil Using Multiple Re- [15] W. IR. WAHIDIN, Chapter 3: Membership Func-
gression, ANN, and ANFIS Techniques. Comput. tion. In Knowledge-based Systems, Teknik Elektro
Inf. Sci., 2(3) (2009), 127–136. Universitas Indonesia, 2009.

[2] T. ADDISON, S. VALLABH, Controlling Software [16] K. KHANFAR, A. ELZAMLY, W. AL-AHMAD, E. EL-
Project Risks – an Empirical Study of Methods used QAWASMEH, K. ALSAMARA, S. ABULEIL, Managing
by Experienced Project Managers. In Proceedings Software Project Risks with the Chi-Square Tech-
of SAICSIT, (2002), pp. 128 – 140. nique. Int. Manag. Rev., 4(2) (2008), 18–29.

[3] P. BANNERMAN, Managing Structure-Related Soft- [17] J. LIN, Q. ZHUANG, C. HUANG, Fuzzy Statistical
ware Project Risk: A New Role for Project Gov- Analysis of Multiple Regression with Crisp and
ernance. In 21st Australian Software Engineering Fuzzy Covariates and Applications in Analyzing
Conference, (2010), pp. 129–138. Economic Data of China important. Comput. Econ.,
39(1) (2012), 29–49.
[4] Y. CHEN, C. WENG, Mining fuzzy association rules
from questionnaire data. Knowledge-Based Syst., [18] C. L. MARTIN, J. L. PASQUIER, C. M. YANEZ A. T.
22(1) (2009), 46–56. GUTIERREZ, Software Development Effort Estima-
tion Using Fuzzy Logic: A Case Study. In Proceed-
[5] R. DASH, R. DASH, Risk Assessment Techniques ings of the Sixth Mexican International Conference
for Software Development. Eur. J. Sci. Res., 42(4) on Computer Science (ENC’05), (2005), pp. 113–
(2010), 629–636. 120.
144 Managing Software Project Risks (Analysis Phase) with Proposed Fuzzy Regression Analysis Modelling...

[19] V. MARZA, M. SEYYEDI, Fuzzy Multiple Regres- Received: December, 2013

sion Model for Estimating Software Development Revised: May, 2014
Time. International Journal of Engineering Busi- Accepted: May, 2014
ness Management, 1(2) (2009), 31–34.
Contact addresses:
[20] J. MILER, J. GÓRSKI, Supporting Team Risk Man- Abdelrafe Elzamly
agement in Software Procurement and Development Department of Computer Science
Projects. In 4th National Conference on Software Faculty of Applied Sciences
Al-Aqsa University
Engineering, (2002), pp. 1–15. P.O.BOX: 4051
Gaza
[21] ORACLE, A Standardized Approach to Risk Im- Palestine
proves Project Outcomes and Profitability, 2010. e-mail: abd [email protected]
Burairah Hussin
[22] R. PANDIAN, Applied software risk management: Fakulti Maklumat & Komunikasi
A guide for software project managers. Auerbach Universiti Teknikal Malaysia Melaka
Publications is an imprint of the Taylor & Francis Locked Bag 1752, Durian Tunggal
Group, 2007. P.O.BOX: 76109
Durian Tunggal
Melaka Malaysia
[23] C. POPESCU, M. GIUCLEA, A model of multiple e-mail: [email protected]
linear regression. Publ. house Rom. Acad., 8(2)
(2007), 1–8.
[24] F. REYES, N. CERPA, A. CANDIA, M. BARDEEN, The
ABDELRAFE ELZAMLY is currently a Ph.D. student in Software and
optimization of success probability for software Information Systems Engineering at the Faculty of Information and
projects using genetic algorithms. J. Syst. Softw., Communication Technology at Technical University Malaysia Malaka
84(5) (2011), 775–785. (UTeM), Born on November 30, 1976, in Gaza, Palestine. He received
his B.Sc. degree computer in 1999 from Al-Aqsa University, Gaza, and
[25] L. RUI-GE, W. BING-RONG, The Correlation Influ- his Master’s degree in computer information system in 2006 from The
ence Factors Analysis in the Initial Dosage of In- University of Banking and Financial Sciences. He works as lecturer of
sulin Therapy of Diabetes. In Second International Computer Science at Al-Aqsa University from 1999 to 2014 full time
Conference on Mechanic Automation and Control and worked as lecturer in Islamic University in Gaza from 1999 to 2007
as part time lecturer. Also he worked as a manager in The Mustafa
Engineering (MACE), (2011), pp. 774–777. Center for Studies and Scientific Research -Gaza from 2010 to 2012.
His research interests are risk management, quality software, software
[26] K. SCHWALBE, Information Technology Project engineering, and data mining.
Management, Sixth. Course Technology, Cengage
Learning, 2010.
BURAIRAH HUSSIN got a Ph.D. in Management Science – Condition
[27] J. SODHI, P. SODHI, IT Project Management Hand- Monitoring Modelling from University of Salford, UK in 2007. He re-
book. Management Concepts, 2001. ceived his M.Sc. Degree in Numerical Analysis and Programming from
University of Dundee, UK in 1998. He received his B.Sc. Degree
[28] H. TAYLOR, The move to outsourced IT projects: in Computer Science from University Technology Malaysia in 1996.
key risks from the provider perspective. In SIGMIS He is currently working as associate professor in University Techni-
CPR ’05 Proceedings of the 2005 ACM SIGMIS cal Malaysia Malaka (UTeM) and as Research Manager at Centre for
CPR Conference on Computer Personnel Research, Advanced Computing Technology (C-ACT), Faculty of Information
and Communication Technology at Technical University of Malaysia
(2005), pp. 149–154. Malacca (UTeM). Also he worked as Deputy Dean (Research and Post
Graduate), of the Faculty of Information and Communication Technol-
[29] J. TAYLOR, Managing Information Technology ogy at Technical University of Malaysia Malacca (UTeM). His research
Projects: Applying Project Management Strategies interests are in data analysis, data mining, maintenance modelling, arti-
to Software, Hardware, and Integration Initiatives. ficial intelligence, risk management, numerical analysis, and computer
AMACOM2004,c 2004. network advisor and development.

[30] P. VASANT, Hybrid Mesh Adaptive Direct Search

Genetic Algorithms and Line Search Approaches
for Fuzzy Optimization Problems in Production
Planning. In Handbook of Optimization Intelligent
Systems Reference Library, 38, (I. ZELINKA, V.
SNÁŠEL, A. ABRAHAM, Eds.) (2013) pp. 779–799.
Berlin, Heidelberg: Springer Berlin Heidelberg.