1. A2 Agreement Trial ICT November 2012

2. Agenda  10.00 GCE ICT – Entries and Transitional Arrangements  10.152012 Outcomes and Issues  10.45Coffee  11.15Principal Moderator’s Report Exemplar Materials  12.30Lunch  1.15Exemplar Materials  3.00Plenary

3. Objectives To inform Centres of the new A2 Assessment Arrangements To provide feedback from the A2 Award 2012 To agree marks for the exemplar materials

4. GCE ICT Entries Unit Existing Component Code New Component Code Revised Weighting Revised UMS Implementation Date AS1AW111AP111 60% of AS 30% of A-level 120 UMS For first examination in January 2013 AS2AW121AP121 40% of AS 20% of A-level 80 UMS For first submission in May 2013 A21AW211AP211 60% of A2 30% of A-level 120 UMS For first examination in January 2014 A22AW221AP22140% of A2 20% of A-level 80 UMSFor first submission in May 2014 New cash-in codes: - S2654 for first AS level cash-in summer 2013 - A2654 for first A2 level cash-in summer 2014

5. GCE ICT Entries Resit candidates:  Previous weightings will still hold for candidates who began the course prior to September 2012 i.e. candidates in Y14 who are resitting AS units  Existing component codes must be used – AW111, AW121  Existing cash-in codes must be used – S2653 for AS in Summer 2013  For candidates who are resitting all of Y13 again i.e. being held back a year, they must be entered using the new component and cash-in codes – AP111, AP121 and cash-in S2654 The final resit opportunity for A2 candidates, who began the course prior to September 2012 under the old weightings, will be in January 2014

6. The Current A2 Award Issues with the current A2 Award  Coursework grade boundaries rising  Examination performance causing some concern at the upper end of the mark range

7. Changes to A Level ICT AS Unit Weightings From September 2012 40%( Coursework)/60% (Examination) A2 Unit Weightings From September 2013 40%( Coursework)/60% (Examination)

8. Coursework Weightings SectionMark Analysis20 Design20 Implementation and Testing20 Documentation10 Evaluation10 Total Mark 80 This will not change in September 2013

9. Implications of change Content in A21 will not increase to reflect the change of weighting ( from 50% to 60%) Content of A22 will not decrease to reflect the change of weighting ( from 50% to 40%) Change of weightings should contribute to a more balanced award outcome in terms of grade boundaries

10. Process of Moderation What happens during Moderation?  Centre sends in sample requested by CCEA  Moderation team meet to agree standards  Each Moderator will be allocated a number of Centres  Moderator will sub sample each centre  (N/2) + 1 including top and bottom  If sub sample is within tolerance, process finishes  Tolerance is a tool only available to Moderators  If sub sample is not fine, then the whole sample is moderated  Moderator does not change Centre marks, only recommends a change

11. Key Points from Moderation  Majority of centres applied the assessment criteria successfully  Majority of solutions were suitable across centres.  Majority of solutions involved a relational database.  Fewer Centres are using Web based solutions  Some Centres encourage students o build on their AS tasks to develop an A2 project  Teacher comments/annotation makes the process of moderation more meaningful.  “Cutting and Pasting” assessment criteria indicators is not helpful

12.  The range and quality of work is excellent  Project should be submitted as a number of clearly labelled sections as indicated in the CCEA specification  Centres are encouraging Candidates to produce relevant documentation, thus reducing the bulk  Better candidates included appropriate diagrams such as DFD’s, ER Models, Decomposition diagrams etc. in their documentation Key Points from Moderation

13. Last Page of Design

14. Key Points from Moderation  Candidates should be encouraged to apply their knowledge from A2 examination paper  Relational database solutions should clearly document all the stages of database normalisation in the design section of their solution.  It would be good practice to use ER modelling alongside database normalisation

