SRS Document

BATCH NO:3

19 april, 2022

principles of software engineering

BATCH NO:3; SRS Document 2

Software Requirements Specification

for
PERSONAL INSULIN PUMP

Version 1.5

Prepared by

Group Name: BATCH-3

b.Gayathri . . . . . . . . . . . . . . . 20VV1A1210 . . . . . . . . . . . . . . . [email protected]

b.saikiran. . . . . . . . . . . . . . . .20VV1A1211. . . . . . . . . . . . . . . [email protected]
ch.Abhilash. . . . . . . . .20VV1A1212. . . . . . . . [email protected]
d . vishnu priya . . . . . . . . . . . . . . 20VV1A1213 . . . . . . . . . . . . . . [email protected]

Instructor: Dr . B.TIRIMULA RAO SIR

Course: SOFTWARE ENGINEERING
Lab Section: 10:00-1:00
Teaching Assistant: MRS. Madhumitha Chanda
Date: APRIL 2022
BATCH NO:3; SRS Document 3

CONTENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
REVISIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
1 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.1 DOCUMENT PURPOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 PRODUCT SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW . . . . . . . . . . . 1
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS . . . . . . . . . . . . . . 1
1.5 DOCUMENT CONVENTIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.6 REFERENCES AND ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . 2
2 OVERALL DESCRIPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 PRODUCT OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 PRODUCT FUNCTIONALITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 DESIGN AND IMPLEMENTATION CONSTRAINTS . . . . . . . . . . . . . . . . 3
2.4 ASSUMPTIONS AND DEPENDENCIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 SPECIFIC REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 EXTERNAL INTERFACE REQUIREMENTS. . . . . . . . . . . . . . . . . . . . . . . .4
3.2 FUNCTIONAL REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 USE CASE MODEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 OTHER NON-FUNCTIONAL REQUIREMENTS . . . . . . . . . . . . . . 6
4.1 PERFORMANCE REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 SAFETY AND SECURITY REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 SOFTWARE QUALITY ATTRIBUTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 OTHER REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
APPENDIX A – DATA DICTIONARY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
APPENDIX B - GROUP LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Revisions
Version Primary Author(s) Description of Version Date Completed
Draft Type and Number Full Name Information about the revision. This
table does not need to be filled in whenever a document is touched, only
BATCH NO:3; SRS Document 4

1 Introduction

1.1 Document Purpose

The Document is on INSULIN PUMP , it contains all the requirments to
provide an overview to complete the project . This document contains all
the information needed by a software engineer to design and implement the
software product i.e INSULIN PUMP. The purpose of this document is to
present a detailed description of the Automatic Insulin Pump system. It
will explain the purpose and features of the system, the interfaces of the
system, what the system will do, the constraints under which it must
operate and how the system will react to external stimuli. This document is
intended for both the stakeholders and the developers of the system.
1.2 Product Scope
This SW system will be an automatic insulin pump designed for the
patients which are suffering from diabetes. This system will be designed to
check the level of glucose in the patient’s body automatically through
embedded sensors and if glucose level is low or high ’ performs the
corresponding functions which are designed to level the amount of glucose
in the body (methods are described below). The project is required to
construct an insulin pump simulator that can be used for diabetes patients,
insulin pump developers and physicians.

According to WHO, approximately 347 million people had diabetes in 2008.

Similarly, as per the International Diabetes Federation (IDF), around 384
million people had diabetes in 2013, and almost 592 million people are
predicted to suffer by 2035. The number of people diagnosed with diabetes
is expected to rise at a very high rate. The most substantial percentage
increase is expected to be in the demographic with ages over 60.
1.3Intended Audeence and Document Overview
TPeople with diabetes cannot make their own insulin, a hormone that is
BATCH NO:3; SRS Document 5

normally secreted by the pancreas. Insulin is essential to metabolize sugar

and hence generate energy. Currently most diabetics inject insulin two or
more times per day, with the dose injected based on readings of their blood
sugar level. However, this results in artificial blood sugar fluctuations as it
does not reflect the on-demand insulin production of the pancreas. A
personal insulin pump is an external device that mimics the function of the
pancreas. It uses an embedded sensor to measure the blood sugar level at
periodic intervals and then injects insulin to maintain the blood sugar at a
‘normal’ level. Using readings from the embedded sensor, the system
automatically measures the level of glucose in the sufferer’s body.
Consecutive readings are compared. If they indicate that the level of
glucose is rising then insulin is injected to counteract this rise. The ideal
situation is a consistent level of sugar that is within some ‘safe’ band. This
document provides a complete overview on the structure of and internal
unction of the INSULIN PUMP . It provides the functions and roles of the
insulin reserviour , control unit, sensor pump..
1.4Definitions, Acronyms and Abbreviations
BATCH NO:3; SRS Document 6
BATCH NO:3; SRS Document 7

DKA 1.4 Document Conventions

