A COMPARISON OF STEPWISE AND FUZZY MULTIPLE REGRESSION ANALYSIS TECHNIQUES FOR MANAGING SOFTWARE PROJECT RISKS: ANALYSIS PHASE

Risk is not always avoidable, but it is controllabl e. The aim of this study is to identify whether tho se techniques are effective in reducing software failu re. This motivates the authors to continue the effo rt to enrich the managing software project risks with con sider mining and quantitative approach with large d ata set. In this study, two new techniques are introduc e namely stepwise multiple regression analysis and fuzzy multiple regression to manage the software ri sks. Two evaluation procedures such as MMRE and Pred (25) is used to compare the accuracy of techni ques. The model’s accuracy slightly improves in stepwise multiple regression rather than fuzzy mult iple regression. This study will guide software man agers to apply software risk management practices with re al world software development organizations and ver ify the effectiveness of the new techniques and approac hes on a software project. The study has been condu te on a group of software project using survey questio nnaire. It is hope that this will enable software m anagers improve their decision to increase the probability of software project success.


INTRODUCTION
Despite much research and progress in the area of software project management, software development projects still fail to deliver acceptable systems on time and within budget. For some of these reasons corrective action is often complex to cost-justify or to implement efficiently in a software practice (Masticola, 2007). According to (Yassin, 2010), identifying the risks that facing software projects and reasons behind their failure has haunted project managers, software industry consultants and academician for a long time. Therefore, management is still unable to effectively manage the risks involved in these software projectsDue to the involvement of risk management in monitoring the success of a software project, analyzing potential risks and making decisions about what to do with potential risks, the risk management is considered the planned control of risk. In addition, risk is an uncertainty that can have a negative or positive effect on meeting project objectives. This study incorporates between risk management approach and software development life cycle to mitigate software failure. Risk management is the process of identifying, analyzing and controlling risk throughout the lifecycle of a software project to meet the software project objectives (Schwalbe, 2010). Clearly, the success or failure of software projects is generally assessed with dimensions such as budget, schedule and quality (Miler, 2005). In this study, we identify software risk factors and risk management techniques on a large Science Publications JCS set that are guided software project managers to mitigate risks in a software project. According to (Hoffer et al., 2011), Software Development Life Cycle (SDLC) is the process of creating and methodologies that can use to develop a software project which including phases as planning, analysis, design, implementation and maintenance. In addition, we focused on analysis phase: It includes looking at any existing system to see what it is doing for the organization and how well that system is doing its job. According to (Taylor, 2004), we should apply approaches and techniques consistently throughout the software risk management. Risk management is a practice of controlling risk such as processes, tools and methods for managing risks in a software project before the occuring of risks (Sodhi and Sodhi, 2001). Therefore, previous study had considered many aspect of risk management approach, including principles and practices for risk identification, risk analysis, risk prioritization and risk mitigation (Boehm, 2003).
The objective of this study is: Only identify software risk factors and risk management techniques in analysis phase is considered from various literatures, to rank the software risk factors and risk management techniques according to their importance, severity and occurrence frequency, later, the realtionship between the software risk factors and risk management techniques is develop using stepwise multiple regresion anlayis and fuzzy multiple regression analysis, the comparison between botth techniques is conducted using evaluation techniques such as MMRE and Pred (25).
The organization of this study as will be as follows. Section 2% an overview of the literature. Section 3 introduces the software risk factors (analysis phase) relevant to the study. Section 4 introduces the most common risk management techniques to these risks. Section 5% the empirical work. Section 6 concludes the article and glimpses on future work.

