Software Development

Writing a program that works for real users takes much more than coding. This chapter covers how software is developed from start to finish, how designs are drawn, and how programs are tested and kept up to date.

12.1 Program development life cycle

Stages of development

The program development life cycle has these stages:

1. Analysis: find out what the system must do. Study the existing system, talk to users (interviews, questionnaires, observation, looking at documents), identify the problem, and produce a requirements specification that lists exactly what the program must do, the inputs, processes and outputs, and the user's needs.
2. Design: decide how it will do it. Produce the structure of the program (structure charts, flowcharts, pseudocode), the data structures and files, the user interface and the test plan.
3. Coding: write the program (and unit test each module) in a chosen programming language, following the design, with comments and good practice.
4. Testing: check that the program works correctly with test data, against the requirements specification, and fix the faults found.
5. Maintenance: keep the program working after it is in use: fix faults, adapt it, and improve it.

Some descriptions add implementation/installation and documentation as stages. Documentation includes user documentation (how to use it) and technical documentation (how it works, for maintenance).

Life cycle models

A life cycle model is the plan for how the stages are organised.

Waterfall model. Each stage is completed in order (analysis, then design, then coding, then testing, then maintenance), and the output of one is the input of the next. There is little or no going back.

• Advantages: simple and easy to manage; the stages and the deliverables of each are clear; good documentation; suits a project whose requirements are well understood and unlikely to change.
• Drawbacks: it is hard to change the requirements once started; a mistake in an early stage may not be noticed until testing; the user does not see a working program until late, so problems are found late and are expensive to fix.

Iterative model. The program is built in repeated cycles: a first version, with some features, is built, tested and reviewed; the feedback is then used to improve it in the next cycle (an iteration), repeating until the product is complete. Each cycle includes some analysis, design, coding and testing.

• Advantages: early working versions let users give feedback; changing requirements can be handled; risks are found early.
• Drawbacks: it may be difficult to plan the final cost and finish date; needs more user involvement and more testing; the design can become untidy if it is not well managed.

Rapid application development (RAD). Builds prototypes quickly, with the users closely involved and giving feedback on each, and using reusable components rather than detailed planning up front. The prototypes are refined (and may become the final product).

• Advantages: fast development, a product that matches what users actually want, early feedback and low risk of building the wrong thing.
• Drawbacks: the quality and documentation may be weaker; needs users to be available often; not suitable for very large or critical systems (for example a nuclear power station controller), where careful design matters most.

Tap to enlarge

Two life cycle models side by side: the waterfall model as a staircase of analysis, design, coding, testing and maintenance where each stage finishes before the next, and the iterative model as a loop of analyse and design, code a version, test it and review with users, repeated for each version

Close

12.2 Program design

Structure charts

A structure chart shows how a program is decomposed into modules (subroutines) and how they are connected. It is a hierarchy:

• The top box is the whole program (main).
• Each box below is a module that the box above calls.
• Selection is shown by a diamond on the line above the modules, and iteration (a module called repeatedly) by a curved arrow.
• Data passed between modules (parameters and return values) is shown by small arrows labelled with the data names.

                 Calculate wages
              /         |         \
      Get hours     Work out pay    Print payslip
                     /       \
              Basic pay     Overtime pay

Tap to enlarge

A structure chart with the module Calculate wages at the top calling Get hours worked, Work out pay and Print payslip; Work out pay calls Basic pay and Overtime pay, with a selection diamond on the overtime line, and the data passed between modules is labelled on the lines

Close

A structure chart is used in top-down design (stepwise refinement) and each box becomes a procedure or function. It shows the modular structure, but not the order or detail of the steps, which are in the flowcharts or pseudocode.

A structure chart can be turned into pseudocode. The top module becomes the main procedure, which calls a procedure or function for each module below it, and the data labels on the lines become parameters and return values.

