A2 ICT

Coursework
Practical issues involved in the use
of ICT in the digital world

INFO4
Project Guide

Authors / Contributors

Whitby Community College and Fyling Hall School, North Yorkshire

Wendy Banks

Paul Armstrong Whitby Community College, North Yorkshire

Kathryn Shaw
AQA

Riverside College, Cheshire

Background, specification, marking grids and exemplar material

Contents

INTRODUCTION
Brief

Working together (with clients and other students)

Using software

Further project ideas

Important note about malpractice

Sections of the project

Specification

Hints & Tips

Deadlines

8
9

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 1 of 21

1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
2
2.1
2.2
2.3
2.4
2.5
2.6
3
3.1
3.2
3.3
3.4
3.5

BACKGROUND AND INVESTIGATION (14 MARKS)

1 2
Introduction to the Organisation (2 marks)
12
Description of the Current System (3 marks)
12
I dentification of Client, Users and Audience (2 marks)
1 2
Business Case for Change (2 marks)
A
1 3
I nvestigation Techniques (3 marks)
1 3
lient Requirements (2 marks)
C
1 4
erms of Reference
T
1 5
ANALYSIS AND DELIVERABLES (15 MARKS)
1 6
tatement of Scope (3 marks)
S
1 6
Description of the Proposed System and Deliverables (3 marks)
17
ocumentation of Processes (3 marks)
D
1 9
Description of the Users of the Proposed System (3 marks)
1 9
valuation Criteria (3 marks)
E
2 0
vidence of Checking the Findings with the Client
E
2 0
DESIGN AND PLANNING FOR IMPLEMENTATION (14 MARKS)
lternative Design Solutions (2 marks)
A
2 1
esign of the Solution (3 marks)
D
2 1
I mplementation Plan and Training Requirements (3 marks)
2 2
esting Strategy (3 marks)
T
2 3
est Plan (3 marks)
T
2 4

TESTING AND DOCUMENTATION OF THE IMPLEMENTATION (13

MARKS)
5
2
4.1
esting the Whole Solution (3 marks)
T
2 5
4.2
esting with Client and Users (3 marks)
T
2 5
4.3
ocumentation (3 marks)
D
2 6
4.4
echnical Documentation (2 marks)
T
2 6
4.5
ppropriateness of Documentation (2 marks)
A
2 7
5
VALUATION (7 MARKS)
E
2 8
5.1
valuation of the Whole Solution (2 marks)
E
2 8
5.2
valuation against Client Requirements and Evaluation Criteria (2 marks)
E
5.3
valuation of Students Own Performance (3 marks)
E
2 8
6
ROJECT REPORT (7 MARKS)
P
2 9
6.1
se of Software (3 marks)
U
2 9
6.2
rganisation and Use of Language (2 marks)
O
2 9
6.3
iagrams and Illustrations (2 marks)
D
2 9
7
IBLIOGRAPHY
B
0
3
8
PPENDIX
A
0
3

21

28

Introduction
Brief

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 2 of 21

This unit provides you with the opportunity to complete a substantial project involving the production
of an ICT-related system over an extended period of time. In so doing, you will enhance your
transferable practical skills. It is important for your project to have a level of complexity and demand
appropriate to the second year of an A Level. Regular involvement of the end-user is essential to the
success of the project. You will need to provide evidence to verify this.
The following may help to illustrate the range of possible projects that could be undertaken. They
show how you might be able to work on an individual or group project whilst still producing an
individual project report that has your own work clearly identified.
You may, for example, produce
a software solution such as an e-commerce or multimedia system
a training system, including training materials for a client. This could, for example, be for a
course for someone working from home
a user support system, such as for a user help desk in a company or school/college, or a fault
logging system
a system for ensuring the security of an organisations ICT systems. An idea here would be to
formulate a policy to specify appropriate use of a company or a schools/colleges laptop
computers and other mobile devices, or a database to record usage
a system for communication within an organisation: for example, for how schools could use
technology to communicate with students within the school or a communal diary system
a system for evaluating new software to be purchased or for a new system to be installed,
including hardware, software, communications, consumables and services
a backup and recovery system and a disaster recovery plan for an organisation
a system for managing relationships with customers

Working together (with clients and other students)

It is intended that you will become involved in real situations in organisations where you can apply
your skills, knowledge and understanding of ICT to solve problems for a client. An organisation is
defined as any group of people who use ICT to achieve their aims and objectives. Examples of an
organisation include a local company, a retailer, a school or college, a charity, a club or society, or just
a group of people coming together to organise an event.
It is quite acceptable for you to work in a team for the same client, if that is what is required for the
work being undertaken.
The team could consist of two or more students working with one or more members from the client
organisation. This approach is encouraged if it allows students to become involved in larger more
realistic projects where each student can work on part of a system.

Using software
The project should involve you using applications software for a variety of purposes and should also
introduce you to the fundamentals of project management.
You will be expected to make full use of the functionality available in word processing software for
the production of the project report and, if required, to enable collaborative working.
The project should encourage you to think creatively, innovatively, analytically, logically and critically
as you consider and suggest alternative approaches, investigate and discuss possibilities, and
recommend actions to be taken.
You will produce a project report that will be assessed internally by the school, to the criteria provided
in this specification. The schools assessment will then be moderated by AQA. For this reason,
although collaborative working is encouraged, it is imperative that assessors are able to identify your
own contribution, and you must produce your own project report.

Further project ideas

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 3 of 21

The following may help to illustrate the range of possible projects that could be undertaken, and how
groups of students could work together, whilst still producing an individual project report that has their
own work clearly identified. It is perfectly acceptable to produce a spreadsheet or database solution to
a problem if that holds more interest for you.

Website, intranet site or extranet site

For any organisation (or event), students could produce parts of an intranet for different departments
within an organisation, working collaboratively to establish house styles and consistency of end
product, and in sharing their skills in the use of the variety of applications software needed to create
the end product.

