PSG COLLEGE OF TECHNOLOGY

(Autonomous Institution)
COIMBATORE – 641
004

DEPARTMENT OFCOMPUTER SCIENCE AND ENGINEERING

MASTER OF ENGINEERING

Branch: COMPUTER SCIENCE AND ENGINEERING

MAY 2023

Name of the Student: Madhumitha N H

Roll No.: 22MZ02

Course code: 21ZC62

Course Name: Application Development Laboratory

 ME COMPUTER SCIENCE & ENGINEERING
18ZC53 - SOFTWARE DEVELOPMENT
LABORATORY

INDEX

Faculty
Sno Date Exercise Page Marks
No Sign

1 16-02-2023 Identification of Real time Problem 1

2 23-02-2023 Related study for the identified problem 2

3 02-03-2023 Selection of Process Model 4

4 09-03-2023 Software Requirement Specification 5

5 06-04-2023 Post lab Questions on Project Planning 18

and Management and SRS

6 13-04-2023 Use case document 26

7 20-04-2023 Software Architecture Document 35

8 27-05-2023 Post lab Questions on System Design 45

9 04-05-2023 Implementation of the Hospital 51

Management System

10 18-05-2023 Test Plan document 52

11 18-05-2023 Post lab Questions on Software Testing 66

& Maintenance

12 18-05-2023 Patent search for concept selection 75

 S.No: 1 IDENTIFICATION OF REAL TIME PROBLEM

Date: 16-02-2023
HOSPITAL MANAGEMENT SYSTEM

It is very important to maintain efficient software to handle all the information of a

Hospital. There are lot of information required to maintain in a hospital like patient details, doctor
details, supporting staff like nurse, receptionist etc.. All the summary of the patients should be
maintained securely. All the salary status of the doctor should be updated in the database properly.

This project is aimed to automate the hospital management system. The purpose of the project
entitled as HOSPITAL MANAGEMENT SYSTEM is to computerize the Front Office Management of
Hospital to develop software which is user friendly, simple, fast, and cost –effective. It deals with the
collection of patient’s information, diagnosis details, etc. Traditionally, it was done manually. The
main function of the system is to register and store patient details and doctor details and retrieve these
details as and when required, and also to manipulate these details meaningfully. The database stores the
all the details. Patient can book the appointment via their dashboard. This replaces the traditional process
of visiting the hospital and waiting for their turn. This also reduces the waiting time of the patient in the
hospital, since the token is generated in the system, based on the token number they can visit the
hospital.

1
 S.No: 2 RELATED STUDY ON HOSPITAL MANAGEMENT SYSTEM
Date: 23-02-2023

LITERATURE SURVEY

The paper titled "E-Hospital Management & Hospital Information Systems-Changing Trends" by
Balaraman and Kosalram, published in the International Journal of Information Engineering & Electronic
Business in 2013, explores the evolving trends in e-hospital management and hospital information systems. The
authors address the increasing need for efficient management and information systems in hospitals to cope with
the growing complexities of healthcare delivery. They highlight the importance of integrating technology and
information systems to streamline hospital operations, enhance patient care, and improve overall efficiency.
The paper discusses the key components and functionalities of hospital information systems. It emphasizes the
utilization of electronic health records (EHRs) for maintaining comprehensive patient data and facilitating
seamless information exchange between different healthcare providers. The authors also delve into the benefits
of using e-hospital management systems, such as reduced paperwork, improved data accuracy, and enhanced
decision-making capabilities. Furthermore, the authors discuss the changing trends in e-hospital management
and information systems. They explore the adoption of cloud computing and mobile technologies in healthcare,
which allow for remote access to patient information and enable real-time communication and collaboration
among healthcare professionals. The paper also addresses the challenges associated with implementing and
integrating e-hospital management systems. It emphasizes the importance of strong leadership, adequate
training, and change management strategies to ensure successful adoption and utilization of these systems. In
summary, the paper highlights the significance of e-hospital management and hospital information systems in
the modern healthcare landscape. It discusses the functionalities of these systems, such as electronic health
records and improved decision-making capabilities. The authors also explore the changing trends in the field,
including the adoption of cloud computing and mobile technologies. Finally, the paper addresses the challenges
associated with implementing these systems and emphasizes the need for proper leadership and change
management strategies.
The paper titled "Intelligent Hospital Management System (IHMS)" by Koyuncu B and
Koyuncu H, presents an innovative approach to hospital management utilizing intelligent systems. The research
was presented at the 2015 International Conference on Computational Intelligence and Communication
Networks (CICN). The authors introduce the Intelligent Hospital Management System (IHMS) as a solution to
address the complexities and challenges faced by hospitals in managing patient care, resources, and operations.
The IHMS aims to enhance efficiency, accuracy, and overall quality of healthcare services through the
integration of intelligent technologies. The paper highlights the key features and functionalities of the IHMS. It
emphasizes the importance of intelligent decision-making processes to improve patient flow, resource
allocation, and scheduling within the hospital. The authors propose the utilization of data mining techniques to
analyze patient data and generate valuable insights for better decision-making. Furthermore, the IHMS
incorporates an intelligent monitoring system to track the real-time status of patients, medical equipment, and
resources. This allows for proactive management, early detection of potential issues, and prompt intervention.
The system also includes a communication module to facilitate effective information exchange among
healthcare providers and support seamless coordination. The authors discuss the implementation challenges and
potential benefits of the IHMS. They emphasize the significance of collaboration between healthcare
professionals, administrators, and IT experts to ensure successful adoption and integration of the system. The
paper concludes with a discussion on future directions for research and development in the field of intelligent
hospital management systems. In summary, the paper presents the Intelligent Hospital Management System
(IHMS) as an innovative solution to improve the efficiency and quality of healthcare services. It introduces key
features such as intelligent decision-

2
making, data mining, real-time monitoring, and communication modules. The authors highlight the potential
benefits of the IHMS and emphasize the need for collaboration in its implementation.
The paper titled "A New Costing Model in Hospital Management: Time-Driven Activity-Based Costing
System" by Öker and Özyapıcı, published in 2013 in The Health Care Manager journal, presents a novel
approach to costing in hospital management using the Time-Driven Activity-Based Costing (TDABC) system.
The authors address the limitations of traditional costing systems in hospitals and propose TDABC as an
alternative method. TDABC focuses on the measurement and management of costs based on the time required
to perform activities rather than relying solely on allocation rules and cost drivers. The paper discusses the key
concepts and components of TDABC, including time equations, resource capacity costs, and cost per time unit.
The authors emphasize the importance of accurately identifying and measuring the resources consumed by each
activity in a healthcare process. The authors present a case study where they implement the TDABC model in a
Turkish hospital to calculate the costs of providing appendectomy services. They compare the results obtained
from TDABC with those from the hospital's existing costing system, highlighting the advantages of TDABC in
providing more accurate and transparent cost information. Furthermore, the paper discusses the potential
benefits and challenges of implementing TDABC in hospital management. It emphasizes the improved
accuracy and transparency of cost data, enabling informed decision-making regarding resource allocation,
process improvement, and pricing strategies. The authors conclude by highlighting the significance of TDABC
as a practical and effective costing model in hospital management. They suggest that TDABC can contribute to
better financial management and resource utilization in healthcare organizations. In summary, the paper
introduces the Time-Driven Activity-Based Costing (TDABC) system as a new costing model in hospital
management. It discusses the key concepts and components of TDABC and presents a case study
demonstrating its implementation in a Turkish hospital. The authors emphasize the advantages of TDABC in
providing accurate cost information and enabling informed decision-making. The paper concludes by
highlighting the potential benefits of TDABC in hospital management.

REFERENCES:
[1] Balaraman, P. and Kosalram, K., 2013. E-Hospital Management & Hospital Information
Systems-Changing Trends. International Journal of Information Engineering & Electronic
Business, 5(1).
[2] Koyuncu, B. and Koyuncu, H., 2015, December. Intelligent hospital management system
(IHMS). In 2015 International Conference on Computational Intelligence and
Communication Networks (CICN) (pp. 1602-1604). IEEE.
[3] Öker, F. and Özyapici, H., 2013. A new costing model in hospital management:
time-driven activity-based costing system. The health care manager, 32(1), pp.23-
36.

3
 S.No: 3 SELECTION OF PROCESS MODEL
Date: 02-03-2023

PROBLEM STATEMENT :

Hospital Management System is a web-application developed using MEAN stack

(MONGO,EXPRESS JS,ANGULAR,NODE JS). This system aims in creating a web application that helps
hospital to manage patient records in efficient manner. The application has an user friendly interface that
helps patient to easily navigate across various pages in the application.

PROCESS MODEL SELECTION :

WATERFALL MODEL

Appropriate Model:

Waterfall Model:
Waterfall model is suitable to develop this type of project since all the requirements and functionality
are clearly defined. Waterfall model is best suited for small application development. Since it is small project
it is better to go with waterfall model.

Inappropriate Model:

Incremental Model:
Incremental model is not used as we know the prior requirements of our projects and moreover
incremental model is mostly used in case of customers quickly need to see the working model. Here in this
case no iterative increments are going to be developed. So incremental model is not chosen.

Prototype Model:
Prototype model is used when the requirements are unclear and it is mostly used to verify the results
at the end of an iteration . Since our project is a mini project and our modules are well defined I have chosen
waterfall model over prototype model.

Spiral Model:
Spiral model is mostly used in case of high risk application and when we need to design a high
budget application within a short span of time. Since we are developing a small application waterfall model
is more recommended over spiral model.

4
S.No: 4 SOFTWARE REQUIREMENT SPECIFICATION
Date: 09-03-2023

Software Requirements
Specification
for

Hospital Management System

Version 1.0 approved

5
1. Introduction
The problem statement is to create an application for Hospital Management System using MEAN Stack.
This application will be helpful in booking the appointment. This application gives an overview about
existing departments in the hospital, contact information, gallery page etc... The application features a user-
friendly interface that allows users to easily navigate through the various sections of the app.

1.1 Purpose
The purpose of the Software Requirements Specification document is to develop a desktop application on
hospital management application. It also defines and describes both the functional and non-functional
requirements including the interfaces, operations, performance, efficiency and accuracy. It also describes the
general guidelines, design constraints and other factors necessary to provide complete and clear description
of the requirements which are to be followed while designing the application. It also outlines the complete
requirements for the system.

1.2 Document Conventions

The font followed in the entire SRS document is Times New Roman of font size 14 for sub- headings and
Times New Roman of font size 12 for description of each sub-headings or titles. ThisSRS document
specifies different requirements which are connected to one another and has their own priority.

1.3 Intended Audience and Reading Suggestions

The main intended audience are the people. The general intended users are developers, data analyst,
product managers, marketing staff, database management users and testers. This type of application is
intended for the audience of large hospitals where so much of data produced in the hospital for patients are
maintained. The data collected has stored in different types of database management system and some of
the data may have similar attribute or it can may also have similar values. This documentation can be
helpful for the analyst, designers, developers, QA team, testers, users, department heads and
documentation writers. The rest of the document contains overview, systemfeatures, functional
requirements and non- functional requirements of the system.

6
 Sequence for reading the document for specific users are:

 Analyst - Functional requirements

 Designers - Functional and non-functional requirements and product functions
and designconstraints.
 Developers - View the Software Requirement Specification for clarity of
the functionalitiesif the Software Design Specification is not clear.
 QA team - Creates the test plan from the functional and nonfunctional
requirementsspecified in SRS.
 Testers - Purpose, assumptions and dependencies, functional
requirements, constraints, non-functional requirements.
 Users - Read the entire Software requirement specification.
 Documentation writers - The entire document from the beginning.

1.4 Product Scope

The main objective and benefit of this software is to develop an application for easy integration and
interpretation of data which helps in quick, efficient analysis, finding relations, objects, properties from
multiple datasets, generally two or more datasets and for retrieving information using queries.

1.5 References
The reference document used for Software requirement specification template is IEEE SRS
document Template framed by Karl E. Weigers in 1999.The version number is 1.0.

Other References for application development study are:

[4] Balaraman, P. and Kosalram, K., 2013. E-Hospital Management & Hospital Information
Systems-Changing Trends. International Journal of Information Engineering & Electronic
Business, 5(1).
[5] Koyuncu, B. and Koyuncu, H., 2015, December. Intelligent hospital management system
(IHMS). In 2015 International Conference on Computational Intelligence and Communication
Networks (CICN) (pp. 1602-1604). IEEE.
[6] Öker, F. and Özyapici, H., 2013. A new costing model in hospital management: time-
driven activity-based costing system. The health care manager, 32(1), pp.23- 36.
[7] Dunka, B., Emmanuel, E. and Oyerinde, D.O., 2018. Simplifying Web Application
Development Using-Mean Stack Technologies. International Journal of Latest Research in
Engineering and Technology (IJLRET).

