S. Mataga; +263 773 506 057; matagas@gmail.com; +263 4 790 988/84 mataga@trustacademy.co.

zw

office 403, fourth floor north wing 40 Livingstone Ave 1

Projects Guidelines
Objectives
The project an important piece of work in the programme. It provides the opportunity for students to demonstrate independence and originality, to plan and organise a large project over a long period, and to put into practice some of the techniques that would have been taught throughout the course.

Assessment
It is important when choosing a project to understand the way it will be assessed. A good firstclass project involves a combination of sound background research, a solid implementation, or piece of theoretical work, and a thorough evaluation of the project's output in both absolute and relative terms. A good tip is to try to think of the project as an "investigation", rather than an effort to deliver a fully-functioning "product". Proper evaluation of the project is thus crucial to achieving high marks (see below). The very best projects invariably cover some new ground, e.g. by developing a complex application which does not already exist, or by enhancing some existing application or method to improve its functionality, performance etc. A straightforward implementation project is acceptable, but you must appreciate that it is unlikely to gain high marks, regardless of how well it is done. Likewise, projects which are predominantly survey reports, unless they are backed up with experimentation, implementation, or theoretical analysis, e.g. for performing an objective comparison of surveyed methods, techniques etc. Pure survey reports, with no supporting implementation or theory, are not acceptable.

Meeting Your Supervisor

You must make sure that you arrange regular meetings with your supervisor. The meetings may be brief once your project is under way but your supervisor needs to know that your work is progressing. You should inform the supervisor of your college address and any changes to it, so that they can contact you, if necessary. If you need to talk to your supervisor between meetings and cannot locate him/her in their office, leave a note, or send mail, asking them to suggest a time when they will be available. When you go to see your supervisor (or second marker) you should have prepared a written list of points you wish to discuss. Take notes during the meeting so that you do not forget the advice you were given or the conclusions that were reached.

The Project Report

The project report is an extremely important aspect of the project. It serves to show what you have achieved and should demonstrate that:

S. Mataga; +263 773 506 057; matagas@gmail.com; +263 4 790 988/84 mataga@trustacademy.co.zw

office 403, fourth floor north wing 40 Livingstone Ave 2

You understand the wider context of computing by relating your choice of project, and the approach you take, to existing products or research. You can apply the theoretical and practical techniques taught in the course to the problem you are addressing and that you understand their relevance to the wider world of computing. You are capable of objectively criticising your own work and making constructive suggestions for improvements or further work based on your experiences so far. As a computing professional, you can explain your thinking and working processes clearly and concisely to third parties who may not be experts in the field in which you are working.

Most of the project assessors will not have followed the project throughout and will only have a short time to listen to a presentation or see a demonstration. For this reason they will rely heavily on the report to judge the project. You should appreciate that the external examiners, who play a crucial role in the final recommendation, have only the report by which to judge your project performance. Many students underestimate the importance of the report and make the mistake of thinking that top marks can be achieved simply for producing a good product. This is fundamentally not the case and many projects have been graded well below their potential because of an indifferent or poor write-up. In order to get the balance right you should consider that the aim of the project is to produce a good report and that software, hardware, theory etc. that you developed during the project are merely a means to this end. Don't make the mistake of leaving the write-up to the last minute. Ideally you should produce the bulk of the report as you go along and use the last week or two to bring it together into a coherent document. The physical layout and formatting of the report is also important, and yet is very often neglected. A tidy, well laid out and consistently formatted document makes for easier reading and is suggestive of a careful and professional attitude towards its preparation. Remember that quantity does not automatically guarantee quality. A 150 page report is not twice as good as a 75-page one, nor a 10,000 line implementation twice as good as a 5,000 line one. Conciseness, clarity and elegance are invaluable qualities in report writing, just as they are in programming, and will be rewarded appropriately. It is important to appreciate that the appropriate size and structure of a report can vary significantly from one project to the next. Try to ensure that your report contains the following elements (the exact structure, chapter titles etc. is up to you): Title page This should include the project title and the name and student ID of the author of the report. You should also list the name of your supervisor, institute and year of publication. Abstract The abstract is a very brief summary of the report's contents. It should be about half a page long. Somebody unfamiliar with your project should have a good idea of what it's about having read the abstract alone and will know whether it will be of interest to them. Its written using single spacing and usually is one paragraph. Acknowledgements It is usual to thank those individuals who have provided particularly

S. Mataga; +263 773 506 057; matagas@gmail.com; +263 4 790 988/84 mataga@trustacademy.co.zw

office 403, fourth floor north wing 40 Livingstone Ave 3

useful assistance, technical or otherwise, during your project. Your supervisor will obviously be pleased to be acknowledged as he or she will have invested quite a lot of time overseeing your progress, and do not forget the institutes. Contents page This should list the main chapters and (sub) sections of your report. Choose self-explanatory chapter and section titles and use one and half spacing for clarity. You should include page numbers indicating where each chapter/section begins. Try to avoid too many levels of subheading. Try if possible to stick to sections and subsections; sub-subsections are usually avoidable. Introduction This is one of the most important components of the report. It should begin with a clear statement of what the project is about so that the nature and scope of the project can be understood by a layman reader. It should summarise everything you set out to achieve, provide a clear summary of the project's background, relevance and main contributions. The introduction should set the scene for the project and should provide the reader with a summary of the key things to look out for in the remainder of the report. When detailing the contributions it is helpful to provide pointers to the section(s) of the report that provide the relevant technical details. The introduction itself should be largely non-technical. It is sometimes useful to state the main objectives of the project as part of the introduction. However, avoid the temptation to list low-level objectives one after another in the introduction and then later, in the evaluation section (see below), say something like "All the objectives of the project have been met blah blah...". A project that meets all its objectives is, by definition, weak and unambitious. Concentrate instead on the big issues, e.g. the main questions (scientific or otherwise) that the project sets out to answer.

