SQA Higher Computing Science

A development methodology is an agreed way of organising the work of turning a problem into a working program. Two are needed at Higher: the iterative development process and agile methodologies. Both break the work into stages and both allow earlier work to be revised, and what separates them is how large each cycle is and how much the client is involved along the way.

The stages of software development

Whatever methodology is used, the same activities take place. They are usually listed as:

1. Analysis: finding out what the problem is and what the software must do.
2. Design: planning how the software will do it, using structure diagrams, pseudocode and wireframes.
3. Implementation: writing the code from the design.
4. Testing: checking the program against the requirements and finding errors.
5. Documentation: writing the user guide and technical information.
6. Evaluation: judging whether the finished solution is fit for purpose.
7. Maintenance: fixing faults and making changes after the software is in use.

A methodology decides how these activities are ordered, how often they are repeated and who takes part.

The iterative development process

In the iterative development process the stages are followed in order, but each stage can send the team back to an earlier one. Testing may show that a design decision was wrong, so the team returns to design, changes it, and implements and tests that part again. Evaluation may show that a requirement was misunderstood, so the team returns to analysis. Each pass through the stages produces a better version of the same solution.

The requirements are gathered mostly at the start, and the whole solution is designed before much of it is written. The client sees the finished product, or a large part of it, at the end of a cycle.

This suits problems that are well understood and unlikely to change. A large system with a fixed specification, where the cost of a late change is high, is a typical case. Its weaknesses follow from the same feature: if the client's needs change part-way through, or were described badly at the start, the problem may not come to light until late, when changes are expensive. A long gap also separates the client's first description of the problem from their first sight of working software.

Agile methodologies

Agile methodologies divide the project into many small pieces, each built and delivered in a short, fixed period. In the best-known form each of these periods is called a sprint and usually lasts between one and four weeks. At the start of a sprint the team chooses a small set of requirements from the full list, then analyses, designs, implements and tests them inside the same sprint. At the end there is a working piece of software that the client can use and comment on.

Several features distinguish agile working:

• The client, or someone who represents the users, takes part throughout and gives feedback after every sprint.
• Requirements are expected to change and are gathered again for each sprint, rather than fixed at the start.
• Working software counts for more than detailed documents, so there is less written planning up front.
• The team is small and meets often, typically for a short daily meeting to say what has been done, what is next and what is in the way.
• Prototypes are often used to start a discussion with the client about what is needed.

A problem where the client is unsure exactly what they want suits agile development well, because each sprint turns a vague idea into something they can look at and react to. Changes are cheap because only the current sprint is affected. The drawbacks are that it needs a client who has time to take part regularly, it is harder to predict the final cost and date when the full scope is not fixed, and with less documentation it can be harder for new team members to learn what has been built.

Comparing the two

Choosing a methodology

The choice depends on the problem. If a client is known to change their mind often, agile suits, because feedback after each sprint catches a change early and the client sees progress all the time. If the problem is fully specified and the client cannot take part regularly, a more traditional iterative process with a thorough analysis and design phase is easier to plan and cost.

Suppose a school asks for a timetabling program and the staff are not sure which features they want. An agile team would deliver a first sprint that enters teachers and rooms, show it to the staff, and let their reaction decide what the second sprint builds. An iterative team would spend the early weeks analysing every requirement, and staff would see nothing running until a large part was complete.