ABSTRACT

This project is entitled with “Maintenance Record Management System for Kombolcha
Polytechnic Maintenance Office”. The project would have support Kombolcha Polytechnic
facility office to perform maintenance activities in divided categories such as Furniture
maintenance (chair, table, door, window, locker, and door key), and Electronic Device
maintenance (desktop, laptop, fan, AC, pulp). Currently the maintenance system faces many
problems these are time wastage, queuing problem of requests, and delay of service. When we
observing such like problems especially in electronic and furniture category, we initiate to
develop this project with the objective of solving the customers and Kombolcha Polytechnic
Maintenance office problem in maintenance activity. Our project would have user friendly
interface design to make it easy for user. The System has four actors these are: system admin,
Team leader, Technicians, and End users (customers). The end user sends a request to team
leader when the material is malfunctioned then team leader assign technician then finally the
technician maintains the material.
 CHAPTER ONE

1.1 INTRODUCTION
1.1.1Background of the organization
Kombolcha Polytechnic is one of the greatest Colleges of Ethiopia, which is found in Amhara
region southern part of Ethiopia. It was established in 1997 E.C and in 1999 E .C it was actually
opened with two campuses (i.e.Dessie and Kombolcha). Kombolcha Institute of Technology
(KIOT) is one of the well-known Institute Of Technologies in Ethiopia which is located in South
Wollo zone of the Amhara region. KIOT maintenance Office was established in 1999 E.C
together when the campus established.

The Office started to provide full service and its name was changed to repair and maintenance
team office, now it has two main departments such as Furniture Maintenance and Electronic
device maintenance. There are 15 employees in the office.

KIOT Repair and Maintenance Office has a great role in the Campus by maintaining the
malfunctioned materials and by giving so n y Facility services. It provides
information about broken material and maintains them. To facilitate this activity, the
organization uses a manual system to register and follow all of the activities done by customers
and technicians. Due to this, system user loss their time, power and resource to report the broken
material to get the service. This makes the customer to incur extra cost and wastes much time to
send service request to the system when the necessary material is broken, and also when the
maintenance head assign technicians to customers.

We initiate to develop the web based material maintenance management system by considering
the current system it is performing its operations manually. Hence the manual system is lying to
errors and in addition it has many disadvantages related to the organization’s and customer’s
resources like time, labor, money and other resource. By analyzing these problems, our project
has targets for such problems occurred on manual system and planned to solve the problems.
1.1.2 Introduction about the project
Our project will be done for Kombolcha Polytechnic maintenance system. Still, the system is
manual. It should be web based to maximize the benefits gained from information technology
The current system has too much problems such as:-Files are exposed to be lost and damaged
since the files are stored on a paper, it takes too much time to get any information for Kombolcha
Polytechnic Maintenance office, it is not secured, it is costly, it increases employee burden and it
is quite difficult to generate report. The main intension of this project is to create web based
Kombolcha Polytechnic maintenance system, turn the manual in to automated operations for easier
management, speed up operations for better record keeping, to help management make better
decisions and to make the system simple, effective and efficient. In addition the proposed
system will allow users to request online, managers to respond online, to reduce data
redundancy, to see technician’s status and to assign them online by the manager, to generate
report, to search and view the availabilities of items used for maintenance purpose etc.
The web based Maintenance Record Management System is the main output of this project. The
project supports Kombolcha Polytechnic maintenance Office to perform Maintenance activities
in divided categories such as Furniture Maintenance (chair, table, door, window, and door key,
etc.), and Electronic device Maintenance (desktop, printer, fan, AC, pulp, etc.). When one’s
Material failed or broken report to technician’s office then technician head identifies the
problems that are electronic Maintenance, furniture Maintenance finally assigns technicians to
the Materials properly functioned. So The System allows applicants to register broken or
malfunctioned item information, the System administrator would respond to applicant’s request,
the maintained Material quickly give Facility, the System saves a lot of time, money and human
power, avoid data redundancy, which means extended data can be retrieved without affecting
Other data and Reduce response time of customer’s request.

1.3 Statement of the problem

The current MRMS perform every activities manually it hasn’t any well-organized file/data
management system. As we get the information by interviewing some members of the office and
by direct observing user’s interaction to the system the current system is totally full of problems.

The following are the most noticeable problems of the current system:-

 Performance problem
The current system unable to perform tasks and activities with efficient and required time .It is
tedious and not fast and accurate communication among each department.
  Information Problem
 Lose of data may occur.
 Due to manually collecting of data there is a redundant record and
inconsistency problems.
 In accuracy of data and information may produced
 Incorrect information leads to poor decision making
 Poor flow of information between departments

 Data storage problem

 Lack of a well-organized database system
 Data are not easily accessible due to its integration and placed in different
location
 Difficult to change and edit
 Data redundancy that leads to inconsistency

 Efficiency Problem
The efficiency of the existing system not optimal, because
 Storing, locating of data takes much more time
 Redundancy flow of information, data can be inputted, processed and
produced as redundantly as demands much time.
 Security and control problem
   The current system can be accessed by unauthorized person, since it doesn’t have any
authentication and authorization system.

 Quite difficult to know solved and unsolved problems timely.

1.4 Objectives

1.4.1 General Objective

The general objective of the project is to develop Web based Maintenance Record Management
System for Kombolcha Polytechnic maintenance Office.

1.4.2 Specific Objective

To achieve the general objective, the following specific objectives are undertaken:
  Gather/elicit requirements from the existing Systems e.g. what is the information
necessary to generate information etc.
 Analyze and specify the requirement of the System.
 Design a way to solve the problem that is specified analysis phase of the proposed
System for Maintenance Record Management System.
 Design user friendly interfaces.
 Design easily accessible databases.
 Test the System using different testing methods to be sure the System is implemented
with all the functionalities.
 Deploy the System into the working environment for Kombolcha Polytechnic.

1.5 Significance of the project

Our project has the following significances after the System is deployed in the working
environment.

 Facilitate communication between staff workers or end user and Maintenance

Department.
 Customers can send their service request to Maintenance department easily.
 Customer can get service within expected time.
 To generate effective and reliable Maintenance reports
 Facilitate the access of the System online in all areas of Kombolcha Polytechnic.
 Timely availability of resource.
 Cost saving and highly save the customers time.
 Reduce loss of data.

