The systems lifecycle and feasibility

The stages from feasibility to maintenance, the three kinds of maintenance, and scoring a feasibility study.

A14.1Software development, law and ethicsA level35 min

Do this lesson in the simulator

At GCSE you wrote programs to a brief and tested them (F6.3), and you weighed up the impacts of technology (F12.1). At A level you need to know how a whole system is built for a real client: the stages it goes through, what is produced at each one, and how a team decides whether it is worth building at all. This module follows one example throughout: a school wants a robot that delivers parcels between rooms.

Systems analysis

A system is the whole of what the client needs: the hardware, the software, the data, the people who use it and the procedures they follow. Systems analysis is the study of how the current system works and what the new one must do. The person who does it, a systems analyst, is the link between the client, who knows the problem, and the developers, who know the technology.

The work is divided into stages. Together they are called the systems lifecycle or software development lifecycle (SDLC). It is a lifecycle because it goes round: once a system is in use, its evaluation and maintenance lead to the next version.

The stages

Stage The question it answers What it produces
Feasibility study Should we build this at all? a feasibility report with a recommendation
Analysis What exactly must the system do? a requirements specification with success criteria
Design How will it do it? data structures, algorithms, a modular structure, interface designs, a test plan
Implementation Build it. the program code and the hardware set up
Testing Does it work, and does it meet the requirements? test results, fixed errors
Installation How does the client start using it? the system in place, users trained, documentation
Evaluation Did it meet the success criteria? an evaluation report
Maintenance What needs changing now it is in use? updates and new versions

Every stage feeds the next. Success criteria written in analysis become the tests in testing and the headings of the evaluation, which is why a vague requirement causes trouble three stages later.

The feasibility study

Before any money is spent, a feasibility study decides whether the project is possible and worth doing. It is often remembered as TELOS:

  • Technical: does the technology exist, and does the team have the skills? Can a small robot find its way between rooms reliably?
  • Economic: will the benefits outweigh the costs of building, running and maintaining it? A cost-benefit analysis compares them.
  • Legal: does it comply with the law? A robot that photographs corridors collects personal data (lesson A14.7).
  • Operational: will people actually use it, and does it fit how the organisation works? Will staff trust a robot with exam papers?
  • Schedule: can it be finished in the time available? A system ready after the school year ends is no use this year.

The study ends with a recommendation: go ahead, go ahead with changes, or stop. Stopping here is a success, not a failure: it is the cheapest point at which to find out a project cannot work.

A simple way to compare proposals is to score each aspect and weight it by how much it matters:

# score each aspect 0 to 5, weight it by how much it matters to this client
aspects = [("technical", 4, 3), ("economic", 3, 2), ("legal", 4, 2), ("operational", 3, 2), ("schedule", 3, 1)]

total = 0
weights = 0
for name, score, weight in aspects:
    total += score * weight
    weights += weight
    print(f"{name:12} score {score} x weight {weight} = {score * weight}")
print("weighted score:", total / weights)

Run this in the simulator

The weighted score is 35 / 10 = 3.5 out of 5. A number like this helps a discussion, but it can hide a fatal problem: a project that is illegal cannot be rescued by scoring well on everything else. That is why real studies treat some weaknesses as blockers.

Fact finding

Analysts find out how the current system works, and what the new one needs, in several ways. Each has a trade-off.

Method Good for Weakness
Interviews detail and follow-up questions with key people slow, and only reaches a few people
Questionnaires many people, answers easy to compare fixed questions, low response rates
Observation what people really do, not what they say they do people behave differently when watched
Document analysis forms, logs and reports show the data in use shows the official process, not the workarounds

Installation and changeover

Moving from the old system to the new one is called changeover. The school could switch everything to the robot on one day (direct), run the robot alongside the porters for a term (parallel), start with one building (pilot), or bring in one feature at a time (phased). Direct is cheapest but riskiest; parallel is safest but doubles the work while it lasts.

Maintenance

Once a system is in use, it still changes. There are three kinds of maintenance:

  • Corrective: fixing errors found after release. The robot stops too late on a shiny floor.
  • Adaptive: changing the system because its environment changed. The school opens a new wing, or a new data protection rule applies.
  • Perfective: improving performance or adding features users ask for. Deliveries are made faster, or a battery report is added.

Most of the lifetime cost of software is maintenance, not the first version. Code that is modular, commented and well tested is cheaper to maintain, which is one reason examiners reward those qualities.

Evaluation

Evaluation judges the finished system against the success criteria agreed in analysis, not against what the developers happen to like. A good evaluation says which criteria were met, gives the evidence (a test result, a measurement, user feedback), explains any that were not met, and says what would be done next. It also considers wider qualities: is it effective, usable, reliable and maintainable?

Task: the feasibility study

Four robot projects have been scored for feasibility. proposals is a list of (name, aspects), where name is a string and aspects is a list of five tuples (aspect, score, weight): aspect is a string, score is a whole number from 0 to 5, and weight is a whole number from 1 to 3.

Write two functions:

  • weighted_score(aspects) returns the total of score * weight divided by the total of the weights, rounded to one decimal place.
  • blockers(aspects) returns a list of the names of the aspects that score less than 2, in the order they appear.

Then, for each proposal in order, print one line: <name>: <score> <verdict>, with the score to one decimal place. The verdict is not feasible (blocked by <aspects>) if there are any blockers, with their names separated by ,; otherwise not feasible (score below 3) if the score is less than 3; otherwise feasible. For example, delivery robot: 3.5 feasible. The robot stays still.

# the two lines every program starts with: the commands, then the robot
from bugbot import *
connect()

proposals = [
    ("delivery robot", [("technical", 4, 3), ("economic", 3, 2), ("legal", 4, 2), ("operational", 3, 2), ("schedule", 3, 1)]),
    ("face-recognition door", [("technical", 4, 3), ("economic", 4, 2), ("legal", 1, 2), ("operational", 3, 2), ("schedule", 4, 1)]),
    ("robot lawnmower fleet", [("technical", 3, 3), ("economic", 2, 2), ("legal", 3, 2), ("operational", 3, 2), ("schedule", 2, 1)]),
    ("voice-controlled lift", [("technical", 1, 3), ("economic", 1, 2), ("legal", 4, 2), ("operational", 3, 2), ("schedule", 4, 1)]),
]

def weighted_score(aspects):
    pass

def blockers(aspects):
    pass

Challenges

  1. The face-recognition door scores well overall but is blocked on legal grounds. Write two sentences explaining why a legal problem should stop a project that scores 3.2.
  2. Classify each change as corrective, adaptive or perfective: the robot is updated for a new floor plan; a crash when the battery reads 0 is fixed; the route planner is made faster.
  3. Suggest the changeover method you would use for the delivery robot, and justify it in terms of the risk to the school.