Training materials
Training materials could be developed for a course within the centre or for an external organisation.
Materials could take a variety of formats and be created using a range of software. Individual students
could work on one aspect or one format, whilst the whole group has to adopt consistent styles and
approaches to development. For example, training could be needed in
a new piece of software
using new laptops, PDAs or other portable devices
using loan items such as digital cameras or recording equipment
a new security policy
a backup and recovery strategy
health and safety legislation or guidelines
environmental policies, such as disposal of computer equipment.
Other students could perhaps develop a system for storing, cataloguing or loaning out training
materials that have been created.

User support and fault logging

A group of students could each work with a different type of user, or a different department of a school
or other organisation. Materials required might be similar in purpose, but need to be produced so as to
best suit the individual types of user, or some may have specialist needs which need supporting.
Recording and storage of requests for maintenance, error reporting or fault logging could be built in.

Managing relationships with customers

This could involve a system for the collection of customer feedback via a website and a back office
system that can collect, store and classify responses, plus a system that results can be fed into for
statistical analysis. Individual students could take on one of the elements, where collaboration would
be essential to ensure effective data transfer, correctness and accuracy.

Multimedia solutions
These can be used in a variety of situations. They can be extremely large systems and frequently need
to be broken down into manageable chunks. Separate students could work on parts of an overall
solution. This could include producing an interactive map, where subject specialisms or special
interests could determine with what areas students became involved. For example, one student could
prepare and incorporate information on areas of interest for young adults, another on sporting venues,
a third on flora and fauna. This could be produced for the local tourist board or town council.

Important note about malpractice

You need to be aware that teachers should inform candidates of the AQA regulations concerning
malpractice. Candidates must not
submit work which is not their own;
lend work to other candidates;
allow other candidates access to, or the use of, their own independently-sourced source material
(this does not mean that candidates may not lend their books to another candidate, but
candidates should be prevented from plagiarising other candidates research);
include work copied directly from books, the Internet or other sources without
acknowledgement or attribution;
submit work typed or word-processed by a third person without acknowledgement.

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 4 of 21

These actions constitute malpractice, for which a penalty (e.g. disqualification from the examination)
will be applied.

Sections of the project

The project constitutes 20% of the full A Level qualification (40% of the A2 year).
The project is marked out of 70 marks. Here is the breakdown of the marks for each section of the
project
Background and Investigation
Analysis and Deliverables

(14 marks)
(15 marks)

(14 marks)
Testing and Documentation of the Implementation
( 13 marks)
Evaluation
( 7 marks)
Project Report
( 7 marks)
Design and Planning for Implementation

Hints & Tips

As we have a tight time schedule for marking your project, you must ensure that you
hand in your project by each deadline.
Keep a diary log of all the occasions you met or talked with your client / user and the reason for
the meeting.
Remember that project write-ups are time consuming Dont leave it until the last minute
work on it throughout the project.
Divide your project into manageable sub-tasks (bite sized chunks) set yourself intermediate
deadlines for each one and stick to them.
Make sure that you complete all sections of the project.
Only your write up will be seen by the moderator you must make sure that it shows evidence
of everything you have done they will not see your work on computer.
You must provide evidence that your solution works.
Design sketches and annotations should be done by hand.
Leave a left hand margin of at least 20mm on all pages to allow for binding.
Annotated printouts, scans, diagrams, pictures etc should be given a fig number so that they can
be referred to in the write-up.
Dont be afraid to ask for help, if needed, but any direct assistance given by the teacher may
affect your mark.
Provide a clear and detailed record of all sources of information gathered and used throughout
the project.
Record any work done outside the supervision of your teachers.
Read through all documentation you receive so that you are clear of exactly what is expected of
you.
Much of what you learn in INFO3 can be applied in this INFO4 coursework.

Deadlines
You will have interim deadlines for different parts of the project throughout the year when your work
will be handed in and interim marked. The final deadline for the completed work is

First lesson after the Easter holidays

Monday 27th April 2012
Specification
The following table has been copied directly from the AQA supplied specification and explains what
you need to include in your project. It is therefore important that your project report covers all of the
sections listed in the table.

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 5 of 21

You should refer to this table for help throughout the project plus the detailed notes that follow. In
addition, you should refer to the A2 Nelson Thornes textbook. The mark scheme has also been
provided so that you can see what you need to do within each mark range.
Section

The project report

Amplification
should Include
1. Background & An introduction to the This should include the type and purpose of the
investigation
organisation.
organisation, and give an idea of its size and scale of
operation. Your contact within the organisation should be
identified.
(14 marks)
A description of the
current system (or
existing situation) and
its environment.
Identification of client,
users and audience.

2. Analysis &
deliverables
(15 marks)

3. Design &
planning for
implementation
(14 marks)

Moving down in scale to describe the system (or existing

situation) within the organisation/for the organisation
which is under investigation. The people/departments
involved.
Who is it for? Clear identification of client, users and
audience (where applicable). N.B. It is likely that there is
one client, but multiple users. At this level of study, it is
expected that this will be the case.
Why the project is needed by the organisation.

A business case
(reasons) for change.
Evidence of the use of Evidence of, for example, planning, conducting,
relevant investigation documenting and evaluating meetings with clients,
techniques.
interviews, observation, questionnaires, research as
appropriate.
Requirements of the
What is the proposed system to provide?
client.
Statement of scope.
This should include any internal or external constraints on
the proposed system. These may include hardware,
communication technologies, software, format of external
information requirements, staffing and environmental
factors.
Description of the
This may take various formats but should include the
proposed system.
benefits for, and likely impacts on, the organisation.
Documentation of
Again, the format for the documentation is not fixed but
processes.
should be appropriate to the system being analysed.
Description of the
Details of the skills of the users of the proposed system,
users of the proposed
appropriate to the system.
system.
Evaluation criteria.
Both quantitative and qualitative criteria against which
the solution can be tested and evaluated. These should be
derived from the requirements of the client.
Agreed deliverables. What is to be produced and handed over to the client?
This may be a prototype system or a partial system.
Evidence of checking
Findings must be presented in such a way as to be
the findings with the
understandable to the client.
client.
Evidence of
investigating
alternative design
solutions.

