Hospital Management System Srs 6s4y3m
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report 3b7i
Overview 3e4r5l
& View Hospital Management System Srs as PDF for free.
More details w3441
- Words: 7,953
- Pages: 71
Hospital Management System
Submitted in partial fulfillment of the requirements for the award of the degree of Master of Computer Application To Guru Gobind Singh Indraprastha University, Delhi Submitted to
Submittedby: Yash Kapoor Rahul Kapooria Sweta thapa Neetu Rana
1
Certificate We, Yash Kapoor ,Sweta thapa , Rahul Kapooria , Neetu Rana certify that the Project Report entitled “Hospital Management System” is done by us and it is an authentic work carried out by us at “Lal Bahadur shastri institute of Management.” The matter embodied in this project work has not been submitted earlier for the award of any degree or diploma to the best of my knowledge and belief.
2
ACKNOWLEGEMENT
Apart from our efforts, the success of our project depends largely on the encouragement and guidelines of many others. We take this opportunity to express my gratitude to the people who have been instrumental in the successful completion of this project. We would like to show our greatest appreciation to our Project guide Mr Bhavya Deep. We can’t say thanks enough for the tremendous and help. Without their encouragement and guidance this project work would not have been materialized. Finally we would also like to extend our profound thanks to all our esteemed colleagues who helped us in specific areas of the project.
3
1.
INTRODUCTION
Pg. No. 5-7
2.
PROBLEM STATEMENT
8-9
3.
QUESTIONNAIRE
10-11
4.
FEASIBILITY STUDY
12-15
5.
PROCESS MODEL
16-20
6.
SOFTWARE REQUIREMENT 21-29 SPECIFICATION SOFTWARE DESIGN DOCUMENT 30-33
Sno.
7.
Topic
8.
USE CASE DIAGRAM
34-36
9.
DATA FLOW DIAGRAM
37-44
10.
E-R DIAGRAM
45-46
11.
SCREEN SHOTS
47-52
12.
TESTING
53-62
13.
SYSTEM MAINTENANCE AND 63-66 EVALUATION OBJECTIVES,SCOPE,SUMMARY 67-68 CONCLUSION OF PROJECT REFERENCES 69-71
14. 15. 16. 17.
ADVANTAGES
18. 19.
4
5
The Hospital Management System is designed for Any Hospital to replace their existing manual, paper based system. This project targets to provide complete solution for Hospital and related services. The project Hospital Management system includes registration of patients, storing their details into the system, and also computerized billing in the pharmacy, and labs. The software has the facility to give a unique id for every patient and stores the details of every patient and the staff automatically. It includes a search facility to know the current status of each room. can search availability of a doctor and the details of a patient using the id. The Hospital Management System can be entered using a name and . It is accessible either by an or receptionist. Only they can add data into the database. The data can be retrieved easily. The interface is very -friendly. The data are well protected for personal use and makes the data processing very fast. The purpose of the project entitled as “HOSPITAL MANAGEMENT SYSTEM” is to computerize the Front Office Management of Hospital to develop software which is friendly, simple, fast, and cost – effective. It deals with the collection of patient’s information, diagnosis details, etc. Traditionally, it was done manually. The main function of the system is to and store patient details and doctor details and retrieve these details as and when required, and also to manipulate these details meaningfully System input contains patient details, diagnosis details; while system output is to get these details on to the CRT screen. The common features of this type of software are:
6
• This software facilitates complete and smooth running of the reception. • It manages all the bed allocation systems and the wards of the hospitals. • It manages the laboratory and the equipments. • It manages the treatments as well as the entire history of the patients • This software manages the day to day scheduling of both the nurses and the doctors to various departments and also allocates the schedules of their duties. • It also manages the timely and proper ing to make sure a proper and current billing. • The hospital management software also maintains the proper tests of a number of patients as well as keeps the records of all the medical reports. • The biggest benefit of the hospital management system is that it can be used at the same time via a number of s.
7
8
The information is very difficult to retrieve and to find particular information like- E.g. - To find out about the patient’s history, the has to go through various s. This results in inconvenience and wastage of time. The information generated by various transactions takes time and efforts to be stored at right place. Various changes to information like patient details or immunization details of child are difficult to make as paper work is involved. Manual calculations are error prone and take a lot of time this may result in incorrect information. For example calculating patient’s bill based on various treatments. This becomes a difficult task as information is difficult to collect from various s. How can we overcome the limitations of the manual system? The working in the organization will be well planned and organized. The data will be stored properly in data stores, which will help in retrieval of information as well as its storage. The level of accuracy in the proposed system will be higher. All operation would be done correctly and it ensures that whatever information is coming from the center is accurate. The reliability of the proposed system will be high due to the above stated reasons. The reason for the increased reliability of the system is that now there would be proper storage of information. In the proposed system utmost care would be that no information is repeated anywhere, in storage or otherwise. This would assure economic use of storage space and consistency in the data stored. The main objective of proposed system is to provide for a quick and efficient retrieval of information. Any type of information would be available whenever the requires. In manual system there are many problems to store the largest amount of information. The system should be easy to operate and should be such that it can be developed within a short period of time and fit in the limited budget of the .
9
10
Questionnaire Que1- What is the problem with the current system? Que2- What do you want in this system exactly? Que3- What modules you would like to be in the system? Que4- What kinds of features do you think would attract you to use this system? Q5 Who would be the s of the hospital management system? Q6 Would you like to display the patient’s report online by providing patients a id and ? Q7 A friendly system will be perfect as people with less technical knowledge should be able to use it? Q8 How many record should the database be able to hold? Q9. Timely updation to be made in the software so that huge amount of record to be maintained? Q10 The entries in the software to be self explanatory so as to avoid confusion? Q11. Software to be secured from unauthorized access? Q12 Allocation of rooms to patients operated should be done simultaneously? Q13What kind of platform for working is required? Q14 Any kind of special security is needed for the software? Q17 Are you satisfied with the current processes and policies? Q18 what data required by exist in other system? Q19 what problem do you want this system to solve? Q20 Do you need any additional functionality for improving the performance of the system? Q21 Have you faced any calculation errors in the past? Q22 Who is the controller of the software? Q23 Who will be using the software? Q24 Who will explain the manual system?
11
12
Feasibility Study A feasibility study is conducted to select the best system that meets performance requirement. This entails an identification description, an evaluation of candidate system and the selection of best system for the job. The system required performance is defined by a statement of constraints, the identification of specific system objective and a description of outputs. Steps in feasibility analysis The following steps are involved in the feasibility analysis. They are : Form a project team and appoint a project leader. Prepare system flowcharts. Enumerate potential proposed systems. Define and identify characteristics of proposed system. Determine and evaluate performance and cost effectiveness of each proposed weight system performance and cost data. Select the best proposed system. Type of feasibilities The key considerations in feasibility analysis are: • Operational Feasibility The preliminary investigation of the current system leads to the fact that it is operationally feasible. s of the system will not resist for the induction of the new system because the 13
project is going to help them a lot as, it will increase their efficiency by reducing the time for doing the same repetitive task. It is mainly related to human organizational and political aspects. The points to be considered are: • What changes will be brought with the system? • What organizational structures are disturbed? Generally project will not be rejected simply because of operational infeasibility but such considerations are likely to critically affect the nature and scope of the eventual recommendations. • Economic feasibility Since the current system is small the investigation on the project would be of normal expense. It is economical, as investment needed for developing this project would need one personnel computer and some operational cost is needed for the project. There is very little development cost. According to the computerized system we propose, the costs can be broken down to two categories. Costs associated with the development of the system. Costs associated with operating the system. From our analysis, we came to result that both these costs occurred to the developers will be recurred within first 6 months of project implementation thereafter providing economical benefits so ever. So, we can see that current system is economically feasible. • Technical feasibility This is concerned with specifying equipment and software that will successfully satisfy the requirement. The technical needs of the system may vary considerably, but might include: 14
• The facility to produce outputs in a given time. • Response time under certain conditions. • Ability to process a certain volume of transaction at a particular speed. Legal feasibility Legal feasibility is a determination of whether a proposed project infringes on known Acts, Statutes, as well as any pending legislation. Basically legal feasibility is to determine whether the proposed system conflicts with the legal requirements. e.g. a data processing system must comply with the Local Data Protection Acts Its simply to determine the any infringement and everything must comply the legal requirements.
15
16
SOFTWARE LIFE CYCLE MODELS The goal of Software Engineering is to provide models and processes that lead to the production of well-documented maintainable software in a manner that is predictable. “The period of time that starts when a software product is conceived and ends when the product is no longer available for use. The software life cycle typically includes a requirement phase, design phase, implementation phase, test phase, installation and check out phase, operation and maintenance phase, and sometimes retirement phase”. Methodology usedIn Iterative model, iterative process starts with a simple implementation of a small set of the software requirements and iteratively enhances the evolving versions until the complete system is implemented and ready to be deployed. An iterative life cycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which is then reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software at the end of each iteration of the model.
17
Iterative Model Design: Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental). Following is the pictorial representation of Iterative and Incremental model:
The iterative model consists of five phases: 1.Requirements. 18
2.Design. 3.Implementation . 4.Testing. 5.Review. 1.Requirements : A requirement phase involves in collection of requirements that are needed to develop the software for analyzing. Requirements phase goes on until the complete requirements are gathered and analyzed. Once the requirements are gathered for the first phase. We move on to the next phase. 2. Design :In design phase , as per the gathered requirements the deg takes place in order to give the best software product to the client. The design may include the previous projects design or new projects design whichever is feasible for the software development. 3. Implementation: In the implementation phase, where in the coding of the software takes place as per the requirements and design done in step 1 and 2. 4.Testing: After implementing the software, the individual modules are combined together to form a integrated software and testing phase starts from the scratch. 5.Review: In review process, the software developed is under evaluation , the available current requirements are reviewed and changed if necessary . If any additions are made to the current requirements they are taken to the next cycle implementation. After completion of all the phases we can come to the conclusion that one complete cycle is completed. Now we have to make a decision whether the developed software can be taken to the next cycle or we need to start from the scratch as the developed software did not meet the client expectation. 19
Then another cycle starts from the requirements phase to review phase this process is an iterative process, the process ends when the complete software is developed as per the client satisfaction. Each cycle can be taken as individual versions. So, in a nutshell, in incremental model the whole requirement is divided into various builds. During each iteration, the development module goes through the requirements, design, implementation and testing phases. Each subsequent release of the module adds function to the previous release. The process continues till the complete system is ready as per the requirement. ADVANTAGES: The advantage of this model is that there is a working model of the system at a very early stage of development which makes it easier to find functional or design flaws. Finding issues at an early stage of development enables to take corrective measures in a limited budget. Thus the advantages can be summarized as: • Avoids the problems resulting in risk driven approach in the software • Understanding increases through successive refinements. • Performs cost-benefit analysis before enhancing software with capabilities. • Incrementally grows in effective solution after every iteration • Does not involve high complexity rate. • Results are obtained early and periodically. • Parallel development can be planned and progress can be measured.
20
21
Introduction: The Systems Requirements Specification (SRS) is designed to express the behavioral, performance, and development requirements of this product and serves as the fundamental requirements document for the development of the product. The Systems Requirements Specification includes a description of every input into the system, every output from the system and all functions performed by the system in response to input or in of an output. The SRS meets IEEE standards and is the exclusive requirements document to be used in development; all design and testing choices must be compatible with this document. Purpose: The purpose of this document is to outline the requirement of Hospital management system making it computerized and to study the requirement of its various s. Scope The software to be produced would be Hospital management system of ABC hospital. This product would make the hospital management system automated from manual system. It shall reduce the redundancy, paperwork, maintenance of records.
22
s should be able to insert, modify or update the records. work load and paper work of maintaining the records in a file or folder manually. The overall goal of this would be : •
Reduce paper work
•
Easy to update
•
Computerized
•
Maintain security
Overview The software requirement specification provides the developer with the requirements of the . When developer knows about the requirements of the he can design it accordingly. SRS also helps in feasibility study as well by providing an input for the latter. The requirements would help to determine whether the software can be developed. OVERALL DESCRIPTION Product Perspective Hospital management system is a replacement for the manual system which depends on paper work for recording information. The software will ease the burden of by performing various tasks such as storing information of patients, updating of databases etc. This hospital management also generates a complete summary of payable bills and collected amount.
23
Product Functions It would help in providing adequate data to the management. It would also end the practice of keeping records in files and stacking up a pile of files. This would help the hospital prepare and organize its patient related records more efficiently on the basis of each student report. Normal s The Patients should be provided with the updated information about their bills. Patients have the facility to view their report or any information related to it. They can also see their bill status ie, paid, outstanding etc. Characteristics s of the software are patients, staff and the s who maintain the system. are assumed to have basic knowledge of computers. s of the system should have more knowledge of internal modules of the system and are able to rectify small problems that may arise due to disk crashes, power failures and other catastrophes. Friendly interface, must be sufficient to educate the s on how to use this product without any problems or difficulties. ’s Requirement:A requirement specifies capabilities that a system must provide in order to solve a problem. Requirements include:•
Functional requirements
•
Performance requirements
24
A clear statement of the requirements and information needs is necessary for good system design. If the information required is not complete or the objectives are not identified properly and clearly, then the design effort will produce less than optimum results. Information needs also vary at different levels. Functional requirements: Modules in the project1.
2.
In Patient
3.
Out Patient
4.
Lab
5.
Billing
6.
View Reports
When the explains his current scenario of work, the developer may not quite get him. It is very essential for the developer to understand the way things are functioning at the ’s place, since it is on the basis of his understanding that he will develop the software and computerize the current system. In turn the also needs to understand how things are going to get computerized and how is work scenario going to change once things are computerized. To be able to fetch the purpose of the developer and the we develop a document called Software requirement Specification (SRS). SRS is a document that explains what the proposed software 25
should do. It focuses on what has to be done and not on how. It describes the complete behavior of the proposed software. The usually does not understand software or software development process so he needs that things are put down in black and white in simple manner. So, this communication gap is bridged by the software requirement specification. An SRS establishes an agreement between the and the developer on what the requires and what the software product will do: •
Aim
•
characteristics
•
General constraints
•
General assumption
•
Information description:
PERFORMANCE REQUIREMENTS The performance features which is required in the proposed system is Friendliness The proposed system should be friendly, understandable and easy to use. It should provide on line help and error messages for ease. should be able to take the output of reports on the screen. Requirements• This software should not breakdown suddenly in any disaster like power failure.
26
• The timeline of this software must be in our mind. • The performance of the functions and every module must be well. • At every step the output of the one phase is the input of the other phase and it will be reliable and accurate. • The risk factor must be taken at initial step for better performance of the software. • For individual function the performance will be well. • For to the software and name will be matched to the and name saved in the database and thus only authenticated s are allowed to the . • There will be various ways of retrieving data and it takes less time. Safety Requirements The database may get crashed at any certain time due to virus or operating system failure. Therefore, it is required to take the database backup Security Requirements We are going to develop a secured database for the school. Depending upon the category of the access rights are decided. It means if the is an then he can be able to modify the data, delete, append etc. Whereas the can only view the information but cannot update or delete the records. HARDWARE REQUIREMENTS PROCESSOR-
Intel Pentium III processor 27
RAM-
Minimum 128 MB RAM Recommended 256 MB RAM
HARD DISKNETWORK-
Minimum hard disk 40GB Internet connection through Modem or LAN Card
6.7.4 SOFTWARE REQUIREMENTS WINDOWS XP OPERATING SYSTEM •
MS Access 2007
•
MS WORD 2007
•
Microsoft Visual Basic-6.0
6.7.5 Technology Used •
Front End: - Microsoft Visual Basic-6.0
•
Back End: - Microsoft Access.
Constraints: The computer should have enough processor speed, memory, and hard disk space to run the complier we’ve chosen. We can check the manufacturer’s specification to determine these requirements
28
The above specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly. SPECIFIC REQUIREMENTS Interface Constraints Using this system is fairly simple and intuitive. A familiar with basic browser navigation skills should be able to understand all functionality provided by the system. Hardware Constraints The system should work on only school istration desktop computers. Software Constraints No specific software required Communications Constraints System must have access to the included database. Other components of the fee management system may require access to certain data which is available with school istration only.
29
30
PURPOSE The purpose of this document is to describe the implementation of software,” HOSPITAL MANAGEMENT SYSTEM” for ABC Hospital. The software is developed for computerizing the working in a hospital and is capable to provide easy and effective storage of information related to patients that come up to the hospital. SCOPE: This software can be used in any Hospital, Clinic for maintaining patient details and their test results. SYSTEM OVERVIEW This system is designed to reduce the paperwork and provide ease for maintaining , searching ,updating and deleting the information about the patients and staff . will be responsible for updating information about the patients and patients are also provided with facility to view their reports and bills. MODULE DECOMPOSITION: It describes different modules of the system, shown in entity relationship diagram: a) : This module provides with the facility to in the system and add ,delete , update or view information about the patients. Also the patients can and view their medical reports and bills.
31
b) INPATIENT: This module consist of list of inpatients and their information such as their personal details as well as it and discharge date, ward allotted to them etc. has right to update the inpatient list . c) OUTPATIENT: This module consists of the list of outpatients and their personal information. can add, delete and update the information. d) LAB: This module provides the facility for generating medical reports of the patients. e) BILLING- This module provides the facility for generating the bills of the treatment of the patient .This module is accessible by the patients also in order to see their bills and make payment. f) VIEW REPORTS- This module allows patients to view their reports(eg xray,blood test etc). 3.2 CONCURRENT PROCESS DECOMPOSITION: It describes the concurrent processes of system software. a) SIMULTANEOUS : or Patient can software simultaneously. c) SIMULTANEOUS AND UPDATE:
While
is updating
the
information about the patients , simultaneously on the other side patient can view his reports and billing status. DATA DECOMPOSITION: This section contains a description of each data element that is shared between components, its storage, and its logical structure (but not its representation in a programming language).
32
a) DATA SHARING: Data is shared between modules to keep each section of system well informed and up to date. Patients can view their reports and bills. b) DATA STORAGE: In order for system to function, it must have access to a database such as MySQL, which contains information about system as well as s. The database is constructed using relational model, which means that links can be made between various tables, attributes of tables. c) DATA ACCESS : Data can be accessed ,updated ,deleted by only while the patients can view their medical reports and bills only. These functions can be performed through menu options provided at frontend, at backend it could be performed by queries. 4. DEPENDENCY DESCRIPTION: The following section will describe the relationship between each given module of the system with the other modules of the system. MODULE DEPENDENCY: This section outlines the dependencies and interactions in the modules. 1. : can to system through ID and . 2. INPUT: The system receives input from the . This input can be taken in the form of a text field and submitting by clicking on a button . 3. DATABASE: The Server then processes this information and calls methods on to solve the queries (request by through input).
33
4. OUTPUT: After successfully performing the queries desired result is returned. For the desired output would be the changes made by him in database and for patients result would be display of their medical reports and bills. 4.2 DATA DEPENDENCY: This section describes the different database tables that make up the database for the system.
34
USE CASE It is a visually representation what happens when actor interacts with system. A use case diagram captures the functional aspects of a system. The system is shown as a rectangle with name of the system inside ,the actor are shown as stick figures, the use case are shown as solid bordered ovals labeled with name of the use case and relationships are lines or arrows between actor and use cases. Symbols used in Use case are as followsUse case
Relationship
Actors
35
In Patient
Out patient
Lab
Payment Receipt
Fig() Use Case diagram for hospital management system
36
37
Data flow diagram A data flow diagram or bubble chart (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated. DFDs can also be used for the visualization of data processing (structured design). A DFD shows what kinds of information will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel (which is shown on a flowchart). The primitive symbols used for constructing DFD’s are: Symbols used in DFD A circle represents a process.
A rectangle represents external entity
A square defines a source or destination of the system data.
An arrow identifies dataflow. 38
Double line with one end closed indicates data store Data Flow Diagrams a) Context level Diagram
LEVEL 0 DFD
VIEW REPORTS
IN PATIENT Patient
OUT PATIENT
HOSPITAL MANAGEMENT SYSTEM
VIEW REPORTS
39
PAYMENT
Patient
LEVEL 1 DFD Patient
Table
ID and wod
In patient Enter details In In Patient Patient
Out patient Enter details Out Out patient patient
Discharge details
Payment table Patient
Amount Payment Payment
Save details
Update in
Give details
Reports table
Lab Lab
Name and patient’s details
Receipt given Receipt Receipt
40
LEVEL TWO DFD
Level 2 DFD
Patient
table
ID and
1.1 Update
1.2 Change
Payment
Payment table
Update database
Amount paid Payment
Patient
41
IN PATIENT In patient table Add Patient’s details
Patient’s details
Patient’s details
Patient’s details
2.1 2.1 Create Create
2.2 2.2 View View
View
2.3 2.3 Edit Edit
Edit
2.4 2.4 Delete Delete
42
Delete
Payment
Payment table
Update database
Amount paid Payment
Patient
Out patient
Out patient table Add Patient’s details
Patient’s details
Patient’s details
Patient’s details
2.1 2.1 Create Create
2.2 2.2 View View
View
2.3 2.3 Edit Edit
Edit
2.4 2.4 Delete Delete
43
Delete
Lab Patient’s detail
Add in database
Lab Lab
Report generated Given to Reports Reports
44
Lab table
45
Entity Relationship Diagram
Hospital Management E-R Diagram Employee Age
Is A
Name Name
Name Name Patient ID ID Address Address
Receptionist Doctor
Attends Date itted Name
Nurse
Doctor_Id Doctor_Id
Assigned
ID ID
Governs
Room
Maintains Name Name Room_ID Room_ID
Room Room Type Type
Records Patient’s Patient’s info info
Record Record No No
46
Appointment Appointment
47
1.
Interface Design
Unsucessful
48
CHANGE
IN PATIENT
49
OUT PATIENT
50
PAYMENT
51
RECEIPT
LAB 52
53
54
Testing & Debugging Testing Methodology Testing is the process of executing a program with the intent of finding errors” As we know, software is one component of a large computer based system. Ultimately, Software is incorporated with other system components and thus, a series of special tests are to be conducted. Petschenik gives some guidelines for choosing test cases during system testing. The first is that testing the system’s capabilities is more important than testing its components. During system testing, we should evaluate a number of attributes of the software that are vital to the . Testing The most crucial stage of software development, testing validates the application. During testing we will be concerned about the inputs and their expected outputs. We emphasize on the testing where we will input the data and compare the output with the expected results. At this stage we are not concerned about the process; we are only looking for correct outputs. Various software testing techniques exists which take different approaches to test and validate a software. Tests done on the designed software was to the following properties of the software: Correctness (satisfaction of the specifications)
55
Reliability (how well it meets the requirements) Portability (running in different environments) Usability (ease with which can use the software) Maintainability (modifications after initial release)
Debugging Debugging is removing the undesirable errors or bugs from the program. We implemented debugging using the Visual basic compiler in which the application was developed. During testing the program to tested is executed with the set of test cases and have the output of the program for the test cases is evaluated to determine if the program is performing as expected. Due to its approach dynamic if the program is performing as expected. Due to its approach dynamic testing can only presence of errors in the program, the exact nature of errors is not usually decided by testing. Testing forms is the process to determine errors in the program. Once a program are tested individually then the system as a whole needs to be tested. During testing the system is used experimentally to ensure that the software does not fail i.e. it will run according to its specification. The programs executed to check for any syntax and logical errors. The errors are corrected and test is made to determine whether the program is doing what supposed to do.
56
Software Testing Techniques The importance of software testing and its impact on software cannot be under estimated. Software testing is a fundamental component of software quality assurance and represents are view of specification, design and coding. The greater visibility of software systems and the cost associated with software failure are motivating factors for planning, through testing. It is not uncommon for a software organization to spent 40% of its effort on testing.
White Box Testing White box testing is a test case design approach that employs the control architecture of the procedural design to produce test cases. Using white box testing approaches, the software engineering can produce test cases that Guarantee that all independent paths in a module have been exercised at least once. Execute all loops at their boundaries and in their operational bounds Exercise internal data structures to maintain their validity.
Various white box techniques Basis Path Testing: Basic path testing is a white box testing techniques that allows the test case designer to produce a logical complexity measure of procedural design and use this measure as 57
an approach for outlining a basic set of execution paths. Test cases produced to exercise each statement in the program at least one time during testing. Control Structure Testing: Although basis path testing is simple and highly effective, it is not enough in itself. Next we consider variations on control structure testing that broaden testing coverage and improve the quality of white box testing. Different control structure techniques are Condition testing Data flow testing Loop testing Black Box Testing: Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc. As the name "black box" suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Various black box techniques Functional Testing: In this type of testing, the software is tested for the functional requirements. The tests are written in order to check if the application behaves as expected. Smoke Testing: This type of testing is also called sanity testing and is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level.
58
Recovery Testing: Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc. Type or extent of recovery is specified in the requirement specifications. Alpha Testing: In this type of testing, the s are invited at the development center where they use the application and the developers note every particular input or action carried out by the . Any type of abnormal behavior of the system is noted and rectified by the developers. Beta Testing: In this type of testing, the software is distributed as a beta version to the s and s test the application at their sites. As the s explore the software, in case if any exception/defect occurs that is reported to the developers. Software Testing Strategies in used in the project A strategy for software testing integrates software test case design techniques into a well-planned set of steps that cause the production of software. A software test strategy provides a road map for the software developer, the quality assurance organization, and the customer Unit testing: Unit testing concentrates verification on the smallest element of the program the module. Using the detailed design description important control paths are tested to establish errors within the bounds of the module. Firstly the unit testing on various modules and sub modules is performed in the project. Different modules are tested with different correct and incorrect data. For example in the order processing module order of 0 product is not allowed so in this case different methods are used to find out whether the modules is performing all processes correctly. All modules are tested to find out that whether they are working properly
59
Integration testing :-Once all the individual units have been tested there is a need to test how they were put together to ensure no data is lost across interface, one module does not have an adverse impact on another and a function is not performed correctly. Integration testing is a systematic approach that produces the program structure while at the same time producing tests to identify errors associated with interfacing.In this project bottom up integration testing is used. Firstly lower level modules are tested. As modules are integrated bottom up, processing required for modules subordinates to a given level is always available and the need for stubs is eliminated. Validation testing :-As a culmination of testing, software is completely assembled as a package, interfacing errors have been identified and corrected, and a final set of software tests validation testing are started. Validation can be defined in various ways, but a basic one is valid succeeds when the software functions in a fashion that can reasonably expected by the customer. In the first phase of alpha testing, developers test the software using white box techniques. Additional inspection is then performed using black box techniques. This is usually done by addicted testing team. This is often known as the second stage of alpha testing. Unit and integrated tests concentrate on functional verification of a component and incorporation of components into a program structure. Validation testing demonstrates tractability to software requirements, and system testing validates software once it has been incorporated into a larger system. Test Cases Specification for System Testing The different conditions that need to be tested, along with the test cases used for testing those conditions and expected output are given. The goal is to test different functional requirements, as 60
specified in requirement document. Test cases have been selected for both valid and invalid inputs.
Test CasesModule1-
S.no
Test Case
Description INPUT
Expected OUTPUT
Result
1
name
name to be displayed and should not be empty “ to the system should not be empty
“Matched”
2
The name set should be entered The should be entered
Expected OUTPUT
Result
Id Type: text form Type: text “text” form
“ successful”
Module 2 (In Patient)
S.no
Test Case
Description INPUT
1
S.no
The S.no of patient to be entered and unique s.no tobe entered
2
Name
The name of the patient to be itted
3
Address
4
The Address of patient to be entered The number of patient
Type: number The s.no should be unique for every Patient and should not be in text Name to be Type: text displayed and form should not be empty Address Address to be Type: taken by the Alphanumeric system Type=number no. to Should input be taken only numeric values
61
The record to be saved in database
Record to be saved within the database Record to be saved within the database Record to be saved within the database
5
Age
The age to be Type = entered number Text values will not be accepted
Age to be displayed and should not be empty
Record to be saved within the database
Expected OUTPUT
Result
Module 3 :Out Patient
S.no
Test Case
Description INPUT
1
S.no
The S.no of patient to be entered and unique s.no tobe entered
2
Name
3
Address
4
5
Age
6
Date itted
7
Date discharged
8
Bill Status
Type: number The s.no should be unique for every Patient and should not be in text The name of Name to be the patient to Type: text displayed and be itted form should not be empty The Address Address Address to be of patient to Type: taken by the be entered Alphanumeric system The Type=number no. to number of Should input be taken patient only numeric values The age to be Type = Age to be entered number displayed and Text values should not be will not be empty accepted The date of Type= date Date of ission of text value ission to the patient should not be be displayed entered The date of Type =date Date of discharge of discharge to the patient be displayed The bill should be Bill status to status to be checked be shown paid whether paid or not paid 62
The record to be saved in database
Record to be saved within the database Record to be saved within the database Record to be saved within the database Record to be saved within the database
Record to be saved within the database Record to be saved within database Record to be saved within database
Module 4 (Lab)
S.no 1
Test Case
Description
INPUT
Name
The name of the patient to be itted
Type: text form
2
Address
3
Test Name
4
Description
S.no
The Address of patient to be entered The test to be conducted in the lab The description of the report made of the test conducted
Test Case
Description
1
Name
The name of the patient
2
Address
3
Amount Paid
4
Amount Due
The Address of patient to be entered The amount paid by the patient The amount the patient has to pay
Expected OUTPUT
Result
Name to be displayed and should not be empty Address Address to be Type: taken by the Alphanumeric system Type: Text The test of name to be displayed Type :Text The results of the report to be displaye
Record to be saved within the database
INPUT
Result
Expected OUTPUT Name to be Type: text displayed and form should not be empty Address Address to be Type: taken by the Alphanumeric system Type: The amount Number paid to be displayed Type: The amount Number patient has to pay
63
Record to be saved within the database Record to be saved within the database Record Saved
Record to be saved within the database Record to be saved within the database Record to be saved within the database Record to be saved within the database
64
Software needs to be maintained not because some of its components wear out and need to be replaces but because there are often some residual errors remaining in the system that must be removed as they are discovered. Many of the errors surfaces only after the system have been in operation, sometimes for a long time. To discovered & removed such type of errors called
Corrective maintenance. Up gradation, enhancement, modification, include some more features & added some more services are the such type of changes which a software must adapt to the needs of the changed environment. The changed software then changes the environment, which in turn requires further changes, called Adaptive Maintenance. As software is used, the will recognize additional functions that will provide benefit,It comes under Perfective maintenance. This maintenance extends the software beyond its original functional requirements. For maintenance point of view, we have taken all three approaches: 1. Corrective Maintenance 2. Adaptive Maintenance 3. Perfective Maintenance
65
Corrective Maintenance: In Transportation System Automation Process, we have checked the system with original data of the . We will collect the errors which surfaces after system has started working & will remove them immediately by repairing processing. Because there are often some residual errors remaining in the system so in future prospects we shall also discoverthe errors on regular basis, which can be remaining in the system and all will be removed by us day to day. Adaptive Maintenance: we have adopted such type of approach that after up gradation or modification or any further enhancement, the software should be environment compatible but if it requires further changes according to the needs we will maintain it as needed. Perfective Maintenance: We have taken a lot of care at the time of analysis but after the starts using the software, if suggested we will add additional functions to enhance the functionality of the software. If the is looking for any additional enhancement in this system like, Addition of any new module or any modification in any module or any up gradation in any of the existing module can be added, modify and up graded easily with out any difficulty or major changes. After the completion of any further changes like modification, up gradation or any enhancement we have also a step of regression testing. In this step we will execute the old test cases to check that if there is any error occurs after changes has taken place. System Evaluation Evaluation of the system is performed to identify its strengths and weakness. 66
Operational Evaluation: In this, assessment of the system functions, ease of use, response time, and suitability of information’s formats, overall reliability, and level of utilization is undertaken.
All the above aspects were very well taken into consideration from the very beginning. Reliability of this project is high. Recovery methods are well written, even if something exceptional occurs has a way to come out of the undesirable situation and carry on with the work. Records are saved only if they are valid.
67
Objectives of the Project The main objective of hospital management system is to perform all the functions or operations accurately and correctly. The proposed system has the following objectives to be achieved. 1. Friendly Environment. 2. Less Space. 3. Fast Retrieval. 4. Easy to Operate. 5. Accuracy. 6. Receipt generation
Scope of The Project 1. Including module to enable the software’s to record payment done by patient 2. Including a module that adds the record of a new patient 3. Including a module to view the patient’s record Future Scope and Limitations Hospital management system is in itself a complete system, though it has a few limitations but it has a lot of future scope and features that could be added to make it more widely acceptable. One limitation is that our software is limited to small and medium scaled hospitals. One of the major future scope is making our system online. Connecting the system of a particular hospital to a common data centre will provide globalization to the school, and then the will be able to share the data across the branches. Summary
68
The project entitled “Hospital Management” is about Managing fee records. There are many functions like registration, , change , payment, inpatient,out patient etc. The end can the Patient by filling the necessary details and can make the payment on student’s behalf. During process there is one more function available that is change . This function allows the to change the . Successful will lead to registration form where can the patient and record all the data of the patient.
Conclusion
This software is a database project with all the basic capabilities a database should have. This application software is about student fee system and it records and maintains records about the student fee. In doing so, an appreciation of project management, communication and consultancy skills should be acquired, along with a thorough understanding of the development of windows based applications using Visual basic. I feel that all of these aims were achieved, some to greater extent than others.
69
70
The references for the project “HOSPITAL MANAGEMENT SYSTEM” have been taken from the following books and website.
WEB REFERENCES
http://en.wikipedia.org/
BOOKS REFERENCES Software engineering by KK AGGRAWAL Software engineering by Pankaj Jalote
71
Submitted in partial fulfillment of the requirements for the award of the degree of Master of Computer Application To Guru Gobind Singh Indraprastha University, Delhi Submitted to
Submittedby: Yash Kapoor Rahul Kapooria Sweta thapa Neetu Rana
1
Certificate We, Yash Kapoor ,Sweta thapa , Rahul Kapooria , Neetu Rana certify that the Project Report entitled “Hospital Management System” is done by us and it is an authentic work carried out by us at “Lal Bahadur shastri institute of Management.” The matter embodied in this project work has not been submitted earlier for the award of any degree or diploma to the best of my knowledge and belief.
2
ACKNOWLEGEMENT
Apart from our efforts, the success of our project depends largely on the encouragement and guidelines of many others. We take this opportunity to express my gratitude to the people who have been instrumental in the successful completion of this project. We would like to show our greatest appreciation to our Project guide Mr Bhavya Deep. We can’t say thanks enough for the tremendous and help. Without their encouragement and guidance this project work would not have been materialized. Finally we would also like to extend our profound thanks to all our esteemed colleagues who helped us in specific areas of the project.
3
1.
INTRODUCTION
Pg. No. 5-7
2.
PROBLEM STATEMENT
8-9
3.
QUESTIONNAIRE
10-11
4.
FEASIBILITY STUDY
12-15
5.
PROCESS MODEL
16-20
6.
SOFTWARE REQUIREMENT 21-29 SPECIFICATION SOFTWARE DESIGN DOCUMENT 30-33
Sno.
7.
Topic
8.
USE CASE DIAGRAM
34-36
9.
DATA FLOW DIAGRAM
37-44
10.
E-R DIAGRAM
45-46
11.
SCREEN SHOTS
47-52
12.
TESTING
53-62
13.
SYSTEM MAINTENANCE AND 63-66 EVALUATION OBJECTIVES,SCOPE,SUMMARY 67-68 CONCLUSION OF PROJECT REFERENCES 69-71
14. 15. 16. 17.
ADVANTAGES
18. 19.
4
5
The Hospital Management System is designed for Any Hospital to replace their existing manual, paper based system. This project targets to provide complete solution for Hospital and related services. The project Hospital Management system includes registration of patients, storing their details into the system, and also computerized billing in the pharmacy, and labs. The software has the facility to give a unique id for every patient and stores the details of every patient and the staff automatically. It includes a search facility to know the current status of each room. can search availability of a doctor and the details of a patient using the id. The Hospital Management System can be entered using a name and . It is accessible either by an or receptionist. Only they can add data into the database. The data can be retrieved easily. The interface is very -friendly. The data are well protected for personal use and makes the data processing very fast. The purpose of the project entitled as “HOSPITAL MANAGEMENT SYSTEM” is to computerize the Front Office Management of Hospital to develop software which is friendly, simple, fast, and cost – effective. It deals with the collection of patient’s information, diagnosis details, etc. Traditionally, it was done manually. The main function of the system is to and store patient details and doctor details and retrieve these details as and when required, and also to manipulate these details meaningfully System input contains patient details, diagnosis details; while system output is to get these details on to the CRT screen. The common features of this type of software are:
6
• This software facilitates complete and smooth running of the reception. • It manages all the bed allocation systems and the wards of the hospitals. • It manages the laboratory and the equipments. • It manages the treatments as well as the entire history of the patients • This software manages the day to day scheduling of both the nurses and the doctors to various departments and also allocates the schedules of their duties. • It also manages the timely and proper ing to make sure a proper and current billing. • The hospital management software also maintains the proper tests of a number of patients as well as keeps the records of all the medical reports. • The biggest benefit of the hospital management system is that it can be used at the same time via a number of s.
7
8
The information is very difficult to retrieve and to find particular information like- E.g. - To find out about the patient’s history, the has to go through various s. This results in inconvenience and wastage of time. The information generated by various transactions takes time and efforts to be stored at right place. Various changes to information like patient details or immunization details of child are difficult to make as paper work is involved. Manual calculations are error prone and take a lot of time this may result in incorrect information. For example calculating patient’s bill based on various treatments. This becomes a difficult task as information is difficult to collect from various s. How can we overcome the limitations of the manual system? The working in the organization will be well planned and organized. The data will be stored properly in data stores, which will help in retrieval of information as well as its storage. The level of accuracy in the proposed system will be higher. All operation would be done correctly and it ensures that whatever information is coming from the center is accurate. The reliability of the proposed system will be high due to the above stated reasons. The reason for the increased reliability of the system is that now there would be proper storage of information. In the proposed system utmost care would be that no information is repeated anywhere, in storage or otherwise. This would assure economic use of storage space and consistency in the data stored. The main objective of proposed system is to provide for a quick and efficient retrieval of information. Any type of information would be available whenever the requires. In manual system there are many problems to store the largest amount of information. The system should be easy to operate and should be such that it can be developed within a short period of time and fit in the limited budget of the .
9
10
Questionnaire Que1- What is the problem with the current system? Que2- What do you want in this system exactly? Que3- What modules you would like to be in the system? Que4- What kinds of features do you think would attract you to use this system? Q5 Who would be the s of the hospital management system? Q6 Would you like to display the patient’s report online by providing patients a id and ? Q7 A friendly system will be perfect as people with less technical knowledge should be able to use it? Q8 How many record should the database be able to hold? Q9. Timely updation to be made in the software so that huge amount of record to be maintained? Q10 The entries in the software to be self explanatory so as to avoid confusion? Q11. Software to be secured from unauthorized access? Q12 Allocation of rooms to patients operated should be done simultaneously? Q13What kind of platform for working is required? Q14 Any kind of special security is needed for the software? Q17 Are you satisfied with the current processes and policies? Q18 what data required by exist in other system? Q19 what problem do you want this system to solve? Q20 Do you need any additional functionality for improving the performance of the system? Q21 Have you faced any calculation errors in the past? Q22 Who is the controller of the software? Q23 Who will be using the software? Q24 Who will explain the manual system?
11
12
Feasibility Study A feasibility study is conducted to select the best system that meets performance requirement. This entails an identification description, an evaluation of candidate system and the selection of best system for the job. The system required performance is defined by a statement of constraints, the identification of specific system objective and a description of outputs. Steps in feasibility analysis The following steps are involved in the feasibility analysis. They are : Form a project team and appoint a project leader. Prepare system flowcharts. Enumerate potential proposed systems. Define and identify characteristics of proposed system. Determine and evaluate performance and cost effectiveness of each proposed weight system performance and cost data. Select the best proposed system. Type of feasibilities The key considerations in feasibility analysis are: • Operational Feasibility The preliminary investigation of the current system leads to the fact that it is operationally feasible. s of the system will not resist for the induction of the new system because the 13
project is going to help them a lot as, it will increase their efficiency by reducing the time for doing the same repetitive task. It is mainly related to human organizational and political aspects. The points to be considered are: • What changes will be brought with the system? • What organizational structures are disturbed? Generally project will not be rejected simply because of operational infeasibility but such considerations are likely to critically affect the nature and scope of the eventual recommendations. • Economic feasibility Since the current system is small the investigation on the project would be of normal expense. It is economical, as investment needed for developing this project would need one personnel computer and some operational cost is needed for the project. There is very little development cost. According to the computerized system we propose, the costs can be broken down to two categories. Costs associated with the development of the system. Costs associated with operating the system. From our analysis, we came to result that both these costs occurred to the developers will be recurred within first 6 months of project implementation thereafter providing economical benefits so ever. So, we can see that current system is economically feasible. • Technical feasibility This is concerned with specifying equipment and software that will successfully satisfy the requirement. The technical needs of the system may vary considerably, but might include: 14
• The facility to produce outputs in a given time. • Response time under certain conditions. • Ability to process a certain volume of transaction at a particular speed. Legal feasibility Legal feasibility is a determination of whether a proposed project infringes on known Acts, Statutes, as well as any pending legislation. Basically legal feasibility is to determine whether the proposed system conflicts with the legal requirements. e.g. a data processing system must comply with the Local Data Protection Acts Its simply to determine the any infringement and everything must comply the legal requirements.
15
16
SOFTWARE LIFE CYCLE MODELS The goal of Software Engineering is to provide models and processes that lead to the production of well-documented maintainable software in a manner that is predictable. “The period of time that starts when a software product is conceived and ends when the product is no longer available for use. The software life cycle typically includes a requirement phase, design phase, implementation phase, test phase, installation and check out phase, operation and maintenance phase, and sometimes retirement phase”. Methodology usedIn Iterative model, iterative process starts with a simple implementation of a small set of the software requirements and iteratively enhances the evolving versions until the complete system is implemented and ready to be deployed. An iterative life cycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which is then reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software at the end of each iteration of the model.
17
Iterative Model Design: Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental). Following is the pictorial representation of Iterative and Incremental model:
The iterative model consists of five phases: 1.Requirements. 18
2.Design. 3.Implementation . 4.Testing. 5.Review. 1.Requirements : A requirement phase involves in collection of requirements that are needed to develop the software for analyzing. Requirements phase goes on until the complete requirements are gathered and analyzed. Once the requirements are gathered for the first phase. We move on to the next phase. 2. Design :In design phase , as per the gathered requirements the deg takes place in order to give the best software product to the client. The design may include the previous projects design or new projects design whichever is feasible for the software development. 3. Implementation: In the implementation phase, where in the coding of the software takes place as per the requirements and design done in step 1 and 2. 4.Testing: After implementing the software, the individual modules are combined together to form a integrated software and testing phase starts from the scratch. 5.Review: In review process, the software developed is under evaluation , the available current requirements are reviewed and changed if necessary . If any additions are made to the current requirements they are taken to the next cycle implementation. After completion of all the phases we can come to the conclusion that one complete cycle is completed. Now we have to make a decision whether the developed software can be taken to the next cycle or we need to start from the scratch as the developed software did not meet the client expectation. 19
Then another cycle starts from the requirements phase to review phase this process is an iterative process, the process ends when the complete software is developed as per the client satisfaction. Each cycle can be taken as individual versions. So, in a nutshell, in incremental model the whole requirement is divided into various builds. During each iteration, the development module goes through the requirements, design, implementation and testing phases. Each subsequent release of the module adds function to the previous release. The process continues till the complete system is ready as per the requirement. ADVANTAGES: The advantage of this model is that there is a working model of the system at a very early stage of development which makes it easier to find functional or design flaws. Finding issues at an early stage of development enables to take corrective measures in a limited budget. Thus the advantages can be summarized as: • Avoids the problems resulting in risk driven approach in the software • Understanding increases through successive refinements. • Performs cost-benefit analysis before enhancing software with capabilities. • Incrementally grows in effective solution after every iteration • Does not involve high complexity rate. • Results are obtained early and periodically. • Parallel development can be planned and progress can be measured.
20
21
Introduction: The Systems Requirements Specification (SRS) is designed to express the behavioral, performance, and development requirements of this product and serves as the fundamental requirements document for the development of the product. The Systems Requirements Specification includes a description of every input into the system, every output from the system and all functions performed by the system in response to input or in of an output. The SRS meets IEEE standards and is the exclusive requirements document to be used in development; all design and testing choices must be compatible with this document. Purpose: The purpose of this document is to outline the requirement of Hospital management system making it computerized and to study the requirement of its various s. Scope The software to be produced would be Hospital management system of ABC hospital. This product would make the hospital management system automated from manual system. It shall reduce the redundancy, paperwork, maintenance of records.
22
s should be able to insert, modify or update the records. work load and paper work of maintaining the records in a file or folder manually. The overall goal of this would be : •
Reduce paper work
•
Easy to update
•
Computerized
•
Maintain security
Overview The software requirement specification provides the developer with the requirements of the . When developer knows about the requirements of the he can design it accordingly. SRS also helps in feasibility study as well by providing an input for the latter. The requirements would help to determine whether the software can be developed. OVERALL DESCRIPTION Product Perspective Hospital management system is a replacement for the manual system which depends on paper work for recording information. The software will ease the burden of by performing various tasks such as storing information of patients, updating of databases etc. This hospital management also generates a complete summary of payable bills and collected amount.
23
Product Functions It would help in providing adequate data to the management. It would also end the practice of keeping records in files and stacking up a pile of files. This would help the hospital prepare and organize its patient related records more efficiently on the basis of each student report. Normal s The Patients should be provided with the updated information about their bills. Patients have the facility to view their report or any information related to it. They can also see their bill status ie, paid, outstanding etc. Characteristics s of the software are patients, staff and the s who maintain the system. are assumed to have basic knowledge of computers. s of the system should have more knowledge of internal modules of the system and are able to rectify small problems that may arise due to disk crashes, power failures and other catastrophes. Friendly interface, must be sufficient to educate the s on how to use this product without any problems or difficulties. ’s Requirement:A requirement specifies capabilities that a system must provide in order to solve a problem. Requirements include:•
Functional requirements
•
Performance requirements
24
A clear statement of the requirements and information needs is necessary for good system design. If the information required is not complete or the objectives are not identified properly and clearly, then the design effort will produce less than optimum results. Information needs also vary at different levels. Functional requirements: Modules in the project1.
2.
In Patient
3.
Out Patient
4.
Lab
5.
Billing
6.
View Reports
When the explains his current scenario of work, the developer may not quite get him. It is very essential for the developer to understand the way things are functioning at the ’s place, since it is on the basis of his understanding that he will develop the software and computerize the current system. In turn the also needs to understand how things are going to get computerized and how is work scenario going to change once things are computerized. To be able to fetch the purpose of the developer and the we develop a document called Software requirement Specification (SRS). SRS is a document that explains what the proposed software 25
should do. It focuses on what has to be done and not on how. It describes the complete behavior of the proposed software. The usually does not understand software or software development process so he needs that things are put down in black and white in simple manner. So, this communication gap is bridged by the software requirement specification. An SRS establishes an agreement between the and the developer on what the requires and what the software product will do: •
Aim
•
characteristics
•
General constraints
•
General assumption
•
Information description:
PERFORMANCE REQUIREMENTS The performance features which is required in the proposed system is Friendliness The proposed system should be friendly, understandable and easy to use. It should provide on line help and error messages for ease. should be able to take the output of reports on the screen. Requirements• This software should not breakdown suddenly in any disaster like power failure.
26
• The timeline of this software must be in our mind. • The performance of the functions and every module must be well. • At every step the output of the one phase is the input of the other phase and it will be reliable and accurate. • The risk factor must be taken at initial step for better performance of the software. • For individual function the performance will be well. • For to the software and name will be matched to the and name saved in the database and thus only authenticated s are allowed to the . • There will be various ways of retrieving data and it takes less time. Safety Requirements The database may get crashed at any certain time due to virus or operating system failure. Therefore, it is required to take the database backup Security Requirements We are going to develop a secured database for the school. Depending upon the category of the access rights are decided. It means if the is an then he can be able to modify the data, delete, append etc. Whereas the can only view the information but cannot update or delete the records. HARDWARE REQUIREMENTS PROCESSOR-
Intel Pentium III processor 27
RAM-
Minimum 128 MB RAM Recommended 256 MB RAM
HARD DISKNETWORK-
Minimum hard disk 40GB Internet connection through Modem or LAN Card
6.7.4 SOFTWARE REQUIREMENTS WINDOWS XP OPERATING SYSTEM •
MS Access 2007
•
MS WORD 2007
•
Microsoft Visual Basic-6.0
6.7.5 Technology Used •
Front End: - Microsoft Visual Basic-6.0
•
Back End: - Microsoft Access.
Constraints: The computer should have enough processor speed, memory, and hard disk space to run the complier we’ve chosen. We can check the manufacturer’s specification to determine these requirements
28
The above specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly. SPECIFIC REQUIREMENTS Interface Constraints Using this system is fairly simple and intuitive. A familiar with basic browser navigation skills should be able to understand all functionality provided by the system. Hardware Constraints The system should work on only school istration desktop computers. Software Constraints No specific software required Communications Constraints System must have access to the included database. Other components of the fee management system may require access to certain data which is available with school istration only.
29
30
PURPOSE The purpose of this document is to describe the implementation of software,” HOSPITAL MANAGEMENT SYSTEM” for ABC Hospital. The software is developed for computerizing the working in a hospital and is capable to provide easy and effective storage of information related to patients that come up to the hospital. SCOPE: This software can be used in any Hospital, Clinic for maintaining patient details and their test results. SYSTEM OVERVIEW This system is designed to reduce the paperwork and provide ease for maintaining , searching ,updating and deleting the information about the patients and staff . will be responsible for updating information about the patients and patients are also provided with facility to view their reports and bills. MODULE DECOMPOSITION: It describes different modules of the system, shown in entity relationship diagram: a) : This module provides with the facility to in the system and add ,delete , update or view information about the patients. Also the patients can and view their medical reports and bills.
31
b) INPATIENT: This module consist of list of inpatients and their information such as their personal details as well as it and discharge date, ward allotted to them etc. has right to update the inpatient list . c) OUTPATIENT: This module consists of the list of outpatients and their personal information. can add, delete and update the information. d) LAB: This module provides the facility for generating medical reports of the patients. e) BILLING- This module provides the facility for generating the bills of the treatment of the patient .This module is accessible by the patients also in order to see their bills and make payment. f) VIEW REPORTS- This module allows patients to view their reports(eg xray,blood test etc). 3.2 CONCURRENT PROCESS DECOMPOSITION: It describes the concurrent processes of system software. a) SIMULTANEOUS : or Patient can software simultaneously. c) SIMULTANEOUS AND UPDATE:
While
is updating
the
information about the patients , simultaneously on the other side patient can view his reports and billing status. DATA DECOMPOSITION: This section contains a description of each data element that is shared between components, its storage, and its logical structure (but not its representation in a programming language).
32
a) DATA SHARING: Data is shared between modules to keep each section of system well informed and up to date. Patients can view their reports and bills. b) DATA STORAGE: In order for system to function, it must have access to a database such as MySQL, which contains information about system as well as s. The database is constructed using relational model, which means that links can be made between various tables, attributes of tables. c) DATA ACCESS : Data can be accessed ,updated ,deleted by only while the patients can view their medical reports and bills only. These functions can be performed through menu options provided at frontend, at backend it could be performed by queries. 4. DEPENDENCY DESCRIPTION: The following section will describe the relationship between each given module of the system with the other modules of the system. MODULE DEPENDENCY: This section outlines the dependencies and interactions in the modules. 1. : can to system through ID and . 2. INPUT: The system receives input from the . This input can be taken in the form of a text field and submitting by clicking on a button . 3. DATABASE: The Server then processes this information and calls methods on to solve the queries (request by through input).
33
4. OUTPUT: After successfully performing the queries desired result is returned. For the desired output would be the changes made by him in database and for patients result would be display of their medical reports and bills. 4.2 DATA DEPENDENCY: This section describes the different database tables that make up the database for the system.
34
USE CASE It is a visually representation what happens when actor interacts with system. A use case diagram captures the functional aspects of a system. The system is shown as a rectangle with name of the system inside ,the actor are shown as stick figures, the use case are shown as solid bordered ovals labeled with name of the use case and relationships are lines or arrows between actor and use cases. Symbols used in Use case are as followsUse case
Relationship
Actors
35
In Patient
Out patient
Lab
Payment Receipt
Fig() Use Case diagram for hospital management system
36
37
Data flow diagram A data flow diagram or bubble chart (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated. DFDs can also be used for the visualization of data processing (structured design). A DFD shows what kinds of information will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel (which is shown on a flowchart). The primitive symbols used for constructing DFD’s are: Symbols used in DFD A circle represents a process.
A rectangle represents external entity
A square defines a source or destination of the system data.
An arrow identifies dataflow. 38
Double line with one end closed indicates data store Data Flow Diagrams a) Context level Diagram
LEVEL 0 DFD
VIEW REPORTS
IN PATIENT Patient
OUT PATIENT
HOSPITAL MANAGEMENT SYSTEM
VIEW REPORTS
39
PAYMENT
Patient
LEVEL 1 DFD Patient
Table
ID and wod
In patient Enter details In In Patient Patient
Out patient Enter details Out Out patient patient
Discharge details
Payment table Patient
Amount Payment Payment
Save details
Update in
Give details
Reports table
Lab Lab
Name and patient’s details
Receipt given Receipt Receipt
40
LEVEL TWO DFD
Level 2 DFD
Patient
table
ID and
1.1 Update
1.2 Change
Payment
Payment table
Update database
Amount paid Payment
Patient
41
IN PATIENT In patient table Add Patient’s details
Patient’s details
Patient’s details
Patient’s details
2.1 2.1 Create Create
2.2 2.2 View View
View
2.3 2.3 Edit Edit
Edit
2.4 2.4 Delete Delete
42
Delete
Payment
Payment table
Update database
Amount paid Payment
Patient
Out patient
Out patient table Add Patient’s details
Patient’s details
Patient’s details
Patient’s details
2.1 2.1 Create Create
2.2 2.2 View View
View
2.3 2.3 Edit Edit
Edit
2.4 2.4 Delete Delete
43
Delete
Lab Patient’s detail
Add in database
Lab Lab
Report generated Given to Reports Reports
44
Lab table
45
Entity Relationship Diagram
Hospital Management E-R Diagram Employee Age
Is A
Name Name
Name Name Patient ID ID Address Address
Receptionist Doctor
Attends Date itted Name
Nurse
Doctor_Id Doctor_Id
Assigned
ID ID
Governs
Room
Maintains Name Name Room_ID Room_ID
Room Room Type Type
Records Patient’s Patient’s info info
Record Record No No
46
Appointment Appointment
47
1.
Interface Design
Unsucessful
48
CHANGE
IN PATIENT
49
OUT PATIENT
50
PAYMENT
51
RECEIPT
LAB 52
53
54
Testing & Debugging Testing Methodology Testing is the process of executing a program with the intent of finding errors” As we know, software is one component of a large computer based system. Ultimately, Software is incorporated with other system components and thus, a series of special tests are to be conducted. Petschenik gives some guidelines for choosing test cases during system testing. The first is that testing the system’s capabilities is more important than testing its components. During system testing, we should evaluate a number of attributes of the software that are vital to the . Testing The most crucial stage of software development, testing validates the application. During testing we will be concerned about the inputs and their expected outputs. We emphasize on the testing where we will input the data and compare the output with the expected results. At this stage we are not concerned about the process; we are only looking for correct outputs. Various software testing techniques exists which take different approaches to test and validate a software. Tests done on the designed software was to the following properties of the software: Correctness (satisfaction of the specifications)
55
Reliability (how well it meets the requirements) Portability (running in different environments) Usability (ease with which can use the software) Maintainability (modifications after initial release)
Debugging Debugging is removing the undesirable errors or bugs from the program. We implemented debugging using the Visual basic compiler in which the application was developed. During testing the program to tested is executed with the set of test cases and have the output of the program for the test cases is evaluated to determine if the program is performing as expected. Due to its approach dynamic if the program is performing as expected. Due to its approach dynamic testing can only presence of errors in the program, the exact nature of errors is not usually decided by testing. Testing forms is the process to determine errors in the program. Once a program are tested individually then the system as a whole needs to be tested. During testing the system is used experimentally to ensure that the software does not fail i.e. it will run according to its specification. The programs executed to check for any syntax and logical errors. The errors are corrected and test is made to determine whether the program is doing what supposed to do.
56
Software Testing Techniques The importance of software testing and its impact on software cannot be under estimated. Software testing is a fundamental component of software quality assurance and represents are view of specification, design and coding. The greater visibility of software systems and the cost associated with software failure are motivating factors for planning, through testing. It is not uncommon for a software organization to spent 40% of its effort on testing.
White Box Testing White box testing is a test case design approach that employs the control architecture of the procedural design to produce test cases. Using white box testing approaches, the software engineering can produce test cases that Guarantee that all independent paths in a module have been exercised at least once. Execute all loops at their boundaries and in their operational bounds Exercise internal data structures to maintain their validity.
Various white box techniques Basis Path Testing: Basic path testing is a white box testing techniques that allows the test case designer to produce a logical complexity measure of procedural design and use this measure as 57
an approach for outlining a basic set of execution paths. Test cases produced to exercise each statement in the program at least one time during testing. Control Structure Testing: Although basis path testing is simple and highly effective, it is not enough in itself. Next we consider variations on control structure testing that broaden testing coverage and improve the quality of white box testing. Different control structure techniques are Condition testing Data flow testing Loop testing Black Box Testing: Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc. As the name "black box" suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Various black box techniques Functional Testing: In this type of testing, the software is tested for the functional requirements. The tests are written in order to check if the application behaves as expected. Smoke Testing: This type of testing is also called sanity testing and is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level.
58
Recovery Testing: Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc. Type or extent of recovery is specified in the requirement specifications. Alpha Testing: In this type of testing, the s are invited at the development center where they use the application and the developers note every particular input or action carried out by the . Any type of abnormal behavior of the system is noted and rectified by the developers. Beta Testing: In this type of testing, the software is distributed as a beta version to the s and s test the application at their sites. As the s explore the software, in case if any exception/defect occurs that is reported to the developers. Software Testing Strategies in used in the project A strategy for software testing integrates software test case design techniques into a well-planned set of steps that cause the production of software. A software test strategy provides a road map for the software developer, the quality assurance organization, and the customer Unit testing: Unit testing concentrates verification on the smallest element of the program the module. Using the detailed design description important control paths are tested to establish errors within the bounds of the module. Firstly the unit testing on various modules and sub modules is performed in the project. Different modules are tested with different correct and incorrect data. For example in the order processing module order of 0 product is not allowed so in this case different methods are used to find out whether the modules is performing all processes correctly. All modules are tested to find out that whether they are working properly
59
Integration testing :-Once all the individual units have been tested there is a need to test how they were put together to ensure no data is lost across interface, one module does not have an adverse impact on another and a function is not performed correctly. Integration testing is a systematic approach that produces the program structure while at the same time producing tests to identify errors associated with interfacing.In this project bottom up integration testing is used. Firstly lower level modules are tested. As modules are integrated bottom up, processing required for modules subordinates to a given level is always available and the need for stubs is eliminated. Validation testing :-As a culmination of testing, software is completely assembled as a package, interfacing errors have been identified and corrected, and a final set of software tests validation testing are started. Validation can be defined in various ways, but a basic one is valid succeeds when the software functions in a fashion that can reasonably expected by the customer. In the first phase of alpha testing, developers test the software using white box techniques. Additional inspection is then performed using black box techniques. This is usually done by addicted testing team. This is often known as the second stage of alpha testing. Unit and integrated tests concentrate on functional verification of a component and incorporation of components into a program structure. Validation testing demonstrates tractability to software requirements, and system testing validates software once it has been incorporated into a larger system. Test Cases Specification for System Testing The different conditions that need to be tested, along with the test cases used for testing those conditions and expected output are given. The goal is to test different functional requirements, as 60
specified in requirement document. Test cases have been selected for both valid and invalid inputs.
Test CasesModule1-
S.no
Test Case
Description INPUT
Expected OUTPUT
Result
1
name
name to be displayed and should not be empty “ to the system should not be empty
“Matched”
2
The name set should be entered The should be entered
Expected OUTPUT
Result
Id Type: text form Type: text “text” form
“ successful”
Module 2 (In Patient)
S.no
Test Case
Description INPUT
1
S.no
The S.no of patient to be entered and unique s.no tobe entered
2
Name
The name of the patient to be itted
3
Address
4
The Address of patient to be entered The number of patient
Type: number The s.no should be unique for every Patient and should not be in text Name to be Type: text displayed and form should not be empty Address Address to be Type: taken by the Alphanumeric system Type=number no. to Should input be taken only numeric values
61
The record to be saved in database
Record to be saved within the database Record to be saved within the database Record to be saved within the database
5
Age
The age to be Type = entered number Text values will not be accepted
Age to be displayed and should not be empty
Record to be saved within the database
Expected OUTPUT
Result
Module 3 :Out Patient
S.no
Test Case
Description INPUT
1
S.no
The S.no of patient to be entered and unique s.no tobe entered
2
Name
3
Address
4
5
Age
6
Date itted
7
Date discharged
8
Bill Status
Type: number The s.no should be unique for every Patient and should not be in text The name of Name to be the patient to Type: text displayed and be itted form should not be empty The Address Address Address to be of patient to Type: taken by the be entered Alphanumeric system The Type=number no. to number of Should input be taken patient only numeric values The age to be Type = Age to be entered number displayed and Text values should not be will not be empty accepted The date of Type= date Date of ission of text value ission to the patient should not be be displayed entered The date of Type =date Date of discharge of discharge to the patient be displayed The bill should be Bill status to status to be checked be shown paid whether paid or not paid 62
The record to be saved in database
Record to be saved within the database Record to be saved within the database Record to be saved within the database Record to be saved within the database
Record to be saved within the database Record to be saved within database Record to be saved within database
Module 4 (Lab)
S.no 1
Test Case
Description
INPUT
Name
The name of the patient to be itted
Type: text form
2
Address
3
Test Name
4
Description
S.no
The Address of patient to be entered The test to be conducted in the lab The description of the report made of the test conducted
Test Case
Description
1
Name
The name of the patient
2
Address
3
Amount Paid
4
Amount Due
The Address of patient to be entered The amount paid by the patient The amount the patient has to pay
Expected OUTPUT
Result
Name to be displayed and should not be empty Address Address to be Type: taken by the Alphanumeric system Type: Text The test of name to be displayed Type :Text The results of the report to be displaye
Record to be saved within the database
INPUT
Result
Expected OUTPUT Name to be Type: text displayed and form should not be empty Address Address to be Type: taken by the Alphanumeric system Type: The amount Number paid to be displayed Type: The amount Number patient has to pay
63
Record to be saved within the database Record to be saved within the database Record Saved
Record to be saved within the database Record to be saved within the database Record to be saved within the database Record to be saved within the database
64
Software needs to be maintained not because some of its components wear out and need to be replaces but because there are often some residual errors remaining in the system that must be removed as they are discovered. Many of the errors surfaces only after the system have been in operation, sometimes for a long time. To discovered & removed such type of errors called
Corrective maintenance. Up gradation, enhancement, modification, include some more features & added some more services are the such type of changes which a software must adapt to the needs of the changed environment. The changed software then changes the environment, which in turn requires further changes, called Adaptive Maintenance. As software is used, the will recognize additional functions that will provide benefit,It comes under Perfective maintenance. This maintenance extends the software beyond its original functional requirements. For maintenance point of view, we have taken all three approaches: 1. Corrective Maintenance 2. Adaptive Maintenance 3. Perfective Maintenance
65
Corrective Maintenance: In Transportation System Automation Process, we have checked the system with original data of the . We will collect the errors which surfaces after system has started working & will remove them immediately by repairing processing. Because there are often some residual errors remaining in the system so in future prospects we shall also discoverthe errors on regular basis, which can be remaining in the system and all will be removed by us day to day. Adaptive Maintenance: we have adopted such type of approach that after up gradation or modification or any further enhancement, the software should be environment compatible but if it requires further changes according to the needs we will maintain it as needed. Perfective Maintenance: We have taken a lot of care at the time of analysis but after the starts using the software, if suggested we will add additional functions to enhance the functionality of the software. If the is looking for any additional enhancement in this system like, Addition of any new module or any modification in any module or any up gradation in any of the existing module can be added, modify and up graded easily with out any difficulty or major changes. After the completion of any further changes like modification, up gradation or any enhancement we have also a step of regression testing. In this step we will execute the old test cases to check that if there is any error occurs after changes has taken place. System Evaluation Evaluation of the system is performed to identify its strengths and weakness. 66
Operational Evaluation: In this, assessment of the system functions, ease of use, response time, and suitability of information’s formats, overall reliability, and level of utilization is undertaken.
All the above aspects were very well taken into consideration from the very beginning. Reliability of this project is high. Recovery methods are well written, even if something exceptional occurs has a way to come out of the undesirable situation and carry on with the work. Records are saved only if they are valid.
67
Objectives of the Project The main objective of hospital management system is to perform all the functions or operations accurately and correctly. The proposed system has the following objectives to be achieved. 1. Friendly Environment. 2. Less Space. 3. Fast Retrieval. 4. Easy to Operate. 5. Accuracy. 6. Receipt generation
Scope of The Project 1. Including module to enable the software’s to record payment done by patient 2. Including a module that adds the record of a new patient 3. Including a module to view the patient’s record Future Scope and Limitations Hospital management system is in itself a complete system, though it has a few limitations but it has a lot of future scope and features that could be added to make it more widely acceptable. One limitation is that our software is limited to small and medium scaled hospitals. One of the major future scope is making our system online. Connecting the system of a particular hospital to a common data centre will provide globalization to the school, and then the will be able to share the data across the branches. Summary
68
The project entitled “Hospital Management” is about Managing fee records. There are many functions like registration, , change , payment, inpatient,out patient etc. The end can the Patient by filling the necessary details and can make the payment on student’s behalf. During process there is one more function available that is change . This function allows the to change the . Successful will lead to registration form where can the patient and record all the data of the patient.
Conclusion
This software is a database project with all the basic capabilities a database should have. This application software is about student fee system and it records and maintains records about the student fee. In doing so, an appreciation of project management, communication and consultancy skills should be acquired, along with a thorough understanding of the development of windows based applications using Visual basic. I feel that all of these aims were achieved, some to greater extent than others.
69
70
The references for the project “HOSPITAL MANAGEMENT SYSTEM” have been taken from the following books and website.
WEB REFERENCES
http://en.wikipedia.org/
BOOKS REFERENCES Software engineering by KK AGGRAWAL Software engineering by Pankaj Jalote
71
Related Documents 3m3m1z
Hospital Management System (srs) 4p585w
November 2019 244
Hospital Management System Srs 6s4y3m
October 2021 0
Hospital Management System Srs 6s4y3m
October 2019 370
Srs Of Hospital Management System 1t54g
November 2019 171
Srs For Hospital Management System 5c5cp
December 2021 0
Srs For Hospital Management System 5c5cp
August 2021 0More Documents from "Yash Kapoor" l2q2y
Hospital Management System Srs 6s4y3m
October 2019 370
Project Report On Vimal Oils And Foods Ltd. 3i1m1e
December 2019 90
Crpc-search-and-seizure.docx 1e3m3r
December 2021 0
Gall Bladder Menu 394e1w
July 2022 0
Welcome To Mplun System (1) 3u92u
December 2019 67