Woldia University

Faculty of Technology

Department of IT

Industrial Project I:

A Project Submmited To Department Of Information Technology Partial Fulfilment Of

The Requirenments For The Degree Bachleor Of Science In Information Technology

Project Title: Facility Management System for Woldia University

Prepared by:

Members NameID NO

1. DenekewTizazu………………………………FOT(R) 1706/08

2. TibebuZeleke…………………………………FOT(R) 1893 /08

3. HabtamGolie……………………………….... FOT(R) 1793/08

4. BirhanuAlebachew……………………………FOT(R) 0069/07

5. ZintalemWubet……………………………... FOT(R) 1928/08

Advised by:

1. AndualemChekol.

2. BinyamEwunetu.

Jan-13- 2011

Woldia, Ethiopia
Group-3 WDU-FMS 2011 E.C

[Title]

Facility Management System for Woldia University

This page is needed to certify that this project paper is approved by the following list of
committee. It contains project advisor name, vice-advisor name, examiner1 name, examiner2
name and their unique signature for all responsible committees.

Name Signature Date

1. Advisor Name: ………………………….. ……………. …………

2. Vice-Advisor Name: …………………… …………….. ………….

3. Examiner Name: ………………………… ……………… ………….

4. Examiner Name: …………………………. ………………. ………….

5. Examiner Name:………………………….. ……………… …………..

5. Chairman: ………………………………… ……………… …………...

This project is our own and has not presented for a degree in any other places and sources of
this project material used for this project have been fully acknowledged. Name and signature
of the project group name are listed as followed.

NO Name ID Signature Date

1. Denekew Tizazu FOT(R) 1706/08 …………….. ……………..

2. TibebuZeleke FOT(R) 1893/08 …………….. ……………...

3. HabtamGolie FOT(R) 1793/08 …………….. ………………

4. BirhanuAlebachew FOT(R) 0069/07 ……………... ………………

5. ZintalemWubet FOT(R) 1928/08 …………….. …………….....

II
Group-3 WDU-FMS 2011 E.C

ACKNOWLEDGMENT
First, we would like to say thanks to God for giving us opportunity and effort as well as
initiate us to do this project and to complete this project. Then we would like to thank our
advisors Instructor BinyamEwunetu and Instructor AndualemChekol for their constructive
advising and willingness to participate in each part of our project and their effective
directions, assistance and guidance for the accomplishing of this project documentation.
Second, we also wish to thank Woldia University Facility Management System directorate
managerAtoBelete and W/roYeshalem who is secretary of property administration office for
giving us the required information about the current Facility management system.
Finally, we would like to thank the teaching staffs of Information Technology who have
contributed greatly to the success of this project.

III
Group-3 WDU-FMS 2011 E.C

ABSTRACT
This project concerned about Web-based Facility Management System of Woldia University.
Today the overall activities of the Facility Management System are under taken manually.
There repetitive and large activities like registering vehicle, registering Employee,
generating reports , generating vehicle report and Preparing vehicle schedule all this and
other tasks are conducted manually. In the manual System, there are number of inefficiencies
that face the system. Assigning office to employees is one of the foremost problems. It is very
difficult to get the overall employees, offices and vehicles information reports at one time.
Based on the above problem this project is to automate partially the existing manual system
and producing an automated or (Web-based) system. Generally the main goal of web-
basedfacility management system is to reduce existing system task errors, to reduce
redundancy of data, to improve the accuracy of input.

IV
Group-3 WDU-FMS 2011 E.C

Table of Contents
ACKNOWLEDGMENT.......................................................................................................... III
ABSTRACT .............................................................................................................................IV
LIST OF TABLES ................................................................................................................ VIII
LIST OF FIGURES .................................................................................................................IX
ACRONYMS/ABBRIVATIONS ............................................................................................XI
Chapter One ............................................................................................................................... 1
1. Introduction ........................................................................................................................ 1
1.1. Organizational Background............................................................................................. 1
1.2. Statement of the Problem ................................................................................................ 2
1.3. Objective of the project ................................................................................................... 2
1. 3.1. General objective ..................................................................................................... 2
1. 3.2. Specific Objectives .................................................................................................. 2
1.4. The significance of the project ........................................................................................ 2
1.5. Scope of the project ......................................................................................................... 3
1.6. Limitation of the project .................................................................................................. 3
1.7. Beneficiaries of the system ............................................................................................. 3
1.8. Methodology ................................................................................................................... 4
1.8.1. Fact Finding Techniques .......................................................................................... 4
1.8.2. System Development tools ....................................................................................... 4
1.8.3. System Development (design) model ....................................................................... 6
1.8.4. System Analysis and Design methodology .............................................................. 6
1.9. Feasibility of the project .................................................................................................. 7
1.9.1. Operational Feasibility ............................................................................................. 7
1.9.2. Technical Feasibility................................................................................................. 7
1.9.3. Economic Feasibility ................................................................................................ 7
1.9.4. Political feasibility .................................................................................................... 8
1.10. Work Breakdown Structure ........................................................................................... 8
1.11. Project Team Organization............................................................................................ 8
Chapter Two............................................................................................................................. 10
2. System Analysis ................................................................................................................... 10
2.1. Introduction to Existing System .................................................................................... 10
2.2. Overview of Activities of the Existing System ............................................................. 10
2.3. Problem analysis in Existing system ............................................................................. 11

V
Group-3 WDU-FMS 2011 E.C

2.4. Alternative Solutions ..................................................................................................... 11

2.5. Business rules for the Existing System ......................................................................... 11
2.6. Forms used in the Existing System ............................................................................... 12
2.6.1. A manually Registration Paper for Facilities ......................................................... 12
2.6.2. A form for Property Issued ..................................................................................... 13
2.6.3 Requesting Paper for facility ................................................................................... 15
2.7. Generated Reports of the Existing System .................................................................... 15
Chapter Three........................................................................................................................... 17
3. Requirement Elicitation for the New Proposed System ...................................................... 17
3.1 Overview of the Proposed System ................................................................................. 17
3.2. Functional Requirement ................................................................................................ 17
3.3. Nonfunctional Requirement .......................................................................................... 18
3.4. Functional Requirement Modeling................................................................................ 19
3.4.1. Use Case Diagram of the System ........................................................................... 19
3.4.2. Actor Description ................................................................................................... 20
3.4.3. Use case Description .............................................................................................. 22
3.4.4. Class Diagram of the system .................................................................................. 34
Chapter Four ............................................................................................................................ 35
4. Analysis Modeling ............................................................................................................... 35
4.1Sequence Diagram........................................................................................................... 35
4.2 Activity Diagram ............................................................................................................ 46
4.3 State Chart Diagram ....................................................................................................... 54
4.4. Collaboration Diagram .................................................................................................. 59
Chapter Five ............................................................................................................................. 63
5. System Design ..................................................................................................................... 63
5.1. Architecture of the System ............................................................................................ 63
5.2 Subsystem decomposition (package diagram of the system) ......................................... 64
5.4. Deployment diagram ..................................................................................................... 65
5.5. Persistence data modeling ............................................................................................. 67
5.6. Access control matrix .................................................................................................... 68
5.7. User Interface design Prototype .................................................................................... 70
Chapter six ............................................................................................................................... 72
6. Implementation .................................................................................................................... 72
6.1 User Interface ................................................................................................................. 72
6.2 Sample implementation .................................................................................................. 75
VI
Group-3 WDU-FMS 2011 E.C

6.2 Security level of Implementation ................................................................................... 76

6.3 Conclusion...................................................................................................................... 77
6.4 appendix ......................................................................................................................... 78
REFERENCES ........................................................................................................................ 80

