SQA National 5 Computing Science

Development methodologies

A development methodology is an agreed way of organising the work of making software, so that it is carried out in a planned order and not by trial and error.

Iterative development

Software is developed in a sequence of phases, and the sequence is an iterative development process: a later phase can send the developer back to an earlier one, and the cycle is repeated until the program is right. The phases are:

1. Analysis
2. Design
3. Implementation
4. Testing
5. Documentation
6. Evaluation

Analysis finds out what the program has to do. Design plans a solution before any code is written, using a structure diagram, a flowchart or pseudocode. Implementation is writing the program in a programming language. Testing runs it with chosen data to find errors. Documentation records the program for the people who will use or maintain it, for example a user guide or a description of how the code works. Evaluation judges the finished program against what was asked for.

Each phase is allowed to feed back into the ones before it. A test that shows the program crashes on an empty input sends the developer back to implementation to add a check. An evaluation that shows the client needs a report the program does not produce sends them back to analysis, and then design, before the new feature is coded. An iterative approach is needed whenever the requirements are unclear at the start, whenever the client changes their mind, and whenever testing finds a fault that cannot be fixed without rethinking how the solution was planned.

Computational thinking

Computational thinking is the habit of approaching a problem so that a computer can solve it, and it runs through every phase. The problem is broken into smaller parts that are easier to solve one at a time, which is decomposition; the details that do not matter are set aside so that only those needed remain, which is abstraction; and the solution is written as a precise sequence of steps, an algorithm, that can be followed without any guesswork. The structure diagram in the design phase is decomposition drawn out, and a program's variables are an abstraction of the things it works with.

Analysis

Analysis begins with the problem. The developer works out the purpose of the program, which is one sentence saying what it is for, and its functional requirements, which are the things it must do. A functional requirement is stated in terms of inputs, processes and outputs.

• The inputs are the data the program receives, from the keyboard, a file or another device.
• The processes are what the program does with that data: calculations, comparisons, decisions and repeated steps.
• The outputs are what it gives back, such as a message on the screen, a total or a file.

For a program that tells a swimming club how much a session costs, the analysis might be recorded in a table.

Two things are easy to confuse. A process is something the program does (calculate, compare, add to a total), while an input or output is a piece of data that enters or leaves it. The value a user types is an input; the act of multiplying it by a rate is a process; the answer displayed is an output.

Why analysis comes first

A program that solves the wrong problem is not rescued by good code. Writing the requirements down before designing gives the developer and the client something they can both check. It also supplies the list against which the program is tested and evaluated later: every functional requirement should have a test, and the final evaluation asks whether each one was met.