University of Gondar

1
 Project Guideline for Underg
Faculty of Informatics
12/8/2019

Prepared by
1. FEDLU NURHUSIEN (COMPUTER SCIENCE)
2. ASSEFA CHEKOLE (INFORMATION SCIENCE)
3. GIRMA SISAY (INFORMATION SYSTEMS)
4. HABTAMU TEGENE (INFORMATION
TECHNOLOGY)

2
Preface
Faculty of Informatics is one of the academic programs at the University of Gondar. It was
established in June 2016. The Faculty established four fields of study namely, Computer Science,
Information Technology, Information Systems, and Information Science. Formerly all
departments have been managed under the College of Natural and Computational Sciences.
Currently, the Faculty has undergraduate and postgraduate programs in regular and extension as
well as Sumer bases.
The postgraduate programs found in the Faculty of Informatics have been mentioned as follows:
Master of Science Degree in Computer Science, Master of Science Degree in Information
Technology, Master of Science Degree in Data Science and Analytics, and Master of Science
Degree in Information Systems. Moreover, the Faculty participates in income generation
through continuing education, and the staff members have actively participated in research,
community service, and technology transfer projects. So, the Faculty plays a great role in the
improvement of educational quality at the University of Gondar as well as at the national level.
To complete the undergraduate and postgraduate degree programs the students should conduct
group project work and individual thesis work respectively. Therefore, the purpose of this
guideline is to govern the undergraduate student’s group project work to keep uniformity across
the four departments. In addition, this guideline determines the components included in project
proposal and final report writing, project evaluation mechanisms, and implementation rules as
well as methods to handle plagiarism.

3
4
Table of Contents
Preface..........................................................................................................................................................i
1. Objective of this Guideline......................................................................................................................1
2. Project Documentation Writing Format..................................................................................................2
3. Description of the Project Outlines..........................................................................................................5
4. Document Style and Formatting Instructions........................................................................................16
5. PowerPoint preparation and formatting instructions............................................................................17
6. Progress Report.....................................................................................................................................19
8. Roles of project coordinators................................................................................................................20
9. schedule for defense.............................................................................................................................20
10. Plagiarism and related issues...............................................................................................................21
Appendices................................................................................................................................................26
References.................................................................................................................................................28

i
1. Objective of this Guideline
For Students:
 To gain insight into the rules and procedures that should be followed in the final project
document writing, system analysis, system design, system modeling, and implementation
phases.
 To develop their project using a consistent format
 To understand the advising time frames and the evaluation methods.
For Advisors:
 To use consistent project outlines to advise the students
 To timely control the student’s project progress and to report it according to the schedule.
 To evaluate the student's project work using a consistent format
For project Coordinators:
 To facilitate the progress of the student's project between the students and advisors
 To implement a uniform student project evaluation across departments

1
2. Project Documentation Writing Format
The project report is an extremely important aspect of the project. It serves to show what you
have achieved and should demonstrate that:
 You understand the wider context of computing or system development 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 or system development.
 You are capable of objectively criticizing your work and making constructive suggestions
for improvements or further work based on your experiences so far.
This section encompasses the following preliminary pages and the main reports of the project
accomplishments, next to the preliminary pages the remaining main body of the report will be
organized in the form of chapter headings.
2.1Outlines of the Project Document
Preliminary Pages
i. Title Page
ii. Approval Sheet
iii. Acknowledgements
iv. Table of Contents
v. List of Figures
vi. List of tables
vii. Acronyms
viii. Executive Project Summary
Chapter 1: Introduction
1.1 Background of the project
1.2 Statement of the Problem and Justification
1.3 Objective of the Project
1.3.1 General objective
1.3.2 Specific objectives
1.4 Scope of the Project
1.5 Limitations of the Project
1.6 System Development Methodology

2
 1.6.1 System Development Approach
1.6.2 System Development Tools
1.7 Significance of the Project
1.8 Beneficiaries of the project
1.9 Feasibility Study
1.10 Project Schedule
1.11 Project Budget
Chapter 2: Requirement Analysis
2.1 Current System Description
2.1.1 Major function of the current system
2.1.2 Problem of Existing System
2.2 Requirement Gathering
2.2.1 Requirement Gathering Methods
2.2.2 Business Rules
2.3 Proposed System Description
2.3.1 Overview
2.3.2 Functional Requirements
2.3.3 Nonfunctional requirements
2.3.3.1 Performance
2.3.3.2 Scalability
2.3.3.3 Availability
2.3.3.4 Reliability
2.3.3.5 Maintainability
2.3.3.6 Security
2.3.3.7 Environmental
2.3.3.8 Usability
2.3.3.9 Interoperability
Chapter 3: System Model
3.1 Scenario
3.1.1 Use Case Model
3.1.2 Use Case Diagram
3.1.3 Description of Use Case Model

