My Project5

OROMIA STATE UNIVERSITY
COLLEGE OF SCIENCE AND TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY
Project Title:- Web Based Electronics Maintenance Management
System for Oromia State University.
BY :- Group 2
NAME OF THE STUDENTS IDNO

1. Jemal Mustefa------------------------------------------------------------PIT/E/2012/021
2. Tashela Remato--------------------------------------------------------- PIT/E/2012/033
3. Baba Tefu---------------------------------------------------------------- PIT/E/2012/006
4. Rehima Gemechu-------------------------------------------------------- PIT/E/2012/037
5. Chaltu Morke------------------------------------------------------------- PIT/E/2012/011
6. Uma Mustefa-------------------------------------------------------------- PIT/E/2012/034
Under the Advisor:- Instructor Feyisa Gemechu(MSc)
Oromia State University, Batu, Ethiopia

Month Date, Year
Web Based Maintenance Management System Page i

OROMIA STATE UNIVERSITY
COLLEGE OF SCIENCE AND TECHNOLOGY
DEPARTMENT OF INFORMATION TECHNOLOGY
Title Of Project: Web Based Electronics Maintenance Management
System For Oromia State University.
Submitted to Department of Information Technology, College of Science and

Technology, Oromia State University, in Partial fulfillment for the requirement of
the Degree of Bachelor Science in (Information Technology).
BY
NAME OF THE STUDENTS IDNO
1. Jemal Mustefa------------------------------------------------------------PIT/E/2012/021
2. Tashela Remato--------------------------------------------------------- PIT/E/2012/033
3. Baba Tefu---------------------------------------------------------------- PIT/E/2012/006
4. Rehima Gemechu-------------------------------------------------------- PIT/E/2012/037
5. Chaltu Morke------------------------------------------------------------- PIT/E/2012/011
6. Uma Mustefa-------------------------------------------------------------- PIT/E/2012/034
Under the Advisor:- Instructor Feyisa Gemechu(MSc)
Oromia State University, Batu, Ethiopia
Web Based Maintenance Management System Page ii

DECLARATION
This is to declare that this project work which is done under the supervision of Feyisa Gemechu
and having the title web based electronics maintenance management system is the sole
contribution of:
Group Members Name Here
No part of the project work has been reproduced illegally (copy and paste) which can be
considered as Plagiarism. All referenced parts have been used to argue the idea and have been
cited properly. We will be responsible and liable for any consequence if violation of this
declaration is proven.
Date: _____________________
Group Members:
Full Name Signature
1. Jemal Mustefa _____________
2. Tashela Remato _____________
3. Baba Tefu ______________
4. Rehima Gemechu ______________
5. Chaltu Morke _______________
6. Uma Mustefa ________________
Month Date, Year
Web Based Maintenance Management System Page iii

Approval Form
This is to confirm that the project report entitled web electronics based maintenance
management system for Oromia State University submitted to Oromia State University, College
of Science and Technology Department of Information Technology.
Group Members Name.
1. Jemal Mustefa
2. Tashela Remato
3. Baba Tefu
4. Rehima Gemechu
5. Chaltu Morke
6. Uma Mustefa
Advisor Name Signature Date

Feyisa Gemechu ---------- ------------
Department Head Name Signature Date
Basha Tasfeye ------------ ------------
Examiner 1 Name Signature Date
Yigermal Semahagn ---------- ----------
Bekele Abera ------------- -------------
Abdisa D ------------- -------------
Web Based Maintenance Management System Page iv

Acknowledgment
First of all we want to appreciate the God for the gift of life, preservation, favor, Academic
success and for giving the strength to complete this project work. We want to in a special way
acknowledge our project advisor Feyisa Gemechu for his support in realization of this project
work. We want to also in a special way to appreciate our friends for their support for our project
work.
Web Based Maintenance Management System Page v

Abstract
Web based electronics maintenance management system for Oromia State University has
prepared based on the document under the web based electronics maintenance office. Currently,
electronics maintenance management system records are organized in a very rudimentary way in
the form of manual files. This method of data management often results in human error, delay to
retrieve information etc. Thus, electronics maintenance Management System was designed and
implemented to manage for Oromia State University web based electronics maintenance. This
project was done using basic html for visible web contents, Php for Server scripting and
MySQL database was used to store and manage the database. Tools used to achieve this Project
include notepad++, CSS for styling, JavaScript, php, wamp server and MySQL. The project was
implemented successfully and the result obtained provides web based electronics maintenance
management system which integrates all the information about web based electronics
maintenance and can easily be accessed which improved the overall efficiency of web
electronics based maintenance system.
Web Based Maintenance Management System Page vi

Table of Contents
DECLARATION ........................................................................................................................... iii
Approval Form ............................................................................................................................... iv
Acknowledgment ............................................................................................................................ v
Abstract .......................................................................................................................................... vi
List of Table .................................................................................................................................. xv
LIST OF ACRONYMS ............................................................................................................... xvi
Microsoft word............................................................................................................................. xvi
Chapter One .................................................................................................................................... 1
Introduction ..................................................................................................................................... 1
1.Background of the Organization .................................................................................................. 1
1.1. Mission..................................................................................................................................... 2
1.1. 2.Vision .................................................................................................................................... 2
1.2.Statement of the Problems ........................................................................................................ 2
1.3.Objective of the project ............................................................................................................. 2
1.3.1. General Objectives ................................................................................................................ 2
1.3.2. Specific Objectives ............................................................................................................... 3
1.4. Feasibility Analysis. ................................................................................................................. 3
1.4.1. Technical Feasibility. ............................................................................................................ 3
1.4.2. Operational Feasibility .......................................................................................................... 4
Web Based Maintenance Management System Page vii

1.4.3. Economical Feasibility.......................................................................................................... 4
1.5. Significance of the project ....................................................................................................... 5
1.5.1. Beneficiary of the Project ..................................................................................................... 5
1.6. Scope and Limitation of the Project......................................................................................... 7
1.6.1.Scope of the Project ............................................................................................................... 7
1.6.2. Limitation of the Project ....................................................................................................... 8
1.7.1. Data Collection Tools/Techniques ........................................................................................ 8
1.7.2. System Analysis and Design ................................................................................................. 9
1.7.3. System Development Model ................................................................................................. 9
1.7.4. Testing Methodology. ......................................................................................................... 10
1.7.5. Development Tools and Technologies................................................................................ 10
1.7.5.1. Frontend Technologies..................................................................................................... 11
1.7.5.2. Backend Technologies ..................................................................................................... 11
1.8.Budget and Schedule of the Project ....................................................................................... 11
1.8.1. Budget of the Project .......................................................................................................... 12
1.9. Team Composition. ................................................................................................................ 13
Chapter Two.................................................................................................................................. 14
Description of the Existing System............................................................................................... 14
2.1. Introduction of existing system .............................................................................................. 14
2.2. Players in the Existing System ............................................................................................... 14
Web Based Maintenance Management System Page viii

2.2.1.Data flow diagram................................................................................................................ 15
2.3. Major functions/activities in the existing system................................................................... 15
2.3.1. The major role of user in the existing system as input, process and Output....................... 15
2.3.3. The major role of ICT Director in the existing system as input, process and output ......... 16
2.3.2. The major role of Technician in the existing system as input, process and output ............ 16
2.4. Business Rules of the Existing system .................................................................................. 16
2.5. Report generated in the existing system ................................................................................ 16
2.6.Maintenance registering form ................................................................................................. 18
2.7. Bottlenecks of the Existing System ....................................................................................... 18
2.7.1. Performance (Response time). ............................................................................................ 18
2.7.2. Input (Inaccurate/redundant/flexible) and Output .............................................................. 19
2.7.3. Security and Controls .......................................................................................................... 19
2.7.4. Efficiency ............................................................................................................................ 19
2.8. Practices to the Preserved ...................................................................................................... 20
Chapter Three................................................................................................................................ 21
3. Proposed System ....................................................................................................................... 21
3. Data flow diagram for proposed system. .................................................................................. 22
3.1. Functionalities Requirements................................................................................................. 22
3.1.1. Storage related requirements............................................................................................... 23
3.1.2. Performance Requirements. ................................................................................................ 23
Web Based Maintenance Management System Page ix

3.1.3. Process Requirements ......................................................................................................... 23
3.1.4 Input Related Requirements. ................................................................................................ 24
3.1.5 Output Related Requirements. ............................................................................................. 24
3.2. Non-functional requirements. ................................................................................................ 24
3.2.1. User Interface and human factors. ...................................................................................... 25
3.2.2 Hardware Consideration ...................................................................................................... 25
3.2.3 Security issues and Access Permissions .............................................................................. 25
3.2.4 Performance Considerations. ............................................................................................... 26
3.2.5 Error Handling and Validation............................................................................................. 26
3.2.6 Quality Issue. ....................................................................................................................... 26
3.2.7 Backup and recovery............................................................................................................ 27
3.2.8. Physical Environment ......................................................................................................... 27
3.2.9. Resource Issue. ................................................................................................................... 27
3.2.10. Documentation .................................................................................................................. 28
Chapter Four ............................................................................................................................... 30
4. System Analysis. ....................................................................................................................... 30
Introduction ................................................................................................................................... 30
4.1. System Model ........................................................................................................................ 30
4.1.1. Use case Model ................................................................................................................... 31
4.1.1.3. Use case scenarios............................................................................................................ 41
Web Based Maintenance Management System Page x

