Industrial Project II Final

BAHIRDAR UNIVERSITY
INSTITUTE OF TECHNOLOGY (IOT)

SCHOOL OF COMPUTER AND ELECTRICAL ENGINEERING
PROJECT ON
AUTOMATION OF BAHIR DAR UNIVERSITY IOT MAINTENANCE

SYSTEM
SUBMITTED To Anergechew (MSc)
BY
No Name ID No.
1 Yibellu Semneh 0503465

2 Yibeltal Ayele 0503466
3 Yonas Yirga 0503471
4 Yeynetesfa Mengistu 0503464
5 Zebura Nursebo 2168
6 Tewobesta Tefese 0503423
7 Serkelem 05033
April 2008
BAHIR DAR, ETHIOPIA
Automation of Bahir dar university IOT maintenance system 2008
TABLE OF CONTENTS
Contents
Error: Reference source not found
LIST OF FIGURE
Figure 1: Time Schedule.......................................................................................................................................................6
Figure 2: Use Case Diagram...............................................................................................................................................12
Figure 3: Login.................................................................................................................................................................... 29
Figure 4 : Assigns technician...............................................................................................................................................30
Figure 5 : Views message....................................................................................................................................................31
Figure 6 : Generate report...................................................................................................................................................32
Figure 7: View report..........................................................................................................................................................33
BDU | School of Computer and Electrical Engineering Department of Computer Engineering program
Figure 8: Search for manage...............................................................................................................................................34
Figure 9: Search for technician............................................................................................................................................35
Figure 10: Update Information............................................................................................................................................36
Figure 11: Approve request.................................................................................................................................................37
Figure 12: Send request service...........................................................................................................................................38
Figure 13: Delete request....................................................................................................................................................39
Figure 14: Check status.......................................................................................................................................................40
Figure 15: Login ………………………………………………………………………………………………………………………….42
Figure 16: Assign technician...............................................................................................................................................43
Figure 17: Logout................................................................................................................................................................44
Figure 18: Generate report.................................................................................................................................................45
Figure 19:View account......................................................................................................................................................46
Figure 20: Cancel request…………………………………………………………………………………………………47
Figure 21: Check status.......................................................................................................................................................48
Figure 22: Delete request....................................................................................................................................................49
Figure 23: Search Information.............................................................................................................................................50
Figure 24: Update Information............................................................................................................................................51
Figure 25: View message....................................................................................................................................................52
Figure 26: View report........................................................................................................................................................53
Figure 27: Create account....................................................................................................................................................54
Figure 28: Deployment Diagram.........................................................................................................................................56
Figure 29: Class Diagram....................................................................................................................................................58
Figure 30: ER Diagram.......................................................................................................................................................70
Figure 31: Schema Diagram................................................................................................................................................77
LIST OF TABLE
Table 1: Individual task.........................................................................................................................................................6
Table 2: Manager Login......................................................................................................................................................15
Table 3 : Technician login...................................................................................................................................................15
Table 4 : Logout.................................................................................................................................................................. 16
Table 5 : Assign technician..................................................................................................................................................17
Table 6 : Update Information..............................................................................................................................................18
Table 7: Search Information................................................................................................................................................19
Table 8 : Generate report.....................................................................................................................................................20
Table 9 : View account........................................................................................................................................................21
Table 10 : Cancel request....................................................................................................................................................22
Table 11 : Views message....................................................................................................................................................22
Table 12: Views report........................................................................................................................................................24
Table 13: Sends service request...........................................................................................................................................24
Table 14 : Delete request.....................................................................................................................................................25
Table 15 : Check technician status......................................................................................................................................26
Table 16: Create account.....................................................................................................................................................27
Table 17 : Change password................................................................................................................................................27
LIST OF USER INTERFACE

UI 1: Main Screen...............................................................................................................................................................59
UI 2: Login page................................................................................................................................................................. 60
UI 3: Sign Up...................................................................................................................................................................... 61
UI 4: Manager Page............................................................................................................................................................62
UI 5: View Page.................................................................................................................................................................. 62
UI 6: Assign Technician......................................................................................................................................................63
UI 7: Applicant Form..........................................................................................................................................................64
UI 8: Technician Page.........................................................................................................................................................65
UI 9: Update........................................................................................................................................................................ 66
UI 10: Delete....................................................................................................................................................................... 67
UI 11: View Report.............................................................................................................................................................68
UI 12: Search...................................................................................................................................................................... 69
UI 13: Generate Report.......................................................................................................................................................69
LIST OF SYMBOLS AND NOTATIONS

 IOT:-Institute of Technology
 UC:-Use case
 REQ:-Requirement
 HTML:-Hypertext Markup Language
 PHP: - Hypertext Preprocessor
 BDU:-Bahir dar University
 UML:-Unified modeling language
 MYSQL:- Multi-user, Structured Query Language

 UI:-User interface
 Ms:-Microsoft
 WAMP:-Windows apache mySQL PHP