VII
Group-3 WDU-FMS 2011 E.C

LIST OF TABLES

Table1. 1System development tools .....................................................4

Table1. 2Work Breakdown (schedule) .................................................8
Table1. 3Team Organizations ...............................................................9
Table3. 1Apply Registration Use case Description ............................22
Table3. 2Apply Updating Use case Description .................................23
Table3. 3Assigning vehicles Use case Description ............................24
Table3. 4Assigning offices Use case Description...............................25
Table3. 5 Managing Accounts Use case Description .........................26
Table3. 6View comments Use case Description .................................27
Table3. 7 Send request Use case Description .....................................28
Table3. 8 Prepare vehicle schedule Use case Description ..................29
Table3. 9View vehicle reports Use case Description .........................30
Table3. 10 View office or vehicle reports use case description .........31
Table3. 11 Login Use case Description ..............................................32

Table5. 1 Access Control Matrix ........................................................................ 69

VIII
Group-3 WDU-FMS 2011 E.C

LIST OF FIGURES

Figure1. 1Object oriented System Analysis and Design methodology ................ 7

Figure2. 1Model_19 manual registration forms for facilities (vehicle and

office). ................................................................................................................. 13

Figure2. 2A model_22 manual forms for property issued .................................. 14

Figure2. 3Employee requesting form ................................................................. 15

Figure2. 4A receipt reports for property received .............................................. 16

Figure3. 1Use case Diagram ............................................................................... 19

Figure3. 2Class diagram ..................................................................................... 34

Figure4. 1Sequence diagram for login ................................................................ 36

Figure4. 2Sequence Diagram for Register Vehicles........................................... 37

Figure4. 3Sequence Diagram for Register Offices ............................................. 38

Figure4. 4Sequence Diagram for Register Employee ........................................ 39

Figure4. 5 Sequence Diagram for View Vehicles information .......................... 40

Figure4. 6Sequence Diagram for View Offices information.............................. 41

Figure4. 7 Sequence Diagram for Create Account ............................................. 42

Figure4. 8Sequence Diagram for Deactivate Account ....................................... 43

Figure4. 9Sequence Diagram for Sending Vehicle Request .............................. 44

Figure4. 10Sequence Diagram for Sending Office Request ............................... 45

Figure4. 11Activity Diagram for Login .............................................................. 46

Figure4. 12Activity Diagram for Vehicle Registration ...................................... 47

Figure4. 13 Activity Diagram for Office Registration ....................................... 48

Figure4. 14Activity Diagram for Employee Registration .................................. 49

Figure4. 15Activity Diagram for Prepare Schedule ........................................... 50

IX
Group-3 WDU-FMS 2011 E.C

Figure4. 16Activity Diagram for Employee to send Vehicle Request ............... 51

Figure4. 17Activity Diagram for Employee to send Office Request ................. 52

Figure4. 18Activity Diagram for Employee to Create Accounts ....................... 53

Figure4. 19A state chart diagram for login ......................................................... 55

Figure4. 20A State chart Diagram to Register Vehicles..................................... 56

Figure4. 21A State chart Diagram to Register Office ........................................ 57

Figure4. 22A State chart Diagram to Register Employee .................................. 58

Figure4. 23Collaboration Diagram for login ...................................................... 59

Figure4. 24Collaboration Diagram to Create Account ....................................... 60

Figure4. 25Collaboration Diagram to Deactivate Account ................................ 61

Figure4. 26Collaboration Diagram to Register Employee ................................. 62

Figure5. 1 Architecture diagram ......................................................................... 64

Figure5. 2 Decomposition diagram..................................................................... 65

Figure5. 3 Deployment diagram ......................................................................... 67

Figure5. 4 Persistence data modeling ................................................................. 68

Figure5. 5 Home page of facility management system ...................................... 70

Figure5. 6 User login interface ........................................................................... 71

X
Group-3 WDU-FMS 2011 E.C

ACRONYMS/ABBRIVATIONS
NO Acronyms Stands For
1 CD Compact Disk
2 GB Giga Byte
3 PHP HyperTextPre-Processor
4 MS Word Micro Soft Word
5 IEEE Institute of Electricity and Electrical Engineering
6 OOSAD Object Oriented System Analysis and Design
7 SAD System Analysis and Design
8 UML Unified Modeling Language
9 CSS Cascading Style Sheet
10 HTML Hyper Text Markup Language
11 MYSQL Structured Query Language
12 WDU Woldia University
13 WDU-FMS Woldia University-Facility Management System
14 UC Use Case
15 DB Data Base
16 HRM Human Resource Management
17 P.Manager Property Manager
18 S.Manager System Manager
19 S.Admin System Administrator
18 INFO Information
19 Bs Bootstraps
20 EC Ethiopian Calendar
21 GC Gregorian Calendar

XI
Group-3 WDU-FMS 2011 E.C

Chapter One

1. Introduction
Technology is spreading its wings in almost every walks of human life activities. Now a day
it is better if every activity is done using new technology in order to fulfill the need of human
being, Organization, Enterprise etc. As today’s world there are many organizations and each
organization need to be preferable, computable, work on faster way in order to satisfy users
interest etc. That means they should have facilitated for their activities in computerized way.

Woldia University, employers use or get service (transportation, office, health service,
dormitory service) from the university itself. The university uses manual approach of Facility
Management System like scheduling the vehicles to give service, scheduling vehicle
maintenance, putting detail information of each vehicle and employee, office allocation for
new incoming employee and others. While giving those activities it stores the data in a file
paper which creates inefficiency in terms of access, track, and store information in the
working environment.

1.1. Organizational Background

Woldia University (WDU) is one of Ethiopian third generation Universities which was
established in the year 2004 E.C by the Ethiopian government. WDUis located in the
Northern part of Ethiopia, in Amhara regional state, North Wolo Zone, near Woldia town
which is 704.8 km far from Addis Ababa to the Woldia. The foundation of the University was
laid down in May 2000 E.C [1].

WDU started the teaching, learning Process on January 28, 2005E.C (2012 G.C) with
enrollment of 599students in the faculty of education in 12 departments with four faculties.
After three consecutive years’ i.e. 2007 E.C enrollment of WDU was 5387 Students.
Currently the University runs over 38 departments in first degree by the total of around15,
000 students. In addition to the academic service the university provides health care,
dormitory, community service, vehicle service, office allocation service for new incoming
employees and other services for the students as well as for employees. The University
nowadays is performing expansion and development plan which expects a combined effort of
different sectors with in itself. Being as one of the vital gain to the development plans vehicle
service and office allocation service plays a greater role with respect to quality education [2].

1
Group-3 WDU-FMS 2011 E.C

1.2. Statement of the Problem

In Facility management system all offices and vehicle servicing requests are conducted in
manual way and it is difficult to manage and control the system and difficulty to get the
required detailed information about specific vehicle, specific office and specific employee at
one place due to the presence of centralized database. It also takes time to prepare the
schedule for vehicles, additionally, Files are randomly processed. Beside of this, it is difficult
to find specificinformation about a certain facility. Updatingof employees, vehicles and office
status is not easy too. The other main problem is that the service requests are not getting fast
feedback as per their request (high time delay). Generally; there is data loss because of
improper data storage (no centralized database) for backup system.

1.3. Objective of the project

1. 3.1. General objective
The main objective of this project is to develop a web-based Facility Management System for
office and vehicles servicing of Woldia University.

1. 3.2. Specific Objectives

In order to achieve the general objective that we have mentioned above the project will have
the following specific objectives:

 Study the existing system and find out the problem. .

 Creating a Centralized database system for the proposed system.
 Making the system interface user interactive.
 Assigning office to employees automatically.
 Automatic assigning of vehicles to the requested employee.
 Preparing automatic vehicle schedule.
 Test our system until it will fit to the needs of the users. To prepare accounts search
