Project (2)

JIMMA UNIVERSITY

INSTITUTE OF TECHNOLOGY

COMPUTING DEPARTMENT

IT PROGRAM

WEB BASED MAINTENANCE REQUEST SERVICE

MANAGEMENT SYSTEM FOR JU

Team members: NAME ID.NO

1 Rehana kasim 01936/032 Semira Mohammad 01949/033 Seblewengele Dessie 01945/03

Advisors: Mr. Seid

And Mr.Yemam

Jan 31 2014

JIMMA UNIVERSITY

INSTITUTE OF TECHNOLOGY

COMPUTING DEPARTMENT

IT PROGRAM

Approved by 1. 2.

Content Table

AcknowledgementFirst of all we would like to thanks ALLAH (SWA) for helping us to overcame this project .then

our advisor Mr. Seid and co advisor Mr. Yemam .special thankful for Jimma University maintenance department staff how played a great role on our analysis phase by

giving us the information we want and for our department supplying project writing guidelines

and noticing the final time of project which accelerate us to accomplish our task at a time.

Finally we would also like to thank our friends who helped us a lot to finish this project.

Abstract

This project document all about online maintenance request management system for Jimma

University. It has three chapters: proposal, analysis and design. The proposal part deals with the

background, statement of the problem, scope and more importantly with a feasibility of the

project in terms of economic, technical and time feasibility. It also includes project time schedule

and organization of the project.

The second chapter elaborates analysis of the existing and the new system in detail. Analysis of

the existing system contains the description of the existing system and functional of the existing

system. And the new system deals with deep discussions of the new proposed system using a

UML diagrams. A detailed description of system functionalities and use case documentation are

also part of this new proposed system.

The third and the last part of this documentation is the design. The web based solutions to the

problems of the system which is online maintenance request management system are included in

this part. It starts with purpose and goals of the design. Next the proposed architecture of the

solution including subsystem decomposition, class diagram, component diagram, collaboration

diagram, deployment diagram and ER diagram followed with the access control and security are

included in this part.

7

CHAPTER ONE

1.1 BackgroundJimma University is a public higher educational institution established in December 1999 by the

amalgamation of Jimma College of Agriculture (founded in 1952), and Jimma Institute of Health

Sciences (established in 1983).The two campuses are located in Jimma city 335 km southwest of

Addis Ababa with an area of 167 hectares and Building maintenance office is also coexisted

with the establishment of Jimma university. Today computer and other electronic device

increasingly communicate and interact directly with other devices over a variety of network such

as internet. The internet provides individuals and informal organizations the ability to

communicate inexpensively.

Hence, developing the system using IT technology has a great effect for organizations and

offices; which in our case the JU Building Maintenance service office request process is

currently, their system is manual; in which the user fill forms, then, the client manager assigns

technician for the user subsequent to technician cease his job detail information documented

manually. So, if the JU Building Maintenance office is able to use IT technology they can benefit

in more than a few means they carry out.

A vision of maintenance service for JU is sustaining a good working environment which exists

and correcting some hindrances happening during the process of the office

Mission of maintenance service for JU is providing fast and efficient services for customers and

to satisfy them. And Maintenance service has Missions of ensuring that there will not be any

delay in academics plane due to any damage on academics supporting materials

1.2 Statement of the problem

Currently most of the transactions in JU Building maintenance request service are manual; hence

if they are automated they will gracefully increase performance and efficiency of the existing

system. These transactions includes:-

Maintenance request is not handled easily.

When there is a problem or any failure on the buildings the requests which are sent to the

maintenance department is manual.

The user’s maintenance request forms are stored manually.

The technicians are assigned manually.

The users must go to the office to give feedback.

The report is done manually.

1.3 Objective 1.3.1 General Objective

The general objective of this project is to develop web based maintenance request service

management system for JU.

1.3.2 Specific objective

To achieve the above mentioned general objective, the system will address the following specific

objective. The developed system will be able:

To manage maintenance request.

Manage user registration

Manage account

To allocate technician online.

Give feedback online.

To generate a report.

1.1.4 Scope of the project

The new Jimma University maintenance request service management system meets the following

system and information requirements.

Accepts on-line request from clients.

Create account to the users.

Manage maintenance request which is given by the maintenance department or

enterprise.

