Software Dysfunction: Why Do Software Fail?

Abstract

Software is pervasive in modern society, but we are often unaware of its presence until problems arise. Software is one of the most important and yet one of the most economically challenging techniques of this era. As a purely intellectual product, it is among the most labor-intensive, complex, and error-prone technologies in human history. Until the 1970s, programmers were very meticulous in planning their code, rigorously checking code, providing detailed documentation, and exhaustive testing before the software is released to users. However, as computer became widespread, attitudes changed. Instead of meticulously planning code, the attitude of the average programmer today is possibly hacking sessions or writing any sloppy piece of code and the compiler will run diagonally, a situation called, “code and fix”, where the programmer tried to fix errors one by one until the software compiled properly. As programs grew in size and complexity, the limits of this “code and fix” approach became evident. In this paper, we studied the various reasons why software fails. Our studies reveal that the major reasons why software fails are poor or no design at all, inadequate testing of codes, and attitudinal changes among programmers and other factors.

Share and Cite:

Ogheneovo, E. (2014) Software Dysfunction: Why Do Software Fail?. Journal of Computer and Communications, 2, 25-35. doi: 10.4236/jcc.2014.26004.

Conflicts of Interest

The authors declare no conflicts of interest.

References

[1] Kumaresh, S. and Ramachandran, B. (2012) Defect Prevention Based on 5 Dimensions of Defect Origin. International Journal of Software Engineering & Applications (IJSEA), 3, 87-98.
http://dx.doi.org/10.5121/ijsea.2012.3407
[2] Nggada, S.H. (2012) Software Failure Analysis at Architecture Level Using FMEA. International Journal of Software Engineering and Its Applications, 6, 61-74.
[3] Dijkstra, E.W. (1976) A Discipline of Programming. Prentice-Hall, Upper Saddle River.
[4] IEEE Standard 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, 1990.
[5] Pressman, R.S. (2007) Software Engineering: A Practitioner’s Approach. 6th Edition, McGraw-Hill, Boston.
[6] Rothenberger, M.A., Dorley, K.J., Kulkarin, U.R. and Nada, N. (2003) Strategies for Software Reuse: A Practical Component Analysis of Reuse Practices. IEEE Transactions on Software Engineering, 29, 825-837. http://dx.doi.org/10.1109/TSE.2003.1232287
[7] Storey, N. (1996) Safety-Critical Computer Systems. Addison Wesley Longman, London.
[8] Chu, T.L., Martinez-Guridi, G., Yue, M. and Lehner, J. (2006) A Review of the Software-Induced Failure Experience. American Nuclear Plant Instrumentation Control and Human Machine Interface Technology.
[9] Robertson, P. and Williams, B. (2006) Automatic Recovery from Software Failure. Communications of the ACM, 49, 41-47. http://dx.doi.org/10.1145/1118178.1118200
[10] Box, G. and Hunter, S. (2010) 25 Great Quotes of Software Testers. https://hexawise.com/posts/25-great-quotes-for-software-testers
[11] Mann C. C. (2002) Why Software Is So Bad, Technology Review, July/August, 2002, 33-38. www.technologyreview.com,
[12] Chillarge, R., Bhandari, I.S., Chaar, J.K., Halliday, M.J., Moebus, D.S., Ray, B.K. and Wong, M.-Y. (1992) Orthogonal Defect Classification—A Concept for In-Process Measurements. IEEE Transactions on Software Engineering, SE-18, 94-96.
[13] Hobbs, C. (2011) The Changing Nature of Software Failure. China Technology Innovation Conference.
[14] Jalote, P., Murphy, B., Garzia, M. and Errez, B. (unpublished) Measuring Reliability of Software Products.
[15] Weiner, L.R. (1993) Digital Woes. Addison-Wesley, Boston.
[16] Slabodkin, G. (1998) Software Glitches Leave Navy Smart Ship Dead in the Water. Government Computer News, July 13. http://gcn.com/Articles/1998/07/13/Software-glitches-leave-Navy-Smart-Ship-dead-in-the-water.aspx
[17] Ehrlich, W.K., Iannino, A., Prasanna, B.S., Stampfel, J.P. and Wu, J.R. (1999) How Faults Cause Software Failure: Implications for Software Reliability Engineering. Int’l Symposium on Software Reliability Engineering, Austin.
[18] Smedley, R. (2009) Trusted Software? Between the Button and the Bomb, Is There an Operating System You Can Trust? LinuxPro, March, 70-73. http://www.linuxformat.co.uk
[19] Sommerville, I. (2006) Software Engineering. 8th Edition, Addison-Wesley, Boston, 5-6.
[20] Williams, L. (2006) Testing Overview and Black-Box Testing Technique, 34-59.
http://agile.csc.ncsu.edu/SEMaterials/BlackBox.pdf
[21] Carlone, R.V. (1991) Patriot Missile Defense: Software Problems Led to System Failure at Dhahran, Suadi Arabia. http://www.ima.umn.edu/~arnold/disasters/patriot.html
[22] Chillarege, R. (1996) What Is Software Failure? IEEE Transactions on Reliability, 45, 354-355. http://dx.doi.org/10.1109/TR.1996.536980
[23] Lyu, M.R.-T. (2002) Software Reliability Theory, Encyclopedia of Software Engineering. John Wiley & Sons, Inc, Hoboken.
[24] Charette, R.N. (2005) Why Software Fails [Software Failure]. IEEE Spectrum, 42, 42-49. http://dx.doi.org/10.1109/MSPEC.2005.1502528
[25] Krasner, H. (1998) Using the Cost of Quality Approach for Software. CROSSTALK: The Journal of Defense Software Engineering, 11, 6-11.
[26] Dowson, M. (1997) The ARIANE-5 Software Failure. ACM SIGSOFT Software Engineering Notes, 22, 84. http://dx.doi.org/10.1145/251880.251992
[27] Knuth, D.E. (1992) The Errors of TeX: Software Practice and Experience, in Literature Programming. CSLI Lecture Notes, 19, 607-681.

Copyright © 2024 by authors and Scientific Research Publishing Inc.

Creative Commons License

This work and the related PDF file are licensed under a Creative Commons Attribution 4.0 International License.