7
2. Overall Description
2.1 Product Perspective
To develop a new, self-contained product. It is designed to manage hospital information such as patient information,
and provide patients with emergency contact details and book appointments with a seamless and hassle-free
experience when booking appointments for their visit to the hospital. The application features a user-friendly
interface that allows users to easily navigate through the various sections of the app. The backend of the application is
built using Node.js and Express, which provides a robust and scalable platform for handling API requests and
managing the database. The database is powered by MongoDB, which is a NoSQL database that provides high-
performance and scalability for managing large amounts of data. The frontend of the application is built using
Angular, which provides a responsive and dynamic user interface by providing front-end framework. The application
supports various features such as search for a particular department, get contact details for the hospital, booking
appointments. Users can view available slots and book appointment based on their preferences.

2.2 Product Functions

 Helps users with viewing their existing bills and paid bills and even the patient summary.
 Has separate dashboard for each users displaying the only actions they can perform in the system. Supporting
staff, Doctor and Admin all play an important role in managing the hospital system and provide service to the
patient.
 Has contact details of the hospital so that the user can contact the respective person in case of any
queries/emergency.
 Has a dedicated appointment booking function that helps the patient to book appointment

8
2.3 User Classes and Characteristics
The ultimate users are the:
User who use this application for booking appointment purposes or for viewing bills and summary. Data
source such as MongoDB etc. are used for storing the data.

2.4 Operating Environment

The Hospital Management System will be a web application and will be accessible from any device that supports a
web browser.
Hardware platform: Windows, Mac, Linux (Any operating system with the latest browser extensions)

2.5 Design and Implementation Constraints

Hardware limitations: Minimum RAM of 2 GB memory required
Tools: A computer System or a laptop with desktop application of java, editors like Notepad, Visual Studio
Code, database systems like MongoDB
Databases to be used: MongoDB
Language requirements: Typescript, JavaScript

Performance: Angular are known for their high-performance capabilities. However, to ensure optimal
performance of the website, certain design and implementation strategies must be followed.

Security: Security is an essential aspect of any web application. The Hospital Management System will be developed
with security in mind to ensure that user data is protected from unauthorized access.

Scalability: As the number of users and movies on the website grows, the application must be scalable to handle the
increased load. The website will be designed with scalability in mind.

Platform-specific constraints: Angular is a cross-platform technologies that can be used to develop web applications
that can run on various devices and platforms. However, certain platform-specific constraints must be considered,
such as the differences in screen sizes, user interfaces, and input mechanisms between desktop and mobile devices.

Availability of resources: The development of the website will depend on the availability of resources, such as
development tools, hosting services, and APIs. The availability of these resources can impact the development
timeline and the final product's quality.

Overall, the design and implementation constraints for the Hospital Management System must be taken into
consideration during the design and development process to ensure that the website is
secure, scalable and reliable.

9
2.6 User Documentation
 The tutorial regarding the usage of this application will be available for the application users for
handling the software.
 The user documentation will be available.
 The Hospital Management System will include user documentation, which will provide
users with instructions on how to use the website. The documentation will include a user
guide, frequently asked questions, and troubleshooting tips.

2.7 Assumptions and Dependencies

The development of the Movie Streaming Website assumes that users have access to a stable internet connection
and a modern web browser. The website will be dependent on Firebase Realtime Database for storing and retrieving
data

3. External Interface Requirements

3.1 User Interfaces
The user interface focuses on the usability and hence navigation bar appears in all the pages of the website. The
buttons used are from Prime NG components which appeal pleasant to the users. The color of the user interface is
according to the standards.

Error Message:
 When the user credentials are invalid then invalid username or password will be displayed as an
error message.
 If the user tries to perform actions that are not intended for them then, something went wrong error
message will be displayed.

3.2 Hardware Interfaces

For Processor, the Minimum requirement is 1.9 gigahertz (GHz) x86- or x64-bit dual core
processor with SSE2 instruction set and the Recommended requirements is 3.3 gigahertz
(GHz) or faster 64-bit dual core processor with SSE2 instruction set
● Recommended Network requirement is Bandwidth greater than 50 KBps (400 kbps) with latency
under 150 ms
● Supported Web browsers are latest publicly released versions of
o Microsoft Edge running on Windows 11, Windows 10, Windows 8.1Mozilla Firefox
runningon Windows 11, Windows 10, Windows 8.1
o Google Chrome running on Windows 11, Windows 10, Windows 8.1 and two
o latest Mac OS versions
o Apple Safari running on two latest Mac OS versions

10
● Minimum RAM of 2 GB and Recommended RAM of 4 GB or more
● Display Required is Super VGA with a resolution of 1024 x 768
● Operating System of Window XP and above can be used
● Front-end software : Angular Application
● Back-end software : MongoDB

3.3 Software Interfaces

The following are the specific software components which are to be used:
Database: MongoDB
OperatingSystem: Windows Tools: VS
Code
Libraries: Express js, Mongoose

Input:
The patient credentials are is the input given to the software and it is verified in the backend with the data
stored in MongoDB. All the hospital details act as input and it is given to the system.

Output:
On receiving the credentials, the backend processing happens and if it is valid then their respective
dashboard will be displayed and actions can be performed in the dashboard as a result of output.

3.4 Communications Interfaces

Express mongoose connection is used to create backend connection to our database and make the required CRUD
operations

11
4. System Features
The product obtained finally is the hotel booking app which is useful to make booking reservations

4.1 Admin Features

4.1.1 Description and Priority

Admin features has utmost high priority in the system. As admin deals with handling all the
activities related to managing the hospital by organizing all the patient, doctor and supporting staff
data. This is the first step of task which needs to be carried out. Stimulus/Response Sequences

 The sequence of user actions is as follows:

 The admin can add new departments for the hospital and can also add new supporting staff by
mentioning their type.
 The admin can update the salary status for the doctor.
 The username and password is sent as an mail to the respective person once admin adds a new patient
into the database.

4.1.2 Functional Requirements

REQ-1: Application should get Input user details and store it in backend
MongoDB
REQ-2: Application should provide input interface through which the admin can perform
their functionalities and send mail as response to his/her action to the respective
person.
REQ-3: Application should allow the admin to perform all the operation which is available
in the application

12
4.2 Supporting Staff Features

4.2.1 Description and Priority

Supporting staff plays an important role in managing the system. Receptionist play an important
role in adding new patient details into the existing hospital database. Nurse can add bills generated
for the patient and update the summary details of the patient which is provided by the doctor. This
feature has moderate priority.

4.2.2 Stimulus/Response Sequences

The sequence of user actions is as follows:

 The Receptionist must enter their username and password. Validation takes place for their input
with the help of backend data. Then they perform their actions such as adding new patients or if it
is biller then they update the bills of the patient. Nurse can update the summary of the patient once
they received from the doctor.

4.2.3 Functional Requirements

REQ-1 : Application should have user interface for getting the

input from the staff.
REQ-2: Application should have network connectivity access.

4.3 Patient Features

4.3.1 Description and Priority

After login into their respective dashboard the functionalities can be performed by them are
displayed. To satisfy patient needs is the foremost important for success of the hospital. So they are
at high priority. Managing their data and allowing them to leverage the system.

4.3.2 Stimulus/Response Sequences

The sequence of user actions is as follows:

The patient enters the hospital management page and view the departments available and find out the
infrastructure of the hospital by gallery page provided in the navigation bar. The existing patient can enter into
the system by providing their username and password. Validation happens in the backend and

13
 the patient enters into their dashboard and see the summary details and various bills generated for them. They
can even book appointments to the particular doctor who belongs to particular department and can select a
particular slot.

4.3.3 Functional Requirements

REQ-1: Application should have user interface for getting the patient input. REQ-
2: Application should have connected to network .

5. Other Nonfunctional Requirements

5.1 Performance Requirements
● The system should have an interface that is user friendly and easy to follow
● The system should perform crud operations without any issues

5.2 Safety Requirements

 Validate the input.
 Application should use latest version for Database management system and software tools.
 System should have an interface that produces relevant error messages.
 Use Exception handling for managing exceptions.

5.3 Security Requirements

The patient files have information or details about a person and type of treatment undergone. Hence it has to
be secured.

5.4 Software Quality Attributes

The ISO 9126 quality factors as shown in Table are functionality, reliability, usability, efficiency,
maintainability, and portability. These factors are further subdivided into sub characteristics such as
suitability, accuracy, security, and time behavior. These sub characteristics are comprehensive, that is, any
component of software quality can be described in terms of some aspects of one or more of these six factors.

Functionality Shows the existence of a set of functions and their specified properties. The functions satisfy s

14
 Reliability That capability of software which maintains its level of performance
under given conditions for a given period of time
Usability Attributes that determine the effort needed for use and the assessment
of such use by a set of users

Efficiency The relationship between the level of performance of the software

and the amount of resources used under stated conditions
Maintainability The effort needed to make specified modifications

Portability The ability of the software to be transformed from one environment

to another

The software developed for Hospital Management System using MEAN stack should possess the above
given software Quality Attributes to ensure the quality of software.

5.5 Business Rules

 The product will be a desktop application which would help the hospitals to manage their
information and organize the patients data.
 Admin can perform all the functions in the system, he can add new staffs, doctor and
update the salary status. Doctors can see their salary status and patient report.
 Patient can use the system to book appointments, see the departments available in the hospital and emergency
contact related details.

6. Other Requirements
Speed: Determine whether the software application responds quickly.
Processor usage: Amount of time processor spends for a non-idle operation should be minimized. Memory
usage: The amount of physical memory available should be sufficient enough for the process.
Disk time: Disk time of the reading and writing request.
Failure: Percentage of critical failure of the system should be less.

15
 Appendix A: Glossary
 MongoDB: open-source No-SQL database

management

SystemQA : Quality Assurance

 HTML: Hypertext Markup Language- A markup language used to create web pages

 HTTP: Hypertext Transfer Protocol- An application protocol for distributed, collaborative,

and hypermedia information systems

 HTTPS: Hypertext Transfer Protocol Secure - An extension of HTTP used for secure communication
over the Internet

 CSS: Cascading Style Sheets - A style sheet language used for describing the presentation of a
document written in HTML or XML

 SQL: Structured Query Language - A domain-specific language used in programming and designed
for managing data held in a relational database management system

 UI: User Interface - The visual elements of a website or application that a user interacts

16
Appendix B: Analysis Models
Architecture Diagram

17
S.No: 5 POST LAB QUESTIONS
Date: 06-04-2023

PROJECT PLANNING AND MANAGEMENT AND SRS

1. When you know programming, what is the need to learn software Engineering concepts?
Software engineering is a technique through which we can develop or create software for computer
systems or any other electronic devices. It is a systematic, scientific and disciplined approach to the
development, functioning, and maintenance of software.
Basically, Software engineering was introduced to address the issues of low-quality software projects.
Here, the development of the software uses the well-defined scientific principal method and
procedure.
 Handling Big Projects: A corporation must use a software engineering methodology in order to
handle large projects without any issues.
 To manage the cost: Software engineering programmers plan everything and reduce all those
things that are not required.
 To decrease time: It will save a lot of time if you are developing software using a
software engineering technique.

2. How can you gather requirements? – Explain.

Gathering requirements is a crucial phase in the software development process, where the goal is to
identify and document the needs, expectations, and constraints of a project. Effective requirements
gathering ensures that the software solution meets the stakeholders' needs and helps in delivering a
successful product. Here are some common techniques and approaches used to gather requirements:

1. Interviews: Engage in one-on-one or group discussions with stakeholders, including end-users,

clients, subject matter experts, and project sponsors.
2. Workshops: Conduct interactive workshops involving stakeholders and development team members.
3. Surveys and Questionnaires: Prepare structured questionnaires or surveys and distribute them
to relevant stakeholders.
4. Document Analysis: Review existing documents such as business plans, user manuals, process
flows, and system specifications.
5. Observations: Observe users and stakeholders in their natural environment while they perform
their tasks.
6. Prototyping: Develop quick prototypes or mockups to demonstrate certain functionalities or
user interfaces.

3. What is software scope?

Software scope refers to the boundary or extent of a software project, defining what features,
functionalities, and deliverables are included and excluded from the project. It outlines the specific
goals, objectives, and boundaries that govern the software development effort. Defining the software
scope is important as it sets clear expectations and helps manage project resources, timeframes, and
stakeholders' requirements.

The software scope typically includes the following components:

1. Functional Scope: It defines the features, capabilities, and interactions the software will provide
to its users.
2. Non-Functional Scope: It encompasses the qualities and characteristics that the software should
possess, such as performance, security, usability, reliability, scalability, and maintainability.

18
3. Data Scope: This aspect relates to the data that the software will process, store, or interact with. It
includes defining the types of data, data sources, data storage requirements, data processing, and data
security considerations.
4. User Scope: It involves identifying the target users or user groups of the software, their roles,
responsibilities, and specific needs.
5. Project Scope: It defines the specific deliverables, milestones, and constraints of the software project.