1.6 Scope and Limitation of the Project

1.6.1 Scope of the project
The Web based Maintenance Record Management System helps Kombolcha Polytechnic
maintenance Office to accomplish their services to the College by dividing their works into
basically two categories in order to facilitate the overall activities of Maintenance. So we
propose this project for implementing to play roles in the following scope:

 Managing the requests that are sent from client to get services from the office.
  Assign technicians for broken categories of Materials.
 Generate the report for the performed activities.
 Storing and retrieving information for Kombolcha Polytechnic on Maintenance activities
these are: Electronic Device Maintenance and Furniture Maintenance.
 Managing information that the users and Maintenance department communicate
together.

1.6.2 Limitation of the project

The limitations of our project are listed below. They are constraint that our project does not
support them in any case. These are:

 Our project would have used only one language that is English.
 This System is inaccessible outside of Kombolcha Polytechnic. It is accessible only in
Kombolcha Polytechnic local area network.
 Our System can’t perform automated detection when Material is broken or malfunction.

1.7 Methodology
1.7.1 Data Gathering Methodology
For designing and developing the Maintenance Record Management System, we used the
following methods to gather information about the current System and alternate ways to develop
the new System.

1. Primary Data Gathering Methods

 Interview: we ask questions face to face how the System working about the
Maintenance Record Management System.
 Observation: we use this method to get the right information about the
organization and also to understand the existing System works.

2. Secondary Data Gathering Methods

 Document analysis: we use this method to analyze written document in the
Repair and Maintenance Office and get more secondary source information about
the Maintenance System, project report documents and other reading Materials
that were needed to develop this System.
1.7.2 Development Methodology
Among the different methodologies, we plan to use the object oriented System
development methodology for the development of our System. The team will use object
oriented System development methodology. This methodology is used for simplicity,
increased quality, faster development, code reusability and maintainability of the System.
In our project we use development methods in three phases that are [3]:
 Object Oriented Analysis (OOA): During this phase our team members will
look at the problem domain, and with the aim of producing a conceptual model of
the information that exists in the area which will be analyzed [4].
 Object Oriented Design (OOD): During this phase Model object interactions
and behaviors that support the use case scenario, and finally update object model
to reflect the implementation environment and transforms the conceptual model
produced in object oriented analysis to take account of the constraints imposed to
the System format, so that the team members will use this phase to refine the use
case model to reflect the implementation environment [3].

We used OOSD because of the following important features:

 Increase reusability: - the object oriented provides opportunities for reuse through
the concepts of inheritance, polymorphism, and encapsulation [12].
 Increased extensibility: -when you need to add new feature to the system you only
need to make changes in one part of the applicable class [12].
 Flexibility: It is really flexible in terms of using implementations [14].
 Improved quality: - quality of our system must be on time, on budget and meet our
exceeded the expectation of the users of our system, improved quality comes from
increased participation of users in the system development [13].
 Financial benefits: - reusability, extensibility and improved quality are all the
financial benefits, because they led to the business benefits of the object- oriented
from the point of view of the users, the real benefits are we can built, system faster
and cheaper.
  Object oriented implementation (OOI): During this phase the design is
implemented using object oriented languages such as PHP platform and backend
Database.

1.8 Development Tools

1.8.1 Hardware tools
Hardware tools are tools that we need to develop our System and how much it needs. Such as

 Personal computer (either laptop or desktop).

 USB flash disk (8 GB)
 Pen, paper, pencil

1.8.2 Software tools

These are tools that we need to develop our System. Before starting our project, the software
tools should install and ready to use.

Software Purpose

Notepad++,notepad, Dreamweaver For editing php and html codes

Edrawmax and virtual paradigm To draw UML diagrams

Wampserver To run php code

Msword2007, 2013, 2010, 2016 To edit the documentation of the project

MYsql server To test mysql database

Windows 10, 8.1 pro To operate all the activities

TABLE 1 SOFTWARE TOOLS

1.9 Organization of the project

Our project documentation basically has five chapters .The first chapter is the proposal part
which gives brief explanation about background of the project, scopes, limitations and
objectives of the proposed system. The second chapter deals about Description of the Existing
System and Requirement Gathering. The third chapter deals about Analysis of the system. The
 fourth chapter studies about Design of the system. Fivith chapter studies about Design of the
system .The Sixth one which holds the conclusion and recommendation of Kombolcha
Polytechnic MRMS and points for future studies.

1.10 Beneficiary of the Project

 Staff members:-
 Can get service easily
 Save their time
 Reduce workers load
 Decrease errors in information access of the manual system
 Employees:-
 Saving their time and work loads
 Reduce complexity
 Easily access information from organized and centralized
database.
 Group members:-
 The project has initiated our team to get knowledge of how to
develop the required system application. While struggling with
some difficulties, the team got a lot of experiences of solving
problems

1.11 Feasibility Study

1.11.1 Economic Feasibility

These project has economic feasibility is to identify the financial benefit and cost association
with the development project, economic feasibility is often referring to us cost benefit analysis.
Thus we have stated the costs related to the project which is small amount compared to the
benefit that will be gained after completion of the project.

1.11.2 Technical Feasibility

The development of proposed System software is feasible because the technical resources needed
to develop, install and to operate can be done by the developer or the project team. It is planned
to implement the proposed System using PHP Platform, MySQL, and Windows 10 operating
System.

1.11.3 Operational Feasibility

The proposed System will be operated and accessed easily as it has a user-friendly interface.
Once the System is deployed, it can operate on any of the operating Systems without any mal
functionalities. The users of the System can be trained easily because of the simplicity of the
System. Hence, the System is operationally feasible.

1.12 Work Plan(Gantt Chart)

Work plan schedule is concerned with analyzing the expected completion date of the project and
the constraints that may bring change to this date. So we have a schedule to work together the
project with our group members within each day and for the simplicity and fast developing
purpose.

List of activities are depicted in the following Gantt chart. Major tasks are listed here and
routines of activities can be performed accordingly.
 Project schedule
Date
March2 May18- May29- Julay5- Julay9 Sept10-
0- May28- Julay4- Julay8 - Sept Oct3
May17- 2022 2022 2022 Sept9- 28- 2022
Activity
2022 2022 2022

Data collection

Analysis

