Hospital Management System Srs

Published on May 2017 | Categories: Documents | Downloads: 79 | Comments: 0 | Views: 538
of 71
Download PDF   Embed   Report

Comments

Content

Hospital Management System

Submitted in partial fulfillment of the requirements
for the award of the degree of
Master of Computer Application
To
Guru Gobind Singh Indraprastha University, Delhi
Submitted to

Submittedby:
Yash Kapoor
Rahul Kapooria
Sweta thapa
Neetu Rana

1

Certificate
We, Yash Kapoor ,Sweta thapa , Rahul Kapooria , Neetu Rana certify that the
Project Report entitled “Hospital Management System” is done by us and it is an
authentic work carried out by us at “Lal Bahadur shastri institute of Management.”
The matter embodied in this project work has not been submitted earlier for the
award of any degree or diploma to the best of my knowledge and belief.

2

ACKNOWLEGEMENT

Apart from our efforts, the success of our project depends largely on the
encouragement and guidelines of many others. We take this opportunity to express
my gratitude to the people who have been instrumental in the successful
completion of this project.
We would like to show our greatest appreciation to our Project guide Mr Bhavya
Deep. We can’t say thanks enough for the tremendous support and help. Without
their encouragement and guidance this project work would not have been
materialized.
Finally we would also like to extend our profound thanks to all our esteemed
colleagues who helped us in specific areas of the project.

3

1.

INTRODUCTION

Pg.
No.
5-7

2.

PROBLEM STATEMENT

8-9

3.

QUESTIONNAIRE

10-11

4.

FEASIBILITY STUDY

12-15

5.

PROCESS MODEL

16-20

6.

SOFTWARE
REQUIREMENT 21-29
SPECIFICATION
SOFTWARE DESIGN DOCUMENT 30-33

Sno.

7.

Topic

8.

USE CASE DIAGRAM

34-36

9.

DATA FLOW DIAGRAM

37-44

10.

E-R DIAGRAM

45-46

11.

SCREEN SHOTS

47-52

12.

TESTING

53-62

13.

SYSTEM
MAINTENANCE AND 63-66
EVALUATION
OBJECTIVES,SCOPE,SUMMARY
67-68
CONCLUSION OF PROJECT
REFERENCES
69-71

14.
15.
16.
17.

ADVANTAGES

18.
19.

4

5

The Hospital Management System is designed for Any Hospital to replace their existing manual,
paper based system. This project targets to provide complete solution for Hospital and related
services.
The project Hospital Management system includes registration of patients, storing their details
into the system, and also computerized billing in the pharmacy, and labs. The software has the
facility to give a unique id for every patient and stores the details of every patient and the staff
automatically. It includes a search facility to know the current status of each room. User can
search availability of a doctor and the details of a patient using the id.
The Hospital Management System can be entered using a username and password. It is
accessible either by an administrator or receptionist. Only they can add data into the database.
The data can be retrieved easily. The interface is very user-friendly. The data are well protected
for personal use and makes the data processing very fast.
The purpose of the project entitled as “HOSPITAL MANAGEMENT SYSTEM” is to
computerize the Front Office Management of Hospital to develop software which is user
friendly, simple, fast, and cost – effective. It deals with the collection of patient’s information,
diagnosis details, etc.
Traditionally, it was done manually. The main function of the system is to register and store
patient details and doctor details and retrieve these details as and when required, and also to
manipulate these details meaningfully System input contains patient details, diagnosis details;
while system output is to get these details on to the CRT screen.
The common features of this type of software are:

6

• This software facilitates complete and smooth running of the reception.
• It manages all the bed allocation systems and the wards of the hospitals.
• It manages the laboratory and the equipments.
• It manages the treatments as well as the entire history of the patients
• This software manages the day to day scheduling of both the nurses and the doctors to various
departments and also allocates the schedules of their duties.
• It also manages the timely and proper accounting to make sure a proper and current billing.
• The hospital management software also maintains the proper tests of a number of patients as
well as keeps the records of all the medical reports.
• The biggest benefit of the hospital management system is that it can be used at the same time
via a number of users.

7

8

The information is very difficult to retrieve and to find particular information like- E.g. - To find
out about the patient’s history, the user has to go through various registers. This results in
inconvenience and wastage of time. The information generated by various transactions takes
time and efforts to be stored at right place. Various changes to information like patient details or
immunization details of child are difficult to make as paper work is involved. Manual
calculations are error prone and take a lot of time this may result in incorrect information. For
example calculating patient’s bill based on various treatments. This becomes a difficult task as
information is difficult to collect from various registers.
How can we overcome the limitations of the manual system?
The working in the organization will be well planned and organized. The data will be stored
properly in data stores, which will help in retrieval of information as well as its storage. The
level of accuracy in the proposed system will be higher. All operation would be done correctly
and it ensures that whatever information is coming from the center is accurate. The reliability of
the proposed system will be high due to the above stated reasons. The reason for the increased
reliability of the system is that now there would be proper storage of information. In the
proposed system utmost care would be that no information is repeated anywhere, in storage or
otherwise. This would assure economic use of storage space and consistency in the data stored.
The main objective of proposed system is to provide for a quick and efficient retrieval of
information. Any type of information would be available whenever the user requires. In manual
system there are many problems to store the largest amount of information. The system should
be easy to operate and should be such that it can be developed within a short period of time and
fit in the limited budget of the user.

