Like every year, many solutions consisted of a front-end coded in either Java, Python or HTML, which connected to a variety of back-end databases. There was a widespread variety in the quality of projects submitted. 

Most students showed a clear understanding of the assessment criteria, but many chose to address them in a superficial manner and only a few students put effort into producing high quality work. 

There were some projects with inadequate products (e.g. a website or Access database created from template). Some projects did not address a real-life need for a real client and would be better suited as a classroom exercise in coding. 

Some students developed only a prototype and not a fully functional solution.

Some students embarked on overly ambitious projects like a fully functional library system or a time-tabling system for their school. These complex project ideas are beyond the scope of the Computer Science IA and should be discouraged.

There is a clear correlation between strong Criteria for Success and successful projects. It is therefore recommended that teachers spend time on guiding students to produce sufficient, specific and measurable Criteria for Success.

Students should be guided to create a proper Design Overview which documents their algorithmic thinking in flowcharts and/or pseudo-code, and which explains the data structures to be used in their solution. Screenshots of the actual product have no place in design and will be discounted. 

Please limit the screencast videos to 7 minutes. Do not allow students to speed-up their videos as sped-up videos tend to become unintelligible. These videos should only show evidence for the full functionality of the solution. Code design or extensibility should not be included in the screencast.

Students should be guided to write a proper evaluation against the Criteria for Success, which incorporates and refers to meaningful client feedback to be added in an appendix. Recommendations for improvement should go beyond unfulfilled CfS and they should avoid the word 'more' (as in more content, more images, more levels, etc.) and instead focus on realistic improvements to the existing product (like solving problems that only became apparent after the client started using the product).

There was again a wide variety in the quality of projects submitted. Most students showed a good understanding of the assessment criteria, but many chose to address them in a superficial manner. 

Few students put in the effort to produce high quality work.

Like last year, many solutions consisted of a front-end coded in either Java, Python or HTML, which connected to a variety of back-end databases. A few of the samples showed evidence that these had been developed from a standard outline solution provided to the students by the teacher. This kind of uniform approach is (obviously) not valid. Similarly, a "fill in the boxes" approach to the documentation will not allow much differentiation between projects in a school's sample, as all students will make the same misguided mistakes. On the other hand, many inspiring and sometimes surprising products were seen that had been developed with the client's need in mind.

Overall, there appear to be more issues with superficial projects, for example:

• prototypes of a potential solution instead of an actual solution.

• underdeveloped databases, that hardly do more than save and display data.

• classroom exercises in coding (basic add/edit/delete/save).

• non-integrated solutions (often websites) where the client must edit the back-end database directly.

• trivial use of complex tools and techniques, like recursion to run a loop.

• trivial login with sign-up that gives access to a single workspace (in other words, anybody can enter and access all data and functionality).

Projects that aimed to address a real-life need for a real client tend to achieve better than the ones with unfocused Criteria for Success.

Some students embarked on overly ambitious projects like a fully functional library system or a time-tabling system for their school. These project ideas are beyond the scope of the Computer Science IA and should be discouraged.

Teachers should encourage the students to follow the Systems Development Life Cycle and document the various stages as they work through them.

There is a clear correlation between strong Criteria for Success and successful projects. It is therefore recommended that teachers spend time on guiding students to produce sufficient, specific and measurable Criteria for Success.

Students should be guided to create a proper Design Overview which documents their algorithmic thinking in flowcharts and/or pseudocode, and which explains the data structures to be used in their solution. Screenshots of the actual product have no place in design and will be discounted.

Please limit the screencast videos to 7 minutes. Do not allow students to speed-up their videos as sped-up videos tend to become unintelligible. These videos should only show evidence for the full functionality of the solution. Code design or extensibility should not be included in the screencast.

Students should be guided to write a proper evaluation against the Criteria for Success, which incorporates and refers to meaningful client feedback (to be added in an appendix). Recommendations for improvement should go beyond unfulfilled CfS (which are considered trivial). They should avoid the word 'more' (more content, more images, more levels, etc.) and instead focus on realistic improvements to the existing product (like solving problems that only became apparent after the client started using the product).

In comparison to the May 2023 session, fewer projects followed the guidelines for submission by not including all the appropriate documents. Some students submitted links to products, videos or even documentation. This is not acceptable and linked components will be ignored by the moderator. Both the product and the video need to be uploaded as part of the submission. Only one 7-minute video should be included and only to show evidence of the functionality of the solution (no code, no extensibility, no recommendations for improvement). Moderators are not required to watch or listen to any other (potentially lengthy) video or audio files.

Like last year, many solutions consisted of a front-end coded in either Java, Python or HTML, which connected to a variety of back-end databases. There was a wide spread in the quality of projects submitted. 

Most students showed a clear understanding of the assessment criteria, but many chose to address them in a superficial manner and only a few students put effort into producing high quality work. 

There were some projects with inappropriate scenarios (like coding a solution to issues that cannot be solved with a coded program) and inadequate products (e.g. a website or Access database created from template). 

Some projects did not address a real-life need for a real client and would be better suited as a classroom exercise in coding. 

Some students made worthwhile efforts to create control systems. However, these were typically developed as a prototype and not as a fully functional solution.

Some students embarked on overly ambitious projects like a fully functional library system or a time-tabling system for their school. These project ideas are beyond the scope of the Computer Science IA and should be discouraged.

There is a clear correlation between strong Criteria for Success and successful projects. It is therefore recommended that teachers spend time on guiding students to produce sufficient, specific and measurable Criteria for Success.

Students should be guided to create a proper Design Overview which documents their algorithmic thinking in flowcharts and/or pseudocode, and which explains the data structures to be used in their solution. Screenshots of the actual product have no place in design and will be discounted. 

Please limit the screencast videos to 7 minutes. Do not allow students to speed-up their videos as sped-up videos tend to become unintelligible. These videos should only show evidence for the full functionality of the solution. Code design or extensibility should not be included in the screencast.

Students should be guided to write a proper evaluation against the Criteria for Success, which incorporates and refers to meaningful client feedback to be added in an appendix. Recommendations for more images, more levels, etc.) and instead focus on realistic improvements to the existing product (like solving problems that only became apparent after the client started using the product).

Most samples followed the guidelines for submission and included the appropriate documentation. Some students submitted links to either product or video. This is not acceptable and linked components will be ignored by the moderator. Both the product and the video need to be uploaded as part of the submission. 

Only one 7-minute video should be included to show evidence of the functionality of the solution. 

Evidence of client interaction must be in writing. Please note that examiners cannot be expected to listen to (potentially lengthy) audio files of interviews.