ABSTRACT
The system developed in this project, IOT Maintenance System, provides a simple and efficient
way of facilitating maintenance service. Achieving this objective is difficult using a manual
system due to redundant and collecting relevant malfunctioned materials information may be very
time consuming. All these problems will be solved by automating the manual system.
This document contains the introduction, methodology that uses tools like Notepad++, Xampp
and VISIO, data sources like site observation, interview and document analysis, and for design
methodology . For analysis model we use sequence and activity diagram. For system design we
include deployment diagram, architecture diagram, UI design, data structure design, and
algorithm design for the project that is going to be developed. To develop the real system, designs
had been made that covers the system architecture, user interfaces and database designs.
CHAPTER ONE
1.1. Introduction
Our project is concerned on Bahir Dar University institute of technology (IOT) maintenance
systems. Till now, the system is manual. The system should be automated to maximize the
benefits gained from information technology .The intension of this study is, therefore, to make
system simple, effective and efficient using information technology solution.
The new system will give best file management strategy, user friendly to the users and provide
correct and usable information for the users and customers to make timely decision.
1.2. Background
Bahir dar University Institution of Technology was upgraded to Degree Program in 1997. The
Polytechnic Institute was renamed to Bahir Dar University, Engineering Faculty. In year 2010, it
changes its institutional structure, from Bahir Dar University Engineering Faculty to Bahir Dar
University, Institute of Technology (IOT).
Bahir Dar University Institute of Technology maintenance system established by a few number of
peoples in 1963 G.C. At that time, the name of the system is office of machine and later in1990
G.C year, the name is changed to (maintenance case team).The maintenance case team serve all
members of the IOT campus by maintaining devices and other materials.
1.2.1 Mission
The mission of Bahir Dar University is to contribute significantly for social, economic, political,
scientific and technological development of the nation through the provision of high quality
education, active commitment in research activities for the ease of life
1.2.2 Vision
The Vision of Bahir Dar University is to become one of the ten Premier Research Universities in
Africa for the future.
1.3. Purpose of the system

 To be simple the overall maintenance system in the campus by observing the
existing general service to develop the new automated system
 To identify problems and make the system to reduce or remove those problems by
giving services to the customers with interaction to the system WebPages.
 To Solve the problem of manual record keeping system by using computerized
information system with only interaction to the system
 To reduce the time to get service from the maintenance system by only passing
message
1.4. Existing System vs. Proposed System
1.4.1 Existing System

The existing system gives services to its customers manually. The following are the problems in
countered in the existing system
 Files are exposed to loss and damage since the files are stored on a paper.
 Customer must come physically to report problem about maintained problem.
 The System records documents on papers as result it needs more storage place and
resources and it is difficult to manage properly.
 Data redundancy: Paper based documentation does not support integration of data,
as a result similar data may be recorded redundantly. This makes modification very
difficult and leaves inconsistent data here and there.
 Poor coordination with proctor in the context of proving requested information

appropriately.
1. 4.2. Proposed system

The proposed system is used to solve the existing problems and it is expected to include the
following tasks:
 The system should be allowed to search, delete, and update stored data
automatically.
 The system shall allow applicants to register about failed and/or malfunctioned
item information.
 The manager responds for applicants request online.
 Improve quality of service like facility of the system.
 Provide secured system by checking user name and password
 The customer data kept properly because we will use database application.
 Avoid data redundancy by using database management system.
 Prepare different documents and reports on required time automatically.
 User friendly system, that means the customer and system interact in a good
manner.
1.5. Objective of the project
The general and specific objectives are described below.
1.5.1 General objective

The general objective of the project is to build web based application to automate maintenance
system for Bahir dar University Institution of Technology (IOT).
1. 5.2 Specific objective

To achieve the specified general objective, the following specific objectives are undertaken:
 Reviewing the existing system problems
 Determining what to build and understand the problem domain of the system
using low fidelity models consisting of transforming user requirements in to
system requirements.
 Determining how to build the proposed system and show the solution domain of
this system.
 Implementation of the project using programming language according to the

design specification.
 To generate a report, showing the analysis, design, user manual and

implementation documented.
1.6. Scope of the project

There are so many sub systems in Bahir Dar University, from those different systems our project
concerned on the Institute of Technology maintenance system. The project will develop a system
for troubleshooting or maintaining malfunctioned materials, assigning assistance technician for a
task and generating report for the institute.
1.7. Methodology
The purpose of the methodology is to give an experienced investigator enough information to
replicate the study.
For conducting our project we used the following methodologies
1.7.1 Data collection method

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

requirement in information system projects. We have used interview to gather
facts, opinions, and truths of users about the current system and See Appendix 1
 Document analysis: - Using this method the team will try to analyze written
documents in the organization which have importance to the project. This
include the organization mission strategy, sample business forms, reports
procedure manuals, Business rules, and documentation of existing systems, if
any document view. See Appendix 2
1.7.2 Development Tool

 We have use Ms Visio 2003 to design and develop the interfaces of the
system
 We have use PHP for coding and use Xampp server to implementation this
PHP code
Why PHP?
There are several types of web programming language that are used for making a site more
dynamic. But, for this project we are choosing php scripting language to design our database.
Because:
 It’s fast and easy

 It’s cross platform
 It accesses everything
 It’s free
Why MySQL?
There are several reasons to use MySQL.
 It’s quick and powerful
 It’s improving all the time

 It’s free
1.7.3 Analysis and Design Tool

Analysis tool is a graphical language for developing specific, clear and understandable system.
For modeling analysis and design artifact, our teams have use UML (Unified Modeling
Language) tool that supports reconstruction of UML model from an implementation. For
systems development process we will use the iterative incremental model since it combines the
spiral water- fall development model because the iterative model used to review and update the
information when we gather requirements up to the final documents and implementation of the
system.
1.8. Significance of the Project

