Criterion E - Evaluation

Instructions and Advice

From the Syllabus:

"Evaluation of the product
The evaluation of the product should refer directly to the success criteria in criterion A, feedback from the client/adviser, as well as any other appropriate feedback obtained

5–6 The product is fully evaluated against the success criteria identified in criterion A including feedback from the client/adviser. Recommendations for further improvement of the product are realistic.

Mr Rayworth Instructions:

(An overall key point from past grading: Make sure you reference the client feedback. It has to be clear that what you are basing your recommendations on is from the client. Some of the recommendations could come from you alone, but in a perfect world all would come from the client. Just make sure that most of the recommendations are from the client. So either direct quotes, or references to an interview, for example.)

(An overall key point from past grading: Do make sure to paste in Stage A - Criteria for Success, don't just refer to it.)

(An overall key point from past grading: You are once again required to include a word count for the complete Criterion E.)

Step 1: Criteria For Success Table

Make a table, for example, in which you copy and paste your Criteria for Success. And then comment one way or the other about whether or not you achieved that criteria.

- If you accomplished any given criteria, there is no need to do much commenting about it, or indeed any commenting at all, beyond "Accomplished".

- If you did not accomplish any given criteria, YOU NEED TO write a sentence or two explaining why you did not. (And if you suddenly realize you have forgotten a simple criteria for success, such as hover message (toolTextTip), or meta keyboard shortcut, it could be argued that now is an Ok time to do so, and this exercise of going through your criteria for success valuable for this reason as well.)

- And if you went beyond what you had planned, this also should be explained and justified, and hopefully with respect to your client's wishes and needs.

Step 2: Build and Distribute the Program

Video of how to build the executable file for distribution from Netbeans.

Build and zip your dist folder of your program and either hand deliver it to your client, or e-mail it to them - and don't forget instructions to not change the locations of the files and folders within the diet folder (which you should re-name as your program's name).

And remember that with making the "Build", you first have to go to the Propertie and select the main main method (probably the one in your GUI.)

Step 3: Get Feedback
- ***this may not be possible the first time through doing Stage E (if many students are not yet finished their code). So half a class should be set aside at a later date to finish this off after everyone has delivered the final product to their client, and also received feedback from them.

Get feedback from your client. This is primarily what you will base your recommendations on so that your recommendations are realistic, as required to get full marks for this.

You can e-mail both the application and the video of how it works to give them an idea of how to use it.

Suggested Approaches

A. Arrange to interview your client after they have used your program a little bit.
---> Come up with questions for that interview to get things rolling; try to keep them a bit more specific that just "Do you like your program?"

B. Come up with the questions and e-mail them to your client. Maybe even have them answer according to a 1 to 5 scale. And in this case, you could even use your success criteria as the points they are evaluating you on.

In coming up with your questions, consider

- if you have time run the program with them and watch how they use it and look for any problems with the way they do so

- whether they think you have achieved the various criteria for success - even show the

- things they like best, or don't like

- was it like they expected; how so or how not

- things they would like improved

- ask them about particular ways particular things work

- recommendations for improvement, including how important those requests are, and possibly realistic they would consider them to be from their perspective.

From the Syllabus

"Recommendations for the future development of the product
The student will use the feedback and the evaluation of the specific performance criteria to recommend possible future developments to the product. These recommendations should explain the benefits of these developments."

5–6 The product is fully evaluated against the success criteria identified in criterion A including feedback from the client/adviser. Recommendations for further improvement of the product are realistic.


Step 4: Recommendations from Client

Best might be a three column table:

Recommendation for Improvement Benefits Why/how Realistic

Or you could do it more in narrative form. But one way or the other, you need to be sure the recommendations are realistic, and there are two people involved in that assessment - you the programmer, and your client as well.

One way to have gotten the conversation of recommendations going with the user is to go over your ***realistic*** extensibility/To Do list with your client to get their feedback on these ideas. This will likely prompt other ideas and recommendations.

****But a BIG THING**** here is you HAVE TO REFERENCE your conversation/interview with your client when you showed them the finished, or almost finished, product. Direct quotes, or footnotes, or something. And that interview needs to appear some place, so why not here, instead of an appendix, and just put a big bold "Interview Does Not Count in Word Count" note by it.


As soon as you can you need to package your program and get it to your client to use and try out. And either at the same time, or shortly after that you need to interview them to find out how they like it, and any improvements they would wish.