| Analysis | Design | Implementation |
| Testing | Documentation | Deadlines |
Your project must be based around the requirements of a real user, who must not be yourself and almost certainly not a friend, unless that person fulfils the criteria. You must implement a real system for a real user, not an imaginary simulation for no one in particular.
You need to identify a real situation of a suitable size and scope and produce a computer based system for it. The situation you choose should be accessible to you, such as a family business, a local club or charity with which you have some contact, or something in school.
You will need to consult with people who work in the present system, you will need to be able to observe people at work and you will need access to paperwork associated with the system. The people in the situation you choose must be sympathetic to your needs and tolerant of your presence and inquiries. You will need to spend time with the people involved to develop your ideas and models.
The problem you choose should require some genuine attention, it should not be a good working system: don't try to fix something that already works! You need to have real issues to address and real problems to solve.
Getting the level of problem right can be quite difficult as you have no prior experience on which to draw, only instinct and 'feel'. You need to choose a problem which is sufficiently complex to include material from the syllabus but not so large that it takes too much time and will be impossible to complete. For example, if you are interested in flying you could write something for a local flying club: forget Heathrow and the national ATC system! On the other hand, you should not choose something where you think you know everything in advance and do no research.
You will maximise your marks by covering all the requirements well, not by doing some bits well and ignoring the rest through lack of time.
The Computing project requires that you write program code, you cannot use a package like Access without producing code to perform processing tasks. Your best bet is probably to use Delphi, though you can use Access with Delphi or another programming language such as VB if you feel more comfortable with that.
Any of these projects will make you think about the problems an application can pose and about the type of user interface and functionality appropriate to the situation and the users.
Remember that you are producing a system for a user and writing a report on what you have done.
The analysis section should provide the reader with a detailed understanding of your project environment equal to your own. The design section should provide the information needed for someone other than yourself to build the solution to the problem.
Analysis of the situation and problem you choose should be as extensive and rigorous as possible. You will probably be doing this for the first time but you will only get one chance (two at most!) to collect the information you need so you must prepare carefully and proceed with care. You must use the formal techniques in your documentation and you will probably need to spend some time turning observations, interviews and thoughts into more structured analysis and diagrams.
You must identify the prospective user (e.g. the receptionist and manager at the taxi company) and ascertain the user's needs. You should design a solution for the problem and justify it, considering any alternatives that you have considered and rejected.
You must specify and document the data flow and the processing requirements for the system, using the appropriate techniques. You must identify needs for the development and maintenance of the system you will develop. You must establish the data requirements and produce a full conceptual data model from these. Produce a preliminary data dictionary and document any specific mathematical algorithms such as calculations. Use other techniques as appropriate, including E-R models.
Specific techniques of analysis include observations, interviews, document searches, meetings and questionnaires. These all take time to prepare and must be done to a high standard: don't rely on informal 'chats' or guesswork. You need to start early and give yourself plenty of time to reflect and produce good quality material. In advance of an interview you need to prepare questions on topics such as: objectives, input, process, output, data, exceptions, errors, security, constraints and solutions. Record the interview as notes or on tape and write them up carefully - this is the basis of the whole project.
Document your findings and re-write them in systems terminology: inputs, processes, outputs, problems, requirements, limitations. Seek out input documents, record processes and obtain copies of outputs. Data models are essential for the structure they impose, the questions they raise and for the improved understanding they produce. Models ensure that the problem is broken down into smaller, more manageable chunks or sub-problems and that attention is focused on one aspect of a problem at a time.
Do not underestimate the requirements of this stage, read the specification carefully, fulfill the criteria and get the project off to a solid start. Be sure to do enough research, this will be the basis of the project and you will only get one chance. Use all the methods you can, do not rely on interview and/or questionnaire alone.
References: Heathcote chapter 62, Bradley chapters 14 & 16
Expected contents for this section of the report:
Background to and identification of problem
Describe background to problem thoroughly. Describe the organisation and the section within it where your solution will be used. Add whatever you think is relevant to your project, there is no need to give a detailed history or comprehensive list of departments and personnel, just the ones you are considering.
Include comments from existing knowledge or preliminary research if you can, for example a well-known problem or issue in the organisation that you are attempting to address.
Identification of the prospective user(s)
Say who this is and describe their position, job, tasks, etc. These should be described in a reasonable level of detail, how important they are, what roles they carry out and why you have chosen them as the focal point of your work.
There may be more than one level of user. You may be producing a system for a person in charge of a process but the system itself may be used by many employees. For example, a sign-in and sign-out programme for employees or a management system for a group that meets each week in a village hall where each person will need to know how to use your system. This will have implications for your documentation and help sections later.
Different levels of user may also have implications for security and access to data.
Identification of user needs and acceptable limitations
Write a list of the user's needs. Explore all possible aspects of their needs. By this stage you should have a good understanding of the system you are studying. Acceptable limitations are the limits you will impose upon yourself in completing your project.
The problem area within which you are working is probably larger than what you could hope to produce a system for - this is what is meant by 'open ended', the problem area is large. An acceptable limitation is to confine yourself to one part of the wider system so it is within the scope of A level.
Limitations may also be imposed by legislation, especially data protection.
Data source(s) and destination(s)
Here you describe where the data in the system comes from e.g. entered in a ledger or book or single sheets of paper stored in a filing cabinet. Source of data would also include the originator (another word for 'source'), that is who is sending the data or how it is entering the system. You are likely to replace paper input documents with computer data entered via keyboard, bar code reader or some other method.
Destination would include storage and outputs such as printed documents. An appreciation of sources and destinations will help you draw your data flow diagrams.
Analysis Data Dictionary (from perspective of end user)
Write down all the data items that the system contains. Use a table and add the sources, destinations and data types. Don't arrange these items into tables, that is done in the design stage.
Data flow Diagrams (existing and proposed system)
These are probably the best diagrammatic technique to use at this stage. They are simple and effective. With the knowledge you have gained you should now be able to put together quite quickly a representation of the existing system. You should also do a DfD for the proposed system as you should now be in a position to provide an outline of this. Look up the technique in the text book if you are uncertain of the details.
Objectives for the proposed system
Write down the things that you want the proposed system to achieve. Aim for something between 6 and 10 objectives. These should be carefully worded and precise in nature. Examples might refer to your aim to develop a system to replace the current manual system, to provide a well-designed and logical user interface to match current workflow, to provide a database and an interface to it that is easier to use than the database product on its own.
Objectives for the new system must, according to AQA, be specific and measurable, for example to increase processing by 25%, to increase revenue by 20% or to reduce costs by 30%. Objectives such as 'improve worker satisfaction', 'increase turn-around time', 'produce user-friendly interface' or 'make system faster' or 'more effective' are too vague. The distinction here is between quantitative objectives, which are quantified, and qualitative objectives, which are not. You can add qualitative objectives if you wish but you must have quantitative ones as your primary statements. Objectives might include providing better management information, providing a better service, saving time and/or effort, improving accuracy, saving money or making a task easier or less dull. Beware of phrases like 'user friendly'.
Realistic appraisal of the feasibility of potential solutions
Consider how you might implement your proposed solution. Typical choices of software might include: spreadsheet, database, bespoke program, database and program. You will need to comment on how each of these applications might be used to implement your solution. Review the features of the software relevant to your project and explain why the application might or might not be suitable.
Here are some comparative features of Excel, Access and Delphi:
Excel:
Access
Delphi
Justification of chosen solution
You will probably choose database and program, explain why you have done so (combines the benefits of both, creates a free-standing program, data can be edited in database, etc.)
Use of formal methods e.g. observation, analysis of existing documentation, interviews, questionnaires
Be sure to use at least 2 or 3 of these and record your findings in full. Include copies of forms and any other relevant documents you find. Note that there is no date for this as it refers to more than one section.
If appropriate:
E-R Models
Can be a useful tool to show the main entities in your proposed solution and the relations (one-one, one-many, many-many) between them. This can form the basis of your normalisation of the data dictionary in the design section - assign the fields to the respective entities and then check for 1NF, 2NF, 3NF and BCNF.
Identification of Objects and Object analysis diagrams
This section may not apply to you as it is concerned with diagrams to support object oriented programming.
The analysis section should provide the reader with a detailed understanding of your project environment, equal to your own. The design section should provide the information needed for someone other than yourself to build the solution to the problem.
Specify and document a design that meets the requirements of a real problem in terms of hardware and software, using methods such as system flowcharts, structure charts, hierarchy charts, algorithms in pseudo-code and relations. Use prototyping where appropriate. You must design a system that works, which will include a data model, data validation and storage, decomposition of the system into individual tasks and an overview such as a menu hierarchy.
You must provide:
Overview of the system, how it solves the user's problem. A system outline chart or a system flow chart may be useful here (Bradley pages 341-2).
There should be a conceptual model for your system using entity-attribute-relationship models such as an ER diagram. List all data items in the system along with properties such as name, data type, size, default value and any validation or verification routines to be performed.
Design of the user interface including I/O forms and reports and details of data capture and entry. Don't copy from your implementation back into the design, it will be obvious what you have done, the screen shots will be identical, and you should show any development of your ideas from design to implementation. You might draw the input forms, moving from rough sketches to careful drawings or prototypes set up in your programming tool. Think first about the outputs from the system and then work through the inputs and processing necessary to achieve them.
The interface design should take the user and I/O devices into account (keyboard, barcode reader, etc.). The interface should include simple and clear dialogues, careful use of colour and informed use of icons and 3D effects. The design should minimise the amount the user has to remember and provide feedback, on-line help and helpful error messages. Exits should be clearly marked. It should seek to avoid errors and handle them appropriately if they occur.
Details of record structure, file organisation and processing and full normalisation (to BCNF) of any database. Use screen shots from Access for table definitions and relationships.
Specification of modules. In Delphi this may be based on the unit/form and the component/object model e.g. your system may have five forms in respective units and within each unit there will be procedures to handle the events associated with each component. You may add procedures and/or functions to implement algorithms or routines not associated with components e.g. calculations. The unit, the form class, class data and class methods provide a natural way to specify design at this level. You should be able to link these closely with the components of the user interface, specifying the design from the input forms and the flow of data through the system established in the Analysis stage.
Full testing is done after code design but you should include an outline in the Design section on your approach to testing. Types of testing include: logical (to test every path in the system); functional testing (to check that all functions and procedures work correctly); system testing (to ensure that the system works correctly) and recovery testing (what happens if you reset the computer when your program is running?); acceptance testing (tested by the user to see if it meets the specified needs).
These must be covered, along with access control to the system. Don't forget about backup routines.
Be sure to finish your design before you start the implementation and avoid feeding information back from the later stages into the design section, it will be evident that you have done this.
References: Heathcote chapter 63, Bradley chapters 14 & 16
Overall system design
You must give a description of the complete system that you are producing for your user.
Description of modular structure of system
Break the proposed system down into appropriate modules and describe what each one does. Remember that you can employ 'module testing' as one of your test strategies (see last section below).
Definition of data requirements (Design data dictionary- from the viewpoint of programmer) including:
Description of record structure
Validation required
File organisation and processing
or
Database design including Normalised E-R Model
Identification of appropriate storage media
Identification of processes & suitable algorithms for data transformation
What does your application do to the data that it takes in? It should do more than just input, store and output, there should be a process in between that requires some sort of algorithm. For a basic solution simple arithmetic will get you some marks. For a more advanced solution there may be more logical processing to be performed on the data as it is transformed from one state to another.
Or class definitions (diagrams) and details of object behaviours and methods
If you happen to be programming in OOP style...
User interface design (HCI) rationale including:
Sample of planned data capture and entry designs (prototype screen dumps may be used but must be annotated as the HCI rationale)
Sample of planned valid output designs
At this stage you design the data capture form for your system, either as drawings or as prototype designs in your application framework, e.g. forms in Delphi. You should not implement the design yet and there will be probably be a distinct difference between the designs here and the final product. A difference here may be an advantage because it will show that you did not copy your the forms from your implementation into the design stage.
Description of measures planned for security and integrity of data
How will you keep the user's data secure and what methods will you employ to make sure that it is of good quality and not susceptible to corruption or loss?
Description of measures planned for system security
A typical solution at this level is to restrict access by a password system.
Overall test strategy
Define a test strategy in technical terms such as 'modular' or 'black box'. Define the data you will use to test under normal, boundary and erroneous situations.
The implementation section consists of an account of your program when you have completed it. This will consist largely of screen shots of the program with a commentary to explain what the images represent. Code listings should be placed in an appendix and description of the algorithms and/or procedures and functions should be set out in the system maintenance section. Code should be annotated in order to demonstrate understanding of what has been produced. For the highest marks you should produce a:
"Well-structured program/suite of programs demonstrating methodologies appropriate to the programming language used."
In the case of Delphi those methodologies would include:
forms and controls to provide the user interface
procedures linked to controls such as menu items and buttons that carry out processing
user-defined procedures that encapsulate processing such as calculations
procedures that use parameters so they can work with a range of data
The type of evidence expected includes the following:
listings of the program(s);
listings of macros;
samples of annotated .design views, showing details of application-generated forms reports, queries; buttons, cross tabulations etc.;
any other reported evidence showing how the implementation was achieved.
The aim of testing is to discover as yet undiscovered errors and to show that the software works as intended. You should have identified your testing strategy during the Design phase of the project. By thinking about testing in this way you will focus on the things that will make your system work successfully.
The test plan should include samples of tests done, including the purpose of the test, the data used and the expected results. Samples of hard copy, annotated and cross-referenced, should prove the correct working of the system. Test results will normally be in the form of file dumps, screen shots and test runs. If using screenshots to illustrate messages include the screen behind, not just the message boxes (you could fake message boxes!).
Identify suitable test strategies and select and document those appropriate to your project: top-down, bottom-up, module testing, black-box, white-box, unit testing, integration testing, system testing, acceptance testing.
The testing should test the system, not just menus or buttons. The test data should be designed to test the limits of the system, not just operation with normal data. Test the most complex and vital aspects of the system rather than showing repeated validation tests on input data. Each test should be numbered, should specify what is to be tested, should provide an explanation of why the test is being performed, should specify the data to be used and give the expected and actual results.
The full set of test results should be put into an appendix in the back of the project. Test results should be cross-referenced to the test plan.
References: Heathcote chapter 63, Bradley chapter 17
A test plan that includes
details of individual tests using a minimal set of test data;
expected results for typical data;
expected results for erroneous data;
expected results boundary (extreme) data;
samples of annotated hard copy of actual test runs for typical, erroneous and extreme data and samples of annotated hard copy showing the system working (system testing);
all samples cross-referenced to the test plan.
This section should include annotated program listings so the source could be understood and modified if necessary. Structures inherent in a programming language such as units, classes, procedures and functions should provide a natural way or organising this. If your code includes sections of SQL then this should be documented as well (state whether you wrote it yourself or got Access to do it).
The documentation should also include a data dictionary, samples of pseudo-code, structure charts and/or flowcharts. This section should provide a technical person with the information required to maintain your software after you have finished it. Describe the limitations of the system and note any outstanding problems or odd test results.
Expected contents for this section of the report:
System overview;
A sample of the detailed algorithms developed by the candidate;
Procedure and variable lists with descriptions for programs and a list of package items developed with descriptions (if a package is used);
All cross-referenced to listings of program code and representative samples of annotated design views. showing details of forms, reports, queries; buttons, cross tabulations etc. that have been tailored by the candidate (if a package is used).
There is no requirement to include automatically generated code or details of items generated by using wizards. An acknowledgement that the item has been used is all that is required.
There should be an introduction, installation instructions, samples of screen displays, including menus, data input forms, sample data and expected output. There should be sample error messages, help screens and recovery procedures. You do not need to document every aspect of the system, just choose one and try to include some menu choices, data entry and report production.
Expected contents for this section of the report, which should read as a self-contained document:
Contents page;
A brief introduction and installation instructions;
Detailed description of how to use one section of the system including:
Samples of actual screen displays in situ;
Samples of error messages and error recovery procedures.
The final section should be an appraisal of your system and whether, in particular, it has met the objectives set out in the Analysis phase. Reflect critically on what you have done and assess how well you have met your aims. Include the real user's comments, if possible, preferably in such a way that they are clearly genuine (e.g. on headed paper). Include suggestions for amendment or improvement, either from you or your user. Be critical of your own efforts but do not blame other people for any shortcomings, especially not the users! If you were over-ambitious say so.
Expected contents for this section of the report:
Comparison of project performance against objectives;
Possible extensions;
User feedback.
Word process the report and set it it out in sections that correspond to the headings in the mark scheme. Use Headings from the Styles list and include a table of contents. Put name, candidate number and school in the footer with page number in the bottom right corner. Refer to appendices where appropriate. Add an index if you fell it helps.
| Background | 17/9/07 |
| Identification of user | 21/9/07 |
| Identification of needs & limitations | 24/9/07 |
| Data sources & destinations | 28/9/07 |
| Data flow diagrams & E-R model | 1/10/07 |
| Analysis data dictionary | 5/10/07 |
| Objectives | 8/10/07 |
| Feasibility of potential solutions | 15/10/07 |
| Justification of chosen solution | 19/10/07 |
| Overall system design | 5/11/07 |
| Modular structure | 5/11/07 |
| Data requirements | 9/11/07 |
| Identification of storage material and format | 9/11/07 |
| Algorithms | 16/11/07 |
| Validation | 19/11/07 |
| User interface | 23/11/07 |
| Sample planned data capture and entry | 26/11/07 |
| Sample planned data validation | 26/11/07 |
| Description of record or database structure | 26/11/07 |
| Sample of planned valid output | 26/12/07 |
| File organisation and processing | 30/11/07 |
| Database design (to 3NF/BCNF) and E-R model | 30/11/07 |
| Security and integrity of data | 3/12/07 |
| System security | 3/12/07 |
| Overall test strategy | 3/12/07 |
| Design of test plan | 25/2/08 |
| Minimal set of test data | 25/2/08 |
| Expected results for typical data | 25/2/08 |
| Expected results for erroneous data | 25/2/08 |
| Expected results for extreme data | 25/2/08 |
| Hard copy of test runs | 21/4/08 |
| Cross-referenced to test plan | 21/4/08 |
System Maintenance
| System overview | 28/4/08 |
| Summary of features of packages used | 28/4/08 |
| Sample of detailed algorithm design | 28/4/08 |
| Annotated program listing | 28/4/08 |
| Procedure and variable lists or package items | 28/4/08 |
| Data dictionary | 28/4/08 |
User Manual
| Brief introduction | 28/4/08 |
| Screen displays | 28/4/08 |
| Error messages | 28/4/08 |
Appraisal
| Were the objectives met (from Analysis)? | 28/4/08 |
| Feedback from user e.g. letter, interview | 28/4/08 |
| Suggestions for further improvement | 28/4/08 |
Quality of Communication
| Contents page | 28/4/08 |
| Clear and logical organisation | 28/4/08 |
| Set out in sections identified in specification | 28/4/08 |
| Page numbers | 28/4/08 |
| Continuous prose | 28/4/08 |
| Good use of English | 28/4/08 |
| Word-processed, clear fonts | 28/4/08 |
| Appropriate word processing techniques | 28/4/08 |