Program development life cycle, design, testing and maintenance

Why a program needs a development life cycle

A program development life cycle is the set of stages a program passes through from the moment somebody recognises a problem to the moment the finished system is retired, together with the order those stages are carried out in. It is a framework for managing the work, not a way of writing code: it says what has to be produced at each stage, who reviews it, and what the next stage is allowed to assume.

Its first purpose is to make a large job controllable. A program of any size is too big to hold in one person's head, so the life cycle cuts it into stages, and each stage ends with something concrete that the next stage uses - a requirements specification, then a design, then working code, then a tested system, then a maintained system. Because each stage has a deliverable, progress can be measured, budgeted and reviewed, the client can agree what is being built before the expensive part starts, and several people can work on different parts without losing track of how they fit together.

Its second purpose is to catch faults early, because the cost of a fault rises steeply the later it is found. A misunderstood requirement corrected during analysis costs a sentence in a document. The same misunderstanding discovered after the system is in use costs a redesign, rewritten modules, a full retest and retraining of the users, and it may already have damaged data.

Every model in this topic contains the same five stages - analysis, design, coding, testing and maintenance - and the models differ in how often they go round them and in how much has to be finished before the next stage can start. The table below summarises what each stage does and what it hands on to the next one.

The waterfall model

The waterfall model carries out the stages in strict sequence. Analysis is completed, reviewed and signed off before design begins; design is completed and signed off before coding begins; and so on to testing and maintenance. The output of each stage is the input to the next, the client sees a working program only at the end, and going back to an earlier stage is treated as an exception rather than a normal part of the process.

Each stage produces documentation - the requirements specification, the design documents, the test plan, the user manual - and each stage has a milestone that management can check against a plan.

One detail is worth remembering because it explains a lot of the model's behaviour: the test plan is written during design, from the specification, before any code exists. Tests are therefore derived from what the system is supposed to do rather than from what the programmer built, so testing can find a missing requirement and not just a mistyped line.

• Benefit - simple to manage: one stage at a time, with clear milestones and deliverables, so progress, cost and staffing are easy to plan and report.
• Benefit - thorough documentation: every stage leaves a written record, which is what maintenance needs years later and what regulators and auditors demand for safety-critical systems.
• Benefit - requirements settled first: because design starts only when the requirements are signed off, the design can be complete and consistent, and a fixed-price contract is possible.
• Benefit - planned testing: the test plan is written from the specification, so every requirement has a test waiting for it.
• Drawback - requirements must be right at the start: if the client cannot state them, or states them wrongly, the error is built in and carried through every later stage.
• Drawback - no working software until late: the client cannot try anything until coding and testing are nearly finished, so misunderstandings surface when they are most expensive to fix.
• Drawback - change is expensive: once a stage is signed off, a change means reopening it, and every later stage may have to be repeated.
• Drawback - testing at the end: faults in the design are found only after all the code is written, and risk is concentrated in the last stage.
• Drawback - unsuitable for unclear or interactive work: it fits a problem that is well understood and stable, not one whose requirements will emerge as users see the system.

Iterative development and rapid application development

Iterative development goes round the stages more than once. Each iteration is a short pass through analysis, design, coding and testing that produces a working version of part of the system, which the users try. What they say feeds the next iteration, so the requirements are allowed to become sharper as the system grows.

An iteration can add a feature (incremental development) or refine an existing prototype (evolutionary development); either way the project delivers working software early and repeatedly instead of once.

Rapid application development (RAD) is the fastest form of this idea. A small team works closely with the users, often in workshops where the users sit with the developers and agree screens and reports on the spot, and it uses prototyping tools, reusable components and code generators so that a working prototype can be produced in a very short time and then refined. Work is timeboxed: each cycle has a fixed short deadline and delivers something usable, and features that do not fit are moved to a later cycle rather than the deadline being extended.

The benefits follow from the feedback. Working software appears early, so a misunderstanding is discovered in the first cycle rather than after delivery; the user tests real screens instead of reading a specification, which is far more reliable; change is expected, so it is cheap; and the highest-priority features can be delivered first. The drawbacks follow from the same speed.

