ONLINE LIBRARY MANAGEMENT SYSTEM.

BY
ONESS NAMES m
A project documentation for an online library management system

NOVEMBER, 2019

________________________________________________________________________

Page 1 of 40
DECLARATION
I hereby declare that this Project is my own work and has, to the best of my knowledge,
not been submitted to any other institution of higher learning.

Student: ___________________ Registration Number:

_________________

Signature: ............................................... Date: .....................................................

This project [proposal] has been submitted as a partial fulfillment of requirements for the
Diploma in Information Technology in Zetech University with my approval as the
University supervisor.

Supervisor: _________________________

Signature: ..................................................... Date:

..................................................

Page i of 40
ABSTRACT
“ONLINE LIBRARY MANAGEMENT SYSTEM” is system developed for managing
various activities in the school library. For the past few years the number of educational
institutions is increasing rapidly. Thereby the number of library is also increasing for
quality learning of the students studying in this institution. And hence there is a lot of
strain on the person who are recording/issuing the books and software’s are not usually
used in this context. This particular project deals with the problems on managing library
activities and avoids the problems which occur when carried manually. Identification of
the drawbacks of the existing system lead to the designing of computerized system that
will be compatible to the existing system with the system which is more user friendly and
more GUI oriented. We can improve the efficiency of the system, thus overcome the
drawbacks of the existing system.

Page ii of 40
DEDICATION
This project is dedicated to my parents; Douglas mutahi and Peris Wanjiku who has fully

supported me financially in my entire study; Mr. and Mr.’s Kariuki who have been of great

help to me.My Supervisor Mr Gitonga . and to the institution (Zetech University) for

giving me the opportunity to expand my knowledge. Thank you for your never-ending

support without you I would have not accomplished this.

Page iii of 40
ACKNOWLEDGEMENT.
Here i gladly present this project report on “ONLINE LIBRARY MANAGEMENT
SYSTEM” as part of the year two semester two. At this time of submitting this report I
use this opportunity to mention those people who worked with me along the work. I take
this occasion to thank God, almighty for blessing me with his grace and taking my
endeavor to a successful culmination. I extend my sincere and heartfelt thanks to my
esteemed guide, Mr. for providing me with the right guidance and advice at the crucial
junctures and for showing me the right way and to Mr. Onkoba, Mr. Barrack and Mr.
kavoi for their encouragement and advice. I extend my sincere thanks to my respected
Head of the Department Mrs. cate for allowing me to use the facilities available. I would
like to thank the other faculty members also, at this occasion. Last but not the least; I
would like to thank friends and family for the support and encouragement they have
given me during the course of my work.

Submitted by Oness

Page iv of 40
Table of Contents

Contents
DECLARATION .............................................................................................................................. i
ABSTRACT..................................................................................................................................... ii
DEDICATION ................................................................................................................................ iii
ACKNOWLEDGEMENT. .................................................................................................................... iv
Table of Contents ............................................................................................................................. v
CHAPTER ONE - Introduction ........................................................................................................... 1
1.1 Background of Study ........................................................................................................... 1
1.2 Problem Statement............................................................................................................... 2
1.3 Aim of the Study................................................................................................................... 3
1.3.1 Research Questions ........................................................................................................ 3
1.4 Limitations ............................................................................................................................ 3
CHAPTER TWO – Literature Review ................................................................................................. 5
2.1 Introduction .......................................................................................................................... 5
2.2 Existing Systems ................................................................................................................... 5
2.2.1 Disadvantages: ................................................................................................................ 5
2.3 Proposed Solution ................................................................................................................ 6
CHAPTER THREE – Methodology ..................................................................................................... 7
3.1 Introduction .......................................................................................................................... 7
3.2 Feasibility .............................................................................................................................. 8
3.2.1 Technical Feasibility ............................................................................................................ 9
3.2.2 Economic Feasibility............................................................................................................ 9
3.2.3 Operation Feasibility ........................................................................................................... 9
3.3 Requirement Specification.................................................................................................... 9
3.3.1 Functional Requirements .................................................................................................... 9
3.3.2 Non-functional Requirements .......................................................................................... 10
3.4 Data Collection .................................................................................................................... 10
3.4.1 Interview ........................................................................................................................... 11
3.4.1 Questionnaires ..................................................................... Error! Bookmark not defined.
3.5 Hardware Configurations ..................................................................................................... 11
3.5 Software Configurations ..................................................................................................... 12