Should include investigating options for all elements of

an ICT system as appropriate to the project.

Draft design work.

To be able to discuss with client.

Final design work.

From which to implement.

Plan for
implementation, testing
and instalment,
including proposed
time scales.
Training requirements This may include what documentation will be required
for the new system.
for training the users.
Testing strategy.
Should set out what testing is necessary, who will do it,
when and where. You should describe here any

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 6 of 21

Test plan.
4. Testing &
Evidence of testing.
documentation of
the
implementation
(13 marks)

Evidence of testing
should include
evidence of client
and/or end user testing.
Comprehensive
documentation of the
solution that would
allow the solution to be
used/maintained or
developed further
which is appropriate
for the client/ users.
5. Evaluation of A critical evaluation of
the implemented the solution that would
solution
allow the solution to be
used/ maintained or
developed further
(7 marks)
which is appropriate
for the client/user.
An evaluation of the
students own
performance.
6. The project
The complete work
report
should be submitted in
the format of a project
report.
(7 marks)

constraints on live testing that require a simulated

environment to be used.
The tests that will be undertaken, what the tests are
testing, the order in which the tests will be completed.
Where testing in the intended environment is not
possible, testing in a simulated environment will be
acceptable providing this has been explained and justified
in the testing strategy. Testing should concentrate on the
testing of complete processes and the system as a whole.
Evidence of functional or unit tests, for example for
validation or for the backing up of one file, is not
required.
As appropriate, depending on whether the client is also
the end user.

Documentation could be technical or user documentation

depending on the individual project undertaken and the
agreed deliverables.

The solution should be critically evaluated against the

evaluation criteria and the client needs, as defined during
the investigation and analysis stages. Evidence from
testing should be referenced.

This should identify strengths and weaknesses in the

approach they have identified, how they would improve
their performance on a similar project in the future.
The report should be well structured and should make use
of facilities available within software packages to enable
this to be done: for example, by including a contents list,
headers/footers, pagination, indexes, effective use of
appendices and presentation techniques.
Appropriate use of technically accurate illustrative and
visual material for effective communication. An
appropriate style of writing has been adopted. The
standard of your written communication will be assessed
in the report.

Detailed information for each section of the report is included on the following pages.
The order of some of the items from the above specification has been changed to match the marking
grids. Copies of the marking grids are included at the end of the guide.

1 Background and Investigation

(14 marks)

1.1 Introduction to the Organisation

(2 marks)

Give a description of the organisation that requires the new system you are going to develop. Try to
build a mental picture for the reader of what the organisation is about. Suggested things to include
are:
o Company/organisation name
o What do they do?
o How long have they been in operation?
o Where they are located?
o Do they have multiple sites?

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 7 of 21

o Names of any key people involved. E.g. managing director,

managers, staff using the current system
o The name of your contact within the organisation and what their
responsibilities are
o A hierarchy diagram with explanation showing different
levels within the organisation (see chapter 1)
o How many employees do they have?
o What are the different job functions?
o Any relevant history e.g. are they a new company?
o Any photographs, pictures, helpful information to add?
o Any particular reasons why they are looking to get a new system?
o What do they want?

1.2 Description of the Current System

(3 marks)

Write a detailed description of the existing system how do they do things currently?
o Who are the people involved in the current situation?
o What are the problems with the current system?
o How did these problems come about?
o Is there any background history to these problems?
o What information does it produce? Who uses this?
o If there is no current system, then explain what happens now instead even if it is not
a computerised system.
o You can include data decomposition diagrams and data flow diagrams of the existing
system here. Make sure you explain any diagrams you include.

1.3 Identification of Client, Users and Audience

marks)
o
o
o
o
o

