Selecting and approaching a project

Selecting a project

The NEA project will take a significant amount of time to complete and contributes 20% of the marks to the final A-level grade. It is important that a student selects an appropriate subject for the project that:

  • can maintain their interest over a long time period
  • is suitably challenging and will enable them to fulfil their learning potential
  • will enable them to access the full mark range
  • can be supported and assessed by the teacher.

It is the student who must decide upon the project subject, but it is expected that the teacher should also be involved. Students can choose between:

Solution to a problem

The student selects a problem and develops a system to solve it. Typically, the solution would be developed for a third party. There is no requirement for there to be an end user, but having one is likely to be useful. Examples of this type of project include:

  • a simulation eg of a business or scientific nature, or a well know problem such as the game of life
  • a solution to data processing problem for a business. eg stock control, membership systems
  • the solution of an optimisation problem. eg production of a rota, shortest-path problems, route finding
  • a computer game
  • an application of artificial intelligence
  • a control system, operated using a device such as Arduino board
  • a website with dynamic content, driven by a database back-end
  • an app for a mobile phone or tablet.

Investigation

The student selects an area of the subject that they are interested in and conducts an investigation of this area, with the focus being on programming. For an investigation, the student would need a supervisor with some knowledge of the area being investigated. Examples of this type of project include:

  • machine learning algorithms
  • 3d graphics rendering
  • analysis of live data feeds eg Twitter feeds
  • AI
  • exploring large datasets for correlations, eg World Bank’s, and creating useful visualisations of these correlations to answer interesting questions
  • scientific investigations, eg where an analytic solution is not possible.

For both types of project, the structure of the documentation required is essentially the same, with minor differences where necessary.

In individual centres the problem chosen by a student to solve or investigate should be sufficiently different to avoid the work of one student informing the work of another because they are working on the same problem or investigation. Teachers are required to record on the Candidate Record Form for each student that they have followed this guideline. If in any doubt on whether problems chosen by students have the potential to raise this issue, please contact your AQA advisor.

It is expected that a task that is selected will be of A-level standard. See Determining if a project is of A-level standard for examples of what this means, and how to deal with projects that are not of A-level standard.

Selecting the subject for the project could be done at the end of the first year of the A-level or at the start of the second year. At this point, it may be that some of the techniques required to complete the project (eg SQL, some data structures) have not been taught, so the teacher will need to ensure that the project is realistically achievable.

Approaching the project

It is not expected that a student will follow any particular formal software engineering methodology, such as the waterfall model, when working on their projects. The different sections of the project report indicate the order that work should be presented for marking, not the order that it must be completed in.

Research

Students need to research the problem they are going to tackle at the start of the project, which will involve some analysis. It is important that at this stage a well-defined set of measurable objectives are written so that the student and teacher have a common understanding of what the student hopes to achieve and so that the student can gauge their progress.

Critical path

Once a student has a thorough understanding of the problem, they should be encouraged to identify what the critical path to be followed to produce a solution is, ie what are the key tasks that need to be completed to produce a solution. A student should be encouraged to focus on achieving these before working on more ancillary aspects of the problem.

Designing

It wouldn’t be a good idea for a student to try to design all aspects of a solution before starting to code it. This methodology is outdated and inappropriate, particularly in the context of a project during which a student is likely to be learning new programming techniques as the project develops. Therefore, an agile approach should be adopted where students design, code and test one aspect of their system before moving on to the next, iteratively using experience from testing to improve their design and coding. Evidence does not need to be gathered to show this development process taking place.

The project report

The project report should be presented in the following order:

  1. Analysis
  2. Documented design
  3. Technical solution
  4. Testing
  5. Evaluation

This does not mean that the evidence must be produced in this order. Further detail on what should be included in each section is included below.

The project documentation should be clearly organised, including appropriate titles, page numbering and a contents page so that evidence can be easily found and referred to.

Analysis (9 marks)

Analysis enables student’s to gain a deep understanding of the problem. This in turn allows the student to identify the objectives for the project, giving a clear purpose and direction for their design and solution development.

Methods and sources

Students should be encouraged to use a range of appropriate methods and sources to research and investigate the problem, including websites, existing software, books, interviews, questionnaires, prototyping.

Relevant and genuine evidence should be presented in the report (most likely in an appendix, but referenced in the main report) but students should be discouraged from generating evidence unnecessarily or artificially.

Identifying a third party

It is important that a third party (that is someone other than the student) is involved in the analysis process. The third party might be a potential user of the software, such as a friend, relative, employee or teacher or somebody with knowledge, interest or expertise in the problem area. Their role is to support the student in investigating the problem, drawing up the objectives and to give feedback, particularly at the end of the project.

