Essay:

Essay details:

  • Subject area(s): Engineering
  • Price: Free download
  • Published on: 7th September 2019
  • File format: Text
  • Number of pages: 2

Text preview of this essay:

This page is a preview - download the full version of this essay above.

Identifying and Evaluation of Risks in Software Projects in Gazans Software Projects

Abstract

Risk management is a very important success factor for software project. Risk management use to identify, analyze and control risks in the software development process in order to achieve the business values and goals of the project's success such as time, budget and performance. Despite the existence of several risk management researches, software development processes still have a high degree of failures. To manage software risks, the first step is to identify software risk checklist. Our intensive survey resulted in the List of 82 distinct risk associated with software development projects. This list used in this paper to collect and analyzed the opinions of experts and project managers in the field of software development. The results from the analysis reveal that risks threatening all the essential elements of the project directly connected to project schedule, system requirements, team members, project champion, and project managers. Moreover, its reveal that, management and requirements processes are the most affected by risk exposure. The top ten risk factors in software development in the Gaza strip were unstable and unclear requirements, lack of top management support, the lack of a clear testing plan, there are no adequate and continuous documentation of the risks,  unrealistic estimates cost and schedule, Inadequate documentation of the product, and  lack of project champion . Therefore, the project managers must develop appropriate solutions to avoid or minimize the impact of these risks on software projects.

Keywords:

Software project, software risk factors, Risk management, Successful Software Projects factors.

1. Introduction

Because of the rapid development of technology and intense competition to acquire markets, the software is becoming a major part of enterprise business in order to stay survival and competitive. According to (Ki-moon, 2012) the worldwide information technology (IT) spending more $250 billion each year on developing.  However, a large number of these software fail to achieve their goals in the aspect of business values (cost, time, and quality) (chaos-report, 2014) (Conrow & Shishido, 1997; Han & Huang, 2007; Rubinstein, 2007; Wallace, Keil, & Rai, 2004; Williams, Pandelios, & Behrens, 1999). The software projects by its nature unique, complex, abstract, intangible, and expensive processes. Therefore, project managers must periodically work to identify risks that affected the project success and manage these risks to ensure that the project can achieve its goal on time, budget and requirements (Conrow & Shishido, 1997; Han & Huang, 2007; Rubinstein, 2007; Wallace, Keil, & Rai, 2004; Williams, Pandelios, & Behrens, 1999).

This paper makes contribution to literature in software risk management in the following ways. Firstly, it investigates, classifies, prioritizes the software risks that may have contributed to fail software projects in the Gaza strip. Secondly, it reviews various literature sources deals with the identify risk factors

2. Background

This section gives a background of software risks, software classification, and SRM and its related definitions

2.1 Software Risk

Every software project involves risk of some form such as poor planning, team turnover, changeable and inconsistent requirements.  This section presents several formal definitions of risk available in literature and their sources, few of them presented below.

(a) The degree of risk exposure on software projects (Barki, Rivard, & Talbot, 1993; Boehm, 1991) (Conrow & Shishido, 1997). Mathematically, risk exposure can be written as, R = P x I (Boehm, 1991). Where, R is the risk exposure, P is the risk probability and I is the impact of risks on a software project.

(b) A particular aspect of issues will increase the ratio of project failure, such as (development, task, process, or environment) which, if ignored (Purao, Paul, & Smith, 2007). Project failure usually measured in cost or time in projects.

(c) Unexpected events related to changes and additions to the software specifications during the development period (Gefen, Wyss, & Lichtenstein, 2008).  

(d) A set of factors or conditions that can threat the success of a software project outcome (cost , performance , and schedule) (Chaos-report, 2015; Wallace & Keil, 2004) (El-Masri & Rivard, 2010; Leishman, 2003) ((Williams et al., 1999) (Boban, Pozgaj, & Sertic, 2003).Li, Slyngstad, Torchiano, Morisio, & Bunse, 2008; Tao, 2008)

(e) Containing the three  elements (risk factor,  risk event and risk reaction). Where, a risk factor is something  causing a negative effect and a risk event is the occurrence of a negative effect (Kontio, 2001) (Barki et al., 1993; Boehm, 1991).

Whereas the definitions of risk might vary, a few characteristics are common to all definitions as shown in table (1).

Table 1. Common Characteristics of Risks