(2

Describe the client, users and audience clearly

Give names, job roles and positions within the organisation
How do these people use the current system?
What problems do these different people have with the current system?
Do they have different problems?

As part of your continuing contact with your client and users, you should keep a diary record to record
all your contact with them throughout the project. Make a note of who you met, when, where, the
purpose of the meeting and any outcomes or feedback from them. Also include any contact via phone,
email or other means. This diary log can be presented in the Appendix and is probably best laid out in
a table.

1.4 A Business Case for Change

(2 marks)

Explain why this project is needed by the organisation. Reasons for change usually fall into four main
categories.
o Technology perhaps a new technology has emerged which the business needs to
embrace e.g. when barcodes were invented, or perhaps existing technology is being
phased out and the current system will no longer be supported. Is their old system too
slow so it is losing them customers?
o Economic perhaps the existing system is too expensive to maintain or the new system
would introduce cost savings? Are they losing business? Is it to save money? Do they
want to attract more customers as they need to make more money? Have they got a
competitor who is taking all their business? Have they grown quickly as a business
and are finding it difficult to maintain adequate records?
o Legal have there been changes to legislation that means the system is needed?
o Operational does the existing system operate correctly? Perhaps it does not have the
required functions.

1.5 Investigation Techniques

(3 marks)

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 8 of 21

There are a variety of techniques that you can use to investigate the current system and you need to
include two or more to gain higher marks.
o Interviews
o Questionnaires
o Observation
o Thought showers
o Record searching / document analysis
o Fact recording
Make sure you explain what techniques you are using, why you are using them, what data and
information you can gain from them, how the techniques are appropriate for your project and what
people are involved etc. Include scanned copies of any documents and refer to them within your text.
You could use photographs of observations if they are relevant.

1.5.1 User Skills Survey

At this point you should also conduct a survey of user skills. Documentation of this will follow in the
analysis section but it needs to be carried out now. You need to get a good idea of the skill level for
each user (or group of users) and determine exactly what they can and cant do, what skills they
already have, how they prefer to learn (self taught, in a classroom, from a colleague, from a book or cd
etc). Consider their business skills and non-technical skills too, not just what they can do on the
computer. Think about how you can find out this information e.g. by questionnaire, interview,
observation etc. If a questionnaire, then you need to think carefully about the design of the form and
the way you word your questions.
Remember that users can be both internal and external to an organisation
o internal = member of own workforce
o external = e.g. member of public using extranet to buy goods and services

1.6 Client Requirements

(2 marks)

You need to identify all of the requirements for the client.

Requirements tend to be what the system has to be able to do and what it is to provide.
They may be a mixture of qualitative (opinion) and quantitative (measurable) requirements.
If you have clear requirements this will make it easier for you to evaluate your system at the end of the
project.
Types of requirements you should consider alongside the actual processes of the proposed system
o performance (e.g. time needed to complete a task)
o timing (any deadlines for output to be produced)
o archive (how long for, where, how etc)
o system availability (24/7, 9-5, etc)
o failures (contingency, computer failure)
o System integrity (what to do about errors)
Examples of qualitative requirements (opinion)
o The system should be user friendly
o The system should be easy to learn
o The system should be easy to navigate
o The system should be pleasant to look at
o The system should be easy to read and understand
Examples of quantitative requirements (measurable)
o The system should be able to look up a customer in x
minutes/seconds
o The system should be able to complete an order in x
minutes/seconds
o The system should automatically print out an invoice on paper
o The system should include a facility for the user to provide
written feedback
o The system should include the company logo on all
documentation
o The system should use the corporate colours and styles

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 9 of 21

It is very important that you have a logical numbering system for your requirements because you will
be referring to them throughout the project. You can number them in any way you wish but be
consistent e.g.
o 1, 2, 3, 4 etc
o A, B, C, D etc
o R1, R2, R3, R4 etc
The best way to lay this section out so that it is clear is to create a table with 3 columns (requirement
number, short description, detailed description). For each requirement give some detailed explanation
that includes:
o A more detailed description of the requirement
o The reason for the requirement why is it needed? What does it do for the user?
o Limitations give any constraints imposed on the resolution of the requirement
Typical constraints could include hardware/software, legal constraints, policy constraints,
system-related constraints, financial constraints etc

1.7 Terms of Reference

It is advisable to create a Terms of Reference document for your client although it is not specifically
referred to in the specification or marking grids. It is what would happen in a real business and it
helps to set out all the initiation aspects of the project so everyone involved knows exactly what is to
be produced and what is being omitted. It should be a separate document and you should include it in
the appendix. It is not usually a long document probably only a couple of pages. The client should
agree your Terms of Reference and provide you with signed approval, preferably on headed notepaper.
A scanned copy of the letter should also be placed in the Appendix.
(See page 130). A Terms of Reference should include most or all of the following information (leave
out any that are not appropriate for your project):

Background

An introduction to the project along with relevant background information to

set the scene for the justification of this project. Include references
to the current problems and errors in the existing system.

Aims and Objectives Aim: a clear statement of the purpose of the proposed project.
Objectives: set out what the project will do in specific, measurable terms. They
should be realistic and achievable in the time available.

Deliverables States what the project will deliver at each stage of the life cycle. Deliverables
are NOT the same as requirements. (See analysis section for further
detail).

Scope States what is included and what is excluded from the project.
Resourcing W
hat people are involved, when they will be needed, for how long, in what
capacity etc.

Timescales

Overall timescales for the project including any specific deadlines e.g.
proposed system design to be ready on dd/mm/ccyy, and the
proposed end date when the system will be installed and fully
functioning.

Reporting arrangements States when and how you will contact your client.
Client and User
escription of who the client and users of the proposed system are and
D
what their roles are.

2 Analysis and Deliverables

2.1 Statement of Scope

(15 marks)
(3 marks)

The scope of the project sets out exactly what will be produced by the proposed system and what will
be excluded. In other words it states the boundaries of the system. If you do not explicitly state what

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 10 of 21

the boundaries are you cannot get 3 marks. You also need to discuss the constraints on the proposed
system and these can be internal or external constraints. Things to consider for both internal and
external constraints are:
o Hardware
o Software
o Communication technologies
o The format of information requirements
o Finances
o Staffing
o Environmental factors
An internal constraint is something that can limit your ability to complete the project, but is
something that you may have some control over. For example
o Do you have particular software that you have to use and why? Perhaps the
organisation has already licensed certain software and dont want to buy other
software or perhaps all their staff are already skilled in the software they specified.
o Do you have a budget to work to? There may be only a limited amount of
money to complete the work.
o Do you have particular timescales in which to complete the work?
o Staff may have skills in particular software so you have to use that software to
produce the solution.
o You only have a certain number of staff available to you to complete the work.
An external constraint is something that is outside of the business and that you may have no control
over.
For example
o Your work is required to be compliant with the acts of law such as The Data
Protection Act, The Copyright, Design and Patents Act and the Disability
Discrimination Act.
o You have to wait for delivery/installation of something at some point in your
plan. If that is delayed the project will be delayed. E.g. in a building project, the
installation of the roof would be critical as inside work could not start until this is
completed.
The teacher resource bank on the AQA website has an example of scope with examiners
comments. Even though it is a well written, very long example it only got 2 marks because the
student did not define the boundaries of the proposed system.

2.2 Description of the Proposed System and

Deliverables
(3 marks)
At this stage you are still describing the proposed system in English and you should not be referring
to specific pieces of software e.g. spreadsheets, databases etc, UNLESS your client has
SPECIFICALLY asked for a certain type of software to be used and it is one of your
requirements/constraints. The Analysis section is all about WHAT the system is going to do and
nothing about HOW it is going to be done that comes later in the Design section. The description
should also consider the benefits of the proposed system to the organisation and any impacts (both
positive and negative).

2.2.1 Description of the Proposed System

You should consider the following questions plus any others of your own:
o What software do you propose to use? (only if this is a specific requirement
e.g. a website)
o What hardware will it run on?
o Does it need any extra hardware/software e.g. printer, scanner, barcode reader,
Flash installed etc.
o Describe any particular key features it will have
o What will the user be able to do with it?
o How will the user and audience use it?
o How will it be updated?
o How will it be backed up?
o Will people be able to use it at the same time?

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 11 of 21

o Will it have any particular security on it?

2.2.2 Benefits of the Proposed System

Describe what benefits the new system will bring to the client, user and audience. For example:
o Will it make them money?
o Will it improve customer satisfaction?
o Will it make anyones job easier how?
o Will it bring more customers?
o Will it raise their profile?
o Will it make them more competitive?
o Will it help them to expand or move into other markets?
o Will it make it easier for customers to contact them?

2.2.3 Impact of the Proposed System

For each of the benefits you have identified you should consider what impact each one could have.
o In the case of a business opening an online shop, the extra business could
secure existing jobs or result in more jobs being created.
o In the case of a tourist information website, the impact could be more
customers in the tourist information shop possibly requiring more staff, and
more visitors to the region resulting in an improved local economy.

2.2.4 Deliverables
Deliverables are NOT the same as requirements. A deliverable is something you are going to provide
to your client at various stages in the development of your system and what you will hand over at the
end. You need to be specific when listing the deliverables so there is no confusion over what you
intend to deliver. For example, if you say you are going to deliver web pages, the customer may
expect the website to have been registered and be up and running, whereas you may be expecting to
just hand over the files and it is up to them to find a host and register the URL.
Some examples could include:
o A project plan showing timescales, key milestones etc.
o Identification of user skills and training requirements
o User documentation in the form of a User Guide
o Design of the system such as online forms, printed reports etc
o Microsoft Access Database meeting set requirements
o Administrator Guide
o Website pages to be handed over to customer to register URL and host.
o Website with registered URL and hosting included.
o Desktop Hardware (2Ghz processor, 2GB memory, 20GB HDD, 17 monitor)
o 1 week training course between 1-5 Sept to train all staff on the new system,
o 1 person providing support for 1 month after the system is implemented.
See p46 for further examples.
You need to list all of your deliverables, explain each one and give a due date for each one.
It is important to include the deliverables with dates in your Terms of Reference and get client
approval.

2.2.5 Project Plan

All projects need a plan of how they are going to proceed and your project is no different. You need
an overall project length with a defined total duration plus start date and end date. Then sub-divide the
project into sections for example, Analysis, Design, Construction, Testing, Installation etc. For each
section work out a realistic duration, start date and end date. Remember that some tasks can be done
at the same time and you dont have to be working exclusively on one section fully at one time so
there can be some overlap. You may for example do both implementation and testing of different
parts of the system at the same time.
The easiest way to show this information is in a Gantt chart. Include week numbers and dates and
show any milestones such as design documentation or user training etc. These are identified by a
diamond shape. You can use any software. There is dedicated software available for project planning
but it is perfectly acceptable to create a table in Word or Excel that will be sufficient for what you
need. At this stage this is an overall project plan. In the Design section you will create a more
detailed plan by further developing your Gantt chart and adding more detail to encompass the sub

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 12 of 21

tasks you have designed and the different types of testing you will undertake.
A simple example of a Gantt chart:
week 1
date 0

2/
1
1/
0
9

10 11 12 13 14 15 16 17 18 19 20 21 22

0
9/
1
1/
0
9

1
6/
1
1/
0
9

2
3/
1
1/
0
9

3
0/
1
1/
0
9

0
7/
1
2/
0
9

1
4/
1
2/
0
9

2
1/
1
2/
0
9

2
8/
1
2/
0
9

0
4/
0
1/
1
0

1
1/
0
1/
1
0

1
8/
0
1/
1
0

2
5/
0
1/
1
0

0
1/
0
2/
1
0

0
8/
0
2/
1
0

1
5/
0
2/
1
0

2
2/
0
2/
1
0

0
1/
0
3/
1
0

0
8/
0
3/
1
0

1
5/
0
3/
1
0

2
2/
0
3/
1
0

2
9/
0
3/
1
0

Analysis
Design
Construction
Testing
Installation

2.3 Documentation of Processes

(3 marks)

As well as a written description of what the new system is going to do you should also consider using
data decomposition diagrams and DFD diagrams (data flow diagrams). These can be created at
different levels (level 0, level 1 etc) and help to define how the data flows around the proposed
system, where it comes from, where it goes to, where data needs to be stored etc. You could also
consider the use of flowcharts to document the logical processes involved.
Examples of these can be found in the textbook Coursework for A2 ICT by Barbara Wilson.
You need to document all the inputs, processes and outputs. It is always easier to start with the
outputs and then identify the inputs and processes needed to create that output. For example:
INPUT
PROCESS
OUTPUT
Customer name and address Multiply price by quantity to get total cost of items Invoice for a
Item code and description Add up all total costs to get overall total cost
customer
Quantity
Calculate vat
Price
Add vat to overall total cost to get grand total
IMPORTANT these must be non-software specific. The example above just lists data that would be
relevant, says how calculations are done and what needs to be produced. It does not mention any type
of software at all and it does not imply where any data is stored.
Also look at the activity on page 139 in your textbook. This will help you identify what information
will be useful when defining your processes.

2.4 Description of the Users of the Proposed System

marks)