For an investigative project, the third party is most likely to be the person who has agreed to act as the student’s supervisor. The objectives should be established early on and fixed at a point in time agreed with the third party and the teacher responsible for monitoring the student’s project.

Further research

It is accepted that the student’s depth of understanding of the problem will grow and develop as the project progresses. They should be encouraged to carry out further relevant research and after consultation with their teacher, refine and reassess their initial objectives as appropriate. The teacher should be the final arbiter and base their judgement on the initially agreed set of objectives and the scope appropriate for the abilities of the student and the nature of the project.

Prototyping and critical path

Prototyping the critical path at the analysis stage, early in the project development period, is encouraged so that changing objectives later on occurs only in exceptional circumstances, and with the agreement of the teacher. The achievement of the objectives will have an effect on determining the mark awarded for the coding of the project.

A point in time should be reached when the agreed set of objectives is frozen. This cut-off point should be early in the project development period once the critical path has been established and assessed as achievable.

We recommend that students are given time to carry out prototyping early in the project development period, eg in the first term of Year 13 , in order to investigate and test key algorithms, data structures and data stores and most importantly demonstrate that the critical path of the problem can be solved in the available time. This is valuable in enabling students to assess the feasibility and scope of their objectives. However, the initial objectives and the involvement of the third party are important in providing a reference point and structure for the project.

Required documentation (analysis)

Documentation for this section of the report should include:

  • a clear statement that describes the problem area and the specific problem being solved/investigated
  • an outline of how the problem was researched
  • a statement indicating who the problem is being solved/investigated for
  • background in sufficient detail for a third party to understand the problem being solved/ investigated
  • a numbered list of measurable, 'appropriate' specific objectives, covering all required functionality of the solution or areas of investigation ('appropriate' means the specific objectives are single purpose and at a level of detail that is without ambiguity)
  • any modelling of the problem that will inform the Design stage, for example a graph/ network model of Facebook connections or an E-R model, state diagrams, scientific/mathematical models or formulae, data flow diagrams.

The setting of well-defined, appropriate objectives is the most important part of the analysis, as these objectives will eventually be used to assess the success of the project and award marks to the solution produced.

If a student sets objectives that go beyond the scope of what is required at A-level, they should be indicated as extension objectives by the student, in consultation with the teacher responsible for the student’s project. If the objectives were not achieved, this would not prevent a student from achieving the highest available marks for the final developed system.

Documented design

The importance of design is to assist a student to produce a working, efficient solution to a problem and to enable maintenance of the system at a later date. Evidence for this section of the project report can be produced before, after or during the coding of the system.

Sequencing

It is often useful to complete some elements of the design, such as planning data structures, before coding takes place. This helps students avoid making mistakes which may result in unnecessary work and recoding at a later stage. Other elements of the design that would be useful for maintenance could have their design documented after they have been coded.

For students, design is also an opportunity to convey the level of technical complexity of their solution.

We recognise that design, coding and testing are inherently iterative processes, and not three distinct stages, carried out linearly, one after another. After designing some parts of a system, a student might then go on and code these before other parts of the system are designed in detail. After coding part of a solution it is likely that this part will be tested, which may result in possible recoding and/or redesign.

Required documentation (design)

The aspects of the system that a student needs to document the design of will depend upon the type of system they are developing. It is anticipated that for all systems, a high-level overview of how different parts of the system interact would be useful. This may be a structure/hierarchy chart, a system flowchart, a data flow diagram, or object/class diagrams, accompanied by any further explanation that is helpful. Non-standard diagrams that combine elements of data flow and program control flow are acceptable, as long as the two can be clearly distinguished.

Students should also document how the important parts of their system work. Possible items that might be present in design could be:

Algorithms

Processing of data should be at the heart of all projects. Students need to show and explain sample algorithm(s) that their project uses. These could be user-defined or standard algorithms, but should be chosen to demonstrate the complexity of the system and should be key algorithms that are essential to the success of the project. Pseudo-code, Structured English or any other appropriate methodology could be used.

Data structures

If a project makes use of data structures in memory, these should be explained. Simple structures, arrays of records, might only require a short explanation, while a more complex structure, such as a queue, linked list or hash table could be explained in more detail.

File structure and organisation

If a project stores data directly in files, the structure of the records in these files should be described, together with how the records are organised for access and inter-relationships between files.

Database design

If a project stores data in a database, the structure of the tables should be described and an entity-relationship diagram could be used to show how the tables are related.

Queries

If a project uses a database, samples of the queries that are used, together with explanations should be provided. The samples chosen should illustrate the complexity of the system.

HCI

In almost all cases, it is expected that there will be on-screen interaction between the student's system and the user. A small number of samples of screen/hard copy, with explanations and reasons should be presented. We recognise that most students will design their HCI on screen, using the features of their chosen programming environment. Therefore, evidence of HCI can be presented as explained screenshots rather than hand-drawn or package-drawn plans.

