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.
- Database structure
- Test data
- Database controller + database classes
- Form which contains some of the main features
- All other forms in order of most important to least important.
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 –
- Use comments!
- Use indentation
- Use functions where possible
- Use sensible variable names
- Follow your class diagram!
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 –
- Code listing
- What the code does / additional information
- Test run / alpha test
- Any bugs found
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
- Screen shot of every table
- Make it clear if any validation rules are implemented on the database
- Also make it clear which field is the primary key!
- Screen shot of test data (which should be sensible!)
- You do not need much test data. About 3-5 rows will do!
- Short description of each table. This could be copied from design.
Form implementation
Note – one of these PER form
- Code listing
- Maintaining the syntax colouring would be helpful but not critical
- What the code does / additional information
- You can /should reference design here!
- Test run / alpha test
- Copy your tests for that form and then run them!
- Any bugs found
- Screenshots help here but are not always necessary. DO NOT include syntax errors!
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
- Data structures are clearly evidenced and annotated
- Code is modular (uses functions + classes)
- Code has clear annotation for every function, class and relevant structures
- The code fully fulfils the design brief
- Code has been well tested
Middle mark boundary
- Data structures are clearly evidenced and annotated
- Code is modular (uses functions + classes)
- Code has clear annotation for every function, class and relevant structures
- The code fulfils the design brief but will have minor flaws or omissions
- Code has been tested during development and bugs have been found
Low mark boundary
- Data structures are c evidenced
- Code is annotated but may not be in detail.
- The code only partially fulfils the design brief
- Limited testing evidenced
Very low mark boundary!
- Code listings are evidenced but not annotated (or limited annotation)
- The code does not full fill the design brief
Top tips
- Leave yourself 2-3 months to produce the implementation. It is really important you do not try and rush it!
- If you know you will have difficulties producing a bit of code see your teacher BEFORE you get to it. That way they can point you in the right direction or write some sample code for you. Waiting for help will be a bottle neck you will want to avoid!
- Make sure you document any logic or runtime errors you get. Even if you just jot it down in rough first. It will help you document the code later.
- The internet is your friend! Use it!