Full Document of The Project

Online information management system for DC Building Maintenance
Chapter one:
Introduction
Many developing countries are in a good position to exploit the opportunity of technology
revolution and advance human development. The information and communication technology
provide new resource materials for expanding communication.
In fact the second half of 20 th century has wittiness the global phenomena of an information
explosion. The development of different electronic technology has made it possible for millions
of people to have fast access to huge information presented in several forms. 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 tremendous effect for organizations and
offices; which in our case the AMU Building Maintenance office currently, their system is
manual; in which the user seal forms, then, the client manager assigns technician for the user
subsequent to technician cease his job detail information documented manually. So, if the AMU
Building Maintenance office is able to use IT technology they can tremendously benefit in more
than a few means they carry out.
1.1 Background of AMU Building maintenance
Arba Minch University (AMU) is established in 2004 by the regulation No. 111/2004 of the
charter at the premises of the former Arba Minch Water Technology Institute (AWTI), which
was established in 1986. The university is located at a picture square site 5km North of Arba
Minch town on Arba Minch-Addis Ababa road. It has an area of 106 hectare having rolling
topography. Lake Abaya 3 km to East provides a panoramic view, the campus has an average
elevation of 1200m a.m.s.l and the temperature all the year round remains pleasant with an
average of 28oc. and Building maintenance office is also coexisted with the establishment of
Arba Minch University
1.2 Vision statement of AMU Building maintenance
A vision of AMU building maintenance is sustaining a good working environment which exists
and correcting some hindrances happening during the process of the office.
1 Chapter one: | AMU 2004 E.c

1.2.1Mission statement of AMU Building Maintenance

Mission of AMU building maintenance is providing fast and efficient services for customers and
to satisfy them. And also AMU Building Maintenance has Missions of ensuring that there will
not be any delay in academics plane due to any damage on academics supporting materials.
1.3 Background of the project
Now a day the company is getting wider and wider in its services. But the way giving services to users is
hard to satisfy their need, the current system difficult to manage and inefficient in different aspects. In
order to get better efficiency and to make the building maintenance office advantageous, yielding profit
and satisfy users need, so the team initiates to build up an online AMU Building Maintenance by
maximizing the performance.
The main reason that initiate to carry out this project is to full fill Degree level criteria for Graduation.
1.4 Team composition
No Name Id.No E-mail Mobile No responsibility
1 Yohannis Asfaw RET/1961 John.0926111115@gmail. 092611111 All activities
/01 com 5
2 Fsaha Ataklti RET/965 /01 fsahaataklti@gmail.com 092086075 All activities
3
3 Bayesh Ejara RET/ 075 /01 b.ejara3@gmail.com 091468350 All activities
9
4 Nakew Nekere REG/030 /00 Nakewnekere93@ymail.co 091001569 All activities
6
1.5 Statement of the problem

Currently most of the transactions in AMU Building maintenance are manual; hence, if they are
automated they will elegantly increase performance and efficiency of the existing system. These
transactions includes:-
 Users maintenance request forms are stored manually
 The current system uses MS-Excel as a data storage
 Report generation is unwieldy
 Searching for a record takes a long time
 Controlling materials shelf life is too difficult

 Maintenance request is not handy

1.6 Objective
1.7 General objective
The general objective of this project is to develop online information management system for
AMU building maintenance.
1.8 Specific objective
To achieve the above mentioned general objective, the system will address the following specific
objective. The developed system will be able:
 To generate a report
 To manage system user
 To manage articles
 To authenticate a user
 To allocate technician online
 To record issue material information
 To record purchased or manufactured materials information
 To manage materials request
 To manage maintenance request
 To encrypt users password.
1.9 Scope
The new AMU building maintenance information management system developed meets the
following system and information requirements.
 Record maintenance materials list and everyday jobs inside a database.
 Accepts on-line request from clients
 Generate detail report about resources and measures taken.
 Users manage their accounts.
 Encrypts password while storing
 Manage user requirement
 Upload dynamic content on the web page
 Manage received materials
 Manage maintenance request
 Manage material request
 Manage issue material

 Scheming back end for the administrator to have full control over the system
 Alarming for hardly existing materials
 Displaying geographical location of buildings of AMU’s main campus
 The system cannot deal how to contact with client manager superintendents
 The system cannot record purchase related information’s
1.10 Beneficiary of the project
There are different beneficiary bodies from online AMU Building Maintenance System
Which includes:-
 Firstly client manager can easily make plans, coordinates and supervises activities
involving the improvement, maintenance operation, regulation and protection of
buildings; directs the work activity of building maintenance personnel through
subordinate foremen and superintendents.
 Secondly the AMU staffs are benefited since they save their time, energy and can simply
requests for maintenance from their offices online.
 Thirdly AMU staffs will gain good control of internal comfort condition, possibility of
