What is it?
This is where you explain how well the project has done in detail. As long as you can justify yourself you can still get full marks on evaluation without completing the final system.
Copy the requirements
In order to get full marks you need to state the degree of success for every requirement. The easiest way to do this is to copy the requirements and then make a statement on each one.
You need to state how well it was done and provide evidence to back up your claims.
If it worked...
You need to provide proof via –
- Which tests prove your program works?
- Statement from end user (which comes in the next section or in end user testing)
- Screen shots or designs.
You then need to evaluate the degree of success. Something which works may still have problems. You need to be critical of your own work. For example rather than saying “I can easily add a new customer to the database.” You can say “My tests show that a new customer can be added. The form used is intuitive and has clear onscreen guidance to aid the user. However the validation rules could be tightened up a bit as it does not verify if the user has entered a valid email address .”
If it did not work or if it was not completed...
You need to be able to justify why something does not work or was not implemented. Statements such as “I ran out of time” do not cut the mustard! You need to justify why you ran out of time (which obviously cannot be that you left it to the last minute!).
Common reasons include –
- Technical problems learning the language or API.
- What I wanted to do was not possible in the software I chose.
- I had to do it differently / manually.
- Delays in previous technical issues meant that this had to be dropped (low priority)
Notice the last comment does say “I ran out of time” but does so in a way which justifies why.
Mark boundaries
3–4 marks |
A full discussion, taking each objective mentioned in (b) (i) and explaining the degree of success in meeting them (indicating where in the project evidence can be found to support this), or reasons why they were not met. |
1–2 mark |
Some discussion about a number of objectives, but some omissions or inadequate explanation of success or failure. |
0 marks |
No discussion present. |
High mark boundary
- Each objective is discussed
- Comments say how WELL a object was completed rather than just saying it was completed
- Evidence to back up claims
- Explanations for objectives not complete are well justified.
Middle mark boundary
- Not all objectives discussed
- Explanations are brief and lack evidence or justification.
Low mark boundary
No discussion present.
Top tips
- Imagine you are in a argument and you have to prove that you had completed a feature. You need as much evidence as you can to back up your claims. This is the essence of evaluation!
- Be critical on your work. You get LESS marks if you say your work has very few problems! All programs have issues.
User response
What is it?
This is acceptance testing. The user will write a statement saying how happy they are with the system and state any issues they may have with the system produced. You again will be assessed on your onscreen help in regards to how user friendly the system is.
What the end user needs to say
- What features they like about the system
- Would they be able to use the system in its current form?
- What problems did they encounter that needs fixing?
Ask your end user to be specific about which features they like or have issues with.
Response to end user statement
You should respond to your user’s statement by explaining how the problems that the user encountered could be rectified. You need to explain how these faults could be fixed by giving detailed suggestions. This section will be big or small depending on how many faults there are!
Mark boundary
3 marks |
The user indicates that the system could be used but there are some faults which need to be rectified. The candidate provides a detailed discussion of how these inadequacies may be dealt with. |
2 marks |
The system is, in the main, user-friendly, but there is room for improvement (eg no on-screen help has been provided). The user indicates that the system could be used but there are some faults which need to be rectified. The candidate has made some limited attempt to discuss how these inadequacies may be dealt with. |
1 mark |
The system does not meet the design specification and the end user is not able to make use of the system. The candidate |
High mark boundary
The user specifies that there are no faults to the system AND it is clear that a well developed solution has been produced.
OR
The user is overall happy but has identified some faults. These faults are discussed and possible solutions detailed.
Middle mark boundary
- The system is user friendly but may lack onscreen help.
- The user has stated that small problems exist with the developed solution
- These problems are discussed but not in any great detail.
Low mark boundary
The system is unusable by the end user.
Desirable extensions
What is it?
This is more of a classic evaluation. The title of “desirable extensions” is misleading. It is really asking for you to say what the good and bad points are and then state possible improvements.
Good and bad points
You need to state what are the good and bad points of your system. Like in any evaluation you need to be specific and really should focus on specific objectives. So rather than saying “it is easy to use” you can talk about specific forms which are easy to use. What makes them easy to use (like on screen help and validation rules).
The bad points should be areas of weakness noticed by your end user. You MUST NOT talk about objectives which were not implemented. Just focus on what parts of the system you IMPLEMENTED and you will be fine.
Possible extensions
Note – DO NOT say that objectives you have not completed are extensions. They are not!
Extensions are “wish list” ideas. Things which could be done but would of been impossible to complete. Things such as implement a online shopping basket and checkout service or automated fingerprint recognition. Extensions must
- NOT be part of the original specification
- Be desirable and useful (i.e. not just eye candy!)
- Be practical and offer value to the user.
You must also suggest how the extension could be implemented. This includes what hardware and software it would need and a rough idea how it could be implemented. This means that you should not include really complicated extensions!
Mark boundary
3 marks |
The candidate clearly portrays the good and bad points of the system indicating the limitations, possible extensions and how to carry out the extensions. |
2 marks |
The candidate clearly identifies good and bad points and any limitations. |
1 mark |
The candidate identifies the obvious good points of the system and possibly some bad points or limitations. |
High mark boundary
- Well chosen good and bad points have been stated.
- Well chosen extensions with explanations on how to implement the extensions.
Middle mark boundary
- Well chosen good and bad points have been stated.
Low mark boundary
- Has stated the good parts of the system but not many / any bad points.
