HealthHub: Hospital Management System

Project Report

SUPERVISOR: Dr. Vibha Gaur

SUBMITTED BY

Adarsh Kumar (AE-343)

Sharvan Kumar (AE-347)
Kartik Dhama(AE-351)

2024
Department of Computer Science
ACHARAYA NARENDRA DEV COLLEGE
 ACKNOWLEDGEMENT

This Project was jointly undertaken by Adarsh Kumar, Shravan Kumar and Kartik Dhama
as their Semester-IV Software Engineering Project, under the guidance and supervision of
Dr. Vibha Gaur. Our primary thanks go to her, who poured over every inch of our project with
painstaking attention and helped us throughout the working of the project. It is our privilege to
acknowledge our deepest gratitude to her for her inspiration which has helped us immensely.
We are extremely grateful to her for her unstilted support and encouragement in the preparation
of this project.

ADARSH KUMAR SHARVAN KUMAR KARTIK DHAMA

 Acharya Narendra Dev College
(University Of Delhi)

CERTIFICATE
This is to certify that the project entitled “HEALTHHUB: A COMPREHENSIVE
HOSPITAL LISTING AND PATIENT RECORDS MANAGEMENT SYSTEM” has been
done by: Adarsh Kumar, Sharvan Kumar and Kartik Dhama of Bachelor of Computer
Science(Prog.) during Semester-IV from Acharya Narendra Dev College, University of Delhi
under the supervision of Dr. Vibha Gaur.

Adarsh Kumar Sharvan Kumar Kartik Dhama

Supervisor
Dr. Vibha Gaur
Contents

1. Problem Statement …………………………………………………………………………

Goal …………………………………………………………………………………….
2. Process Model ……………………………………………………………………………...
Advantages ………………………………………………………………………………
Disadvantages …………………………………………………………………………..
3. Requirement Modeling & Analysis ………………………………………………………
3.1 DFD ………………………………………………………………………………….
3.1.1 Context Level DFD………………………………………………………………
3.1.2 Level 1 DFD……………………………………………………………………
3.2 Data Dictionary……………………………………………………………………….
3.3 Use Case Diagram…………………………………………………………………….
3.4 Sequence Diagram…………………………………………………………………….
4. Software Requirement Specification………………………………………………………
4.1 Overall Discerption……………………………………………………………………
4.1.1 Product Functions………………………………………………………………
4.1.2 User Characteristics…………………………………………………………….
4.1.3 General Constraints…………………………………………………………….
4.1.4 Assumptions and Dependencies……………………………………………....
4.2 External Interface Requirements……………………………………………………..
4.2.1 User Interface………………………………………………………………….
4.2.2 Hardware Interface…………………………………………………………….
4.2.3 Software Interface……………………………………………………………..
4.3 Functional Requirements…………………………………………………………….
4.3.1 FR1 Login Requirement……………………………………………………..
4.3.2 FR2 Registration Requirement………………………………………………
4.4 Design Constraints………………………………………………………………….
5. Estimations………………………………………………………………………………
5.1 Function Points……………………………………………………………………..
 5.2 Efforts……………………………………………………………………………….
6. Scheduling………………………………………………………………….....................
6.1 Timeline Chart……………………………………………………………………..
7. Risk Management………………………………………………………………………..
7.1 Risk Table………………………………………………………………………….
8. Design……………………………………………………………………………………
8.1 Design Description…………………………………………………………………
8.2 Structured Chart………………………………………………………………
8.2.1 Pseudo Code………………………………………………………………….
9. Testing……………………………………………………………………………………
9.1 Test Case Diagram………………………………………………………………….
9.2 Flow Graph…………………………………………………………………………
9.3 Basis Path Set……………………………………………………………………….
9.4 Cyclomatic Complexity……………………………………………………………...
10. Reference…………………………………………………………………....…………….
Chapter 1