Design

Finalized documentation

Coding/implementation

Testing

Presentation

Figure1 Tentative Schedule for the project

Team composition
ID ID Numbers NAME Responsibility
1 WOUR/0544/11 Adane Anbaye All Activity
2 WOUR/0598/11 Bosena Gereme All Activity
3 WOUR/0710/11 Mariyan Hasso All Activity

Table 2 Team composition

1.13 Cost break down
This describes the costs that will finish when we develop our system from initial stage up to
implementation stage.

NO. Name of Tools Quantity Amount of Cost

1 Computer 1 25000

2 Flash Disk 1 300

3 For printing - 200

document

4 Paper 1pack 200

5 Transport - 500

6 Internet(for - free
reading)

7 TOTAL - 26200

Table 3 budget plan of the project

1.14 Project risks and management strategies

The objectives of Risk Management are to increase the probability and impacts of positive events
and decrease the probability and impacts of events adverse to project objectives Since the
methodology is object oriented its risk is low, but its reusability is high due to this the system
has no more risk. Sample risks and their solutions are listed below:

 It may not be possible for us to complete the project in given strict time deadline if we try to
add all functionalities and make the software work for any Organization

 Possible solutions:-
 Discuss with our advisor about the problem

 Ask our advisor in order to tell us best ways

 Most of the employees do not have basic computer skill

 Possible solution:-Train employee

 Some employees cannot tell what problem has the system they are using.

 Possible solutions:-

 Asking them clear questions

 By observing the problem they have

 By preparing a paper to write a problem when it occurred

CHAPTER TWO

2. Description of the Existing System and Requirement Gathering

2.1 The over view of the existing System
Currently Kombolcha Polytechnic Maintenance Office work’s manually. The office accepts the
customer’s request on the paper form. The existing System of Kombolcha Polytechnic
Maintenance Office performs all its work in manual way. In this case: if the Materials are
malfunction, the user reports to the team leader by going physically. Before the team leader
assign a technician the user need to fill paper form then the leader assign technicians and the
technician are assigned by paper. The technician stores the papers in some shelf and he report to
his leader what he have performed in Maintenance per a week or per a day.

2.1.1 Problem of the existing System

The existing System has faced with many problems. Among those problems:

 The System is prone to error.

 The other problem is that data Management related problems this implies the data is not
easily accessible, not well organized, and the data is stored redundantly in the form of
multiple copies of files.
 Due to of files there may be wastage of necessary data.
 Since it is manual based the System is not efficient, do not give better quality service as
users need.
 Due to this reason user do not satisfy with the service provided by Kombolcha
Polytechnic Maintenance Office.
 It also takes so many times to report the broken Material due to the need of going
physically.
 Due to this reason customer lose their time and power to get service from the office.
 The files are prone to external damages (such as theft, wet) because it is stored in shelf.
2.1.2 Weakness and strength of the existing System

2.1.2.1 Weakness of the existing System

Mainly the weakness of the existing System is already listed above on the problem of the
existing System section. In addition to that the existing System has weakness that is concerned
on performance of the System. Among those

 Delay of service
 The efficiency of the Maintenance activity is not enough.
 There is queuing problem of requests received from customer.
 The System requires many numbers of employee and energy.
 The data may loss and redundant.

2.1.2.2 Strength of the existing System

 It is independent of network (which can work without network connection).

2.1.3 Business rules of the existing System

A business rule is effectively an operating principle or polices that must be fulfilled and
Obligated in order the System will function properly and effectively. It often related to access
Control issues, business calculations, or operating polices and principles of Kombolcha
Polytechnic Maintenance Office. To perform the tasks successfully the actors should follow the
following rules:

BR1: The technician should plan their daily work.

BR2: Team leader collects the technicians plan and develop team plan.

BR3: Director receives team plan from each team leader and design directorate plan.

BR4: Each plan should be designed in terms budget, time schedule, and man power required.

BR5: Technician should contact with their leaders with in each entry and exit time.

BR6: The team leader should give priority for the task that needs quick response.

BR7: The team leader should generate report per week and redirect to directorate office.

BR8: Team leader should control and evaluate technicians who are led by him.
BR9: Director directs the team leader to indicate what they should do.

BR10: Team leader evaluates the technician based on the feedback received from customers and
performed activities.

BR11: The employee controlling System should keep their hierarchy means director controls
team leader, team leader controls technician and technician should take responsibilities of the
task.

2.2 Overview of the proposed System

Aim of the proposed System is to develop improved facilities that can overcome all the problems
of the existing System. The System provides proper security and reduces a wide range of manual
work.

Maintenance Record Management System is design to provide fast and easy way of controlling
all the activities of maintaining Materials in Kombolcha Polytechnic Maintenance Office. It is
also used to communicate end users with Maintenance Office using the web, keep the data for
the longest time with in the database.

Our proposed System provides an easy way for end user to send request for Maintenance service.
The System also provides an easy way for admin to manage user accounts and to see end user’s
request on the web and approve their request. The System also used to the team leader can view
the request and assign technician based on technician’s status.

Generally, Maintenance Record Management System is concerned on managing the flow of

information for purpose of maintaining malfunctioned Materials, providing easy and
understandable way of controlling the activities of maintaining Material, and making easy and
fast communication held between end user, System admin, Team leader and technicians.

Our proposed System is better from the existing System because of the following advantages.

 Improved accessibility of customer data.

 Reduce data redundancy.
 Maintain quality data.
 Avoid inconsistency.
 Maintain integrity.
  Enforce security measures.
 Centralized information control.

2.2.1 Functional requirements of the proposed System

Functional requirement consists of a specification of a function that the System supports. In this
section we discuss what is our web based System is expected to do is. The type of user in this
System is customer (End user), System admin, Team leader and Technician.

This section includes the requirements that specify all the fundamental actions of the
Maintenance Record Management System. So under this we try to put all the functionality of our
System by classifying based on actors.

System Admin:

 The System allows the System admin to login before accessing the System.
 The System allows the System administrator can create user account for Team leaders,
and technician
 The System allows System admin to manage all user accounts.
 The System allows System admin to send and receive message.

Technicians:

 The System allows Technicians to view their assigned requests.

 The System allows Technicians to generate report to indicate their completed task.
 The System allows Technicians to send feedback.
 The System allows Technicians to send and view message which is sent to him.