Give a response for user’s request.

Allocate technician online.

The user and technician will give feedback to the administrator.

The system will generate detail report.

1.5 Methodology

When we illustrate the current system we use different techniques to collect information.

Observation: we see the current system work flow problems that customer face,

requirements needed by users, necessity of online information management system. Interview: By asking question from concerned bodies we get information about the

current system.

1.5.1. Tools used for system design

System design –is the transformation of analysis mode in to design model system.

Class Diagram- it shows a set of class and their relationship.

Use case diagram- it shows what the system functions are performed for which actor.

Sequence Diagram- it shows how processes operate with one and in what order system.

Activity Diagram- it shows the process of the project from starting to the end.

1.5.2. Development tool

Table 1.5.2 Development tool

1.6 Feasibility of the project 1.6.1 Economic feasibility

Activities Tools/Programs

Client side coding HTML

Client side scripting JAVA script

Plat form MS-Windows

Database server/back end Mysql,Xamp

Webserver Apache

Server-side scripting PHP

Editors Macromedia Dream weaver, Edraw

Documentation MS-word

The purpose of assessing 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. This system minimizes the cost of paper and reduces cost of hiring

unprofessional employees in the organization. There is no need to buy new machine used for this

system or hiring of new employees.

1.6.2 Technical Feasibility

The purpose of technical feasibility is to gain an understanding of the organization ability to

construct proposed system. The system graphical user interface is user friendly to the employees

and customer of the organization and in JU internet access is 24 hours available and the

employees which work in JU are educated .finally the system can be easily maintained base on

this our system is technically feasible.

1.6.3 Time Feasibility

This feasibility concerned with analysis defining the duration of the project for its initiation

states up to the final implementation of the system. Hence, we try to analyze and define the time

line so as to accomplish within the desired deadline.

1.1.7 Significance of the project

Earlier Jimma University building maintenance service is working with manual which is

consuming much time. The importance of this project is to change the manual system to

computerized or automated system. This computerized service will

Reduce work burden of employee. Reduce resources wastage. Enables to perform different activities within a short period of time. Reduce the number of days taken to give a service. Supplies timely information for user.

1.8 Limitation This website gives service for only staff members. This website is only for maintaining old buildings rather than constructing a new one. Time limited for the completion of the project is one factor for developing a complete

system. Budget constraints can be major limitation, in case required materials are not purchased

on time. If scope creep is made knowingly it may be a limitation since more time is required to

cover the newly added scope.

1.9 Organization of the projectThe project consists of four chapters. The first chapter includes background, objective,

methodology, among others. After successfully completed proposal part, analysis of the

system is going to be conducted; this includes current system description, problem of the

current system, alternative solution, proposed solution, functional and nonfunctional

requirements and other tasks.The chapter three deals with design using different modeling chapter four we Implement the system based on identified solution. This chapter includes writing code

and testing. Finally the implemented system is checked weather it is

successfully implemented to solve the problem of the organization.

CHAPTER TWO

Analysis2.1 Existing System2.1.1 Existing System Description

In the existing system Jimma University the maintenance department gives service to staffs by

the direct contact to the maintenance department and by using manual request. The technician

assignation is done manually. In the existing system, all the activities are performed in

maintenance coordinator (department head) office; Files are manually stored, moved and

processed from one section to another. Finally the current system is so boring and time taking for

the users and employee.

2.1.2 Major Function of existing system

Users sent maintenance request for the maintenance department head by filling forms

about what they want

After checking this request if it is possible to done by those technician who found under

the maintenance department the request is sent to the technician from the maintenance

department head

But if the service requested by the user is impossible by those technician who are found

under the maintenance department then the request is sent from the maintenance

department head to the enterprises

Then the enterprise manager orders a technician manually.

If the work is not done they will report again by going to the department physically.

2.2 New System2.2.1 New System Description

The development of new web based maintenance service request management system for Jimma

University office benefits all the staffs and users by increasing the efficiency of the system. We

also come with a solution for big problem through making online maintenance request service.

This will reduces the burden for those busy staffs and also facilitates the operation of the system.

Our system registers the user through their id and then they can create their account. The other

thing is it will verify the works which is done by two departments and control over technician

assignation through online. The administrator also sends assignation message for the technician