Hardware selection/design

For most projects, students are unlikely to have a choice of hardware to use, so this section will not need to be addressed. However, some projects are more focussed on the use of hardware, such as Arduino boards. For these projects, it would be appropriate to explain the suitability of the hardware and to present, by any appropriate method, information about the design of the hardware or how the hardware is used by the project. Students should provide evidence of those things that are relevant to their own project; the list above is not intended as a checklist, on which every item needs to be ticked off. If a project focuses particularly heavily on certain technical areas, then we would expect more evidence for these areas to demonstrate that although other areas may not be covered at all, the project is of suitable difficulty. The list above intended to be exhaustive; students are free to present other types of evidence that are relevant and useful to their project. For example, a student producing a simulation project might decide to include life cycle diagrams for entities.

Technical solution (42 marks)

Credit for the technical solution is awarded based upon two distinct aspects:

  • Completeness of solution (15 marks)
  • Techniques used (27 marks)

The key evidence that a student needs to provide for this section is their commented program code. Good commenting and the use of self-documenting techniques for programming, such as meaningful identifiers, will make this section easier to assess.

When including the program code, it would be helpful if it were broken down into titled sections and perhaps indexed to aid the identification of evidence.

Students are free to include any other evidence that might highlight the technical quality of the work completed.

Completeness of solution (15 marks)

Marks are awarded based upon how much of the proposed system the student has created. To enable this section to be assessed, it is of vital importance that a student has produced a sound and detailed set of objectives in the analysis and that appropriate testing has been carried out to evidence the achievement of the objectives.

If a student has not produced a suitable set of objectives in the analysis, then this mark should be awarded on the basis of what the assessor believes a reasonable set of objectives for the project would have been. Similarly, if a student has attempted to define the objectives in such a way as to make it unjustifiably easy to achieve the marking criteria, then the assessor should consider what they believe a reasonable set of objectives to be.

It is possible that a student might have identified in the analysis extension objectives that go beyond A-level standard. A failure to achieve any of these objectives should not prevent the student from being awarded a mark for having achieved 'all or almost all' of the objectives.

Techniques used (27 marks)

This section assesses the technical skills demonstrated in the solution the student has created.

Analysis of the program code written should be the main route through which the technical skills demonstrated by the student can be identified. However, this judgement could be assisted by other evidence:

  1. The documented design should include evidence of the data structures and algorithms the student intended to use.
  2. Comments should be included in the program code to highlight where techniques have been used.
  3. The teacher could look at the program code with a student present and ask the student to explain what they have done and how.
  4. The teacher could ask students to write notes to point out where in their program code they have used particular techniques.

1 to 4 can be used to assist in deciding on a mark, but the mark must be determined by what is seen in the program code as, for example, the student might plan a complex algorithm but not fully implement it, or exaggerate what they have done in a discussion.

There are three different levels of marks that can be awarded for the techniques used. Sections 4.14.3.3.2 and 4.14.3.4 of the A-level specification provide detailed guidance about the types of technical skill demonstrated for each level.

Within a level, the specific mark to award is determined by:

  • the extent to which the criteria for the mark band have been achieved
  • the quality of the coding style that the student has demonstrated
  • the effectiveness of the solution.

Section 4.14.3.4.2 of the specification illustrates the qualities that should be looked for when determining the quality of the coding style.

How to award the mark for the technical solution

Testing (8 marks)

Testing demonstrates that the student has, or has not, achieved the objectives identified in the analysis. It is not necessary to provide evidence of testing, or planning to test all aspects of the operation of the system, and the candidate should select and provide evidence of testing those aspects which most clearly demonstrate that the project fulfils its purpose.

There is no simple answer to the question of how many tests need to be carried out. Ideally, the tests completed should show that the system developed has fulfilled its purpose and demonstrates to the assessor the scope of the final system.

Testing does not all need to be carried out on the final version of the system. It is acceptable for testing evidence to be gathered during earlier stages in the development of the system.

Investigative type projects

It is possible that a student might choose an investigative type of problem for their project, where the detailed outcome of runs of the system on input data is unknown. For example, if a simulation is produced, the whole purpose of the system might be to see what happens under certain conditions and testing the core processing functions of the project would involve experimentation.

With such projects, there might be some tests with known correct outcomes that could be conducted on the parts of the system that can be predicted. The test evidence could also include examples of runs of the system where the outcome is unknown, and so cannot be specified in a test plan other than as a goal, eg the effect of income on life expectancy, together with explanations of what they show. Students attempting such projects should not be penalised for being unable to specify expected outcomes for tests.

Required documentation (testing)

