Final boss

FSD PRACTICAL 166710000000
1
Hospital Management System
Made BY
PREET OJHA
&&
ALPESH SOLANKI

2
PRACTICAL-1
AIM: Identify the development model for software with proper explanation.
1. WATERFALL MODEL
The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-
sequential life cycle model. It is very simple to understand and use. In a waterfall model, each
phase must be completed fully before the next phase can begin. This type of software
development model is basically used for the for the project which is small and there are no
uncertain requirements. At the end of each phase, a review takes place to determine if the project
is on the right path and whether or not to continue or discard the project. In this model software
testing starts only after the development is complete. In waterfall model phases do not overlap
WATERFALL MODEL DIAGRAM:
Advantages of waterfall model:
 This model is simple and easy to understand and use.
 It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 In this model phases are processed and completed one at a time. Phases do not overlap.

3
 Waterfall model works well for smaller projects where requirements are very well
understood.
Disadvantages of waterfall model:
 Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing.
When to use the waterfall model:
 This model is used only when the requirements are very well known, clear and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.

4
2. INCREMENT MODEL
In incremental model the whole requirement is divided into various builds. Multiple
development cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are
divided up into smaller, more easily managed modules. Incremental model is a type of software
development mode like V-model, Agile model etc.
In this model, each module passes through the requirements, design, implementation
and testing phases. A working version of software is produced during the first module, so you
have working software early on during the software life cycle. Each subsequent release of the
module adds function to the previous release. The process continues till the complete system is
achieved.
INCREMENTAL MODEL DIAGRAM:
Advantages of Incremental model:
 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and handled during it’d
iteration.

5
Disadvantages of Incremental model:
 Needs good planning and design.
 Needs a clear and complete definition of the whole system before it can be broken down
and built incrementally.
 Total cost is higher than waterfall.
When to use the Incremental model:
 This model can be used when the requirements of the complete system are clearly defined
and understood.
 Major requirements must be defined; however, some details can evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.

6
3. RAD MODEL
RAD model is Rapid Application Development model. It is a type of incremental model. In RAD
model the components or functions are developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into a working prototype. This can
quickly give the customer something to see and use and to provide feedback regarding the
delivery and their requirements .
DIAGRAM OF RAD MODEL:
The phases in the rapid application development (RAD) model are:
Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that
are needed for the business.

7
Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective. Description are identified and
created for CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and the
actual system.
Testing and turnover: Test new components and all the interfaces.
Advantages of the RAD model:
 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD model:
 Depends on strong team and individual performances for identifying business
requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.
When to use RAD model:
 RAD should be used when there is a need to create a system that can be modularized in
2-3 months of time.
 It should be used if there’s high availability of designers for modeling and the budget is
high enough to afford their cost along with the cost of automated code generating tools.
 RAD SDLC model should be chosen only if resources with high business knowledge are
available and there is a need to produce the system in a short span of time (2-3 months).

8
4. PROTOTYPE MODEL
The basic idea in Prototype model is that instead of freezing the requirements before a design or
coding can proceed, a throwaway prototype is built to understand the requirements. This
prototype is developed based on the currently known requirements. Prototype model is
a software development model. By using this prototype, the client can get an “actual feel” of the
system, since the interactions with prototype can enable the client to better understand the
requirements of the desired system. Prototyping is an attractive idea for complicated and large
systems for which there is no manual process or existing system to help determining the
requirements.
The prototype are usually not complete systems and many of the details are not built in the
prototype. The goal is to provide a system with overall functionality.
DIAGRAM OF PROTOTYPE MODEL:
Advantages of Prototype model:
 Users are actively involved in the development
 Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily
 Confusing or difficult functions can be identified
Requirements validation, Quick implementation of, incomplete, but
functional, application.
Disadvantages of Prototype model:
 Leads to implementing and then repairing way of building systems.
 Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.

9
When to use Prototype model:
 Prototype model should be used when the desired system needs to have a lot of
interaction with the end users.
 Typically, online systems, web interfaces have a very high amount of interaction with
end users, are best suited for Prototype model. It might take a while for a system to be
built that allows ease of use and needs minimal training for the end user.
 Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.

10
5. SPIRAL MODEL
The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements is
gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral. It’s one of
the software development models like Waterfall, Agile, V-Model.
Planning Phase: Requirements are gathered during the planning phase. Requirements like
‘BRS’ that is ‘Business Requirement Specifications’ and ‘SRS’ that is ‘System Requirement
specifications’.
Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate
solutions. A prototype is produced at the end of the risk analysis phase. If any risk is found
during the risk analysis then alternate solutions are suggested and implemented.
Engineering Phase: In this phase software is developed, along with testing at the end of the
phase. Hence in this phase the development and testing is done.
Evaluation phase: This phase allows the customer to evaluate the output of the project to date
before the project continues to the next spiral.
DIAGRAM OF SPIRAL MODEL:
Advantages of Spiral model:
 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.