4.2. Object Model ......................................................................................................................... 44
4.2.1. Class Diagram ..................................................................................................................... 44
4.3 Dynamic Model ...................................................................................................................... 46
4.3.1. Sequence diagram ............................................................................................................... 46
4.3.2. Activity Diagram ................................................................................................................ 55
4.3.3. State Chart Diagram ............................................................................................................ 64
Chapter Five: ................................................................................................................................. 66
SYSTEM DESIGN ..................................................................................................................... 66
Introduction ................................................................................................................................... 66
5.1. Design Goal ........................................................................................................................... 66
5.1.1. End User.............................................................................................................................. 67
5.1.2. Priority of Design Goal ....................................................................................................... 67
5.2. Current System Architecture.................................................................................................. 67
5.3. Proposed System Architecture ............................................................................................... 68
5.3.1. Subsystem Decomposition .................................................................................................. 69
5.3.2. Hardware/Software Mapping. ............................................................................................. 72
5.3.3. Deployment Modeling. ....................................................................................................... 72
5.3.4. Detailed Class Diagram ...................................................................................................... 74
5.3.5. Persistent Data Privilege ..................................................................................................... 75
5.4. Package Diagram .................................................................................................................. 77
Web Based Maintenance Management System Page xi

5.5.Algorithm Design.................................................................................................................... 79
5.6. User Interface Design. ........................................................................................................... 82
5. 7. Conclusion ............................................................................................................................ 85
5.8. Recommendation ................................................................................................................... 85
5.9. References .............................................................................................................................. 86
Web Based Maintenance Management System Page xii

List Of Figure
Figure 2.1 Data flow diagram for existing system ...................................................................................... 15
Figure 2.2. Register form ............................................................................................................................ 18
Figure 3.1. data flow diagram for proposed system ................................................................................... 22
figure 4.1.use case diagram ........................................................................................................................ 32
Figure 4.2.1 Sequence diagram of create account .................................................................................... 46
Figure 4.2.2 Sequence diagram of login..................................................................................................... 47
Figure 4. 2.3 Sequence diagram of log out ................................................................................................ 48
Figure 4.2.4Sequence diagram of block account ....................................................................................... 49
Figure 4.2.5. sequence diagram of send request ........................................................................................ 50
Figure 4.2.7 Sequence diagram of approve request ................................................................................... 52
Figure 4.2.8 Sequence diagram of assign technician .................................................................................. 53
Figure 4.2.9. Sequence diagram change password..................................................................................... 54
Fig 4.3.1 Activity Diagram for Registration. ................................................................................................ 55
Fig 4.3.2 Activity Diagram for login ............................................................................................................. 56
Fig 4.3.3 Activity Diagram for create account ............................................................................................. 57
Fig 4.3.6 Activity Diagram for request ........................................................................................................ 58
Fig 4.3.7 Activity Diagram for views report ................................................................................................ 59
Fig 4.3.8 Activity Diagram for views request .............................................................................................. 59
Fig 4.3.9 Activity Diagram for search .......................................................................................................... 60
Fig 4.3.10 Activity Diagram for assign technician ....................................................................................... 61
Fig 4.3.11 Activity Diagram for update ....................................................................................................... 62
Fig 4.3.12 Activity Diagram for change password ....................................................................................... 63
Fig 4.3.13 State Chart Diagram for login ..................................................................................................... 64
Fig 4.3.13 State Chart Diagram for home page........................................................................................... 65
Figure 5.1 Proposed System Architecture .................................................................................................. 68
Fig 5.2 Subsystem Decomposition 1 ........................................................................................................... 69
Web Based Maintenance Management System Page xiii

Fig 5.8 deployment diagram ....................................................................................................................... 73
Fig 5.9 Normal class diagram ...................................................................................................................... 74
Fig 5.10 Package Diagram ........................................................................................................................... 78
Fig 5.14 Create Account interface............................................................................................................... 83
Fig 5.15 Home Page interface ..................................................................................................................... 83
Web Based Maintenance Management System Page xiv

List of Table
Table 1 Development Tools and Technologies ........................................................................................... 10
Table 1.1 Frontend Technologies ................................................................................................................ 11
Table 1.2 Backend Technologies ................................................................................................................. 11
Table 1.3 Budget of the Project .................................................................................................................. 12
Table 1.4 Time Schedule Feasibility. ........................................................................................................... 12
Table 1.5 Team Composition. ..................................................................................................................... 13
Table 4 .1 Use case description of login...................................................................................................... 33
Table 4.2 Use case description of log out ................................................................................................... 34
Table 4.3 Use case description of create account ...................................................................................... 35
Table 4.6 Use case description of sand request ......................................................................................... 36
Table 4.7 Use case description of views request ........................................................................................ 36
Table 4.8 Use case description of write report ........................................................................................... 37
Table 4.9 Use case description of sign up ................................................................................................... 37
Table 4.10 Use case description of views order ......................................................................................... 38
Table 4.11 Use case description of views report ........................................................................................ 39
Table 4.12 Use case description of assign technician ................................................................................. 39
Table 4.16 Use case description of change password ................................................................................ 40
Table 5.2 Persistent Data Privilege request table ....................................................................................... 75
Table 5.3 Persistent Data Privilege user table ............................................................................................ 75
Table 5.4 Persistent Data Privilege account table ...................................................................................... 76
Table 5.5 Persistent Data Privilege technician table................................................................................... 76
Table 5.6 Persistent Data Privilege manager table ..................................................................................... 76
Web Based Maintenance Management System Page xv

LIST OF ACRONYMS
Acronym Definitions
PHP Hypertext preprocess
UML Unified model language
DB Database
UA User action
SA System action
FR Functional requirement
SDD System design develop
RAD Requirement analysis design
Admin Administrator
Empid Employ ID
OSU Oromia State University
HTML Hypertext markup language
SQL Structural Query language

CSS Cascading style sheet
MS
Microsoft word
Web Based Maintenance Management System Page xvi

Chapter One
Introduction
A web-based electronics maintenance management system is a software application that helps
organizations manage their assets, schedule maintenance tasks, track work orders, and generate
reports. A web-based system can be accessed from any device with an internet connection,
making it easier to share information and collaborate across teams.
1.Background of the Organization

Having Human Resource Development and Organizational Transformation as its pillars of
excellence or operational areas, Oromia State University first came into being as a short-term
training institute - Oromia Management Institute (OMI) in 2000. In 2005, the institute was scaled
up to a college level and named: Public Service College of Oromia (PSCO). In January 2017 the
institution has been granted the status of higher learning institution and has been given its current
name, OSU following Regulation No 190/2009 of the Oromia Regional State Council. The
university, as a capacity building higher learning institution, has been contributing its share in the
ongoing process of institutional transformation, peace building, governance, and development by
providing better education, training and consultancy as well as undertaking problem solving
researches aimed at transforming public sectors in the Oromia Regional State and beyond. The
university has carried out a wide range of commendable activities and has obtained considerable
amount of achievements and recognitions in the betterment of the livelihood of the people of the
region in general and building capacity in the public sector in particular. As per its leadership,
the university is led by a President who is assisted by four vice presidents:
 Vice President for Academic Affairs,
 Vice President for Reform, Research and Community Service,
 Vice President for Partnership and Business Development, and
 Vice President for Administration and Student Services.
Taking into account the fast-changing national quest for reform in the public sectors in particular
and educational dynamics in general the university has been undertaking various reform
1|Page
1.1. Mission
Oromia State University is in charge of capacity building for generating, embracing and
sustaining reform initiatives in the region and beyond through first-rating education, training,
research, consultancy and community services backed by state of the art of technology.
Oromia State University has a mission to support the development endeavors of the people by
tackling the insistent problems by utilizing natural resources and cultural values, through
inculcating scientific knowledge and skills relevant to the country and ensuring quality
education.
1.1. 2.Vision
By 2020 E.C OSU is to be one of the competent and best reform sustaining institutions in East
Africa in delivering high quality education, training, research and consultancy services.
1.2.Statement of the Problems

In Oromia state University there are different maintaining places. This office use manual system
to manage their Information .This management system causes different problems. These are
problems with use manual management systems, it consumes time,it is consumption of resources
because of not having fast response, it is difficult to control resources, it uses many manpower,
Being late to maintenance ,there is limitation of time and location, customers must come
physically to the office to report the problem and less reliability
1.3.Objective of the project