No. Characteristics References

1. The loss or negative effect must exist (Barki et al., 1993; Lawler & Howell-Barber, 2016; Leishman, 2003; Li et al., 2008; Williams et al., 1999).

2. Uncertainty with the risk probability must exist (Guiling & Xiaojuan, 2011; Li et al., 2008).

3. Decisions are required to prevent or mitigate these risks (Guiling & Xiaojuan, 2011; Li et al., 2008).

4. Risks affected all software process (Purao et al., 2007)

5. The Risks caused the project to fail (Conrow & Shishido, 1997; Leishman, 2003; Wallace & Keil, 2004; Williams et al., 1999)

2.2 Source of Software Risks

The goal of risk management is to identify risks and develop response plans to reduce the negative impact on the project outcome (cost, time, and performance). The  identification of risk sources provides a basis for understanding the nature of risks that involved in software projects. According to (Roberts, Wallace, & McClure, 2003) (Guiling & Xiaojuan, 2011; Kremljak & Kafol, 2014; Williams, 2004) (Higuera & Haimes, 1996) the main software  risk sources are

' Strategic Risk: relates to risks that can affect the strategic direction the organization.

' Schedule Risks: many projects fail due to schedule risks. Schedules usually exceeded due to inexperienced project  managers, incorrect estimation  of required time, insufficient resources, and  lack of top management commitment.

' Change or Project Risk:  change or project risk can operate at middle level of management within the organization.

' Operational Risk:  relates to the risks in project processes includes the process itself, internal activities involving people, products or services offered, operational systems, external factor's asset base, and the legal issues within the organization.

' Known Risk: known risks are the risks that have been identified in advance, so the project manager can be identified these risks at the beginning of the project.

' Predictable Risk: refers to risks it can predict by the previous experience.

' Unpredictable Risk:  refer to risks which difficult to predict.

' Financial Risk: financial risks lead to increase in project budget that could affect the financial business as risks in market, liquidity risk, funding risk, interest rate risk, investment risk, pricing risk, credit risk, and so on.

' External Risks: this covers those risks on project changes, new stakeholders emerge and demand new work, new stakeholders' request.

' Internal Risks: this covers those risks in project as employee faults, tools, managements and leadership.

' Process Risks: related to software development process and to whether the team members actually follow the process.

2.3 Software Risk Management (SRM)

In the literature, risk management process is the basic principle of identifying, analyzing, prioritizing  and eliminating the software risks before they become a major sources of software failure (Boehm, 1991) (Lawler & Howell-Barber, 2016; Smith, Eastcroft, Mahmood, & Rode, 2006). According to (Johnson, 2006) two approaches to managing software risks (traditional and risk-oriented). The traditional approach is reactive and deals with problems when they occur. While, Risk-oriented is proactive and continuous processes by identifying and managing risks before they influence the project (Williams, 2004). To maximize the efficiency of risk management, the risk management should be continuously developed during the entire project. According to (Dareshuri, Darehshori, Hardoroudi, & Sarkan, 2011; Guiling & Xiaojuan, 2011; Tao, 2008) good risk management should meet the following demands: follows standard in order to assess the possibility of risk, continuously, analyze, control, and monitor  risks through the software development process, and managing Full documentation of all data on risks.

2.4 Software Checklists

A checklist is a formal and most common method to help identify potential risk factors in a software project. The most known software lists are provided by (Barki et al., 1993; Boehm, 1991; Schmidt, Lyytinen, Keil, & Cule, 2001), (Johnson, 2006), (Addison & Vallabh, 2002) , and (Barki et al., 1993). In practice, these lists used to collect the opinions of experts and project managers about the risks associated with the projects and their impacts on project outcome (time, cost, and performance). The main benefit of the checklist approach provides a quick way to identify risks, easy to use, wide scope, control of scope, coverage of key risks, ease of use, simple and accurate output (Bannerman, 2008). However, in practice, checklists have disadvantages such as unsuitable scope; unsuitable level of detail, limited scope, and sometimes the list is too long. A lot of the risk list published, but these lists are not relevant for all software projects, not suitable for all countries, and not adequate all time. Therefore, it must be update and refresh every period.

3. Research Methodology