(3

Use the information gathered / questionnaire you created in the investigation stage to document the
user skills. If there are multiple users, describe each of their skills individually. This need not only be
their technical skills e.g. how well can they use spreadsheets, but also what business experience they
have and how quickly they can pick up new skills. If the users have completed the questionnaires by
hand then scan them into your work.
Things to consider for each user:
o Identify the job role
o What parts of the proposed system are they likely to be using?
o What skill levels have you identified for these users?
o Describe what skills (technical, non technical, business) you think they will need to use
the proposed system
o What they can and cant do will influence how you design the system and what types
of help and support you may include. Describe how you will consider their skills and

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 13 of 21

knowledge when creating your design in the next stage

o Do you think they will need any training?
o What types of training will be the most suitable for them? Refer to Section 8 in the
textbook
o What support do you need to provide for them once the system is up & running?
o How would they cope with problems that occur during use?
o Do they need user guides? Online help? etc
Remember, anything you need to provide for your user needs to be included in your test plan later.

2.5 Evaluation Criteria

(3 marks)

Evaluation criteria are a way of measuring the success of the project once it is completed. Just like
requirements, they should be a mixture of qualitative and quantitative measures. It is important that
your evaluation criteria relate to your original requirements. Each requirement should have at least
one evaluation criteria, preferably more and they should be identifiable e.g. numbered. For example:
REQ Requirement
Evaluation Criteria
1
The system must
print out class lists 1.1 Class lists must be sorted into alphabetical order of surname
for each teacher
1.2 Class lists must be printed on A4 paper in portrait format
1.3 Class lists must use the house style and show the school logo in the top
right hand corner
1.4 Class lists must look professional and easy to read
1.5 It should take no more than 1 minute to locate the correct class and
print it
Note that neither the requirements nor the evaluation criteria specifically mention or imply a certain
piece of software. Sometimes it is unavoidable especially for example, if your client has requested a
website, but try as far as you can to keep them generic and independent of any software.
Evaluation criteria categories that you could consider (see p134):
o Performance e.g. overall time to complete a business process
o Timing e.g. output deadlines
o Archive e.g. retention period for data
o System availability e.g. required hours per day
o Failure measures e.g. contingency procedures
o System integrity e.g. error management

2.6 Evidence of Checking the Findings with the Client

It is now very important that you get some feedback from your client to make sure that what you have
described in your investigation and analysis is what they actually want. Give your client a copy of the
relevant parts of your work. They need to give you written feedback and explain in writing any
changes that they need you to make. You should then update your work to include the changes that
they have requested.
Describe here what documents and information you are providing for your clients and what changes
they have requested. Provide evidence of letters, emails, scans etc.

3 Design and Planning for Implementation

3.1 Alternative Design Solutions

(14 marks)
(2 marks)

You need to provide evidence of investigating alternative solutions to the problem. Identify two or
three different design solutions which could be used to meet the clients requirements. It could be
different types of software (e.g. databases vs spreadsheets vs manual) or it could be different ways of
solving the problem with the same type of software. For each alternative
o Describe the alternative solution
o Refer back to the clients requirements and discuss whether or not this solution can

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 14 of 21

meet the requirements and how well. Discuss advantages and disadvantages of each
solution.
A clear way of presenting your findings could be in a table as below.
Requirement Option A Option B

After you have completed the comparison, state which option you are going to use and why.

3.2 Design of the Solution

(3 marks)

This section will probably be a long section! You need to document the whole design of your system,
including the hardware and software, and designing all the inputs, processes and outputs (in other
words, HOW you will do everything). You will also need to get user feedback after you have
completed this part, provide evidence that you have consulted them and then incorporate any changes
into a final design. How you provide this evidence is up to you. For example you may have given
them some screen designs and they have hand written comments and changes directly onto the paper.
You could include these copies in the appendix and describe the changes within the body of your
report. Or you could include scans of these documents within this section and show the final design of
that feature incorporating their changes. Or you could ask the client to summarise all the findings in a
formal letter which you then scan into your report. The choice is yours.
What hardware needs to be used and why?
Where will that hardware be located?
What type of network structure will be needed?
What software is needed for the application components e.g. operating system, DBMS,
applications software, communications software etc
o What type of backups will be needed? Where will they be stored? etc
o
o
o
o

What else you include in this section will again depend on the type of system you are creating.
Remember that these are designs of what you are going to create; you havent created anything yet (or
you shouldnt have!) so therefore screenshots are unacceptable. Screen layouts and reports should be
done by hand and scanned. Make sure each design is clear with a short description of each. You need
to consider the following:
o
o
o
o
o
o
o
o
o
o
o
o
o
o

Style sheets
Data Dictionary all items of data within the system
Database table designs field names, types, keys, sizes, descriptions, restrictions etc
Data dependencies and relationships
Data capture and Data input
Validation and Verification
Input forms
Queries, searches, sorts,
Output screens and reports
Data backup, security, archiving
User interface standards
Screen based interactions
Hierarchy diagrams for website pages
(see page 142- for further information)

3.3 Implementation Plan and Training Requirements

marks)