Bahir dar University maintenance system is working with manual system which is time
consuming and costly. The importance of this project is to solve such kinds of problem within the
maintenance office. Changing manual system into computerized or automated system is much
more important to
 Helps to avoid incorrect placement of record data.
 Reduce the loss of documents & human resource.
 Avoid data redundancy, which means extended data can be retrieved without
affecting other data.
 To support customer application system;
 To facilitate report generation,
 To allow manager to view reports
.9 .Time Schedule
The project time schedule is shown in the following diagram
\ Figure 1: Time Schedule
1.10. Individual Tasks

No. Name Task
1. Yibellu Semeneh Project proposal, requirement, coding and project
manager
2. Yibeltal ayele Project proposal, requirement analysis and design,
coding
3. Yonas yirga Project proposal, coding, requirement analysis and
design
4. Yeynetesfa mengistu Project proposal, coding, requirement analysis and
design
5. Zebura nursebo Project proposal, coding, requirement analysis and
design
6. Tewobesta tefese Project proposal, coding, requirement analysis and
design
7. Serkelem Project proposal, requirement analysis and design,
coding
Table 1: Individual task
CHAPTER TWO: SYSTEM FEATURES
2.1 Existing System Description

The existing system function is described as follows.
2.1.1 To request a service

 The existing system is generally manual as mentioned earlier .If a user wants to
request a service to the maintenance office in order to maintain or replace the material.
The system follows the following procedure to request service from the system:
 The customer goes to manager office
 Manager gives a form to the users to fill all the information regarding to the failed
material.
 After the customer fill the forms ,he/she gives it back to the manager and again the
manager look at the form and assign a technician
 Manager call phone to technician and technician receive and fill the form when he/she
start a maintenance service.
 After technician accomplishing the task, he tells the user to sign in the form.
 Technician returns the form back to the maintenance office manager.
If the required material that is going to be maintained or replaced is not found in the store
management:-
 Check if the budget is found to purchase the material, if not the budget is approved by
deputy manager.
 The purchasing officer assigns the Performa committee and opens the Performa.
 If the purchasing cost is very high from the expected cost it must fail and review again
by the deputy manager to approve again the budget.
 The budget approved by deputy manager then goes to the purchasing office and the
material will be bought and given to the store management.
 The technician takes the material from store management and uses it to maintain failed
item.
2.1.2 Updating information of technician

Updating the information of technician when update is needed or technician change profession by
any purpose.
2.1.3 Searching the file

To search the request that comes from the user, the manager uses the date when that request is
come to the office and search the form by date for purpose of selecting the form from catalog
when the user was requested but does not answered . The manager uses date which technician
submits report, to search the report that comes from technician for view.
2.1.4 Problems encountered by the user

The user who mainly live in the area of student’s dormitory lack responsibility for the material
and also the block proctors take over money from students for their own use when materials
damage in the dormitory such as mirror, key and other metallic and wood materials after this the
proctor announce to the maintenance office in order to solve the problem through the technician
assigned by the manager but the manager does not recognize whether the proctor receive a money
from a student or not such kind of problems are occurred in the existing system.
2.1.5 Limitation of the maintenance office

The maintenance system in the area of instructor block or living room is give the maintenance
service only once in the year. The service is given once in a year for failed and/or malfunctioned
materials reside in instructors’ living room.
2.2 Proposed System Description
The new system will include solution of existing system problems by giving services better than
the older one as much as possible. We proposed the following list of tasks included in our system.
The system follows the following procedure to request service:
 The customer of the system opens the website and click on applicant’s link to open
request form.
 The customer fills the form that contain field that fill with kind of the failed item and
profile of applicant.
 The customer clicks on send button to get the service.
 Message is send to manager.
 The customer who is the member of the campus, open the website and select the
applicant link.
 The manager opens the website and login in to the system then view the failed items
information coming from the applicant. After observing the problem, he/she assign
the technician that is related to the problem.
 Technician also login into the website and view failed item information that is send
from the manager. After viewing the problem the technician maintain the problem
encountered in the area by contacting physically with the problem area. After
accomplished his task, he/she generates and sends report to the manager.
 Manager selects the report link and view if report is submitted or not. If report is
found, he view report and approves the report and finish the work. If the material that
is going to be replaced or maintained is not found in the store management.
 Manager can cancel user request when the request is not announced by him. But he
accept and approve the request when request is valid or consider his responsibility
 Manager deletes the request after he/she accepts the report. But the deleted request
saves in other places.
2.3 Functional Requirements

These requirements constitute all requirements which are necessary for completing function of the
system.
2.3.1 User Requirements

It is requirements of the organization, manager, technician and the customer of maintenance
system that needs the system to perform. To uniquely identify our user requirements we used
“REQ #” REQ – requirement and # unique number to identify.
 REQ 1. Login: Manager, administrator, customer and technician log in to website

by using their own username and password to start the task.
 REQ 2. Logout: Manager, administrator, customer and Technician log out from
website to close system.
 REQ 3. Assigns technician: Manager assigns technician to maintain failed item.
 REQ 4. Update technician information: manager and customer updates status
their information by ID.
 REQ 5. Search: The administrator search user account by status of a person.
 REQ 6. Generate report: Technician generates report to indicate completed his
given task.
 REQ 7. View account: Administrator views each customer to solve a person
forget username and password to tell.
 REQ 8. Cancel request: Manager accept or reject request of user based on type of
question.
 REQ 9.View message: Technician view message that accept from manager to
maintained failed item.
 REQ 10.View report: Manager Views report that generated and send by
