Crisis Response and Management

Introduction

In the 1960s, the so-called “software crisis” triggered the advent of software engineering as a discipline. This term originated from the critical development complexity, which happened due to the rapid growth of computational power. At that time, the computing power of the machines became so overwhelming that a number of software development projects were over budget, late or unsuccessful. One well-known example was the first General Electric’s payroll system launched in 1954 at Louisville, Kentucky; this was late, over budget, and missing crucial features (Topi, & Tucker, 2014). Irrespective of human efforts, the complexity of the hardware and software systems was hard to cope with by means of the old methods and techniques. The challenge was so dramatic that in 1967 NATO arranged an invitation-only conference, where world leaders in IT research and practice searched for an efficient response. At the conference, the term “software crisis” was coined by F.Bauer and used by E.Dijkstra (Naur, & Randell, 1968).

Another term suggested at the conference by the same F. Bauer was software engineering. The idea was to apply the engineering methods of material production to the new domain of large-scale concurrent software systems in order to make the software projects more accurate and predictable. This software engineering approach was feasible, though the methods and practices used had to differ substantially from those used in the material production. Specifically, the experts examined bridges as the instances of complex material systems.

The attendees concluded that the distribution of time and cost by the lifecycle phases, especially for the post-delivery maintenance was very different for software and material production. This is why the new software engineering discipline was in need of new methodologies, techniques and tools.

The focus of the software engineering discipline was the “serial” production of substantially large-scale, complex and high quality software systems. Concerning software complexity, at least two dimensions were identified; these were technical and management complexity (Booch, 2006). To measure software product complexity and quality, a set of attributes and metrics was suggested. The quality attributes included performance, reliability, security, fault tolerance, usability, strategic reusability and maintainability; their importance depended on the product size and scope (Lattanze, 2008). The complexity metrics included product size in terms of lines of code, function points, nesting levels, cyclomatic complexity and a number of more sophisticated ones (Debbarma, Debbarma, Chakma, & Jamatia, 2013). These metrics assisted in the divide-and-conquer strategy; later, they this general approach transformed into elaborate product estimation techniques and software development methodologies (Jensen, 2014).

Researchers argue whether the crisis in software engineering is over yet (Colburn, Hsieh, Kehrt, & Kimball, 2008) or it still exists (Buettner, Dai, Pongnumkul, & Prasad, 2015). This happens because of the fundamental differences in the lifecycles of software and material products. One critical difference between large-scale software and material production is the distribution of time and cost by the development lifecycle phases. Therewith, maintenance is the most time and cost consuming, it often exceeds 60% of the software project expenses (Schach, 2011). The other crucial difference is that software production often depends dramatically upon human factors. These human factors relate to the management aspects of software complexity, whereas the technology factors relate to the technological aspects. Certain product categories are far more complex in terms of management than in terms of technology; however, the influence of the human factors on their development is largely underestimated. For such software product categories as enterprise information systems and defense management information systems, neglecting these human factors often results in project delays or even failures (Booch, 2006).