Computer Science NEA

Name: Target:

Section A: Analysis (9 marks)

1-3 Partially scoped/documented. Specific objectives, not all measurable/appropriate. Requirements partly addressed with some attempt to consider user(s)
needs. Problem partly modelled and of some use in subsequent stages.
4-6 Well scoped with most requirements documented. Specific & measurable objectives which cover most of the solution. Requirements consider needs of
intended user(s). Problem sufficiently well modelled to be of some use in subsequent stages.
7-9 Fully scoped with requirements clearly presented. Specific & measurable objectives which cover the whole solution. Requirements consider needs of
intended user(s), with communication fully documented. Problem sufficiently well modelled to be of some use in subsequent stages.

Clear statement that describes the problem being solved/investigated Outline of how the problem was researched
Statement indicating who the problem is being solved/investigated for Explain problem in sufficient detail for a third party to understand
Primary Research (interviews/surveys with client, users & other stakeholders) Secondary Research (Existing programs/Internet/books/articles etc.)
Analysis of research findings Numbered list of specific & measurable objectives
Modelling of the problem that will inform the design stage Prototyping & Critical Path analysis - how feasible are your objectives?

Section B: Design (12 marks)

1-3 Inadequate design, difficult to obtain a picture of how the solution is to be structured without looking directly at the programmed solution.
4-6 Partial design for a real problem that describes how some aspects of the solution are to be structured.
7-9 Adequate design for a real problem that describes how most key aspects of the solution are to be structured.
10-12 Full design for a real problem that describes how all key aspects of the solution are to be structured.

Structure/hierarchy chart(s) Algorithms – flowchart(s)/pseudocode Interface designs

Data Structure designs (e.g. 2D Arrays, queues, hash tables) Data Dictionary File structure organisation
Entity Relationship Diagram (ERD) Query Designs Data Flow Diagram (DFD)
Object/Class diagram(s)

Section C: Completeness of Solution (15 marks)

1-5 A system that tackles some aspects of the problem.
6-10 A system that achieves many of the requirements but not all. System includes some of the most important requirements.
11-15 A system that meets almost all of the requirements.

Section D: Techniques Used (27 marks)

1-9 Level of technical skill equivalent to those listed in Group C.
10-18 Level of technical skill equivalent to those listed in Group B.
19-27 Level of technical skill equivalent to those listed in Group A.

