Monitoring PDF

Final Year Project Monitoring System for HU Faculty of Informatics 2018
CHAPTER ONE
INTRODUCTION
1.1 BACKGROUND OF THE STUDY
In Hawassa University Institute of Technology particularly Faculty of Informatics there are
so many final year projects are done every year. Although final year projects are good and
appreciable, there is no repository system for the project and it is difficult for junior students
and also for instructors to identify whether the project is done or not before, there is
similarity of projects or plagiarism of the project title and no status of the project. Due to
manual system there is wastage time, money and failure in morality of the students who
come up with similarity of the project and there is no indication of the project status whether
it is fail or reject or in progress to improve it immediately. Because of this problem there
must be need of system to monitor all the activities of students and staff members.
Having this problem in mind, we come up with a solution to the above all problems to help
students and instructors of Hawassa university Institute of Technology Faculty of Informatics
by developing Web-Based Final Year Project Monitoring System.
The aim of this paper is to design an intranet based repository system containing students’
final year project title, and information on the scope and process of development of each
project.
We are going to design and implement the project using open source and server side
language PHP, HTML, JavaScript, CSS and MYSQL as back end.
Hawassa university secured online network (intranet) where we can create content,
communicate, cooperate, manage project file in Hawassa University.
It is also a network operating like the www ,but having access restricted to a limited group of
authorized users.(for example Hawassa university communities)
An intranet gives you many ways to communicate, and simplifies both real-time and not
coordinated communication.
Intranet makes our communication easy for our team to work together and get things done on
scheduled time.
Intranet also gives us to create pages and provides the team members information.
Most intranet platforms allow you to create some kind of team page or project page.
Page | 1
1.2 STATEMENTS OF THE PROBLEM

As a starting point for problem definition, we tried to see how the final year projects are
monitored in Hawassa University Faculty of Informatics. As a team we gathered information
from previous student, advisor and coordinator that Faculty of informatics monitors final year
project through manual system.
Due to the manual system and absence of online project monitoring system the following
problems are occurred.
 Now a days when everything is online how its possible that in faculty of informatics
left web application behind to monitor final year projects?
 There is the repetition of the project title.
 There is no platform communication ways between students and advisors, and also
between advisors and coordinators. Because of this problem the student behave
carelessness to work project correctly.
 In the existing system control of action of the student’s and advisor does not
monitored, because of this student agree with advisor and change the given title
without announcing to coordinators and examiner. At final presentation the
coordinators and examiners knows the previous title and expect students to present
that title. But student present the other title which they changed by agreeing with the
advisors and disagreement become arise.
 There is no repository system or database system that students and advisors refer
easily last year project.
 There is no efficient and effective project evaluation system because manual system
evaluates students’ final presentation by recording on paper based on different
performance and collect this recorded data from different evaluators at different time.
That means time consuming, costly and requires much man power.
 It is difficult to know the status of the project.
 Project title is given to students unfairly. That means priority of the title is not
preferred. Because may be corruption easily takes places when recording project title
and description date and time.
 These are the main problems that we consider it and going to solve by designing and
implementing Final Year Project Monitoring System for Faculty of Informatics.
Page | 2
By changing manual system into Web based final year project monitoring system we are
going to satisfy communities of Faculty of informatics.
1.3 OBJECTIVES OF THE PROJECT
1.3.1 General objective
In the 21st century paper based systems are considered backward and out dated so most of
this systems are being left and automated systems are used around the world.
The main objectives of this project is to create web based final year project monitoring
system and to facilitates the progress of project monitoring system.
1.3.2 Specific Objective
We can achieve the general objective by fulfilling the specific objective listed below.
1. Analyzing the existing system: - Studying the business function, functional work
flows and timing of critical process and procedures by the user in the existing system.
2. Identification and definition of the problem: - To identify what kinds of problems

that are faced by users in the current system in the HU Faculty in any aspect of
teaching and learning process.
3. Generation of requirement: - Gathering all the requirements that have direct
relationship with the current system in order to fulfill users’ needs
4. Design of the new system: - In order to solve the problem easily and quickly we need
to design the web based application
5. Implementation and testing: - Apply the proposed system into the real world to be
tested. At this stage the new system is ready to function all its activity. Finally
deploying the implemented system.
1.4 SIGNIFICANT OF THE PROJECT

To the Developer:-whenever we design or develop a new system that is important to us to
get additional knowledge and satisfaction.
To Hawassa University:- Since Hawassa University is in the community, and the system
solves community problem and it proves that the university is in the community and
providing good quality project monitoring system.
Page | 3
To the Faculty of informatics:-any organization like this Faculty always plan to incorporate
new system, so when the system is developed it improve the organizational project file
repository system.
To the Students:-students need safe and better environment for their day to day activity, by
developing and applying this system it will give such a good environment for referring the
final year project source file and easily identify whether the project is done or not.
1.5 SCOPE OF THE PROJECT
The project is specifically designed for the Hawassa University Institute of Technology
Faculty of Informatics students and staff members. This Web based final year project
monitoring system is basically replacing the manual final year project monitoring system into
an web-based system so that the Faculty of Informatics students and staff members can
access the details of the projects and related information.
1.6 LIMITATION OF THE PROJECT

 The system requires network connection.
 The system does not support mobile device.
 The system we are going to design does not completely resolve the above mentioned
problems but somewhat it minimizes the problem.
 The Person who accesses the web system should have basic knowledge of computer.
 The system is basically applicable only in English language.
 The system we going to develop is only applicable in the Faculty of Informatics.
Because of that it’s only fully applicable in all features in Hawassa University.
 The system only works on desktop computer or laptop.
1.7 METHODOLOGY OF THE PROJECT
To develop this project relevant technique, tools, models that are used in object oriented
development environment are applied. For the successful completion of this project, a
number of data gathering, analysis, and programming tools and techniques are put into use.
Accordingly we will use different tools and techniques throughout the project life cycle.
Page | 4
1.7.1 Data Collection Methodology
Data collection methodologies are methods that we used to collect different data from
different data sources (documents, users and from Faculty of informatics).
Primary data source
Interview: We used interview as one of the major data collection method. During interview
our team got different necessary information from the school coordinator.
Document Analysis: we analyzed different documents of the last year project.
Direct observation:- As part of the learning process and as a student we have gone through
the scheduling process and observe the problem when submitting the title.
Preparing the questionnaire:- As a team we prepare some very important questionnaire to

coordinators, advisors, fresh teachers and to senior teachers to collect the data.
Secondary data source
Internet: Internet aids us to see the available sample on the internet and to download
different types of tutorials which are related to our project and help us in doing the project.
 Also referred other senior projects.
