January 2011 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material January 2011 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
There were many difficulties in the development of large software systems during the 1960s and 1970s. The term “software crisis” dates from that time. The problems stemmed from an inability to apply the techniques used to build small software systems to the development of larger and more complex systems. The typical way to develop small systems can be described as “code-and-fix”.
The “code-and-fix” approach to software development is not a proper life cycle (see later this unit). Code-and-fix development occurs when software engineers come together with a vague set of requirements and start producing software, fixing it, and changing it until the correct product appears.
This is the simplest way to produce software and is invariably how every programmer learns to program. But for anything other than small software projects, code-and-fix is a disaster for a number of reasons:
There is no way to estimate time-scales or budgets.
There is no assessment of possible risks and design flaws: you may come close to a finished product only to find an insurmountable technical problem which sets the whole project back.
We only mention the code-and-fix approach in the context of life cycle models since it is a base-line model which we should avoid. From a software engineer's point of view, code-and-fix is a worst case scenario.
Many project failures resulted from the inability to scale the techniques employed when developing small software systems to handle larger, more complex systems. This failure leads to:
never completed systems
missed deadlines
exceeded budgets
a system that does not do all that is required of it
a system that works but is difficult to use
a system difficult to modify to meet changes in organisational needs and practices
a loss of trust from users, who may experience many problems with using the software.
These problems were largely due to the lack of any framework for the planning and organisation of software development projects. Although some software projects were organised, and these were often the more successful ones, it was the luck of the draw whether a project manager had good intuitions for software development, and whether or not problems arose due to misunderstandings between the customers and the developers of the system. Likewise, there were no clear methods to monitor whether a system was soon to go over budget or miss deadlines.
From some of these problems we can see that at some stage the system developers attempted (not always successfully) to understand the requirements for the new system. We can now include in our diagram of the process these specified requirements for the new system:
