hms.new C++

8/2/2019 hms.new C++

1/117

1

PROJECT REPORT

ON

HOSPITALMANAGEMENTSYSTEM

GOLDFIELD INSTITUTE OF TECHNOLOGY &

MANAGEMENT

Maharshi Dayanand University, Rohtak

June-July 2010

SUBMITTED TO: SUBMITTED BY:Mr.AMIT DUBEY H.NITISH

08/CSE/27

8/2/2019 hms.new C++

2/117

2

GGOOLLDD FFIIEELLDD IINNSSTTIITTUUTTEE OOFF TTEECCHHNNOOLLOOGGYY&& MMAANNAAGGEEMMEENNTT

CCEERRTTIIFFIICCAATTEE

This is to certify that the project report entitled,HHOOSSPPIITTAALL MMAANNAAGGEEMMEENNTTsubmitted by thestudents of computer science is a bonafide record of the

work carried out by them under my supervision and is their

original work during the project they were found obedient,

diligent and disciplined.

MMrr.. PPrraaddeeeepp

((HHOODD ooffCCSSEE//IITT))

MMSS.. SSUUPPRRIIYYAA SSIINNGGHHAA

((PPrroojjeecctt GGuuiiddee))

8/2/2019 hms.new C++

3/117

3

ACKNWLEDGEMENT

I would like to thanks to all my guides who really acted as pillars to

help my way throughout this project that has led to successful and

satisfactory completion of this study of this project.

Firstly I would like to thanks my project in charge MR. A.N

MISHRA under whose able guidance and motivation this work has

been performed.

The inspiration of the faculty members of the Computer Science

Department of G.F.I.T.M, faridabad enabled me to make a thorough

study of this subject.

Last but not the least, no acknowledgement will be complete without

mentioning my family and friends. They have also supported me

throughout the development projects.

NAME: H.NITISHROLL NO. 08/CSE/27

8/2/2019 hms.new C++

4/117

4

COMPANY PROFILE

NIC, under the Department of InformationTechnology of the Government of India, is apremier Science and Technology organization, at

the forefront of the active promotion andimplementation of Information andCommunication Technology (ICT) solutions in thegovernment. NIC has spearheaded the e-Governance drive in the country for the last threedecades building a strong foundation for betterand more transparent governance and assisting

the governments endeavor to reach theunreached.

8/2/2019 hms.new C++

5/117

5

CONTENTS

CHAPTER 1 INTRODUCTION 6-10

CHAPTER 2 WHY C++ IS USED FOR MAKING THIS PROJECT 11-14CHAPTER 3 SRS (SOFTWARE REQIURMENT SPECIFICATION) 15-23

3.1 SOFTWARE REQUIRMENT SPECIFICATION

3.2 HARDWARE REQUIRMENT SPECFICATION

CHAPTER 4 SYSTEM ANALYSIS AND SOFTWARE DESIGN 24-46

4.1 DFD(DATA FLOW DIGRAM)

4.2 HIERARCHY DIGRAM

4.3 SOFTWARE MODEL

4.4 FEASIBILITY STUDY

4.4.1 ECONOMIC

4.4.2 TECHINCAL

4.4.3 OPERATIONAL

4.4.4 LEGAL

4.4.5 ORGANISATIONAL

4.4.6 ENVIRONMENTAL

CHAPTER 5 CODING 48-94

CHAPTER 6 OUTPUT 95-106

CHAPTER 7 TESTING 107-112

CHAPTER 8 CONCLUSION 113-115

CHAPTER-9 BIBILOGRAPHY 116-118

8/2/2019 hms.new C++

6/117

6

CHAPTER-1

8/2/2019 hms.new C++

7/117

7

INTRODUCTION

8/2/2019 hms.new C++

8/117

8

ABOUT THE PROJECT

A Hospital Management System is an automated software system that

manages the function of a health care. The presented project here is made in view

overcoming the problems faced by many Hospitals regarding Maintaining patient

records , Recording and keeping of Doctors information, Bed management ,

Report generation etc. i.e. General HMS Automation.

This project can be widely used in any Hospital which contains

different departments with various employees having different designations etc.

HMS not only provides an opportunity to the hospital to enhance their patient care

but also can increase the profitability of the organization.

About the Organization

A Hospital normally contains information about patient. A hospital

management system normally contains the following parts:-

Patient Admission

Patient admission means capturing information of all the patients

visiting the hospital and provides record of all the registered patients through a

unique patient identification number or room number.

View details of patients

It views the details of existing patients by registration number.

Searching process

Search the details of patients by city or by blood group.

Delete record:

Delete the record of patients by registration number.

8/2/2019 hms.new C++

9/117

9

Our Vision:

We shall define ourselves in the cutting edge technology in the

coming era.

We shall create honest working environment with see-through-glass

planning.

Our Mission:

To create opportunity for growth & self actualization and provide an

environment of highly conducive works culture.

OBJECTIVE OF THE PROJECT

PROJECT RECORD MAINTENANCETo maintain the proper details of hospital management system

provides the following: Admission, list of patients, adding doctors, record of

patients, modify details, discharge of patients so on under various provision

provided by the management.

MAINTAIN FLEXIBILITIES

The system should be modified depending on the changing needs of

the user such modification should be entire reconstructing on recreation of

software. It should also be portable to different computer system.

INCREASE PRACTICABILITY

The system should be a stable and can be operated by people with

average intelligence means it should be user friendly.

INCREASE EFFICIENCY

This project involves accuracy, timeliness & comprehensiveness of

the system output.

COST

It is desirable to aim for a system with a minimum cost subject to the

condition that must satisfy all the requirements.

MAINTAIN THE SECURITY

This is very important aspect of the design and should cover areas ofhardware reliability, physical security of data.

8/2/2019 hms.new C++

10/117

10

PROPOSED SYSTEM

In the proposed system transactions are made at the time of admission of the patient

or to get the information from previous records. It is basically a deal between the

hospital management and the patient that are included in the system at the time of

admission. The full detail about every patient is maintained in the transaction like.

Patient Record Details of existing patients Searches the details of patients by city or by blood group Delete the records

ADVANTAGES OF PROPOSED SYSTEM

This package is designed by taking all the aspects and need of hospitalmanagement system.

This system is easy to handle and easy to maintain. The front page of the software provides easy selection of options and thus

easy access to the capabilities of the system.

The system is also very flexible; the changes required are made in very lesstime and resources of the user. So, it is very advantages to the user that

modification is easy to handle.

The system is capable of printing all the reports timely and accurately which a

manual system cant.

8/2/2019 hms.new C++

11/117

11

CHAPTER -2

8/2/2019 hms.new C++

12/117

12

WHY C++ IS USED FOR MAKING THIS PROJECT

8/2/2019 hms.new C++

13/117

13

WHY C++ IS USED FOR MAKING THIS PROJECT?

C++ is an ideal programming language for developing professional

application for any organization. Object Oriented Programming (OOP) has

become the preferred programming approach by the software industries, as it

offers a powerful way to cope the complexity of real world problems. C++ is atype of computer language created in 1983 by Bjarne Stroustrip; C++ was

designed to serve as an enhanced version of the C programming language. C++ is

Objected Oriented Programming language and is considered a high level

language. Object oriented programming allows decomposition of a problem into a

number of entities called objects and then builds data and functions around these

objects.

Object - A ObjectB

ObjectC

The organization of data and functions in objectoriented programs

is shown in fig. the data of an object can be accessed only the functions associated

with that object. However, functions of an object can access the functions of other

objects.

Data

Functions

Data

Functions

Communication

Functions

Data

8/2/2019 hms.new C++

14/117

14

ADVANTAGES OF C++

New programs would be developed in less time because old code canbe reused.

Creating and using new data types would be easier in C++ than in C

The memory management under C++ would be easier and moretransparent.

Programs would be fewer bugs prone, as C++ uses a stricter syntaxand type checking.

Data hiding the usage of data by one program part while other programbeing easier to implement with c++.

8/2/2019 hms.new C++

15/117

15

CHAPTER-3

8/2/2019 hms.new C++

16/117

16

SOFTWARE REQUIRMENT

SPECIFICATION

8/2/2019 hms.new C++

17/117

17

System

Description

Analysis

Model

Design

Model

REQUIREMENT SPECIFICATION

Requirement specifications are very important part of the software

development project. IT requires the understanding of the whole project and its

objectives and hence we can say that requirement specification evolves out of the

requirement analysis task, which species what is to be done. Both softwaredeveloper and customer conduct review of a software requirement specification.

The software requirement specification is produced at the culmination of the

analysis task. Software project constraints:

1. The process should not be too cumbersome to handle.2. Economically viable.

REQUIREMENT ANALYSIS

Requirement analysis results in the specification of softwares operational

characteristics; indicates softwares interface with other system elements and

establishes constraints that software must meet. Requirement analysis allows thesoftware engineer (sometimes called an analyst or modeler in this role) to elaborate

on basic requirements established during earlier requirement engineering tasks and

build, models that depict user scenario, functional activities, problem classes and

their relationships, System and class behavior, and the flow of data as it is

transformed.

Throughout analysis modeling, the software engineers primary focus is on

What objects does the system manipulate. What functions must the system perform? What behavior does the System exhibit. What interfaces are defined. What constraints apply?

OBJECTIVES OF ANALYSIS MODEL

To describe what the customer requires. To establish a basis for the creation of a software design. To define a set of requirements that can be validated once the software is

built.

Analysis model bridges the gap between a system- level, description thatdescribes overall system functionality as it is achieved by applying software,

8/2/2019 hms.new C++

18/117

18

hardware, data, human and other System elements and a software design that

describes the softwares application architecture, user interface and component

level structure.

REQUIREMENT DOCUMENTATION

Requirement documentation is very important activity after the requirements

elicitation and analysis. This is the way to represent requirements in a consistent

format. Requirement documents are called software Requirements Specification

(SRS).

The SRS is a specification for a particular software product, program or set

of programs that performs certain functions in a specific environment. It serves a

number of purposes depending on who is writing it. First, the SRS could be written

by the customer of a System second, the SRS could be written by developer of the

system. The two scenarios establish different purpose and serves as a contract

document between customer and developer.

CONSIDERATION FOR PRODUCING A GOOD SRS

a) Nature of the SRS ;b) Environment of the SRS ;c) Characteristics of a good SRS ;d) Joint preparation of the SRS ;e) SRS evolution ;f) Prototyping ;g) Embedding design in the SRS ;h) Embedding project requirement in the SRS ;