Team leader:

 The System allows Team leader to View report that generated by technician.
 The System allows Team leader to approve request after viewed.
 The System allows the Team leader to checks status of technicians.
 The System allows the Team leader to assign technician based on the request type and
technician status.

End users:
  The System allows the End user send request for service.
 The System allows End user send confirmation for the accomplished request.
 The System allows users send feedback and Team leader receive comments about the
Maintenance activities.
 The System allows End user to View their request and status of it.
 The System allows End user to update the request.

2.2.2 Nonfunctional requirements of the proposed System

Non-Functional requirements describe user visible aspects of the System that are not directly
related with the functional behavior of the System. But it can support and give more quality for
the new System. The non-functional requirements also address aspects of the System
development process and operational personnel. It includes the following:

 The System shall be user friendly and consistent

 The System shall provide attractive graphical interface for the user
 The System shall target customer base

Usability

 The System should provide an easy-to-use graphical interface so user can easily learn
how they use the System. So, little knowledge on how Web pages can be accessed is
required for user to use, it does not being complex.

Effectiveness

 Our System should have the capability of producing a desired result or the ability to
produce desired output. When something is deemed effective means it has an intended or
expected outcome.

Efficiency

 The quality of producing the outputs. Our System have should have minimum resource
consumption to produce the output.

Fault tolerance
  It the property of the System that enables a System to continue operating properly in the
event of the failure of some of its components.

Interoperability

 It is a characteristic of our System whose interfaces are completely understood to work

with other products or Systems.

Extensibility

 Our System has design principle where the implementation takes future growth in to
consideration. The System can upgrade and growth for the future.

Maintainability

 It is the ease with which a product can be maintained in order to:

 Correct defects or their cause.
 Repair or replace faulty or worn-out components without having to replace still
working parts.

System Performance
Response Time: The output should be generated within a maximum of 3 seconds depending on
the performance of the computer device.

 Response time of the System should be 2 and 3 seconds in worst case. The System should
show no visible deterioration in response time as the number of users or reservation data
increases.

2.2.3 System requirements of the proposed System

System requirement is the requirement that is needed for deploying the System in the client’s
environment. Meaning that what the user’s device should be and how much storage area it will
take in the server side because of the System is web based. So the requirements are:-

In the client side

 1 GHz processor or faster 32-bit (x86) or 64-bit (x64)

 1 GB of RAM for 32-bit or 2 GB of RAM for 64-bit
  16 GB of hard drive space for 32-bit or 20 GB for 64-bit
In the server side
 16 GB of hard drive space for windows server 2008 or 2012

2.2.4 Business rules of the proposed System

The following are our proposed System business rule that guide the user to accomplish their
task.
BR1. Team leader and technician should take user name and password from System admin.

BR2. Team leader should assign technician for the task sent from the user.

BR3. System admin should create and manage all the accounts.

BR4. Technicians should take responsibility for their assigned request to accomplish.

BR5.Users must have user name and password.

2.3 Constraints and Assumptions.

2.3.1 Constraints
Constraint is a restriction on the degree of freedom we have in providing solution. Constrains can
be economical, technical, environmental and schedule. It restricts an entity, project or System
from achieving its potential with a reference to its goal. Some of the constraints of our System
are:

Economical constraint:

There is insufficient supply of personal computer and also Materials that used to replace the old
Material.

Technical constraint:

 Failure of local area network.

 Server may stop for giving service in case of either in hotness and coldness of the
environment or in the technical error of server admin.
 In accessibility of personal computer.
 Power fluctuation.
2.3.2 Assumption
It is a belief of what we assume that are expected to happen during the project's life cycle. .
 The accuracy of the information of users is the responsibility of all users.
 The new System shall permit only authorized members who have the appropriate right to
update, edit and delete the information.
 Nobody should be allowed to login to the System except authorized users who have user
name and password to get into the System.
 To use the new System end user should be employee of the College.
 Customer must be good in computer usage and so on.

2.4 Modeling the existing systems

2.4.1 Essential Use Case Modeling

Essential use case diagram just to describe the general over view of existing system, identify the
function of existing system and anything or anyone that interact with the system. Essential use
case is a use case that is technology independent, it describes the fundamental business tasks
without bringing technological issue into account. Use case diagram contains four components.

 The boundary, which defines the system of interest in relation to the world around it.
 The actors, usually individuals involved with the system defined according to their roles.
 The use cases, which the specific roles are played by the actors within and around the
system.
Figure 2 Essential use case diagram
2.4.2 Essential User Interface Prototyping

A technology-independent prototype created using paper that can be used to identify UI

requirements.

Figure 3 Essential user interface prototype.

 CHAPTER THREE

3.System Analysis( Modeling the Propose System)

This chapter deals about the modeling technique that follows to design the System. Object
oriented analysis design technique can be used. It includes System use case model, sequence
diagrams, class diagram Actor specification, use case identification and use case description.

System modeling is the process of developing abstract models of a System, with each model
presenting a different view or perspective of that System. System modeling has generally come
to mean representing the System using some kind of graphical notation, which is now almost
always based on notations in the Unified Modeling Language (UML) like Use case, sequence,
activity, class, etc. However, it is also possible to develop formal (mathematical) models of a
System, usually as a detailed System specification [6]. So our System modeling is the following:

3.1 Use case modeling

Use case diagrams of MRMS are usually referred to as behavior diagrams used to describe a set
of actions (use cases) that our System should or can perform in collaboration with one or more
external users of the System (actors). Each use case should provide some observable and
valuable result to the actors or other stakeholders of the System [7]. Our System Use case and
Actors are listed below:

Use case modeling consists of actors, use cases and their relationships.

 Actors: An actor is a person, organization, or external System that plays a role in one or
more interactions with the System.
 Use Case: The System use case to describe a sequence of actions that provide something
of measurable value to an actor and are drawn as a horizontal ellipse. The use case
diagram provides and depicts a collection of use-case, actor, and their association.
3.1.1 Use case identification
The following are the use cases identified for developing use case diagram of the Material
Maintenance Management System: -
UC01: Login
UC02: Create account
UC03: Update account
UC04: Send service request
UC05: View request
UC06: Give feedback
UC07: View feedback
UC08: Delete request
UC09: Add technician
UC10: Assign technician
UC11: Approve request
UC12: Generate report
UC13: View report
UC14: Change password
UC15: Logout

