1. Computer Science Project Criteria

2. Computer Science Project The project is intended to simulate the analysis, design, progamming and documentation stages of a computer based solution to a real-world problem.

3. A1 - The Analysis What’s Good The problem is analysed in detail from the user’s point of view There is evidence of data collection Details of present/previous solutions The user goals are stated Why the project is being undertaken, not how

4. A1 – The Analysis What’s Bad Students focus on the solution not the problem The end-user is imaginary The problem is poorly defined

5. A2 – Criterion for Success What’s Good Objectives are limited (5-6), clearly stated and attainable They are clearly linked to the user’s goals They include usability objectives Bullet points probably best

6. A2 – Criterion for Success What’s Bad Too many objectives Not clearly linked to user goals Not all user goals are covered Lots of writing A1 and A2 merged

7. A3 – Protoype Solution What’s Good Prototype must be proceeded by an initial design (simple and modular) Prototype will show basic menus Feedback from user is documented and leads to revised prototype Analysis stage checked off by teacher

8. A3 - Prototype Solution What’s bad No design shown No documented feedback

9. B1 – Data Structures What’s Good All file / data structures listed with sample data All choices justified Full explanation of how they will work within the program

10. B1 – Data Structures What’s Bad Data structures absent No satisfactory explanations for their inclusion or their functioning Description of generic structures Loss of mastery marks

11. B2 Algorithms What’s good All main algorithms listed ‘Header’ includes brief description, parameters and return values

12. B2 Algorithms What’s bad Code taken from final program Code too detailed (esp. standard routines) Parameters / return values missing Every minor method included

13. B3 – Modular Organisation What’s good Modular design shown (classes) Links shown to data structures and methods Followed by descriptions Teacher checks off design stage

14. B3 – Modular Organisation What’s bad Missing links Lack of descriptions

15. C1 – Programming Style What’s good Contains a detailed header Classes clearly separated and described All methods described Comments within the methods Indentations correct

16. C1 – Programming Style What’s bad One long set of code Inadequate internal documentation Ink cartridge running out

17. C2 – Handling errors What’s good A varied range of error handling described Sections of code included or referenced Table format good

18. C2 – Handling errors What’s bad Range of different types of errors lacking No code shown or referenced

19. C3 – Success of the Program What’s good Documented evidence linking to a complete sample run showing that all objectives from A2 have been met

20. C3 – Success of the Program What’s bad No section devoted to this Objectives from A2 not explicitly referred to

21. D1 – Hard Copy of Test output What’s good Most options are shown All test runs are annotated All ‘mastery’ aspects shown to work Teacher witnesses test runs

22. D1 – Hard Copy of Test output What’s bad Runs are not annotated Changes are not shown

23. D2 – Evaluating Solutions What’s good The solution is outlined The effectiveness of the program from the viewpoint of the user discussed The efficiency of the coding discussed Alternative approaches discussed

24. D2 – Evaluating Solutions What’s bad Written on the deadline day Looked at purely from the point of view of the programmer Too brief – no discussion

25. Recommendations A real user is found Repeated interaction between user / student / teacher until clear realistic, attainable goals have been set Teacher sets no-pass deadlines