Journal of. Risk Analysis of the Waterfall Model for Educational Software Development. Abstract

(1)

1 Vol. 4 No. 2 July – December 2014

Journal

Journal of

of of of Industrial Industrial Industrial Industrial Technology Technology Technology UbonTechnology Ubon RatchathaniUbonUbonRatchathaniRatchathani Rajabhat RatchathaniRajabhat Rajabhat University Rajabhat University University University

Risk Analysis of the Waterfall Model for

Educational Software Development

Prawit Simmatun1_{, Songsak Songsanit}2_{, Kanok Samavardhana}3*_{and Chaleenuch Khonsue}4 1,2,3*_{Computer Education Rajabhat Maha Sarakham University}

4_{Rajamonkala University Sakhon Nakhon Thailand}

E-mail : [email protected]*

Abstract

This study is a survey research focusing on experts’ opinions in the area of software development; about the risk that may occur when they use a Waterfall Model in their software development process. Because risk analysis process does not include in the model. Therefore, interesting problem is finding any hidden risk in the model. Structural interviewing and questionnaires are used in the phases of data collection. Samples are twenty-six experts in field of software development and/or software engineering from eight of Thailand’s universities who have at least 3 years experiences in software development and used to develop successfully software. The Delphi Technique is used in this research. Research results are divided into three phases, the first; experts can identify many risks n their development process. The order of the risk in their opinion is 1) the customer requirements step by mean = 4.12, 2) mean = 3.80 in maintenance and 3) mean = 3.69 in test step. Secondly, five rating scale of the risks identified in the first phase questionnaires are weighted by the developers to clarify those risks. And the last as expected by every experts who confirm their opinions

The results indicated that 95% of the specialists mentioned that the highest risk was the negotiation between software developers and the customers. The second risk was on unlimited cost of the project, and undecided customers share the same risk level as.

Keywords : Risk Analysis, Waterfall Model, Educational software development,

(2)

ปที่ 4 ฉบับที่ 2 กรกฎาคม – ธันวาคม 2557 2

1. INTRODUCTION

A risk analysis is an important phase in software development process. A lack of the risk analysis may lead to project failure. Risk analysis, now becomes to a modern topics in software development project [14]. Even through, in an earliest methods [3] are still widely used [11], Waterfall Model, which is powerful for developing a large scale software, it does not include the risk analysis into its model.

Thus, in software development models, such as Spiral Model, the risk analysis is integrated into the process as a part of software development. For instances, in case of Spiral Model, risk assessments are rigidly anchored [15] and performed every iteration of development process. This makes the model complicated, go it does not much used as Waterfall Model [12]. May be, if the risk assessment tailored down, it would have many advantages and could even more use in Thailand. For Incremental Model, another popular model, this model is divided into four big phases. Firstly, the inception phases, in this phase the following deliverables are made: a vision document, an initial exploration of customer requirements, a business case, an initial project plan and an initial risk assessment. Secondly, the elaboration phases, in this phase, actually, understanding what the customer wanted and also, decided and well documented the risk of the project and to eliminate the risk early in the project [2]. The risk should be analyzed an eliminated in the first two phases. But, there are some serious disadvantages as following: Each phase of an iteration is rigid and do not overlap each other, and problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle [7]. For Prototyping Model, one of software engineering model which likely to foster quality outcomes, and satisfy the requirements of programmer and educator [6]. But, the most disadvantages of this model is a danger of raising expectation, to develop stable it required time and more effort etc. And the last, Waterfall Model, is widely used to develop educational software known as “Linear Sequential Model”, which is down sized to develop medium scale software project, such as, Linux TLE, PlaDao Office etc.

(3)

Journal

Journal of

2. CONCEPTUAL FRAMEWORK

By studying all risk assessment processes of four software engineering models consisted of: Waterfall Model, Spiral Model, Incremental Model and Prototyping Model. Analyzing found that four models above, excepted Waterfall Model, there are risk analysis process combined with its model. Why not risk analysis include in this model? Waterfall Model was the oldest model used by expert in specific job; therefore, risk analysis was not necessary in that time. Spiral Model has risk analysis perform in every iteration, Spiral Model; therefore, have to use more experts to analyzed and more cost in the model. Also, based on Waterfall Model, Incremental Model combined with risk analysis in two first phases including; initialized risk assessment in an inception phase and risk reduction in an elaboration phase. The research teams’ evolutionary framework will make risk analysis process to be the first step of the model by replacement requirement analysis as well as Incremental Model, but more explicitly as part of model, as shown in Figure 1. Expectation of the frame work is an efficiently method of software development based on Waterfall Model.

