Mathematical Problems in Engineering

Volume 2013 (2013), Article ID 376375, 9 pages

http://dx.doi.org/10.1155/2013/376375

Research Article

Using the Fuzzy Linguistic Preference Relation Approach for Assessing the Importance of Risk Factors in a Software Development Project

Shih-Tong Lu,1,2 Shih-Heng Yu,² Dong-Shang Chang,² and Shih-Chang Su²

¹Graduate Institute of Project Management, Kainan University, No. 1, Kainan Road, Taoyuan, Luzhu Shiang 33857, Taiwan

²Department of Business Administration, National Central University, No. 300, Jhongda Road, Taoyuan, Jhongli City 32001, Taiwan

Received 15 January 2013; Accepted 28 April 2013

Academic Editor: Ker-Wei Yu

Copyright © 2013 Shih-Tong Lu et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract.

This study employs fuzzy linguistic preference relation (Fuzzy LinPreRa) approach to assess the relative degree of impact of risk factors in software development project for two expert groups working in technology enterprises and software development companies. For the identified risk dimensions, the results show the same rankings for these two groups. “Organization function risk” is considered the most important dimension influencing the software development project performance, with the others, in order, being “developing technology risk,” “resources integration risk,” “personnel system risk” and “system requirement risk.” The proposed approach not only facilitates the information collecting for making pairwise comparisons, but it also eliminates the inconsistencies in the collected information.

1. Introduction

Software development projects are usually designed by highly skilled and trained experts due to projects’ complicate, professional, and technicality nature. However, these types of projects often have series of setbacks such as high cost, schedule overruns, quality issues, and usability problems [1, 2]. From the past experience, most software development projects use more resources than originally planned, take longer time to complete, and unfortunately, often deliver poor functionality and low quality than expected [3]. It is obvious that the life cycle of software development process is inherent numerous uncertainties and risk factors. Therefore, there are some researchers that focused on the study of risk evaluation, risk assessment, and risk management of software development.

Since there are numerous risks in software development, the proposed assessment procedure has designed using multiple criteria decision making (MCDM) approach. Besides, associated risk evaluation is often determined by experts subjectively; however, it is not easy for the experts to achieve precise judgments with limited time. Therefore, to solve the problem of incorporating more assessment factors and working within time limitations for interviews with experts, this study applies the fuzzy linguistic preference relation (Fuzzy LinPreRa) proposed by Wang and Chen [5]. This method is based on the consistent fuzzy preference relations (CFPRs) approach which was proposed by Herrera-Viedma et al. [6] to deal with the relative degree of impact of software development risk factors. The results can provide decision makers with the ability to propose risk management strategies in advance of implementing a software development project.

2. Risk Factors for a Software Development Project

Many uncertain problems could confront whether done by oneself or by outsourcing groups when the software development projects are performed. In order to reduce failure rate of software development, software engineers and information system researchers should always identify as many risk factors affecting project outcome as they can. In the literatures review, ten risk items for software development projects were identified by Boehm [7], which include personnel shortfalls, unrealistic schedules and budgets, developing the wrong functions and properties, developing the wrong user interface, adding more functionality/features, continual requirement changes, shortfalls in externally furnished components, shortfalls in externally performed tasks, real-time performance shortfalls, and straining of computer-science capabilities. A hierarchical structure model for evaluating software development risk was constructed via fuzzy set theory by Lee and Lin [8]. They proposed six risk attributes in order to evaluate the aggregative risk: personnel, system requirements, schedules and budgets, developing technology, external resource, and performance. The fourteen risk items can be categorized into six attributes.