1.3.1. General Objectives
The General objective of this project is to develop a Web Based Electronics Maintenance
Management System for Oromia state University.
2|Page
1.3.2. Specific Objectives
In order to achieve the general objective, we have the following specific objectives:
 To Study and analyses manual system.
 To identify and definition of the existing system problem.
 Understand work flow of existing system.
 Propose possible solution for current system.
 To build effective working environment.
 To design database with MSQL.
 To register item, view item, record item.
 To register user.
 To develop good graphical user interface (UI).
 Implementation and testing of proposed system.
 To use HTML for user interface (UI) design.
1.4. Feasibility Analysis.

Feasibility analysis enables the system to determine ether or not the project can be developed
Evaluates and identifies the newly developed system. Therefore, the feasibility analysis of
proposed system involves the following feasibility
1.4.1. Technical Feasibility.

The system developers understand the scope, objectives including specific objectives and
Limitations of the proposed system well and the users have technical capability labiality to use
this system. As a result the develop the system for Oromia State University successfully within
proposed resources (budget, time, etc.). This also deals with the hardware as well as software
3|Page
requirements. We have to find out whether the necessary technology and the proposed equipment
have the capacity to hold the maintenance used in the project. The technical feasibility issues
usually raised during the stage of fact finding includes the following:-
This software is running in windows and Linux operating system.
1.4.2. Operational Feasibility

Operational feasibility is a measure of how well a proposed system solves existing problems.
The system will be very simple and easy to use and since the interface has nothing complicated
and interesting to use, we have made it so that any user can easily use it and achieve its
performance without any confusion.
1.4.3. Economical Feasibility

When the team can be analyses the system by comparing the cost with the benefit (the enterprise
Can get by using the proposed system), surely the benefit out weight the cost. The cost of
developing a full system, including software and hardware cost for the class of application being
considered should be evaluated. So, the benefit that obtain by using the proposed system can be
categorized as tangible and in tangible.
Tangible benefits are:
 Using less nan power than the existing system.
 Increase speed of activities and competence.
 Reduce cost.
Intangible benefits are:
 Knowledge required by project developer.
 Facilitating information processing.
 Updating information.
 Increasing the competitiveness of the individual.
 Improved productivity.
4|Page
 Improving the morale of our team.
 Facilitating information processing of our team
 Therefore the team decided the proposed project is economically feasible.
1.5. Significance of the project

OSU maintenance system is working with manual system which is time consuming and costly.
The importance of this project is to solve such kinds of problem within the web based
maintenance office. Changing manual system into computerized or automated system is much
more important
 Able to give maintenance in short period of time
 avoid time and place limitation
 Easily control of maintenance system
 Support customer application system.
 Able to use resources properly
 reduce time consumption
 reduce manpower
 can inform to the right person
1.5.1. Beneficiary of the Project

The Benefits of this project could be applied in the real world for Oromia State University. There
are Three Perspectives of the project Benefits:
 Staff Member and customer :-
• Easier and faster to find information.
• Allow the User to summit clearance report timely.
• Allow User to search clearance online.
• The system is faster for retrieval, update and communication
5|Page
• The system can deliver fast service for office.
 Organizational Perspective
• Increasing service effectiveness.
• Easy to handle user record.
• Easy way of taking back up and managing dead file
• Avoid tiredness to separate the dead file.
• It provides security for data.
• Reduce the loss of space & human resource.
• Time consuming activities (tasks) will be reduced.
• Enable to perform different activities within short period of time & less cost.
3- ICT Director Perspective
• Can access user data easily.
• Save their time.
• Reduce workers load.
• Reduce complexity.
• Control office records and reduce data redundancy
4. Technician Perspective
• Can access user data easily.
• Save their time.
• Reduce workers load.
• Reduce complexity.
6|Page
1.6. Scope and Limitation of the Project
1.6.1.Scope of the Project
Defines what the proposed system is not going to perform or what is not including in the
proposed System. This project covers some of the aspects of computer software web based
maintenance processing system using Oromia State University as case study.
There are many systems in OSU, from those different systems our project concerns on the
university web based maintenance management system. The project was develop a system for
generating report and for controlling data in web based maintenance management system office.
The project is mainly aimed to develop cost effective and efficient web based maintenance
management system. Hence, It includes all the important functions in maintenance management
like add user cases, manager user , register user, director, expert, store manager, purchase .
Generally the scope of this project includes:-
 The proposed system is accessed by English language.
 Registering user.
 Regis request item
 Registration Request Item
 System checks maintenance of equipment.
 System can change password of user if necessary.
 To develop a system for generating report and for controlling data in web based
maintenance management system office.
 To develop cost effective and efficient web based maintenance management system.
7|Page
1.6.2. Limitation of the Project
 Internet reliance means internet is not everywhere yet so that area cannot be connect.
 Since it is an online project, customers need internet connection to log complain or for
request for services.
 Internet goes down or slow will not work properly.
 User interface is only in English.
 People who are not familiar with computers can’t use this application.
 User can login only with his assigned username and password i.e. no guest facility is
available.
1.7. Methodology of the Project

1.7.1. Data Collection Tools/Techniques
Observation: - To understand directly how the existing system works currently, we have used
observation. We observed customer interaction with maintenance office.
Interviewing: - Most analysts use interviewing as a primary way of gathering requirement in

information system projects. We have used interview to gather facts, opinions, and truths of
users about the current manual system. We interviewed the employees working on the
electronics maintenance management system. Among those we interviewed, we used interviews
with Midaksa, Haji and Malakamu on 02/4/2016 E.C about maintenance.
There are two types of interviews which we chose to use to collect the required data
This includes face-to-face interviews and interview by phone.
Document analysis: - Using this method the team was try to analysis written documents in the
organization which have importance to the project.
8|Page
1.7.2. System Analysis and Design
In this project the team used Object Oriented System Analysis and Development methodology
(OOSAD), This has two phases.
Object Oriented Analysis (OOA):- During this phase the team used to model the functions of the
System (Use case modeling), find and identify the business objects, organize the objects and
identify the relationship between them and finally model the behavior of the object.
Object Oriented Design (OOD):- During this phase the team used to refine the use case model
to elect the implementation environment, model object interactions and behavior' s that support
the use case scenario, and finally update object model.
1.7.3. System Development Model

Planning: In this phase, the requirements of the maintenance management system are identified
and analyzed. The scope of the system is defined, and the feasibility of the project is assessed.
Analysis: In this phase, the requirements identified in the planning phase are analyzed in detail.
The functional and non-functional requirements of the system are defined, and the system
architecture is designed.
Design: In this phase, the detailed design of the maintenance management system is created. The
design includes the database schema, user interface, and system modules.
Implementation: In this phase, the maintenance management system is developed. The code is
written, tested, and integrated into the system.
Testing: In this phase, the maintenance management system is tested to ensure that it meets the
requirements defined in the planning phase. The system is tested for functionality, performance,
and security.
Deployment: In this phase, the maintenance management system is deployed to the production
environment. The system is installed, configured, and tested in the production environment.
Maintenance: In this phase, the maintenance management system is maintained. The system is
monitored, and any issues are resolved. The system is updated to meet changing requirements.
9|Page
1.7.4. Testing Methodology.
We will perform different testing for checking functionality of our proposed system:-
Unit testing: first we will test each unit at each system, so if a problem is encountered it will
immediately maintain at which the problem is occurred.
Integration testing: after we test each unit of the proposed system we will perform and
integration test to check whether the system meets all the functional requirements. 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 all of the above testing is checked we will test our system by other
Peoples and we will conduct some comments how they get our system.
1.7.5. Development Tools and Technologies

Activity Tools/program
Client Side Scripting JavaScript
Server Side Scripting PHP
Web Server Apache
Database server MySQL
Client Side coding HTML
Platform MS windows
Browser Internet Explorer ,Mozilla Firefox 3.0.Crome.
Editor Notepad ++ ,Notepad, SUMLIME
Documentation MS Word, MS Excel,
User testing MS PowerPoint, video Player
Table 1 Development Tools and Technologies
10 | P a g e
1.7.5.1. Frontend Technologies
S.NO Front end Requirement
1 HT ML Interface Design
2 JS For validation
3 CSS Control Appearance of web

site
Table 1.1 Frontend Technologies
1.7.5.2. Backend Technologies

S.NO Back end Requirement
1 PHP Server side language
2 MySQL SERVER Databases
3 NOTEPAD++ FOR EDIT CODE
4 SUMLIME FOR EDIT CODE
Table 1.2 Backend Technologies
1.8.Budget and Schedule of the Project