NATURE OF THE SRS

The SRS is a specification for a particular software product, program , or set of

programs that performs certain functions in a specific environment .The SRS may

be written by one or more representative of the supplier ,one or more

representatives of the customer, or both.

The basic issues that the SRS writer(s) shall address are the following:

8/2/2019 hms.new C++

19/117

19

1) FUNCTIONALITY: What software is supposed to do?

2) EXTERNAL INTERFACES: How does the software interact with people,the Systems hardware, other hardware and other software?

3) PERFORMANCE: What is the speed availability, response time, recoverytime, etc of various software functions?

4) ATTRIBUTES: What are the considerations for portability, correctness,maintainability, security, reliability etc?

5) DESIGN CONSTRAINTS IMPOSED ON AN IMPLEMENTATION:Are there any required standards in effect, implementation language,

policies for dbase integrity, resource limits, operating environments etc.

ENVIRONMENT OF THE SRS

It is important to consider the part that the SRS plays in the total project plan. The

software may contain essentially all the functionality of the project or it may be

part of a larger system.

The SRS has a specific role to play in the software development process, the SRS

writer(s) should be careful not to go beyond the bounds of that role. This means

the SRS

a) Should correctly define all of the software requirements. A softwarerequirement may exit because of the nature of the task to be solved or because of