3
3.1.4 Activity Diagram
3.1.5 Object Model
3.1.6 Data Dictionary
3.1.7 Class Model
3.1.8 Dynamic Modeling
3.1.9 User Interface
Chapter 4: System Design
4.1 Introduction
4.2 Current software architecture (if any)
4.3 Proposed Software Architecture
4.3.1 System Decomposition
4.3.2 Hardware/ software mapping
4.3.3 Persistent Data Modeling
4.3.4 Access control and security
4.3.5 Detailed class diagram
4.3.6 Package Diagram
4.3.7 Deployment
Chapter 5: Implementation
5.1 Mapping Models to Code
5.2 Screen Images
5.3 Testing and Evaluation
5.4 System maintenance
Chapter 6: Conclusion and Recommendation
6.1 Conclusion
6.2 Recommendation
Reference
Appendix

4
3. Description of the Project Outlines
i. Title page
See Appendix 1 for the title page format.
ii. Approval Sheet
See Appendix 2 for the approval sheet format.
iii. Acknowledgements
Acknowledgment in scientific literature writing is a statement of gratitude for friends, family,
instructors, advisors, organizations, etc. for assistance in producing a specific work. Receiving a
credit by way of acknowledgment indicates that the person or organization did not have a direct
hand in producing the work in question, but may have contributed criticism, or encouragement to
the performer(s). Apart from the citation, which is not usually considered to be an
acknowledgment, acknowledgment of conceptual support is widely considered to be the most
important for identifying intellectual debt.
iv. Table of Contents
A table of contents may be headed simply "Contents," which is an organized list of divisions
(chapters or articles) and the pages on which they start or the place where they may be found in
the order in which the parts appear. The contents usually include the titles or descriptions of the
first-level headers, such as chapter titles in longer works, and often include second-level or
section titles (A-heads) within the chapters as well, and occasionally even third-level titles
(subsections or B heads).
Table of Contents as a gateway through the document shall automatically be indexed or
generated.
v. List of Figures
The list of figures identifies the titles and locations of visuals (figures, drawings, photos, maps)
in a research document. Figures concentrate information in unusual ways and show critical
details, configurations, and evidence.
Often Advisors, reviewers, and readers review them independently of other sections of a report.
If figures do not accompany your report or article, look for ways to include them. Figure titles
are capitalized, and figures are numbered consecutively in Arabic number through the report. In
a larger document, the figure number may be in two parts, the first part referring to the section
number: for example, "Figure 3-5" for the fifth figure in Chapter 3. Be sure the figure captions
are descriptive.

5
 vi. List of tables
Tables are used for organizing information in a structural approach, so when you use tabular
presentation for the information, the list of tables should be maintained including the captions
and locations (page numbers referred)
vii. Acronyms
Acronyms are abbreviations formed from the initial letters of other words and pronounced as
a word (e.g., ASCII: is the acronym for American Standard Code for Information
Interchange, and NASA: stands for National Aeronautics and Space Administration). So,
abbreviations that are found on your document should be stated to show their normal
meanings/long forms.
viii. Executive Project Summary
This section will contain an overview of what you accomplished in the project. This section will
provide a high-level view for the readers and examiners to easily understand what you have
done. You should clearly state the motivation, problem statement, approach, and significance of
the project.
Chapter 1: Introduction
Your introductions should not exceed two pages (double-spaced, typed). The purpose of an
introduction is to acquaint the reader with the rationale behind the work and to defend it. It
places your work in a theoretical context and enables the reader to understand and appreciate
your objectives. When writing the introduction, you should consider the following:
 Use past tense except when referring to facts. After all, the paper will be submitted after
all of the work is completed.
 Organize your ideas, making one major point with each paragraph.
 Present background information only as needed to support a position. The reader does not
want to read everything you know about a subject.
 State the objective precisely - do not oversimplify.
 As always, pay attention to spelling, clarity, and appropriateness of sentences and
