Download presentation
Presentation is loading. Please wait.
Published byLeona Hamilton Modified over 8 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.