a special characteristic of the project.

b) Should not describe any design or implementation details .These should bedescribed in the design stage of the project.

c) Should not impose additional constraints of the software. These areproperly specified in other documents such as a software quality assurance

plan,

8/2/2019 hms.new C++

20/117

20

CHARACTERISTICS OF GOOD SRS

An SRS should be

a) Correct ;

b) Unambiguous ;c) Complete ;d) Consistent ;e) Ranked for importance and stability ;f) Verifiable ;g) Modification ;h) Traceable ;

JOINT PREPARATION OF THE SRS

The software development process should begin with supplier and customeragreement on what the completed software must do. This agreement, in the form

of the SRS, should be jointly prepared. This is important because usually neither

the customer nor the supplier is qualified to write a good SRS alone.

Customers usually do not understand the software design anddevelopment process well enough to write a usable SRS.

Suppliers usually do not understand the customers problem and field ofendeavor well enough to specify requirements for a satisfactory system.

Therefore, the customer and the supplier should work together to produce a well

written and completely understood SRS.

SRS EVOLUTION

The SRS may need to evolve of the development as the software product

progresses. It may be impossible to specify some details at the time the project is

initiated. Additional changes may ensue as deficiencies, shortcomings, and

inaccuracies are discovered in the SRS.

Two major considerations in this process in the following:

a. Requirements should be specified as completely and thoroughly as isknown at the time, even if evolutionary revisions can be foreseen as

inevitable. The fact that they are incomplete should be noted.

b. A formal change process should be initiated to identify, control, track, andreport projected changes.

Approved changes in requirement should be incorporated in the SRS in such a

way as to

1. Provide an accurate and complete audit trail ofchanges;

2. Permit the review of current and supersedesportions of the SRS.

8/2/2019 hms.new C++

21/117

21

PROTOTYPING

Prototyping is used frequently during the requirements portion of a project. Many

tools exist that allow a prototype, exhibiting some characteristics of a system, to

be created very quickly and easily.

Prototypes are useful for the following reasons:

a. The customer may be more likely to view the prototype and react to itthan to read the SRS and react to it. Thus, the prototype provides quick

feedback.

b. The prototype displays unanticipated aspects of the systems behavior.Thus, it produces not only answers but also new questions. This helps

reach closure on the SRS.

c. An SRS based on a prototype tends to undergo less change duringdevelopment, thus shortening development time.

EMBEDDING DESIGN IN THE SRS

A requirement specifies an externally visible function or attribute of a system .A

design describes particular subcomponents of a system and its interfaces with

other subcomponents. The SRS writer(s) should clearly distinguish between

identifying required design constraints and projecting a specific design.

The SRS should specify what functions are to be performed on what to produce

what results at what location for whom. The SRS should focus on the services to

be performed. The SRS should not normally specify design items such as the

following:

a. Partitioning the software into modules ;b. Allocating functions to the modules ;c. Describing the flow of information or control between modules ;d. Choosing data structures.

NECESSARY DESIGN REQUIREMENT

In special cases some requirements may severely restrict the design. For example,security or safely requirement may reflect directly into design such as the need to;

a. Keep certain functions in separate modules ;b. Permit only limited communication between some areas of the programs;c. Check data integrity for critical variables.

8/2/2019 hms.new C++

22/117

22

EMBEDDING PROJECT REQUIRMENTS IN SRS

The SRS should address the software product, not the process of producing the

software product.

Project requirements represent an understanding between the customer and thesupplier about contractual matters pertaining to production of software and thus

should not be included in the SRS. The normally include items such ass

a. Costb. Delivery schedules;c. Reporting procedures;d. Software development methods;e. Quality assurance;f. Validation and verification criteria;g. Acceptance procedures.

Project requirement are specified in other document, typically in a software

development plan, a software quality assurance plan, or a statement of work.

SOFTWARE REQUIREMENT SPECIFICATION

STEP I:

PRODUCT OVERVIEW AND SUMMARYThe project titled Hospital Management System has been prepared

for removing the time consuming manual systems. This package is designed by

taking all the aspects and need of hospital using system which is very easy to handle

and easy to maintain. Basically the purpose of this project is to provide necessary

things like individual admission, discharge, availability of rooms etc. to each and

every patient in a computerized form, so that no patient has to wait in a long queues

for admission and discharge as they did earlier.

STEP II:

DEVELOPMENT,OPERATING AND MAINTENANCE ENVIRONMENTThe development, operating and maintenance environment of the

product consists of the following:

SOFTWARES REQUIREMENTS

1. Operating System: - Windows 98, 99, 2000, XP, NT

2. C compiler : - Turbo, Borland

8/2/2019 hms.new C++

23/117

23

HARDWARE REQUIREMENTS

SYSTEM TYPE : Pentium

MEMORY : 256 MB

HARD DISK : 20 GB

PRINTER : LASER

STEP III :

FUNCTIONAL REQUIRMENTSSince, the project is prepared on the computerized Hospital

Management System and the end user who will use this software must have some

basic knowledge. So, a good level of user friendliness is the requirement.

STEP IV :

PERFORMANCE REQUIREMENTSThe records in it should not overlap and we can able to get the

record by providing the room number and somehow the proper security of all the

records should be maintained.

STEP V :

EXCEPTIONAL HANDLING

The software must be able to display proper error messages

in case if some error encounters.

STEP VI :

FORESEEABLE MODIFICATIONS AND ENHANCEMENTS

This project is very flexible i.e. we can modify it in future in

case if some need arises.

8/2/2019 hms.new C++

24/117

24

CHAPTER -4

8/2/2019 hms.new C++

25/117

25

SYSTEM ANALYSIS & DESIGN

8/2/2019 hms.new C++

26/117

26

SYSTEM ANALYSIS

System analysis describes the detailed description of the scenario, and the