PROBLEM STATEMENT
In the healthcare sector, efficient management of hospital listings and patient records is
paramount for providing quality care, ensuring patient safety, and streamlining administrative
processes. However, many healthcare facilities still rely on outdated paper-based systems or
disjointed electronic systems, leading to inefficiencies, errors, and compromised patient care.
Therefore, the need for a comprehensive Hospital Listing and Patient Record Management
System arises to address these challenges: -

Key Challenges
o Privacy and Security Concerns.
o Insufficient appointment scheduling.
o Limited accessibility of patient records to hospitals which delays the treatment.
o Lack of hospital knowledge to patient in their locality.

Goal
Developing a Comprehensive Hospital Listing and Patient Record Management System that
addresses the above challenges is essential for modernizing healthcare delivery. The proposed
system should include the following features:
o A unified patient health record that includes medical history, lab results, imaging studies
and medication records.
o An appointment scheduling that optimizes appointment slots based on patient needs and
doctors' availability.
o Listing of hospitals so that patients can find the best possible hospital for their treatment at
their locality.
Chapter 2

PROCESS MODEL

A process model in software engineering refers to a structured approach or framework that

defines the activities, tasks, and phases involved in developing software systems. It outlines
the sequence in which these activities are performed and provides guidelines for managing the
software development process efficiently. Incremental model is being shown below in Figure
2.1

Incremental Model is an iterative software development approach where the software system
is developed in increments or smaller portions. Each increment builds upon the functionality
of the previous increment, gradually adding new features until the complete system is
developed. This model divides the software development process into manageable increments,
allowing for incremental development, testing, and delivery of software functionality.
Incremental model is used as:
1. Basic patient record management.
2. Appointment scheduling.
3. Hospital listing and search functionality.
4. Integration with external systems.
Advantages:
o Incremental Model enables the early delivery of essential features or core functionality.
o Since each increment is developed and delivered incrementally, you have the opportunity
to have feedback on the functionality.
o The Incremental Model reduces the risk as it is divided into increments, issues are identified
early in the process.
o Testing is easy as you can test each increments separately.

Disadvantages:
o Managing dependencies and interactions between increments can become complex as the
development progresses.
o If the requirements for each increment are not carefully defined or prioritized, there is a
risk of delivering increments with incomplete or insufficient functionality.
o Managing multiple increments simultaneously may introduce additional overhead.
o The effectiveness of the Incremental Model depends heavily on the initial architecture and
design decisions made at the beginning of the project.
Chapter 3
REQUIREMENT MODELING & ANALYSIS
Requirement analysis is the process of gathering, documenting, and analyzing the requirements
for a system. It involves understanding the needs of users and translating them into a form that
can be understood by developers.
Modelling involves creating abstract representations of the system being developed. Models
are used to understand, communicate, and validate the system's requirements, design, and
behaviour. Data Flow Diagrams (DFDs) are used for modelling the requirements.

3.1 Data Flow Diagram (DFD)

A Data Flow Diagram (DFD) is a graphical representation of the flow of data within a system.
It's a powerful tool used in software engineering and systems analysis to depict how data moves
through processes, stores, and external entities within a system.

3.1.1 Context Level DFD

A Context Level Data Flow Diagram (DFD) is the highest-level view of a system that shows
the interactions between the system being developed and external entities. It provides a broad
overview of how data flows into and out of the system without delving into the internal
workings of the system. Context level DFD is being shown in figure 3.1.
3.1.2 Level 1 DFD
A Level 1 Data Flow Diagram (DFD) is a visual representation that illustrates the flow of data
within a system at a higher level of abstraction. In the context of system analysis and design,
DFDs are commonly used to model the processes, data stores, external entities, and data flows
within a system. A level 1 DFD is shown in the figure 3.2.

3.2 Data Dictionary

A data dictionary is a centralized repository of information about the data structures used in a
system. It serves as a reference guide that provides detailed descriptions of data elements, such
as data types, field lengths, validation rules, and relationships between data elements.
The data dictionary is being shown in table 3.2.1.
 Table 3.2.1: Data Dictionary
Field Name Data Type Data Format Field Size Description

Name String [A-Z] [a-z] 30 Name of the user