phrases.
1.1 Background of the project

6
The background section of the report should set the project into context by relating it to existing
published work which you read at the start of the project when your approach and methods were
being considered. There are usually many ways of solving a given problem, and you shouldn't
just pick one at random. Describe and evaluate as many alternative approaches as possible. The
background section can be included as part of the introduction but is usually better as a separate
chapter, especially if the project involves a significant amount of prior research. The published
work may be in the form of research papers, articles, textbooks, technical manuals, or even
existing software or hardware from which you have had hands-on experience. You must
acknowledge the sources of your inspiration. You are expected to have seen and thought about
other people's ideas; your contribution will be putting them into practice in some other context.
However, avoid plagiarism: if you take another person's work as your own and do not cite your
sources of information/inspiration you are being dishonest; in other words, you are cheating.
When referring to other pieces of work, cite the sources where they are referred to or used, rather
than just listing them at the end.
1.2 Objective of the Project
Objectives are specifically for targets within the general goal. Objectives are time-related to
achieve a certain task. Objectives are measurable activities that achieve goals; the endpoints
envisioned. These objectives might be, for example, the development of a specified measurement
capability that meets a prescribed accuracy, data rate, instrument packaging characteristics (size,
weight, etc.), and other possible requirements.
The objectives section of the project is typically very brief, usually a half-page at most. This is
because the rationale for objectives could also be explained in the problem statement, while the
ways of achieving the objectives should be explained in the methodology section. Indicating both
the general and specific objectives of the project will be important.
 The General objectives provide a short statement of the development goal being pursued
by the project.
 The Specific objectives are operational. They may indicate specific types of knowledge
to be produced, certain audiences to be reached, and certain forms of capacity to be
reinforced. These are the objectives against which the success of the project will be
judged. It is important to distinguish the specific objectives from the means of achieving
them.
1.3 Statement of the Problem and Justification

7
 Give a brief, general statement of the problem to be investigated or solved by the system.
Explain what your system has found out or shown. This section should normally make up
one of the significant parts of the project.

1.4 Scope of the project

