ICT A-Level – Software Systems Development
A Level – CCEA SSD Software Systems Development
Examination Board: CCEA
This course is aimed at developing programming skills and emphasis on object oriented development and event driven programming along with systems approaches and database concepts. To undertake this course students should have proven skills, knowledge and understanding of Computer Science.
This specification aims to encourage students to:
- develop a genuine interest in software systems development with a focus on programming;
- develop an understanding of systems approaches and modelling techniques to support software development;
- develop software development skills that will prepare them for work in today’s software industry;
- participate in the development of a software project using a complete software development process;
- apply their skills to relevant work-related scenarios;
- work with others in group settings;
- research, develop and present their findings in a variety of formats; develop advanced study skills in preparation for third level education; and demonstrate their understanding and application of key concepts through challenging internal and external assessment.
|AS 1: Introduction to Object Oriented Development||External written examination: 2 hours|
Short and extended questions, stimulus response and data response questions based on the principles of object oriented development
|50% of AS|
20% of A level
|AS 2: Event Driven Programming||Internal assessment|
Portfolio showing evidence of designing, implementing, testing and evaluating an event driven application
|50% of AS|
20% of A level
|A2 1: Systems Approaches and Database Concepts||External written examination: 2 hours|
Short and extended questions relating to current systems approaches and database concepts. These questions are based on a pre-release case study.
|30% of A level|
|A2 2: Implementing Solutions||Internal assessment|
Portfolio showing evidence of the analysis, design and implementation of a software solution of a specified problem in a pre-release case study and task.
|30% of A level|
Coursework: AS 2: Event Driven Programming
In this unit, students have the opportunity to implement and develop object oriented technologies in an event driven environment. Students are able to state requirements and design, implement, test and evaluate their application. This unit is internally assessed.
Coursework: A2 2: Event Driven Programming
In this unit, students have the opportunity to design and implement a solution to a given problem using the knowledge and skills acquired in the preceding units of the course from AS to A2 Level. The students implement an agreed design using an appropriate software tool. The unit allows them to experience the elements of the systems development process. Students are required to build their solutions using an RDMS (Relational Database Management System) through an event driven programming environment. This unit is internally assessed with a pre-release case study. Students must use the pre-release case study throughout.
Careers and Further Study
GCE Software Systems Development can lead to a wide range of careers including multimedia and website design, software design, games design, computer programming, graphic design, IT management, CAM engineering and CAD design.
An Advanced GCE AS or full A Level in Software Systems Development combines well with almost all other AS and Advanced GCE subjects. Taken with Mathematics and Science, it supports applications for any IT-based University courses. Taken with Languages or Arts it supports an equally wide range of university courses such as Communications, Media, Business and Management.
Implementation is the next stage of developing a new system, after design. This is where the new system is created and installed.
Tasks that might take place include:
- writing programs [program: a list of instructions written in a programming language ]
- purchasing hardware [hardware: the physical components of a computer ] and software [software: a general term used to describe an application or a program ]
- writing user documentation [user documentation: a resource - for example, a collection of documents containing all the information a user needs to know about using and getting support with a piece of software ]
- testing the system using the test plan
- installing networks [network: a group of interconnected computers ]
- training staff
If the tests are not satisfactory then any problems will need to be corrected and the system tested again.
User documentation will be written to help staff become familiar with the new system. It will include:
- a user guide [user guide: a step by step guide, eg a guide to using a piece of software including instructions, example scenarios and screenshots ]
- installation details
- input [input: Everything that goes into a system. The three most common inputs in industry are physical inputs, labour and capital. ] and output [output: the term denoting either an exit or changes which exit a system and which activate/modify a process ] samples
- screen shots [screen shot: taking a screen shot of what's displayed on screen and saving it in an image file, eg as a *.jpg, *.bmp or *.gif ]
- details of what error messages mean, ie troubleshooting advice
Methods of changeover
When the system is ready to go on-line there are different ways of moving from the old to the new system:
Running both the old and new system until you are certain the new system is working correctly. Parallel running is likely to be the most expensive as it involves doing the work twice for a period of time. However, it is the safest. If there are any bugs in the new system, you can always go back to the old system while the problems are corrected.
Changing over in a small part of the company to start with. Only when the system is deemed satisfactory will it be rolled out to the rest of the organisation. A supermarket introducing a new 'self-scanning' system might choose to introduce it in two or three stores at first. This is a pilot changeover.
The old system is scrapped and immediately replaced by the new system. With this option there is a danger that there may still be problems with the new system. Even though it is the most risky type of changeover, many companies use this method.
The change over is split into phases or stages. Each stage is introduced one at a time and the old system is kept running to do the remainder of the tasks that have not yet been changed.
Back to ICT systems index