1.7.2 Testing Methodology
We will test and check our system that is successfully completed at the end of
implementation. As we tried to conclude some types of testing as like:
Unit testing: After developing an individual program module or component, it would test.
To ensure that it works according to the specification, operates within acceptable parameters,
and meets the appropriate standards.
Page | 5
Integration Testing: When a number of components are complete, it will test. To ensure
that they integrate well with each other, the operating system, and other components.
System testing: After preceded the above testing strategies the whole system will test with
the participation of workers and user in final year project monitoring system.
1.7.3 System Development Methodology
Object Oriented System Analysis and Design (OOSAD) Methodology is used, OOSD is a
system development paradigm which uses objects together with their interaction in order to
develop a system. [1]
We used OOSAD because of the following important features:
- Increase reusability:- the object oriented provides opportunities for reuse through
the concepts of inheritance.
- Increased extensibility: - when you to need to add new feature to the system you
only need to make changes in one part of the applicable class.
- Improved quality: - quality of our system must be on time, on budget and meet our
exceeded the expectation of the users of our system, improved quality comes from
increased participation of users in the system development.
Iterative model: it is unusual to design a complete project once. Therefore, to design our
project we are required to review and redesign in each phase iteratively to meet user
requirements.
1.7.4 System Development Tools
To develop the new system our team identified programming languages and database
management software as tools to be used. While developing the project starts from the
documentation to the implementation, we use the following development tools:
Software tools we are going to use are:
Back-end:
Page | 6
MySQL: We are planning to use MySQL at the back-end of our system. MySQL is a
programming language for querying and modifying data and managing database. It allows us
to insert, delete, update, and retrieve data easily.
PHP was chosen as a server side scripting language and offers many attractive and in
reached features.
Front-End:
Html: provides a collection of elements that allow web developers to organize web
documents in meaningful ways
CSS: allows us to create a standard set of commands, either embedded inside the web page
or from an external page, which controls the style of all subsequent pages.
Java-Script: is a computer programming language used us in the development of scripts.

Scripts are small programs embedded inside HTML pages.
MS Word 2013: The project team used Microsoft Word 2013 to write down the
documentation portion of the project. Microsoft Office was chosen because of its
compatibility to various platforms and its easy-to-use features
E-draw max: it’s a software tools that we used to draw artifacts of the system UML
diagrams.
Axure RP: it’s a software tools that we used to draw user interface design.
Hardware tools we are going to use are:
Computer: A machine that we are working on.
USB Flash: A storage devices that we used to store file in and transfer it.
Paper: A4 type paper for designing diagrams.
Pen : We used to write on paper.
1.8 FEASIBILITY STUDY

This analysis helps the organization in determining whether they should proceed with a
project or not. Feasibility study is essential to evaluate the cost and benefits of the new
system.
Page | 7
Need of the feasibility study:

 It determines the potential of the existing system.
 It used to determine/finds out the problem of the existing system.
 To determine all goals of the new system.
 It finds all possible solutions to the problems of the existing system
1.8.1 Technical Feasibility:- According to feasibility study/analysis procedure, the technical
feasibility of the system is analyzed and the technical requirements such as software
facilities, procedure, inputs are identified which are used to accomplish user requirements in
software within allocated time and budget. For this our team establishes the recourses and
technology that can be added to accomplish our task.
1.8.2 Operational Feasibility
Operational feasibility is mainly concerned with issues like whether the system will be used
if it is developed and implemented.
1.8.3 Economical Feasibility
Economic feasibility is most frequently used for evaluation of the effectiveness of the
system. More commonly known as cost/benefit analysis the procedure is to determine the
benefit and saving that are expected from a system and compare them with costs, decisions is
made to design and implement the system. Since the university is well equipped with the
required hard ware and software, the project is found to be economically feasible.Since this
project computerizes the existing system, reduction of cost for materials used in manual
operation becomes beneficiary to the Faculty of informatics and students.
Generally, the system that we are going to develop produces both tangible and intangible
products.
Tangible benefits:
 Reduction of paper and pen.
 Cost Reduction.
 Reduction of space needed to record data or storage.
Intangible benefits:
1. Error Reduction.
Page | 8
2. Increase Speed of activity.

3. Give better and effective services.
4. Increase efficiency.
1.8.4 Schedule Feasibility
Schedule feasibility is process of assessing the degree to which the potential time frame and
completion dates for all major activates with in a project meet. Concerning the project
schedule, it will be based on strict timing. So it must be delivered within the time bound
given over the Gantt chart below. Our intention is to finalize it, hopefully implement it and
start operation in the real environment before the end of this academic year. We will try to
avoid the problems as much as we can and finish our project as scheduled.
1.9 COST ESTIMATION AND SCHEDULE BREAKDOWN
Description Quantity Cost in birr
Computer 1 15,000
Flash disk 1 180
Pen 5 25
Paper 150 45
Edraw max - Free
AxureRP - Free
Sql server - Free
Apache server - Free
Ms word - Free
Table 1Cost Estimation
1.10 PROJECT PLAN ACTIVITY

Our team is working as the following project plan or schedule which is given by Gantt chart
to develop the proposed system. We used Gantt chart because it is simple to create and it is
clear to read or understand.
Page | 9
S.No Phases Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase

6
MAY-
17th DEC-3th
4th JAN–20th
NOV-
MAR-
15th DEC
25th MAY
15th MAY
JUNE
JAN
JAN
20th
15th
4th
1 Project Proposal
2 Requirement Analysis
3 Design
4 Implementation
5 Installation & Testing
6 Project Closure
-Start - To show the working time - End

Table 2Gantt chart schedule time
Page | 10
CHAPTER TWO
DESCRIPTIONS OF EXISTING SYSTEM
2.1 INTRODUCTION OF EXISTING SYSTEM
In Hawassa University Faculty of Informatics final year project are controlled and monitored
in manual ways. Existing system is a manual one in which users used paper to store the
project detail and monitors project progress. It is very difficult to maintain long time project
data and also other paper that is worked in departments. So in this section we provide a
previous background study of the existing system and we deeply explain what the system
itself is and how the system monitors final year projects. Regarding to the file tracking and
repository systems it’s important to gain more information about current existing file
tracking and repository system in order to propose the new system accurately. This is to
ensure that the study that currently being conducted contribute at certain level of application
thus it become more efficient and practical. There are many manual designs have been
proposed to provide for file tracking and repository systems in Hawassa university Faculty of
informatics many years ago and until now. From this manual system one is using excel to
record and store the final year projects files. This excel only contains student group name, the
date, the given titles, advisors name and examiners names are included. That means we
cannot access the data file when it is needed and to know about all features and application of
the project. Because the system is manual only the advisor can understand what the system is
and also what the function of the system itself. Maybe examiners sometimes understand the
project objectives and its function when at final presentation student present it correctly and
briefly. This project is intended to replace the manual project monitoring system to online
file tracking and project monitoring system using intranet and the system avoids more
manual hours that need to spend in record user information.. This system allows students and
school communities to communicate or reviews online what happened and going on without
physical contact. It is very easy to manage historical data in database. We can easily use the
tool that decreases manual hours spending for normal things and hence increases the
performance. As we get information from of Hawassa University Faculty of informatics
Lecture and coordinator Mr.Ayenew the current project file tracking and monitoring system
Page | 11
is recorded on excel .That means the current project monitoring system is the manual system
that requires cost, resource, consume time, less security.
2.2 PROPOSED SYSTEM DESCRIPTION
In this phase we are going to describe all about the proposed system that are planned to
works on it. The proposed system are web based final year project monitoring system
that will change the existing system that is currently used by Hawassa university Faculty
of informatics. This system is used for conduct web based final year project monitoring
system. The students can use their own user login to access the project file in the given
privilege and they can able to store project file finally after they presenting it. This
system will perform deposited, display the project file immediately and also store it in
database. This system provides the coordinator with the ability to control all activities
that is involved in the project doing progress.
The general overview of the proposed system is designed to address the problems of the
existing system. The proposed system solves or minimizes those entire problems in the
existing system. It will provide online file monitoring system. The proposed system will
be able to access and retrieve different data related to project.
2.2.1 The Goals Of Proposed System
The goals of the proposed systems are to replace the manual system currently used by
Hawassa university Faculty of informatics. This will bring operational efficiency by
minimizing time wastage and cost funded by the university to human resource service and
minimizes the man power by replacing paper based system.
And the main objective of proposed system is minimizing material and time wastage during
project monitoring time and handling information in consistent way through using repository
system.
The following are also the goals of proposed system.
 The modern computerized system is developed with the aim to overcome the
