Managing and Controlling Design Process Issues by Using Stepwise Approach Modelling

The objective of study is to introduce stepwise regression approach modelling to mitigate and manage the software design process issues in software project by using proposed controls. In addition, the software design process issues were controlled and modelled by using stepwise regression approach except risk 3. Furthermore, we illustrated the design process issues were mitigated by control techniques in Table 40. However, we need to combine more techniques and artificial optimal algorithms to mitigate the issues in software design process.


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.In addition, risk is an uncertainty that can have a negative or positive effect on meeting project objectives.Risk management is the process of identifying, analyzing and controlling risk throughout the life of a project to meet the project objectives (Schwalbe, 2010).However, Software Development Lifecycle is the processes of creating and risk control techniques are used to mitigate issues it should involve in all phases include: Planning, analysis, design, implementation and maintenance.In addition, we focused on Design phase (Hoffer et al., 2011): It involves the actual creation and design of a system.This involves putting together the different pieces that will create the system.Techniques and models for mitigating risk in software development projects classified into three categories-namely, qualitative, quantitative and intelligent approaches (Elzamly and Hussin, 2015b).The objective of this study is: To identify issues in the software design process in the Palestinian software development organizations, to manage and mitigate the software design issue factors by using quantitative approach techniques.

LITERATURE REVIEW
We improved quality of software projects of the participating companies while estimating the quality-affecting risks in IT software projects.The results show that there were 40 common risks in software projects of IT companies in Palestine.The amount of technical and non-technical difficulties was very large (Elzamly and Hussin, 2011a).However, we presented the chi-square (χ 2 ) test to control the risks in a software project.Fourteen risk factors and eighteen control factors were used (Khanfar et al., 2008).Further, we present new mining technique that uses the fuzzy regression analysis modelling techniques to manage the risks in a software development project.Top ten software risk factors in planning phase and thirty risk management techniques were presented to respondents (Elzamly and Hussin, 2014b).Therefore, regression test (simultaneous selection procedure) and effect size test proposed to managing the risks in a software project and reducing risk with software process improvement (Elzamly and Hussin, 2011b).Generally, to manage software risk we need to know the software risk factors and control factors.Stepwise Regression analysis is used to compare to compare the controls to each of the risk factors in implementation phase to determine if they are effective in mitigating the occurrence of each risk (Elzamly and Hussin, 2013a).In addition, we presented a new mining technique that introduced the fuzzy multiple regression analysis to manage the risks in a software development project in the maintenance phase (Elzamly and Hussin, 2014c).Finally, risk management methodology that has five phases: Risk identification (planning, identification, prioritization), risk analysis and evaluation (risk analysis, risk evaluation), risk treatment, risk controlling, risk communication and documentation these relied on three categories techniques as risk qualitative analysis, risk quantitative analysis and risk mining analysis throughout the life of a software project to meet the goals (Elzamly et al., 2015a;Elzamly and Hussin, 2014a).