individual room control, effective monitoring and targeting of energy consumption, and
gets effective response for any request according to their priority.
1.11 Data collection methodology
To gather data from the staffs and employees the team will use the following techniques.
Those are:
Interview:-to get the basic information about the existing AMU building maintenance
information management system, the team will interview the AMU building maintenance
material coordinator and some staffs about the services that are given to them, and the problems
associated with that environment.
Questioner: after we finish the interview, we will also use the other methodology of data
collection that is a questioner. During this time we will prepare a questioner and distribute it to
AMU building maintenance employees and staffs who are served to find information on
activities of the AMU building maintenance and the limitations and strength too.
1.12 Software development techniques
 Waterfall frame work
1.13 System analysis and design methodology

The team plan to use the object oriented design methodology for the development of the system
among the different methodologies. Because it is better way to construct, manage and assemble
objects that are implemented in our system. Object oriented design methodology has two
phases:-
Object Oriented Analysis (OOA): During this phase the team 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. And this model the functions of the system (use case modeling),
identifying the business objects, organize the objects and also the relationship between them and
finally model the behavior of the objects.
Object Oriented Design (OOD): During this phase the model interactions and behaviors that
support the use case scenario, and finally update object model to reflect the implementation
environment. And also transforms the conceptual model produced in object-oriented analysis to
take account of the constraints imposed to our system format, so that we will use this phase to
refine the use case model to reflect the implementation environment.
1.14 Development tools

 XAMPP server for system deployment
 Microsoft office 2007 to document about the project
 Microsoft Visio 2010 to design the system diagram
 E-draw to design the system diagram
 HTML, CSS and JAVA SCRIPT for designing the website
 Adobe Photoshop to edit and design web images and texts
1.15 System development environment
Development team uses windows XP and seven as a development environment for the project.
1.16 Project deliverables
 Requirement analysis document
 Design document
 Implementation document and implementation code
 User guide and compiled system
 Testing plan document
 Testing result document

1.17 Schedule
1.18 Project application

The proposed system has the following functionalities; it will record material list and every
day jobs, generate report To manage user, grant adding a new web page by the client manager,
grant editing web pages, grant authentication of user login, allow to see technician allocation on-
line, accept comments on-line, encrypt user accounts and has back end for client manager to
have full control over the system.
Depending on the above functionality of the system the proposed project increases the
efficiency of the existing system in terms of time accuracy, availability. And also it reduces
burdens on the manager; stores detail information’s about the user’s technicians and materials
this also makes it easily manageable
1.19 Limitation
 Time management problem: we tried solving this problem using proper schedule for each
phase of the project and cooperative work among the team, but it was difficult to manage it
completely.

1.20 Risk analysis and mitigation
1.20.1 Risk
Risk ID Risk
1 The client manager may not give us all important and appropriate
information’s if he has no computer experience freeing to lose his job after
system development
2 Virus attack to while developing the system
1.20.2 Mitigation
Risk ID Mitigation
1 Design systematic interview questioner
2 Duplicate files in different computers and Backup files on DVD and external
devices
1.21 Beget of the project

The following table of lists determines budget needed for development of the system
1.21.1 Hardware cost

No Material Amount Price per unit Total price
1 A4 size paper 2 Destin 100 Birr 200Birr
2 pen 7 4 Birr 28Birr
3 Flash disk 2 240 Birr 480Birr
4 For Print 80 sheet 1.5 Birr 120 Birr
5 CD 6 4 Birr 24 Birr
6 Dell computer 3 8500 Birr 25,500 Birr
Total 26,352.00 birr
1.21.2 Software cost
No Material Price per unit
1 XAMPP free
2 Microsoft office 2007 free
3 Micro soft Visio 2010 100

4 E-draw 100
5 MYSQL free
7 Dreamweaver 60
Total 9,490.00 Birr
2 Chapter Two:
Existing System
2.1 Overview
AMU building maintenance provides services for AMU staffs according to certain literal
priorities. Services can be provide by classifying buildings in to two categories, the first category
includes, staffs living houses, studying class rooms, cafeterias and dormitories; and the second
category includes staff offices, Management, Registrar and others. Materials maintained will be
one of the two categories in the buildings
With the existing system, all
the activities are performed manually. In maintenance material coordinator office there is a little
use of general applications like Ms Excel and access to store and process data. Files are manually
stored, moved and processed from one section to another. Finally all manual activities delivered
to material account section for encoding and generating reports.
2.2 Players of existing system
The players of the existing system includes: -
 Department head who is responsible for approving material request and monitoring
different activities
 Store head who is responsible for approving issue material from store
 Store keeper who is responsible for issuing materials and monitoring materials shelf life
status
 Stock card which is a type of form used in the AMU Building Maintenance office to
register newly purchased or manufactured materials information.

 Bin card which is a type of form used in the AMU Building Maintenance office to
register material issue information
 Maintenance request form which is a type of form used in the AMU Building
Maintenance office to request for maintenance service
2.3 Major Functions of Existing System

The office has different major functions, which includes:-
 Registration of purchased or manufactured materials
o Main storekeeper receives and registers newly purchased or manufactured
materials
 Sub storekeeper requests materials from main store
o Sub storekeeper requests maintenance material from main store
o Main store keeper checks the availability of materials
o Director office approves the request
o Then Resource office approves the request
o After that Administration office approves the request
o At last balance office calculates balance
o And finally main store keeper issues materials
 User request for maintenance service