Page v of 40
CHAPTER FOUR – System Analysis ................................................................................................. 13
4.1 Introduction ......................................................................................................................... 13
4.2 Analysis of the current System ............................................... Error! Bookmark not defined.
4.3 System Requirements .......................................................................................................... 13
4.3.1 Functional Requirements .............................................................................................. 14
4.3.2 Non-Functional Requirements ...................................................................................... 15
CHAPTER FIVE – System Design ..................................................................................................... 17
5.1 Introduction ......................................................................................................................... 17
5.2 Architectural Design............................................................................................................. 17
5.2.1 The Login Component ....................................................................................................... 17
5.2.2 The Registration Component ............................................................................................ 18
5.2.2.1 Client Registration......................................................... Error! Bookmark not defined.
5.2.2.3 Student’s Room Booking ............................................................................................ 18
5.3 General Flowchart of the system ............................................ Error! Bookmark not defined.
5.4 Database Design................................................................................................................... 20
Admin table ............................................................................................................................ 20
Registered Student ................................................................................................................ 20
5.4 User interface Design ........................................................................................................... 21
5.4.1 Login User interface ...................................................................................................... 21
5.4.2 Registration User interface ........................................................................................... 22
5.4.4 Registration User interface 2 ............................................................................................ 23
5.4.7 Student Portal .............................................................................................................. 23
5.4.8 Admin Portal ................................................................................................................. 24
CHAPTER SIX – Implementation and Testing ............................................................................. 25
6.1 Introduction .......................................................................................................................... 25
6.2 Development environment ................................................................................................... 25
6.3 System Components............................................................................................................. 25
a) Front-end ........................................................................................................................ 25
b) Back-end ........................................................................................................................ 25
c) Users .............................................................................................................................. 25
6.4 Test Plan ............................................................................................................................... 26
6.5 Test Data .............................................................................................................................. 26
6.6 Test Cases............................................................................................................................. 27

Page vi of 40
 6.7 Test Result............................................................................................................................ 27
CHAPTER SEVEN – Conclusion ....................................................................................................... 28
7.1 Achievements and lessons learnt ........................................................................................ 28
7.3 Recommendations ............................................................................................................... 29
REFFERENCES ................................................................................................................................. 30
Appendix 1 ..................................................................................................................................... 31
Project Timeline ............................................................................................................................. 31
Appendix 2 ..................................................................................................................................... 31
Project Budget ............................................................................................................................... 31

Page vii of 40
List of Figures
Figure 1 Incremental Model.............................................................. Error! Bookmark not defined.
Figure 2 Current System Flowchart .................................................. Error! Bookmark not defined.
Figure 3 Login Component ............................................................................................................. 18
Figure 4 Registration Component ..................................................... Error! Bookmark not defined.
Figure 6 Student Room Booking ...................................................... Error! Bookmark not defined.
Figure 7 Proposed system Flowchart ................................................ Error! Bookmark not defined.
Figure 8 Admin ............................................................................................................................... 20
Figure 9 Student ............................................................................................................................. 20
Figure 11 Login UI .......................................................................................................................... 21
Figure 12 Registration UI ............................................................................................................... 22
Figure 13 Registration UI 2 ............................................................................................................ 23
Figure 16 Student Portal ................................................................................................................ 23
Figure 17 Admin Portal .................................................................................................................. 24