Budget and Time Schedule of the Project is concerned with analyzing the expected completion
date of the project and the constraints that may bring change to this date. We have so many fixed
schedules to work together the project with all groups within each day and for the simplicity and
fast developing purpose.
11 | P a g e
1.8.1. Budget of the Project
Activities Fees in birr
1 Proposal 25000
2 Requirement specification 30,000
3 Database design 20 ,000
4 System layout 35,000
5 Implement 60,000
6 Test 35,000
7 Maintenance 55,000
Total 260,000
Table 1.3 Budget of the Project
November December January
Activities Week Week Week Week Week Week Week Week Week Week Week Week
1 2 3 4 5 6 7 8 9 10 11 12
Requirement
Gathering &
Analysis
System Design
Implementation
Testing
Table 1.4 Time Schedule Feasibility.
12 | P a g e
1.9. Team Composition.
No Student Name ID/NO Email Task
1 Jemal Mustefa IT/E/12/021 jemalmstefa33@gmail.com Team leader
2 Teshale Rameto IT/E/12/033 Rametoteshale36@gmail.com Programmer
3 Baba Tefu IT/E/12/006 Designer
4 Rahima Gemachu IT/E/12/037 Rahimagemechu49@gmail.com Programmer
5 Cheltu Morke IT/E/12/011 morkechaltu@gmail.com Data collector
6 Uma Mustefa IT/E/12/034 Analyst
Table 1.5 Team Composition.
13 | P a g e
Chapter Two
Description of the Existing System
2.1. Introduction of existing system

This chapter deals with analyzing the general work flow of the existing system, players in the existing
system. And briefly describes the existing system working process, problem of the existing system.
The current maintenance processing: system is the manual system that needs intensive human labor,
resource, consume time, less security. Here, the users to visit all the maintenance offices with a form for
them to fill and get sign by the respected offices. Once these forms are signed, it proves that the users
have been cleared. This process takes some days to be completed and possess a lot of stress to all the
users and workers who provide maintenance system.
2.2. Players in the Existing System

The main player in the existing system includes the following: -
ICT Director: - ICT Directors are responsible for maintaining the functionality, security, and
accessibility of all computer resources within the organization. This includes networking equipment,
computer hardware and software, data storage infrastructure, and web applications .
Technician: - You will be responsible for a wide variety of tasks, from fixing broken equipment to
performing preventative maintenance. This is a critical role, and you will need to be able to work quickly
and efficiently to keep our company running smoothly.
Users:- users will go to Office to get the maintenance form and fill the form then go to different offices to
get sign..
14 | P a g e
2.2.1.Data flow diagram
Figure 2.1 Data flow diagram for existing system
2.3. Major functions/activities in the existing system

The main task of maintenance is to meet the customer's needs. Provide quality work to the customer and
reduce the waste of time of employees and users in OSU.
2.3.1. The major role of user in the existing system as input,

process and Output
Input: users request to fill the forms to use from the campus
Process: filling the basic inputs that the form needs
Output: use from the campus with safe manner
15 | P a g e
2.3.3. The major role of ICT Director in the existing system as
input, process and output
Input: maintenance Form signed by all officers will be submitted to ICT Director by the users.
Process: Collect and store maintenance form of users on which all other officers sighed.
Output: Giving maintenance for users by putting ICT Director seal.
2.3.2. The major role of Technician in the existing system as

input, process and output
Input: maintenance approval form.
Process: checking if users is clear from any debt.
Output: giving approval by signing on the maintenance form.
2.4. Business Rules of the Existing system

The Business Rules is a principle or a policy in which the proposed system operates accordingly-
The main business rules or principles are: -
Br 1: -Admissions officers issue maintenance forms to university beneficiaries.
Br 2: -officials of the University are not expected to give maintenance on ,Saturday, Sunday and holiday
Br 3: - When a user wants to sign a maintenance form, the must fill the required information and must
have the id code with it.
Br 4: - the user must return any Exchange items or pay for any lost items or Damage before repair.
Br 5: - users the university beneficiary must send the system a user maintenance form to the registrar.
2.5. Report generated in the existing system

A report generated in the existing system for maintenance management system can provide valuable
insights into the performance of the system.
Here are some examples of the types of reports that can be generated:
Work order completion report: This report provides information on the number of work orders
completed within a specific time frame. It can help identify trends and patterns in work order completion
rates and help identify areas for improvement.
16 | P a g e
Asset performance report:- This report provides information on the performance of assets within the
system. It can help identify assets that are underperforming or require maintenance and help prioritize
maintenance activities.
Maintenance cost report:- This report provides information on the cost of maintenance activities within
the system. It can help identify areas where costs can be reduced and help optimize maintenance
spending.
Maintenance management report:- This report provides information on the inventory levels within the
system. It can help identify inventory shortages or surpluses and help optimize inventory levels.
Downtime report:- This report provides information on the amount of downtime experienced by the
system. It can help identify areas where downtime can be reduced and help improve system availability.
These are just a few examples of the types of reports that can be generated in a maintenance management
system. The specific reports that are generated will depend on the needs of the organization and the
capabilities of the system.
Different reports are generated in the existing user maintenance system of Oromia State University.
Reports are generated based on the general information about a user and workers in the University.
In an existing system there are different reports generated for different purposes. Those reports include
customer allocation report, customer status report; Resource maintenance report, repaired property
report,unrepaired property report and damaged resource report etc.
-to-date information about the following

are the reports and summaries generated in Oromia State University user computer maintenance
management system
 Damaged resource report.
 Repaired property report.
 Unrepaired property report.
17 | P a g e
2.6.Maintenance registering form
Figure 2.2. Register form
2.7. Bottlenecks of the Existing System

Due to the manual means being used by the university, in keeping information about users maintenance, a
lot of problems are encountered which includes
2.7.1. Performance (Response time).

Wait in the queue while processing the maintenance form.
Unavailability of some key staff while processing the maintenance form.
take a lot of time to get back a particular maintenance from the respected offices.
18 | P a g e
2.7.2. Input (Inaccurate/redundant/flexible) and Output
During filling of the form the user may fill inaccurate or incorrect information and may miss necessary
information, this show the system is inaccurate and the system is not flexible because if User wants to
erase the form he/she must only change another form.
2.7.3. Security and Controls

A Security and Controls maintenance management system is a software application that helps
organizations manage their security and controls maintenance activities. It is designed to help
organizations ensure that their security and controls are up-to-date and effective. Here are some
guidelines that you can follow to create a Security and Controls maintenance management system for
Oromia State University:
Identify the requirements: The first step in creating a Security and Controls maintenance management
system is to identify the requirements of the system. You need to determine what features and
functionalities the system should have to meet the needs of Oromia State University.
Design the system: Once you have identified the requirements, the next step is to design the system. You
need to create a detailed design of the system that includes the architecture, data model, user interface,
and other components.
Develop the system: After designing the system, the next step is to develop the system. You need to
write the code for the system and test it to ensure that it works as expected.
Deploy the system: Once the system is developed, the next step is to deploy the system. You need to
install the system on the servers and configure it to work with the existing infrastructure.
Maintain the system: Finally, you need to maintain the system to ensure that it continues to work as
expected. This includes monitoring the system, fixing bugs, and updating the system to meet changing
requirements.
2.7.4. Efficiency
Due to the manual operation most of the activities are easy to wastage of resources like stationary
materials, manpower, time etc. to produce the corresponding outputs. This makes the current system
inefficient while utilizing resources.
19 | P a g e
2.8. Practices to the Preserved
Even if the existing system has a lot of problems, there are a number of activities that need to be
preserved. The system uses files and forms to define operations and to perform business rules in the
maintenance system. Our team members preserve the following practices form the existing system.
 System procedures.
 The rule and regulation of the university.
 Formalities of the users of the system, offices concerned staffs and users.
20 | P a g e
Chapter Three
3. Proposed System
To be simple the facility maintenance system in the campus by observing the existing general service to
develop the new automated system. To identify problems and make the system to reduce or remove those
problems by giving services to the customers with interaction to the system Webpages. To solve the
problem of manual record keeping system by using computerized information system with only
interaction to the system. To reduce the time to get service from the maintenance system by only passing
message proposed system. The proposed system is used to solve the existing problems and it include the
following tasks:
• The system shall allow applicants to register about failed and/or malfunctioned item information.
• The manager responds for applicants request online.
• Improve quality of maintenance of the system.
• Provide secured system by checking user name and password.
• User friendly system, that means the customer and system interact in a good manner.
21 | P a g e
3. Data flow diagram for proposed system.
Figure 3.1. data flow diagram for proposed system
3.1. Functionalities Requirements.

User Requirements
The requirements described in the following section define the required functionality for the maintenance
management system. Each functional requirement is given an identifier.
Technician Requirements
Description- technician is a person who maintain and fix the problem
Manager Requirements
Description- manager is the person who control the flow of the work
Create Account
Description- an account is the fundamental object for the system (refer to the glossary for a detailed
description). The functional requirements for creating new accounts are described below.
22 | P a g e
Change password
Description- the system must allow the users to change their account password
Search:- Enables the Registrar and Officer login to the system and search maintenance.
Update It needs to have the capability to perform an efficient maintaining/updating of maintenance.
Authentication: - The system will be verified by denying unauthorized user from using the system.
Displaying of user maintenance from the database was the main process for the system.
For those who use it to solve problems by asking questions Check at any time about the maintenance
status.
Handles all the user made by officer from the time it is placed to the dispatching of there quest.
3.1.1. Storage related requirements