4. What is feasibility study?

A feasibility study is a preliminary assessment conducted to evaluate the practicality, viability, and
potential success of a proposed project or endeavor. It aims to determine whether the project is
technically, economically, operationally, and legally feasible. Feasibility studies are commonly
conducted before undertaking significant initiatives, such as starting a new business, launching a new
product, implementing a software system, or undertaking a construction project.

Here are the key aspects typically examined during a feasibility study:
1. Technical Feasibility: This aspect assesses whether the project can be successfully implemented
from a technical perspective.

2. Economic Feasibility: This aspect analyzes the financial viability of the project. It involves
evaluating the estimated costs, potential revenues, return on investment (ROI), payback period, and
profitability of the project.
3. Operational Feasibility: This aspect evaluates whether the proposed project aligns with the
organization's existing operations, systems, processes, and capabilities.
4. Legal and Regulatory Feasibility: This aspect examines whether the proposed project complies
with applicable laws, regulations, permits, and legal requirements.
5. Schedule Feasibility: This aspect assesses the project timeline and determines whether the project
can be completed within the desired timeframe.
The feasibility study typically involves conducting research, analyzing data, performing cost-benefit
analyses, and engaging with stakeholders. The study's findings and recommendations help decision-
makers assess the project's viability and make informed decisions on whether to proceed, modify the
project, or abandon it.
It's important to note that a feasibility study is not a guarantee of success but serves as a valuable tool
to assess the project's potential challenges, risks, and opportunities. It provides a foundation for
informed decision-making and helps mitigate risks by identifying potential issues early in the project
lifecycle.

5. What is software process or Software Development Life Cycle (SDLC)?

Software process, also known as Software Development Life Cycle (SDLC), is a framework that
outlines the steps involved in developing software from conception to delivery. The SDLC provides a
structured approach to software development, ensuring that software projects are well planned,
executed, and managed.

There are typically six phases in the Software Development Life Cycle:

1. Requirements Gathering: In this phase, the software development team works with stakeholders to
gather and document the project requirements. This involves identifying the needs, goals, and
constraints of the software project.
2. Analysis and Design: In this phase, the development team analyzes the requirements and designs
the software system's architecture, components, and modules.
3. Implementation or Coding: In this phase, the software system is developed by writing code,
creating databases, and integrating third-party libraries or frameworks.
4. Testing: In this phase, the software system is tested for functionality, performance, usability,
security, and reliability.

19
5. Deployment: In this phase, the software is deployed to a production environment or made available
for end-users to access.
6. Maintenance: In this phase, the software is maintained and updated to fix bugs, add new features,
and improve its performance and functionality.
The SDLC is a flexible and iterative process, and each phase can overlap and interact with others.
Different software development methodologies, such as Agile, Waterfall, or DevOps, may have
different SDLC phases, but the core principles of planning, development, testing, deployment, and
maintenance remain the same.
The SDLC helps software development teams to manage the software development process
systematically and efficiently, ensure high-quality software products, and reduce risks and costs
associated with software development. By following a structured SDLC process, software
development teams can ensure that software products meet stakeholders' needs, are delivered on time
and within budget, and are of high quality.

6. List and explain the phases of requirements engineering process.

The requirements engineering process involves several phases that collectively guide the successful
identification, analysis, documentation, and management of software requirements. Here are the
commonly recognized phases of the requirements engineering process:
1. Requirements Elicitation: This phase focuses on gathering requirements from stakeholders, end-
users, and other relevant sources. Various techniques such as interviews, workshops, observations,
and document analysis are employed to understand stakeholders' needs, expectations, and constraints.
2. Requirements Analysis: In this phase, the collected requirements are analyzed and refined. The
goalis to identify inconsistencies, conflicts, and missing information.
3.Requirements Documentation: Once the requirements are analyzed and refined, they are
documented in a structured manner.
4. Requirements Verification and Validation: This phase focuses on verifying and validating the
documented requirements.
5. Requirements Management: Requirements management is an ongoing process that involves
managing changes to requirements throughout the software development lifecycle. This phase
includes establishing a systematic approach for handling requirement changes, tracking the status of
requirements, and ensuring traceability between requirements and project deliverables.
6. Requirements Communication: Effective communication is critical for successful requirements
engineering.
7. Requirements Evolution: Requirements are not static and may evolve over time due to changing
business needs, technology advancements, or stakeholder feedback.

7. List the characteristics of a good SRS.

A Software Requirements Specification (SRS) document serves as a crucial artifact in software
development projects. It describes the requirements and specifications of the software system to be
developed. A good SRS possesses the following characteristics:

1. Correctness
2. Completeness
3. Consistency
4. Clarity
5. Unambiguity
6. Verifiability
7. Traceability
8. Feasibility
9. Modifiability
10.Understandability

20
8. What do you mean by risk management? Also explain the Risk Management process.
Risk management refers to the systematic process of identifying, assessing, mitigating, and
monitoring risks to minimize the negative impact they can have on a project or organization. It
involves proactive planning, analysis, and decision-making to effectively handle potential risks and
uncertainties. The risk management process typically involves the following steps:
1. Risk Identification: In this step, risks are systematically identified and documented. This includes
identifying potential threats that may impact the project objectives, as well as opportunities that can
bring benefits.
2. Risk Analysis: Once the risks are identified, they are analyzed to assess their potential impact and
likelihood of occurrence. Qualitative analysis evaluates risks based on subjective scales, such as
probability and impact ratings, while quantitative analysis involves numerical analysis, such as Monte
Carlo simulations, to provide more accurate risk assessments.
3. Risk Evaluation: The identified risks are further evaluated to determine their significance and
prioritize them based on their potential impact on project objectives.
4. Risk Mitigation: In this step, strategies are developed and implemented to reduce or eliminate the
identified risks. Mitigation measures may involve avoiding the risk, transferring the risk to a third
party, implementing controls and safeguards, or developing contingency plans.
5. Risk Monitoring and Control: Risk management is an ongoing process, and risks need to be
continuously monitored and reviewed throughout the project lifecycle.
6. Risk Documentation and Communication: Throughout the risk management process, it is crucial to
maintain comprehensive documentation of identified risks, analysis, mitigation strategies, and their
status.

9. How can you gather requirements?

Gathering requirements is a critical activity in the software development process. The following are
some commonly used techniques for gathering requirements:

1. Stakeholder Interviews: Conduct interviews with key stakeholders, such as clients, end-users,
managers, and subject matter experts.
2. Workshops and Focus Groups: Organize interactive workshops or focus groups involving
stakeholders and project team members.
3. Surveys and Questionnaires: Prepare structured surveys or questionnaires and distribute them to
relevant stakeholders.
4. Prototyping: Develop quick prototypes or mock ups to demonstrate certain functionalities or user
interfaces.
5. Observations and Job Shadowing: Observe users and stakeholders in their natural environment as
they perform their tasks.
6. Document Analysis: Review existing documents, such as business plans, process flows, user
manuals, or system specifications.
7. Use Cases and User Stories: Define specific scenarios or narratives that describe how users interact
with the software system.
8. Collaborative Prototyping: Engage stakeholders and users in collaborative prototyping sessions
where they actively participate in designing and refining the software's interface and functionality.
9. Domain Expert Consultation: Seek guidance and insights from domain experts who possess
specialized knowledge and expertise relevant to the software system's domain.
10. Continuous Feedback and Iterative Refinement: Maintain ongoing communication and
collaboration with stakeholders throughout the software development process.

10. List the different types of SDLC process models.

There are several different Software Development Life Cycle (SDLC) process models, each with its
own approach to organizing and executing the software development process. Here are some of the
commonly used SDLC process models:

21
1. Waterfall Model: The Waterfall model follows a sequential and linear approach, with distinct
phases such as requirements gathering, design, implementation, testing, deployment, and
maintenance.
2. Agile Model: Agile methodologies, including Scrum, Kanban, and Extreme Programming
(XP), prioritize flexibility, collaboration, and iterative development.
3. Spiral Model: The Spiral model combines elements of the Waterfall model and iterative development.
4. Iterative Model: The Iterative model divides the development process into smaller iterations or
cycles.
5. V-Model: The V-Model is a variation of the Waterfall model. It emphasizes the relationship
between each phase of the development process and its corresponding testing phase.
6. Rapid Application Development (RAD): RAD focuses on rapid prototyping and iterative
development.
7. Incremental Model: The Incremental model involves dividing the project into small,
manageable increments.
8. DevOps: DevOps is not a specific SDLC process model, but rather an approach that emphasizes
close collaboration between development and operations teams.

11. Prepare check list to select a best process model for the particular requirement.
When selecting the best process model for a specific project requirement, it is crucial to consider
various factors. Here is a checklist that can help in evaluating and selecting the most suitable process
model:
1. Project Characteristics:
- Is the project well-defined with clear objectives and requirements?
- Is the project large or small in scope and complexity?
- Is there a fixed deadline or time constraint?
- Are there any specific regulatory or industry compliance requirements?
2. Flexibility and Adaptability:
- Is the project likely to undergo changes in requirements during the development process?
- Does the development team and stakeholders value adaptability and responsiveness to change?
- Is the project susceptible to evolving technology or market conditions?
3. Stakeholder Collaboration:
- Are the stakeholders actively involved and available for ongoing collaboration throughout the
development process?
- Do stakeholders have a clear understanding of their requirements and expectations?
- Are stakeholders geographically distributed or located in the same vicinity?
4. Time-to-Market:
- Is there a need to deliver working software in a short timeframe?
- Are there market pressures or competitive factors that require quick iterations and frequent releases?
5. Risk Management:
- Are there significant risks associated with the project, such as technical uncertainties,
changing business conditions, or external dependencies?
- Is risk mitigation and early feedback important for the success of the project?
6. Team Experience and Expertise:
- Does the development team have prior experience with specific process models?
- Is the team comfortable with collaborative and iterative approaches?
- Are there any specific skills or expertise required for the project that align with certain process
models?
7. Resource Availability:
- What are the available resources in terms of human resources, budget, and technology infrastructure?
- Are there any limitations or constraints that may influence the choice of a process model?
8. Organizational Culture:
- Does the organization have an established culture that aligns with a specific process model, such
as agile values or a more traditional and structured approach?
- Are there any organizational norms, practices, or guidelines that need to be considered?

22
9. Documentation and Formality:
- Are there specific documentation requirements, such as extensive regulatory compliance
or contractual obligations?
- Does the project require comprehensive and detailed documentation throughout
the development process?

12. List and explain the different types of CASE tools available to develop SRS.
CASE (Computer-Aided Software Engineering) tools are software applications that assist in the
development and management of software systems. While there are various types of CASE tools
available, the focus here is on the ones commonly used for developing Software Requirements
Specifications (SRS). Here are some examples:
1. Requirements Gathering Tools
2. Diagramming Tools
3. Requirements Management Tools
4. Collaborative Tools
5. Modeling Tools
6. Traceability Tools

13. Illustrate how project planning can be done with suitable example.
Project planning is a crucial phase in the software development process that involves defining project
objectives, creating a roadmap, and establishing the necessary steps to successfully execute the
project. Let's illustrate project planning with an example of developing a mobile application.
1. Define Project Objectives:
- Identify the purpose of the mobile application, such as providing a platform for online shopping.
- Determine the target audience, such as young adults interested in fashion and lifestyle products.
- Set clear goals, such as achieving a certain number of downloads and generating a specific revenue
within a defined time frame.
2. Scope Definition:
- Determine the features and functionalities to be included in the mobile application, such as user
registration, product browsing, shopping cart, payment integration, and order tracking.
- Identify any constraints, such as compatibility with specific mobile operating systems or
integration with existing backend systems.
3. Resource Identification:
- Determine the project team members, such as project manager, developers, designers, testers,
and UI/UX specialists.
- Identify any external resources or vendors that may be required, such as graphic designers or
third- party payment gateway providers.
- Allocate the necessary budget and estimate the required resources, including time, human
resources, and equipment.
4. Task Breakdown:
- Break down the project into smaller tasks, such as requirement gathering, UI/UX design,
frontend development, backend development, testing, and deployment.
- Estimate the effort and duration for each task based on the team's expertise and available resources.
- Create a work breakdown structure (WBS) to visualize the hierarchy of tasks and their dependencies.
5. Timeline Creation:
- Develop a project schedule by assigning start and end dates to each task, considering their
dependencies and resource availability.
- Use project management tools like Gantt charts or project scheduling software to create a
timeline that shows the project's duration and critical milestones.
6. Risk Identification and Mitigation:
- Identify potential risks and uncertainties that may affect the project, such as technical
challenges, resource constraints, or changes in market conditions.
- Develop strategies to mitigate and manage those risks, such as having backup resources,

