86464560-Hospital-Management-System.doc

1HOSPITAL MANAGEMENT SYSTEM

TABLE OF CONTENTS

1. Introduction 2. System Analysis 2.1 System Analysis Analysis 2.2 Identification 2.3 Preliminary Investigation 2.4 Feasibility Study 2.4.1 Technical Feasibility 2.4.2 !erational Feasibility 2.4.3 "conomical Feasibility 2.4.4 Social Feasibility

3. Soft#are "ngineering 3.1$aterfall 3.1$aterfall %odel

4. Soft#are &e'uirement S!ecification 4.1 Soft#are &e'uirement S!ecification 4.1.1 Introduction 4.1.2 Pur!ose of (evelo!ment


4.1.3 Sco!e of develo!ment 4.1.4 Functional re'uirement

4.1.) vervie# 4.1.* (escri!tion of S.&.S 4.1.+ ,ard#are Interface &e'uirement 4.1.- Performance &e'uirement

). (esign of System ).1 (esign bective ).2 (esign /once!ts ).2.1 To!0(o#n (esign ).2.2 ottom0! (esign

).3 Architectural (esign

).3.1 " & (iagram ).3.2(ata Flo# (iagram ).3.3/ontet (iagram ).3.4se case diagram ).3.)(ata (ictionary

*.Im!lementation +.Testing


+.1 Test obective +.2 Test /ase  Test /ase criteria +.3 lac5 bo testing +.4 $hite bo testing +.) oundary value analysis +.* Functional testing +.+ Structural testing +.- 6evels of testing +.-.1 nit testing +.-.2Integrated tesing +.-.3&egression testing +.-.4System and Acce!tance testing

-./onclusion 9.Future Scope


INTRODUCTION

In the era of high end Industrial gro#th and globali7ation8 local institutions9organi7ations9industries9com!anies9hos!itals are facing a stiff com!etition in the financial9 economical9 industrial mar5et. :e# Standards have to be ada!ted8 devised and follo#ed in order to meet the re'uirements and to 5ee! in !ace #ith the ever increasing #or5 and com!etition. The goals have shifted mainly from !erforming the cor!orate #or5 to !erforming cor!orate #or5 in an efficient and faster #ay. As a !art of this8 organi7ations today are more techno savvy and are investing large amount of time and money in automation and com!uteri7ation of the their #or5. As the need for com!uteri7ation increase8 com!uters have become the internal !art of increasing the gro#th rate of com!any;s !rogress due to the efficiency and s!eed #ith #hich they !erform the tas5. The management currently uses the conventional method of string the records in the registers. 6ots of !a!er #or5 is to be done #hich is very time consuming and is often !rone to errors.

For eam!le< $henever a Patient comes to ,os!ital for the registration8 he9she must fill the form filling all the details regarding them i.e. their name8 guardians; name8 bed ty!e etc. along #ith the residence !roof. After the verification of the data filled by the !atient or the relative8 it is !assed to net stage #here the re'uest is transferred to a staff for allotting the registration number8 after that the registration is !rovided to the !atients. This is a real time consuming system. %odification of records is also not so easy in the !resent system. "diting in the hand #ritten records ma5es it loo5 untidy and causes misunderstanding. In order to ma5e the system more convenient and !acify the dra#bac5s8 the system #as com!uteri7ed through a #indo#0based a!!lication serving the !ur!ose for eclusive.


DEFINING TE !RO"#E$ AI$S AND O"%ECTI&ES

%ain aims designated of the !roect are as follo#s< 1. 2. 3. 4.

Automation of all the activities of the /haritable ,os!ital to ma5e them ha!!en faster. It !ermits to add a ne# !atient record. =enerates the annual !atient number automatically. Also allo#s searching of some !articular records of the !atients on the basis of their names8 or the guardian;s name or date of admission. ). If the !atient tends to change the bed ty!e in bet#een its treatment schedule8 the changes are made accordingly. ur system su!!orts the same. *. $henever a ne# !atient is admitted to the charitable hos!ital8 then the ratio of the number of beds vacant to the number of beds occu!ied is u!dated. +. Stores !ersonal Information and contact addresses #ith !hone numbers of the doctors engaged #ith the charitable hos!ital -. Also hel!s in searching the details about a !articular doctor based on their names and s!eciali7ation. >. An a!!ointment for the o!eration can be made !rior to the date but before a month. 1?. It !ermits the !erson on des5 to edit the records for the !atients

HOSPITAL MANAGEMENT SYSTEM

ADVANTAGES OF PROPOSED SYSTEM The advantages of this ,os!ital %anagement System are given belo#< 1. It #ill reduce the burden of all the files8 as data can no# be stored in the database. 2. It can reduce the #or5 of the Staff that ust has to #or5 on soft#are no#. 3. The staff ust has to enter a 'uery to search the records and they can have the results in no time. 4. @ueries can be sorted out easily and 'uic5ly. ). &esult determination is done hand to hand. *. The System is develo!ed 5ee!ing in mind the benefits of the !atients. +. Timely access to Patient information. -. "asy !dating of records

As8 in current System the records are maintained manually. It ta5es a lot of time and the !rocess is very lengthy. So to increase our #or5 ca!acity #e need to com!uteri7e our ,os!ital %anagement System ,%SB. The ,%S covers all the aims and obectives of the charitable hos!ital #hich #ere 5e!t in mind earlier.

!HOSPITAL MANAGEMENT SYSTEM

ADDITIONA# FEATURES

A!art from the features mentioned above8 our system also !rovides the fullCfledged solution to all the !roblems of security8 such as< aB Secured' ur system is not ust a #al5 through. nly the !erson #ho is authori7ed or has the !ass#ord is allo#ed to access the system. bB #imited access' Since a charitable hos!ital consists of a number of em!loyees8 all of them can;t be granted com!lete access. Dee!ing this thing in mind system is designed as such so that only a fe# authori7ed or very im!ortant !eo!le li5e< Su!ervisorB are granted com!lete access to the system #ith the hel! of !ass#ord cB Easy to (andle' se of menu o!tions and other !oint and clic5 functions ma5e our a!!lication more accessible and easy to use even for the !eo!le #ith little 5no#ledge of com!uters. dB #imited )edit *eatures' Allo#s editing only a !art of Patient;s information. eB Automatic +eneration o* t(e disc(ar+e re,orts' (ischarge re!ort is automatically generated as #ell as !rinted that contains the case history !atient;s information8 reason of discharge etc. etc. #ith the total !ayable and non0!ayablealready !aidB accounts 8at the time #hen the !atient discharges. All the records are automatically deleted from the databases ece!t for the !atient history and general information. fB

If some money in advanced is de!osited on behalf of the !atient;s treatment8 the information regarding the advance money de!ositedB can be easily trac5ed.

"HOSPITAL MANAGEMENT SYSTEM

S-STE$ ANA#-SIS