9

10

Questionnaire
Que1- What is the problem with the current system?
Que2- What do you want in this system exactly?
Que3- What modules you would like to be in the system?
Que4- What kinds of features do you think would attract you to use this system?
Q5 Who would be the users of the hospital management system?
Q6 Would you like to display the patient’s report online by providing patients a login id and
password?
Q7 A user friendly system will be perfect as people with less technical knowledge should be able
to use it?
Q8 How many record should the database be able to hold?
Q9. Timely updation to be made in the software so that huge amount of record to be maintained?
Q10 The entries in the software to be self explanatory so as to avoid confusion?
Q11. Software to be secured from unauthorized access?
Q12 Allocation of rooms to patients operated should be done simultaneously?
Q13What kind of platform for working is required?
Q14 Any kind of special security is needed for the software?
Q17 Are you satisfied with the current processes and policies?
Q18 what data required by exist in other system?
Q19 what problem do you want this system to solve?
Q20 Do you need any additional functionality for improving the performance of the system?
Q21 Have you faced any calculation errors in the past?
Q22 Who is the controller of the software?
Q23 Who will be using the software?
Q24 Who will explain the manual system?

11

12

Feasibility Study
A feasibility study is conducted to select the best system that meets performance requirement.
This entails an identification description, an evaluation of candidate system and the selection of
best system for the job. The system required performance is defined by a statement of
constraints, the identification of specific system objective and a description of outputs.
Steps in feasibility analysis
The following steps are involved in the feasibility analysis. They are :
Form a project team and appoint a project leader.
Prepare system flowcharts.
Enumerate potential proposed systems.
Define and identify characteristics of proposed system.
Determine and evaluate performance and cost effectiveness of each proposed weight system
performance and cost data.
Select the best proposed system.
Type of feasibilities
The key considerations in feasibility analysis are:
• Operational Feasibility
The preliminary investigation of the current system leads to the fact that it is operationally
feasible. Users of the system will not resist for the induction of the new system because the
13

project is going to help them a lot as, it will increase their efficiency by reducing the time for
doing the same repetitive task. It is mainly related to human organizational and political aspects.
The points to be considered are:
• What changes will be brought with the system?
• What organizational structures are disturbed?
Generally project will not be rejected simply because of operational infeasibility but such
considerations are likely to critically affect the nature and scope of the eventual
recommendations.
• Economic feasibility
Since the current system is small the investigation on the project would be of normal expense. It
is economical, as investment needed for developing this project would need one personnel
computer and some operational cost is needed for the project. There is very little development
cost.
According to the computerized system we propose, the costs can be broken down to two
categories. Costs associated with the development of the system. Costs associated with operating
the system. From our analysis, we came to result that both these costs occurred to the developers
will be recurred within first 6 months of project implementation thereafter providing economical
benefits so ever. So, we can see that current system is economically feasible.
• Technical feasibility
This is concerned with specifying equipment and software that will successfully satisfy the user
requirement. The technical needs of the system may vary considerably, but might include:
14

• The facility to produce outputs in a given time.
• Response time under certain conditions.
• Ability to process a certain volume of transaction at a particular speed.
Legal feasibility
Legal feasibility is a determination of whether a proposed project infringes on known Acts,
Statutes, as well as any pending legislation. Basically legal feasibility is to determine whether the
proposed system conflicts with the legal requirements. e.g. a data processing system must
comply with the Local Data Protection Acts
Its simply to determine the any infringement and everything must comply the legal requirements.

15

16

SOFTWARE LIFE CYCLE MODELS
The goal of Software Engineering is to provide models and processes that lead to the production
of well-documented maintainable software in a manner that is predictable.
“The period of time that starts when a software product is conceived and ends when the product
is no longer available for use. The software life cycle typically includes a requirement phase,
design phase, implementation phase, test phase, installation and check out phase, operation and
maintenance phase, and sometimes retirement phase”.
Methodology usedIn Iterative model, iterative process starts with a simple implementation of a small set of the
software requirements and iteratively enhances the evolving versions until the complete system
is implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing just part of the software, which is
then reviewed in order to identify further requirements. This process is then repeated, producing
a new version of the software at the end of each iteration of the model.

17