technician.
 REQ 11. Send service request: User sends information of failed item to the
manager to accesses service.
 REQ 12.Delete request: manager delete request of user after solved the problem
but save this delete request in other table and administrator delete user account
when a customer leave a campus.
 REQ 13.Send message: User sends message to manager to indicate answered
his/her request.
 REQ14.Check technician’s status: Manager checks status of technician for
assigning technician.
 REQ15.Create account: Administrator creates an account for manager, customer

and technician.
 REQ16.Change password: System administrator, technician, manager and
customers are change password for it self.
2.3.2 System Requirements

As we have proposed to develop a new system in BDU IOT, maintenance system, it is time to
come to the requirement model of the system.
Requirement model is a collection of requirement artifacts including; essential use case model,
essential use case model description which in their entirety help us to capture the essential aspect
of the maintenance system.
2.3.2.1 Use case Diagram

Use case Diagram depicts a collection of use cases, actors, their associations, a system boundary
box (optional), and packages (optional). A use case describes a sequence of actions that provide a
measurable value to an actor and is drawn as a horizontal ellipse. An actor is a person,
organization, or external system that plays a role in one or more interactions with your system
(actors are drawn as stick figures). Relationships between actors and classes are indicated in use
case diagrams, a relationship exists whenever an actor is involved with an interaction described
by a use case.Error: Reference source not found
Figure 2: Use Case Diagram
2.3.2.2 Actors of the system

 Customer: A person who is send service request to the manager to access
service. Customer of the system are:
Student
Proctor
Instructor and
Staff members.
 Technician: The person who is responsible for maintaining the requested

problems
 Manager: A person who manages the overall system
 System Administrator: A person who creates and changes an account.
2.3.2.3 Use case list

 UC 1. Login: Manager, system administrator and technician log in to website by
using their own username and password to start the execution.
 UC 2. Logout: Manager, system administrator, customer and technician log out
from homepage.
 UC 3. Assigns technician: Manager can assign technician to maintain failed item.
 UC 4. Update information: manager and customer updates status of information
by ID.
 UC 5. Search: The Administrator search account by a status of a person
 UC 6. Generate report: Technician generates report to indicate completed his
given task.
 UC 7: View account: Administrator view all username and password to tell when
each user forger their account.
 UC 8. Cancel request: Manager accept or reject request of user based on type of
request.
 UC 9.View message: Technician view message that accept from manager to
maintained failed item.
 UC 10.View report: Manager Views report that generate by technician.
 UC 11. Sends service request: User sends information of failed item to the
manager
 UC 12.Delete request: manager delete request of user after solved the problem
but save this delete request in other table and administrator delete user account
when user leave the campus.
 UC 13.Send message: User sends message to manager to indicate answered

his/her request.
 UC14.Check technician’s status: Manager checks status of technician for
assigning technician.
 UC15.Create account: Administrator creates an account for manager and
technician.
 UC16.Change password: System administrator change password and user
account of manager and technician when both are leave the organization
2.3.2.4 Use case description
Use case No: UC-1

Use case Login
Name:
Actor (s): Manager, Administrator
Description: Manager Login to system in order to have privileges for
performing different tasks.
Typical course Actor Action System Response

of events 1.Open web site 3.If username and
2.Click login button password is valid
4.Manager enter 5. Manager action
username and password performed page display.
and then click on login,
Alternative 3.1If the user name and password is not valid.

course: 3.2System back user to login page and return to error
message
3.3If manager try more that 3 time, system close the page.
Preconditions Manager has privilege to access system
Post condition The system is opened.
Table 2: Manager Login
Use case No: UC-1

Use case Name: Login
Actor (s): Technician, Customer
Description: Technician must be logged in to perform tasks related to
his/her duty.
Typical course of Actor Action System Response
events 1.Open web site 3.Display login page
2.Click login link 5. If username and
4.The Technician enter password valid.
username and password 6. Technician action
and then click on login performed page display.
Alternative course: 5.1If the user name and password is not valid, back to
login page and return to error message
5.2If technician try more that 3 time, system close the
page.
Preconditions Technician has a username and password
Post condition Logged to the system
Table 3 : Technician login
Use case No: UC-2

Use case Name: Logout
Actor (s): Manager, Administrator, Customer and Technician
Description: Manager and Technician logout from the system when finishes
their task.
events 1. Close all opened file. 3. The system is closed.
2. Manager and
Technician click logout
link.
Alternative course: 3 If the user name and password is not valid.

4 System back user to login page and return to error message
5 If manager try more that 3 time, system close the page.
Preconditions The manager and technician first login and finish the task.
Post condition The system is closed.
Table 4 : Logout
Use case No: UC-3
Use case Name: Assigns Technician
Actor (s): Manager
Description: Manager assign technician to maintain failed item.
events 1.Open website 4. If technician is not assigned,
2. Logged to website the system displays all
3. The Manager Checks status technicians.
whether the technician is 6. If technician is assigned, the
assigned before or not. system displays “technician is
5. If technician not assigned assigned before” message.
before. 9.Successfully assigned
7. Fill on assign form.
8. Click assign button.
Alternative course: 5.1If technician assigned before.

5.2The manager compares the problem to give priority.
Preconditions Manager checks status of technician to assign.

Post condition Assigned technician that related to the problem.
Table 5 : Assign technician
Use case No: UC-4