LITERATURE REVIEW
There is no structure way of managing software risk, project manager using their experience, opinion and self judgment to mitigate risk. Hence, techniques or model to mitigate software risks in software project is necessary. In the literature, many considered on mitigate risk by qualittive and quantitative technques, but rarely combine between software development life cycle and risk mannagement based on quantitative and mining techniques to mitigate software risks. In addition, a few authors combine between software risk factors and risk management techniques to reduce riks in SDLC. However (Khanfar et al., 2008), used chisquare (χ2) to mitigate risks in a software project by using control factors. And proposed new techniques the regression test and effect size test to manage the risks in a software project (Elzamly and Hussin, 2011a). Furthermore, the new stepwise regression technique used to manage the risks in a software project (Elzamly and Hussin, 2013a). Indeed, the multiple regression analysis techniques with fuzzy concepts is used to mitiagte the risks in a software project in design phase (Elzamly and Hussin, 2013b). In addition, they proposed Techno-Portfolio Advisor to helps the investors to understand the critical relations and support mutual funds selection during the Asset Management Companies in India. Further the new mining technique that uses the fuzzy regression analysis modelling techniques to manage the risks in a software planning development project. Top ten software risk factors in planning phase and thirty risk management techniques were presented to respondents (Elzamly and Hussin, 2014b). However, Oracle corporation described risk management solutions enable a standardized approach for identifying risk, assessing risk and mitigating risk throughout the software project lifecycle (Oracle, 2010). Previous studies had shown that risk mitigation in software project can be classified by 3 categories such as qualitative, quantitative and mining approaches. Quantitative risk is based on statistical methods that deal with accurate measurement about risk or leading to quantitative inputs, that helped forming a regression model to understand how software project risk factors influence project success (Bhoola et al., 2014) such as network analysis and regression models and other objective approach, but qualitative risk techniques lead to subjective opinions expressed or self judgment by software manager (Bhoola et al., 2014) such as scenario, Delphi analysis, brainstorming session and other subjective approach to mitigate risks. Mining approach is a new way of identifying risk from data that create relationships between data and find the optimum result from them. This includes techniques such as simulation analysis, fuzzy logic models, fuzzy multiple regression, neural network models, genetic algorithm and heuristic algorithm. The goal of mining and statistic techniques is predicted to select the best model based on modelling and their prediction accuracy to mitigate risks. The new framework software risk management methodology proposed for successful software project that including 5 phases such as

JCS
identification risk, risk analysis and evaluation, risk treatment, risk controlling, risk communication and documentation for software development life cycle which relied on three categories techniques as qualitative analysis, quantitative analysis and mining analysis to meet the goals (Elzamly and Hussin, 2014a).

TOP 10 SOFTWARE RISK FACTORS (ANALYSIS PHASE)
We display the top ten software risk factors in software development lifecycle (analysis phase) that common in the literature review. We present 'top-ten' based on (Boehm, 1991;Miler, 2005), etc. The 'Top 10 software risk factors' lists differ to some extent from author to author, but some essential software risk factors that appear almost on any list can be distinguished. These factors need to be addressed and thereafter need to be controlled. The list consists of the 10 most serious risks of a software project ranked from one to ten, each risk's status and the plan for addressing each software risk. In this section the top software risk associated with analysis phase is discussed. In addition, the software risk factors (analysis phase) listed below in Table 1 are considered in this study.

Risk 02: Failure to Incomplete or Missing Detailed Requirements Analysis and Specification Documentation
This risk is referred to incomplete or missing detailed requirements as terminations from this source are more likely to come from mismanaged software projects as reported by (Boehm, 2001;CHAOS, 1995;Chen and Huang, 2009;Elzamly and Hussin, 2011a;2011b;Khanfar et al., 2008;Maglyas, 2009;Sumner, 2000). In the missing detailed requirements analysis, the attributes are unverified through inadequate measuring. Indeed, missing detailed requirements analaysis will lead unvaluable input for measuring the resources required to develop the software development lifecycle (Galorath, 2006;Keil et al., 1998).

