You need the following mark scheme headings in c(i) of your project:

• Technical description of how the solution relates to the design specification.
• Evidence of development work.
• Testing during development.
• Fully documented code.
• Modular programming.

Technical description of how the solution relates to the design specification.
The easiest way to do this is to write (using report-writing style, of course) about your project. Start by stating what language you used, what version and any additional tools, libraries, IDEs used etc. Point out the features in whatever programming language and IDE you used and say how you actually used them to meet specific requirements in your Requirements Specification. You need to explain clearly how you achieved all of the things mentioned in the Requirements Specification, using the functions and features and tools available in the language and IDE you selected.

Evidence of development work.
You should refer to your diary entries here and the many discussions you should have had with your user at different stages of development. You should refer to printouts of draft copies of mock-ups. You should show here printouts of the product at different stages of development and discuss what you were doing briefly.

Testing during development.
You should refer to your test strategy in b(iii). You should then refer to the next section c(ii), where you user can see details of the testing that has taken place during development. You don't need to repeat what is already in other places in your project - simply refer the reader to it.

Fully documented code.
You should start by describing what the reader is about to look at. You should then print out the whole system. This should print out each input screen, each output screen or report or hardcopy, any menu screens, and any screens asking the user to do something. Each printout or screendump must have a clear title and a clear explanation, stating what the reader is looking at.

Then move on to describing the code; the procedures, the functions, any libraries used, any tools used, any code you got and used from other sources and so on, so the reader has a written description of the parts of the program. however, the reader also needs a clear understanding of how it all fits together so that must be described in writing, too. Diagrams will help you get across how your program works and there are a number of standard ones you should have learnt about. In OO for example, these are described as part of the theory work in Unit F453, section 3.3.6.

Now print out the code. The usual rule of thumb with code is that it should commented in such detail that if you took away the code, someone could reconstruct it from the comments! That means your code should be documented in detail, clearly. Use spacing, indentation and meaningful names for variables and such like.

When you have done this section, see if someone at home can follow what you have written! If they can, then you have probably written clearly enough.

Modular programming.
In this section, describe your use of libraries (both ones you have written and external ones), procedures and functions, with examples. Refer to the code in the last section, demonstrating your use of subroutines. (Don't print out code again - just refer to the relevant parts in the code from the last section and highlight their use). Get across why you used modular programming.

CHECK:

ARE YOU USING YOUR TEMPLATE(S)?

ARE YOU USING REPORT WRITING STYLE?

HAVE YOU BEEN UPDATING YOUR DIARY?