The system was developed MySQL database server which maintained all the user information such as
cleaned user and current user information to be cleaned.
3.1.2. Performance Requirements.

The proposed system shall give exact solution to the users for what questions they have been asking. The
system shall have the capacity to operate more users maintenance.
The system performance is one of the functional requirement in which they regularly and maintenance
quality. It is all time ready to perform all the maintenance, faster maintenance and use minimal space
usage.
3.1.3. Process Requirements

The proposed system shall have the ability to processes the following functionalities
 The system shall enable the administrator to access and manage the maintenance information.
 The system shall edit maintenance account.
 The system shall enable the user to view maintenance clearance online.
 The system shall process administrator and user account creation, and update
 The system shall search user by ID.
23 | P a g e
3.1.4 Input Related Requirements.
After the System is implemented, to perform a process it needs inputs like user username, user ID No and
other information which are necessary to in processing maintenance are entered in maintenance process.
3.1.5 Output Related Requirements.

the system takes in an input to perform or to process some function in order to produce an output based
on the given input . Such as
 The system shall display user detail.
 The system shall display maintenance report.
 The system shall display maintenance unproved clearance status.
3.2. Non-functional requirements.

Our proposed system has the following non-functional requirements to achieve its functionality.
 USABILITY
Description: The system easy to be used by user with less knowledge & experience with computers.
User with responsible that uses the system.
Requirements: Simple user
Ranking: essential
 Reliability
Description: Any information, comment, or complain the user gives is only viewed by the authentication
person.
Requirements: the authentication person must be trust.
Ranking: essential
 Performance
The system performs efficiently and effectively as much as possible which is going to be used 24 hours a
day Fast loading system
Description: Waiting for an opening and load can be frustrating for an end user. To them, loading is
extremely important high connection.
24 | P a g e
Requirements: the connection must fast.
Ranking: essential
 Availability
Description: The system is available anywhere any time, where internet access is available.
Requirements: The system active
 Security: - The system is secured and safeguard as much as possible so that there is permissible.
 Authenticates:- the user by means of a user name and password with which user will be able to
login to his/her respective pages and use the system as required.
 Portability: -
The system is machine independent and software system independent so it can be transported to different
target platforms.
3.2.1. User Interface and human factors.

The developed system provides web application user interfaces that are compatible browsers Like Internet
Explorer. Mozilla Firefox, Google chrome, etc.
3.2.2 Hardware Consideration

The organization should have computers having typical storage capacity and processing speed.
Different hardware tools are used to develop our project.
Database, Minimum 512 MB Memory, Max 4Gb, also available 6 or 8 Gb.
Processor Min-1.7GHz Max 3.4 GHz.
Keyboard: To give input to the computer.
3.2.3 Security issues and Access Permissions: - The system provides or

contains user name And password for each users based on their privilege. This performs the Following
activity: -
 Authenticated user with predefined access right will only enter to the information related to
maintenance.
25 | P a g e
 Every users should use strong passwords especially admin.
 User must enter valid user name and password to login to system. Without this, access to the
system is denied.
 Maintenance is encrypted for security.
 System allows only registered users to access maintenance system and also allows the users to
view their own profile not the other users' profile.
3.2.4 Performance Considerations.

Because the system is to be accessed by different users with different needs, it should be the system
should be able to handle and process their requests quickly The system should be able to handle multiple
users at the same time and it should be able to work on the maintenance workflow system.
3.2.5 Error Handling and Validation

When the users of the system interact with the system errors may appear. To control these inaccuracies
the system will generate different messages. To do this, most of the system execution buttons will be
controlled according to the sequence which the user is expected to follow. Or this can be done by
generating different system responses to the input of the users.
3.2.6 Quality Issue.

The new system is reliable and robust compared with the current system, and also when we observe the
current system it's not always available anywhere and anytime as the new system.
Availability: The new system provides service to the client without concerning the locations of the user
and also it works for 24 hours.
Reliability: The user of the new system can access more relevant and reliable information about the
services and also it detect the current location accurately.
Robustness: The ability of error detection of the new system is more efficient than the current system.
Since the new system is based on client-server architecture when an error occurred we were just
concerned mainly on the server side. For this reason, we are saving time in detecting errors.
Content Richness: The new system provides information about maintenance in the University. In the
case of our new system user involvement in the development processes is a vital requirement for the
quality of the system.
26 | P a g e
3.2.7 Backup and recovery.
Backups: - Backups are useful primarily for two purposes. The first is to restore a state following a
disaster (called disaster recovery). The second is to restore small numbers of files after they have been
accidentally deleted or corrupted. Data loss is also very common. 66% of internet users have suffered
from serious data loss. The system should be holding a backup of the data by using different storage
devices. Some of them are Flash Memory, DVD Backup, Tape Backup, Hard Drives and A drive.
Recovery: - Data recovery is the process of restoring data that has been lost, accidentally deleted,
corrupted or made inaccessible for some reason. Data recover by using system recovery and any software
like restoration, wise data recovery, recover software.
3.2.8. Physical Environment

The system is deployed to repair each user's computer.
A maintenance management system is a process developed by your maintenance team to improve the
reliability, safety, and longevity of your physical assets . The physical environment in a maintenance
management system refers to the physical conditions of the assets being maintained. This includes the
location of the assets, their current condition, and the resources needed to maintain them.
To detect the current location of the user the system needs protection from external factors like those
things that do not make a clear connection between the device and the internet since the system needs a
clear Connection between the computer to detect the location of the user.the system needs a good
environment. But also a harsh environment that must be used: backup the cloud and protect the System.
3.2.9. Resource Issue.

A common resource issue in web-based maintenance management systems is resource allocation .
Resource allocation refers to the process of assigning resources such as labor, equipment, and materials to
specific tasks or projects. In a web-based maintenance management system, resource allocation can be
challenging due to the complexity of the system and the number of resources that need to be managed.
Web-based maintenance management systems can help to address resource allocation issues by providing
real-time data on resource availability, utilization, and performance . This data can be used to optimize
resource allocation and improve the efficiency of maintenance operations
27 | P a g e
3.2.10. Documentation
The system contains the required documents needed to implement the project.
After the project, every activity of the entire development, design, and other process will be documented
for future reference.
There will also be documentation of implementation for maintenance during web application failure.
28 | P a g e
29 | P a g e
Chapter Four
4. System Analysis.
Introduction
This chapter deals with analyzing the proposed system by using different UMI analysis Modeling
techniques such as use case diagrams, the use case descriptions (scenarios), analysis Class diagram,
Sequence diagram. Activity Diagram, State chart Diagram. After identifying the actors and use cases, he
use cases are developed and textual descriptions (Scenarios) are stated. The Sequence diagram id depicted
based on the use cases which are developed for the proposed system. Activities will be represented by the
activity diagrams.
4.1. System Model

A system model is the conceptual model that describes and represents a system. A system comprises
multiple views such as planning, requirement analysis, design, implementation, deployment, structure,
behavior, input data, and output data views. A system model is required to describe and represent all these
multiple views.
System modeling is intended to assist in developing and maintaining large systems with emphasis on the
Construction phase. The idea is to encapsulate complex or changeable aspects of a design inside separate
components with well-defined interfaces indicating how each component interacts with its environment.
Complete systems are then developed by composing these components. System modeling can increase
reliability and reduce development cost by making it easier to build systems, to reuse previous built
components within new systems, to change systems to suit changing requirements such as functional
enhancement and platform changes, and to understand systems. In this way, a system mode can satisfy
different requirements such as documenting the system, providing a notation for tools such as consistency
checkers and can also be used in the design stage of system development. Thus, system modeling is used
ensure that a developing piece of software evolves in a Consistent manner and that the task of integrating
software components is simplified.
30 | P a g e
4.1.1. Use case Model
Key terms.
 ICT Director
 Technician
 User
Actors Description
The actors that interact with the system are the Manager user, Registrar Admin, Technician, consumer are
users of the system. They are described here in brief:-
Name: ICT Director.
Description: ICT Directors are responsible for maintaining the functionality, security, and accessibility of
all computer resources within the organization. This includes networking equipment, computer hardware
and software, data storage infrastructure, and web applications
Name: Technician.
Description: A Technician is a skilled professional who specializes in maintaining, repairing, and

troubleshooting various systems, equipment, or machinery. Their responsibilities include diagnosing
issues, performing repairs, and ensuring that systems operate efficiently.
Name: User
Description: User is able to their profile customization. Request, and views their own information.
31 | P a g e
figure 4.1.use case diagram
32 | P a g e
4.1.1.2. Use case description
Login
Use case No: UC-1
Use case Login