with lower and
upper cases
Login ID String [A-Z] [a-z] [0-9] 30 Unique login id
[@] [.] with special
characters
Password String [A-Z] [a-z] [0-9] 8 Password should
[@] [#] [$] [*] contain special
characters with
upper and lower
cases

3.3 Use Case Diagram

A use case diagram is a visual representation of the functional requirements of a system. It
illustrates how users interact with a system to achieve specific goals or tasks. Use case diagrams
are part of the Unified Modelling Language (UML) and are widely used during the
requirements analysis phase of software development to capture and communicate the system's
behaviour. The use case diagram has been shown in figure 3.3.
Chapter 4
SOFTWARE REQUIREMENT SPECIFICATION
Content
A software requirement specification (SRS) is a description of a software system to be
developed. The SRS document typically includes detailed descriptions of what the system
should do, how it should behave, and what constraints it should adhere to. It outlines the
functional and non-functional requirements of a software system.

4.1 Overall Description

The overall description gives an overview of software requirements and other important
subsections. All the requirements will be described in detail in their specific requirement
subsections.
The purpose of the Software Requirements Specification document is to clearly define the
system under development, namely hospital listing and patient record management system. The
intended audience of this document includes the development team such as requirement team,
requirement analysis, design team and other members of developing organization.

4.1.1 Product Functions

Product functions, refer to the specific tasks or actions that a software product is designed to
perform in order, to fulfil the needs and requirements of its users. These functions describe the
capabilities or features of the software system.
The product functions can be divided into core functions like patient registration, patient record
management, appointment scheduling and medical history tracking which are essential for the
primary purpose of the system and non-core functions such as document management, search
and filter capabilities, integration with external systems, which enhance usability, efficiency or
user experience.

4.1.2 User Characteristics

User characteristics refer to the attributes, traits, or qualities of the individuals or groups who
will interact with the software system. Understanding user characteristics is crucial for
designing and developing software that meets the needs, preferences, and abilities of its
intended users. There will be mainly three types of users: - Patients, Medical Professionals and
Administrator
Patients
A patient will be someone who may have access to certain features of the system, such as
scheduling appointments, viewing their medical records, accessing educational materials, and
communicating with healthcare providers.
Medical Professionals
A medical professional will be someone which includes doctors, nurses, and other healthcare
providers who will use the system to access patient records, update medical information,
schedule appointments, and communicate with other staff members.
Administrator
An administrator will have full access to software. Administrators have the full responsibility
of maintaining the software and data which is included in the software. They are responsible
for maintaining and supporting the system will have access to administrative features for
managing user accounts, system configurations, backups, and updates.

4.1.3 General Constraints

General Constraints refer to the limitations or restrictions that may impact the design,
development, deployment, or operation of a software system. These constraints can arise from
various factors, including technological, organizational, regulatory considerations.
o The user interface will be intuitive enough so that no training is required by any kind of
users.
o Internet connection is mandatory need for the access of the software.
o Compliance with healthcare regulations that are set up by regulatory bodies.
o User interface design that follows best practices for usability and accessibility.

4.1.4 Assumptions and Dependencies

Assumptions and dependencies mean certain assumptions are made at the beginning of the
development of software. User interface design that follows best practices for usability and
accessibility.
o One should know about the terms related to healthcare and technical terms that are
associated with healthcare facilities.
o The user should have prior knowledge to the computer, and they must understand the input
and output of the software.
o The user and medical professionals should have good internet connection.
o The medical professionals should have knowledge about the technology and patient
scheduling.

4.2 External Interface Requirement

External interface requirements are specifications that define how a system or software
interacts with external entities, such as other systems, devices, or users. These requirements
outline the interfaces that must be established and maintained to enable communication and
data exchange between the system and its external environment.

4.2.1 User Interface

A user interface (UI) is the means through which a user interacts with a computer system or
software application. It serves as the point of communication between the user and the system,
enabling users to input commands, provide data, and receive feedback or output from the
system. The user interface encompasses all the elements, controls, and mechanisms that
facilitate this interaction, including visual components, input devices, and feedback
mechanisms.
o A centralized dashboard for easy access to key functionalities include widgets for quick
access to patient lists, appointments, medical records and administrative tasks.
o Patient listing display a searchable and filterable list of patients with key information such
as name, age, gender, and medical record number.
o Patient registration design a user - friendly form for registering new patients, capturing
essential information such as personal details, contact information and medical history.
o Appointment scheduling implement a calendar – based interface for scheduling patient
appointments with healthcare providers.
o Medical records management create a comprehensive interface for viewing and managing
patient medical records.
o Role-based access control is implemented to restrict access to sensitive patient information
based on user roles and permissions.

4.2.2 Hardware Interface

A hardware interface refers to how software communicates and interacts with hardware
components or devices. It defines the protocols, signals, and mechanisms through which the
software can control, monitor, or exchange data with the hardware.
o Computer systems including servers for hosting the software application and databases for
storing patient records and other data.
o Networking hardware such as routers, switches, and firewalls may be necessary to establish
network connections between different components of the system, including client
computers, servers, and external systems for data exchange.
o Input devices such as keyboards, mice, and touchscreens are required for users to input data
and interact with the software application.
o Output devices such as monitors, printers, and digital displays are needed to present
information to users.
o Storage devices such as hard drives, solid-state drives (SSDs) may be used to store patient
records, medical images, and other data generated by the system.

4.2.3 Software Interface

a software interface refers to the point of interaction between different software components or
systems. It defines how these components communicate and interact with each other, enabling
them to exchange data, invoke functions, or coordinate activities.
o The name of the software is HealthHub.
o The system would interact with a database management system (e.g., SQL database) to
store and retrieve patient records, hospital listings, appointment schedules, and other data.
o For frontend HTML and CSS is used and for backend JavaScript is used for interactive
GUI.

4.3 Functional Requirements

functional requirements are descriptions of the system's behaviour or functions, specifying
what the system should do. These requirements define the fundamental capabilities or features
of the software that enable it to perform specific tasks or operations to meet the needs of its
users.

4.3.1 FR1 Login Requirement

o The users need to login by filling their details and create a login ID and password.
o If any box is left empty, an error pop will show like “All fields are required to fill”.
o If all fields are filled, then the user can hit the login button and reach on the home page of
Health Hub.
o There will be validation of user's details.

4.3.2 FR2 Registration Form Requirement

o After login new users need to register themselves by providing their information like name,
age, gender, mobile number, medical diagnosis, etc.
o If the user leaves any empty box a pop will come like “All fields are required”.
o After filling all the information user will be registered and gets a welcome message saying,
“Welcome to HealthHub”.
o There will be validation of user's details.

4.4 Design Constraints

Design constraints in software engineering refer to the limitations, conditions, or requirements
that shape the design process and influence the final product.
o All coding is done in HTML, CSS, JavaScript.
o The software can run on windows and Mac OS.
o The software can also run on UNIX platform.
Chapter 5

ESTIMATIONS
estimation refers to the process of predicting the effort, time, resources, and cost required to
complete a software development project or a specific task within that project. Estimation plays
a crucial role in project planning, scheduling, budgeting, and resource allocation.

5.1 Function Points

Function Points are a measure used in software development to quantify the size and
complexity of a software application based on its functionality. They provide a standardized,
objective way to measure software size, which can then be used for estimating effort, cost, and
resources required for development.
Function points can be used for various purposes such as:-
o Function Points can be used as a basis for estimating the effort required to develop the
software.
o By combining Function Points with productivity metrics and cost/duration estimates,
project managers can derive estimates for project cost and duration.
o Function Points can be used to measure productivity by comparing actual effort expended
on a project to the estimated effort based on Function Point counts.
o Productivity = FP/PM (effort is measured in person - months).

1. External Inputs (EI): These are user inputs that add, change, or delete data within the
system being measured. Each unique input type is counted. In given project login ID,
password, personal information and medical records are external inputs.
2. External Output (EO): These are user outputs generated by the system being measured.
Each unique output type is counted. In given project output screen and confirmation of
appointments are external outputs.
3. External Inquiries (EQ): An external inquiry is a user request for information from the
system being measured those results in the retrieval of data, without updating or altering
any data within the system. In other words, an external inquiry involves the system
providing information in response to a user's query without changing the internal state of
the system. appointment scheduling by patient is only external inquiries.
4. Internal Logical Files (ILF): These are user-recognizable groups of logically related data
within the system being measured, maintained by the system. repositories, user database
and result repositories are internal logical files.
5. External Interface Files (EIF): Each external interface file is a logical grouping of data
that resides external to the application but provides data that may be of use to the
application. There are no EIF.
All the five parameters of function points are assigned some weight that have been
experimentally determined and shown in the table 5.1.1.
 Table 5.1.1. Computing Function Points
Functional Weighting Factors Count Total
Units

Low Average High

External 3 4 6 5 20
Inputs (EI)
External 4 5 7 2 10
Output (EO)
External 3 4 6 1 4
Inquiries (EQ)
External 7 10 15 3 30
Logical Files
(ILF)
External 5 7 10 0 0
Interface Files
(EIF)
Count Total (Average Case) 64

Now value adjustment points have been calculated by answering some questions on the scale
of 0 to 5 which is being shown in table 5.1.2.

Table 5.1.2: Computing Value Adjustment Factor

1. Does the system require reliable backup and recovery? 3

2. Are specialized data communications required to transfer information to or 4

from the application?

3. Are there distributed processing functions? 3

4. Is performance critical? 3

5. Will the system run in an existing, heavily utilized operational environment? 2

6. Does the system require online data entry? 5

 7. Does the online data entry require the input transaction to be built over multiple 2
screens or operations?
8. Are the master files updated online? 3

9. Are the inputs, outputs, files, or inquiries complex? 1

10. Is the internal processing complex? 1

11. Is the code designed to be reusable? 4

12. Are conversion and installation included in the design? 0

13. Is the system designed for multiple installations in different organizations? 2

14. Is the application designed to facilitate change and ease of use by the user? 3

∑(fi) 36

The fi( i = 1 to 14 ) are value adjustment factors (VAF) based on responses to the questionnaires
from table 5.1.2.
Count total is the sum of all function point entries obtained from the table 5.1.1.
The function point (FP) is thus calculated with the following formula :
Function Point = Unadjusted Function Point * Complexity Adjustment Factor
FP = UFP * CAF
Where CAF is complexity adjustment factor and is equal to [0.65 + 0.01 x ΣFi]. The Fi (i=1 to
14) are the degree of influence and are based on responses to questions noted in 5.1.2.
Function point for this project is calculated below :
FP = UFP * CAF
FP = UFP * [0.65 + 0.01 * Σ (Fi)]
FP = 64 * [0.65 + 0.01 * 36]
FP = 64 * 1.01
FP = 64.64
Hence, 64.64 is being obtained as function point for this project.

5.2 Effort
Efforts refers to the amount of time, resources, and work required to complete a software
development project or task. Effort encompasses various activities involved in the software
development lifecycle, including analysis, design, coding, testing, documentation, and
deployment.
It is calculated as E = FP / P where ,
E stands for effort
FP stands for function points
P stands for productivity

Here productivity, P = 21 (Nominal value according to the requirement of project)

Effort = Function Point / Productivity

= 64.64/21
Effort = 3.07 person – months
Chapter 6

SCHEDULING

Scheduling refers to the process of creating a timeline or plan for completing various tasks and
activities within a software development project. Scheduling involves determining when
specific tasks will be started and completed, allocating resources to those tasks, and
establishing dependencies between them.

Project Scheduling
Project scheduling involves creating a detailed plan for the execution of tasks and activities
within a software development project. It's a critical aspect of project management aimed at
organizing and coordinating resources, timelines, and dependencies to ensure the successful
delivery of the software product.
Here are the key components and steps involved in project scheduling in software engineering:
o Tasks and activities required to complete the project, this typically involves breaking down
the project scope into smaller, manageable units
o Identify all the functions required to complete the project.
o Determine the dependency among various activities.
o Establish the most likely size for the time duration required to complete the activities.
o Allocate resources to activities.
o Plan the beginning and ending dates for different activities.
o Determine the critical path. A critical way is the group of activities that decide the duration
of the project.

The timeline gantt chart is given in figure 6.1

Figure 6.1 : Gantt Chart
Chapter 7

RISK MANAGEMENT

Risk management in software engineering refers to the process of identifying, analyzing,

prioritizing, and mitigating risks that could potentially impact the success of a software
development project. Risks are events or conditions that, if they occur, may have a negative
impact on the project's objectives, such as delays in schedule, cost overruns, quality issues, or
failure to meet user requirements.
There are three main classifications of risks which can affect a software project:
o Project Risk
o Technical Risk
o Business Risk

7.1 Risk Table

A risk table, often referred to as a risk matrix or risk register, is a tool used to identify, analyze,
and prioritize risks associated with a software development project. It provides a structured
approach for capturing and assessing potential threats to the success of the project and helps
project managers and teams make informed decisions about risk mitigation strategies.
A project team begins by listing all risks (no matter how remote) in the first column of the
table. This can be accomplished with the help of the risk item checklists. Each risk is
categorized in the second column (e.g., PS implies a project size risk, BU implies a business
risk). The probability of occurrence of each risk is entered in the next column of the table. Each
risk component is assessed and an impact category is determined.
The impact is rated as: Negligible (4), Marginal (3), Critical (2) & Catastrophic (1).
Risk table for this project is being shown in table 7.1
(SR: Schedule Risk, QR: Quality Risk, PR: Performance Risk, OR: Operational Risk )
Table 7.1 : Risk Table
Risks Category Probability Impact RMM

Incorrect data SR 50% 3 Collect correct

received by users data from the
users.
Risks associated OR 30% 4 Complying every
to compliance law with the
with governance government.
Server failure OR 35% 4 Better server
implementation

Larger number of QR 50% 3 Increase your

user than server capacity
planned
Inexperience SR 20% 4 Train users how
Users to use the
platform
Testing might SR 25% 4 Plan different
revel some error level of testing
on multiple
phases.
Staff turnover SR 33% 2 Develop
will be high techniques to
handle staff
Less funding OR 80% 2 Ensure funding
received from different
sources
Chapter 8

DESIGN

Design refers to the process of creating a blueprint or plan for building a software system that
meets specified requirements and objectives. It encompasses the architectural, structural, and
behavioural aspects of the software, defining how it will be organized, how its components will
interact, and how it will function.

8.1 Design Description

Design description provides a comprehensive overview of the Hospital Listing and Patient
Record Management System, covering its architecture, modules, data design, user interface,
algorithms, error handling, security, and integration aspects.
1. Architectural Overview
The Hospital Listing and Patient Record Management System follows a client-server
architecture. The client side consists of a web-based interface accessible via browsers, while
the server side hosts the application logic, database, and APIs.
2. Module Description
Patient module : - Responsible for patient registration, updating information, and managing
patient records.
Doctor Module :- Lists of all available doctors with their specialties, schedules, and contact
information which enables patients to schedule appointments with doctors.
Appointment module :- Handles appointment scheduling, modification, and cancellation
provides notifications to patients and doctors about upcoming appointments.
Medical Record Module :- Stores and manages patient medical records securely supports the
creation, viewing, and updating of medical records by authorized personnel.
3. User Interface Design
Clean and intuitive web-based interface with separate sections for patients, doctors,
appointments, medical records, and billing. Easy-to-use forms for data entry and updating
patient information. Interactive calendar for scheduling appointments with doctors.

8.2 Structured Chart

A structured chart is like a map that helps developers organize and understand how different
parts of a program fit together. It's a visual representation showing the flow of control or data
through a system. a structured chart is like a map that helps developers organize and understand
how different parts of a program fit together. It's a visual representation showing the flow of
control or data through a system.
Structured chart is being shown in figure 8.1

Figure 8.1 : Structured Chart

8.2.1 Pseudo Code
Pseudocode is a way of writing out the steps or logic of a computer program in a language that
is more human-readable than actual programming code. It's like a rough draft or outline of a
program's algorithm, expressed in plain language with some programming-like conventions.

1. Start
2. Display Menu:
a. List Hospitals
b. Manage Patient Records
c. Exit
3. Read user input
4. If user input is "a":
Display list of hospitals
5. If user input is "b":
Display sub-menu for managing patient records:
a. Add new patient
b. Search for patient
c. Update patient information
d. Delete patient record
e. Go back to main menu
6. Read user input for patient record management
7. If user input is "a":
Prompt user to enter patient information (name, age,
gender, etc.)
Add new patient record to database
8. If user input is "b":
Prompt user to enter patient name or ID to search
Display patient information if found
9. If user input is "c":
Prompt user to enter patient name or ID to update
Display current patient information
Allow user to update patient details
10. If user input is "d":
Prompt user to enter patient name or ID to delete
Delete patient record from database
11. If user input is "e":
Go back to main menu
12. If user input is "c":
Exit the program
13. End
Chapter 9

Testing

Testing is the process of evaluating a software application or system to ensure that it behaves
as expected and meets the specified requirements. The primary goal of testing is to identify
defects, bugs, or errors in the software so that they can be fixed before the product is released
to users.

White Box Testing

White-box testing, also known as clear-box testing, glass-box testing, or structural testing, is a
software testing technique that involves examining the internal structure, logic, and code of a
software application or system.
In white-box testing, testers have access to the source code, design documents, and architecture
of the software, allowing them to design test cases based on the internal logic and paths through
the code. The main objective of white-box testing is to ensure that all paths through the code
are executed and that the software functions correctly according to its specifications.
Here are some commonly used white-box testing techniques:
• Path Coverage: Path coverage ensures that every possible path through the code, including
loops and conditionals, is executed at least once during testing. Test cases are designed to
exercise all possible combinations of paths through the code to identify complex
interactions and potential control flow issues.
• Data Flow Coverage: Data flow coverage techniques analyze how data is manipulated and
used throughout the code. Techniques such as def-use coverage and du-path coverage
ensure that data values are properly initialized, used, and updated within the code to identify
potential data flow errors and dependencies.
• Statement Coverage: This technique aims to ensure that every statement in the source
code is executed at least once during testing. Test cases are designed to exercise each
statement individually to verify that all parts of the code are reachable and functional.

Black Box Testing

Black-box testing is a software testing technique that focuses on assessing the functionality of
a software application or system without examining its internal structure, code, or
implementation details. In black-box testing, the tester interacts with the software as an external
user would, without knowledge of its internal workings. The primary goal of black-box testing
is to validate that the software behaves according to its specified requirements and functional
specifications.
Black-box testing is essential for validating the correctness, completeness, and usability of
software applications from an end-user perspective, helping to ensure that they meet user
expectations and functional requirements.
Here are some commonly used white-box testing techniques:
• Equivalence Partitioning: This technique divides the input domain of the software into
equivalence classes, where each class represents a set of input values that should produce
the same result.
• Boundary Value Analysis: Boundary value analysis focuses on testing the boundaries or
edges of equivalence classes, as errors often occur at the boundaries of valid input ranges.
Test cases are designed to include values at the boundaries, just above and below the
boundaries, and just beyond the valid input range.
• Random Testing: In random testing, input values are selected randomly from the input
domain without following any specific test design technique. While this approach may
not provide systematic coverage, it can help uncover unexpected defects and edge cases
that may not be identified using structured testing techniques.

9.1 Test Case Design

Test case design is the process of creating detailed test cases based on requirements
specifications to verify that a software application behaves as expected. It involves
systematically defining inputs, actions, and expected outcomes to validate different aspects of
the software's functionality.
● Test Case 1: Check results on entering valid input
● Test Case 2: Check results on entering Invalid input
● Test Case 3: Check response on leaving fields empty
A test case is given in table 9.1
Table 9.1 : Test Cases
Test Test Case Description Input Expected Actual Output Pass/Fail
Case Output
No.

1. Register Valid/ Name, Register page Register page Pass

Module invalid Login ID, would open would open
Name is Password
entered by
user
 2. Login Module Valid/ Login ID, Home page Home page Pass
invalid Password should be open should be open
Name is
entered by
user

3. Appointment Slots Hospital Confirmation Confirmation Pass

availability and date of an of an
appointment appointment

9.2 Flow Graph

Flow Graph is defined as a function in a program that can be represented as a control flow
graph and the nodes in the flow graph are defined as program statements while the directed
edges are the flow of control. A Flow Graph consists of nodes and edges.
A flow is being shown in figure 9.1
1. Start
2. Display Menu:
a. List Hospitals
b. Manage Patient Records
c. Exit
3. Read user input
If user input is "a":
4. Display list of hospitals
If user input is "b":
5. Display sub-menu for managing patient records:
a. Add new patient
b. Search for patient
c. Update patient information
d. Delete patient record
e. Go back to main menu
6. Read user input for patient record management
If user input is "a":
7. Prompt user to enter patient information (name, age, gender,
etc.)
Add new patient record to database
If user input is "b":
8. Prompt user to enter patient name or ID to search
Display patient information if found
If user input is "c":
9. Prompt user to enter patient name or ID to update
Display current patient information
Allow user to update patient details
If user input is "d":
10. Prompt user to enter patient name or ID to delete
Delete patient record from database
If user input is "e":
11. Go back to main menu
If user input is "c":
12. Exit the program
13. End

Figure 9.1 : Flow Graph

9.3 Basis Path Set
Basis Path Testing is a white-box testing technique based on the control structure of a program
or a module. Using this structure, a control flow graph is prepared and the various possible
paths present in the graph are executed as a part of testing. Therefore, by definition, Basis path
testing is a technique of selecting the paths in the control flow graph, that provide a basis set
of execution paths through the program or module. An independent path is any path through
the program that introduces at least one new set of processing statements or a new condition.
When stated in terms of a flow graph, an independent path must move along at least one edge
that has not been traversed before the path is defined.
Independent Paths is being shown
1. 1>2>3>5>6>7>8>9>10>11>12>13
2.1>2>3>4>13
3.1>2>3>5>6>7>13
4.1>2>3>5>6>8>9>10>11>12>13
5.1>2>3>5>6>8>9>13
6.1>2>3>5>6>8>9>10>11>13

9.4 Cyclomatic Complexity

Give definition of cyclomatic complexity and compute cyclomatic complexity of various
modules.
Cyclomatic complexity is a software metric that provides a quantitative measure of the
logical complexity of a program. When used in the context of the basis path testing method,
the value computed for cyclomatic complexity defines the number of independent paths in
the basis set of a program and provides you with an upper bound for the number of tests that
must be conducted to ensure that all statements have been executed at least once.
Complexity is computed in one of three ways:
1. The number of regions of the flow graph corresponds to the cyclomatic complexity.
2. Cyclomatic complexity V ( G ) for a flow graph G is defined as V ( G ) = E - N + 2
where E is the number of flow graph edges and N is the number of flow graph nodes.
3. Cyclomatic complexity V ( G ) for a flow graph G is also defined as
V(G)=P+1
where P is the number of predicate nodes contained in the flow graph G .
The Cyclomatic Complexity
1. Closed Region = 5
2. V(G) = E - N+2 = 15 – 12 + 2 = 5
3. Number of predicate nodes = V(G) = P + 1 = 4 + 1 = 5
Chapter 10

Reference

1. Aggarwal, K. K., & Singh, Y. (2007). Software Engineering. 3rd edition. New Age
International Publishers.
2. Pressman, R. S., & Maxim, B. R. (2015). Software Engineering: A Practitioner’s Approach.
8th edition. McGraw-Hill.