Project scope is a general guide which used to cover as a tool to define and group a project’s
discrete work elements in a way that helps organize and define the total work scope of the
project. Therefore, the students are required to define the specific boundaries of the project in
terms of what the system must do.
1.5 Limitations of the project
Limitations are shortcomings, conditions, or influences that cannot be controlled by the
Project team. Any limitations that might influence the results should be mentioned. Describe the
problems you expect to encounter and how you hope to solve them. For example, texts might be
unavailable, necessitating travel to other libraries or use of inter-library loan facilities; people
you had hoped to interview might be unavailable or unwilling to participate, necessitating that
you select other interviewees or change the focus; internet sites might be down or no longer
available, etc. (Try to imagine every possible problem so that you have contingency plans and
the project doesn't become disrupted.)
1.6 System Development Methodology
Nowadays, different system development methodologies help to achieve the objectives of small-
scale up to large-scale system projects. Hence, the students should select the appropriate system
development approaches that meet their proposed system, when selecting their system
development approach, the students should justify the selected approaches (why it is preferred
over other approaches).
In addition, there needs to be a criteria-based comparison of the features of the top-ranked
system development approaches. The students are also required to mention the system development
tools used in terms of hardware and software paradigms.
1.7 Significance of the Project
Here the students are required to justify the values of the new system for the community. In
terms of operations, productivity, in comparison with the current system should be discussed.
1.8 Beneficiaries of the project
Here the students should mention the target beneficiaries of the new system/software.

8
 1.9 Feasibility Study
In this section, the feasibility of the new system should be discussed clearly in terms of the
following components:
 Economic feasibility
 Operational feasibility
 Technical feasibility
 Time feasibility
 Legal feasibility…and so on.
1.10 Project Schedule
In this section, the project timeline should be prepared in line with the correspondence set of
activities that will be used to control the progress of their project work. So, the project timeline
should be prepared using a Gantt chart, a PERT chart, or any other CASE diagramming tools.
1.11. Project Budget
This section contains the financial plan for implementing the project. It should be clear, realistic,
and Reasonable (affordable).
• It should be itemized according to the following:
o Equipment
o Stationery
o Materials
o Software
o Hardware
o Transportation costs
o Other costs such as Secretarial, Photocopying, Printing, and Binding

Chapter 2: Requirement Analysis

1.1 Current System Description
1.1.1 Major function of the current system
1.1.2 Problem of Existing System
1.2 Requirement Gathering
1.2.1 Requirement Gathering Methods
There are different types of requirement-gathering techniques, the student should carefully meet
this section to develop a successful system. Studies conducted regarding system requirements
show that the most common reason for the systems to fail is due to a lack of collecting
9
appropriate requirements. Therefore, the students are required to present the detailed
requirements that have been collected.
1.2.2 Business Rules
List any operating principles about the product, such as which individuals or roles can perform
which functions under specific circumstances. These are not functional requirements in
themselves, but they may imply certain functional requirements to enforce the rules.
1.3 Proposed System Description
1.3.1 Overview
1.3.2 Functional Requirements
In this section, the students need to mention what the new system intends to do.
1.3.3 Nonfunctional requirements
In this section, the students should discuss the characteristics of the new system in terms of the
following system features.
1.3.3.1 Performance
1.3.3.2 Scalability
1.3.3.3 Availability
1.3.3.4 Reliability
1.3.3.5 Maintainability
1.3.3.6 Security
1.3.3.7 Environmental
1.3.3.8 Usability
1.3.3.9 Interoperability

Chapter 3: System Model

3.1 Scenario
Scenarios are an instance of a use case explaining a concrete major set of actions. Scenario or use
case realizations are just a graphical sequence of events or an instance of a use case these
realizations are depicted as either a sequence or collaboration diagram.
3.1.1 Use Case Model
3.1.2 Use Case Diagram
3.1.3 Description of Use Case Model
3.1.2 Activity Diagram
3.1.3 Object Model
3.1.4 Data Dictionary
3.1.5 Class Model
3.1.6 Dynamic Modeling
Document the behavior of the object model, in terms of state chart diagrams, and interaction
diagrams (sequence diagrams and/or communication diagrams).
3.1.7 User Interface (as a prototype)
This section describes navigational paths and screen mock-ups of the proposed system interfaces.

10
Chapter 4: System Design
4.1 Introduction
In this section, the students need to provide a brief overview of the software architecture and the
design goals (Subsystem decomposition, Hardware/software mapping, Persistent data
management Access control, and security). You should also provide traceability information
(e.g. how the design is related to the requirement analysis done in the previous chapter,
constraints impacting the software architecture).
4.2 Current software architecture (if any)
In this section, the students need to describe the Current software architecture of the system
being replaced (if there are any previously implemented systems existed).
4.3 Proposed Software Architecture
4.3.1 System Decomposition
System decomposition describes the decomposition into subsystems and the responsibilities of
each. This is the main product of system design. Here, use UML component diagram to
diagrammatically depict your components.
4.3.2 Hardware/ software mapping
Hardware/software mapping describes how subsystems are assigned to hardware and off-the
shelf components (if any). Here, use UML deployment diagram to diagrammatically depict the
hardware/software mapping.
4.3.3 Persistent Data Modeling
Persistent data modeling describes the persistent data stored by the system and the data
management infrastructure required for it. This section typically includes the description of data
schemes, the selection of the database, and the description of the encapsulation of the database.
Here, use an E-R diagram if you are using a relational database or an Object diagram if you are
using an object database.
4.3.4 Access control and security
Access control and security describe the user model of the system in terms of access privilege.
You can use tables to show the privileges assigned to each user of the system. This section also
describes security issues, such as the selection of an authentication mechanism, the use of
encryption, and the management of keys.
4.3.5 Detailed class diagram
In this section,

11
 Identify missing attributes and operations. During this activity, you need to examine each
subsystem service and each analysis object. You need to identify missing operations and
attributes that are needed to realize the subsystem service.
 Specify visibility and signatures. During this activity, you need to decide which operations
are available to other objects and subsystems, and which are used only within the
subsystem. You need to also specify the return type of each operation as well as the number
and type of its parameters.
 Specify contracts. During this activity, we describe in terms of constraints the behavior of
the operations provided by each object. In particular, for each operation, we describe the
conditions that must be met before the operation is invoked and a specification of the result
after the operation returns.
Here, you can use the UML class diagram to specify attributes and operations with their visibility
information.
4.3.6 Package Diagram
This section describes the decomposition of subsystems into packages and the file organization
of the code. This includes an overview of each package, its dependencies with other packages,
and its expected usage.
Here, use a UML package diagram to diagrammatically depict your packages.
4.3.7 Deployment
Since, this is the final stage in the system development life cycle to put the system in production
(utilization). The students are required to show, how the system is to be deployed for the
intended organization.
Chapter 5: Implementation
In this section, the programming tools and languages will be decided. The algorithms developed
in the design phase are coded in the appropriate language, and component modules be tested. A
well-designed user interface is of great importance to ensure that your program is well-received
by its intended audience.
5.1 Mapping Models to Code
In this section,
 Mapping Associations,
o Unidirectional one-to-one associations
o Bidirectional one-to-one associations

12
 o One-to-many associations
o Many-to-many associations
 Mapping operation contracts to exceptions,
 Mapping the class model to a storage schema is performed.
5.2 Screen Images
5.3 Testing and Validation
A variety of testing techniques can be brought to bear on the question, "Are the computed results
correct?" The processing of some carefully chosen data will be necessary to detect typing errors,
at least. The effort required for validation can be greatly reduced by taking pains to demonstrate
the validity of the algorithms during the design phase. In your project report, you should include
a description of the tests performed and the test data used.
There are several testing methods; so, you the students are required to apply some of them, such
as, White Box Testing, Black Box Testing, and Acceptance Testing.
5.4 System maintenance
Chapter 6: Conclusion and Recommendation
6.1 Conclusion
In this section, summarize what you have done in the entire system development process, basic
achievements (main functions of the system), the motivations initiated to develop the system,
and mention the methods and system development approaches that have been applied to Solve
the current problems.
6.2 Recommendation
In this section, the students are required to discuss Suggestions for Better Approaches to the
Problem or Project. Need to discuss the system's feasibility for utilization for organizational
efficiency. Furthermore, the students possibly mention their Suggestions for Future Extensions
(improvements) to the system.

13
Bibliography
Reference numbers should be cited within the text as well as figure/table captions either as
Superscripts or enclosed in square brackets. In this way of citation, all references should be
Numbered (Arabic numerals) in the order in which they are first cited in the report. Another
The alternative is citing references using the author’s last name and the year the material was
published.
Here, all references should be arranged in a chronological ascending order. Strictly avoid citing
References in chapter/section/subsection titles. References are cited to convey to the reader that.
The idea, concept, formulation, data, inference, or information being discussed is attributable to
The cited literature. All figures/tables, that are taken from the literature, must be acknowledged.
by citing the reference number or the author and the year of publication at the end of the
Caption.
The main reference sources include books/monographs/ handbooks, archived journal papers,
conference papers in published proceedings, institutional technical reports, theses/ project
Documents, dissertations, and other archived reports and standards. Internet websites are also.
Increasingly becoming an important source. However, it should be noted that the Internet.
References should not form the entire list of references. Allowing URLs as references must not
Be misunderstood to mean that all Internet material is acceptable. Internet material may be
Transitory, may not be technically reviewed and may have questionable authenticity, that is, it.
May not be proper archival material. It may be used as a secondary information source to
Supplement the main sources. List references at the end of the paper in either numerical order or
chronologically ascending order. Sample references could be as listed below:
For a book: author(s), book title (bold), publisher, city, and year.
Example:
[1] L. R. Rabinerand B. H. Juang. Fundamentals of Speech Recognition. PTR
Prentice Hall Inc, Englewood Cliffs NJ, 1993.
For a journal paper: author(s), paper title (bold), journal name, volume number, issue
Number, page numbers (inclusive), publisher, year.
Example:
[2] R. K. Aggarwal and M. Dave. Acoustic modeling problem for automatic
Speech recognition system: conventional methods (Part I). In International
Journal of Speech Technology, Vol. 14, Issue 4, pp 297 - 308, Springer Science Business Media,

14
2011.
For a proceedings paper or chapter in an edited book: author(s), paper or chapter title, volume
title, editor(s) (if applicable), volume number (if applicable), page numbers (inclusive),
publisher, city, year.
Example:
[3] S. T. Abate and W. Menzel. Syllable-Based Speech Recognition for
Amharic. In Proceedings of the 5th Workshop on Important Unresolved
Matters, pp. 33–40, Association for Computational Linguistics, Prague, Czech
Republic, 2007.
For an internet source: author(s), year, webpage title (bold), URL [access date].
Example:
[4] M. P. Lewis (Ed). (2009). Ethnology: Languages of the World (Sixteenth
edition) [Online]. Available: http://www.ethnologue.com/ [February 05,
2013].
Note: the examples given above follow the IEEE referencing style