about the request which is sent from the user as well as for the user about the technician when

he/she will go to the venue of the maintenance request. And it will generate a report.

2.3 Requirement Analyses 2.3.1 Functional Requirements

The new system deals with automating the maintenance request management system for Jimma

University. This web based Maintenance request management system for Jimma University is

desired to do several things for the department. It is described as follow.

In this system we will make the maintenance service request online which is easily

accessible by users. Users should register online to get user account. After users authentication he /she can get the service.

After user fill the form the system verifies the request.

Administrators can assign the technician online. Technicians can see where and when it is assigned. The technician can report the work is completed. Users can send a report for the administrators the work is completed or not. Generate report.

2.3.2 Nonfunctional requirement

The system provides short response time for user action.

The designed system will not have much graphics, so, it can be loaded to a

browser in short time period.

The designed system will use low utilization of system resource in terms of

space and time.

1. Usability

The designed systems user interface graphics will reflects the system.

The user interface will be light weight and easy to use and manage.

The designed user interface will be attractive.

2. Backup and Recovery

Backup will be stored on the intranet server and JU website.

All process can be made available after unplanned down time within 1 day.

3. Security

The system provides user name and password to prevent the system from

unauthorized access. The staff password must be greater than eight characters.

2.4 Business Rule

Business rule is the rules and regulation of the organization that is used to perform the overall

activities of the organization.

BR1.The customer must register online to get an account.

BR2.All users must have their own account to use the system according to their role.

BR3. The two departments work is different.

BR4.The administrator should check whether request is sent to them.

BR5.The technician must check his account daily.

BR6.The administrator should reply for the request as soon as it sent.

BR7.Each member of Jimma university staff information should be recorded on the database.

2.5 System design model

2.5.1 Use case modeling

System use case reflects analysis decisions and arguably even design decisions during analysis.

our main goal is to develop our essential use cases. A system use case model is composed of a

use case diagram and the accompanying documentations describing the use cases actors, and

associations

The identification of use case is;

Issue request Login Online registration Manage account Response Give feedback View Assign technician Generate report

Actor Identification

Customer-is the one who use the system and make a request to get services.

Technician-who is assigned by the administrator to give service to the requests and give feedback

to the administrator that the work is done or not.

Administrator -control the whole system and administer according to the users information and

assign the technician online and give the response to the customer.

System -is the dispatcher which identify request which is sent made by the customer to the two

departments.

2.5.1Use Case Diagram

A Use Case diagram is a graphical representation of the high- level system scope. It includes

A Use Case diagram is a graphical representation of the high-level system scope. It includes use cases, which are pieces of functionality the system will provide, and actors, who are the users of

The system. Looking at a Use Case diagram, you should easily be able to tell what the system will do and who will interact with it.

Fig 2.5.1 Use case diagram

2.5.2 Use case documentation

Table1.Online Register use case documentation

Name: Online Register

ID: UC#1

Actor: Customer

Description: Each customer register in maintenance

department to get the permission to use the

service of the system

Precondition : Customer must be Jimma university staff

member

Post condition: Customer will be register in the system if they

are fulfill registration criteria

Basic course of action: 1: Customer wants to register in the system

2: Customer select registration button

3: The system display registration form

4: Customer fill all the necessary information

5: Customer submit his registration

6: System validates the form

7: Display successfully message

8: Use case end

Alternative course of action(A): If the registration is invalid

A6: System display error message and return to

step 4

A7: Use case end

Table 2.5.2.1 Use case documentation

Table2. Login use case documentation

Name Login

ID UC#2

Actor Customer,administrator,technician

Description All actors click on login button

to the system

Precondition All actors should know user name and

password to enter the system

Post condition The User enters to privileged page

Include

Extend

Basic course of action 1.The user open homepage

2.The user click on login button

3.The system display the login page

4. The user enters the user name and password

5. The system determines the actors user

accounts weather they enter correct user

account or not

6.The user login to the system

7. Use case end

Alternative course of action(A) If user does not enter valid name and password

A3: System display error message or renter the

correct user name or password

A4: The system will return to step 3

A5: Use case end


Table3. Manage Account use case documentation

Name Manage Account

ID UC#3

Actor Administrator

Description The administrator can manage the users

account

Precondition Account created

Post condition User resign from jimma university