Figure 1 Conceptual Framework

3 . PURPOSES OF THE STUDY

To find and analyze the risks that may occur in each step of the Waterfall Model, finding guidelines for the risks assessment and finding the method to control the risks in the process of the university-based software development using twenty-six experts who

Customer Design Implementation Test Maintenance Risk analysis 1 st

(4)

have at least 3 years of experiences in software development from 8 universities in Thailand.

4 . METHODOLOGY

To study the theories about software engineering, the software development models, the software design process and review the researches based on risks analysis in software development process. Then define the scope of this research as following: Finding and collecting on the risk items that may occur in the process using Delphi Technique, analyzing the risks found assess or evaluate and prioritized the risks from prior analyzed results.

5. EVALUATION RESULTS

Data analysis was analyzed in three phases according to the step of Delphi Technique as following: open end questionnaires that allowed experts state their opinions freely, after grouping those opinions the finding can be conclusion as shown in Table 1.

Table 1 Risk in each step of Waterfall Model shown as descending order

Steps n Mean S.D. Customer Req. 26 4.12 0.357 Maintenance 26 3.80 0.864 Test 26 3.69 0.772 Design 26 3.67 0.802 Implementation 26 3.45 0.789

Table 1 twenty-six experts’ opinions indicated that the highest risk might occur in the first step of the Waterfall original model at average of 4.12, secondly, the maintenance phase, with the average of 3.80, thirdly, test step with average of 3.69 and so on.

(5)

Journal

Journal of

Table 2 Customer Requirement phase

Customer Req. Weighting (Percent)

1 2 3 4 5 A1 - - 11.5 50 38.5 A2 - - 3.8 34.6 61.5 A3 - - 15.4 26.9 57.7 A4 - 3.8 34.6 26.9 34.6 A5 30.8 57.7 11.5 A6 30.8 57.7 11.5 A7 3.8 3.8 42.3 50 A8 11.5 19.2 42.3 26.9 A* See Appendix

From Table 2 data was collected in second step, experts weighted to any risk, result was 61.5% of the experts had pointed the most risk in customer requirements is A2 (Developer and customer cannot establish right communication.)

Table 3 Design phase

Design Weighting (Percent)

1 2 3 4 5 B1 7.7 3.8 23.1 42.3 23.1 B2 7.7 7.7 30.8 38.5 15.4 B3 3.8 - 30.8 38.5 26.9 B4 3.8 7.7 19.2 53.8 15.4 B* See Appendix

From Table 3 26.9% of the experts showed that the most risk is B3 (Security part was not designed included)

(6)

Table 4 Implementation

1 2 3 4 5 C1 - 11.5 34.6 38.5 15.4 C2 3.8 15.4 38.5 34.6 7.7 C3 3.8 11.5 46.2 30.8 7.7 C4 3.8 15.4 23.1 26.9 30.8 C5 3.8 11.5 30.8 38.5 15.4 C* See Appendix

From Table 4 30.8% of the experts indicated the most risk is C4 (Are the team members following the software process as it is documented)

Table 5 Test phase

1 2 3 4 5 D1 - 15.4 34.6 15.4 34.6 D2 - 11.5 23.1 42.3 23.1 D3 7.7 - 23.1 50.0 19.2 D4 11.5 3.8 15.4 53.8 15.4 D* See Appendix

From Table 5 34.6% of the experts indicated the most risk is D1 (Is there a formal inspector)

(7)

Journal

Journal of

Table 6 Maintenance phase

1 2 3 4 5 E1 3.8 7.7 11.5 53.8 23.1 E2 3.8 7.7 23.1 42.3 23.1 E3 3.8 - 42.3 26.9 26.9 E4 3.8 3.8 19.2 42.3 30.8 E* See Appendix

From Table 6 30.8% of the experts indicated the most risk is E4 (was users’ feedback always collected and analyzed)

Although, the project had finished, the risk still could be occur. As a result, experts’ opinions synthesize a new conceptual framework based on an original five-step Waterfall Model integrated risk analysis process into the top of the original model, into an implementation phase and also, into maintenance phase in order. As shown in Figure 2.

Figure 2 New Conceptual Frameworks

Customer Design Implementation Test Maintenance Risk analysis 1 st Risk analysis 2 nd Risk analysis 3 rd

(8)

6. CONCLUSIOS AND FUTURE WORK