o User request maintenance service
o Maintenance materials coordinator views maintenance request, approve
maintenance request and order technician.
 Technician request for maintenance material
o Technician view his order, request maintenance material from sub store.
o Sub storekeeper views maintenance material request, and issues maintenance
material.
 Information and flow after technician work accomplished

o Technician registers accomplished works and puts his remark.

o User views work accomplished by technician and puts his remark.
 Material return from technician to sub store,
o Sub store keeper receives materials and registers material return information and
puts his remark.
o Technician views Material return information and puts his remark.
2.4 Business Process Model
The following business use cases are identified during the requirement gathering process and
described thereafter.
No BUC ID BUC Name BUC Description
1 BUC-1 Manage In this business use case a Material Requester requests material
material request from store using store requisition form .This form is prepared by
the Department and approved by department head.
2 BUC-2 Manage In this business use case, the storekeepers receive the
Received purchased/manufactured materials and store them in to their
materials perspective store location and register materials on Stock Card.
3 BUC-4 Manage In this business use case, materials returned to store are
Material Return received, registered and arranged on the shelf by the
Storekeeper.
4 BUC-5 Users manage In this business use case, the users login in to the system and
their accounts update their existing accounts from a database.
5 BUC-6 manages system In this business use case, the Administrator manages user
users accounts by login in to the system.
6 BUC-7 upload dynamic In this business use case, the client manager can creates and
content upload dynamic contents on the website by login into the
system.
7 BUC-8 Manage In this business use case, the Storekeeper make timely materials
materials shelf- shelf life and status checkup register the result and submit hardly
life and status existing materials reports to the Store head.
8 BUC-9 Generate detail In this business use case, the Store head, the storekeeper and the
report department head can login into the system and generates
periodical report.
2.5 Report Generated in Existing System

In existing system detail report generated about every transactions and materials applied
quarterly for use, to their superintendents.
2.6 Forms and other documents of the existing systems
2.6.1 Stock card

Fig 1. Stock card
2.6.2 Bin card
Fig 2. Bin card

2.6.3 Maintenance request form

Fig 3. Maintenance request form
2.7 Bottlenecks of the Existing System
As the team explained in chapter one, the existing system has many problems, which initiated the
team to develop a new computerized system to the AMU Building maintenance. These problems
can be explained in terms of PIECES framework:
The performance of the existing system can be evaluated by the time duration of the service after
the staff’s maintenance request and the number of staffs served at a time, and this depend on the
number of staffs and the number of employees who give the service. If the numbers of the staffs
requesting are a less, the service will provide to all of them at a time.
All the above statements are full filled if the employees can handle the entire staffs request
effectively and quickly, but the existing system has a problem like:
 The numbers of employees needed to handle the staffs request are limited.
 It takes lot of time to diffuse the maintenance request information to employees.
Therefore these stated problems make the performance of the existing system low.
Regarding to the information, the existing system has lack of the information in terms of
timeliness, accuracy and format. The team sees this section in terms of input and output.
Inputs:
 Loss of items information
 Fragmentation of information’s in different files
Output:
 In terms of producing report information to Boss.
 In terms of getting remained maintenance information.
The existing system has a great problem in terms of controlling and managing all documents of
the registered new maintenance requests and the daily and monthly report of the maintenance

service perfectly, as days increase, the maintenance requests will increase and the documents
also increase so it will be out of control to manage the documents.
In terms of the security the documents are not protected from any unauthorized access. In
addition, if there is a natural disaster or other thing that can damage the documents, there is no
means of getting the documents back. So the security of the AMU building maintenance is in
danger.
The efficiency of the existing system could be evaluated in terms of the services of the AMU
building maintenance for AMU staffs. But as we explained in above problems, the overall
efficiency of the existing system is not stable or as a general it is not efficient.
Because AMU building maintenance is using the manual system there is a problem in giving the
service to the staffs. To mention some of the problems of the existing system,
 Need of high energy and time to diffusing maintenance information’s for employees.
 In saving the staffs time because they have to wait long time until they get the ser -
vice.
 Inability to give the service to more staffs at a time.
2.8 Practice to be preserved in existing system

Existing system provides effective service for users, in main campus and new campuses
according to certain literal priorities. Materials inside store located accordingly on their right
perspective location which makes them easy to find when required. In existing system detail
reports are also has been generated quarterly per a year about transactions and materials used for
replacing; so, it is nice timing for reporting.
Although the teams have mentioned that the AMU Building maintenance has problems that
constraint its fast way of efficiency, there is also other important side that must be included in the
proposed systems that is the list of the preserved practices from the existing system stated below.
 The way of providing services to staffs with good approach.

 Controlling and registering the items when they come into the store
 System procedure

2.9 Proposed solution for the new system