Evidence showing that the system works must be presented to enable the assessor to understand how many of the objectives have been achieved when marking the programmed solution section. It is expected that the assessor will have seen the system running when coming to a judgement about this, but the testing evidence can provide further evidence of this and also helps to confirm the assessor's judgements to a moderator.

For each test carried out, it is expected that the student will describe and comment on the outcome of the test. This could be achieved by a test plan or by writing a commentary alongside the screenshots obtained that show test evidence. A suitable explanation of a test would include:

  • its purpose if not self-evident
  • the test data used
  • the expected test outcome
  • the actual outcome with a sample of the evidence, for example screen shots of before and after the test, etc, sampled in order to limit volume.

Evaluation (4 marks)

Evaluation allows the student to reflect on the success of the project in meeting the objectives identified in Analysis. The student should also reflect on feedback from the third party and discuss potential improvements and extensions to the solution.

Required documentation (evaluation)

Documentation for this section of the report should include:

  • an explanation of how well the objectives have been met and how this was achieved
  • a discussion of how the solution could be improved
  • analysis of feedback from the third party who was involved at the analysis stage.

A sensible approach would be to copy the objectives from the analysis into the evaluation so that each can be easily commented on. For each objective, the student could judge how effectively it has been met and also comment (if appropriate) on how it might be improved.

The student should aim to explain, in outline, how they might go about implementing the possible improvements. It is important that any third party feedback obtained is analysed by the students, not simply included as, for example, an email from the person.

In addition to commenting on the individual objectives, students should also give an overview of the effectiveness of their solution, as it may be that some points would not be covered by commenting on the objectives alone. For example, some ideas for improving the system might be outside of the selected objectives.

The actual feedback obtained from the third party should be included in an appendix. If feedback was also obtained at an earlier stage in the production of the project, for example based upon a prototype, then this could be referenced to in this evaluation so that it could be considered for credit.

Determining if a project is of A-level standard

If the problem (problem or investigation) selected for a project is not of A-level standard, mark the project against the standard marking criteria, but adjust the mark awarded downwards by two marking levels (two marks in the case of evaluation) in each section for all but the technical solution. For technical solution, you should have already taken the standard into account for this, by directly applying the criteria. For example, if a student had produced a 'fully or nearly fully articulated design of a real problem describing how solution is to be structured/is structured' this would, for an A-level standard project, achieve a mark in Level Four for Documented Design (10–12 marks). If the problem selected was too simple to be of A-level standard but the same criteria had been fulfilled, shift the mark awarded down by two levels, into Level Two, an award of 4–6 marks. If a downward shift by two levels is not possible, then a mark in the lowest level should be awarded.

The examples below are illustrative of tasks that are and are not of A-level standard.

Noughts and crosses

An implementation of noughts and crosses, in which the computer validated the legality of moves and checked for a winner would not be of A-level standard. However, the implementation of some good AI such as the use of a game tree / minimax so that the computer acted as one of the players would turn the game into a project that is of A-level standard.

The range of marks that were accessible for the technical solution would depend upon the sophistication of the algorithms used for the AI. A more secure way of ensuring that a project was of A-level standard would be to choose a more sophisticated game which could include more complex AI, advanced graphics or perhaps network communications.

Rota system

A system that stores information about employee availability and shifts that employees are needed for at a business and matches these two together would be of A-level standard, presuming that it was the program that carried out the matching process and not the user. If the matching was completed by an algorithm them the range of marks available for the technical solution would depend upon the sophistication of the matching algorithm, for example the number of factors taken into account by it (eg staff holidays, qualifications, desired working hours). If the matching was carried out by the user then it is unlikely that the project would be of A-level standard.

Encryption

A program that demonstrates the use of a simple encryption method such as the Caesar Cipher is unlikely to be of A-level standard due to the limited amount of processing done. However, if this were developed into a more complete system, for example with the option to use alternative types of cipher, a graphical display of the Caesar Cipher wheels, the ability to load/save data then this would be of A-level standard but unlikely to achieve a high mark for the technical solution. The incorporation of a code-cracking option that used techniques such as frequency analysis or comparing potential solutions to dictionary text to crack a code would offer access to higher marks for the technical solution, as a result of more complex algorithms being used.

Quiz

A simple quiz program that stored multiple choice questions and answers in a single table or file and scored a user based upon their answers to the questions would not be of A-level standard.

The additional of functionality for a user to login and for their scores to be saved, and for questions to be edited within the program would make the system of A-level standard.

The implementation of a more sophisticated technique to analyse responses and tailor future quizzes based upon these has the potential to enable the awarding of a higher mark for the technical solution, as would making the quiz work across a network using TCP/IP so that players could compete against each other.

Last modified: Wednesday, 27 April 2016, 11:05 AM