Risk 03: Developer Software Gold-Plating
According to (Boehm, 1991;Dash and Dash, 2010;Elzamly and Hussin, 2011a;Khanfar et al., 2008;Maglyas, 2009;Sodhi and Sodhi, 2001;Surie, 2004), reported that developer when taking work on a software project put an extra effort and put value in it Therefore, it focused as a bad software project management practices, techniques and methods as this approach give to extra adding unnecessary features occur to software project because of professional interest or user's demands (Horine, 2009;Ropponen and Lyytinen, 2000). Furthermore, developer software gold plating can result in wasting resources on implementing functionality that is not of real value or that's never actually used (Westfall, 2006). This would introduce new quality risks into the software project but to do nothing to improve the actual deliverable quality, yet they can require additional time and costs (Fairley, 2009;Horine, 2009).

Risk 06: Inadequate Knowledge about Tools and Programming Techniques
According to (Aloini et al., 2007), the inadequate use of tools for software project. In addition, lack of tools and methods in software programming is also abig contributor to software risk (Bennatan, 2006;Chen and Huang, 2009;Elzamly and Hussin, 2011b;Ewusi-Mensah, 2003;Nakatsu and Iacovou, 2009;Pandian, 2006). Thus, adequate knowledge about tools and techniques of software project may lead to better practices for software development lifecyle.

Risk 07: Lack of Traceability, Confidentiality, Correctness and Inspection of the Software Project Analysis
Addison (2003) reported that insufficient procedures to ensure transaction traceability, confidentiality and correctness is the most common risk in analysis stage. In addition (Aritua et al., 2011;Chen and Huang, 2009;Elzamly and Hussin, 2011b;Kontio, 2001) also referred to lack of traceability such as difficult to trace back to design specifications and user requirements as another changlleges. Traceability establishes logical links between two work process stated by (Fairley, 2009). Therefore, the lack of traceability between requirements and tests will resulted in unfocused or incomplete testing (Sodhi and Sodhi, 2001).

Risk 08: Major Requirements Change after Software Project Plan Phase
This risk relates to uncontrolled software requirements and inconsistency of software requirement, with plan phase as reported by (Boehm, 1991;Elzamly and Hussin, 2011b;Fairley, 2009;Ewusi-Mensah, 2003;Sodhi and Sodhi, 2001). Consequently, it may be lead to slow the progress to date and delays the objectives for the next.

JCS
corrected when necessary, by means of either a change or a revision (Grady, 2010). This will lead to request bout new functionality and need to rewrite the specification many times during software project lifecycle (Maglyas, 2009). As aconsequences will change specifications unimproved consistency, increase development time and limitatation of available implementation technology (Schulmeyer, 2008).

Risk 10: Inadequate Value Analysis to
Measure Progress Accordingly (Aloini et al., 2007;Elzamly and Hussin, 2011b;Jones, 2009;Ewusi-Mensah, 2003;Pandian, 2006), measurement is needed to measure software project progress. It is reported by (Han and Huang, 2007;Huang and Han, 2008), if a software project progress not monitored closely enough. It may lead to software failure.

RISK MANAGEMENT TECHNIQUES
Through reading the existing literature on software risk management, we listed the most common thirty risk management techniques that are considered important in mitigating the software risk factors (analysis phase) identified; these controls are:

C1: Using of Requirements Scrubbing
Requirements scrubbing is a best practice for software projects in which a product specification is carefully examined for unnecessary or overly complex requirements, which are then removed (Boehm and Ross, 1989;Boehm, 1991;McConnell, 1996). This is believed the reasons as the process of reviewing each requirement in detailed absolutely necessary for the upcoming release and it can dramatically increase the chances of delivering software project on-time and within budget (Fairley, 2009;Miller, 2004).

C2: Stabilizing Requirements and Specifications as Early as Possible
The key to stabilizing requirements is through a partnership developed in software projects. Therefore, the functional manager plays vital role in transferring business knowledge to the software project team and participating in the process design and the requirements that support the process design (Ferraro, 2012). Many software projects are faced with uncertainty when software requirements are first stated (Addison and Vallabh, 2002). However, they referred to stabilize requirements and specifications as early as possible as a control factor (Khanfar et al., 2008).

