Honours Project Documentation Guidelines

In addition to a working program and its source code, you must also author the documents discussed below to gain full credit for the programming project. The fundamental structure of these documents is entirely independent of project, programming language, and operating system. 
 
You will find a number of advantages when you pursue a rigid documentation approach to programming. First of all, you will have a firm understanding of the task at hand before you start coding. A good understand of the problem leads to a clean design that tends to have fewer bugs. Always make your goal to program it right the first time. The next advantage is that others will be able to use your documentation to test the program, fix bugs, and make enhancements. In the corporate world, these duties are normally performed by different people and often by different groups within a single company. Therefore, the more detailed, organised, and easy-to-read your documentation is, the more you help other people do their jobs. As you learn to write solid documentation, you will also come to appreciate reading solid documentation, and will eventually detest reading technical jargon (the world is full of poorly written technical books and manuals). In other words, write simply and clearly. The way you write is just as important as the details you present. Always strive to spell correctly and use proper grammar. The campus Writing Center can aid you in this respect.
 

• User Requirements Document (URD)
• Requirements Analysis Document (RAD)
• User Interface Specification (UIS)
• The Prototype
• Object Orientated Analysis (OOA) or High Level Design (HLD)
• Object Orientated Design (OOD) or Low Level Design (LLD)
• Code Document
• Testing Document (TD)
• User Guide

 

Description of the four Presentations

First presentation: four minute talk + four minute questions and answers (Q&A)
Describe your project: its requirements and your analysis. This presentation should have a maximum of four to five. Remember, you are talking for only five minutes. The slides should be keyword or bullet-based. You may also use diagrams or pictures. Your slides must be on your website. If you don’t have a website yet, contact our webmaster ASAP.
 
Second presentation five minute talk + five minute prototype demo + five minute Q&A
Give a brief introduction to your project to remind us of what it’s all about. The major thrust of this talk is on the OOA/HLD and OOD/LLD. You should talk to diagrams of the HLD and LLD. Particular emphasis should be given to the OOA/HLD in terms of class and object definitions and their relationships to one another. Flow charts are not enough. Logical systems should be broken down into constituent parts and explained in terms of objects. You should also include a prototype demo. With a GUI-oriented project, the prototype is usually a skeleton. The prototype will vary from project to project.
 
Third Presentation five minute talk + five minute demo + five minute Q&A
Give a brief introduction to your project to remind us of what it’s all about. The third term mostly concerns implementation, therefore the third talk should discuss your implementation. Also explain the design decisions you had to make and explain why you made them. Discuss the changes you had to make to your UIS, OOA, and OOD based on your experiences doing the coding. Explain how you organised your code, and your approach to implementation overall. This is a good time to also list the tools and languages that you used. You must also give a demo, similar to the last talk, but it should not be a prototype anymore: it should work.
 
Final Presentation five minute talk + five minute demo + five minute Q&A
Give a brief introduction to your project to remind us of what it’s all about. This presentation must cover the entire spectrum of the project. Walk us through the entire project, from requirements, analysis, interface, design, implementation, but spend roughly half of the talk discussing the test issues and results. You may also want to show what your User’s Guide looks like, but please don’t read it out. Give a demo of the final product.
 

How Your Presentation is Marked

• Delivery [10] refers to the use and abuse of communication and spoken skills: body language, gestures, spoken language, word choice, how you handle yourself in front of an audience, etc.
• Content [10] refers to the arrangement and the content of the presentation: quality and correctness of data, how topics progress from one slide to the next, etc.
• Audiovisuals [10] refers to having the slides on a website, in bullets, nicely presented, fonts and colours easy on the eye, demonstrations, etc.
• Timing [10] is how you give the presentation with respect to time: amount of time per slide, right number of slides, balance of information per slide, etc.
• Q&A [10] refers to how well you answer questions from the audience: how you demonstrate knowledge over the material, your ability to handle criticism and come back with valid answers, etc.

Project Planning and Meetings

Each term, you must define a project plan that includes the specific tasks of your project, and the dates by which you intend to accomplish them. Everyone’s project plan will include dates for the submission of project documents, weekly meetings, monthly reports, and the presentation. However, the most important items on the project plan will relate specifically to the technical issues of your project. The project plan should be continually updated. 

Essentially, the project plan maps out a schedule for each term, and should be updated as you work ahead or fall behind the schedule, or discover things that you need to do along the way. If you organise your project plan well, by the end of each month, you will have a summary of what you have accomplished for the month. 

For CoE students, the monthly report must be clearly identified on a webpage devoted to the project. You are required to meet with your project supervisor on a weekly basis to discuss the progress and problems related to your project. The format, length and content of the meetings will vary from supervisor to supervisor, and even student to student, but the overall objectives are to inform your supervisor of your progress and also to get advice on how to go about defining and prioritising the activities required to complete each module’s objectives. If you miss three of these meetings, you will not be allowed to pass the module. 
 

Project Marks

To prevent you from coding or performing your project two weeks before it is due (at the end of the fourth term), you will be continually assessed on your progress. Your weekly meetings with your supervisor are included in the marking schedule. That means you get marks just for attending those meetings. Take advantage of those meetings because they set the tone for your entire project. You must meet weekly with your supervisor to make sure you stay on track. If you miss three meetings with your supervisor per term, you may not pass a project module. The project’s marks are broken into marks for the four modules.
 
The marks for a term consist of the following:

• 50% module requirements
• 20% project plan/ monthly report 
• 20% Presentation
• 10% Weekly attendance with supervisor
• 100% Total

 

Here is an interpretation of marks

85% and over: A truly outstanding distinction: demonstrating advanced levels of understanding, originality and analysis or research (theoretically and/or empirically) over and above that required for other distinction categories below. Worthy of publication as is.
80 – 85: A strong distinction without reservations: authoritative coverage of relevant material as well as background literature and/or related issues; outstanding presentation in terms of argument, organisation, originality and style. Demonstrates full understanding of subject matter and at most minor typographical corrections required.
75 – 79: Merits distinction though with some reservations: a more than competent presentation with good organisation and sound critical arguments. Evidence of originality / clear insight / solid depth of understanding. Some minor omissions and / or corrections required.
70 – 74: Does not merit a distinction, but there is evidence of some originality and flair. The substantive part of the work is competently covered, well organised and lucidly argued. There are omissions or areas where revisions would improve the work.
60 – 69: Solidly executed, adequate organisation, competent methodology and conclusions adequately drawn. Very little originality, if any, but an adequate overall performance. May require some minor revisions.
50 – 59: No originality, a pedestrian, albeit competent, review of the literature, a basic understanding of the significance of the issue discussed, and a fairly competent methodology. There may be problems of organisation and expression, of layout and typographical errors, but the work exhibits the main features of academic work sufficiently to pass. Some major revisions may be required.
49 and less:  The work is clearly not adequate. It exhibits such a level of disorganisation and incoherence as to be termed incompetent. The work fails to demonstrate familiarity with basic academic conventions of presentation and organisation. A failing mark indicates that it clearly does not pass in its present form, but if re-worked substantially and re-submitted it may be brought into a pass worthy form.