ICT6 Coursework Guidelines

[ Home ] [ Up ] [ In the Media ] [ Major Project ] [ Project Ideas ] [ Candy Floss ]

More detailed guidance is available in the ICT6 Project Guide (Word Document)

Choosing a Project

There is a Project Advice Form in the Specification.  You can send your proposal to the board for their consideration. 

See our list of Project Ideas for some inspiration!

Analysis (18 marks)

·        Name an end-user and explain the "problem".  Identify the aspects of the problem that you will tackle.

·        Explain in detail any relationship between the system you intend to produce and the existing manual system.  

·        You should have a lengthy interview with your end-user (do not just rely on a questionnaire).  Spend time in the working environment and talk to everyone whose working life will be affected by your system.  Gather sample documents and include them in your project.  Make a full record of any visits/meetings.  Then, draw conclusions from these interviews/observations.

·        Come up with an agreed requirements specification with your intended user(s).  Get the end-user to sign his/her requirements.  These will be your performance criteria that will drive the whole project, from this point onwards.  

·        Identify qualitative and quantitative evaluation criteria (obviously, these should be heavily influenced by the end-user's requirements specification).

·        Explain clearly how your system will improve the current system (avoid vague statements such as “to save time”, “to improve efficiency”, “to make system user friendly” etc.)  

·        Identify those elements of your system that are intended to be "reusable"

·        What hardware and software will be used and why? 

See http://www.athree.com/access_info/pros_and_cons.html for a description of the pros and cons of Access.

You also need to explain why you will be using Access instead of Excel

·        You should show an appreciation of the full potential of the hardware and software that you intend to use.  

·        List the Inputs, Outputs and Processes.  Be very specific about these.

·        Fully explain the information flow (include Data Flow Diagrams).

All About Data Flow Diagrams

How to Draw Flowcharts

It is very important that you explain the diagrams.  A diagram alone does not fully explain the flow of data.

·        Evaluate the user’s current IT skill level and his/her training needs  

·        Explain how the software will be used.

·        Are there any legal, ethical and social issues arising from what you intend to do (e.g. issues of data protection?)

Design (16 marks)

·        Consider in detail a range of appropriate approaches to a solution.  Why is an Access solution preferable to an Excel solution?  Why is a computerised system preferable to a manual system?  Why is a relational database better than a flat file solution?  Do some basic designs to show how these alternative approaches would work.

·        Give compelling reasons for the final choice of solution.  Consider the likely effectiveness of your solution.  

·        Follow a process of Normalization.

See: http://itm.blackpool.ac.uk/computing/Course_Webs/HND_Computing/DATABASE/03/norm.pps 

·        Produce entity-relationship diagrams

See: Drawing Entity Relationship Diagrams using PowerPoint

See: A more complicated description of ERDs and Normalisation

·        Break down all envisaged tasks into sub-tasks.

·        Create a well defined schedule and work plan to show how each task will be carried out.  Explain why you have chosen to carry out the tasks in this particular order.

N.B. This is a schedule of the implementation not for the project as a whole.  Include dates!

·        Produce a detailed design of the solution clear enough to allow a competent third party to implement it.  Include designs of  reports, forms, tables, queries, relationships, macros, the menu structure, etc.  Fully annotate the diagrams to show validation, fonts, field sizes, default values, data capture methods, security features and so on.  Make sure you design the processes as well as the inputs and the outputs.

·        Refer back to your requirements specification and ensure that your design meets your user’s requirements.

·        Write a test strategy (How will you go about testing?  Who will be involved?  What will be the difference between your testing and the end user's testing?  What sort of data will you use?  What sort of things will you test?)

·        Create a full and effective testing plan with a comprehensive selection of test data.  Give reasons for your choice of this test data.  Make it obvious that your testing plan is inspired by your requirements specification (cross-reference it).  Remember that you are testing the flow of data, not just whether a particular button works or not.

The Test Plan carries a lot of marks.  For top marks, you should ensure that you are fully testing the functionality of the system and that you are using "extreme and erroneous test data".  There should be a separate end-user test plan.  There should be a "dataset" for testing the queries.  Make sure you "test to fail".

N.B.  The end-user test plan is very important.  It should be noticeably different to your test plan.  An end-user test plan will probably test the functionality of the system, the interface, the help facilities and the output rather than long sets of extreme/erroneous test data.

·        Design the user interface in relation to the experience/skill level of the end user(s)

·        Design online/offline help  

·        Design a backup system (remember that you are thinking here about the backup system to be used by your end user - it should go without saying that you should backup your project).

·        Design any inter-relationship between software packages

·        Include navigational diagrams

·        Consider prototyping  

·        Consider the "management of change"

Implementation (15 marks)

·        All or most of the facilities of the software and the hardware must be fully exploited.  

This means a fully relational database, which utilises the advantages of relational databases, forms based on multiple tables, reports that include grouping and calculations, subforms and Action Queries to make the system "resusable".

·        Progression of work must be shown by printing out regularly and annotating fully

·        If wizards are used, should how they have been modified.

·        Commentary should explain what decisions you made and why you made them.

·        Print out and annotate VBA code or expressions.  

·        Organise appropriate training 

User Guide (8 marks)

·        Include fully illustrated and comprehensive user guide, with examples of screen displays, explanation of validation restrictions, user interface, error messages that the user might encounter, etc. Wording should be sympathetic (avoid jargon).

·        Make sure you include sections on installation, backup procedures, general use and troubleshooting.  

·        User Guide should be bound separately from the rest of the project.  It should be well organised.  Include contents page and index.  Number the pages. 

·        Hand the User Guide to your end-user before the Testing stage.

Testing (15 marks)

·        Clear evidence of end-user involvement in testing (e.g. evidence of an end-user test plan being followed).

·        Test outputs should be fully annotated and cross-referenced to the test plan.

·        Test typical, extreme and erroneous data and ensure that the functionality of the system is tested.

·        Testing should show appreciation of different circumstances (e.g. the difference between a standalone computer and one on a network)

·        Explain the reason for each test

Evaluation (10 marks)

·        Consider clearly a full range of qualitative and quantitative criteria for evaluating the solution.  Make it clear that these criteria relate to the requirement of the user(s).  

N.B. It is a good idea to refer to your testing.  The test outputs are the best evidence that your system does what it was intended to do.

·        What problems did you encounter and how did you overcome them?

·        How could your system be developed/extended?

·        Explain any differences between your original design and the system you eventually produced. 

·        Show involvement of the end-user in the evaluation stage (a simple letter of acceptance is not sufficient).

Report (8 marks)

This is not a separate section of your project.  These eight marks are awarded for the general quality of your documentation.  Ensure that you have spell-checked your project, that you have included referenced diagrams and that you have a well-organised folder.  Include a contents page and an index and number your pages.  Make sure your project is divided into sections and that everything is in the right section.

The report should be accurate and concise and it should not exceed 4,000 words (excluding annotations, screen dumps, diagrams, etc.)