15. Centre Report  Centres receive a TAC 6 and you can request follow up  Need to consider moderator comments:  “…just within tolerance…”  “ …slightly generous in ….”  “…lenient in the higher range of marking..”  “…slightly severe across all assessment criteria…”

16. Databases Data modelling including ER models and database normalisation Internal and external sources of information System development life cycles Roles of the developer and the end user Difference between technical and user documentation A2 Theory

17. Methods used in software production Testing and Software maintenance User interfaces User support and ICT training. Legal issues affecting ICT Implications of ICT within an organisation A2 Theory

18. Exemplar Materials 2012 1.CPN Database 2. Mahon’s Hotel 3.Icon Hairdressing

22. Additional Slides to help New Centres and New Teachers

23. Define the nature of the problem to be solved Fact finding methods to investigate the problem Identify data sources Gather sample documents currently used Identify the current user activities Investigate the tasks carried out by the user Specify limitations of the current system Describe information requirements of a system State the objectives of new system. Analysis

24. ANALYSIS Mark Range A detailed coherent analysis has been produced for a demanding problem. Full discussion of information requirements including fact finding. Demonstrates an in-depth understanding of structured analysis techniques in the investigation and effective use of structured analysis tools in specifying the system. 16-20 A good analysis has been produced for a demanding problem or a detailed analysis has been produced for a less demanding problem. A discussion of information requirements including fact finding. Demonstrates good understanding of structured analysis techniques in the investigation and reasonable use of structured analysis tools in specifying the system 11-15 A good analysis of a simple problem or a limited analysis of a difficult problem. Requirements specification included but with little or no justification. Limited use made of structured methods in investigating and specifying. 6-10 A simple problem with little evidence of any analysis, aims not clearly identified, poor investigation and recording of findings. Little use made of structured methods in investigating and specifying. 0-5

25. Evaluate possible solutions Design and document data capture forms Design of user interface Describe data validation required Design and document data structures Choose appropriate hardware and software Relate the solution to the capabilities of the software and hardware. Design

26. Software solution developed from the design (not documented) No Explicit Software Development section Evidence of testing will imply software has been developed. A test plan produced from the system objectives including:  Valid, invalid and extreme data;  Testing of the user interface  System functionality  Evidence of user testing Implementation and Testing

27. Output from the testing, cross referencing the test plan A description of a strategy for implementing the system into the organisation  Implementation plan  Description of the system changeover  The training required  The problems encountered and the actions taken  Description of how existing data is converted for use in the new system Implementation and Testing

28. Mark Range Evidence of a full and effective software solution to a demanding problem. Clear evidence of a full and effective test plan for a demanding problem. The results of the testing are fully documented with outputs cross-referenced to the original plan. Evidence that all functions agreed upon with the user(s) are indeed present and correct. Corrective action taken due to test results clearly documented. Plan for implementing the solution 16-20 Evidence of a reasonable software solution to a demanding problem or an effective software solution to a less demanding problem. Evidence of a reasonable test plan for a demanding problem. Test plan followed in a systematic way but the test plan has omissions in it and/or not all cases have been tested (i.e. have no evidence of testing). Some documentation of corrective action taken due to test results. Plan for implementing the solution 11-15 Evidence of an effective software solution to a simple problem or a limited software solution to a demanding problem. Evidence of an effective test plan and cross-referenced outputs for a simple problem or a patchy/limited testing of a demanding problem. Brief plan for implementing the solution 6-10 Inadequate software solution to a simple problem. Inadequate test strategy and test plan devised or a plan followed in a limited fashion. Little or no hard copy evidence of the results of testing or implementation of solution 0-5

29. Installation Guide Step by step operating instructions Troubleshooting Backup procedures. User Documentation

30. Evaluate results against objectives Identify strengths and limitations of the final system Identify possible extensions to the system Evaluation

31. CCEA Support 2012  Agreement Trials  Revised Specification  Revised Schemes of Work for new specification  Teacher support days  Coursework Clinic ( Feb 2013 )  Continued development of Microsite