Page viii of 40
CHAPTER ONE - Introduction
1.1 Background of Study
The online library management system is web-based software to provide students with
access to the library more efficiently. This project also keeps details of the student’s book
borrowing and classes. It is headed by the Librarian. He\ She will be the administrator.
For Management of books borrowed by students automatically and penalties to every
student with lost or late returns of books. This document is intended to minimize human
works and student access to records on book borrowing and access an easier job for
students and librarian.

 online access of Book details

 Automatically update the library database on books available
 total number of books borrowed
 Student log in.
 Allocate penaties to book lost or late returns.
 Automatically block inactive students from accesing the system.

Students will get to view;

 Check books borrowed.

 Check return dates of books.
 Check penaties to be paid.

Page 1 of 40
1.2 Problem Statement
The main problem that was observed was that the information generated from the current
existing library system (the manual system is not that accurate and clears for both the
Students and the library management. The proponent also observed that the Librarian
took a hard time retrieving the needed information about student’s forms and student
access to reading r in the problem process in reservation of events, retrieving and
restoring data, human error and hard manual process. Also cited is the problem of putting
a data to the record book the librarian can possibly write wrong details and misspelled
words and difficulty for the librarian in making new forms for issued books and lack of
security for the files.

1. Data Redundancy occurs. The Customer Relationship Officer does not check if the
customer record already exist.

2. Details are not complete and clarified. Some customers do not fill out the
reservation form.

Page 2 of 40
1.3 Aim of the Study
The literature on and implementation of online Library management system problem is
scattered, vast and far-fetched. The aim of this work is to generate a booking system
while demonstrating the possibility of building the lists automatically through the use of
computers in a way that they are optimal and complete with little or no redundancy. The
objectives of this work are as follows:

 Maintain the students as hostellers and waiting list students separately

 Process Students list.
 Admin can send reminder notification to every student on late book returns via
email.
 Automatically insert student’s details to the library’s database when the student is
confirmed by the admin.
 Students can check there books.
 Admin can edit notice board and each student can view it.
1.3.1 Research Questions
Topic: online libray management system
Thesis: Educational institutions adopt online library management system.
Research Questions:
1. How does online library management system reduce paperwork and save time?
2. How does online library management system help real-time status tracking of
library attendance?
3. What makes the online library management system provide accurate records?

1.4 Significance of the study

The reasons for this work are outlined below

i. The proposed system will provide an attractive graphical front-end for the
administrators and students (mobile platform).
ii. It will improve flexibility in Library services to students.
iii. The system will save time.
iv. Productivity will be improved.
v. The system can be revised i.e. its backend can be revised.
vi. Proper recording of Categories available, number of student registered, number
of books available.
vii. Efficient execution of academic activities.

Page 3 of 40
1.5 Scope of the study
This study will only cover the management and allocation of books for students in the
institution Library, Zetech University.

1.6 Limitations
The researcher outlined some of the limitations as follows

 More human power

 More strength and strain of manual labor needed
 Repetition of same procedure.
 Low security.
 Data redundancy.
 Difficulty to handle.
 Difficulty to update data.
 Record keeping is difficult.
 Backup data can be easily generated.

1.6 Assumptions
For the Online Library Management System to efficiently work there are some crucial
assumptions were made. They include: -
 System users must have access to internet
 User should at least own a Smartphone or a Computer or any device with access to
the internet.

Page 4 of 40
CHAPTER TWO – Literature Review
2.1 Introduction
In this section we are going to analyze the existing system and provide solution to errors
or build a new system all together

2.2 Existing Systems

The existing system is manual based and need lot of efforts and consume enough time. In
the existing system Books are posted on a database but the filling processes are done
manually. It may lead to corruptions in the filling process and book lost payments.

2.2.1 Disadvantages:
 More human power
 More strength and strain of manual labour needed
 Repetition of same procedure.
 Low security.
 Data redundancy.
 Difficulty to handle.
 Difficulty to update data.
 Record keeping is difficult.
 Backup data can be easily generated.

Page 5 of 40
2.3 Proposed Solution
This project is aimed at developing a system for keeping records and showing information about
student library interaction. This system will help the librarian to be able to manage the affairs of
student book access and return policies. This system will provide full information about a
student in the class. It will show results available on books borrowed and returned or not and
number of students with declared as of the registered with the library sytem

Page 6 of 40
CHAPTER THREE – Methodology
3.1 Introduction
Methodology may be defined as a collection of procedures, techniques, tools and
documentation aids that will help in the developing of an online student result system. It
includes a model, which embodies methods, tools, techniques and documentation. It also
includes a feasibility study and requirements Specification which outlines the functional
and the non-functional requirements of the system.

 In the case of the student result management system I will be using object
oriented modelling (OOAD) to propose the methodology for developing this
project.

Reasons of using the OOAD model:

 The OOAD model has improved Reliability and Flexibility

 It is easy to Understand
 Reduced maintenance
 Better Efficiency compared to other models

This methodology is developed with 3 phases:

Object-oriented analysis

 In the analysis stage, the problem is formulated, user requirements are identified
then a model is built based upon real world objects. The analysis produces models
on how the system should function and how it will be developed.

Object-oriented design

 Design includes two main stages namely, system design and object design.
System design:
In this stage the complete architecture of the desired system is designed. The
system is termed as a set of interacting subsystems that is composed of a
hierarchy of interacting objects grouped into classes. System design is done
Page 7 of 40
 according to both the system analysis model and the proposed system
architecture where the emphasis is on the objects comprising the system.

Object design:
In this phase, a design is developed based on both the models developed based
on both the system analysis phase and the architecture designed in the design
phase. The classes required will be identified, the designer will have to decide
whether:
 New classes are to be created,
 Any existing classes can be used in their original form or
 New classes should be inherited from the existing classes.
 The associations between the identified classes are established and the
hierarchies of classes are identified. The designing of the data structure for each
attribute and the algorithms for the operations is done at this point.

Object-oriented Implementation

 In the implementation stage the design model developed is translated in to code

in a programming language or software tool. The databases are created and the
specific hardware requirements are ascertained. The code is then tested using
specialized techniques to identify and remove errors in the code.

3.2 Feasibility
Feasibility study aims to objectively and rationally uncover the strengths and
weaknesses of the proposed student result project, opportunities and threats
present in the environment, the resources required to carry through, and
ultimately the prospects for success. It determines whether the project is worth
the investment.

Page 8 of 40
3.2.1 Technical Feasibility
The technical feasibility in the proposed system deals with the technology used in
the system. It deals with the hardware and software used in the system whether
they are of latest technology or not and if it happens that after a system is
prepared, a new technology arises and the user wants the system based on that
technology. This system use windows platform, apache server, sql for database,
php as the language and html or xml as user interface. Thus ONLINE LIBRARY
MANAGEMENT SYSTEM is technically feasible.

3.2.2 Economic Feasibility

Economic analysis is the most frequently used method for evaluating the
effectiveness of a new system. More commonly known as cost/benefit analysis.
Php, html, xml and sql database are easily available on internet.

3.2.3 Operation Feasibility

The project has been developed in such a way that it becomes very easy even for
a person with little computer knowledge to operate it. This software is very user
friendly and does not require any technical person to operate .Thus the project is
even operationally feasible.

3.3 Requirement Specification

Here, information related to the potential system is gathered from the hostel
management levels and students. After examining the current systems and manual way
of processing payment and the allocation of services, both functional and non-functional
requirements that would make the new system address the problems of the previous
systems are considered.

 The system is focused into 2 ways:

3.3.1 Functional Requirements

 The function of the potential system or its component is defined. The function will
be described as a set of inputs, the behavior, and outputs.
 The system is expected to perform the following basic functions:
Page 9 of 40
  The system should be able to accept creation of new accounts for students.
 The system should be able to capture the new user’s details and get enrolled on
the systems
 Process student’s Id and and give access to his/her portal.
 Efficient storage and retrieval of user’s particulars, in a safe database which will
restrict unauthorized persons from gaining access to the system by use of
password and username.

3.3.2 Non-functional Requirements

 Here, the criteria that can be used to judge the operation of a system is specified,
rather than specific behaviors. They are constraints imposed on the functionality
of the system.
 The system should have the characteristics such as:
 The new system should be easy to maintain and upgrade.
 The system should offer adequate security as user’s information is very
confidential.
 The system should be easy to learn and use fast and efficient.
 The system should be simple to use with a user friendly interface and features that
are simple to use e.g. icons, command buttons.
 The system should be easy to extend to include features that will unfold in the
future.

3.4 Data Collection

 Data collection is the process of gathering and measuring information on
targeted variables in an established systematic fashion, which then enables one
to answer relevant questions and evaluate outcomes. The data collection
component of research is common to all fields of study
including physical and social sciences, humanities and business. While methods
vary by discipline, the emphasis on ensuring accurate and honest collection
remains the same. The goal for all data collection is to capture quality evidence

Page 10 of 40
 that then translates to rich data analysis and allows the building of a convincing
and credible answer to questions that have been posed.

3.4.1 Interview
 This is a direct face-to-face communication with the proposed user of the system
which will help get suggestions and recommendations that may help during the
design of student result system.
The interviews will help in:
 Acts as a fact-finding to gather facts about the existing system
 Verifying and clarifying facts gathered through other methods
 Getting the user involved in the development of the new system
3.5 Hardware Configurations
The section of hardware configuration is an important task related to the software
development. Insufficient random access memory may affect adversely on the speed and
efficiency of the entire system. The process should be powerful to handle the entire
operations. The hard disk should have sufficient capacity to store the file and application.
Processor: Pentium IV and above

Processor speed: 1.4 GHz Onwards

System memory: 128 MB minimum (256 MB recommended)

Cache size: 512 KB

RAM: 512 MB (Minimum)

Network card: Any card can provide a 100mbps speed

Network connection: UTP or Coaxial cable connection

Printer: Inkjet/Laser Color printer provides at least 1000 Dpi

Hard disk: 80 GB

Monitor: SVGA Color 15”

Page 11 of 40
Mouse: 104 keys US Key Serial, USB or PS/2

3.5 Software Configurations

A major element in building a system is the section of compatible software since the
software in the market is experiencing in geometric progression. Selected software
should be acceptable by the firm and one user as well as it should be feasible for the
system. This document gives a detailed description of the software requirement
specification. The study of requirement specification is focused specially on the
functioning of the system. It allow the developer or analyst to understand the system,
function to be carried out the performance level to be obtained and corresponding
interfaces to be established.

Technology Implemented: Apache Server

Language Used: PHP 5.3 or newer versions

Database: My SQL 5.5 or newer

User Interface: HTML, AJAX

Web Browser: Mozilla, Chrome or Internet Explorer 8(or newer)

Software: XAMPP or WAMP Server

Operating System: Windows XP or higher versions.

Page 12 of 40
CHAPTER FOUR – System Analysis
4.1 Introduction
In this process the primary object is to identify user requirements and to build a system that
satisfies these requirements. Design of the system is mainly the logical design that can be
sketch on a paper or on a computer. It includes physical design elements, describes the data
to be inputted. Model can be built for the existing system to better understand the proposed
system. Process modelling is technique which involves graphical representation of
functions or processes that capture, manipulates, stores or distribute data between a system
& its environment or among components with in a system. The process involved in
manipulation of data & output design represents: -

 File structure, storage devices etc.

 Database is also designed in this phase
 Changes to be made in the organizational structure of the institution are outlined
 Input, Output, files, forms and procedures are planned
 Finally, standards for testing, documentation, system control are designed

4.3 System Requirements

System requirements are all of the requirements at the system level that describe the
functions which the system as a whole should fulfill to satisfy the student needs and
requirements, and is expressed in an appropriate combination of textual statements, views,
and non-functional requirements; the latter expressing the levels of safety, security,
reliability, etc., that will be necessary. System requirements help a lot in coming up with a
good system as they: -

 Form the basis of system integration and verification activities

 Act as a reference for validation and customer acceptance.
 Form the basis of system architecture and design activities.
 Provides a means of communication between the various technical staff that interact
throughout the project.
System requirements gives a wider vision of what the system should look like and function.
They are expresses in technical language that is useful for architecture and design.
Page 13 of 40
4.3.1 Functional Requirements
Functional requirements explain what has to be done by identifying the necessary task,
action or activity that must be accomplished. Functional requirements analysis will be used
as the top-level functions for functional analysis. The requirements qualitatively describe
the system functions or tasks to be performed in operation. The Online Library System has
various Functional requirements. They include: -

4.3.1.1 The Student’s Functional requirements

 Login
Students must login in order to view the books borrowed and access their services i.e check
on penalties and late return dates. Only registered Students will be able to login.
Unregistered users will be shown an error message asking them to register first. After
successful login a session is opened with all the student’s details and he or she can view
his/her library interaction status.

 View Profile and Book Return dates.

While in the portal, student can explore various options and one of them is viewing his
Book borrowing history. Penalties owed by the library. In case the student has interest in
keeping the record. He clicks on the download.

 Update Profile
The user after a successful ligin he/she can update the details about him/her self from the
portal.

 User Logout
After using the system, student can be able to logout successfully and other user’s login
again and use the system. When logging out the session is terminated and the website
redirects to the sign in page.

4.3.1.2 The admin’s functional requirements

 Registration and Login

Page 14 of 40
This process is similar to student’s registration. The only difference is the types of account
and privilege’s available. The admin can register a student account from his/her account,
he can also stop a student from accessing his/her portal by blocking him.

 Manage Students
The administrator should be able to manage users that is, can add new student, view
existing students and even deleting the registered students. The admin can view full profile
of the students and edit their details.

 Manage Book Authors

Apart from being able to manage Students the administrator should also be able to manage
the books authors by adding a book author or managing an existing one.

 Manage Book Categories

Apart from being able to manage Students the administrator should also be able to manage
the categories of books available by adding a category or managing an existing one.

 Manage Books
Apart from being able to manage Students and categories the administrator should also be
able to manage the books by adding a book title or managing an existing one.

4.3.2 Non-Functional Requirements

Non-functional requirements are requirements that specify criteria that can be used to judge
the operation of a system, rather than specific behaviors. They include: -

 Reliability
The system should be able to handle all what it’s meant to do at any given time. This
includes 24/7 uptime of the system which will enable users to access their portals any day
any time.

 Security

Page 15 of 40
Security is everything in online systems. The system should be able to distinguish between
Students and admin. Also, the system should be able to make sure that login users have
registered on the system first before allowing them to their respective portals

 Maintainability
Once the system is fully operational, the administrators should be able to handle any errors
arising at a given time. Changes should be made without affecting the systems
functionality.

 Portability
The system should be able to run on all platforms. This includes all browsers and all devices
(smartphones, tablets, laptops, smart TVs etc.)

Page 16 of 40
CHAPTER FIVE – System Design
5.1 Introduction
In this process the primary object is to identify user requirements of the system and to build
a system that satisfies these requirements. Design of the system is mainly the logical design
that can be sketch on a paper or on a computer. It includes physical design elements,
describes the data to be inputted.
For the Online Library Management System, several design tools are used and they
represent various operations within the system.
The process involved in manipulation of system design represents: -
 File structure, storage devices etc.
 Database is also designed in this phase
 Changes to be made in the organizational structure of the firm are outlines
 Input, Output, files, forms and procedures are planned
 Finally, standards for testing, documentation, system control are designed.

5.2 Architectural Design

The architectural design involves description of the design environment and system
components. This system incorporates several components together leads to the success of
the system operations. To give a detailed information of these operations Unified
Modelling Language is used. Components of this system include: -

5.2.1 The Login Component

Below is a diagram showing the login process within the system. This applies to all types
of users within the system. That is the admin, and students. The login process involves
several steps which are conducted sequentially. First the user has to have access to the
internet and a web browser which can be on any device. When on the website the users
should click on their respective logins: student login or admin login.
A login form will pop up prompting them to fill in their details and password. This data is
then sent to the server and the server transfers the data from the form to the database for
checking. While in the database the system checks if the data provided is available. If data
Page 17 of 40
is found, the database returns a success message to the server. The server then opens a new
session and then redirects the user to his or her respective portal. The portal will have
several options depending on the type of user.
Still on the database, when user information does not match or does not exist, and error
message is sent back to the systems server and the user prompted to fill in valid data or
register.

Figure 1 Login Component

5.2.2 The Registration Component
Registration is the only component within the system which allows addition of new users.
Students who wish to use the system services have to first be registered then be able to
login.

5.2.2.3 Student’s Profile

After a successful login the student is directed to a portal. In this portal the student can
view books borrowed and deadlines to return books borrowed and also view penalties on
late book returns.

Page 18 of 40
5.1 Functions of the System
After a successful login, users can access the database and perform various functions
depending on the account type.

Admins can do the following Functions: -

Admin Functions
Add Categories
Add Authors
Add Books
Issue Books
Block Inactive Students
Unblock Students
View all Reports
Students can handle the following functions: -

Students Functions
View Profile
View Books issued
Check Deadlines to return books borrowed
View Books not returned yet.

Page 19 of 40
5.4 Database Design
For permanent storage the server uses MySQL. The database design is illustrated below.
This diagram represents the data entities stored in the database and the relation between
them.

Admin table

Figure 2 Admin
Registered Student

Figure 3 Client

Page 20 of 40
5.4 User interface Design
A User Interface is a combination of menus, screen design, keyboard commands and
language which together create the way a user interacts with the system. It determines how
user interacts with system. The hardware part of user interface consists of monitor,
keyboard and mouse. The software part of interface determines what things look like on
the screen and how user gives commands to get work done.

5.4.1 Login Admin interface

Figure 4 Admin Login UI

Page 21 of 40
5.4.2 Registration User interface

Figure 5 Registration UI

Page 22 of 40
5.4.4 User Login Interface

Figure 6 User Login UI

5.4.7 Student Dashboard

Figure 7 student dashboard

Page 23 of 40
5.4.8 Admin Dashboard

Figure 8 Admin Dashboard

Page 24 of 40
CHAPTER SIX – Implementation and Testing
6.1 Introduction
In this chapter implementation and testing of the project is described.

6.2 Development environment

PHP -This is because it can work in all operating system platforms; it is open source and supports
a variety of database management systems.

JavaScript-This is because it supports creation of ambient user interfaces and allows for easy
validations of data items.

CSS-This is because it allows for the creation of appealing user interfaces, is free and easy to use.

Bootstrap framework- This is because the front-end framework of bootstrap classes helps to view
the applications well in all screen sizes of the devices used.

HTML-This is because it is supported by all browsers and it is free

6.3 System Components

The system consists of four major components the front end, backend of the website, users
and the payment system.

a) Front-end
This is the part of the system that the users interact with. It’s made in such a way that it’s
so easy to use by every person in the website. The Frontend is mainly coded with html,
JavaScript, CSS and Bootstrap.