Iterative work needs the user available throughout and able to make decisions, it invites scope creep as new requests appear in every cycle, and the overall design can drift if nobody takes responsibility for keeping the modules consistent. RAD adds its own limits: it needs skilled developers and good tools, it is a poor fit for very large or safety-critical systems where behaviour must be proved and documented, and speed can be bought by skimping on performance, robustness or documentation - which is then paid for in maintenance.

The analysis and design stages in detail

Analysis is about the problem, never the solution. It establishes what the current system does and what the new one must do: the inputs the system receives, the outputs it must produce, the processing in between, the volume of data, who uses the system and how often, and the constraints of hardware, software, money, law and time. The information is gathered by interviewing the client and the users, by questionnaires where there are many users, by watching people do the job, and by studying the documents, forms, reports and files the existing system produces.

If a program already exists, its code is read as evidence of the current rules. The stage ends with a requirements specification agreed with the client, plus success criteria that say how everyone will know the system works. A short feasibility check runs alongside it - whether the system is technically possible, affordable, legal, and worth doing compared with improving what already exists - because everything later is measured against this document, and an error here is the most expensive error in the whole life cycle.

Design plans the solution in enough detail that coding becomes translation rather than invention. It decides the module structure - the decomposition recorded in a structure chart - the logic of each module, written as pseudocode or a flowchart, and a state-transition diagram where the system's response depends on its current state. It also designs the data (variables, records, arrays, files or tables and their validation), the interface (input screens with validation and output reports), and the test plan with its test data.

Design is done on paper because paper is cheap: if you cannot write the pseudocode for a module, you do not yet understand the problem well enough to code it, and it is far easier to redraw a structure chart than to unpick 200 lines of code.

Coding turns each designed module into the chosen language, keeping to the design instead of inventing as you type. Good practice at this stage is what makes the program maintainable: meaningful identifiers, named constants rather than unexplained numbers, indentation that shows the structure, comments that explain why rather than what, one job per procedure or function, and unit testing each module as soon as it is written. Coding is usually the shortest of the five stages; the time saved by skipping design is spent several times over in debugging.

Structure charts: decomposing a problem and passing parameters

A structure chart records the design of a program as a hierarchy of modules. The top box is the main program, the boxes below it are the sub-tasks it calls, and the boxes below those are the sub-tasks of those sub-tasks, down to modules small enough to be written as a single procedure or function. Each box is labelled with what the module does, as a verb phrase such as CalculateAverage or ValidateMark, and each line joins a module to the one that calls it.

The arrows on the lines are the important part: they are labelled with the data that passes between the modules, so the chart shows the parameters as well as the structure.

Its purpose is top-down design, also called decomposition. A problem that is too big to solve is broken into sub-tasks, each sub-task is broken again if it is still too big, and the work is finished when every remaining task is small enough to write and test on its own. That gives three practical advantages: different programmers can take different modules, each module can be unit tested separately, and a module can later be rewritten or replaced without disturbing the rest, provided the parameters on its arrows stay the same.

A structure chart is not a flowchart. It shows what the parts of the program are and which module calls which; it does not show the order in which instructions run, decisions, loops or the code inside a module. Those belong in pseudocode or a flowchart for that module, and a chart that tries to show the sequence of events has stopped being a structure chart.

To build one, start with a single box for the whole task and write the sub-tasks the main program must carry out underneath it. For each sub-task ask whether it can be written as one procedure; if not, decompose it again one level down. Then work through every line and decide what data passes along it - what the module needs from the module that calls it (input parameters, arrow pointing down) and what it sends back (a returned value, or an updated variable passed by reference, arrow pointing up).

A value that only tells a module which of several jobs to do, such as a flag or a menu choice, is a control parameter. Every arrow must end up as a parameter in the header of the derived procedure or function, and a module with no arrows takes no parameters.

• PROCEDURE ProcessStudentMarks()
• NumberOfStudents <- GetStudentCount()
• Marks <- InputMarks(NumberOfStudents)
• Average <- CalculateAverage(Marks, NumberOfStudents)
• Grade <- AssignGrade(Average)
• CALL DisplayReport(Average, Grade)
• ENDPROCEDURE
• FUNCTION ValidateMark(Mark : INTEGER) RETURNS BOOLEAN
• IF Mark >= 0 AND Mark <= 100 THEN RETURN TRUE ELSE RETURN FALSE
• ENDFUNCTION