The twelve risk categories identified by Jiang and Klein [9] include technological acquisition, project size, lack of general team expertise, lack of team’s expertise with the task, lack of team’s development expertise, lack of user support, intensity of conflicts, extent of changes brought, resources insufficient, lack of clarity of role definitions, application complexity, and lack of user experience. In addition, Houston et al. [10] listed thirty software development risk factors and further studied the effects of six common and significant risk factors. They are creeping user requirements, lack of staff commitment, low morale, instability and lack of continuity in project staffing, inaccurate cost estimation, excessive schedule pressure, and lack of senior management commitment. Büyüközkan and Ruan [11] applied the Choquet integral aggregation approach to analyze the effects of importance and interactions among software development risks. They extracted software development risk factors by surveying a large amount of literature, and they explored several types of risks including product engineering risks, development environment risks, and program constraint-related risks such as the main risk dimensions. Factors associated with product engineering risks include requirements, design, code and unit tests, integration and testing, engineering specialists. Factors in development environment risks include development process, development system, management process, management methods, and work environment. Resource, contract, and program interfaces are those factors that influence the program constraint risks. Lu and Ma [12] identified the risk factors according to the life cycle of a software development project for owners and contractors. For owners, the causes of risk are distinguished into conceive stage, development stage, execution stage, and finish stage. In the conceive stage and development stage there are eight risk factors, respectively. Six risk factors belong to execution stage, but in finish stage, the main risk factor is that there is no standard and criterion of the information system. For contractors, risk factors in software development include four aspects: policy risk, technique risk, scope change risk, and management risk. The management risk consists of cost management risk, quality management risk, schedule management risk, integration management risk, human resources management risk, and communication management risk. Lu and Yu [4] constructed a hierarchical structure of five dimensions and associated twenty-two risk factors for software development project and presented two approaches to assess the importance and the ranking of these risk factors by fuzzy set theory. The five risk dimensions include organization function risk, developing technology risk, personnel system risk, resources integration risk, and system requirement risk.

From these literatures review, the software development risk factors were further screened and synthesized for this study. We can adopt the hierarchical structure of risk factors developed by [4] for applying the proposed Fuzzy LinPreRa approach conveniently. Figure 1 shows the hierarchical structure of risk factors for a software development project.

Figure 1: Hierarchical structure of risk factors for a software development project [4].

3. Method for Assessing the Degree of Impact of Risk Factors

This study not only would like to realize the risk factors in the process of software development, but is also considers which of these factors are important for the project managers. It is impractical to assume that the different project risk factors equally affect project success. Therefore, the impact degree of the risk factors on project success should be carefully evaluated for better managing of the project risk and increasing the chance of project success. That is, the varying effects of project risk factors on project success provide valuable information needed to allocate software development project resources. This study would like to assess the relative impact degree among software development risk factors for helping developers to draw up the risk management strategies. However, the largest possible number of evaluation criteria of a dimension is five. If we apply the conventional analytic hierarchical process (AHP) proposed by Saaty [13], or fuzzy AHP proposed by Buckley [14], to design the questionnaire, we may encounter great difficulties and challenges in collecting information. In addition, the model also needs to consider the fuzziness of the judgments or opinions of selected experts when they answer the questionnaires. Thus, this study applies the fuzzy linguistic preference relation (Fuzzy LinPreRa) approach for constructing the decision matrices of pairwise comparisons. The FLPR approach was constructed by Wang and Chen [5] based on the consistent fuzzy preference relations (CFPRs) proposed by Herrera-Viedma et al. [6]. The Fuzzy LinPreRa not only makes it easy for interviewers to use linguistic variables to present a set of criteria with the least amount of subjective judgment, but it also avoids the necessity to check for consistency in the decision-making process. More importantly, it is more convenient to acquire the judgments of practitioners or experts of software development industry through a questionnaire. A brief introduction of the definitions and steps in the adopted Fuzzy LinPreRa method is given.

3.1. Consistent Fuzzy Preference Relations (CFPRs)

The fuzzy preference relation on a set of evaluation criteria is a fuzzy set of the product with a membership function . The preference relation is represented by the matrix , where   for  all  . Herein,   is interpreted as the degree of importance of criteria   over  . If  , it means that    and    are equally important; indicates that is absolutely important to  ; and    shows that    is more important than  . In this case, the preference matrix, , is usually assumed to be additive reciprocal; that is, ,  for  all  . When the reciprocal fuzzy preference relation    is consistent and verifies additive consistency, there exists a relationship equation such that [6]

Equation (1) is very important because it can be used to construct a consistent fuzzy preference relation from the set of   values  . If a decision matrix with entries in the interval ,   is outside the interval  , it can be constructed by transforming the obtained values using a transformation function that preserves reciprocity and additive consistency. The transforming function is ,  . In such a way, we can facilitate the expression by the evaluator of consistent preferences in the decision process.

3.2. Linguistic Variables and Fuzzy Numbers

A linguistic variable is the one whose values are words or sentences expressed in a natural or artificial language. Here, we use this kind of expression to compare the impact degree of two risk dimensions or factors for a software development project using linguistic terms: “absolutely (not) important,” “very strongly (not) important,” “essentially (not) important,” “weakly (not) important,” “equally important,” with respect to a triangle fuzzy number (TFN) proposed by [15]. A TFN is a fuzzy number on if its membership function is equal to (2), following the definition in [14]