form for system admin to get detail info about employee accounts by searching by
their ID.

1.4. The significance of the project

 Avoiding improper resource consumption (example paper, pen, time).
 Avoiding data loss because of improper data storage.
 Minimize cost of operations.
 Minimize time delay in getting information and service.
2
Group-3 WDU-FMS 2011 E.C

 Anyone (employee) who has privilege can get the detail info of the vehicles and offices
only by authorization. .

1.5. Scope of the project

As the working system makes use of manual operations in vehicle and office management
system therefore the scope of our project plans and targets in developing and implementing a
new web based or automated system to replace and solve the problems within existing
manual system.
The following are the scope of our project:
 Searching, updating and managing registered vehicles, employees and offices to give
efficient service timely.
 The system identifies the status of offices.
 The system prepares vehicle schedules for the requested employee automatically.
 Enabling the clients (employees) to submit their required request online.
 Storing data and information in the database.
 Registering the full profiles of employees, office and vehicles.
 System assigning new incoming employee (which are registered in HRM) to a
specific office as per his/her request automatically.

1.6. Limitation of the project

 The system excludes identifying the specific location of the vehicles and offices.
 Excluding Renewal of driver licenses & level assigning for vehicles.
 Excluding car rental service (does not give car rental service).
 Facility manager does not send SMS notification to drivers but, the manager notifies
them on their page on the browser.
 Woldia University Facility Management System is broad concept and it gives a lot of
broader services; so, we cannot include all the services available inside it. As a result,
we will concern on two issues of facility management system of Woldia University.
I.e. vehicle service system and office service system.
 Excluding punishments if needed on unethical employees (it will conducted offline).

1.7. Beneficiaries of the system

There are different bodies that will be benefited from this system. The main beneficiary of
this system is facility management office of WoldiaUniversity.Since; the manual system will
be changed to a computerized system, which improves the quality of internal operations as

3
Group-3 WDU-FMS 2011 E.C

well as services distributed between workers in the office. In addition, the problem associate
with manual processing is minimized and the quality of work and services become improved.
Additionally, the office will be highly benefited from the system because of the aspects such
as the system reduces delay time of answer (feedback) for requests, the vehicles will be
sorted in unique identification methods (ID), and vehicle scheduling will be highly processed
in digitally working system, offices will be registered in their unique identification number
(ID). The managers benefit of quick report generated by the system. And also, the team
members who develop this project will be highly beneficial because when the team works
this project, they will refer different sources and get different knowledge.

1.8. Methodology
To gather the requirement, the project team uses the following methodology which enables us
to successfully concern with our project.

1.8.1. Fact Finding Techniques

Interview: -we gathered information by asking personnel (AtoBelete)in facility management
office atWDU.
Document analysis:-To get more secondary source information and ideas about facility
management systems, we use project report documents which were done in the past and other
reading materials that will needed to develop this system [3].
Observation: We have observed property administration office of Woldia University and
facility management system. From property administration office, we have seen that all
facilities like vehicles, offices and other all types of facilities are registered by property
administration manager. Finally the list of all facilities which have been registered at property
administration office will be sent to facility management office in order to give service. On
the other hand employees are registered by HRM. Unless they are not registered at HRM,
they are not legal employee.

1.8.2. System Development tools

While developing the project starts from the documentation to the implementation, we will
use the following case tools:
Table1. 1System development tools

4
Group-3 WDU-FMS 2011 E.C

Activities Tools
Documentation MS word 2007 and MS Word 2010, IEEE
Design Microsoft Visio 2007, Edraw Max
Editing Paint, snipping tool, notepad ++, notepad,
dream waver, wamp server
Script languages PHP, JavaScript, CSS, HTML
Data base Server MySQL database
Hardware used
 2GB RAM
 80GB hard disk
 CD 700 MB
Definitions of tools:
Microsoft Word 2007/2010: -we have used Microsoft word for documentation purpose (to
write all the necessary documents about our project).
IEEE: -Institute of Electronics and Electrical Engineering reference style in order to avoid
unnecessary resource plagiarism.
Editing:
Microsoft Visio 2007: -This software is used because we need to construct the total work
break down or task schedule from beginning to ending of our project.
EdrawMax: - Since, all the actors inside our project have their Owen tasks to perform, so to
Shaw their tasks in diagram we use edrawmax software for drawing purpose. This software is
preferable to draw use case, sate chart, sequential, deployment and other diagrams.
Design:
Snipping tool: - For screenshot purpose of images, drawings or pictures.
Paint: - For any painting of pictures, drawings, images or anything else in our project.
Notepad, Notepad++, Dreamweaver: -this software is used because of the editing purpose
of our php code.
Scripting Languages:
Php: -php is a server side, cross-platform technology and it came to mean “Hypertext
Preprocessor”. It is widely general-purpose scripting language that is especially suited for
dynamic web development and it can also have embedded into HTML (hypertext markup
language) [4].

5
Group-3 WDU-FMS 2011 E.C

Java script: - it is a code inside php tag used for validating, redirecting and instructing forms
that we have in our project.
Front Ends:
Cascading Style Sheet (CSS): -it is a small part of code that is saved externally out of a
certain php code which helps us to make our system user interactive.
Hypertext Markup Language (HTML): -it is used in order to make our project user
interactive and to construct forms for our project.
Back Ends:
MySQL server: this is used under our project because to create database and tables, to store
records inside the database provided, to retrieve necessary records from database.

1.8.3. System Development (design) model

Iterative: The Iterative model is repetition incarnate. Instead of starting with fully known
requirements, project teams implement a set of software requirements, then test, evaluate and
pinpoint further requirements. A new version of the software is produced with each phase, or
iteration. Rinse and repeat until the complete system is ready.Advantages of the Iterative
model over other common SDLC methodologies is that it produces a working version of the
project early in the process, and makes it less expensive to implement changes. One
disadvantage: Repetitive processes can consume resources quickly [5].

1.8.4. System Analysis and Design methodology

We use the object oriented approach which examines requirements from the perspective of
the class and objects found in the problem domain. The reasons that we use the object
oriented system analysis and design (OOSAD) approach are:

 We can inherit properties of the class that are defined in the super class.
 We can reuse methods for avoiding redundancy.
 The data and functions are encapsulated in the objects that help us for easily
debugging purpose.
 It enables us to comprehensively model a system before we develop it [6].

6
Group-3 WDU-FMS 2011 E.C

Figure1. 1Object oriented System Analysis and Design methodology

1.9. Feasibility of the project

1.9.1. Operational Feasibility
The system we will develop works onanyoperating system without any failure, and it will
provide the employees with high benefits of operational feasibility. The system will also taste
on different basis and mechanisms of tasting (unit testing and system testing) ofa module and
the team will build the system to fit any inquiries and expectations.

1.9.2. Technical Feasibility

The system will be developed by Object Oriented System Development architecture and
technique to draw any necessary diagrams about our system. And the team tried to use
any methodologies at hand and developing the system with faire practice. The total
aggregated effort now makes the system to be technically feasible. The design is correct
and will meet the given requirement the products needed to build it are available and the materials
and techniques to implement it are known to work. It doesn’t violate some law of physics (say, needs
information to travel faster than light).

1.9.3. Economic Feasibility

The system we will develop is economically feasible and the benefit is outweighing the cost.
Generally, the system we will develop for facility management officewill bring a number of
Tangible and intangible benefits:

Tangible benefits:

 Reduction of paper and pen.

 Reduction of space needed to record data.

7
Group-3 WDU-FMS 2011 E.C