The research methodology consisted of two stages: At first, the risk factors relating to software projects in literature were identified, analyzed, classified, and documented in a list. This list used to establish a comprehensive risk checklist. Secondly, applying an online questionnaire with questions about the impact and likelihood of each identified risk in software development processes.

3.1 Sample, Population or Subjects

The paper targeted the managers and experts in software development processes in Gaza strip software. A total of 120 questionnaires were distributed to the respondents and a total of 86 questionnaires were returned which represents (71.1%) of the number of questionnaires that were distributed. This indicates that 34 questionnaires were not returned by the respondents and this is (28.33%) of the total questionnaires distributed.

3.2 Instrumentation and materials

The identifying of software risk is important for improving software industry and risk management practice in the Gaza strip. The questionnaire was developed in Google-Docs and the data were processed using Microsoft  Excel 2010 and SPSS 20.

4. Design  Survey Questionnaire

In response to the increasing number of software project failures, many researchers have become interested in addressing  the factors that  associated with these failures. Our  extensive survey review 20 of the most popular studies related to software risk (Chaos-report, 2015; peta, 2013) (Addison & Vallabh, 2002; Boehm, 1991; Conrow & Shishido, 1997; Han & Huang, 2007; Islam, Joarder, & Houmb, 2009; Jiang, 2001; L''pez & Salmeron, 2012; Pare, Sicotte, Jaana, & Girouard, 2008; Perera & Ranasinghe, 2006; Schmidt et al., 2001; Sharma & Gupta, 2012; Smith et al., 2006; Wallace & Keil, 2004). This review resulted in the identification of distinct 82 risk factors as shown in table (2). These risks common to most software projects. Next step is to categorize risks into the six categories according to software development processes:

1. Requirements Analysis and Definition:  The requirements analysis and definition risks relates to software requirements and project objectives

2. Design.: The design risks deals with software complexity, design specifications, and user interface design.

3. Implementation and Unit Testing: Implementation and unit testing relates to hardware, and software resources, implementing the user interface, security, database, integration, and software testing.

4. Operation and Maintenance: Management factors deal top management commitment and support, planning, communication, project champion, and documentation.

5. Management: Management factors deal top management commitment and support, planning, communication, project champion, and documentation.

6. Environmental Factors: Environmental factor deals with the project team, organizational environment, users, political and contractual issues.

Table (2) shows a list of risk factors in software development process. We will use this list as a checklist to identify software risks in Gaza.

Table 2. Comprehensive Risks Checklist in Software Development Process

Index Abbreviation Risk Factors

Requirements Analysis and Definition Risks

1. R1 Unrealistic schedule

2. R2 Unclear project objectives

3. R3 Inadequate estimation of required resources

4. R4 Unrealistic  estimates cost

5. R5 Continually changing system requirements

6. R6 Unclear  system requirements

7. R7 Unrealistic system requirements

8. R8 Incorrect system requirements

9. R9 Incomplete system  requirements

10. R10 Conflict Requirements

11. R11 Externally performed requirements

12. R12 Inadequate documentation of the product

13. R13 Not managing change properly

14. R14 Inadequate security features being built into the system

Design Risks

15. R15 Application complexity

16. R16 The highly complex task being automated

17. R17 Insufficient design specifications

18. R18 Poor interface design

19. R19 Too many designs into one project.

Implementation and Unit Testing Risks

20. R20 Insufficient hardware resources

21. R21 Insufficient  software resources

22. R22 Developing the wrong user interface

23. R23 Gold plating (adding more functionality/features than is necessary)

24. R24 Project progress not monitored closely enough

25. R25 Insufficient procedures to ensure security of the database.

26. R26 Insufficient procedures to ensure integrity of the database

27. R27 Insufficient procedures to ensure availability of the database

28. R28 The unsuitable computer language used to develop software

29. R29 Difficult to get expert advice on the development system

30. R30 Delay of responding by the customer/contractor

31. R31 Developing the wrong software functions

32. R32 Inadequate integration and testing environment

33. R33 The lack of a specialist team to test the system.

34. R34 The lack of a clear plan to test the system.

Operation and Maintenance Risks

35. R35 Failure to involve the user in testing  the system.

36. R36 Tools and means are not sufficient to test the system.

37. R37 There is no clear plan for system operation.

38. R38 Poor code

39. R39 Documentation was very poor

40. R40 The lack of a specialist team of maintenance operations