The development of new online management information system for AMU Building
Maintenance office benefits all the staffs and users by increasing the efficiency of the system.
We also comes with a solution for big problem through making online maintenance service
request available, this will reduces the burden for those staffs requesting from other campus
beside the main campus, for busy staffs and also facilitates the operation of the system. Our
system will provide good database storage and control over materials so, the manager controls
every aspects on the material if they are available or not or ended. And also it is easy to decide
when to request for the delivery of almost ended materials.
The other thing is that the store keeper can easily manage every receiving of materials disposal
of materials, since, they would be recorded inside a database.
2.10 Requirement Analyses
2.10.1 Functional Requirements
The proposed system deals with automating; using a web based system, the AMU Building
Maintenance. In order to see the desired outcome of the system the following requirements are
identified. The functionalities range from maintaining permanent information to generating
various report types. The core functional requirements of the system are listed as follow
 Manage Users Request: This functional requirement is one of the main targets of this
project; in which users can request online for a service, and the AMU Building
Maintenance office can provide them the desired service accordingly.
 Manage Recruitment: The proposed system will allow the Administrator to enrol
users and staffs in which all of them are inside the system of the office
 Manage Materials Disposal: In this functionality, the system should manage disposed
materials information and notify the users when a specific material is disposed. The
system should also alarm when the materials hardly exist
 Maintain Member Profile: The proposed system should allow the manager to keep
information about the staffs and users; the information can be received and used at any
time.
 Prepare Report: The system will generate a report about each transaction taken place;
in this functionality; a weekly, monthly, quarterly and annually report should be
generated based on the report type and duration data entered by the client manager.
2.10.2 Non Functional Requirement

 Usability: The system needs to be user friendly, the user interface will be designed to be
easy to use and attractive, and it will provide different functionality like providing
information whenever appropriate or when user makes error. Thus, the system is
supposed to be efficient and easy to learn.
 Documentation: The system development documentation which shows how the system
is developed from starting phase up to the end will be provided so that users will be able
to grasp how the system is developed.
The system will also be accompanied with the following documentation:
 Online User guide (user manual)
 Operational Procedure
 Application Training manual
 Security issues: Since the proposed system automates AMU Building Maintenance on
web based the system should provide higher security from any intentional attacks
 Concurrency: The system should support multiple accesses of users. It should give
service to multiple users concurrently.
 Portability: The system should be portable thus capable of running on different
platforms, adaptable with other systems, installable on different machines architectures,
and replaceable if the need arises.
 Maintainability: The System should be easily maintainable in case of problems,
changeable in case the need of incorporating new components arises from either the
clients side or technological changes, give consistent service at all times without
fluctuation and should be testable.
2.11 The nonfunctional requirements must have the following
1. Performance
 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.

2. User Interface
 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.
3. Security and Access Permissions
 Only users holding the role administrator can manage contents of the website,
and maintain system user’s profile.
 Only users holding the role storekeeper will manage transactions on materials.
 Only users holding the role Department head will approve transactions on
materials.
 Only users holding the role user and technician can request for a service.
4. Backup and Recovery
 Backup will be stored on the intranet server and AMU website.
 All process can be made available after unplanned down time within 1 day.

3 Chapter three
System Analysis
3.1 Introduction
This chapter is about Analysis of the proposed AMU Building Maintenance system. The system
is analyzed using different UML analysis modeling techniques, which, includes, use case
diagram, use case documentation, sequence diagram, activity diagram, and analysis class
diagram and user interface prototype.


3.2 System Requirement Specification
3.2.1 Use case diagram

3.2.2 Use case description
Table1. Mange system user

Use Case Name:
Manage system user
Actors: Administrator
Purpose To give permission for user to manage recourses
Description: In this use case each user is assigned a role and permission to use the system resources
(common tasks). More over the user’s will be provided with their own user name and
password
Alternative 1. Administrator assigns role for resources

2. Administrator enroll users
Table2. Manage dynamic article
Use Case Name: Manage dynamic article
Actors: Administrator
Purpose To edit and upload new article on the web
Description: In this use case the Administrator upload new article which was not existed on the web
Alternative Administrator edits existing article

Table3. Login
Use Case Name: Login
Actors: All users
Purpose Entering to privileged mode to use resource
Description: In this use case the user enter to privileged mode and performs the possible required action on the
resource available for him
Alternative
Table4. Manage accounts
Use Case Name: Manage accounts
Actors: All users
Purpose To change their own password or to remember his/her forgotten Password
Description: In this use case the user can manage his account according to his will he can change his password
Alternative He can recover his forgotten Account
Table5. Material request

Use Case Name: manage material store request
Actors: Sub tore keeper, Department technician
Purpose To make it easily available to response for user request
Description: The user prepare periodical and annual consumption request
Alternative The user cancels the information is preparing for request or he may enters wrong data in
request form
His data may not be valid
Table6. Received material

Use Case Name: manage material store request

Actors: Sub tore keeper, Department technician
Purpose To make it easily available for response user request
Description: The user prepare periodical and annual consumption request
Alternative The user cancels the information is preparing for request or he may enters wrong data in
request form
His data may not be valid
Table7. Issue Materials
Use Case Name: Issue materials
Actors: Includes(Main store keeper and sub store keeper)
Purpose To issue requested materials for a requester
Description: In this use case after Main storekeeper or sub store keeper received approved material request he
would have to deliver to the requester if the materials are available
Alternative Put approved request out of stump
Table8. Manage Building Maintenance Information
Use Case Name: Manage Building Maintenance Information
Actors: Technician
Purpose Recording information about maintenance of a building
Description: In this use case after Technician is maintains the building he will recorded all the necessary
information’s about the maintenance and materials used
Alternative