C3: Assessing Cost and Scheduling the Impact of Each Change to Requirements and Specifications
According to (Na et al., 2007;Ropponen and Lyytinen, 2000), they found that risk is positively related to both cost and schedule overruns. Hence, estimating cost and software project schedule impact is important to mitigate risk requirements and spicifications and the successful software development (Jones, 2008;Kamaruddin, 2006;Linberg, 1999).

C4: Develop Prototyping and have the Requirements Reviewed by the Client
Software prototype is a rapid software development for validating the requirements and help software team to understand the sofwtare (Puntambekar, 2009). It is a software model that created to represent a user interface or a function for the purpose of better understanding the requirements and the feasibility of the proposed solution (Tsui, 2004). In aaddition, it is clear that building early prototypes can help coin out some changes software development lifecycle (Boehm, 1991). This is reported by (McConnell, 1996;Savolainen et al., 2012), as prototpying can reduce requirements creep and can be combined with other approaches (McConnell, 1996;Savolainen et al., 2012). Furthermore, prototyping approach can used to mitigate risk issues as user interfaces, software/system interaction, or software performance (Boehm et al., 1995;Surie, 2004).

C5: Developing and Adhering a Software Project Plan
Some authors reported that developing and adhering a software project plan to deliver software project within the budget and on the schedule (Addison and Vallabh, 2002;Dufner et al., 1999). Software project planning should be allocated to each of these sofwtare phases to manage and reduce potential occering failure (Cantor, 1998;Westfall, 2001). In addition, he proposed application of software planning techniques to manage the multiple problems and the complexity associated with software planning (Anantatmula, 2010). A risk management plan techniques will lead to mitigate the potential occurring risks and the overall impact of risks in software project (Westfall, 2001). Finally, they referred to need for planning approach to mitiagite mutilple risk in software project (Chapman and Thomas, 2007).

C6: Implementing and Following a Communication Plan
Communication plan is crucial for monitoring progress (Sarfraz, 2009) as each individual should feel comfortable to provide inputs on raised problems. Progress information should be shared with all concerned during or at the completion of each task before moving forward to the next. Risk management communication planning techniques implemented to be a continuous feedback loop through extra information risk and developed (Westfall, 2001).

C7: Developing Contingency Plans to Cope with Staffing Problems
Developing contingency actions that able to be taken if the software project turns into a risk failure (Addison and Vallabh, 2002;Westfall, 2001). Furthermore (RM: GBP, 2003), contingency plans are developed as a result of a risk failure being identified and pre-defined action plans that able to be implement if identified risks occur really. Creating risk contingency plans is risk mitigation for the facility or group of facilities to be reduced risks (Chapman and Thomas, 2007).

C8: Assigning Responsibilities to Team Members and Rotate Jobs
Assigning clear responsibilities and roles for the members of the risk response team that contribute developing software project in software development lifecycle and to meet immediately with various aspects of disaster response, assessment and recovery (Addison and Vallabh, 2002;Grabski et al., 2001). It is importanat to assign the responsibilities clearly for the appropriate performing organizations in the early stage with lead (Schulmeyer, 2008). It is also sometimes better to rotate developers and leaders the sections of the software project development to gain a variety of experiences (Lientz and Larssen, 2006;Sodhi and Sodhi, 2001). The software project team member's roles and responsibilities have been well established to identify and address issues (Cantor, 1998).

C9: Have Team-Building Sessions
Clearly, when team building sessions were conducted by the software project manager throughout the entire software project lifecycle it contribute to software project success that reportected by (Boehm, 1991;Holcombe, 2008;Jianga et al., 2002;Tomczyk, 2005).

C10: Reviewing and Communicating Progress to Date and Setting Objectives for the Next Phase
The team manager need to review the progress in all phases such as number of units designed, reused, tested and integrated module that reported by (Kouskouras and Georgiou, 2007;Ma et al., 2009;Munch and Heidrich, 2004;Sarfraz, 2009;Sodhi and Sodhi, 2001;Tayntor, 2006).

