CSCE 431 Final Project

1. CSCE 431 Final Project Aaron Loveall, Cory Walker, Kern Loest, Michael Nootbaar, Anthony Fleshner, and Aaron Herstein

2. Requirements • Purpose • Construct a unified web-based hospital management system • To allow patients, doctors, nurses, and pharmacists (the users of the system) to easily access information

3. Requirements • Product Scope • Covers all aspects of the interactions in the hospital between the patients and various employees • Uses a central database to integrate and store all information • Only excludes actual physical operation of the hospital (e.g. maintenance)

4. Requirements • System Perspective • Web-based system based on a PHP website interacting with a SQLite database • User interacts directly with the browser system (driven by HTML and PHP) and the PHP code interacts with the SQLite database

5. Requirements • System functions include: • Registration • Login • Appointment scheduling • Prescription management • Payroll • Account management

6. Requirements • Functional requirements include • Registration • Login • Profile Update • Appointment Scheduling • Medical Record editing • Prescribe Medicine • Fill Prescription • Check In/Check Out • Retrieve Profile Info • Payroll

7. Requirements • Security Requirements • Implements a user registration system. Only registered users can view any sensitive information • Doctors, nurses, and pharmacists can only be registered by a system administrator • Information about patients, doctors, nurses, and pharmacists can only be accessed and viewed by the appropriate user

8. Requirements In all, this system provides a comprehensive management system. As such, users can interact without having to be physically at the hospital. Because it is web-based, this system can be accessed from anywhere.

9. Testing Procedures • Tested during each iteration • Examples: • Iteration 1: Login and registration • Iteration 2: Making appointments • Iteration 3: Prescriptions and check in/out • Iteration 4: Billing and payment • Iteration 5: Complete system

10. Testing Procedures (cont.) • White Box Testing • Used for our testing during each iteration • Involved choosing inputs to exercise paths through the code while determining the appropriate outputs • Helped testing paths between different units of our software

11. Testing Procedures (cont.) • Black Box Testing • Used after our final iteration • Focused on testing the software design based on the specifications and requirements • Used a form of “state transition” testing to test a user could move between different features • Tested that users were only allowed to perform the tasks stated in the requirements for their role

12. GRASP Patterns • Creator: Responsible for the creation of objects • Example: add.php • Information Expert: Delegates responsibilities • Example: users.php • Controller: deals with system events • Example: register.php

13. GRASP Patterns (cont.) • Polymorphism: functions with multiple forms • Example: account.php • Indirection: reuse between two elements • Example: patientCheck.php with checkIn.php and checkOut.php

14. Group Management • Getting started • SCRUM meetings • On task • Clarity