Iterative Model Design:
Iterative process starts with a simple implementation of a subset of the software requirements
and iteratively enhances the evolving versions until the full system is implemented.
At each iteration, design modifications are made and new functional capabilities are added. The
basic idea behind this method is to develop a system through repeated cycles (iterative) and in
smaller portions at a time (incremental).
Following is the pictorial representation of Iterative and Incremental model:

The iterative model consists of five phases:
1.Requirements.
18

2.Design.
3.Implementation .
4.Testing.
5.Review.
1.Requirements : A requirement phase involves in collection of requirements that are needed to
develop the software for analyzing. Requirements phase goes on until the complete requirements
are gathered and analyzed. Once the requirements are gathered for the first phase. We move on
to the next phase.
2. Design :In design phase , as per the gathered requirements the designing takes place in order
to give the best software product to the client. The design may include the previous projects
design or new projects design whichever is feasible for the software development.
3. Implementation: In the implementation phase, where in the coding of the software takes place
as per the requirements and design done in step 1 and 2.
4.Testing: After implementing the software, the individual modules are combined together to
form a integrated software and testing phase starts from the scratch.
5.Review: In review process, the software developed is under evaluation , the available current
requirements are reviewed and changed if necessary . If any additions are made to the current
requirements they are taken to the next cycle implementation. After completion of all the phases
we can come to the conclusion that one complete cycle is completed. Now we have to make a
decision whether the developed software can be taken to the next cycle or we need to start from
the scratch as the developed software did not meet the client expectation.
19

Then another cycle starts from the requirements phase to review phase this process is an
iterative process, the process ends when the complete software is developed as per the client
satisfaction. Each cycle can be taken as individual versions.
So, in a nutshell, in incremental model the whole requirement is divided into various builds.
During each iteration, the development module goes through the requirements, design,
implementation and testing phases. Each subsequent release of the module adds function to the
previous release. The process continues till the complete system is ready as per the requirement.
ADVANTAGES:
The advantage of this model is that there is a working model of the system at a very early stage
of development which makes it easier to find functional or design flaws. Finding issues at an
early stage of development enables to take corrective measures in a limited budget.
Thus the advantages can be summarized as:
• Avoids the problems resulting in risk driven approach in the software
• Understanding increases through successive refinements.
• Performs cost-benefit analysis before enhancing software with capabilities.
• Incrementally grows in effective solution after every iteration
• Does not involve high complexity rate.
• Results are obtained early and periodically.
• Parallel development can be planned and progress can be measured.

20

21

Introduction:
The Systems Requirements Specification (SRS) is designed to express the behavioral,
performance, and development requirements of this product and serves as the fundamental
requirements document for the development of the product. The Systems Requirements
Specification includes a description of every input into the system, every output from the system
and all functions performed by the system in response to input or in support of an output. The
SRS meets IEEE standards and is the exclusive requirements document to be used in
development; all design and testing choices must be compatible with this document.
Purpose:
The purpose of this document is to outline the requirement of Hospital management system
making it computerized and to study the requirement of its various users.
Scope
The software to be produced would be Hospital management system of ABC hospital. This
product would make the hospital management system automated from manual system. It shall
reduce the redundancy, paperwork, maintenance of records.

22

Administrators
Admin should be able to insert, modify or update the records. work load and paper work of
maintaining the records in a file or folder manually. The overall goal of this would be :


Reduce paper work



Easy to update



Computerized



Maintain security

Overview
The software requirement specification provides the developer with the requirements of the user.
When developer knows about the requirements of the user he can design it accordingly. SRS also
helps in feasibility study as well by providing an input for the latter. The requirements would
help to determine whether the software can be developed.
OVERALL DESCRIPTION
Product Perspective
Hospital management system is a replacement for the manual system which depends on paper
work for recording information. The software will ease the burden of administrator by
performing various tasks such as storing information of patients, updating of databases etc. This
hospital management also generates a complete summary of payable bills and collected amount.

23

Product Functions
It would help in providing adequate data to the management. It would also end the practice of
keeping records in files and stacking up a pile of files. This would help the hospital prepare and
organize its patient related records more efficiently on the basis of each student report.
Normal Users
The Patients should be provided with the updated information about their bills. Patients have the
facility to view their report or any information related to it. They can also see their bill status ie,
paid, outstanding etc.
User Characteristics
Users of the software are patients, staff and the administrators who maintain the system.
Members are assumed to have basic knowledge of computers. Administrators of the system
should have more knowledge of internal modules of the system and are able to rectify small
problems that may arise due to disk crashes, power failures and other catastrophes. Friendly user
interface, must be sufficient to educate the users on how to use this product without any
problems or difficulties.
User’s Requirement:A requirement specifies capabilities that a system must provide in order to solve a problem.
Requirements include:•

Functional requirements



Performance requirements

24

A clear statement of the user requirements and information needs is necessary for good system
design. If the information required is not complete or the objectives are not identified properly
and clearly, then the design effort will produce less than optimum results. Information needs
also vary at different levels.
Functional requirements:
Modules in the project1.