41. R41 The System design is too complex, making it difficult to maintain.

42. R42 There is no clear plan for system  maintenance.

43. R43 Maintenance operations are very expensive.

Environmental Risks

44. R44 Personnel shortfalls

45. R45 The Project involved the use of new technology

46. R46 Lack of available skilled personnel

47. R47 Failure to gain user commitment

48. R48 Unstable organizational environment

49. R49 High employee turnover

50. R50 Lake of user support

51. R51 Changes to membership on the project team

52. R52 Changes in law ,legal or contractual issues.

53. R53 Inconsistency of regulations within country or organization

54. R54 Political and legal issues

55. R55 User resistance to change

Managements Risks

56. R56 Lack of top management commitment

57. R57 Lack of top management support

58. R58 Lack of involvement of  client in development activities

59. R59 Poor project planning

60. R60 Inexperience team members

61. R61 Inexperienced managers in software management

62. R62 Following standards

63. R63 Lack of communication ability

64. R64 Ineffective project management

65. R65 Political games or conflicts

66. R66 Failure to manage end-user expectations

67. R67 Inadequate configuration management system

68. R68 No coordination between distributed development sites

69. R69 Lack of effective project management methodology

70. R70 Team diversity

71. R71 Lack of commitment from the project team

72. R72 Low morale of the  project team

73. R73 Inadequately  trained development team members

74. R74 Estimation of hardware and software capabilities

75. R75 Frequent conflicts between development team members

76. R76 Lack of project champion

77. R77 Ineffective communication

78. R78 Project milestones not clearly defined

79. R79 Steady consumption of time

80. R80 The inability to resolve the crisis within the project.

81. R81 Lack of incentives for team members.

82. R82 There are no adequate and continuous documentation of risks.

4.1 Measurement Scale of Questionnaire:

Three measures are associated with a risk: probability, impact, and risk exposure. Risk impact refers to the ability of risk to influence on software development process. Table (3)  illustrates the 5 levels of the risk impact.

Table 3. Levels of Risk Impact Criteria (Huang & Han, 2008)

Level Risk Impact The ability to influence

1. Negligible (N) ~ 10 %

2. Minor (M) ~ 30 %

3. Moderate (MO) ~ 50 %

4. Serious (S) ~ 70 %

5. Critical (C) ~ 90 %

Where, risk likelihood represents the possibility that a given event will occur (Boehm, 1991).  Table (4)  illustrates the 5 levels of the risk likelihood.

Table 4. Levels of Likelihood Criteria

Level Likelihood Possibility

1. Remote (R) ~ 10 %

2. Unlikely (U) ~ 30 %

3. Likely (L) ~ 50 %

4. Highly likely (H) ~ 70 %

5. Near certainty (NC) ~ 90 %

5. Data Analysis and Results

The results of the analyze each risk measurement (impact, likelihood, and exposure) that identified in the table (5) according to the respondent's views are summarized in table (4).

Table 5. Risks Factors Affecting Software Projects in Gaza strip

Index Risk Factors Risk Impact Risk Likelihood

Risk Exposure

Weight % Mean Deviation Impact Weight % Mean Deviation Likelihood Weight % Result Rank

1. R1 76.47 3.82 0.834 S 81.70 4.09 .753 N 62.52 H 7

2. R2 71.76 3.59 1.184 S 77.60 3.88 .913 H 55.72 H 16

3. R3 72.94 3.65 1.012 S 73.50 3.68 .638 H 53.64 H 21

4. R4 80 4.00 1.015 C 78.23 3.91 0.621 H 62.6 H 6

5. R5 85.88 4.29 0.970 C 83.50 4.18 .716 N 71.72 H 1

6. R6 73.53 3.68 1.199 S 81.10 4.06 .952 N 59.68 H 10

7. R7 70.59 3.53 1.308 S 65.88 3.29 .871 H 46.52 H 47

8. R8 65.29 3.26 1.378 S 69.41 3.47 .861 H 45.32 H 52

9. R9 78.82 3.94 1.071 S 80.59 4.03 .627 N 63.52 H 5

10. R10 71.18 3.56 1.353 S 67.06 3.35 .950 H 47.72 H 45

11. R11 57.06 2.85 1.077 MO 57.65 2.88 .880 L 32.88 L 82