State-transition diagrams

A state-transition diagram documents an algorithm whose next action depends on the state the system is currently in. It shows every state the system can be in, drawn as a circle labelled with what is true in that state, and every event or input that moves it from one state to another, drawn as an arrow labelled with that event. Where an action or output happens on the way, it is written on the arrow as well, so the diagram records state, event and response together.

The diagram is used for event-driven systems: a vending machine, a cash machine, a lift, a ticket barrier, a traffic light sequence, a washing machine program, a network protocol, or the menu and game states of an application. In all of these the same input means different things at different times - pressing the coin return is valid while money is held and meaningless when the machine is idle - and that is exactly what a state-transition diagram makes explicit. It also shows which events are illegal in each state, which is where a great many bugs live.

A flowchart is a poor substitute here. A flowchart traces one run through a program from start to finish; a state-transition diagram shows all the states at once and the moves between them, including moves back to an earlier state. For a system that waits for events and can return to where it started, the state diagram is both a better design document and a ready-made source of test cases: every arrow is a transition that has to be tested, including the ones that should be refused.

Errors: finding them, fixing them, avoiding them

A syntax error breaks the grammar of the language, so the translator cannot turn the source into an executable at all. A missing ENDIF, an unbalanced bracket, a mistyped keyword, a comma where a semicolon belongs or a call with the wrong number of arguments will stop the compile, and the translator reports the line - sometimes the line after the real mistake, because that is where the error only becomes obvious. Syntax errors are the easy ones: they are found every time the program is translated, and they are found before it runs.

A logic error is a program that runs to completion and produces the wrong answer. The condition uses < where it needed <=, so the loop runs one time too few; the total adds when it should multiply; the average divides by the wrong counter; the wrong variable is displayed. Nothing in the language forbids any of it, so the translator is silent and the fault is exposed only by comparing the output with the expected result - in testing, in a dry run with a trace table, or in a walkthrough of the code.

A run-time error happens while the program is running, and only when a particular instruction is reached with particular data: dividing by zero, indexing an array outside its bounds, opening a file that is not there, converting text that is not a number, or recursing until the stack overflows. The program usually halts with an error, which is why a fault that never showed in testing can appear the first week the system is used - the test data never took that path.

Errors are exposed by testing with data chosen to reach the awkward paths, by dry running the algorithm with a trace table before it is ever coded, by structured walkthroughs in which colleagues read the code aloud and question it, by a debugger with breakpoints, single stepping and watched variables, by temporary output statements, and by unit testing each module as it is written rather than saving everything for the end. They are avoided earlier and more cheaply: design the module before coding it, use structured code with one job per module, choose meaningful identifiers and named constants, declare variables with the right types, validate every input, check for zero, empty and out-of-range values before dividing or indexing, handle exceptions where a failure is possible, review each other's code, and test as you go. Correcting a fault means fixing its cause rather than the symptom, then rerunning the whole test plan, because a fix in one module is a favourite way of breaking another.

• Syntax: found by the translator at compile time; the program cannot run until every one is fixed.
• Logic: found only by comparing output with the expected result - testing, dry run, walkthrough, trace table.
• Run-time: found only when the offending instruction executes with the offending data; hard to reproduce, so record the exact input that triggered it.
• Expose: planned test data, dry run, walkthrough or code review, debugger, unit tests, regression tests.
• Avoid: design first, modular structured code, meaningful names and constants, validation, bounds and zero checks, exception handling, peer review.

Testing: the methods, the plan and the data

Testing is not one activity but a family of them, and the mark usually comes from saying who does it and what it can find. A dry run is a person working through the pseudocode or code by hand, recording every variable in a trace table, with no computer involved: it finds logic errors while the design is still on paper. A walkthrough is a structured review in which the programmer presents the code to colleagues who step through it and challenge it; it finds faults the author cannot see and spreads knowledge of the code.

