The architecture may have to be designed before specifications are written to provide a means of structuring the specification and developing different sub-system specifications concurrently, to allow manufacture of hardware by sub-contractors and to provide a model for system costing.
Object-oriented development helps to reduce these problems as it supports the grouping of entities (in object classes) so therefore simplifies program understanding. It also provides protection for entities declared within objects so that access from outside the object is controlled (the entity may not be accessible, its name may be accessible but not its representation or it may be fully accessible). This reduces that probability that chances to one part of the system will have undesirable effects on some other part.
A consistent user interface may be impossible to produce for complex systems with a large number of interface options. In such systems, there is a wide imbalance between the extent of usage of different commands so for frequently used commands, it is desirable to have short cuts. Unless all commands have short cuts, then consistency is impossible.
An example of such a system is an operating system interface. ...
It may also be the case in complex systems that the entities manipulated are of quite different types and it is inappropriate to have consistent operations on each of these types.
An example of such a system is an operating system interface. Even MacOS which has attempted to be as consistent as possible has inconsistent operations that are liked by users. For example, to delete a file it is dragged to the trash but dragging a disk image to the trash does not delete it but unmounts that disk.
A program need not be completely free of defects before delivery if:
Remaining defects are minor defects that do not cause system corruption and which are transient i.e. which can be cleared when new data is input.
Remaining defects are such that they are recoverable and a recovery function that causes minimum user disruption is available.
The benefits to the customer's business from the system exceed the problems that might be caused by the remaining system defects.
Testing cannot completely validate that a system is fit for its intended purpose as this requires a detailed knowledge of what that purpose will be and exactly how the system will be used. As these details inevitably change between deciding to procure a system and deploying that system, the testing will be necessarily incomplete. In addition, it is practically impossible for all except trivial system to have a complete test set that covers all possible ways that the system is likely to be used.
Program inspections are effective for the following reasons:
They can find several faults in one pass without being concerned about interference between program faults.
They bring a number of people with different experience of different types of