Online Dormitory Reservation System PDF
Online Dormitory Reservation System PDF
Online Dormitory Reservation System PDF
Fall 2015
Ramya Vakity
Governors State University
Recommended Citation
Mothe, Adithya; Suragoni, Koushik Kumar; and Vakity, Ramya, "Online Dormitory Reservation System" (2015). All Capstone Projects.
152.
http://opus.govst.edu/capstones/152
For more information about the academic degree, extended learning, and certificate programs of Governors State University, go to
http://www.govst.edu/Academics/Degree_Programs_and_Certifications/
i
1 PROJECT DESCRIPTION
1.1 Project Abstract
This project is Online Dorms Systems which allows users to book their room in the dorm from anywhere;
this is an automated system where the user can search the availability of rooms in the dorm.
The search can be done based on the dates. The rooms that available are come with the status available, it
will display all the rooms available as of that particular search date. Once the room has been booked the user can
cancel the reservation within 48 hours. And there is concept of user login. As the user creates his own account with
his email id, he can login into his account.
There is an administrator login page for administrator, who has the control over the dorms system
application. He can also review the business profit and growth. The proposed system reduces a lot effort for student
and the administrator of the dorms as well.
The objective of this application is to develop an online dorm system for Improving Software Quality and
Reliability is useful for applications developed in an organization. This system can be used for reduce problems of
student against an application/module, assigning dorms to individuals and solving problems of student.
1
the bed Main problem of the existing system is the only paper based work and everything has to do it physically and
they should pass the documents by hand to hand from starting and there is no concept of the information reusability.
As I discussed earlier in this chapter about the existing system which is using in the university takes a lot of
time to start each on each applicant request to allot the rooms. Mainly it consuming a lot of time because of only
thing is paper based work and whenever the applicant visits second it would be like waste of time for both the
applicant and the administrator as well.
Mainly in this paper based work we dont have any kind of storage system to access the information of the
applicant whenever the administrator wants. Here, if any applicants documents missed in the administrators office
unfortunately then the applicant have come again and do all the application process again. In this case the dorms
management may lose the faith and credibility among their customers. So, this makes me to generate a system which
can store a lot of data and can be able to access in future time, by doing this I can solve the problems like lack of
information reusability and work effort in case of the lost application.
When security comes into picture it makes a lot of difference to the current system because its only the
paper based work so we cant provide any kind of security to the existing system. Some of the applicants may do not
want their information like phone number and address go publicly this. At this time, may some other people in the
admission room can see the information about the applicant. But, when I got the thought of creating an online
automated system myself took a lot security problem in order to provide to the proposed system.
As there is no online system so the applicant has to pay the bill at the administrators office only. In the
proposed system there should be a mechanism in which the applicant can pay the bill online.
Need of the System:
The system itself tells that it is the online method of traditional dorm reservation system, by developing this
system there would not any functional changes but there will be increase in performance and functionality. Sending
the applicants information through online gives the solution to some of the problems that are encountered with the
existing system. In this project, the security aspects are evaluated.
By using the proposed system we can achieve the following benefits:
User can enjoy the cool and comfort User Interface.
The applicant does not have to come to the administrators office to make a reservation, so that the effort
for the applicant can be reduced.
There will be an account for each and every user which validates them based on their Email address. So
that the applicant does not have to give their information as many times as they visit.
The information reusability has achieved.
The user data can be stored in a database.
The administrator will have an account through which he can login and know the business statistics like
revenue and profit.
2
The challenges that have faced initially when I thought of the proposed system are:
Have to provide a feel good and user friendly User Interface so that the applicant feel comfort than that of
the existing system.
Have to provide a system, in which the applicants information can be used in the future, i.e. the applicant has to
have a profile or account with his information in it.
Have to provide a secure pay method as my system deal with the money payment.
Have to design a data storage system that stores as many applicants details as possible.
Have to provide a safe and secure money payment method. In case he cancels the reservation the system
has to provide the applicant with a money back option.
We can provide a full- fledged user account and we can also give notifications for that account. We can
also add events to the system that will let us know if anything going to happen in the dorms. Also based on this web
2 Technical Description
As discussed earlier, there are certain problems with the current dorm management system in the
university. Sometimes the application may be lost completely without even knowing to the administrator and the
people who are participating in the application due to the negligence of the either the administrator or the people
working under the administrator. And there is no security for the user or applicants information. These are the
factors to motivate me to develop this project. Determination of whether the Dorms management is worth doing or
not is done in this section. Finally I found the result positive.
3
2.1 Project / Application Architecture:
The project has been developed in Model-2 architecture. Model 2 is a complex design pattern used in the
design of Java Web applications which separates the display of content from the logic used to obtain and manipulate
the content. Since Model 2 drives a separation between logic and display, it is usually associated with the model
viewcontroller (MVC) paradigm. While the exact form of the MVC "Model" was never specified by the Model 2
design, a number of publications recommend a formalized layer to contain MVC Model code. The Java Blue Prints,
for example, originally recommended using EJBs to encapsulate the MVC Model.
In a Model 2 application, requests from the client browser are passed to the controller. The controller
performs any logic necessary to obtain the correct content for display. It then places the content in the request
(commonly in the form of a JavaBean or POJO) and decides which view it will pass the request to. The view then
renders the content passed by the controller. Model 2 is recommended for medium- and large-sized applications.
The following figure shows a typical Model2 architecture. In which a database and a web browser can
communicate using MVC (Model-View-Control)
4
"model 1" due to its ordering in the document) was a simplistic model whereby JSP pages were standalone,
disjointed entities. Logic could be contained within the page itself, and navigation between pages was typically
achieved by way of hyperlinks. This fit with the then-common usage of template technology. ColdFusion and Active
Server Pages are examples of contemporary technologies that also implemented this model.
The second model referred to by the document ("model 2" in the ordering) was an improved method that
combined servlet technology with JSP technology. The specific difference listed was that a servlet would intercept
the request, place the content to render into a request attribute (typically represented by a JavaBean), then call a JSP
to render the content in the desired output format. This model differed from the previous model in the fact that JSP
technology was used as a pure template engine. All of the logic was separated out into a servlet, leaving the JSP with
the sole responsibility of rendering the output for the content provided.
In March 2000, the Apache Struts project was released. This project formalized the division between View and
Controller and claimed implementation of the "Model 2" pattern. Once again, the implementation of the "Model"
was left undefined with the expectation that software developers would fill in an appropriate solution. Database
interaction via JDBC and EJBs were options suggested on the Struts homepage. More recently, Hibernate, iBati
and Object Relational Bridge were listed as more modern options that could be used for a model.
Since the release of Struts, a number of competing frameworks have appeared. Many of these frameworks also claim
to implement "Model 2" and "MVC". In result, the two terms have become synonymous in the minds of developers.
This has led to the use of the term "MVC Model 2" or "MVC2" for short.
Stages in SDLC:
5
Requirement Gathering
Analysis
Designing
Coding
Testing
Maintenance
Requirements Gathering stage:
The requirements gathering process takes as its input the goals identified in the high-level requirements
section of the project plan. Each goal will be refined into a set of one or more requirements. These requirements
define the major functions of the intended application, define
Operational data areas and reference data areas, and define the initial data entities. Major functions include critical
processes to be managed, as well as mission critical inputs, outputs and reports. A user class hierarchy is developed
and associated with these major functions, data areas, and data entities. Each of these definitions is termed a
Requirement. Requirements are identified by unique requirement identifiers and, at minimum, contain a requirement
title and textual description.
These requirements are fully described in the primary deliverables for this stage: the Requirements
Document and the Requirements Traceability Matrix (RTM). The requirements document contains complete
descriptions of each requirement, including diagrams and references to external documents as necessary. Note that
detailed listings of database tables and fields are not included in the requirements document.
6
The title of each requirement is also placed into the first version of the RTM, along with the title of each goal
from the project plan. The purpose of the RTM is to show that the product components developed during each stage
of the software development lifecycle are formally connected to the components developed in prior stages.
In the requirements stage, the RTM consists of a list of high-level requirements, or goals, by title, with a
listing of associated requirements for each goal, listed by requirement title. In this hierarchical listing, the RTM
shows that each requirement developed during this stage is formally linked to a specific product goal. In this format,
each requirement can be traced to a specific product goal, hence the term requirements traceability.
The outputs of the requirements definition stage include the requirements document, the RTM, and an
updated project plan.
Feasibility study is all about identification of problems in a project.
No. of staff required to handle a project is represented as Team Formation, in this case only modules are
individual tasks will be assigned to employees who are working for that project.
Project Specifications are all about representing of various possible inputs submitting to the server and
corresponding outputs along with reports maintained by administrator
Analysis Stage:
The planning stage establishes a bird's eye view of the intended software product, and uses this to establish
the basic project structure, evaluate feasibility and risks associated with the project, and describe appropriate
management and technical approaches.
The most critical section of the project plan is a listing of high-level product requirements, also referred to as
goals. All of the software product requirements to be developed during the requirements definition stage flow from
one or more of these goals. The minimum information for each goal consists of a title and textual description,
although additional information and references to external documents may be included. The outputs of the project
planning stage are the configuration management plan, the quality assurance plan, and the project plan and schedule,
with a detailed listing of scheduled activities for the upcoming Requirements stage, and high level estimates of effort
for the out stages.
7
Designing Stage:
The design stage takes as its initial input the requirements identified in the approved requirements document.
For each requirement, a set of one or more design elements will be produced as a result of interviews, workshops,
and/or prototype efforts. Design elements describe the desired software features in detail, and generally include
functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo
code, and a complete entity-relationship diagram with a full data dictionary. These design elements are intended to
describe the software in sufficient detail that skilled programmers may develop the software with minimal additional
input.
When the design document is finalized and accepted, the RTM is updated to show that each design element is
formally associated with a specific requirement. The outputs of the design stage are the design document, an updated
RTM, and an updated project plan.
8
The RTM will be updated to show that each developed artifact is linked to a specific design element, and that
each developed artifact has one or more corresponding test case items. At this point, the RTM is in its final
configuration. The outputs of the development stage include a fully functional set of software that satisfies the
requirements and design elements previously documented, an online help system that describes the operation of the
software, an implementation map that identifies the primary code entry points for all major system functions, a test
plan that describes the test cases to be used to validate the correctness and completeness of the software, an updated
RTM, and an updated project plan.
9
The outputs of the integration and test stage include an integrated set of software, an online help system, an
implementation map, a production initiation plan that describes reference data and production users, an acceptance
plan which contains the final suite of test cases, and an updated project plan.
Installation & Acceptance Test:
During the installation and acceptance stage, the software artifacts, online help, and initial production data are
loaded onto the production server. At this point, all test cases are run to verify the correctness and completeness of
the software. Successful execution of the test suite is a prerequisite to acceptance of the software by the customer.
After customer personnel have verified that the initial production data load is correct and the test suite has
been executed with satisfactory results, the customer formally accepts the delivery of the software.
10
The primary outputs of the installation and acceptance stage include a production application, a completed
acceptance test suite, and a memorandum of customer acceptance of the software. Finally, the PDR enters the last of
the actual labor data into the project schedule and locks the project as a permanent project record. At this point the
PDR "locks" the project by archiving all software items, the implementation map, the source code, and the
documentation for future reference.
Maintenance:
Outer rectangle represents maintenance of a project, Maintenance team will start with requirement study,
understanding of documentation later employees will be assigned work and they will undergo training on that
particular assigned category.
For this life cycle there is no end, it will be continued so on like an umbrella (no ending point to umbrella
sticks)
11
2.2. Project/ Application Information flow:
Below architecture diagram represents mainly flow of requests from users to database through servers. In this
scenario overall system is designed in three tires separately using three layers called presentation layer, business
logic layer and data link layer. This project was developed using 3-tier architecture.
User
SERVER
Request Response
Data
Base
12
2.3 Interaction with other Projects
In addition to dividing the application into three kinds of components, the Modelviewcontroller (MVC) design
defines the interactions between them.
A controller can send commands to the model to update the model's state (e.g., editing a document). It can also
send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through
a document).
A model notifies its associated views and controllers when there has been a change in its state. This notification
allows the views to produce updated output, and the controllers to change the available set of commands.
A passive implementation of MVC omits these notifications, because the application does not require them or the
software platform does not support them.
Project group takes part in risk assessment gatherings and individuals serve as meeting recorder and timekeeper Key
partners partake in danger evaluation gatherings Project Sponsor may take part in danger appraisal gatherings.
13
3. REQUIREMENT SPECIFICATIONS
3.1 Identification of Requirements
The first phase of the project is the requirement specification. We have divided this phase into 3 modules.
The 3 modules in the project are,
UI Creation and Database Design
User Module
Admin Module
14
3.3 Security and Fraud Prevention:
Security is the main thing that we need to take care of. In our project, we are using a secure gateway for the
payment. It will automatically connects to the concerned bank and the payment process will continue. For the
security we are using this secured gateway for the payment. The same thing will be applied to the fraud prevention.
We are using the security measures for the frauds to not to interrupt the payment process.
System Security:
Setting Up Authentication for Web Applications
Introduction:
To configure authentication for a Web Application, use the <login-config> element of the web.xml
deployment descriptor. In this element you define the security realm containing the user credentials, the method of
authentication, and the location of resources for authentication.
Security in Software
To set up authentication for Web Applications:
1. Open the web.xml deployment descriptor in a text editor or use the Administration Console. Specify the
authentication method using the <auth-method> element. The available options are:
BASIC
Basic authentication uses the Web Browser to display a username/password dialog box. This username and
password is authenticated against the realm.
FORM
Form-based authentication requires that you return an HTML form containing the username and password.
The fields returned from the form elements must be: j_username and j_password, and the action attribute must be
j_security_check. Here is an example of the HTML coding for using FORM authentication:
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
</form>
The resource used to generate the HTML form may be an HTML page, a JSP, or a servlet. You define this
resource with the <form-login-page> element.
15
Database : mysql
IDE : Eclipse juno
JDK Version : JDK1.7
Server : Tomcat5.5
Hardware Requirements:
Processor : Pentium
RAM : 1GB
HTML is not a programming language but it is an application of ISO Standard 8879, SGML (Standard
Generalized Markup Language),but Specialized to hypertext and adapted to the Web. We can navigate through
the information based on out interest and preference. A markup language is simply a series of items enclosed
within the elements should be displayed.
Hyperlinks are underlined or emphasized works that load to other documents or some portions of the
same document.Html can be used to display any type of document on the host computer, which can be
geographically at a different location. It is a versatile language and can be used on any platform or desktop
HTML provides tags (special codes) to make the document look attractive.
HTML provides are not case-sensitive. Using graphics, fonts, different sizes, color, etc., can enhance the
presentation of the document. Anything that is not a tag is part of the document itself.
Basic Html Tags:
<! -- --> Specific Comments.
<A>.</A> Creates Hypertext links.
<B>.</B> Creates hypertext links.
<Big>...</Big> Formats text in large-font
<Body>.</Body> Contains all tags and text in the Html-document
<Center>...</Center> Creates Text
<DD>.</DD> Definition of a term.
<TABLE>.</TABLE> Creates table
<Td>..</Td> indicates table data in a table.
<Tr>..</Tr> designates a table row
<Th>..</Th> creates a heading in a table.
Advantages:
o A HTML document is small and hence easy to send over the net. It is small because it does not
include formatted information.
o HTML is platform independent
16
o HTML tags are not case-sensitive
Java Script
JavaScript is a compact, object-based scripting language for developing client and server internet
applications. Netscape Navigator 2.0 interprets JavaScript statements embedded directly in an HTML page. And
Livewire enables you to create server-based applications similar to common gateway interface (cgi) programs.
In a client application for Navigator, JavaScript statements embedded in an HTML Page can recognize and
respond to user events such as mouse clicks form Input, and page navigation.
For example, you can write a JavaScript function to verify that users enter valid information into a form
requesting a telephone number or zip code. Without any network transmission, an Html page with embedded Java
Script can interpret the entered text and alert the user with a message dialog if the input is invalid or you can use
JavaScript to perform an action (such as play an audio file, execute an applet, or communicate with a plug-in) in
response to the user opening or exiting a page.
We have used Java and JSP pages for the front end and MYSQL for the backend. Java uses integration
methods to create the application and MYSQL has the secure system that will store the data automatically as we
have used the Model 2 architecture.
Online Dormitory Reservation System, provides some advance methods for the users. We have taken some
specific input and output measures in the design of the document to provide a user friendly and reliable reservation
system.
To provide flexibility to the users, the interfaces have been developed that are accessible through a browser. The
GUIS at the top level have been categorized as
The administrative user interface concentrates on the consistent information that is practically, part of the
organizational activities and which needs proper authentication for the data collection. These interfaces help the
administrators with all the transactional states like Data insertion, Data deletion and Date updating along with the extensive
data search capabilities.
The operational or generic user interface helps the end users of the system in transactions through the existing
data and required services. The operational user interface also helps the ordinary users in managing their own
information in a customized manner as per the included flexibilities
17
Input & Output Representation
Input design is a part of overall system design. The main objective during the input design is as given
below:
To produce a cost-effective method of input.
To achieve the highest possible level of accuracy.
To ensure that the input is acceptable and understood by the user.
Input Stages:
The main input stages can be listed as below:
recording
Data transcription
Data conversion
Data verification
Data control
Data transmission
Data validation
Data correction
Input Types:
It is necessary to determine the various types of inputs. Inputs can be categorized as follows:
External inputs, which are prime inputs for the system.
Internal inputs, which are user communications with the system.
Operational, which are computer departments communications to the system?
Interactive, which are inputs entered during a dialogue.
Input Media:
At this stage choice has to be made about the input media. To conclude about the input media
consideration has to be given to:
Flexibility of format
Type of input
Accuracy
Speed
Verification methods
Rejection rates
Ease of correction
Storage and handling requirements
Security
Easy to use
18
Portability
Keeping in view the above description of the input types and input media, it can be said that most of the inputs are
of the form of internal and interactive. As Input data is to be the directly keyed in by the user, the keyboard can be
considered to be the most suitable input device.
Output Design:
In general are:
External Outputs whose destination is outside the organization.
Internal Outputs whose destination is within organization and they are the Users main interface with
the computer. Outputs from computer systems are required primarily to communicate the results of
processing to users. They are also used to provide a permanent copy of the results for later
consultation. The various types of outputs
Operational outputs whose use is purely with in the computer department.
Interface outputs, which involve the user in communicating directly with the system.
Output Definition
1 The outputs should be defined in terms of the following points:
It is not always desirable to print or display data as it is held on a computer. It should be decided as which
form of the output is the most suitable.
For Example
Will decimal points need to be inserted
Should leading zeros be suppressed.
Output Media:
In the next stage it is to be decided that which medium is the most appropriate for the output. The main
considerations when deciding about the output media are:
The suitability for the device to the particular application.
The need for a hard copy
The response time required.
19
The location of the users
The software and hardware available.
Keeping in view the above description the project is to have outputs mainly coming under the category of
internal outputs. The main outputs desired according to the requirement specification are:
The outputs were needed to be generated as a hard copy and as well as queries to be viewed on the screen.
Keeping in view these outputs, the format for the output is taken from the outputs, which are currently being
obtained after manual processing. The standard printer is to be used as output media for hard copies.
20
Table 2 Customer Details
Table 3 - Hostel
21
Normalization
A Database is a collection of interrelated data stored with a minimum of redundancy to serve many
applications. The database design is used to group data into a number of tables and minimizes the artificiality
embedded in using separate files. The tables are organized to:
Reduced duplication of data.
Simplify functions like adding, deleting, modifying data etc..,
Retrieving data
Clarity and ease of use
More information at low cost
Normalization
Normalization is built around the concept of normal forms. A relation is said to be in a particular normal
form if it satisfies a certain specified set of constraints on the kind of functional dependencies that could be
associated with the relation. The normal forms are used to ensure that various types of anomalies and inconsistencies
are not introduced into the database.
First Normal Form:
A relation R is in first normal form if and only if all underlying domains contained atomic values only.
Second Normal Form:
A relation R is said to be in second normal form if and only if it is in first normal form and every non-key
attribute is fully dependent on the primary key.
Third Normal Form:
A relation R is said to be in third normal form if and only if it is in second normal form and every non key
attribute is non-transitively depend on the primary key
Impacts
By following the specifications we can get an idea about what we need to do and by following the database
design and normalizations we will find out the internal and external interface impacts and how it effects the project.
Mainly we need to focus on the database design and the front end can be done by following the design requirements
we will get an output which will suit our project.
22
6.1 Functional Area/Design Unit A
6.1.1Functional Overview:
Mainly the project design follows the Waterfall model, we need to find the requirements first and then we should go
to the other phases like construction and deployment. It can be described by UML Diagrams and Activity Diagrams.
UML DIAGRAMS
Unified Modeling Language:
The Unified Modeling Language allows the software engineer to express an analysis model using the
modeling notation that is governed by a set of syntactic semantic and pragmatic rules.
A UML system is represented using five different views that describe the system from distinctly different
perspective. Each view is defined by a set of diagram, which is as follows.
User Model View
i. This view represents the system from the users perspective.
ii. The analysis representation describes a usage scenario from the end-users perspective.
Structural model view
i. In this model the data and functionality are arrived from inside the system.
ii. This model view models the static structures.
Behavioral Model View
It represents the dynamic of behavioral as parts of the system, depicting the interactions of
collection between various structural elements described in the user model and structural model
view.
Implementation Model View
In this the structural and behavioral as parts of the system are represented as they are to be built.
Environmental Model View
In this the structural and behavioral aspects of the environment in which the system is to be
implemented are represented.
UML Analysis modeling, this focuses on the user model and structural model views of the system.
UML design modeling, which focuses on the behavioral modeling, implementation modeling and
environmental model views.
Use case Diagrams represent the functionality of the system from a users point of view. Use cases are used
during requirements elicitation and analysis to represent the functionality of the system. Use cases focus on the
behavior of the system from external point of view.
Actors are external entities that interact with the system. Examples of actors include users like administrator, bank
customer etc., or another system like central database.
23
User Module: Use case diagram
Activity Diagram:
Activity Diagram describes the complete flow of the process. It will clearly describes how the process and
control flow will takes place. As per the diagram everything starts from the Home page. The User and Admin can
login and do play the respective roles like booking, reserving and cancelling the reserving beds.
24
Activity Diagram
6.1.2. Impacts:
By following the above processes we can get to know the complete flow of the processes. By watching the
activity diagram we can get to know everything in the project. If there is any issue then we can easily find out by
following the UML and Activity diagrams.
6.2 Functional Area/Design Unit B
6.2.1 Functional Overview
6.2.2 Feasibility Report
Preliminary investigation examines project feasibility; the likelihood the system will be useful to the
organization. The main objective of the feasibility study is to test the Technical, Operational and Economical
feasibility for adding new modules and debugging old running system. All systems are feasible if they are given
unlimited resources and infinite time. There are aspects in the feasibility study portion of the preliminary
investigation:
25
Technical Feasibility
Operation Feasibility
Economic Feasibility
Technical Feasibility
The technical issue usually raised during the feasibility stage of the investigation includes the following:
Does the necessary technology exist to do what is suggested?
Do the proposed equipments have the technical capacity to hold the data required to use the new
system?
Will the proposed system provide adequate response to inquiries, regardless of the number or location
of users?
Can the system be upgraded if developed?
Are there technical guarantees of accuracy, reliability, ease of access and data security?
Operational Feasibility
User-friendly
Customer will use the forms for their various transactions i.e. for adding new routes, viewing the routes details. Also
the Customer wants the reports to view the various transactions based on the constraints. These forms and reports are
generated as user-friendly to the Client.
Reliability
The package wills pick-up current transactions on line. Regarding the old transactions, User will enter them in to the
system.
Security
The web server and database server should be protected from hacking, virus etc.
Portability
The application will be developed using standard open source software (Except Oracle) like Java, tomcat web server,
Internet Explorer Browser etc. these software will work both on Windows and Linux o/s. Hence portability problems will
not arise.
Availability
This software will be available always.
Maintainability
The system called the ewheelz uses the 2-tier architecture. The 1st tier is the GUI, which is said to be front-end
and the 2nd tier is the database, which uses MYSQL, which is the back-end.
26
The front-end can be run on different systems (clients). The database will be running at the server. Users access
these forms by using the user-ids and the passwords.
Economic Feasibility
The computerized system takes care of the present existing systems data flow and procedures completely and
should generate all the reports of the manual system besides a host of other management reports. It should be built as
a web based application with separate web server and database server. This is required as the activities are spread
throughout the organization customer wants a centralized database. Further some of the linked transactions take
place in different locations Open source software like TOMCAT, JAVA, Mysql and Linux is used to minimize the
cost for the Customer.
6.2.3 System Testing and Implementation:
In order to make sure that the system does not have errors, the different levels of testing strategies that are applied at
differing phases of software development are:
Unit Testing:
Unit testing is done on individual modules as they are completed and become executable. It is confined
only to the designer's requirements.
Each module can be tested using the following two Strategies:
Black Box Testing:
In this strategy some test cases are generated as input conditions that fully execute all functional
requirements for the program. This testing has been uses to find errors in the following categories:
Incorrect or missing functions
Interface errors
Errors in data structure or external database access
Performance errors
Initialization and termination errors.
In this testing only the output is checked for correctness. The logical flow of the data is not checked.
27
Involves in-house testing of the entire system before delivery to the user. Its aim is to satisfy the user the
system meets all requirements of the client's specifications.
Acceptance Testing:
It is a pre-delivery testing in which entire system is tested at client's site on real world data to find errors.
Test Approach:
Testing can be done in two ways:
Bottom up approach
Top down approach
Bottom up Approach:
Testing can be performed starting from smallest and lowest level modules and proceeding one at a time. For
each module in bottom up testing a short program executes the module and provides the needed data so that the
module is asked to perform the way it will when embedded within the larger system. When bottom level modules
are tested attention turns to those on the next level that use the lower level ones they are tested individually and then
linked with the previously examined lower level modules.
Top down approach:
This type of testing starts from upper level modules. Since the detailed activities usually performed in the
lower level routines are not provided stubs are written. A stub is a module shell called by upper level module and
that when reached properly will return a message to the calling module indicating that proper interaction occurred.
No attempt is made to verify the correctness of the lower level module.
28
Home page:
Admin Login
Availability Page
29
Cancellation Page
30
Check Vacant Beds
31
7. OPEN ISSUES
Technical Relating to a technological problem in the project.
Business process Relating to the project's design.
Change management Relating to business, customer, or environmental changes.
Resource Relating to equipment, material, or people problems.
Third party Relating to issues with vendors, suppliers, or another outside party.
8. ACKNOLEDGEMENTS
We drive our great pleasure in expressing our sincere gratitude to advisor Dr.Soon Oak Park and Professor N.CHEN
for their timely suggestions, which helped us to complete the project work successfully.
9 REFERENCES:
Database System Concepts sixth edition by Abraham silbershatz, Henry F. Korth, S. Sudarshan.
www.javatpoint.com.
www.w3schools.com.
http://www.apachefriends.org
10 APPENDICES
32