b) Back-end
This is Core system functioning behind the front-end. The backend uses php and JavaScript
to acquire information from the database. The database used is MySQL database.

The following is a list of all package dependencies used in the backend of the system.

c) Users
This are the people interacting the website. They Login and view companies being
advertised.

Page 25 of 40
6.4 Test Plan
Verified that the system works and meets all of the business requirements defined in the
analysis phase. Test conditions were taken among the following types of tests:

• Unit testing – tests individual units of code

• System testing – verifies that the units of code function correctly when integrated
• Integration testing – verifies that separate systems work together
• User acceptance testing (UAT) – determines if the system satisfies the business
requirements
This test plan describes the testing approach and overall framework that will drive the
testing of the Smart Disposal System. It includes test data, test cases and test results.

High Level Test Objectives

 To ensure that the [work product] satisfies all project requirements.

 To ensure that all components of the [work product] function according to design.
 To ensure that all use case scenarios can be executed successfully.
 To ensure that the [work product] can perform under the anticipated user load.
 To determine if the application is intuitive and easy to use, and if it
presents the users with the intended user experience

6.5 Test Data

The following needs to be set up:

Environment
URL
Access Instructions
User ID/password

Page 26 of 40
6.6 Test Cases
Unit Testing

Unit tests were used to ensure that a given function works.