Table9. Mange material return

Use Case ID:
Use Case Name:

Manage material return
Actors: Store keeper
Purpose To return disposal materials to store
Description: Material return information is registered on stock card by store keeper
Alternative Store keeper enters wrong data about materials Return information yet he would cancel
the information before sending it is permanent
Table10. Generate Report
Use Case Name: Generate report
Actors: Includes(Main storekeeper, sub storekeeper ,department head )
Purpose Geminating required report
Description: In this use case the user can generate required report in period
Alternative

3.2.3 System Use case documentation
1. Manages system user

Use Case ID: 1
Use Case Name: Manage System Users
Actors: Primary
 Administrator
Description: In this system use case ,Each user is assigned a role and permission to use the
system resources (common task and pages).Moreover, each user will be provided
with his/her own user name and password to log-in to the system.
Trigger:  When new user or role is appear.
Preconditions:  The user should be authentic and should insert his/her user name and pass-
word correctly.
Normal Flow: 1. The user selects Manage Resource option from Admin page menu.
2. The system display Resource Registration form
3. The user registers all the necessary information and then presses "ADD
Resource" button.
4. End of use case
Post conditions: Resource is registered and saved on the database.
Alternative Flows: The User wants to Manage Role
1. The user selects Manage Role option from Admin page menu.
2. The system display Manage Role form
3. The user registers New Role
4. The user Assign role to Resource
5. Then presses "Save" button.
6. End of alternate flow
Post condition: Role is registered and assign to resource.
The User wants to Manage User
1. The Page Administrator selects Manage User option from Admin page

menu.
2. The system display Manage User form
3. The Page Administrator registers New user
4. The Page Administrator Assign User to Role
5. Then presses "Save" button.
Post condition: New User is registered and assign to Role.
Table: 1 Manage System Users
2. Manages dynamic articles

Use Case ID: 2
Use Case Name:

Manage Dynamic Articles
Actors: Primary
 Administrator
Description:
In this system use case the user approves valid requests
Trigger:
When the user select Approve request
Preconditions:
 The user should be authenticated
Normal Flow: 1. The user selects “add new articles”

2. The system displays the “add new article” page.
3. The user selects and fills all the necessary information’s
4. The user selects upload button
5. The system validates new article information
6. If the information is invalid return to step 2 and the system displays er-
ror confirmation message
7. If the information is valid the system saves the new article to a data -
base and uploads it the web and the system displays validity confirma-
tion message.
8. End use case

Post conditions: The article uploaded to the web
Alternative Flows: The user want to edit existing article

1. The user press “edit article” button
2. The system displays list of articles with “search” option
3. the user selects the article he wants to edit
4. the system displays details of the article
5. the user edits and press save
6. the system validates edited information
7. If the information is invalid return to step 2 and the system displays error
confirmation message
8. If the information is valid the system saves the edited article to a database
and uploads it the web and the system displays validity confirmation mes-
sage.
Post condition: The article edited and uploaded to the web
The user want to cancel the information entered
10. The user press cancel button
11. the system cancel the information entered
Post condition: The entered information cancelled
Table: 2 Manage Dynamic Articles

3. Login
Use Case ID: 3
Use Case Name:

Login
Actors: Primary
 Include(Administrator, Main Store head, sub store head , technician,

user)
Description:
Trigger:
When the Staff browses home page or admin page
Preconditions:
 The system should displays login form
Normal Flow: 1.The user enters user name and password and selects role
2.The user selects submit button
3.The system validates user information
4.If the user account information is not valid return to step 1 and displays error
5.If the user account information is valid the user enters to prevailed mode and
displays validity confirmation message
6.End use case
Post conditions: The user enters to privileged page
Alternative Flows: The user want to cancel the information entered

7.The user press cancel button
8.the system cancel the information entered
9.End of alternate flow
Table: 3 Login
4. Manages account
Use Case ID: 4

Use Case Name:

Manage account
Actors: Primary
 Staff
Description:
Trigger:
When the Staff browses home page or admin page
Preconditions:
Normal Flow: 1. The user selects change password

2. The system displays change password page
3. The user fills and selects all necessary information’s
4. The system validates user information
5.If the user account information is not valid return to step 2 and displays error
6. If the user account information is valid the system changes user’s password
and displays validity confirmation message
7. End use case
Post conditions: The user enters to privileged page
Alternative Flows: The user want to remember his account information

1. The user selects “forget password” or “forget user name”
2. The system displays remember password or remember user name form
3. The user fills and selects all the necessary information’s required by the
form
4. The system validates the information entered in the form
5. If the information is invalid the system returns to step 2 and display inva-
lidity confirmation message
6. If the information is valid the system displays the user’s user name or
password


Table: 4 Manage account
5. Maintain received materials

