Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start 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.


Hospital Management System

No description

Jaffar Ahmed

on 27 April 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Hospital Management System

Feasibility Study
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
Data Table
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
Medical status
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.

Technical feasibility
Economic Feasibility
Operational feasibility
Entity Relationship Diagram
Log In Table
Patient Details
Model Used
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.

Calculating Functional Points
Effort Calculation
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.

Project Management
Process Activities-
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.
No Redundancy
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
Software Requirements
Operating System
Windows XP or Higher
Microsoft Access
Pentium 2 or Higher
64 MB or Higher
Disk Space
130 MB
Administration Level
User Level
Database Management Staff
Other Users
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.

E =
Effort in person-month
FP =
Function point count

Albert and Gaffney Method
Kemmerer 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

· Advantages

This approach verifies major control or decision points early in the test process

· Disadvantages

§ 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

· Advantages

This approach verifies low-level data processing early in the testing process

Need for stubs is eliminated

· Disadvantages

· 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
Sandwich Integration
· 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
Regression Testing
· 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
Smoke Testing
· 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

· Benefits:

§ Integration risk is minimized

§ The quality of the end-product is improved

§ Error diagnosis and correction are simplified

§ Progress is easier to assess
Full transcript