A2 Computing

1. A2 Computing Unit 3 / 4

2. Staff / Structure • David Hughes • Richard Lee • 5 lessons per week • Focusing on COMP4 (project) first

3. Weighting • Unit 1 – 30% • Unit 2 – 20% • Unit 3 – 30% • Unit 4 – 20% • AS units combined with A2

4. Unit 3 Problem Solving, Programming, Operating Systems, Databases and Networking • Assessed through exam in June • 2 hour 30 min written exam • Will start this after everybody's projects are on track

5. Unit 4 • Practical Project • Separate deadline for each section • Progress closely monitored • 75 marks in total

6. Mark scheme

7. Project Complexity • Complex • Adequately Complex • Limited in Complexity • Simple • Complexity affects marks awarded!

8. Complexity marking examples • Analysis stage • Complex 12 marks • Adequate complexity 9 marks • Limited complexity 6 marks • Simple 3 marks

9. complexity • Which of the following do you think are complex enough? • Database of shop sales that allows people to update stock and add new stock items • Online revision site allowing students to log in a sit random generated tests • 3D shooter game • Photo album database

10. Project topics • Projects should be selected which allow candidates (within their own capabilities) to demonstrate practical and problem solving skills, as well as the techniques of documentation and system testing. • The project topic could involve a computer solution to: • a data-processing problem of an organisation • a scientific or mathematical problem • a simulation of a real-life situation • a computer-aided learning system • a control system / robotics.

11. End user • Need to investigate a REAL problem associated with a GENUINE end user whose REALISTIC needs should be taken into account when designing the solution • End user cannot be you! • Can be a relative, support staff, teacher or someone introduced to you for the purpose of the project

12. Programming language • We need to be able to support you • Consider this when deciding the project language

13. Project log sheet

14. Good practice • Share ideas • Communicate! • Observe past projects • Keep on top of deadlines • DO NOT leave things! You will fail!

15. Analysis • Begins with research! • You cannot create a high mark analysis section if no evidence of research exists.

16. Analysis sections • Background to / identification of problem • Description of current system • Identification of prospective users • Identification of the user needs and acceptable limitations • Data volumes • Data sources and destinations • Analysis data dictionary (from perspective of end user) • Data flow diagrams (DFD’s) (existing and proposed systems) • Entity relationship model (if appropriate) • Object analysis diagrams (if appropriate) • Numbered general and specific objectives of the project • Realistic appraisal of the feasibility of potential solutions • Justification of chosen solution • Evidence of use of appropriate analysis techniques

17. Research • To aid in understanding what your project is • INTERVIEW - Put together questions for your user to find out what your objectives are: • Current system and how it runs • Problems with current system • Users • Skill levels • What is wanted from the new system • Preferences on platform • QUESTIONNAIRE (multiple users) • OBSERVATION – sample documents of current system (paper based)

18. Background / identification of problem • 2 paragraphs • Details of the company / person the system is for • What does the company do? • This section needs to give the reader an idea of the problem • This should be an overall description of the problem • No need to give details of specific languages

19. Description of current system • Expanding on the previous section • Detailed information on the problem / problems itself • Describe the current system that is in place. What are its flaws? • slow, secure, ease of use, multiple users • If it is an existing paper based system, provide sample documents in the appendix and refer to them • How are users impacted as a result? • Interview • Sample documents

20. Prospective users • Who will need access? • Need to recognise all possible users • How much access is required by different users? • Be as detailed as possible, you need to show that you understand what the user wants / needs • eg Stock control system. who are the users?

21. User needs & acceptable limitations • Extensive list detailing what the user requires from the system • Follows on from any interviews, sample documents • What data should it store? • What processes will it need to carry out? • Tracking data • Functionality • User interface • Running local or on a server? (depends on user/s)

22. Data volumes • How much data is passed through the system? • Storage • Database queries? • Think about what your system will be storing • Think about processes being carried out • eg "the system will store several hundered customers" • "each customer will have their orders recorded" • "based on research each customer will make an average of ...... orders meaning there will be ..... "

23. objectives • Crucial section, need to get this right! • Clear objectives for the system • SMART • Specific - make sure it is not ambiuous • Measurable - can you easily prove that you have met this target? • Attainable - make sure that within the time limit you will be able to complete this • Relevant - is it going to help meet your user needs? • Timely - you are limited by time in this project • When building the system this is what you will be working towards achieving

24. objective examples Are the following objectives SMART? - The system will allow staff to update stock and add new stock items - The sports club system will have a clock displaying the time on each page - The system will calculate and display the total number of sales per customer - The system will process 5,000,000 transactions a second

25. Appraisal of potential solutions • Research and document various potential solutions • try to provide 3 potential solutions • Mention positives and nagatives for each • Comparison • Existing software and its uses

26. Justification of chosen solution • Justify the solution you have chosen to follow • Programming language / tools required • You need to show why the solution you have chosen is the right or most reasonable choice

27. Data flow diagrams • Modelling the current and new system • Will be covered in detail later

28. Data Flow diagram (DFD) • Model the flow of data within a system • Focuses on how data is transferred in a system to achieve a goal • Interface between the real world activities and how this is converted into a computer system • Standard notation used • You are required to model the existing and new systems • Need to identify: • Data storage • Data flows • Processes • Entities (e.g. customer, employee, user)

29. DFD notation • Process • Numbered in top left corner • Process being carried out in centre (description – start with a verb) • Destination (place or name) at the top • Data store • Labelled as M (manual) or D (database) followed by number • Also includes a name for the data store

30. Dfd notation • Data flow • Indicated on the DFD by arrows showing the direction of data • Needs to be named to show what data is being passed • Entities • anything outside the system that interacts in some way. • Can be a person, company or another system Customer contact details Purchase Order

31. Dfd levels • Different levels exist • Each one shows more or less detail than the others • You are required to produce: • Level 0: context diagram • Level 1 • For both existing and solution

32. Example level 0 • A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one process node (process 0) that generalises the function of the entire system in relation to external entities.

33. Example level 1 • Level 1 DFD breaks the main system process down into further processes. Data flows are also shown in more detail. • Data stores (manual or databases) are added to the diagram.

34. Example level 0 – hairdressing salon Request appointment Appointment card

35. Example Level 1 – hairdressing salon

36. Context diagram (level 0) • The Level 0 Data Flow Diagram, or Context Diagram, is designed to represent only the inputs and outputs of the overall process. • Draw a square in the middle of your work space. This will represent your overall process. • Arrange ovals around this process. Draw one oval for each external system that either contributes to or draws from your central process. • Draw arrows (flows) between these entities to show how information will move to and from these different systems. Label each arrow with the name of the information exchanged.

37. Level 1 data flow diagram • Now you need to break down the central process into multiple processes. • Identify all data that will be inputted and outputted by the system • Identify the processes that will handle this data • Connect the data flows to the external entities • Remember to add the data stores • Start with your first input then follow all the paths through the system • Consider all users (external entities) and their inputs

38. Dfd summary • When beginning you should list: • All the External Entities of the system  • All the Inputs to the System • All the outputs from the System • Context diagram of the system • The context diagram is expected to show the following: • External entities for the system • Inputs to and Outputs from the system • System Boundary  • Level 1 diagram of the system • Level 1 Data Flow Diagram is expected to show: • All processes, data flows and data stores of the system • Follow all the conventional rules/symbols of DFDs.  • All processes, data stores and data flows must be named/ numbered properly.  • Use strong, definite verbs for naming processes.  • Data flows to/from external entities in Level 1 DFD should match with the context diagram.