Intangible benefit:

 Give better and effective service

 Error reduction
 Increase security
 Increase speed of facility service
Since in this project we will try to computerize the existing system, the reduction of cost for
materials used in manual operation becomes beneficiary to the organization (WDU).

1.9.4. Political feasibility

Different concerned individuals such as the security, secretary and other employees of the
Woldia University will have good approach and view towards this project and they wish to
play an important role for the success of this system by giving good ideas to produce better
and efficient results. Our project does not bias to any political parties. It is neither supporter
nor oppose of any political parties and it is definitely neutral.

1.10. Work Breakdown Structure

Table1. 2Work Breakdown (schedule)

1.11. Project Team Organization

8
 Group-3 WDU-FMS 2011 E.C

Table1. 3Team Organizations

No Name ID NO. Responsibilities

Denekew Tizazu -Group coordinator
1. FOT(R)1706/08 -Testing & Coding
-Implementation
TibebuZeleke -V/Group coordinator
2. FOT(R)1893/08 -Documentation
-Designer
-Implementation
HabtamGolie. -Data gathering
3. FOT(R)1793/08 - Testing & Coding
4. BirhanuAlebachew FOT(R)0069/07 -Data gathering
5. ZintalemWubet FOT(R)1928/08 -Data gathering

9
Group-3 WDU-FMS 2011 E.C

Chapter Two

2. System Analysis
2.1. Introduction to Existing System
Currently the system WDU-FMS use paper based documentation or manual system approach
to record and to process its file. There are many activities and tasks that can be done by the
Manager, driver and technician, employee. Registering vehicles, registering offices,
assigningvehicles, assigning office and In this case they use material like pen, paper and
pencil to communicate and exchange data among each other. So, the use of manual system
approach consumes resource and time.Since the WDU-FMSis currently using the manual
approach their working process has no speed. For this reason, first the project team will try to
list the major activities that are currently performed by Woldia University Facility
Management System .Second the project team will use object oriented model and design to
represent the major activities of WDU-FMS.And finally the project team will try to list
alternative solution for the existing WDU- FMS.

2.2. Overview of Activities of the Existing System

 Vehicle registration: -When the new car will purchased, first it will be registered by
property administration manager of WDU and send to facility management office.
The manager fills the form and registers the new vehicle.
 Office registration: -When the new office will build, first it will be registered by
property administration manager of WDU and send to facility management office.
The manager fills the form and registers the new office.
 Employee registration: -First of all the employee are registered their profile at HRM.
The HRM manager checks the filled form and put it in a provided document finally
their data will be sending to the facility management office.
 Detail info (report) preparation:-detail info can be prepared in the form of paper
documentation from the work done (in a table format).
 Document collection: -data about facility management system are documented in
paper format.
 Assign Vehicle: - When employees need to get vehicle, they should tell their request
to the manager physically then the manager assigns vehicle to employees as per their
request.
10
 Group-3 WDU-FMS 2011 E.C

 Assign Office: -When employees need to get office, they should tell their request to
the manager physically then the manager assigns office to employees as per their
request. When the customers or employees forward the request service to the
manager, then the manager accept or reject request service.

2.3. Problem analysis in Existing system

Problem related to employee, vehicle or office data store: - When the data of registered
facilities stored; there is no suitable place to hold up the detail info about facilities. Because
of unstructured storage place or database, generating record information is not easy.

Problem related to retrieve information: - The main problem exists in the existing system to
retrieved information is that to search the needed facility to be retrieved.

Problem related to employee satisfaction: - Employees couldn’t get satisfaction due to the
reason of high time to process data and work load, because their work is harder since many of
their work is done manually.

Problem related time: - Employees consume more time to get services and to get required
information.

Proposed Solution: our proposed solution for the existing facility management system is to
develop partially automated facility management system using web based technology in order
to reduce the existing system problems.

2.4. Alternative Solutions

The current system has drawbacks that limit the functionality, performance, efficiency and
speed of the system because of the system operates manually. And it does not use the
available resources effectively. So, In order to overcome the current system problems that
exist in the functioning of the facility management system, our project team members have
put down alternative options. Some of these are:
 Automating the system using web based technology.
 Changing the whole manual system in to computerized system.
 Prepare centralized database for the proposed system.

2.5. Business rules for the Existing System

It is the collection of rule and regulation of the facility management system that shows which action
should be done and which is forbidden to do for the employee. The Business rules are statements

11
 Group-3 WDU-FMS 2011 E.C

about the facility directorate organization’s way of doing business and they reflect business
policies. Organizations have policies in order to satisfy the business objective, make good use of
resources, and conform to laws or general business conversions. The existing system includes the
following operating principles or business rules:

 When an employee need to transport must expect his/her request at the time of the
service.
 When an employee needs to get office, he/she must expect at the time of the
service.
 Every vehicle must have their unique identifier number.
 Every office must have its own unique identification number which uniquely
identifies it.
 Different paper forms and fields should be fulfilled by the respected body only.
 Every employee must be registered their detail profile at HRM to get facility
services and finally their profile send to facility management office.
 Recorded information can only be retrieved based on their unique ID.
 Facilities (vehicles and offices) must be registered at property administration
office.
 Drivers must view vehicle schedule to give proper transportation service to
employees

2.6. Forms used in the Existing System

There are many forms used in the existing system of facility management system.
Some of the forms used right in the existing system are:
 A manually registration paper form for facilities (including vehicles and
offices).
 A manual form used for sending request
 A manual information report paper about recorded facilities

2.6.1. A manually Registration Paper for Facilities

In facility management system of Woldia University, there is no specific manual registration

paper for vehicles and offices. All facilities are registered in the property administration
office of Woldia University.

12
Group-3 WDU-FMS 2011 E.C

Figure2. 1Model_19 manual registration forms for facilities (vehicle and office).

2.6.2. A form for Property Issued

This form is used in the existing system of facility management system to borrow properties.
This form is commonly known as model_22 receipts for articles of property issued.

13
Group-3 WDU-FMS 2011 E.C

Figure2. 2A model_22 manual forms for property issued

14
Group-3 WDU-FMS 2011 E.C

2.6.3 Requesting Paper for facility

There is no a specific requesting form in existing system of facility management system for
offices. A letter which includes requester’s (employee’s) name, department and time is used.

Figure2. 3Employee requesting form

2.7. Generated Reports of the Existing System

Since there is no a unique registration form for vehicles and for offices, so there is no report
forms for vehicles as well as for offices in the existing facility management system of woldia
university. But there is a report receipt that shows all about available facilities.

15
Group-3 WDU-FMS 2011 E.C

Figure2. 4A receipt reports for property received

16
Group-3 WDU-FMS 2011 E.C

Chapter Three

3. Requirement Elicitation for the New Proposed System

3.1 Overview of the Proposed System

The new system deals with automating all activities in the vehicle and office services of
Woldia university facility management system.

The newly proposed system is efficient in facilitating the tasks, like register vehicles,
registering employees, registering offices, give ID number for employees, give ID number for
all actors to identify them correctly and so on. The proposed system is also efficient in file
handling mechanisms, because it will have a centralized database. The major thing in the
proposed system is authenticated users that means Authorized one only access the system and
prevented by user name and password mechanism.

Proposed system can facilitate the following activity: -

 Register facilities (vehicles and offices) by property administration manager.

 Making the required update on registered facilities.
 Generate information about registered facilities.
 Give ID for any employees to identify them properly.
 Setting organizational information in organized manner.
 Retrieve the required data at required time.
 Automatic vehicle schedule preparation as per employee’s requests.
 Delegate employees to their provided office automatically.
 Calculate fuel balance to scheduled-approved incoming vehicles.