C11: Dividing the Software Project into Controllable Portions
A software project manager need to break large software project into incremental small work elements to mitigate software project risks (Addison and Vallabh, 2002). According to (SPM: MT, 2004), the methodology describes how a software project is divided into manageable stages enabling efficient control of resources and regular progress monitoring throughout the software development lifecycle.

C12: Reusable Source Code and Interface Methods
According to (Jones, 2008;Sodhi and Sodhi, 2001), reusable source code and interface methods will impacted many new tools and programming languages such as Java and Object-Oriented (OO) languages. Thus, reusable source code and interface method is useful to mitigate risk (Galorath and Evans, 2006).

C13: Reusable Test Plans and Test Cases
A pre-release defect can be found in any of the software project (Emam, 2005;Jones, 2008). Hence, reusable test plans and cases would speed up the process of creating testability of test plans and allow an easier test case generation (Kasurinen et al., 2010).

C14: Reusable Database and Data Mining Structures
According to (Jones, 2008), reusable database structures and data mining tools greatly improve the ability of the analyst to make data-driven discoveries, where most of the time spent in performing an analysis spent in data identification, gathering, cleaning and processing the data. This is similar to which proposed a method for generic and reusable text mining techniques in support of biological database (Miotto et al., 2005).

C15: Reusable user Documents Early
According to (Jones, 2008), referred to reusable user documents. In addition (Kanjanasanpetch and Igel,

JCS
2003), proposed that explicit part of knowledge could be captured in several forms such as user manual, training documents, process design documents and others. This will help software developers and used bind into a strandard communication a pproach (Shand, 1994).

C16: Implementing/Utilizing Automated Version Control Tools
According to (Cantor, 1998;Green, 2000), software developers need to have a version control systems for manage source code changes (Green, 2000). the version control tools are to able to track evolving versions of a project's work products and testing tools to aid in verifying the software (Fairley, 2009). Fairly also commented that automated version control is essential for establishing and maintaining the baselines of various work products in various stages of development.

C17: Implement/Uilize Benchmarking and Tools of Technical Analysis
According to (Hill, 2010), providing information and practical estimating techniques-primarily based on the International Software Benchmarking Standards Group will assist project managers with the task of estimating the three key variables that follow the establishment of software project requirements, namely: Size, effort and duration. In addition (Jones, 2008), explained benchmarking, or comparing software productivity, quality, schedules, salaries and methodologies, between companies was rare when the data for the first edition was assembled. Therefore, software benchmarking is continuing to expand in terms of the kinds of information collected and the number of companies that participate. Based on the ever-growing amount of solid data, the benchmarking is now a mainstream activity within the software world.

C18: Creating and Analyzing Process by Simulation and Modeling
Modeling and simulation of software development processes is gaining an increasing demand to reduce risks that focuses on a specific software development/maintenance/evolution process (Kouskouras and Georgiou, 2007;Surie, 2004). In addition (Jiang and Chen, 2004), described the process model simulation on risk occurrence probability do have an impact in software project. Furthermore, software processing simulation modeling (SPSM) has been emerging as a promising approach to address a variety of issues in software engineering area, including risk management ).

C19: Provide Scenarios Methods and Using of the Reference Checking
According to (Alhawari et al., 2008), described risk analysis phase by conducting scenarios for major risks and events to establishes a probability of losses for every risk scenario. However (Schmidt et al., 2001), suggested various methods for identifying software risk factors including scenarios. This will lead to allow more realistic plans and estimates to be prepared and identified risk (Azari et al., 2011;Smith et al., 2006).

C20: Involving Management During the Entire Software Project Lifecycle
The involvement of all members in software development team will reduce risk. This is because the nature of the work process and relations required more management involvement (Dyba and Dingsoyr, 2008;Lyons and Skitmore, 2004).

C21: Including Formal and Periodic Risk Assessment
According to (Webern et al., 2010), risk analysis is a models for quantifying and evaluating a critical event occurrence. This is include a process of identifying relevant information of resources (software risk factors), discovering their relationships and integrating them to form a risk assessment argument (Lee, 2011). Hence, a model-based assessment that covers the formal and periodic risk should facilitate communication between internal and external factors in software project (Aagedal et al., 2002).