Use case Name: Updates Information
Actor (s): Manager ,Customer
Description: The system allows customer, manager can updates information of
manager.
events 1. Open website 4. Display search form
2. Logged to website. 6. If technician id is valid,
3. Click update tab display required
5. Search information by information.
TECHID. 9.If modified data is
7.Modify information correct, display successfully
8. Click update button updated
Alternative course: 1 If searched information is not found and back to

search page.
9.2 If modified data is incorrect, back to update page.
Preconditions Logged in to the system.

Post condition Updated information.
Table 6 : Update Information
Table 7: Search Information
Use case No: UC-5
Use case Name: Search
Actor (s): Administrator
Description: System shall allow Administrator to search requires information.
Actor Action System Response
Typical course of 1. Open website 4.Display search page

events 2. Logged to website 7. Display required information.
3. Click search button
5.Select any criteria to search
like status of customer
6.Click search button
Alternative course: 5.1If searched information is not found, back to search page.
Preconditions Logged system.

Post condition Display require information or error message.
Table 8 : Generate report

Use case No: UC-7
Use case Name: View account
Actor (s): No:
Use case Administrator
UC-6
Description:
Use case Name: This use case
Generate describes that administrator view username and password
report
Actor (s): to tell to customer.
Technician
Typical course of Actor
Description: : SystemAction Systemreport
shall allow technician generate Response
which indicate the task
events 1. Open
complete. website. 4. Display user account.
Typical course of Actor 2. Action
Logged to website. System Response
3. Click on view
1. Open website. 4. Display report form.
events
administrator request
2. Logged to website. 6.Display report
button
3. Click report link.
5.View usergenerate
5.Click account and
report
select one of status
button
technician
7.Click send report
Alternative course: 5.1. If there is not account found, back to view search form and
return error message.
Alternative course:
Preconditions Logged into website.
Preconditions
Post condition First the technician
Administrator view finishes
username hisand
task.
password to tell for each user and to
Post condition Report willload
reduce the be generate
of work.
Table 9 : View account

Use case No: UC-8
Use case Name: Cancels request
Actor (s): Technician
Description: Manager cancels request when user request is not appropriate request like
request is not solved by them.
events 1. Open website 4.Display cancel page
2. Logged the website. 6.Display customer request
3. Click on cancel request 9. System return successfully cancel
button. message.
5.Click view button
7.Select unwanted request
8.Click cancel button
Alternative course: 5.1If request is not found, return error message.
Preconditions View request.
Post condition Cancel request from database.
Table 10 : Cancel request

Table 11 : Views message
Use case No: UC-9
Use case Name: Views message
Actor (s): Technician
Description: This use case describes that technician can views message send from
manager to maintain failed item.
events 1. Open website 4. Display view form.
2. Logged to website. 6. Display message send from
3. Click on view link manager.
5.Click on view button
5. If there is message that
send from manager.
UC-10
Alternative 5.1If there is no message, return error message that inform
Use case Name: view report
course: technician.
Actor (s): Manager
Description: This use case describes that manager views report that have
information about maintained an item.
Preconditions UC-1
Typical course Actor Action System Response
of events
Post condition 1. Open
The website.
manager sends message to4.technician
Display view
and areport form. maintain an
technician
2. Logged to website.
item 6. Display report form
3. Click on report
Assumptions: link.
4. Click on view
report.
5.If there is report that
send from technician
Alternative 5.1If there is no report that send from technician, return

course: error message that inform manager and back to
logged page.
Preconditions Manager must have there own privilege to view report about
maintained item.
Post condition Report will be viewed by manager that sends by technician.
Use case No: UC-11

Use case Name: Sends service request
Actor (s): Customer
Description: This use case describes that user can sends request to manager to show failed
item.
events 1. Open website 3. Display request form.
2. Click on applicant link. 6. Display successfully send request
3. Fill the form correctly message.
4. Click Send button
5.If the form is correctly fill
by customer
Alternative course: 5.1If the form is not fulfilling, back to the form and return error message that
inform manager.
Preconditions All require fields of form are correctly fill by the user.
Post condition The manager approve or reject for user asked when he/she sends failed item
Assumptions:
Table 12: Views report
Table 13: Sends service request
Use case No: UC-12
Use case Name: delete request
Actor (s): Manager
Description: This use case describes that a manager delete request of user after the failed
item is maintained but save this delete request in somewhere.
Actor Action System Response
Typical course of 1. Open website. 4. Display search form.

events 2. Logged to website. 7.Display the request
3. Click on delete link. 9. Display successfully delete request
5. Enter id in to search
form
6.If searched id is found
8.Click on delete button
Alternative course: 6.1. If the form is not fulfilling, back to the form and return error
message that inform manager.
Preconditions Login through correct user name and password.

Post condition The manager delete request from user database
Assumptions:
Table 14 : Delete request
Use case No: UC-13

Use case Name: Check technician’s status
Actor (s): Manager
Description: This use case describes that a manager to check status of technician for
assigning.
events 1. Open website 4. Display checks form.
2. Logged to website. 5. Display status of technician.
3. Click on check status
link.
5. Click check button.
Alternative course: 3.1If the form is not fulfilling, back to the form and return error
Preconditions Login through correct user name and password.
Post condition The manager assign technician
Table 15 : Check technician status
Use case No: UC-15

Use case Name: create account
Actor (s): System Administrator

Description: Administrator must have privilege to access site.

