King Khalid University College of Computer Science

Project Documentation Guidelines Computer Science and Information Systems Departments

Project Documentation Guidelines Computer Science and Information Systems Departments

The purpose of this document is to guide the students on the final year project Levels 9 and 10 The project is an extended piece of individual work. Students will work on their projects, and will have to have regular meetings with the supervisor to discuss project work progress. Students are asked to write and submit a formal report (documentation) in a structured way along the suggested guidelines. It should demonstrate that the relevant work has been carried out at a workplace under proper supervision. It is the project supervisor responsibility to receive the projects materials and documentation from the project team and to assure meeting the specifications mentioned below.

1. Project Objectives
The project will develop student's ability to: Initiate a project from ideas, thorough an analysis of the problem; Plan, schedule, monitor and control work; Work in teams; Enhance communication skills Time management; Defend ideas in discussions and presentations; Use references; Apply theories, tools and techniques from taught courses; Present the findings; Formal report writing.

2. Project Supervisor
A student or a group of students should have a project supervisor. The supervisor should be able to guide the students throughout the project. The supervisor should have appropriate knowledge in the application area and be a PhD holder.. It is a requirement that the student regularly meets the project supervisor during the semester(s). Project students should work independently but report the progress and seek guidance from the supervisor to ensure the correctness of the approaches. The students should agree on a timetable with information about methods of contact with the supervisor at the start of the project. Typically, students should expect to meet with the supervisor for about an hour per week. Some supervisors would want to meet the students more often than this, especially at the start of the project and at the writing stage. If the supervisor requests, the students would also have to regularly submit short progress reports on the project work prior to the meeting (usually by email).

3. Project Management, Report Writing And Presentation / Demonstration

3.1.

Project Management

Students should demonstrate the ability to work independently and meet all deadlines comfortably. The following guidelines are intended to assist with the writing of the project documentation and the presentation/demonstration. An outline of some important set of objective criteria is given to enable students to ensure that their project conforms to the required standard. There will be no evaluation and no grade for projects that does not meet the below standards. The project supervisor is responsible for assuring that the documentation meets the standards. A project supervisor should not accept any project that does not meet the specifications below.

3.2.

Format of the Project Documentation