¡In general this document follows the IEEE formatting requirements. Use
Arial font size 11, or 12 throughout the document for text. Use italics for
comments. Document text should be single spaced and maintain the 1”
margins found in this template. For Section and Subsection titles please
follow the template.
TO DO: Describe any standards or typographical conventions that were
followed when writing this SRS, such as fonts or highlighting that have
special significance. Sometimes, it is useful to divide this section to several
sections, e.g., Formatting Conventions, Naming Conventions, etc.¿
1.5 References and Acknowledgments
IEEE-2004 version of SWEBOK.
Editors: Pierre Bourque, École de technologie supérieureRobert Dupuis,
Université du Québec à Montréal
• https://www.webmd.com/diabetes/insulin-pump
• https://www.endocrineweb.com/guides/insulin/insulin-pump-overview
• https://www.medtronicdiabetes.com/treatments/insulin-pump-therapy
• https://en.wikipedia.org/wiki/Insulinp ump
BATCH NO:3; SRS Document 8

2 Overall Description
2.1 Product Overview
Overall Description section of this document gives an overview of the
functionality of the product. It describes the informal requirements and is
used to establish a context for the technical requirements specification in the
next sections. After Overall Description section, Requirements Specification
section of this document is written primarily for the developers and
describes in technical terms the details of the functionality of the product.
2.2Functionality
• Sugar level check.
• Quantity of insulin in the pump.
• Time interval.
• Digital meter reader.
• Memory set-up.
• Method of purification of apparatus
• Cost effective.
• Blood pressure and body temperature.
• Battery recharging (back-up battery).
• User friendly.
• Automatic and manual operations.
• Data storage in computer when device connected to a computer.
• Online doctor consultant and GPS based system
2.2 Design and Implementation Constraints
1. Object-Oriented Analysis (OOA) 2.Object-Oriented Design (OOD)
3.Object-Oriented Programming (OOP) 4.Java 5.Planttext 6.Plantuml text
editor 7.ArgoUML 8.Latex Overleaf 9.Angular node JS 10.Webflow and
Figma UI designer In design constraints we tell about limitations of our
system and software For Example, this could specify the requirement for
software to trace processing activity And we also tell about our system
BATCH NO:3; SRS Document 9

requirements For this type of software we require following type of system

hardware

2.3 Assumptions and Dependencies

One assumption is that it will always be used on the software installed in it
by default.
Users might have allocated with other applications, there may be scenarios
where the application does not work as intended or even at all.
BATCH NO:3; SRS Document 10

3 Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

he communication between the different parts of the system is important

since they depend on each other. However, in what way the communication
is achieved is not important for the system and is therefore handled by the
underlying operating systems for both the mobile application and the web
portal..

3.1.2 Hardware Interfaces

Since neither the IP nor the web portal have any designated hardware, it
does not have any direct hardware interfaces. The physical GPS is managed
by the GPS application in the IP and the hardware connection to the
database server is managed by the underlying operating system on the
mobile phone and the web server..

3.1.3 Software Interfaces

The IP communicates with the GPS application in order to get
geographical information about where the user is located and the visual
representation of it, and with the database in order to get the information
about the restaurants. The communication between the database and the
web portal consists of operation concerning both reading and modifying the
data, while the communication between the database and the IP consists of
only reading operations.

3.2 Functional Requirements

The functional requirements of IP are :
1) Safety Constraints
BATCH NO:3; SRS Document 11

The initial capacity of the insulin reservoir is set to 100. Maximum daily
dose, maximum single dose and minimum dose are set to 35, 5, and 1,
respectively. Maximum daily dose is defined the maximum dose that can be
delivered in 12 minutes that is scaled down from a day. Maximum single
dose is the maximum dose of insulin that can be delivered in a single
injection. Minimum dose is the dose that may be delivered to maintain an
existing trend in blood sugar levels.

2) Once the dose has been computed the simulator then must determine
whether the dose calculated is safe. It is essential due to the critical nature
of the simulator. There are two scenarios about safety requirements
depending on simulator mode –AUTORUN Mode and MANUALMode.

3) AUTORUN Mode: If maximum daily dose will be exceeded by the sum

of the dose calculated and the cumulative doze, the dose to be injected
should be calculated by subtracting the sum of the calculated doze and
cumulative dose of insulin from maximum daily dose. If the sum of the dose
calculated and cumulativedoze is less than or equal to maximum daily doze,
there are two possibilities: 1) If the dose calculated is less than or equal to

maximum single dose, deliver the insulin calculated;

2) If the single dose computed is too high, deliver the maximum single dose.
Alert the user and set the status to warning, if the safe constraints
(maximum single doze and/or maximum daily doze) broken.
4) MANUAL Mode
: If maximum daily dose is exceeded and/or maximum single dose is
exceeded, alert the user and set the status to warning. The maximum daily
and maximum single dose safety constraints will be overridden. In other
BATCH NO:3; SRS Document 12

words, amount of insulin units calculated will be injected as it is. 5) All