Login

2.

In Patient

3.

Out Patient

4.

Lab

5.

Billing

6.

View Reports

When the user explains his current scenario of work, the developer may not quite get him. It is
very essential for the developer to understand the way things are functioning at the user’s place,
since it is on the basis of his understanding that he will develop the software and computerize the
current system. In turn the user also needs to understand how things are going to get
computerized and how is work scenario going to change once things are computerized. To be
able to fetch the purpose of the developer and the user we develop a document called Software
requirement Specification (SRS). SRS is a document that explains what the proposed software
25

should do. It focuses on what has to be done and not on how. It describes the complete behavior
of the proposed software. The user usually does not understand software or software
development process so he needs that things are put down in black and white in simple manner.
So, this communication gap is bridged by the software requirement specification. An SRS
establishes an agreement between the user and the developer on what the user requires and what
the software product will do:


Aim



User characteristics



General constraints



General assumption



Information description:

PERFORMANCE REQUIREMENTS
The performance features which is required in the proposed system is
User Friendliness
The proposed system should be user friendly, understandable and easy to use. It should provide
on line help and error messages for user ease. User should be able to take the output of reports
on the screen.
Requirements• This software should not breakdown suddenly in any disaster like power failure.

26

• The timeline of this software must be in our mind.
• The performance of the functions and every module must be well.
• At every step the output of the one phase is the input of the other phase and it will be reliable
and accurate.
• The risk factor must be taken at initial step for better performance of the software.
• For individual function the performance will be well.
• For login to the software password and user name will be matched to the password and name
saved in the database and thus only authenticated users are allowed to the login.
• There will be various ways of retrieving data and it takes less time.
Safety Requirements
The database may get crashed at any certain time due to virus or operating system failure.
Therefore, it is required to take the database backup
Security Requirements
We are going to develop a secured database for the school. Depending upon the category of user
the access rights are decided. It means if the user is an administrator then he can be able to
modify the data, delete, append etc. Whereas the user can only view the information but cannot
update or delete the records.
HARDWARE REQUIREMENTS
PROCESSOR-

Intel Pentium III processor
27

RAM-

Minimum 128 MB RAM
Recommended 256 MB RAM

HARD DISKNETWORK-

Minimum hard disk 40GB
Internet connection through Modem or LAN Card

6.7.4 SOFTWARE REQUIREMENTS
WINDOWS XP OPERATING SYSTEM


MS Access 2007



MS WORD 2007



Microsoft Visual Basic-6.0

6.7.5 Technology Used


Front End: - Microsoft Visual Basic-6.0



Back End: - Microsoft Access.

Constraints:
The computer should have enough processor speed, memory, and hard disk space to run the
complier we’ve chosen. We can check the manufacturer’s specification to determine these
requirements

28

The above specific operating system will be available on the hardware designated for the
software product. If, in fact, the operating system is not available, the SRS would then have to
change accordingly.
SPECIFIC REQUIREMENTS
User Interface Constraints
Using this system is fairly simple and intuitive. A user familiar with basic browser navigation
skills should be able to understand all functionality provided by the system.
Hardware Constraints
The system should work on only school administration desktop computers.
Software Constraints
No specific software required
Communications Constraints
System must have access to the included database. Other components of the fee management
system may require access to certain data which is available with school administration only.

29

30

PURPOSE
The purpose of this document is to describe the implementation of software,” HOSPITAL
MANAGEMENT SYSTEM” for ABC Hospital. The software is developed for computerizing
the working in a hospital and is capable to provide easy and effective storage of information
related to patients that come up to the hospital.
SCOPE: This software can be used in any Hospital, Clinic for maintaining patient details and
their test results.
SYSTEM OVERVIEW
This system is designed to reduce the paperwork and provide ease for maintaining , searching
,updating and deleting the information about the patients and staff . Admin will be responsible
for updating information about the patients and patients are also provided with facility to view
their reports and bills.
MODULE DECOMPOSITION: It describes different modules of the system, shown in entity
relationship diagram:
a) LOGIN: This module provides admin with the facility to login in the system and add ,delete ,
update or view information about the patients. Also the patients can login and view their
medical reports and bills.

31

b) INPATIENT: This module consist of list of inpatients and their information such as their
personal details as well as admit and discharge date, ward allotted to them etc. Administrator has
right to update the inpatient list .
c) OUTPATIENT: This module consists of the list of outpatients and their personal information.
Admin can add, delete and update the information.
d) LAB: This module provides the facility for generating medical reports of the patients.
e) BILLING- This module provides the facility for generating the bills of the treatment of the
patient .This module is accessible by the patients also in order to see their bills and make
payment.
f) VIEW REPORTS- This module allows patients to view their reports(eg xray,blood test etc).
3.2 CONCURRENT PROCESS DECOMPOSITION: It describes the concurrent processes of
system software.
a) SIMULTANEOUS LOGIN: Admin or Patient can login software simultaneously.
c) SIMULTANEOUS LOGIN AND UPDATE:

While administrator

is updating

the

information about the patients , simultaneously on the other side patient can view his reports and
billing status.
DATA DECOMPOSITION: This section contains a description of each data element that is
shared between components, its storage, and its logical structure (but not its representation in a
programming language).

32

a) DATA SHARING: Data is shared between modules to keep each section of system well
informed and up to date. Patients can view their reports and bills.
b) DATA STORAGE: In order for system to function, it must have access to a database such as
MySQL, which contains information about system as well as users. The database is constructed
using relational model, which means that links can be made between various tables, attributes of
tables.
c) DATA ACCESS : Data can be accessed ,updated ,deleted by admin only while the patients
can view their medical reports and bills only. These functions can be performed through menu
options provided at frontend, at backend it could be performed by queries.
4. DEPENDENCY DESCRIPTION: The following section will describe the relationship
between each given module of the system with the other modules of the system.
MODULE DEPENDENCY:
This section outlines the dependencies and interactions in the modules.
1. LOGIN: Admin can login to system through ID and Password.
2. INPUT: The system receives input from the user. This input can be taken in the form of a text
field and submitting by clicking on a button .
3. DATABASE: The Server then processes this information and calls methods on to solve the
queries (request by user through input).

33

4. OUTPUT: After successfully performing the queries desired result is returned. For admin the
desired output would be the changes made by him in database and for patients result would be
display of their medical reports and bills.
4.2 DATA DEPENDENCY: This section describes the diļ¬€erent database tables that make up the
database for the system.

34

USE CASE
It is a visually representation what happens when actor interacts with system.
A use case diagram captures the functional aspects of a system.
The system is shown as a rectangle with name of the system inside ,the actor are shown as stick
figures, the use case are shown as solid bordered ovals labeled with name of the use case and
relationships are lines or arrows between actor and use cases.
Symbols used in Use case are as followsUse case

Relationship

Actors

35

Login
In Patient

Out patient

Lab

Payment
Receipt

User

Administrator
Fig() Use Case diagram for hospital management system

36

37

Data flow diagram
A data flow diagram or bubble chart (DFD) is a graphical representation of the "flow" of data
through an information system, modeling its process aspects. Often they are a preliminary step
used to create an overview of the system which can later be elaborated. DFDs can also be used
for the visualization of data processing (structured design).
A DFD shows what kinds of information will be input to and output from the system, where the
data will come from and go to, and where the data will be stored. It does not show information
about the timing of processes, or information about whether processes will operate in sequence
or in parallel (which is shown on a flowchart).
The primitive symbols used for constructing DFD’s are:
Symbols used in DFD
A circle represents a process.

A rectangle represents external entity

A square defines a source or destination of the system data.

An arrow identifies dataflow.
38

Double line with one end closed indicates data store
Data Flow Diagrams
a) Context level Diagram

LEVEL 0 DFD

LOGIN

VIEW REPORTS

IN PATIENT
Patient

OUT PATIENT

HOSPITAL MANAGEMENT
SYSTEM

VIEW REPORTS

39

PAYMENT

Patient

LEVEL 1 DFD
Patient

Login Table

ID and passwod

Verify

ADMINISTRATOR

Login
Login

In patient
Enter details
In
In Patient
Patient

Verify

Out patient
Enter details
Out
Out patient
patient

Discharge details

Payment table
Patient

Amount
Payment
Payment

Save details

Update in

Give details

Reports table

Lab
Lab

Name and patient’s details

Receipt given
Receipt
Receipt

40

LEVEL TWO DFD
LOGIN

Level 2 DFD
Administrator

Patient

Login table

Verify

ID and password

1.1
Login
Update

1.2
Change password

Payment

Payment table

Update database

Amount paid
Payment

Patient

41

IN PATIENT
In patient table
Administrator
Add
Patient’s details

Patient’s details

Patient’s details

Patient’s details

2.1
2.1
Create
Create

2.2
2.2
View
View

View

2.3
2.3
Edit
Edit

Edit

2.4
2.4
Delete
Delete

42

Delete

Payment

Payment table

Update database

Amount paid
Payment

Patient

Out patient

Out patient table
Administrator
Add
Patient’s details

Patient’s details

Patient’s details

Patient’s details

2.1
2.1
Create
Create

2.2
2.2
View
View

View

2.3
2.3
Edit
Edit

Edit

2.4
2.4
Delete
Delete

43

Delete

Lab
Patient’s detail

Add in database

Administrator

Lab
Lab

Report generated
Given to
Reports
Reports

44

Lab table

45

Entity Relationship Diagram

Hospital
Management E-R
Diagram
Employee
Age