3.2. Functional Requirement

The proposed system will addressed the following functional requirements:

 Facility registration.
 Make necessary updating on records.
 Prepare automatic vehicle schedules as per employee’s requests.
 Managing user accounts.
 Generate information about registered facilities.
 Delegate office to legal employees with accordance of their requests.
17
Group-3 WDU-FMS 2011 E.C

 Enabling employees to send service request.

 Facility manager send notification (on browser) to drivers, if there is change in
vehicle schedule.

3.3. Nonfunctional Requirement

Anon-functional requirement is a requirement that specifies criteria that can be used to judge
the operation of a system, rather than specific tasks. This should be contrasted with functional
requirements that define specific task or functions. In this system user interface is designed
user-friendly by making our system menu based. Additionally this project will have session
and cookies for better controlling of users account that are logged into the system.
This system proposed to maintain the following non-functional standards towards -

 Accuracy
 Authorization restriction and privileges
 Security and usability of information
 Testability, maintainability

Error handling: -This system handles error done by users giving hint when he or she enters
wrong inputs.
Availability: - The system will available 7/24 hours with internet connection only.
Portability: - The system will work properly in any browsers and smart phones by using
bootstraps.
Reliability: - The system is better to increase the reliability of the Service if there is an
internet connection.
Security:-make the system secure using session and cookies for password and by using
database encryption and data backup, restore and recovery.
User Interface:-Describe the logical characteristics of each interface between the system and
the users. This may include any GUI standards or menu based interface, standard buttons and
functions that will appear on every screen, error message displayed, and so on. So this system
does these all functions in easy and efficient way.

18
Group-3 WDU-FMS 2011 E.C

3.4. Functional Requirement Modeling

3.4.1. Use Case Diagram of the System

Figure3. 1Use case Diagram

19
Group-3 WDU-FMS 2011 E.C

3.4.2. Actor Description

System Manager: -manager a person who can perform the following tasks:
 Login into the system.
 View the information of records.
 Sends necessary notices to the rest of system actors.
 Update on staff information.

System admin: -an admin is a person who has full knowledge about this system.
That he/she can:-
 Login into the system.
 Create accounts.
 Backup and recovery
 Activate and deactivate user accounts.
 View account.

Property Manager: a one who is responsible to register any properties in the property
administration office.

 Registration of offices and vehicle.

 Update necessary features on records.

HRM Manager: a person who is responsible for registering employees in the campus.

 Registering employees.
 Update on employee’s information.

Employee: - those are users of this systems or workers (employee) inside the campus.
 Login into the system.
 View information about vehicles or offices.
 Send comments to facility system manager.
 Send requests.
 View his/her user account.
 View their own vehicle schedules only (if he/she is department head and if he/she
has approved vehicle schedules).
 View their own office information if they are delegated.

Driver: - he/she is a person with a qualified ability of driving vehicles.

That he/she can:-

20
Group-3 WDU-FMS 2011 E.C

 Login into the system.

 View information about vehicles.
 View vehicle schedule.
 Send comments manager.
 View notification (on the browser) from facility manager if schedule is changed.
 View their own vehicle schedule privately that for whom and for what purpose that
their vehicle is scheduled to.
 View his/her own fuel balance report privately.

Scheduler: - an employee he/she can post schedules about the working of vehicles.

That he/she can:-

 Login to the system

 Calculate fuel balance
 Make necessary update on campus service schedules.
 View his/her user account.
 View information about vehicle.

21
Group-3 WDU-FMS 2011 E.C

3.4.3. Use case Description

Table3. 1Apply Registration Use case Description

Use case name Apply Facility Registration

Identifier UC1
Actor Property Manager
Description Vehicles and offices can be registered by property manager of property
administration office.
Aim/Goal To register/add office and vehicle records into the database.

Precondition  Facilities that going to be register must be checked by the

property manager to give full service and ready to registered.
 The manager should first open the system and he/she must be at
home page and he/she must continue to the basic course of action.
Basic course of action  P. Manager Action:  The System Response:
1. Open the home page.
2. Click login Button 3. Displays login form
4. Enter his/her username
5. Click on login button. 6.Checks entered values(valid/invalid)
7. Click on registration (Vehicle,
Office) link. 8. Display registration form
9. fill necessary information
11.Check values validity
10. Click submit button.
12. Registered successfully.

Alternative course  If step 6 incorrect, back to step 4.

of action  If step 11 not correct, back to 9.

Post condition  Registered successfully message will be displayed.

 Recorders will be saved to the database.

22
Group-3 WDU-FMS 2011 E.C

Table3. 2Apply Updating Use case Description

Use case name Apply Facility Updating

Identifier UC2
Actor Property Manager
Description Vehicles and offices record will be updated if necessary.

Aim/ Goal To make necessary update/changes on records, if needed.

Precondition  Property manager must check whether that facility has been
registered or not by searching it by its unique ID.
 The property manager should enter the valid facility ID which is
needed to make updating on it.
 Finally the property manager should be open the system and
he/she must be at home page to continue on the basic course of
action.
Basic course of action  P. Manager Action:  The System Response:
1. Open the home page.
3.Click login Button 2. Displays home page.
4. Enterusername, password.
6. Click on login button. 4. Displays login form.
7. Click on update (Vehicle,
Office) Link. 5. The system validates values.
9. Update the necessary records.
8. Displays update form.
10. Click submit button.
11. Validates values entered.

12. Updated successfully.

Alternative course  If step 5 becomes incorrect, system backs to step 4.

of action  If 11 will be incorrect, back to 9.

Post condition The property manager will update the records and submit to the database
successfully.

23
Group-3 WDU-FMS 2011 E.C

Table3. 3Assigning vehicles Use case Description

Use case name Assigning vehicles

Identifier UC3
Actor System
Description System can assign vehicle to employees.
Aim/ Goal To assign vehicles to the requested employee.
Precondition  First the system should fully healthy.
 Then the system should accepts employee vehicle request and get
necessary information from them.
 System should choose which vehicle to be assigned for why.
 System should check weather that vehicle is fully functional or
not.
 The system should also check if that vehicle is assigned for
another work.
 System must consider vehicle’s capacity to hold.
 Finally the system should also consider vehicle schedule.
Basic course of action System Actions:
1. Accept vehicle requests from employees.
2. Fetch all vehicle data from vehicle table, choose functional and free
(not scheduled vehicles).

3. Compare the number of the requested passengers with the capacity of

the selected vehicle.

4. If the requirements are fully checked, the system delegates vehicle to

the requested employee.

Alternative course  If step 2 incorrect, then request will be rejected.

of action

Post condition  Assigned successfully message.

 The system will assign vehicle for employees and submit to the
database.

24
Group-3 WDU-FMS 2011 E.C

Table3. 4Assigning offices Use case Description

Use case name Assigning offices

Identifier UC4
Actor System
Description Facility management system manager can assign office to employees.

Aim/ Goal To assign office to the requested employee.

Precondition
Basic course of action
Alternative course
of action
 First the system should be at fully healthy to continue with basic
course of action.
 Then system must accepts employee office request and get
necessary information from them.
 System should choose which office to be assigned for whom.
 The system should check whether the office is functional or not.
 The system should also check if that office is assigned for another
work.
 The system must check maximum office’s capacity to hold
employees inside it.
System Action:
1. Accept office requests from employees.
2. If the request is to get academic office/and or administrative
office,
3. The system fetches all registered academic/administrative office
data from academic/administrativetable; choose from
academic/administrative office as per the department of the
requester.
4. Check the maximum capacity of that academic/administrative
office.
5. If the requirements are fully checked, the system delegates
academic/and or administrative office to the requested employee.
 If there is no anymore registered academic/administrative office