functioning of the system. The transaction and input/output requirements are also

presented. The problems in the current system are discussed and the necessaryimprovements are recommended.

Systems Development can generally be thought of as having two major

components:

o System Analysis

o System Design

System Design:

System Design is the process of planning a new business system or one

to replace or complement an existing system. But before this planning can be

done, we must thoroughly understand the old system and determine how computers

can best be used (if at all) to make its operation more effective.

System Analysis:

System Analysis is the process of gathering and interpreting facts,

diagnosing problems, and using the information to recommend improvements to the

system.

8/2/2019 hms.new C++

27/117

27

DATA FLOW DIGRAM

8/2/2019 hms.new C++

28/117

28

DATA FLOW DIAGRAM

: Data flow diagram is means of representing a system at any level of

details with a graphic network of symbols showing data flows, data

processes, and data sources/ destinations.

The DATA FLOW DIAGRAM shows the flow of data or information. It

can be partitioned into single processes or functions .Data flow diagrams

can be grouped together or decomposed into multiple processes. There can

be physical DFD's that represent the physical files and transactions, or

they can be business DFD's.

A DFD, also know as "bubble chart", serves the purposes of clarifying

system requirements and identifying major transformations that will

becomes programs in system design. So it is the starting point of the

design phase that functionally decomposes the requirement specification

down to the lowest level of details. A DFD consists of a series of bubbles

joined by lines .The bubbles represent data transformation and lines

represent data flows in the system. The DFD is a representation of various

processes and the input and output in each process.

Graphical description of a system's data and how the processes

transform the data is known as DATA FLOW DIAGRAM (DFD).

PURPOSE /OBJECTIVE

The purpose of data flow diagrams is to provide a semantic bridge

between users and systems developers. The diagrams are:

Graphical representations that eliminate the need for writing

thousands of words ;

Logical representations, modeling WHAT a system does, rather

than physical model s showing HOW it does it;

Hierarchical representations, showing system at any level of

details ; and

8/2/2019 hms.new C++

29/117

29

JargonLess representation, allowing easy understanding and reviewing.

The goal of data flow diagramming is to have a commonly understood

model of a system. The diagrams bare the basis of structured system

analysis .Data flow diagrams are supported by other techniques of

structured systems analysis such as data structure diagrams, data

dictionaries and procedure-representing techniques such as decision table

and structured English. Data flow diagrams have the objectives of

avoiding the cost of:

User /developer misunderstanding of a system ,resulting in a need

to redo systems or in not using the systems or in not using the

system;

System inefficiencies because a system get computerized before

it gets systematized;

Being unable to evaluate system project boundaries or degree of

automation, resulting in a project of inappropriate scope.

COMPONENTS OF DATA FLOE DIAGRAMS

Data flow diagrams are composed of the four basic symbols shown below.

Any system can be represented at any level of detail by these four symbols

8/2/2019 hms.new C++

30/117

30

The EXTERNAL ENTITY symbol represents sources of data to

the system or destinations of data from the system.

The DATA FLOW symbol represents movement of data.

The PROCESS symbol represents an activity that transforms ormanipulates the data.

NAMING CONVENTIONS IN DFD

Each component in a data flow diagram is labeled with a descriptive

name. Process names are further identified with a number that will be used

for identification purposes. The number assigned to a specific process

does not represent the sequence of processes. It is strictly for identification

and will take on added value when we study the components that make up

a specific process.

The name of data stores, sources and destination are written in capital

letters. Process and data flow names have the first letter of each work

capitalized.

The names of the processes must clearly explain the actual task being

performed in the process.

DEVELOPING A DFD

To be useful and informative, DFD must be drawn properly. In this section

we shows, how to draw them: where to start, how to add details to

description, how to be consistent in naming items included in the

diagrams. The discussion also points out common mistakes that should be

avoided.

8/2/2019 hms.new C++

31/117

31

DEVELOPMENT PROCESS

System analysts must first study the current systems, that is, the actual

activities and processes that occur. In the terminology of structured

analysis, this is the study of physical system. The physical system is

translated into logical descriptions that focus on data and processes. It is

advantageous to emphasize data and processes in order to focus on actual

activities that occur and the resources needed to perform them, rather than

on who performs the work.

These are EXAMPLES of physical system details

Department Copy room or building location

Person Step number

Files Procedure

During data flow analysis, these details are evaluated in terms of the

logical components of data flows, processes, data stores, origins and

destinations.

During the design stages that follow, system requirements are translated

into logical design details. Actual construction, such as the programming

of computer software, translates logical specifications into physical

features and a working information system.

CONTEXT DIGRAM

The context diagram is the top level DFD .It represents a system as a

single process with only major inputs and outputs to the system

represented as data flows. The source and destination of the data as

external are also represented.

8/2/2019 hms.new C++

32/117

32

LEVEL 1 AND HIGHER LEVEL DFD

When we explode the context diagram and break the single process into a

number of detailed processes, then 1DFD is created. Further breaking of

each process leads to further levels of level DFDs. The numbering

convention in the DFD is as follows.

In the context diagram, no number is given to processes as only

one process exists.

In the level 1 DFD, the processes are numbered as 1, 2, and 3.

In the next level, the processes are numbered depending on which

process has been broken. For example, if process 2 of level 1 DFD

level is broken, the processes are numbered as 2.1, 2.2 and so on.

The processes are numbered as 3.2.1, 2.3.2.1 and so on as further

levels of DFD are created.

THE RULES OF THUMB IN DRAWING DFDs ARE:

1. Process should be named and numbered for easy reference.

Each name should be representative of the process.

2. The direction of flow is from top to bottom and from left to

right. Data traditionally flows from the source to the

destination, although they may flow back to a source. An

alternative way is to repeat the source symbol as a destination.

Since, it is used more than once in the DFD, it is marked with a

short diagonal in lower right corner.

3. When the process is exploded into lower level details, they are

