| Brief guide | Schedule | Guide |
For project 2 you must design and implement a solution to a problem for a real user with a genuine need for the system you produce. The end-users must be able to input their own data into the system you produce and answer questions to real problems.
Examples could be drawn from:
Whatever system you choose you should, if possible, choose one that involves more than one person so that you can collect information from them.
You should read chapters 18, 19 and 20 in WSG. There is a list of possible titles in the specification, pages 46-50 (though most of these will seem old-fashioned now as the world has moved on). There are further notes in the specification on pages 74-84, including the mark scheme and guidance. Further information can be found in the Teachers' Guide, pages 38-50. Be sure to read these guidelines, preferably more than once and one section at a time as your project develops (we will go through them step by step in class).
Choice of problem is critical to the success of the project: you have to get this right if you are to do well. The following cannot be said often enough:
The problem you choose must have an existing system and the people in that system must have on-going problems of finding and processing data.
The word 'data' has many uses and applications may be drawn from a wide range of situations.
The current system will be manual so the problems are likely to include:
But this level of description is too vague: the problems must be detailed and specific to the problem area you are investigating.
If you cannot think of a problem to solve then you can choose one from a list suggested by your teacher. Here is a list of possible topics within school from which you might choose your project:
These people are very busy doing their jobs so we cannot have more than two pupils assigned to any of these problems. Here are some further ideas based on scenarios outside school:
If you have used one of the problems suggested by your teacher you must show the list and state which one you have chosen.
Obtaining the cooperation of an organisation that runs an existing system is by far the best way to proceed. Use contacts such as parents or friends to establish a link with a user who will take time to help you.
Project 2 must follow the guidelines for system development:
It is very important that you link the work from one section to the next so that the project as a whole is coherent and follows a simple narrative:
Your work should flow naturally from one section to the next. It should logically consistent and coherent with each step following as a consequence of the previous ones.
Note that you should be able to complete the project in 80-100 pages. The layout of each page should be clear and easy to follow so that the markers and moderators can see quickly that you have met the requirements.
Identify a problem and analyse it to the point where you understand it well enough to design a replacement.
There is very little about the new system in the Analysis section; it is nearly all about the current, existing system.
As stated above, you must identify a problem that has clearly defined data handling problems. Any problem that does not include these will get few marks because it will not meet the mark scheme for either this section or the ones that follow.
The sample project on an estate agent's identifies problems as follows:
What the agent does when a client wants to sell a property:
What the agent does when a client wants to buy a property:
There is then a list of problems:
For describing the system and listing the problems there is one mark.
Generalising from this example, your own work might have problems like these:
Remember that these problems are all in the current system.
The problem scenario should have more than one user so that you can, in part (b), collect information from them, for example by questionnaire. If there is only one person in the problem that you choose to study then you must use more than one technique to collect information about it e.g. interview and document inspection.
This section should include a list of the user’s requirements for the new system. This may appear later in the Analysis section, after the Investigation. The user's requirements will be detailed and specific and based on the problems that you have identified. Simply, turn the problems into requirements:
User's requirements will also include the data that must be stored, the questions that must be answered (queries) and the outputs that the system will produce (such as letters, labels, badges, cards...)
Do not use the word 'database' at this stage: the user does not need a database, just the ability to store data (perhaps a spreadsheet could be used...)
If the outputs clearly involve transferring data from one piece of software to another then your work may qualify as 'complex'. But don't claim it is complex, let the reader decide.
Setting out the user requirements is very important because these are the things that you will design, implement, test, document and evaluate and most of the marks are dependent on them.
To gain the highest mark Project 2 should include more than one type of software and it should involve automatic transfer of data between them (not copy and paste). Examples of combinations of software include:
These software items should integrate to produce a single coherent system. Data should be transferred between them in an automated fashion, not by copy and paste. You should not have to force an additional piece of software into your solution, it should fit naturally as a requirement of the solution you have proposed and developed. Rather less common but certainly viable for this project is the catalogue merge feature of MS Publisher.
However, you should not mention software (or hardware) until the final section of Analysis (A3 - see below). It is the problem that must be complex, not the solution. If you are to get the extra marks for a complex problem you must describe a scenario that involves outputs such as letters or badges that include data items drawn from a data store.
The problem you investigate may have additional software requirements such as a spreadsheet for calculations or modelling or desk top publishing software for newsletters. The problem may seem fairly small when you begin but as you work through the various stages of the project you will appreciate how even quite small tasks can benefit from a computerised solution and a systematic approach to data handling and document management.
Obtain an understanding of the problem from the users and justify the method you choose to solve the problem. Use at least one standard method (interview, questionnaire, observation, document inspection) per person. Describe the methods used, including those you did not use and explain why you chose the methods you did use. Include an assessment of the advantages and disadvantages of the methods used.
You must provide evidence that you have done a thorough job of collecting the information. This could include letters, emails, interviews, questionnaires, photographs and so on. It is not enough just to gather data for a database or to produce data capture methods. You must show evidence that you have contacted your user in the form of letters or emails. An email is generally not sufficient evidence: a signed copy of your interview notes will be required (or of questionnaires or photographs of you in the location of the system...)
You should consider the various methods of fact-finding available to you and discuss each one before deciding on which is most appropriate for your problem. Do this in the first person in narrative form:
When you have completed this section you should understand your user's requirements, which you now write about as part of A1.
Describe the inputs, processing and outputs required by the current system. IN OCR-speak inputs are queries to the system. Processing is the way that questions are answered e.g. looking through a diary or list of contacts. Outputs are things like letters or lists on pieces of paper.
A typical input might be "Are there any tubes of Colgate toothpaste in stock?" You will have already identified these queries in the A1 section so in this section you will describe them in more detail.
You need around 5 of these queries. These are what you will later design, implement, test, document and evaluate.
Remember that the queries are based on the existing system, not the new one: you will be transferring the queries from the old system to the new one.
This section could be done in a table with a column for input, process and output and rows for each question.
Write an outline of the hardware that will be required e.g. a desktop PC and a printer. Likewise the software e.g. a database or spreadsheet and a word processor or DTP package.
Produce two outline systems and explain why one is preferable to the other. One system will include the items that you want to use, the other will include alternatives. Explain why you think each item in one system is preferable to the alternative in the other. e.g. why a desktop is preferable to a laptop (or vice versa); e.g. why a laser printer is better than an inkjet and why a database is better than a spreadsheet. The reasons must relate to the system and not be just general points about laptops.
Your system must include everything that you need to meet the user's requirements.
This includes software. If your system includes documents then you must consider the features that your system will need from document production software e.g. justification (for a letter), selection of fonts (for cards, labels, etc), graphical tools (for cards), layout tools such as guides (again for graphical docuements such as cards). Similarly for data storage you should probably compare a spreadsheet with a database: databases have better facilties for queries and input forms than spreadsheets.
You should not name products at this stage, just generic items. You can leave detailed choices until Design.
All designs must be appropriate to the system that you have described and proposed.
Describe alternative appropriate designs for the data structure and justify the choice. Appropriate means that the design should meet the user's requirements: no marks if it doesn't. Look back at your user requirements when designing the tables.
You should produce two working designs for each table in your system. There is no need to make multiple tables, this just creates extra work for no extra marks. If you do include more than one table they need not be related, for example you might have a table of items and a table of customers but there is no need to link the items to the customers.
The best way to do this is to produce two alternative data dictionaries, that is lists of fields with their types and properties. Define two separate solutions that would both be valid as a solution to the problem. Describe them both and explain why you have chosen one over the other.
Valid differences between the tables include: field type, validation rules, primary key, breaking a field into more fields (address, name). Changing the name or length do not count as changes.
Be sure to keep some changes for later as you get marks in Implementation for further changes to the data structure.
Design and describe two alternative appropriate designs for the input forms and justify the final choice. These should be based on the final choice of data structure from the previous section. They should be hand drawn or done in a program such as Publisher; certainly not in Access. Look back at your user requirements when designing the forms.
Areas of difference could be the layout (portrait or landscape), title (label), labels for the fields, font settings (face and size), logo, header/footer, buttons to call up actions such as navigation, printing or queries. You could also change the font, font size and colour of the form to something more appropriate and you could also add a graphic or logo.
The design chosen should reflect workflow for the user.
Be sure to keep some changes for later as you get marks in Implementation for further changes to the interface.
Describe alternative appropriate designs and justify the final choice. The outputs may include lists or tables of data produced by queries, reports from a database, charts or mail merge documents. You need at least two outputs that involve automatic transfer of data so you will need to produce at least two mail merges or catalogue merges or output to a spreadsheet.
Create two designs for each output, describe them and justify your choice of one of them over the other. Differences between the outputs could be in terms of layout, basic formatting (justification, font, font size, colour) or content (address, text, logo).
Be sure to keep some changes for later as you get marks in Implementation for further changes to the outputs.
Describe alternative appropriate choices of hardware and software and justify the final choice. You will have made an initial choice of the type of computer and software you want to provide in Analysis Part 3 e.g. choice between laptop and desktop and between types of software. Now you must choose actual models of computer that meet this initial definition.
The hardware should be suitable for running the software. You can get technical specifications of hardware from magazines or web sites. Compare two appropriate computers and printers plus software. Choice must be specific e.g. between MS Word and Open Office Writer or between MS Excel and MS Access. Or between Word & Publisher if you want to design a brochure. And between Access and Open Office Base for the data storage. Defining distinctions between two very similar packages such as Access & OO Base is very tricky as they are almost identical. Reasons for choice of hardware and software must link back to the requirements of the system e.g. to create queries or forms or transfer data to a word processor for a mail merge. OCR say that the reasons cannot be "cheaper/free" or "easier to use" so you would need detailed knowledge of the two packages to make the comparison. Or choose an alternative that is clearly unsuited to the task such as the spreadsheet Excel. You already rejected Excel in Design 4 but needs must! Excel is not suitable because it does not have stored queries; it has forms for data entry but they cannot be changed as easily as the ones in Access. Choosing fields for display in a query is difficult because you have to delete or hide columns rather than choosing fields. You've heard it all before... (see 1B)
This will probably be about the Tables section of your database software (possibly a spreadsheet?)
Give details of features like field names, field types, field size, other field properties like format, validation rule, validation message. Note that you are expected to provide your own validation messages and not leave it to the software to provide a generic one. Making a field 'required' will generate a system message and will not get you any marks in the final part of Documentation. Likewise input masks can only generate system messages (though you can still use them if you wish).
Note also that you get extra marks here for changing the data structure in two or more ways and for justifying these changes, for example you could add the primary key at this stage and add or change some of your validation routines.
This will probably be the largest section in your documentation as you will have done most work here on your inputs and outputs. You will have created at least one form for your inputs and at least two outputs from your system such as mail merge letters, newsletters, a catalogue or address labels. You may also have defined queries that will produce outputs and you may be using the reporting or charting facilities in the data handling software that you chose.
First of all you should define the queries. Back in Analysis part 1 you established your user requirements and this should have included some reference to the searches that the user carries out in the current system. You wrote about these in more detail in Analysis Part 3, the Inputs, Processing and Outputs of the current system. You now make the queries that your system needs. Each query you add makes more work so you should limit the number to no more than 5.
A popular choice of feature for input forms is the use of buttons that automate processes such as record navigation, calling macros or opening reports. To gain top marks in this and the next section you will need to use a wide range of software features and you will also need to explain and justify your choice of the features that you used. Note that you get extra marks here for changing the input and output in two or more ways and for justifying these changes, for example you might decide to add a logo or change the font.
There are many things you can do in software to implement a system; whatever you do you have to document it.
No additional work is required for this section, the marks are based on what you did in the previous two sections and also in testing and documentation.
To gain full marks you need to have justified your choice of software features, for example you might say that you added buttons to launch reports because this makes it easier for the user to carry out this operation. Or you might have said that you used Design View rather than the Query Wizard because Design View takes you straight to the design of a query. Or you might say that you chose to use mail merge rather than copying and pasting text because that is a more efficient way to create letters or badges or address labels.
Got it? To get these marks you have to say why you have used certain features of the software. OCR always require at least 2 reasons for each item.
In producing the required two documents that use automatic data transfer you will have already covered this section. What you need to do is provide a brief summary of what you did and refer to the details elsewhere in your documentation.
Before you start testing you could copy the user's requirements from Analysis so that you can check whether you have tested them.
For this section you will devise some test data that can be entered into your system with the aim of showing that it validates data input in the way you want and produces correct outputs. Five records should be enough. These should include boundary and extreme data so that you can test the validation routines.
You should also write down a list of the tests that you will perform. Group these under Inputs, Queries and Outputs. Give each test a number so that you can refer to it when you do the actual tests. This is a test plan.
When giving the details of each test you will need to state the expected and actual outcomes of the test. You could present the test results in a table. You will also need to describe the data that you used to make the test and explain why you chose it.
For full marks you will need to test your solution thoroughly (all sections) and include a section on testing by the user. The user’s comments should include critical comments that you can use in the Evaluation section to suggest improvements. You will need to produce a sheet with a list of tests that your user carries out and space for a tick mark or comment from the user. Make sure the user signs and dates it and says who they are.
The test data should, where possible, include normal data, boundary data and extreme data. The extreme data will trigger the validation routines so you can show that they work as intended.
To get 3 marks you will need to show that you have tested all aspects of the solution that you proposed in the user requirements. To get 4 marks you will have to provide evidence of testing by the user (a signed list of tests should do this).
You get marks in this section for describing the expected and actual results of your tests described above. You can achieve this in a single table if it includes the data, justification of the data chosen, a description of the test, the expected result, the actual result and a comment on whether this was expected or not.
Two of the tests should raise an unexpected result, for example a query might have an incorrect search criterion so the resulting data set is not what was expected and the resulting mail merge documents are incorrect. Make sure that any errors are present in the earlier accounts so they are not manufactured at this stage to produce the result. It is easy to put '>' instead of '<' or '>='.
The mark for explaining the choice of test data is awarded in this section.
Describe for the user how they will enter, amend and save data. One way to cover this might be to take a screen shot of your input form and annotate it with arrows and directions.
Describe for the user how the system will process data and how outputs are produced. You should provide documentation for all aspects of your solution, as set out in your user's requirements.
List errors that may occur during the running of the software that makes up the solution. The errors that you described should be ones generated by your system and not ones inherent in the software, for example entering wrong data or leaving tables open when they should be closed.
You need at least two problems and appropriate solutions. These would typically be based on validation rules for numeric data so you can show your own error messages - this is what the moderators expect.
Describe what your system can do and whether it matches the users’ requirements set out in Analysis.
Compare your solution with your design (has it changed?). Describe any limitations of the solution (what it can't do) and suggest possible improvements.
Evaluate your solution from the point of view of users – refer to the comments provided by them during testing.
|
Section |
Sub-Section |
Due by |
Pupil |
Teacher |
|
Analysis (4) |
Identify problem |
8/11/10 |
||
|
(4) |
Collect information |
15/11/10 |
||
|
(4) |
Inputs, processes, outputs |
22/11/10 |
||
|
Design (3) |
Data structures |
29/11/10 |
||
|
(3) |
User interface |
29/11/10 |
||
|
(3) |
Outputs |
5/12/10 |
||
|
(3) |
Software & hardware |
5/12/10 | ||
|
Implementation (4) |
Features of software used to produce data structure |
4/2/11 |
||
|
(4) |
Features of software used to produce input & output formats |
11/2/11 |
||
|
(4) |
Justify choice of range of features & software |
11/2/11 |
||
|
(2) |
Interchange data between software packages |
18/2/11 | ||
|
Testing (4) |
Describe tests and provide evidence of testing |
4/3/11 |
||
|
(3) |
Compare actual with expected results. Explain choice of test data. |
4/3/11 |
||
|
Documentation (2) |
User guide covering input, amendment & saving of data |
11/3/11 |
||
|
(3) |
User guide covering processing and outputs |
18/3/11 |
||
|
(2) |
List errors that user should avoid |
18/3/11 |
||
|
Evaluation
(4) |
Compare solution with design. Limitations. Effective solution for user? Suggest improvements |
25/3/11 |