Contact

Is A

Name
Name

Name
Name
Patient
ID
ID
Address
Address

Receptionist
Doctor

Attends
Date admitted
Name

Nurse

Doctor_Id
Doctor_Id

Assigned

ID
ID

Governs

Room

Maintains
Name
Name
Room_ID
Room_ID

Room
Room Type
Type

Records
Patient’s
Patient’s info
info

Record
Record No
No

46

Appointment
Appointment

47

1.

Interface Design
LOGIN

Login Unsucessful

48

CHANGE PASSWORD

IN PATIENT

49

OUT PATIENT

50

PAYMENT

51

RECEIPT

LAB
52

53

54

Testing & Debugging
Testing Methodology
Testing is the process of executing a program with the intent of finding errors” As we know,
software is one component of a large computer based system. Ultimately, Software is
incorporated with other system components and thus, a series of special tests are to be
conducted. Petschenik gives some guidelines for choosing test cases during system testing. The
first is that testing the system’s capabilities is more important than testing its components.
During system testing, we should evaluate a number of attributes of the software that are vital to
the user.
Testing
The most crucial stage of software development, testing validates the application. During testing
we will be concerned about the inputs and their expected outputs. We emphasize on the testing
where we will input the data and compare the output with the expected results. At this stage we
are not concerned about the process; we are only looking for correct outputs. Various software
testing techniques exists which take different approaches to test and validate a software.
Tests done on the designed software was to verify the following properties of the software:
Correctness (satisfaction of the specifications)

55

Reliability (how well it meets the requirements)
Portability (running in different environments)
Usability (ease with which user can use the software)
Maintainability (modifications after initial release)

Debugging
Debugging is removing the undesirable errors or bugs from the program. We implemented
debugging using the Visual basic compiler in which the application was developed.
During testing the program to tested is executed with the set of test cases and have the output of
the program for the test cases is evaluated to determine if the program is performing as expected.
Due to its approach dynamic if the program is performing as expected. Due to its approach
dynamic testing can only presence of errors in the program, the exact nature of errors is not
usually decided by testing. Testing forms is the process to determine errors in the program.
Once a program are tested individually then the system as a whole needs to be tested. During
testing the system is used experimentally to ensure that the software does not fail i.e. it will run
according to its specification. The programs executed to check for any syntax and logical errors.
The errors are corrected and test is made to determine whether the program is doing what
supposed to do.

56

Software Testing Techniques
The importance of software testing and its impact on software cannot be under
estimated. Software testing is a fundamental component of software quality assurance and
represents are view of specification, design and coding. The greater visibility of software
systems and the cost associated with software failure are motivating factors for planning, through
testing. It is not uncommon for a software organization to spent 40% of its effort on testing.

White Box Testing White box testing is a test case design approach that employs the control
architecture of the procedural design to produce test cases. Using white box testing approaches,
the software engineering can produce test cases that
Guarantee that all independent paths in a module have been exercised at least once.
Execute all loops at their boundaries and in their operational bounds
Exercise internal data structures to maintain their validity.

Various white box techniques
Basis Path Testing: Basic path testing is a white box testing techniques that allows the test case
designer to produce a logical complexity measure of procedural design and use this measure as
57

an approach for outlining a basic set of execution paths. Test cases produced to exercise each
statement in the program at least one time during testing.
Control Structure Testing: Although basis path testing is simple and highly effective, it is not
enough in itself. Next we consider variations on control structure testing that broaden testing
coverage and improve the quality of white box testing. Different control structure techniques are
Condition testing
Data flow testing
Loop testing
Black Box Testing: Black Box Testing is not a type of testing; it instead is a testing strategy,
which does not need any knowledge of internal design or code etc. As the name "black box"
suggests, no knowledge of internal logic or code structure is required. The types of testing under
this strategy are totally based/focused on the testing for requirements and functionality of the
work product/software application.
Various black box techniques
Functional Testing: In this type of testing, the software is tested for the functional requirements.
The tests are written in order to check if the application behaves as expected.
Smoke Testing: This type of testing is also called sanity testing and is done in order to check if
the application is ready for further major testing and is working properly without failing up to
least expected level.

58

Recovery Testing: Recovery testing is basically done in order to check how fast and better the
application can recover against any type of crash or hardware failure etc. Type or extent of
recovery is specified in the requirement specifications.
Alpha Testing: In this type of testing, the users are invited at the development center where they
use the application and the developers note every particular input or action carried out by the
user. Any type of abnormal behavior of the system is noted and rectified by the developers.
Beta Testing: In this type of testing, the software is distributed as a beta version to the users and
users test the application at their sites. As the users explore the software, in case if any
exception/defect occurs that is reported to the developers.
Software Testing Strategies in used in the project
A strategy for software testing integrates software test case design techniques into a well-planned
set of steps that cause the production of software. A software test strategy provides a road map
for the software developer, the quality assurance organization, and the customer
Unit testing: Unit testing concentrates verification on the smallest element of the program the
module. Using the detailed design description important control paths are tested to establish
errors within the bounds of the module. Firstly the unit testing on various modules and sub
modules is performed in the project. Different modules are tested with different correct and
incorrect data. For example in the order processing module order of 0 product is not allowed so
in this case different methods are used to find out whether the modules is performing all
processes correctly. All modules are tested to find out that whether they are working properly