Project outline
N.B: All level 2.2s and 4.2s Project Documents must follow the format below: 2.2s go as far as chapter 4 only Cover Page Abstract Acknowledgements Dedication Table of contents List of Acronyms List of tables List of figures List of Appendices NB. Each of the topics above must have a different page (i.e. must start on a new page) and must be paginated using Roman Numerals except for the COVER PAGE

Chapter 1: Project Proposal

1.0 Introduction (introduce your topic) 1.1 Background Study

S. Mataga; +263 773 506 057; matagas@gmail.com; +263 4 790 988/84 mataga@trustacademy.co.zw

office 403, fourth floor north wing 40 Livingstone Ave 4

1.1.1 Background of Organisation 1.1.2 Organisational Structure 1.1.3 Vision 1.1.4 Mission Statement) 1.2 Problem definition 1.3 Aim 1.4 Objectives (* Note that objectives must be S.M.A.R.T) 1.5 Hypothesis 1.6 Justification 1.8 Conclusion

Chapter 2: Planning phase

2.0 Introduction 2.1 Why build the system 2.2 Identify business value 2.3 Analyze feasibility 2.3.1Technical 2.3.2 Economic 2.3.3 Social 2.3.4 Operational Feasibility 2.4 Develop work plan 2.6 Conclusion

Chapter 3: Analysis phase

3.0 Introduction 3.1 Information gathering methodologies 3.2 Analysis of existing system Description of current system Process analysis Activity Diagram of current system Data Analysis Context Diagrams and DFDs Weaknesses of current system 3.3 Evaluate Alternatives (Refer to Feasibility Analysis) Outsource Improvement Development Recommend one for this system (Why, justify in terms of costs from others etc) 3.4 Analysis of the proposed system Description of proposed system Process analysis Activity Diagram for proposed system Data Analysis Context Diagrams and DFDs Weaknesses of proposed system 3.5 Requirements Analysis

S. Mataga; +263 773 506 057; matagas@gmail.com; +263 4 790 988/84 mataga@trustacademy.co.zw

office 403, fourth floor north wing 40 Livingstone Ave 5

Functional Requirements (Use Case diagram Non-functional requirements 3.6 Outline constraints 3.7 Conclusion

Chapter 4: Design phase

4.0 Introduction 4.1 System Design (How will the system work?) May use Flow charts 4.2 Architectural design 4.3 Physical design How software and hardware interact 4.4 Database design (ER or Tables and EER diagram) 4.5 Program design (Package and class, collaboration or sequence diagram) 4.6 Interface design 4.7 Test Data Design 4.8 Security Design 4.9 Backup Design 4.10 Conclusion

Chapter 5: Implementation phase

5.0 Introduction 5.1 Coding (Pseudo Code) 5.2 Testing and Test strategies used Detailed system testing including screen shots of tests and test results for each test carried out 5.3 Validation and Verification 5.4 Conversion methods and their evaluation, conversion method to be used 5.5 Conclusion

Chapter 6: Maintenance and Security

6.0 Introduction 6.1 Software Security 6.2 Observations, Recommendations and conclusions 6.3 Conclusion

Bibliography (Harvard Referencing Style and arrange in alphabetic order)

E.g. Surname, Initial. (Year of publication), Title of Book or Journal, publishing hall, country of publication Note that if you are referencing a site you need to state exactly the document accessed and the date you accessed the document E.g. http://www.tkn.tu-berlin/research/QoS.html Accessed 20/01/2011.

S. Mataga; +263 773 506 057; matagas@gmail.com; +263 4 790 988/84 mataga@trustacademy.co.zw

office 403, fourth floor north wing 40 Livingstone Ave 6

Wikipedia is not an academic website so dont include inf ormation from that site, educational sites have an extension .edu, ac , etc eg http://nile.wpi.edu

Appendices
Appendix A : User manual Evidence of research Appendix B : interview checklist Appendix C : Questionnaire checklist Appendix D : observation score sheet Appendix E : etc. Appendix F : Snippet of Code

Final Stage
Documentation Binding Oral presentation (30%)

**************************VERY IMPORTANT*************************** There are two ways that you can use to present your minor headings 1) Bold ONLY 2) Underline ONLY A graduate is supposed to choose ONE way of presenting minor heading. The style must be consistent throughout the documentation. Each Major heading MUST start on a fresh page and must be BOLD Each and every table, diagram, graph, chart etc MUST be numbered. The numbering must depend with the Chapter in which the item is in Eg diagram in Chapter 1 can be numbered as Figure 1.1: Organogram. Note that the First 1 denotes the chapter in which the diagram falls under and the Last 1 tells us about the position of the diagram in the chapter, so literally Figure 1.1 means the figure is in Chapter 1 and its diagram number 1. This means that the next diagram must have a .2 suffix, thus Figure 1.2. Note that minor headings are those headings that are not bold and the major headings are in bold from the guidelines above. Each and every topic, subtopic must be numbered. MAIN Headings should be of font size 14 and MINOR headings of font size 12. E.g

Chapter 4: Design Phase (16)

Introduction (14)

**************GOOD LUCK************