Name:
Actor (s): All actors
Description: Actors Login to system in order to have privileges for performing

different tasks.
Typical course Actor Action System Response

of events
1.Open web site 4.If username and password is valid
2.Click login button 5. Actor action performed page

display.
3.Actor enter username and
password and then click on
login,
Alternative If the user name and password is not valid.

course:
System back user to login page and return to error message
If actor try more than 3 time, system close the page.
Preconditions Manager has privilege to access system
Table 4 .1 Use case description of login
33 | P a g e
Log out
Use case No: UC-2
Use case Name: Logout
Description: Actors logout from the system when finishes their task.
Typical course of Actor Action System Response

events
1. Close all opened file. 3. The system is closed.
2. Actors click logout link.
Preconditions Actors first login and finish the task.
Post condition The system is closed.
Table 4.2 Use case description of log out
Create account
Use case No: UC-3
Use case create account

Name:
Actor (s): ICT Director
Description: ICT Director must have privilege to access site.
Typical Actor Action System Response
34 | P a g e
course of 1. Open website. 3. Display create account form.
events
2. Click create account link. 8. If the new user name and password is
not found in account table, display
4. Select status.
successfully created.
5.Enter new user name and password
6.Re-enter password
7. Click create button.
Alternative If the form is not fulfilling, back to the form and return error message that
course: inform ICT Director.
Preconditions Privileged access.
Post Account created

condition
Table 4.3 Use case description of create account
Send request
Use case No: UC-6
Use case Name: Send request
Actor (s): User
Description: This use case describes that User can send request.

events
1.Open website 4. Display request form.
2. Logged to website. 6. Display request successfully sent.
3.Click on send request link
5. fill the information on the form

and click send button
35 | P a g e
Preconditions UC-1
Post condition Send request successfully
Table 4.6 Use case description of sand request
View request
Use case No: UC-7
Use case Name: Views request
Description: This use case describes that ICT Director can views request send from User

events
1.Open website 4. Display view order form.
2. Logged to website. 6. Display request sent from User.
3.Click on view request link
5. If there is request sent from

User.
Preconditions UC-1
Post condition Request viewed by manager
Table 4.7 Use case description of views request
Write report
Use case No: UC-8
Use case Name: Write report
Actor (s): User, technician
Description: Actors write reports what it is done.
36 | P a g e
events
1.Open website 4.Display write report page
2. Logged the website. 7. System return successfully sent

message.
3. Click on write report button.
5.write reports what has done
6.Select send button
Preconditions Uc-1
Post condition Write report to the manager
Table 4.8 Use case description of write report
Sign up
Use case No: UC-9
Use case Name: Sign up
Actor (s): User
Description: This use case describes that User can sign up.

events
1. Open website 3. Display sign up form.
2. Click on sign up link 6. Successfully registered.
4. fill the forms in the sign up

form
5.select the sign up button
Preconditions Visit the web site
Post condition Signed up
Table 4.9 Use case description of sign up
37 | P a g e
View order
Use case No: UC-10
Use case Name: Views order
Actor (s): Technician
Description: This use case describes that technician can views order send from manager to
maintenance.

events
1. Open website 4. Display view order form.
2. Logged to website. 6.Display message send from manager.
3.Click on view order link
5. If there is message that send

from manager.
Alternative course: If there is no message, return error message that inform technician.
Preconditions UC-1
Post condition The manager sends message to technician and a technician maintain a
particular problem
Table 4.10 Use case description of views order
View report
Use case No: UC-11
Use case Name: view report
38 | P a g e
Description: This use case describes that ICT Director views report that have information
about previous operation that have been done and the achievements (feedback).

events
1. Open website. 5. Display view report form.
2. Logged to website.
3. Click on report link.
4. Click on view report.
Preconditions ICT Director must have privilege to view report.
Post condition Report was be viewed by ICT Director
Table 4.11 Use case description of views report
Assign technician
Use case No: UC-12
Use case Name: Assigns Technician
Description: ICT Director assign technician to maintenance.
Typical course of events Actor Action System Response
1.Open website 5.Successfully assigned
2. Logged to website
3. Fill on assign form.
4. Click assign button.
Preconditions ICT Director checks status of technician to assign.
Post condition Assigned technician that related to the problem.
Table 4.12 Use case description of assign technician
39 | P a g e
Change password
Use case No: UC-16
Use case Name: Change password
Description: All actors must have privilege to access the site.

events
1. Open website. 3. Display signup form.
2. Click sign up link. .
4. Select status.
5. Enter old user name and

password.
6.Click change password button
Preconditions All actors must have privilege to access the site
Post condition Password changed
Table 4.16 Use case description of change password
40 | P a g e
4.1.1.3. Use case scenarios
A scenario is a description of some definite interaction between one or more actors and the system.
Log in
This use case used for a security check point to access the system
Actors:-User and manager
Precondition:-the Actor must have valid user name and passwords
Post condition:-The system will be available for use
Basic course of action:-
• The actor instantiate the log in screen
• The system ask to enter user name and password
• Actor enter user name and password
• Id preparation
When the consumer requests ID then the register checks his/her information and the department
head approves it
Retirement
Whenever the user request retirement and the Register check her or his and the department head allow the
retirement.
Biography
The Register records the users biography
File borrowing
users request file borrowing and the officers checks his or her file give the file to the user
Summary sheet
user request maintenance the Officers checks his or her file and writes the maintenance with the
Officers approval
41 | P a g e
Log off
After the user and Officer finished working, the system should be log off.
Scenario for update content
1. Scenario name: Update content
Actor: ICT Director
Flow event: Administrator request for updating.
The system verifies if the user is authorized or not.
The system allows to updating the content.
Administrator updates the content.
2. Scenario for delete content
Scenario name: Delete content
Actor: ICT Director
Flow event: Officer request for deleting.
The system allow to deleting the content
Administrator deletes the content.
3. Scenario for upload content
Scenario name: Upload content
Actor: ICT Director
Flow event: user request for upload.
The system allows to uploading the content.
user uploads the content
42 | P a g e
4. Scenario for detect location
Scenario name: Detect location
Actor: User
Flow event: user starts the application.
The system starts detecting the current location.
The system displays the current location.
5. Scenario for Attractions
Scenario name: Attractions
Actor: User
Flow event: user touches on attraction link.
The system listed different attractions and historical places.
The user selects one of the types.
The system display basic information about the particular place. Scenario for Available services
6. Scenario name: Available services
Actor: User
Flow event: user touches on service link.
The system listed different available services.
The user selects one of the types.
The system display basic information about the particular service.
43 | P a g e
4.2. Object Model
4.2.1. Normal Class Diagram

It represents the properties of entities, their operations and relationships Also it drives use case diagrams
from use case.
The class diagram is the main building block in our project modeling.
It is used both for general conceptual modeling of the systematic of the application and for detailed
modeling translating the models into programming code.
The classes in a class diagram represent both the main objects and or interactions in the application and
the objects to be programmed.
Generally the project is including the following class in the class diagram the over view of the class
diagram is:-
44 | P a g e
figure 4.2.1.Normal class diagram
45 | P a g e
4.3 Dynamic Model
4.3.1. Sequence diagram

Sequence diagrams show the interaction between participating objects in a given use case. They are
helpful to identify the missing objects that are not identified in the analysis object model.
{ Creat Account}
:Owner :Create account link :Create account :Create account form :Account :Confirmation
<<Actor>> <<bouondary>> <<Controler>> <<UI>>
click
1. The owner click on create account create
button. create
2. The system display create account
form. Fill
3.The owner fill the create account

submit
form
4.owner click signup button. check

5. system display successful validate
message for owner when the owner
fill correct information . if not valid
Or display error message

5. system display error when the
owner fill incorrect information .
validated
create
display
Figure 4.2.1 Sequence diagram of create account
46 | P a g e
Figure 4.2.2 Sequence diagram of login
47 | P a g e
Figure 4. 2.3 Sequence diagram of log out
48 | P a g e
Figure 4.2.4Sequence diagram of block account
49 | P a g e
Figure 4.2.5. sequence diagram of send request
50 | P a g e
{View report}
:Owner :View report link :View repoort :Report category :Report

<<Actor>> <<Boundary>> <<Controller>> <UI>>
click
create
create
1. The owner click on view report link.
select
2. The system display category.
click on view report button
3.The owner select category
4.The owner click on view report button display
5. The system display report.
6.The owner view the report
Figure 4.2.6 Sequence diagram of view report
51 | P a g e
Figure 4.2.7 Sequence diagram of approve request
52 | P a g e
Figure 4.2.8 Sequence diagram of assign technician
53 | P a g e
{ Change password}
Owner,sales person :Change password link :Change password :Change password form :Account :Confirmation
<<Actor>> <<boundary>> <<Controller>> <<UI>>
click
1. Members click
'change password' link.
create
2. The system will display
the form that used to
change password. create
3. Members fill the old