drawbacks of manual system.
 To create system that is platform which is make communication between the student
and staff member.
 To provide quick access to project information to the student and advisor .
Page | 12
 To minimize cost and time required to monitor the project.

2.2.2 Advantage Of The Proposed System
The advantages of proposed system are something that we want and expect in the futures and
minimize the existing system backwards. Some are:
 Ensure data correctness.
 Minimize manual data entry.
 Better service.
 Minimum time required.
 It reduces the wastage of time and money.
2.3 STRENGTH OF EXISTING SYSTEM
As our team we gather information from Hawassa University Faculty of informatics staff
members and coordinator manual project monitoring system has somehow strength, those
are:-
 It cannot depend on internet connection and because of that they not need connection
to record project file and to access it.
 It can use local language.
 It cannot need computer skill like computerized system.
2.4 WEAKNESS OF EXISTING SYSTEM

As we get information from Hawassa University Faculty of informatics staff members and
coordinators the existing system has the following weakness:-
 The system boring to do with it.

 Losing of hard copy data.
 Difficult to search the previous final year project when we need to see it.
 Excessive paperwork.
 Unreliable and inefficient data entry.
 Needs a lot of working staff and extra attention on all the records.
 The System records documents on papers as result it needs more storage place and
resources and it is difficult to manage properly.
Page | 13
 Data redundancy: Paper based documentation does not support integration of data,
as a result similar data may be recorded redundantly. This makes modification very
difficult and leaves inconsistent data here and there.
 Limitation on information Retrievals: -The information is very difficult to retrieve

and to find particular information for example searching for detail information.
 Problem on information storage: - The information generated by various

transactions takes time and efforts to be stored at right place.
 Problem on economics:-The existing system has to be evaluated from the economic
point of view by analyzing the cost and benefits. There is high time cost involved in
ordering and approving process. It’s difficult to control the materials which going to
waste.
 Lack of security: Poor security system because one can get easily the document and
change whatever they want, loss of information and sometimes because many years
data are reposted duplication may happen
 Generate Report: - the task of report generating is difficult to generate important
data easily for required body.
2.4.1 Alternative Solution
 As we try to describe in the above the current system faces many problems, the
problem is primarily resulted from the manual system of running the activities, and
we try to put an alternative solution to the problems, which are described, in the
existing system.
 As it’s the first title project in the Faculty of informatics and we are not familiar with
the title; so we are going to design a web based final year project monitoring system
as the best alternative solution to the existing system.
Page | 14
CHAPTER 3
SYSTEM FEATURES
3.1 INTRODUCTION
Proposed system solves the problems of the existing system by changing it in to web based
final year project monitoring system. This is the new system that removes the existing
problems which usually occurred in the manual system. The main purpose of the proposed
system is to improve the activities of project monitoring through computerization way that
simplifies the works of staff and student by speeding up the operation of the system.
3.2 FUNCTIONAL REQUIREMENT

A functional requirement defines the capabilities of our system that must be able to perform
successfully. Using the final year project repository and tracking system the following
functional requirements are performed by each major actors of the system.
Manage User Account: Coordinator should able to create, delete, and update the user
account and surely to make the system secured.
Manage project Detail: Coordinator should able to control all activities in the project
including add project detail like, whom done the projects (advisor, student), year, area of the
projects (is it web based, networking, android or desktop application), scope and key words
to search the project.
View Task: Coordinator, advisor and student should able to see the previous done project
and also view the project they are working on and through this method coordinator monitors
the activities of advisors and student.
View Mark: Coordinator, student and advisor should view the mark that assigned by
examiner finally.
Page | 15
Schedule Meetings: Advisor will be able to schedule meetings with students and
coordinator.
Assign Advisor: Coordinator should able to assign advisors to the project group based on his
performance area, experience year and specialization.
Assign Examiner: Coordinator should able to assign examiner to the project group based on
his performance area, experience year and specialization.
Evaluate Task: Advisor should able to evaluate task that student submit to him/her.
Assign Task: Advisor should able to assign the task to student after he/she is assigned to the
project group.
Send Advising Request: Coordinator able to send advising request to advisors after assigned
him/her.
Send Examining Request: Coordinator also able to send examining request to examiner
after assigned him/her.
Approve Advising Request: Advisor can able to approve advising request sent to him/her
by the coordinator.
Approve Examining Request: Examiner can also able to approve examining request sent to
him/her by coordinator.
Submit project Title: Student must be able to fills project submission form and submit to
coordinator.
Submit Task: Student can able to submit task that given to them by advisor.
Check Status: Student should be able to receive the response whether the project title is
accepted or not.
Approve Project Title: coordinator should able to response whether the project title is
accepted or not.
Create Project Group: coordinator can able to create project group member based on any
method.
Page | 16
Assign Mark: Examiner able to assign or grade student when they are presenting final
presentation.
Upload File: Student finally able to upload all project file to the system.
Download File: Student able to download project file.
Search Project: This use case enables student to search project
Generate Notification: Coordinator will generate different notifications related to the

project and these notifications will be sent to student or advisor.
Send Comment: Advisor able to send comment about task that they are working on to
student.
View Comment: Student able to see the comment given to them by advisor about the task
they are doing on.
3.3 NON FUNCTIONAL REQUIREMENT

Non-functional requirements or system qualities capture required properties of the system,
such as performance, security, maintainability and in other words, how well some behavioral
aspect of the system should be accomplished.
 Fast processing Time: Since document processing unit can be various, the
processing time is different. This system needs as much as possible faster
response time than typical web application.
 Error Handling: The system should display error message if the user input
invalid information.
 Accessibility: The system provides access have the right to control for each of its
user and every user can access the data which belong to them.
 Security: All input need to be encrypted and validated to prevent unauthorized
user. User can only perform operation under the permission.
 Usability: web based final year project monitoring system has a very user-
friendly interface. The users will feel happy since it is easy to work on it. The
system is designed to have user-friendly interfaces and easy navigation which
Page | 17
enhances users’ efficiency of usage. It is also designed in such a way that users
can easily learn how to interact with the system.
 Reliability/availability: - The system is ready for use all times during office working
hours. The system is also expected to be used smoothly without being corrupted and
frequently failure. The system should satisfy the user.
 Performance: -the system should provide the needed information in real time and it
should be responsive. .
 Scalability: - if we want to apply this system to other University’s it can be
