Académique Documents
Professionnel Documents
Culture Documents
1. Context: In this Fire Safety system there are many operation which are
automated which ease the work for the working of the Fire Rescue Center. Which
reduces the requirement for the manual labour and the automated tasks will be error
free as they will only work as they are programmed whereas doing work manually
there is always a possibility of human error.
2. Information: The existing Fire Rescue Center system is slow as every task is
being performed by the human being and comparing the computer task speed with a
computer is not fair.
4. Functions:
▪ FSS Branch: Every branch will have its unique identification number and a
branch name. From this module, we can easily identify the branch location
and the other information like employees working at that branch.
For the communication purpose, there will a permanent phone number. The
branch module will also help bank find out about their performance at a different
location so they evaluate on this improve the customer service quality. There will
always some kind of special benefit for the people of the home branch.
1 | Page
Every customer has their unique account number and the FSS will identify you by
only that account number. The account number will be same for the entire branch
for that particular FSS.
5. Performance:
6. Problem decomposition:
Branch: This entity contains the details about the location of the branch. This will not
help management but separate the employee from branch to branch and
customers.
-Branch_ id: This will be the primary key for the entity. This will help to search
and sorting uniquely in the table of branch entity.
-Branch_ name: This attribute will help in verifying the identity of the branch if the
branch is led to confusion.
-Branch_ city: It will contain the city where the branch is
located.
-Branch_ phone: This phone number will be helped in communicating with the
branch. This number is only for the banking use not for public use. For the public,
there will be a single number at all the bank branches.
o Employee: The employee entity contains all the information about the
employees working in different branches of the bank. This will enable them to
manage the employee data easily. Searching the information will just a few
clicks. It will have all the necessary attributes required for the employer. It has
the following attributes:
-Employee_ id: This will be the primary key for this entity. It will help in identifying
the particular employee easily. This gets useful when two employees have a
similar name like conditions.
2 | Page
-Employee_ address: In any case when the employee address needed for
example sending any email or documents at the employee’s residence.
-Department_ id: The department will have a different id for manager, clerk and
other designation so we can find the job profile of the employee.
-Account_ number: Every employee will have the account in the FSS this will
give their account details.
o Department: This entity will help in keeping the track of the job profile of
the employee. Each profile will be assigned to one department in which will
have the details about their job. It will have the following attributes:
-Department_ id: This is the primary key for the table it will help identify each job
profile uniquely in with the department.
-Head_ of_ department: It will take the employee id as a value which will define
that a particular person/employee is the head of that department.
o Customer: This entity of Fire Safety system has the details of the
customer. It will not contain the FSS details but personal details of the
customer. After opening an account every user will get one unique account
number. It has the following attributes:
-Customer_ id: This is the primary key the particular table. It will be used to find
the customers personal details.
-Customer_ name: The customer will be for the document verification for the
account opening.
-Branch_ id: This will tell about the home branch of the customer. Like where the
user has opened his/her account in the bank. -Account_ number: This will link the
account to the user’s banking details like the transaction or the balance of this
account holder.
o Accounts: This table will contain all the FSS account details of the
customer.
Live tracking, time for reaching and
history.
-Account_ number: This is the primary key for the particular table. It will be linked
with the customer table’s attribute of customer id. Each customer id will have a
separate account number.
- Branch_ id: To identify the location of the branch where the customer has
opened the account.
-Customer_ id: This is required to link the correct account number to particular
customer id.
P R PS
4 | Page
PRACTICAL: -2
• Advantages
1. Simple and easy to understand and use 2. Phases are processed and
completed one at a time. 3. Works well for smaller projects where
requirements are very well understood. 4. Clearly defined stages. 5. Easy to
arrange tasks.
• Disadvantages
1. No working software is produced until late during the life cycle. 2. High amounts of
risk and uncertainty. 3. Not a good model for complex and object-oriented projects.
4. Poor model for long and ongoing projects. 5. Not suitable for the projects where
requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process
model.
Incremental Model
• Advantages
• Disadvantages
5 | Page
Prototype Model
• Advantages
• Disadvantages
1. Costly w.r.t time as well as money. 2. It is very difficult for the developers to
accommodate all the changes demanded by the
customer. 3. After seeing an early prototype, the customers sometimes demand the
actual product to
be delivered soon. 4. The customer might lose interest in the product if he/she is not
satisfied with the initial
prototype.
RAD Model
• Advantages
1. Use of reusable components helps to reduce the cycle time of the project. 2.
Feedback from the customer is available at initial stages. 3. Reduced costs as fewer
developers are required. 4. It is easier to accommodate changing requirements due
to the short iteration time spans.
• Disadvantages
• Advantages
1. Risk Handling: The projects with many unknown risks that occur as the
development
proceeds, in that case.
6 | Page
2. Good for large projects: It is recommended to use the Spiral Model in large and
complex
projects. 3. Flexibility in Requirements: Change requests in the Requirements at
later phase can be
incorporated accurately by using this
model.
• Disadvantages
1. Complex: The Spiral Model is much more complex than other SDLC
models. 2. Expensive Spiral Model is not suitable for small projects as it is
expensive.
JUSTIFICATION
From all these software engineering models we will be using incremental model
for our Library
is easier to test and debug during a smaller iteration. In this model customer can
respond to each
built.
7 | Page
Incremental model would be suitable because of following
reasons:
• Major requirements are already defined; however, some details can evolve with
time.
• With the help of this model we can make the first iteration or the first module
of the application or
product totally ready and can be demoed to the customers.Likewise in the second
iteration the
other module is ready and integrated with the first module. Similarly, in the third
iteration the whole product is ready and integrated. Hence, the product got ready
step by step.
P R PS
8 | Page
PRACTICAL 3
1. Introduction
1.1 Purpose
The main purpose is to provide easy access to important information to your
citizens. App users have the ability to receive instant push notifications from your
fire department, follow along a fire safety checklist, view a map of station locations,
access a post-fire checklist and more – all from an app! Scope ❖ The Fire Safety
1.2 Overview
The proposed Fire safety system will take care of the safety details at any point of
time in day. The Fire safety system will make sure that the fire department get the
emergency notification and details on time and they could react accordingly.
2. General Description
With the increase in population the amount of man-made fire has increased. The
Fire Safety System focuses on improving the safety of citizens through a smart
way and decrease the amount of loss of human life and property. The Fire Safety
System provides you the way to alert the people and fight the fire as rapidly as
we can through phone. The Fire Safety System is developed on the android
platform.
3. Functional Requirements
3.1 Description
Fire Safety System will also provide all necessary services for databases
such as creating, deleting, updating and searching information. It will also
provide GPS location and other important details like where the fire has
spread through the
9 | Page
building. The design of product interface to be developed will be supported by
Microsoft IE, Netscape Navigator and Opera browsers. User interfaces will be
ergonomically easy to use. 3.2 Criticality
This issue is essential to the overall system. All the modules provided with the
software must fit into this Graphical User Interface and accomplish to the
standard defined. 3.3 Technical Issue
In order to satisfy this requirement the design should be simple and all the
different interfaces should follow a standard template. There will be the possibility
of connectivity issue. 3.4 Cost and Schedule
❖ App Size ❖ Development rates as per the regions ❖ Once, all of the
above mentioned factors are considered, we can say the actual cost of
development will range between 50000Rs-250000, while if you choose to
integrate advanced features or develop the app for more platforms, then the
cost would automatically increase.
3.5 Risks
The major risk is hardware failure which will delay the alert which is lethal.
Issues like connectivity issue can increase the risk as well.
All user interfaces should be able to interact with the user management
module and a part of the interface must be dedicated to the login/logout
module.
Usage data for management of Fire Safety system. Retain all required
records. Management of firefighters. Usage data must not identify
individuals.
4. Interface Requirements
4.1 User Interfaces
4.1.1 GUI (Graphical User Interface)
Most users interact with this Fire Safety System through graphical user
interfaces (GUIs).
10 | Page
GUI characteristics:
• Windows
• Icons
• Menus
•GPS
• Graphics GUI is Fast, full-screen interaction is possible with immediate access to
anywhere on the screen. 4.1.2 CLI (Command Line Interface)
❖ User types commands to give instructions to the system e.g. UNIX. ❖
May be implemented using cheap terminals. ❖ Easy to process using
compiler techniques ❖ Commands of arbitrary complexity can be created
by command
combination ❖ Concise interfaces requiring minimal typing can be
created 4.1.3 API (Application Program Interface)
We use Simple REST API for the Fire Safety system. The main
entities/resources served by the API are:
❖ Alert ❖
Citizens
4.2 Hardware Interface 5. T he existing Local Area Network (LAN) will be
users and 6. also for updating the Library Catalogue 7. The existing Local Area
Network (LAN) will be used for collecting data from the users
and 8. also for updating the Library
Catalogue
The existing Local Area Network (LAN) will be used for collecting data from
the users and also for updating the records. Server Side:
❖ Operating System: Windows 9x/XP, Windows ME
11 | Page
❖ Processor: Pentium 3.0 GHZ or higher
❖ RAM: 256Mb or more ❖ Hard Drive:
10GB or more
Client Side:
4.3 Communication
Interface
The Fire Safety System will be connected to the Man. The user
must connect to the internet: ❖ Dialup Modem of 52kbps ❖
Broadband Internet ❖ Dialup or Broadband Connection with an
internet Provider. 4.4 Software Interface
A firewall will be used with the server to prevent unauthorized access to the
system
❖ Database: SQL Server ❖ Application: ASP (Active Server Pages) ❖
Web Server: IIS (Internet Information Services) is a powerful Web Server
that provides a highly reliable, manageable and scalable Web application
infrastructure
5. Performance
Requirements
❖ Operating system: Windows ❖ Hard disk: 30 GB ❖ RAM: 512 MB ❖
Processor: Pentium(R) Dual-core CPU or Above ❖ The system shall
accommodate high number of books and users without any
fault. ❖ Responses to view information shall take no longer than 5 seconds to
appear on
the screen.
6. Design
Constraints
Each Building will be provided with unique ID which will give all the details of the
building and each individual user will be provided with their own user Id as well. If
there is a fire breakout the user in the building will be marked for the
administration to react and save them accordingly.
12 | Page
7. Other Non-Functional
Attributes
7.1 Security
❖ System will use secured database. ❖ Normal users can just read
information but they cannot edit or modify anything
except their personal and some other information. ❖ System will have different
types of users and every user has access constraints. ❖ Proper user
authentication should be provided ❖ No one should be able to hack users’
password ❖ There should be separate accounts for admin and members
such that no member
can access the database and only admin has the rights to update the
database. 7.2 Binary Compatibility
Two system versions are Binary Compatible with each other if the compiled
bytecode of these versions can be interchanged without causing Linkage
Errors.
7.3 Reliability
❖ Its cost is under the budget and it is desirable to aim for a system with a
minimum cost subject to the condition that it must satisfy the entire
requirement. ❖ Clearly identifying the information needed by the user, the
source of the
information and outputs expected from the system. ❖ System testing is properly
done to avoid bugs and unexpected errors. ❖ Database is properly
normalized ❖ Risk Analysis is also done and security measures are taken to
avoid lethal and
non-lethal problems and unauthorized access. ❖ System recovery will
be fast because of proper backup systems
7.4 Maintainability
13 | Page
7.5 Portability
7.6 Extensibility
❖ Extensibility is a measurement of a piece of technology’s capacity to
append
additional elements and features to its existing structure. ❖ A software program, for
example, is considered extensible when its operations may be augmented
with add-ons and plugins. Extensible programming languages have the ability
to define new features and introduce new functionality within them.
7.7 Reusability
❖ The basic approach of reusability is to configure and specialize
pre-existing
software components into viable application systems. ❖ Such source code
components might already have associated specifications and designs
associated with their implementations, as well as have been tested and
certified. ❖ Therefore, assembling reusable software components is a
strategy for decreasing software development effort in ways that are
compatible with the traditional life cycle models.
7.9 Resource
Utilization
14 | Page
Fire Safety System helps in maintaining safety and data. This helps
administrator to have a proper log of buildings and any particular building may
require maintenance at any given time like detector’s stopped responding.
This kind of Fire Safety System is universal but they can be customized as
per individual’s requirement also. It’s easy to use interface and immediate
reporting make things easier for the administration. With the help of system,
we can:
7.10 Serviceability
❖ Serviceability is the measure of and the set of the features that support the
ease and speed of which corrective maintenance and preventive
maintenance can be conducted on a system.
8. Operational
Scenarios
a. First
❖ Fire ignited in a building. ❖ Fire detectors detect fire.
❖ Alarm sounds and alerts send to warn about fire. ❖
Records are displayed to the fire station and they act. ❖
Logs are recorded after rescue. b. Second
❖ Building is to be registered in system. ❖ Information is
recorded in database and alarms are set in building. ❖ Users are
registered in the system. ❖ Building is assigned to the nearest
Fire Stations.
9. Preliminary Schedule
We may have the technology, but that doesn’t mean we have the skills required
to properly apply the technology in this project. Initially, there will be time domain
to be agreed upon between us and the stakeholders (client). True, all information
systems professionals can learn new technologies. However, that learning curve
will impact the technical feasibility of the Fire Safety System, specifically, it will
impact the schedule.
15 | Page
App Size: The size of an app depends on a number of factors, such as the
amount of features added to the app, how advanced features that you add, more
devices the app is designed for, number of app platforms you choose to develop
the app on, and also the third-party integrations. The more these will be, the
more would be the cost of the app.
Development rates as per the regions: Mainly it is the mobile app size on
which the mobile app development cost depends on as the app size define the
time needed to develop an app, but the rate of developers is also a contributing
factor. Like, the development rate per hour for US-Based, UK-Based, and
Europe-Based developers are a lot higher when compared to the Indian-based
app developers and development companies.
11. Appendices
11.1. Definition, Acronyms,
Abbreviations
None used
11.2. References
[1].... IEEE 830-1998 standard for writing SRS document. [2].....I. Somerville,
Software Engineering, 8th ed. England: Addison-Wesley, 2007. [3]....
Google.com [4].... Slideshare.net [5]....Introduction to fire safety
management by Andrew Furness and Martin Muckett [6].... Software
Engineering Textbook by R. Pressmen; 6th Edition
P R PS
16 | Page
PRACTICAL 4:
. GANTT CHART:
TABLE:
P R PS
17 | Page
Practical: 5
Aim: Design of different software cost estimation
models.
0= no influence and 5=
essential
FP= UFP*CAF
Given the following values compute function point when all the CAF and weighting
factors are average.
User input=6
User output=4
User inquiries=5
User files=5
External interfaces=1
Solution:
18 | Page
Step 1:
F = 14*3 (Scale=3)
F = 42
Step 2:
CAF = 0.65+(0.01*42)
CAF = 1.07
Step 3:
UFP = (6*4)+(4*5)+(5*4)+(5*10)+(1*7)
UFP = 24+20+20+50+7
UFD = 121
Step 4:
FP = 121*1.07
FP = 129.47
⇨ Applying COCOMO Model:
1. Effort = ab*(KLOC)bb
= 3.6*(4)1.20
= 19.0009
2. Duration = cb*(E)db
= 2.5*(19)0.32
= 6.414 months
=6 months(approx)
3. Person = E/D
= 19/6
19 | Page
= 3.1667
= 3 people (approx)
P R PS
20 | Page
Practical 6
24 | Page
Practical : 7
Use case :
25 | Page
Scenarios :
Customer do Registration. Customer logins. Customer Makes a
Request for Fire Emergency. Request is received by Server. Server
stores the location in Location Data Store. Server fetches the U_id.
Server fetches address from Customer Data Store. Server calculates
estimated Arrival time and sends to FSS. FSS receives the EAT. FSS
sends that EAT to customer. FSS Sends a notification that customer’s
Request has been Accepted. FSS sends the steps to be taken before
team reaches the location. If any how Team was not able to reach the
location customer can inquire. Server waits for the confirmation of
customer. After Receiving Confirmation from a customer Server closes
the Request. If anything was not good customer can complain also.
Class Diagram :
26 | Page
State Diagram :
P R PS
27 | Page
Practical : 8
Collaboration Diagram :
28 | Page
Sequence Diagram :
Activity Diagram :
29 | Page
1) The project title must always be set to something meaningful as it is used in the Windows
task list and for message box captions when no default is supplied in the call to the message
box function.
2) A help file must be associated with all components. For application modules, help files
should describe key application features and operational instructions. For ActiveX components,
help files should describe component design goals, classes, methods, properties and enums
etc. to aid re-use by other developers.
3) The project icon should be set as it becomes the application icon when the project is
compiled.
4) The application start-up object must always be 'Sub Main' for standard EXE
components.
5) To ensure that all source files pertaining to a Visual Basic project are correctly archived, all
project source files must reside in the same folder as the Visual Basic project file (.VBP).
6) The extension of designer files must match the Visual Basic default extension of
'.dsr'.
8) The extension of module filenames must use the Visual Basic default
extension of
'.bas'. 9) The scope for a module-level 'Const' declaration must always be explicitly declared
Public or Private as
appropriate.
10) The "As" keyword must be used within a constant declaration to explicitly state the data
type of the declared constant.
11) Procedure return data types must not return arrays. Due to a known bug in Visual Basic 6.0,
when you use a function that returns an array as a parameter to the UBound or LBound
functions, the memory allocated for the array is not released thereby causing a memory leak.
12) To aid code readability, all local variables must be declared at the head of a
procedure.
13) To ensure that procedures are easy to understand, test and maintain, 'If...Then' statements
must not be nested beyond three levels deep.
14) To reduce code complexity and improve code readability avoid nesting Select...Case
statements within other Case statement blocks. If the Case statement needs to perform
conditional or complex logic this is best delegated to another function.
32 | Page
15) The "Stop" statement should not be used during debugging as it may be accidentally left
within source code and cause the compiled application to terminate abruptly. The "End"
statement should be used instead if the application is indeed to terminate. If the "Stop"
statement was intended to highlight a problem during debugging, replace the "Stop" statement
with "Debug.Assert False".
16) Use of the "On Error GoTo 0" statement to switch off error trapping within a procedure is not
common practice and must be carefully considered before implementation.
17) To achieve a consistent user interface, all forms must contain a control
box.
19) The maximum number of controls per form must not exceed 50. Forms containing large
numbers of controls are perceive to be "busy" and not intuitive for users. Large numbers of
controls per form also consume resources and can lead to application failure and should
therefore be avoided.
20) Dialog 'OK' buttons must not be defined which contain an accelerator key e.g. '&OK' must
not be used whereas the caption 'OK' is allowed if the Default property is also set to True.
21) Variant variables add additional overhead to execution which can degrade operational
performance and also prevents strict type checking. Declaration of variables 'As Variant' must
be avoided whenever possible.
22) Each time ReDim Preserve is used, the existing array must be copied to a new memory
location which can degrade operational performance if repeated often. If you must use dynamic
arrays, consider growing the array by larger increments so that ReDim Preserve can be invoked
less often. This can have a drastic effect on performance. Alternatively, you may wish to
consider the use of a collection under some circumstances.
P R PS
33 | Page
Practical: 10
AIM: Study of different Testing Tools with
comparison
DB
Stress
sting the server parts of information
34 | Page
➢ Embedded Test Tools
Reactis
Tester
35 | Page