Richard J. Sutcliffe
ABSTRACT
Past generations of software developers were well on the way to building a software engineering mindset/gestalt, preferring tools and techniques that concentrated on safety, security, reliability, and code re-usability. Computing education reflected these priorities and was, to a great extent organized around these themes, providing beginning software developers a basis for professional practice. In more recent times, economic and deadline pressures and the de-professionalism of practitioners have combined to drive a development agenda that retains little respect for quality considerations. As a result, we are now deep into a new and severe software crisis.
Scarcely a day passes without news of either a debilitating data or website hack, or the failure of a mega-software project. Vendors, individual developers, and possibly educators can anticipate an equally destructive flood of malpractice litigation, for the argument that they systematically and recklessly ignored known best development practice of long standing is irrefutable. Yet we continue to instruct using methods and to employ development tools we know, or ought to know, are inherently insecure, unreliable, and unsafe, and that produce software of like ilk.
The authors call for a renewed professional and educational focus on software quality, focusing on redesigned tools that enable and encourage known best practice, combined with reformed educational practices that emphasize writing human readable, safe, secure, and reliable software. Practitioners can only deploy sound management techniques, appropriate tool choice, and best practice development methodologies such as thorough planning and specification, scope management, factorization, modularity, safety, appropriate team and testing strategies, if those ideas and techniques are embedded in the curriculum from the beginning.
The authors have instantiated their ideas in the form of their highly disciplined new version of Niklaus Wirth's 1980s Modula-2 programming notation under the working moniker Modula-2 R10. They are now working on an implementation that will be released under a liberal open source license in the hope that it will assist in reforming the CS curriculum around a best practices core so as to empower would-be professionals with the intellectual and practical mindset to begin resolving the software crisis.
They acknowledge there is no single software engineering silver bullet, but assert that professional techniques can be inculcated throughout a student's four-year university tenure, and if implemented in the workplace, these can greatly reduce the likelihood of multiplied IT failures at the hands of our graduates. The authors maintain that professional excellence is a necessary mindset, a habit of self-discipline that must be intentionally embedded in all aspects of one's education, and subsequently drive all aspects of one's practice, including, but by no means limited to, the choice and use of programming tools.
- Kowarsch, B. and Sutcliffe, R. J. 2016. Modula-2 R10 Repository. https://bitbucket.org/trijezdci/m2r10/.Google Scholar
- Kowarsch, B. and Sutcliffe, R. J. 2016. Modula-2 R10 Information Site. http://www.modula-2.info.Google Scholar
- Chua, A. Y. K. 2009. Exhuming IT projects from their graves: an analysis of eight failure cases and their risk factors. The Journal of Computer Information Systems. 49, 3, 31--39.Google Scholar
- Charette, R. N. 2005. Why software fails. IEEE spectrum. http://www.rose-hulman.edu/Users/faculty/young/OldFiles/CS-Classes/csse372/201310/Readings/WhySWFails-Charette.pdf.Google Scholar
- Purao, S. and Desouza, K. 2011. Looking for clues to failures in large-scale, public sector projects: A case study. 44th Hawaii International Conference on System Sciences (HICSS). Google ScholarDigital Library
- Goldstein, H. 2005. Who killed the virtual case file? {case management software}. Spectrum. Google ScholarDigital Library
- Ewusi-Mensah, K. 2003 Software development failures. MIT Press. Google ScholarDigital Library
- Linberg, K. R. 1999. Software developer perceptions about software project failure: a case study. Journal of Systems and Software. 49, 177--192. Google ScholarDigital Library
- Shaw, R. and Culbert, L. 2015 12 14. Major B.C. government IT projects go over budget or end up missing key features. Vancouver Sun.Google Scholar
- Shaw, R. and Culbert, L. 2014 05 29. The B.C. government's $182-million computer system just won't work. Vancouver Sun.Google Scholar
- Sherlock, T. 2015 09 21. Another year, another computer foulup affecting B.C. teachers. Vancouver Sun.Google Scholar
- Sherlock, T. and Crawford, T. 2015 08 03. B.C.'s auditor general says technology used by public health system inefficient. Vancouver Sun.Google Scholar
- Shaw, R. and Culbert, L. 2015 12 15. The province and computers: Finding out what works and why. Vancouver Sun.Google Scholar
- Shaw, R. 2014 07 11. B.C. alone in using troubled software system to manage child welfare. Vancouver Sun.Google Scholar
- Shaw, R. and Culbert, L. 2015 12 15. B.C. not alone in bungling computer projects. Vancouver Sun.Google Scholar
- Verner, J., Sampson, J., and Cerpa, N. 2008. What factors lead to software project failure. Research Challenges in Information Science. RCIS 2008. Second international Conference on. 71--80.Google Scholar
- Williams, T. C. 2011 Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure. American Management Association. Google ScholarDigital Library
- Singpurwalla, N. D. and Wilson, S. P. 1994. Software reliability modeling. International Statistical Review. 62, 3, 289--317.Google ScholarCross Ref
- Phipps, G. 1999. Comparing observed bug and productivity rates for Java and C Software. Software - Practice and Wxperience. 29, 4, 345--358. Google ScholarDigital Library
- Tiwari, V. and Pandey, R. K. 2012. Some Observations on Bug Fixing Process and Defect Density of Open Source Software. International Journal of Advanced Research in Computer Science. 3, 1.Google Scholar
- Khomh, F., Dhaliwal, T., and Zou, Y. 2012. Do faster releases improve software quality? an empirical case study of mozilla firefox. Mining Software. Google ScholarDigital Library
- Chomal, V. S. and Saini, J. R. 2014. Significance of Software Documentation in Software Development Process. International Journal of Engineering Innovations and Research. 3.4, 410--416.Google Scholar
- Zhi, J., Garousi-Yusifoğlu, V., Sun, B., and Garousi, G. 2015. Cost, benefits and quality of software development documentation: A systematic mapping. Journal of Systems and Software. 99, 175--198.Google ScholarDigital Library
- van Loggem, B. 2014. Software documentation: a standard for the 21 st century. ISDOC '14 International Conference on Information Systems and Design of Communication. 149--154. Google ScholarDigital Library
- Arraki, K. S. 2016. Source code management with version control software. American Astronomical Society Meeting Abstracts. http://adsabs.harvard.edu/abs/2016AAS.22712701A.Google Scholar
- Gajda, W. 2013 Working with Well-Known Repositories. In Git Recipes, Springer.Google Scholar
- Miriam Quick, Ella Hollowood, Christian Miles and Hampson, D. World's Biggest Data Breaches. http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/.Google Scholar
- Gollmann, D. 2010. Computer Security. Wiley Interdisciplinary Reviews: Computational Statistics. 2, 5, 544--554. DOI=10.1002/wics.106.Google ScholarDigital Library
- Tian-yang, G., Yin-sheng, S., and You-yuan, F. 2010. Research on software security testing. World Academy of Science, Engineering and Technology. 70.Google Scholar
- Chess, B. and Arkin, B. 2011. Software security in practice. IEEE Security & Privacy. March/April. Google ScholarDigital Library
- Nunes, F. J. B. and Belchior..., A. D. 2010. Security engineering approach to support software security. Services (SERVICES-1) 2010 6th World Congress on. 48--55. Google ScholarDigital Library
- Myers, G. J., Sandler, C., and Badgett, T. 2015 The art of software testing. Wiley. Google ScholarDigital Library
- Al-Ahmad, W., Al-Fagih, K., Khanfar, K., Abuliel, S., and Abu-Salem, H. 2009. A taxonomy of an IT project failure: Root Causes. International Management Review. 5, http://search.proquest.com/openview/367d4e172fb56040e736cd2d5b6ae55b/1?pq-origsite=gscholar.Google Scholar
- Galorath, D. 2008. Software Project Failure Costs Billions... Better Estimation & Planning Can Help. Project Management.Google Scholar
- France, R. and Rumpe, B. 2007. Model-driven development of complex software: A research roadmap. Future of Software Engineering. Google ScholarDigital Library
- Evans, E. 2004. Domain-driven design: tackling complexity in the heart of software. books.google.com. http://www-public.tem-tsp.eu/~gibson/Teaching/CSC7322/ReadingMaterial/Evans03.pdf. Google ScholarDigital Library
- Jennings, N. R. 2001. An agent-based approach for building complex software systems. Communications of the ACM. 44.4). Google ScholarDigital Library
- Kerzner, H. R. 2013 Project management: a systems approach to planning, scheduling, and controlling. Wiley.Google Scholar
- Royce, W. 1998. Software project management. Pearson Education India. Google ScholarDigital Library
- Burke, R. 2013. Project management: planning and control techniques.cupa.ir.Google Scholar
- Curtis, B. and Walz, D. 2014 The Psychology of Programming in the Large: Team and Organizational. Academic Press.Google Scholar
- Dooley, J. 2011 Software development and professional practice. Springer. Google ScholarDigital Library
- Wirth, N. 1996. Recollections about the development of Pascal. History of programming languages---II. Google ScholarDigital Library
- Morris, R. 2009. Niklaus Wirth: Geek of the Week. http://fruttenboel.verhoeven272.nl/modula-2/data/NikGeek.pdf.Google Scholar
- Lindsey, C. H. 1996. A history of Algol 68. History of programming languages---II. Google ScholarDigital Library
- Böszörményi, L., Gutknecht, J., and Pomberger, G. 2000. The school of Niklaus Wirth: the art of simplicity. books.google.com.Google Scholar
- Wirth, N. 1982 Programming in Modula-2. Springer-Verlag. Google ScholarDigital Library
- Wirth, N. 1983 Programming in Modula-2. Springer-Verlag. Google ScholarDigital Library
- Wirth, N. 1985 Programming in Modula-2. Springer-Verlag. Google ScholarDigital Library
- Wirth, N. 1988 Programming in Modula-2. Springer-Verlag. Google ScholarDigital Library
- Andrews, D. J., Cornelius, B.J., Henry, R.B., Sutcliffe, R.J., Ward, D.P., Woodman, M. 1994 Information technology -- Programming Languages -- Modula-2 International Standard (ISO/IEC 10514-1). ISO.Google Scholar
- Sutcliffe, R. J. 1997 Information technology -- Programming Languages -- Generic Modula-2 (ISO/IEC 10514-2). ISO/IEC.Google Scholar
- Henne, E., Wiedemann, A., Woodman, M., Lancaster, J. 1996 Information technology -- Programming Languages -- Standard Object Oriented Modula-2 (ISO/IEC 10514-3). ISO/IEC.Google Scholar
- Sutcliffe, R. J. 1987 Introduction to programming using Modula-2. Merrill.Google Scholar
- Eisenbach, S. and Sadler, C. 1989 Program design with Modula-2. Addison-Wesley.Google Scholar
- Gabrini, P. J. and Kurtz, B. L. 1997 Data structures and algorithms with Modula-2. Jones and Bartlett Publishers. Google ScholarDigital Library
- Helman, P. and Veroff, R. 1988 Walls and Mirrors: Intermediate Problem Solving and Data Structures. Benjamin/Cummings Pub. Co. Google ScholarDigital Library
- Sincovec, R. and Wiener, R. 1986 Data structures using Modula--2. Wiley. Google ScholarDigital Library
- Sutcliffe, R. J. 2005. Modula-2: Abstractions for Data and Programming Structures (Using ISO-Standard Modula-2). http://www.arjay.bc.ca/Modula-2/Text/index.html.Google Scholar
- Pronk, C. and Sutcliffe, R. J. 1997. Scalable Modules in Modula-2. Modular Programming Languages. Google ScholarDigital Library
- Pronk, C. S., R. March 19-21, 1997. Scalable Modules in Generic Modula-2. Joint Modular Languages Conference at Johannes Kepler University, Linz, Austria. Lecture Notes Series in Computer Science #1204. Google ScholarDigital Library
- Pronk, C. and Schönhacker, M. S., Richard J. & Wiedemann, Albert Nov 1997. Standardized Extensions to Modula-2. SIGPLAN Notices. Google ScholarDigital Library
- Pronk, C., Schönhacker, M., and Sutcliffe, R. J. W., Albert Oct 2000. Extensions to the language Modula-2. Journal of Object Oriented Programming.Google Scholar
- Brooks, F. P. 1978. The Mythical Man-Month: Essays on Software. 1st ed. Addison-Wesley Longman. Google ScholarDigital Library
- Tanenbaum, A. 2009 Modern operating systems. Pearson Education International. Google ScholarDigital Library
Index Terms
- Closing the Barn Door: Re-Prioritizing Safety, Security, and Reliability
Recommendations
Collaborating with industry: strategies for an undergraduate software engineering program
SSEE '06: Proceedings of the 2006 international workshop on Summit on software engineering educationSoftware engineering is prominent in the collection of undergraduate disciplines that benefit most from experiential learning. Despite an exhaustive classroom and laboratory curriculum, the obtainment of program outcomes cannot be achieved without the ...
Imprinting community college computer science education with software engineering principles: work in progress
ACM SE '10: Proceedings of the 48th Annual Southeast Regional ConferenceAlthough the two-year curriculum guide includes coverage of all eight software engineering core topics, the computer science courses taught in the Alabama community colleges limit student exposure to the programming, or coding, phase of the software ...
Technology workshops by in-service teachers for pre-service teachers
SIGUCCS '01: Proceedings of the 29th annual ACM SIGUCCS conference on User servicesThis project was an initiative through university courses to have graduate in-service teachers, who have learned the use of technology for classroom instruction, offer workshops to undergraduate pre-service teachers. The goals of the project were two-...
Reviews
Haim I. Kilov
The problems discussed in this important and timely paper have been with us for decades: the terms "software engineering" and "software crisis" were coined in 1968, when for the first time "programmers' difficulties were openly discussed in a public forum-and with unusual frankness" [1] at the NATO Software Engineering Conference. The authors demonstrate that "we are now deep into a new and severe software crisis" characterized by failed projects, software crashes resulting in lost customer confidence, thousands of bugs in products endured by the marketplace with "few or no consequences for behavior and performance that in almost any other context would be viewed as unacceptable, unethical and actionable," poor or inadequate documentation, easily compromised systems, and so on. Further, the authors stress the need for a disciplined approach starting with clearly defined specifications and observe that quick and dirty programming, perhaps adequate "to hack together a program that occupies a screen of code," does not scale, as well as that both professionalism in software management and appropriate choice of tools are essential for success. They emphasize that university students must, from the beginning, be taught using the best languages and best practices. The need for simple and elegant high-level languages has been known for decades, but "fashionable" languages that do not support abstraction (and safety) are still with us. A program first and foremost has to be readable and understandable by humans, and the authors properly put readability at the head of the list of proposed solutions. They stress the requirement for language-supported safety and discuss it at length, and then present the requirements for demonstrable correctness, security, reliability, and modifiability. As the language to be used, the authors propose their modernized dialect of Wirth's Modula-2 (with quite a few examples showing its properties), and in my opinion, their promotion of this language is justified. The authors properly criticize some popular but clearly inadequate approaches to software development including languages "inherently lending [themselves] to writing cryptic [and unsafe] code"; specifications created "on-the-fly under the assumption that the final project can be created in chunks" without knowing how, and whether, they will work together; code that is never reviewed "for code quality and specification compliance"; and so on. Their proposals to clearly state these problems and teach how to solve them, using their dialect of Modula-2, are more than welcome. At the same time, as many of us (ought to) know, such ideas have been around for decades. The paper's reference list of 65 items regretfully does not include [1] or other software engineering classics such as Dijkstra. I would also disagree with some of the authors' statements regarding traditional languages: first, Algol (both 60 and 68) was not "designed by a large committee," and second, while PL/I indeed is of rather monstrous size and complexity, it was not too difficult to extract from it a small, disciplined subset used both in teaching and in industry. Note also that such an unfashionable and arguably unpleasant language as COBOL was recently praised (of all places) in the Financial Times for "being strictly structured, modular, and, not least, having clearly readable self-documenting syntax and format," thus avoiding the "challenging problem of code fragility where change in one part of a program has unforeseen consequences on another" [2]. To deal with the current software crisis, as Wirth observed, "programmers must become engaged crusaders against homemade complexity" [1]. This has to start early, in the classroom, and the authors propose to "teach classic professional engineering principles and tradecraft, and instill the self-discipline to apply them habitually." Thus, I would certainly recommend the paper as an excellent step in the right direction. Online Computing Reviews Service
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Comments