12. R12 73.53 3.68 1.007 S 83.53 4.18 1.058 N 61.4 H 8

13. R13 70.00 3.50 1.052 S 75.88 3.79 .729 H 53.12 H 22

14. R14 58.82 2.94 1.043 MO 66.47 3.32 .806 H 39.12 M 73

15. R15 71.39 3.57 0.841 S 62.94 3.15 .925 H 44.92 H 53

16. R16 64.12 3.21 0.946 S 61.76 3.09 .753 H 39.6 H 70

17. R17 61.76 3.09 0.900 S 64.12 3.21 .770 H 39.6 H 71

18. R18 71.18 3.56 1.186 S 62.94 3.15 1.019 H 44.8 H 56

19. R19 61.76 3.09 1.357 S 63.53 3.18 .968 H 39.24 H 72

20. R20 64.82 3.24 0.891 S 57.06 2.85 1.105 L 37 H 78

21. R21 61.76 3.09 1.026 S 54.12 2.71 1.088 L 33.44 H 81

22. R22 60.59 3.03 1.000 S 62.35 3.12 1.175 H 37.76 H 76

23. R23 64.71 3.24 1.046 S 58.24 2.91 .965 L 37.68 H 77

24. R24 55.88 2.79 0.914 MO 79.41 3.97 .717 H 44.36 M 59

25. R25 72.35 3.62 0.922 S 67.65 3.38 1.074 H 48.96 H 34

26. R26 73.53 3.68 1.319 S 74.71 3.74 .898 H 54.92 H 18

27. R27 68.82 3.44 1.353 S 67.06 3.35 1.070 H 46.16 H 48

28. R28 66.47 3.32 1.408 S 57.65 2.88 1.200 L 38.32 H 75

29. R29 55.29 2.76 1.281 MO 65.88 3.29 .836 H 36.44 M 79

30. R30 61.18 3.06 1.179 S 78.18 3.91 .579 H 47.84 H 44

31. R31 69.41 3.47 0.929 S 58.82 2.94 .952 L 40.84 H 68

32. R32 66.47 3.32 1.342 S 68.48 3.42 .751 H 45.52 H 51

33. R33 72.35 3.62 1.129 S 88.82 4.44 .746 N 64.28 H 4

34. R34 74.71 3.74 0.751 S 87.06 4.35 .884 N 65.04 H 3

35. R35 73.53 3.68 0.945 S 77.06 3.85 .857 H 56.68 H 13

36. R36 72.35 3.62 1.015 S 72.94 3.65 .734 H 52.76 H 25

37. R37 67.02 3.35 0.861 S 59.41 2.97 1.087 L 39.84 H 69

38. R38 61.18 3.06 0.983 S 58.82 2.94 1.013 L 36 H 80

39. R39 58.82 2.94 1.179 MO 85.88 4.29 .871 N 50.52 M 31

40. R40 71.18 3.56 1.133 S 75.88 3.79 .880 H 54 H 20

41. R41 67.06 3.35 1.252 S 64.12 3.21 .914 H 43 H 62

42. R42 68.24 3.41 1.395 S 80.59 4.03 .904 N 55 H 17

43. R43 70.00 3.50 1.107 S 65.29 3.26 .864 H 45.72 H 50

44. R44 66.97 3.35 1.010 S 67.06 3.35 .849 H 44.92 H 54

45. R45 71.18 3.56 1.021 S 62.35 3.12 .880 H 44.4 H 58

46. R46 62.94 3.15 0.784 S 65.88 3.29 .938 H 41.48 H 66

47. R47 70.00 3.50 1.135 S 80.59 4.03 .674 N 56.4 H 14

48. R48 75.29 3.76 1.075 S 70.00 3.50 .615 H 52.72 H 26

49. R49 74.71 3.74 1.109 S 68.82 3.44 .824 H 51.4 H 29

50. R50 78.82 3.94 1.099 S 69.41 3.47 .825 H 54.72 H 19

51. R51 74.12 3.71 0.970 S 65.88 3.29 .871 H 48.84 H 36

52. R52 72.94 3.65 0.950 S 66.47 3.32 .727 H 48.48 H 39

53. R53 66.47 3.32 1.007 S 69.41 3.47 .788 H 46.12 H 49

54. R54 69.41 3.47 1.398 S 76.36 3.82 .683 H 53 H 23

