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 | |
All people who come into contact with software may suffer from various myths associated with developing and using software. Here are a few common ones.
Our company has books full of standards, procedures, protocol, and so on, related to programming software. This provides everything that our programmers and managers need to know. While company standards may exist, one must ask if the standards are complete, reflect modern software practice, and are — importantly — actually used.
If we fall behind schedule in developing software, we can just put more people on it. If software is late, adding more people will merely make the problem worse. This is because the people already working on the project now need to spend time educating the newcomers, and are thus taken away from their work. The newcomers are also far less productive than the existing software engineers, and so the work put into training them to work on the software does not immediately meet with an appropriate reduction in work.
A vague collection of software objectives is all that is required to begin programming. Further details can be added later. If the goals / objectives for a piece of software are vague enough to become ambiguous, then the software will almost certainly not do what the customer requires.
Changing requirements can be easily taken care of because software is so flexible. This is not true: the longer that development on the software has proceeded for, the more work is required to incorporate any changes to the software requirements.
Once the software is written, and works, our job is done. A large portion of software engineering occurs after the customer has the software, since bugs will be discovered, missing requirements uncovered, and so on.
The only deliverable for a project is the working program. At the very least there should also be documentation, which provides support to both the software maintainers, and to the end-users.
Software engineering will make us create a lot of unnecessary documentation, and will slow us down. Software engineering is not about producing documents. Software engineering increases the quality of the software. Better quality reduces work load and speeds up software delivery times.