Technical Solution Guidelines

The Technical Solution

The technical solution that you produce is worth more than half the marks for your NEA. This means that this is expected to take up a majority of your project time.

Roughly 1/3 of the marks of your solution are for the completeness of solution. The rest of the marks come from the techniques used and the coding style shown.

Evidencing The Technical Solution

The full listing of your technical solution should be given in your report. This can either be done in your technical solution or as an item in your Appendix section. Either way it is important to refer to the code from within your report.

You will need to make sure that your code:

• Contains useful comments that explain difficult algorithms or parts of the code.

• The code should be self-documenting, so that it can be read without additional explanations. Using meaningful identifiers throughout will help with this.

• Use appropriate file names. When putting code into the report, include titled sections for each major part or file so that it is obvious what will be included.

Source Code

When you put the source code into the report you need to copy and paste if from the IDE rather than using screenshots. This will mean that the code will be easy to read.

Copying and pasting source code can lead to some problems with code that goes beyond the page being difficult to follow. This makes adding titles to different files and sections in your code important so it is easier to follow.

Make sure that when you paste the text in from the IDE you keep it in its original formatting so that it appears as it should in the IDE.

Code Contents Page

Before the code in your report you should create a contents page that will help the reader identify where the key parts of the program are with their page number.

Completeness of Solution

You will gain marks for the completeness of your solution compared to the objectives you originally set out to achieve.

If some of your objectives were very hard and beyond A level standard, you will not be marked down for failing to achieve these. However, if your objectives were too easy, even if you complete them all, there is a high likelihood that you will not get full marks. For this reason you need to make sure that you have objectives that allow you to show the technical skills from Group A.

You should aim to meet all the objectives of your system. Appropriate testing of your code will help in providing evidence that you have met the objectives.

Techniques Used

You will be awarded a mark for the techniques that you have used in your programming. Be aware, the marks here are given for what you actually manage to successfully program and not just what you planned.

The code listings that you evidence will help to establish the use of techniques. You will need to make sure that your code contains comments to highlight where techniques have been used, especially if they are in Group A in the mark scheme.

The marks that you recieve for this section will be based on:

• Use of technical skills

• How well the technical skills have been implemented

• Use of coding styles

• How effective the solution is

You may find that producing a short video will help to demonstrate the effectiveness of the solution. It may also help to have feedback from the end user(s) or supervisor here.

You also might find it helpful to refer back to you Documented Design section to help explain sections of code.

Coding Styles

The style of code which you use will make a difference to the mark you are awarded for techniques, This is something you need to consider right at the start of your coding, as it will be very difficult to change once you have built your solution.

Whilst the mark scheme classifies different coding the styles of Excellent, Good and Basic, in order to achieve an excellent coding style , you will need to also achieve the characteristics of Good and Basic.

Your mark is evidenced through the overall quality of your code, not just one section that demonstrates good coding style, so you will need to be consistent throughout your work.

The example below shows a small section of code and how it can demonstrate many of the features of Basic, Good and Excellent coding styles. You will not need to highlight or comment to show these styles in your code because the teacher and moderature will be able to recognise them in your code.

Good coding style will also be demonstrated through:

• Creating self-documenting code - this is achieved by using good identifier names, well-organised code and annotation/comments. This will make the code easy to understand without any further documentation.

• Use of a consistent style throughout - there are different styles of indentation, variable naming and validation that can be carried out. Make sure this stays consistent through your code.

• Parameterised file paths - if you are reading or writing files then you should not refer to a path such as 'C:\Users\LukeSmith' as this would only work of computers set up for that user on that drive. Instead you should use relative pages such as '..\documents\May2010.pdf' or use environmental variables such as '%HOMEPATH%\SchedulingSystem'.

• Creating a well-designed user interface - to do this, consider how the design helps the user with labels and titles and a neat arrangement of objects.

For outstanding code quality, your program will also need to use defensive programming techniques. This means that the program will continue to work even if unforeseen circumstances occur. Techniques that will help in demonstrating defensive programming include:

• Make sure the program code is fully tested and any errors are fixed.

• Make good use of exception handling

• Validating user input and handling invalid data in a predictable manner.

• Making sure that the source code is readable.