yet, request will be rejected.

Post condition  Assigned successfully message

 The system will assign offices for employees and submit to the
database.

25
Group-3 WDU-FMS 2011 E.C

Table3. 5Managing Accounts Use case Description

Use case name Managing accounts

Identifier UC5
Actor System Admin
Description Accounts should be updated by system admin if necessary.

Aim/ Goal To make necessary updating on accounts.

Precondition  First system admin must be on his/her home page to continue on

the basic course of action.
 Then system admin must have lists of accounts from account table
which have been registered before.
 He/she must search which account to be updated through user
unique ID.
Basic course of action  The System Admin Action:  The System Response:
1. Open the home page.
3.Click login Button 2. Displays system home page.
5. Enter his/her username and 4. Displays login form
password. 7. Check values.
6. Click on login button. 8. Displays account manage
9. Click on manage account link.
page.
11. Make update onaccounts.
12. Click submit button. 10. Displays account updating
form.
13. Check the values.
14. Account updated.
Alternative course  If step 7 incorrect, back to step 5
of action  If step 13 not true, the system will back admin to step 11 and
continue.

Post condition  Updated successfully message

 The administrator will make necessary update on accounts and
submit to the database.

26
Group-3 WDU-FMS 2011 E.C

Table3. 6View comments Use case Description

Use case name View comments

Identifier UC6
Actor The System manager
Description Comments should be sent from employees and the manager can see
comments sent..
Aim/ Goal To view comments and to send feed backs.

Precondition  Comments must send from users first.

 The system manager must open the system and he/she must be at
home page to view comments.
Basic course of action  System Manager Action:  The System Response:
1. Open the home page.
3. Click login Button. 2. Displays home page.
5. Enter username and password. 4. Displays login form.
6. Click on login button. 7. Validate username & password.
9. View comments.
10. Click on send feedback link if 8. Displays view comment page.
necessary. 11. Displays feedback form.
12. Enter necessary feedback. 14. Validates entered values.
13. Press send button. 15. Comments sent.

Alternative course  If step 7 incorrect, then the system backs the manager to step 5.
of action  If step 14 becomes incorrect, nothing will happen and the manager
will back to step 12.

Post condition  Feedback sent successfully message will be displayed.

 Feedback will be recorded to the database.

27
Group-3 WDU-FMS 2011 E.C

Table3. 7Send request Use case Description

Use case name Send vehicle request

Identifier UC7
Actor Employee
Description Employees send request to the manager and the manager looks their
request information and assign vehicle.
Aim/ Goal To send vehicle request to manager in order to get transport services.

Precondition  First employees must be registered at HRM table.

 Employees must sure that he/she is at right request time.
 Then he/she must be on employee’s page to send vehicle request.
 An employee must view basic information about available
vehicles.
 He/she must be view vehicles schedule.
Basic course of action  The Employee Action :  The System Response:
1. Open the home page.
3.Click login Button 2. Displays home page.
5. Enter username and password. 4. Displays login form.
6. Click on login button. 7. Validates username & password.
9. Click on send request link.
11. Fill necessary information. 8. Displays employee page.
12. Click submit button. 10. Displays request form.
13. Validates entered values.
14. Vehicle request sent.
Alternative course  If step 7 not correct, back to step 5.
of action  If step 13 not true, nothing will happen but the process back to step
11 and continue.

Post condition  Request sent to manager successfully message.

 Request will be saved to the database.

28
Group-3 WDU-FMS 2011 E.C

Table3. 8Prepare vehicle schedule Use case Description

Use case name Prepare vehicle schedule

Identifier UC9
Actor System
Description The systemprepares schedules about vehicles by looking all necessary
information about vehicles.
Aim/ Goal To prepare vehicle schedule.

Precondition  First the system must well functional.

 At the time of that employees send vehicle schedule request, the
system automatically prepare schedule to the requester.
Basic course of action System Action:
1. Fetch necessary information from the requester employee.
2. At the time of assigning vehicle to the employee, the system
simultaneously prepares vehicle schedule.
3. Finally, the system requests scheduler to approve the schedule.

Alternative course  If there is no any request from employees, nothing happen.

of action
Post condition  Schedule will be saved to the database.

29
Group-3 WDU-FMS 2011 E.C

Table3. 9View vehicle reports Use case Description

Use case name View vehicle information

Identifier UC10
Actor Driver
Description The driver searches vehicle and view vehicle information.

Aim/ Goal To view necessary and detailed information about searched vehicle.

Precondition  The driver must be registered first.

 He/she must open the system and must be at the driver page.
 Vehicles should be registered.
 Driver should know vehicle ID to search.
Basic course of action  The Driver Action:  The System Response:
1. Open the home page. 2. Displays home page.
3. Click on login Button 4. Displays login form.
5. Enter username and password. 7. Check username , password
6. Click on login button. 8. Displays driver’s page.
9. Click on view vehicle reports link. 10. Display vehicle’s search
11. Click on search button. form.
12. Display Vehicle info.
13. Vehicle info displayed.
Alternative course  If step 7 is not correct, then back to step 5 and try again.
of action  If step 13 not true, nothing will be displayed but the process will
back to step 11 and continues.

Post condition  The driver finally views vehicle information.

30
Group-3 WDU-FMS 2011 E.C

Table3. 10View office or vehicle reports use case description

Use case name View office and vehicle information

Identifier UC11
Actor Employee and Property Manager
Description The employees can view detail information about vehicle or office by
searching the required vehicle or office by its ID.
Aim/ Goal To view necessary information about vehicles or offices.

Precondition  Employees and property manager must be registered and also they
must have their own account.
 Then offices and vehicles must be registered to the database.
 They should know the unique ID of office or vehicle to search and
view.
 Finally they must open the system and he/ she must be at their
home page.
Basic course of action  Actor Action:  System Response:
1. Open the home page. 2. Displays home page.
2. Click login Button. 3. Displays login form.
4. Enter username and password. 6. Checks username, password.
5. Click on login button. 7. Displays employee page.
8. Click on vehicle/office info link. 9. Vehicle/office info displayed.
Alternative course  If step 6 is not correct, backs to step 4 to try again.
of action
Post condition  Necessary information about vehicle/office will be displayed, and
an employee will view information.

31
Group-3 WDU-FMS 2011 E.C

Table3. 11 Login Use case Description

Use case name Login

Identifier UC12
Actor System Admin, System Manager,Employee,Driver,Scheduler, Property
Manager and HRM Manager
Description System Admin, System Manager, Employee, Driver, Scheduler, Property
Manager and HRM Manager can login in to their own page by typing
their username and password on login form.
Aim/ Goal To log into their own page and to perform their tasks.

Precondition  First of all each user must be registered to the central database.
 They must have their own user account which is registered to the
database.
 They must remember their username and password to login into
the system.
 Each user must be at their page only.
Basic course of action  The Actor Action:  System Response:
1. Open the home page. 2. Displays home page.
2. Click login Button. 3. Displays login form.
4. Enter username and password. 6. Checks username, password.
5. Click on login button. 7. Displays appropriate page.
10. Perform their task. 8. Select their task.
11. Finally click on logout button. 9. Displays appropriate form.
12. The system back to home
page
Alternative course  If step 6 is incorrect, back to step 4 to try again.
of action
Post condition  Necessary page will be displayed and an actor performs his/her
task.

32
Group-3 WDU-FMS 2011 E.C

Table 2.12 Use case Description to Register Employees

Use case name Apply Employee Registration

Identifier UC1
Actor HRM Manager
Description HRM manager is responsible for registering employees.

Aim/Goal To register/add employees into the database.

Precondition  Employees must give valid profiles to HRM manager to be