numbered. The sub-levels are numbered on the basis of their

parent process number.

4. The names of data stores, sources, destinations must be in

capital letters while the names of processes and data flows

must start with a capital letter.

8/2/2019 hms.new C++

33/117

33

O LEVEL DFD

Figure 6.2

INFORMATION

REQUEST

FEEDBACK

Infirmary

Services REGISTRATION

DATAFILE

EN UIRY

PATIENT-

8/2/2019 hms.new C++

34/117

34

1-LEVEL DFD

SEARCH ADD RECORDFOR

RECORD

Figure 6.3

REQUEST

FEEDBACK

DATABASE

ENQUIR

PATIENT

Infirmary

Services

INFORMATION

DOCTOR

INFORMATION

UPDATE

SYSTEM

8/2/2019 hms.new C++

35/117

35

FLOW CHART (MENU)

Y

N

N

N Y

N

N

Y

N

Figure 6.4

WELCOME SCREEN

Option to OP

IfOP=1

If OP=2

If

OP=3

If

OP=4

STOP

START

INSTALL

Patients Record

Show Patients Detail

Exit

8/2/2019 hms.new C++

36/117

36

Hospital

management

system

nnnnnnnNew

patient

informationNew patient

info. system

View details

of patient

process

Search

processdelete

Patient record

accepted process

View detailsof patient

Request to

enter newpassword Requests t o

view detailsRequests

to search

Requests to delete

a record

Accepts thedetails

Search by

city process

Search by bloodgroup process

Delete recordprocess

Accepts registration no.

By

city

By blood group Accepts

registration .no

Gives details

process

user

Patient record database

Gives details

Storesrecords Acceptscity

Accepts blood group

8/2/2019 hms.new C++

37/117

37

HOSPITAL

MANAGEMENT

SYSTEMUSER

REQUESTS TOENTIRE NEW

PATIENT INFO

VIEW DETAILS OF

EXITING PATIENT

SEARCH BY

CITY BLOOD

GROUP

GIVES

RESULT

GIVES

RESULT

USER

PRINTER

8/2/2019 hms.new C++

38/117

38

HIERARCHY DIAGRAMS

8/2/2019 hms.new C++

39/117

39

HIERARCHY DIGRAMS

The Hierarchy Diagram begins at the Top Level with the Main Module. The Main

Module represents aprograms main routine and is the highest module that

controls the overall logic of the program. The other modules in the HierarchyDiagram may be considered as Sub Modules of the controlling or main module

and they are performed when the Main Module CALLs or PERFORMs them

and they then return control to the Main Module when their logic is complete.

HOSPITAL

MANAGEMENT SYSTEM

NEW PATIENT

INFORMATIOM

SYSTEM

REGISTRATION

NUMBER

NAME

MARTIAL

STATUS

ADDRESS

DATE OF

BIRTH

BLOOD

GROUP

DETAILS OF

EXITING

PATIENT

SEARCHING

PATIENT

DELETE

RECORD

BY

REGISTRATION

NUMBER

BLOOD CITY

SEX

8/2/2019 hms.new C++

40/117

40

SOFTWARE MODEL

8/2/2019 hms.new C++

41/117

41

SOFTWARE MODEL

WATERFALL MODEL

Waterfall model sometimes called classic life cycle, suggests a Systematicsequential approach to software development that begins with customer

specification of requirements and progresses through planning, modeling,

construction and deployment, culminating is on going support of the completed

software.

The waterfall model is a popular version of the system development life

cycle model for software engineering. Waterfall development has distinct goals for

each phase of development.

THE WATERFALL MODEL

COMMUNICATIO

N project

Initiation

requirements

gatheringPLANNING

Estimating

Scheduling

TrackingMODELING

Analysis

Design CONSTRUCTION

Code

Test

DEPLOYMENT

Delivery

Support

Feedback

8/2/2019 hms.new C++

42/117

42

PHASES OF WATERFALL MODEL

This model has five phases:

Requirement analysis and specification. Design Implementation and unit Testing Integration and system testing. Operation and maintenance.

The phases always occur in this order that they do not overlap. The

developer must complete each phase before the next phase begins. This model is

named Waterfall Model because its diagrammatic representation resembles a

cascade of waterfalls.

REQUIREMENT ANALYSIS AND SPECIFICAION PHASE

The goal of this phase is to understand the exact requirements of the

customer and to documents them properly. This activity is usually executed

together with the customer, as the goal is to document all functions, performance

and interfacing requirements for the software. The requirements describe the what

of a system, not the how. This phase produces a large document, written in a

natural language, contains a description of what the System will do without

describing how it will be done. The resultant document is known as software

requirement specification document (SRS).

Requirement analysis

and specification

Design

Implementation and

unit testing

Integration and system

Testing

Operation and

Maintenance

8/2/2019 hms.new C++

43/117

43

DESIGN PHASE:

The SRS document contains the exact requirements of the customer. The

goal of this phase is to transform the requirements specification into a structure that

is suitable for implementation in some programming language. Here overallsoftware architecture is defined, and the high level and detailed design work is

performed. This work is documented and known as software design description

(SDD) document. The information contained in the SDD should be sufficient to

begin the coding phase.

IMPLEMENTING AND UNIT TESTING PHASE :

During this phase, design is implemented. If the SDD is complete, the

implementation or coding phase proceeds smoothly, because all the information

needed by the software developers is contained in SDD. During testing, the major

activities are centered the exam and modification of code. Initially, small modulesare tested in isolation from the rest of the software product. The problem that are

encountered while testing a module in isolation are solved in this phase and

modules are tested after writing some overhead code.

INTEGRATION AND SYSTEM TESTING PHASE :

This is a very important phase effective testing will contribute to the

delivery of higher quality software products, more satisfied users, lower

maintenance costs and more accurate and reliable results. Unit testing is used for

implementing each independent module correctly, due to which there are less