events 1. Open website. 3. Display signup form.
2. Click signup link. 6. If the new user name and
4 Select status. password is not found in account table,
3. Enter new user name and display successfully created.
password
4. Re enter password
5. Click create button.
Alternative course: 6.1 If the form is not fulfilling, back to the form and return error
Preconditions Account is created.
Post condition The manager assign technician
Assumptions:
Table 16: Create account

Use case No: UC-16
Use case Name: Change password
Actor (s): System Administrator

Description: Administrator must have privilege to access site.

events 1. Open website. 3. Display signup form.
2. Click sign up link. .
4. Select status.
5. Enter old user name and
password.
6.Click change password
button
Alternative course: 5.1 If the form is not fulfilling, back to the form and return error
Preconditions Administrator must have privilege to access site

Post condition Account of manager, administer, technician are changed.
Table 17 : Change password
2.4 Non Functional Requirements

Non functional requirements (NFRs), also known as "technical requirements" or "quality of
service" (QoS) requirements, focus on aspects that typically cross-cut functional
requirement. Common NFRs include accuracy, availability, concurrency,
environmental/green concerns, internationalization, operations issues, performance,
regulatory concerns, reliability, security, serviceability, support, and timeliness.
 The system sends message to a manager it should gives accurate result; so should
be reliable.
 The system should have an easily understandable design in order for users to use
it; this means the system should be user friendly.
 The system provides quick and easy information analysis which in turn
maximizes the overall work efficiency.
 The system should be able to manage all the information incoming from the
database and the catalogue; Capacity Requirements.
 The system should respond to any user action in 3 second. (Performance)
 The system should be respond to any user action by user of the system that has
access privilege. (security)
 The system should be full documentation of the preliminary investigation, system
requirement analysis; system design document will be compiled to enhance future
reference and system maintenance.
2.5 Analysis Models

Previously, we have been doing on the requirement analysis which has extensively tried
to capture the essential aspects of the problem domain by understanding the users’
requirement. Although requirement model is effective to understand what users want to
have built, it is not as effective as understanding what to build.
2.5 .1 Sequence Diagram

Sequence diagrams are used to model the logic of usage scenarios. A usage scenario is exactly
what its name indicates – the description of a potential way that your system is used. The logic of
a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire
pass through a use case, such as the logic described by the basic course of action or a portion of
the basic course of action plus one or more alternate scenarios. Error: Reference source not found
Figure 3: Login
Figure 4 : Assigns technician
Figure 5 : Views message
Figure 6 : Generate report
Figure 7: View report
Figure 8: Search for manage
Figure 9: Search for technician
Figure 10: Update Information
Figure 11: View account

Figure 12: Send request service
Figure 13: Delete request
Figure 14: Check status
2 .5.2 Activity Diagram

UML Activity diagrams are used to document the logic of a single operation or method, a single
use case (may be the basic course of action or the alternate course of action) or the flow of a logic
of a business process. They are the object oriented equivalent of flow charts and data flow
diagrams (DFDs) in the structured development approach. We have done the activity diagram for
the total business process of the maintenance system of BDU IOT.
An Activity diagram is similar to a flowchart. It is flow of control between

activities. Activity diagrams and State chart diagrams are related. An activity
diagram is a simple and intuitive illustration of what happens in a workflow,
what activities can be done in parallel, and whether there are alternative paths
through the workflow.Error: Reference source not found
Figure 15: Login
Figure 16: Assign technician
Figure 17: Logout
Figure 18: Generate report
Figure 19: View account
Figure
Figure 21: Check status
Figure 22: Delete request
Figure 23: Search Information
Figure 24: Update Information
Figure 25: View message
Figure 26: View report
Figure 27: Create account
CHAPTER THREE: SYSTEM DESIGN
3. System Design
The purpose of the design phase is to plan a solution of the problem specified by the requirements
document. The design of a system is perhaps the most critical factor affecting the quality of the
software; it has a major impact on the later phases, particularly testing and maintenance.
3.1. Deployment Diagram

A UML deployment diagram depicts a static view of the run-time configuration of processing
nodes and the components that run on those nodes. In other words, deployment diagrams show
the hardware for your system, the software that is installed on that hardware, and the middleware
used to connect the disparate machines to one another. You want to create a deployment model for
applications that are deployed to several machines.Error: Reference source not found
Figure 28: Deployment Diagram
3.2. Architectural Design

In architecture the focus is on identifying components or subsystems and how they connect; in
high level design the focus is on identifying the modules; and during detailed design the focus is
on designing the logic for each of the modules. In other words, in architecture the focus is on
what major components are needed, in high level design the attention is on what modules are
needed, while in detailed design how the modules can be implemented in software is the issue.
3.2.1 Class Model

Class models are the mainstay of object-oriented analysis and design, and before the UML
most methodologies called them object models instead of class models. Class models show the
classes of the system, their inter-relationships (including inheritance, aggregation, and
association), and the operations and attributes of the classes.Error: Reference source not found
Class diagram Key:
 AdminID=Administrator Identification Number

 Fid=Furniture Identification Number
 AcadamicEmp=Acadamic Employee
 ElecNo=Electronic Number
 WSHE=Water Sanitation and Hygiene Equipment
 WSHEno=Water Sanitation and Hygiene Equipment Number
 AdminEmp=Administrative Employee
 EmpId=Employee Identification Number
 StudID=Student Identification Number
Figure 29: Class Diagram

3.3. User Interface Design