registered on to the database.
 The HRM manager should be open the system and he/she must be
at home page.
Basic course of action  HRM Manager Action:  The System Response:
1. Open the home page.
2. Click login Button 3. Displays login form
4. Enter his/her username
6.Checks entered values(valid/invalid)
5. Click on login button.
7. Click on registration 8. Display registration form
(employee) link.
11.Check values validity
9. fill necessary information
10. Click submit button. 12. Registered successfully.

Alternative course  If step 6 incorrect, back to step 4.

of action  If step 11 not correct, back to 9.

Post condition  Registered successfully message will be displayed.

 Recorders will be saved to the database.

33
Group-3 WDU-FMS 2011 E.C

3.4.4. Class Diagram of the system

Figure3. 2Class diagram

34
Group-3 WDU-FMS 2011 E.C

Chapter Four

4. Analysis Modeling

The purpose of modeling is to determine how the system is going to build and to obtain the
information needed to drive the actual implementation of the system. It focuses on
understanding the model how the software will be built. System modeling is the detail
investigation of our system. In this chapter we will try to study basic and important models
(diagrams) of our system, which can included sequence diagram, state chart diagram, activity
diagram and collaboration diagram [7].

4.1Sequence Diagram

A sequence diagram in a unified modeling language (UML) is a kind of interaction diagram

that shows how processes operate with one another and in what order. It is a construct of a
Message Sequence Chart. A sequence diagram shows object interactions arranged in time
sequence. It can show both the starting and ending time of each task in our system. It is one
of Unified Modeling Language (UML) [8].

35
Group-3 WDU-FMS 2011 E.C

Figure4. 1Sequence diagram for login

36
Group-3 WDU-FMS 2011 E.C

Figure4. 2Sequence Diagram for Register Vehicles

37
Group-3 WDU-FMS 2011 E.C

Figure4. 3Sequence Diagram for Register Offices

38
Group-3 WDU-FMS 2011 E.C

Figure4. 4Sequence Diagram for Register Employee

39
Group-3 WDU-FMS 2011 E.C

Figure4. 5 Sequence Diagram for View Vehicles information

40
Group-3 WDU-FMS 2011 E.C

Figure4. 6Sequence Diagram for View Offices information

41
Group-3 WDU-FMS 2011 E.C

Figure4. 7Sequence Diagram for Create Account

42
Group-3 WDU-FMS 2011 E.C

Figure4. 8Sequence Diagram for Deactivate Account

43
Group-3 WDU-FMS 2011 E.C

Figure4. 9Sequence Diagram for Sending Vehicle Request

44
Group-3 WDU-FMS 2011 E.C

Figure4. 10Sequence Diagram for Sending Office Request

45
Group-3 WDU-FMS 2011 E.C

4.2 Activity Diagram

Activity diagram is another important diagram in UML (Unified Model of Language) to

describe dynamic aspects of the system. Activity diagram is basically 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 [9].

The purposes of activity diagram can be described as:

 Describes the activity flow of the system.

 Describes the sequence from one activity to another.
 Describes the parallel, branched and concurrent flow of the system.

Figure4. 11Activity Diagram for Login

46
Group-3 WDU-FMS 2011 E.C

Figure4. 12Activity Diagram for Vehicle Registration

47
Group-3 WDU-FMS 2011 E.C

Figure4. 13Activity Diagram for Office Registration

48
Group-3 WDU-FMS 2011 E.C

Figure4. 14Activity Diagram for Employee Registration

49
Group-3 WDU-FMS 2011 E.C

Figure4. 15Activity Diagram for Prepare Schedule

50
Group-3 WDU-FMS 2011 E.C

Figure4. 16Activity Diagram for Employee to send Vehicle Request

51
Group-3 WDU-FMS 2011 E.C

Figure4. 17Activity Diagram for Employee to send Office Request

52
Group-3 WDU-FMS 2011 E.C

Figure4. 18Activity Diagram for Employee to Create Accounts

53
Group-3 WDU-FMS 2011 E.C

4.3 State Chart Diagram

It shows the sequence of states that an object goes through, the events that cause the
transition from one state to the other and the actions that result from a state change.
A state chart diagram is a view of a state machine that models the changing behavior of a
state. State chart diagrams show the various states that an object goes through, as well as the
events that cause a transition from one state to another [10].

The common model elements that state chart diagrams contain are:

States:A state represents a condition during the life of an object during which it satisfies
some condition or waits for some event.

Start state: It represents the starting point of a given action.

End states:It can show the last ending point of a given action/task.

Transitions: It is a symbol to show the flow of action from one state to another one.it carries
messages and communicates between states.

54
Group-3 WDU-FMS 2011 E.C

Figure4. 19A state chart diagram for login

55
Group-3 WDU-FMS 2011 E.C

Figure4. 20A State chart Diagram to Register Vehicles

56
Group-3 WDU-FMS 2011 E.C

Figure4. 21A State chart Diagram to Register Office

57
Group-3 WDU-FMS 2011 E.C

Figure4. 22A State chart Diagram to Register Employee

58
Group-3 WDU-FMS 2011 E.C

4.4. Collaboration Diagram

A collaboration diagram describes interactions among objects in terms of sequenced

messages. Collaboration diagrams represent a combination of information taken from class,
sequence, and use case diagrams describing both the static structure and dynamic behavior of
a system.

The UML Collaboration diagram is used to model how objects involved in a scenario
interact, with each object instantiating a particular class in the system. Objects are connected
by links, each link representing an instance of an association between the respective classes
involved. The link shows messages sent between the objects, and the type of message passed
[11].

The following are some examples of collaboration diagram:

Figure4. 23Collaboration Diagram for login

59
Group-3 WDU-FMS 2011 E.C

Figure4. 24Collaboration Diagram to Create Account

60
Group-3 WDU-FMS 2011 E.C

Figure4. 25Collaboration Diagram to Deactivate Account

61
Group-3 WDU-FMS 2011 E.C

Figure4. 26Collaboration Diagram to Register Employee

62
Group-3 WDU-FMS 2011 E.C

Chapter Five

5. System Design
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.
The purpose of designing is to show the direction how the system is built and to obtain clear
and enough information needed to drive the actual implementation of the system. It is based
on understanding of the model the software built on. The objectives of design are to model
the system with high quality. Implementing of high quality system depend on the nature of
design created by the designer. If one wants to change to the system after it has been put in to
operation depends on the quality of the system design. So if the system is design effetely, it
will be easy to make changes to it.

5.1. Architecture of the System

The architecture chosen for the system is three tiers. The first layer runs on the client side, the
second layer at the middle layer and the third layer will be the database system. The system
will run using web technology. This architecture provides greater application scalability,
flexibility, efficiency, lower maintenance, and reusability of components. Since each tier runs
on a separate machine, it improves systems performance.
The system uses dynamic web technology, i.e., adding and retrieving data to and from the
data store whenever requested is possible. It requires a client side program which is accessed
by the manager, by the driver, by the mechanic, by the employee, by the vehicle scheduler
and also an interface that communicate with the external system. It needs server side
functions that implement the functional requirements and the database system that stores
data.

63
Group-3 WDU-FMS 2011 E.C

Figure5. 1Architecture diagram

5.2 Subsystem decomposition (package diagram of the system)

Decomposition diagram shows a high level function, process, organization, data subject, area
or other type of object broken down into lower level, more detailed components. It may be
represent organizational structure or functional decompositions into processes. It provides
logical hierarchal decomposition of a system. It is used for reduce the complexity of the
system design or solution domain.

64
Group-3 WDU-FMS 2011 E.C

Figure5. 2 Decomposition diagram

5.4. Deployment diagram