3.1.2 Actor specification

There are four actors in our proposed System; each actor has their own privilege in the System.
The actors are:

End users (staff workers): they are users or customers of the System who can send service
request to the office. They can get service from the office.

Manager (Admin): a person who have full privilege accessing everything in the System. System
admin is the manager of the office.

Team Leader: a person who leads the technician in each category. For example in electric
category there is one team leader, similarly in furniture there is one team leader. He have
privilege to assign technician.
Technician: a person who performs the maintaining activity after the request is assigned from
team leader. In each category there is a numbers of technicians lead by one leader.

The authority of each actor in MRMS has shown in the below table:

Actors Use Cases

End user (staff workers)  Login

 Send service request
 View request
 Update request
 Change password
 Send feedback
 logout
Team leader Login
View request
Approve request
Delete request
View feedback
Cancel request
Check technician status
Assign technicians
View report
Search request
Change password
logout
Technicians  Login
 View assigned request
 Generate report
 Send feedback
 Change password
 Delete request
  logout
Manager (admin)  Login
 Create account
 Update account
 Change password
 View total users
 Logout
TABLE 4 ACTORS AND THEIR USE CASES

3.1.3 Use case diagram

This is use case diagram of Maintenance Record Management System.

Figure 4 System Use Case Diagram

3.1.4 Use case description
There are two common style of description of use case such as Narrative style and Action response style.
But our project team selects Action Response style description of the use case or scenario to describe all
Use case (UC).
TABLE 5: LOGIN USE CASE DESCRIPTION

Use case ID UC01

Use case Name Login
Author Adane
Purpose To enter into privilege mode of the System
Description Login to System in order to have privileges for performing
different tasks.
Priority High
Pre-condition The users should have username and password
Post-condition Successfully login
Actor(s) End users, System admin, team leader, technicians.
Extends Logout
Flow of Event
Basic flow of event Actor action System response
1.Open MMMS 3. Log in form display
2. Click login button. 6. The System Check the validation
enter username and Password by
4. Enter username and
Authenticated user.
password
7.The System successful login and
5. The user curglick login
display main page
button
8. Use-case ends
Alternative flow of event A7. The user name and password are incorrect please enter correct
user name and password message is display.
Exceptional flow of event E7. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.
Includes
TABLE 6: CREATE ACCOUNT USE CASE DESCRIPTION

Use case ID UC02

Use case Name Create account
Author Adane
Purpose To create account of System user
Description Administrator must have privilege to access site and to create
account of users.
Priority High
Pre-condition Administrator Login to the System and have Delivery information
about who want to Create Account
Post-condition The user account has been created.
Actor(s) System admin
Extends Logout
Flow of Event
Basic flow of event Actor action System response
1. Click on Create account 2. Create Account form is
button. displayed.
3. Fill the required 5. The System checks the
information. validation entered information by
Administrator.
4. Presses Create Account
button. 6. The System Create user
Account successfully. Message
will be displayed.
7. Use Case ends.
Alternative flow of event A6.The System informs to the expert invalid user format is used,
please try again message will be displayed.
Exceptional flow of event E6. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.
Includes Login
TABLE 7: UPDATE ACCOUNT USE CASE DOCUMENTATION

Use case ID UC03

Use case Name Update account

Author Adane

Purpose To edit the information of created account of System user

Description Describe how to Update User Profile in the System

Priority High

Pre-condition They must be have an Account previously

Post-condition Updated the previously account correctly

Actor(s) System admin

Extends Logout

Flow of Event

Basic flow of event Actor action System response

1. Click Update user Account 2.Update User Account form is

button. display

3.Fill the required information 5.The System Check the

validation enter Information by
4. Press Update button.
users
7. Use Case ends.
6. Successful Update user
Account message display.

Alternative flow of event A6. The fill Information are incorrect Please enter correct format
message is displayed.

Exceptional flow of event E6. “Error! Can’t open the database, please contact the System
 Admin” Message is displayed.

Includes Login

TABLE 8: SEND SERVICE REQUEST USE CASE DOCUMENTATION

Use case ID UC04

Use case Name Send Service Request

Author Behaylu

Purpose User sends information of failed item to the team leader.

Description Sends service request with full information of failed item

Priority High

Pre-condition Administrator must have full information about the user

account

Post-condition After click send button the request is sent to team leader.

Actor(s) End user

Extends Logout

Flow of Event

Basic flow of event Actor action System response

1. Open end user page 3. Service request form display

2.Click service request 5. service request successfully

sent message display
4. Fill service request
information

6. Use-case ends.
Alternative flow of event A5. Filled information are incorrect please try again message is
display

Exceptional flow of event E5. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.

Includes Login

TABLE 9: VEIW REQUEST USE CASE DOCUMENTATION

Use case ID UC05

Use case Name View Requests

Author Adane

Purpose To see the request

Description The team leader has seen the request then assign technician.

Priority High

Pre-condition First requests are sent from end users

Post-condition Team leader accept or reject the request.

Actor(s) Team leader, end user

Extends Logout

Flow of Event

Basic flow of event Actor action System response

1.Open team leader page 3.request is display from database

2.Click view request button 4.view request display

5. Use-case ends.
Alternative flow of event A4.there is no request please try again message is display.

Exceptional flow of event E4. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.

Includes Login

TABLE 10: GIVE FEEDBACK USE CASE DOCUMENTATION

Use case ID UC06

Use case Name Give Feedback

Author Adane

Purpose To send feedback

Description The end user to give comment, suggestion about services to the
team leader

Priority Medium

Pre-condition The end user should have account and take some service from the
office.

Post-condition The feedback is stored in database of feedback table and seen by

team leader

Actor(s) End user

Extends Logout

Flow of Event

Basic flow of event Actor action System response

1. Click Give Feedback 2. Give Feedback form display

Button 3. Fill the required 5.Successful Give Feedback
information message display.
 4. Press Give Button

6. Use Case ends.

Alternative flow of event A5. The fill information are incorrect please try again message is
display

Exceptional flow of event E5. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.

Includes Login

TABLE 11: VIEW FEEDBACK USE CASE DOCUMENTATION