i. Has the test data required for the particular test been identified?
ii. Does the unit testing validate the data at the field level?
iii. Have any preconditions been setup?
iv. Have step-by-step test instructions (including sample input data) been
set up?
v. Has the process for how original data will be recovered before and after
test execution been described?

6.7 Test Result

i. Has the test data required for the particular test been identified? Confirmed
ii. Does the unit testing validate the data at the field level? Confirmed
iii. Have any preconditions been setup? Confirmed
iv. Has the process for how original data will be recovered before and after test execution
been described? Confirmed

Page 27 of 40
CHAPTER SEVEN – Conclusion
7.1 Achievements and lessons learnt
Some of the lessons learnt in this project include: -

i. System design should consider the system implementation process, tools and
scope environment
ii. Database design should be done with care and rules are enforced to ensure data
integrity and consistency.
iii. System scope should be well defined and understood by the developer.
iv. User interface design should be done in accordance to the system requirement
specification and should be friendly to both user types.
v. Project management is key to its success.
vi. Use of JavaScript helps in fetching of data from the Database easily
vii. System design helps to determine future requirements.
viii. Taking advantage of changing technologies is key to success in the
development phase.
ix. It’s necessary that the testing phase must be completed.
x. A best suited implementation method should be adopted so that the normal
business activities are not interrupted.
xi. The key to success in maintenance phase is that all knowledge workers and IT
specialists work together.