easily done because the questionnaire being used is uniform across the
universities in the country.
3.4 ANALYSIS MODEL
3.4.1 Introduction
Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a
conceptual model of the information that exists in the area being analyzed. Analysis models
do not consider any implementation constraints that might exist, such as concurrency,
distribution, persistence, or how the system is to be built. Implementation constraints are
dealt during object-oriented design (OOD). Analysis is done before the Design. [2] This
chapter mainly focuses on the following point.
3.4.2 Use Case Diagram
We use a Use-case to identify a sequence of actions that provides a measurable value to the
actor which is participating in our system and our use case describes a way to which the
environment interacts with the system.
User interface identification
User interface is the space where interaction between actors and the system occurs.
UC-ID Activities Done Actor
UC-ID 001 LOGIN ALL
UC-ID 002 MANAGE USER ACCOUNT COORDINATOR
Page | 18
UC-ID 003 CREATE PROJECT GROUP COORDINATOR
UC-ID 004 APPROVE PROJECT TITLE COORDINATOR
UC-ID 005 VIEW MARK ALL EXCEPT EXAMINER
UC-ID 006 MANAGE PROJECT DETAIL COORDINATOR
UC-ID 007 GENERATE NOTIFICATION COORDINATOR
UC-ID 008 SUBMIT PROJECT TITLE STUDENT
UC-ID 009 VIEW TASK ALL EXCEPT EXAMINER
UC-ID 010 CHECK STATUS STUDENT
UC-ID 011 SCHEDULE MEETINGS ADVISOR
UC-ID 012 ASSIGN MARK EXAMINER
UC-ID 013 SEND ADVISING REQUEST COORDINATOR
UC-ID 014 SEND EXAMINING REQUEST COORDINATOR
UC-ID 015 APPROVE ADVISING REQUEST ADVISOR
UC-ID 016 APPROVE EXAMINING REQUEST EXAMINER
UC-ID 017 EVALUATE TASK ADVISOR
UC-ID 018 ASSIGN TASK ADVISOR
UC-ID 019 SUBMIT TASK STUDENT
UC-ID 020 ASSIGN ADVISOR COORDINATOR
UC-ID 021 ASSIGN EXAMINER COORDINATOR
UC-ID 022 SEND COMMENT ADVISOR
UC-ID 023 VIEW COMMENT STUDENT
UC-ID 024 DOWNLOAD FILE STUDENT
UC-ID 025 UPLOAD FILE STUDENT
UC-ID 026 SEARCH PROJECT STUDENT
Page | 19
Table 3User Interface Identification
Actor identification
1. Coordinator.
2. Student.
3. Advisor.
4. Examiner.
System use case diagram
Use case diagrams are ideal artifacts to capture the requirements of the system. They
represent the user requirements gathered during requirement elicitation. Use case diagram
consists of use cases, actors, and their relationship and system boundary.
Figure 1Use Case Diagram
Page | 20
Use Case Description

It is a sequence event that describes what the proposed project monitoring system we will
develop does and how it interacts with the environment mainly. This section describes the
most important activates that the user of final year project monitoring system do experience
to make use of the system.
List of Actors and List of user interface.
Name: Login
UC_ID: UC_001
Actor: Users (Coordinator, Advisor, Student and Examiner)
Description: This use case is used to ensure security in system usage.
Precondition: The user must have at least username and password.
Post condition: The user get access to the system according to their predefined system
privilege and finally he/she logout or turn off the page.
Main course of action:
Actor action System response
Step1: User has to activate the system. Step3: The System responses by
Step2: User selects login displaying the login interface and allow
the user for the user name and password.
Step4: User selects account type and fills
his or her username and password. Step6: System verifies Username and
Password.
Step5: he/she select login button.
Step7: System displays user home page.
Step8: the User get authentication and
access the system. Step9: Use case ends.
Table 4Main Course of Action for Login
Page | 21
Alternative course of action (if user enters wrong user name and / or password)
Step7: If the System displays an incorrect username and password message.

Step8: System enables user to fill the form again from basic course of action step 4.
Name: Manage User Account

UC_ID: UC_02
Include: Login
Actor: Coordinator
Description: This use case is done by the coordinator when he/she need to delete, edit and
make some modification to the account.
Preconditions: The coordinator login to the system to manage users.
Post conditions: The user information will be managed by coordinator.
For adding new user account
Step1: coordinator wants to add new user to the Step4: the system validates the new user
system and he/she login to the system. detail.
Step2: coordinator enters the new user name, Step5: the system save the user detail to
account type, Password and re-enter password to the database.
the system via adding new user form. Step6: the system permits some
Step 3:submits the new user information. operational tasks according to his/her
Step7:coordinator tells the category, user name category of the new user.
and password to the user. Step8:the system ends
Table 5Main Course of Action for Add New User Account
Alternative course of action:

Step2: If the coordinator does not enter the username and password the system displays a
message “please enters the user name and password correctly”.
Step4: if not correct the system doesn’t save the entered information to the database.
Step5: the system displays a fill again message and allow him/her to fill again.
For updating an account:
Page | 22
Step1: coordinator wants to update an Step4: the system checks the new account
account and he/she login to the system. information with the existing account in the
Step2: coordinator inserts account type, database.

username, password, and other user Step5: the system save the new account to
information. the database.
Step3: he/she submits the data. Step6: the updating process ends
Table 6Main Course of Action for Update Account
Alternate course action:
Step5: the system doesn’t save the new account to the system database and it displays a fill
again message.
For inactivate the account:
Step1: coordinator wants to inactivate Step5: the system checks the entered
the account. information with the existing account in
Step2: he/she login to the system. the database
Step3: enters the account type, username Step6: the system sends message “Do
of the user to be inactivated in the form. you want to inactive?”
Step4: selects the inactivate button. Step8: the system inactivated the account
from the system.
Step7: selects the yes option.
Table 7Main Course of Action for Inactivate Account
Alternate course action:
Step3: the system displays fill again message.

Step4: it does nothing.
Step5: the system sends a try again message.
Step7: the system ends if he/she selects no.
Name: Create project Group
Page | 23
Actor: Coordinator
UC_ID: UC_003
Include: Login
Description: Coordinator create group by setting its year and starting dateand member
information
Preconditions: Admin should have to login.
Post condition: The group created successfully
Main course of action
For submit project title:

Step1: coordinator wants to create Step 2: display project creation form

project group and click on create project Step4: validate input
group page.
Step5:display successfully message
Step3: fill the forms and click on create
Step6: the process ends.
Table 8Main Course of Action for Inactivate Account

Step5: display fills form again from basic course of action step3
Name: Approve Project Title

Actor: Coordinator
UC_ID: UC_004
Include: Login
Description: this use case is done by the coordinator when he/she sends a response to
student.
Precondition: the student should have to submit project title first.
Post condition: the student receives an approval response or disapproval message.
Actor Action System Response
Page | 24
Step1: coordinator want to approve project title Step3:display project title approval form
Step2: select the approve project title page. Step5: validate the input
Step4:fill the forms and submit it Step6:display successful message
Table 9Main Course of Action for Return Response

Step6: Displays try again from basic course action step4
Name: View Mark

UC_ID: UC_005
Include: Login
Actor: Coordinator, Student, Advisor
Description: This use case is seen by Coordinator, Student, and Advisor when they want to
view the result of the project grade finally.
Pre-Conditions: The Examiner should first assign mark and coordinator, Student, and
Advisor login to the system first.
Post-conditions: Coordinator, Student, and Advisor views mark assigned by examiner.
Step 1: Coordinator, Student and Step3: the system displays the assigned
Advisor want to view mark. mark
Step2: The user selects view mark Step 4: the use case process end
button.
Table 10Main Course of Action for View mark
Alternative course action:

Step3: the system does not display the mark if not assigned by examiner.
Name: Manage Project Detail
UC_ID: UC_006
Actor: Coordinator
Page | 25
Include: Login
Description: This use case is done by the coordinator when he/she wants to manage task or
records all project related data.
Preconditions: Coordinator has to login to the system when he/she wants to manage
task/project.
Post conditions: The task information or project detail will be recorded to the database of the
system.
Main course of action for adding project detail:

Step1: coordinator wants to add project Step3: the system displays types of
detail to the system. management.
Step2: coordinator select manage project Step5: the system display project detail
link. adding form.
Step4:coordinator selects Add project Step7: the system validates information.

button Step8: the system displays a message
“project successfully added”.
Step6: coordinator fill the form click add
Step9: end the system.
project.
Table 11Main Course of Action for adding project
Step 8: the system display project is not added.

