1. Software – Acquisition & Testing

2. ICT5 How to acquire software There are several options: The software may be written by the end-user; A specialist department within the organisation may design, write, test and document it; External consultants may be called in to write and test the software; An off-the-shelf package may be bought, and possibly customised; Software may be leased, with the user paying an annual fee for the right to use the product.

3. ICT5 End-user-written software Normally only for very small project where the end- user is a computer specialist Advantages the requirements are precisely known so no problems of communication arise, the software is likely to be developed quite quickly in response to a specific need. Disadvantages end-user is very unlikely to provide any technical or user documentation for later users only useful for minor projects with a limited life-span.

4. ICT5 Writing software in-house Advantages Many organisations have own specialists for software maintenance and development. any confidential information or ideas are kept within the organisation. Disadvantages developing a major new system may require extra staff with specialised skills such people may be difficult to recruit, especially for a short time. company may prefer to bring in outside consultants

5. ICT5 External consultants For a major project, going to an external software house may be the only solution. The job may be ‘put out to tender’, with several companies submitting. The more complex the project, the greater the pitfalls, and so great care is needed in the choice of consultant. Cost is important but a consultant with several successful systems already installed may be worth the extra money. The relationship between consultant and client may be crucial in implementing a new system.

6. ICT5 Buying a package Advantages over specially written software: Cheaper than custom-written software development costs of a package may be £ millions, but sales are made to thousands of customers Immediately available and already tested so is unlikely to have major bugs in it; Documentation is usually available e.g. reference manuals, user guides and tutorials; Training courses may be available from third-party trainers; Technical support is usually available via a Web site or telephone line (at a price); Other users of the package can be consulted as to its suitability before purchase; Upgrades usually available every year or two.

7. ICT5 Buying a package Disadvantages: The package may not do exactly what you want; It may not run on the firm’s existing hardware; It may not interface with other software already in use in the organisation

8. ICT5 Other methods of Acquisition Leasing Packages can be leased rather than purchased outright Benefits - automatic upgrades and less initial expense Disadvantage – may be more expensive in the long run Modifying existing packages A package may be bought and modified Disadvantage Manufacturer no longer provides support Modifications may ‘knock-on’ effect

9. ICT5 Software testing Typically consists of five stages: 1. Unit testing. Each individual component (e.g. subroutine or code for a particular function) is tested. 2. Module testing. A module is a collection of dependent components or subroutines. 3. Subsystem testing. Testing collections of modules which have been integrated into subsystems. 4. System testing. May reveal errors resulting from interaction between different subsystems. 5. Acceptance testing. The final stage before the system is accepted for operational use. It involves testing the system with data supplied by the system purchaser rather than with simulated data developed specially for testing purposes.

10. ICT5 Software testing Testing is an iterative process Each stage in the test process being repeated when modifications have to be made owing to errors coming to light at a subsequent stage. Unit testing Acceptance testing Sub-system testing Module testing System testing

11. ICT5 Modes of Acceptance Testing Alpha testing for specially-commissioned software testing continues until agreement reached between developer and purchaser Systems must work correctly and fulfil specification requirements Beta testing Used with new software packages Package distributed to potential users who test and report faults Microsoft typically follow this approach Successive beta releases are distributed until developer considers product ready for full release

12. ICT5 Software maintenance Required for a number of reasons Errors may appear in the software Original requirements are modified Hardware developments may make it desirable to change the software to take advantage New legislation may be introduced

13. ICT5 The categories of maintenance Perfective maintenance system can be made better in some way without changing its functionality. Adaptive maintenance changing needs in a company may mean systems need to be adapted – e.g. a single-user system may be adapted to a multi-user system. Corrective maintenance involves correction of previously undetected errors. e.g. the millennium bug. Many major programs are released with ‘bugs’ that require maintenance releases – ‘patches’ or ‘service packs’ to fix them (most of the Microsoft products)

14. ICT5 Maintenance releases Process triggered by: user or management requests Further development by manufacturer Cost and impact on system are assessed for feasibility New release has to be programmed and tested Software packages generally have release numbers Minor releases are indicated by a change in number suffix e.g. 3.0 to 3.1 with Windows Major releases are often indicated by a change like 4.0 to 5.0 or by a change in name

15. ICT5 ‘Laws’ of software maintenance Lehman and Belady 1985 1. The law of continuing change A program that is used in a real-world environment necessarily must change or become progressively less useful in that environment. 2. The law of increasing complexity As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure. 3. The law of large program evolution Program evolution is a self-regulating process. System attributes such as size, time between releases and the number of reported errors are approximately invariant for each system release. 4. The law of organisational stability Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development. 5. The law of conservation of familiarity Over the lifetime of a system, the incremental change in each release is approximately constant.

16. ICT5 Maintenance Most software developers would prefer to be working on exciting new projects Maintenance is very expensive Cost-effectiveness depends upon A clearly-defined and well-documented original system Suitably qualified and informed analysts and programmers A clear and uncomplicated dialogue path between user and developer A transparent structure that allows analysts and programmers to assess fully the impact of any changes Limiting the amount of change at any one time