Software – Acquisition & Testing

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.

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.

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

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.

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.

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

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

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.

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.

Unittesting

Acceptancetesting

Sub-systemtesting

Moduletesting

Systemtesting

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

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

ICT5

The categories of maintenance Perfective maintenance

system can be made better in some way without changing its functionality.

Adaptive maintenancechanging 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 maintenanceinvolves 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)

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

ICT5

‘Laws’ of software maintenance Lehman and Belady 19851. 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 complexityAs 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 evolutionProgram 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 stabilityOver 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 familiarityOver the lifetime of a system, the incremental change in each release is approximately constant.

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