59

Integration testing :-Once all the individual units have been tested there is a need to test how they
were put together to ensure no data is lost across interface, one module does not have an adverse
impact on another and a function is not
performed correctly. Integration testing is a systematic approach that produces the program
structure while at the same time producing tests to identify errors associated with interfacing.In
this project bottom up integration testing is used. Firstly lower level modules are tested. As
modules are integrated bottom up, processing required for modules subordinates to a given level
is always available and the need for stubs is eliminated.
Validation testing :-As a culmination of testing, software is completely assembled as a package,
interfacing errors have been identified and corrected, and a final set of software tests validation
testing are started. Validation can be defined in various ways, but a basic one is valid succeeds
when the software functions in a fashion that can reasonably expected by the customer.
In the first phase of alpha testing, developers test the software using white box techniques.
Additional inspection is then performed using black box techniques. This is usually done by
addicted testing team. This is often known as the second stage of alpha testing. Unit and
integrated tests concentrate on functional verification of a component and incorporation of
components into a program structure. Validation testing demonstrates tractability to software
requirements, and system testing validates software once it has been incorporated into a larger
system.
Test Cases Specification for System Testing
The different conditions that need to be tested, along with the test cases used for testing those
conditions and expected output are given. The goal is to test different functional requirements, as
60

specified in requirement document. Test cases have been selected for both valid and invalid
inputs.

Test CasesModule1- Login

S.no

Test
Case

Description INPUT

Expected
OUTPUT

Result

1

Username

Password

Username to
be displayed
and should
not be empty
“Login to the
system
should not be
empty

“Matched”

2

The
username set
should be
entered
The
password
should be
entered

Expected
OUTPUT

Result

Id
Type: text
form
Password
Type: text
“text” form

“Login
successful”

Module 2 (In Patient)

S.no

Test
Case

Description INPUT

1

S.no

The S.no of
patient to be
entered and
unique s.no
tobe entered

2

Name

The name of
the patient to
be admitted

3

Address

4

Contact

The Address
of patient to
be entered
The contact
number of
patient

Type: number The s.no
should be
unique for
every Patient
and should
not be in text
Name to be
Type: text
displayed and
form
should not be
empty
Address
Address to be
Type:
taken by the
Alphanumeric system
Type=number Contact no. to
Should input be taken
only numeric
values

61

The record to
be saved in
database

Record to be
saved within
the database
Record to be
saved within
the database
Record to be
saved within
the database

5

Age

The age to be Type =
entered
number
Text values
will not be
accepted

Age to be
displayed and
should not be
empty

Record to be
saved within
the database

Expected
OUTPUT

Result

Module 3 :Out Patient

S.no

Test
Case

Description INPUT

1

S.no

The S.no of
patient to be
entered and
unique s.no
tobe entered

2

Name

3

Address

4

Contact

5

Age

6

Date
Admitted

7

Date
discharged

8

Bill Status

Type: number The s.no
should be
unique for
every Patient
and should
not be in text
The name of
Name to be
the patient to Type: text
displayed and
be admitted
form
should not be
empty
The Address Address
Address to be
of patient to
Type:
taken by the
be entered
Alphanumeric system
The contact
Type=number Contact no. to
number of
Should input be taken
patient
only numeric
values
The age to be Type =
Age to be
entered
number
displayed and
Text values
should not be
will not be
empty
accepted
The date of
Type= date
Date of
admission of text value
admission to
the patient
should not be be displayed
entered
The date of
Type =date
Date of
discharge of
discharge to
the patient
be displayed
The bill
should be
Bill status to
status to be
checked
be shown
paid
whether paid
or not paid
62

The record to
be saved in
database

Record to be
saved within
the database
Record to be
saved within
the database
Record to be
saved within
the database
Record to be
saved within
the database

Record to be
saved within
the database
Record to be
saved within
database
Record to be
saved within
database

Module 4 (Lab)

S.no
1

Test Case

Description

INPUT

Name

The name of
the patient to
be admitted

Type: text
form

2

Address

3

Test Name

4

Description

S.no

The Address
of patient to
be entered
The test to be
conducted in
the lab
The
description of
the report
made of the
test conducted

Test Case

Description

1

Name

The name of
the patient

2

Address

3

Amount Paid

4

Amount Due

The Address
of patient to
be entered
The amount
paid by the
patient
The amount
the patient
has to pay