Use case ID UC07

Use case Name View Feedback

Author Adane

Purpose To see the feedbacks

Description The team leader see the feedbacks and try to fix the errors

Priority Medium

Pre-condition Team leader should be log in first.

Post-condition The feedback is viewed and team leader try to re correct the errors
based on the comment.

Actor(s) Team leader

Extends Logout

Flow of Event

Basic flow of event Actor action System response

1.Open manager page 2.Click 3.feedback table is display from

view feedback button database
 5. Use-case ends. 4.feedbacks viewed

Alternative flow of event A4. There is no more feedbacks stored in DB

Exceptional flow of event E4. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.

Includes Login

TABLE 12 : DELETE REQUEST USE CASE DOCUMENTATION

Use case ID UC08

Use case Name Delete Requests

Author Adane

Purpose To delete the request

Description Delete the accomplished or redundant request.

Priority Low

Pre-condition User should identify which request is unnecessary.

Post-condition The requests has been deleted from DB

Actor(s) Team leader

Extends Logout

Flow of Event

Basic flow of event Actor action System response

1.Open manager page 2.manager page display

3.Click delete request 4. delete request message display

 5. Use-case ends..

Alternative flow of event A4.you cannot delete this request please try again later.

Exceptional flow of event E4. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.

Includes Login

TABLE 13: ADD TECHNICIAN USE CASE DOCUMENTATION

Use case ID UC09

Use case Name Add Technicians

Author Adane

Purpose To add Maintenance technicians

Description To add new technician based on the need of the office.

Priority High

Pre-condition System admin should sent message to team leader about the new
technician.

Post-condition The technician is added

Actor(s) Team leader

Extends Logout

Flow of Event

Basic flow of event Actor action System response

1. login to team leader page 2. Add technician form is display

and click add technician
5. The technicians add
button
successfully message is displayed.
 3. Fill information of
technicians

4. Press submit button

6. Use-case ends.

Alternative flow of event A5. Information of technicians incorrect then can’t add please try
again message is display.

Exceptional flow of event E5. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.

Includes Login

TABLE 14: ASSIGN TECHNICIANS USE CASE DOCUMENTATION

Use case ID UC10

Use case Name Assign Technicians

Author Adane

Purpose To assign Maintenance technicians for service request.

Description Team leader assigns technician for requests received from end
user.

Priority High

Pre-condition Team leader checks status of technician to assign.

Post-condition Assigned technician maintain malfunctioned Material.

Actor(s) Team leader

Extends Check Status

 Flow of Event

Basic flow of event Actor action System response

1. Open team leader page 2. Team leader page display

3.Click assign technician 5.Assign technician form display

button
7. technicians assigned message
4. The Manager Checks display
status whether the technician
is assigned before or not.

6.fill on assign form and click

assign button

8. Use-case ends.

Alternative flow of event A7. the technicians information incorrect please try again message
is display

Exceptional flow of event E7. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.

Includes Login

TABLE 15: APPROVE REQUEST USE CASE DOCUMENTATION

Use case ID UC11

Use case Name Approve request

Author Adane

Purpose To approve request of end users.

Description Team leader approve end user requests to assign technicians.

Priority High

Pre-condition End users send request

Post-condition Assign technicians

Actor(s) Team leader

Extends Check Status

Flow of Event

Basic flow of event Actor action System response

1.Click approve button 2. Approve page displayed

3. Approve submit. 4. Approve message displayed

5. Use-case ends.

Alternative flow of event A4. The request cannot approved please try again message is
display

Exceptional flow of event E4. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.

Includes Login

TABLE 16: GENERATE REPORT USE CASE DOCUMENTATION

Use case ID UC12

Use case Name Generate report

Author Bosena

Purpose To identify Material is maintained when and who maintain it.

Description Technicians generate report about maintained Material with the

time when it maintained.
Priority Medium

Pre-condition Team leader should perform assigned request.

Post-condition Report will be viewed by team leader that is generated by

technician

Actor(s) Technicians

Extends Check Status

Flow of Event

Basic flow of event Actor action System response

1. Logged to Technicians 2.Login form display

page
4. Generate report form displayed.
3. Press generate report button
7. Check the validation of the
5.fill the required forms System

6. press submit button 8. Generate report successfully.

9. use case ends

Alternative flow of event A8. The reports can not completely filled in the form please try
again.

Exceptional flow of event E8. “Error! Can’t open the database, please contact the System
Admin” Message is displayed

Includes Login

TABLE 2: VIEW REPORT USE CASE DOCUMENTATION

Use case ID UC13
Use case Name View report

Author Bosena

Purpose To identify the maintained item.

Description Team leader views report that have information about maintained
an item.

Priority Medium

Pre-condition Team leader must have their own privilege to view report about
maintained item.

Post-condition Report will be viewed by team leader that send from technician

Actor(s) Team leader

Extends Check Status

Flow of Event

Basic flow of event Actor action System response

1. Open Manager page.

3. Click on report link. 2.displayed Manager page

4. Click on view report.

5. If there is report that send 6. Display reports

from technician.

7. Use-case ends

Alternative flow of event A6.If there is no report that send from technician please try again
later message is display.

Exceptional flow of event E6. “Error! Can’t open the database, please contact the System
Admin” Message is displayed.
Includes Login
TABLE 18: CHANGE PASSWORD USE CASE DOCUMENTATION

Use case ID UC14

Use case Name Change password

Author Mariyan

Purpose To change the old password.

Description Changing the passwords of our account to make secure the account

Priority Medium

Pre-condition The user should have an account first.

Post-condition The old password is replaced by new password.

Actor(s) Technicians, team leader, System admin, end user

Extends Logout

Flow of Event

Basic flow of event Actor action System response

1.The user login first 2.main page is display

2. Click change password 3. Change password form

button. displayed.

4. User enters the old 6. The System process and check

password and new password old password is correct or not.
with its confirmation.
7. The password is successfully
5. User clicks save change changed message is displayed.
button.

8. use case ends

Alternative flow of event A7. The error was occurred message may display and change
 password form is displayed.

Exceptional flow of event E7. “Error! Can’t open the database, please contact the System
Admin” Message is displayed

Includes Login

TABLE 19: LOGOUT USE CASE DOCUMENTATION.

Use case ID UC15