Appendices
This section comprises Explanatory Notes which include project approval letters, screenshots,
project source codes, and instruments like interview sample protocols, etc.

15
4. Document Style and Formatting Instructions
The faculty has prepared the project document writing format and its description for the final
project work as an outline. So, the project document will be formatted using the following
guiding instructions.
4.1 Language
The project document must be prepared in English.
4.2 Paper Size and Specification
The document must be prepared using a standard A4 (8.27" X 11.69") paper size.
Use the normal page margins: Top: 1’’ Bottom: 1’’
Left: 1’’ Right: 1’’
4.3 Font Type and Size
4.3.1 For Title Page
 Font Type: Times New Roman [UPPER CASE]
 Font size: 16 [bold]
 For other texts on the cover page, use Times New Roman and 14 font sizes
4.3.2 Main Headings:
 Font type: Times New Roman [UPPER CASE]
 Font size: 12 [bold]
4.3.3 Body Text:
 Font type: Times New Roman
 Font size: 12
4.3.4 For Sub Headings:
 Font type: Times New Roman
 Font size:10 [bold]
4.3.5 Indentation and Line Spacing
 The line spacing between texts should be 1.5 with the exceptions of captions, lists,
graphs, charts, items with tables, and lists in the appendices.
 The alignment of each paragraph should be justified.
 Each chapter must start on a new page. Chapter titles should be centered and be as Major