User interface prototyping is an iterative analysis technique in which users are actively involved
in the mocking-up of the user interface for a system. It enables to explore the problem domain and
the solution space of the system. We design the following user interfaces for BDU IOT
maintenance system.
UI 1: Main Screen
UI 2: Login page
This user interface is displayed whenever the administrator wants to login into the system. The
administrator must have the valid user name and password. If the administrator enters valid
password and username the system will allow her/him to log in to the system and displays main
menu screen and the same as for other members.
UI 3: Sign Up
This user interface is used to select the activities admin wants to perform. The admin can select
one of the activities links and click sign up button. This user interface is used to create new user
account. When the admin clicks on Signup button, the system verifies the entered information. If
the admin clicks on clear, all the information on the form will be cleared.
UI 4: Manager Page
This user interface is used to view the activities of manager wants to perform. The manager can
select one of the activities links.
UI 5: View Page
This user interface is used to view failed item information that are reported from the customers
UI 6: Assign Technician
This user interface is used to select the technician and assign to solve the problems
UI 7: Applicant Form
This user interface is used to report a problem of each customer as well as their detail personal
information to the manager
UI 8: Technician Page
This user interface is used to view the activities of technician wants to perform. The technician
can select one of the links.
UI 9: Update
This user interface is used to update customer and technician information by the manager.
UI 10: Delete
This user interface is used to cancel the customer request after the technician solve the problem
and report to the manager, if he/she successfully maintain the material
UI 11: View Report

This user interface is used to view the report by the manager that is send from the technician
UI 12: Search
This user interface is used to search customer and technician information.
UI 13: Generate Report

This user interface shows that the technician generate a report when he/she finished their task
successfully
3.4 Data Structure Design
3.4.1 ER Diagram
Figure 30: ER Diagram
ER Diagram Key:
 Lname:-Last Name
 Fname:-First Name
 TechId:-Technician Identification Number
 CustId:-Customer Identification Number
 AdminId:- Administrator Identification Number
 WSHE:-Water, sanitation and hygiene equipment
 WSHEmarkNo:- Water, sanitation and hygiene equipment mark number
 ElecNo:-Electronic number
 FurnNo:-Furniture number
 Acqdate:-Acquired date
3.4.1.1 ER Description
 Entity’s:- manager, technician, administrator, material, customer, WSHE, electric,
furniture, office machine, account and service
 Attribute: - Fname, lname, Sex,managerID, TechID, custID,
location,type,status,serialNo,salary,applicantDate,ElecNo,phoneNo,size,
WSHEmarkNo, FurNo,account , user name, password, acq date, and serviceDate etc..
 Relationship: Receive request, offers, assigns, create, request, has, uses and maintains.
3.4.1.2 Entity Description

 Manager: Customer request to gate service then the manager views failed item
information that is going to be maintained and assigns technician to maintain an item.
 Technician: The technician assigned by the manager in order to give service to
customers.
 Customer: The customers are the users of the system have their own materials and a
relationship with manager to gate service
 Material: materials are maintained by technician
 Administrator: The administrators create account for customer, technician and manager
 Service: The technician gives service to customers of the system.
 Account: The accounts are a privilege to each user that have user name and password
to access the system
3.4.1.3 Relationship Description

 Maintains: This relationship shows that the technician maintains materials
 Has: This relationship shows that an interaction between account and users (customer,
technician and manager )
 Uses: This relationship shows that an interaction between customers and service
 Receive request- This relationship shows that the manager receive customers request
 Create- This relationship shows that the administrator create account for manager,
technician and customer
 Assigns- This relationship shows that a manager assigns many technicians technician
 Request service- This relationship shows that the customer’s request service or report
their problems to the manager
3.4.2 ER-Relation Mapping

 Mapping Material Entity
Material
Brand Size Type custID TechID
 Electric
ElecNo Brand Size Type custID TechID
 Office Machine
serialNo Brand Size Type custID TechID
 Furniture
FurNo Brand Size Type custID TechID
 WSHE
WSHEmarkNo Brand Size Type custID TechID
 Mapping technician Entity

Technician
TechID Fname Lname Sex account Salary phoneNo managerID

 Mapping Customer_Material Entity
Customer_Material
SerialNo FurNo ElecNo SantmarkNo acqDate CustID
 Mapping Manager Entity

Manager
managerID Fname Lname Sex account Salary phoneNo

 Mapping Customer Entity
Customer
custID Fname Lname account Sex Location requsetDate

 Mapping Technician_Material Entity
Technician _Material
TechID FurNo ElecNo WSHEmarkNo serialNo

 Mapping System Administrator Entity
System Administrator
AdminID Fname Lname Sex account Salary phoneNo

 Mapping Customer_Account Entity
Customer_Account
custID Fname Lname account Sex Location requsetDate Username

 Mapping Technician_ Account Entity
Technician _ Account
TechID Fname Lname Sex account Salary phoneNo username

 Mapping Manager_Account Entity
Manager_Account
managerID Fname Lname Sex account Salary phoneNo username

 Mapping Account Entity
Account
Password username
 Mapping Manager_Service Entity
Manager_Service
managerID applicantDat serviceDate

e
 Mapping Technician_Service Entity
Technician _Service
TechID applicantDat serviceDate

e
 Mapping Customer_Service Entity
customer _Service
custID applicantDat serviceDate

e
 Mapping Service Entity
Service
serviceDate applicantDate
1. First normal form (remove multi valued attributes)
 Technician(phone No)