11
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
Disadvantages of Spiral model:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.
When to use Spiral model:
 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because of potential changes to economic
priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and exploration)

12
PRACTICAL-2
AIM: Requirement gathering of a system
Requirements gathering: - The goal of the requirements gathering activity is to collect all
relevant information from the customer regarding the product to be developed and analyzed.
This phase is done to clearly understand the customer requirements so that incompleteness
and inconsistencies are removed. This activity begins by collecting all relevant data regarding
the product to be developed from the user and from the customer through interviews and
discussions.
For example, to perform the requirements analysis of a business
accounting software required by an organization, the analyst might interview all the
accountants of the organization to ascertain their requirements.
The data collected from such a group of users usually contain several
contradictions and ambiguities, since each user typically has only a partial and incomplete view
of the system. Therefore it is necessary to identify all ambiguities and contradictions in the
requirements phase and resolve them through further discussions with the customer.
Requirements specification: - After all ambiguities, inconsistencies, and incompleteness have
been resolved and all the requirements properly understood, the requirements specification
activity can start.
During this activity, the user requirements are systematically organized into a Software
Requirements Specification (SRS) document.
The customer requirements identified during the requirements gathering and analysis activity
are organized into a SRS document.
The important components of this document are: -functional requirements of the system -
nonfunctional requirements of the system -goal of implementation
Requirements specification: - After all ambiguities, inconsistencies, and incompleteness have
been resolved and all the requirements properly understood, the requirements specification
activity can start. During this activity, the user requirements are systematically organized into a
Software Requirements Specification (SRS) document.
The customer requirements identified during the requirements gathering and analysis activity
are organized into a SRS document.
The important components of this document are: -functional requirements of the system -
nonfunctional requirements of the system -goal of implementation.

13
PRACTICAL 3
AIM: System Requirement Specification Document for Hospital Management System.
Objective: To get with preparing requirement document, which is used to capture
and document all the requirements at the start of project. In the assignment we mainly focus
on functional requirements.
1. Introduction:
1.1 Purpose:
The main purpose of our system is to make hospital task easy and is to develop software that
replaces the manual hospital system into automated hospital management system. This
document serves as the unambiguous guide for the developers of this software system.
1.2 Document Conventions:
•HMS - Hospital Management System
•GUI - Graphical User Interface
•PHID - Patient Hospital Identification Number
1.3 Scope of the Project:
The purpose of this specification is to document requirements for a systemto manage the
hospital. The specification identifies what such a system is required to do. The specification is
written in a format conforming to the IEEE Standard 830-1984. Subject to approval, the
specification will complete the Requirements phase and will be followed by detailed design,
implementation, and testing. The product will be labeled the Hospital Management System
(HMS). The Hospital Management System will manage a waiting list of patients requiring
different treatment. The availability of beds will is determined and if beds are available the next
appropriate patient on the list will be notified. Nurses will be allocated to wards depending on
ward sizes, what type of nursing is needed, operating schedules, etc.The current manual
method of managing patients, nurses, and beds is time consuming and error prone. It is also
difficult to manage the large paper flow involved in this process. The Hospital Management
System will allow hospital administrative staff to access relevant information efficiently and
effectively. The goal of HMS is to manage nurses, patients, beds, and patient medical
information in an efficient cost-effective manner. All of these sub-systems (managing nurses,
beds, patient medical information) need to be designed and implemented so that HMS can run
effectively.
1.4 Reference:

14
• Austin, C.J. (1983). Information Systems for Hospital Administration. Health Administration
Press.
• Dean, R. (1996). The Healthcare Information Systems Directory.
• Rowland, H.S. (1984). Hospital Administration Handbook. Aspen Publishing.
• Rowland, H.S., Rowland, B.L. (1992). Manual of Hospital Administration. Aspen Publishing
2. Overall Description:
2.1 Product Perspective:
The HMS is designed to help the hospital administrator to handle patient, nurse and bed
information. The current design goal is to build an internal systemto achieve the functionality
outlined in this specification.
2.2 Product Functions:
The HMS will allow the user to manage information about patients, nurses, and beds. Patient
management will include the checking-in and checking-out of patients to and from the hospital.
The HMS will also support the automatic backup and protection of data.
2.3 Operating Environment:
Following are the requirements for running the software successfully-
• Processor – Pentium III or Higher.
• Ram– 512 MB or Higher.
• Disk Space – 10 GB or Higher.
• OS – Windows XP or Above.
2.4 Design & Implementation Constraint:
• GUI only in English.
• Login and password is used for identification of user and there is no facility for guest.
2.5 Assumption & Dependencies:
• It is assumed that one hundred compatible computers will be available before the systemis
installed and tested.
• It is assumed that Hospital will have enough trained staff to take care of the system
.
3. External Interface Requirements:
3.1 User Interface:

15
Input from the user will be via keyboard input and mouse point and click. The user will navigate
through the software by clicking on icons and links. The icons will give appropriate responses to
the given input.
3.2 Hardware Interface:
These are the minimum hardware interfaces-
• Processor – Pentium III or Higher.
• Ram– 512 MB or Higher.
• Disk Space – 10 GB or Higher
3.2 Software Interface:
These are the minimum software interfaces-
• Technologies: C# .Net 2.0
• Database: SQL server (standard edition).
• Operating system: Windows XP or above
4. System Features:
4.1 System Features:
• Work Scheduling – assigning nurses to doctors and doctors to patients
• Admissions - Admitting patients, assigning the patients to appropriate wards
• Patient Care - Monitoring patients while they are in the hospital
• Surgery Management - Planning and organizing the work that surgeons and nurses
performing the operating rooms
• Ward Management - Planning and coordinating the management of wards and rooms
• Waiting list: Monitoring to see if there are any patients waiting for available beds, assigning
them to doctors and beds once these become available.
5. Other Non-functionalRequirements:
5.1 Performance Requirements:
The performance of our software is at its best when the following are regularly done:
• Password Management
• Regular Database Archiving
• Virus Protection
5.2 Safety Requirements:

16
Humans are error-prone, but the negative effects of common errors should be limited e.g. users
should realize that a given command will delete data, and be asked to confirm their intent or
have the option to undo.
5.3 Security Requirements:
Each member is required to enter an individual Username & password when accessing the
software. Administrators have the option of increasing the level of password security their
members must use. The data in the database is secured through multiple layers of Protection.
One of those security layers involves member passwords. For maximum-security of your
software, each member must protect their password.
5.4 Software Quality Attributes:
The Quality of the systemis maintained in such a way so that it can be very user-friendly. The
software quality attributes are assumed as under:
• Accurate and hence reliable.
• Secured.
• Fast Speed.
• Compatibility.

17
PRACTICAL 4
AIM: Design Activity diagram for Hospital Management System.
DIAGRAM OF Activity diagram:

18
PRACTICAL 5
AIM: Design Use Case diagramfor Hospital Management System.
DIAGRAM OF Use Case diagram:

19
PRACTICAL 6
AIM: Design Data Dictionary for Online Admission System.
Faculty Details
Name Type Size Description
F_ID Integer 30 Faculty ID
F_Name Varchar 2 100 Faculty Name
F_Add Varchar 2 150 Address of Faculty
F_Mo Integer 50 Mobile NO of Faculty
F_Qua autonum 30 Faculty Qualification
AdminDetails
NAME TYPE Size DESCRIPTION
A_ID Integer 100 Admin ID
A_Name Varchar2 50 Admin Name
A_Address Varchar2 150 Admin Address
A_Mobile Integer 90 Mobile NO of Admin
A_Gender Varchar2 30 Admin Gender
A_depa Varchar2 50 Admin of Department
Student Details
NAME TYPE Size DESCRIPTION
S_ID Integer 100 Student ID
S_Name Varchar2 50 Student Name
S_Address Varchar2 150 Student Address
S_Mobile Integer 90 Mobile NO of Student
S_Gender Varchar2 30 Student Gender
S_depa Varchar2 50 Student of Department

20
PRACTICAL 7
AIM: Design ER diagram for Online Admission System.
ER Diagram of Online Admission System:

21
PRACTICAL-8
AIM: Design Data Flow Diagram for Online Admission System.
PRIMITIVE SYMBOLES
Process
Transform of incoming data flow(s) to outgoing flow(s).
Dataflow
Movement of data in the system.
Data Store
Data repositories for data that are not moving.It may be as
simpale as a buffer or a queue or as sophisticated as a relational
database.
External Entity
Sources of destinations outside the specified system boundary.

22
0 level data flow diagram

23
1 Level Data Flow Diagram
***********************

Final boss

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Final boss

Similar to Final boss (20)

Recently uploaded

Recently uploaded (20)

Final boss