PROCEDURE CalculateWages()
    DECLARE Name : STRING
    DECLARE Hours, Pay : REAL
    INPUT Name
    CALL GetHours(Hours)                 // Hours is returned through a BYREF parameter
    Pay ← WorkOutPay(Hours)
    CALL PrintPayslip(Name, Pay)
ENDPROCEDURE

FUNCTION WorkOutPay(Hours : REAL) RETURNS REAL
    DECLARE Pay : REAL
    Pay ← BasicPay(Hours)
    IF Hours > 40                        // the selection diamond on the chart THEN
        Pay ← Pay + OvertimePay(Hours)
    ENDIF
    RETURN Pay
ENDFUNCTION

State-transition diagrams

A state-transition diagram shows the states a system can be in, and the events or inputs that make it change from one state to another. It is used to design systems that react to events, such as a washing machine, a traffic-light controller or a digital camera.

• States are drawn as circles or rounded boxes.
• Transitions are arrows from one state to the next, labelled with the event that causes the change (and sometimes the action).
• A start arrow marks the initial state.

Tap to enlarge

A state-transition diagram of a digital camera with three states, standby, ready and taking picture, joined by arrows labelled with the events turn on, turn off, press shutter and picture saved, and a start arrow into standby

Close

A state-transition table gives the same information in rows: current state, event, next state.

12.3 Program testing and maintenance

Types of error

• Syntax error: the code breaks the rules of the language (a missing bracket, a misspelt keyword). The translator reports it and the program will not run until it is fixed.
• Logic error: the program runs but gives wrong results because the algorithm is wrong (using + instead of -, a loop that runs one time too many). The translator does not detect it; it is found by testing.
• Run-time error: the program crashes while running because it tries to do something impossible (divide by zero, read a file that does not exist, array index out of range, running out of memory).

To locate and correct errors, use dry runs and trace tables, debugging tools in an IDE (stepping, breakpoints, watching variables) and extra output statements to display the values of variables.

Methods of testing

• Dry run (desk checking): work through the program by hand with sample data using a trace table, without a computer. Finds logic errors early.
• Walkthrough: the programmer explains the code step by step to other people (peers or experts) who look for errors.
• White-box testing: the tester knows and uses the structure of the code and designs tests that exercise every path, branch and statement.
• Black-box testing: the tester only knows the inputs and the expected outputs and does not look at the code.
• Integration testing: testing that modules work correctly together once each has been tested individually (unit testing).
• Stub testing: when a module being tested calls other modules that have not yet been written, a short stub (a simple placeholder routine that returns a fixed value or a message) stands in for each missing module, so the module under test can be tried early.
• Alpha testing: carried out in the company by the developers or its own staff before release.
• Beta testing: a version is released to a selection of real users outside the company, who use it in real conditions and report faults.
• Acceptance testing: the customer or end user tests the finished system against the requirements specification, and decides whether to accept it.

Test data

Choose test data that checks each type of input. For an input that must be a whole number from 1 to 100:

Test strategy and test plan

A test strategy is the overall approach: what will be tested and with which methods, in what order (unit, integration, alpha and beta, acceptance), who will do it, and when. A test plan is the detailed list of individual tests. It includes, for each test: the test number, what is being tested, the test data, the expected result and the actual result, and whether it passed. After a fault is fixed, the tests are repeated (regression testing) to be sure nothing else has broken.

Sample test plan lines:

Maintenance

Maintenance is the work done after a program has been put into use. There are three types:

• Corrective maintenance: fixing faults (bugs) found after release.
• Adaptive maintenance: changing the program to work with a new environment or requirement (a new operating system, new hardware, a change in the law or tax rate).
• Perfective maintenance: improving the program's performance or adding new features, or making it easier to use, at the users' request.

Good maintenance depends on clear documentation, meaningful identifiers, comments, modular code, and a test plan that can be repeated. Maintenance is needed because users' needs change and faults are always found in real use.