Pavur, Robert

Windsor, John

Zhang, Xiaoni

English

AIS Electronic Library (AISeL)

Association for Information SystemsAIS Electronic Library (AISeL)AMCIS 2001 Proceedings Americas Conference on Information Systems(AMCIS)December 2001Investigating Information Systems FailuresXiaoni ZhangUniversity of North TexasJohn WindsorUniversity of North TexasRobert PavurUniversity of North TexasFollow this and additional works at: http://aisel.aisnet.org/amcis2001This material is brought to you by the Americas Conference on Information Systems (AMCIS) at AIS Electronic Library (AISeL). It has been acceptedfor inclusion in AMCIS 2001 Proceedings by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contactelibrary@aisnet.org.Recommended CitationZhang, Xiaoni; Windsor, John; and Pavur, Robert, "Investigating Information Systems Failures" (2001). AMCIS 2001 Proceedings. 280.http://aisel.aisnet.org/amcis2001/2802001  Seventh Americas Conference on Information Systems 1447INVESTIGATING INFORMATION SYSTEMS FAILURESXiaoni ZhangBCIS DepartmentUniversity of North Texaszhangx@unt.eduJohn WindsorBCIS DepartmentUniversity of North Texaswindsor@unt.eduRobert PavurBCIS DepartmentUniversity of North Texaspavur@unt.eduAbstractCompanies have invested large amounts of money on information systems development. Unfortunately, not allinformation systems developments are successful. An extensive body of research stream has focused onsoftware reliability studies for the past two decades and many software reliability growth  models have beendeveloped for the estimation of software reliability and the number of errors embedded in the software.Comparatively few studies relate software structure to information systems failures. In this study therelationships among variables business requirements change, software complexity, program size and the errorrate in each phase of software development life cycle are tested and interpretations of the hypotheses testingare provided.Keywords: Information systems failure, software complexityIntroductionSoftware development includes analysis, design, development and  maintenance. Activities carried out and requirements set ineach phase determine the final functions  of the systems. Errors occurring in any of these phases affect the performance of thesystems and affect the costs in the keeping the systems up and running and meeting user’s requirements (Huq 2000). Banker, Davis and Slaughter (2000) developed a two-stage model in which software complexity is a key intermediate variablethat links design and development decisions to their downstream effects on software maintenance. Their study suggests thatsoftware development practices are related to maintenance performance. Adhikari (1996) stated that software development shouldput more effort into defining business requirements. As the understanding of the software development process improves, a clearerrelationship is found between that software complexity and the  location of faults (Mata-Toledo and Gustafson). The literaturesuggests that software practices in software development life cycle, software complexity, and business requirement are all relatedto failures (Zhang and Pham 1998). Previous research has not focused on empirical research investigating a theoretical model which operationalizes variables thatcause errors, especially business requirements change. A change in business requirements causes failures. In this study, hypothesesare tested using variables suggested in the literature. These variables include business requirements change, software complexity,and program size. We use a logistic regression model to test the contribution of the variables business requirements change,software complexity, and program size in predicting error rate in the software development life cycle.IS and S/W Design, Development, and Use1448 2001  Seventh Americas Conference on Information SystemsBusiness RequirementsSoftware ComplexitySoftware failureProgram SizeTotal lines of executable codeResearch FrameworkThe research framework consists of independent variables business requirements, program size, software complexity anddependent variable software failure.Measurement of the VariablesTable 1. Variables and MeasurementsVariables MeasurementSoftware Complexity Is measured by Cyclomatic complexityProgram Size The total number of lines in the programTotal number of lines in Procedure division The total number of executable lines in procedure divisionBusiness requirements change The frequency of the modification that is due to businessrequirements changeDesign failure rate The frequency of modification that is caused by designstageAnalysis failure rate The frequency of modification that is caused by analysisstageProgramming failure rate The frequency of modification that is caused byprogramming stageResearch MethodologyLongitudinal data analysis was performed in this study by analyzing data collected by professional programmers and auditors ina gas company between 1982-1991. Both qualitative and quantitative data were documented for 100 COBOL programs. Theseprograms include commercial bill, statistical analysis, print programs, report programs, commercial bill cancellation programs,commercial bill zero balance programs, deposit premium programs, list of commercial policies programs, backup statistical systemtransaction programs, annual warehouse purge of cancelled/expired policies. The smallest program has 101 lines of codes andthe largest one has 18488 lines of codes. To gain insight into the relationship of software failures with attributes about software, 100 COBOL programs are selected forthis study from a single company. We are interested in knowing whether the independent variables business requirements change,software complexity and program size are good predictors of error rate in each phase of the software development. Because theindependent variables are a mixture of categorical and continuous variables, the multivariate normality assumption will not hold.Logistic regression does not require the strict normality assumptions that standard discriminant analysis assumes. Thus, thisstatistical procedure is appropriate for analyzing the data associated with software error rate. We present several hypothesesconcerning the relationship between independent variables and software failure and use logistic regression to determine ifsignificant relationships existed. Zhang et al./Investigating Information Systems Failures2001  Seventh Americas Conference on Information Systems 1449Hypotheses TestingH1a: There is relationship between design failure rate and program size controlling for business requirements, cyclomaticcomplexity and total procedure lines.H2a : There is relationship between design failure rate and business requirements controlling for program size, totalprocedure lines and cyclomatic complexity.H3a: There is relationship between design failure rate and cyclomatic complexity controlling for business requirements,program size, and cyclomatic complexity.H4a: There is relationship between design failure rate  and total procedure lines controlling for business requirements,essential complexity, and program size.H5a: There is relationship between analysis failure rate and business requirements controlling for program size, essentialcomplexity, and cyclomatic complexity.H6a: There is relationship between analysis failure rate and total procedure lines controlling for program size, businessrequirements and cyclomatic complexity.H7a: There is relationship between analysis failure rate and cyclomatic complexity controlling for business requirements,total procedure lines and program size.H8a: There is relationship between analysis failure rate and program size controlling for business requirements, totalprocedure lines and cyclomatic complexity.H9a: There is a relationship between program failure rate and business requirements controlling for program size, totalprocedure lines, and cyclomatic complexity.Table 2.  Logistic Regression Parameter for Models with DependentVariable Analysis, Design and Programming Failure RateAnalysis Design ProgrammingParameter Pr > ChiSq Pr > ChiSq Pr > ChiSqIntercept 0.0105 0.0062 0.0030Business requirements 0.0008 <.0001 <.0001Cyclomatic complexity 0.0410 0.1149 0.6907Total number of lines 0.0199 0.5095 0.9155Total lines in procedure 0.0199 0.1619 0.5743Table 2 presents the significant levels of the four independents variables, business requirements, cyclomatic complexity, totalnumber of line, and total lines in procedure. At analysis stage, all the four independent variables are significant. At design stageonly business requirements and cyclomatic complexity are good predicators for failures. At programming stage, only businessrequirement is significant (p < 0.0001). ConclusionsPractices in different phases of software development life cycle impact the quality, performance and stability of informationsystems. Software attributes such as software complexity and program size impact the ease of making changes in the program.These attributes also affect software volatility. Our study shows that business requirements have a significant relationship withdesign failure rate, analysis failure rate and program failure rate. Companies face challenges, regulations and competitionsconstantly. Opportunities lead to changes in business requirements. Changes in business requirements will inevitably forcechanges in information systems. Information systems need to be adaptive and flexible to cope with the changes in businessIS and S/W Design, Development, and Use1450 2001  Seventh Americas Conference on Information Systemsrequirements. The findings suggest that management should allocate more resources to analysis and design stages of softwaredevelopment life cycle. Code produced at programming stage is usually decent and not requirement much change. Systemmanagement needs to monitor environmental change and create incentives for better design.Software complexity, program size and number of the procedure line play a role in determining analysis failure rate. The morecomplex a system is, the more likely it will have analysis failure. Typically, the larger the program, the higher the analysis failurerate will be. Extra attention should be given to the large and complex programs during the analysis phase so as to reduce thelikelihood of program changes. Developing an adaptive system is the way to have a sustainable system that can live with thechanges in business environment. ReferencesAdhikari, R. “Developers Benefit from a Process Blueprint,” Software Magazine, (16:3),1996, pp. 59-69. Banker, R.D., Datar, S.M., Kemerer, C.F., Zweig, D. “Software  Complexity and Maintenance Costs,” Communications of theACM (36:11), 1993, pp. 81-94Banker, R. D. Davis, G.B. Slaughter, S. “A Software Development Practices, Software Complexity, and Software MaintenancePerformance: A Field Study,” Management Science (44:4), 1998, pp. 433-450. Huq, F. “Testing in the Software Development Life-cycle: Now or Later,” International Journal of Project Management (18:4),2000, pp. 243-250 . Khoshgoftaar, T. M. Munson, J. C. Lanning, D. L. “Alternative Approaches for the Use of Metrics to Order Programs byComplexity,” Journal of Systems & Software (24:3), 1994, pp. 211-221.Mata-Toledo, R. A. Gustafson, D. A. “A Factor Analysis of Software Complexity Measures.  Journal of Systems & Software(17:3), 1993, pp. 267-273. Pham, H. Software Reliability Assessment: Imperfect Debugging and Multiple Failure Types in Software Development, Technicalreport, EG&G-RAAM-10737, Idaho National Engineering Laboratory, 1993.Zhang, X. Pham, H. A software cost model with warranty cost, error removal times and risk costs. IIE Transactions. (30:12),1998, pp. 1135-1142.  Zhang, X. and Pham, H. “An Analysis of Factors Affecting Software Reliability,” Journal of Systems & Software. 50(1), 2000,pp. 43-56. 

Investigating Information Systems Failures

https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1719&amp;context=amcis2001

Investigating Information Systems Failures

Abstract

Similar works

Full text

Available Versions

AIS Electronic Library (AISeL)