(3

3.3.1 Implementation Plan

Divide your system design into manageable chunks or subtasks and describe what each subtask is.
You have already created a project plan by using a Gantt chart. You now need to expand it to include
all of the subtasks within your system. You need to allocate durations, start dates and end dates for

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 15 of 21

each subtask. This will affect the construction, testing and installation parts of the plan. You also need
to prioritise each task and work out what order each task needs to be done in. Think about where user
testing could be incorporated and whether any user testing could be done at the same time as you are
working on other parts of the system. If you copy your original project plan you can add all the
subtasks onto the same plan. Make sure you include an explanation of what your plan is showing. It
is not sufficient to just have a Gantt chart and nothing else. Also include user training, installation,
conversion of existing data etc in your plans.

3.3.2 Training Requirements

You have already investigated the skills of your users and documented this. You now need to describe
what training needs the users have and any support needs they may have for when the system is
completed and installed. More than one method may be needed and different users may have different
needs. Provide justification for your choices. Training and Support Options could include:
o Initial training via one-to-one tutoring or whole group session
o Printed Manual / User Guide
o CD-ROM Training Guide
o Powerpoint Presentation
o Website / online screens
o Online help built into the system

3.4 Testing Strategy

(3 marks)

A test strategy is an overall plan for all testing activities that will be carried out to check that the
original needs have been met. The strategy is concerned with checking the solution as a whole and
that all the original requirements are working as they should. Testing is carried out at several levels
which are listed below and for each level you need to consider the following in your strategy:
o Purpose, type and scope of the tests and what deliverables are expected
o Who is responsible for these tests
o Who will do the testing (mention user involvement where appropriate)
o What activities will take place and which people will be involved
o Where the testing will take place
o When the testing will take place
o What resources are needed
o Any constraints on live testing?
o Is volume testing required?
o Does the system need to operate on a variety of platforms or different screen sizes
(e.g. different screen resolutions for displaying web pages)
o Is a simulated environment needed?
o How will you test against the client requirements and evaluation criteria you specified?
o How will the finished solution be installed? Direct, phased, parallel, pilot? See p75
The different types of test you will undertake fall into these broad categories (see p48):
o Unit testing
o Integration testing
o Functional testing
o Systems testing
o User testing
o Operational testing
For example, if you were writing a computer program that contained several modules, each module
would be unit tested on its own first and then integration tested to make sure the modules fit together
correctly. They are both concerned with what the actual code does within the program. Then
functional testing checks that if you put abc in, you get xyz out. System testing would then look
at the system as a whole and tests would be devised to consider different possibilities, e.g. if we add a
new customer and choose products to buy does the system produce an invoice and send a confirmation
email? User testing is only started once the system is working correctly and you are completely happy
with it.
You may wish to consider prototyping where you give your client a limited version of a solution e.g. a
set of web pages that have functioning hyperlinks but the text content of the pages is omitted, to give
them a feel for the solution. They offer their comments and you then make changes.

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 16 of 21

Your strategy should also consider backups for when the system is live. You will need to check that
the backup process works correctly when you do your testing:
o How will the backups be done?
o How often will backups be done and when will they be done?
o What will be backed up?
o Who will be responsible for doing the backups?
o What medium will be used and where will they be stored?

3.5 Test Plan

(3 marks)

A test plan is a very important part of creating a solution and you must make sure it is thorough and
complete. It is important that you carry out unit testing for example, validation settings, extreme data,
erroneous data etc to make sure the system works, data can be fully seen, all the correct information is
present etc, though there is no requirement for you to document this in the project report. The test
plan must focus on systems tests, user tests and operational tests (where appropriate).
A test plan is created after the design of the solution has been completed, but before the solution is
actually created. In a large organisation, different people would be responsible for the design and
construction of the solution so once the analysts have completed the design, they will pass it over to
programmers who will create the solution. While the system is being created the analysts will then
work on producing system test plans and user test plans so that they will be ready to use once the
system has been completed. The programmers would be responsible for doing any unit and program
testing before handing it back to the analysts.
It may be helpful to break your system testing into the subtasks you identified earlier. This will help
you to focus on all the different aspects of your system and make sure nothing is omitted. You can use
a logical numbering system to do this make sure you explain any numbering / organisation schemes
you use. Also, dont forget to include tests for all of your client requirements and any relevant
deliverables e.g. a user guide. Your user test plan should be on a separate page to the system test plan
so that it can be given to the user for testing.
The best way to lay out your test plan is to turn the page landscape and use a table with several
columns. This is one example though you may see variations. At this point, the last two columns will
be empty, and will be populated once you commence your testing.
Test
No.
1.1

Description Input Expected Results Actual Results Comments

1.2
For your user test plan, it is advantageous to contact your client / users and ask them to identify real
live data that can be used for testing purposes. Sometimes this can be difficult because of
confidentiality, data protection rules etc, but it is worth trying to get them involved if you possibly can.

4 Testing and Documentation of the

Implementation

(13 marks)
4.1 Testing the Whole Solution

(3 marks)

It is important that you complete full unit testing to make sure your system works, that all validation is
correct etc before you start formal system testing. There is NO requirement for you to provide
evidence of unit testing. If you include it you will not gain any credit for it and AQA have specifically
stated that they only wish to see evidence of testing the whole solution.
As there is no requirement for unit testing, and you no longer have to provide any evidence of creating
the solution (implementation), testing and documentation is the only place you have to show the
quality and extent of what you have created. The marker and examiner will not see your finished
solution, only your project report, so if you have an all-singing, all-dancing spreadsheet or database
then you need to make sure there is evidence of it here. If it is not appropriate to include it in the
testing section, then consider whether it would be more appropriate in the technical documentation

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 17 of 21

section e.g. database structures, finished web pages etc.

Copy the test plan from the design section into this section and carry out each test systematically one
at a time. For EVERY test you need to add what actually happened to the Actual Results column.
You must provide evidence via screenshots, scans of reports etc plus a description of what the
evidence shows. In the comments column you can add any modifications you had to make or include
a reference to the page number of where the testing results can be found. Make sure every piece of
test evidence refers to the correct test number. Before and after screenshots may be applicable in some
cases to prove something works. If any test fails, for whatever reason, you must retest it and show
evidence of it working.

4.2 Testing with Client and Users

(3 marks)

It is essential you have your client and users test the system you have created. There needs to be
evidence of their involvement and it is beneficial if you can get all of your users to test the system.
Print out the user test plan you created in the design section and give a copy to your users (you should
have more than one user). You may have different tests being done by different users so make it clear
which users are doing which tests. Ask them to do all the tests you have identified and to add their
results and comments to the page. It is also sometimes beneficial to give the users a blank test plan so
that they can add any extra tests they think of that you may have overlooked. Or ask them to write a
short document about their findings. (Refer to sections 4.5, 5.1 and 5.2 regarding client feedback).
These documents can then be scanned into the appropriate place in your project report.

4.3 Documentation

(3 marks)

The types of documentation you could consider creating:

o User Guide
o Technical or maintenance documentation
o Installation Guide
o Training Manual
o Training Instructors Manual
You will probably create just the first two of these, unless you have a specific requirement from your
client to create any of the others, or to deliver a training course. Include a paragraph in your report of
how you think your documentation (all types) meets the needs of the client/user. Make sure you
reference where the documents can be found in the Appendix.

4.3.1 User Guide

A User Guide should be a separate document provided for your users and should be presented in the
appendix. It should be written in language that your users can understand (i.e. not technical!) and
should be pleasing to the eye. Try and find some good and bad examples of manuals to help inform
your choice. What you include will depend on your system but you could consider:
o A Front Cover
o A Table of Contents
o An introduction stating what the system is about and who uses it
o Instructions on how to load the system (and install it if appropriate)
o Routes through menus/website navigation guide
o An explanation of what each option on a menu does using screen shots to illustrate
o Samples of output on screen and paper outputs
o Any special instructions on how to input data e.g. the format of a date field or the range
of accepted values for a field
o How to save changes
o Explanation of error messages and what to do if they occur / FAQ

4.4 Technical Documentation

(2 marks)

A separate document that can be used as technical documentation is strongly recommended though it
does depend on what type of system you have created. Include it as a separate document with its own
front cover, table of contents, page numbering etc and include it in the appendix. This is NOT a guide
on how to use the software (assume that the reader knows the software); it is documentation to help

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 18 of 21

someone maintain your system and make changes to its structure, add new features etc. Remember
what was said in the testing evidence. If you have a complex solution but it hasnt been evidenced
very well in testing or anywhere else, consider putting it in the technical documentation. What you
include will depend on your system but you could consider:
o Hardware and Software requirements
o Instructions for opening and configuring the system
o Database relationship diagrams
o Database table structures
o Validation and verification procedures
o Macros
o Complex formulae, functions, calculations etc
o Any programming code you have used
o How web pages link together (hierarchy diagram)
o How to upload changes to a website
o Information about domains, web hosting etc

4.5 Appropriateness of Documentation

(2 marks)

You need to get feedback from all of your users so that they can comment on the documentation you
have supplied. You could do this via a questionnaire if you wish. It could also be combined with all
the feedback you need to get for the whole solution, not just the documentation. Write a concluding
paragraph to back up your evidence and explain your conclusions. Include any client and user
comments here with evidence e.g. scans, letters, emails etc.

5 Evaluation

(7 marks)

5.1 Evaluation of the Whole Solution

(2 marks)

Ask your client and users for feedback about your solution. This could be in the form of a
questionnaire so you can ask specific questions, or it could be general comments from them. Either
way, you must include some feedback in your evaluation and also refer back to your testing to back up
any statements you make. Include any written feedback you receive in your report.
Look at the solution as a whole and identify the strengths and weaknesses of the system.
o What works really well?
o What is not so successful?
o Is the solution an effective one?
o What improvements and enhancements would you suggest?
o Are there any changes the user would like to make? Why?

5.2 Evaluation against Client Requirements and Evaluation

Criteria
(2 marks)
Now you need to evaluate your system in more detail by referring back to the original client
requirements and evaluation criteria. Copy your table of requirements and evaluation criteria into this
section from the analysis section.
For each requirement, comment critically about each of the evaluation criteria that relate to that
requirement. Again refer to client feedback and your own testing to back up your comments. You can
include any suggested improvements here too. Use the four questions above to help structure your
comments.

5.3 Evaluation of Students Own Performance

marks)