In this paper, a new conceptual model, a risk analysis of Waterfall Model for educational software development has been proposed as shown in Figure 4. An original framework, the process of risk analysis was the first step of the model, however, the conclusion of experts’ opinions suggested that the risk not only occurred in the first step of the model, but, may occur all the time the software development process is still running also. Thus, the new conceptual model consist of 5 original phases and 3 phases of risk analysis increased, however, risk analysis phase may greater than Incremental Model but, less than using in Spiral Model, so development process cost will be in the middle of both Spiral and Incremental Model. Since, development process still as easy as Waterfall Model, reduce risk as early as Incremental Model and safely from risk as Spiral Model. For future work, trying to develop university-based software, medium scale, and lift up the new conceptual framework to new software engineering stable model.

7. REFERENCES

[1] Braude, Eric J. Software Engineering an Object-Oriented Perspective. 2 edition. USA: John Wiley & Son Inc. New York; 2010.

[2] Bunea, Dan. Introduce to Iterative, Incremental Framework for building software projects [Internet]. [Accessed October 2003] Available from: http://www.codeproject. com/en/design/IterativeInc Framework.asp.

[3] Burd, Leo. Development of Software for Educational Activities, Brazil: State University of Campinas; 1999.

[4] Green, Darryl and Ann Di Caterino, A Survey of System Development Process Models Center for Technology in Government. New York: University of Albany; 1998.

[5] Dobbs, Theresa. Introduction to the Personal Software Process [Internet]. Available from: http://lifelong.engr.utexas.edu/shortcourse.cfm?course_num=791.

[6] Humphrey, watt S. The Personal Software Process. 1 edition. USA: John Wiley & Son Inc. New York; 1996.

[7] Kennedy, David M. Software Development Teams in Higher Education: an Educator’s View. Australia: the University of Melbourne; 2010.

(9)

Journal

Journal of

of of of Industrial Industrial Industrial Industrial Technology Technology Technology UbonTechnology Ubon RatchathaniUbonUbonRatchathaniRatchathani Rajabhat RatchathaniRajabhat Rajabhat University Rajabhat University University University [8] Lewallen, Raymond. Software Development Life Cycle Models. Available from:

http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx [9] Lindsay Groves and Ray Nickson. A Survey of Software Development Practices in the

New Zealand Software Industry. New Zealand: School of Mathematical and Computing Sciences, Victoria University of Waikato; 2006.

[10] Lu Xiangnan and Ge Yali, Risk Analysis in Project of Software Development. School of Management University; Zhejiang; P.R.China; 2003.

[11] Mark Burgess and Trond Reitan. A risk analysis of disk backup or repository maintenance. Science of Computer Programming; 2006.

[12] Michael J Rees. A Feasible User Story Tool for Agile Software Development. Australia: School of Information Technology; Bond University; 2002.

[13] Nabil Mohammed, Ali Munassar and A. Govardhan. A Comparison between Five Models of Software Engineering. IJCSI International Journal of Computer Science Issues, Vol. 7; Issue 5; 2010

.

[14] Pressman, R.A. Software engineering: A practitioner’s approach. Fourth ed. New York: McGraw-Hill Companies Inc.; 1997.

[15] Wu Ching-She and Dick B. Simmons. Software Project Planning Associate (SPPA): A Knowledge-Based Approach for Dynamic Software Project Planning and Tracking; 2000. [16] Easterbrook Steve, Software Lifecycle. Department of Computer Science, University of

Toronto, Canada; 2001.

[17] http://www.the-software-experts.ed/e_dta-sw-process.htm

8. APPENDIX

A1 Non-Assessment of number of customers, investment and development duration. A2 Could developer and customer establish right communication?

A3 Customer could not clarify their requirements

A4 Is the customer technically sophisticated in the product area? A5 Developer did not interest in the size of software.

A6 Are the team members following the software process as it is documented? A7 Does the customer have a solid idea of what is required?

(10)

A8 Project budgeting dose not estimate.

B1 Developer can not clarify the process to be used on this project.

B2 Has your organization developed a written description of the software process to be used on this project?

B3 Security part was not designed include. B4 Designing Process was not inspected by other.

C1 Are compilers or code generators available and appropriate for the product to built?

C2 There is no any appropriate tools.

C3 Have members of the project team received training in each of the tools? C4 Are the team members following the software process as it is documented? C5 Do the people has the right combination of skills?

D1 Is there formal inspector?

D2 Is there inspects both unit and the whole? D3 Is there document in every inspection?

D4 Are the results of each formal technical review documented, including defects found and resources used?

E1 Is there re-analysis when defects were found?

E2 Do the documents always readjustment every time software was adjusted? E3 Is there a configuration document?