Cambridge TECHNICALS OCR LEVEL 2 CAMBRIDGE TECHNICAL CERTIFICATE/DIPLOMA IN IT SYSTEMS SOFTWARE AND HARDWARE FOR DEVELOPMENT D/505/4621 LEVEL 2 UNIT 25 GUIDED LEARNING HOURS: 60 UNIT CREDIT VALUE: 10
Systems software and hardware for D/505/4621 LEVEL 2 Aim and purpose of the unit This unit will enable learners to become familiar with the system software and hardware required for software. They will discover the software and hardware constraints associated with software and explore how these constraints can be resolved. Learners will use diagnostic tools to resolve software and hardware constraints. www.ocr.org.uk 2
Systems Software and Hardware for Development Level 2 Unit 25 ASSESSMENT AND GRADING CRITERIA Learning Outcome (LO) Pass Merit Distinction The learner will: The assessment criteria are the pass requirements for this unit. The learner can: To achieve a merit the evidence must show that, in addition to the pass criteria, the learner is able to: To achieve a distinction the evidence must show that, in addition to the pass and merit criteria, the learner is able to: 1 Know the system software required for software P1 describe the types of system software used in software D1 explain the need for compatibility between operating system software and programming languages 2 Know the hardware required for software 3 Know the systems software and hardware constraints of software 4 Understand the solutions to systems software and hardware constraints P2 describe hardware configurations used in software P3 describe systems software constraints that can occur during software P4 describe hardware constraints that can occur during software P5 explain how systems software constraints can be resolved P6 explain how hardware constraints can be resolved M1 use a diagnostic tool to resolve system software constraints M2 use a diagnostic tool to resolve hardware constraints D2 evaluate diagnostic tools used to resolve system software and hardware constraints 3
Teaching content The unit content describes what has to be taught to ensure that learners are able to access the highest grade. Anything which follows an i.e. details what must be taught as part of that area of content. Anything which follows an e.g. is illustrative, it should be noted that where e.g. is used, learners must know and be able to apply relevant examples to their work though these do not need to be the same ones specified in the unit content. LO1 Know the system software required for software Low level programming languages machine code assembly language High level programming languages (e.g. Java, C, C++, Scratch, Python, Prolog) Operating systems e.g. Linux MS-DOS Mac OSX Windows Android Operating systems and programming languages e.g. Linux (Java) Mac OS X (Scratch) Windows (Scratch, Visual Basic) Android (Java) Software tools Assembler (e.g. assembly language to machine code) Compiler (e.g. used with C, C++, C#, Java) Interpreter (e.g. used with BASIC, LISP, Python, Ruby) Compatibility (e.g. operating system, versions) Integrated Development Tools (e.g. Microsoft Visual Studio, Eclipse, BlueJ, NetBeans) Software Development Kits/Software Developer s Kits (e.g., Windows Phone SDK, QuickTime Mac OS, Android SDK, ios SDK for ipad) LO2 Know the hardware required for software Hardware components processor family (e.g. Intel, PowerPC, AMD) processor performance (e.g. speed, efficiency) hard disk capacity temporary storage (e.g. RAM) motherboard input/output devices memory cards graphics cards video cards sound cards screen (e.g. size, resolution) communication devices LO3 Know the systems software and hardware constraints of software Systems Software constraints: outdated systems software versions incompatibility between systems software and programming languages incompatibility between systems software and hardware insufficient memory limited storage issues with device drivers registry issues Application Development Software: (e.g. ios Developer, JavaScript, HTML, Flex, Adobe Flash Builder) www.ocr.org.uk 4
Systems Software and Hardware for Development Level 2 Unit 25 Hardware constraints outdated hardware specifications incompatibility between hardware components inaccessibility (e.g. screen size) incompatibility with software LO4 Understand the solutions to systems software and hardware constraints Systems Software Upgrade systems software buy a new version of system software download a software patch Buy new system software advantages of buying new versions of system software (e.g. generally error free) disadvantages of buying new versions of system software (e.g. cost) Download a software patch advantages of downloading a software patch (e.g. free) disadvantages of downloading a software patch (e.g. can contain errors, can be out-of-date/become out-of-date quickly) Use diagnostic tools e.g. Pc-Check, PC Inspector(Windows), QuickTech Windows (Windows, Android), QuickTechIA (Apple) Hardware Upgrade hardware (e.g. add additional memory, increase hard disk storage capacity, replace cards) Use diagnostic tools (e.g. Pc-Check, PC Inspector(Windows), QuickTech Windows (Windows, Android), QuickTechIA (Apple) Evaluation usability (e.g. ease of use, what help and support does it offer the user) functionability (e.g. general maintainance features, management/diagnostics features, repair and recovery features, optimization features, security features) acceptability (e.g. what operating system software does it support i.e. is it Windows compatible, Mac compatible, etc.) 5
Delivery guidance Know the system software required for software Learners should be taught the different types of systems software, the main types of operating systems and software tools. This could be delivered through handouts, practical exercises and individual research. When undertaking individual research a list may be provided to facilitate this activity, with further research providing clarification and broader understanding. Learners should be introduced to the various types of programming languages and the purposes of the languages delivered through handouts, practical exercises and individual research. Learners should be instructed to undertake research on several high level programming languages, how they are used by commercial organisations and the focus for this usage. A list could be provided to help them focus on key aspects of this task. Learners should understand the need for compatibility between systems software and programming languages and examples of this demonstrated which could be delivered through handouts and practical exercises. Learners should understand the impacts and problems caused through lack of compatibility and research cases in the media where systems have been developed in isolation and are then deemed unsuitable for their original purpose. The more high-profile cases in the media involve the wastage of millions of pounds worth of funding and learners should be instructed to research examples of such cases. Learners could be directed to investigate the system software installed on the computer systems that they use at school/college, home and workplace and if possible at other workplaces. When the specification of the system software is established learners can recommend which programming languages would be compatible for use with the system software. Comparisons between the systems looked at should be discussed and documented. Know the hardware required for software Learners need to know about hardware components, their specifications and their relevance to software and this could be delivered through handouts and practical exercises that involve examining the specification of various hardware components referred to in the teaching content. Learners need to understand that the hardware specification is required to be compatible with the system software and programming languages used for software to enable the extension, expansion and flexibility across different platforms. Learners should be directed to assess the hardware configurations of the computer systems that they use at school/college, home, workplace and if possible at other workplaces. When the hardware configurations are determined, learners should recommend what system software and programming languages would be appropriate to use with the hardware and for what purpose. Know the systems software and hardware constraints of software Learners need to be aware of the various types of software and hardware constraints that can occur during software ; this could be delivered through handouts and practical exercises. They will already have identified these constraints as part of their research in learning outcomes 1 and 2. In addition to discussing these constraints, some or all of these potential problems should be demonstrated, so that the learners are able to develop their understanding of each issue. The results of incompatibility between systems software and programming languages should be demonstrated and the resulting issues recorded by learners. The results of incompatibility between hardware and system software and programming languages could also be demonstrated if possible and the resulting problems documented by learners. They may be able to draw on their research from learning outcomes 1 and 2 to provide examples for discussion and further research. www.ocr.org.uk 6
Systems Software and Hardware for Development Level 2 Unit 25 Understand the solutions to systems software and hardware constraints Learners should understand the various software and hardware constraints and if possible, examples as to how these have been or can be resolved should be demonstrated to enable learners to develop their understanding of each solution. The use of diagnostic tools should be explained and the features demonstrated to show how this software can detect various system software and hardware problems and suggest remedies. To help learners understand the use of diagnostic tools they should be instructed to use them to remedy software and hardware faults. They should then be directed to evaluate the diagnostic tools that they have used to evaluate aspects such as usability, for example, ease of use and support offered to the user; functionality, such as general maintenance features, management/diagnostic features, repair and recovery features, optimization features and security features and acceptability, that is, what operating system does it support for example Windows, Mac compatible etc. 7
Suggested assessment scenarios and task plus guidance on assessing the suggested tasks Assessment Criteria P1, D1 For P1 learners must describe the types of system software used in software and should consider a range of language types. They could present their evidence in a report, presentation or booklet. For distinction assessment criterion D1 learners must explain the need for compatibility between operating system software and programming languages, and should clearly identify considerations and problems that may be caused due to incompatibility. The evidence presented for this may be an extension to the original report/presentation. Assessment Criterion P2 For P2 learners must describe hardware configurations required in software which should relate to a purpose identified by the learner. They could present their evidence in a report, presentation or booklet. Assessment Criteria P3, P4 It is suggested that the evidence for P3 & P4 could be presented together. For P3 learners must describe systems software constraints that can occur during software ; a range of constraints should be identified. For P4 learners must describe the hardware constraints that can occur during software. These may be due to the operating system or the languages used, and a range of constraints should be identified. The evidence for P3 & P4 could be in the form of a report, presentation or booklet. Assessment Criteria P5, P6 It is suggested that the evidence for P5 & P6 could be presented together. For P5 learners must explain how systems software constraints can be resolved. Learners should ensure that the constraints are identified, in addition to explaining how they can be resolved. For P6 learners must explain how hardware constraints can be resolved. Learners should ensure that the constraints are identified, in addition to explaining how they can be resolved. The evidence for P5 & P6 could be in the form of a report, a presentation or booklet. Assessment Criteria M1 For merit assessment criterion M1 learners must demonstrate that they can use a diagnostic tool to resolve software constraints, demonstrating the main features and functions of the diagnostic tool. There must be evidence of the learner resolving constraints using a diagnostic tool. Their evidence should include which tool they are using and which software constraints have been determined and resolved. This could take the format of a video, photographs with accompanying report or an observation statement. Assessment Criteria M2, D2 For merit assessment criterion M2 learners must demonstrate that they can use a diagnostic tool to resolve hardware constraints, demonstrating the main features and functions of the diagnostic tool. There must be evidence of the learner resolving constraints using a diagnostic tool. Their evidence should include which tool they are using and which hardware constraints have been determined and resolved. This could take the format of a video, photographs with accompanying report or an observation statement. For distinction assessment criterion D2 learners must evaluate diagnostic tools used and their effectiveness in resolving the system software and hardware constraints. The evaluation should include the areas as outlined in the teaching content. The evidence for this could be in the form of a report, presentation or booklet. Suggested scenarios Tutors could provide learners with an outline of a software project. Learners should consider this project with regard to software, hardware and operating systems. Learners could produce information for people who want to undertake software in their own time at home and who need to be made aware of the system software and hardware requirements for their preferred programming language, the potential system software and hardware constraints that they may encounter and how they could solve these potential constraints. Learners could produce information for a small business/ charity that wants to engage with an external organisation to undertake the, and needs to have core awareness of requirements. www.ocr.org.uk 8
Systems Software and Hardware for Development Level 2 Unit 25 A case study based on a local or national company could be produced and each task undertaken would in some way relate to the case study and the learners asked to produce information as part of their employment/work experience at the company. RESOURCES Learners will need access to the Internet for carrying out research and it may be appropriate to provide a list of websites that learners are recommended and permitted to access. Learners will need to use diagnostic tools, some are available free of charge from the Internet, e.g. PC-Cleaner. Publications such as Computer Active, PC Advisor and Computer Weekly may be useful. Case studies could be made available, but research should also be encouraged. 9
www.ocr.org.uk 10
Systems Software and Hardware for Development Level 2 Unit 25 Mapping within the qualification to the other units Unit 4: Installing computer hardware Unit 5: Installing computer software Unit 8: IT fault diagnosis and remedy Unit 14: Computer systems Links to NOS 4.1 Systems Architecture 5.1 Systems Development 5.2 Software Development 5.3 IT/Technology Solution Testing 5.4 Systems Integration 7.3 IT/Technology Problem Management 11
CONTACT US Staff at the OCR Customer Contact Centre are available to take your call between 8am and 5.30pm, Monday to Friday. We re always delighted to answer questions and give advice. Telephone 02476 851509 Email cambridgetechnicals@ocr.org.uk www.ocr.org.uk