Heading.

16
4.4 Tables
 Tables should be consecutively numbered and labeled. Table numbering should
Indicate the chapter where it resides.
4.5 Figures
 Figures should be consecutively numbered and labeled. Figure numbering should
Indicate the chapter where it resides.
4.6 Page Numbers
 Except for the title page, number all pages which come before the first page of the
Body chapters consecutively with lowercase Roman numerals (i, ii, iii, iv…).
 The first page with Arabic numerals (1, 2, 3, and so on) starts from the page of the
Introduction. Put page numbers centered and aligned.
4.7 Page Headers
 The header will comprise the title of the Project report. On every odd page will appear the
title of the report while on the even pages, the title of the chapter or section will be
mentioned.
 The first page of every section or chapter shall not carry the header.

5. PowerPoint preparation and formatting instructions

You are expected to defend your project by preparing a catchy presentation. Developing an
outline or structure for your presentation will help you communicate a clear and meaningful
message to your audience.
5.1 Slide Layout
Your slides should have a white background with little or no graphics.
Your bullet points should be short and quick hits and try to keep the number of bulleted items
around six per slide.
5.2 Font
 Use Arial font type with the color black.
 Main body contents should be coined in 20-24 pts.
 Font type, size, and style of the main content area on all slides except for the title slide
Should be the same.
 The title of your project should be a maximum of 36 point-size

17
  Each content slide should have a title and should solely reflect the comprised content.
 The titles should be brief and descriptive. They should not be full sentences.
 The title of each slide should be 30- a point-size
5.3 Total number of slides
A general rule of thumb is one slide per minute. If you have a 20-minute presentation, you
should include about 20 slides. You don’t want to overwhelm your audience with too much
information. Focus on the key concepts you want your audience to remember. However, for the
sake of your defense, up to 26 slides are allowable.
Notice!
This is one of the biggest mistakes most students make with PowerPoint: They cram too much.
Text onto their slides. The text-only slides should be short, quick-hit highlights written as
Phrases rather than complete sentences. If your audiences are busy reading your slide, they are
Not going to be paying attention to you. Or they may not read the slide at all, which renders
Your PowerPoint presentation is useless. So, make sure to leave some white space around the
The main content on your slide. This helps to focus the reader’s attention on the key information.

18
6. Progress report
A progress report is a written document that explains how much progress is being made on the
project tasks that you have previously planned. That is, it is a report of the progress that has been
made on the project and reports about the ongoing project. The following are some of the rules of
progress report preparation and submission guidelines.