Program code (#commented) - highlighting technical quality Code broken down into organised, titled sections
Clearly showcases use of versioning/iterative approach (feedback etc.) Clearly demonstrates which objectives were/were not achieved

See back of sheet for Table 1 detailing groups A-C

Section E: Testing (8 marks)

1-2 A small number of tests which demonstrate that some parts of the solution work. Evidence presented may not be entirely clear.
3-4 Moderately extensive testing, but falling short of demonstrating that the solution is robust. Evidence presented is explained.
5-6 Extensive testing, but does not make clear all requirements have been achieved. Maybe some aspects not tested or evidence not always presented clearly.
7-8 Clear evidence of thorough testing. Demonstrates robustness of the complete solution and that the requirements have been achieved.

Testing against each of your objectives Functionality Testing (does it work as intended?) Usability (UX) Testing (is it easy to use?)
Normal Tests (expected inputs/events) Boundary Tests (around the limits of what’s acceptable) Erroneous Tests (unexpected inputs/events)
As with all sections of the project, you should be showing an iterative approach. Therefore, informal testing should be carried out during early stages of development.
The outcome of these should provide opportunities to discuss, fix and then retest. Don’t just wait until the end and only perform tests on the final version!

Section F: Evaluation (4 marks)

1 Some outcomes are assessed but only in a superficial way. No independent feedback obtained or if obtained is so basic as to be not worthy of evaluation.

2 Outcome is discussed but not all aspects are fully addressed. May be because some requirements have not been met or ignored altogether in the evaluation.
No independent feedback obtained. If obtained is not sufficiently useful or realistic to be evaluated in a meaningfully way.
3 Nearly full consideration given to how well the outcome meets all of its requirements. How it could be improved is discussed but consideration is limited.
Independent feedback of a useful and realistic nature. However, feedback is not evaluated and discussed in a meaningful way, if at all.
4 Full consideration given to how well the outcome meets all of its requirements. How it could be improved is discussed and given detailed consideration.
Independent feedback of a useful and realistic nature. Feedback is evaluated and discussed in a meaningful way.

Explanation of how well each objective has been met and how this was achieved Discussion of how the solution could be improved & how?
Analysis of feedback from the client who was involved at the analysis stage Overview of the effectiveness of your solution
 Table 1 (Example technical skills)
Model  Algorithms 
A  Complex relational database (several linked tables)  Complex SQL
(High)  Hash tables, lists, stacks, queues, graphs, trees  Graph/Tree Traversal
 Files(s) organised for direct access?  Complex List Operations
 Complex scientific/mathematical model  Stacks/Queues Operations
 Complex user-defined use of OOP  Advances Matrix Operations
 Complex client-server model  Recursive Algorithms
 Complex sorting algorithms (e.g. merge sort)
 Dynamic generation of objects using OOP
B  Simple relational database (2-3 linked tables)  Simple SQL
(Mid)  2D Arrays (Lists of Lists)  Simple sorting algorithms (e.g. bubble sort)
 Dictionaries  Binary Search
 Records  Reading & writing from files
 Text Files  Simple user-defined algorithms
 Simple scientific/mathematical model  Generation of objects using simple OOP
 Simple user-defined use of OOP
 Simple client-server model
C  Arrays/Lists  Linear search
(Low)  Appropriate choice of simple data types  Simple mathematical calculations (eg average)
 Single table database  Non-SQL table access

Table 2 (Coding Styles)

Basic  Good  Excellent 
 Meaningful identifier names  Well-designed interface  Classes and Objects
 Code annotated effectively  Modular code  Use of own methods
where required  Parameters & Return values (not global)  Defensive programming
 Minimal use of global variables  Good exception handling
 Changing Data Types
 Meaningful variable names etc.
 Consistent style throughout
 File paths parameterised
Overall criteria
Overall Layout
Criteria Completed in
Full (Y/N)
Clear pages numbers on the bottom of work
Headers and Footers Used to give name & title of project including
candidate number and centre number
Each section is numbered appropriately starting with 1. Something
Any diagram used has a clear italic reference after e.g. Figure 1.1.1 Flow
Chart of Customer Order
The work doesn’t include references to Me, My, We, I, Us, Our in any
section other than “Research” and “Log Book”
All tutorials, examples, video clips and research that has been conducted
includes a reference to where it was found

Analysis
1.1 Background & Current System
Criteria Completed in Full (Y/N)

There is a clear introduction to the group/ company/

organisation/ user group
A section covering the clients current problem
Current System explained fully including every process
that takes place, every store of data, every data flow, and
every key attribute within the company discussed and all
people involved with the current system.

1.2 Problems with the Current System

Criteria Completed in Full (Y/N)
Clear problems with the current system have been
discussed.

This could be as a bulleted list, with each explained

further.
Ensure every problem has been discussed in detail in the
current system.

1.3 Approaches to Research

Criteria Completed in Full (Y/N)
Discussion about current or similar solutions to the
problem area will be researched:
 Internet
 Existing Systems
 Current System
1.4 User Identification (needs & limitations)
Criteria Completed in Full (Y/N)
A list and description of each user potential user of the
new system.
This should (where possible) include names and job
titles – or group names e.g. Teaching Staff, Cleaners,
Police Officers.

For each user group of the new system there should be

a set of their needs. What do each set of users “Need”
from a computerised/new system?

This can be bulleted and expanded further

What are the limitations e.g. what is outside of the
scope of the project?
It may be that the user asked for a web-based multi-
user environment and within the time frame it is only
possible to build a standalone version.

1.5 Objectives
Criteria Completed in Full (Y/N)
All objectives are numbered
e.g.
1.
2.
3.

Each objective is specific (for one single purpose, to the

point and includes references to any attributes if
relevant)

All objectives have been previously discussed in either

the problems of the current system or the current
system section.

e.g. Why would we put an objective if it wasn’t a

problem in the first place?

e.g. Why would we have an objective if we hadn’t

analysed how this was currently being done?

Objectives need to have a measurable aspect.

Objectives should be SMART whenever possible.

Specific
Measurable
Achievable
Realistic
Timely

After each numbered objective there should be a

paragraph explaining the objective in detail.
Designs
Criteria Completed in Full (Y/N)
All aspects of the modelling section should have written
commentary to accompany the work.

A table displayed showing Data Flow,

Sources/Recipients.

This should link with Current System and also have a

diagram reference e.g. Fig 1.3 Table showing Data and
its source/recipient

This should have commentary afterwards.

A Context Diagram – showing the overview of the

company with external entities and data flows.

A Level 1 Diagram for the existing system showing

processes, data flows and stores of data

A Level 1 Diagram of the proposed system showing

additional functionality in processes as outlined in the
objectives / user needs

All diagrams have commentary discussing them

An IPSO Chart produced summarising the Inputs,

Outputs, Processes and Storage.

Data Dictionary entries for each current store of data

Pseudocode / Algorithms / flow chars demonstrating how

parts of the system will work

User Interface Designs – Designs for any menus and / or

screens the user will use. This will be annotated, and
decisions justified (i.e., colour)

Data Dictionary – All data that is being used should be

labelled with its data type with justification on choice

File Structure – How will the program and its assets be

stored?
An Entity Relationship diagram produced on the Existing
System only

If database is used - Any Many to Many relationships

broken down

Query Designs – Any database / table queries

Object / Class diagrams

Solution
Criteria Completed in Full (Y/N)
Fully created coding with comments and
annotations

Code broken down into individual objectives and

sections and discussed. i.e., Login code screen
shot, and discussion about choice of algorithm to
create login.

Clearly demonstrated versioning of “test + fix”

approach to code to show progress. i.e.
Screenshot of login screen not working > discussion
on the problem > Screenshot on fixed solution.
Testing
Criteria Completed in Full (Y/N)
Testing table using original objectives with
discussion on success / failure

Functionality Testing (i.e. does main menu load

when code is initially run)

Usability Testing (i.e. when logging in does it check

and give you correct messages)

Normal Testing (expected inputs > outputs)

Boundary Testing (i.e., accepting 1900 as DOB)

Erroneous Testing (i.e., adding A into DOB)

User testing

Evaluation
Criteria Completed in Full (Y/N)

Discuss each objective as success or fail

How could you improve the program

Reflect on user testing. What could you do better /

what went well

Overall effectiveness of your project