Analysis

The Analysis section of the project is worth 12 marks out of a total 75.

You need to include:

• Identification of the problem - Why does the current system not work?
• Description of the current system - This may be a computer system or a manual system
• Identification of the prospective users - who are they? What is their link to the problem?
• Identification of user needs and acceptable limitations - What does the user need you to provide? Are you able to provide all of these things? If a task is too complex can you agree a compromise with your user?
• Data Sources and Destinations - Where will you get the input from your program and how will you give the output to the user? For example you could output to file, send it to a server or display to screen.
• Data Volumes - How will data be stored within the program?
• Analysis Data Dictionary - What sort of data will you be dealing with? What format will it take?
• Data Flow Diagrams (DFD's) - For both the existing system if there is one as well as the system you are proposing to introduce.
• Entity Relationship Diagrams - If you are using Databases you need to show Entity Relationship diagrams, they don't have to be too in detail - save that for the design section - but you need to show that you have thought about how the Database world work.
• Object Analysis Diagrams - What classes will you be defining in your project. Will they inherit from other classes? What functions might they have/need?
• Numbered general and specific objectives of the project - this is very important as you will need to return to these later in the project to evaluate how you have done!
• Present a selection of possible solutions - not all of these have to be involving a computer, you could present a manual solution.
• Justification of Chosen Solution - What reasons have you for going with your chosen solution? More importantly why haven't you gone with one of the other solutions that you presented?
• Evidence of appropriate analysis techniques. - Interviewing staff, examining the existing paperwork, documents and data, using a questionnaire or observation of the current system, to name just a few examples.

Worksheet Analysis of Interview.doc
Worksheet Analysis Scenario.doc
Worksheet Creating DFD.doc
Analysis Example.docx
Info_sheet_Analysis_guidelines.doc

Design

The design section follows on logically from the Analysis and is worth a further 12 Marks.  Don't be tempted to jump straight into writing the program without doing the design section first. It pays to think the problem through and carefully decide how you are going approach it. Completing the complete design process can often save you from making a task too complicated and save you time in the long run.

In the write up of your design process you need to include:

• Description of the Modular system - Your program should be a size that modules are necessary as good programming practice. You need to describe how the modules will fit together and what will be in which module.
• Data Design Dictionary - The data requirements of your project, what data you will have, how it will stored within the program and where it will come from.
• Description of the record structure - If you are using a database within your project you need to talk about how records will be stored across tables, what the primary keys and foreign keys will be and what method of record standardisation you are using (think normal forms)
• Validation - How will you make sure that the data has been entered has been correct. Does some input need to be numbers for it to work?
• File Organisation - How will the files within your program be stored, if you are working with a database this would include database design and relations across tables.
• Sample of Planned SQL queries (if you are using Databases)
• Identification of Storage media - this may be flash memory, Hard Disk or cloud storage
• Algorithms - You need to talk about the algorithms you are going to use on your data.Are there any known algorithms that you are going to use (for sorting or searching etc) pseudo code for any algorithms that you are designing yourselves.(If you are using a known algorithm eg. Binary Search, within one of your algorithms you can assume that the reader knows and understands how Binary Search works.
• Class Definition Diagrams - What properties and methods are in the class.
• User Interface Design (HCI) - You need to be able to justify why you have chosen your interface, this might be to keep in accordance with other programs available (iPhone) or it could be to make it stand out. It might be a good idea to link this back to the User.
• User interface sample of data entry - a sketch or photoshop mockup of what you want the data input screen(s) to look like.
• User Interface sample output - How will data be outputted to the user? Sketch this.
• Security and Integrity of data - How are you going to keep the data secure? Are you working with sensitive data (eg. contact details)? How are you going to make sure data is still valid after it has been stored.
• System Security - How are you going to keep your program secure, is there an admin side?
• Test Strategy - You need to outline how you intend to test your program, the A2 textbook is your best resource for this.

Class Diagrams

Class Diagrams should be written to Unified Modelling Language (UML) specifications. You need to show what each class contains, and the methods within that class, what those methods return and what parameters are required for those methods. There is a great free online tool for drawing these diagrams that does everything you need. You can sign in with your school account providing you have signed up for GoogleDocs through the MyHighcliffe.

http://www.genmymodel.com/

Data Flow Diagrams - Introduction.ppt
Worksheet Design Guidelines.doc
Worksheet Example Design.doc
Writing Algorithms Notes.pdf

Implementation

You should attach a complete printout of your program code to the project that you hand in. It needs to be easy to read (line spacing and indentation) and well commented so that the examiner can understand what the code does and more importantly he can see that you understand how your code works, proving that you haven't just copied it all off github!   

Testing

Testing.ppt

Testing.docx

Systems Maintenance and User Manual

This section is split into two, System Maintenance, information for a programmer looking at your program, and User Manual, information for someone, possibly without much knowledge of computers, who just wants to use your program.

System Maintenance

The System Maintenance section of yur report should be aimed at people with a similar programming knowledge to yourself. You should discuss:
A General overview of the program, how it works what code is where, and where it gets it data from
Explain the algorithms - this can be in paragraph form rather than pseudo code, keep it vague, we just need to understand how the program works, we don't need to see it
A list of Procedures and what they do
A list of Global Variables and what they do
An excerpt of code with annotations

User Manual

The User manual section of your report should be aimed at users of the program who don't need to know how it works, they just want to use it. You should include:

• A Brief introduction (1 Paragraph) stating what the program does.
• Installation Instructions
• Detailed description of how to use every feature
• Some Screen shots of real situations
• Sample Error Messages and what to do in case of that errors

In this section you are also marked on your 'Quality of Written communication. This means you need to make sure that the tone of the document is correct, that Grammar and Spelling is all correct and the document is laid out in an easy to read professional manner.

You might want to consider making the User Manual as a stand alone document and attaching it to your project as an Appendix.

Evaluation

In your project evaluation you must include:

Comparison the project performance to the objectives you set out at the beginning. 

• Have you met all of the specifications?
• If you did not meet some of the specifications, why not?
• Did any of your specifications change over time? Explain this.

User Feedback

• This should be authenticated by Mr Downs

Analysis of User Feedback

• Comment on valid points you think that have been raised by the user.
• What would you change if you had more time based on what the user has told you?
• Highlight something that you did not notice because you are not the user
• Is there anything you should have tested more thoroughly?

Possible Extensions

• Discuss at least two possible extensions to your project.
• Why would these be good extensions?

The evaluation of the project is worth 6 marks and is an easy six marks to get providing you follow the guidlines above!