password and the new fill
password .
4. click the change button. submit
5.The system will
display a successful check
message when replace
the old password by the
new password to the if not valid
database.
display error message
5. The system displays an
error message.
validated
6. The system will give a
chance to re-enter the old create
password.
display
Figure 4.2.9. Sequence diagram change password
54 | P a g e
4.3.2. Activity Diagram
Activity diagram used to emphasize the flow of control from activity to activity or to model the low of an
object as it moves from state at different points in the flow of control.
1. Activity Diagram for Registration.
Fig 4.3.1 Activity Diagram for Registration.
55 | P a g e
Fig 4.3.2 Activity Diagram for login.
56 | P a g e
Fig 4.3.3 Activity Diagram for create account
57 | P a g e
Fig 4.3.6 Activity Diagram for request
58 | P a g e
Fig 4.3.7 Activity Diagram for views report
Fig 4.3.8 Activity Diagram for views request
59 | P a g e
Fig 4.3.9 Activity Diagram for search
60 | P a g e
Fig 4.3.10 Activity Diagram for assign technician
61 | P a g e
Fig 4.3.11 Activity Diagram for update
62 | P a g e
Fig 4.3.12 Activity Diagram for change password
63 | P a g e
4.3.3. State Chart Diagram
State diagrams show the various states that are valid for an object (which could be anything from a
method to a class to the system as a whole.
Initial Time=0
Time=10
Logging in invalid username or Password
Valid Entry Time<10 sed
Logging in
Fig 4.3.13 State Chart Diagram for login
64 | P a g e
Fig 4.3.13 State Chart Diagram for home page
65 | P a g e
Chapter Five:
SYSTEM DESIGN
Introduction
In designing this system, the object-oriented system approach was used. Specifically, to design the
System we have used UML the reason why we used object-oriented approach is that it allows
decomposition of systems in to objects.
Designing a system has a goal to involve converting the proposed system in to logical and then physical
design specification. We expect one can understand our new system implementation because it gives full
description about whole system. Also one can understand easily and enable to answer how the system
developed and functioned in simplified manner.
This project is a website web based maintenance management system it was solve problems related to
facility maintenance office. This website was help to the web based maintenance office to accomplish
their daily tasks easily and provides flexible service for the users. It makes the system easy to use.
Within the Software Design Document are narrative and graphical used throughout the document, Next,
the document describes the system under development in terms of subsystem decomposition,
hardware/software mapping, persistent data management and access control. Generally the purpose of this
document is to determine how we are going to implement our system and to obtain the information
needed to derive the actual implementations of our system.
5.1. Design Goal

Our system designing phase was on the bases of object-oriented system approach, this designing phase
uses activity and other diagrams to model the system. The design phase is the interface between the
requirement specification and the implementation part. One of the importance’s of this phase is to clarify
specifications as it clearly represents the blue print of the actual system.
The following design goal identified:-
Security: The system should be designed to prompt the user with password and user name. This provides
security in such a way that unauthorized users can not have access to the system’s resources. Moreover,
the system should be designed to reject invalid user inputs to ensure the system’s robustness for all
interacting users.
66 | P a g e
Maintainability: the system should be extensible enough to incorporate functionalities and easy
modifiable.
User Interface: Our system provides user friendly and self-explanatory graphical user interface that eases
the interaction of the user with the system.
Performance: The response time to users request should be tolerable.
Reliability: The system should be reliable and consistent so that it provides the correct result in all
circumstances unless an error is encountered. If an error occurs the system was traps the error in the input
and notify the user to take appropriate corrections.
Availability: The system is web based or online system so it was be accessible 24 hours per day and 7
days per week unless some problems happened like connection failure, power failure and other. And also
the system accessible from any system that can operate internet access (like computers, smartphones,
tablets and soon) and was be accessible anytime a user would want to use the system.
Easy to use: This system was have a well-defined and easily understood interface. The processes was be
easy to understand and use by a user’s.
Data integrity: The system to maintaining and assuring the accuracy and consistency of data over its
entire life-cycle, and is a critical aspect to the design, implementation and usage of system which stores,
processes or retrieves data
5.1.1. End User

Usability is the extent to which a product can be used by specified users to achieve specified goals with
effectiveness, efficiency, and satisfaction in a specified context of use. From the end user's perspective,
the system should be designed in such a way that it is easy to learn and use efficiently.
5.1.2. Priority of Design Goal

Maintenance Management System is to facilitate the web based maintenance system and provides
efficient service at the right time.
5.2. Current System Architecture

In the current state of art OSU Maintenance Management System fully paper-based system. Therefore,
the project team identified that the current software architecture of the existing system has no any
architecture.
67 | P a g e
5.3. Proposed System Architecture
This part describes the overall system architecture of facility management system how it is decomposed.
User interface: - that holds all possible presentation of the system, which is directly accessed and used by
users.
Database access: -which has direct interaction with database. It retrieves data from the database and
gives to logic process for further displaying to users by. It stores data as variables.
Web Server:-it stores the overall data that passes through the data base.
Figure 5.1 Proposed System Architecture
68 | P a g e
5.3.1. Subsystem Decomposition
To effectively provide these services as per the goals specified, the system is decomposed into SIX main
subsystems. These main subsystems are called facility maintenance management User Interface
subsystem and facility maintenance management Database.
The subsystems are described as follows:
Decomposition 1
USER<<BROWSER>>
TASK ASSIGN
MODULE
REQUEST MODULE
REPORT
MODULE
SERVER<<WAMP>>
DATABSE<<MYSQL>>
Fig 5.2 Subsystem Decomposition 1
Decomposition 2
USER<<BROWSER>>
Task assign module

REPORT MODULE
Request
MODULE
SERVER<<WAMP>>
69 | P a g e
DATABSE<<MYSQL>>
Decomposition 3
USER<<BROWSER>>
UPDATE
MODULE
ACCOUNT MODULE
SECURITY
SERVER<<WAMP>> MODULE
DATABSE<<MYSQL>>
Decomposition4
USER<<BROWSER>>
ACCOUNT
SECURITY MODULE MODULE
SERVER<<WAMP>>
DATABSE<<MYSQL>>
70 | P a g e
Decomposition 5
USER<<BROWSER>>
TASK ASSIGN MODULE REQUEST

MODULE
SERVER<<WAMP>>
DATABSE<<MYSQL>>
Decomposition 6
USER<<BROWSER>>
UPDATE MODULE ACCOUNT

MODULE
SERVER<<WAMP>>
DATABSE<<MYSQL>>
71 | P a g e
5.3.2. Hardware/Software Mapping.
Since the maintenance management system web based it needs servers networks, cables, and related
network hardware. The proposed subsystem will be implemented in Client Server architecture.
In this type of architecture, the clients request the server and the server responds to the client. Then the
client can get the information whatever they request to the server.
The first type is a web server which is responsible for receiving browsers' requests through the HTTP
protocol and responding accordingly the second type of server is a maintenance server, which is
Responsible for providing the requested maintenance services to the web server. The maintenance server
is responsible for the modification and insertion of material into the maintenance.
The client side is a web browser that receives requests from the user of the system and responds to the
request by communicating with the web server. The web server will run over XAMPP 3.2.1 Server, the
programming language Used to develop the proposed system is PHP version 5.2.6 and some scripting
languages such as hypertext markup language (HTML), Java script (JS) and MYSQL version 5.0.5 I b as
the maintenance management system or maintenance server.
The system was deploy or installed in server machine and can be accessed in the client side which means
the node is a three tier.
5.3.3. Deployment Modeling.

UML deployment diagram show physical view of system, taking software into real world by showing
how software gets assigned to hardware and how communicates. The deployment diagram shows how the
software components, processes, and objects are deployed into the physical architecture of the system. It
shows the configuration of the hardware units (e.g. Computers. communication devices, etc.) and how the
software components are distributed across the units. Oromia State University Online Student clearance
Management System is server client structure architecture, where clients access services offered by
server.
72 | P a g e
Fig 5.8 deployment diagram
73 | P a g e
5.3.4. Detailed Class Diagram
Class Modeling is design level that introduces changes to analysis class model based on implementation
technologies. It focuses on the solution domain instead of the problem domain. It shows static nature of
how the software is built.
Fig 5.9 Detail class diagram.
74 | P a g e
5.3.5. Persistent Data Privilege
The system was depend on a relational database to perform day-to-day operations and storing data.
Data was be stored in apache and manipulated through the Database Subsystem, which was ensure
integrity and consistency of the data. It allows the database to be easily integrated with and accessed by
the rest of the system. The database was retain customer information, managerial information, technician
information, system administrator information, types of requests and orders. Whenever possible, the data
itself was be used as a primary key – in the case of the user’s information table, the account and empid
would be unique to each user. An individual could not have more than one account and empid.
Request table
Attribute name Data type Null Default Remark
Request id Int No Int Necessary
Type Char No Necessary
Date Int No Necessary
Time Int No Necessary
Table 5.2 Persistent Data Privilege request table
User table
Empid Int No Int Necessary
First name Char No Necessary
Last name Char No Necessary
Location Char No Necessary
Address Char No Necessary
Table 5.3 Persistent Data Privilege user table
75 | P a g e
Account table
Account id Int No Int Necessary
Account type Char No Necessary
Username Char No Necessary
Password Char No Necessary
Table 5.4 Persistent Data Privilege account table
Technician table
Emp id Int No Int Necessary
Table 5.5 Persistent Data Privilege technician table
Manager table
Empid Int No int Necessary
Table 5.6 Persistent Data Privilege manager table
76 | P a g e
Maintenance table
Id Int No Int Necessary
Type Char No Necessary
Date Char Yes Optional
Name Char Yes Optional
5.4. Package Diagram

A package diagram is a UML structure diagram that shows packages and dependencies between the
packages. A package diagram enables you to gain a high-level understanding of the collaboration among
model elements by analyzing the relationships among their parent package. This also helps explain the
system's architecture from a broad view.
77 | P a g e
Fig 5.10 Package Diagram
78 | P a g e
5.5.Algorithm Design.
An algorithm design is detail serial of instruction for carrying out an operating or solving a problem. In a
non-technical approach.
Technically, our project use algorithms to list the detailed instructions for carrying out an operation to
compute online student clearance management system, the computer uses an algorithm. To accomplish
this task, appropriate data must be entered into the system. An algorithm is a detailed series of
instructions for carrying o Out an operation or solving a problem.
Pseudo code Manager
Steps/procedure
Method name= 0fficer
Begin
Variable:
User Name
Password
user type
If (*variable is valid*)
Then
Manager is the maintenance quality checker.
Otherwise
Display "the entered input is invalid'"
End if
End
Pseudo code System admin
Steps/procedure
Method name- System admin
79 | P a g e
Begin
Variable:
User Name
Password
user type
If(variable is valid*)
Then
The system admin check status of the maintenance clearance
Otherwise
Display he entered input is invalid"
End if
End
Pseudo code User
Steps/procedure
Method name= User
Begin
Variable:
User Name
Password
user type
If (variable is valid*)
Then
User check status of the clearance
Otherwise
80 | P a g e
Display "the entered input is invalid"
End if
End
Pseudo code Technician
Steps/procedure
Method name= Technician
Begin
Variable:
User Name
Password
user type
If (variable is valid*)
Then
Technician check status of the maintenance
Otherwise
Display "the entered input is invalid"
End if
End
81 | P a g e
5.6. User Interface Design.
User interface design is the specification of the interaction between the system users and a system.
Fig 5.13 Login interface
82 | P a g e
Fig 5.14 Create Account interface
Fig 5.15 Home Page interface
83 | P a g e
Web Besed Maintenance Managment System
-End1 -End2 -End3 -End4
Home Page
1 * * *
Home Page About Maintenance Feedback Help Page Login Page

About Us Contact
Interface1
-End5 -End6
User Technician Manager
* *
End13
End1 End1
Approve expert
Generat Report
Update Profile
Generate Report
Register Admin
Search Maintenance Veiw Apprpove
Maintenance Veiw Request Maintenance Purchese

Search
Register Dep't
Take Maintenance darector
Manage User View case

End14 End2 End2
Register Offiser Veiw case
End3
End9 Add case
Register Faculty
End11
Register User
End8
End7 End10 End12 End4

End5 End6
Fig 5.16 relationship interface
84 | P a g e
5. 7. Conclusion
Web based maintenance is one of the most important maintenance department in Oromia State
University. Web based maintenance is still in using manual system of files store. This system is
inefficient as well as looking up of specific information. This greatly affects the flow of Critical
information. All these deficiencies are removed using the online web based maintenance
management system. Web based maintenance management system effectively stores all the
information that are send from the customer which have all the necessary information about the
problem and the manager can see the requests. All these improvements greatly reduce the time
at which specific information is delivered to web based maintenance office.
5.8. Recommendation
Currently web based maintenance Management System can only be deployed for a manual based
with some computers. But the system has to be developed as computerized application where
each implementation of web based maintenance management can be connected and
communicate with each other. This will make the whole system highly centralized as well as
well connected.
85 | P a g e
5.9. References
These are the references that we use
Uml applied (object oriented analysis and design using Uml)
Doug Rosenberg and Matt Stephens 2007(use case driven object modeling with Uml: theory and
practice)
Margareta Rouse. (2013). Use case Diagram[online]. Website:
http://saerchsoftwareequality.techtarget.com/ Retrieved on: [December 14, 2014].
Kirill Fakhroutdihov. (2014). Sparx System: UML diagram[Online]. Website: http://www.uml-
diagrams.org/ Retrieved on: [December 20, 2014].
Scott Sehlhorst. (2006).RequirementGathering [Online]. Website:
http://www.tynerblain.com/blog. Retrieved on: [November 10, 2014].
Design specification template http://www.construx.com/survivalguide/desspec.html
http://en.wikipedia.org/wiki/Activity_diagram
Lars Mathiassen et.al 2000. Object oriented analysis & design. Marko, Aalborg. Dk.
86 | P a g e
87 | P a g e

My Project5

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

My Project5

Uploaded by

Copyright:

Available Formats

OROMIA STATE UNIVERSITY

COLLEGE OF SCIENCE AND TECHNOLOGY

NAME OF THE STUDENTS IDNO

Under the Advisor:- Instructor Feyisa Gemechu(MSc)

Oromia State University, Batu, Ethiopia

Web Based Maintenance Management System Page i

Submitted to Department of Information Technology, College of Science and

Under the Advisor:- Instructor Feyisa Gemechu(MSc)

Oromia State University, Batu, Ethiopia

Web Based Maintenance Management System Page ii

Month Date, Year

Web Based Maintenance Management System Page iii

Advisor Name Signature Date

Web Based Maintenance Management System Page iv

Web Based Maintenance Management System Page v

Web Based Maintenance Management System Page vi

DECLARATION ........................................................................................................................... iii

Approval Form ............................................................................................................................... iv

List of Table .................................................................................................................................. xv

LIST OF ACRONYMS ............................................................................................................... xvi

Microsoft word............................................................................................................................. xvi

Chapter One .................................................................................................................................... 1

1.Background of the Organization .................................................................................................. 1

1.1. 2.Vision .................................................................................................................................... 2

1.2.Statement of the Problems ........................................................................................................ 2

1.3.Objective of the project ............................................................................................................. 2

1.3.1. General Objectives ................................................................................................................ 2

1.3.2. Specific Objectives ............................................................................................................... 3

1.4. Feasibility Analysis. ................................................................................................................. 3

1.4.1. Technical Feasibility. ............................................................................................................ 3

1.4.2. Operational Feasibility .......................................................................................................... 4

Web Based Maintenance Management System Page vii

1.5. Significance of the project ....................................................................................................... 5

1.5.1. Beneficiary of the Project ..................................................................................................... 5

1.6. Scope and Limitation of the Project......................................................................................... 7

1.6.1.Scope of the Project ............................................................................................................... 7

1.6.2. Limitation of the Project ....................................................................................................... 8

1.7.1. Data Collection Tools/Techniques ........................................................................................ 8

1.7.2. System Analysis and Design ................................................................................................. 9

1.7.3. System Development Model ................................................................................................. 9

1.7.4. Testing Methodology. ......................................................................................................... 10

1.7.5. Development Tools and Technologies................................................................................ 10

1.7.5.1. Frontend Technologies..................................................................................................... 11

1.7.5.2. Backend Technologies ..................................................................................................... 11

1.8.Budget and Schedule of the Project ....................................................................................... 11

1.8.1. Budget of the Project .......................................................................................................... 12

1.9. Team Composition. ................................................................................................................ 13

Description of the Existing System............................................................................................... 14

2.1. Introduction of existing system .............................................................................................. 14

2.2. Players in the Existing System ............................................................................................... 14

Web Based Maintenance Management System Page viii

2.3. Major functions/activities in the existing system................................................................... 15

2.4. Business Rules of the Existing system .................................................................................. 16

2.5. Report generated in the existing system ................................................................................ 16

2.6.Maintenance registering form ................................................................................................. 18

2.7. Bottlenecks of the Existing System ....................................................................................... 18

2.7.1. Performance (Response time). ............................................................................................ 18

2.7.2. Input (Inaccurate/redundant/flexible) and Output .............................................................. 19

2.7.3. Security and Controls .......................................................................................................... 19

2.7.4. Efficiency ............................................................................................................................ 19

2.8. Practices to the Preserved ...................................................................................................... 20

3. Proposed System ....................................................................................................................... 21

3. Data flow diagram for proposed system. .................................................................................. 22

3.1. Functionalities Requirements................................................................................................. 22