23
implementing a robust testing process, or regularly monitoring market trends.
7. Communication and Collaboration:
- Establish clear communication channels among team members and stakeholders, such as
regular project meetings, progress reports, and collaboration tools.
- Define roles and responsibilities for each team member, ensuring everyone understands their
tasks and expectations.
- Encourage open and transparent communication to address any issues or concerns promptly.
8. Documentation:
- Create and maintain project documentation, including the project plan, requirements
specifications, design documents, and test plans.
- Keep track of changes and updates throughout the project to ensure documentation accuracy.
9. Monitoring and Control:
- Regularly monitor the project's progress against the established timeline and milestones.
- Track and control project risks, changes in scope, and resource utilization.
- Take corrective actions when necessary, such as reassigning tasks, adjusting timelines, or
revising requirements.
10. Review and Evaluation:
- Conduct regular reviews and evaluations to assess the project's performance, adherence
to objectives, and overall quality.
- Collect feedback from stakeholders, users, and the development team to identify areas
for improvement and incorporate lessons learned into future projects.

14. list the ways by which progress of a software project can be tracked
Tracking the progress of a software project is essential to ensure that it stays on schedule, meets
objectives, and remains within budget. Here are several ways to track the progress of a software
project:
1. Milestones: Define key milestones or checkpoints that mark significant achievements or
deliverables in the project. Regularly track and review the completion of these milestones to assess
progress.
2. Task Lists and To-Do Lists: Break down the project into smaller tasks and create task lists or to-do
lists. Track the completion status of individual tasks to understand the overall progress.
3. Gantt Charts: Use Gantt charts to visualize the project timeline, dependencies, and task durations.
Monitor the progress of tasks by comparing the planned schedule with the actual progress.
4. Kanban Boards: Utilize Kanban boards or agile project management tools to track the progress of
tasks in various stages, such as to-do, in-progress, and completed. Visualize the flow of work and
identify bottlenecks or delays.
5. Burn-Down Charts: In Agile methodologies, track the progress using burn-down charts. These
charts display the remaining work versus time, allowing you to assess if the project is on track to meet
the desired goals within the sprint or iteration.
6. Time Tracking: Monitor the time spent on each task or activity using time tracking tools. This
provides insights into resource utilization, helps identify potential bottlenecks, and ensures
accountability.
7. Regular Status Meetings: Conduct regular status meetings with the project team to discuss
progress, identify any issues or roadblocks, and determine necessary actions to keep the project on
track.
8. Project Dashboards: Create project dashboards that display key metrics and indicators of progress,
such as task completion rates, overall project completion percentage, budget utilization, and critical
milestones. These dashboards provide a high-level overview of project progress.
9. Agile Retrospectives: Conduct retrospectives at the end of each sprint or iteration in Agile
methodologies. Reflect on what went well, what could be improved, and what actions can be taken to
enhance the project's progress and efficiency.
10. Regular Communication and Feedback: Maintain open communication channels with
stakeholders, clients, and the project team to receive regular feedback on progress. Actively address
any concerns or issues raised and incorporate feedback into the project plan.
11. Quality Assurance and Testing: Track the progress of quality assurance activities, such as testing
24
and bug fixing. Monitor the number of defects found, their severity, and the time taken to address
them

25
to gauge the overall quality of the project.
12. Documentation and Reporting: Keep comprehensive project documentation, including progress
reports, status updates, and change logs. Regularly update these documents to reflect the current
project status and progress.

26
S.No: 6 USE CASE DOCUMENT
Date: 13-04-2023

Use Cases
for

Hospital Management System

Version 1.0 approved

27
1. Use Case Identification

1.1. Use Case ID

Give each use case a unique numeric identifier, in hierarchical form: X.Y. Related use cases can be
groupedin the hierarchy. Functional requirements can be traced back to a labeled use case.
The use case id for patient registration the use case is UC 1.0 while the use case id of patient performing
desired actions is the use case id 2.0 and the use case id of booking appointment for their visit is the use
case diagram is UC 3.0.

1.2. Use Case Name

The name of the use cases are:
 UC 1.0 : Patient Registration
 UC 2.0 : View Summary
 UC 3.0 : Booking appointment.

1.3. Use Case History

1.3.1 Created By
The name of the person who initially documented this use case is Madhumitha N H

1.3.2 Date Created

The use case was initially documented in 10.04.2023.

1.3.3 Last Updated By

The most recent update to the use case description is done by Madhumitha N H.

1.3.4 Date Last Updated

The use case was initially documented in 10.04.2023.

2. Use Case Definition

2.1. Actor
An actor is a person or other entity external to the software system being specified who interacts with the
system and performs use cases to accomplish tasks. Different actors often correspond to different user
classes, or roles, identified from the customer community that will use the product.

28
The actor who will be performing this use case is user or a patient who try to view bills and summary and admin who
takes effort in managing the hospital record.

2.2. Description

Patient Registration: This use case involves a patient to login only when a receptionist adds a new
patient into the dataset, providing their username and password in email. The outcome would be a new
user account created in the database.
View Summary: This use case involves viewing summary details of a patient in their dashboard.
Appointment Booking: This use case involves a patient to search for the available slots and book
the appointment by making preferences for the doctor. Then the patient books an appointment based on
his/her preference A confirmation message will be popped up to the user which states the status of the
booking appointment.

2.3. Preconditions
The preconditions are the list any activities that must take place, or any conditions that must be true,
before the use case can be started. Each precondition is numbered. The appropriate precondition for the
project are:
1. UC 1.0: User has access to the website.
2. UC 2.0: User is logged in to the website
3. UC 3.0: User is logged in to the website

2.4. Postconditions
Post conditions describes the state of the system at the conclusion of the use case execution.
Eachpostcondition is numbered. The appropriate post conditions for the project are:
 UC 1.0 : User is registered and can log in to their dashboard.
 UC 2.0: User is logged in and can access their personal information such as summary details.
 UC 3.0 : The user can make bookings based on his/her preferences for the slot.

29
 2.5. Priority
Indicate the relative priority of implementing the functionality required to allow this use case to be
executed.The priority scheme used must be the same as that used in the software requirements
specification.
Here, in this case high priority has to be given for all activities such as handling the patient details and
allowing the patient to perform booking activities. The medium priority has to be given for salary status
of the doctor.

2.6. Frequency of Use

Estimate the number of times this use case will be performed by the actors per some appropriate unit of
time.
If a patient is registered, then he/she may use the use case frequently for around 5 times a day.

2.7. Normal Course of Events

Provide a detailed description of the user actions and system responses that will take place during
executionof the use case under normal, expected conditions. This dialog sequence will ultimately lead to
accomplishing the goal stated in the use case name and description. This description may be written as an
answer to the hypothetical question, “How do I <accomplish the task stated in the use case name>?” This
is best done as a numbered list of actions performed by the actor, alternating with responses provided by
the system.
The normal course of events for user registration use case are:
1. Receptionist navigates to the registration page.
2. Then he/she enters their personal information, including name, age, sex, contact details,
address, email address, and password.
3. User clicks on the "Add patient" button.
4. System verifies the user's information and creates a new account and indicate it by popping
up successful.
5. System sends username and password message to the user via email.
The normal course of events for view bills and summary use case are:
1. User navigates to the login page.
2. User enters their email address and password.
3. User clicks on the "Login" button.
4. System verifies the user's information and logs them in with the help of data stored
in MongoDB.
5. System validates and displays dashboard with view summary option. When ‘view summary’
button is clicked it displays the summary for the patient.
The normal course of events for booking appointments are:
1. User navigates to the book appointment option.
2. User enters their preferences by selecting the doctor and slot according to their preferences.
3. User clicks on the "Confirm Booking" button.
4. System displays the status using Angular toast.

30
2.8. Alternative Courses
Document other, legitimate usage scenarios that can take place within this use case separately in this
section.State the alternative course, and describe any differences in the sequence of steps that take place.

UC 1.A.C.1.1 – Receptionist enters invalid information. The system displays an error message and
prompts the user to correct the information regarding age, email address and phone number.
UC 1.A.C.1.2 - User attempts to register with an email address that is already in use. The system displays an
error message and prompts the user to choose a different email address.
UC 2.A.C.2.1 - User enters an invalid email address or password. The system displays an error message
and prompts the user to try again.
UC 3.A.C.3.1 - User tries to make booking for appointment with doctor who is on leave then the angular
toast displays error message.
UC 3.A.C.3.2 - User booking for the appointment with doctor request is unsuccessful then error
message is displayed and prompts please try again.

2.9. Exceptions
Describe any anticipated error conditions that could occur during execution of the use case, and define
howthe system is to respond to those conditions. Also, describe how the system is to respond if the use
case execution fails for some unanticipated reason.

2.10. Includes
List any other use cases that are included (“called”) by this use case. Common functionality that appears
inmultiple use cases can be split out into a separate use case that is included by the ones that need that
commonfunctionality. In case of our project ,
EX 1 If database access error or other database errors, then MongoDB exception has to be thrown EX 2 If user

enters improper action, then IO exception has to be thrown

2.11. Special Requirements

Nonfunctional requirements are:
Integrity - Data should have overall accuracy, completeness, and
consistency. Efficiency - Query process should correctly use memory within the
stipulated time.Correctness - The retrieved data should have completeness.
Reliability - System should accurately retrieve the data from the data source.

31
2.12. Assumptions
In our project, the assumption can be considered as
 Receptionist are able to provide valid and accurate information during the registration process.
 Users will be able to use the website's login functionality to login into their
dashboard successfully.
 Users will be able to select options displayed such as view bills, view summary.
 Users will have the necessary hardware and software to book appointments on the website.
 Users will be able to access the website and its features without any technical difficulties or errors.
 The website will provide appropriate error messages to users in case of any unexpected issues
or errors

2.13. Notes and Issues

The use case diagrams of the system for use cases are shown below. Use Case
Diagram:

32
 Use Case Template

Use Case ID: 1.0

Use Case Patient Registration
Name:
Created By: Madhumitha N H Last Updated By: Madhumitha N H
Date Created: April 10, 2023 Date Last April 10, 2023
Updated:

Actor: Receptionist
Description: The receptionist add new patient into the hospital database
by providing relevant information about the user.

Preconditions:  User is logged in to the website

Postconditions:  User is registered and can log in to their dashboard.

Priority: Moderate
Frequency of Use: Need to be generated for all the patients who visit the hospital.

Normal Course of  Receptionist navigates to the registration page.

Events:  Then he/she enters their personal information,
including name, age, sex, contact details, address,
email address, and password.
 User clicks on the "Add patient" button.
 System verifies the user's information and creates a
new account and indicate it by popping up successful.
 System sends username and password message to
the user via email.
Alternative Courses:  Receptionist enters invalid information. The system
displays an error message and prompts the user to correct
the information regarding age, email address and phone
number.
 User attempts to register with an email address that is
already in use. The system displays an error message
and
prompts the user to choose a different email address.
Exceptions:  If database access error or other database errors,
then MongoDB exception has to be thrown
Includes:
Special Requirements:
Assumptions:  Receptionist are able to provide valid and
accurate information during the registration process.

Notes and Issues:

33
 Use Case Template
Use Case ID: 2.0
Use Case View Summary
Name:
Created By: Madhumitha N H Last Updated By: Madhumitha N H
Date Created: April 10th 2023 Date Last April 10th 2023
Updated:

Actor: End User

Description: This use case involves viewing summary details of a patient in
their dashboard.

Preconditions:  The user account should exist and the user should
be logged in
Postconditions:
 User is logged in and can access their personal
information such as bill details and summary details.

Priority: High
Frequency of Use: Any number of times

Normal Course of  User navigates to the login page.

Events:  User enters their email address and password.
 User clicks on the "Login" button.
 System verifies the user's information and logs them in with
the help of data stored in MongoDB.
 System validates and displays dashboard with view bills
and summary option. When ‘view summary’ button is
clicked it displays the summary for the patient.
Alternative Courses:  User enters an invalid email address or password.
The system displays an error message and prompts the user
to try again.
Exceptions:  If database access error or other database errors, then
Database exception has to be thrown
 If user enters improper action I/O exception is
thrown.
Includes:
Special Requirements:
Assumptions:  Users will be able to use the website's
login functionality to login into their
dashboard successfully.
 Users will be able to select options displayed such as
view summary.

Notes and Issues:

34
 Use Case Template
Use Case ID: 3.0
Use Case Booking Appointment
Name:
Created By: Madhumitha N H Last Updated By: Madhumitha N H
Date Created: April 10th 2023 Date Last Updated: April 10th 2023

Actor: End User

Description: This use case involves a patient to search for the available slots and boo
the appointment by making preferences for the doctor. Then the patien
books an appointment based on his/her preference A confirmation
messag will be popped up to the user which states the status of the
bookin appointment.

Preconditions:  The user logged into the website.

