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
Sno. Topic Pg.
No.
INTRODUCTION 5-7
1.
PROBLEM STATEMENT 8-9
2.
QUESTIONNAIRE 10-11
3.
FEASIBILITY STUDY 12-15
4.
PROCESS MODEL 16-20
5.
SOFTWARE REQUIREMENT 21-29
6. SPECIFICATION
SOFTWARE DESIGN DOCUMENT 30-33
7.
USE CASE DIAGRAM 34-36
8.
DATA FLOW DIAGRAM 37-44
9.
E-R DIAGRAM 45-46
10.
SCREEN SHOTS 47-52
11.
TESTING 53-62
12.
SYSTEM MAINTENANCE AND 63-66
13. EVALUATION
OBJECTIVES,SCOPE,SUMMARY 67-68
14. CONCLUSION OF PROJECT
REFERENCES 69-71
15.
16.
ADVANTAGES
17.
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 used-

In 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 project-

1. 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 DISK- Minimum hard disk 40GB

NETWORK- 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 different 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 follows-

Use case

Relationship

Actors

35
 Login

In Patient

Out patient

Lab

Payment

Receipt

Administrator User

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
HOSPITAL MANAGEMENT
Patient OUT PATIENT SYSTEM Patient
PAYMENT
VIEW REPORTS

39
 LEVEL 1 DFD
Patient

Login Table

ID and passwod Verify

ADMINISTRATOR Login
Login

In patient
Enter details
Verify
In
In Patient
Patient

Out patient

Enter details
Out
Out patient
patient Discharge details

Payment table

Amount
Patient
Payment
Payment Save details

Update in Reports table

Give details Lab
Lab

Name and patient’s details

Receipt given
Receipt
Receipt

40
LEVEL TWO DFD

LOGIN

Level 2 DFD

Administrator Patient

Login table

ID and password Verify

1.1
Login

Update

1.2
Change password

Payment Payment table

Amount paid Update database

Patient Payment

41
IN PATIENT

In patient table

Administrator
Add
2.1
2.1
Patient’s details Create
Create

Patient’s details
2.2
2.2 View
View
View

Patient’s details Edit

2.3
2.3
Edit
Edit

Patient’s details Delete

2.4
2.4
Delete
Delete

42
Payment Payment table

Amount paid Update database

Patient Payment

Out patient

Out patient table

Administrator
Add
2.1
2.1
Patient’s details Create
Create

Patient’s details
2.2
2.2 View
View
View

Patient’s details Edit

2.3
2.3
Edit
Edit

Patient’s details Delete

2.4
2.4
Delete
Delete

43
Lab

Patient’s detail Add in database Lab table

Administrator Lab
Lab

Report generated

Given to

Reports
Reports

44
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 Doctor_Id
Doctor_Id Nurse
Assigned

Governs ID
ID
Room
Maintains
Name
Name

Room_ID
Room_ID Room
Room Type
Type
Records

Patient’s
Patient’s info
info

Record
Record No
No Appointment
Appointment

46
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 Cases-

Module1- Login

S.no Test Description INPUT Expected Result

Case OUTPUT
1 Username The Id Username to “Matched”
username set Type: text be displayed
should be form and should
entered not be empty
2 Password The Password “Login to the “Login
password Type: text system successful”
should be “text” form should not be
entered empty

Module 2 (In Patient)

S.no Test Description INPUT Expected Result
Case OUTPUT
1 S.no The S.no of Type: number The s.no The record to
patient to be should be be saved in
entered and unique for database
unique s.no every Patient
tobe entered and should
not be in text
2 Name The name of Name to be Record to be
the patient to Type: text displayed and saved within
be admitted form should not be the database
empty
3 Address The Address Address Address to be Record to be
of patient to Type: taken by the saved within
be entered Alphanumeric system the database
4 Contact The contact Type=number Contact no. to Record to be
number of Should input be taken saved within
patient only numeric the database
values

61
 5 Age The age to be Type = Age to be Record to be
entered number displayed and saved within
Text values should not be the database
will not be empty
accepted

Module 3 :Out Patient

S.no Test Description INPUT Expected Result
Case OUTPUT
1 S.no The S.no of Type: number The s.no The record to
patient to be should be be saved in
entered and unique for database
unique s.no every Patient
tobe entered and should
not be in text
2 Name The name of Name to be Record to be
the patient to Type: text displayed and saved within
be admitted form should not be the database
empty
3 Address The Address Address Address to be Record to be
of patient to Type: taken by the saved within
be entered Alphanumeric system the database
4 Contact The contact Type=number Contact no. to Record to be
number of Should input be taken saved within
patient only numeric the database
values
5 Age The age to be Type = Age to be Record to be
entered number displayed and saved within
Text values should not be the database
will not be empty
accepted
6 Date The date of Type= date Date of Record to be
Admitted admission of text value admission to saved within
the patient should not be be displayed the database
entered
7 Date The date of Type =date Date of Record to be
discharged discharge of discharge to saved within
the patient be displayed database
8 Bill Status The bill should be Bill status to Record to be
status to be checked be shown saved within
paid whether paid database
or not paid

62
Module 4 (Lab)

S.no Test Case Description INPUT Expected Result

OUTPUT
1 Name The name of Name to be Record to be
the patient to Type: text displayed and saved within
be admitted form should not be the database
empty
2 Address The Address Address Address to be Record to be
of patient to Type: taken by the saved within
be entered Alphanumeric system the database
3 Test Name The test to be Type: Text The test of Record to be
conducted in name to be saved within
the lab displayed the database
4 Description The Type :Text The results of Record Saved
description of the report to
the report be displaye
made of the
test conducted

S.no Test Case Description INPUT Expected Result

OUTPUT
1 Name The name of Name to be Record to be
the patient Type: text displayed and saved within
form should not be the database
empty
2 Address The Address Address Address to be Record to be
of patient to Type: taken by the saved within
be entered Alphanumeric system the database
3 Amount Paid The amount Type: The amount Record to be
paid by the Number paid to be saved within
patient displayed the database
4 Amount Due The amount Type: The amount Record to be
the patient Number patient has to saved within
has to pay pay the database

63
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