safety requirements are reset every 12 minutes
.
5)Insulin Dose Computation Requirments
1)The dose of insulin to be delivered shall be computed by measuring the
current level of blood sugar, comparing this to previous measured levels and
computing the required dose as described below. 2)The possible blood
sugar level is between 1 and 35 and the simulator shall measure the blood
sugar level and deliver insulin if required every 10 seconds. 3)The amount
of insulin to be delivered shall be computed according to the current sugar
reading as read by the simulator: a.If the reading is below the safe
minimum, no insulin shall be delivered. Alarm is on and a warning message
must be displayed. b.If the reading is within the safe zone, then insulin is
only delivered if the level of sugar is rising and the rate of increase of sugar
level is increasing. The amount of insulin required must be defined based on
the algorithm. c.If the reading is above the safe zone, insulin is delivered
unless the level of blood sugar is falling and the rate of decrease of the blood
sugar level is increasing. The amount of insulin required must be defined
based on the algorithm. d.The amount of insulin actually delivered may be
different from the computed dose as various safety constraints specified at .
There is a limit on the maximum dose to be delivered in a single injection
and a limit on the total cumulative dose in 12 minutes. If maximum daily
dose will be exceeded by the dose calculated, the dose to be injected should
be calculated by subtracting cumulative dose of insulin from maximum
daily dose. In the mean time the warning message shall be issued. This
message can be reset by the user within the 12 minute time window.
6)Whenever Error And Warning Requirments
errors and/or warnings occur, the simulator displays the corresponding
messages immediately. Since there is no insulin pump hardware for the
BATCH NO:3; SRS Document 13

simulator, the error messages such as “No Needle Unit,” “Sensor Failure,”
“Insulin Reservoir Removed,” and “pump Failure” are activated and
deactivated by the user. The error message, “No Insulin,” and the warning
messages such as “Maximum Daily Dose,” “Maximum Single Dose,” “Low
Insulin Level,” “Low Battery,” and “Low Blood Sugar Level” shall be
activated and deactivated by the simulator. These messages can be also
reset every 12 minute. Note that these messages reflect the status of the
insulin simulator. For example, “Low Battery” shall be issued if the status
of the battery has fallen to one-third of the full charge after the simulator
starts. Note that the level of battery shall decrease by 4 units every 30
second. Note that when the battery is completely empty, the simulator shall
stop. The table below specifies the error and warning messages and their
descriptions. When at least one error occurs, AUTORUN and MANUAL
modes are suspended until the errors are removed; simulation timer and
battery keep going.
7) Insulin Pump Status Requirments
1)The possible status of the insulin pump simulator includes SWITCHON,
AUTORUN, MANUAL and SWITCHOFF. 2)When the simulator is
loaded, it goes to SWITCHOFF mode. 3)The SWITCHON mode simulates
the behaviour of the pump when the user pushes the switch-onbutton.
When the user switches on the simulator, it goes to AUTORUN mode. It is
assumed that the user’s blood sugar is at SAFE stage (for example, the
blood sugar level is five. 4)Under normal operating conditions, the
simulator is defined by the AUTORUN. If the user increases the blood
sugar level, the simulator should respond properly based on. Unless the
user increases the blood sugar level, the simulator does not take any insulin
injections and the blood sugar level remains SAFE. Note that cumulative
dose is reset to zero at the beginning of the each 12 minutes period. The
AUTORUN can be further defined in three statuses: normal, warning, and
BATCH NO:3; SRS Document 14

error. In normal operation, the status is running; if a state exists which is

potentially hazardous such as low battery and low insulin level, then the
status is warning and The simulator keep functioning with displaying
warning messages; if a state exists such as pump fail, sensor fail, delivery
fail and insulin empty, the status is error. In the error state, normal
operation (AUTORUN mode and MANUAL mode) are suspended until the
errors are removed. 5)As soon as the user clicks a manual mode button, the
simulator goes to MANULA mode. The user is able to specify the amount
of insulin to be delivered by pressing the button within 5 second period.
The number of clicks specifies the number of units of insulin to be injected.
Insulin injection occurs when the five second time window is expired. Note
that safety checks, specified at Requirement V.1, are overruled. If maximum
daily dose and maximum single dose are exceeded, the amount of insulin is
injected while the simulator displays the corresponding warning messages.
Cumulative dose and the last dose of insulin are still updated. After insulin
injection, the simulator automatically goes to the AUTORUN mode. Note
that the blood sugar level will be updated when the simulator goes back to
the AUTORUN mode. 6)When switch off, the simulator goes to the
SWITCHOFF mode that clear all information. When the user switches on,
the simulator starts new
Graphical User Interface Requirments
1) A power on/off switch shall be displayed.
2) A MANNUAL button is used to inject insulin manually. The number of
clicks within five second is the amount of insulin injected.
3) Display the current mode (AUTORUN, MANNUAL).
4) All values are reset every 12 minutes.
5) A current blood sugar level and at least two previous levels should be
displayed. Implementing a graphical representation (with numerical values)
to a current sugar level and previous sugar levels is required.
BATCH NO:3; SRS Document 15