55. R55 61.76 3.09 1.288 S 82.94 4.15 .821 N 51.24 H 30

56. R56 70.78 3.54 0.759 S 81.76 4.09 .965 N 57.88 H 11

57. R57 74.71 3.74 1.189 S 91.18 4.56 .991 N 68.12 H 2

58. R58 77.65 3.88 1.149 S 67.06 3.35 1.098 H 52.08 H 28

59. R59 73.53 3.68 0.945 S 64.71 3.24 .819 H 47.56 H 46

60. R60 71.18 3.56 0.927 S 60.59 3.03 .937 H 43.12 H 61

61. R61 65.88 3.29 1.268 S 64.12 3.21 .914 H 42.24 H 64

62. R62 72.94 3.65 1.346 S 65.88 3.29 .760 H 48.04 H 42

63. R63 69.41 3.47 1.187 S 64.71 3.24 .741 H 44.92 H 55

64. R64 66.47 3.32 1.093 S 67.06 3.35 .884 H 44.56 H 57

65. R65 71.18 3.56 1.307 S 67.65 3.38 .739 H 48.16 H 41

66. R66 71.76 3.59 1.617 S 68.24 3.41 .821 H 48.96 H 35

67. R67 74.71 3.74 0.963 S 77.06 3.25 .702 H 48.52 H 38

68. R68 70.59 3.53 1.261 S 79.41 3.97 .577 H 56.04 H 15

69. R69 67.65 3.38 1.206 S 77.06 3.85 .821 H 52.12 H 27

70. R70 70.59 3.53 1.237 S 68.82 3.44 .927 H 48.6 H 37

71. R71 69.41 3.47 1.161 S 69.41 3.47 .615 H 48.2 H 40

72. R72 71.18 3.56 1.211 S 54.71 2.74 1.024 L 38.92 H 74

73. R73 72.35 3.62 0.985 S 61.18 3.06 .983 H 44.28 H 60

74. R74 68.24 3.41 1.048 S 62.94 3.15 .892 H 42.96 H 63

75. R75 66.47 3.32 0.976 S 75.29 3.76 .741 H 50.04 H 33

76. R76 75.88 3.79 1.366 S 80.58 4.03 .969 N 61.16 H 9

77. R77 71.76 3.59 1.258 S 58.82 2.94 .983 L 42.2 H 65

78. R78 65.29 3.26 1.053 S 63.53 3.18 .797 H 41.48 H 67

79. R79 72.35 3.62 0.985 S 69.41 3.47 .706 H 50.24 H 32

80. R80 73.53 3.68 1.036 S 77 3.85 0.657 H 56.68 H 12

81. R81 78.24 3.91 1.215 S 61.17 3.06 .851 H 47.88 H 43

82. R82 78.82 3.94 1.043 S 67.06 3.35 .812 H 52.84 H 24

5.1 A list of the top 10 risks in Software Projects in Gaza Strip

To determine the top 10 risks in software projects, the assessment of risk impacts, likelihood, and exposure of all identified  risks were computed according to the respondents' views. Table 5 presents a list of the top 10 software risks and their likelihood,  impact, and  exposure.

Table 5. The Top Ten Software Risks in Gaza Strip

Rank Software risk Process likelihood Impacts Exposure

1. Continually changing system requirements Requirements 85.88 83.50 62.52

2. Lack of top management support Management 74.71 91.18 68.12

3. The lack of a clear plan to test the system Testing 74.71 87.06 65.04

4. The lack of a specialist testing team Testing 72.35 88.82 64.28

5. Incomplete system  requirements Requirements 78.82 80.59 63.52

6. Unrealistic estimates cost Management 80 78.23 62.6

7. Unrealistic schedule Planning. 76.47 81.70 62.52

8. Inadequate documentation of the product Management 73.53 83.53 61.4

9. Lack of project champion Management 75.88 80.58 61.16

10. Unclear  system requirements Requirements 73.53 81.10 59.68

5.2 Risk Impact in Software Development Processes

In other hand, the three risk elements (impact, risk, and  exposure) for every phase in software development processes are shown in table (6).

   Table 6. Risk Impact for Every Phase in Software Development Processes

No Software process Risk Impact Risk Likelihood Risk Exposure Result Rank

