Describe system design, testing strategies, methods of installation and changeover, documentation, evaluation and maintenance.

What this dot point is asking

WJEC wants you to describe how a system is designed, tested, installed and maintained: the design specification, testing strategies (including black-box and white-box, alpha and beta), methods of changeover, documentation, evaluation against requirements, and the types of maintenance. This follows directly from the life-cycle dot point and is examined by questions on testing types and on changeover methods, both of which reward precise, contrasted answers.

The answer

System design

Designing thoroughly before coding means the difficult decisions are made and checked on paper, where they are cheap to change, rather than discovered halfway through implementation.

Testing strategies

Using several strategies catches different faults: black-box finds requirement mismatches, white-box finds untested code paths, and beta testing finds real-world problems the developers never imagined.

Changeover, documentation and evaluation

Changeover methods are direct (old off, new on at once), parallel (both run together as a fallback), phased (one part at a time) and pilot (one group first). Documentation is split into user documentation (how to use the system) and technical documentation (how it works, for maintainers). Evaluation judges the finished system against its original requirements and the user's needs.

Maintenance

Examples in context

Example 1. Parallel running for a hospital records system

A hospital introducing a new patient-records system runs it alongside the old paper or legacy system for a month, comparing outputs. If the new system errs, staff still have the old records, so patient safety is protected. This is exactly why parallel changeover, despite its cost, suits high-risk systems.

Example 2. Beta testing a game finds what alpha missed

A studio's in-house alpha testing passes, but beta testers on hundreds of different hardware configurations find crashes the developers never saw. This shows the distinct value of beta testing: real users in real conditions expose problems controlled in-house testing cannot, which is why both stages are used.

Example 3. Why technical documentation matters years later

A maintainer fixing a fault five years after release relies on technical documentation describing the data structures and module design to make the change safely. Without it, every fix risks breaking something else, illustrating why documentation is part of delivering, not an optional extra.

Try this

Q1. State which changeover method keeps the old system available as a fallback while the new one is trusted. [1 mark]

• Cue. Parallel changeover (running both systems together).

Q2. Name the type of maintenance that adapts a system to run on new hardware or a new operating system. [1 mark]

• Cue. Adaptive maintenance.