Step9: the system displays “fill form again” message from basic course of action step6.
Name: Generate Notification
Actor: Coordinator
UC_ID: UC_007
Include: Login
Description: The system will generate notification that will be sent to selected users
Preconditions: Coordinator should have to login.
Post condition: A notification is generated and sent to selected users timelines
Page | 26
Main course of action for Generate Notification:
Step1: Coordinator select the generate Step 2:System displays generate

notification link. notification form
Step 3:fill the forms and click send it Step 4:validate the form and
button Step5: display successful message
Table 12Main Course of Action for Generate Notification.

Step5: Displays try again from basic course of action step3
Name: Submit Project Title

UC_ID: UC_008
Include: Login
Actor: Student
Description: the student does this process when they need to submit project title.
Preconditions: The student has to login to the system and they have to fill the project
submission form correctly.
Post conditions: The student will sent project submission form.
Main course of action
For submit project title:
Step1: student wants to submit project Step 3:displays project title submission
title. form.
Step2: select submit project title page Step6:validate the input
Step4: fill the all required information Step7: display the success message
Step5: click on submit button
Table 13Main Course of Action for submit project title
Page | 27

Step7: system displays a try again message from basic course of action step4
Name: View Task
UC_ID: UC_009
Include: Login
Actor: Coordinator, Advisor and Student
Description: This use enable student, coordinator and advisor to view project that advisor
and student works on and the project that was done before.
Preconditions: The Task should be uploaded first.
Post conditions: The users able to see the available project information.
Step1:userwants to view the project/task Step3:display task available

detail. Step5:The use case ends.
Step2:The user select view task page.
Table 14Main Course of Action view task
Alternative course action:

If task is not uploaded
Step3: The system displays no task available
Name: Check Status
Actor: Student
Include: Login
UC_ID: UC_010
Include: Login
Description: the student does this use case when they want to see the approval or
disapproval of the project title by coordinator.
Precondition: the student should submit the project title first and coordinator should approve
it.
Page | 28
Post condition: the student receives an approval response or disapproval message.
Main course of action are:
Actor Action System Response
Step1: the student wants to check status. Step 3:display information either approval or not
Step2: the student selects the check status page Step5: the process ends.
Step4: the student views the response.
Table 15Main Course of Action for check status
Name: Schedule Meetings

Actor: Advisor
UC_ID: UC_011
Include: Login
Description: Advisor will set meeting schedule for students to meet
Preconditions: Advisor is logged in and is assigned to groups
Post condition: A meeting notification is sent from advisor to selected user
Main course of action for schedule meetings are:
Step1: Advisor wants to schedule Step 2: the system displays schedule

meeting for student and click on meeting form
schedule meeting. Step5: System generates a meeting
Step3: Advisor fills meeting forms. notification and sends it to respective
Step4: Advisor submits the form. groups
Table 16Main Course of Action for schedule meetings

If Advisor entered wrong input
Step5: Systems does not send notifications and fill again from basic course of action step3
Page | 29
Name: Assign Mark

Actor: Examiner
UC_ID: UC_012
Include: Login
Description: This use case enable examiner to grade students or assign mark/result to the
project
Preconditions: Examiner is logged in to the system and student must present their work first.
Post condition: A group has been successfully graded or mark assigned.
Main course of action for assign mark are:
Step1: Examiner wants to assign mark. Step3: System display assigning mark
Step2:Examiner selects assign mark form.

pageStep4:Examiner fills the form and Step5:System validates inputs.
submits it. Step6:System sets the grade for selected
group
Table 17 Main Course of Action for assign marking.

Step4: Examiner enters wrong input in Grade
Step6: Systems does not sets grade and try again from basic course of action step4
Name: Send Advising Request

Actor: Coordinator
UC_ID: UC_013
Include: Login
Description: this use case enables system admin to send advising requestto advisor
Preconditions: The user must be registered and admin log in to the system
Post condition: Advising request is sent to advisor.
Main course of action for sending advising request:

Page | 30
Step1:the coordinator wants to send Step2: the system display home page
advising request to advisor Step4:the System display send advising
Step3:the coordinator select send request form.
advising request from home page menu Step6: the system display “request sent
Step5:coordinator fill send advising ”message
request form and submit it
Table 18Main Course of Action for sending advising request:

Step5: If the coordinator enters wrong data
Step6: The Systems display request does not sent and try again from basic course of action
step5.
Name: Send Examining Request

Actor: Coordinator
UC_ID: UC_014
Include: Login
Description: this use case enables coordinator to send examining request to examiner.
Preconditions: The user must be registered and login to the system
Post condition: Examining request is sent to examiner.
Main course of action for sending Examining request:
Step1: coordinator want to send Step3display form to send examining

examining request to examiner request
Step2: coordinator select send Step4: validate the input information

examining request page Step5: the system display “request sent
Step4: coordinator fills form and ”message to user
submits it.
Page | 31
Table 19Main Course of Action for sending examining request

Step4: If the coordinator renters wrong information
Step5: The Systems display request does not sent and try again from basic course of action
step4.
Name: Approve Advising Request

Actor: Advisor
UC_ID: UC_015
Include: Login
Description: This use case enable advisor to approve advising request that sent to them by
coordinator.
Preconditions: Request must be sent to him/her.
Post condition: Advisor approves or disapprove request.
Main course of action for approving advising request:
Step1:advisor want to approve advising Step3: display approval request form to

request advisor.
Step2: Advisor select approve request Step:4 validate the input

from home page menu Step5: the system display “request
Step4:the advisor fill approval form and approved” message
submit it
Table 20Main Course of Action for approve advising request

Step4: if user enters wrong data
Step5: Systems display request does not sent approved and try again from basic course of
action step4.
Name: Approve Examining Request

Actor: Examiner
Page | 32
UC_ID: UC_016
Include: Login
Description: This use case enable examiner to approve examining request that sent to them
by coordinator.
Preconditions: Request must be sent to him/her.
Post condition: Examiner approves or disapprove request.
Main course of action for approving examining request:
Step1:examiner want to approve Step3:display examining approval form

examining request Step5:validate the input.
Step2:the examiner select approve Step6: the system display “request
request from home page menu approved” message
Step4:the examiner fill approval form
and submit it.
Table 21Main Course of Action for approving examining request

Step4: If the examiner enters wrong data or information
Step6: Systems display request does not approved and try again.
Name: Evaluate Task

Actor: Advisor
UC_ID: UC_017
Include: Login
Description: Advisor able to evaluate task that student upload to them.
Preconditions: Student must be upload task
Post condition: The task is evaluated by advisor.
Page | 33
Main course of action for evaluating task:
Step1:advisor enter to his/her account Step2: the system display home page
Step3:advisor select evaluate task from Step4:the system display uploaded task
home page menu and form to evaluate task.
Step5: Advisor view task and fill Step6: the system display “task is
evaluate form and submit it. evaluated” message
Table 22Main Course of Action for evaluating task

Step5: If the advisor enters wrong data or information.
Step6: the Systems display task does not evaluated and try again.
Name: Assign Task

Actor: Advisor
UC_ID: UC_018
Include: Login
Description: Advisor able to assign task to student.
Preconditions: Advisor must be assigned to a group
Post condition: Advisor assign task to student.
Main course of action for assign task:
Step1: advisor wants to assign task Step3:display task assigning form
Step2: advisor select assign task page Step5:validate input
Step4:Advisor fill assign task form and Step6: the system display “task is
submit it. assigned” message
Step7: use case ends
Table 23Main Course of Action for assign task