C22: Utilizing Change Control Board and Exercise Quality Change Control Practices
Contingency funds were managed centrally by the project through change control board procedures (Strawbridge, 2005). Author like (Kandt, 2003) reported that requirements should be managed using a defined configuration management process that uses change control boards and automated change control tools that manage each requirement. Realy (Fairley, 2009;Horine, 2009;Hayat et al., 2010;IEEE, 2011;Kandt, 2003), can be defined Change Control Board as the minimum set of project stakeholders who need to review and approve any change request impacting the software project's critical success factors.

C23: Educating Users on the Impact of Changes During the Software Project
They integrated hardware/software approach is useful for educating users about software technology in software project is important to reduce risks (Persohn and Brylow, 2011). Software risk management is affected by several factors as well educated practitioners for usres (Islam, 2009).

C24: Ensuring that Quality-Factor Deliverables and Task Analysis
According to (Bavani, 2010;Tsui, 2004), ensuring high quality deliverables on schedule is important to mitigate risks in software project. Furthermore (Keil et al., 2008), provided guidance on how to select members of review teams that help assure the quality of software project deliverables.

C25: Avoiding Having too Many new Functions on Software Projects
Modern technical systems typically consist of multiple components and must provide many functions that are realized as a complex interaction of these components (Greenyer et al., 2012). It is said that too many functions has difficult human interfaces for beginners, thus needs to implement new functionality on an incremental rather than too many new function (Oda, 2011).

C26: Incremental Development (Deferring Changes to Later Increments)
Increment development is not based on a certain scope (requirement subset) but is instead based on a measure of effort for improvement (Brandon, 2006). Genarlly, stakeholders specify the requirements and evaluate the increment, thus, the change suggested in the current increment are implemented in the next increment (Puntambekar, 2009).

C27: Combining Internal Evaluations by External Reviews
Generally, the product will had internal evaluations by software project teams before delivering it to customers (Bavani, 2010). Moreover, reviewing and evaluating strengths and weaknesses from a reviewer is one of the external factors to mitigate risk. The objective of internal and external is In addition, the objectives of external and internal is to have the consistency of all elements in software (Peppen and Ploeg, 2000).

C28: Maintain Proper Documentation of Each Individual's Work
In the software industry, documented bi-directional traceability is needed needs to be maintained over the entire life cycle of the software project (Chen and Huang, 2009). In addition, it is reported that substantial percentage amount of software firm do not maintain documented procedure for after sales service (Begum et al., 2008). Overcome this issue can be treated with a control of the management process.

C29: Provide Training in the New Technology and Organize Domain Knowledge Training
According to (Fairley, 2009), organizational training: To develop skills and knowledge among workers can perform their jobs efficiently and effectively. Furthermore, training plans should be developed and implemented to ensure that all personnel that involved in service management initiatives are given the opportunity to develop their skills, knowledge and competences (Rudd, 2010).

C30: Participating Users During the Entire Software Project Lifecycle
According to (Dzung and Briod, 2005;Li et al., 2013), initiating user can be found from a group of users the one whose profile best matchesto limit the risk. This is because the set of participating users, hardware and software in ubiquitous computing environments is highly dynamic and unpredictable (Cahill et al., 2004). The authers like (Jin and Li, 2009) referred to participating users in the software development will enable more advantage during their communication with other user to specify the requirement.