(3

Finally you need to evaluate your own performance. You are required to identify your strengths and
weaknesses in the approach you took and how you have learned from any problems or achievements.
Then you need to consider areas for improvement. Students usually find this part quite difficult.
AQA have included an example of a self evaluation on the teacher resource bank of the website and
you should have a look at this for ideas. Also, try the following:
o Identify an achievement, something you were pleased with, or proud of, in this project
o What have you achieved? What has changed for you? Is there something you can do

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 19 of 21

o
o
o
o

now that you could not do before? Is there something you now understand that before
wasnt clear?
Why is this achievement important? What does it mean to you?
How do you know what youve achieved? What specific evidence do you have? This
could be a skill you have acquired in your project.
How did you get there? What specific actions did you take?
Can you build on what youve achieved? Is there a next step? Are there still aspects
you would like to improve that would make an impact on your performance in the
future?
Try and answer the above questions for other achievements in this project.

6 Project Report

(7 marks)

6.1 Use of Software

(3 marks)

Use styles to ensure all headings are consistent throughout the report
Make good use of consistent styles for different levels of your work
Use bullets, outline numbering techniques (i, ii etc)
Page numbers are essential in the footer and should be sequential
Use headers and footers for other relevant/helpful information
Page layout (both landscape and portrait may be required within the document)
Use of section breaks
Use consistent margins
Include a table of contents
Include an index if appropriate
Captions for any illustrative material
Use an Appendix where appropriate e.g. for Terms of Reference, User Guide
etc
o Appendices should be used sparingly
o
o
o
o
o
o
o
o
o
o
o
o

6.2 Organisation and Use of Language

(2 marks)

o Use the section headers detailed in this guide, this will help with your
organisation
o Use appropriate technical language
o Make sure you use the spell checker and that it uses UK spellings not USA
o Use correct grammar
o Dont use text-speak!
o Get someone to proof read your work
o Check, check and check again. There is nothing worse as a marker seeing
constant spelling and typing errors.

6.3 Diagrams and Illustrations

(2 marks)

Illustrate your work as appropriate using

o Photographs and pictures
o scans of original documents
o sketches
o screenshots
o hierarchical diagrams e.g. in website design or organisation structure
o Use captions on your illustrations e.g. Fig 1 etc and refer to them in your
written work

7 Bibliography
Include references to all sources of information that you have used e.g. textbooks, other books, printed
material from your client, Internet websites etc.

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 20 of 21

8 Appendix
The appendix should not be huge. It is very time consuming for the marker/examiner to keep having
to jump around a project report trying to find the relevant material especially if it hasnt been crossreferenced very well. Try and keep all diagrams, scans, questionnaires and client involvement
evidence etc in the correct place in your document. This will ensure your numbering is sequential and
make it easier for you to organise. For each document you need to add to the appendix, make sure you
have a front cover for it and number the appendices sequentially Appendix I, Appendix II, etc. If you
use the heading styles consistent with the rest of your report then they will also appear in your table of
contents which is desirable.
The main documents that you are likely to need to put into the Appendix are:
o Terms of Reference
o Diary Log of Client/User contact
o User Documentation
o Technical Documentation

A2 INFO4 Coursework Guide

Page 16

http://www.thestudentroom.co.uk/attachment.php?attachmentid=199703&d=1361712975#_Toc264663285

19/11/2015, 13:22
Page 21 of 21