1. Software Requirements Analysis and Definition 71.39% 74.36% 53.08% H 2

2. Software Design 65.29% 63.06% 41.17% L 6

3. Software implementation and Unit Testing 70.00% 69.16% 48.41% M 5

4. Software Operation and Maintenance 72.35% 70.00% 50.65% M 3

5. Business Environment 71.76% 68.28% 49.00% M 4

6. Managements process 77.65% 70.12% 54.44% H 1

Table (6)  shows that the management processes accounts the highest percentage of risk exposure for software projects (54.44%), followed by Software Requirements processes (53.08%). Many researchers agree with these results. (Arnuphaptrairong, 2011) see that the lack of management awareness of risks and Misunderstanding of the requirement have an important impact on project outcomes.

6. Conclusion

Several statistics indicate that many software projects fail due to several reasons, and concentrate on addressing these reasons are  important thing for a project success, for this purpose, this paper review 20 of the most popular papers related to software risks and extracted 82 unique risks; hence, top ten of software risk factors was identified.  Results as seen in table (4.8) can be summarized as follows:

' The result indicates that "continually changing system requirements" risks is critical to achieving the project goals.

' "Schedule, management support, testing team and plan, documentation " risks got the highest scores of surveyed risk factors given by managers.

' "Software and hardware resources, team morale, externally performed requirements, and computer language" risks are less frequent risks in Gazans software projects.

' Difficult to get expert advice on the development system, Project progress not monitored closely enough, Externally performed requirements, Inadequate security features being built into the system, and Documentation was very poor are less impact on Gazans software projects.

' Risks threatening all the essential elements of the project directly connected to project schedule, system requirements,  team members, project champion,  and project managers.

' The software projects suffer from managements risks such as (documentation, incentives for team members).

' The software projects suffer from requirement risks such as (Unclear, Continually and Incomplete system requirements.

' Respondents believe that projects suffer from lack in testing team.

' The absence of implementation risks of the top ten software risks, that's mean, the software projects have good developers.

' Unstable organizational environment such as political issues, the siege, and limited energy  unseen as top software risks in Gaza.

The future work of this study is to propose appropriate tool that will help software managers to manage risk factors in their projects to enhance the chance of software success ratio.

 References:

Addison, T., & Vallabh, S. 2002. Controlling software project risks: an empirical study of methods used by experienced project managers. Paper presented at the Proceedings of the 2002 annual research conference of the South African institute of computer scientists and information technologists on Enablement through technology.

Arnuphaptrairong, T. 2011. Top ten lists of software project risks: Evidence from the literature survey. Paper presented at the Proceedings of the International MultiConference of Engineers and Computer Scientists.

Bannerman, P. L. 2008. Risk and risk management in software projects: A reassessment. Journal of Systems and Software, 81(12): 2118-2133.

Barki, H., Rivard, S., & Talbot, J. 1993. Toward an assessment of software development risk. Journal of management information systems: 203-225.

Boban, M., Pozgaj, Z., & Sertic, H. 2003. Strategies for successful software development risk management. Management, 8(2): 77-91.

Boehm, B. W. 1991. Software risk management: principles and practices. Software, IEEE, 8(1): 32-41.

chaos-report. 2014. The Standish Group Report CHAOS.

Chaos-report. 2015. THE STANDISH GROUP REPORT.

Conrow, E. H., & Shishido, P. S. 1997. Implementing risk management on software intensive projects. IEEE software, 14(3): 83-89.

Dareshuri, A. F., Darehshori, E. F., Hardoroudi, A. H., & Sarkan, H. M. 2011. Implementing corrective and preventive actions in risk assessment software. Paper presented at the Open Systems (ICOS), 2011 IEEE Conference on.

El-Masri, M., & Rivard, S. 2010. Specifying the software project risk construct.

Gefen, D., Wyss, S., & Lichtenstein, Y. 2008. Business familiarity as risk mitigation in software development outsourcing contracts. MIS quarterly: 531-551.

Guiling, L., & Xiaojuan, Z. 2011. Research on the Risk Management of IT Project. Paper presented at the E-Business and E-Government (ICEE), 2011 International Conference on.

Han, W.-M., & Huang, S.-J. 2007. An empirical analysis of risk components and performance on software projects. Journal of Systems and Software, 80(1): 42-50.