Expected
OUTPUT

Result

Name to be
displayed and
should not be
empty
Address
Address to be
Type:
taken by the
Alphanumeric system
Type: Text
The test of
name to be
displayed
Type :Text
The results of
the report to
be displaye

Record to be
saved within
the database

INPUT

Result

Expected
OUTPUT
Name to be
Type: text
displayed and
form
should not be
empty
Address
Address to be
Type:
taken by the
Alphanumeric system
Type:
The amount
Number
paid to be
displayed
Type:
The amount
Number
patient has to
pay

63

Record to be
saved within
the database
Record to be
saved within
the database
Record Saved

Record to be
saved within
the database
Record to be
saved within
the database
Record to be
saved within
the database
Record to be
saved within
the database

64

Software needs to be maintained not because some of its components wear out and need to be
replaces but because there are often some residual errors remaining in the system that must be
removed as they are discovered. Many of the errors surfaces only after the system have been in
operation, sometimes for a long time. To discovered & removed such type of errors called

Corrective maintenance.
Up gradation, enhancement, modification, include some more features & added some more
services are the such type of changes which a software must adapt to the needs of the changed
environment. The changed software then changes the environment, which in turn requires further
changes, called Adaptive Maintenance.
As software is used, the user will recognize additional functions that will provide benefit,It
comes under Perfective maintenance. This maintenance extends the software beyond its original
functional requirements.
For maintenance point of view, we have taken all three approaches:
1. Corrective Maintenance
2. Adaptive Maintenance
3. Perfective Maintenance

65

Corrective Maintenance: In Transportation System Automation Process, we have checked the
system with original data of the user. We will collect the errors which surfaces after system has
started working & will remove them immediately by repairing processing. Because there are
often some residual errors remaining in the system so in future prospects we shall also
discoverthe errors on regular basis, which can be remaining in the system and all will be
removed by us day
to day.
Adaptive Maintenance: we have adopted such type of approach that after up gradation or
modification or any further enhancement, the software should be environment compatible but if
it requires further changes according to the needs we will maintain it as needed.
Perfective Maintenance: We have taken a lot of care at the time of analysis but after the user
starts using the software, if suggested we will add additional functions to enhance the
functionality of the software.
If the user is looking for any additional enhancement in this system like, Addition of any new
module or any modification in any module or any up gradation in any of the existing module can
be added, modify and up graded easily with out any difficulty or major changes.
After the completion of any further changes like modification, up gradation or any enhancement
we have also a step of regression testing. In this step we will execute the old test cases to check
that if there is any error occurs after changes has taken place.
System Evaluation
Evaluation of the system is performed to identify its strengths and weakness.
66

Operational Evaluation: In this, assessment of the system functions, ease of use, response time,
and suitability of information’s formats, overall reliability, and level of utilization is undertaken.

All the above aspects were very well taken into consideration from the very beginning.
Reliability of this project is high. Recovery methods are well written, even if something
exceptional occurs user has a way to come out of the undesirable situation and carry on with the
work. Records are saved only if they are valid.

67

Objectives of the Project
The main objective of hospital management system is to perform all the functions or operations
accurately and correctly. The proposed system has the following objectives to be achieved.
1. User Friendly Environment.
2. Less Space.
3. Fast Retrieval.
4. Easy to Operate.
5. Accuracy.
6. Receipt generation

Scope of The Project
1. Including module to enable the software’s user to record payment done by patient
2. Including a module that adds the record of a new patient
3. Including a module to view the patient’s record
Future Scope and Limitations
Hospital management system is in itself a complete system, though it has a few limitations but it
has a lot of future scope and features that could be added to make it more widely acceptable. One
limitation is that our software is limited to small and medium scaled hospitals. One of the major
future scope is making our system online. Connecting the system of a particular hospital to a
common data centre will provide globalization to the school, and then the user will be able to
share the data across the branches.
Summary

68

The project entitled “Hospital Management” is about Managing fee records. There are many
functions like registration, login, change password, payment, inpatient,out patient etc. The end
user can register the Patient by filling the necessary details and can make the payment on
student’s behalf. During login process there is one more function available that is change
password. This function allows the admin to change the password. Successful login will lead to
registration form where administrator can register the patient and record all the data of the
patient.

Conclusion

This software is a database project with all the basic capabilities a database should have. This
application software is about student fee system and it records and maintains records about the
student fee.
In doing so, an appreciation of project management, communication and consultancy skills
should be acquired, along with a thorough understanding of the development of windows based
applications using Visual basic. I feel that all of these aims were achieved, some to greater extent
than others.

69

70

The references for the project “HOSPITAL MANAGEMENT SYSTEM” have been taken from
the following books and website.

WEB REFERENCES

http://en.wikipedia.org/

BOOKS REFERENCES
Software engineering by KK AGGRAWAL
Software engineering by Pankaj Jalote

71

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close