SECTION F – EVALUATION

 

Section F – Evaluation (6 marks)

The system life cycle is a continuous process – problems are analysed, solutions are designed, implemented and tested and then the whole process starts again! Look at any popular piece of software and you’ll find it’s in its nth version (Paintshop Pro 7, Office 2000, Flash 5 etc.) Why? After completing projects good system designers carry out a thorough evaluation of their solutions. Features that work well in the solution will be incorporated into later versions while those features that are missing or don’t perform as well as expected are either added or replaced.

It’s tempting, after mastering Access and producing a workable solution, to sit back, think “I’ve finished!” and produce a 3 line evaluation patting yourself on the back for a job well done. Don’t!

• No design is perfect.

 

• Due to time limits you may not have been able to satisfy all the user requirements.

• You may have had ideas about a feature you would like to have used but at this stage, didn’t know how to do it.

 

• You may have expected Access to perform a function beyond its capabilities.

• Your testing will have identified these limitations and/or other errors – how many calculated fields did you leave named as “expr1”or formatted as number when they should have been currency?

 

• Evaluation accounts for 10% of the total mark!

• Three lines is hardly likely to gain 10%

 

• You need to evaluate your project against your original specification, identify its limitations and identify potential improvements.

Preparation

 

Evaluation is all about assessing what was successful AND how your solution could be improved:

• Look at you original objectives. Make a note of those you achieved and those that weren’t achieved. You’ll need to look at your testing to find evidence that you actually fulfilled these objectives. Make a note of the pages that show the evidence.

 

• Try and evaluate why some objectives weren’t achieved and make notes on why not. You don’t need to know the solution but try to explain how your solutions failed. Be honest!

• Make sure you have an end-user questionnaire. See Section D. Your end-user is the only person who can truly evaluate the system. (S)he should have evaluated your system already. Try and get them to complete a summary evaluation (cross-referenced to the original user requirements) printed or written on company notepaper.

 

Paperwork

Your evaluation must prove two things:

• You have, as far as possible, satisfied the user requirements
• You have taken account of the limitations of your solution

 

You could use the following outline plan to write up your evaluation. This is not prescriptive and you may choose to include more headings:

• Evaluation

 

1.1             User requirements
Restate your original user requirements and/or objectives as a numbered list. This will provide a checklist for you to evaluate your project against

1.2             System Evaluation
Work through the numbered list systematically and evaluate how well you have met your objectives – some will have been completely met, others partially met and others not met at all. Be honest in your evaluation. You’ll be given credit for recognising the limitations of your solution.

Don’t make broad, sweeping statements such as “it worked well”. Each of the comments in your evaluation must be cross-referenced to evidence – either the results of your testing or feedback provided by the end-user.

• Enhancements

Even if your system met all the end-user requirements and passed rigorous testing it is likely that it could still be improved. Write a few paragraphs outlining how your system could be improved. This may include minor enhancements (such as adding or removing controls from a form) or major upgrades (adding completely new modules).

Finished!

Now sit back and congratulate yourself on a job well done. Enjoy having some time to yourself and take a moment to relax. We start the major project in two weeks!