6) The amount of the last dose of insulin to be administered shall be

displayed.
7) The amount of the cumulative of insulin injected shall be displayed.
8) The amount of time the simulator run shall be displayed. 9) Current
real-time shall be displayed.
10) The status of battery shall be displayed with a numeric value and
progress bar.
11) The status of the insulin reservoir shall be displayed.
12) Warning and error messages shall be displayed in the single line text
box. If there is one message, keep displaying that message. When there is
more than one message, each message is displayed for 3 seconds until all
messages have been displayed. The display sequence then restarts with the
first message unless warnings and errors are clear. Also an audio alarm for
each message shall be given.
13) Users are allowed to change the current blood sugar level in order to
test the insulin pump
simulator’s reaction to varying blood sugar readings. 14) If users decide
that they require insulin immediately they can manually override the
automatically delivering system. Users specify how much insulin to be
injected by pressing a
button. The number of button presses within 5 second period specifies the
number of units of
SWITCH-ON AUTORUN MANUAL SWITCH-OFF insulin to be injected.
The system must be in manual mode for this to be operational and you may
assume that after the first press is detected, the number of presses is
counted automatically.
3.3 Use Case Model
BATCH NO:3; SRS Document 16
BATCH NO:3; SRS Document 17
BATCH NO:3; SRS Document 18

USE CASE CODE

@startuml
skinparam actorStyle awesome
left to right direction
actor patient as p
rectangle Insulinp umpusecase(sendstheglucosereadings)ass
usecase (control signals) as signals
usecase (checks hardware issues) as issues
package controller
actor controller as c
rectangle statuso fg lucose
usecase (high) as h
usecase (normal) as n
usecase (low) as l
package pump
usecase (amount of insulin) as amount
usecase (delivery of insulin) as delivery
usecase (insulin reservoir ) as reservoir
package monitor
usecase (displaying record) as d1
usecase (warning messages) as d2
usecase (display error) as d3
p –s
s –signals
signals –c
c –h
c –n
c –l
h ..¿amount:¡¡includes¿¿
BATCH NO:3; SRS Document 19

n ..¿amount:¡¡includes¿¿
h ..¿d2:¡¡includes¿¿
l ..¿d1:¡¡includes¿¿
amount –delivery
delivery ..¿ reservoir:¡¡include¿¿
p ..¿monitor:¡¡extend¿¿
delivery ..¿p:¡¡include¿¿
c – issues
issues ..¿ d3:¡¡includes¿¿
issues ..¿delivery:¡¡extends¿¿
delivery ..¿monitor:¡¡extends¿¿
@enduml
4 Other Non-functional Requirements

4.1 Performance Requirements

By and large, the performance requirements for the simulator are classified
into six groups: safety requirements, computation requirements,
after-insulin-injection-blood-sugar-level requirements, insulin pump status
requirements, and graphical user interface requirements

4.2 Safety and Security Requirements

1) The initial capacity of the insulin reservoir is set to 100. Maximum daily
dose, maximum single dose and minimum dose are set to 35, 5, and 1,
respectively. Maximum daily dose is defined the maximum dose that can be
delivered in 12 minutes that is scaled down from a day; Maximum single
dose is the maximum dose of insulin that can be delivered in a single
injection; Minimum
dose is the dose that may be delivered to maintain an existing trend in
blood sugar levels. 2) Once the dose has been computed the simulator then
BATCH NO:3; SRS Document 20

must determine whether the dose

calculated is safe. It is essential due to the critical nature of the simulator.
There are two scenarios about safety requirements depending on simulator
mode – AUTORUN Mode and MANUAL Mode.
3) AUTORUN Mode: If maximum daily dose will be exceeded by the sum
of the dose calculated and the cumulative doze, the dose to be injected
should be calculated by subtracting the sum of the calculated doze and
cumulative dose of insulin from maximum daily dose. If the sum of the dose
calculated and cumulative doze is less than or equal to maximum daily
doze, there are two possibilities
: 1) If the dose calculated is less than or equal to maximum single dose,
deliver the
insulin calculated; 2) If the single dose computed is too high, deliver the
maximum single dose
Alert the user and set the status to warning, if the safe constraints
(maximum single doze and/or maximum daily doze) broken.
4) MANUAL Mode: If maximum daily dose is exceeded and/or maximum
single dose is exceeded,
alert the user and set the status to warning. The maximum daily and
maximum single dose safety
constraints will be overridden. In other words, amount of insulin units
calculated will be injected as it is.
5) All safety requirements are reset every 12 minutes
4.3)Software Quality Attriibutes:
There are a number of attributes of software that can serve as requirements.
• Reliability : Our system is reliable because we use best type of hardware
to make our system reliable we use :
Compact design
Flexible handling
BATCH NO:3; SRS Document 21

