5.1 Software is a different kind of product
Software is considered to be a rather intangible product, which is realised in the form of texts of various sorts: design documents, program code, user and operator manuals, forms and ultimately only in the observable actions of a computer system. Such systems may be highly complex, multi-functional and linked to a wide variety of other systems involving software, computer hardware and networks.
Intangibility and the notorious complexity of software make it prone to error. For example, increasing the size and complexity of the software increases the number of alternative pathways and has consequences for the probability that something might fail during use. If a particular component of the software is not thoroughly tested – something that can be impossible due to the amount of time it takes to test all possibilities in a complex program, or impossible to do because the circumstances in which that component should be activated are not possible to simulate for testing – the error will not appear until it is too late.
There is another factor, known as malleability, which contributes to the unique status of software. Software is easy to change. This malleability encourages the desire to change software rather than replace it, based on the assumption that it is easier or less costly to do so. However, every change that is made to the software introduces the possibility of new errors.
Errors in a program’s logic, which may lead to a system failure, can often be traced back to errors in the requirements. The importance of requirements and their relationship with project definition has been known for some time. Morris (1996) compared information technology (IT) projects with other kinds of project and found that:
IT projects do indeed pose a particular class of management difficulty. The essence of this difficulty is the way that information technology is so intimately bound to its organisational contexts. As a result, issues of organisational effectiveness and user involvement are both more complex and more prominent in IT projects than they are in most other project industries. This puts much greater emphasis on the tasks of project definition and user involvement in IT than in other project situations.
One of the factors involved in such an evaluation is the operational or working life of a product. A new building, for example, is likely to be in use for more than one person’s lifetime. In contrast, a particular software product is rarely used beyond 10 years. Hence, the choice of life cycle is related to the expected lifetime of a proposed product. In broader terms, the choice of appropriate life cycle is context-dependent.