Page | 34
Step4: If the advisor enters wrong data or information.
Step6:Systems display task does not assigned and fill again.
Name: Submit Task

Actor: Student
UC_ID: UC_019
Include: Login
Description: This use case enables student to submit task to advisor.
Preconditions: Student must be given a task to do.
Post condition: Student submit task to advisor.
Main course of action for submit task:
Step1:student wants to submit task to Step3: the system display form to

advisor submit task.
Step2:student select submit task page Step6:validate inputs
Step4: student fill submit task form. Step7: the system display “task is
Step5: student click submit button. submitted” message
Table 24Main Course of Action for submitting task

Step7: If the student enters wrong data or information.
Step7: the Systems display fill again from basic course of action of step4.
Name: Assign Advisor

Actor: Coordinator
UC_ID: UC_020
Include: Login
Description: This use case enables coordinator to assign advisor by referring their
performance and interesting area..
Preconditions: Advisors performance and interesting area must be registered.
Page | 35
Post condition: Coordinator assign advisor to student.
Main course of action for assigning advisor:
Step1:coordinator want to assign Step3: the system display advisors

advisor profile
Step2: Coordinator view advisor profile

from manage project detail
Step4: Coordinator view project detail

and assign advisor to the group.
Table 25Main Course of Action for assigning advisor
Name: Assign Examiner

Actor: Coordinator
UC_ID: UC_021
Include: Login
Description: This use case enables coordinator to assign examiner by referring their
performance and interesting area from project detail.
Preconditions: Examiner performance and interesting area must be registered.
Post condition: Coordinator assign examiner to student.
Main course of action for examining examiner:
Step1:coordinator want to assign Step3: the system display advisors

examiner profile
Step2:Coordinator view examiners

profile from manage project detail
Step4: Coordinator view project detail

and assign examiner to the group.
Table 26Main Course of Action for assigning examiner
Page | 36
Name: Send Comment

Actor: Advisor
UC_ID: UC_022
Include: Login
Description: This use case enable advisor to send comment to student after viewing task that
student working on
Preconditions: Student must submit task.
Post condition: Advisor sent comment to student.
Main course of action for sending comment:
Step1:advisor want to send comment Step3: the system display comment
Step2:advisorselect send comment page sending form
Step4: Advisor comment and fill the Step6: validate inputs

form. Step7: the system display “comment is
Step5: Advisor click send button. sent” message.
Table 27Main Course of Action for sending comment
Name: View Comment

Actor: Student
UC_ID: UC_023
Include: Login
Description: Student able to view comment given to them by advisor.
Preconditions: Advisor must send comment.
Post condition: Student view comment.
Main course of action for viewing comment:
Page | 37
Step1: student enter to his/her account Step2: the system display home page
Step3: student select view comment Step4: the system display comment
button from home page menu. Step5: the use case ends
Table 28Main Course of Action for viewing comment
Name: Download File
Actor: Student
UC_ID: UC_024
Include: Login
Description: Student able to download previous done project that is uploaded by student and
added by coordinator.
Preconditions: File must be uploaded by student or added by coordinator.
Post condition: Student download project file.
Main course of action or downloading file:
Step3: student select download button Step4: the system display download
from home page menu option
Step5: student select file they want to Step6: the system display message “file
download and click on download file. is downloaded”
Step7: use case ends.
Table 29Main Course of Action for downloading file
Name: Upload File

Actor: Student
UC_ID: UC_025
Include: Login
Description: Student able to upload project that they are working on after finishing it
Preconditions: Student must finish their work before upload it.
Page | 38
Post condition: Student upload project file.
Main course of action for uploading file:
Step3: student select upload page Step4: the system display upload option
Step5: student select file they want to Step6: the system display message file is
upload and click on upload file. uploaded.
Step7: use case ends
Table 30Main Course of Action for uploading file
Name: Search Project File

Actor: Student
UC_ID: UC_026
Include: Login
Description: This use case enables student to search the project that was done before in order
to identify whether it was done or not and to refer it.
Preconditions: Project must be added to the system by coordinator or uploaded by previous
student.
Post condition: Student able to get project file.
Main course of action for searching project file:
Step1:student want to search project Step3: the system display search form
file Step5: the systems search information
Step2: student select the search page and request database
from home page menu Step6: The system displays file that is
Step4: student insert data or file they required.
want to search and select the search Step7: The use case ends.
button.
Page | 39
Table 31Main Course of Action for searching project file

Step6: If the required file is not available the system displays no file available.
3.4.3 Sequence Diagram
Sequence diagrams show a succession of interaction between classes or object instances over
time. It also shows the processing described in a single scenario. It describes interaction
among classes in terms of an exchange of message overtime. It is a good way to visualize and
validate various runtime scenarios.
Figure 2Sequence diagram for login
Page | 40
Figure 3Sequence diagram for submit project title
Figure 4 Sequence diagram for submit task
Page | 41
Figure 5 Sequence diagram for search project detail
Page | 42
Figure 6 Sequence diagram for assign tasks
Page | 43
Figure 7 Sequence diagram for assign mark
Figure 8 Sequence diagram for sending advising request
Figure 9 Sequence diagram for sending examining request
Page | 44
Figure 10 Sequence diagram for adding project detail
Page | 45
Figure 11 Sequence diagram for generate notification
Figure 12 sequence diagram for evaluation task

3.4.4 Activity Diagram
Activity diagram is another important diagram in UML to describe dynamic aspects of the
system. Activity diagram is a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system. So the control flow is
drawn from one operation to another. This flow can be sequential, branched or concurrent.
Activity diagrams deals with all type of flow control by using different elements like fork,
join etc.
The purposes of activity diagram can be described as:
 Draw the activity flow of a system.
 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.
Page | 46
Figure 13 Activity diagram for login form
Page | 47
Figure 14 Activity diagram for advisor evaluating task
Figure 15 Activity diagram for view task
Page | 48
Figure 16 Activity diagram for manage user
Figure 17 Activity diagram for approval request
Page | 49
Figure 18 Activity diagram for creating project group
Figure 19 Activity diagram for generate notification
Page | 50
3.4.5 Class Diagram
Class diagrams in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system's classes, their
attributes, operations (or methods), and the relationships among the classes. [3] The classes
diagrams are widely used in the modeling of object oriented systems because they are the
only UML diagrams which can be mapped directly with object oriented languages. The class
diagram with its corresponding objects will be present in the following diagram.
Page | 51
Figure 20 class diagram for final year project monitoring system
Page | 52
3.4.6 User Interface Design
User interface design is the overall process of designing how a user will be able to interact
with a system. The goal of user interface design is to make the user's interaction as simple
and efficient as possible. User Interface Design (UID) focuses on anticipating what users
might need to do and ensuring that the interface has elements that are easy to access,
understand, and use to facilitate those actions.
Figure 21 User interface design for home page
Page | 53
Figure 22 User interface design for login
Page | 54
Figure 23 User interface design for advisor page