Rich features
Errors can occurs with warning also gives the tips to repair
High testing of this software we done so we say that is this system is reliable
This software have high fault tolerance
• Security:
We secure data and resources
Analysis and design of this is secure
Security design of this software is best
Confidentiality is great application data base on the critically
Access privilege controls in place
Identifying the mode of data transmitted or processed within the application
Design application related infrastructure and designing the technical
requirements
Replication and redundancy in data base system
• Maintainability:
To make higher maintainability higher the bug fixing speed Modular design
Un needed complexity
We also make a portion for duplicate code if system crash we use duplicate
code

AIM: to create a class diagram for insulin pump.

DESCRIPTION: The overall approach used to produce the insulin pump software was
to emulate the hardware organisation by producing separate software objects (classes) for
each distinguishable hardware object. Of all of these software objects the controller object
is where the bulk of the computation within the system is carried. It is within the controller
that the dose of insulin to be delivered is computed and where the self tests are performed.
Working in together with the controller object there is a clock object which runs in a thread,
constantly determining how much time has lapsed since the software was started or the timer
was reset (which happens every 24 hours). Then periodically, at every interval specified the
clock triggers certain events required to be performed by the system. In order to present
information to the user, a software object called display is used to create a graphical user
BATCH NO:3; SRS Document 22

interface (GUI), the data is then presented to the user via text boxes positioned on the GUI.
The remaining software objects model the peripheral hardware units, the software contained
within these objects simply records the current state of the hardware unit and for the purpose
of simulation, provides the functionality to change that state. Together the aforementioned
objects combine to produce the working insulin pump system. However one other object is
also provided, the simulator software object. This object runs in a thread parallel to the
insulin pump software and provides the user with the functionality to perform a simulation
of real-world events that would affect the pump software in differing manners. The simulator
facilitates the testing process, making it quicker and easier to perform the necessary testing
required in order to determine whether the insulin pump system is adequately safe.
OBJECT INTERACTION – OBJECT CLASSES:
Object classes, represented here in UML, detail the make up of the objects within the system.
The objects are represented by three sections: 1. The name of the object class 2. The class
attributes 3. The operations associated with the object class

CODE:
BATCH NO:3; SRS Document 23
BATCH NO:3; SRS Document 24
BATCH NO:3; SRS Document 25
BATCH NO:3; SRS Document 26
BATCH NO:3; SRS Document 27
BATCH NO:3; SRS Document 28
BATCH NO:3; SRS Document 29

OUTPUT:
BATCH NO:3; SRS Document 30
BATCH NO:3; SRS Document 31

AIM:To draw a sequence diagrams for insulin pump.

DESCRIPTION: Object Interaction – Sequence Diagrams In order to illustrate the se-

quence of object interactions that occurs in the insulin pump software the following sequence
diagrams have been produced:
Sequence of object interactions involved in the automatic delivery of insulin The diagram
assumes that a reading has already been given to the Sensor object before the clock begins
the sequence of interactions. The final two sequences show how information that is intent
to be output to the user is initially passed to the clock object where it is stored in a buffer.
The contents of this buffer are then continually displayed to the user one after another for a
period of five seconds each.
Sequence of object interactions involved in the manual delivery of insulin
The diagram shows that after the user has switched the insulin pump system to the man-
ual mode they must then input how much insulin they wish to administer, this is done so
by pressing the AdministerInsulinBut button as many times as is required in a five second
period.

CODE:

INSULIN PUMP SEQUENCE DIAGRAM:

@startuml

actor patient as p
participant Sensor[
=Sensor
—-

””sends the glucose readings””

]
v actor controller as c
BATCH NO:3; SRS Document 32

participant status[
=Status of glucose
—-
””includes the level of glucose””
]
participant amount[
=Amount
—-
””amount of insulin to be delivered””
]
participant Issues [
=Issues
—-
””checks hardware issues””
]
participant delivery[
=Delivery
—- ””delivery of insulin””
]

participant displaye rrors[

= displaye rrors
−−−−
””Errorsardisplayed””
]
participantdisplayr ecord[
= displayr ecord
−−−−
””Recordsaredisplayed””
]
participantwarningm essages[
= warningm essages
−−−−
”W arningmessagesaredisplayed””
]
BATCH NO:3; SRS Document 33

p− > Sensor : givesblood

Sensor− > c : sendsthecontrolsignals
c− > status : computesthelevelof glucose
groupStatuso fg lucose[Status]
groupHigh[high]
status− > warningm essages : yourbloodsugarlevelsarehigh
whenlevelsareHIGH
status− > amount : amountof insulintobedeliveredis
calculatedwhenlevelsareHIGH
end
groupN ormal[normall evel]
status− > amount : amountof insulintobedeliverediscalculated
whenlevelsareN ORM AL
end

groupLow[low]
status− > displayr ecord : displaysthereadingswhenlevelsareLOW
end
end
amount− > delivery : theamountof insulintobedeliveredis
delivered
c− > Issues : checksif thereareanyissues

