Practical – 1

Aim: Project definition and objective of the specified

module.

Title: Fire Safety System

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.

▪ Less security of customer and Fire Rescue Center

information.
▪ Require more physical work and man power.
▪ All the manual entry and editing will take more time.

3. ​Objectives: ​More secure information as it will give a layer of security of

authentication and authorization.

• Required very less man power.

• Maintain data integrity Validate the manual calculations avoid the calculation
error.
• Safeguard the data accuracy.
• More reliable and efficient.
• More user-friendly interface.

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.

▪ Account: Account enables the customer to take advantage of the facilities

provided by the FSS.

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:

➢ Secure Internet Connection ➢ Server ➢ Database ➢ Central

Computer ➢ Any physical device for customers which support
web browsing

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.

The attributes of this entity are

-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_ country: This attribute will hold the name of the

country.

-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.

-Employee_ name: This is required for the verification purpose. Usually on

government issued ID cards it has a name as identification.

2 | ​Page
-Employee_ address: In any case when the employee address needed for
example sending any email or documents at the employee’s residence.

-Employee_ phone: It is good to have employee’s contact number to have

immediate communication

-Employee_ email: It is required when a bank needs to make an announcement.

So, they will select the employees emailed and simply broadcast the
announcement. Branch_ id: This will help to identify at which branch the
employee is working currently. We can find the branch details from Bank_ branch
table.

-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.

-Department_ name: It will contain the name of the department to avoid

confusion to clear and avoid the confusion from the id.

-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.

-Designation: To know about the designation of the employee like if the

employee hold manager or HOD or any other designation.

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.

-Customer_ address: To send any envelope to the customer’s residence or any

contact to the address.

-Customer_ phone: To communicate with the customers over the

phone.
 3 | ​Page
-Customer_ email: To send any offer from the bank to the customer or formal
communication with the customer.

-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

AIM: - Design and implementation of different

software engineering.

Water Fall Model

• 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

1. Uses divide and conquer for breakdown of

tasks. 2. Lowers initial delivery cost. 3.
Incremental Resource Deployment.

• Disadvantages

1. Requires good planning and design. 2. Total

cost is not lower. 3. Well defined module
interfaces are required.

5 | ​Page
Prototype Model
 • Advantages

1. New requirements can be easily accommodated as there is scope for

refinement. 2. Missing functionalities can be easily figured out. 3. Flexibility in
design.

• 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

1. The use of powerful and efficient tools requires highly skilled

professionals. 2. The absence of reusable components can lead to failure
of the project. 3. The systems which cannot be modularized suitably cannot
use this model. 4. Customer involvement is required throughout the life
cycle.
Spiral Model

• 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.

Rapid Application Development(RAD) Model for

Fire Safety System

To solve actual problems in an industry setting, software engineer or a team of

engineers must incorporate a development strategy that encompasses the process,
methods and tools layers and generic phases. This strategy is often referred to as
process model or a software engineering paradigm or project development
approach.
 A process model for software engineering is chosen based on the
nature of the project and application, the methods and tools to be used, and the
controls and deliverables that are required.

This software is based on Rapid Application Development (RAD)

Model. RAD model is an incremental software development process model that
emphasizes an extremely short development cycle. If requirements are well
understood and project scope is constrained, the RAD process enables a
development team to create a “fully functional system” within short time periods (60-90
days). And for this System development which falls within a short period of time, there
is no other methodology suitable other than RAD, which is the best approach in
producing the expected Fire Safety System.

JUSTIFICATION

From all these software engineering models we will be using incremental model
for our Library

management system. This model is more flexible – less costly to change

scope and requirements. It

is easier to test and debug during a smaller iteration. In this model customer can
respond to each

built.

7 | ​Page
Incremental model would be suitable because of following
reasons:

• Requirements of the complete system are clearly defined and

understood.

• Major requirements are already defined; however, some details can evolve with
time.

• There is a need to get a product to the market

early.

• A new technology is being used.

• 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.

• There are some high risk features and

goals.

P R PS
 8 | ​Page
PRACTICAL 3

Aim: Design Software Requirement Specification (SRS) for

FIRE SAFETY SYSTEM

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

System provides notification in case the fire breaks out in a building.

​ It will warn all
the people who work or live in that building and it will notify the location where the
​ ​Several features and safety measurements can be added to the
fire is located. ❖
system according
the needs of the administration.

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

There are several factors that need to be considered to decide on the

development cost of a Fire Safety System. They include:

❖ ​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.

3.6 Dependencies with other

Requirements

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.

3.7 Other Requirements

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

Rules for accessing the API:

❖ ​Allow an ordinary user to only perform GET operations ​❖ A

​ llow only
an Admin to perform POST, PUT, DELETE and PATCH
operations ​❖ ​Allow an Admin to be able to GET all the registered users' information
from the database

4.2 Hardware Interface ​5. ​ T​ he existing Local Area Network (LAN) will be

used for collecting data from the

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:

❖ Operating System: Windows 9xp or above, MAC or UNIX, Android 5.0

 or
above. ❖ Processor: Pentium III or 2.0 GHZ or higher ❖
RAM: 256Mb or more

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.

There are two “directions” when we describe compatibility of a system

release:

Backward Compatible: means that a newer system version can be used in an

environment where an older version is expected. When talking about binary
and source compatibility, this is the common and implied direction.

Forward Compatible: means that an older system can be used in an

environment where a newer version is expected. Forward compatibility is
generally not upheld for systems.

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

❖ Maintainability analysis provides calculated information regarding various