EMPIRICAL STRATEGY
Data collection was achieved through the use of a structured questionnaire in estimating the quality of software. Top ten software risk factors and thirty control factors were presented to respondents. The method of sample selection referred to as 'snowball' and distribution personal regular sampling was used. This procedure is appropriate when members of homogeneous groups (such as software project managers, IT managers) are difficult to locate. The seventy six software project managers have participated in this study.
Respondents were presented with various questions, which used scales1-7. All questions in software risk factors were measured by a 7-point Likert scale from Science Publications JCS unimportant to extremely important and risk management techniques were measured by a seven-point scale from never to always. The data is collected from various to IT manager, software project managers from software organazitions in Palestine. In order to find the relation among risks and risk management techniques, we introduce stepwise multiple regression analysis, fuzzy multiple regression, later the evalaution techniques that the best way to measure error, compare acccuracy level in models such as MMRE and Pred (l).

Stepwise Regression (Adds and Removes Variables)
According to (Lan and Guo, 2008;Lin et al., 2012), stepwise regression method combines and alternates between forward selection and backward elimination. At each step, the best remaining variable is added, provided it passes the significant at 5% criterion, then all variables currently in the regression are checked to see if any can be removed. Also, the stepwise-multiple regression method that systematically adds and removes modal elements depend on statistical test to automatically identify the risks for a large scale data in operation (Zhou et al., 2012). Therefore (Lin et al., 2012), this technique is particularly useful when we need to predict a set of dependent variables from a large set of independent variables.

Regression Analysis Model with Fuzzy Concepts
Fuzzy multiple regression analysis is an extension of the traditional regression analysis in which some elements of the models are represented by fuzzy numbers (Dom et al., 2012). On the other words, fuzzy multiple regression analyis in that response variable is fuzzy variable and part of the covariates are crisp variables (Lin et al., 2012). However, identify the various data types that may appear in a questionnaire. Thus, we introduce the survey questionnaire data mining risk and define the rule patterns that can be mined from survey questionnaire data (Chen and Huang, 2009). Therefore, we must extend the crisp association rules to fuzzy association rules from questionnaire data.

Fuzzy Concepts with Membership Function
Fuzzy concepts help to find the deviation of each data from goodness equation, so we define a normal distribution membership function as follow (Marza and Seyyedi, 2009) Equation 1: Where: µ = Average of sample points and σ = Square root of variance math If we add fuzzy domain to regression technique, the effect of discrete data points on the goodness result will be reduced and the effect of concentrated data points on the fitness result will be enhanced. Indeed, a membership function is a curve that defines how each point in the input space is mapped to a membership value between 0 and 1 (Dom et al., 2012).

Evaluation Techniques Criteria
In order to validate the model with respect to its fitting accuracy, we use the Mean Magnitude of Relative Error (MMRE) and Pred (25%) (Sentas et al., 2003). A common criterion for measurement of software effort estimation model performance (Kumar et al., 2011), which is calculated for each observation, is the Magnitude of Relative Error (MRE) that the absolute value of the relative error (Alyahya et al., 2009;Marza and Seyyedi, 2009) We evaluated the impact of estimation accuracy by using (MRE, MMRE) evaluation criteria, for each model.
The Mean Magnitude of Relative Error (MMRE) is the average of all magnitudes of relative errors. Pred (25%) is the percentage of software projects with an MRE of 25% or less (Sentas et al., 2003). Therefore, with aggregation of MRE of all data set, the Mean Magnitude of Relative Error (MMRE) is achieved with the equation below Equation 5: Therefore, we used Pred (25) or more than according to the Equation 6: To explain parameters k is the number of observations, where MRE is less than or equal to l, for example, Pred (25) gives the percentage of projects which were predicted with a counting the number of MRE less or equal than 0.25 and dividing by the number of projects (Alyahya et al., 2009). However, the accuracy of an estimation technique is proportional to Pred (25), Pred (25) and inversely proportional to the MMRE (Marza and Seyyedi, 2009;Martin et al., 2005). According to (Stensrud, 2003), MMRE is used for two kinds of assessments (at least). MMRE is to select between competing prediction models and to provide a quantitative measure of the uncertainty of a prediction. Table 2 illustrates all respondents indicated that the risk of "developer software gold-plating" was the highest software risk factors and very important. In fact, the software risk factors in the analysis phase from risk number 3, 4, 5, 6, 1, 8, 2 were identified as very important, the software risk factors from risk number 9, 7, 10 in descending means were identified as important. Table 3 shows the mean and the standard deviation for risk management techniques. The results of this study show that the risk management techniques are used most of time and often.