where   and stand for the lower and upper bounds of the fuzzy number , respectively, and stands for the median value. The TFN can be denoted by , and Table 1 shows the corresponding TFN for each linguistic assessment variable. The table of converting linguistic terms to fuzzy numbers is constructed from [15]. Detailed conversion scales can contain and match all the verbal terms given by the evaluators, and it is very important for the evaluators to be familiar with the decision problem context.

Table 1: Fuzzy linguistic assessment variables.

Linguistic variables
Triangle fuzzy numbers

Absolutely important (AB)
()

Very strongly important (VS)
()

Essentially important (ES)
()

Weakly important (WK)
()

Equally important (EQ)
()

Weakly not important (WN)
()

Essentially not important (EN)
()

Very strongly not important (VN)
()

Absolutely not important (AN)
()

3.3. Fuzzy Linguistic Preference Relations (Fuzzy LinPreRa)

Given a set of criteria, is associated with the fuzzy linguistic preference relations matrix based on consistent fuzzy preference relations and fuzzy linguistic assessment variables. If the matrix above complies with additive reciprocal consistency, then the following statements must be equivalent:

Notably, if the values of the obtained matrix with elements in the interval are not in the interval  , the obtained fuzzy numbers will need to be transformed by way of a transformation function to preserve the reciprocity and additive consistency. The transformation functions for left, median, and upper values of TFN in every element of decision matrix    are given in (4). Finally, we can obtain a consistent additive reciprocal decision matrix  

3.4. Determination of Criteria Weights

If there are evaluators to participate in the judgments, this study uses the notion of the average value to integrate the fuzzy judgment values of evaluators from the set of values  ; that is,

Here, we can establish an original synthetic fuzzy judgment matrix   and then use (3) and (4) to obtain the consistent synthetic fuzzy judgment matrix . In order to obtain the weights of each criterion, this study adopts column vector average approach proposed by Saaty and Vargas [16] as follows:

The result of the fuzzy synthetic decision reached by each criterion is a fuzzy number, . Therefore, it is necessary that a defuzzification method for fuzzy numbers is used. Methods for such defuzzified weighting generally include the mean of maximal (MOM), center of area (COA), and α-cut methods [17, 18]. This study utilizes the COA method to find that the nonfuzzy value is a simple and practical method. The defuzzified weights of the fuzzy number can be found by the following equation:

4. Case Study

Two companies were invited to answer the questionnaire related to the risk of a software development project. The first group is comprised of five experts with 5 to 15 years’ experience in the information management division from a medium scale technology enterprise. The second group is also comprised of five experts with 5 to 10 years’ experience in establishing enterprise resource planning (ERP) systems for a software development company. The individuals in the two groups were invited to provide responses to the questionnaire survey and were asked to compare the relative degree of impact for the risk dimensions and factors identified in this study in pairwise sequential order. That is, they only needed to compare the relative impact degree from to ,  from   to ,  from   to ,  from   to ,  from   to ,  from   to , and so on. Tables 2 and 3 list the original evaluation results of this pairwise comparison for the risk dimensions given by the five experts of the two groups. Similarly, Tables 4 and 5 display the original pairwise comparison matrix for the twenty-two risk factors given by the two groups. Since the preferences and experiences of these experts are different, we use the fuzzy linguistic assessment variables, as in Table 1 and from (3) to (5), to aggregate the experts’ subjective judgments toward the impact of the degree of risk dimensions and factors, yielding the synthesized triangular fuzzy numbers listed in Tables 6, 7, 8, and 9, respectively. The ranking of the impact degree is determined by constructing a crisp value from the fuzzy number. Hence, defuzzification needs to be performed to arrange the fuzzy numbers for ranking. Table 10 lists the impact degree and ranking of risk dimensions and factors for software development projects obtained by using (6) and (7).

Table 2: Original evaluation results for the risk dimensions by the first group.

VS
VS
EQ
WN
VN

VN
VS
EQ
AB
AB

VS
VN
WN
VS
VN

EQ
EN
VS
WK
EQ

Table 3: Original evaluation results for the risk dimensions by the second group.

ES
VS
VN
WK
EQ

EQ
WN
VS
VS
VS

ES
VS
EN
AN
WN

ES
WK
EQ
AB
WK

Table 4: Original evaluation results for the risk factors by the first group.

VS
AB
VS
EQ
AB

VN
VN
VN
ES
EN

AB
WK
EQ
ES
WK

VS
AB
VS
WK
ES

VS
EQ
WK
WK
EN

AN
VN
EN
EQ
VN

AN
VN
EQ
VN
AN

VS
VS
WK
VN
AB

AN
AN
VN
AN
VS

EQ
VS
AB
EQ
VN

EQ
EN
EQ
WN
EQ