chances that whether the interface between modules are correct, for this reason

integration testing is performed. System testing involves the testing of the entire

System, where as software is the part of the System.

OPERATION AND MAINTENANCE PHASE :

Software maintenance is a task that every development group has to face,

when the software is delivered to the customers site, installed and is operational.

Therefore, release of software inaugurates the operation and maintenance phase of

the life cycle. Software maintenance includes error correction, enhancement ofcapabilities, deletion of obsolete capabilities and optimization. The purpose of this

phase is to preserve the value of the software over time

MODEL CHOSEN

The model chosen for this project is Waterfall Model because of the

following reasons:-

8/2/2019 hms.new C++

44/117

44

ADVANTAGES OF WATERFALL MODEL

It can serve as a useful process model in situations where requirements arefixed and work is to proceed to completion in a linear manner.

Testing is inherent to every phase of the waterfall model. It is a simple and elegant model which can be used in testing projects. It is an enforced disciplined approach It is not costly It is documentation driven, i.e. documentation is produced at every stage.

FEASIBILITY STUDY

All the projects are feasible given unlimited resources and infinite time.

Unfortunately, the development of a computer based system is more likely to beplayed by a scarcity of resources and difficult delivery date. It is both necessary and

prudent to evaluate the feasibility of a project at the earliest possible time. In the

development of the present project, no such limitation was imposed that was not

feasible, s all the resources where easily available and time given was sufficient

enough.

OBJECTIVES OF FEASIBILITY STUDY

What are the problems with conventional System? What are the solutions available to overcome these problems? What are the goals and sub goals of the proposed System? What the proposed System would be achieved? Who all should be involved in the administering the System? The benefits, the System will give over the conventional System? The estimated cost of the implementation. The estimated time needed to develop and implement the proposed System?

1. ECONOMIC FEASIBILITY

This involves questions such as whether the form can afford to built the

system, whether its benefits should substantially exceed its costs, and whether theproject has higher priority and profits than other projects that might use the same

resources.

Since, our project is made on C++ it is not very costly as it is very common

available software. We dont need any extra software or hardware requirements or

any GUI (Graphic user interface)

2. TECHNICAL FEASIBILITY

This involves question such as whether the technology needed for the

system exists, how difficult it will be to build and whether the firm has enough

experience using that technology.

8/2/2019 hms.new C++

45/117

45

The software made is on C++ which is a very common language, so we can

get the experienced persons in it very easily.

3. LEGAL FEASIBILITY

All projects must face legal scrutiny. When an organization either has legal

council on staff or on retainer, such reviews are typically standard. However, any

project may face legal issue after completing too. Our software is legally feasible.

4. ORGANISATIONAL FEASIBILITY

This involves question such as whether the System has enough support to be

implemented successfully, whether it brings an excessive amount of change, andwhether the organization is changing too rapidly to absorb it.

Since, it is a very small project its purpose is for submission of BCA (3

year) degree and all the members are equally include for the submission of project.

So, there is a good Coordinating among all the members.

5. ENVIRONMENTAL FEASIBILITY

People are inherently resistant to change and computers have been known to

facilitate change. An estimate should be made of how strong a reaction the user

staff is likely to have towards the development of a computerized system.

8/2/2019 hms.new C++

46/117

46

CHAPTER -5

8/2/2019 hms.new C++

47/117

47

CODING

8/2/2019 hms.new C++

48/117

48

/*

**************************************************

* Project: *

* Simulation of hospital Management Software *

**************************************************

*/

#include //for input and output stream regulation

#include //for exit ()

#include //for strlen () and strcmp ()

#include //for getch () and clrscr ()

class all //declaration for class "all"

{

private:

struct address

{

int house;

char city[30];

char state[30];

char street[30];

char country[30];

};

struct age

{

int day;

int month;

int year;

};

struct patient_info

{

age A1; //nested structure inplemented

address AD1; //nested structure implementedint sex;

int reg_no;

int bld_group;

char name[50];

int martial_status;

}PI[100];

int task;

protected: //functions declared

void search_menu();

void search_city();

void exit_function();void search_show_info();

8/2/2019 hms.new C++

49/117

49

void search_blood_group();

void enter_patient_info();

void show_patient_detail();

void after_search_options();

void after_restore();

public:void tasks();

void recycle_bin();

void delete_entry();

void software_detail();

void after_delete_options();

int s_group;

int s_choice;

int en_del_index;

int delete_choice;

char ch;

char answer;char answer1;

char s_city[30];

char exit_answer;

char delete_confirm;

char after_search_answer;

}; //end of class "all"

class date //declaration for class "date"

{

private:

int date;

int month;

int year;

public:

void enter_date();

void show_date();

}; //end of class "date"

class dob //declaration for class "dob"

{

private:struct dob1

{

int date;

int month;

int year;

int rem;

}DOB11[100];

public:

char birth_answer;

void show_date();

void enter_date();void search_show_date();

8/2/2019 hms.new C++

50/117

50

}; //end of class "dob"

class temp //declaration for class "temp"

{

public:

int m; //temporary variables declared with global scopeint i;

int j;

int k;

int d;

int e;

int f;

int rem;

int temp;

int count;

int regis;

int index;int entry;

int serial;

int attempt;

int current;

int d_index;

int ssi_count;

int show_count;

int delete_show;

int search_index;

int search_count;

int current_year;

int delete_count;

int search_number;

int restore_serial;

int delete_attempt;

int restore_attempt;

int entry_index[100];

int after_search_choice;

int after_restore_choice;

char enter_now;

char restore_confirm;char duplicate_answer;

char delete_all_confirm;

char restore_all_confirm;

char after_search_answer;

temp() //constructor for temp invoked

{

i=0;

j=0;

d=0;

e=0;

f=0;serial=0;

8/2/2019 hms.new C++

51/117

51

current=0;

d_index=0;

ssi_count=0;

show_count=0;

delete_show=0;

delete_count=0;delete_attempt=0;

restore_attempt=0;

} //end of constructor for temp

//destructor for temp invoked

}; //end of class "temp"

