Hospital Management System Software Engineering Project ..., Study Guides, Projects, Research of Software Engineering

Download Hospital Management System Software Engineering Project ... and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity! 1 | P a g e Hospital Management System Software Engineering Project Report MATA SUNDRI COLLEGE FOR WOMEN B.Sc. (H) Computer Science Submitted By:- Esha Bisht Akansha Rathi Monika Chaudhary 17044570011 17044570012 17044570016 Department Of Computer Science Delhi University 2 | P a g e ACKNOWLEDGEMENT Apart from the efforts of team, the success of any project depends largely on the encouragement and guidelines of many others. We take this opportunity to express our gratitude to the people who have been instrumental in the successful completion of this project. The completion of any inter-disciplinary project depends upon cooperation, co-ordination and combined efforts of several sources of knowledge. We are eternally grateful to our teacher ASHEMA HASTI for her even willingness to give us valuable advice and direction under which we executed this project. Her constant guidance and willingness to share her vast knowledge made us understand this project and its manifestations in great depths and helped us to complete the assigned tasks. Esha Bisht (17044570011) Akansha Rathi (17044570012) Monika Chaudhary (17044570016) 5 | P a g e Table of Contents SNO TOPIC Page No 1. PROBLEM STATEMENT 9 2. PROCESS MODEL 11 3. SOFTWARE REQUIREMENTS SPECIFICATION 15 4. CONTEXT LEVEL DIAGRAM 18 5. DFD LEVEL 1 19 6. DFD LEVEL 2 20 7. USE CASE DIAGRAM 24 8. USE CASE DESCRIPTION 25 9. DATA DICTIONARY 35 10. ER DIAGRAM 36 11. DATA DESIGN 37 12. COMPONENT LEVEL DIAGRAM 40 13. PROJECT SCHEDULING 44 14. TIMELINE CHART 45 15. FUNCTION POINT METRICS 46 16. COCOMO MODEL 52 17. SAMPLE SCREENSHOTS 56 18. RISK ANALYSIS 68 19. TESTING 69 20. CONCLUSION 74 6 | P a g e LIST OF FIGURES USED IN THE PROJECT FIGURE_NO NAME PAGE No 2.1 CONTEXT LEVEL DFD 18 2.2 LEVEL – 1 DFD 19 2.3 LEVEL – 2 REGISTRATION 20 2.4 LEVEL – 2 LOGIN 20 2.5 LEVEL – 2 MAKE APPOINTMENT 21 2.6 LEVEL – 2 ADD DESCRIPTION 21 2.7 LEVEL – 2 DOCTOR MODULE 22 2.8 LEVEL – 2 PAYMENT 22 2.9 LEVEL – 2 CANCEL APPOINTMENT 23 2.10 LEVEL – 2 PAITENT MODULE 23 6.1 HOME PAGE 57 6.2 SELECT LOGIN 57 6.3 PATIENT LOGIN PAGE 58 6.4 REGISTRATION 58 6.5 PATIENT PROFILE 59 6.6 PATIENT UPDATE DETAILS 59 6.7 PATIENT BOOK APPOINTMENT 60 6.8 PATIENT APPOINTMENT STATUS 60 6.9 PATIENT CANCEL APPOINTMENT 61 6.10 PAYMENT 61 6.11 PATIENT PAYMENT RECIPET 62 7 | P a g e 6.12 PATIENT VIEW PAYMENT HISTORY 62 6.13 PATIENT VIEW DOCTORS 63 6.14 DOCTOR LOGIN PAGE 63 6.15 DOCTOR PROFILE 64 6.16 DOCTOR VIEW APPOINTMENT 64 6.17 DOCTOR ADD DESCRIPTION 65 6.18 ADMIN LOGIN PAGE 65 6.19 ADMIN ADD DOCTOR 66 6.20 ADMIN UPDATE DOCTOR DETAILS 66 6.21 ADMIN PAYMENT REQUEST 67 6.22 ADMIN VIEW RECORDS 67 10 | P a g e • Overall cost reduction o Cuts down paper costs as all the data are computerized o No separate costs for setting up physical servers • Data accuracy o Removes human errors o Alerts when there’s a shortage of stock • Data security o Helps to keep patients records private o Restricts access through role-based access control • Revenue management o Makes daily auditing simple o Helps with statistics and other financial aspects 11 | P a g e PROCESS MODEL Hospital Management System follows INCREMENTAL MODEL because initially software requirements are reasonably well defined but the overall scope of development effort is a purely linear process. There may be other requirements of the user which will be known later. So, those requirements can the implemented and delivered in the following next increments. Our project is a short term project of 3 months and 3 weeks only and staffing available is also low (3 persons). 12 | P a g e CHAPTER 1 INTRODUCTION 1.1 PURPOSE 1.2 SCOPE 1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS 1.4 REFERENCES 1.5 OVERVIEW 15 | P a g e CHAPTER 2 SOFTWARE REQUIREMENT SPECIFICATION 2.1 Product Perspective 2.1.1 System Interfaces 2.1.2 System Specifications 2.1.2.1 H/W Requirement 2.1.2.2 S/W Requirement 2.1.3 Communication Interfaces 2.2 Product functions 2.3 Data Flow Diagram (DFD) 2.3.1 Context Level Diagram 2.3.2 DFD Level – 1 2.3.3 DFD Level – 2 2.4 Use Case Diagram 2.5 Use Case Description 2.6 User characteristics 2.7 Constraints 2.8 Assumptions and dependencies 16 | P a g e 2.1 Product Perspective This Hospital Patient Info Management System is a self-contained system that manages activities of the hospital. Due to improperly managed details medical center faces quite a lot of difficulties in accessing past data as well as managing present data. The fully functional automated hospital management system which will be developed through this project will eliminate the disadvantages caused by the manual system by improving the reliability, efficiency and performance. The usage of a database to store patient, employee, stock details etc. will accommodate easy access, retrieval, and search and manipulation of data. The access limitations provided through access privilege levels will enhance the security of the system. The system will facilitate concurrent access and convenient management of activities of the medical center. 2.1.1 System Interfaces ❖ User Interfaces ▪ This section provides a detailed description of all inputs into and outputs from the system. It also gives a description of the hardware, software and communication interfaces and provides basic prototypes of the user interface. ▪ The protocol used shall be HTTP. ▪ The Port number used will be 80. ▪ There shall be logical address of the system in IPv4 format. ❖ Hardware Interfaces ▪ Laptop/Desktop PC-Purpose of this is to give information when Patients ask information about doctors, medicine available lab tests etc. To perform such Action it need very efficient computer otherwise due to that reason patients have to wait for a long time to get what they ask for. ▪ Laser Printer (B/W) - This device is for printing patients’ info etc. ▪ Wi-Fi router - Wi-Fi router is used to for internetwork operations inside of a hospital and simply data transmission from pc’s to sever. ❖ Software Interfaces ▪ JDK 1.8 - Java is fast, secure, and reliable. From laptops to data centers, game consoles to scientific supercomputers, cell phones to the Internet, ▪ Mysql server - Database connectivity and management ▪ OS Windows 7/8/8.1- Very user friendly and common OS ▪ JRE 1.8 - JAVA Runtime Environment for run Java Application and System 17 | P a g e 2.1.2 System Specifications 2.1.2.1 H/W Requirement  Core i5 processor  2GB Ram.  20GB of hard disk space in terminal machines  1TB hard disk space in Server Machine 2.1.2.2 S/W Requirement  Windows 7 or above operating system  JRE 1.8  Mysql server 2.1.3 Communication Interfaces  NIC (Network Interface Card) – It is a computer hardware component that allows a computer to connect to a network. NICs may be used for both wired and wireless connections.  CAT 5 network cable- for high signal integrity  TCP/IP protocol- Internet service provider to access and share information over the Internet  Ethernet Communications Interface- Ethernet is a frame-based computer network technology for local area networks (LANs)  Ubiquitous, easy to set up and easy to use. Low cost and high data transmission rate. 2.2 Product functions o Provide access to registered users only. o Registration of new patients. o Enable patient to view their record. o Enable patient to update their record. o Generate appointment date and timing. o Confirmation by doctor. o Patients can do Payment. o Modification in schedule by patient. o Admin access to patient’s record. o Admin Verify Payment and Generate Bill/Receipt. o Admin can view monthly/yearly records. 20 | P a g e FIGURE 2.3 LEVEL – 2 Registration FIGURE 2.4 LEVEL – 2 Login 21 | P a g e FIGURE 2.5 LEVEL – 2 Make Appointment FIGURE 2.6 LEVEL – 2 Add Description 22 | P a g e FIGURE 2.7 LEVEL – 2 Doctor Module FIGURE 2.8 LEVEL – 2 Payment 25 | P a g e 2.5 USE CASE DESCRIPTION (1) PATIENT * REGISTRATION DESCRIPTION - The new patient can register themselves and add their details like name, age , gender, blood group etc. The patient entry will be made in the hms database. PRE -CONDITION – The patient must be a new patient, If necessary fields left by user then prompt user to fill the necessary fields. MAIN FLOW OF EVENTS 1. Patient selects sign up in login module. 2. A registration form get displayed 3. Patient fills the required details. POST CONDITIONS - Patient record is added to hms database. * UPDATION DESCRIPTION-The patient should be enabled to update his/her details and the changes should reflect in hms database. PRE-CONDITION – The patient must be a registered patient, The patient cannot update details after treatment starts. MAIN FLOW OF EVENTS 1. Patient logs in to the system. 2. Patient view his record 3. Patient selects update details. 4. Now patient may change the necessary fields. 5. Pop of update details. POST CONDITION - The record of patient is updated in hms database. 26 | P a g e *APPOINTMENT DESCRIPTION - It shows users a list of available doctors, timings, dates and enables patients to select the most suitable appointment date and doctor. The patient may also the cancel the appointment. PRE-CONDITION - The patient must be a registered patient, Patient can fix only one appointment for a particular department. MAIN FLOW OF EVENT 1. Patient first logs in to system. 2. View his/her record. 3. Create a new appointment or cancel the appointment.. POST CONDITIONS - patient details are displayed and a new appointment is fix or a existing appointment is cancelled. The hms database is updated. *PAYMENT DESCRIPTION – It enables user to pay the consultant fee of Doctor online. PRE-CONDITION - The patient must be a registered patient, If Patient don’t wants to pay online he/she can pay by cash also. MAIN FLOW OF EVENT 1. Patient first logs in to system. 2. View his/her record. 3. Appointment confirmed by the Doctor then go for Payment. POST CONDITIONS – A Reciept will be displayed. The hms database is updated 27 | P a g e (2) DOCTOR DESCRIPTION- The doctor view patient record/ update his details and add description of the treatment given to patient. PRE-CONDITION – The doctor must be a registered doctor, System does not allow the doctor to modify the qualification, hospital managed details. MAIN FLOW OF EVENTS 1.Doctor logs in to the system. 2. Doctor may select view patient. 2.1 Patient record is displayed with treatment history. 3. Doctor add description of patient treatment. 4. Doctor may select appointment details 4.1 Appointment Requests is displayed with schedule. 5. Doctor confirm or cancel appointment. POST CONDITION – The patient and doctor ‘s database are updated. (3) ADMIN DESCRIPTION - The admin add doctor, update docotr details and verify payment and generate Bill/Reciept for the same. MAIN FLOW OF EVENTS 1. Admin logs in the system. 2. Admin may add doctor new doctor. 2.1 admin fills the doctor’s details. 3. Admin view Doctor record. 3.1 Admin enters the doctor id in the system. 3.2 Doctor details are displayed, Admin can update details. 4. Admin Verify the payment submited by the Patient. 4.1 Generate Bill/Reciept and confirmation message for the same. PRE –CONDITION - Admin must first log in with his/her credentials. POST CONDITION - The hms database is updated. 30 | P a g e CHAPTER 3 SPECIFIC REQUIREMENTS 3.1 Performance requirements 3.2 Safety requirements 3.3 Security constraints 3.4 Software system attributes 3.4.1 Usability 3.4.2 Availability 3.4.3 Correctness 3.4.4 Maintainability 3.4.5 Accessibility 3.5 Functional Requirements 31 | P a g e 3.1 PERFORMANCE REQUIREMENTS o Response time- The system will give responses within 1 second after checking the patient information and other information. o Capacity-The system must support 1000 people at a time o User interface- User interface screen will response within 5 seconds 3.2 SAFETY REQUIREMENTS If there is extensive damage to a wide portion of the database due to catastrophic failure, such as a disk crash, the recovery method restores a past copy of the database that was backed up to archival storage and reconstructs a more current state by reapplying or redoing the operations of committed transactions from the backed up log, up to the time of failure. All the administrative and data entry operators have unique logins so system can understand who is login in to system right now no intruders allowed except system administrative nobody cannot change record and valuable data. 3.3 SECURITY REQUIREMENTS 1. Want take the responsibility of failures due to hardware malfunctioning. 2. Warranty period of maintaining the software would be one year. 3. Additional payments will be analyzed and charged for further maintenance. 4. If any error occur due to a user’s improper use. Warranty will not be allocated to it. 5. No money back returns for the software. 3.4 SOFTWARE SYSTEM ATTRIBUTES 3.4.1 Usability: Software can be used again and again without distortion. 3.4.2 Availability: The system shall be available all the time. 3.4.3 Correctness: Bug free software which fulfills the correct need/requirements of the client. 3.4.4 Maintainability: The ability to maintain, modify information and update fix problems of the system. 3.4.5 Accessibility: Administrator and many other users can access the system but the access level is controlled for each user according to their work scope. 32 | P a g e 3.5 FUNCTIONAL REQUIREMENTS S.No. MODULE NAME APPLICABLE ROLES DESCRIPTION 1. LOGIN PATIENT DOCTOR ADMIN PATIENT: Can login using unique Id and Password after this system shall show his/her profile. DOCTOR: Can login using unique Id and Password after this system shall show his/her profile. ADMIN: Can login using unique Id and Password after this system shall show a profile with links to maintain the website. 2. REGISTRATION PATIENT PATIENT: Can Register by filling all the required details, after this the system will verify the details and check if already registered or not. 3. MAKE APPT. PATIENT PATIENT: Can Select doctor, date time and make an appointment request after this system shall show a confirmation for appointment request. 4. CANCL APPT. PATIENT DOCTOR PATIENT : Can Cancel appointment if want to by just one click after this system shall ask for re-schedule or refund of payment. DOCTOR : Can Cancel appointment if want to by just one click after this system shall send a message to the patient. 5. PAYMENT PATIENT PATIENT : Enter payment details and make payment after this system shall show the generated bill by the hospital. 6. DOCTOR MODULE ADMIN ADMIN : Can add a new doctor by filling all the details after this system shall show a confirmation message. Can Remove a doctor by just one click after this system shall show confirmation message. 35 | P a g e 4.1 DATA DICTIONARY 1. legal_character [a-z| A-Z] 2. Dig it [0-9] 3. special_ch [@|$|#|+|-] 4. Blood [A|B|AB|O] Table 4.1 Data Dictionary 1. Name first_name + (middle_name) + last_name 2. first_name {legal_character}* 3. middle_name {legal_character}* 4. last_name {legal_character}* 5. P_ID {legal_character + digit}* 6. D_ID {legal_character + digit}* 7. A_ID {legal_character + digit}* 8. Password {legal_character + digit + special_ch}* 9. Address House_no + (Street) + City 10. House_no {legal_character + digit}* 11. Street {legal_character}* 12. City {legal_character}* 13. Mobile No. { digit }* 14. Blood_Group {Blood + special_ch}* 15. Specialization {legal_character}* 16. Consultant Fee { digit }* 17. Medicine {legal_character + digit}* 18. Advice {legal_character + digit}* 19. Remark {legal_character + digit}* 36 | P a g e 4.2 ER DIAGRAM 37 | P a g e 4.3 DATA DESIGN S NO. COLUMN NAME DATA TYPE CONSTRAINTS DESCRIPTION 1. P_ID Varchar(50) Primary Key Contains Unique Id 2. Name Varchar(50) - Contains Name 3. DOB Varchar(50) - Contains Date Of Birth 4. Gender Varchar(50) - Contains Gender 5. Blood Group Varchar(50) - Contains Blood Group 6. Email ID Varchar(50) - Contains Email Id 7. Address Varchar(50) - Contains Address 8. Mobile No. Integer - Contains Mobile No. 9. CGHS/Private Varchar(50) - Contains Category Table 4.2 Patient S NO. COLUMN NAME DATA TYPE CONSTRAINTS DESCRIPTION 1. P_ID Varchar(50) Primary Key Contains Unique Id Patient 2. Specialization Varchar(50) - Contains Name of the Department in which Patient wants to visit 3. Doctor’s Name Varchar(50) - Contains Doctor Name Patient Wants To Visit 4. Consultant Fee Integer - Contains Consultant Fee Of Doctor 5. Date Date - Contains Date For The Appointment 6. Time Time - Contains Time For The Appointment Table 4.3 Appointment 40 | P a g e 4.4 COMPONENT LEVEL DIAGRAM Book Appointment Module enum Status { confirm , cancel} ; int Department, Date , Time, mode, ch; char Dr_Name(50); cout<< Enter The Information : cin>> Department; cin>>Dr_Name; cin>> Date; cin>> Time; bool Appointment = cancel; cout<<Mode; cout<<1.Cash; cout<<2.Debit Card/Credit Card cout<<3.Net Banking cout<<Enter mode of payment; cin>>mode; if(mode==1) { Generate a Receipt and send confirmation message; } else if(mode == 2) { Enter Card Details Make Payment Send confirmation message } else { Enter Account Details 41 | P a g e Make Payment Send confirmation message } //end if Send appointment Request to the doctor Doctor will check the Appointment Requests; cout<<Mode; cout<<1.Confirm; cout<<2.Cancel; cout<<Enter Your choice; cin>>ch; if(ch==1) { Appointment = Confirm; Send a Confirm Message to the patient. } else { Send a Cancel Message to the patient. }//end if Js Appointment Confirmed By the Doctor? 42|Page 45 | P a g e 5.2 Timeline chart Month ~> January February March April Week ~> 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 PROBLEM STATEMENT SOFTWARE MODEL PROJECT SCHEDULING SRS CONTEXT LEVEL DIAGRAM DFD LEVEL - 1 DFD LEVEL - 2 DATA DICTIONARY ER DIAGRAM DATA DESIGN USE CASE DIAGRAM USE CASE DISCRIPTION FUNCTION POINT MATRIX COCOMO MODEL RISK ANALYSIS TESTING Table 5.2 Timeline Chart 46 | P a g e 5.3 Size Estimation (FUNCTION BASED METRICS) Information domain values are defined in the following manner: • Number of external inputs (EIs) - Each external input originates from a user or is transmitted from another application and provides distinct application-oriented data or control information. Inputs are often used to update internal logical files (ILFs). Inputs should be distinguished from inquiries, which are counted separately. • Number of external outputs (EOs) - Each external output is derived data within the application that provides information to the user. In this context external output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately. • Number of external inquiries (EQs) - An external inquiry is defined as an online input that results in the generation of some immediate software response in the form of an online output (often retrieved from an ILF). • Number of internal logical files (ILFs) - Each internal logical file is a logical grouping of data that resides within the application’s boundary and is maintained via external inputs. • Number of external interface files (EIFs). - Each external interface file is a logical grouping of data that resides external to the application but provides information that may be of use to the application. 47 | P a g e SIZE ESTIMATION FOR THIS PROJECT Screen No EIs EOs EQs ILFs EIFs 1. 1.Select Language - 1.Doctor’s On Leave 2.Visitors on Website Hospital File - 2. - - - - - 3. 1.Username 2. Password - - Hospital File - 4. 1 .Name 2 .Dob 3. Gender 4 .Email 5. Blood Group 6 .Mobile No 7 .Address 8 .CGHS / Private 9.Card Picture - - Hospital File - 5. - 1.Profile - HF - 6. 1. Department 2 .Date 3 .Time 4 .Doctor Name - - Hospital File - 7. 1.Appointment Status Hospital File - 8. 1 .Card Holder Name 2. Card number 3. Expire Date 4. CVC Number - - Hospital File - 9. 1.Registered Mobile No. 2.Edit Appt. Schedule - - Hospital File - 10. - - 1.Payment History Hospital File - 11. - 1.Profile - HF - 50 | P a g e CALCULATING ( ∑ 𝒇𝒊 ) Total Degree of Influence of the 14 General System Characteristics 1. How many communication facilities are there to aid in the transfer or exchange of information with the application or system? 2. How are distributed data and processing functions handled? 3. Did the user require response time or throughput? 4. How heavily used is the current hardware platform where the application will be executed? 5. How frequently are transactions executed daily, weekly, monthly, etc.? 6. What percentage of the information is entered online? 7. Was the application designed for end-user efficiency? 8. How many ILFs are updated by online transaction? 9. Does the application have extensive logical or mathematical processing? 10. Was the application developed to meet one or many user’s needs? 11. How difficult is conversion and installation? 12. How effective and/or automated are start-up, back-up, and recovery procedures? 13. Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? 14. Was the application specifically designed, developed, and supported to facilitate change? Considering all adjustment factors of average influence ∑ 𝒇𝒊 = 14 * 3 = 42 51 | P a g e TOTAL EXTERNAL INUPUTS = 41 TOTAL EXTERNAL OUTPUTS = 7 TOTAL LOGICAL INTERNAL FILES = 1 TOTAL EXTERNAL INQUIRIES = 6 TOTAL EXTERNAL INTERFACE FILES = 0 Assuming all the parameters are of SIMPLE COMPLEXITY. UFP (Count Total) = {41 * 3} + {7 * 4} + {1 * 3} + {6 * 7} + {0 * 5} = 196 Considering all adjustment factors of average influence ∑ 𝒇𝒊 = 14 * 3 = 42 Function point = FP = Count Total + (0.65 + (0.01 *∑ 𝒇𝒊) = 196 * (0.65 + (0.01 * 42) = 196 * (0.65 + (0.42) = 196 * (1.07) = 209.72 FUNCTION POINT = 209.72 52 | P a g e 5.4 Cost Estimation (COCOMO II MODEL) The original COCOMO model became one of the most widely used and discussed software cost estimation models in the industry. It has evolved into a more comprehensive estimation model, called COCOMO II. COCOMO II models require sizing information. Three different sizing options are available as part of the model hierarchy:- o Object Points o Function Points o Lines Of Source Code The COCOMO II application composition model uses object points. Like function point, the object point is an indirect software measure that is computed using counts of the number of (1) screens (at the user interface), (2) reports, (3) components likely to be required to build the application. Each object instance (e.g., a screen or report) is classified into one of three complexity levels (i.e. ,simple ,medium, or difficult). Once complexity is determined, the number of screens, reports, and components are weighted according to the table illustrated in Table 5.4 . TABLE 5.4 COCOMO II Complexity Weights OBJECT TYPE COMPLEXITIY WEIGHT SIMPLE MEDIUM DIFFICULT SCREEN 1 2 3 REPORT 2 5 8 3GL COMPONENT 10 55 | P a g e TOTAL SCREENS = 22 TOTAL 3GL MODULES = 0 TOTAL REPORTS = 8 CONSIDERING ALL OF THE ABOVE HAVE MEIDEM COMPEXITY, 0% OF COMPONENTS ARE REUSED AND TAKING THE DEVELOPER EXPERIENCE AND ENVIRONMENT MATURITY AS LOW. PRODUCTIVITY RATE = 7+7 2 = 7. OBJECT POINT = {22 * 2} + {8 * 5} = 84. ESTIMATED EFFORT = NOP PROD = 84 7 = 12 Person-Months. 56 | P a g e CHAPTER 6 SAMPLE SCREENSHOTS 57 | P a g e FIGURE 6.1 HOME PAGE FIGURE 6.2 SELECT LOGIN 60 | P a g e FIGURE 6.7 PATIENT BOOK APPOINTMENT FIGURE 6.8 PATIENT APPOINTMENT STATUS 61 | P a g e FIGURE 6.9 PATIENT CANCEL APPOINTMENT FIGURE 6.10 PAYMENT 62 | P a g e FIGURE 6.11 PATIENT PAYMENT RECIPET FIGURE 6.12 PATIENT VIEW PAYMENT HISTORY 65 | P a g e FIGURE 6.17 DOCTOR ADD DESCRIPTION FIGURE 6.18 ADMIN LOGIN PAGE 66 | P a g e FIGURE 6.19 ADMIN ADD DOCTOR FIGURE 6.20 ADMIN UPDATE DOCTOR DETAILS 67 | P a g e FIGURE 6.21 ADMIN PAYMENT REQUEST FIGURE 6.22 ADMIN VIEW RECORDS 70 | P a g e BASIS PATH TESTING FOR BOOK APPOINTMENT MODULE enum Status { confirm , cancel} ; int Department, Date , Time, mode, ch; char Dr_Name(50); cout<< Enter The Information : cin>> Department; cin>>Dr_Name; cin>> Date; cin>> Time; bool Appointment = cancel; 1 cout<<Mode; cout<<1.Cash; cout<<2.Debit Card/Credit Card cout<<3.Net Banking cout<<Enter mode of payment; cin>>mode; if(mode==1) 2 { Generate a Receipt and send confirmation message; 3 } else if(mode == 2) 4 { Enter Card Details Make Payment 5 Send confirmation message } else { Enter Account Details 6 Make Payment Send confirmation message 71 | P a g e } //end if 7 Send appointment Request to the doctor 8 Doctor will check the Appointment Requests; cout<<Mode; cout<<1.Confirm; cout<<2.Cancel; 9 cout<<Enter Your choice; cin>>ch; if(ch==1) 10 { Appointment = Confirm; Send a Confirm Message to the patient. 11 } else { Send a Cancel Message to the patient. 12 }//end if 13 72 | P a g e FLOW GRAPH NOTATION