Postconditions:  The user can make bookings based on his/her preference
with doctor and slot.
Priority: High
Frequency of Use: Any number of times

Normal Course of Events:  User navigates to the book appointment option.

 User enters their preferences by selecting the doctor and slot
according to their preferences.
 User clicks on the "Confirm Booking" button.
 System displays the status using Angular toast.

Alternative Courses:  User tries to make booking for appointment with doctor who is on
leave then the angular toast displays error message.
 User booking for the appointment with doctor request is
unsuccessful then error message is displayed and
prompts please try again
Exceptions:  If database access error or other database errors,
then Database exception has to be thrown
 If user enters improper action I/O exception is thrown.

Includes:
Special Requirements:
Assumptions:  Users will have the necessary hardware and software to
book appointments on the website.
 Users will be able to access the website and its
features without any technical difficulties or errors.
 The website will provide appropriate error messages to
users in case of any unexpected issues or errors

Notes and Issues:

35
S.No: 7 SOFTWARE ARCHITECHTURE DOCUMENT
Date: 20-04-2023

Software Architecture Document

Hospital Management System

using MEAN Stack

Version 1

36
1 Introduction

This document is about “Hospital Management System using MEAN stack. It illustrates
what can be the content of a Software Architecture Document (SAD) produced during the
Elaboration phase.
A Software Architect will typically perform height major steps in order to define a global
architecture,and each time an activity is completed, a specific section of the SAD is enriched
accordingly.

Architectural activities Software Architecture Document

Step 1 - Identify and prioritize significant Use- Cases Section 4

Step 2 - Define the candidate architecture Section 3,5,7,8

Step 3 - Define the initial Deployment Model Section 7
Step 4 - Identify key abstractions Section 8
Step 5 - Create an Analysis Model Section 4,5
Step 6 - Create the Design Model Section 4
Step 7 - Document concurrency mechanisms Section 6, 7
Step 8 - Create the Implementation Model Section 8

1.1 Purpose
The Software Architecture Document (SAD) provides a comprehensive architectural overview of
Hospital Management System using MEAN stack 1.0. It presents a number of different architectural
views to depict different aspects of the system. It is intended to capture and convey the significant
architectural decisions which have been made on the system.

In order to depict the software as accurately as possible, the structure of this document is based
on the “4+1” model view of architecture [KRU41] .

The “4+1” View Model allows various stakeholders to find what they need in the software
architecture

37
1.2 Scope

The scope of this SAD is to depict the architecture of the Hospital Management
System using MEAN stack.

1.3 Definitions, Acronyms and Abbreviations

UML: Unified Modeling Language
SAD: Software Architecture Document

1.4 References

[KRU41]: The “4+1” view model of software architecture, Philippe Kruchten,

November1995,
http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepaper s
/2003/Pbk4p1.pdf

[RSA]: IBM Rational Software Architect

http://www-
306.ibm.com/software/awdtools/architect/swarchitect/index.html

[RUP]: The IBM Rational Unified Process

http://www306.ibm.com/software/awdtools/rup/index.html

1.5 Overview
In order to fully document all the aspects of the architecture, the Software
ArchitectureDocument contains the following subsections.
Section 2: Describes the use of each view
Section 3: Describes the architectural constraints of the system
Section 4: Describes the most important use-case realization. Will contain the Analysis Modeland
the Design Model
Section 5: Describes design’s concurrency
aspectsSection 6: describes design’s
concurrency aspects
Section 7: Describes how the system will be deployed. Will contain the
Deployment ModelSection 8: Describes the implementation view of the application
Section 9: Describes any significant persistent element. Will contain the
Data ModelSection 10: Describes any performance issues and constraints Section
11: Describes any aspects related to the quality of service (QoS) attributes

38
 2 Architectural Representation

This document details the architecture using the views defined in the “4+1” model [KRU41],
but using the RUP naming convention. The views used to document the Hospital Management
System using MEAN stack are:

Logical view
Audience:
Designers.
Area: Functional Requirements: describes the design's object model. Also describes the most
importantuse-case realizations.
Related Artifacts: Design model

Process view
Audience:
Integrators.
Area: Non-functional requirements: describes the design's concurrency and synchronization aspects.
Related Artifacts: (no specific artifact).

Implementation view
Audience:
Programmers.
Area: Software components: describes the layers and subsystems of the application.
Related Artifacts: Implementation model, components

Deployment view
Audience: Deployment managers.
Area: Topology: describes the mapping of the software onto the hardware and shows the system'sdistributed
aspects.
Related Artifacts: Deployment model.

Use Case view

Audience: all the stakeholders of the system, including the end-users.
Area: describes the set of scenarios and/or use cases that represent some significant, centralfunctionality of
the system.
Related Artifacts : Use-Case Model, Use-Case documents

Data view (optional)

Audience: Data specialists, Database administrators
Area: Persistence: describes the architecturally significant persistent elements in the data model
Related Artifacts: Data model.

3 Architectural Goals and Constraints

This section describes the software requirements and objectives that have some significant
impacton the architecture

3.1 Technical Platform

The Hospital Management System using MEAN stack application will be deployed onto a

39
web application with the help of angular.
3.2 Security
The input and output files have information or details about a patient or the hospital.
Hence it hasto be encrypted using an Encryption Algorithm.
3.3 Persistence
Data persistence will be addressed using a non-relational database Mongo DB.

3.4 Reliability/Availability (failover)

The availability of the system is a key requirement by nature. The candidate architecture must
ensure failover capabilities.

3.5 Performance
The entire process of managing the hospital and patient details has to take place without error and halting.

4 Use-Case View
This section lists use cases or scenarios from the use-case model if they represent some significant,
central functionality of the final system. The use-cases present are patient dashboard and doctor side.

4.1 Booking Appointment and view summary

This use-case of booking appointment has the following steps. Initially, login page appears.
Patients login into their dashboard and the book appointment button plays a major role in booking the
appointment. The preferred slot can be selected and then then the doctor can also be selected. A
dropdown button displays the available slots and doctor. Then the appointment can be booked. A
token number will be generated for the patients. According to the number the patient can visit the
hospital. This avoids the waiting time of the patient. The appointment booking details will be stored in the
collection. Next the patient can view the summary based on the report uploaded by the nurse. The patients can
downloadthe summaryreport in pdf format.

40
4.2 View Salary status
This use case has the following steps starting from login to their dashboard. Once the doctor
logins into their dashboard they can see their personal details and can view the salary status which
will be updated by the admin. The doctor can view the patient’s summary details.

41
5 Sequence Diagram

6 Process View
There are many processes to be completed. It includes adding the doctor, supporting staff,
sending mail to their respective id with password. Then updating the salary status in admin side;
in patient side there are booking appointments, view personal details and summary by
downloading them;in receptionist side patients can be added; in nurse side the summary can be
uploaded and in doctor side the patient summary details can be displayed and can view their own
personal and salary status details.

42
7 Deployment Diagram

8 Implementation View

43
9 Data View

10 Size and Performance

Size:
The data involved consist of patient and hospital data. These datasets are generated real time. The
size of the dataset increases as the demand increases in the real-time.

Performance:
Patient Dashboard:
The patient has to login to their dashboard. The list of functions that can be performed by the patients
will be displayed. They can view their personal details, view the summary by downloading the file in
pdf format. The appointments can booked on that particular day by selecting the available slot and
selecting the doctor. A token number will be generated. This can reduce the patient waiting time as
they can come according to the token number. This can be done with the help of angular toast. All
the summary, personal and appointment details will be stored in the database.

Admin Dashboard:
The admin can perform various functions by login into their dashboard. The function includes
adding supporting staff such as nurse, receptionist and adding doctor. Mail will be sent to the
respective id with the password with the help of nodemailer functionality. This requires time for
connecting with database servers, retrieving information and processing this information.

44
11 Quality
The following quality goals has to be satisfied in this Hospital Management application:

Scalability
System’s reaction when patient demands increase
Reliability
Giving standard results every time when the patient uses.
Availability
Should be available to patient all the time
Portability
Ability to be reused in another environment

45
S.No: 8 POST LAB
QUESTIONS Date: 27-04-2023
SOFTWARE DESIGN
1. List out all possible relationships in an UML class diagram. Tabulate the
relationshipswith columns like name of the relationship, notation and purpose.
There are six main types of relationships: inheritance , realization / implementation , composition
, aggregation , association, and dependency .