delivery -¿ p:the insulin is delivered to patient via needle

Issues -¿ delivery: if needle not inserted properly
Issues -¿ displaye rrors : if needlenotinsertedproperly
delivery− > displayr ecord : theinsulindeliveredis
madeasarecord
displayr ecord− > p : therecordisdisplayedandletpatientknow
@enduml
2.CON T ROLLERSEQU EN CEDIAGRAM :
@startuml
actorcontrollerasc
c− > status : computesthelevelof glucose
groupStatuso fg lucose[Status]
BATCH NO:3; SRS Document 34

groupHigh[high]
status− > warningm essages : yourbloodsugarlevelsarehigh
whenlevelsareHIGH
status− > amount : amountof insulintobedeliveredis
calculatedwhenlevelsareHIGH
end
groupN ormal[normall evel]
status− > amount : amountof insulintobedeliverediscalculated
whenlevelsareN ORM AL
end
groupLow[low]
status− > displayr ecord : displaysthereadingswhenlevelsareLOW
end
end

c− > Issues : checksif thereareanyissues

@enduml
3.P U M P SEQU EN CEDIAGRAM :
@startuml
participantamount[
= Amount
−−−−
””amountof insulintobedelivered””
]
participantdelivery[
= Delivery
−−−−

””deliveryof insulin””
]
amount− > delivery : theamountof insulintobedeliveredisdelivered
delivery− > displayr ecord : theinsulindeliveredismadeasarecord
delivery− > displayr ecord : theinsulindeliveredismadeasarecord
@enduml
4.M ON IT ORSEQU EN CEDIAGRAM :
@startuml
BATCH NO:3; SRS Document 35

participantdisplaye rrors[
= displaye rrors
−−−−
””Errorsardisplayed””

]
participantdisplayr ecord[
= displayr ecord
−−−−
””Recordsaredisplayed””
]
participantwarningm essages[
= warningm essages
−−−−
”W arningmessagesaredisplayed””
]
displayr ecord− > p : therecordisdisplayedandletpatientknow
Issues− > displaye rrors : if needlenotinsertedproperly
delivery− > displayr ecord : theinsulindeliveredismadeasarecord
@enduml

hardware
p3–¿p3:checks hardware
BATCH NO:3; SRS Document 36

OUTPUT:
BATCH NO:3; SRS Document 37

AIM:To draw a use case diagramd diagrams for insulin pump.

DESCRIPTION:
A collaboration diagram, also known as a communication diagram, is an illustration of the
relationships and interactions among software objects in the Unified Modeling Language
BATCH NO:3; SRS Document 38

(UML). These diagrams can be used to portray the dynamic behavior of a particular use
case and define the role of each object..

