Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Computing Module 6 - Coursework
This is a short(ish) guide to the AQA CPT6 coursework specification, for 2009. I wrote this myself, from experience - this may apply to other exam boards, but they probably have slightly different specifications, so be sure to fulfil your exam board's specification, not necessarily AQA's. I cannot tell you how to make your system, or exactly what to write in your documentation because it's got to be your own work, but I can provide a breakdown of the sections you should include in your documentation, just like any teacher can, and like other resources on the internet do.
At the top there are some Frequently Asked Questions about the general specification, and also some points you can refer to if you're trying to work out whether the problem you've chosen is suitable for this project. The main section is the project breakdown - what you're going to put in your write-up. The words in orange are the main things you need to include - if you're looking through this after completing your project to check everything's complete, you can do this quickly by checking you have all the orange sections included in your documentation.
FAQs
The Specification
FAQ: Does my user have to be real?
Answer: No - unlike in ICT, this is not specified in the specification. It's possible to complete the project without a real user, but a few points must be taken into consideration before you decide this. Do not state anywhere in your write-up, that you do not have a real user. Not only this, but you could lose marks all over the place for this. In Analysis (because interviews and questionnaires are required with the end user), in Design (because feedback is required), and in Evaluation (as the majority of this is the analysis of feedback from your user). If you really, really have nobody who needs a new system making, then ask someone to be your user, and to make a problem up for you. Otherwise, although possible, if you completely invent a user and a problem, it could end up going very very wrong.
FAQ: Do I need to put absolutely everything I do in my write-up?
Although it is envisaged that the candidate will develop a complete working solution, the project report need only contain carefully selected samples of evidence in order to demonstrate each skill.
Answer: Computing projects are going to contain a lot of code, and it would be unrealistic of the exam board to expect all this code to be put into the write-up and annotated. Therefore, only a sample of this work is required, and it's usually suggested that the more complex/advanced code is put in the documentation and explained. As long as there's not an unrealistic amount, it may be a good idea to put the complete code listing in an appendix at the end of the write-up.
FAQ: What software can I use to make my system?
Answer: Your teacher may have specified this and told you the best software to use. A lot of candidates use Microsoft Office Access, and this is very suitable for the project. However, Access projects must contain a large amount of VBA coding to be suitable, and to gain high marks. This is Computing, and the project requires a significant programming aspect. A standalone programming language such as Pascal may be used, and is a popular choice.
FAQ: Is my project idea suitable?
Answer: There's no easy way to tell, but if your idea ticks the vast majority (and ideally all) of the points below, then your project is suitable.
Is it a real situation that the candidate can investigate?
Is there a user whose needs can be investigated and taken into account when designing the solution?
Does it conform to the specification requirements i.e. will the finished product be a tailored solution which allows interaction between the user and the computer system with input, storage and manipulation of data and output of results?
Is it of Advanced Level standard?
Is it within the capability of the candidate to complete in a reasonable time?
Are the necessary facilities readily available to the candidate?
Is it a subject the candidate has knowledge of/interest in?
Club/gym/society membership - creating invoices, sending out letters
Video/book rental - be careful with this one. You need to remember that realistic libraries will have more than one copy of each book
Equipment/instrument rental - you could also include future reservations for items
Vehicle hire - make sure prices are realistic, and fuel/mileage is taken into account if necessary
Sporting events - ensure it's not a one-off event, and can be used multiple times
Newspaper delivery - make sure you don't copy the example Heathcote puts in some of her books
Hotel/GP/repairs/entertainment booking system - possibilities are endless here
Project Breakdown
Analysis
(12 marks)
The longest section, worth the most marks, but also the hardest to gain full marks on. This really does need to be spotless to get marks above 15. The first thing you need is the background to, and identification of the problem. In this section, you must describe the current system in full - an annotated Data Flow Diagram would help here too. You'll need to carry out appropriate analysis fact-finding techniques such as observations, questionnaires, and/or interviews with your end user and other staff. From this, you'll then need to identify the prospective users of the system, including the user's skills when it comes to working with a computer - think about whether the users will be able to use the system with ease, or whether training may be required. Talk about the hardware currently used by your user, and take this into consideration by talking about system delivery (how will the system be delivered once it's been completed - if the user doesn't have a CD-ROM drive, then delivering it on CD won't be useful). Then talk about the ICT requirements of the new system - this is basically general objectives, written out in paragraph style. Consider the current data flow (draw an Data Flow Diagram), and then draw an generalised Entity Relationship Diagram - remember, you haven't designed the tables yet. Finally, you need to list the system objectives, one by one (consider a bulleted list), and explain each and every one of them. Make sure they're quantitative and not qualitative (i.e. use specific values instead of saying "the system must work well". These are known in the specification as the "evaluation criteria". The last thing you need to do for this section is to consider the feasibility of possible solutions for the problem (list spreadsheet, database, bespoke, and discuss advantages and disadvantages of both), and then come to a conclusion as to which is the best solution to use. The justification of the chosen solution must be in depth, and must show what decisions were made when you chose to use the solution.
In summary, to get the top range of marks for Analysis:
Evidence of an extensive well structured analysis.
Extensive investigation of a demanding open ended problem showing realistic appreciation of system requirements and demonstrating a high level of perception of a real user’s needs.
Clear and comprehensive set of measurable system objectives.
Design
(12 marks)
You should then consider drawing, and explaining, a Data Flow Diagram for the proposed system. You must also show the modular structure of the proposed system, for example which menu options/groups you have to navigate through to reach a specific process. This can be kept relatively simple. Then, identify the appropriate storage media and format of your system - where will the system be stored (probably the computer's hard drive, but you must compare and contrast different methods such as USB devices and even floppy disks) and the format of the data (series/sequential etc. If you're using Access, it's simply the "Microsoft Office Access database format". Then you start the actual design - begin by listing all the data/fields you're going to use (as in a flat file database), and normalise them to Third Normal Form, and if necessary to Boyce-Codd Normal Form. Then draw an Entity Relationship Diagram showing your normalised model, write out a detailed data dictionary, and talk about validation required in the system. You then need to draw and annotate your form and report designs, write out query designs (including what they do and what they'll be used for), and macro and algorithm designs (e.g. data archiving or anything you intend to do using VBA/other coding - you can design this is Pseudo code). You finally need to talk about system security (password etc.), and your general test strategy (how and why you will test the system) - you do not need to create a test plan at this stage.
In summary, to get the top range of marks for Design:
Evidence of detailed design, well fitted to a problem of adequate or greater scope, incorporating all the required aspects for the development of a fully working system.
Technical Solution
(15 marks)
This section does not appear in your documentation. It refers to your complete system, and the marks are awarded from evidence (program/macro listings, samples of annotated design views) in other sections (Maintenance, Appendices).
In summary, to get the top range of marks for Technical Solution:
A robust working project that demonstrates a high standard of technical competence over a range of complex tasks.
For a program: Well-structured program/suite of programs demonstrating methodologies appropriate to the programming language used.
For a package: Fully tailored solution including the writing of complex programming language routines to provide a solution fully fitted to the user requirements.
Testing
(6 marks)
This is where you create a full test plan, and carry out all the tests you list. You need to say if each one was successful or not. If the system behaves as you expect, you need to show this by using screenshots and annotations. If something fails, you should show that it doesn't work, attempt to fix it, run the test again and explain what you did to fix the problem. This is called corrective action, and you need evidence of this. You should also carry out a system walkthrough - the best way to do this is to ask your user to write down some scenarios that they want you to complete, based on the original requirements they gave you. You should then sit down with them, and work through the given scenarios (such as print off a list of members), and you should ask your user to comment on each scenario (whether it worked or not, etc.). This should also be documented by screenshots if possible.
In summary, to get the top range of marks for Testing:
A well-designed test plan showing expected results supported by selected samples of carefully annotated and crossreferenced hard copy showing test runs that prove the reliability and robustness of the candidate’s system.
All significant aspects thoroughly tested using boundary and erroneous data.
Maintenance
(6 marks)
The Maintenance section is important because not only does it provide you with a possible six marks, it also provides a lot of the 15 marks for the technical solution. It's therefore important that you include enough information here to be able to prove that your system works, and show how it works (past the stage of testing). You will need an introduction to the system, a summary of the software/package you used for the project, and a system overview (tables, relationships, forms reports and queries explained, with a screenshot). Remember you only need a representative sample for this section - show your best forms and queries off. You'll then need annotated listings of program code and algorithms. Again, choose your best, most complex processes, the ones you're most proud of. You need to annotate the code to show which bits do what, and you'll need to indicate how this links in with your form objects. You'll then need to list all of your procedures/functions and variables/constants. The final part of Maintenance is to mention any known problems or limitations of the system, such as futureproofing problems. This won't be a long section, but you should try to find something to write about here.
In summary, to get the top range of marks for Maintenance:
A clearly set out overall system design supported by details of the component parts and underlying structures.
For a program: Overall system design including information about modules/procedures etc. Representative samples of algorithm design using an appropriate standard method. Program listings clearly set out and selfdocumenting.
For a package: List and clear description of items developed. Details of data structures and links together with samples of items tailored by the candidate provided in ‘design view’ with clear annotation and full selfdocumenting code listings.
User Guide
(6 marks)
The user guide must act as a separate document, which means it needs it's own title page, it's own table of contents etc. In the user guide, you should make sure you include system requirements (what hardware is needed to run the system), installation (how to get the system up and running), detailed explanations of at least one of the system's functions, how to backup the data in the system, and an error recovery or troubleshooting section for common errors or FAQs. Use screenshots wherever possible to make it user friendly.
In summary, to get the top range of marks for User Guide:
Well presented documentation incorporating an introduction to system describing functionality together with information on how to use the candidate’s system supported by samples of screen displays and error messages. The manual should be at a level appropriate for the prospective user.
Appraisal
(5 marks)
This is the final section, and the section you will lose marks on if you don't have a real user. The first thing you need to do is to compare your final system with each and every one of the original objectives you set out in Analysis. You need to show, with screenshots, that each objective has been achieved. If some objectives haven't been reached, don't worry, and don't go removing them from earlier in your project, because that's where things begin to go wrong. Just explain why it hasn't been achieved (unrealistic objective, or not enough time) and you won't lose marks for that. User feedback is very important here. Your end user must give a detailed report on what they think of the system. This really does have to be very detailed, and it should touch on as many aspects of the system as possible, even the user interface. This can be handwritten and signed, as it provides authenticity of the end user. You must analyse your user's comments, and make comments on them yourself. You then need to consider the possible future developments of the system, such as modifications and extensions. This should be based on the feedback your user gives you in this section, so make sure that it's not 100% positive. You or your user need to come up with ways that the system can be modified to run more efficiently for example, or extra functionality added.
In summary, to get the top range of marks for Appraisal:
Achievement clearly and directly related to objectives.
Analysis of any improvements needed together with realistic suggestions of how these could be incorporated.
Analysis of feedback from users.
Appendices
Here you should place full interview transcripts, scans of existing documentation, real hard copies (not screenshots) of any reports your system generates, and anything else you deem necessary.
Quality of Communication
(3 marks)
Make sure you have a title page, a table of contents, proper headers, consistent layout, logical order, and correct spelling/grammar.
In summary, to get the top range of marks for Quality of Communication
Clearly and logically presented.
Grammar, punctuation and spelling of an acceptable standard with few and minor errors.
Final Comments and Useful Links
The whole project is marked out of 65, and the grade boundaries are usually reasonably consistent from year to year. It's usually approximately 50 (77%) for an A, 44 (68%) for a B, 39 (60%) for a C, 34 (52%) for a D, and 29 (45%) for an E.
The AQA CPT6 specification can be found here.
AQA's CPT6 advice and information booklet can be found here.
If asking for advice in this thread, please ensure you state the subject you're studying, and your exam board.
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
ICT Module 6 - Coursework
This is a short(ish) guide to the AQA ICT6 coursework specification, for 2009. I wrote this myself, from experience - this may apply to other exam boards, but they probably have slightly different specifications, so be sure to fulfil your exam board's specification, not necessarily AQA's. I cannot tell you how to make your system, or exactly what to write in your documentation because it's got to be your own work, but I can provide a breakdown of the sections you should include in your documentation, just like any teacher can, and like other resources on the internet do.
At the top there are some Frequently Asked Questions about the general specification, and also some points you can refer to if you're trying to work out whether the problem you've chosen is suitable for this project. The main section is the project breakdown - what you're going to put in your write-up. The words in orange are the main things you need to include - if you're looking through this after completing your project to check everything's complete, you can do this quickly by checking you have all the orange sections included in your documentation.
FAQs
The Specification
FAQ: Does my user have to be real?
The project will require candidates to identify and research a realistic problem for which there must be a real end-user. (Candidates are not permitted to be their own end-user).
Answer: Yes, according to the specification. In practice, no. Of course it's possible to complete the project without a real user, but a few points must be taken into consideration before you decide this. The specification states that you must have a real user, and so if at any point during the process does your teacher find out that your user doesn't exist, you can lose marks explicitly for this. Therefore, do not state anywhere in your write-up, that you do not have a real user. Not only this, but you could lose marks all over the place for this. In Analysis (because interviews and questionnaires are required with the end user), in Design (because feedback is required), and in Evaluation (as the majority of this is the analysis of feedback from your user). If you really, really have nobody who needs a new system making, then ask someone to be your user, and to make a problem up for you. Otherwise, although possible, if you completely invent a user and a problem, it could end up going very very wrong.
FAQ: Can my project do anything?
The emphasis will be on the project being an open system of a cyclic nature, such as being repeated once a year or once an event.
Answer: This means that, unlike for ICT3 where the system could be for one-use only, this year the system must be capable of running continuously from day to day, not just for one event. In addition to this, it means that your system should contain at least one aspect (e.g. a process) which is repeated regularly, once a month or once a year etc. This is simpler to achieve than most people think - it could be a simple archiving process, where old data is archived on the first day of every month.
FAQ: What software can I use to make my system?
It is possible that these may be provided by a suite of generic application software. It is not within the spirit of this syllabus for candidates to use a stand-alone general purpose programming language.
Answer: This outlines the software that you should be aiming to use for your project. Your teacher may have specified this and told you the best software to use. The vast majority of candidates use Microsoft Office Access, and this is very suitable for the project. The specification forbids a "stand-alone general purpose programming language" such as Pascal/Java/C++ etc., so I would really stay away from these. It is important, if using Access, that the package is customised greatly, not just using Wizards to generate forms and leaving them as they appear.
FAQ: Is my project idea suitable?
Answer: There's no easy way to tell, but if your idea ticks the vast majority (and ideally all) of the points below, then your project is suitable.
Is it a real situation that the candidate can investigate?
Is there a user whose needs can be investigated and taken into account when designing the solution?
Does it conform to the specification requirements i.e. will the finished product be a tailored solution which allows interaction between the user and the computer system with input, storage and manipulation of data and output of results?
Is it of Advanced Level standard?
Is it within the capability of the candidate to complete in a reasonable time?
Are the necessary facilities readily available to the candidate?
Is it a subject the candidate has knowledge of/interest in?
Club/gym/society membership - creating invoices, sending out letters
Video/book rental - be careful with this one. You need to remember that realistic libraries will have more than one copy of each book
Equipment/instrument rental - you could also include future reservations for items
Vehicle hire - make sure prices are realistic, and fuel/mileage is taken into account if necessary
Sporting events - ensure it's not a one-off event, and can be used multiple times
Newspaper delivery - make sure you don't copy the example Heathcote puts in some of her books
Hotel/GP/repairs/entertainment booking system - possibilities are endless here
Project Breakdown
Analysis
(18 marks)
The longest section, worth the most marks, but also the hardest to gain full marks on. This really does need to be spotless to get marks above 15. The first thing you need is the background to, and identification of the problem. In this section, you must describe the current system in full - an annotated Data Flow Diagram would help here too. You'll need to carry out appropriate analysis fact-finding techniques such as observations, questionnaires, and/or interviews with your end user and other staff. From this, you'll then need to identify the prospective users of the system, including the user's skills when it comes to working with a computer - think about whether the users will be able to use the system with ease, or whether training may be required. Talk about the hardware currently used by your user, and take this into consideration by talking about system delivery (how will the system be delivered once it's been completed - if the user doesn't have a CD-ROM drive, then delivering it on CD won't be useful). Then talk about the ICT requirements of the new system - this is basically general objectives, written out in paragraph style. Consider the information flow (draw an Information Flow Diagram), and then draw an generalised Entity Relationship Diagram - remember, you haven't designed the tables yet. Finally, you need to list the system objectives, one by one (consider a bulleted list), and explain each and every one of them. Make sure they're quantitative and not qualitative (i.e. use specific values instead of saying "the system must work well". These are known in the specification as the "evaluation criteria".
In summary, to get the top range of marks for Analysis:
The candidate has identified an appropriate problem in conjunction with their end-user and independently of the teacher.
A clear, statement covering both the context and the nature of the problem has been provided.
The candidate has clearly identified and delimited a substantial and realistic problem, recognising the requirements of the intended user(s) and the capabilities and limitations of the available resources.
All of the requirements are specified and clearly documented. The candidate has fully identified the information flow and data dynamics of the problem.
The analysis indicates understanding of the full potential of the appropriate hardware and software facilities which are available and, as appropriate, the limitations.
The candidate has identified the user’s current IT skill level and training needs.
Qualitative and quantitative evaluation criteria have been identified in detail and analysis has been completed without undue assistance.
Design
(16 marks)
The first thing you need to do for the design is to consider the feasibility of possible solutions for the problem (list spreadsheet, database, bespoke, and discuss advantages and disadvantages of both), and then come to a conclusion as to which is the best solution to use. The justification of the chosen solution must be in depth, and must show what decisions were made when you chose to use the solution. You should then consider drawing, and explaining, a Data Flow Diagram for the proposed system. You can also show the modular structure of the proposed system, for example which menu options/groups you have to navigate through to reach a specific process. This can be kept relatively simple. Then, identify the appropriate storage media and format of your system - where will the system be stored (probably the computer's hard drive, but you must compare and contrast different methods such as USB devices and even floppy disks) and the format of the data (series/sequential etc. If you're using Access, it's simply the "Microsoft Office Access database format". Then you start the actual design - begin by listing all the data/fields you're going to use (as in a flat file database), and normalise them to Third Normal Form, and if necessary to Boyce-Codd Normal Form. Then draw an Entity Relationship Diagram showing your normalised model, write out a detailed data dictionary, and talk about validation required in the system. You then need to draw and annotate your form and report designs, write out query designs (including what they do and what they'll be used for), algorithm designs if applicable (e.g. data archiving or anything you intend to do using VBA - you can design this is Pseudo code, but for ICT it's not required). You finally need to talk about system security (password etc.), your general test strategy (how and why you will test the system), and lastly your full test plan.
In summary, to get the top range of marks for Design:
A relevant range of appropriate approaches to a solution has been considered in detail. Compelling reasons for final choice of solution are given which have been fully justified and the likely effectiveness has been fully considered.
A completely detailed solution has been specified so that it could be undertaken by a competent third party. The proposed solution has been clearly broken down into sub-tasks, with the necessary indications of how those are to be solved. All the requirements are specified and clearly documented.
A well-defined schedule and work plan have been included, showing in detail how the task is to be undertaken. This explains what is required in a comprehensible manner – it can include layout sheets, record structures, spreadsheet plans, design for data-capture sheets, as appropriate.
An effective and full testing plan has been devised, with a comprehensive selection of test data and reasons for the choice of the data clearly specified.
This stage has been undertaken without assistance.
Implementation
(15 marks)
This is relatively simple to explain. You basically need to document (using annotated screenshots and explanations) your implementation. It's so much easier if you do this as you go along instead of trying to remember what you did after completing the system. This section needs to include all the errors you came across during the implementation, and how you fixed them.
In summary, to get the top range of marks for Implementation:
The candidate has fully implemented the detailed design unaided, in an efficient manner and with no obvious defects.
All the appropriate facilities of the software and hardware available were fully exploited.
The documentation is clear and thorough.
Testing
(15 marks)
This is where you take your test plan from Design, and carry out all the tests you listed. You need to say if each one was successful or not. If the system behaves as you expect, you need to show this by using screenshots and annotations. If something fails, you should show that it doesn't work, attempt to fix it, run the test again and explain what you did to fix the problem. This is called corrective action, and you need evidence of this. You should also carry out user acceptance testing - the best way to do this is to ask your user to write down some scenarios that they want you to complete, based on the original requirements they gave you. You should then sit down with them, and work through the given scenarios (such as print off a list of members), and you should ask your user to comment on each scenario (whether it worked or not, etc.). This should also be documented by screenshots if possible.
In summary, to get the top range of marks for Testing:
The candidate has shown insight in demonstrating effective test data to cover most or all eventualities.
There is a clear evidence of full end-user involvement in testing.
The system works with a full range of test data (typical, extreme, erroneous), the test outputs are fully annotated.
User Guide
(8 marks)
The user guide should either be slotted in between Testing and Evaluation, or placed separately after the appendices. Different teachers prefer different things, and it's not clearly stated in the specification as to which they prefer. However, the user guide must act as a separate document, which means it needs it's own title page, it's own table of contents etc. In the user guide, you should make sure you include system requirements (what hardware is needed to run the system), installation (how to get the system up and running), detailed explanations of at least one of the system's functions, how to backup the data in the system, and an error recovery or troubleshooting section for common errors or FAQs. Use screenshots wherever possible to make it user friendly.
In summary, to get the top range of marks for User Guide:
A comprehensive, well-illustrated user guide has been produced that deals with all aspects of the system (installation, backup procedures, general use and trouble shooting).
Evaluation
(10 marks)
This is the final section, and the section you will lose marks on if you don't have a real user. The first thing you need to do is to compare your final system with each and every one of the original objectives you set out in Analysis. You need to show, with screenshots, that each objective has been achieved. If some objectives haven't been reached, don't worry, and don't go removing them from earlier in your project, because that's where things begin to go wrong. Just explain why it hasn't been achieved (unrealistic objective, or not enough time) and you won't lose marks for that. User feedback is very important here. Your end user must give a detailed report on what they think of the system. This really does have to be very detailed, and it should touch on as many aspects of the system as possible, even the user interface. This can be handwritten and signed, as it provides authenticity of the end user. You then need to consider the possible future developments of the system, such as modifications and extensions. This should be based on the feedback your user gives you in this section, so make sure that it's not 100% positive. You or your user need to come up with ways that the system can be modified to run more efficiently for example, or extra functionality added.
In summary, to get the top range of marks for Evaluation:
The candidate has considered clearly a full range of qualitative and quantitative criteria for evaluating the solution.
The candidate has fully evaluated his/her solution intelligently against the requirements of the user(s).
Evidence of end-user involvement during this stage has been provided.
Appendices
Here you should place full interview transcripts, scans of existing documentation, photos of the work place, real hard copies (not screenshots) of any reports your system generates, and anything else you deem necessary.
Report
(8 marks)
The report (write-up) is worth a lot, so make sure it looks decent. Make sure you have a title page, a table of contents, proper headers, consistent layout, logical order, and correct spelling/grammar.
In summary, to get the top range of marks for Report:
A well-written, fully illustrated and organised report has been produced.
It describes the project accurately and concisely.
Final Comments and Useful Links
The whole project is marked out of 90, and the grade boundaries are usually consistent from year to year. It's usually 59 (66%) for an A, 51 (57%) for a B, 43 (48%) for a C, 36 (40%) for a D, and 29 (32%) for an E. The grade boundaries are low, but the marks are hard to get - a good grade is by no means guaranteed.
The AQA ICT6 specification can be found here.
There are some useful resources on the FatMax website, including some project ideas. Be careful though, some of the information on that website is not up to date, and may not fit the current specification.
If asking for advice in this thread, please ensure you state the subject you're studying, and your exam board.
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Originally Posted by iainmacn
I'd take issue with the point about there not having to be a real user for computing - from the specification:
"Candidates should investigate a real problem associated with a user whose realistic needs should be taken into account when designing the solution."
Yes, but the specification is relaxed as opposed to that of ICT6. You won't lose marks for not having a real user in Computing, but you will in ICT. Of course it's recommended that a real user is found, and I've commented on the advantages of this.
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Definitely to be recommended for all the reasons you say
Would you lose marks if the exam board found out your end user wasn't real? The board may have changed their mind from previous years but in the past for computing they've always been pretty clear that it was required.
Having said that, I'm sure lots of projects don't have real end users, it just requires a bit of subtlety (and not concocting fake letters from British Airways saying how impressed they were with an A level student's booking system he'd made for them - sounds daft but I've seen it!)
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Originally Posted by iainmacn
Definitely to be recommended for all the reasons you say
Would you lose marks if the exam board found out your end user wasn't real? The board may have changed their mind from previous years but in the past for computing they've always been pretty clear that it was required.
Having said that, I'm sure lots of projects don't have real end users, it just requires a bit of subtlety (and not concocting fake letters from British Airways saying how impressed they were with an A level student's booking system he'd made for them - sounds daft but I've seen it!)
Not for computing, no. There is nothing in the assessment criteria (marking grid) for teachers or for moderators which touches upon whether the candidate has a real user or not, whereas in the ICT assessment criteria, I remember there is a section which can only be fulfilled if the candidate has a real user. I accept marks are more likely to be lost elsewhere in the project if you don't have a real user, as I've outlined, but that'll be the responsibility of the candidate, I've just stated the facts and yes, haha, I do think some people go a bit over the top with faking letters from organisations singing their praises
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Originally Posted by secretmessages
Not for computing, no. There is nothing in the assessment criteria (marking grid) for teachers or for moderators which touches upon whether the candidate has a real user or not, whereas in the ICT assessment criteria, I remember there is a section which can only be fulfilled if the candidate has a real user.
Sorry if it seems like I'm nitpicking because on the whole I think you've posted some excellent stuff - this is a small technical point - but it is mentioned about the end user in both the appraisal and analysis criteria, and possibly in the technical solution section as well - that last one is somewhat open to interpretation. It could be argued that a solution can't meet the user's requirements if there isn't a real user.
Although it would be nice if the criteria were absolutely watertight, in practice there is a whole load of interpretation going on. That's way more true for ICT than computing in my experience, and the best guide is a teacher who's been to the exam board meetings for that year, as the board can change their interpretation year on year, even if the written specification doesn't change!
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Originally Posted by iainmacn
Sorry if it seems like I'm nitpicking because on the whole I think you've posted some excellent stuff - this is a small technical point - but it is mentioned about the end user in both the appraisal and analysis criteria, and possibly in the technical solution section as well - that last one is somewhat open to interpretation. It could be argued that a solution can't meet the user's requirements if there isn't a real user.
I agree with this, but marks aren't lost explicitly because you haven't got a real user. If someone uses their mother as the end user, she is not a real user for this problem, but she can provide good feedback, and can act just like a real user would. In ICT, it's not acceptable to use your mother as the end user (unless obviously she has a real problem for a real organisation), and I'm just trying to make this distinction. Anyway I'm sure if people read the guides above, they'll also read these comments and will be able to judge for themselves
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Sorry - but they are - it's in the marking criteria, particularly for analysis.
Sure - a family member could give you some feedback on the user interface, but couldn't provide you with feedback on how well the system met their requirements, which is specified in the specification(!). There's also a statement in the appraisal section which I don't remember seeing before about making sure the teacher checks that any user feedback is from the real end user - which again makes me think the board is pressing this point.
They also couldn't provide the stuff you need for analysis, for instance - unless of course they do have a real business or club. If you look at the bands of marks for analysis it's impossible to get above two without a real end user (or making it look like you have one).
It's entirely possible to use family members if they do run a business, or for example a tennis club or similar. Ditto things within a school, such as an attendance monitoring system, or a school library (although that might well not be complex enough).
Anyway - we've probably done this one to death now - it's a good idea for everyone to become familiar with the spec - I wish more students did it
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Originally Posted by iainmacn
...
Could you PM me a copy of the marking criteria you mention, or a quote from it please, so I can have a look at where marks are explicitly lost for having a real user? I'm interested in this change. Thanks.
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Originally Posted by secretmessages
ICT Module 6 - Coursework
This is a short(ish) guide to the AQA ICT6 coursework specification, for 2009. I wrote this myself, from experience - this may apply to other exam boards, but they probably have slightly different specifications, so be sure to fulfil your exam board's specification, not necessarily AQA's. I cannot tell you how to make your system, or exactly what to write in your documentation because it's got to be your own work, but I can provide a breakdown of the sections you should include in your documentation, just like any teacher can, and like other resources on the internet do.
At the top there are some Frequently Asked Questions about the general specification, and also some points you can refer to if you're trying to work out whether the problem you've chosen is suitable for this project. The main section is the project breakdown - what you're going to put in your write-up. The words in orange are the main things you need to include - if you're looking through this after completing your project to check everything's complete, you can do this quickly by checking you have all the orange sections included in your documentation.
FAQs
The Specification
FAQ: Does my user have to be real?Answer: Yes, according to the specification. In practice, no. Of course it's possible to complete the project without a real user, but a few points must be taken into consideration before you decide this. The specification states that you must have a real user, and so if at any point during the process does your teacher find out that your user doesn't exist, you can lose marks explicitly for this. Therefore, do not state anywhere in your write-up, that you do not have a real user. Not only this, but you could lose marks all over the place for this. In Analysis (because interviews and questionnaires are required with the end user), in Design (because feedback is required), and in Evaluation (as the majority of this is the analysis of feedback from your user). If you really, really have nobody who needs a new system making, then ask someone to be your user, and to make a problem up for you. Otherwise, although possible, if you completely invent a user and a problem, it could end up going very very wrong.
FAQ: Can my project do anything?Answer: This means that, unlike for ICT3 where the system could be for one-use only, this year the system must be capable of running continuously from day to day, not just for one event. In addition to this, it means that your system should contain at least one aspect (e.g. a process) which is repeated regularly, once a month or once a year etc. This is simpler to achieve than most people think - it could be a simple archiving process, where old data is archived on the first day of every month.
FAQ: What software can I use to make my system?Answer: This outlines the software that you should be aiming to use for your project. Your teacher may have specified this and told you the best software to use. The vast majority of candidates use Microsoft Office Access, and this is very suitable for the project. The specification forbids a "stand-alone general purpose programming language" such as Pascal/Java/C++ etc., so I would really stay away from these. It is important, if using Access, that the package is customised greatly, not just using Wizards to generate forms and leaving them as they appear.
FAQ: Is my project idea suitable?
Answer: There's no easy way to tell, but if your idea ticks the vast majority (and ideally all) of the points below, then your project is suitable.
Is it a real situation that the candidate can investigate?
Is there a user whose needs can be investigated and taken into account when designing the solution?
Does it conform to the specification requirements i.e. will the finished product be a tailored solution which allows interaction between the user and the computer system with input, storage and manipulation of data and output of results?
Is it of Advanced Level standard?
Is it within the capability of the candidate to complete in a reasonable time?
Are the necessary facilities readily available to the candidate?
Is it a subject the candidate has knowledge of/interest in?
Club/gym/society membership - creating invoices, sending out letters
Video/book rental - be careful with this one. You need to remember that realistic libraries will have more than one copy of each book
Equipment/instrument rental - you could also include future reservations for items
Vehicle hire - make sure prices are realistic, and fuel/mileage is taken into account if necessary
Sporting events - ensure it's not a one-off event, and can be used multiple times
Newspaper delivery - make sure you don't copy the example Heathcote puts in some of her books
Hotel/GP/repairs/entertainment booking system - possibilities are endless here
Project Breakdown
Analysis
(18 marks)
The longest section, worth the most marks, but also the hardest to gain full marks on. This really does need to be spotless to get marks above 15. The first thing you need is the background to, and identification of the problem. In this section, you must describe the current system in full - an annotated Data Flow Diagram would help here too. You'll need to carry out appropriate analysis fact-finding techniques such as observations, questionnaires, and/or interviews with your end user and other staff. From this, you'll then need to identify the prospective users of the system, including the user's skills when it comes to working with a computer - think about whether the users will be able to use the system with ease, or whether training may be required. Talk about the hardware currently used by your user, and take this into consideration by talking about system delivery (how will the system be delivered once it's been completed - if the user doesn't have a CD-ROM drive, then delivering it on CD won't be useful). Then talk about the ICT requirements of the new system - this is basically general objectives, written out in paragraph style. Consider the information flow (draw an Information Flow Diagram), and then draw an generalised Entity Relationship Diagram - remember, you haven't designed the tables yet. Finally, you need to list the system objectives, one by one (consider a bulleted list), and explain each and every one of them. Make sure they're quantitative and not qualitative (i.e. use specific values instead of saying "the system must work well". These are known in the specification as the "evaluation criteria".
In summary, to get the top range of marks for Analysis:
Design
(16 marks)
The first thing you need to do for the design is to consider the feasibility of possible solutions for the problem (list spreadsheet, database, bespoke, and discuss advantages and disadvantages of both), and then come to a conclusion as to which is the best solution to use. The justification of the chosen solution must be in depth, and must show what decisions were made when you chose to use the solution. You should then consider drawing, and explaining, a Data Flow Diagram for the proposed system. You can also show the modular structure of the proposed system, for example which menu options/groups you have to navigate through to reach a specific process. This can be kept relatively simple. Then, identify the appropriate storage media and format of your system - where will the system be stored (probably the computer's hard drive, but you must compare and contrast different methods such as USB devices and even floppy disks) and the format of the data (series/sequential etc. If you're using Access, it's simply the "Microsoft Office Access database format". Then you start the actual design - begin by listing all the data/fields you're going to use (as in a flat file database), and normalise them to Third Normal Form, and if necessary to Boyce-Codd Normal Form. Then draw an Entity Relationship Diagram showing your normalised model, write out a detailed data dictionary, and talk about validation required in the system. You then need to draw and annotate your form and report designs, write out query designs (including what they do and what they'll be used for), algorithm designs if applicable (e.g. data archiving or anything you intend to do using VBA - you can design this is Pseudo code, but for ICT it's not required). You finally need to talk about system security (password etc.), your general test strategy (how and why you will test the system), and lastly your full test plan.
In summary, to get the top range of marks for Design:
Implementation
(15 marks)
This is relatively simple to explain. You basically need to document (using annotated screenshots and explanations) your implementation. It's so much easier if you do this as you go along instead of trying to remember what you did after completing the system. This section needs to include all the errors you came across during the implementation, and how you fixed them.
In summary, to get the top range of marks for Implementation:
Testing
(15 marks)
This is where you take your test plan from Design, and carry out all the tests you listed. You need to say if each one was successful or not. If the system behaves as you expect, you need to show this by using screenshots and annotations. If something fails, you should show that it doesn't work, attempt to fix it, run the test again and explain what you did to fix the problem. This is called corrective action, and you need evidence of this. You should also carry out user acceptance testing - the best way to do this is to ask your user to write down some scenarios that they want you to complete, based on the original requirements they gave you. You should then sit down with them, and work through the given scenarios (such as print off a list of members), and you should ask your user to comment on each scenario (whether it worked or not, etc.). This should also be documented by screenshots if possible.
In summary, to get the top range of marks for Testing:
User Guide
(8 marks)
The user guide should either be slotted in between Testing and Evaluation, or placed separately after the appendices. Different teachers prefer different things, and it's not clearly stated in the specification as to which they prefer. However, the user guide must act as a separate document, which means it needs it's own title page, it's own table of contents etc. In the user guide, you should make sure you include system requirements (what hardware is needed to run the system), installation (how to get the system up and running), detailed explanations of at least one of the system's functions, how to backup the data in the system, and an error recovery or troubleshooting section for common errors or FAQs. Use screenshots wherever possible to make it user friendly.
In summary, to get the top range of marks for User Guide:
Evaluation
(10 marks)
This is the final section, and the section you will lose marks on if you don't have a real user. The first thing you need to do is to compare your final system with each and every one of the original objectives you set out in Analysis. You need to show, with screenshots, that each objective has been achieved. If some objectives haven't been reached, don't worry, and don't go removing them from earlier in your project, because that's where things begin to go wrong. Just explain why it hasn't been achieved (unrealistic objective, or not enough time) and you won't lose marks for that. User feedback is very important here. Your end user must give a detailed report on what they think of the system. This really does have to be very detailed, and it should touch on as many aspects of the system as possible, even the user interface. This can be handwritten and signed, as it provides authenticity of the end user. You then need to consider the possible future developments of the system, such as modifications and extensions. This should be based on the feedback your user gives you in this section, so make sure that it's not 100% positive. You or your user need to come up with ways that the system can be modified to run more efficiently for example, or extra functionality added.
In summary, to get the top range of marks for Evaluation:
Appendices
Here you should place full interview transcripts, scans of existing documentation, photos of the work place, real hard copies (not screenshots) of any reports your system generates, and anything else you deem necessary.
Report
(8 marks)
The report (write-up) is worth a lot, so make sure it looks decent. Make sure you have a title page, a table of contents, proper headers, consistent layout, logical order, and correct spelling/grammar.
In summary, to get the top range of marks for Report:
Final Comments and Useful Links
The whole project is marked out of 90, and the grade boundaries are usually consistent from year to year. It's usually 59 (66%) for an A, 51 (57%) for a B, 43 (48%) for a C, 36 (40%) for a D, and 29 (32%) for an E. The grade boundaries are low, but the marks are hard to get - a good grade is by no means guaranteed.
The AQA ICT6 specification can be found here.
There are some useful resources on the FatMax website, including some project ideas. Be careful though, some of the information on that website is not up to date, and may not fit the current specification.
If asking for advice in this thread, please ensure you state the subject you're studying, and your exam board.
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Just a quick question regarding the Implementation aspect of the specification. If you are dealing with SQL in a programming environment, (For example in my system I will be using PHP and MySQL), do you have to include the SQL in the code listing for creating the tables? MySQL allows you to generate these tables automatically, much like access. Do you have to declare the actual SQL needed to generate them in the listing? ( CREATE table contact { order int unsigned not null }) etc, etc.
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Originally Posted by n2s
Just a quick question regarding the Implementation aspect of the specification. If you are dealing with SQL in a programming environment, (For example in my system I will be using PHP and MySQL), do you have to include the SQL in the code listing for creating the tables? MySQL allows you to generate these tables automatically, much like access. Do you have to declare the actual SQL needed to generate them in the listing? ( CREATE table contact { order int unsigned not null }) etc, etc.
Many Thanks
Is this for Computing or ICT? If it's not written by yourself then perhaps include just a couple of examples of the code, but it depends which section you're intending to put it in. However, make it clear that you didn't write the code yourself and that it was automatically generated, but show anywhere that you've customised the SQL if applicable.
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Awesome thread, you shall be getting some rep points (when I say some, I mean 36) today This will be majorly helpful for me in the coming year (well, I was supposed to have finished the Analysis section over the summer ... oops :P )
Re: Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
Originally Posted by LastLordofTime
Awesome thread, you shall be getting some rep points (when I say some, I mean 36) today This will be majorly helpful for me in the coming year (well, I was supposed to have finished the Analysis section over the summer ... oops :P )
Computing and ICT discussion, revision and homework help.
Useful Resources:
Computing and ICT Coursework (CPT6/ICT6) Help and Advice Thread
. These are known in the specification as the "evaluation criteria". The last thing you need to do for this section is to consider the feasibility of possible solutions for the problem (list spreadsheet, database, bespoke, and discuss advantages and disadvantages of both), and then come to a conclusion as to which is the best solution to use. The justification of the chosen solution must be in depth, and must show what decisions were made when you chose to use the solution. 
and yes, haha, I do think some people go a bit over the top with faking letters from organisations singing their praises 