Include Login

Extend

Basic course of action 1.The administrator Login

2.the administrator click manage account

3.the system display accounts

4.select the account

5.click on delete

Alternative course of action(A)


Table4.Issue request use case documentation

Name: Issue request

ID: UC#4

Actor: Customer

Description: In this system the customer issue the request

he/she want

Precondition: The user must be authenticated

Post condition: The user issue request and get response

Include use case Login

Extend

Basic course of action: 1.customer want to send request

2.customer must be login

3.the customer click on issue request

4. system display the fill form page

5.customer fill the form

6.customer click on submit button

7.system check the filled form

8. The system determine the request

9. The system save the request to the database

10.the system display “successfully message”

11. use case end

Alternative course of action (A): If the customer fill form is invalid

A5. System display error confirmation and

return to step 3

A6. Use case end


Table5. View use case documentation

Name: View

ID: UC#5

Actor: Administrator,customer,technician

Description: All users should view their messages which are

sent to them.

Precondition: The message should be send to them

Post condition: The message (request) will be viewed.

Include Login

Extend

Basic course of action: 1.The users wants to view

2. All user must be login in his/her account

3. user click on view button

4.the system displays their message

information

5.use case end


Table6. Response use case documentation

Name: Response

ID: UC#6

Actor: Administrator

Description: The admin will give a response to the users

(customers)

Precondition: The user must send the request

Post condition: The administrator will assign a technician send

a response to the requests.

Include Login ,view

Extend

Basic course of action: 1:The user must login

2:user wants to give response

3:select the requester

4: click on response button

5:sends message to the requester about the

assignation

6: System display successfully message

7: use case end

Alternative course of action(A):


Table7. Assign technician use case documentation

Name: Assign technician

ID: Uc#7


Description: The admin should select the assign technician

Precondition: the technician must be registered on the

database

Post condition: The admin assign the technician

Include Login

Extend

Basic course of action: 1. The administrator must login

2.The administrator select assign technician

page

3.The system displays the technician list and

information page

4.The administrator select the concerned

technician

5.The administrator send the assignation

message to the technician

6. The system confirm delivery message.

7. use case end


Table8. Feedback use case documentation

Name: Feedback

ID: UC#8

Actor: Customer ,technician

Description: Customer and technician give feedback to

administrator after the work is properly done

Precondition Customer ensure issue request and technician

must be assigned for the work

Post condition The user give feedback

Include Login

Extend

Basic course of action 1. Wants to give feedback.

2. user first login

3.The user click on feedback button

4. The system displays the feedback form.

5.fill the form

6. click submit button

7.use case end

Alternative course of action(A): If the username and password is invalid

A1.the system display the error message

A2.use case end


Table9. Generate report use case documentation

Name: Generate report

ID: UC#9


Description: Generate report for all user of the system who

wants to view the report.

Precondition: All detail information should be record on the

database.

Post condition: All users able to view the report generate

information.

Include Feedback

Extend

Basic course of action: 1.admin want to generate report

2. The admin must login.

3. The click on generate report.

4. The system displays report type

5.select the report type

6. The system displays the report

7.use case end


2.6 Sequence diagram

2.6.1 Sequence diagram for “Online register”

Fig 2.6.2 Sequence diagram modeling

2.6.2 Sequence diagram for “Login”


2.6.4Sequence diagram for “Issue request”

Fig 2.6.5 sequence diagram modeling

2.6.5 Sequence diagram for “View”

Fig 2.6.5 sequence diagram modeling

2.6.6Sequence diagram for “Response”


2.6.7 Sequence diagram “Assign technician”

Fig2.6.7 Sequence diagram modeling

2.6.8Sequence diagram for “Feedback”


2.6.9 Sequence diagram for “Generate report”


2.7 Activity diagram

An activity diagram illustrates the dynamic natural of a system by modeling the flow of control

from activity. An activity represents an operation on some class in the system that result in a

change in the state of the system. Typically activity diagrams are used to model work flow or

business processes and internal operation.

2.7.1 Activity diagram for “login”

Fig 2.7.1 Activity diagram modeling

2.7.2 Activity diagram for “online registration “


2.7.3 Activity diagram for “Response”


2.7.4 Activity diagram for “issue request


2.7.5 Activity diagram for “view”


