Aspects of software development revision notes

Analysis

Before solving a problem, define it clearly, establish the system requirements and create a data model. Requirements should be established by interacting with the intended users. Prototyping or an agile approach can help clarify requirements, while abstraction can model relevant aspects of the external world in a program.

Design

Design specifies how the solution will be constructed. This includes planning data structures for the data model, designing algorithms, choosing a modular structure and designing the human user interface. Modules should have clear, documented interfaces. Design may be iterative, particularly when using prototyping or an agile approach.

Implementation

Models and algorithms are implemented as data structures and code that the computer can understand. Development involves writing, debugging and testing programs. A solution may be developed iteratively, with the critical path addressed first. A programmer should be able to explain how a program works and argue for its correctness and efficiency using logical reasoning, test data and user feedback.

Testing

Testing checks the implementation for errors. Selected test data should include normal data, boundary data and erroneous data. Normal data is typical valid input; boundary data tests relevant limits; erroneous data is intended to reveal how the system handles invalid input. The system should also undergo acceptance testing with intended users to check that it meets its specification. Evidence of user feedback is required, rather than details of tests performed by the end user.

Evaluation

A completed system must be evaluated using the criteria for evaluating a computer system. Do not confuse testing with evaluation: testing seeks errors in the implementation, whereas evaluation considers the system against appropriate criteria.

Common errors

Do not treat requirements as assumptions made only by the programmer. Do not omit the data model from analysis or the user interface from design. Do not use only typical test data. Do not claim that acceptance testing is complete without intended-user feedback. Do not describe an iterative process as necessarily following a single fixed sequence.