Use Case ID: 5
Use Case Name: Maintain Received Materials Information
Actors:  Main Store Keeper
Description: In this system use case the user maintains Received materials received at store.
Trigger: When the user want to maintain Receive Items
Preconditions:  The user should be authenticated
Normal Flow: 1. Store keeper selects “Add New received materials” option
2. The System displays the page and generates the next received material
Number.
3. Main Store keeper fills/selects all the required and necessary fields on
stock card.
4. Store keeper presses “Save” button and the data are saved to a data-
base.
5. End of use case
Post conditions: Newly received materials are added to the stock card.


Table: 5 Maintain Received Materials Information
6. Requests material
Use Case ID: 6
Use Case Name:

Manage Material Store Requisition
Actors: Primary
 Requester (Sub Store Keeper, Department Technician )
Description:
In this system use case the user prepare periodical and annual consumption request
Trigger:
When the user select Prepare Store Requisition or Prepare Annual Consumption
Request option.
Preconditions:
Normal Flow: 1. The Requester select “Add New Store Request” page
2. The system displays the SR page
3. The Requester select stock of material he/she want to request from materials list
combo box
4. The system displays material balance of the selected material code.
5. The Requester fills the quantity he/she want and press Add button.
6. The system adds the selected material along with the amount requested to the req-
uisition materials list.
7. The Requester writes his/her remark and press Submit button.
8. The system display confirmation message
9. End use case
Post conditions: The Store Requisition sent to approver to be approved
Alternative The user want to cancel the information entered

Flows: 1. The user press cancel button

Table 6: Manage Material Request
10. Orders technician

Use Case ID: 7
Use Case Name:

Assign technician
Actors: Primary
 Department head
Description:
Trigger:
When the Department head selects Assign technician
Preconditions:
Normal Flow: 1. The user selects Assign technicians page

2. The system displays the technician Assigning page
3. The user selects and fills the required information
4. The system validates inputs
5. The user selects save button
6. If the input is invalid the system returns to step 3 and displays invalidity
of input confirmation message
7. If the input is valid the system saves the information in a data base and
displays validity of input confirmation message
8. End use case
Post conditions: Assignment information sent to assigned technician

Table: 7 Orders technician

11. Issue Material

Use Case ID: 8
Use Case Name:

Issue Materials
Actors: Primary
 Issue staff (Sub Store keeper, Main store keeper)
Description:
In this system use case the user Issue materials another user
Trigger:
When the user selects Issue Material
Preconditions:
Normal Flow: 1. The user selects Issue item

2. The system displays the Issue item page
3. The user selects Issue item
4. The system displays the Issue type list of store approved requests
5. The User selects type of issue and an approved store request.
6. The system displays new issue voucher.
7. The User selects and fills information in issue voucher.
8. The system validates information.
9. The User selects save button.
10. If the information fill is invalid the system return to the step 7 and dis -
play error confirmation message.
11. If the information is valid the information will be saved in the data
base and the system displays confirmation message.
12. End of use case.
Post conditions: The issue items information saved to a database and a user receives issue
materials


Table: 8 Issue Materials
12. Manages maintenance information

Use Case ID: 9
Use Case Name:

Manage Maintenance Information
Actors: Primary
 Department Technician
Description:
In this system use case the user register’s maintenance information
Trigger:
When user selects manage maintenance information
Preconditions:
Normal Flow: 1. The user selects manage maintenance information

2. The system displays the technician maintenance management page
3. The user selects and fills the required information
4. The user selects save button
5. The system validates inputs
6. If the input is invalid the system returns to step 2 and displays invalidity
of input confirmation message
7. If the input is valid the system saves the information in a data base and
displays validity of input confirmation message
8. End use case
Post conditions: Maintenance information registered to a database
Alternative Flows: The user want to edit existing maintenance information

1. The user press “edit” button
2. The system displays list of non user accepted maintenance information’s

with “search” option

3. the user selects the maintenance information he wants to edit

4. the system displays details of the maintenance information
5. the user edits and press save
6. the system validates edited information
7. If the information is invalid return to step 2 and the system displays error
8. If the information is valid the system saves the edited
Post condition: The edited information saved to a database

Table: 9 Manage maintenance information
10. Manages material return

Use Case ID: 10
Use Case Name: Manage Material Return
Actors: Primary
 Store Keeper

Description: In this system use case both fixed and none fixed Material returns information
registered, update by the users.
Trigger: When the user select Material return option from the page menu.

 Material should be returned first
Normal Flow: 1. Store keeper selects “Material return” option
2. The System displays the “Maintain SRN” form and generates the next SRN
Number.
3. The user fills/selects all the required and necessary fields on SRN.
4. The user presses “Save” button and the data is saved as “PREPARED”
SRN Status.
5. The system updates Bin card and display confirmation message.
6. End of use case
Post conditions: Material return information is registered
Alternative When the user wants to view SRN information

Flows:
1. The Storekeeper selects “View material return” option
2. The system displays SRN View Form with “Search” options
3. The Storekeeper specifies the searching criteria.
4. The system displays the data related to the selected SRN Number on the
main page content
5. The Storekeeper views and/or prints the SRN Form after pressing “File”-
>“Print Preview”->”Print” menus of the browser.
Post Condition: The request SRN information is viewed and/or printed.