White-box testing is done with knowledge of the code and aims to execute every statement, branch and path, so coverage can be measured. Black-box testing ignores the code entirely and tests inputs against the expected outputs from the specification, which is why it can find a requirement that was never implemented. Integration testing joins modules together and tests the joins, looking for faults in the parameters passed between them, and a stub is a dummy module that stands in for one not yet written, returning fixed values so that the module that calls it can be tested - the standard tool of top-down integration testing.

The last three methods move outward to the customer. Alpha testing is carried out in-house, by the developers and their own testers, in controlled conditions before release. Beta testing releases the near-final software to real users outside the organisation, who use it on their own hardware and report faults; it finds what no laboratory can, because the variety of machines, data and habits of real users cannot be simulated.

Acceptance testing is the client testing the system against the requirements specification to decide whether it is fit for purpose and can be accepted - and paid for - and it is normally done with the client's own data.

A test strategy is the overall approach: what will be tested, at which stage, by whom, with which methods, how much coverage is enough, what counts as a pass, how faults are logged and closed, and what must be true before testing starts and before the system is released. A test plan is the document that applies the strategy to one system or one phase. It lists the features to be tested and the order they will be tested in, the test data for each test, the expected result for each test, and space to record the actual result, whether it passed, who ran it, when, and what was done about any failure.

Both are needed because unplanned testing is not repeatable: without a written plan nobody can prove what has been tested, the same tests are not rerun after a change, and the tests that are left out are always the awkward ones.

Test data is chosen deliberately, not invented as you go. Normal data is typical valid data that the system should accept and process correctly. Abnormal data is invalid data that the system should reject - wrong type, wrong sign, impossible value, missing value - and it tests the validation rather than the calculation.

Extreme or boundary data is the data at the edges of the acceptable range, and one step outside it, because faults collect at boundaries: a field that accepts 11 to 18 should be tested with 11 and 18 (accepted), and with 10 and 19 (rejected). For every item of data the plan states the expected result, so that a failure is a disagreement between two written statements rather than an opinion.

Maintenance, and changing a program that already works

Maintenance is everything that happens to a system after it is delivered. It is needed because a system lives for years while the world around it does not stand still: users find faults that testing missed, the organisation changes what it wants, the hardware, operating system or file formats are replaced, and the law or tax rules change. Maintenance usually lasts far longer than development and accounts for the largest share of the total cost of a system over its life, which is why the documentation produced in the earlier stages matters so much - a change cannot be made safely in code nobody can read.

There are three types, and they are told apart by why the change is made: corrective maintenance fixes a fault - a calculation that is wrong, a report that crashes on a particular customer, a validation rule that lets through a value it should reject. Adaptive maintenance changes the system because something outside it has changed: a new version of the operating system, replacement hardware, a new file format, a change in the law such as a new rate of tax, or moving the system to a network. Perfective maintenance improves a system that is already working: a faster search, a clearer screen, an extra report the users have asked for, or the code tidied up so that future changes are easier.

The awkward cases are decided by cause, not by effort: adding a report the users requested is perfective, because nothing was wrong and nothing outside changed, while changing the program because the government altered the tax rate is adaptive, because the program was correct for the old rule. A program that crashes when a customer's name contains an apostrophe needs corrective maintenance, however small the fix. Getting the label wrong loses the mark even when the example is sensible.

Enhancing an existing program - the practical skill in this section - follows the same discipline in miniature. Read the documentation and the code until you can say which modules are involved; identify the interfaces, because the parameters on the structure chart tell you what a module may safely be given and what it must return; plan the smallest change that does the job instead of rewriting what works; keep to the existing style and naming; update the structure chart, pseudocode, test plan and user documentation; add test data for the new behaviour; and then rerun the whole existing test plan, not just the new tests, because a change in one module is the commonest way of breaking another. Keep a copy of the working version before you start, so that a failed change can be undone.

• Corrective: the system is wrong - fix the fault, retest, update the version.
• Adaptive: the environment changed - new platform, new law, new format; the program was right before.
• Perfective: the system works - make it faster, clearer or more capable.
• Before amending: back up, read the design and code, find the modules and interfaces, plan the minimum change.
• After amending: update the design documents, test plan and user guide, then rerun every existing test as well as the new ones.