aspects of maintenance. ❖ The goal of performing maintainability analysis is to
determine the amount of
time required to perform repairs and maintenance
tasks.

13 | ​Page

7.5 Portability

❖ Portability, in relation to software, is a measure of how easily an

application can
be transferred from one computer environment to another. ❖ A computer software
application is considered portable to a new environment if the effort required
to adapt it to the new environment is within reasonable limits. ❖ The meaning
of the abstract term 'reasonable' depends upon the nature of the
application and is often difficult to express in quantifiable
units.

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.8 Application Compatibility

❖ Once you have your list of applications you are ready to move forward to
check
these application for compatibility. ❖ There’re several different options for tools you
could use to help streamline and automate the process. The beauty of these
tools is they allow you to batch process all of your applications at once.

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:

❖ ​Alert people ​❖ ​Report

issues ​❖ ​Manage Fire
stations

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.

10. Preliminary Budget

 There are several factors that need to be considered to decide on the
development cost of a Fire Safety System. They include:

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; 6​th ​Edition
 P R PS

16 | ​Page
PRACTICAL 4:

Aim: Documentation of Software Project Management Planning

(SPMP) for Library Management System

We have used Rapid Development Model for the Fire Safety

System.

. ​GANTT CHART:
TABLE:

ID Task name Starting date Finishing date Duration

1 Analysis 01-07-2019 20-07-2019 20d

2 Design 29-07-2019 14-08-2019 13d

3 Code 19-08-2019 28-09-2019 31d

4 Test 08-09-2019 11-10-2019 3d

P R PS

17 | ​Page
Practical: 5
Aim: Design of different software cost estimation
models.

Function point is an element of software development which help to approximate the

cost of development in early process. It measures functionality from users point of
view.

Step 1: ​F= 14*Scale where scale varies from 0 to

5

0= no influence and 5=
essential

Step 2: ​Calculate Complexity Adjustment Factor

(CAF)

CAF= 0.65+ (0.01*F)

Step 3: ​Calculate Unadjusted Function Point

(UFP)

Function Unit Table:

Function Unit Low Average High ​External Input 3 4 6 External Output 4 5 7

External Inquiries 3 4 6
External Files 7 10 15 External Interfaces 5 7 10

Multiply each individual function point to corresponding values in

table.

Step 4: ​Calculate Function Point

(FP):

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 FP = 32 LOC in Visual Basic

129.47 FP = 4143.04 LOC in VB

=>4 KLOC (approx)

1. Effort = a​b​*(KLOC)​b​b

= 3.6*(4)​1.20

= 19.0009

= 19 Person Month (approx)

2. Duration = c​b​*(E)​d​b

= 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

AIM : Design SA/SD for current semester project. It includes

Requirement specification, DFD with data dictionary and
Structure chart for current semester project.

Data Flow Diagram :

21 | ​Page
22 | ​Page
23 | ​Page
Data Dictionary :

Key Name Type Size Description

Primary Key U_ID Varchar 20 Unique Id of user

Name Varchar 20 Name of the user

Contact No. Int 10 User contact number

E_Mail Varchar 20 User Email ID

Password Varchar 20 User Password

Address Varchar 50 User residential address

Server_ID Varchar 20 Unique server Id

Server_location Varchar 20 Location of server

Server_Type Varchar 20 Type of server

EAT Varchar 20 Estimated Arrival Time

Message Varchar 50 Steps to be taken before Team arrival

Request_ID Varchar 20 Unique request Id

Response_ID Varchar 20 Unique response Id

 P R PS

24 | ​Page
Practical : 7

AIM : Designing the module using object oriented

approach including use case diagram with user scenarios,
class diagram & state diagram..

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

AIM : Designing the module using object oriented

approach including Collaboration Diagram, Sequence
Diagram and Activity Diagram.

Collaboration Diagram :
 28 | ​Page
Sequence Diagram :
Activity Diagram :
 29 | ​Page

Activity Diagram FSS

Activity Diagram Customer
30 | ​Page
P R PS
 31 | ​Page
Practical: 9

AIM: Coding Standards and walk

through

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'.

7) Form filenames must use the Visual Basic default extension of

'.frm.

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.

18) keyboard navigation of the user

interface.

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

➢ ​Functional Test Tools

Product Vendor Comments

.TEST Parasoft Unit-testing tool that automatically tests classes written

on Microsoft's .NET Framework without requiring
developers to write a single test scenario or stub.
tional test and verification product
AberroTest Aberro er interface level.
Software

➢ ​Performance Test Tools

Product Vendor Comments

cations, as well as DBMSs and
BugTimer BugStomper s.
Software
mer was designed to streamline the entire
s of timing and documenting Performance Test
into one Application. BugTimer is a timer
tion that records, displays, saves, sorts, and
Performance Test results.

DB

Stress
sting the server parts of information
 34 | ​Page
➢ ​Embedded Test Tools

Product Vendor Comments

maximizing the probability of finding
Message available for software testing. The
Magic model-generated outputs as well as
software components - processes, enerated test harnesses can
s, etc. With MessageMagic, one can test a certain e correctness of source code
by simulating its neighbour components. odels.
ols for visualization of messages traffic (also
sages) between the testable component and
ted counterparts.

Reactis
Tester

comprehensive test suites from

ateflow models. The test suites exercise large
he software under test while avoiding
, thereby maximizing the probability of finding
in the time available for software testing. The
ests store model-generated outputs as well as
at Tester-generated test harnesses can
ly check the correctness of source code
tions of models.
comprehensive test suites from
ateflow models. The test suites exercise large
he software under test while avoiding
P R PS

35 | ​Page