6.1 Every group should submit a progress report for their respective advisor based on the
specified time and date per week.
6.2 Every advisor should send all the submitted progress reports to the project coordinator once
per three weeks using the format attached at the annex. Here Friday of the third week is for
collection of progress reports from each advisor. Hence at each month, the third week’s
Friday till 11:00 will be the last date for a progress report submission.
6.3 Every group must submit the progress report based on the work breakdown and phase-by-
phase task divisions stated in the project document.
6.4 The faculty project coordinators team should hold a meeting once a month (at the beginning
date of the month), to see the progress that students and assigned advisors are making so far.
Here in case of holidays and other urgent responsibilities, the meeting date can be re-
arranged based on the team agreement.

7. Roles of advisors
7.1 Every advisor is expected to contact one group for 2 hours per week.
7.2 Per each semester there will be minimum of 14 contacts by considering the assumption of 1
week for title selection and group assignments.
7.3 While the group members contact their advisor, it is a must that all group members should be
available during the contact hour and the advisor is expected to take attendance.
7.4 If there is a failure of achieving rule 7.3 for more than two contacts per month, then the
advisor should report to the project coordinator of the department.
7.5 If students are unable to get their advisor for subsequent period of time (minimum of two
consecutive contacts per month), then they should report to the department project
coordinator.

19
7.6 Every advisor and project coordinator must sign the final document that will be submitted by
every group.

8. Roles of project coordinators

8.1 The project coordinator is responsible for forming the group among final-year students. In
each group, the number of students shall be between 4 to 5 members.
8.2 The project coordinator should represent his/her department at the faculty level during title
review and related meetings that will be held in the faculty.
8.3 The project coordinator should organize presentation and defense sessions in both semesters.
8.4 The project coordinator is the responsible body to collect titles for approval, progress reports
from each advisor and final project documents in that department.
8.5 After defense the project coordinator should collect student marks from their respective
examiners and advisors. Then he/she must submit students grade using SIS system.
8.6 Each department project coordinators are responsible for preparing schedules in collaboration
with other sister departments, assigning examiners and following over all work of the defense
and they should submit the grade based on the academic calendar.
8.7 Since the project titles are selected with faculty level each department have a mandate to
select examiners from the other sister departments.
8.8 Right after the title approval, the department and the project coordinator should assign an
advisor for each project. While assigning the advisor, the department should consider the
total load and the number of active staff in the department.
8.9 The project coordinator of the department will be assigned by department council and his/her
term is limited to one academic year.

9. schedule for defense

Defense is a presentation where by students will present their final work to the examiners for
final grading. The following are some of the rules before and after defense.

9.1 Every group must submit their final document one week before the defense time.

20
9.2 The project coordinator must distribute the submitted project documents to the examiner
before 5 days of the presentation.
9.3 As evaluation criteria 30 marks are reserved for the advisor and the remaining 70 marks are
reserved for the examiner. The defense results are the average marks given by all examiners
during the presentation.
9.4 Every group must submit the corrected project document after three consecutive days of the
defense date. If students fail to do so, their grades will be suspended for grade submission.
9.5 Defense should be done once per semester so that the students will have 2 defense schedules
at their graduation year. The defense should be conducted after the final exam is completed,
and their grade should be done at most within the specified academic calendar.
9.6 For the defense, which will be conducted at both semesters, the total time allotted is 1 hour,
where by 25 minutes is for presentation/demonstration and the rest 35 minutes for defense.

10. Plagiarism and related issues

Plagiarism is using the words or ideas of another as if they were your own. It can be an
intentional or unintentional act, but either way, there can be severe consequences. It is also
unethical practice to use projects (either planned or accidental) of other students/instructors
without proper acknowledgment and visible differences. The following are ways to manage
plagiarism.

 If there is a suspicion of plagiarism in a student’s project, first the examiner should report
to the project coordinator of the department, and he will present for discussion with the
department. Here the academic council (AUC) can go for further investigation through
assigned committees. Then based on the committee report if the plagiarism level is more
than 50 %, the punishment will be re-doing the project for an additional semester. If the
level is below 50% they should be punished to re-do and resubmit it within one month.

21
22
 UNIVERSITY OF GONDAR

FACULTY OF INFORMATICS

UNDERGRADUATE STUDENTS FINAL PROJECT EVALUATION

ADVISOR EVALUATION FORM

No. Student Attendance: Document preparation based on Team Progress report:10% Total:
Name 5% advisor comments & guidelines: coordination (5 reports per chapter) 30%
(from 0 – 5 10% & Task
marks) 100% 75% 50% 25% 0% division: 10pts 8pts 6pts 4pts 2pts 0pt
(10pts) (7.5pts (5pts) (2.5pts) (0pt) 5%
)
(from 0 – 5
marks)
1.