TOP 10 SOFTWARE DESIGN PROCESS ISSUE FACTORS
Indeed, we classify the top ten software design process issue factors in SDLC and thereafter these issues need to be mitigated and controlled, these issues were explain in this section and Table 1 below: Risk 01: Introduction of new technology: New technology is always regarded as required technology in a software project reported by Addison (2003), Boehm (1991Boehm ( , 2007)), Han and Huang (2007), Ewusi-Mensah (2003), Nakatsu and Iacovou (2009) and Surie (2004).Introduction of new technology usually bring about a number of training needs.This technology may be used operationally in processes that involve packaging, quality testing, money transaction and other (Buckley and Caple, 2009;Ewusi-Mensah, 2003).As a result software project that applied poor technology investments will have a high risk to dealing with software project complexity and competitiveness (Bennatan, 2006;Han and Huang, 2007;Huang and Han, 2008;Pandian, 2007).
Risk 02: Developing the wrong software functions and properties: There are possibilities of developing wrong software functions and properties in software project (Addison and Vallabh, 2002;Boehm, 1991;Dash and Dash, 2010;Selby, 2007).Functionality risk is defined as the software risk factors in a completed system that does not meet users' expectations or a development of software functions that are not needed or are wrongly specified (Kaur and Malhotra, 2013).Developing the wrong software function will lead to problems such as incorrect operation of the software, unexpected results, increase in maintenance for taking corrective actions, user dissatisfaction, overhead of rework, product rejection which adversely affects developer reputation and that lead the software project to the failure (Kaur and Malhotra, 2013).
Risk 03: Developing the wrong user interface: There are circumstances when wrong user interfaces are developed in software projects (Boehm, 1991(Boehm, , 2007;;Dash and Dash, 2010;Sodhi and Sodhi, 2001;Surie, 2004).Although software projects did an adequate job software functionality, but they created every unfriendly user interface (Selby, 2007).As a result of unclear user interfaces unclear; software projects are not able to specify the planning of the human interface including screen formats, contents of menus and command structure (Jalote, 2008).
Risk 04: Insufficient procedures to ensure security, integrity and availability of the database: According to Addison (2003), Aritua et al. (2011), Ewusi-Mensah (2003), Nakatsu and Iacovou (2009) and Sumner (2000), insufficient procedures to ensure security, integrity and availability of the database is also related to major risks in a software project.Generally, insufficient attributes of software project requirements in database that include reliability, integrity, availability, security, maintainability and portability (Laplante, 2004) result in a loss of data and low quality factors to deliver the software within the stipulated date (Addison, 2003).

9
Lack of effective software project team integration between clients, the supplier team and the supply chain (Cliff Mitchell, 2011).
1 10 Misalignment of software project with local practices and processes (Aloini et al., 2007). 1 Total frequency 32 among software managers will lead to the integrated components that are incorrect, incomplete and inconsistent with their intended propose (Fairley, 2009).
Risk 06: Lack of architecture and performance software project: Certainly, poor software structures will lead to software failure as reported by Pandian (2007), Aritua et al. (2011), Ewusi-Mensah (2003) and Boehm (2007).This is even worst where process performance process performance data model to understand the organization's standard of processes (Fairley, 2009).With that matters process of each component is incomplete, incorrect and inconsistent with respect to the architectural design, iterative development processes that support incremental implementation, verification and validation of software need to be built (Fairley, 2009).
Risk 07: Absence of quality architectural and design documents: Besides, lack of reusable documentation, inadequate system documentation is another factor to be taken into consideration (Aloini et al., 2007;Chen et al., 2009;Khanfar et al., 2008;Pandian, 2007).Architectural design of the software is concerned with specifying the major software components and interfaces, their interrelationships and their connections to the environment of the software project (Fairley, 2009).Therefore, it is also important to recognize the lack of a well-designed and documented process as a characteristic of the initial level of maturity (Ahmed, 2011).
Risk 08: Failure to redesign and design (blueprints) software processes: Aloini et al. (2007), Nakatsu and Iacovou (2009), Pandian (2007) and Sumner (2000) reported that lack of the designs risk (blueprints) of software process is another factor of software risk.Thus, any major redesign in the product's architecture which is not reflected by the blueprint lacks communication (Thomas and Uwe, 2010).
Risk 09: Lack of effective software project team integration between clients, the supplier team and the supply chain: According to Cliff Mitchell (2011) and Schmidt et al. (2001), lack of effective software project team integration between clients, the supplier team and the supply chain is critical in the software project.House of Commons ( 2009) reported that the software project always selected suppliers as the main delivery partners and did not seek a wider evaluation of their requirements from the market.Without good communication (House of Commons, 2009), this will lead to failure in the delivery of the software project on time and within budgets thus resulting in bad practices.
Risk 10: Misalignment of software project with local practices and processes: Paré et al. (2008) reported that misalignment of software project with local practices and processes might lead to a software failure (Paré et al., 2008).For example, Aloini et al. (2007) and Yogesan et al. (2009), pontificate that aligning new systems with local work practices but due to the lack of consistencies between the new system and local work practices may result in processes that are less promising (Yogesan et al., 2009).

RISK MANAGEMENT TECHNIQUES
We listed thirty risk controls that are considered important in minimizing the software issue factors in design process identified; these risk controls are (Elzamly and Hussin, 2015b;Elzamly et al., 2015b;Elzamly and Hussin, 2014a, 2014b, 2014d, 2014f, 2015a): The literature review revealed the following question: Do experienced project managers control software project risk factors in design phase by using the controls identified in this study?To answer this question, the following objectives for the empirical work have been set forth: Identify the software design risk factors of software projects in the Palestinian software development organizations, to rank the software design risk factors according to their importance, severity and occurrence frequency based on data source, to identify the activities performed by software project managers to manage the software design project risks which identified.

EMPIRICAL STRATEGY (RESULTS AND DISCUSSION)
We collected data by using questionnaire and historical data for mitigating issues in software project.In addition, snowball and distribution personal methods are used to select sampling and then survey questionnaire were distributed to 76 software project managers in Palestinian software development organizations.In this study, we used correlation analysis, regression analysis models based on stepwise selection method and Durbin-Watson Statistic by using IBM SPSS statistics for manipulating and analyzing the data set.
Modelling software design process issues by controls variables: These tests were performed using stepwise modelling analysis, to mitigate software design process issues by controls.2 to 5 show that the significant value is less than the assumed value at α = 0.05 level of significance, so there was a positive relation between controls 1, 2, 3,4,5,6,7,8,9,10,11,15,23 and risk 1.Any risk management techniques (controls) were no significant and thus were not reported.However, for model 1 it was goodness to predict risk 1 (the dependent variable) from independent variables such as control 3.In addition, control 3 had an impact on risk 1.In addition, the results showed that control 3 had a positive impact value of 0.513 and the value of R 2 is 0.264.This was interpreted as a percentage of 26.4 % from the dependent variable of risk 1.Therefore, there was no multicollinearity when collinearity diagnosis (Tolerance test and VIF test) were used.Furthermore, the Durbin-Watson statistic (D) was 1.986 and (d U = 1.652, d L = 1.598) based on K = 1, N = 76, at α = 0.05; there is no autocorrelation based on the rule (d U < D < 2+d L : No autocorrelation).

R2: Risk of 'developing the wrong software functions and properties' compared to controls:
Table 6 to 9 show that the significant value is less than the assumed value at α = 0.05 level of significance.Therefore, there was a positive relation between controls 4, 19, 28 and risk 2. Any risk management techniques (controls) were no significant and thus were not reported.However, for model 1 it was goodness to predict risk 2 (the dependent variable) from independent variables such as control 4. In addition, control 4 has an impact on risk 2. Besides, the results showed that control 4 had positive impact value of 0.276 and the value of R 2 was 0.076.This was interpreted as a percentage of 7.6 % from the dependent variable of risk 2. Therefore, there was no multicollinearity when collinearity diagnosis (Tolerance test and VIF test) were used.Furthermore, the Durbin-Watson statistic (D) was 1.876 and (d U = 1.652, d L = 1.598) based on K = 1, N = 76, at α = 0.05.Thus, there is evidence of no autocorrelation based on the rule (d U < D < 2+d L : No autocorrelation).
R3: Risk of 'developing the wrong user interface' compared to controls: Table 10 and 11 show that the significant value is greater than the assumed value of α = 0.05 level of significance, this implies that is no relation between all controls and risk 3 and controls that do not have a relation (no significant) were not reported.In addition, we found the model is to be unfit.

R4: Risk of 'Insufficient Procedures to Ensure Security, Integrity and Availability of The Database'
Compared to Controls: Table 12 to 15 show that the significant value is less than the assumed value at α = 0.05 level of significance.Thus, there was a positive relation between controls 2,4,8,9,10,19,23,24,25,26,28 and risk 4. In addition, controls 19 and 24 have an impact on the risk 24.Any risk management techniques were no significant and thus were not reported.However, it was goodness that model 2 is used to predict a risk 24 (the dependent variable) from independent variables such as controls 19, 24.In addition, the results showed that control 19 and 24 had a positive impact value of 0.335 and 0.273 respectively.Thus, the multiple correlation value was 0.403 and the value of R 2 was 0.162.This was interpreted as a percentage of 16.2 % from the dependent variable of risk 24.Therefore, there was no multicollinearity when collinearity diagnosis (Tolerance test and VIF test) were used.Furthermore, the Durbin-Watson statistic (D) was 2.106 and (d u = 1.680, d L = 1.571) based on K=2, N = 76, at α = 0.05; there is evidence of no autocorrelation (d U < D < 2+d L : No autocorrelation).

R6: Risk of 'lack of architecture, performance and quality software project' compared to controls:
Table 20 to 23 show that the significant value is less than the assumed value at α = 0.05 level of significance, so there was a positive relation between controls 1, 2, 3,4,10,11,23,24,26,28,29,30 and risk 6.Any risk management techniques (controls) were no significant and thus were not reported.However, the goodness of model 2 is that it was able to predict risk 26 (the dependent variable) from independent variables such as controls 26 and 30.Controls 26 and 30 had an impact on risk 6.In addition, the results showed that controls 26 and 30 have a positive impact value of 0.420 and 0.358 respectively.Thus, the multiple correlation value was 0.474 and the value of R 2 was 0.225.This was interpreted as a percentage of 22.5 % from the dependent variable of risk 6.Therefore, there is not multicollinearity by using collinearity diagnosis in Tolerance test and VIF test.Furthermore, the Durbin-Watson statistic (D) was 2.211 and (d U = 1.680, d L = 1.571) based on K = 2, N = 76, at α = 0.05; there was no evidence of autocorrelation (d U < D < 2+d L : No autocorrelation).R7: Risk of 'absence of quality architectural and design documents' compared to controls: Table 24 to 27 show that the significant value is less than the assumed value at where α = 0.05 level of significance, so there was a positive relation between controls 1, 2, 7, 10, 24, 26 and risk 7. Any risk management techniques (controls) were no significant and thus were not reported.However, the model 1 was good to predict risk 7 (the dependent variable) from independent variables such as controls 2, 15.Controls 2 and 15 had an impact on the risk 7.In addition, the results showed that the multiple correlation value was 0.418 and the value of R 2 was 0.175.This was interpreted as a percentage of 17.5 % from the dependent variable of risk 7. Thus, the use of collinearity diagnosis did not reveal multicollinearity.Furthermore, the Durbin-Watson statistic (D) was 2.029 and (d U = 1.680, d L = 1.571) based on K = 2, N = 76, at α = 0.05; thus, there is no evidence of autocorrelation (d U <D< 2+d L : No autocorrelation).

R8: Risk of 'failure to design (blueprints) and redesign software processes' compared to controls:
Table 28 to 31 show that the significant value is less than the assumed value at where α = 0.05 level of significance, so there was a positive relation between controls 2, 3,4,9,10,20,21,24,27,28,29 and risk 8. Any risk management techniques (controls) were no significant and thus were not reported.However, model 4 was good to predict risk 8 (the dependent variable) from independent variables such as    controls 29, 4, 24, 5. Controls 4, 5, 24 and 29 had an impact on risk 8.In addition, the multiple correlation value was 0.570 and the value of R 2 was 0.325.This was interpreted as a percentage of 32.5 % from the dependent variable of risk 8. Therefore, there was no multicollinearity shown in the use of collinearity diagnosis (Tolerance test and VIF test).Furthermore, the Durbin-Watson statistic (D) was 1.765 and (d U = 1.515, d L = 1.739) based on K = 4, N = 76, at α = 0.05; thus stating there was no evidence of autocorrelation (d U < D < 2+d L : No autocorrelation).
R9: Risk of 'lack of effective software project team integration between clients, the supplier team and the supply chain' compared to controls: Table 32 to 35 show that the significant value is less than the assumed value at α = 0.05 level of significance, so there was a positive relation between controls 4, 16, 19, 20, 24, 25, 26, 27, 28, 29, 30 and risk 9. Any risk management techniques (controls) were no significant and thus were not reported.However, it was good that model 1 was able to predict risk 9 (the dependent variable) from independent variables such as controls 24, 4, 1, 27. Controls 4, 24 and 27 had an impact on risk 29.In addition, the multiple correlation value was 0.526 and the value of R 2 was 0.277.This was interpreted as a percentage of 27.7 % from the dependent variable of risk 29.Therefore, there was no multicollinearity   36 to 39 show that the significant value is less than the assumed value whereby α = 0.05 level of significance, so there was a positive relation between control 3, 13, 14 and risk 10.As none of risk management techniques (controls) were significant, they were not reported.However, it was good that model 3 could predict a risk 10 (the dependent variable) from independent variables such as controls 13, 3, 8. Controls 3 and 13 had an impact on risk 30.In addition, the results showed that the multiple correlation value was 0.451 and the value of R 2 was 0.203.This was interpreted as a percentage of 20.3% from the dependent variable of risk 10.Therefore, there was no multicollinearity shown in the use of collinearity

Software design risk factors identification checklists and control factors (risk management techniques):
Table 40 shows software design process issue Factors identification checklist with risk controls based on a questionnaire of experienced software project managers.He can use the checklist on software projects to identify and mitigate software design risk factors on life cycle software projects by risk management techniques.

CONCLUSION
The concern of this study is the mitigating software design process issues by using approach modelling.Indeed, we referred to the positive relation between software issues and controls.Furthermore, we listed the issues that were controlled by using stepwise approach in Table 40.In the future work, we need to use more techniques and artificial optimal algorithms to mitigate and manage the issues in software projects in the real world like fuzzy logic and genetic algorithm, etc.

:
Using of requirements scrubbing C2 : Stabilizing requirements and specifications as early as possible C3 : Assessing cost and scheduling the impact of each change to requirements and specifications C4 : Develop prototyping and have the requirements reviewed by the client C5 : Developing and adhering a software project plan C6 : Implementing and following a communication plan C7 : Developing contingency plans to cope with staffing problems C8 : Assigning responsibilities to team members and rotate jobs C9 : Have team-building sessions C10 : Reviewing and communicating progress to date and setting objectives for the next phase C11 : Dividing the software project into controllable portions C12 : Reusable source code and interface methods C13 : Reusable test plans and test cases C14 : Reusable database and data mining structures C15 : Reusable user documents early C16 : Implementing/Utilizing automated version control tools C17 : Implement/utilize benchmarking and tools of technical analysis C18 : Creating and analyzing process by simulation and modeling C19 : Provide scenarios methods and using of the reference checking C20 : Involving management during the entire software project lifecycle C21 : Including formal and periodic risk assessment C22 : Utilizing change control board and exercise quality change control practices C23 : Educating users on the impact of changes during the software project C24 : Ensuring that quality-factor deliverables and task analysis C25 : Avoiding having too many new functions on software projects C26 : Incremental development (deferring changes to later increments) C27 : Combining internal evaluations by external reviews C28 : Maintain proper documentation of each individual's work C29 : Provide training in the new technology and organize domain knowledge training C30: Participating users during the entire software project lifecycle.
shown in the use of collinearity diagnosis (Tolerance test and VIF test).Furthermore, the Durbin-Watson statistic (D) was 1.678 and (d U = 1.739, d L = 1.515) based on K = 4, N = 76, at α = 0.05; as such, there was evidence of inconclusive (d L < D < d U : Inconclusive).R10: Risk of 'misalignment of software project with local practices and processes' compared to controls: Table diagnosis (Tolerance test and VIF test).Furthermore, the Durbin-Watson statistic (D) was 1.688 and (d U = 1.709, d L = 1.543) based on K = 3, N = 76, at α = 0.05; there is evidence of inconclusive (d L <D<d U : Inconclusive).

Table 3 :
Illustrates the value of correlation and R square

Table 4 :
Illustrates an analysis of variance (ANOVA b )

Table 5 :
Illustrates the coefficients and distributed T (Coefficients a )

Table 9 :
Illustrates the coefficients and distributed T (Coefficients a )

Table 11 :
Illustrates an analysis of variance (ANOVA b )

Table 19 :
Illustrates the coefficients and distributed T (Coefficients a )

Table 23 :
Illustrates the coefficients and distributed T (Coefficients a )

Table 26 :
Illustrates an analysis of variance (ANOVA c )

Table 27 :
Illustrates the coefficients and distributed T (Coefficients a )

Table 30 :
Illustrates an analysis of variance (ANOVA e )

Table 31 :
Illustrates the coefficients and distributed T (Coefficients a )

Table 34 :
Illustrates an analysis of variance (ANOVA e )

Table 35 :
Illustrates the coefficients and distributed T (Coefficients a )

Table 38 :
Illustrates an analysis of variance(ANOVA d )

Table 39 :
Illustrates the coefficients and distributed T (Coefficients a )

Table 40 :
Software risk factors in the design phase are mitigated by risk management techniques No Software design process issue factors Risk control factors 1 Introduction of new technology.C3: Assessing cost and scheduling the impact of each change to requirements and specifications.2 Developing the wrong software functions and properties.C4: Develop prototyping and have the requirements reviewed by the client.Provide training in the new technology and organize domain knowledge training, C4: Develop prototyping and have the requirements reviewed by the client, C24: Ensuring that quality-factor deliverables and task analysis, C5: Developing and adhering a software project plan.9 Lack of effective software project team integration between clients, the supplier team and the supply chain.C24: Ensuring that quality-factor deliverables and task analysis, C4: Develop prototyping and have the requirements reviewed by the client, C1: Using of requirements scrubbing, C27: Combining internal evaluations by external reviews.10 Misalignment of software project with local practices and processes.C13: Reusable test plans and test cases, C3: Assessing cost and scheduling the impact of each change to requirements and specifications, C8: Assigning responsibilities to team members and rotate jobs.