The name Deployment itself describes the purpose of the diagram. Deployment diagrams are
used for describing the hardware components where software components are deployed.
Component diagrams and deployment diagrams are closely related.Component diagrams are
used to describe the components and deployment diagrams shows how they are deployed in
hardware. UML is mainly designed to focus on software artifacts of a system. But these two

65
Group-3 WDU-FMS 2011 E.C

diagrams are special diagrams used to focus on software components and hardware
components. So most of the UML diagrams are used to handle logical components but
deployment diagrams are made to focus on hardware topology of a system. Deployment
diagrams are used by the system engineers.The purpose of deployment diagrams can be
described as:

 Visualize hardware topology of a system.

 Describe the hardware components used to deploy software components.
 Describe runtime processing nodes.

66
Group-3 WDU-FMS 2011 E.C

Figure5. 3 Deployment diagram

5.5. Persistence data modeling

Persistence modeling is used to communicate the design of the database, usually the data base
to both the users and the developers. It is also used to describe the persistence data aspect of
the system. The following diagram indicates the persistence diagram of the system.

67
Group-3 WDU-FMS 2011 E.C

Figure5. 4Persistence data modeling

5.6. Access control matrix

Access control matrix deals with the access of different actors with their functionality or
activity. It helps us to control the access of our system. Individual actor may perform several
tasks as well as singe action may also perform by several actors. Access control matrix
realizes that which actor performs which activity in case of our system.

68
Group-3 WDU-FMS 2011 E.C

Table5. 1 Access Control Matrix

No Activities Actor names

System Syste HRM driver scheduler Property employe system
manage m manager e
r admin
1 Login       
2 Create account 
3 Activate account 
4 Deactivate 
account
5 Update record 
6 Assign office 
7 Accept employee r 
8 Assign vehicle 
9 System backup 
10 Register employee 
11 View employee 
information
12 View vehicle    
information
13 View vehicle   
schedule
14 Send comment  
15 Prepare vehicle 
schedule
16 Vehicle fuel 
balance
17 View office  
information
18 Register vehicle 
19 Register office 
20 Send 
transportation
request to
manager
21 Send office 
request to
manager
22 View record       
23 Send vehicle 
request to system
manager

69
Group-3 WDU-FMS 2011 E.C

5.7.UserInterface design Prototype

The user inter face prototype is used to explore an achievable and suitable user inter face
design. It helps us to test the user inter face design our system, including before the
development starts

Figure5. 5Home page of facility management system

70
Group-3 WDU-FMS 2011 E.C

Figure5. 6User login interface

71
Group-3 WDU-FMS 2011 E.C

Chapter six

6. Implementation
Implementation is an understanding of a technical specification or algorithm as a program
software component or other computer system through computer programming and
deployment. In our project, implementation exist for a given specification or stsndard.so the
team is in a position of converting all documents gathered and designed in to the code so that
the system will be implemented for the user to be used for the purpose it developed. To
implement it, the organization must have a server on which the system will be hosted because
this system can run on internet site with connection available or internet connection.

6.1 User Interface

In this system users will communicate with it through the following user interfaces.

I. Home Page: This form contains some links which lead it to the concerned page, and if
the user has an account he/she will directly go to concerned page by entering their
username and password.

Figure6. 1User interface home page snapshot

72
 Group-3 WDU-FMS 2011 E.C

II. Log In form:-This form found in home page and display when user press login button.
All users will have their own password. To inter the system and perform task user must
inter user name and password. The system check user account and open there page.

Figure6. 2User interface for login snapshot

73
Group-3 WDU-FMS 2011 E.C

Figure6. 3Account activates and deactivate snapshot

74
Group-3 WDU-FMS 2011 E.C

6.2Sample implementation
Sample implementation code for admin home page

75
Group-3 WDU-FMS 2011 E.C

6.2 Security level of Implementation

Sample implementation of login page

There are several types of security level for securing the system from attack. By using them it
is easy to prevent the system to be accessing by unauthorized users. We have used md5
(Message Digestion 5) for encrypting and decrypting password because of each and every
user must confident with their user name and password. In addition we have used backup the
database and restore it again.

76
Group-3 WDU-FMS 2011 E.C

6.3 Conclusion
The system “web based facility management system ” is developed to improve efficiently
and effectively the working habit of facility management system in Woldia university, that
is the current and crucial issue for today’s world. It is developed by using
PHP,MySQLandJavaScript. Thesystem allows sending office allocation request, then the
system check the employee and allocates office for that employee based on their
department and job level. The system allows preparing vehicle schedule for automatically
and also calculating fuel balance to protect the driver use woldia university car for his own
benefits. So the driver cannot use the car for himself because the system calculate fule
balance and time if the driver use out of calculatingfuel balance must have punishement.
The system can permit to office and vehicle request only registered employee. not only
office request send comment also permit for employee.

77
Group-3 WDU-FMS 2011 E.C

6.4 appendix
Interview questions
1. How many facilities are there inWoldia University?

2. How to allocate office for new employee currently?

3. How to prepare vehicle schedule?

4. Currently How to protect the driver if they use university’s car for own purpose?

Forms Currently Used

Property Registration Form

78
Group-3 WDU-FMS 2011 E.C

Report Form

Property Issuing Form

79
Group-3 WDU-FMS 2011 E.C

REFERENCES
1. Woldia University . [Online] [Cited: Dec-22-2011 Dec-22, 2011 e.c.] .www.wldu.edu.et
woldia university site/home page..

2.Woldia University public web Site. [Online] [Cited: Dec-22 22, Dec-22-2011 E.C.]
.www.wldu.edu.et woldia university site/home page..

3.[Online] [Cited: Dec-05-2011 E.C Dec-05, 2011 E.C.] [4]. Final Project on Car Rental
System/wolo University 2005 E.C.

4.HyperTextPreProcessor. PHP Page. [Online] [Cited: Jan-08 08, Jan-08-2011 E.C.]

[online].www.php.net/ Basics and Definitions .

5.SDLC Pages (Methods). Soft ware Developement Life Cycle web Site. [Online] [Cited: Jan-
13 13, Jan-13-2011 E.C.] [online].www.Basic SDLC Methodologies.com/By Robert
HalfNovember 21, 2017.

6.object oriented system analysis and design(OOSAD). OOSAD Page. [Online] [Cited: Oct-
29 29, Oct-29-2011 E.C.] [online]www.object oriented system analysis and
design.com/introduction.

7.unified modeling language. UML Page. [Online] [Cited: Jan-19 19, Jan-19-2011 E.C.]
[Google].www.google.com/Types of[ Unified Modeling Language (UML)]/Basics and
benefits..

8.UML [Sequence Diagram]. UML Page. [Online] [Cited: Jan-19 19, Jan-19-2011 E.C.]
[Google].www.google.com/Types of Unified Modeling Language (UML)-Sequence
Diagram-Definitions/Basics and benefits.

9.UML-[Activity Diagram]. UML-Page. [Online] [Cited: Jan-19 19, Jan-19-2011 E.C.]

[Google].www.google.com/Types of Unified Modeling Language (UML)-Activity-
Diagram/Definitions/Basics and benefits.

10.UML-[State Chart Diagram]. UML Page. [Online] [Cited: Jan-19 19, Jan-19-2011 E.C.]
[Google].www.google.com/Types of Unified Modeling Language (UML)-State Chart
Diagram-/-Definitions/Basics and benefits.

11.UML-[Collaboration Diagram]. UML Page. [Online] [Cited: Jan-19 19, Jan-19-2011 E.C.]
[Google].www.google.com/Types of Unified Modeling Language (UML)-[Collaboration
Diagram]/Basics and benefits..

80