2.

3.

4.

5.
6.

Project title: _________________________________________________________________

Adviser Name: ________________________________ Signature: _____________ Date: _____________

22
 UNIVERSITY OF GONDAR

FACULTY OF INFORMATICS

UNDERGRADUATE STUDENTS FINAL PROJECT EVALUATION

ADVISORS PROGRESS REPORT SUBMISSION FORM FOR PROJECT
COORDINATORS
Weeks Summary of discussion points Students Name Date Remark
Week 1 -
-
-

Week 2 -
-
-

Week 3 -
-
-

Advisor Name: _________________ Signature: _____________ Date: __________

23
 PPT Statement Objecti Scope Method Signifi Require System Document Confide Total:
No Student Name preparati of the ves and ology: cance: ment model & formatting nce,
. on: problem: (Genera limitati (Requir 5% Analysis Design: : Commu 70 %
(Consiste (Current l& on: ement (Functio (Use 5% nication
ncy, & Specific 4% gatherin nal & case, Skills,
Clarity, Proposed) ) g, Non- Activity, and
Bullet & 5% 4% System Function Sequenc Defense
Numberi Develop al): e, Class, perform
ng) ment) 10% Compon ance:
5% 5% ent, 12%
Deploym
ent, SW
architect
ure)
15%
1
2

5
UNIVERSITY OF GONDAR
FACULTY OF INFORMATICS
UNDERGRADUATE STUDENTS FINAL PROJECT EVALUATION
FINAL DOCUMENT EVALUATION FORM – SEMESTER I
Project title: ______________________________________________________________________________________

Examiner Name: _____________________________________________ Signature: _____________ Date: __________

24
25
 UNIVERSITY OF GONDAR
FACULTY OF INFORMATICS
UNDERGRADUATE STUDENTS FINAL PROJECT EVALUATION
FINAL DOCUMENT EVALUATION FORM – SEMESTER II

PPT UI Design: DB Functional Validation Implement Document Confidence, Total

No. Student Name preparation: 5% connecti ity of the : 8% ation of the formatting Communicati
2% on: system: system: 10% on Skills, and 70 %
5% 10% 15% Defense
performance
15 %

Project title: ______________________________________________________________________________________

Examiner Name: _____________________________________________ Signature: _____________ Date: __________

25
Appendices
Appendix 1: Title Page Format

Institution Name
Faculty:
Department:
Project Title
By
(List of project team members)
A Group Project
Submitted to the Department of __________, Faculty of Informatics, University of Gondar, in
meeting the preliminary project requirement for partial fulfillment of the award of Bachelor of
Science Degree in _________________________.
Gondar, Ethiopia
Date/Year: _________

26
Appendix 2: Approval Sheet Format
This Group Project entitled “……………………………………………….………………” has
been read and approved as meeting the preliminary project requirements of the Department of
_____________________ in partial fulfillment for the award of Bachelor of Science degree in
_____________________, University of Gondar, Gondar, Ethiopia.

Approved by:

1. Name of Advisor: ___________________________ Signature: ___________Date: ________

2. Name of Project Coordinator: __________________ Signature: ___________Date:

________

27
References
1. IEEE Computer Society. IEEE Recommended Practice for Software Requirements
Specification (IEEE Std 830-1998). 1998.
2. Maker ere University, research proposal writing format [online]. Available:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.9598&rep=rep1&type=pdf.
[Accessed: 12-Dec-2019]
3. Computer Science Project Guide [Online]. Available:
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=3155131B52567FEFBDA17CEA
B86C18D? Doi=10.1.1.198.3752&rep=rep1&type=pdf. [Accessed: 12-Dec-2019]
4. Information and Guidelines for Computer Science Projects [Online]. Available:
http://www.cas.mcmaster.ca/~cs4zp6/4ZP6booklet.pdf. [Accessed: 12-Dec-2019]
5. Bernd Bruegge, Allen H. Dutoit. Object-Oriented Software Engineering Using UML,
Patterns, and Java. Third Edition. 2010.
6. IEEE Computer Society. IEEE Standard for Information Technology—Systems
7. Design—Software Design Descriptions (IEEE Std 1016™-2009). 2009

28