code:
@startuml
skinparam actorStyle awesome
left to right direction
actor patient as p
rectangle Insulinp umpusecase(sendstheglucosereadings)assusecase(controlsignals)assignalsusecase(che

package monitor
usecase (displaying record) as d1
usecase (warning messages) as d2
usecase (display error) as d3

p –s
s –signals
signals –
c –h
c –n
c –l
h ..¿amount:¡¡includes¿¿
n ..¿amount:¡¡includes¿¿
h ..¿d2:¡¡includes¿¿
l ..¿d1:¡¡includes¿¿
amount –delivery
delivery ..¿ reservoir:¡¡include¿¿
p ..¿monitor:¡¡extend¿¿
delivery ..¿p:¡¡include¿¿
c – issues
issues ..¿ d3:¡¡includes¿¿
issues ..¿delivery:¡¡extends¿¿
pump – monitor
@enduml
BATCH NO:3; SRS Document 39

output:

AIM:To draw a sequence diagrams for insulin pump.

DESCRIPTION:
A collaboration diagram, also known as a communication diagram, is an illustration of the
relationships and interactions among software objects in the Unified Modeling Language
(UML). These diagrams can be used to portray the dynamic behavior of a particular use
case and define the role of each object..

code:
@startuml

object ”Patient” as p
object ”Sensor” as s
object ”Controller” as c
object ”Amount of Insulin” as a
object ”Delivery of insulin” as d
object ”Monitor” as m
p : —INPUT–
BATCH NO:3; SRS Document 40

p : Patientn ame
p : P atientI D
s : − − −IN P U T − − −
s : T akesb lood
s : − − −OU T P U T − − −
s : Glucoser eadings
s : Controls ignals
c : − − −IN P U T − − −
c : Glucoser eadingsi nput
c : Controls ignals
c : − − −OU T P U T − − −
c : Statuso fG lucose
c : W arningm essages
c : Hardwarei ssues
c : Alarm
c : N eedlea ssembly
a : − − −IN P U T − − −
a : Statuso fG lucose
a : − − −OU T P U T − − −
a : Amounto fi nsulint ob ei nserted
d : − − −IN P U T − − −

d : Amounto fi nsulint ob ei nserted

d : Amounto fI nsulini nI nsulinr eservoir
d : − − −OU T P U T − − −
d : Deliveryo fs ignals
d : Deliveryo fi nsulin
m : − − −IN P U T − − −
m : W arnings ignals
m : Insulind elivereds ignals
m : Hardwarei ssues ignals
m : − − −OU T P U T − − −
m : Displayr ecord
m : Displayw arning
m : Displayp reviousr eadings
m : Displaye rrors
BATCH NO:3; SRS Document 41

p ∗ − − m : 10.T herecordisdisplayed
p − −| > s : 1.Givesblood
s − −| > c : 2.Sendsthecontrolsignals
a − −od
d − −om : 9.T heinsulindeliveredisdisplayed
c − −oa
d − − ∗ p : 6.T heinsulinisdeliveredtopatient
a − −om : 4.T heamountof insulintobedelivered
c − −| > c : 3.Computesthesugarlevels
c − −| > c : 5.checksf orhardwareissues
c − −| > d : 7.if needlenotinsertedproperly
c − −| > m : 8.if needlenotinsertedproperly
a − −| > m : 11.Displaythestatusof glucose
@enduml
output:
BATCH NO:3; SRS Document 42
BATCH NO:3; SRS Document 43

AIM:
To estimate the cost of the personal insulin pump in a cocmo model

DESCRIPTION:
ocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines
of Code. It is a procedural cost estimate model for software projects and is often used as a
process of reliably predicting the various parameters associated with making a project such
as size, effort, cost, time, and quality. It was proposed by Barry Boehm in 1981 and is based
on the study of 63 projects, which makes it one of the best-documented models.

The key parameters which define the quality of any software products, which are also an
outcome of the Cocomo are primarily Effort Schedule:

Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
Schedule: Simply means the amount of time required for the completion of the job, which
is, of course, proportional to the effort put in. It is measured in the units of time such as
weeks, months.

Different models of Cocomo have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of constant to be
used in subsequent calculations. These characteristics pertaining to different system types
are mentioned below.

Boehm’s definition of organic, semidetached, and embedded systems:

Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also
the team members have a nominal experience regarding the problem.
Semi-detached – A software project is said to be a Semi-detached type if the vital charac-
teristics such as team size, experience, knowledge of the various programming environment
BATCH NO:3; SRS Document 44

lie in between that of organic and Embedded. The projects classified as Semi-Detached are
comparatively less familiar and difficult to develop compared to the organic ones and require
more experience and better guidance and creativity. Eg: Compilers or different Embedded
Systems can be considered of Semi-Detached type.
Embedded – A software project requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size
than the other two models and also the developers need to be sufficiently experienced and
creative to develop such complex models.
All the above system types utilize different values of the constants used in Effort Calculations.

Types of Models: COCOMO consists of a hierarchy of three increasingly detailed and ac-
curate forms. Any of the three forms can be adopted according to our requirements. These
are types of COCOMO model:

Basic COCOMO Model

Intermediate COCOMO Model
Detailed COCOMO Model
The first level, Basic COCOMO can be used for quick and slightly rough calculations of
Software Costs. Its accuracy is somewhat restricted due to the absence of sufficient factor
considerations.

Intermediate COCOMO takes these Cost Drivers into account and Detailed COCOMO ad-
ditionally accounts for the influence of individual project phases, i.e in case of Detailed it
accounts for both these cost drivers and also calculations are performed phase-wise hence-
forth producing a more accurate result. These two models are further discussed below

Estimation of Effort: Calculations –

Basic Model –
E= a(KLOC)b
time = c(Ef f ort)d
P ersonrequired = Ef f ort/time
T heabovef ormulaisusedf orthecostestimationof f orthebasicCOCOM Omodel, andalsoisusedinthesubsequ
BATCH NO:3; SRS Document 45

The effort is measured in Person-Months and as evident from the formula is dependent on
Kilo-Lines of code.
The development time is measured in months.
These formulas are used as such in the Basic Model calculations, as not much consideration
of different factors such as reliability, expertise is taken into account, henceforth the
estimate is rough.
Intermediate Model – The basic Cocomo model assumes that the effort is only a
function of the number of lines of code and some constants evaluated according to the
different software systems. However, in reality, no system’s effort and schedule can be
solely calculated on the basis of Lines of Code. For that, various other factors such as
BATCH NO:3; SRS Document 46

reliability, experience, Capability. These factors are known as Cost Drivers and the
Intermediate Model utilizes 15 such drivers for cost estimation.
Classification of Cost Drivers and their attributes:
(i) Product attributes –
Required software reliability extent
Size of the application database
The complexity of the product
(ii) Hardware attributes –
Run-time performance constraints
Memory constraints
The volatility of the virtual machine environment
Required turnabout time
(iii) Personnel attributes –
Analyst capability
Software engineering capability
Applications experience
Virtual machine experience
Programming language experience
(iv) Project attributes –
Use of software tools
Application of software engineering methods
Required development schedule

2.png

Detailed Model –
Detailed COCOMO incorporates all characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step of the software engineering process.
The detailed model uses different effort multipliers for each cost driver attribute. In
detailed cocomo, the whole software is divided into different modules and then we apply
COCOMO in different modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
Planning and requirements
BATCH NO:3; SRS Document 47

System design
Detailed design
Module code and test
Integration and test
Cost Constructive model
The effort is calculated as a function of program size and a set of cost drivers are given
according to each phase of the software lifecycle.

cocomo-1.png

cocomo-2.png
BATCH NO:3; SRS Document 48

AIM:
To calculate the Function point for the persional insulin pump
DESCRIPTION:
Function Point Analysis was initially developed by Allan J. Albercht in 1979 at IBM and it
has been further modified by the International Function Point Users Group (IFPUG).
The initial Definition is given by Allan J. Albrecht: FPA gives a dimensionless number
defined in function points which we have found to be an effective relative measure of
function value delivered to our customer.

FPA provides a standardized method to functionally size the software work product. This
work product is the output of software new development and improvement projects for
subsequent releases. It is the software that is relocated to the production application at
project implementation. It measures functionality from the user’s point of view i.e. on the
basis of what the user requests and receives in return.

Function Point Analysis (FPA) is a method or set of rules of Functional Size Measurement.
It assesses the functionality delivered to its users, based on the user’s external view of the
functional requirements. It measures the logical view of an application, not the physically
implemented view or the internal technical view.

The Function Point Analysis technique is used to analyze the functionality delivered by
software and Unadjusted Function Point (UFP) is the unit of measurement.

Objectives of FPA: The objective of FPA is to measure the functionality that the user
requests and receives. The objective of FPA is to measure software development and
maintenance independently of the technology used for implementation. It should be simple
enough to minimize the overhead of the measurement process. It should be a consistent
measure among various projects and organizations.

Types of FPA:
Transactional Functional Type –
External Input (EI): EI processes data or control information that comes from outside
the application’s boundary. The EI is an elementary process.
External Output (EO): EO is an elementary process that generates data or control
information sent outside the application’s boundary.
External Inquiries (EQ): EQ is an elementary process made up of an input-output
combination that results in data retrieval.
BATCH NO:3; SRS Document 49

Data Functional Type –

Internal Logical File (ILF): A user identifiable group of logically related data or control
information maintained within the boundary of the application.
External Interface File (EIF): A group of users recognizable logically related data
allusion to the software but maintained within the boundary of another software.
Counting Function Point (FP):

Step-1:
F = 14 * scale
Scale varies from 0 to 5 according to character of Complexity Adjustment Factor (CAF).
Below table shows scale:
0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential
Step-2:
Calculate Complexity Adjustment Factor (CAF).
CAF = 0.65 + ( 0.01 * F )
Step-3:
Calculate Unadjusted Function Point (UFP).

3.png

Step-4:
Calculate Function Point.
FP = UFP * CAF

function pointer.png
BATCH NO:3; SRS Document 50

AIM:
Illustrate the use of the Gantt project.
Description:
A gantt chart is a horizontal bar chart used in project management to visually represent a
project plan over time. Modern gantt charts typically show you the timeline and
status—as well as who’s responsible—for each task in the project.

Here’s a quick look at the details a gantt chart enables you to capture at a
glance:

How a project breaks down into tasks

When each task will begin and end

How long each task will take

Who’s assigned to each task

How tasks relate to and depend on each other

When important meetings, approvals, or deadlines need to happen

How work is progressing in a project

The full project schedule from start to finish

In other words, a gantt chart is a super-simple way to communicate what it will take to
deliver a project on time and budget. That means it’s a whole lot easier to keep your
project team and stakeholders on the same page from the get-go.

Gantt charts may seem complicated at first. But once you learn the basics, you’ll be able
to read and create a gantt chart easily and tell exactly where your projects are and what
needs to happen to guide them to success.

Elements of a gantt chart Reading a gantt chart really comes down to

understanding how the different elements come together to make a gantt chart
work.
BATCH NO:3; SRS Document 51

Let’s review some basic terminology so you understand the key parts of a gantt
chart and how they function in a project plan: Task list: Runs vertically down the

left of the gantt chart to describe project work and may be organized into groups and
subgroups

Timeline: Runs horizontally across the top of the gantt chart and shows months, weeks,
days, and years

Dateline: A vertical line that highlights the current date on the gantt chart

Bars: Horizontal markers on the right side of the gantt chart that represent tasks and
show progress, duration, and start and end dates

Milestones: Yellow diamonds that call out major events, dates, decisions, and deliverables

Dependencies: Light gray lines that connect tasks that need to happen in a certain order

Progress: Shows how far along work is and may be indicated by percent complete and/or
bar shading

Resource assigned: Indicates the person or team responsible for completing a task
Here’s a gantt chart with these components highlighted. This gantt chart highlights 8
features every gantt chart should include: