Software Acquisition

1
Software Acquisition Testing
2
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
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
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
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
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
Buying a package

• Disadvantages
• The package may not do exactly what you want
• It may not run on the firms existing hardware
• It may not interface with other software already
  in use in the organisation

8
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
Criteria for selecting software

• Functionality
• Robustness
• Performance
• Support
• Portability
• Transferability
• Appropriateness
• Security
• Upgradability

10
Software testing

• Typically consists of five stages
• Unit testing. Each individual component (e.g.
  subroutine or code for a particular function) is
  tested.
• Module testing. A module is a collection of
  dependent components or subroutines.
• Subsystem testing. Testing collections of
  modules which have been integrated into
  subsystems.
• System testing. May reveal errors resulting from
  interaction between different subsystems.
• 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.

11
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
12
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

13
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

14
The categories of maintenance

• Perfective maintenancesystem 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)

15
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

16
Laws of software maintenance

• Lehman and Belady 1985
• The law of continuing changeA program that is
  used in a real-world environment necessarily must
  change or become progressively less useful in
  that environment.
• 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.
• 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.
• The law of organisational stabilityOver a
  programs lifetime, its rate of development is
  approximately constant and independent of the
  resources devoted to system development.
• The law of conservation of familiarityOver the
  lifetime of a system, the incremental change in
  each release is approximately constant.

17
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