TechID Fname Lname Sex Salary phoneNo managerID
TechID Fname Lname Sex Salary phoneID phoneNo managerID
 Manager (phone No)
managerID Fname Lname Sex Salary phoneNo
managerID Fname Lname Sex Salary phoneID phoneNo

 Customer (location)
custID Fname Lname Sex Location requsetDate managerID
custID Fname Lname Sex locationID Location requsetDate managerID

 System Administrator(phoneNo)
AdminID Fname Lname Sex account Salary phoneNo
AdminID Fname Lname Sex account Salary phoneNo phoneID
All tables are normal in first normalization and finished. There is not second and third normal
form.
3.5 Schema Diagram

Material
Brand Size Type custID TechID
 Electric
ElecNo
 Office Machine
serialNo
 Furniture
FurNo
 WSHE
WSHEmarkNo
 Technician
TechID Fname Lname Sex Salary phoneID phoneNo managerID
 Manager
Fname Lname Sex Salary phoneID phoneNo managerID

 Customer
custID Fname Lname Sex locationID Location requsetDate managerID

 System Administrator
AdminID Fname Lname Sex account Salary phoneNo phoneID

Customer_Material
CustID FurNo ElecNo SantmarkNo acqDate SerialNo

Technician _Material
TechID FurNo ElecNo WSHEmarkNo serialNo
Account
username Password
Customer_Account
Username Fname Lname account Sex Location requsetDate custID

Technician _ Account
Usernam Fname Lname Sex account Salary phoneNo TechID

e
Manager_Account
managerID Fname Lname Sex account Salary phoneNo username

Service
serviceDate applicantDate
Manager_Service
managerID applicantDat serviceDate

e
Technician _Service
serviceDate applicantDate TechID

customer _Service
serviceDate applicantDat custID

e
Figure 31: Schema Diagram

3.6 Algorithm Design
3.6.1 Login
Input: username, password

Output: display home page or error message
Procedure:
Begin
1. Enter user name and password
2. select the previous username and password from database and compare with
entered
3. If (username = entered username and Password = entered password)
Go to home page
5. Else
Display error message and return to login form
End if
3.7. Database Design
Appendix 1
Questions asked during requirement gathering using interview
Q1. What are the objectives of your organization?

Q2. What is the mission of your organization?
Q3. How does your current system work?
A. Is it manual?
B. is it computerized?
C. is it semi automated?
Q4. If your answer for question number 4 is choice “b” or “c” what computer applications do you
use?
Q5. How you make relationship with the customer?
Q6.What is the procedures or steps when customers get service of the organization?
Q7.What qualifications are expected from a customer who wants to request to the system?
Q8.How does you store customers and other information’s?
Q9.What are the problem that you get when the organization use the existed system?
Q10.How you prepare report?
Q11.How employees are make relationship with each other to do their task?
Q12.If your answer for question number 4 is choice “a” which type problem occur?

Industrial Project II Final

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Industrial Project II Final

Transféré par

Droits d'auteur :

Formats disponibles

BAHIRDAR UNIVERSITY

INSTITUTE OF TECHNOLOGY (IOT)

AUTOMATION OF BAHIR DAR UNIVERSITY IOT MAINTENANCE

SUBMITTED To Anergechew (MSc)

1 Yibellu Semneh 0503465

LIST OF USER INTERFACE

LIST OF SYMBOLS AND NOTATIONS

 MYSQL:- Multi-user, Structured Query Language

1.3. Purpose of the system

1.4. Existing System vs. Proposed System

1.4.1 Existing System

 Customer must come physically to report problem about maintained problem.

 Poor coordination with proctor in the context of proving requested information

1. 4.2. Proposed system

1.5. Objective of the project

The general and specific objectives are described below.

1.5.1 General objective

1. 5.2 Specific objective

 Reviewing the existing system problems

 Implementation of the project using programming language according to the

 To generate a report, showing the analysis, design, user manual and

1.6. Scope of the project

For conducting our project we used the following methodologies

1.7.1 Data collection method

 Interviewing: - Most analysts use interviewing as a primary way of gathering

1.7.2 Development Tool

 It’s fast and easy

There are several reasons to use MySQL.

 It’s quick and powerful

 It’s improving all the time

1.7.3 Analysis and Design Tool

1.8. Significance of the Project

\ Figure 1: Time Schedule

1.10. Individual Tasks

CHAPTER TWO: SYSTEM FEATURES

2.1 Existing System Description

2.1.1 To request a service

2.1.2 Updating information of technician

2.1.3 Searching the file

2.1.4 Problems encountered by the user

2.1.5 Limitation of the maintenance office

2.2 Proposed System Description

2.3 Functional Requirements

2.3.1 User Requirements

 REQ 1. Login: Manager, administrator, customer and technician log in to website

 REQ15.Create account: Administrator creates an account for manager, customer

2.3.2 System Requirements

2.3.2.1 Use case Diagram

Figure 2: Use Case Diagram

2.3.2.2 Actors of the system

 Technician: The person who is responsible for maintaining the requested

2.3.2.3 Use case list

 UC 13.Send message: User sends message to manager to indicate answered

2.3.2.4 Use case description

Use case No: UC-1

Typical course Actor Action System Response

Alternative 3.1If the user name and password is not valid.

Preconditions Manager has privilege to access system

Post condition The system is opened.

Table 2: Manager Login

Use case No: UC-1

Preconditions Technician has a username and password

Post condition Logged to the system