2.7.6 Activity diagram for “assign technician “


2.7.7 Activity diagram for “feedback”


2.7.8 Activity diagram for “Generate report”


2.8 Conceptual modeling Class diagram

Class Diagram provides an overview of the target system by describing the objects and classes

inside the system and the relationships between them. It provides a wide variety of usages; from

modeling the domain-specific data structure to detailed design of the target system

Fig 2.8 conceptual diagram

2.9 Prototyping model

The prototyping model is a systems development method(SDM)in which a prototype(an early

approximation of a final system or product)

User interface prototype for Login

Fig 2.9.1 User interface prototyping

User Interface prototype for Registration

Fig 2.9.2 User interface prototyping

User Interface Prototype for Issue Request

Fig2.9.3 User interface prototyping

2.10 State Chart

A state chart diagram shows the behavior of classes in response to external stimuli. This diagram models

the dynamic flow of control from state with in a system.

State chart for issue request

Fig 2.10.1 State chart diagram

State chart for account

Fig 2.10.2 state chart diagram

2.11 Communication Modeling

It is called collaboration or interaction diagram, is an illustration of the relationships and

interactions among software objects in the unified modeling language (UML).Communication

diagram resembles a flowchart that portrays the roles, functionality and behavior of individual

objects as well as the overall operation of the system in real time. The messages between objects

are shown as arrows connecting the relevant rectangles along with labels that define the message

sequencing.

Communication diagram for Login

Fig 2.10.1 Communication diagram

Communication diagram for issue request


Communication diagram for generate report


Chapter Three

System Design3.1 Purpose and goals of design

This project is designed in a manner that solves the problem of the maintenance department by

minimizing the work load that appears on the employees because of the existing manual system.

It provides more efficient, reliable and time saving system. In this project design the team will

try to show:

how the project is designed what are tasks done under the whole project The different modules and their way of functioning are described here.

3.2 Goals of design

Generally, the project will be designed by addressing all of the above criteria of the project

design. It is designed to simplify functions of the manual system and it is capable of doing large

amount of works in short period of time with more accuracy and reliability. Generally this

project design will describe how the project is designed, what tasks done under this project and

different modules and their way of functioning.

The goal of system design according to the proposed project is to manage complexity by

dividing the system into smaller, manageable pieces and to increase the system:-

Efficiency: the system doing something well and thoroughly without waste of money and

time. Flexibility: the system able to change to suite new condition or situation Security: the system should be secured, i.e. Not allow unauthorized users to access the

system. Reliability: the system should be reliable.

3.3 proposed software architectureThe general architecture of the software looks like the following picture. At the top layer the user

interface of the system is set and maintenance request management application login or website

Finally at the back end the request database

Fig 3.3 software architecture

3.3.1 Subsystem decomposition

Any system can be decomposed in to different subsystem based on the functional services. Some

of the subsystems are

Fig 3.3.1 Subsystem decomposition diagram

3.4 Class modeling

Purpose of design-class modeling is to model the static structure of how the software will be

built

Fig 3.4 Class modeling

3.5 Component modeling

A component is a physical unit of implementation with well-defined interfaces .well-designed

components do not depend directly on other components but

Fig 3.5 component diagram

3.6 Deployment Diagram

The deployment diagram shows how a system will be physically deployed in the hardware

environment. Its purpose is to shows where the different components of the system will

physically run and how they will communicate with each other. since the diagram models the

physical runtime. A system’s production staff will make considerable use of this diagram.

Fig 3.6 deployment diagram

3.7 E-R Diagram

An entity relationship diagram is a specialized graphic that illustrate the relationships between

entities in a database. ER diagrams often use symbols to represent three different types of

information. Boxes are commonly used to represent entities. Diamonds are normally used to

represent relationships and ovals are used to represent attributes.

Fig 3.7 Entity relationship diagram

Appendix A: unified modeling language notations

Symbol description

Appendix B: ER-diagram notation

Symbol description

Appendix C: Abbreviation

UC#.............................................Use case

BR#.............................................Business rule

HTTP……………………………Hypertext protocol

MYSQL…………………………Database connection

Reference

Project (2)

Documents

existing system

developed system

new proposed system

vision of maintenance

new system deals

ju building maintenance

background jimma university

jimma city