3.4.7 User Interface Prototype
System that we are proposed has user interfaces that make the user to communicate easily
with the system and it makes the new user to identify what the system user works easily [4].
As a team we attempt to show this interface in general as follows:-
Page | 55
Figure 24 User interface prototype
Page | 56
CHAPTER FOUR
SYSTEM DESIGN
4.1 INTRODUCTION
System design is the transformation of the analysis model into a system design model. Up to
now we were in the problem domain. System design is the first part to get into the solution
domain in a software development. This chapter focuses on transforming the analysis model
into the design model that takes into account the non-functional requirements and constraints
described in the problem statement and requirement analysis sections discussed earlier. In
this chapter we try to describe the Purpose of the system design document (SDD),
architectural design, Logical View of the Architecture, deployment View and database
design.
4.1.1 Purpose Of The System Design Document
The purpose of designing this final year project monitoring system is to show the direction
how the web page is built and to obtain clear and enough information needed to drive the
actual implementation of our web page. It is based on understanding of the model the web
page built on system design and also focuses on decomposing the system in to manageable
parts.
During system design we concentrate on the process of data structures and software and hard
ware components necessary to implement the system.
4.1.2 Scope Of The Project
As a system we identified the scope of the project which determines what we include or not
include in our system based on the triplet project condition (scope, time and cost) that
incurred in the project implementation process. The system (final year project monitoring
system) is a system that we are going to implement it only for Hawassa university faculty of
informatics. The system is limited to Hawassa University faculty of Informatics students and
staff members to simplify the work of project monitoring system and to make
communication between the student, advisor and coordinator platform.
Page | 57
4.2 SYSTEM ARCHITECTURE DESIGN

The system architecture is designed on the basis of the context of the system in accordance
with the principles of architectural design as well as domain knowledge. It is the architecture
that determines the type of interactions that the components are going to have interaction. It
uses Client/Server architecture. In this type of architecture the server is responsible to receive
a request from the client and respond to the request; on the other hand the client is
responsible to interact with that of the users of the system..
Description of the architecture of the system is described as follows. Clients are responsible
for:-
 Provide user interface to the user enabling to get services

 Receiving inputs from user
 Checking range of performance
 Initiating database transactions once all necessary data are collected.
Server responsible for:-
 Transaction performance
 Guaranteeing the integrity of data.
 Putting backup of the database
Figure 25 system architecture design
Page | 58
4.2.1 Sub System Decomposition
Sub system decomposition is needed to the system clear and understandable by dividing the
whole system in to sub systems and components. In the subsystem component decomposition
we try to show the relationship between the components.
Figure 26 Sub system decomposition

4.2.2 Deployment Modeling
Deployment diagrams model the physical architecture of a system, and it shows the
relationships between the software and hardware components in the system and the physical
distribution of the processing The deployment diagram also helps to model the physical
aspect of an object-oriented software system. It models the run-time configuration in a static
view and visualizes the distribution of components in an application. In most cases, it
Page | 59
involves modeling the hardware configurations together with the software components that
lived on.
Deployment modeling used to show the hardware of the system, the software that is installed
in the hardware and also the middleware that is used to connect the disparate machines to one
and other. It also shows how the software and the hardware components work together.
Figure 27 Deployment Diagram

4.2.3 Database Design
This portion is aimed to indicate the database structure. Database is essential for the storage
and management of data. [5] Since this is the design, we have put here normalization of the
database and general database table structure.
Page | 60
Database Normalization
Database normalization is used to remove more than one value in a single cell, to remove
functional dependencies between table columns, to ensure full dependency of all columns on
the primary key. It can be first normal form, second normal form, third normal form or other
high-level normalization forms.
A. First Normal Form (1NF)
First normal is used to ensure that only a single value is recorded on a single cell of the
database table. Here, most of our relational schema structure is well thought of not having
such problems except customer and branch tables. Therefore, it can be used as first
normalized form except for those two tables.
Coordinator
Cord_I Fname Mnam Lname User_ User passwor Phone_No email

D e Type name d
Co/020/1 Abebe Tola Chala Admi Boss 1234 094011012 Boss@gmai

0 n 0, l.com
091106511
2
In the above tables the problem is that phone_No of coordinator is contain multiple value in
one cell. We have to create two columns for each attribute values as follows and we can
create other tuple for all columns to remove repetition of phone_No in one cell.
Normalized form
Cord_ID Fnam Mnam Lnam User_Ty usern passwor Phone_ email
Page | 61
e e e pe ame d No
Co/020/1 Abebe Tola Chala Admin Boss 1234 0940110 Boss@gmail

0 120 .
com
Co/020/1 Abebe Tola Chala Admin Boss 1234 0911065 Boss@gmail

0 112 .
com
B. Second Normal Form (2NF)
It is aimed to remove functional dependencies among different columns of the database table
and each attributes of a table fully depend on primary key. Our database has two tables that
are not in 2NF we can normalize them:
2NF
Coordinator1
Cord_ID Fname Mname Lname User_Type username password email
Co/020/10 Abebe Tola Chala Admin Boss 1234 Boss@gmail.com
Coordinator-Phone
Cord-ID Phone-No
Co/020/10 0940110120
Co/020/10 0911065112
Database normalization for coordinator
1NF Advisor
Adv- fnam mn Lna Use Us pass Phone no Perfo Expe specializat

ID e ame me r- er word rman rienc ion
Page | 62
type na ce e
me area year
Adv/0 Kass Abd Yoh Stan Be 4567 091012413 Andro 5 Programme

12/10 ahun i anis dard ky 8 3,09171102 id r
44 App
Normalized form for advisor
Adv- fname Mna Lna User Us Pass Phone Perfor Exp Specializa
ID me me -type er- word no mance erie tion
na area nce
me year
Adv/0 Kassah Abdi Yoh Stand Be 45678 091711 Android 5 Programm

12/10 un anis ard ky 02 44 App er
Adv/0 Kassah Abdi Yoh Stand Be 45678 091012 Android 5 Programm

12/10 un anis ard ky 4133 App er
2NF for Advisor
Ad-ID Fnam Mna Lna User- Passw AD_ Exper specializa User
e me me type ord PA ience tion –
year name
Adv/012 Kassah Abdi Yoha Stand 45678 Andr 5 Programm Beky

