Implementation

What is it?

This is where you actually make the software!  Your selection of project will heavily influence how implementation will occur. However the documentation side of things will all go in a similar fashion.

Order to develop in

A big project needs to be planned out! Below is a VERY rough guide on the order you should do things.

Your forms will most likely be designed but will not do anything. Implementation of these will involve adding the code to get them working!

It does not need to be perfect!

Due to the size of these projects and the potential complexity it is very likely that not all features will be implements and that bugs will exist. This is not a problem and is very normal. As long as you can justify why things have not worked or have not been implemented then you will not be docked marks. Phew!
However for top marks on implementation you do need to complete everything.

Proper coding standards

When coding remember to –

Alpha testing

To get the top marks you need to test as you go. You will do this naturally as you will want to make sure what you have done works! However you also need to prove that you have done it! When you complete a section of work run your tests from your test strategy to ensure it works. Then when you document it you will have for EACH form –

Note – Any bugs you find document! Write down when something goes wrong! This is proof that you are testing your code! If you have no bugs then we will not believe you! No one has no bugs when they program!

How to document

You will have the following sections

Database implementation

Form implementation

Note – one of these PER form

Mark boundaries

13–16 marks

There is complete evidence showing how the solution was developed using suitable alpha testing at each stage to inform the process. The modular code is fully annotated indicating clearly the purpose of each section and the interrelationship between the sections. The developed solution fulfils all of the design specification.

9–12 marks

Program listings are provided in the form of printouts. Data structures are illustrated as part of the listings where appropriate, detailing their purpose. There is sufficient annotation evident to illustrate how the solution was developed for a particular purpose and indicate the purpose of sections of code. The code will be modular and there will be good evidence to show how testing was used during the development process to inform each stage. The developed solution fulfils the design specification but there are some minor flaws in the solution.

5–8 marks

Program listings are provided in the form of printouts. Data structures are illustrated as part of the listings where appropriate, detailing their purpose. There is some annotation evident to illustrate how the solution was developed and some limited evidence that some testing took place during development. The developed solution has significant flaws and only partially fulfils the design specification. The code may be linear but with some annotation indicating how the code relates to the problem and some limited evidence of alpha testing.

1–4 marks

Program listings are provided in the form of printouts but with no annotation or evidence of alpha testing. The developed solution does not fulfil the design brief

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Note – annotation can mean comments!

High mark boundary

Middle mark boundary

Low mark boundary

Very low mark boundary!

Top tips