all A1; //object for class "all" declared

date D1; //object for class "date" declared

dob DOB1; //object for class "dob" declared

temp T1; //object for class "temp" declared

void main() //main function

{

T1.count=0;

for(T1.m=1;T1.m

8/2/2019 hms.new C++

52/117

52

couttask;

switch(task)

{

case 1:{

A1.enter_patient_info();break;

}

case 2:{

A1.show_patient_detail();

break;

}

case 3:{

A1.search_menu();

break;

}

case 4:{A1.delete_entry();

break;

}

case 5:{

A1.recycle_bin();

break;

}

case 6:{

A1.software_detail();

break;

}

case 7:{

A1.exit_function();

break;

}

default:{

clrscr();

cout

8/2/2019 hms.new C++

53/117

53

while(year10000)

{

clreol();

cout

8/2/2019 hms.new C++

54/117

54

clreol();

cin>>date;

}

}

else

{while(date28) //for non-leap year

{

cout

8/2/2019 hms.new C++

55/117

55

}

}

switch(T1.rem)

{

case 1:{

cout

8/2/2019 hms.new C++

56/117

56

break;

}

case 8:{

cout

8/2/2019 hms.new C++

57/117

57

cout

8/2/2019 hms.new C++

58/117

58

{

A1.tasks();

}

}

}

} //end of "for loop" to prevent duplicate entriescoutPI[T1.i].sex;

while(PI[T1.i].sex!=1&&PI[T1.i].sex!=2)

{

cout

8/2/2019 hms.new C++

59/117

59

switch(PI[T1.i].bld_group)

{

case 1:

case 2:

case 3:

case 4:case 5:

case 6:

case 7:

case 8:{

break;

}

default:{

while(PI[T1.i].bld_group!=1&&PI[T1.i].bld_group!=2&&

PI[T1.i].bld_group!=3&&PI[T1.i].bld_group!=4&&

PI[T1.i].bld_group!=5&&PI[T1.i].bld_group!=6&&

PI[T1.i].bld_group!=7&&PI[T1.i].bld_group!=8){

clreol();

cout

8/2/2019 hms.new C++

60/117

60

{

clreol();

cout

8/2/2019 hms.new C++

61/117

61

while(answer!='Y'&&answer!='y'&&answer!='N'&&answer!='n')

{

clrscr();

coutanswer;}

cout

8/2/2019 hms.new C++

62/117

62

coutbirth_answer;

cout

8/2/2019 hms.new C++

63/117

63

} //end of inner while

} //end of outer while

jump:

clreol();

coutDOB11[T1.temp].month;

while(DOB11[T1.temp].month12)

{

clreol();

cout

8/2/2019 hms.new C++

64/117

64

cin>>DOB11[T1.temp].date;

cout

8/2/2019 hms.new C++

65/117

8/2/2019 hms.new C++

66/117

66

cout

8/2/2019 hms.new C++

67/117

67

cout

8/2/2019 hms.new C++

68/117

68

}

case 4:{

clreol();

cout

8/2/2019 hms.new C++

69/117

69

cout

8/2/2019 hms.new C++

70/117

70

}

} //end of switch

switch(T1.rem)

{

case 1:{

cout

8/2/2019 hms.new C++

71/117

71

break;

}

case 8:{

cout

8/2/2019 hms.new C++

72/117

72

cout

8/2/2019 hms.new C++

73/117

73

{

clreol();

cout

8/2/2019 hms.new C++

74/117

74

break;

}

default:{

clreol();

cout

8/2/2019 hms.new C++

75/117

75

getch();

A1.after_search_options();

}

if(T1.search_count>1)

{

cout

8/2/2019 hms.new C++

76/117

76

for(T1.index=1;T1.index

8/2/2019 hms.new C++

77/117

77

cin>>after_search_answer;

}

if(after_search_answer=='y'||after_search_answer=='Y')

{

coutT1.index;A1.search_show_info();

}

else

{

A1.after_search_options();

}

}

else

{

coutT1.index;A1.search_show_info();

}

} //end of function

void all::search_show_info()

{

T1.ssi_count++;

clrscr();

cout

8/2/2019 hms.new C++

78/117

78

} //end of switch

}

if(T1.entry_index[T1.index]==0)

{

if(T1.ssi_count==3)

{clrscr();

cout

8/2/2019 hms.new C++

79/117

79

{

case 1:{

A1.search_city();

break;

}

case 2:{A1.search_blood_group();

break;

}

} //end of switch

}

clreol();

cout

8/2/2019 hms.new C++

80/117

80

case 4:{

clreol();

cout

8/2/2019 hms.new C++

81/117

81

cout

8/2/2019 hms.new C++

82/117

82

case 19:

case 20:{

cout

8/2/2019 hms.new C++

83/117

83

break;

}

case 7:{

cout

8/2/2019 hms.new C++

84/117

84

T1.ssi_count=0;

A1.search_menu();

break;

}

case 2:{

T1.ssi_count=0;A1.tasks();

break;

}

default:{

clreol();

cout

8/2/2019 hms.new C++

85/117

85

for(T1.j=1;T1.j

8/2/2019 hms.new C++

86/117

86

}

else

{

cout

8/2/2019 hms.new C++

87/117

87

if(en_del_index>0&&en_del_index

8/2/2019 hms.new C++

88/117

88

{

clrscr();

cout

8/2/2019 hms.new C++

89/117

89

{

A1.tasks();

}

}

cout

8/2/2019 hms.new C++

90/117

90

if(T1.entry_index[T1.e]==0)

{

T1.current++;

T1.entry_index[T1.e]=1;

}

}cout

8/2/2019 hms.new C++

91/117

91

getch();

A1.after_restore();

}

}

if(T1.entry_index[T1.restore_serial]==1)

{T1.restore_attempt++;

if(T1.restore_attempt==3)

{

clrscr();

cout

8/2/2019 hms.new C++

92/117

92

A1.recycle_bin();

break;

}

case 2:{

A1.tasks();

break;}

default:{

cout

8/2/2019 hms.new C++

93/117

93

cout

8/2/2019 hms.new C++

94/117

94

CHAPTRER-6

8/2/2019 hms.new C++

95/117

95

OUTPUT

8/2/2019 hms.new C++

96/117

96

8/2/2019 hms.new C++

97/117

97

8/2/2019 hms.new C++

98/117

98

8/2/2019 hms.new C++

99/117

99

8/2/2019 hms.new C++

100/117

100

8/2/2019 hms.new C++

101/117

101

8/2/2019 hms.new C++

102/117

102

8/2/2019 hms.new C++

103/117

103

8/2/2019 hms.new C++

104/117

104

8/2/2019 hms.new C++

105/117

105

8/2/2019 hms.new C++

106/117

106

CHAPTER-7

8/2/2019 hms.new C++

107/117

107

TESTING

8/2/2019 hms.new C++

108/117

108

TESTING

Testing is the process ofexecuting a program with the intent of finding

errors in software development process, errors can be injected at any stages

during development. There are various techniques that are used for detecting and

eliminating errors but no method is perfect because most of the verificationmethods of earlier phases are manual.

During testing, the program to be tested is executed with a test case is

evaluate to determine if the program is performing as expected. Testing is a set of

activities that can be planned in advance and conducted systematically. Its a

process of analyzing a software item to detect the difference between existing and

required conditions (i.e. bugs) and to evaluate the features of the software items.

Test case designs are constructed for each path and for all logical

decisions, and boundary values conditions. There are four paths in the process

flow and therefore four test case designs would be built to test path processing. Atest case will test whether logical decisions are made through condition testing

and on that result whether control of process moves to the appropriate branch.

The white-box testing can be applied to the operations defined for a class

basis path, loop testing, or data flow techniques can help to ensure that every

statement in an operation has been tested. However, the concise structure of many

class operations causes some to argue that the effort applied to white box testing

might be better redirected to tests at a class level.

Black box testing methods are as appropriate for Object Oriented System

as they are for Systems developed using conventional Software engineering

methods.

UNIT TESTING

Unit testing focuses verification effort on the smallest unit of software

design the software component or module. Using the component level design

description as a guide, important control paths are tested to uncover errors within

the boundary of the module. The relative complexity of tests and the errors those

tests uncover is limited by the constrained scope established for unit testing. The

unit test focuses on the internal processing login and data structures within theboundaries of a component. This type of testing can be conducted in parallel for

multiple components.

8/2/2019 hms.new C++

109/117

109

Module

Test Codes

Interface

Local data structures

Boundary Conditions

Independent paths

Error handling paths

The module interface is tested to ensure that information properly flows

into and out of the program unit under test local data structures are examined to

ensure that data stored temporarily maintains its integrity during all steps an

algorithm execution. All independent paths through the control structure are

exercised to ensure that all statements in a module have been executed at once.

For unit testing two testing techniques are applied: white box testing and

black box testing.

WHITE BOX TESTING

White box testing, sometimes called glass box testing, uses the flow and

control structure of the process to derive the test case design white box testing is

carried out to test whether .

a) All paths in a process are correctly operational.b) All logical decisions are executed with true or false conditions.c) All loops are executed with their limit values tested.d) To ascertain whether input data structure specifications are tested

and then used for other processing. In order to handle complexities

of unit level processing, test case designs are built after drawing

process flow charts and flow graphs.

8/2/2019 hms.new C++

110/117

110

1

3

PROCESS FLOW CHART PROCESS FLOW GRAPH

Logical

Sequence

Sequence

Loop

Logical

Design If

Process

stop

Logical design

Unit

Terminal case

While

Back to the next

Element of data

In a loop until.

Stop

Analysis of process flow chart reveals following process paths:-

Start -17stop Start1 -23 -34 - 8stop Start1236 - 1 (Loop) Start12351 (Loop)

BLACK BOX TESTING

Black box testing is also called behavioral testing, concentrates on

functions and features of the software. Black box testing is not an alternative to

white box testing, but is complementary to it. Black box testing confirms whether

for a give valid input, the software executes correctly to produce the required

results. Black box testing discovers errors that are not revealed by white boxtesting. The errors discovered through black box testing are:-

Start

54

6

8

7

Stop

Branching on

condition

8/2/2019 hms.new C++

111/117

111

Incorrect function

Missing function Interface errors not able to receive or send the data to other Systems.

Incorrect preconditions resulting into incorrect function processing Incorrect terminal conditions not responding to stoppage or continues to

execute the function.

Erroneous processing even though data structure is not correct.

8/2/2019 hms.new C++

112/117

112

CHAPTER-8

8/2/2019 hms.new C++

113/117

113

CONCLUSION

8/2/2019 hms.new C++

114/117

114

CONCLUSION

As a student of B.TECH 5th

sem I have done this project according to

my level of technical knowledge and expertise but in future this project can

be enhanced by using advanced technology so that it can become more userfriendly and technically advanced besides that more functionalities can also

be given to the software.

8/2/2019 hms.new C++

115/117

115

CHAPTER-9

8/2/2019 hms.new C++

116/117

116

BIBILOGRAPHY

8/2/2019 hms.new C++

117/117

BIBLOGRAPHY

BOOKS:

1. Roger S Pressman, Software Engineering and practitionersApproach, Tata Mc Graw Hill ,6

thedition.

2. Waman S Jawadekar, Software Engineering principles andpractice.

3. E. Balaguruswamy, Object Oriented Programming through C++

4. Timothy Budd, An Introduction to Object OrientedProgramming.

WEB:

www.c++projects.com

www.tatamcgrawhill.com

www.google.co.in