/10 un nis ard oid er
App
Advisor-phone-no
Adv-ID Phone no
Adv/012/10 0910124133
Adv/012/10 0911065912
Page | 63
General database structure
Coordnator1
Attributes Data Length Constraint
Cord_ID Varchar 15 Primary key
Fname Varchar 15 NOT NULL
Mname Varchar 15 NOT NULL
Lname Varchar 15 NOT NULL
User_Type Varchar 15 NOT NULL
Username Varchar 15 NOT NULL
Password Varchar 10 NOT NULL
Email Varchar 20 NOT NULL
Cordinater_Phone
Cord_ID Varchar 15 Primary key
Phone_No Varchar 15 NOT NULL
Advisor table
Attributes Data type Length Constraints
Ad_id Varchar 15 Primary key
F_name Varchar 15 NOT NULL
M_name Varchar 15 NOT NULL
L_name Varchar 15 NOT NULL
User type Varchar 15 NOT NULL
Page | 64
Performance area Varchar 30 NOT NULL
Experience year Int NOT NULL
Specialization Varchar 30 NOT NULL
User name Varchar 10 NOT NULL
Email Varchar 20 NOT NULL
Advisor-phone-no
Adv_ID Varchar 15 Primary key
Phone_No Varchar 15 NOT NULL
Project group table
Attribute Data type Length Constraints
Group_no Int Primary key
Dept Varchar 15 NOT NULL
User name Varchar 10 NOT NULL
Ad_id Varchar 10 Foreign key
Exm_id Varchar 10 Foreign key
Cor_id Varchar 15 Foreign key
Project table
Attribute Data type Length Constraints
Page | 65
Pro_no Int Primary key
Pro_title Varchar 50 NOT NULL
Pro_type Varchar 20 NOT NULL
Pro_Ad_id Varchar 15 Foreign key
Pro_exm_id Varchar 15 Foreign key
Pro_start_date Date 20 NOT NULL
Pro_end_date Date 20 NOT NULL
Pro_status Varchar 20 NOT NULL
Student table
Attributes Data type Length Constraints
Stud_id Varchar 15 Primary key
F_name Varchar 15 NOT NULL
M_name Varchar 15 NOT NULL
L_name Varchar 15 NOT NULL
Sex Varchar 10 NOT NULL
Pro_no Int Foreign key
Dept Varchar 20 NOT NULL
CHAPTER FIVE
CONCLUSION AND RECOMMENDATION
5.1 CONCLUSION
Final Year Project Monitoring system is a web based system that aimed to change the
current manual system into web based final year project repository and tracking system.
The proposed system serves Faculty of informatics to increases the progresses of project
Page | 66
monitoring ways effective and qualifying the performance of the projects. The proposed
system improve final year project file management, increase staff effectiveness, save a
lot of project file from loss and decrease the time required to search the manual file,
reduce cost and improve the work efficiency by avoid the plagiarism and repetition of
titles by using this project and making platform communication between the staff and
student.
The proposed is composed of five chapters including conclusion and recommendation.
The introduction part is aimed to introduce the whole documentation concept generally. It
includes the major statement specification which allows us understand what initiated us to do
this project, the objective which used to specify what we are going to do, scope and
limitation, methodologies used to develop, time scheduling and cost estimating of the project.
Current system studying is about analyzing the existing system including its strength and
weakness. It is also about defining the proposed system and its advantages and goals. System
modeling is the place where the detail requirement analysis including the functional and non-
functional requirements are presented. It is transforming the analysis gathered and analyzed
into a representative model. Use cases, activity diagrams, sequence diagrams, a class diagram
and user interface prototype are used to do this.
System design is a process of transforming the system shown using system models into
design. Here the architectural design, deployment diagram, subsystems decomposition,
database structure and normalization are included.
5.2 RECOMMENDATION
The proposed system is practically proposed for Hawassa University Faculty of Informatics
staff members and students only and because of that reason the system does not work for
Hawassa University as a whole. In the future anyone who is interested to works on this “final
year project monitoring system “can able to take this start up projects as references and can
able to change the scope into the “Hawassa University Final Year Project and Research
Page | 67
Monitoring System” by requesting system developer and Hawassa University to raise fund
for the accomplishment of the project and works on it.
In the proposed system, we only considering or starting project monitoring activities from
title submission to the end of final presentation. That means we does not consider about
whether the student are learning or not. We simply take the student list in any means. But its
better if the students are registered first before they assigned to the project group and there
should be techniques that verifies whether the students are learning or not by adding head,
secretary and registrar offices as actor to identify the lists of presenting student.
6 REFERENCES
[1] Scott Ambler,. Computing Canada, July 21, 2000.

[2] Scott Ambler,. Computing Canada, July 21, 2000.
[3] David Cackowski, "Object Analysis in Organizational Design," Project Management
Page | 68
Journal, September, 2000.

[4] R. Buhr, "Machine charts for visual prototyping in system design," in Technical Report
88-2. Carlton University, August 1988.
[5] N. Gehani, "The Database Book," in Principles and practice using MySQL. 1st ed., 2006.
7 APPENDIX
FINAL YEAR PROJECT MONITORING SYSTEM QUESTINNARIES
As a team we prepare the following question to coordinator, advisor, senior teacher, and to
fresh teacher to collect data about existing/manual project monitoring system in HU School
of informatics and we politely request you to fill the answer of your choices and your
experiences.
Page | 69
1. What is final year project monitoring system in Hawassa university school of informatics?
A. Manual system B. Online system C. Both
2. In the above question If your answer is manual system; is manual system have ways of
prioritizing the submitted titles?
A. Yes B. No
3. Is manual system having successful evaluation method?
A. Yes B. No
4. Is the school having ways of preventing plagiarism?
A. Yes B. No
5. How the schools prevent project plagiarism?
A. By reviewing the previous project titles from manual documents.
B. By calling to previous advisors and ask in what scope and who was done the project.
6. In the above question number 5 if your answer is choice A; is reviewing from manual
document is good at time management?
A. Yes B. No
7. In the above question number 5 if your answer is choice B; is always the needed advisor is
always available or did you get full information from that advisor?
A. Yes B. No
8. How coordinator monitors communication ways between advisor and student?
A. No ways to monitor B. Weekly progress control C. Monthly progress control
9. How advisors are assigned to different project groups?
A. Randomly B. On their will C. By coordinators will D. Based on their performance area.
10. What is the strength and weakness of existing/manual system?
Page | 70

Monitoring PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Monitoring PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Final Year Project Monitoring System for HU Faculty of Informatics 2018

1.2 STATEMENTS OF THE PROBLEM

2. Identification and definition of the problem: - To identify what kinds of problems

1.4 SIGNIFICANT OF THE PROJECT

1.6 LIMITATION OF THE PROJECT

1.7.1 Data Collection Methodology

Primary data source

Document Analysis: we analyzed different documents of the last year project.

Preparing the questionnaire:- As a team we prepare some very important questionnaire to

Secondary data source

 Also referred other senior projects.

1.7.2 Testing Methodology

1.7.3 System Development Methodology

We used OOSAD because of the following important features:

1.7.4 System Development Tools

Software tools we are going to use are:

Java-Script: is a computer programming language used us in the development of scripts.

Hardware tools we are going to use are:

Computer: A machine that we are working on.

Paper: A4 type paper for designing diagrams.

Pen : We used to write on paper.

1.8 FEASIBILITY STUDY

Need of the feasibility study:

1.8.2 Operational Feasibility

1.8.3 Economical Feasibility

2. Increase Speed of activity.

Flash disk 1 180

Edraw max - Free

Sql server - Free

Apache server - Free

Table 1Cost Estimation

1.10 PROJECT PLAN ACTIVITY

S.No Phases Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase

5 Installation & Testing

-Start - To show the working time - End

 To minimize cost and time required to monitor the project.

2.4 WEAKNESS OF EXISTING SYSTEM

 The system boring to do with it.

 Limitation on information Retrievals: -The information is very difficult to retrieve

 Problem on information storage: - The information generated by various

3.2 FUNCTIONAL REQUIREMENT

Download File: Student able to download project file.

Search Project: This use case enables student to search project

Generate Notification: Coordinator will generate different notifications related to the

3.3 NON FUNCTIONAL REQUIREMENT

3.4.2 Use Case Diagram

User interface identification

UC-ID Activities Done Actor

UC-ID 001 LOGIN ALL

UC-ID 002 MANAGE USER ACCOUNT COORDINATOR

UC-ID 003 CREATE PROJECT GROUP COORDINATOR

UC-ID 004 APPROVE PROJECT TITLE COORDINATOR

UC-ID 005 VIEW MARK ALL EXCEPT EXAMINER

UC-ID 006 MANAGE PROJECT DETAIL COORDINATOR

UC-ID 007 GENERATE NOTIFICATION COORDINATOR

UC-ID 008 SUBMIT PROJECT TITLE STUDENT

UC-ID 009 VIEW TASK ALL EXCEPT EXAMINER

UC-ID 010 CHECK STATUS STUDENT

UC-ID 011 SCHEDULE MEETINGS ADVISOR

UC-ID 012 ASSIGN MARK EXAMINER

UC-ID 013 SEND ADVISING REQUEST COORDINATOR

UC-ID 014 SEND EXAMINING REQUEST COORDINATOR

UC-ID 015 APPROVE ADVISING REQUEST ADVISOR