Explore chapters and articles related to this topic
Introduction to Software Engineering and Component-Based Software Engineering
Published in Umesh Kumar Tiwari, Santosh Kumar, Component-Based Software Engineering, 2020
Umesh Kumar Tiwari, Santosh Kumar
Software engineering is both an art and a science. It is the process of constructing acceptable artifacts with scientific verifications and validations within the limitations of time and budget. The term “software engineering” came into existence in the 1960s when NATO’s Science Committee organized conferences to address the “software crisis.” Krueger (1992) describes the software crisis as “the problem of building large, reliable software systems in a reliable, cost-effective way.” Previously, the industry, the research community and academia had concentrated on the development of capable and competent hardware. The result of this effort was the availability of powerful and cheaper machines. Now, there was the requirement of large, functionally efficient software to fully utilize the capability of the available hardware machines and other resources. Thus, the focus of the community shifted from small, number-crunching programs to developing software that could address real-world problems. The outcome of these conferences was the emergence of the term “software engineering.”
The Way Out of the Software Crisis
Published in Peter Middleton, James Sutton, Lean Software Strategies, 2020
These new practices have been adopted in response to many legitimate problems for both developers and customers. They have at least sometimes (though by no means always, as noted above) led to improvements in error rates, productivity, and development predictability. Yet most of the changes have also imposed extraordinary expenses of every kind on their implementers, such as 1) increased costs in work hours to implement, 2) major organizational restructurings and turmoil, 3) direct monetary costs, and 4) an entropic loss of flexibility and therefore business opportunity to adapt one’s own software process to market and technology changes. In the 30+ years since the term “software crisis” was first coined, and despite these massive investments, quality hasn’t even doubled from its intolerable previous lows, while the dispersion in quality increased from 10:1 in 1990 to 100:1 by 1995.6
Fundamentals of Systems Engineering
Published in Julio Sanchez, Maria P. Canton, Software Solutions for Engineers and Scientists, 2018
Julio Sanchez, Maria P. Canton
Software engineering was first introduced in the 1960s in an effort to treat more rigorously the often frustrating task of designing and developing computer programs. It was around this time that the computer community became increasingly worried about the fact that software projects were typically over budget and behind schedule. The term software crisis came to signify that software development was the bottleneck in the advancement of computer technology.
Design and management of software development projects under rework uncertainty: a study using system dynamics
Published in Journal of Decision Systems, 2023
Mst Taskia Khatun, Kazuo Hiekata, Yutaka Takahashi, Isaac Okada
Despite its significant evolution, the software industry often suffers from a ‘software crisis’ of cost and scheduling overruns. Scheduling overruns are the most common problem. Almost every software development team has some level of experience with this issue. There are two principal factors in this situation: (1) the increasing complexity of software creates difficulties for project managers ininitial project evaluations when there is limited information on project scope, and (2) ineffective decision-making by project managers when faced with such issues. When problems are complex, it is difficult to find a solution (Abramek & Sołtysik-Piorunkiewicz, 2020). The main focus of this study is the second factor. The software production phase primarily involves development, testing, and rework (Abdel-Hamid, 1984; Browning, 2019; Jia et al., 2007, July 29-August 2). In software development, rework is theextra effort required to revise a process that was incorrectly implemented initially. Incorrect implementation usually results from errors, changes, and poor coordination. Rework is an unexpected event thatcauses uncertainty andcreates challenges in achieving project goals, because it is difficult to estimate accurately (Browning, 2019; Li et al., 2021). Therefore, reworkis a challenging topic in ongoing research (Taipalus et al., 2020).