Table: 10 Maintain Material Return Information
11. Approve material requests

Use Case ID: 11
Use Case Name:

Approve store request
Actors: Primary
 Approver staff (Sub Store head, Main store head Department Head )
Description:
Trigger:
When the user select Approve request
Preconditions:
Normal Flow: 1. The user selects approve request

2. The system displays the approve request page with new requests on
hand
3. The user views new request lists and selects the request he wants to
approve
4. The system displays details of the request
5. The user views details of the request and he approves the request
6. The system saves status of the request to a database.
7. The system displays approval confirmation message
8. End use case
Post conditions: The request approved and send to requester
Alternative Flows: The user want to reject the request

1. The user views the requests detail press reject button
2. the system saves the request status to a database
3. the system displays rejection confirmation message
Post condition: The rejected request and send to requester
The user want to void the request

1. The user views the requests detail press void button

2. the system saves the request status to a database
3. the system displays void confirmation message
Post condition: The void request and send to requester
Table: 11 Approve material requests
5. Generate report
Use Case ID: 12
Use Case Name: Manage Material Return
Actors: Primary
 Store Keeper
Description: In this system use case both fixed and none fixed Material returns
information registered, update by the users.
Trigger: When the user select Material return option from the page menu.

 Material should be returned first
Normal Flow: 7. Store keeper selects “Material return” option
8. The System displays the “Maintain SRN” form and generates
the next SRN Number.
9. The user fills/selects all the required and necessary fields on
SRN.
10. The user presses “Save” button and the data is saved as “PRE-
PARED” SRN Status.
11. The system updates Bin card and display confirmation mes-
sage.
12. End of use case
Post conditions: Material return information is registered

Alternative Flows: When the user wants to view SRN information
7. The Storekeeper selects “View material return” option

8. The system displays SRN View Form with “Search” options
9. The Storekeeper specifies the searching criteria.
10. The system displays the data related to the selected SRN
Number on the main page content
11. The Storekeeper views and/or prints the SRN Form after
pressing “File”->“Print Preview”->”Print” menus of the
browser.
Post Condition: The request SRN information is viewed and/or

printed.

Table: 12 Generate Report
3.2.4 Sequence diagram

1. Manage System Users

Fig. 1Sequence Diagram Manage System Users
2. Manage Dynamic Articles

Fig. 2 Manage Dynamic Articles

3. login
Fig. 3 login
4. Manage account

Fig. 4 Manage account
5. Maintain Received Materials Information

Fig. 5 Maintain Received Materials Information
6. Material request

Fig. 6 material request
7. Orders technician

Fig. 7 Orders technician
8. Issue Material

Fig. 8 issue Material
9. Manages maintenance information

Fig. 9Manages maintenance information
10. Maintain Material Return Information

Fig. 10 Maintain Material Return Information
11. Approve material requests

Fig. 11 Approve material requests
12. Generate Report

Fig. 12Generate Report

3.2.5 Activity diagram
3.2.5.1 Manage System Users
Fig. 1 Activity diagram Manage System Users

4 3.2.5.2 Manage Dynamic Articles
Fig. 2 Activity diagram Manage Dynamic Articles

5 3.2.5.3 login
Fig. 3 Activity diagram login

6 3.2.5.4 Manage account
Fig. 4 Activity diagram Manage account

7 3.2.5.5 Maintain Received Materials Information
Fig. 5 Activity diagram Maintain Received Materials Information

8 3.2.5.6 Material request
Fig. 6 Activity diagram material request

9 3.2.5.7 Orders technician
Fig. 7 Activity diagram Orders technician

3.2.5.8 Issue Material
Fig. 8 Activity diagram Issue Material

10 3.2.5.9 Manages maintenance information
Fig. 9 Activity diagram Manages maintenance information

3.2.5.10 Maintain Material Return Information
Fig. 10 Activity diagram Maintain Material Return Information

11 3.2.5.11 Approve material requests
Fig. 11 Activity diagram Approve material requests

12 3.2.5.12 Generate Report
Fig. 12 Activity diagram Generate Report

12.1.1Analysis level class diagram

Fig. 12.1.1 Analysis level class diagram
12.1.2User interface prototype

4. CHAPTER FOUR
SYSTEM DESIGN
4.1 Introduction
This project is designed in a manner that solves the problems of the organization 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.
Generally, the project will be designed by addressing all of the above criteria of 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 sys-
tem.
 Reliability: the system should be reliable.

4.2 Class type architecture
Fig 4.2 class type architecture

4.3 Class modeling

4.4 State chart modeling

4.5 Collaboration modeling

Manage Dynamic Articles
Login

Material request
Manage account

Material Issue
1.

Manages maintenance information
Approve material request

Generate Report

4.6Component modeling

4.7Deployment modeling

4.8Persistence modeling

4.9User interface design




Chapter five:
Implementation and Testing
Introduction
In this phase what the group ambers have done is turning the physical design specification into
working computer code, and then the code is tested until most of the errors have been detected
and corrected user sites are prepared for new system and user must come totally on the new
system rather than the existing one to get there work done. There are some managerial activities
in this, coding, testing, and installation.
5.1 Test procedures

