Crisis Response and Management

Crisis Response and Management

Sergey V. Zykov (National Research University Higher School of Economics, Russia)
Copyright: © 2018 |Pages: 11
DOI: 10.4018/978-1-5225-2255-3.ch120
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Information technology is critically dependent on a number of technological and human factors. Software engineering processes are multi-sided; they include customer and developer parties. Conceptual misunderstanding by either party often results in the products which do not meet customer's expectations. This misconception of the software product scope usually leads to a crisis of software product delivery. To adequately manage and efficiently respond to this crisis, the authors recommend using software engineering models, methods, techniques, practices and tools. Software engineering is a discipline which started in the 1960s as a response to the so-called “software cri-sis”; it combines technical and human-related skills. To manage the crisis, the authors suggest architecture patterns and instantiate them by implementation examples.
Chapter Preview
Top

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).

Key Terms in this Chapter

Sage: A model for estimating software development; includes project management and personnel characteristics.

XP (eXtreme Programming): A software development methodology which is intended to improve software quality and responsiveness to changing customer requirements; a pragmatic approach that emphasizes business results and takes an incremental approach to building the product through continuous testing and revision.

Scrum: An iterative and incremental agile software development methodology for managing product development.

CMM (Capability Maturity Model): A methodology used to develop and refine an organization’s software development process.

Agile: A software development methodology; an alternative to traditional project management where emphasis is placed on empowering people to collaborate and make team decisions in addition to continuous planning, continuous testing and continuous integration.

Oscillator Circuit: An electric circuit, which consists of capacitor and inductive coupling. Uses feedback for oscillation.

COCOMO (Constructive Cost Model): An algorithmic method for evaluating and estimating the cost of software development.

Human-Related Factor: A factor originating from human nature, which influences requirements elicitation, and, consequently, software development.

CMM(I) (Capability Maturity Model Integration): A framework of best practices in managing, measuring and monitoring software development processes.

OOAD (Object-Oriented Analysis and Design): An approach in the system analysis and design through the application of the object-oriented paradigm and concepts including visual modelling.

Crisis: Misbalanced production and realization of a surplus value, the root cause of which is separation between the producers and the means of production.

SCADA (Supervisory Control and Data Acquisition): A category of software application for process control; gathers data in real time from remote locations in order to control equipment and conditions.

Price-S: A composite modelling system for estimating software cost.

Quality Attribute: A systemic property of a software product, which critically influences its quality.

RUP (Rational Unified Process): A software development methodology; a software development methodology from Rational. RUP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development: inception, elaboration, construction, transition.

Third-Generation Programming Language: A high-level programming language such as FORTRAN, COBOL, BASIC, Pascal and C.

Software Engineering: A set of tasks, methods, tools and technologies used to design and implement complex, replicable and high-quality software systems, which include a database.

Software Design Pattern: A general reusable solution to a commonly occurring problem within a given context.

SADT (Structured Analysis and Design Technique): A software engineering methodology for describing systems as a hierarchy of functions.

Agility: Ability to adapt to uncertainties and changes of environment.

Seer: A model for estimating IT project and service costs.

COCOMO II (COnstructive COst Model II): A method for estimating the cost, effort, and schedule when planning a new software development activity.

Enterprise Agility Matrix: Matrix, the columns of which correspond to processes, data and systems, and the rows of which contain enterprise system levels. Used to detect and predict local crises of software production.

CRM (Customer Relationship Management): A set of practices, strategies and technologies that companies use to manage and analyse customer interactions and data throughout the customer lifecycle, with the goal of improving business relationships with customers.

MSF (Microsoft Solution Framework): A software development methodology; a set of principles, models, disciplines, concepts, and guidelines for delivering information technology solutions from Microsoft.

Complete Chapter List

Search this Book:
Reset