Page 28 of 40
7.3 Recommendations
For growth and improvement in the future, my following suggestion would help in
improvement of the system: -

i. Standard secure APIs for payments be adopted for secure payments.

ii. Companies should have business numbers so as to ensure proper integration
with the system
iii. To manage growing population, the following should be done:
 Increase server space and bandwidth.
 To manage scalability, the system can be re-written in a more scalable language
like Python. This is because php isn’t desirably scalable.

Page 29 of 40
REFFERENCES
For the development and drafting of Online Hostel Management System the following
were used :-

J. R. Groff and P. N Weinberg. Complete Reference SQL Second Edition.

K. Ayanlowo, O. Shoewu, S. O. Olatinwo, O. O. Ommitola and D. D. Babalola (2014).

Journal of Science and Engineering Vol 5(1): Development of an Automated Hostel

Facility

Management System Retrieved from www.oricpub.com

K.A. Muhammed Shaheer, A. Muhammed Shiras, R. Vinod Raj, G.V Prashobh (2009).

Project Report on Hostel Management System.

R. Radhakrishhan, P.A Rinsha, R Roopersree (2014). Online Hostel Management System:

Mini Project.

Html and Php from W3 schools. http//w3school.com

en.wikipedia.org/wiki/PHP

www.mysql.com

www.hotscripts.com/category/php/

College Hostel Management Software by Initio (2010).

Loventis Booking System by Loventis Systems (2005).

Indocon Hostel Management Software by Indocon Micro Engineers Limited.

http://www.kassoftindia.com/Product/GeniusAcademic/hostelmgt.htm [accessed
September

24, 2012]

Page 30 of 40
Appendix 1

Project Timeline
This is the amount of time it took to complete the project. The project was carried
out within 12 weeks

Appendix 2

Project Budget
This is the total cost incurred directly or indirectly during the development of the project.
The following table shows the estimated project cost in Kenyan shillings that was incurred
while developing the system.

Item Cost
Internet services for research 4,000/-
Additional JS Scripts and IDEs 2,000/-
Decent PC for the development. 40,000/-
Totals 46,000/-

Page 31 of 40