Problem > Analysis > Design > Implementation > Testing > Evaluation

Problem – The programmer/team meets with the client and identifies the task. The client will specify exactly what they need the program to do and what data they expect the program to process.

Analysis – They now examine the task, testing feasibility and deciding what the key points of the program are. The boundaries and scope of the program are stated, so the client knows the capabilities of the program.

Design - The main steps of the program are laid out and split into sub-problems. A data flow diagram can be used to show the flow of data. Code is not made, but the overall program is planned out.

Implementation – The programmer checks the design with the client and against the client’s needs to ensure it is what they wanted. The client may require a specific programming language, so this needs to be decided. The program is developed in modules or chunks, so they can be tested individually. There may also be standards set which outline how the program should be made because it is essential for later maintenance and improvements to have readable code.

Testing – Programmers will have to test the program to ensure it works with normal, boundary and erroneous data. They may also have to test how well optimised the code is for the system, and how much resources the program will need to operate. The program may also be given to a trial number of users in a company to see how well it copes with normal use and to receive feedback from people who will be using the program in the future. Adjustments to the program can be made if it is not adequate in any of these ways.

Evaluation – The programmer goes through their code making sure it is readable and is maintainable. They will also test its efficiency on system resources. Mainly, they will make sure it is fit for the purpose specified in the analysis, comparing it against the client’s requirements.

Definitions

Feasibility Study – An assessment of how possible and practical it would be to make the program.

Top-down design – Breaking down the problem into sub-problems to understand it better.

Modular design – Designing the program as separate modules. More manageable and can test in chunks.

Data flow diagram – Graphical representation of the flow of data through the program – flowchart.

Data dictionary – Describes the structure of data to be used in the program.

Variables table –

Prototype – A model of the program that show the main functions of the finished product.

Normal data – Data inputted that is expected in the program, and that is expected to work.

Boundary data – Data inputted that is on the edge of the boundary for normal data.

Erroneous data – Data that should be rejected by the program. Data that is incorrect.

Black box testing – The tester doesn’t know the inside workings of the program.

White box testing – The tester knows the internal workings/structure of the program.