Frequency of Occurrence of Controls
3.868 0.754 77.36842

Relationships between Risks and Risk Management Techniques
Regression technique was performed on the data to determine whether there were significant relationships between risk management techniques and software risk factors in anlaysis phase. These tests were performed using fuzzy multiple regression analysis and stepwise multiple regression analysis, to compare the risk management techniques to each of the software risk factors to identiiy if they are effective in reducing the occurrence of each software risk factor. Relationships between software risks and controls, which were significant and insignificant, any control is no significant. Table 4 illustrates an evaluation between stepwise multiple regression and fuzzy multiple regression by using MMRE and Pred (l) that comparing among various software project risk models. Thus, the model's accuracy slightly improves in stepwise multiple regression than fuzzy multiple regression.  objectives for the next phase, C7: Developing contingency plans to cope with staffing problems. Changing software project specifications. C21: Including formal and periodic risk assessment, Involving management during the entire software project lifecycle, C3: Assessing cost and scheduling the impact of each change to requirements and specifications. Inadequate value analysis to measure progress.

JCS
C23: Educating users on the impact of changes during the software project, C20: Involving management during the entire software project lifecycle.

JCS
Also, all models in stepwise and fuzzy acceptable value for MMRE less than 0.25 and Pred(0.25) greater than 0.75 is desirable (Basha and Ponnurangam, 2010). This be explained by the non-deterministic (fuzzy) nature or fuzzy regression. If the problem at hand, involves non-determinstic (fuzzy) variable (fuzzy regression) is recommended which supports the need to use hybrid models in future research as proposed by (Martin et al., 2005). Table 5 shows software risk factors identification checklist with risk management techniques based on a questionnaire of experienced software project managers. He can use the checklist on software projects to identify and mitigate software risk factors on lifecycle software projects by using risk management techniques.

CONCLUSION
The concern of this study is the managing risks of software projects. The results show that all risks in software projects were very important and important in software project manager's perspective, whereas all controls are used most of time and often. These tests were performed using stepwise multiple regression analysis, fuzzy multiple regression analysis techniques proposed, to compare the controls to each of the software risk factors to identify if they are effective in mitigating the occurrence of each software risk factor. However, we referred the risk management techniques were mitigated on software risk factors in Table 5. Through the results, we found out that some control haven't impacted, so the important controls should be considered by the software development companies in Palestinian. Table 4 illustrates after applying MRE, the results show that the most value of MMRE in fuzzy multiple regression model were slightly higher than or equal stepwise multiple regression except risk 6, 9, 10 models. Therefore, the most value of Pred (25) stepwise multiple regression for software risks were slightly higher than or equal the fuzzy multiple regression model value of Pred (25) except 2, 6, 10. The model's accuracy slightly improves in stepwise multiple regression rather than fuzzy multiple regression. However, all models in stepwise and fuzzy acceptable value for MMRE less than 0.25 and Pred (0.25) greater than 0.75 is desirable.
In addition, We cannot obtain historical data from database by using some techniques. Therefore, some of software project managers didn't give us a historical template to follow up software risks. In addition , there is no software clearly to compute the fuzzy regression analysis and combine between linear and nonlinear technique. Unfortunately, there is no software included mining and statistical techniques to mitigate risks in a software project.
As future work, we will intend to apply these study results on a real-world software project to verify the effectiveness of the new techniques and approach on a software project. Likewise, we can use other nonlinear techniques to find the relation between software risk and risk management techniques that we believe can contain better result. Also, we could hybridize the techniques with other artificial intelligence approach to improve the models.

ACKNOWLEDGEMENT
This study is supported by Faculty of Information and Communication Technology, Universiti Teknikal Malaysia Melaka (UTeM) and Al-Aqsa University, Gaza, Palestine.