Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Hospital Management System
Transcript of Hospital Management System
This project will consist of creating a software that would bring the hospital management system currently in existence online and automate most of the activities performed in a hospital.
The project is projected to be deliverable by December, 2016
Solutions offered by the Proposed System
Data Flow Diagram
It maintains the details of patient like the
Date of admission, Room no.
Doctor in charge
The lab tests of the patient, so that both patient and doctor could easily access reports without wastage of time
It also includes diet chart, medicines of patient as prescribed by the doctor.
All the transactions are maintained through the system, the customers can pay through their debits also
Problems In The Current System
The existing system is highly manual involving a lot of paper work and calculation and therefore may be erroneous. This has led to inconsistency and inaccuracy in the maintenance of data.
The data, which is stored on the paper only, may be lost, stolen or destroyed due to natural calamity like fire and water.
The existing system is sluggish and consumes a lot of time causing inconvenience to customers and the Hospital staff.
Due to manual nature, it is difficult to update, delete, add or view the data.
Report generation and billing is tedious and time consuming work, involving going back through all the past records of a particular patient or a doctor. It is even more time consuming in the scenario where past ailments and their treatments are needed.
The proposed system will computerize the hospital management system currently in use and will reduce lots of paperwork and hence, the load on hospital staff. It will also reduce costs as staff.
All the calculations will be performed by the machine, reducing errors.
The data will be stored on cloud, hence eliminating the possibility of data loss or theft. The access to the system needs a user ID and password so unauthorized access will be prevented.
Updating patient records will be easily done. The patient history can be easily recorded and accessed, saving searches through old filing cabinets.
With this hospital management system, we aim to make it easy for the hospital management to keep and access patient records. We also add a new feature which enables the patient to view his record as he pleases.
The software will benefit the hospital in reducing the workforce and tasks for data validation.
The software will aid in the preparation of fast and prompt reports, regarding any patient, doctor or any other member of the staff.
Entity Relationship Diagram
Log In Table
We have inculcated prototyping model in our project,
It is a type of evolutionary process model which produce an increasingly more complete version of the software with each iteration.Prototyping is used when we don’t have knowledge about the resources or the actual implementation and we do it step by step getting more detailed information about the software which is the iterative approach.
USE CASE DIAGRAM
Calculating Functional Points
COMPONENT LEVEL DESIGN
1. No Multilingual GUI
(Only English Supported)
2. Log In and password is used for identification of user and there is no facility for guest.
detailed design: - This process is performed by the development team, who will be generating the application software and integrating the hardware, databases, and communications with these applications.
perform technical reviews: For design status: evaluation of the candidate solutions or COTS products, technical reviews should be held on a periodic basis to review the progress of the design or selection of COTS products.
preform critical design review: At the completion of the detailed design stage, a final “build to” review is held with the Stakeholders. The purpose is for the development team to get final approval of the design prior to starting the implementation of the solution.
The technical issue usually raised during the feasibility stage of the investigation includes the following:
• Does the necessary technology exist to do what is suggested?
• Does the proposed equipment have the technical capacity to hold the data required to use the new system?
• Will the proposed system provide adequate response to inquiries, regardless of the number or location of users?
• Can the system be upgraded if developed?
• Are there technical guarantees of accuracy, reliability, ease of access and data security?
A system can be developed technically and that will be used if installed must still be a good investment for the organization. In the economic feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or exceed the costs.
Is there sufficient support for the management from the users?
• Will the system be used and work properly if it is being developed and implemented?
• Will there be any resistance from the user that will undermine the possible application benefits?
• What new skills will be required?
• Do the existing staff members have these skills?
• If not, can they be trained in due course of time?
1. Provides a set of steps.
2. Provides a set of milestones to judge progress against.
3. Provides a benchmark, to strive towards.
• Focuses testing on the function or software module.
• Concentrates on the internal processing logic and data structures.
• Is simplified when a module is designed with high cohesion.
• Allows errors to be more easily predicted and uncovered.
• Exercises specific paths in a component's control structure to ensure complete coverage and maximum error detection
• Components are then assembled and integrated.
• Provides final assurance that the software meets all functional, behavioral, and performance requirements
• Requirements are validated against the constructed software
• Validation testing follows integration testing
• The distinction between conventional and object-oriented software disappears
• Focuses on user-visible actions and user-recognizable output from the system
• Demonstrates conformity with requirements
• Verifies that all system elements (software, hardware, people, databases) mesh properly and that overall system function and performance is achieved
• The software and other system elements are tested as a whole
Tests for recovery from system faults
Forces the software to fail in a variety of ways and verifies that recovery is properly performed
Tests re-initialization, check-pointing mechanisms, data recovery, and restart for correctness
Verifies that protection mechanisms built into a system will, in fact, protect it from improper access
Executes a system in a manner that demands resources in abnormal quantity, frequency, or volume
Executes a system in a manner that demands resources in abnormal quantity, frequency, or volume
It is also called configuration testing.
Software generally runs on a variety of platforms and operating systems.
It ensures that the software can function in any environment.
It examines all the installation procedures and specialized installation software that will be used by the use, ad all the documentation that will be used to introduce the software to the end user
• Defined as a systematic technique for constructing the software architecture
• At the same time integration is occurring, conduct tests to uncover errors associated with interfaces
• Objective is to take unit tested modules and build a program structure based on the prescribed design
• Focuses on inputs and outputs, and how well the components fit together and work together
• Focuses on the design and construction of the software architecture
• Commonly called the “Big Bang” approach
• All components are combined in advance
• The entire program is tested as a whole
• Chaos ensues.
• Many seemingly-unrelated errors are encountered
• Correction is difficult because isolation of causes is complicated
• Once a set of errors are corrected, more errors occur, and testing appears to enter an endless loop
• The program is constructed and tested in small increments
• Errors are easier to isolate and correct
• Interfaces are more likely to be tested completely
• A systematic test approach is applied
Conducted at the developer’s site by end users
Software is used in a natural setting with developers watching intently
Testing is conducted in a controlled environment
Conducted at end-user sites
Developer is generally not present
It serves as a live application of the software in an environment that cannot be controlled by the developer
The end-user records all problems that are encountered and reports these to the developers at regular intervals
Planned approach towards working
The level of accuracy in the proposed system will be higher.
The reason for the increased reliability of the system is that now there would be proper storage of information.
Utmost care would be that no information is repeated anywhere, in storage or otherwise.
Immediate Information Retrieval
Any type of information would be available whenever the user requires
Immediate storage of information
Easy to Operate
Windows XP or Higher
Pentium 2 or Higher
64 MB or Higher
Database Management Staff
Every user should be:
1. Comfortable of working with computer.
2. He must have knowledge in medical field.
3. He must also have basic knowledge of English too.
A typical estimation model is derived from regression analysis collected from past software projects.
Effort in person-month
Function point count
Albert and Gaffney Method
E=-12.88+0.405*FP(Small Project Regression Model) =-12.8+0.45*57.3 =13.003
TOP DOWN Integration
· Modules are integrated by moving downward through the control hierarchy, beginning with the main module
· Subordinate modules are incorporated in either a depth-first or breadth-first fashion
DF: All modules on a major control path are integrated
BF: All modules directly subordinate at each level are integrated
This approach verifies major control or decision points early in the test process
§ Stubs need to be created to substitute for modules that have not been built or tested yet; this code is later discarded
§ Because stubs are used to replace lower level modules, no significant data flow can occur until much later in the integration/testing process
BOTTOM UP Integration
· Integration and testing starts with the most atomic modules in the control hierarchy
This approach verifies low-level data processing early in the testing process
Need for stubs is eliminated
· Driver modules need to be built to test the lower-level modules; this code is later discarded or expanded into a full-featured version
· Drivers inherently do not contain the complete algorithms that will eventually use the services of the lower-level modules; consequently, testing may be incomplete or more testing may be needed later when the upper level modules are available
· Consists of a combination of both top-down and bottom-up integration
· Occurs both at the highest level modules and also at the lowest level modules
· Proceeds using functional groups of modules, with each group completed before the next
§ High and low-level modules are grouped based on the control and data processing they provide for a specific program feature
§ Integration within the group progresses in alternating steps between the high and low level modules of the group
§ When integration for a certain functional group is complete, integration and testing moves onto the next group
· Reaps the advantages of both types of integration while minimizing the need for drivers and stubs
· Requires a disciplined approach so that integration doesn’t tend towards the “big bang” scenario
· Each new addition or change to base-lined software may cause problems with functions that previously worked flawlessly
· Regression testing re-executes a small subset of tests that have already been conducted
§ Ensures that changes have not propagated unintended side effects
§ Helps to ensure that changes do not introduce unintended behavior or additional errors
§ May be done manually or through the use of automated capture/playback tools
· Regression test suite contains three different classes of test cases
§ A representative sample of tests that will exercise all software functions
§ Additional tests that focus on software functions that are likely to be affected by the change
§ Tests that focus on the actual software components that have been changed
· Taken from the world of hardware
Power is applied and a technician checks for sparks, smoke, or other dramatic signs of fundamental failure
· Designed as a pacing mechanism for time-critical projects
Allows the software team to assess its project on a frequent basis
Includes the following activities
§ The software is compiled and linked into a build
§ A series of breadth tests is designed to expose errors that will keep the build from properly performing its function
§ The goal is to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule
§ The build is integrated with other builds and the entire product is smoke tested daily
§ Daily testing gives managers and practitioners a realistic assessment of the progress of the integration testing
§ After a smoke test is completed, detailed test scripts are executed
§ Integration risk is minimized
§ The quality of the end-product is improved
§ Error diagnosis and correction are simplified
§ Progress is easier to assess