The project documentation is a formal document and the structure and the general content requirements are described later on in this document. This includes advice on how to organize the work into chapters, what should be covered in the main body of the work and what should go in the Appendices. Students are strongly advised, while writing is in progress, to show each chapter to their supervisors for necessary feedback especially on technical content. As for style and grammar, please follow the instructions given below to minimize correction time: (a) The documentation text (defined as everything except title page, tables of contents, bibliography and appendices) should not normally exceed 60 printed on size A4 white pages. (b) The documentation text should use Times New Roman 12-point type and 1.5 line spacing. A typeface less than 10 points should not be used under any circumstances. Use single-sided printing. Left margin is 37mm (to allow for binding), right, top, and bottom margins are 25mm. (c) Chapter heading 14pt bold UPPERCASE, Section headings UPPERCASE 14pt Normal , sub-section heading title 13pt bold, sub sub-section (level 3) heading title 12pt bold. (d) The total length (Project Documentation text together with appendices) of the Project Documentation should not exceed 120 pages (White Clean A4 Papers Weight 70 80 gm) except under unusual circumstances. (e) All pages should be numbered with chapter 1 beginning on page 1 (Center-Bottom) . Use roman letters (Center-Bottom) for pages before that ( acknowledgement, Dedication, Abstract, content, appendices, and table/figures index. (f) Report writing style should use passive form. It is considered very bad style in a formal report to make explicit references to what the candidate himself/herself did, as in I decided. Scientific papers never use the first person in this way. The passive form as in it was decided is strongly preferred. (g) Plagiarism is the presentation of another persons thoughts or words as though they were students own. Students should avoid this when writing their documentations. All sentences or passages quoted in their report from other peoples work have to be specially acknowledged by clear cross-referencing to author, work and page(s). Direct quotations from published or unpublished work of others should always be clearly identified as such by being placed inside quotation marks, and full reference to their source should be provided in the proper form. Equally, if another persons ideas or judgments are summarized, the student should refer to that person in the main text of 3

the Project Documentation, and include the work referred to in the bibliography. Failure to observe these rules may result in an allegation of cheating. Any illustrations, which are not the work of the author (i.e. the student) of his Project Documentation can be used only with the explicit permission of the originator and should be specially acknowledged. The project is an important component of the degree and plagiarism in project work is taken very seriously. A student will fail the project and the degree examination as a whole when plagiarism in project work is discovered. Therefore, it is important to give credit where it is due and acknowledge all work borrowed.

3.3.

Contents of the Project Documentation

The documentation should be divided into a series of numbered chapters and sections, each with titles. It consists of preface material, main chapters and appendices. A possible layout might be as follows: 1. Title page: This comprises the title of your Project Documentation, your name, Student no, index no, the name(s) of the supervisor(s), the date of submission (Month and Year), and the following statement: This Project Documentation is submitted in partial fulfillment for the requirement for the Degree of B.Sc. in ( Computer Science / Information Systems ) at King Khalid University The following page shows an example showing how to organize the title page:

25mm

25mm

KING KHALID UNIVERSITY COLLEGE OF COMPUTER SCEINCE

14, Times New Roman, UPPERCASE

PROJECT TITLE
Font size: 22pt, Bold, Times new roman UPPER CASE

By Student Name, 42xxxxxxx Student Name, 42xxxxxxx Student Name, 42xxxxxxx 14pt, Bold, Times New Roman, Sentence case

Supervised by: Prof Name (Academic Position) 14pt, Bold, Times New Roman, Sentence case

This Project Documentation is submitted in partial fulfillment for the requirement for the Degree of B.Sc. in ( Computer Science / Information Systems )
14pt Bold, Times New Roman, Sentence Case

Month / 20.. Month / 14..

2. Committee Report Page : This is to certify that the project team has submitted their work on time and that the Committee have reviewed the content and evaluated the work. The following is a committee report page example:

COMMITTEE REPORT We certify that we have read this graduation project report as examining committee, examined the student in its content and that in our opinion it is adequate as a project document for B.Sc. in Computer Science. Supervisor: Name: . . . . . . . Examiner1: Name: . . . . . . . . Examiner2: Name: . . . . . . . Signature . . . . . Date: / /

Signature . . . . . . Signature . . . . . . .Date: / / Date: / /

3. Dedication ( Optional) : This is where students dedicate their work to somebody(s). 4. Acknowledgements: It is mandatory that a candidate thanks whoever has helped the candidate. Acknowledgements should be brief and to the point. Should not exceed a page, preferably a paragraph or two. Client certificate should follow this page.

Acknowledgment The authors would like to extend their thanks and gratitude to their supervisor Dr. XXXX for continuous guidance and encouragement throughout the project. The supporting efforts and information availability arranged by the National Industrial Company is highly acknowledged. Thanks are also due to the Computer Center staff for their help in the programming techniques.

5. Abstract: The abstract should encourage the reader to find out more, and has to identify the main technical aspects and distinguishing characteristics of the project. The abstract should provide a clear statement of what the project is about, the scope of the work, a summary of the most important features/results set out in the Project Documentation and its relevance to the goals of the project. Should not exceed a page (150 words) . 6. Contents: Provides page numbers of all sections (up to 3 levels, e.g. 3.4.1), tables and figures. Chapter 1 begins on page 1. Use roman numerals for all previous pages (e.g. title page, abstract, acknowledgements, etc.). The overall structure should show a clear progression of logical thought. The structure of the Project Documentation should be seen to match the summary provided in the abstract.

Example:

Contents
Page Abstract. . . . . . . . . . . . . . . . . . . ...i Dedication . . . . . . . . . . . . . . . . . . .ii Acknowledgement . . . . . . . . . . . . iii Table of Contents. . . . . . . . ... . . . . . . iv List of Figures. . . . . . . . . . . . . . v List of Tables. . . . . . . . . . . ... . . . . vi List of Symbols. . . . . . . . . ... . . . . vii Chapter One: Introduction 1.1 historical summary. . . . .. . . . . . . 1 1.2 security system. . . . . ... . . .. . 3 1.2.1 secret key security. . .. . . . . . . . . 5 1.2.2 Public key security. . . . . . . . . 8 Chapter Two: The Functional Behaviour Public Key System 2.1 Introduction. . . . . . . . . . . . . . 14 2.2 the key generation algorithm . . . . . 16 Chapter Three: Results and Discussions . .. . 35 . Chapter Four: Conclusion and Recommendation For Future Work.. . . . . . . . . .55 . References. . . . . . . . . . . . . . . 65 Appendicies Appendix A. . . . . . . . .. . . . . . .72 Appendix B. . . . . . . . . ... . . . . . 85 Abstract (in Arabic). . . . . .. . . . 95

7. List of Acronyms Abbreviations and Symbols : Provide all abbreviations used in the Project Documentation in alphabetical order with their expected versions. 8. Main Chapters: a. Chapter One: INTRODUCTION: Provides a general introduction to the project with a clear description of the objectives. Initially, the case for the need for this project should be well argued. The subject area concerned is explained next, to provide the motivation for reading this Project Documentation. A detailed specification of the project (problem statement/specification) free of ambiguity should be provided. Clear and appropriate aims and objectives for the project are identified here. User and system requirements for the project are also provided. The basic findings of the project are summarized in one or two paragraphs. Finally, introduce the structure of the Project Documentation (what will be covered in the remaining chapters). b. Chapter Two: ANALYSIS AND DESIGN: main body of Project Documentation is described here. The structure of the main chapters would depend on the nature of the project. A design & implementation project should include chapters on the various phases of the development process. It is suggested that the mode of

testing or validation of software be considered at both the specification and the design stages so that program design and possible testing strategies are developed together. In the design chapter, it is often a good idea to start by discussing why the candidate chose a particular design technique from among several which may be available, before giving an overview of the selected design (using a diagram) and then proceeding to details. In experimental and theoretical projects, the design of the experiments/theories and the analysis of the results should be given appropriate consideration. Sound foundation with own interpretation and synthesis of existing work should be provided with suitable examples discussed throughout. What the reader should know in order to understand the report is provided here. A review of relevant work by other authors and the relationship between this and the project work should form the main thrust of this chapter. If several other people have done closely related work in a different way, then the reasons for the selected approach should be summarized here. Projects which use computational techniques (for example neural networks, genetic algorithms, simulations etc) to explore or extend the properties of a mathematical model or to make predictions of some kind may have separate chapters to cover the computational techniques themselves and the area of application. The structure of the overall intended system should be clear from the design documentation. There should be evidence of a structured methodical approach to the design of the system. All significant design decisions and any necessary trade-offs should be explained. The selection of appropriate algorithms, data structures, etc. should be documented. There should be evidence of some understanding of appropriate background theory, (e.g. equations, algorithms, etc) appropriate to the problem domain. Use data flow, entity relationship and object diagrams as appropriate. Number all diagrams and refer to them in the Project Documentation text. c. CHAPTER Three: IMPLEMENTATION: All aspects of the system should be identified as working correctly (see testing below). All major code and module structures (most important and interesting aspects) should be comprehensively explained. Appropriate appendices containing technical documentation should be included. The implemented environment (hardware and software), any reusable code and development tools used, platform independence and how the system was verified must be discussed. These sections might be included: User Interfaces: Design and implementation projects should provide all aspects of user interface demonstrating evidence of thorough understanding of user needs and requirements. It is essential to indicate how these are integrated in the design. Testing: The test plan should be thorough and comprehensive. It has to be used to generate a wide range of test data. Evidence should be produced to show that all aspects of the system have been tested and specification has been met. Include actual test results in the appendices.

d. Chapter Four: EVALUATION and RECOMMENDATIONS: Critical discussion and assessment of results of project is provided here. This chapter should critically discuss the results of the project, and whether the objectives were satisfied and if not, the reasons for them. It is important that any failures to achieve given objectives should be discussed and analyzed. This does not mean that the candidate will be penalized. Include a valid and comprehensive critical appraisal covering all aspects and stages of the project. Lessons learnt during the course of the project are expanded upon. Suggestions for future work are outlined. The appraisal should identify any deficiencies in the final product, and highlights how improvements could be made. The appraisal includes a review of the original project plan and any deviations from it. The types of experiments/simulations that were carried out may be discussed for experimental projects. Reasons for why they were carried out and not others should also be stated. Important parameters in the simulation and their impact on the results may be discussed. Graphs and tables may be associated in presenting such results. e. Chapter Five: CONCLUSION: This chapter presents conclusions, further work and a summary of what was achieved. A critical appraisal of the candidates own work should be included. Discuss the realization of the original objectives/goals and how the work can be taken further (perhaps by another candidate next year). This can be a fairly short chapter of 2 to 3 pages. The chapter brings together many of the points mentioned in other chapters, especially in the previous (results and evaluation) chapter. Some of the earlier statements may be repeated here. Problems beyond the control of the candidate (e.g. obtaining necessary hardware/software) that have affected the progress of the work may be mentioned here. However, avoid laboring these points too strongly, as this may sound too much as if the candidate is seeking excuses for poor results, and may leave the reader with a negative impression of the work. Be positive and upbeat, even if the candidate feels that he or she has had a tough time.

f. REFERENCES: It is very important to acknowledge any of the work of others that the candidate used or adapted in the project, or that provides the essential background or context to the Project Documentation. Include web links too. In the bibliography, each citation would be listed in the relevant format in alphabetical order of the main author. Examples:
References [1] Caudill, M., Neural Network Primer; Part I, AI Expert, Vol 2, No. 12, (1998. [2] Chltra, S., Use NeuralNetworks for Problem Solving, Chemical Engineering Progress, (1993), PP 44-48. [3] Mahmmod, M.A.B., An Equivalent Model As Medium Scale Neocognitron-like Brain Model, M.Sc. Thesis, University of Basrah, Iraq, (1999). [4] Summers, R. C., Secure Computing, Threats and Safeguards, McGraw-Hill, (1997). [5] Wasserman, P., Neural Computing: Theory and Practice, Van Nostrand Teinhold International Company Limited,(1989).

10

g. APPENDICESE: May include further details of results, mathematical derivations, certain illustrative parts (e.g. class interfaces) of program code, user documentation and log of project milestones. 1. System documentation: Technical documentation is included here. These details should guide candidates who wish to continue or use the candidates project work and allow amendments and extensions to the code. Provide program installation, compilation and execution details. Documentation should point to locations where DLLs and reusable code can be found, if they are publicly available. 2. User documentation: May include a through and comprehensive documentation at a level, which is appropriate to the identified users. User documentation may cover all aspects of the system, with appropriate screen shots. 3. Extra tests and simulation results. 4. Code listing: All code should be well structured, readable and should contain appropriate comments. If there is a great deal of code, and including all of it would exceed the page limit, the candidate should include only an overview of his or her code listing in the Project Documentation and refer to the CD-ROM. 5. Any other necessary documents.

4. Submission of Project Documentation for Evaluation

Projects should conform to the specifications given in above.

4.1.

Project One Report Submission:

Students of project one (level 9) are required to submit six copies (bound with black/blue spiral) of their project documentation including Title page, Abstract, Acknowledgement, Table of contents, Table of Figures, Table Symbols/Abbreviations, Chapter One :Introduction, Chapter Two: Analysis and Design, References, and Appendices (if any ) by the end of their 9th level. Due dates and more details will be posted on the Advertisements board in the college of the Computer Science.

4.2.

Project Two Report/CD-ROM Submission:

Students of project two (level 10) are required to submit (Hard Covered) six copies of their project documentation including all chapters mentioned above along with Three CD-Rom copies of the system (Software/Manuals) by the end of their 10th level. Due dates and more details will be posted on the Advertisements board in the college of the Computer Science. Note: Title page should be Printed on the Hard Cover.

11

5. Projects Timetable:
Project 1: Documentation final submission date: Week 12 of the Semester. Project 2: Documentation final submission date: Week 13 of the Semester. Project 2: System submission date: From Week 13 of the Semester. Project 1: Defense date: Advertised on the College bulletin Board. Project 2: Defense date: Advertised on the College bulletin Board.

6. Delayed submissions
Occasionally, circumstances may prevent students from making submissions on time. Request for such special consideration must be submitted in writing and include supporting documentary evidence. The decision on whether, an extension should be granted or not, for such special cases will be determined by the project evaluation board.

7. Project Evaluation
The project work is evaluated based on the project written paper (documentation) and the defense. The defense of the project will include a presentation and demonstration. The project evaluation board should be satisfied that project objectives have been met as well as the outcome has justified the time spent on the project.

Thank you and Good Luck in your Graduation Project

12