Unit testing: -Every module of the System is separately tested. I.e. the team tests every module by
applying some selection mechanism. Through this mechanism every modules gets tested. If an error
occurs correction will be taken without affecting another module.
Integrated testing: - In this testing part, all the modules combined together and tested for fitness with
each other and with the systems functionality. If error occurs in combining them, the module with
problem will be identified and re combined.
System testing: - In this testing, the team performs over all functional testing by checking whether it
meets the required target.
5.2 Hardware and Software acquisitions

For the project implementation; the following Software and hardware are used.
Hardware
 Printer: For printing Documentation
 Server: for connection to the client computer(to host the system)
 Computers
 Network connection

Software
For the System implementation the following software’s are used.
 Apache server
 Dream weaver
 Notepad++
 Mysql database server
5.3 User manual preparation

Since the system is web based everything important for the user will be explained and
implemented while giving short training when the system is deployed. Rather there is no need of
preparing full user manual because it is only deployed (hosted) on a single machine that is server.
5.4 Training
During the deployment of the system, the project group members will give short time training for
the system administrators explaining how the system works and in what way they can manage
their system.
5.5 Installation
Since the project is a web based System, there is no need to install it on a particular machine
rather it will be hosted on a server.

5.6 Coding




“Login sample code”

“view user profile sample code”




Chapter six
Conclusions and Recommendations
6.1 Conclusions
It is known that developing a system for an organization is not easy. But the team have tried its best
and developed interesting online information management system for AMU. It is flexible, accurate and
attractive with easy GUI approach. Generally, the team confidently can say that the software is
completed successfully with negligible errors. Finally the team expects the software will change the
general information management atmosphere of the Organization and makes it more reliable and
efficient than the previous manual system.
6.2 Recommendation
According to scope of our project the team develops web application .Because of the time constraint
we cannot do beyond to our scopes, but in the future the team believes that this system can be fully
operational by having enough time and fully information.
Finally the team would recommend that further work should done on the system in order to make the
system perform better for interested organizations who would like to use electronic online information
management system for Building maintenance, for those who would like to work on online
information management system Building maintenances its recommended to do more work on the
functionalities such as:-
 Manage expired and dormant materials disposition

 Manage materials purchase request
Reference
http://www.ibm.com/developerworks/rational/library/3101.html
http://www.agilemodeling.com/style/collaborationDiagram.htm
Robert C. Martin Engineering Notebook Column Nov/Dec, 97

Full Document of The Project

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Full Document of The Project

Uploaded by

Copyright:

Available Formats

Online information management system for DC Building Maintenance

1 Chapter one: | AMU 2004 E.c

1.2.1Mission statement of AMU Building Maintenance

1.5 Statement of the problem

2 Chapter one: | AMU 2004 E.c

 Maintenance request is not handy

 Manage issue material

1.13 System analysis and design methodology

1.14 Development tools

 Testing result document

1.18 Project application

6 Chapter one: | AMU 2004 E.c

1.20 Risk analysis and mitigation

1.21 Beget of the project

1.21.1 Hardware cost

7 Chapter one: | AMU 2004 E.c

8 Chapter one: | AMU 2004 E.c

2.3 Major Functions of Existing System

9 Chapter one: | AMU 2004 E.c

o Technician registers accomplished works and puts his remark.

life and status existing materials reports to the Store head.

2.5 Report Generated in Existing System

2.6.1 Stock card

11 Chapter one: | AMU 2004 E.c

Fig 1. Stock card

2.6.2 Bin card

Fig 2. Bin card

12 Chapter one: | AMU 2004 E.c

2.6.3 Maintenance request form

13 Chapter one: | AMU 2004 E.c

Fig 3. Maintenance request form

2.7 Bottlenecks of the Existing System

14 Chapter one: | AMU 2004 E.c

2.8 Practice to be preserved in existing system

 The way of providing services to staffs with good approach.

15 Chapter one: | AMU 2004 E.c

2.9 Proposed solution for the new system

2.10.2 Non Functional Requirement

17 Chapter one: | AMU 2004 E.c

18 Chapter one: | AMU 2004 E.c

19 Chapter one: | AMU 2004 E.c

20 Chapter one: | AMU 2004 E.c

3.2 System Requirement Specification

3.2.1 Use case diagram

21 Chapter one: | AMU 2004 E.c

3.2.2 Use case description

Table1. Mange system user

Purpose To give permission for user to manage recourses

Alternative 1. Administrator assigns role for resources

Table2. Manage dynamic article

Use Case Name: Manage dynamic article

Purpose To edit and upload new article on the web

Alternative Administrator edits existing article

22 Chapter one: | AMU 2004 E.c

Use Case Name: Login

Actors: All users

Purpose Entering to privileged mode to use resource

Table4. Manage accounts

Use Case Name: Manage accounts

Actors: All users

Purpose To change their own password or to remember his/her forgotten Password

Alternative He can recover his forgotten Account

Table5. Material request