VS
VN
VN
ES
VS

EQ
ES
WK
VS
WN

VS
AB
AB
VS
ES

EQ
VS
WN
VN
EN

EQ
VS
ES
ES
ES

VS
VN
WK
VS
EQ

Table 5: Original evaluation results for the risk factors by the second group.

VS
ES
EQ
VS
WK

WN
EN
EQ
VN
EN

ES
ES
EQ
VS
ES

WN
EN
EQ
AB
WN

ES
ES
VS
VS
VN

EN
VN
AN
AN
EN

ES
VS
VN
AB
VS

ES
WK
VS
AB
VN

WN
EN
EQ
AN
EQ

ES
ES
EQ
AB
EQ

WK
ES
EQ
AN
WK

ES
ES
ES
VS
EQ

ES
ES
EQ
VS
WK

VS
VS
AB
AB
ES

EQ
EN
EQ
VS
WN

EQ
ES
EQ
VS
ES

EN
EN
VN
EN
WN

Table 6: Aggregation decision matrix of the risk dimensions form the first group.

Table 7: Aggregation decision matrix of the risk factors from the first group.

Table 8: Aggregation decision matrix of the risk dimensions from the second group.

Table 9: Aggregation decision matrix of the risk factors from the second group.

Table 10: Impact degree and ranking of risk dimensions and factors for the two groups.

Dimensions/factors
Impact degree of the first group
Ranking
Impact degree of the second group
Ranking

0.2481
1
0.2459
1

0.3246
1
0.2968
1

0.1829
4
0.2134
3

0.2793
2
0.2784
2

0.2133
3
0.2114
4

0.2286
2
0.2306
2

0.3301
1
0.2537
2

0.2049
3
0.2432
3

0.1737
4
0.1731
4

0.2912
2
0.3300
1

0.1749
4
0.1813
4

0.1261
5
0.2559
1

0.2266
2
0.2045
2

0.1688
4
0.1684
4

0.2520
1
0.2045
3

0.2265
3
0.1667
5

0.1813
3
0.1894
3

0.2553
3
0.2930
1

0.2777
1
0.2945
2

0.2589
2
0.2325
3

0.2082
4
0.1800
4

0.1671
5
0.1528
5

0.2673
1
0.2716
1

0.1972
3
0.1934
3

0.2074
2
0.1888
4

0.1724
4
0.1500
5

0.1557
5
0.1962
2

For experts in the first group, who are staff members of a technology enterprise, among the identified five dimensions, “organization function risk” was found to be the most important risk dimension to influence software development performance and success. “Developing technology risk” and “resources integration risk” are respectively the second and third highest impact dimensions affecting software development project performance. “Personnel system risk” and “system requirement risk” are the last two dimensions in sequence in relative importance affecting performance and success of the software development project.

For each dimension, among the first risk dimensions (), incapable organization management () was considered the most impact risk factor, and it is also the most important factor for the global aspect. Among the second, fourth, and fifth dimensions (i.e., , , and  ), immature technology development (), improper coordination with related divisions (), and continuing stream of requirements changes () were all found to be the highest impact risk factors influencing the software development project success. Unavailability of key staff or project managers () and lack of staff commitment and low morale (), respectively, are the most observed prominent risk factors which harm software development project success in each dimension.

The points of view in relation to the risk dimensions expressed by the experts of the second group, who are staff members of a software development company, are the same as the first group. For each dimension, the ranking results of the impact degree for risk factors are somewhat different from the first group. For example, among the first risk dimension (), incapable organization management () is also considered as the most impacting risk factor in the first group, but it is the factor having the second greatest impact for global aspects, which is not the same as the first group. The most difference in ranking for factors of dimensions between these two groups was for the third risk dimension (). The second group considers reliance on a few key personnel () as the most important factor in the “personnel system risk” aspect, but it has the least impact based on the evaluations of the first group.

According to the results of this case study, whether it is technology enterprise (demander) or software development company (supplier), they should realize that organization and communication management is the upmost restrict condition for the success of software development project; that is, organizational culture, organizational structure, organizational processes, organization’s established communications channels, and so forth. The internal and external enterprise environmental factors will critically influence the performance of the software development project. It indicates that the application of appropriate project management skills and knowledge is necessary.

5. Conclusions

