Report an issue
Computer Science (CS) IA Exemplar: Interactive Mathematics Game for… | RevisionDojo
Loading document preview...
View file
Back
IB Computer Science (CS) HL Internal Assessment Example
Scores
Rubric
Similar Examples
10
Chat
Creating an interactive mathematics game for my client (middle school math tutor)
HL
Loading scores...
A
B
C
D
E
7
Official IB Result
27/34
Verified
Criteria A: Planning
5/6
0
3
6
Criteria Strands
Pro
View Full Rubric
A.1
Scenario and Client Investigation
Moderate
A.2
Product Rationale
Moderate
A.3
Success Criteria
Excellent
Criteria Feedback
Clear identification of scenario and two client roles
Well-justified rationale linking system features to client needs
Comprehensive and extensive success criteria covering all major functions
Evidence of client consultation is indirect and lacks dated notes or transcripts
Rationale remains qualitative without comparison to other solutions
A few success criteria are phrased vaguely and could be more measurable
Criteria B: Solution Overview
5/6
0
3
6
Criteria Strands
Pro
View Full Rubric
B.1
Record of Tasks
Poor
B.2
Design Overview
Excellent
B.3
Test Plan
Excellent
Criteria Feedback
Highly detailed and systematic test plan linked to success criteria
Comprehensive design overview with multiple complementary diagrams
Mock-ups and UML diagrams give clear insight into data structures and navigation
No formal or dated task list to show chronological development
Formatting of the test plan is uneven and a few expected results are blank
Record of development milestones is minimal
Criteria C: Development
11/12
0
6
12
Criteria Strands
Pro
View Full Rubric
C.1
Complexity and Ingenuity
Moderate
C.2
Use of Tools
Moderate
C.3
Documentation and Sources
Poor
Criteria Feedback
System handles role-based authentication, dynamic trophy logic and analytics—showing strong complexity
Appropriate and effective use of a DBMS and GUI-building tools
Robust flowchart and UML class diagram illustrate deep understanding of system processes
Documentation of external sources and techniques is minimal, no bibliography provided
Mock-ups omit certain error and loading states, reducing clarity of the full UX flow
Class diagram lacks cardinalities and the structure diagram omits data-flow arrows
Comments
1.1
·
Suggestion
Page 1
• Click to view
Consider adding a legend for symbols and explicitly marking the start and end nodes to improve the flowchart’s readability.
1.2
·
Weakness
Page 1
• Click to view
The flowchart lacks a standardized start/end symbol and legend, which can confuse readers about entry and exit points.
1.3
·
Strength
Page 1
• Click to view
The flowchart provides a comprehensive overview of the system’s processes, showing user actions and decision points clearly.
1.4
·
Suggestion
Page 2
• Click to view
Add association lines with multiplicities (e.g., 1-to-many) to show cardinality and strengthen the model’s clarity.
1.5
·
Strength
Page 2
• Click to view
The UML class diagram lists attributes and methods thoroughly, demonstrating careful consideration of system functionality.
1.6
·
Weakness
Page 2
• Click to view
Relationships and cardinalities between classes are missing, making it hard to see how entities interact within the database.
1.7
·
Weakness
Page 3
• Click to view
Data flow arrows are not shown between components, which reduces visibility of inter-module interactions.
1.8
·
Suggestion
Page 3
• Click to view
Consider annotating the diagram with data flow arrows or numbering to show how information moves between modules.
1.9
·
Strength
Page 3
• Click to view
The structure diagram effectively decomposes the system into modules, clarifying high-level organization.
1.10
·
Strength
Page 4
• Click to view
The sign-up prototype specifies field validation rules clearly, aiding future implementation.
1.11
·
Suggestion
Page 4
• Click to view
Add mock-ups for key error conditions (e.g., duplicate username) and specify layout adaptations for mobile screens.
1.12
·
Weakness
Page 4
• Click to view
The mock-up omits examples of error states (e.g., invalid email or mismatched passwords), which are crucial for UX design.
1.13
·
Strength
Page 5
• Click to view
The login screen mock-up clearly identifies input fields and navigation elements, supporting usability.
1.14
·
Weakness
Page 5
• Click to view
Failure and loading states are not represented, leaving ambiguity about user feedback during authentication.
1.15
·
Suggestion
Page 5
• Click to view
Include mock-ups showing invalid credential messages and spinner animations to capture a complete UX flow.
1.16
·
Strength
Page 6
• Click to view
The submenu for “Play Game” is well organized, grouping related options logically.
1.17
·
Suggestion
Page 6
• Click to view
Illustrate real-time updates to trophies and certificates in the incentives mock-up to reflect system behavior.
1.18
·
Weakness
Page 6
• Click to view
The incentives screen mock-up shows rewards but lacks demonstration of how counters dynamically update.
1.19
·
Weakness
Page 8
• Click to view
The questions list lacks sorting or filtering controls, which would improve the user’s ability to find specific items.
1.20
·
Suggestion
Page 8
• Click to view
Use distinct styling (e.g., italics or color) for hint sections to improve readability and user guidance.
1.21
·
Suggestion
Page 8
• Click to view
Incorporate dropdown filters by topic or difficulty and allow column sorting to enhance manageability.
1.22
·
Strength
Page 8
• Click to view
The quiz details screen presents all question properties, including hints and level, in a clear layout.
1.23
·
Weakness
Page 8
• Click to view
Hint text is not visually distinguished, which may confuse users about its purpose versus main content.
1.24
·
Strength
Page 8
• Click to view
The specific question view neatly displays answer keys and hints, aiding teachers in evaluation.
Criteria D: Functionality and Extensibility
4/4
0
2
4
Criteria Strands
Pro
View Full Rubric
D.1
Product Functionality
Poor
D.2
Extensibility
Poor
Criteria Feedback
Architectural design makes expansion theoretically possible
Mock-ups clearly separate educator and student functions
Screens for performance reporting are well organized
No running prototype or video, so actual functionality cannot be verified
Hard-coded thresholds in design make schema changes non-trivial
UX designs lack pagination/filters for large datasets
Comments
2.1
·
Weakness
Page 7
• Click to view
Menu items are not annotated with required permission levels, risking ambiguity in access control.
2.2
·
Strength
Page 7
• Click to view
The login history table displays comprehensive fields for auditing user sessions.
2.3
·
Suggestion
Page 7
• Click to view
Propose adding search filters and pagination to the history screen to maintain performance as data scales.
2.4
·
Strength
Page 7
• Click to view
The teacher main menu mock-up clearly differentiates educator functions from student views.
2.5
·
Suggestion
Page 7
• Click to view
Annotate which menu options require teacher privileges versus those open to all users.
2.6
·
Weakness
Page 7
• Click to view
No filtering or pagination controls are shown, which could limit usability when history records grow.
2.7
·
Suggestion
Page 9
• Click to view
Consider adding an export button to allow teachers to download performance data for offline analysis.
2.8
·
Weakness
Page 9
• Click to view
No graph visualizations or trend lines are shown, missing an opportunity to depict performance over time.
2.9
·
Suggestion
Page 9
• Click to view
Include a mock-up of a chart (e.g., line graph) to illustrate performance trends over multiple sessions.
2.10
·
Strength
Page 9
• Click to view
The performance screen mock-up succinctly aggregates student scores and progress.
Criteria E: Evaluation
2/6
0
3
6
Criteria Strands
Pro
View Full Rubric
E.1
Evaluation Against Success Criteria
Poor
E.2
Client/Adviser Feedback
Poor
E.3
Future Recommendations
Poor
Criteria Feedback
Makes some tentative recommendations about topic suggestions and grade improvement potential
No post-development evaluation section
No client/adviser feedback provided
Recommendations are hypothetical and not well justified