IB Computer Science (CS) HL Internal Assessment Example

There is no rationale explaining why this exact application was chosen over alternatives. A clear Product Rationale section should justify design decisions and discuss trade-offs.

The student provides no real-world scenario or client investigation, which are essential for contextualizing the project. Adding a dedicated Planning section with client background and consultation details would strengthen alignment with the rubric.

No explicit success criteria are listed against which to evaluate the finished product. Include measurable, client-focused criteria to guide testing and evaluation.

A holistic design overview (e.g., diagrams of data structures, class models or UI wireframes) is missing. Include high-level design documents to show the planned architecture.

No structured test plan is provided. A table listing test cases, purposes, expected and actual results is needed to demonstrate thorough quality assurance.

There is no record of tasks, such as a Gantt chart or time log, to demonstrate how development was managed. Add a chronological task record to meet the rubric requirements.

Creating and initializing the SQLite database via code illustrates moderate system complexity. The student effectively connects GUI actions to persistent storage.

The database query functions are well organized in a dedicated section, showing clear separation of concerns. This supports maintainability and reuse.

The confirm_details() method tries input validation then database insertion, demonstrating encapsulation of functionality. Good organization of responsibilities in a single class.

The clock-in INSERT operation (Figure 9) cleanly captures real-time data in the logs table. The manager’s ability to view these entries supports system integrity.

The encapsulation discussion is accurate but would benefit from linking to specific code snippets. Consider including annotated examples showing how methods and fields are protected.

The abstraction section nicely describes interface hiding, but adding a specific code excerpt showing the handle_login() method would reinforce the explanation.

The polymorphism explanation is clear, and the runtime connection of buttons to different methods illustrates the concept well.

Inheritance is described but limited to single-level examples. To demonstrate deeper modularity, consider showing multi-level inheritance or shared base functionality.

References are listed but citation formats vary widely and lack consistency. Adhere to a single style (e.g., APA) and include inline citations where appropriate.

The integration of PyQt5 and SQLite3 demonstrates effective use of existing tools to build GUI and database functionality. This aligns well with rubric expectations.

In Figure 8 the code contains syntax errors and inconsistent variable names (e.g., “curson” vs “cursor”), which will prevent compilation. Correct these issues to ensure functionality.

The GUI screenshots (e.g., login and dialog views) are consistent and professionally styled, supporting intuitive user interaction.

The comment-reply table in Figure 23 uses placeholder data and inconsistent spacing. Replace with realistic test data and ensure uniform cell formatting.

Holiday schedules shown in Figure 24 display start and end dates in one cell, reducing readability. Separate columns for each date to improve clarity.

The wage-record view is comprehensive and clearly labels each column, enabling efficient manager review of employee earnings.

The scheduling calendar offers a simple UX but lacks confirmation of remaining holidays. Displaying remaining days and validation errors would enhance usability.

In the Fetch Wage Records code, variable names and arithmetic contain typos (e.g., “hours_words”, “\theta”). Correct these to guarantee accurate computation.

The schedule() function contains missing SQL, mismatched variable names, and improper indentation. Fix the query and logic to ensure holidays are recorded correctly.

The Try-Except Block example clearly shows error handling for duplicate usernames, preventing crashes and guiding user feedback.

No evidence of client or adviser feedback is included. Collect and document stakeholder responses to validate the product meets user needs.

There are no future recommendations or reflections on how the system could be improved or scaled. Add realistic, well-justified suggestions for next steps.

There is no evaluation section reflecting on success criteria or client feedback. Include a dedicated evaluation with quantitative and qualitative analysis.