Avoiding common errors in interpreting the markscheme
One general comment is regarding proformas. Although it is recognised that some candidates will require a lot of help, the use of proformas is neither encouraged nor supported by the exam boards. They tend to restrict students' thinking, and sometimes make it difficult to tell whose work it really is.
1) Analysis
Identify a problem: For the 4th mark, students must define a complex problem, before they create a solution. A complex problem is one which requires more than one type of software to solve it.
Use methods of collecting information: Information must be collected from potential users of the ICT System. Collecting information from, for example, video store customers, is not acceptable; it must be from the people who will operate the computers. The information collected should be realistic; again, collecting from friends is inappropriate.
Note: some of my students were so enthusiastic one year that the local library phoned to complain about the volume of questionnaires they were being sent! In such a case it might be more appropriate to invite someone in for a group interview.
Identify the inputs, outputs and processing required: The specification states "Based on a manual card-index system..." Many students fail to identify the processes. Also, for 3/4 marks a system specification is required. At this point a detailed hardware & software specification is not needed, just a general list. Software should be generic, not trade names. It is not acceptable to reference this list for the Design section.
2) Design
Produce designs for the data structure: Field definitions should include lengths and data types. There should be more than one alternative - but note that different sections of a data structure, such as a customer table and a product table, are not alternatives; they are part of the same design set. Spreadsheet designs must include formulae.
For the third mark, students should comment on how appropriate the designs are, and make a choice with reasons ("because"). The chosen design should then match that in the implementation - but note that they should leave scope for changes!
Produce designs for the user interface: Hand-drawn designs for user screens, forms, etc, are expected - printouts from a database are not designs. They should be annotated in order to describe them. Third mark as above.
Produce designs for the output formats: As above, for reports and mailmerged letters, etc.
Produce hardware and software requirements: At this point detail is required. Students should give detailed, but realistic, hardware specifications, including peripherals, and software specifications which, as well as the generic application (eg database) can now specify a named product (eg MS Access). It is useful for students to experience the use of alternative software; if cost is an issue then schools should consider free alternatives such as Star Office and OpenOffice.org.
3) Implementation
This section tends to take the longest to complete, many students get hung up on entering pages of records. Twenty is sufficient in most cases! Teachers and students alike miss the fact that the marks are given essentially for "How I did it" and "What did I change".
Implement their data structure: Best practice here involves labelled screenshots. The key principle to remember is "can a competent user recreate the database from the instructions?" for 2 marks. For 3/4 marks students must make at least two changes to the data structure, giving reasons.
Implement their input and output formats: As above. Note that they should produce a system - ie it does more than just store data - so they should prepare standard queries, reports, and mailmerges. A switchboard or main user screen is really useful here, and easy to set up (guide sheet in lesson notes).
Use features of software appropriately: Although there is no need for specific documentation of this, it can be helpful, and the 4th mark is difficult to acheive otherwise. For 2 marks, three features of one application (eg database) should be evident. For 3 marks, another three features in a second application (eg wordprocessor). For the 4th mark students must say why they have used each feature, which is why some documentation of the features is helpful.
Combine software features: This is a big problem area. For two marks, "data must be transferred for two separate purposes". The most common is a mailmerge. Another could be transfer to a spreadsheet for graphing purposes. Copy and paste is NOT acceptable. As it is a lot of work for just one mark, many centres regard this as a throwaway mark.
4) Testing
Describe their testing: Needs evidence of tests being carried out, eg screenshots. For 3 marks, a number of tests to "thoroughly test the solution" are required. Three or four tests is not thorough! Students often use simplistic testing strategies which don't consider the needs of the end user. For the 4th mark, testing by a user is required in addition to the rest. Testing by peers is not really appropriate as their classmates will almost certainly be more skilled in using the software than the average end-user!
Describe the results: A coherent test strategy is essential. Students should select extreme data to test the limits of their solution. They need to forecast the results of the tests before carrying them out, then comment on the actual results. "It worked" is a weak comment and students should be encouraged to carry out more challenging tests. For the 3rd mark they must explain why the test data was selected.
6 User Documentation
This must focus on telling users how to use the system, not how to use the software.
Show a user how to enter, amend, and save data: Instructions to do just that. Loading the software should only be a small part of that. Often students create user screens, then show users how to enter data directly into the table! Look for Enter, Amend, Save.
Show a user how to process and output data: If a system has been created, then this should be a case of how to run the prepared query, report, mailmerge, etc.. It should not be about how to create them - this scores 0. This is where a good switchboard or user screen comes in - buttons or hyperlinks can open these, making the user guide easy to write.
Show a user how to avoid problems: Again, not about the software or hardware. It should involve messages which might be generated by the checks that the student has built in, eg validation checks. The 2nd mark is for the ways of solving the problems.
7) Evaluation
This is about what the solution can do. If no system has been created then it cannot be evaluated, and this section will score 0.
For 1 mark, students list what the system can do. For 2 marks, they compare what the system can do with the users requirements. For 3 marks, they also discuss what the system cannot do and how it could be improved. For the 4th mark, a user must provide some feedback/evaluation of their system.
Note: if all aspects of the DESIGN mave not been completed, the mark here is limited to 2. User testing also cannot apply if the users were not correctly identified in the analysis.
Back to Index Page Back to Tips for Teachers