`Relationship Purpose

Inheritance In the inheritance relationship, the subclass inherits all the

functions of theparent class, and the parent class has
allthe attributes, methods, and subclasses.

Realization / In an implementation relationship, aclass

Implementation implements an interface, and methods in the class
implement all methods of the interface declaration.

Composition The relationship between the whole andthe part, but

the whole and the part cannot be separated

Aggregation Aggregation: The relationship betweenthe whole and part,

and the whole and part can be separated.

Association Indicates that a property of a class holdsa reference to an

instance (or instances)of another class .

Dependencies dependencies are reflected in methods ofa class that

use another class’s object as a parameter

46
2. What is the focus of the UML use case diagram? List out its basic components.
Use case diagrams are used to gather the requirements of a system including internal and
externalinfluences. These requirements are mostly design requirements. Hence, when a system is
analyzed to gather its functionalities, use cases are prepared and actors are identified.
Actors: The users that interact with a system. An actor can be a person, an organization, or an outside
system that interacts with your application or system. They must be external objects that produce or
consume data.

System: A specific sequence of actions and interactions between actors and the system. A systemmay
also be referred to as a scenario.

Goals: The end result of most use cases. A successful diagram should describe the activities and variants
used to reach the goal.

3. Compare and Contrast coupling and cohesion.

Cohesion Coupling

Cohesion is the measure of degree Coupling is the measure of degree of

of relationship between elements of a relationship between different modules.
module.
It is an intra module concept. It is an inter module concept.

Increased cohesion is considered to be Increased coupling has to be avoided

goodfor the software. in software.

It represents relationships within the module. It helps represent the relationships between
the modules.

It represents the functional strength of It represents the independence among the modules.
the modules.

When modules are highly cohesive, a When the modules are loosely coupled, it results
high quality software is built.
in a high quality software.

47
4. Differentiate between class diagrams and object diagrams.

Class Diagram Object Diagram

● A class diagram is a type of static ● An object diagram is also a type of static

structural diagram that describes structural diagram that shows a complete
thestructure of the system by showing the or partial view of the structure of a
classes, their attributes, methods and the modeled system at a specific time.
relationship among the classes.

● Class diagrams define classes and ● Object diagrams show the objects and
show how they relate to each other. their relationships

● Classes are the blueprints ● Objects are the instances of classes.

● In a class diagram, the class name ● In an object diagram, the object name isin
starts with uppercase. e.g., Student. lowercase, and it is underlined. e.g., s1:
Student

5. Compare coincidental cohesion and functional cohesion.

● Coincidental Cohesion: The elements are not related(unrelated). The elements have no
conceptual relationship other than location in source code. It is accidental and the worst form
of cohesion. Ex- print the next line and reverse the characters of a string in a
singlecomponent.

● Functional Cohesion: This type of cohesion occurs when all elements or tasks in a
modulecontribute to a single well-defined function or purpose, and there is little or no coupling
between the elements. Functional cohesion is considered the most desirable type of cohesion as it
leads to more maintainable and reusable code.

48
 6. Compare and contrast the structured design approach with object-oriented designapproach.

Structured Design Object-Oriented Design

It works with top down approach It works with a Bottom-up approach.

Program is divided into a number of submodules Program is organized by having a number of

or functions. classes and objects.

Function call is used. Message passing is used.

Software reuse is not possible. Reusability is possible.

It is suitable for real time systems, embedded It is suitable for most business applications, game
systems and projects where objects are not development projects, which are expected to be
themost useful level of abstraction. customized or extended.

7. What is an interface? Give an example of its usage with a simple class diagram.
An interface is a specification of behavior that implementers agree to meet; it is a contract. By
implementing an interface, classes are guaranteed to support a required behavior, which allows
thesystem to treat non-related elements in the same way – that is, through the common interface.

49
8. Give any two differences between sequence diagrams and communication diagrams.

Communication diagram Sequence Diagram

Communication diagrams show the Sequence diagrams, on the other hand, focuson
interactions between objects or components in the time order of messages.
terms of sequenced messages.

They show the flow of messages between objects, They show the interactions between objects or
along with the object that sends and receives the components as a series of horizontal lines, withthe
message. object boxes listed at the top side-by-side.

Communication diagrams also show the Sequence diagrams also show the lifecycle of
relationships between objects, including which objects, including the creation and destructionof
objects are responsible for sending and receiving objects.
messages.

9. List and explain the major elements of Object oriented analysis and design
withappropriate examples.
There are two categories of elements in an object-oriented system

Major Elements − By major, it is meant that if a model does not have any one of these elements, it
ceases to be object oriented. The four majorelements are
● Abstraction
● Encapsulation
● Modularity
● Hierarchy

Abstraction: Abstraction means to focus on the essential features of an element or object in OOP,ignoring
its extraneous or accidental properties.

Encapsulation: Encapsulation is the process of binding both attributes and methods together withina class.

Modularity: Modularity is the process of decomposing a problem (program) into a set of modulesso as to
reduce the overall complexity of the problem.

Hierarchy: In Grady Booch’s words, “Hierarchy is the ranking or ordering of abstraction”. Through
hierarchy, a system can be made up of interrelated subsystems, which can have their ownsubsystems and
so
50
on until the smallest level components are reached. It uses the principle of “divide and conquer”.
Hierarchy allows code reusability.

10. List any three behavioral diagrams in OOAD.

UML behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a system.
The behavioral diagrams are categorized as follows: use case diagrams, state–chart diagrams, and activity
diagrams.

11. Give an example for a stereotype.

In UML models, a stereotype is a model element that identifies the purpose of other model elements. For
example, the «library» stereotype can be applied to an artifact to indicate that it is aspecific type of
artifact. the «call», «create», «instantiate», «responsibility», and «send» stereotypes can be applied to
usage relationships to indicate precisely how one model element usesthe other.

12. Differentiate structural diagrams and behavioral diagrams.

Structural diagrams Behavioral diagrams

Structure diagrams show the things in the Behavioral diagrams show what should happen
modeled system. In a more technical term, they in a system. They describe how the objects
show different objects in a system. interact with each other to create a functioning
system.

● Class Diagram ● Use Case Diagram

● Component Diagram ● Activity Diagram
● Deployment Diagram ● State Machine Diagram
● Object Diagram ● Sequence Diagram
● Package Diagram ● Communication Diagram
● Profile Diagram ● Interaction Overview Diagram
● Composite Structure Diagram ● Timing Diagram

51
S. NO: 9 IMPLEMENTATION
DATE: 04-05-2023

FRONTEND SCREENSHOT:

BACKEND SCREENSHOT:

52
SI NO: 10 TEST PLAN
DOCUMENT DATE: 18-05-2023

Hospital Management System using MEAN

Stack
Test
Plan

53
 VERSION HISTORY

Version Implemente Revision Appr Approval Reason

# d Date oved Date
By By
1.0 Madhumitha 23/05/2023 Test Plan draft
NH

54
1 Introduction
1.1 Purpose of The Test Plan Document
The Test Plan document documents and tracks the necessary information required to effectively define the
approach to be used in the testing of the project’s product. The Test Plan document is created during the
Planning Phase of the project. Its intended audience is the project manager, project team, and testing team.
Some portions of this document may on occasion be shared with the client/user and other stakeholder whose
input/approval into the testing process is needed.
2 COMPATIBILITY Testing
2.1 Test Risks / Issues
The inputs fetched from the user should be validated each time when an operation is
performed. The login, registration and booking modules should be taken precise care as if it
breaks out then the entire application will crash out . Then we need to do database testing as it
helps in sorting out the load that can be provided to our server at any point of time

2.2 Items to be Tested / Not Tested

Item to Test Test Description Test Date Responsibility
Login Module The login module is tested for many test 23/05/23 Tester
cases such that the login module doesn’t
fail under any circumstances.
Add doctor The add doctor functionality is tested for 23/05/23 Tester
many test cases such that the adding
function doesn’t fail under any
circumstances.
Update salary status The salary update functionality 23/05/23 Tester
functionality is tested for many test cases
such that the updating function doesn’t
fail under any circumstances.
View summary The summary download functionality is 23/05/23 Tester
tested for many test cases such that the
view function doesn’t fail under any
circumstances
Book appointment The booking functionality is tested for 23/05/23 Tester
many test cases such that the booking
function doesn’t fail under any
circumstances
Add department The add department functionality is tested 23/05/23 Tester
for many test cases such that the adding
function doesn’t fail under
any circumstances

2.3 Test Approach(s)

Initially the login module should be tested for any discrepancies and then the functionalities
of dashboard should be tested

2.4 Test Regulatory / Mandate Criteria

THE WEB SERVICE PROVIDED BY THE SYSTEM SHOULD BE ABLE
TO RUN ON ALL VERSIONS OF THE WEB BROWSERS.

55
2.5 Test Pass / Fail Criteria
SUCCESS CRITERIA: The system should run smoothly on all the
versions of the web browser. It should run on the devices like mobile phones,
laptops. The web page should be structured properly when browsed with any web
browser.
FAIL CRITERIA: The user with basic access won’t be able to use a service
provided by the system. The web page is not structured properly in one or more web
browser.

2.6 Test Entry / Exit Criteria

1. TEST ENTRY: TESTING MUST BE CARRIED IN ALL
EXISTING BROWSER AND DEVICES STANDARD.
2. TEST EXIT: THE SYSTEM MUST RUN IN ALL THE VERSIONS OF
THE WEB BROWSER AND ALL DEVICES.

2.7 Test Deliverables

Deliverables of compatibility testing are Test Cases, Test summary report, Error
and appropriate fix strategies.

2.8 Test Suspension / Resumption Criteria

Compatibility testing Suspension criteria:
• Blank webpages or Browser crashes found preventing test
completion. Compatibility testing Resumption criteria:
• All issues in suspension criteria have been resolved or mitigated

2.9 Test Environmental / Staffing / Training Needs

STAFF: software test engineer, software test lead.
The entire web browser versions are needed to test the system for its
compatibility and major screen size.
The compatibility testing tools are:
1. LAMBDATEST
2. BROWSERSTACK

3 Functional Testing
3.1 Test Risks / Issues
The input given by the user should be in correct format as specified in the dataset. Each
function of the system is tested by providing appropriate input, verifying the output against the
functional requirements.

56
3.2 Items to be Tested / Not Tested
Item to Test Test Description Test Date Responsibility
Login check The validity of the input given by 23/05/2023 It is the responsibility of
the user should be checked. the Software developers
and the testing team
Add doctor The validity of the inputs given by 23/05/2023 It is the responsibility of
the admin should be checked the Software developers
against room booking scenarios and the testing team
Update salary The validity of the input given by 23/05/2023 It is the responsibility of
status the admin should be checked and the Software developers
reflected in the database. and the testing team
View summary The downloading 23/05/2023 It is the responsibility of
functionality should be the Software developers
validated. and the testing team
Book The validity of the input given by 23/05/2023 It is the responsibility of
appointment the user should be checked. the Software developers
and the testing team
Add department The validity of the input given by 23/05/2023 It is the responsibility of
the admin should be checked and the Software developers
reflected in the database. and the testing team

3.3 Test Approach(s)

● Run the test case
● Check for any errors
● Display the errors/success message

3.4 Test Regulatory / Mandate Criteria

● Collect input data from users
● Check validity of the input parameters.

3.5 Test Pass / Fail Criteria

● Collect input data from users
● Check validity of the input parameters
● Check whether we are able to login, view summary, add
doctor, add department, update salary status for the inputs
given by the user/admin.
3.6 Test Entry / Exit Criteria
The entry criteria are to check for environment and the corresponding programming
language which are used to run the code.
The exit criteria should be complete correct execution of all the functions in the

57
system.

3.7 Test Deliverables

The test deliverables are the summary report of the test involving all test inputs and the
errors in the function.
3.8 Test Suspension / Resumption Criteria
● If input data is of invalid form suspend the test case
● If the model is unable to carry out booking for the given input
data suspend the test
● Case and report to the administrator.

3.9 Test Environmental / Staffing / Training Needs

Staff: Software test engineers, Software test lead.
• The compatibility testing tools required can be any one from the following:
 Ranorex.
 Selenium.
 Test IO

4 PERFORMANCE TESTING
4.1 Test Risks / Issues
The performance of the system should be consistent and accurate to all the users
independent of the number of users using the system simultaneously.

4.2 Items to be Tested / Not Tested

Item to Test Test Description Test Date Responsibility
How long the system takes to
Response
predict for the given input It is the responsibility of
time of 23/05/2023
Parameters. the software tester
the
system
Performance testing to
Response ensure the
time web application’s response It is the responsibility of
23/05/2023
of the web time is the software tester
application within the expected limit for
20 concurrent users.

58
4.3 Test Approach(s)

● Identify performance requirement of the system under test.

● Identify requirement for test environment.
● Design the performance test environment and performance test cases.
● Setup the performance test environment.
● Execute the performance test for end-user side and server-
side scenarios.
● Analyze and evaluate performance test results against performance
criteria.

4.4 Test Regulatory / Mandate Criteria

The system is checked based on the performance criteria of Response
time of the system and concurrent users.

4.5 Test Pass / Fail Criteria

Test pass criteria: The System gives the result with good response time
within the stipulated time limit.
Test fail criteria: The response time of the system exceeds the time limit

4.6 Test Entry / Exit Criteria

● Performance testing entry criteria:
o Development cycle must be completed with no Critical and Major
functional defects in open state.
o Expected hardware infrastructure should be available to carry out
Performance Testing.
o Sufficient Test Data should be available to be used in Performance
Testing activity.
o Test Data should have been validated by client.
● Performance testing exit criteria:
● No Performance issues are in open state for all the features

4.7 Test Deliverables

The deliverables of performance testing include professional observations, test cases, a
summary report of the test and the defects of the system regarding the performance of the

59
 system.

4.8 Test Suspension / Resumption Criteria

Performance Testing will be suspended under below conditions:
• Unavailability of the system
• Server downtime due to uncertain reason
• Application is having Blocker / Critical defects in open state
• Required dependencies are not available.
Performance Testing will be resumed under below conditions:
• System becomes available
• Server is available, up and running
• Blocker / Critical issues are resolved and fixed
• Dependencies are resolved and the system is functional.

4.9 Test Environmental / Staffing / Training Needs

● Test environmental tools required are Jmeter/ LoadNinja/ LoadView.
● Staff: Software test engineer, Software test lead.

5 UNIT Testing
5.1 Test Risks / Issues
Each unit of the software system is tested by providing appropriate
input parameters and verifying the output against the requirements.

5.2 Items to be Tested / Not Tested

Item to Test Test Description Test Date Responsibility
The unit is tested to check if the user is able
It is the
to enter the input fields in the Prediction page
responsibility of
Input Data fields and alert in case of invalid inputs like blank 23/05/2023
the
fields and invalid metrics for data entered
software tester
It is the
Display summary The unit is tested to check if the user is able responsibility of
23/05/2023 the software
pdf to download summary pdf.
tester
It is the
Display The unit is tested to check if the user is able
responsibility of
appoinment to make appointments for the desired slot. 23/05/2023
the software
results
tester

60
5.3 Test Approach(s)
The test approaches used in unit testing are:
• Black box testing - using which the user interface, input and output are tested.
• White box testing - used to test each one of those functions behavior is tested.
• Gray box testing - used to execute tests, risks and assessment methods.
5.4 Test Regulatory / Mandate Criteria
The system must check for various kinds of functional units and results
must be evaluated.

5.5 Test Pass / Fail Criteria

Unit testing pass criteria:
 The input field takes all values and if any value is left blank, alert is given to the
user. Unit testing fail criteria:
 If any input filed is left blank, alert is given/not given to the user and the system exits.

5.6 Test Entry / Exit Criteria

Unit testing Entry Criteria are:
 All test hardware platforms must have been successfully installed, configured, and
functioning properly.
 All the necessary documentation, design, and requirements information should be
available that will allow testers to operate the system and judge the correct behavior.
 All the standard software tools including the testing tools must have been successfully
installed and functioning properly.
 Proper test data is available and the test environment such as, lab, hardware, software,
and system administration support should be ready.
Unit testing Exit Criteria are:
 A certain level of requirements coverage has been achieved.
 No high priority or severe bugs are left outstanding.
 All high-risk areas have been fully tested, with only minor residual risks left outstanding.

5.7 Test Deliverables

Deliverables of the Unit testing are Test Cases, Test summary reports and
bug reports

61
5.8 Test Suspension / Resumption Criteria
Unit testing Suspension criteria:
• Software/Hardware problems
• Similar kind of data of particular range leads to same output which could
be avoided during the testing.
• Assigned resources are not available when needed by test team.
Unit testing Resumption criteria:
• Resumption will only occur when the problem(s) that caused
the caused the suspension have been resolved.

5.9 Test Environmental / Staffing / Training Needs

Tools: Junit/ NUnit.
Staff: Software test engineer, Software test lead

6 USER ACCEPTANCE Testing

6.1 Test Risks / Issues
The users interact with the software and it is checked to accomplish what
the system need.

6.2 Items to be Tested / Not Tested

Item to Test Test Description
Login check The validity of the input given by
the user should be checked.
Add doctor The validity of the inputs given
by the admin should be checked
against room booking scenarios
Test Date Responsibility
23/05/2023 It is the responsibility of
the Software developers
and the testing team
23/05/2023 It is the responsibility of
the Software developers
and the testing team

Update salary The validity of the input 23/05/2023 It is the responsibility of

status given by the admin should be the Software developers
checked and reflected in the and the testing team
database.
View The downloading 23/05/2023 It is the responsibility of
summary functionality should be the Software developers
validated. and the testing team
Book The validity of the input given by 23/05/2023 It is the responsibility of
appointment the user should be checked. the Software developers
and the testing team
Add department The validity of the input given 23/05/2023 It is the responsibility of
by the admin should be checked the Software developers
and reflected in the and the testing team

62
 database.

6.3 Test Approach(s)

The overall testing approach of User Acceptance Testing is as follows:
• Creation of UAT test plan.
• Identify Test Scenarios.
• Create UAT Test Cases.
• Preparation of Test Data
• Run the Test cases.
• Record the Results.

6.4 Test Regulatory / Mandate Criteria

The response of the booking results should not be timed out and the user should get good aesthetic feel
over the web service by having similar look and feel across all the web pages

6.5 Test Pass / Fail Criteria

User Acceptance Testing Pass criteria:
• The registration is complete after the user is authorized successfully by
the administrator.
User Acceptance Testing Fail criteria:
• Unauthorized user is able to log in the software.

6.6 Test Entry / Exit Criteria

Entry criteria: Unit Testing, Integration Testing and System testing should
be completed ahead before the testing. No critical defects should be
opened by the time of this testing. Exit criteria: No critical defects open.
System should run all the UAT test cases defined to exit from the User
Acceptance Testing.

6.7 Test Deliverables

The test deliverables are the test cases, a summary report of the test and
the defect log of the system regarding the user acceptance of the
system.

63
6.8 Test Suspension / Resumption Criteria
 User acceptance testing suspension criteria:
 Critical error(s) found preventing test completion.
 User acceptance testing resumption criteria:
All issues in suspension criteria have been resolved or mitigated

6.9 Test Environmental / Staffing / Training Needs

Staff: Quality Assurance Manager and Test lead to monitor and control the UAT.

7.0 Selenium Testing:

7.1 Add Department module:

7.2 Update Salary Module:

64
7.3 Add Doctor Module

7.4 View Summary Module

65
7.5 Login Module:

66
S.No: 11 POST LAB QUESTIONS
Date: 18-05-2023
SOFTWARE TESTING & SOFTWARE MAINTENANCE

1. What are the objectives of software testing?

The objectives of software testing are to ensure the quality, reliability, and effectiveness of a
software system. Here are some common objectives of software testing:

1. Identify defects
2. Validate requirements
3. Improve software quality
4. Enhance user satisfaction
5. Ensure reliability and stability
6. Mitigate risks
7. Compliance with standards and regulations
8. Facilitate maintenance and future enhancements

2. what are the characteristics of good test case?

Good test cases possess several key characteristics that contribute to their effectiveness and quality. Here are
some characteristics of good test cases:

1. Clear and understandable

2. Relevance
3. Valid and accurate
4. Independent
5. Comprehensive coverage
6. Traceability
7. Reproducible
8. Scalable and maintainable
9. Measurable
10. Time and resource-efficient

3. List out the principles of software testing.

The principles of software testing provide a foundation for effective testing practices and guide the testing
process. Here are some commonly recognized principles of software testing:

1. Exhaustive Testing is Impossible.

2. Testing Shows the Presence of Defects
3. Early Testing
4. Defect Clustering
5. Pesticide Paradox
6. Testing is Context-Dependent
7. Absence-of-Errors Fallacy
8. Testers Independence
9. Testing is a Risk-Based Activity
10. Continuous Improvement

4. What is the difference between black box testing and white box
testing? Black Box Testing:
- Focus: Black box testing emphasizes the external behavior and functionality of the software
without considering its internal structure or implementation details.
- Perspective: Testers perform black box testing from an end-user perspective, treating the software as a

67
black box where they have no knowledge of its internal workings.
- Knowledge: Testers do not have access to the source code or any information about the internal design
or implementation of the software.
- Testing Approach: Testers design test cases based on the requirements, specifications, or user stories.
They verify if the software meets the expected functionality, handles inputs correctly, and produces the
desired outputs.
- Techniques: Black box testing techniques include equivalence partitioning, boundary value
analysis, decision tables, state transition testing, and exploratory testing.
- Advantages: Black box testing is independent of the internal implementation, allowing for a more
realistic evaluation of the software's behavior from a user's perspective. It can be performed by testers
without programming knowledge.

White Box Testing:

- Focus: White box testing focuses on the internal structure, logic, and implementation details of
the software.
- Perspective: Testers perform white box testing with knowledge of the internal workings of the
software, including access to the source code, architectural design, and implementation details.
- Knowledge: Testers have a deep understanding of the software's internal structure, algorithms, and
data flow, enabling them to design tests that target specific paths, conditions, or components.
- Testing Approach: Testers design test cases to exercise specific code segments, logic branches, and
decision points within the software. They verify the correctness of the code, code coverage, error
handling, and performance aspects.
- Techniques: White box testing techniques include statement coverage, branch coverage, path
coverage, condition coverage, and code review.
- Advantages: White box testing allows for a thorough examination of the internal code and logic,
enabling the identification of hidden defects, potential vulnerabilities, and performance bottlenecks. It
helps ensure code quality and efficiency.

5. What is the purpose of calculating cyclomatic complexity?

The purpose of calculating cyclomatic complexity is to measure the complexity of a software program or
codebase. Cyclomatic complexity provides a quantitative measurement of the number of independent paths
through a program's source code. It is a valuable metric used in software testing and quality assurance to
assess the complexity and understand the potential challenges associated with maintaining and testing the
software.

1. Code Quality Assessment

2. Test Coverage
3. Maintainability
4. Defect Identification
5. Code Review and Refactoring

6. Explain about the levels of testing.

Software testing is conducted at different levels, known as the levels of testing or testing levels.
Each level focuses on specific aspects of the software and serves different purposes in the overall
testing process. The commonly recognized levels of testing are as follows:
1. Unit Testing:
Unit testing is performed at the lowest level of the testing hierarchy. It focuses on testing individual
units or components of the software in isolation.
2. Integration Testing:
Integration testing verifies the interaction and integration between multiple units or components of
the software. It tests the behavior of interconnected modules or subsystems to ensure they work
together correctly.

68
 3. System Testing:
System testing is performed on the entire system as a whole, considering all its components and their
interactions. It focuses on testing the system's compliance with functional and non-functional
requirements.
4. Acceptance Testing:
Acceptance testing is conducted to determine whether the software meets the user's requirements
and is ready for deployment.
5. Regression Testing:
Regression testing is performed to ensure that previously tested and functioning features of the
software have not been adversely affected by recent changes or fixes.
6. Performance Testing:
Performance testing evaluates the software's performance and behavior under different workload
and stress conditions.
7. Security Testing:
Security testing focuses on identifying vulnerabilities and weaknesses in the software's security
measures. It involves testing the system for potential security breaches, unauthorized access, data
integrity, and confidentiality issues.

7.State the difference between alpha testing and beta

testing.Alpha Testing:
1. Environment: Alpha testing is performed in a controlled environment, typically at the developer's site or
in a lab setting. The testing environment closely simulates the real production environment.
2. Participants: Alpha testing is conducted by internal teams, including developers, testers, or employees of
the software development organization. The testers may be familiar with the system and closely work with
the developers.
3. Timing: Alpha testing is conducted in the early stages of software development, before the software is
considered feature complete. It is performed after unit testing and integration testing.
4. Purpose: The primary goal of alpha testing is to assess the overall system's functionality, reliability, and
stability. It helps identify defects, usability issues, and areas that need improvement before the software
progresses to the next stage.
5. Feedback: Feedback from alpha testing is collected by the internal testing team and developers. It helps
identify and resolve defects, refine features, and improve the software based on internal perspectives.

Beta Testing:
1. Environment: Beta testing takes place in a real-world environment that closely represents the end users'
operating environment. It can involve a limited release of the software to a selected group of external users.
2. Participants: Beta testing involves external users who are not part of the development organization. These
users may have varying levels of technical expertise and represent the target audience or a specific user
group.
3. Timing: Beta testing occurs after the completion of alpha testing. It is conducted in the later stages of
software development when the software is feature complete but still undergoing final testing and bug
fixing.
4. Purpose: The main objective of beta testing is to gather feedback from end users in a real-world setting. It
aims to identify any usability issues, compatibility problems, or unexpected behavior. Beta testing helps
ensure that the software meets user expectations and can be refined based on user feedback.
5. Feedback: Feedback from beta testing is collected from external users who provide their experiences,
suggestions, and bug reports. This feedback helps validate the software's performance, usability, and
compatibility across different user environments. It aids in identifying and fixing issues before the software's
official release.

8. List out the automated tools to perform testing on web application.

There are several automated testing tools available for testing web applications. Here is a list of commonly
used tools:
69
 1. Selenium
2. Cypress
3. Puppeteer
4. TestCafe
5. JUnit
6. TestNG
7. Cucumber
8. Appium
9. Postman
10. SoapUI

9. Differentiate between retesting and regression

testing Retesting:
1. Scope: Retesting focuses on verifying that a specific defect or a group of related defects have been fixed
or resolved.
2. Purpose: The primary goal of retesting is to ensure that a previously identified defect has been fixed
and that the affected functionality now works as expected.
3. Test Cases: Retesting involves executing the same test cases that initially uncovered the defect or test
cases specifically designed to validate the fix.
4. Targeted Areas: Retesting typically focuses on the specific areas of the software that were impacted by
the fixed defect.
5. Test Execution: Retesting is performed after the fix has been implemented and is usually conducted in
isolation, independent of other functionality or system behavior.
6. Timeframe: Retesting is usually conducted promptly after the defect fix to verify its correctness and closure.
7. Documentation: Retesting results are typically documented and compared with the expected results to
determine the success of the fix.

Regression Testing:
1. Scope: Regression testing verifies that existing, unaffected functionalities of the software have not
been negatively impacted by recent changes, fixes, or enhancements.
2. Purpose: The primary goal of regression testing is to ensure that the introduction of new changes or
fixes does not cause unintended side effects or regression defects in other parts of the software.
3. Test Cases: Regression testing involves executing a selected set of test cases that represent critical or
high- risk functionalities, including both affected and unaffected areas.
4. Targeted Areas: Regression testing covers both the areas directly impacted by the changes as well as
related functionalities that may have dependencies or interactions.
5. Test Execution: Regression testing is performed after the fixes or changes have been implemented and
may involve executing a combination of new and existing test cases.
6. Timeframe: Regression testing is typically conducted periodically or after significant changes to the
software to ensure that the overall system remains stable and functional.
7. Documentation: Regression testing results are often documented to track the test coverage, identify any
new issues or regressions, and compare against previous test runs.

10. What are the customer satisfaction metrics?

1. Net Promoter Score (NPS):
NPS measures the likelihood of customers recommending a product or service to others. It asks customers to
rate their likelihood on a scale of 0-10. Customers are then categorized as promoters (score 9-10), passives
(score 7-8), or detractors (score 0-6). The NPS is calculated by subtracting the percentage of detractors from
the percentage of promoters.

2. Customer Satisfaction Score (CSAT):

CSAT measures the satisfaction level of customers with a specific product, service, or interaction. It typically

70
uses a rating scale (e.g., 1-5 or 1-10) to collect customer feedback. The average rating across responses is
used as the CSAT score, indicating overall customer satisfaction.
3. Customer Effort Score (CES):
CES measures the ease of customer interactions with a product or service. It focuses on the effort customers
need to expend to achieve their goals. Customers are asked to rate their level of agreement with statements
related to effort (e.g., "The company made it easy for me to solve my issue"). The average score is used to
assess customer effort.
4. Customer Retention Rate:
Customer retention rate measures the percentage of customers who continue to use a product or service over
a specific period. It helps gauge customer loyalty and the effectiveness of retention strategies. A higher
retention rate indicates greater customer satisfaction and loyalty.
5. Churn Rate:
Churn rate measures the rate at which customers stop using a product or service over a specific period. It
represents customer attrition and dissatisfaction. Lower churn rates indicate higher customer satisfaction and
loyalty, while higher churn rates suggest issues or dissatisfaction.
6. Customer Lifetime Value (CLTV):
CLTV estimates the total value a customer brings to a business over their entire relationship. It considers
factors such as repeat purchases, average order value, and customer retention. Higher CLTV indicates
satisfied customers who provide long-term value to the business.
7. Customer Surveys and Feedback:
Collecting customer feedback through surveys, interviews, and feedback forms provides qualitative insights
into satisfaction. Open-ended questions allow customers to express their opinions, suggestions, and
concerns, helping to identify areas for improvement and gauge overall satisfaction.
8. Online Reviews and Ratings:
Monitoring online reviews and ratings on platforms like review websites, social media, and app stores can
provide a snapshot of customer satisfaction. Positive reviews and high ratings indicate satisfied customers,
while negative reviews may highlight areas of improvement.

11. What do you mean by software configuration management?

Software Configuration Management (SCM) is a discipline and set of practices focused on managing
and controlling changes to software throughout its lifecycle. SCM encompasses processes, tools, and
techniques that enable organizations to effectively manage and track software configuration items (e.g.,
source code, documentation, requirements, binaries) and the changes made to them. The primary objectives
of SCM are to ensure the integrity, consistency, and traceability of software artifacts and to support
collaboration among development teams.

12. List out the primary activities of software maintenance.

Software maintenance involves a set of activities performed after the software is deployed to ensure its
proper functioning, address issues, and enhance its capabilities. The primary activities of software
maintenance include:

1. Bug Fixes
2. Enhancements
3. Patch Management
4. Performance Optimization
5. Compatibility and Adaptation
6. Documentation Update
7. Configuration Management
8. User Support
9. Training and Knowledge Transfer
10. Monitoring and Analytics
11. Retirement or Decommissioning

71
13. List out the categories of software maintenance.
Software maintenance is typically categorized into the following categories, which help classify the types of
activities performed during the maintenance phase:

1. Corrective Maintenance
2. Adaptive Maintenance
3. Perfective Maintenance
4. Preventive Maintenance
5. Emergency Maintenance
6. Cosmetic Maintenance
7. Legal and Compliance Maintenance

14. Explain about the software maintenance process.

1. Problem Identification: The maintenance process begins with the identification of problems or issues in
the software. This can be done through various channels, such as user feedback, bug reports, monitoring
tools, or automated error tracking systems. The identified problems are documented and analyzed to
understand their root causes and impacts.

2. Problem Analysis: In this stage, the identified problems are analyzed to determine their severity, priority,
and potential solutions. This involves conducting further investigations, examining error logs, replicating
issues, and tracing back to the source code to understand the underlying causes of the problems.

3. Solution Design: Once the problems have been analyzed, a solution or a set of solutions is designed to
address them. This may involve modifying the source code, reconfiguring the software, adding new features,
or fixing bugs. The solution design phase also includes considering the potential impacts of the proposed
changes on the overall system and ensuring compatibility with existing functionalities.

4. Implementation: The designed solution is implemented in this stage. It involves making changes to the
software's source code, configuration files, or database schema, depending on the nature of the maintenance
task. Care should be taken to follow coding standards, version control practices, and documentation
guidelines during the implementation phase.

5. Testing: After implementing the changes, the modified software undergoes testing to ensure that the
maintenance activities have been successful and do not introduce new issues. Testing may involve various
techniques, such as unit testing, integration testing, regression testing, or user acceptance testing, depending
on the scope of the maintenance task.

6. Deployment: Once the modified software has passed the testing phase, it is deployed to the production
environment. This may involve deploying updated software binaries, updating databases, or configuring the
software on target systems. Proper deployment procedures and change management practices should be
followed to ensure a smooth transition to the updated software version.

7. Validation and Verification: After deployment, the updated software is validated and verified in the
production environment to ensure that it functions as expected and resolves the identified problems. This
may involve monitoring system performance, analyzing logs, and gathering user feedback to validate the
effectiveness of the maintenance activities.

8. Documentation and Communication: Throughout the maintenance process, documentation plays a crucial
role. It includes documenting the identified problems, their analysis, the implemented changes, and any other
relevant information. Clear communication with stakeholders, including end-users, developers, and project
managers, is also essential to keep them informed about the maintenance activities and their outcomes.

72
9. Monitoring and Feedback: Once the updated software is in production, ongoing monitoring and feedback
collection are important to detect any new issues, evaluate the effectiveness of the maintenance efforts, and
gather insights for future improvements. This may involve monitoring system logs, performance metrics,
user surveys, or support tickets to identify areas that require further attention.

10. Iteration and Continuous Improvement: The software maintenance process is often iterative, with
multiple cycles of problem identification, analysis, solution design, implementation, and testing. Continuous
improvement is emphasized by learning from previous maintenance experiences and incorporating feedback
into future maintenance activities to enhance the software's stability, performance, and user satisfaction.

15. Define software quality

Software quality refers to the degree to which a software product or system meets specified
requirements and user expectations. It encompasses various attributes and characteristics that define the
software's overall excellence, reliability, efficiency, maintainability, usability, and customer satisfaction.
Software quality is essential as it directly impacts the software's effectiveness, user experience, and the
organization's reputation.

16. List out the costs associated with software quality

The costs associated with software quality can be categorized into two main categories: prevention costs and
failure costs. Let's explore each category:

1. Prevention Costs:
a. Requirements Analysis and Planning.
b. Training
c. Process Definition and Improvement
d. Quality Assurance
e. Testing
f. Tools and Infrastructure
g. Documentation
2. Failure Costs:
a. Internal Failure Costs
b. External Failure Costs
c. Warranty and Liability Costs
d. Loss of Productivity
e. Lost Opportunities
f. Reputational Damage

17. What do you mean by traceability matrix? Explain with suitable example.
A traceability matrix is a document or tool used in software development and testing to establish and
maintain traceability between different artifacts throughout the software development life cycle. It helps
track the relationships and dependencies between requirements, design elements, test cases, and other project
artifacts. A traceability matrix provides a structured way to ensure that all requirements are addressed,
implemented, and tested.

18. List out the metrics for improving the software process, product and project.
Metrics play a crucial role in improving the software development process, product quality, and
project management. Here are some commonly used metrics in each category:

Software Process Metrics:

1. Defect Density.
2. Code Coverage
3. Effort Variance

73
 4. Schedule Variance
5. Cycle Time

Software Product Metrics:

1. Defect Removal Efficiency2. Mean Time to Failure (MTTF)
3. Customer Satisfaction Index
4. Mean Time to Repair (MTTR)
5. Usability Metrics

Project Management Metrics:

1. Cost Variance
2. Schedule Performance Index (SPI)
3. Risk Exposure
4. Resource Utilization
5. Stakeholder Satisfaction

19. What do you mean by defect tracking?

Defect tracking, also known as bug tracking or issue tracking, is a systematic process of identifying,
documenting, and managing defects or issues found in software products or systems. It is an essential part of
the software development and quality assurance process, helping teams track and resolve problems to ensure
the software meets quality standards and user expectations.

Defect tracking involves the following key steps:

1. Defect Identification: Defects are identified through various means, such as manual testing, automated
testing, user feedback, or code analysis. When a defect is found, it is logged and documented.

2. Defect Logging: The identified defects are logged into a defect tracking system or tool. Each defect is
assigned a unique identifier, and relevant details about the defect are recorded, including its description,
severity, priority, steps to reproduce, and any supporting documentation or screenshots.

3. Defect Classification: Defects are categorized based on their characteristics, impact, and priority.
Common defect categories include functional defects, usability issues, performance problems, security
vulnerabilities, and compatibility errors.

4. Defect Prioritization: Defects are prioritized based on their severity and impact on the software
functionality and user experience. Critical defects that significantly affect the software's core functionality or
pose a high risk may be given higher priority for immediate attention and resolution.

5. Defect Assignment: Defects are assigned to the appropriate team members, such as developers, testers, or
subject matter experts, for further investigation and resolution. Clear assignment and ownership help ensure
that defects are addressed by the responsible individuals.

6. Defect Resolution: The assigned team members analyze the defects, reproduce them if necessary, and
work on resolving the underlying issues. This typically involves code changes, configuration updates, or
adjustments to the software's configuration or environment.

7. Defect Verification: After resolving a defect, it undergoes verification or retesting to ensure that the fix is
effective and the defect no longer exists. Testers or quality assurance professionals validate the defect fix and
update the defect tracking system accordingly.

8. Defect Closure: Once a defect is verified and confirmed as fixed, it is marked as closed in the defect
tracking system. The closure status indicates that the defect has been resolved, and no further action is
required.

74
9. Defect Reporting and Metrics: Defect tracking systems provide reporting capabilities to generate defect-
related metrics and reports. These metrics help monitor defect trends, analyze the effectiveness of defect
resolution efforts, and identify areas for process improvement.

20 . What do you mean by Defect tracking?

Defect tracking is a systematic process that involves identifying, documenting, and managing defects or
issues found in software products or systems. It is an essential component of the software development life
cycle and quality assurance practices.

75
S.No: 12 PATENT SEARCH FOR CONCEPT SELECTION

DATE: 18-05-2023

PATENT:
A patent is a right granted to an inventor by the federal government that permits the inventor
to exclude others from making, selling or using the invention for a period of time.
The patent system is designed to encourage inventions that are unique and useful to society.
A patent may include many claims, each of which defines a specific property right. The
procedure for granting patents, requirements placed on the patentee, and the extent of the
exclusive rights vary widely between countries according to national laws and international
agreements.

PATENT SEARCHES AVAILABLE:

a) Google Patent

Google patent search was launched on December 14, 2006. Google Patents is a search
engine from Google that indexes patents and patent applications. Google Patents indexes
more than 87 million patents and patent applications with full text from 17 patent offices
including USPTO, WIPO etc.

i) Site: https://patents.google.com/
ii) Short description
Google Patents is a search engine from Google that indexes patents and patent applications.
These documents include the entire collection of granted patents and published patent
applications from each database. It has machine-classified Cooperative Patent Classification
codes for searching. Google Patents indexes more than 87 million patents and patent
applications with full text from 17 patent offices. Google Patents also indexes documents
from Google Scholar and Google Books.
Sample UI screenshot

76
b. USPTO

i. Site: https://www.uspto.gov/patents-application-process/search-patents
ii. Short description
The United States Patent and Trademark Office (USPTO) is the federal agency
responsible for granting U.S. patents and registering trademarks. The USPTO is "unique among
federal agencies because it operates solely on fees collected by its users, and not on taxpayer
dollars" USPTO operates a headquarters and Eastern Regional Outreach Office in Alexandria,
Virginia, and four additional regional offices across the USA. The USPTO is also a Receiving
Office, an International Searching Authority and an International Preliminary Examination
Authority for international patent applications filed in accordance with the Patent Cooperation
Treaty.
iii. Sample UI screenshot

77
c. IP INDIA

i. Site :https://ipindiaservices.gov.in/publicsearch
ii. Short description
The Office of the Controller General of Patents, Designs and Trade Marks (CGPDTM)
generally known as the Indian Patent Office, is an agency under the Department for
Promotion of Industry and Internal Trade which administers the Indian law of Patents,
Designs and Trade Marks. Term of every patent in India is 20 years from the date of filing
of patent application, irrespective of whether it is filed with provisional or complete
specification.

iii. Sample UI screenshot

78
d. WIPO
i. Site: https://www.wipo.int/patents/en/
ii. Short description
The World Intellectual Property Organization is one of the 15 specialized agencies of the
United Nations. . WIPO's two main objectives are (i) to promote the protection of
intellectual property worldwide; and (ii) to ensure administrative cooperation among the
intellectual property Unions established by the treaties that WIPO administers. WIPO was
established in 1970, following the entry into force of the 1967 WIPO Convention, with a
mandate from its Member States to promote the protection of IP throughout the world,
through cooperation among states and in collaboration with other international
organizations. Sample UI screenshot
iii. Sample UI screenshot

79
 3. Example relevant Granted Patents

Hospital management system and method using face recognition

Application filed by: 2015-02-27

Application granted: 2016-01-25
Application Number: KR101587924B1

ABSTRACT

Provided are a hospital management system and method,the hospital management system comprising:
entrance cameras for photographing an entrance of a hospital to photograph visitors; indoor cameras, installed inside
the hospital, for photographing specific designated places; an information acquisition unit which analyzesimages
photographed by each of the entrance cameras and the indoor cameras to acquire face recognition information of
people in the images, and acquires information on the photography time and place of facially-recognized people; a
database in which identification information on registrants including registered patients and employees of the hospital
is stored so as to match face information, and schedule information on the respective patients isupdated and managed;
a comparison and determination unit which identifies whether the facially-recognized people are registrants or not by
comparing the face recognition information acquired by the information acquisition unit with the information on the
registrants stored in the database, and determines, from among the registrants, whether the facially-recognized people
are employees, appointment-having patients, walk-in patients, or inpatients; an input unit in which information on
new subjects to be registered and information on appointments, medical care, examinations, treatment, surgery,
prescriptions, admission procedures and discharge procedures are inputted; a management server which tracks the
respective registrants identified by the comparison and determination unit by usingface recognition technology on the
basis of schedule information stored in the database, and manages schedules; and an information transmission unit
which transmits, to a mobile terminal of a preset object, information which is processed and generated by the
management server

80
81
82