There is an old saying that goes “An ounce of prevention is worth a pound of cure.” Therefore, if we can understand the encountered risks and pay more attention in advance, it probably can mitigate loss for the results. In this study, we adopt the five risk dimensions, and associated twenty-two risk factors were developed by [4]. This can help the project managers to have an overview of the global picture of risk. Then, we apply the Fuzzy LinPreRa method which can simplify the Fuzzy AHP method and also avoid the necessity of checking the consistency in the decision-making process to assess project risk for software development. Because in the Fuzzy AHP, if there are criteria/attributes, it needs   pairwise comparisons, but the Fuzzy LinPreRa just requires   comparisons and maintains the decision matrices consistency. The advantage of applying Fuzzy LinPreRa approach compared with Fuzzy AHP is that the information demand has been significantly reduced, especially in obtaining information from practitioners. That is, it is more convenient to acquire the judgments of practitioners or experts of software development industry through a questionnaire.

The evaluation results of the experts in both groups implied that the impact degrees of the risk dimensions are the same whatever the rule on the software development project. Although there are some differences in the ranking of risk factors for each risk dimension, the results should prove to be a valuable reference for software developers. According to the results of the model built, it can be seen that the proposed model can benefit the stakeholders of software development projects and help them recognize what risk factors they may encounter and to facilitate drawing up project risk management strategies for the adequate allocation of resources.

References

H. M. Lee, “Applying fuzzy set theory to evaluate the rate of aggregative risk in software development,” Fuzzy Sets and Systems, vol. 79, no. 3, pp. 323–336, 1996.

Y. H. Kwak and J. Stoddard, “Project risk management: lessons learned from software development environment,” Technovation, vol. 24, no. 11, pp. 915–920, 2004.

M. de Oliveira Barros, C. M. L. Werner, and G. H. Travassos, “Supporting risks in software project management,” The Journal of Systems and Software, vol. 70, no. 1-2, pp. 21–35, 2004.

S. T. Lu and S. H. Yu, “Risk factors assessment for software development project based on fuzzy decision making,” International Journal of Information and Electronics Engineering, vol. 2, no. 4, pp. 596–600, 2012.

T.-C. Wang and Y.-H. Chen, “Applying fuzzy linguistic preference relations to the improvement of consistency of fuzzy AHP,” Information Sciences, vol. 178, no. 19, pp. 3755–3765, 2008.

E. Herrera-Viedma, F. Herrera, F. Chiclana, and M. Luque, “Some issues on consistency of fuzzy preference relations,” European Journal of Operational Research, vol. 154, no. 1, pp. 98–109, 2004.

B. W. Boehm, “Software risk management: principles and practices,” IEEE Software, vol. 8, no. 1, pp. 32–41, 1991.

H. M. Lee and L. Lin, “Fuzzy risk presumptive evaluation in software development,” International Journal of Innovative Computing, Information and Control, vol. 7, no. 7, pp. 3881–3889, 2011.

J. Jiang and G. Klein, “Software development risks to project effectiveness,” The Journal of Systems and Software, vol. 52, no. 1, pp. 3–10, 2000.

D. X. Houston, G. T. Mackulak, and J. S. Collofello, “Stochastic simulation of risk factor potential effects for software development risk management,” The Journal of Systems and Software, vol. 59, no. 3, pp. 247–257, 2001.

G. Büyüközkan and D. Ruan, “Choquet integral based aggregation approach to software development risk assessment,” Information Sciences, vol. 180, no. 3, pp. 441–451, 2010.

X. N. Lu and Q. G. Ma, “Risk analysis in software development project with owners and contractors,” in Proceedings of the IEEE International Engineering Management Conference: Innovation and Entrepreneurship for Sustainable Development (IEMC '04), vol. 2, pp. 789–793, October 2004.

T. L. Saaty, The Analytic Hierarchy Process, McGraw-Hill, New York, NY, USA, 1980.

J. J. Buckley, “Ranking alternatives using fuzzy numbers,” Fuzzy Sets and Systems, vol. 15, no. 1, pp. 21–31, 1985.

S.-J. Chen and C.-L. Hwang, Fuzzy Multiple Attribute Decision Making-Method and Applications, Springer, New York, NY, USA, 1992.

T. L. Saaty and L. G. Vargas, The Logic of Priorities, Kluwer Academic, Boston, Mass, USA, 1982.

T. Y. Hsieh, S. T. Lu, and G. H. Tzeng, “Fuzzy MCDM approach for planning and design tenders selection in public office buildings,” International Journal of Project Management, vol. 22, no. 7, pp. 573–584, 2004.

S. T. Lu, “Using the fuzzy multiple criteria decision making approach for risk evaluation on investment of overseas project,” in Proceedings of the 9th International Conference on Machine Learning and Cybernetics (ICMLC '10), vol. 4, pp. 2031–2036, July 2010.