Software Engineering
Software Engineering
Software engineering
PRACTICAL
File
Syllabus
1. Study and usage of Open Project or similar software to draft a project plan
2. Study and usage of Open Project or similar software to track the progress of a project
A PROJECT REPORT
TABLE OF CONTENTS
1. INTRODUCTION TO PROJECT
2. OVERALL DESCRIPTION
3. EXTERNAL INTERFACE REQUIREMENTS
4. SYSTEM FEATURES
5. OTHER NON-FUNCTIONAL REQUIREMENTS
6. SYSTEM STUDY
7. FEASIBILITY STUDY
8. SYSTEM ANALYSIS
9. DATA FLOW DIAGRAMS
10. INTRODUCTIONTOUML
11. INTRODUCTION TO RATIONAL ROSE
12. USE CASE DESCRIPTION
13. USE CASE DIAGRAM
14. CLASS DIAGRAM
15. SEQUENCE DIAGRAMS
16. COLLABORATION DIAGRAMS
17. STATE CHART DIAGRAMS
18. ACTIVITY DIAGRAMS
19. COMPONENT DIAGRAM
20. DEPLOYMENT DIAGRAM
21. SCOPE
22. CONCLUSION
23. BIBLIOGRAPHY
PURPOSE
Hospital management system is the most important part for Doctors. As test is the most important for
knowing cause of any diseases. Besides maintaining other records of the hospital every year or after some
time, the price of conducting tests changes, then it issues a list of prices of every test. Hence, software
concerning Hospital Management should be well organized for its efficient working. So, this project is
an attempt to relieve the burden of manual system by providing fully automated and a secure system. The
function, which this system provides, is maintaining the records of the patient pertaining to his name,
address, tests and tests results. The password system check allows only the authorized person to use
the system in order to maintain the security of the system and if the user forgets his password then he can
use his security question and password to enter the system.
OVERALL DESCRIPTION
PRODUCT PERSPECTIVE
In the proposed system, all the work done is computerized. All the Tests of the Patients are recorded in
database through the computers. Because of maintenance of records we can easily identify each user.
This System also provides the facilities of maintaining records of the Lab reports & Calculating Bills.
The software will be general software which can be used on any computer system satisfying certain
requirements.
PRODUCT FUNCTIONS
HARDWARE INTERFACES
An important factor in the proposed system is hardware. In hardware we describe the peripheral devices
that are attached to the system and from these devices we insert values as input to attain output.
SOFTWARE INTERFACES
SYSTEM FE ATURES
One Integrated View to Patients for Billing, Collection, Discharge Detail, Patient Medical
History etc.
Package supports Adaptability & Scalability of software making it more robust.
General and Standardized Health Packages for the OPD and IPD Patients
Authentication and verification of entries through Audit Trail Facility
Easy Query Handling for instant decision of Bed Allocation for Patients, and request for the
Bed Transfers
Effective Search facility to search any type of information related to Patient history
Graphical Presentation of the Data for Top Management for analysis. Comprehensive
Performance Reports.
Built in Work Flow Management for all functional areas
Multiple Store Accounting
Interface facility with the Smart Card Technology
Interface with Bar Code
QUALITY ATTRIBUTES:
Graphical User Interface: This System is totally graphical user interface. This mean all work is
done by Pointing Devices or we can say that there is no need of remembering the commands by
the users.
Understandable by novice users: This System is easily understandable by the Novice
Users. Novice users are those that are used the system first time.
Flexible: This system is flexible as new modules can be added easily and faster into the system.
Time saving: - Records maintaining manually takes a lots of Paper work. This work was
very hectic and consumes a lot of labor work. In this all Data is stored Computerized. Data is also
being stored directly & time & labor work is saved.
Easy To Change: - With the help of proposed system it will be easier to change data
regarding the candidates and to store at the same time.
Easy To Understand: - This system is easily understandable by the user. Novice users also
used this system easily.
Chance of Errors: - Since database is maintained automatically there is no chance of error
inconsistencies there. If an error occurs in System in any case can be maintained easily.
User Friendly: - It will provide a user friendly interface and will be easily accessible.
Fast Process: Speed of Processing is high.
Security: - Degree of Security is high in this system because only valid user can access the
system.
SYSTEM STUDY
System study is a comprehensive management study for investigation of overall problem, which is to be
solved by which there will be increase in the efficiency and effectiveness of the system. When a new
system is developed, we need to study the old system and its relationship with an outside of the system.
A Hospital is a place where Patients come up for general diseases. Hospitals provide
facilities like:-
These are the various jobs that need to be done in a Hospital by the operational staff and Doctors. All
these works are done on papers.
Information about Patients is done by just writing the Patients name, age and
gender. Whenever the Patient comes up his information is stored freshly.
Bills are generated by recording price for each facility provided to Patient on a
separated sheet and at last they all are summed up.
Diagnosis information to patients is generally recorded on the document, which contains Patient
information. It is destroyed after some time period to decrease the paper load in the office.
Immunization records of children are maintained in pre-formatted sheets, which are kept in a file.
Information about various diseases is not kept as any document. Doctors themselves do this job
by remembering various medicines.
All this work is done manually by the receptionist and other operational staff and lot of papers are needed
to be handled and taken care of. Doctors have to remember various medicines available for diagnosis and
sometimes miss better alternatives as they can’t remember them at that time.
1. Lack of immediate retrievals: - The information is very difficult to retrieve and to find particular
information like- E.g. - To find out about the patient’s history, the user has to go through various registers.
This results in inconvenience and wastage of time.
2. Lack of immediate information storage: - The information generated by various transactions takes
time and efforts to be stored at right place.
3. Lack of prompt updating: - Various changes to information like patient details or immunization details of
child are difficult to make as paper work is involved.
4. Error prone manual calculation: - Manual calculations are error prone and take a lot of time this may
result in incorrect information. For example, calculation of patient’s bill base d on various treatments.
5. Preparation of accurate and prompt reports: - This becomes a difficult task as information is difficult to
collect from various registers.
1. Planned approach towards working: - 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.
2. Accuracy: - 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.
3. Reliability: - 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.
5. Immediate retrieval of information: - 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 user requires.
6. Immediate storage of information: - In manual system there are many problems to store the largest
amount of information.
7. Easy to Operate: - 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 user.
FE ASIBILTY STUDY
Depending on the results of the initial investigation the survey is now expanded to a more detailed feasibility
study. “FEASIBILITY STUDY” is a test of system proposal according to its workability, impact of the
organization, ability to meet needs and effective use of the resources. It focuses on these major questions:
1. What are the user’s demonstrable needs and how does a candidate systemmeet them?
3. What are the likely impacts of the candidate system on the organization?
During feasibility analysis for this project, following primary areas of interest are to be considered.
Investigation and generating ideas about a new system does this.
TECHNICAL FEASIBILITY
A study of resource availability that may affect the ability to achieve an acceptable system. This
evaluation determines whether the technology needed for the proposed system is available or not.
Can the work for the project be done with current equipment existing software technology &
available personal?
Can the system be upgraded if developed?
If new technology is needed then what can be developed?
This is concerned with specifying equipment and software that will successfully satisfy the user
requirement. The technical needs of the system may include:
An important issue for the development of a project is the selection of suitable front -end and back- end.
When we decided to develop the project we went through an extensive study to determine the most suitable
platform that suits the needs of the organization as
Front-end selection:
1. It must have a graphical user interface that assists employees that are not from IT
background.
3. Flexibility.
4. Robustness.
7. Platform independent.
10. Front end must support some popular back end like Ms Access.
Back-end Selection:
5. Stored procedures.
6. Popularity.
8. Easy to install.
The technical feasibility is frequently the most difficult area encountered at this stage. It is essential that the
process of analysis and definition be conducted in parallel with an assessment to technical feasibility. It
centers on the existing computer system (hardware, software etc.) and to what extent it can support the
proposed system. The system is technically viable because can run on PC with the following hardware and
software configuration:-
Processor : Pentium IV
ECONOMICAL FEASIBILITY
Economic justification is generally the “Bottom Line” consideration for most systems. Economic justification
includes a broad range of concerns that includes cost benefit analysis. In this we weight the cost and
the benefits associated with the candidate system and if it suits the basic purpose of the organization i.e.
profit making, the project is making to the analysis and design phase. The financial and the economic
questions during the preliminary investigation are verified to estimate the following:
It is mainly related to human organizations and political aspects. The points to be considered are : What
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?
The system is operationally feasible as it very easy for the End users to operate it. It only needs basic
information about Windows platform.
SYSTEM AN ALYSIS
System analysis is a detailed study of the various operations performed by a system and their relationships
within and outside the system. The goal of system analysis is to produce the system requirements of the
proposed information system. There is doubt that presently existing manual system can be improved
tremendously by changing certain procedures and implying manp ower. But from the study of present
manual system it is found that there is a large amount of redundancy i.e. some of the information has to be
recorded and checked repeatedly which lead to wastage of time and increase the possibility of committing
errors. Considering all the aspects, the introduction of computers is done to overcome the difficulties
and to provide complete justification to computerize the existing system.
PROBLEM UNDERSTANDING
There is not yet much use of the computers for any work. This has resulted in low efficiency, a lot of time
wastage and data redundancy. Another major flaw in manual system is insecurity. There are no backups
and data recovery solutions available.
Therefore main motive behind the new system was to minimize the problem faced due to old system. All
the problems regarding old system were thoroughly seen. All the minus points were determined so that no
problem could persist.
The development environment ensures that it has the portability and connectivity to run on virtually all
standard hardware platforms, with stringent data security and easy recovery in case of a system failure.
It provides the benefits of streamlined operations, enhanced administration and control, improved
response to patient care, cost control, and increased profitability.
We believe that every hospital is unique in terms of its requirements and priorities. Hence, flexibility has
been built to allow easy customization.
REQUIRED SPECIFICATION
SRS is a document that completely describes what the proposed system should do without
describing how the system will do it. SRS helps the developer in knowing what the client expects from the
computerized system.
Key part of the system analysis is gathering information about the present system. A system not well
defined in the analysis stage can never be correct. The main sources of information that provide
accurate data about the existing system are as follows:
The DFDs given below illustrates and describes data flow, processing steps, source, sinks and data
stores used to describe the overall functionality of the project. The following one describes the
processing transactions that take place.
DFD LEVEL 0
DFD LEVEL 1
DFD LEVEL 2
DFD LEVEL 3
INRODUCTION TO UML
The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and
documenting the artifacts of software systems, as well as for business modeling and other non-software
systems. The UML represents a collection of best engineering practices that have proven successful in the
modeling of large and complex systems. The UML is a very important part of developing object-oriented
software and the software development process. The UML uses mostly graphical notations to express the
design of software projects. Using the UML helps project teams communicate, explore potential designs,
and validate the architectural design of the software.
Goals of UML
1. Provide users with a ready-to-use, expressive visual modeling language so they can develop
and exchange meaningful models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development processes.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as collaborations, frameworks, patterns and
components.
7. Integrate best practices.
As the strategic value of software increases for many companies, the industry looks for techniques to
automate the production of software and to improve quality and reduce cost and time-to-market. These
techniques include component technology, visual programming, patterns and frameworks. Businesses
also seek techniques to manage the complexity of systems as they increase in scope and scale. In
particular, they recognize the need to solve recurring architectural problems, such as physical distribution,
concurrency, replication, security, load balancing and fault tolerance. Additionally, the
development for the World Wide Web, while making some things simpler, has exacerbated these
architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs.
1. Things
2. Relationships
3. Diagrams
1. Things:-
Things are the most important building blocks of UML. Things can be:
Structural Things
Behavioral Things
Grouping Things
Annotational Things
Structural Things:
The Structural things define the static part of the model. They represent physical and conceptual
elements.
1. Class
2. Interface
3. Collaboration
4. Use case
5. Active classes
6. Components
7. Nodes
Class Notation:
UML class is represented by the diagram shown below. The diagram is divided into four parts.
Classes are used to represent objects. Objects can be anything having properties and responsibility.
Interface Notation:
Interface is represented by a circle as shown below. It has a name which is generally written below
the circle.
Interface is used to describe functionality without implementation. Interface is the just like a template
where you define different functions not the implementation. When a class implements the interface it also
implements the functionality as per the requirement.
Collaboration Notation:
Collaboration is represented by a dotted eclipse as shown below. It has a name written inside the ellipse.
Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities.
Component Notation:
A component in UML is shown as below with a name inside. Additional elements can be added wherever
required.
Component is used to represent any part of a system for which UML diagrams are made.
Node Notation:
A node in UML is represented by a square box as shown below with a name. A node represents a
physical component of the system.
Node is used to represent physical part of a system like server, network etc.
Behavioral things:
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral
things:
1. Interaction
2. State machine
Interaction:
State machine:
State machine is useful when the state of an object in its life cycle is important. It defines the sequence of
states an object goes through in response to events. Events are external factors responsible for state
change.
Grouping things:
Grouping things can be defined as a mechanism to group elements of a UML model together. There
is only one grouping thing available:
Package:
Package is the only one grouping thing available for gathering structural and behavioral things.
Annotational things:
Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of
UML model elements. Note is the only one Annotational thing available.
Note:
2. Relationships
A model is not complete unless the relationships between elements are described properly. The
Relationship gives a proper meaning to an UML model. Following are the different types of relationships
available in UML.
1. Dependency
2. Association
3. Generalization
4. Realization
Dependency:
Dependency is a relationship between two things in which change in one element also affects the other
one.
Association:
Association is basically a set of links that connects elements of an UML model. It also describes how many
objects are taking part in that relationship.
Generalization:
Generalization can be defined as a relationship which connects a specialized element with a generalized
element. It basically describes inheritance relationship in the world of objects.
Realization:
Realization can be defined as a relationship in which two elements are connected. One element describes
some responsibility which is not implemented and the other one implements them. This relationship exists
in case of interfaces.
3. UML Diagrams:
UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are used to
make a complete UML diagram and the diagram represents a system.
The visual effect of the UML diagram is the most important part of the entire process. All the other
elements are used to make it a complete one.
There are two broad categories of diagrams and then are again divided into sub - categories:
1. Structural Diagrams
2. Behavioral Diagrams
1. Structural Diagrams:
The structural diagrams represent the static aspect of the system. These static aspects represent those
parts of a diagram which forms the main structure and therefore stable.
These static parts are represents by classes, interfaces, objects, components and nodes. The four
structural diagrams are:
1. Class diagram
2. Object diagram
3. Component diagram
4. Deployment diagram
Class Diagram:
Class diagrams are the most common diagrams used in UML. Class diagram consists of classes,
interfaces, associations and collaboration.
Class diagrams basically represent the object oriented view of a system which is static in nature.
Active class is used in a class diagram to represent the concurrency of the system.
Class diagram represents the object orientation of a system. So it is generally used for development
purpose. This is the most widely used diagram at the time of system construction.
Object Diagram:
Object diagrams can be described as an instance of class diagram. So these diagrams are more close to
real life scenarios where we implement a system.
Object diagrams are a set of objects and their relationships just like class diagrams and also represent
the static view of the system.
The usage of object diagrams is similar to class diagrams but they are used to build prototype of a
system from practical perspective.
Component Diagram:
Component diagrams represent a set of components and their relationships. These components
consist of classes, interfaces or collaborations.
During design phase software artifacts (classes, interfaces etc) of a system are arranged in different
groups depending upon their relationship. Now these groups are known as components.
Deployment Diagram:
Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities where
the components are deployed.
Deployment diagrams are used for visualizing deployment view of a system. This is generally used
by the deployment team.
2. Behavioral Diagrams:
Any system can have two aspects, static and dynamic. So a model is considered as complete when
both the aspects are covered fully.
Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be further
described as the changing/moving parts of a system.
Use case diagrams are a set of use cases, actors and their relationships. They represent the use case
view of a system.
So use case diagram is used to describe the relationships among the functionalities and their
internal/external controllers. These controllers are known as actors.
Sequence Diagram:
A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals with some
sequences, which are the sequence of messages flowing from one ob ject to another.
Interaction among the components of a system is very important from implementation and execution
perspective.
So Sequence diagram is used to visualize the sequence of calls in a system to perform a specific
functionality.
Collaboration Diagram:
Collaboration diagram is another form of interaction diagram. It represents the structural organization of a
system and the messages sent/received. Structural organization consists of objects and links.
The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of
collaboration diagram is to visualize the organization of objects and their interaction.
Statechart Diagram:
Any real time system is expected to be reacted by some kind of internal/external events. These events
are responsible for state change of the system.
Statechart diagram is used to represent the event driven state change of a system. It basically
describes the state change of a class, interface etc.
State chart diagram is used to visualize the reaction of a system by internal/external factors.
Activity Diagram:
Activity diagram describes the flow of control in a system. So it consists of activities and links. The flow
can be sequential, concurrent or branched.
Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared to
capture the entire flow in a system.
Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have an idea of
how the system will work when executed.
1. Names
2. Scope
3. Visibility
4. Integrity
5. Execution
Common Mechanisms:-
1. Specifications
2. Adornments
3. Common Divisions
4. Extensibility Mechanisms
Specifications:-
The UML is more than just a graphical language. Rather, behind every part of its graphical notation there
is a specification that provides a textual statement of the syntax & semantics of that building block.
Adornments:-
“Adorn” the model – i.e., enhance the model. Adds to the meaning and/or semantics of the element to
which it pertains.
Common Division:-
In modeling object-oriented systems, the world often gets divided in at least a couple of ways.
There is the division of class & object. A class is an abstraction. An object is one concrete manifestation of
that abstraction.
Extensibility Mechanisms:-
1. Stereotypes
2. Tagged values
3. Constraints
Stereotypes:
Tagged Values:
2. Stereotypes help create new building blocks; tagged values help create new attributes.
3. Commonly used to specify information relevant to code generation, configuration management, etc.
Constraints:
A Constraint extends the semantics of a UML building block, allowing you to add new rules or modify
existing ones.
UML Architecture
Any real world system is used by different users. The users can be developers, testers, business people,
analysts and many more. So before designing a system the architecture is made with different perspectives
in mind. The most important part is to visualize the system from different viewer’s perspective. The better
we understand the better we make the system.
UML plays an important role in defining different perspectives of a system. These perspectives
are:
1. Design
2. Implementation
3. Process
4. Deployment
And the centre is the Use Case view which connects all these four. A Use case represents the
functionality of the system. So the other perspectives are connected with use case.
Design of a system consists of classes, interfaces and collaboration. UML provides class diagram,
object diagram to support this.
Process defines the flow of the system. So the same elements as used in Design
are also used to support this perspective.
Deployment represents the physical nodes of the system that forms the hardware. UML
deployment diagram is used to support this perspective.
Design View: The design view of a system is the structural view of the system. This gives an idea
of what a given system is made up of. Class diagrams and object diagrams form the design view
of the system.
Process View: The dynamic behavior of a system can be seen using the process view.
The different diagrams such as the state diagram, activity diagram, sequence diagram, and
collaboration diagram are used in this view.
Implementation View: Next, you have the component view that shows the grouped
modules of a given system modeled using the component diagram.
Deployment View: The deployment diagram of UML is used to identify the deployment
modules for a given system. This is the deployment view of the
Use case View: Finally, we have the use case view. Use case diagrams of UML are used to view
a system from this perspective as a set of discrete activities or transactions.
Rational Rose is a powerful visual modeling tool to aid in the analysis and design of object-oriented
software systems. It is used to model your system before you write any code, so you can be sure that the
system is architecturally sound from the beginning. It helps with system analysis by enabling you to design
use cases and Use Case diagrams to show the system functionalities. It will let you design Interaction
diagram to show how the objects work together to provide the needed functions.
Class diagrams can be created to show the classes in a system and how they relate to each other.
Component diagrams can be developed to illustrate how the classes map to implementation components.
Finally, Deployment diagrams can be produced to show the network design for the system.
3. The window you will see will look something like this:
Browse
Diagram
window
Diagra
m
Documentation
Window
Specification
Log
State chart (or state) diagrams describe the states and responses of a class. State chart diagrams describe
the behavior of a class in response to external stimuli. These diagrams contain the following elements:
• States, which represent the situations during the life of an object in which it satisfies some
condition, performs some activity, or waits for some occurrence.
• Transitions, which represent relationships between the different states of an object
Activity Diagrams
Activity diagrams describe the activities of a class. These diagrams are similar to state chart diagrams and use
similar conventions, but activity diagrams describe the behavior of a class in response to internal processing rather
than external events as in state chart diagram.
• Swim lanes, which represent responsibilities of one or more objects for actions within an overall
activity; that is, they divide the activity states into groups and assign these groups to
Objects that must perform the activities.
• Action States, which represent atomic, or non-interruptible, actions of entities or steps in the execution of
an algorithm.
• Action flows, which represent relationships between the different action states of an entity
• Object flows, which represent the utilization of objects by action states and the influence of action states on
objects.
Logical view:
The Logical view focuses on how the system will implement the behavior in the use cases.
It provides a detailed picture of the pieces of the system, and describes how the pieces interrelate. With
these detailed elements, developers can construct a detailed design for the system.
•Classes
•Class diagrams
•Associations
•Interfaces
•Sequence diagrams
•Collaboration diagrams
•Packages
Component view
The Component view contains information about the code libraries, executable files, run - time libraries,
and other components in your model.
The Component view of the system allows you to see the relationships between the modules of
code.
Components
Interfaces
Component diagrams
Packages
Deployment view
The Deployment view is concerned with the physical deployment of the system, which may differ from
the logical architecture of the system. The Deployment view contains processors, devices, processes, and
connections between processors and devices. All of this information is diagrammed on a Deployment
diagram. There is only one Deployment diagram per system. For example, the system may have logical
three-tier architecture. The interface may be separated from the business logic and the database logic.
However, the deployment may be two-tiered. The interface may be placed on one machine, while the
business and database logic are located on another machine.
Other issues, such as fault tolerance, network bandwidth, disaster recovery, and response time, are also
handled using the Deployment view.
Processes
Processors
Connectors
Devices
Deployment diagram
USECASE DESCRIPTION
2. Doctor Appointments
3. Tests Appointments
4. Bed Allotment
5. Undergo Operation
6. Login
7. Draw Salary
8. Add Doctor/Staff
9. Delete Doctor/Staff
Actors: 1. Receptionist
2. Doctors
3. Staff/Nurses
4. Income
5. Expenditure
6. Records System
7. Information System
ADMISSIONS:
This Module helps in registering information about patients and handles patient’s query. A unique ID is generated
for each patient after registration. This helps in implementing customer relationship management and also maintains
medical history of the patient.
DOCTOR APPOINTMENTS:
This Module Deals with, when the ID is generated the patient receives the Appointment time &
number from the Receptionist and accordingly visit the doctor.
TESTS APPOINTMENTS:
This Module Deals with, when the ID is generated the patient receives the Appointment time &
number from the Receptionist and accordingly undergoes the tests.
BED ALLOTMENT:
This Module handles with allotting the Bed to various patients by checking their ID.
UNDERGO OPERATION:
This Module handling with undergoes the various operations by diagnosing the patients.
LOGIN:
This Module checks whether the person is a Doctor/Staff and handles various activities such as draw Salary and
give Salary.
DRAW SALARY:
This Module checks whether the person is a Doctor/Staff and draws salary based on the information.
ADD DOCTOR/STAFF:
This Module handles the activities such as adding Doctor/Staff information into the database.
DELETE DOCTOR/STAFF:
This Module handles the activities such as deleting Doctor/Staff information into the database.
EDIT DOCTOR/STAFF:
This Module handles the activities such as editing Doctor/Staff information into the database.
PRESCRIBE TESTS:
This Module handles various activities such as Doctor Diagnoses the patient, gives treatment &
gives suggestions to the patients, & prescribes laboratory tests & medicines.
This Module takes care of medical equipment, doctor visit, vitals recording, patient case sheet, diet ordering, blood
requisition, transfer intimation and discharge intimation etc. It also deals with the maintenance of the wards, inter-
and intra-ward transfers.
ADMISSION/DISCHARGE REPORTS:
This Module helps in generating patient’s discharge summary, which includes patient’s health at the time of
discharge, medical history, various diagnosis and drug prescriptions, history of present illness and course in hospital.
PATIENT INFORMATION:
This Module helps in generating the patient information which is provided by doctor.
<<exten
ADMISSIONS d>> BED ALLOTMENT
<<extend>
>
TEST APPOINTMENTS
Financ
e
manage
me...
LOGI
N
Expenditure
Staff/Nurses
DRAW SALARY
ADD DOCTOR/STAFF
ADDMISSION/DIS
Informat
CHARGE
ion
REPORTS Syste
m
PATIENT
INFORMATION
CLASSDI AGR AM
ADMISSIO NS:
1 : create()
2 : inpatient()
3:
register()
4:
addApptCharges(
)
5 : date()
6 : time()
1 : ispatient()
2:
addApptCharges(
)
3 : date()
4 : time()
5 : docappt()
TESTS APPOINTMENTS:
1 : inpatient()
2:
addTestCharges(
)
3 : date()
4 : time()
5 : testappt()
BED ALLOTMENT:
1 : addWardCharges()
2:
allotBed()
3 : getname()
4 : dispWardStatus()
UNDERGO OPERATION:
1 : ispatient()
2:
addoprcharges(
)
3:
getOpr()
LOGIN:
1 : isDoctor()
2 : isStaff()
3:
drawSalary()
4:
giveSalary()
DRAW S ALARY:
1 : isDoctor()
2 : isStaff()
3:
drawSalary()
4 : giveSalary()
ADD DOCTOR/STAFF:
Edit DoctorStaff
1 : isDoctor()
2 : isStaff()
3 : addDoctor()
4 : addStaff()
DELETE DOCTOR/STAFF:
Edit DoctorStaff
1 : isDoctor()
2 : isStaff()
3 : delDoctor()
4 : delStaff()
EDIT DOCTOR/STAFF:
Edit DoctorStaff
1 : isDoctor()
2 : isStaff()
3 : editDoc()
4 : editStaff()
PRESCRIBE TESTS:
1 : addTestsCharges()
2 : getTests()
3:
AddisReport()
1 : isPatient()
2 : allotBed()
3 :
bedStat
us()
4 :
dispWardS
tatus()
Pat TestsOperations
ien Reports
t
1 : isPatient()
2 : getTests()
3 :
getOp
er()
4 :
dispWard
Status()
5 :
dispAddisReport()
P ATIENT INFORMATIO N:
Patient Registration
Reports
1 : isPatient()
2 :
dispWardS
tatus()
3 :
dispAddisR
eport()
4 : dispPattinfo()
ADMISSIO NS:
1 : create() 3 : register()
Patient
Registration
2 : inpatient()
4 : addApptCharges()
5:
date()
Appointment Income
6 : time()
1 : ispatient() 2 : addApptCharges()
3 : date()
Patie Inco Appointm 4:
nt me ent time()
5 : docappt()
TestsOperations
TESTS APPOINTMENTS:
3:
1 : inpatient() 2: date()
Patien addTestCharges() Income Appointme
t nts
5 : testappt()
TestsOperations
BED ALLOTMENT:
2 : allotBed()
Income 3 : getname() Ward
1: 4 : dispWardStatus()
addWardCharges(
)
Registration Reports
UNDERGO OPERATION:
2:
addoprcharges(
)
Income
1: 3 : getOpr()
ispatient()
Patient TestsOperations
LOGIN:
3 : drawSalary()
DoctorStaff
2:
isStaff( 4 : giveSalary()
)
1 : isDoctor()
Edit Expenditure
DRAW S ALARY:
3 : drawSalary()
DoctorS Expendi Income
atff ture
4 : giveSalary()
2 : isStaff()
1 : isDoctor()
Edit
ADD DOCTOR/STAFF:
DoctorStaff
4 : addStaff()
3 : addDoctor()
2 : isStaff()
1 : isDoctor()
Edit
DELETE DOCTOR/STAFF:
DoctorStaff
4 : delStaff()
3 : delDoctor()
2 : isStaff()
1 : isDoctor()
Edit
EDIT DOCTOR/STAFF:
DoctorStaff
4 : editStaff()
3 : editDoc()
2 : isStaff()
1 : isDoctor()
Edit
PRESCRIBE TESTS:
Reports
3:
AddisReport()
TestsOperations
2:
1 : addTestsCharges()
getTests()
DoctorSt
aff
Report 4 : dispWardStatus()
s
3 : bedStatus()
War
d
1:
isPatient() 2 : allotBed()
Patient
3 :
getOper
()
TestsOperations 5 :
Reports dispAddisReport()
4 :
dispWardSta
tus()
2 : getTests()
1 : isPatient()
Patient
P ATIENT INFORAMTIO N:
1:
isPatient
()
Patient
Registration
2 : dispWardStatus()
3 : dispAddisReport()
4 : dispPattinfo()
Reports
P ATIENT:
Enter Hospital
Takes Appointment
Undergo Diagnosis
gets
cured
RECPTIONIST:
giv es appointment
giv
es
bill
takes
bill
amount
DOCTOR:
Diagonise
patient
Gives
Treatment
Cures the
patient
COMPONENT DI AGR AM
GUI
DEPLOYMENT DI AGR AM
DISEASE UNIT
SERVER
<<artifact>
>
contains information about
Receptionist PC
<<artifact>
>
user friendly
screens
SCOPE
This project is made in such a way that it can be easily modified in more advance form if need arises. The
database of this software maintains the records of the details of patients who g ive their tests in the
hospital. This record will have a lot of use in the future related to any enquiry. The transactions are also
reveled in this project. Any financial enquiry can be satisfied through this software. In future any fields can
be added and deleted to and from the tables. Thus, this project has a wide application in the future. It can
be used in any Hospital, Clinic, Dispensary or Pathology labs for maintaining patient details and their test
results.
Computers are always changing. There are bugs to fix, enhancement to add and optimization to make. So
changes have to be done in older version to make it applicable for current use and of current version to
cater the need of future though efforts have been made to develop and error free system but no system are
perfect, room for improvement is always there. Proper documentation has been done so that it will be
easy in future to handle any breakdown or any other type of system activity.
The system has been developed putting the best efforts at all the levels of development. There
is a no. of factors that attribute to further improvement into a better package like
The system has been developed keeping a personal computer user in mind .it can be
improve into a system that supports network access.
Graphical output has always been in case of analysis of data as compared to numerical data
facility for generating graphical representation of the growth.
CONCLUSION
The project Hospital Management System (HMS) is for computerizing the working in a hospital. The
software takes care of all the requirements of an average hospital and is capable to provide easy and
effective storage of information related to patients that come up to the hospital. It generates test
reports; provide prescription details including various tests, diet advice, and medicines prescribed to patient
and doctor. It also provides billing facility on the basis of patient’s status.
BIBLIOGRAPHY
Books
Ivar Jacobson
Web sites
www.ecst.csuchico.edu
www.cs.f su.edu
www.iranzik.com