Use case Name Logout
Author Adane
Purpose To exit from operation mode of the System
Description Describes exiting from the System the necessary task is performed
or finished
Priority High
Pre-condition First the user should be login and perform his/her task.
Post-condition The System goes to home page.
Actor(s) End users, System admin, team leader, technicians.
Extends
Flow of Event
Basic flow of event Actor action System response
1.Task performing is finished 3. The System process and
display home page.
2. The user click logout
button.
4. Use case ends

Alternative flow of event A3. System back user to login page and return to error message
A4. Use case ends.
Exceptional flow of event E3. “Error! Can’t open the database, please contact the System
 Admin” Message is displayed.
Includes Login

3.2 Key Abstraction with CRC Analysis

A collection of CRC cards that model all or part of a system. A CRC card is a standard index
card that has been divided into three sections, one indicating the name of the class the card
represents, one listing the responsibilities of the class, and the third listing the names of the other
classes that this one collaborates with to fulfill its responsibilities.
General layout of CRC card seems like the following figure:-
Class

Responsibilities Collaborator

Figure 5 CRC card layouts

Create account<<UI>>
User name Administrator

Password End user

User type

Fill()

Create()

Figure 6 CRC card for create account use case

Login<<UI>>
User name Administrator

Password Team Leader

Fill() Technician

End user

Figure 7 CRC card for login use case

User registration<<UI>>
Fname

Lname Staff members

User name

Gender

Age

phone no

Email

User type

Position

Employee_id

register()

fill()

Figure 8 CRC card for user registration use case

3.3 Sequence diagram

Sequence diagrams describe interactions among classes in terms of an exchange of messages
over time. They're also called event diagrams. A sequence diagram is a good way to visualize
and validate various runtime scenarios. These can help to predict how a System will behave and
to discover responsibilities a class may need to have in the process of modeling a new System
[8]. UML sequence diagrams model the flow of logic within our System in a visual manner,
enabling you both to document and validate your logic and are commonly used for both analysis
and design purposes. Sequence diagrams are the most popular UML artifact for dynamic
modeling, which focuses on identifying the behavior within your System.

Figure 9: Sequence diagram for login

Figure 10: Sequence diagram for logout

Figure 11: Sequence Diagram for Create account

Figure 12: Sequence diagram for Send Request

Figure 13: Sequence Diagram for Update account

Figure 14: Sequence Diagram for Change password

Figure 15: Sequence Diagram for Approve Request

Figure 16: Sequence Diagram for Delete Request

Figure 17: Sequence Diagram for Assign Technician

Figure 18: Sequence diagram for View Request

Figure 19: Sequence Diagram for Send Feedback

Figure 20: Sequence Diagram for View Feedback

Figure 21: Sequence Diagram for Search Request

Figure 23: Sequence Diagram for Generate Report

Figure 24: Sequence Diagram for View Report

3.4 Activity diagram (AD)
Activity diagram are used to document the logic of a single operation/method, a single use case,
or flow of logic of business operation. In many ways activity diagram are the object oriented
equivalent of flow charts and data flow diagrams (DFD) from structured development to
represent the flow from one activity to another activity.

Is one of the components of UML and highlights the activities performed in the system activity.
The processing with in an activity goes to completion and then an automatic transition to the next
activity occurs an arrow represents the transition from one activity to the next. The starting point
of an activity diagram is represented by a filled-in circle and an end point.

A B

admin open create account form

user click login

fill form

enter user name,password

error message invalid

invalid valid
display error message

valid

account successfully created

display approprate page

Figure 25 AD for login and create account

 A B
system admin login to system
open home page and user
registration link

click register new

Technician/TL link
system display form

fill form
fill form

error message invalid

error message invalid

valid
valid

registered
registered successfully successfully

Figure 26 AD for End user registration and Technician/TL registration

3.5 Class diagram
UML class diagrams show the classes of the System, their interrelationships (including
inheritance, aggregation, and association) and the operations and attributes of the classes. Class
diagrams are used for a wide variety of purposes, including both conceptual/domain modeling
and detailed design modeling. A class model is comprised of one or more class diagrams and the
supporting specifications that describe model elements including classes, relationships between
classes, and interfaces. UML class diagrams show the classes of the System, their inter-
relationships, and the operations and attributes of the classes.
Figure 27: MRMS Class Diagram

CHAPTER FOUR
4 System Design
Systems design is the process of defining the architecture, components, modules, interfaces, and
data for a System to satisfy specified requirements. Design of software involves conceiving,
planning out and specifying the externally observable characteristics of the software product. We
have data design, architectural design and user interface design in the design process. These are
explained in the following section. The goal of design process is to provide a blue print for
implementation, testing and Maintenance activities.

System design is one of the activities that are required to build and verify software. The
designer’s goal is to produce a model or representation of an entity that will later be built. Design
provides us with representations of software that can assess for quality. Design is the only way
that we can accurately translate customer’s view into finished software product or System.

The main purpose of System design is to provide architecture design, design goals of the System,
detailed class design and database design for the System. It is the process of defining and
developing Systems to satisfy specified requirements of the user.

Design converts functional models from analysis into models that represent the solution. This
project is designed in a manner that solves the problems of the organization by minimizing the
work load of the existing System. It provides more efficient, reliable and time saving System.

4.1 Design goal

The design part is very important so as to make the implementation very easy. The different
types of the System modeling techniques that are used for the implementation of the System such
as deployment and component modeling are show in detail. Not only the System modeling
techniques but also some System design techniques such as System decomposition design are
cover in detail in this phase. The non-functional requirement is the description of the feature
characters and attributes of the System. Some of the design goals are:

 Performance (Response time) - In terms of performance, the existing/manual System is

not as satisfactory because it is slow/time consuming, energy consuming.
 Security - The System should be secured that unauthorized user cannot access the data
that does not concern with them.
 Reliability - The reliability of the proposed System will be better due to proper storage of
information when users access the System.
  Fault Tolerance -The System should be able to give response (error message) when the
user enters incorrect input. This recommends the user to enter correct input.
 User friendly Interface: Users can easily input and retrieve their required data.
o This means that the System must accommodate a clearly understandable user
interface.
 Backup and Recovery: We have used backup mechanisms such as removable flash