Higuera, R. P., & Haimes, Y. Y. 1996. Software Risk Management: DTIC Document.

Huang, S.-J., & Han, W.-M. 2008. Exploring the relationship between software project duration and risk exposure: A cluster analysis. Information & Management, 45(3): 175-182.

Islam, S., Joarder, M. M. A., & Houmb, S. H. 2009. Goal and risk factors in offshore outsourced software development from vendor's viewpoint. Paper presented at the Global Software Engineering, 2009. ICGSE 2009. Fourth IEEE International Conference on.

Jiang, J. K. 2001. Software project risks and development focus'. Project Management Journal, 32(1): 4-9.

Johnson, D. L. 2006. Risk Management and the Small Software Project. LOGOS International, Inc.

Ki-moon, B. 2012. Information Economy Report 2012: United Nations: Geneva.

Kontio, J. 2001. Software engineering risk management: a method, improvement framework, and empirical evaluation: Helsinki University of Technology.

Kremljak, Z., & Kafol, C. 2014. Types of Risk in a System Engineering Environment and Software Tools for Risk Analysis. Procedia Engineering, 69: 177-183.

Lawler, J., & Howell-Barber, H. 2016. A Big Data Analytics Methodology Program in the Health Sector. Information Systems Education Journal, 14(3): 63.

Leishman, T. R., and VanBuren. 2003. The Risk of Not Being Risk Conscious: Software Risk Management Basics. STSC Seminar Series  , Hill AFB, UT.

Li, J., Slyngstad, O., Torchiano, M., Morisio, M., & Bunse, C. 2008. A state-of-the-practice survey of risk management in development with off-the-shelf software components. Software Engineering, IEEE Transactions on, 34(2): 271-286.

L''pez, C., & Salmeron, J. L. 2012. Risks Response Strategies for Supporting Practitioners Decision-Making in Software Projects. Procedia Technology, 5: 437-444.

Pare, G., Sicotte, C., Jaana, M., & Girouard, D. 2008. Prioritizing clinical information system project risk factors: a Delphi study. Paper presented at the Hawaii International Conference on System Sciences, Proceedings of the 41st Annual.

Perera, M., & Ranasinghe, M. 2006. Prompt list for risk management in Sri Lankan software industry. Paper presented at the Information and Automation, 2006. ICIA 2006. International Conference on.

peta. 2013. Palestinian ICT Market Penetration Study

Purao, S., Paul, S., & Smith, S. 2007. Understanding enterprise integration project risks: A focus group study. Paper presented at the Database and Expert Systems Applications, 2007. DEXA'07. 18th International Workshop on.

Roberts, A., Wallace, W., & McClure, N. 2003. Strategic Risk Management: Pearson Education.

Rubinstein, D. 2007. Standish group report: There's less development chaos today.

Schmidt, R., Lyytinen, K., Keil, M., & Cule, P. 2001. Identifying software project risks: an international Delphi study. Journal of management information systems, 17(4): 5-36.

Sharma, A., & Gupta, A. 2012. Impact of organisational climate and demographics on project specific risks in context to Indian software industry. International Journal of Project Management, 30(2): 176-187.

Smith, D., Eastcroft, M., Mahmood, N., & Rode, H. 2006. Risk factors affecting software projects in South Africa. South African Journal of Business Management, 37(2).

Tao, Y. 2008. A study of software development project risk management. Paper presented at the Future Information Technology and Management Engineering, 2008. FITME'08. International Seminar on.

Wallace, L., & Keil, M. 2004. Software project risks and their effect on outcomes. Communications of the ACM, 47(4): 68-73.

Wallace, L., Keil, M., & Rai, A. 2004. Understanding software project risk: a cluster analysis. Information & Management, 42(1): 115-125.

Williams, L. 2004. Risk Management.

Williams, R. C., Pandelios, G. J., & Behrens, S. G. 1999. Software Risk Evaluation (SRE) Method Description: Version 2.0: Carnegie Mellon University, Software Engineering Institute.

...(download the rest of the essay above)

About this essay:

This essay was submitted to us by a student in order to help you with your studies.

If you use part of this page in your own work, you need to provide a citation, as follows:

Essay Sauce, . Available from:< https://www.essaysauce.com/essays/engineering/essay-2016-05-22-000B8W.php > [Accessed 23.10.19].