System analysis is related #ith the information gathering i.e. analy7ing the system8 deciding #hich information is to be stored in the database8 and in #hich manner. ,ere #e had analy7ed the ,os!ital Information System. In analy7ing the system8 #e have to decide the entities about #hich #e have to store the information8 the attribute of these entities and relation bet#een these entities.

The system consists of the follo#ing entities<

1. 2. 3. 4. ). *. +.

PATI":T &"=IST&ATI: A(%ISSI: $A&( (/T& T"ST &"S6T I:EI/"


1#HOSPITAL MANAGEMENT SYSTEM

S-STE$ DE&E#O!$ENT #IFE C-C#E $ODE#

S(6/ model is a structured se'uence of !hases8 for im!lementing an information System. It contains a set of activities that a designer has to carry for System develo!ment. The life cycle model is not a !rocedure that deals #ith the hard#are and soft#are. 6ife cycle begins #ith the recognition of the user needs. It !rovides a basis for categori7ing and controlling the various activities re'uired to develo! and maintain a soft#are System. The 5ey stages of the life cycle are evaluation of the !resent System8 analysis8 design8 and im!lementation of the System.

1. System Analysis C In this !hase the analyst carry out a detailed study of the user;s re'uirement. They then8 arrive at the !ro!osed System to be built. The model of the System is used to free7e all re'uirements before the n et !hase begins.

2. Desi+n C A set of gra!hical tools are used to re!resent a logical System model to formali7ation the user #ith System characteristics and interrelationshi!s before im!lementation. The tools are C (ata Flo# (iagram (F(B8 (ata (ictionary. The !ur!ose of the design !hase is to s!ecify a !articular soft#are System that #ill meet the state re'uirements.

3. Codin+ C This !hase !roduces the actual code that #ill be delivered to the customer as the running System. Individual modules develo!ed in this !hase are tested before being delivered to the net !hase.

4. Testin+ C All the modules that have been develo!ed before are integrated or !ut together in this !hase8 and tested as a com!lete System.

). Im,lementation  $aintenance C Im!lementation means converting a ne# System design into o!eration. This involves creating com!uter C com!atible files8 training the o!erating Staff8 installing hard#are.


IDENTIF-ING TE #IFE C-C#E $ODE#

For the develo!ment of any System8 #e should have to follo# the #ell0scheduled !ath8 #hich is 5no#n as model. Although there are many life cycle models no#adays8 but according to our !roect and user convenience #aterfall %odel has been selected.

%usti*ication / Usin+ 0ater*all $odel At every !hase there is !rovision of verification  validation8 correction of errors and inconsistencies. 1. All re'uirements are gathered once as #e have done in this ,os!ital %anagement System ,%SB. 2. "very stage begins #hen !revious !hase is finished. According to this model #e have !re!ared all stages as analysis8 designing8 coding8 and then finally develo!ment. 3. This !roect consists of a linear set of distinct !hases. 4. "very !hase has #ell defined entry and eit criteria8 #hich is available in our ,%S. ). "asy to understand and chea!. *. It !rovides !ro!er feedbac58 to minimi7e the #or5 again. +. This is achieved through the !rocess of revie# and documentation. -. It is sim!le8 old and most #idely used !rocess model for soft#are develo!ment. >. "asy to e!lain to the users 1?. Stages and activities are #ell defined 11. Eerification at each stages ensures early detection of errors9misunderstandings

Thus to solve the actual !roblem in an institution settings or System settings a soft#are engineer must incor!orate a develo!ment strategy that encom!asses the !rocess8 methods8 and tool layers. This strategy is often referred to as a !rocess model i.e.8 #hy #e have selected $aterfall %odel8 #hich is very hel!ful to carry out this ,%S !roect.


IDENTIFICATION OF NEED efore re'uirements can be analy7ed8 modeled8 or s!ecified they are gathered through an elicitation !rocess. /ontet free 'uestions #ere as5ed to the management !eo!le belonging to different large de!artments regarding ho# they #ould characteri7e a good out!ut that #ould generate a successful solution8 #hat 5ind of !roblems #ill this solution address8 ho# they describe the environment in #hich the solution #ill be used8 and #ill s!ecial !erformance issues or constraints affect the #ay the solution is a!!roached. Thus the information about the !roblem that is ho# the !atient details #ere stored #ithout the !resence of the soft#are is gathered. In the current ,os!ital %anagement System the !erson at the des5 needs to 5ee! a register to record the details of each !atient #hile admitting it in the hos!ital


!RE#I$INAR- IN&ESTIGATION The initial investigation ,%S has the obective of determining the validity of the user re'uest for a com!uteri7ed System and #hether it is feasible8 studies should be conducted;. It handles a user re'uest to change8 im!rove or enhance an eisting System. First stage is the !reliminary investigation. The main aim of !reliminary investigation is to identify the !roblem. In this !hase of System (evelo!ment #e study the eisting System8 collects various information about the record maintenance and ho# data are fed u! in the files. asically #e need to 5no# eactly #hat our System actually #ants and #hat #e should do our best to !rovide #ith a System that can be im!lemented. The !rocess of registration is summari7ed belo#< $henever a Patient comes to ,os!ital for the registration8 he9she must fill the form filling all the details regarding them i.e. their name8 guardians; name8 bed ty!e etc. along #ith the residence !roof. After the verification of the data filled by the !atient or the relative8 it is !assed to net stage #here the re'uest is transferred to a staff for allotting the annual registration number. After #hich the registration is !rovided to the Patients.


REUIRE$ENT ANA#-SIS

The heart of the Systems analysis is aimed at ac'uiring a detailed understanding of all the im!ortant 'uestions of the !atients and doctors have8 #e made of all0im!ortant areas under investigation. Analysts #or5ing closely #ith em!loyees and managers must study the business !rocess to ans#er the 'uestions. Its !ur!ose is to create an overall !icture or e!lanation of organi7ational data8 not the design for a !articular database. It describes the sco!e o f data maintained by the organi7ation. This !reliminary survey involves the study of the inside of Patient i.e. ho# the hos!ital !rovide various services to its Patient. According to above mentioned need8 #e find the information by 'ueries< 1.

Patient 'uery< 1 y name 2 y guardian;s name 3 y bed ty!e

2.

(octor 'uery< 1 y name 2 y s!eciali7ation

3.

ed 'uery< 1 y bed ty!e 2 y em!ty bed 3 y occu!ied bed

Then the !roblems occurring in the manual system #ere being 'uestioned and noted. The various !roblems #ere related to the !hysical effort in maintaining8 deleting and u!dating the register. Also searching techni'ue of any !atient #as very !oor as manual linear search #as being used. Another !roblem #as that the admitting of !atient #as not according to any grou! or subgrou! categori7ation as no such details #ere there #ith the !erson at the des5. The admitting of !atients #as ust admitting them in the res!ective rooms #ithout any logic8 thus !atients having similar diseases #ere being admitted in different rooms. "!ectations and the need of the !erson at des5 and other staff using the !atient details #ere being as5ed.


FEASI"I#IT- STUDThe obective of a feasibility study is not to solve the !roblem but To !redict on the basis of system analysis  !roblem definitionB that if it does the 5ind f #or5 e!ected on it8 in a reasonable !eriod of ela!sed time8  consistent #ith the financial and !rocessing obective and needs of the organi7ation. (uring this study8 data is being gathered to obtain sufficient information about eisting system to ma5e com!ression #ith !ossible com!uter systems. ,ere the system G,os!ital Information SystemH is manual. It is not !ossible for this a!!lication to store such a huge database of hos!ital account. Feasibility analysis is done in res!ect of the follo#ing<

1. 2. 3. 4.

Technical feasibility "conomical feasibility !erational feasibility Social feasibility

1HOSPITAL MANAGEMENT SYSTEM

1. Tec(nical *easiility A study of resource availability that may affect the ability to achieve an acce!table system. This evaluation determines #hether the technology n eeded for the !ro!osed system is available or n ot.  /an the #or5 for the !roect be done #ith current e'ui!ment eisting soft#are technology  available !ersonalJ  /an the system be u!graded if develo!edJ  If ne# technology is needed then #hat can be develo!edJ This is concerned #ith s!ecifying e'ui!ment and soft#are that #ill successfully satisfy the user re'uirement. The technical needs of the system may include<

Front3end and ac43end selection

An im!ortant issue for the develo!ment of a !roect is the selection of suitable front0end and bac50end. $hen #e decided to develo! the !roect #e #ent through an etensive study to determine the most suitable !latform that suits the needs of the o rgani7ation as #ell as hel!s in develo!ment of the !roect. The as!ects of our study included the follo#ing factors.

Front3end selection < 1.

It must have a gra!hical user interface that assists em!loyees that are not from IT bac5ground. 2.

Scalability and etensibility

3.

Fleibility.

4.

&obustness.

5.

According to the organi7ation re'uirement and the culture.

6.

%ust !rovide ecellent re!orting features #ith good !rinting su!!ort.

7.

Platform inde!endent.

8.

"asy to debug and maintain.

9.

"vent driven !rogramming facility.

10. Front

end must su!!ort some !o!ular bac5 end li5e %s Access.

According to the above stated features #e selected E*.? as the front0end for develo!ing o ur !roect.

1!HOSPITAL MANAGEMENT SYSTEM

"ac43end Selection <

1. %ulti!le user su!!ort. 2. "fficient data handling. 3. Provide inherent features for security. 4. "fficient data retrieval and maintenance. ). Stored !rocedures. *. Po!ularity. +. !erating System com!atible. -. "asy to install. >. Earious drivers must be available. 1?. "asy to im!lant #ith the Front0end.

According to above stated features #e selected %s0Access as the bac5end. The technical feasibility is fre'uently the most difficult area encountered at this stage. It is essential that the !rocess of analysis and definition be conducted in !arallel #ith an assessment to technical feasibility. It centers on the eisting com!uter system hard#are8 soft#are etc.B and to #hat etent it can su!!ort the !ro!osed system.

1"HOSPITAL MANAGEMENT SYSTEM

O,erational *easiility' The assessment made if the System #ill be used or not once it is develo!ed. According to the !roect8 the ,os!ital %anagement System #ill use the o!erational feasibility if the System is develo!ed and im!lemented to measure ho# #ell is our !roect solution #ill #or5 in the organi7ation. And ho# the !eo!le feel about the System. Since8 the System is highly user friendly8 it is acce!table to the organi7ation and other users as #ell. So #e can say it is o!erationally feasible.


Economic Feasiility' "conomic analysis is the most fre'uently used method for evaluating the effectiveness of a !ro!osed System. In this feasibility8 #e decide the !ro!osed System as on the basis of cost9benefit analysis. $hether the !ro!osed System is feasible according to the economic factors i.e. cost or money #ise. "conomic analysis is the most fre'uently used method for evaluating the effectiveness of the System. The benefits that this System has8 are many including the enhancing the #or5ing s!eed of the System8 'ueries are sorted in a fast manner8 the data are stored in the database that can be used #henever re'uired. And the cost of ne# com!uteri7ed System #ill not be much in vie# of its advantages. The benefits out#eigh the costs8 and then the decision is made to design the System. This ,%S for management of 6ife 6ine /haritable ,os!ital is a sim!le !roect and re'uires the soft#are;s li5e Eisual asic and S@6. It is sim!le soft#are and does not re'uire any etra costs other than the cost of the soft#are used for develo!ment and the charges of the develo!er. So #e can say that it is economically feasible.

Social feasibility: Social feasibility is the determination of #hether the !ro!osed model #ill be acce!ted by the !ublic or not. The determination ty!ically eamines the !robability of the !roect being acce!ted by the grou! directly affected by the !ro!osed system change.


SOFT0ARE ENGINEERING 0ater*all model' $aterfall a!!roach #as first Process %odel to be introduced and follo#ed #idely in Soft#are "ngineering to ensure success of the !roect. In KThe $aterfallK a!!roach8 the #hole !rocess of soft#are develo!ment is divided into se!arate !rocess !hases. The !hases in $aterfall model are< &e'uirement S!ecifications !hase8 Soft#are (esign8 Im!lementation and Testing  %aintenance. All these !hases are cascaded to each other so that second !hase is started as and #hen defined set of goals are achieved for first !hase and it is signed off8 so the name K$aterfall %odelK. All the methods and !rocesses underta5en in $aterfall %odel are more visible.


Re5uirements ' This is an informal s!ecification of #hat #e as hos!ital administrators #ant from the com!any designing a system to hel! us manage our hos!ital efficiently and effectively. General !rolem Statement

(ue to budget cutbac5s and general concern for !roviding the best service !ossible to the !ublic8 #e as a hos!ital #ould li5e to ensure that #e are using our scarce hos!ital resources in the most efficient manner !ossible. $ith this in mind #e #ould li5e you to design a system #hich #ill hel! us manage our hos!ital in an efficient8 effective manner. S!ecifically the system should hel! us schedule and monitor the various resources that #e have at the hos!ital. This includes 5ee!ing trac5 of available beds8 #aiting lists for !atients8 !atients e!ected length of stay8 scheduling of surgeries8 !atient notification and billing8 scheduling o f nurses and doctors. The follo#ing information !rovides the more detailed brea5do#n of ho# our ,os!ital is Or$%&'(e). The main hos!ital consists of one building #ith 1? floors. here are + #ards #hich

occu!y various floors of the hos!ital.

0ard Floors "eds 1

Obstetrics 8 50

2

Cardiology 7 50

3

Intensive Care 6 50

4

Recovery 4,5 100

5

Geriatrics 3 50

6

Pediatrics  50

7

O!erating " "0


DATA

The system must store the follo#ing information< 





For hos!ital !hysical buildingB< :o of #ards o For each #ard< o

ty!e of #ard

o

no of beds

For each bed o

#ard itLs in

o

#hether or not itLs occu!ied

o

o

!atient #hoLs in it (ate !atient started occu!ying bed.

Scheduling of hos!ital staff must ta5e the follo#ing information into account. "ach floor re'uires a su!ervising nurse and ) regular nurses during the day and 1 su!ervising and 2 &egular nurse in the evenings. bstetrics8 /ardiology8 Intensive care and !erating all re'uire nurses #ith that s!ecialty. T#o doctors #ith the a!!ro!riate s!ecialty are re'uired during the day and one in the evening for each floor. t#o doctors and t#o nurses are re'uired for each o!eration.

For (os,ital sta**'  

:ame 6ast :ame8 First :ameB Address Full Address8 including city8 !rovince9state8 countryB



Position (octor or :urseB



6evel Su!ervising8 &egularB



S!ecialty /ardiology8 Pediatrics...B



Schedule to #or5<#hich consists of the follo#ing entriesB




(ate to #or5. %onth9(ay9MearB



,our to start #or5ing In military format e.g. 24


,our to end #or5ing In military formatB



$ard in #hich to #or5.

For doctors the follo#ing additional information' 

!erating schedule all stuff from schedule aboveB



ty!e of o!eration





!atient to o!erate on

The system should also be able to 5ee! trac5 of certain !atient information. The system should generate a notification letter 2 #ee5 before a !atient is admitted to the hos!ital as #ell as lists of !atients being admitted and discharged on the net day. Finally the system should generate an invoice for the !atients stay. For ,atients'  

:ame 6ast :ame8 First :ameB Address Full Address8 including city8 !rovince9state8 countryB



Insurance number SI:8 #hatever it is in the statesB



Ty!e of treatment re'uired.



For !atients on #aiting list<



Position on #aiting list



Priority



(ate first on #aiting listB



For !atients in bed<



bed info



The system should also<



Dee! trac5 of !ast info.


".g. ld schedule8 !atients #ho #ere there8 #hether or not o!eration #as successful.

ACTI&ITIES'

The system must be able to !erform the follo#ing actions. NST "OA%P6"SB 1. %ust schedul schedulee hos!ital hos!ital staff staff accordi according ng to the the follo#ing follo#ing rules< rules< Staff must not #or5 too many consecutive shifts. o o

Staff cannot be off #or5 for too many consecutive shifts.

o

The number of staff #or5ing must be as large as !ossible at

o

all times.

o

(octors cannot be scheduled to #or5 a #ard and o!erate at the same time.

2. %ana %anage ge the the #ai #aiti ting ng lis list< t< o

%ust be able to add !atients to the #aiting list

o

%ust be able to ta5e !atients ! atients off the #aiting list< 

For those #ho got s!ontaneously better ust remove from list.



For those #ho got a bed8 transfer !atient info to bed.



As !atients removed from #aiting list8 !ositions must be u!dated according to S%" rules. e.g. !atients of higher !riority move u! list faster.

3. Add and remove remove hos!it hos!ital al staf staff< f<


o

:ote this may mean altering the schedule for every other staff member #ho is #or5ing.

SOFT0ARE SOFT0ARE REURE$ENT S!ECIFICA S!ECIFIC ATION

6.1 Introduction' To Provide an integrated Solution for the ,os!ital8 #hich  ,el!s in "fficient %anagement of the ,os!ital.  "nhance Patient /are.  Im!rove #or5 efficiency. efficiency.  "nable the =ro#th of the ,os!ital.


6.1.1 !ur,ose o* De7elo,ment' De7elo,ment' The !ur!ose of this S&S document is to !rovide a detailed overvie# of o f our soft#are !roduct G,os!ital %anagement SystemH8 its !arameters and goals. This document describes describes the !roectLs target audience and its user interface8 interface8 hard#are and soft#are re'uirements. It defines ho# our client8 team and audience see the !roduct and its functionality. functionality.

6.1.2 Sco,e o* de7elo,ment' It authenticates the user by matching the ser I( and the access code #hich in turn may be generated using some cry!togra!hic algorithmB against the values stored in the database. It enables in creating ne# sers in the system i.e. it !rovides a registration form #hich ma5es the user to enter the ne# user ;s details. It !rovides se!arate billing method for indoor and outdoor !atients8 cor!orate and individual !atients.

ome ,a+e'


#o+in ,a+e:


Functional Re5uirement There are 1) maor modules The various modules are< 

&ece!tion %anagement



Patient &egistration P(  IndoorB



ut Patient %anagement



P( illing



Investigations &e!orting Pathology  ImagingB



Indoor Patient %anagement



Indoor illing



Store



Pharmacy



Financial Accounting



Payroll



%&( %anagement



nline (iagnostic &e!orting



,& %anagement

Rece,tion $ana+ement' &ece!tion is the first !oint of interaction for anybody coming to the ,os!ital. It has all the information of the !atients8 doctors8 de!artments and activities of the ,os!ital. All en'uiries and a!!ointments are scheduled through this module.         

Patient &elated "n'uires< ed Allotment Admission (etails Payment (etails (ischarge (etails (octor &elated "n'uires< Availability (etails A!!ointment Schedules !eration Schedules


!atient Re+istration' All information available here are in real time and any en'uiry about the !atient status8 &oom Status8 (octors availability or tariff;s for various services is on actual status since the data is constantly u!dated

.

This module com!rises of the follo#ing com!onents<


!atient En5uiry'

This #ill !rovide information of any !atient li5e
Consultants En5uiry'

Any Information regarding a visiting /onsultant can be obtained li5e consultant;s availability8 days  time of availability8 (e!artment8 s!eciali7ation or any other.

A,,ointments Sc(edulin+'

This o!tion allocates the slots for various consultants. Any a!!ointment can be boo5ed either by !hone or visit8en'uired and cancelled.

Doctor Sc(edulin+'


ser selects de!t0name and doctor id from dro! do#n list Q doctor;s name dis!lay and user selects date from date !ic5er and enters doctor ty!e8 selects visiting hours and clic5 on submit button. Information saves in database.

!atient A,,ointment Re+istration' "very !atient #ho visits the hos!ital has to get registered !rior to getting any consultation8 treatment or investigations done. &egistration of !atients involves acce!ting certain general and demogra!hic information about the !atient. The !atient is a llocated a uni'ue &egistration number and a Patient Identification number. The Patient I( #ill remain same for his all subse'uent visits to the hos!ital #hereas he #ill be allocated a ne# registration number on every visit. The consultation charges if a!!licableB can also be collected for the P( !atients during registration and a recei!t #ill be generated.


!atient A,,ointment Re+istration'

The follo#ing information is re'uired for the registration of P( Patient00< Patient (etails li5e :ame8 Age8 Se8 Address8 /ontact number8 :ationality8 etc. &eferring Source and S!onsorshi! 9 Penal (etails (e!artment  /onsultant to be visited. 

 

In !atient'


For In!atient the additional information re'uirements are<  &oom 9 bed re'uirement.  /onsultant In charge Treatment re'uired  Authori7ation from S!onsor9Penal if re'uired  After registration an P( /ard is !rinted for the P( !atients8 #hich list all his registration information. This card is used for the !rescri!tion #riting by the consultant. An Admission form is !rinted #ith all the registration details for Indoor !atients8 #hich serves as the cover !age of the !atient file.


In !atient Daily Re,ort' ser selects registration0id from dro! do#n list and clic5 on submit buttonQ then In!atient (aily re!ort generates.


Out !atient $ana+ement' After the registration the !atient comes to the consultation chamber8#here the consultant records his history8 diagnose and !rescribemedicines  investigation. The /onsultant note do#n the follo#ing details on Patients P( /ard<       

/om!laints ,istory (iagnosis Investigation %edicines Advice :et Eisit

This information is then entered into the !atient data by the consultant or theo!erator at the P( /ounter. It serves the !ur!ose of tracing !atient;s visitshistory and also as a feedbac5 for research  analysis. The !rescri!tion can also be scanned and saved. The scanned data can be entered later into various fields by the o!erator.

6.O!D "illin+'

For billing of any P( service li5e Pathology Tests8 or any imaging investigation8 the !atient moves to P( billing counter. ,ere the services are charged as !er the rates already defined for various categories9 !enal9 time etc to the !atient #ith his Patient I(. The Payment is collected for the service !rovided and a recei!t is generated. This module #or5s as an interface #ith the diagnostic modules. All services #ill be automatically entered into the res!ective modules #herever re'uired li5e lab Imaging re!orting. The Salient features of this module are<  &ecord /harges to be ta5en from the !atient. &ecord details of the concession  concession authority  /onsultant charges are automatically !ic5ed according to ge neral or emergency charges.  The charges for the services are automatically !ic5ed according to the category or !anel of the !atient.  The charges are also de!endent on time #hen the service is being given to !atient.  $hen !atient revisits his information #ill be automatically !ic5ed using his identification number.  Patient can be defined under /ash  /redit P(.  All relevant information is transferred to the Investigation de!artments.


8. In7esti+ations Re,ortin+ 9!at(olo+y  Ima+in+:' In the routine functioning of a hos!ital8 various ty!es of investigations are carried out. /arrying out number of tests and ma5ing the results available !rom!tly is very crucial for assessing the !atientLs medical status and deciding on the further course of action. The investigation re'uisition can be auto0generated through P( billing or IP(B or can also be generated here8 de!ending on the system follo#ed in the hos!ital.The tests !arameters are !re defined #ith the inter!retations  formulae #herever a!!licable. The test results are entered into the soft#are manually or #ith e'ui!ment integration and a descri!tive smart re!ort is !rinted after verification and validation.

The Salient features of this module are<  nline investigation re'uisition can be raised from P( or IP( or 6abs  Provision for entering results for diverse tests in multi!le re!orting formats.  Five o!tions for each test !arameter8 along #ith inter!retations  e!lanation.  Age #ise  Se #ise &eference range for Pathology tests.  $arnings  Auto0highlighting of abnormal values.  Auto calculation and validation of test results #ith formulae  All the &e!orts #ill be validated before finally ready for !rinting after verifying its correctness.  &ole ased Security. (ifferent access !ass#ord for each de!artment  ser.  /om!arative analysis of Test result #ith last visits re!orts.  Integration #ith diagnostic e'ui!ments to fetch actual result values directly.

;. !atient $ana+ement' The Indoor !atient module commences #hen the !atient is being registered and allotted a bed in the #ard. It deals #ith the com!lete treatment and services !rovided to the !atient during his stay in the hos!ital. This module #or5s at the nursing station. (uring his stay in the hos!ital8 every !atient is !rovided various services in terms of consultant;s visits8 investigations8 !rocedures8 medicines  consumable8 room services8 diet8 etc. All these services are entered online to the !atient record through nursing station. It also interacts #ith the Investigation module8 Store8 Pharmacy and sends the re'uisitions to these de!artments. This data serves as maor in!ut for the IP( billing.


Salient Features<  ed Allocation and Transfer.  /onsultants visit entry.  &ecording Patient;s /linical (ata  &e'uisition of Investigations re'uired  &e'uisition to Store  Pharmacy for %edicines  /onsumables.  T illing  %anagement.

<. "illin+' Indoor billing module has a su!ervisory role. The entries for billing are automatically transferred to the !atient bill by the res!ective de!artments8 #hich !rovide the service. The services are charged as !er the category9!anel9!ac5age a!!licable. ,ere the bill is com!iled and the !ayment collected from time to time. Provisional and Final bills are generated #hich !rovides com!lete information about the Services availed8 its /harges8 Advance collected8 a!!ro!riate &ecei!ts8 &efunds8 /redit notes8 /oncession allo#ed8 etc. Salient Features<  /ollection of Payment by /ash9/redit /ard9 (( or /he 'ue.  &ecei!ts8 refunds8 /redit :ote =eneration.  Provisional  Final ills.  (e!artment #ise services availed.


   

Scrutini7ing the (e!osit "haust list and sending re'uisition for de!osit. Automatic scrutiny of the credit limit available to the !atient. Provision to bill a !atient against another accoun t 6I/ account9com!any account9(onors account etc.B Additional !ayment for Ambulance9attendants at discharge if re'uired.

=. Central Store' This module deals #ith the inventory of all ,os!ital "'ui!ments8 %aterials8 /onsumables8 and %edicines8 Im!lants  Asset items indifferent de!artments of the hos!ital along #ith their !urchase and su!!lier details. &e'uisitions for different items9e'ui!ment are sent to this store from different de!artments and accordingly the /entral Store issues items9e'ui!ment to various de!artments and generate !urchase orders for !urchases. This also maintains records of !urchases8 stoc58 and su!!lier list8 item9e'ui!ment9material master tables.The Store module ensures that there is a round the cloc5 availability of a sufficient 'uantity of drugs and consumable material for the !atients in a mode that neither hinders efficient clinical #or58 nor it becomes a threat to the survival of the Store.

Salient Features of this %odule are<  %aintains the details of all items8 its su!!liers and !urchase details.  Items can be categori7ed under different grou!s.  Items can be defined for the store i.e. a !articular #ill be able to vie# only those items #hich comes under it.  =enerate Purchase order lin5ed #ith !atient indents.  %aintain Se!arate Stoc5 of /entral Store  %ulti!le Sub Stores.  A !articular store can indent items from all other stores.  %aintain vendor details from #hom Items are being ! urchased.  /entral Store can ac5no#ledge return of !urchased item.  Earious area stores can return items that are not re'uired by them bac5 to the /entral Store.  (ifferent store can issue Items to other Stores8 (e!artment.  Strict /hec5 on the "!iry (ate of %edicines  /onsumables.  Items can be issued according to FIF  6IF chec5  %aintain &eorder 6evel of Items and #arn accordingly

The follo#ing re!orts can be generated as !art of this module<  &e!ort of all items according to their grou!.  Stoc5 in ,and &e!ort =rou!  atch $iseBStoc5 Ealuation on Purchase &ate  %.&.P.  &e!ort on Stoc5 %ovement as #hen  from #here Item #as issued and to #hom it #as issued.  Items "!iry list  #arning  &eorder 6evel of Items.




Purchase  Issue &egisters.

>. !(armacy' The Pharmacy %odule deal #ith the &etail Sale of medicines to P( !atients and Issue of medicines to the In0!atients in the hos!ital. Its function includes8 online drug !rescri!tion8 inventory management and billing of drugs8 consumables and sutures. This module is closely lin5ed to the illing %odule and In0!atient %odule. All the drugs re'uired by the!atient can be indented from the various sub stores.

Salient Features<  This module enables com!lete control on !harmacy including Purchase  Issue of medicine to IP( or P( Patient.  %edicines can be classified under different categories as !er the salt or a!!earance.  Total amount of the bill for IP( Patient #ill automatically get added in his bill.  The Pharmacy can ac5no#ledge the return of items and issue /redit notes  Items can not be issued after the e!iry date.  Items can be issued according to FIF  6IF chec5.  (etails of all vendors are 5e!t in accordance #ith their transactions.  %aintain &eorder 6evel of Item.

The follo#ing re!orts can be generated as !art of this module<  Stoc5 in ,and &e!ort =rou! #ise8 atch #iseB  "!ired medicines list. 6ist of all the items according to their grou!  classification.atch #ise8 or #ithout atch #iseB  &e!ort on Stoc5 Ealuation on Purchase &ate8 Sale &ate  %.&.P.  &e!ort on Stoc5 %ovement as #hen medicine #as issued and to #hom it #as issued.  Purchase8 Sale  Issue &egister.

1?. Financial Accountin+' A Financial accounting module is lin5ed #ith hos!ital billing module. Mou get online accounting of all revenue generated along #ith e!enses incurred. There is no need to enter the revenue entries as they are already fetched from the billing module. All relevant information for the staff salary9#ages8 consultant share8 etc is available.


Salient Features of this module are<  All revenue entries are transferred automatically from billing module.  Nust enter the e!ense vouchers and the accounts are com!lete u! to balance sheet.  /onsultant Share and other relevant Information already available.  ser defined ledger =rou!s  Accounts.  ser definition of /ost /entre.  (e!artment #ise income detail.  /he'ue Printing.  =ra!h #ith Dey &e!orts

Dey &e!orts of this module are<          

Party 6edger 6edger Analysis. (ay oo5 /ash oo5 an5 oo5 Sale oo5 Trial alance as on date. =rou! #ise Trial alance. Profit  6oss &e!ort. alance Sheet

11. !ayroll' Dee! trac5 of all staff member;s attendanceQ there leave record and deductions. =enerate salary sli! and other related re!orts.

Salary %aster< ser clic5s on master salary o!tionQ master salary !age o!ens. ser selects "m!0/ode from dro! do#n list then a ll salary related information dis!lay.


Salient Features of this %odule are<  %aintains com!lete record of all em!loyees including the "m!loyee /ode8  name8 (emogra!hic data8 Salary in different heads8 (e!artment8 (esignation8 PF account8 "SI Account8 etc.  (efinition of Salary head as !er formula or straight a#ay.  6eave;s as !er defined by user.  Salary settings as !er monthly basis8 or on #ages basis.  (aily9 %onthly attendance record.  Short Term  6ong Term 6oans.  &ecord of em!loyee;s in time8 out time8 lunch hours8 over time.  A!!lication of salary increment formula.  Su!!orts all ty!es of Smart /ards8 ar /ards8 etc. Dey &e!orts under this module are<  Salary &egister.  6eave &egister.  Pay Sli!s.  "m!loyee 6ist #ith their com!lete details.  ver time re!ort.  verall PF &e!ort.  &e!ort of 6eaving and ne# oin em!loyees.


12. $edical Record data 9$RD: $ana+ement' Patient;s %edical record data is critical for the analysis and research !ur!oses. This data includes !atient history8 observation8 diagnosis and thera!eutic conclusions along #ith the tests details and serves as a source of information foray analysis and research. The !ur!ose for this module is to utili7e the !atient;s medical information and use it for analysis thereby im!roving !atient care. Salient Features of this %odule are<    

Statistical re!orts based on diagnosis8 age8 se8 geogra!hical areas and other !arameters. (ischarge Summary #ith details of test re!orts. &e!orts on de!artments8 consultants8 etc. irth  (eath &ecords #ith full details.

R $ana+ement' (e!artment< ser enters de!t name8 ,(8 location8 current man !o#er8 Authori7ed man !o#er and user #ill clic5 on save buttonQ information saves in database. $hen user clic5s on reset o!tionQ all fields are cleared.


Em,loyee In*ormation' $hen user clic5s on em!loyee information o!tionQ em!loyee information !age o!ens. And user enters "%P0 name8 em!0ty!e8 user #ill select date from date !ic5er8 enter de!artment8 designation8 'ualification8 select blood grou!8 gender8 status from dro! do#n list and user enters family information and address information and clic5 on save buttonQ !o!u! message dis!lay and information saves in database.


Em,loyee In*ormation'


O7er7ie@' This Soft#are &e'uirements S!ecification S&SB is the requirements work product that formally s!ecifies ,os!ital %anagement System ,%SB. It includes the results of both business analysis and systems analysis efforts. Earious techni'ues #ere used to elicit the re'uirements and #e have identified your needs8 analy7ed and refined them. The obective of this document therefore is to formally describe the system;s high level re'uirements including functional re'uirements8 non0 functional re'uirements and business rules and constraints. The detail structure of this document is organi7ed as follo#s< Section 2 of this document !rovides an overvie# of the business domain that the !ro!osed ,os!ital %anagement System ,%SB #ill su!!ort. These include a general descri!tion of the !roduct8 user characteristics8 general constraints8 and any assum!tions for this system. This model demonstrates the develo!ment teamLs understanding of the business domain and serves to maimi7e the teamLs ability to build a system that truly doe s su!!ort the business. Section 3 !resents the detail re'uirements8 #hich com!rise the domain model. Picture 1 sho#s an overvie# of the ,os!ital %anagement System and the relationshi!s bet#een re'uirements.


Descri,tion o* S.R.S'

$hat does ,%S integrateJ    

(atabase A!!lications Interfaces Tool

Terms8 definitions and abbreviations<



@A 0 @uality Assurance (ATAAS"A 0 !lace #here !ermanent data is stored &S 0 usiness &e'uirement S!ecification S&S0 Soft#are &e'uirement S!ecification



F&S0



,%S0 ,os!ital %anagement System

  

Functional &e'uirement S!ecification

A,,lication descri,tion'


The user #ill enter all the billing information for a !articular !atient. This #ill include the ty!e of the !atient in!atient9out !atient and cor!orate9individualB8 ty!e of billing for in!atient the mode of bill !aymen tmay be !ost0!aid but for out!atient it should be !re!aidB. The user #ill also have to select the laboratory tests done by the !atient8 the date of discharge of the !atient and the amount of discount if there is any.2.2 Interface descri!tion< The user #ill have to be familiar #ith the billing module. If needed8 the user should be trained u! to use this module. The user may be an administrator8 nurse or cashier. It de!ends u!on the !articular hos!ital.

Eternal inter*aces' In!ut from the user #ill be via 5eyboard in!ut and mouse !oint and clic5. The user #ill navigate through the soft#are by clic5ing on icons and lin5s. The icons #ill give a!!ro!riate res!onses to the given in!ut.

Tec(nolo+y Used'


Eisual Studio2??- and S@6 server2??)

So*t@are and ard@are re5uirements' Soware Reqire!e"ts:

Oper%*&$ S+,te-

/'&)o0,2###NTP

ee6op-e&t L%&$u%$e 7',u%6 B%,'c B%c8 E&) :BMS;

M'cro,o< S=L ,erer or M'cro,o< %cce,,

Mi"i!! #ar$ware Reqire!e"ts:

Proce,,or

Pe&*u- 4

:AM

12" MB

H

4 GB

Mot>er?o%r)

A&+ co-p%*?6e

Mou,e

Op*c%6 Scro66 Mou,e

@e+?o%r)

Ge&er%6 or 0't> Hot @e+,=/E:TY.

Mo&'tor

S7GA Mo&'tor

PS

#.5 @7A ,ard#are and Soft#are &e'uirements<

!er*ormance Re5uirement'


The !erformance of our !roduct is at its best if stored locally8 as the res!onse time #ill be much faster. If the !roduct accessed via Internet8 the !erformance is limited by the connection s!eed. The only foreseen limitation is that of #eb0server res!onse. The !erformance of our soft#are is at its best #hen the follo#ing are regularly done< Normal Re5uirements'

1. =ra!hical dis!lays< aB Fully %enu driven. Intuitive 5ey assignments and user interactive screen.

2. 3. 4. ).

bB ser friendly and easy to use menus. Feature to Add8 delete and store data of the !atient8 beds and doctors. Feature to fill !atient details8 bed details or doctor details on a single clic5 and easily access them. Search Facilities. !dation facility #ith easy scrolling through records of !atients8 beds or doctors.

E,ected Re5uirements'

1. Indeing. 2. "ase of human9machine interaction. 3. &eliability and o!erational correctness. 4. "ase of soft#are installation. ). Single !oint data storage for each data element. *. 24 + su!!ort any timeB. +. The system should be secured. -. Should be u!gradeable to incor!orate ne# features. >. Should be e!andable. 1?. Should have fastest !ossible res!onse #hile !rocessing 'ueries.

Security re5uirements'

The follo#ing security re'uirements are considered in this !roect. 1. 2. 3. 4.

Patient9em!loyee 6evel Authentication. &estricted %enu access. Pass#ord !rotected soft#are. nly !erson at des5 should be able to see and go through the records.


S-STE$ DESIGN

Desi+n OBecti7e' This is the most creative and challenging !hase of the System life cycle is System (esigning. The term design describes a final System and the !rocess by #hich it is develo!ed .The first ste! is Gto determine ho# the out!ut is to be !roduced and in #hat formatH. The design of an information System !roduces the detail that clearly describes ho# a System #ill meet its re'uirements identified during the System analysis. System analyst begins the design !rocess by identifying the re!orts and other out!uts the System #ill !roduce. The System design also describes the data to be in!ut8 calculated or stored. The detailed information is !assed on to the !rogramming Staff for the !ur!ose of soft#are develo!ment. A design document states the details of ho# to meet the System re'uirements identified during the System analysis.

Desi+n Conce,ts'

To,3Do@n desi+n'

egin #ith the behavior descri!tion of the faculty and #or5 to#ards the descri!tion of its com!onents and their interconnections.


"ottom3U, desi+n'

egin #ith the set of com!onents and see if they can be arranged to meet the behavior descri!tion of the faculty.


ARCITECTURA# DESIGN

Entity Relations(i,3Dia+ram' "ntity relationshi! diagram is a diagram to sho# the different entities8 its attributes and the relation bet#een them. The entities are the tables in the database. ,ere #e have 3 entities< 1. ed8 2. Patient8 and 3. (octor In an "ntity &elationshi! (iagram #e sho# entities in rectangular boes8 their attributes in circles and the connection bet#een entity and attribute #ith a straight line bet#een the t#o. The relationshi!s bet#een the t#o entities are sho#n in diamond boes8 and the connections bet#een the entities and relationshi!s are sho#n #ith the hel! of arro#s. The above mentioned "ntity &elationshi! (iagram "&(B sho#s the relationshi! bet#een different entities of 6ife 6ine ,os!ital (atabase. It also sho#s the different attributes of the entities of the 6ife 6ine ,os!ital (atabase


Entity Relations(i, dia+ram


Data Flo@ Dia+rams' All the above re'uirements are fulfilled by the (etailed (esign S!ecifications in the form of (F(s. (F(s are the best #ay for e!laining the conce!t in brief  understandable manner.

(F( also 5no#n as Gbubble chartH has the !ur!ose of classifying System re'uirements  identifying maor transformations that #ill become !rograms in System (esign. A (F( consists of a series of bubbles oined by lines. The bubbles re!resent the transformations  the lines re!resent the lo# of data in the System. Its symbols are as follo#ing<

1 2

A s'uare defines source or destination of System data. An arro# identifies data flo#. 3 A circle or bubble re!resents a !rocess. 4 An o!en rectangle is a data store C data at store.

All the above com!onents are used to design the (F( as a #hole (F( in a com!lete  descri!tive manner.


?3le7el DFD


13le7el DFD


23le7el DFD


3le7el DFD

Use3case Dia+ram'


Data Dictionary

#HOSPITAL MANAGEMENT SYSTEM

A data dictionary is a structured re!ository of data about data. It is a set of rigorous definitions of all (F( data elements and data structures. A data dictionary has many advantages< 1. It hel!s in giving the user a com!lete information about the various terms used in the !roect. 2. it hel!s in better understanding of the !roect (uring im!lementation8 it serves as a common base against #hich !rogrammers #ho are #or5ing on the System com!are their date descri!tions. Also control information maintained for each data element is cross0 referenced in the data dictionary.

Data Dic%o"ary of t&e col!"s i" t&e 'ife'i"e Database

Ar'?ute N%-e

%t% T+pe

e,cr'p*o&

p%*e&t  Store, t>e '&or-%*o& %?out t>e p%*e&t, '& t>e >o,p't%6 P&o

Auto&u-?er

,e) %, pr'-%r+ 8e+ 0>'c> ', u&'Due or p%*e&t,  Co)e or t>e re$',tr%*o& t>%t 0'66 u&'Due6+ ')e&*+ t>e-

Bt+

Nu-?er

P%*e&t ?e) t+pe

N%-e

Tet

N%-e o t>e p%*e&t

Se

Tet

Se

A))

Tet

A))re,, o t>e p%*e&t

A$e

Nu-?er

P%*e&t, %$e

Pp>

Nu-?er

P%*e&t, p>o&e &u-?er

G%))

tet

Gu%r)'%&, %))re,,

Gp>

Nu-?er

Gu%r)'%&, p>o&e &u-?er

Gre6

Tet

:e6%*o& o t>e $u%r)'%& %&) t>e p%*e&t

o%

%te

%te o& 0>'c> p%*e&t 0%, %)-'e) to t>e Ho,p't%6

oc

Tet

octor or t>e p%*e&t

1HOSPITAL MANAGEMENT SYSTEM

'%

Tet

)'%$&o,',

)octor Store, t>e '&or-%*o& %?out t>e )octor, oc&%-e

Tet

N%-e o t>e octor

,pec'%6'(%*o&

Tet

octor, ,pec'%6'(%*o&

oc%))

Tet

octor, %))re,,

ocp>

Nu-?er

P>o&e &u-?er

oc-o?

Nu-?er

octor, -o?'6e &u-?er

Be)  Store, t>e '&or-%*o& %?out t>e ?e) t+pe Bt+p

Tet

Be) t+pe

B&o

Nu-?er

Nu-?er o ?e), o t>e 8'&)

Cp)

Nu-?er

C>%r$e, per )%+ or % p%r*cu6%r 8'&) o ?e)

e,p

Tet

e,cr'p*o& o t>e %c'6'*e, pro')e)

TESTING Testing is a !rocess of eecuting a !rogram #ith intent of finding an error. A goal test case is one that has a !robability of finding an us yet undiscovered error. All test should be traceable to customers re'uirement. Test should be !anned long before testing begins. The testing should begin in the small and !rograms to#ards testing in the large. "haustive testing is not !ossible. The most efficient8 testing should be conducted by an inde!endent third !arty.


C(aracteristics o* Good Testin+  A good testing has a high !robability of finding errors. R A good test is not redundant. R A good test should be of breed. R A good test should be neither too sim!le nor too com!licated.

Ty,es o* Testin+ There are t#o basic a!!roaches to testing functional and structural. Functional testing is also called lac5 o Testing. In lac5 o Testing the structure of the !rogram is not considered structural testing is called @(ite "o testin+.

"#AC "O TESTING <0 lac5 bo testing to be a!!lied during lateral of testing lac5 bo Testing enables the soft#are engineer.  lac5 bo testing enables the soft#are engineer.  To derive sets in!ut condition 5ill tall eercise the functional re'uirement of a !rogram.  lac5 bon testing enables to find error in the follo#ing categories.  Incorrect or missing functions.  Interface "rrors.  "rrors in data structure or eternal database access.  Performance errors  Initiali7ation and termination errors.

The lac5 bo testing !rocedure is ehaustive testing. ne criterion for generating test cases is to generate them randomly. There are no formal rules for designing test cases for functional testing. ,o#ever there are a :umber of method that can be used to select test cases they are< 1. "'uivalence class !artitioning. 2. oundary value Analysis. 3. /ase0"ffect =ra!hing. y a!!lying lac5 o testing a set of test cases that satisfy the follo#ing criteria< Test cases that reduce8 by a count that is greater than one8 the number of additional test case must be designed to achieve reasonable testing. Test case that tells as something about the !resence associated only #ith the s!ecific test at hand. 0ITE "O TESTING <0 Structural Testing or #hite o testing< 0 To tet the structural testing or #hite bo testing is used. This test is !reformatted #ee5ly in the testing !rocess. This testing also called =lass bo testing can drive test cases that.

1. =rantee that all the inde!endent !aths #ithin the module have been e!ressed at least once. 2. "ercise all logical designs on their true an d fla5e sides. 3. "ecute all loo!s at their boundaries and #ithin their validity.


4. "ercise internal data stricter to ensue their validity. T(ese are t(ree di**erent a,,roac(es to structural testin+ t(ey are'3 1. /ontrol flo# based testing. 2. (ata ho# ased testing. 3. %utation testing.

#E&E#S OF TESTING'3

Testing is used to default faults introduced dra#ing s!ecifying and different lives of testing !rocess. The basic lives of testing are<  Unit testin+  Inte+ration testin+  system testin+  Acce,tance testin+ 

UNIT TESTING  nit testing is for verification of the code !roduced dra#ing the /ode !hase that is goal of testing is to the internal logic at the modules. As Focus of this testing level is testing the code structure testing is best suited for this level INTEGRATION TESTING  The goal of this testing level is to see if the modules can be integrated Pro!erly. In other accords the em!hasis on testing the inter cases bet#een the modules. This testing activity can be consider testing the design .

S-STE$ TESTING  In this testing entire soft#are is tested. The goal is to see if the soft#are meets its re'uirements.

ACCE!TANCE TESTING  Acce!tance testing is !reformatted using real data of the client to demonstrate that soft#are. Is #or5ing satisfactory. Testing lane focuses in the eternal behavior by the system Intense the fanatical testing is !erformance at this level.

&A#IDATION CECS




Ealidation refers to different set of activities that insure that the soft#are that has been built is traceable that customer re'uirement. Ealidation is the chec5 that Gthe !roduct made is #hat #as re'uired or notH 

Ealidation testing !rovides final assurance !erformance re'uirement. lac5 on testing techni'ue are used eclusively during validation.



After each validation test cues has been conducted8 one or t#o !assable and condition eists. The function or !erformance characteristics conform to s!ecification and are acce!ts.



A deviation from s!ecification is uncovered and a defiance list is created. (eviation or error discovered at this stage in a !roect can rarely be corrected !rior to scheduled com!letion. It is often necessary for resolving deviancies.

CONC#USION


$or5ing on the !roect #as an ecellent e!erience. It hel!ed us to understand the im!ortance of !lanning8 designing and im!lementation so far #e have learnt in our theory boo5s. It hel!ed us unleashing our creativity #hile #or5ing in a team. It also reali7ed the im!ortance of team #or5ing8 communication as a!art of this !roect. The !roect #as successfully com!leted after a lot of efforts and #or5 hours. This !roect under#ent number of com!iling8 debugging8 removing errors8 ma5ing it bug free8 adding more facilities in ,os!ital %anagement System and interactivity ma5ing it more reliable and useful. This !roect focused that scheduling a !roect and adhering to that schedule creates a hard sense of time0 management. It has also let us 5no#n that co0o!erative team#or5 al#ays !roduce effective results.

FUTURE SCO!E

86464560-Hospital-Management-System.doc

Recommend Documents