disks, CD and hard disks. Because the data might lose due to computer viruses or power
fluctuation and recovery when user name and password of user is forgot.
 Availability: shared resources that cooperate to guarantee essential services. The System
must high availability.
 Maintainability: A measure of how easily bug fixes or functional modifications can be
accomplished. High maintainability can be the product of modularity and extensibility.
 Extensibility: Deals about the new capabilities can be added to the System without major
changes to the underlying architecture.

4.2 System decomposition and interrelation between them

Sub System decomposition help reduce the complexity of the System. The sub Systems can be
considered as packages holding related classes/objects. Sub System diagram shows the service it
provides or it accepts from other sub Systems, and the coupling and the coherence between them.
Figure 1: Sub System decomposition diagram

4.3 System architecture

Software architecture represents the System software structure of the System. In this project, the
three tire architecture style is used. As the name of the architecture implies, it organizes sub
Systems into three layers. It consists of the front end (interface layer), a middle layer (connector,
application logic layer) and backend of the System layers (storage layer, database layer). The
interface layer includes all boundary objects that deals with users, including windows, form, web
page, and so on. The application logic layer includes all control and entity objects, realizing the
processing, rule checking, and notification required by the application. The storage layer realizes
the storage, retrieval, and query of persistent objects. The data layer or the database is
responsible for storing all information needed for the System to function correctly.
Figure 2: System architecture

4.4 Deployment diagram

Deployment diagram is a structure diagram which shows architecture of the System as
deployment (distribution) of software artifacts to deployment targets.

A deployment diagram is used to depict (show) the relationship among run-time components and
hardware nodes. A web server, for example, is a component that provides services to Web
browsers. It shows the physical architectures of the new System and how hardware is connected.
When it comes time to think about deploying the System, deployment diagrams are crucial
because they show the processors on the System and the connections between them. A
component is a physical unit of implementation with well-defined interfaces that is intended to
be used as a replaceable part of a System.

This section explains the hardware of the System, the software that is installed in the hardware
and also the middleware that is used to connect the different machines to one and other. The
architecture used for the System is a three-tier Client/Server Architecture. Three tires are a
client-server architecture in which the functional process logic, data access, computer data
storage and user interface are developed and maintained as independent modules on a separate
platform. The System used the three tire architecture because this architecture managing data is
independent of the physical storage, migration to new graphical environments is faster, it is
possible to make changes on the presentation level without affecting the other two (business or
data access layer) and as each tier is independent it is possible to use different sets of developers
and etc.

The purpose of deployment diagrams can be described as Diagram

 Visualize hardware topology of a System.

 Describe the hardware components used to deploy software components.
 Describe run time processing nodes.

Figure 3: Deployment Diagram

4.5 Persistence data Management

Persistent data Management describes the persistent data stored by the System and the data
Management infrastructure required for it. This section typically includes the description of data
schemes, the selection of a database, and the description of the encapsulation to the database.
The System will use the MYSQL database to store persistent data. In addition to the various
benefits of using a modern relational database Management System.

To show the proposed System’s database design, we will use table to indicate what the database
looks like and define appropriate field name, data types and length of the input, primary key, and
foreign key. The database design of the proposed System depicted in the following tables and in
figure 21.

TABLE 20: USER TABLE

TABLE 21: REQUEST TABLE

TABLE 22: MESSAGE TABLE

TABLE 23: FEEDBACK TABLE

TABLE 24: REPORT TABLE

Figure 4: Diagram for persistence data Management

4.6 Access control and security

Access control and security is very important for our System. Good security requires physical
access control, reliable personal, trust worthily. Installation and configuration procedure, secure
communications and control of data base operation. Such as selecting, viewing, updating or
deleting data base records. All of our System is designed to meet customer needs to protect your
customer from unwelcome intruders. Restrict unauthorized access to the places and during the
time you specify all information and resources are protecting from unauthorized people with
respect to confidentiality and integrity. This System is locked to prevent people from accessing
your private document and resources.

Defines which functionalities of the System is allowed to be accessed by a specific actors or user
of the proposed System.
TABLE 25: ACCESS CONTROL

4.7 User interface

4.7.1 User Interface Prototype
It represents the general ideas behind the UI, but not the exact details. Based on this fact these
sections display the overall UI of the project as predicted by developers. The user interface
prototype is depicted below in figure 22.
Figure 5: user interface prototype
References
[1] Kite, Software testing in the real world: Improving the process. Reading, MA: Addison Wesley, 1995.
[2] L.B., Cost Estimation for Software Development, Wokingham: Addison-Wesley, 198
[3] R. Martin, the Process Object Oriented Analysis and Design, Addison Wesley, 19987. .
[4] S. a. M. Shaler, Object Oriented Systems Analysis: Modeling the World in Data, Engle wood Cliffs:
Yourdon Press, 1988.
[5] C. Jacobsen. I, Object Oriented Software Engineering, Wokingham: Addison-Wesley, 1993.
[6] “System modeling”, https://gyires.inf.unideb.hu/GyBITT/07/ch03.html.
[7] “UML use case diagram”, https://www.uml-diagrams.org/use-case-diagrams.html.

[8] “Sequence diagram”, https://www.smartdraw.com/sequence-diagram.

[9]. Cato, William; Mobley, Keith (2002). Computer-managed Maintenance Systems: A Step-by-
step Guide to Effective Management of Maintenance, Labor, and Inventory. Butterworth-
Heinemann. p. 33. ISBN 0-7506-7473-3.
[10]. Bagadia, Kishan (2010-07-19). Computerized Maintenance Management Systems Made
Easy: How to Evaluate, Select, and Manage CMMS. McGraw Hill Professional. 
[11]  Wireman, Terry (1994). Computerized Maintenance Management Systems. Industrial Press
Inc. p. 7. ISBN 9780831130541
[12].Linda Dawson & Paul Swatman, (1998). The Use of Object-Oriented Models In
Requirements Engineering: A Field Study
[13].S Jeffery, D.Bently (2001) Object OrientedSystem Analysis and Design Method (5thedition).
[14].Rumbaugh, J., Jacobson, I., &Booch, G. (2003). The Unified Modeling Language Reference
Manual: the definitive reference to the UML from the original designers, Pearson Education Inc.,
Singapore.

[15].Scott W. Ambler’s book, The Object Primer 2nd Edition