DAV INSTITUTE OF ENGINEERING & TECHNOLOGY, JALANDHAR

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

SOFTWARE ENGINEERING LAB FILE

(BTCS 506-18)

SUBMITTED TO: SUBMITTED BY:

Dr. Parveen Kakkar Karan Gupta
University Roll No.-1904018
Class Roll No. -166/19
CSE-5th sem
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

INDEX

S.NO. PRACTICAL PAGE NO.

Preparation of Software Requirement

Specification Document, Design Documents
1 and Testing Phase related documents for some 3-4
problems

Study and usage of OpenProj or similar software to

2 5-6
draft a project plan
Study and usage of Openproj to track the progress of a
3 project 7-22

Preparation of the Software Configuration management

4 and Risk management related documents. 23-26

5 Study and usage of any Design phase CASE tool 27-32

6 To perform unit testing and integration testing. 33-38

To perform various white box and black box testing

7 39-44
techniques.

Testing a Website
8 45-48

PRACTICAL-1
2
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Preparation of Software Requirement Specification Document, Design Documents and

Testing Phase related documents for some problems.
SRS: - An SRS minimizes the time and effort required by developers to achieve desired goals and
also minimizes the development cost. A good SRS defines how an application will interact with
system hardware, other programs and human users in a wide variety of real- world situations.
Parameters such as operating speed, response time, availability, portability, maintainability, footprint,
security and speed of recovery from adverse events are evaluated. Methods of defining an SRS are
described by the IEEE (Institute of Electrical and Electronics Engineers) specification 830-1998.

Qualities of SRS: -

 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable

The below diagram depicts the various types of requirements that are captured during SRS.

Figure 3.1:-SRS requirements

3
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

1. Introduction

The software ATM version1.0 is to be developed for Automated Teller Machines (ATM).
An automated teller machine (ATM) is computerized telecommunications device that
provides a financial institution's customers a secure method of performing financial
transactions, in a public space without the need for a human bank teller. Through ATM,
customers interact with a user-friendly interface that enables them to access their bank
accounts and perform various transactions.

1.1 Purpose

This document describes the software requirements and specifications (SRS) for an automated
teller machine (ATM) network. The document is intended for the customer and the developer
(design, testers, and maintainers).
The reader is assumed to have basic knowledge of banking accounts and services. Knowledge
and understanding of Unified Modeling Language (UML) diagram is also required.

1.2 Scope

This document applies to Automated Teller Machine software ATM version1.0. This software
facilitates the user to perform various transactions in his account without going to bank. This
software offers benefits such cash withdrawals, balance transfers, deposits, inquiries, credit card
advances and other banking related operations for customers. It also allows the administrator to
fix the tariffs and rules as and when required.

The software takes as input the login Id and the bank account number of the user for login
purposes. The outputs then comprise of an interactive display that lets the user select the
desirable function that he wants to perform. The software requires appropriate record
keeping and security provisions. The software must handle concurrent accesses to the same
account correctly.

The software is expected to complete in duration of six months and the estimated cost is Rs. 10
lakhs.

4
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

1.3 Definitions, Acronyms, and Abbreviations.

AC Alternate Current
AIMS ATM Information Management System.
ATM An unattended electronic machine in a public place,
connected to a data system and related equipment and
activated by a bank customer to obtain cash withdrawals and
other banking services.
Braille A system of writing and printing for blind or visually
impaired people, in which varied arrangements of raised
dots representing letters and numerals are identified by
touch.
BMS Bank Management Software developed by KPM Bank.
Code Division Multiple Access, a reliable data
CDMA communication protocol.
CMS Card Management Software developed by KPM Bank.
DES Data Encryption Standard.
Dial-Up POS A message format for low cost communications.
Electronic For easier, safer information storage, related to modem.
Journals
Internet An interconnected system of networks that connects
computers around the world via the TCP/IP protocol.
MB Mega Bytes
ms Milliseconds.
sec Seconds
Smart Card Card without hardware which stores the user’s private keys
within a tamper proof software guard.
SRS Software Requirements Specification.
Tactile Special keyboard designed to aid the visually impaired.
keyboard
TCP/IP Transmission Control Protocol/Internet Protocol.
V Volts
VGA Video Graphics Adaptor is a display standard.

1.4 References

5
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

The references for the above software are as follows:-

 www.google.co.in

 www.wikipedia.com

 Chevy Chase Bank, UMBC Branch.

 Russell C. Bjork Requirements Statement for Example ATM System. Online.

1.5 Overview

Section 1.0 discusses the purpose and scope of the software.

Section 2.0 describes the overall functionalities and constraints of the
software and user characteristics.
Section 3.0 details all the requirements needed to design the software.

2. The Overall Description

2.1 Documentation Conventions

 Account:
 A single account at a bank against which transactions can be applied.
 Accounts may be of various types with at least checking and savings. A customer can
hold more than one account.
 MaxDailyWD:
 The maximum amount of cash that a customer can withdraw from an account in a day
(from 00:00 AM to 23:59 PM) via ATMs.
 PIN:
 It refers to Personal Identification Number. Used to identify and validate the login of an
ATM user.

6
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

2.2 Intended Audience

The intended audience of this SRS consists of:

 Software Designers
 System Engineers
 Software Developers
 Software Testers
 Customers

2.3 Additional Information

The ATM network does not work independently. It works together with the banks’ computers
and the software run by the network’s banks.
The actors of the system are:
 User
 ATM Machine
 Bank

2.4 General Description

7
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

2.5 Product Perspective

 The ATM is a single functional unit consisting of various subcomponents.

 This software allows the user to access their bank accounts remotely through an ATM
without any aid of human bank teller.

 This software also allows to perform various other functions apart from just accessing his
bank account such as mobile bill clearings etc.

 Some of its hardware components are cassettes, memory, drives, dispensers i.e. for
receipts and cash, a card reader, printer, switches, a console, a telephone dialer port, a
networking port and disks.

 The ATM communicates with the bank’s central server through a dial-up communication
link.

 The Memory of the system shall be 20MB.

 The Cassette capacity shall be at least 2000 notes.

2.6 Product Functions

The major functions that ATM performs are described as follows:-

 Language Selection: - After the user has logged in, the display provides him with a list
of languages from which he can select any one in order to interact with the machine
throughout that session. After the language selection the user is prompted with an option
that whether he wants the selected language to be fixed for future use so that he is not
offered with the language selection menu in future thus making the transaction a bit
faster. User also has the freedom to switch to a different language mentioned in the list in
between that session.

 Account Maintenance:- The various functions that a user can perform with his account
are as follows:-

1. Account Type: - The user has the freedom to select his account type to which all
the transactions are made, i.e. he can select whether the account is current account
or savings account etc.

8
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

2. Withdrawal/Deposit: - The software allows the user to select the kind of

operation to be performed i.e. whether he wants to withdraw or deposit the
money.

3. Amount: - The amount to be withdrawn or deposited is then mentioned by the

user.

4. Denominations: - The user is also provided with the facility to mention the
required denominations. Once he enters his requirements the machine goes
through its calculations on the basis of current resources to check whether it is
possible or not. If yes, the amount is given to the user otherwise other possible
alternatives are displayed.

5. Money Deposition: - Money deposition shall be done with an envelope. After

typing the amount to be deposited and verification of the same, the customer
must insert the envelope in the depositary.

6. Balance Transfer:- Balance transfer shall be facilitated between any two

accounts linked to the card for example saving and checking account.

7. Balance Enquiry:- Balance enquiry for any account linked to the card shall be
facilitated.

 Billing:- Any transaction shall be recorded in the form of a receipt and the same would
be dispensed to the customer. The billing procedures are handled by the billing module
that enable user to choose whether he wants the printed statement of the transaction or
just the updation in his account.

 Cancelling:- The customer shall abort a transaction with the press of a Cancel key. For
example on entering a wrong depositing amount. In addition the user can also cancel the
entire session by pressing the abort key and can start a fresh session all over again.

 Map locating other machines:- The machine also has a facility of displaying the map
that marks the locations of other ATM machines of the same bank in the entire city.

 Mobile Bills Clearings:- The machine also allows the user to clear off his pending
mobile bills there only, if the name of his operator is mentioned there in the list. The
machine displays the list of the companies supported by that bank to the user.

2.7 User Characteristics

9
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

There are different kinds of users that will be interacting with the system. The intended users
of the software are as follows:-

 User A: A novice ATM customer. This user has little or no experience with electronic
means of account management and is not a frequent user of the product. User A will
find the product easy to use due to simple explanatory screens for each ATM function.
He is also assisted by an interactive teaching mechanism at every step of the transaction,
both with the help of visual and audio help sessions.

 User B: An experienced customer. This user has used an ATM on several occasions
before and does most of his account management through the ATM. There is only a
little help session that too at the beginning of the session thus making the transaction
procedure faster.

 Maintenance Personnel: A bank employee. This user is familiar with the functioning
of the ATM. This user is in charge of storing cash into the ATM vault and repairing the
ATM in case of malfunction. This user is presented with a different display when he
logs in with the administrator’s password and is provided with options different from
that of normal user. He has the authority to change or restrict various features provided
by the software in situations of repairing.

2.8 Functional Requirements

The major constraints that the project has are as follows:-

 The ATM must service at most one person at a time.

 The number of invalid pin entries attempted must not exceed three. After three
unsuccessful login attempts, the card is seized/blocked and need to be unlocked by the
bank.

 The simultaneous access to an account through both, the ATM and the bank is not
supported.

 The minimum amount of money a user can withdraw is Rs100/- and the maximum
amount of money a user can withdraw in a session is Rs.10,000/- and the maximum
amount he can withdraw in a day is Rs20,000/-

10
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

 Before the transaction is carried out, a check is performed by the machine to ensure that
a minimum amount of Rs1000/- is left in the user’s account after the withdrawal failing
which the withdrawal is denied.

 The minimum amount a user can deposit is Rs100/- and the maximum amount he can
deposit is Rs10, 000/- .

 A user can select only that cellular operator for mobile bill clearings that is supported by
the bank.

 The software requires a minimum memory of 20GB the database used should be
Oracle7.0.

 There shall be a printer installed with the machine to provide the user with the printed
statement of the transaction.

 For voice interactions, speakers should also be there to accompany the machine.

2.9 Assumptions and Dependencies

The requirements stated in the SRS could be affected by the following factors:

 One major dependency that the project might face is the changes that need to be
incorporated with the changes in the bank policies regarding different services. As the
policies changes the system needs to be updated with the same immediately. A delay in
doing the same will result to tremendous loss to the bank. So this should be changed as
and when required by the developer.
 Another constraint relating to the operating environment is that we are specific to Oracle
Database.
 The project could be largely affected if some amount is withdrawn from the user’s
account from the bank at the same time when someone is accessing that account through
the ATM machine. Such a condition shall be taken care of.
 At this stage no quantitative measures are imposed on the software in terms of speed and
memory although it is implied that all functions will be optimized with respect to speed
and memory.

It is furthermore assumed that the scope of the package will increase considerably in the future.
3. External Interface Requirements

3.1 User Interface Requirements

11
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

The interface provided to the user should be a very user-friendly one and it should provide an
optional interactive help for each of the service listed. The interface provided is a menu driven
one and the following screens will be provided:-

 A login screen is provided in the beginning for entering the required username/pin no.
and account number.

 An unsuccessful login leads to a reattempt (maximum three) screen for again entering the
same information. The successful login leads to a screen displaying a list of supported
languages from which a user can select any one.

 In case of administrator, a screen will be shown having options to reboot system, shut
down system, block system, disable any service.

 In case of reboot/ shut down, a screen is displayed to confirm the user’s will to reboot
and also allow the user to take any backup if needed.

 In case of blocking system, a screen is provided asking for the card no.

 By entering the card no of a particular user, system access can be blocked for him.

 Administrator is also provided with a screen that enables him to block any service
provided to the user by entering the name of the service or by selecting it from the list
displayed.
 After the login, a screen with a number of options is then shown to the user. It contains
all the options along with their brief description to enable the user to understand their
functioning and select the proper options.

 A screen will be provided for user to check his account balance.

 A screen will be provided that displays the location of all other ATMs of same bank
elsewhere in the city.

 A screen will be provided for the user to perform various transactions in his account.

12
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

The following reports will be generated after each session dealt with in the machine: -
1. The login time and logout time along with the user’s pin no and account number
is registered in the bank’s database.
2. The ATM’s branch ID through which the session is established is also noted
down in the bank’s database.
3. Various changes in the user’s account after the transactions, if any, are reported
in the database.
4. A printed statement is generated for the user displaying all the transactions he
performed.

Other various user interface requirements that need to be fulfilled are as follows:-

1. The display screen shall be of 10" VGA color type.

2. The display screen shall have 256 color resolution.
3. The display screen shall also support touch screen facility.
4. The speakers shall support Yamaha codecs.
5. The keypad shall consist of 16 tactile keys.
6. There shall be 8 tactile function keys.
7. The keyboard will be weather resistant.
8. The transaction receipt shall be 3.1" × 6".
9. The statement receipt shall be 4.2" × 12".
10. The deposit envelopes shall be 9" long and 4" wide.

13
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

3.2 Hardware Interface Requirements

There are various hardware components with which the machine is required to interact. Various
hardware interface requirements that need to be fulfilled for successful functioning of the
software are as follows:-

 The ATM power supply shall have a 10/220 V AC manual switch.

 The ATM card should have the following physical dimensions:-

1. Width -
2. Height -
3. Thickness -

 The card reader shall be a magnetic stripe reader

 The card reader shall have Smart card option.

 The slot for a card in the card reader may include an extra indentation for
the embossed area of the card. In effect it acts as a polarization key and
may be used to aid the correct insertion orientation of the card.

 This is an additional characteristic to the magnetic field sensor which

operates off the magnetic stripe and is used to open a mechanical gate on
devices such as ATMs. There shall be a 40 column dot matrix receipt
printer.
 There shall be a 40 column dot matrix statement printer.

 The receipt dispenser shall be a maximum of 4" width and 0.5" thickness.

 The statement dispenser shall be a maximum of 5" width and 0.5" thickness.

 The envelope depository shall be a maximum of 4.5" width, 10" length and 0.5"
thickness.

 Screen resolution of at least 800X600-required for proper and complete viewing of

screens. Higher resolution would not be a problem.

14
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

3.3 Software Interface Requirements

 In order to perform various different functions, this software needs to interact with
various other softwares. So there are certain software interface requirements that need to
be fulfilled which are listed as follows:-

 The transaction management software used to manage the transaction and keep track of
resources shall be BMS version 2.0.
 The card management software used to verify pin no and login shall be CMS version 3.0.
 Yamaha codecs 367/98 for active speakers.

 The database used to keep record of user accounts shall be Oracle version7.0.

3.4 Communication Interface Requirements

The machine needs to communicate with the main branch for each session for various functions
such as login verification, account access etc. so the following are the various communication
interface requirements that are needed to be fulfilled in order to run the software successfully:-

 The system will employ dial-up POS with the central server for low cost
communication.
 The communication protocol used shall be TCP/IP.
 Protocol used for data transfer shall be File Transfer Protocol (FTP).

4. System Features

4.1 Remote Banking and Account Management

The system is designed to provide the user with the facility of remote banking and perform
various other functions at an interface without any aid of human bank teller.

The functioning of the system shall be as follows:-

 At the start, the user is provided with a log in screen and he is required to enter his PIN
NO. and Account details which are then verified by the machine. In case of an
unsuccessful attempt a user is asked again for his credentials but the maximum number of
attempt given to the user is limited to 3 only, failing which his card is blocked and need
to be unblocked by the bank for any future use.
 After a successful log in, the user is presented with a list of language. The user can select
anyone in the list for interaction with the machine for the entire session. After the
language selection the user is also asked whether he wants to fix that language for future
use also so that he is never asked for language in future. In addition there is also a facility
for the user to switch to any other language during that session.

15
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

 After the language selection, the user is directed towards a main page that displays a set
of options/services along with their brief description, enabling the user to understand
their functioning. The user can select any of the listed option and can continue with the
transaction.

The machine also provides the user with a number of miscellaneous services such as:
 The machine lists a set of operators that are supported by the bank.
 A user can clear off his pending mobile phone bills be selecting his operator.
 The machine also has the facility to display a map that marks the location of other ATMs
of the same bank in the city. This may help the user to look for the ATM nearest to his
destination.
 At any moment if the user wants to abort the transaction, he is provided with an option to
cancel it. Just by pressing the abort button he can cancel all the changes made so far and
can begin with a new transaction.
 After the user is finished with his work, for security purpose, he is required to log out and
then take his card out of the slot.

4.2 Validity Checks

 In order to gain access to the system, the user is required to enter his/her correct user
id/pin no and account no failing which his card may be blocked.
 The user can access only one account at a time and can enter only one account no.
 Also if the user is an administrator, he is required to enter his login id in order to access
and change the facilities provided by the system.

4.3 Sequencing Information

The information about the users and their account should be entered into the database prior to
any of the transactions and the backup be maintained for all account information

4.4 Error Handling/ Response to Abnormal Situations

If any of the above validation/sequencing flow does not hold true, appropriate error messages
will be prompted to the user for doing the needful.

4.5 Receipt Generation

After each transaction user has performed, a receipt is generated that contains all the information
about the transaction. The format of the generated receipt is as shown below:-

AXIS BANK
16
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Branch name/Id:-
(Address)
Login Time:-
Date:-
Account No.:-
User Name:-
Transactions:-

FROM TO TYPE
AMOUNT

Logout Time:- Barcode

Thank You For Your Visit.

See You Soon.

5. Other Non-functional Requirements

5.1 Performance Requirements

The following list provides a brief summary of the performance requirements for the software:

5.1.1 Convenience
17
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

The ATM shall provide customers a 24 hour service.

5.1.2 Dynamic requirements

 The card verification time must not exceed 0.8 sec. under normal server workload and 1
sec. under peak server workload.
 The pin number verification time must not exceed 0.3 sec. under normal server workload
and 0.5 sec. under peak server workload.
 Account balance display time must not exceed 2 sec. under normal server workload and
3 sec. under peak server workload.
 Account balance transfer time must not exceed 3 sec. under normal server workload and
4 sec. under peak server workload.
 Cash withdrawal transaction time must not exceed 4 sec. under normal server workload
and 5 sec. under peak server workload.
 Deposit transaction time after insertion of the deposit envelope must not exceed 5 sec.
under normal server workload and 6 sec. under peak server workload.
 Receipt printing time after must not exceed 3 sec. under normal server and peak server
workload.
 Touch screen and button response time must not exceed 5000ms.Credit card advance
time must not exceed 6 sec. under normal traffic and server and peak traffic and server
workload.

5.1.3 Quality
The primary objective is to produce quality software. As the quality of a piece of software is
difficult to measure quantitatively, the following guidelines will be used when judging the
quality of the software

 Consistency – All code will be consistent with respect to the style. (This is
implied when adhering to the standard).
 Test cases – All functionality will be thoroughly tested.

5.2 Software System Attributes

5.2.1 Reliability

18
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

 The data communication protocol shall be such that it ensures reliability and
quality of data and voice transmission in a mobile environment. For example,
CDMA.
 The memory system shall be of non-volatile type.

5.2.2 Availability

 The product will have a backup power supply in case of power failures.
 Any abnormal operations shall result in the shutting down of the system.
 After abnormal shutdown of the ATM, the system shall have to be manually restarted
by a maintenance personnel.
 There should be no inconsistency introduced in the account during whose transaction
the system is abnormally shut down.

5.2.3 Security

 The system shall be compatible with AIMS security standards.

 The system shall have two levels of security i.e. ATM card and pin
verification both authenticated by the CMS software.
 The Encryption standard used during pin transmission shall be triple DES.
 The password shall be 6-14 characters long.
 Passwords shall not contain name of customers as they are easy to be hacked.
 Passwords can contain digit, hyphen and underscore.
 User should be provided with only three attempts for login failing which his card
needs to be blocked.
 There shall be a security camera installed near the ATM.
 There shall be a secured cash vault with a combination locking system.
 The product cabinet cover shall be manufactured using Fiber glass for security
purposes.


5.2.4 Maintainability

 The system components i.e. modem, memory, disk, drives shall be easily serviceable
without requiring access to the vault.
 The system should have the mechanism of self-monitoring periodically in order to detect
any fault.
 The system should inform the main branch automatically as soon as it detects
any error. The kind of fault and the problem being encountered should also be
mentioned by the system automatically.

19
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

5.3 Business Rules

The business rules for the software are as follows:

 The Administrator has the authority to fix the rules and regulations and to set or update
the policies as and when required.
 The staff at the bank performs the following:
1. Making the entries in the system regarding all the details of the bank
account of the user.
2. Keeping the bank account of the user updated as soon as changes are
encountered so that the data is in consistent state.
3. Blocking or seizing of the account of user on discovery of any illegal
transaction.
4. Unblocking of ATM card that got blocked due to more than three
unsuccessful login attempt.
5. Blocking of a lost/stolen ATM card on complaint of the user, only if he
presents his verification and a FIR filed for that case.
6. Constantly monitor all the ATMs in the city to check whether any one of
them is encountering any fault.
7. Immediately correct any fault discovered in any of the ATM.
8. Maintain the backup of all the accounts for reliability purposes.
9. Rollback all the changes made in an account during whose transaction an
ATM got abnormal shutdown.

 In case of loss of the ATM card. The user has to lodge a First Investigation Report
(FIR) and present its one copy to bank officials for card blocking purposes.
 A log of the following annexure is generated by the system:
 User bank account details.
 Updations made in the user account along with date, time and the changes made.
 Schedule of fixed assets.

6. Assumptions:

 Hardware never fails.

 ATM casing is impenetrable.
 Limited number of transactions per day i.e. sufficient money.

20
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

7. ATM: DFD Levels

ATM: DFD Level 0

21
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

ATM: DFD Level 1

8. Conclusion:

 Owing to the above mentioned assumptions this ATM Net Banking Software is
working as fit to customer needs.
 Result is verified accordingly.

Acknowledgement
22
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

The satisfaction and euphoria that accomplishes the successful completion of any task would
be incomplete without the mention of the people who makes it possible. If there is a driving
force that kept us going on in doing this project, it is the constant support of our guide Dr.
Parveen Kakkar. We present our sincere and heartiest thanks to him, for giving us a patient
hearing and clearing our doubts.
We would like to express our profound thanks to Prof. Dr. Parveen Kakkar for their support
and encouragement towards us at every stage in successful completion of our project.
We place our gratitude to our parents who always encouraged us to pursue our interest, who
have led us onto the right path. We are undoubted for all the love and affection they bestowed
upon us. Many are responsible for the knowledge and experience we have gained during our
project and throughout the course. With profound sense od gratitude and regards we
acknowledge for support extended by our friends for their support in completion of this
project.
Finally, we would also like to thank all those who knowingly or unknowingly helped to us all
throughout our project.

PRACTICAL-2

23
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Study and usage of OpenProj or similar software to draft a project plan.

Project managers can use OpenProj, a free project tracking application, when creating Effective
project plans. OpenProj delivers functionality that rivals the capabilities of commercial software.
This can save a project thousands of dollars in startup costs. Of course, saving a lot of money can
be foolish if the project tasks can't be done. This is not the case with OpenProj. Luckily the
OpenProj application gives project managers a full set of tools that are typically used by project
managers to track projects. Useful aids such as critical path analysis, resource tracking and task
comments are all present in Open- Proj. The tool is ideal for simple project management but is
capable of larger efforts as well.
The best way to understand how a project plan may be created using OpenProj is to study a
realistic example such as the one below. This example, while simple, provides a step by step
description of typical actions that a project manager might use to establish a viable project plan
using OpenProj. You are encouraged to try a similar example on your own.
For the purposes of the example project plan, the following assumptions are made:
- The OpenProj software has already been installed and correctly configured on a
workstation with an attached printer

- The project is to launch a new marketing effort in 6 months, called "News Shower"

- There are three full-time project resources, including the project manager

- Budget is not a consideration

- Schedule is the primary consideration

- The target implementation date is 6 months away but is not an absolute fixed date

Step 1: Create the project plan shell:-

The first step is to use OpenProj to identify the basic parameters of the project. The project
manager starts the OpenProj application and presses the "Create Project" button.The project is
named, ("News Shower"), and a starting date is given. You can forward schedule a project which
is the default. This allows you to enter the required tasks and OpenProj will calculate a
completion date. If required, you can schedule a finish date and have OpenProj work backwards
for you. This alternate method works best if there is a hard drop-dead date, such as a launch date.
The project manager can also add initial project notes. These might refer to locations of project
initiation documentation or other optional information.

24
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Fig 2.1:-Particulars of project team

Step 2: Identify the project resources:-

Use the resources view to enter the particulars of all of the project team. The names and roles of the team
members can be specified. If required, you can enter hourly rates, overtime and availability Information for
each team member. For this example, three 100% resources will be entered.

Fig 2.2:-Particulars of project team

Step 3: Identify the project's high-level tasks:-

For this example, the project is similar to an earlier project that was completed successfully. That project
required tasks for initiation, research, contracting, development and launch. The project manager enters
these tasks into the Gantt view of OpenProj. The duration estimates are based on the values previously seen
for similar tasks. There is no ordering of tasks or dependencies. The raw Gantt list is below.

25
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Fig 2.3:- Identifying project’s high-level tasks

Notice that the task "Application Development" is shown with a red duration bar while

All other tasks have blue bars. This task is identified as the project critical path. It is the longest running task in
the project. Since all tasks default to the start date of the project, the analysis of the critical path is quite
premature at this time. The project manager must now modify dependencies.

Step 4: Identify the task dependencies:-

During a project, some tasks can't start until others have been completed. This is true for the project's "Test
launch" task. There is nothing to test until the development is completed. As well, the "News Shower"
launch is dependent on every other task. The project manager, in discussions with team members or
sponsors as appropriate, determines the task dependencies. The modified Gantt view now shows a realistic
project schedule.

Fig 2.4:- Identifying task dependencies

Notice that the project now has a critical path, shown as a red bar, that is comprised of two tasks. The other
tasks are completed in parallel and don't affect the critical path. At this point, no resources have been
assigned to the tasks. No tasks have been split into components.

Step 5: Assign project resources to tasks:-

Each of the tasks can have one or more resources assigned. The column "Resource Names" on the Gantt
View allows direct data entry of this information. Enter the name of a resource in the field. The default
action is to have each named resource work 100% of their time on the task. The field also supports the direct

26
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

entry of multiple resources. Enter the resource names separated by a semi-colon. For example, "Bill
Jones;Cathy Evans", will specify that Bill and Cathy are each assigned to the task. This divides the initial
duration in half. If required, the project manager can specify that a resource is only able to work part-time on
the task. Enter a percentage after the resource name in brackets such as "[50%]". Here is the project plan
now with resources assigned.

Fig 2.5:- Assigning project resources to tasks

Notice that many of the project tasks have been shortened due to having multiple resources assigned to
them. The overall project duration has been reduced to 18.5 work days.

Step 6: Task elaboration:-

An important feature of project management applications is the ability to allow the project manager to split
tasks into smaller sub-tasks. This can allow better accuracy in schedule estimating. It also allows team
members to be specified in a just-in-time fashion for their assignments. The example project has some
opportunities for task elaboration.

Fig 2.6:- Elaborating the task

27
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Step 7: Evaluate the project plan:-

With all of the tasks entered, and sub-tasks specified, the project plan has really evolved. It now shows a
lot of information which can be useful in project reporting. The first item is the critical path. This of the
highest importance to the project manager and the organization. Reports showing the tasks can be
presented to company executives. An analysis of workloads can be done. Task reports can be printed. In
time, as completion percentages are entered for tasks, the project manager can run status reports showing
progress and schedule tracking.

Fig 2.7:- Evaluating the project plan

While further work on the example project plan is required to show the full abilities of the OpenProj
application, it is quite evident in these presented steps that it is quite helpful to the project manager. From
the graphical presentation of the critical path, to resource balancing and task elaboration, OpenProj gives the
project manager a set of functions that help to monitor project performance. Many project managers do not
use comprehensive tracking applications such as

OpenProj due to the cost of the commercial software. Others believe such tools to be difficult to use.
OpenProj is obviously an improvement when evaluated on cost but is also easy to use compared to
commercial products.

Project Management:-Project management is the planning and control of a project. It allows the user to
resolve conflicts in a continuously changing environment and is necessary to continuously drive towards the
achievement of the baseline project goals. Because project management should ideally result in the
fulfilment of all set targets, a significant part of the project manager’s work is dealing with conflicts arising
from unforeseen resource and task variations.

Examples of Project Conflicts:-Because of the absence of planned staff, the project cannot be completed
within the allotted time (schedule variance). The increase of working capacity through overtime would cause
additional costs (cost variance) or a possible reduction of scope would change the project deliverables
(scope variance).

28
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Most conflicts require the project manager to decide which goals and goal types can change and which
cannot. OpenProj can be helpful in assisting these decisions by illustrating ‘critical paths’ within the project
and allow the user to easily identify what impact any changes would have.
Work Breakdown Structure (WBS):-Dividing complex projects to simpler and manageable tasks is the
process identified as Work Breakdown Structure (WBS).Usually the project managers use this method for
simplifying the project execution. In WBS, much larger tasks are broken down to manageable chunks of
work. These chunks can be easily supervised.
When creating a WBS, the project manager defines the key objectives first and then identifies the tasks
required to reach those goals. A WBS takes the form of a tree diagram with the "trunk" at the top and the
"branches" below. The primary requirement or objective is shown at the top, with increasingly specific
details shown as the observer reads down.
Following is an example of WBS:

Fig 2.8: Work Breakdown Structure of an Aircraft Probe

29
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

PRACTICAL-3

Study and usage of Openproj to track the progress of a project

Finding the right project management solution for your team can be very hard. Finding an open source
project management solution may be even harder. That's the mission of solution that allows teams to
collaborate throughout the project life cycle. Additionally, the project aims to replace proprietary software
like Microsoft Project Server or Jira.

The Open Project objectives:

1. Establish and promote an active and open community of developers, users, and companies for continuous
development of the open source project.
2. Define and develop the project vision, the code of conduct, and principles of the application.
3. Create development policies and ensure their compliance.
4. Define and evolve the development and quality assurance processes.
5. Provide the source code to the public.
6. Provide and operate the OpenProject platform.

Mission of Open Project

The mission of OpenProject can be quickly summarized: we want to build excellent open source project
collaboration software. And when I say open source, I meant it. We strive to make OpenProject a place to
participate, collaborate, and get involved—with an active, open- minded, transparent, and innovative
community. Companies have finally become aware of the importance of project management software and
also the big advantages of open source. But why is it that project teams still tend to switch to old-fashioned
ways of creating project plans, task lists, or status reports with Excel, PowerPoint, or Word—or having other
expensive proprietary project management software in use? We want to offer a real open source alternative
for companies: free, secure, and easy to use.

30
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Progress of the project is as below:-

31
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Practical-4

Preparation of the Software Configuration management and Risk management related documents.

Software Configuration management

SCM or Software Configuration management is a Project Function (as defined in the SPMP)
with the goal to make technical and managerial activities more effective. Software configuration
management (SCM) is a software engineering discipline consisting of standard processes and
techniques often used by organizations to manage the changes introduced to its software products.
SCM helps in identifying individual elements and configurations, tracking changes, and version
selection, control, and baselining.
SCM is also known as software control management. SCM aims to control changes introduced
to large complex software systems through reliable version selection and version control.
The SCM system has the following advantages:
 Reduced redundant work.
 Effective management of simultaneous updates.
 Avoids configuration-related problems.
 Facilitates team coordination.
 Helps in building management; managing tools used in builds.
 Defect tracking: It ensures that every defect has traceability back to its source.

Benefits of Software Configuration Management

SCM provides significant benefits to all projects regardless of size, scope, and complexity. Some of
the most common benefits experienced by project teams applying the SCM disciplines described in
this guide are possible because the SCM system:

 Organization
Being that Configuration Management is like the framework for greater information
management programs, it should go without saying that it is critical for greater management and
organization of information as a whole. With a well-ordered system in place, a good IT worker
should be able to see all of the past system implementations of the business, and can better
address future needs and changes to keep the system up to date and running smoothly.

 Reliability
Nothing is worse than an unreliable system that is constantly down and needing repairs because
a company’s configuration management team is lacking in organization and pro-activeness. If
the system is used correctly, it should run like the well-oiled machine that it is, ensuring that
every department in the company can get their jobs done properly. Increased stability and
efficiency of the system will trickle down into every division of a company, including customer
relations, as the ease and speed in which their problems can be solved and information can be
accessed will surely make a positive impact.

 Cost Reduction and Risks

Like anything else in business, a lack of maintenance and attention to details can have greater
risks and cost down the line, as opposed to proactive action before a problem arises.
Configuration Management saves money with the constant system maintenance, record keeping,
32
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

and checks and balances to prevent repetition and mistakes. The organized record keeping of the
system itself saves time for the IT department and reduces wasted money for the company with
less money being spent on fixing recurring or nonsensical issues.
SCM Process

The software configuration management process defines a series of tasks that have four primary
objectives:
1. To identify all the items that collectively defines the software configuration.
2. To manage changes to one or more of these items.
3. To facilitate the construction of different versions of an application.
4. To ensure that software quality is maintained as the configuration evolves over time.

33
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Risk Management
1. A risk is any anticipated unfavourable event or circumstance that can occur while
project is being developed
2. The project manager needs to identify different type of risk in advance so that the
project deadlines don’t get extended
3. There are three main activities of risk management

Risk identification

1. The project manager needs to anticipate the risk in project as early as possible so that the
impact of risk can be minimised by using defective risk management plans
2. Following are the main types of risk that need to be identified
3. Project risk:- these include
 Resource related issues
 Schedule problems
 Budgetary issues
 Staffing problem
 Customer related issues
4. Technical risk := includes
 Potential design problems
 Implementation and interfacing issues
 Incomplete specification.
 Changing specification and technical uncertainty
 Ambiguous specification
 Testing and maintenance problem
5. Business risk :-
 Market trend changes
 Developing a product similar to the existing applications
 Personal commitments
2. In order to be able to successfully identify and foresee the different type of risk that might affect a
project it is good idea to have a company disaster list
3. The company disaster list contains al the possible risk or events that can occur in similar projects

Risk containment: -

1. Risk containment include planning the strategies to handle and face the most likely and damaging
risk first
2. Following are the strategies that can be used in general
a. Avoid the risk:- eg:- in case of having issues in designing phase with reference to specified
requirements , one can discuss withe customer to change the specifications and avoid the risk
b. Transfer the risk :-
i. This includes purchasing and insurance coverage
ii. Getting the risky component developed by Third party
Risk reduction: - leverage factor:
a) The project manger must consider the cost of handling the risk and the corresponding
reduction of the risk
b) Risk leverage = ( risk exposure before reduction - risk exposure after reduction) / cost of

34
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

reduction
Practical-5

Study and usage of any Design phase CASE tool

CASE Tools: -
CASE stands for Computer Aided Software Engineering. It means, development and maintenance of
software projects with help of various automated software tools. CASE tools are set of software
application programs, which are used to automate the SDLC activities. CASE tools are used by
software project managers, analysts and engineers to develop software system.

Reasons for using case tools:

• The primary reasons for using a CASE tool are:

– To increase productivity
– To help produce better quality software at lower cost
– To decrease the development time and cost.
• Various tools are incorporated in CASE and are called CASE tools, which are used to
support different stages and milestones in a software development lifecycle.
Architecture of CASE tools: -

Figure: - 5.1

• Layer 1 is the user interface whose function is to help the user to interact with core of
the system. It provides a graphical user interface to users using which interaction with the system
become easy.
• Layer 2 depicts tool management system (TMS) which constitutes multiple tools of different
category using which automation of the development process can be done. TMS may include
some tools to draw diagrams or to generate test cases.

35
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

• Layer 3 represents object management system (OMS) which represents the set of objects
generated by the users. Group of design notations, set of test cases (test suite) are treated as the
objects.
• Layer 4 represents a repository which stores the objects developed by the user. Layer 4 is
nothing but a database which stores automation files.

Components of CASE Tools: - CASE tools can be broadly divided into the following parts based
on their use at a particular SDLC stage:
 Central Repository - CASE tools require a central repository, which can serve as a source of
common, integrated and consistent information. Central repository is a central place of storage
where product specifications, requirement documents, related reports and diagrams, other useful
information regarding management are stored. Central repository also serves as data dictionary.

 Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages of
SDLC.

 Lower Case Tools - Lower CASE tools are used in the implementation, testing and
maintenance stages.

 Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC, from
Requirement gathering to Testing and documentation.

Figure: - 5.2

36
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Types of CASE tools: - Major categories of CASE tools are:

– Diagram tools
– Project Management tools
– Documentation tools
– Web Development tools
– Quality Assurance tools
– Maintenance tools

Benefits of CASE tools

1. Project Management and control is improved: CASE tools can aid the project management and
control aspects of a development environment. Some CASE tools allow for integration with
industry-standard project management methods (such as PRINCE). Others incorporate project
management tools such as PERT charts and critical path analysis. By its very nature, a CASE tool
provides the vehicle for managing more effectively the development activities of a project

2. System Quality is improved: CASE tools promote standards within a development environment.
The use of graphical tools to specify the requirements of a system can also help remove the
ambiguities that often lead to poorly defined systems. Therefore, if used correctly, a CASE tool
can help improve the quality of the specification, the subsequent design and the eventual working
system.

3. Consistency checking is automated: Large amounts of information about a business area and its
requirement are gathered during the analysis phase of an information systems development
project. Using a manual system to record and cross reference this information is both time-
consuming and inefficient. One of the advantages of using CASE tool is that all data definitions
and other relevant information can be stored in a central repository that can then be used to cross
check the consistency of the different views being modelled.

4. Productivity is increased: One of the most obvious benefits of a CASE tool is that it may
increase the productivity of the analysis team. If used properly, the CASE tool will provide a
support environment enabling analysts to share information and resources, manage the project
effectively and produce supporting documentation quickly.

5. The maintenance effort is better supported : It has been argued that CASE tools help reduce the
maintenance effort required to support the system once it is operational. CASE tools can be used
to provide comprehensive and up-to-date documentation – this is obviously a critical requirement
for any maintenance effort. CASE tools should result in better systems being developed in the
first place.

Data Flow Diagram:

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a system.
A neat and clear DFD can depict the right amount of the system requirement graphically. It can be manual,
automated, or a combination of both.
It shows how data enters and leaves the system, what changes the information, and where data is stored.

37
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be used as a
communication tool between a system analyst and any person who plays a part in the order that acts as a
starting point for redesigning a system. The DFD is also called as a data flow graph or bubble chart.

Types of DFD:
Data Flow Diagrams are either Logical or Physical.

 Logical DFD - This type of DFD concentrates on the system process, and flow of data in the system.
For example in a Banking software system, how data is moved between different entities.
 Physical DFD - This type of DFD shows how the data flow is actually implemented in the system. It
is more specific and close to the implementation.

The importance and need of different levels of DFD in software design

The main reason why the DFD technique is so important and so popular is probably because of the
fact that DFD is a very simple formalism – it is simple to understand and use. Starting with a set of
high-level functions that a system performs, a DFD model hierarchically represents various sub-
functions. In fact, any hierarchical model is simple to understand. Human mind is such that it can
easily understand any hierarchical model of a system – because in a hierarchical model, starting with
a very simple and abstract model of a system, different details of the system are slowly introduced
through different hierarchies. The data flow diagramming technique also follows a very simple set
of intuitive concepts and rules. DFD is an elegant modeling technique that turns out to be useful not
only to represent the results of structured analysis of a software problem, but also for several other
applications such as showing the flow of documents or items in an organization.

Disadvantages of DFDs: -

 Modification to a data layout in DFDs may cause the entire layout to be changed. This is because
the specific changed data will bring different data to units that it accesses. Therefore, evaluation
of the possible of the effect of the modification must be considered first.
 The number of units in a DFD in a large application is high. Therefore, maintenance is harder,
more costly and error prone. This is because the ability to access the data is passed explicitly from
one component to the other. This is why changes are impractical to be made on DFDs especially
in large system.
 DFDs are inappropriate to use in a large system because if changes are to be made on a specific
unit, there is a possibility that the whole DFD need to be changed. This is because the change may
result in different data flow into the next unit. Therefore, the whole application or system may
need modification too.

LEVEL 0: -

The first thing we must do is model the main outputs and sources of data in the scenario above. Then
we draw the system box and name the system. Next we identify the information that is flowing to the
system and from the system.

38
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Level 0 of DFD of Blogger Concept

LEVEL 1: -
The next stage is to create the Level 1 Data Flow Diagram. This highlights the main functions carried out by
the system as follows:

Level 1 of DFD of Blogger Concept

LEVEL 2: -
We now create the Level 2 Data Flow Diagrams. First 'expand' the function boxes 1.1 and 1.2 so
39
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

that we can fit the process boxes into them. Then position the data flows from Level 1 into the
correct process in Level 2 as follows:

Level 2 of DFD of Blogger Concept

40
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Practical-6

To perform unit testing and integration testing

Software testing can be stated as the process of verifying and validating that a software or application
is bug free, meets the technical requirements as guided by it’s design and development and meets the
user requirements effectively and efficiently with handling all the exceptional and boundary cases.
The process of software testing aims not only at finding faults in the existing software but also at
finding measures to improve the software in terms of efficiency, accuracy and usability. It mainly aims
at measuring specification, functionality and performance of a software program or application.
Types of Software Testing:
1. Manual Testing: Manual testing includes testing a software manually, i.e., without using any
automated tool or any script. In this type, the tester takes over the role of an end-user and tests the
software to identify any unexpected behavior or bug. There are different stages for manual testing such
as unit testing, integration testing, system testing, and user acceptance testing.
Testers use test plans, test cases, or test scenarios to test a software to ensure the completeness of
testing. Manual testing also includes exploratory testing, as testers explore the software to identify
errors in it.
2. Automation Testing: Automation testing, which is also known as Test Automation, is when the
tester writes scripts and uses another software to test the product. This process involves automation of
a manual process. Automation Testing is used to re-run the test scenarios that were performed
manually, quickly, and repeatedly.
Apart from regression testing, automation testing is also used to test the application from load,
performance, and stress point of view. It increases the test coverage, improves accuracy, and saves
time and money in comparison to manual testing.
Hierarchy of Testing Levels:

Unit testing: - Unit testing, a testing technique using which individual modules are tested to
determine if there are any issues by the developer himself. It is concerned with functional
correctness of the standalone modules. The main aim is to isolate each unit of the system to
41
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

identify, analyze and fix the defects.

Unit Testing Life cycle:-

Figure: - 6.1
Advantages of unit testing:

 Defects are found at an early stage. Since it is done by the dev team by testing individual
pieces of code before integration, it helps in fixing the issues early on in source code
without affecting other source codes.
 It helps maintain the code. Since it is done by individual developers, stress is being put on
making the code less inter dependent, which in turn reduces the chances of impacting
other sets of source code.
 It helps in reducing the cost of defect fixes since bugs are found early on in the
development cycle.
 It helps in simplifying the debugging process. Only latest changes made in the code need
to be debugged if a test case fails while doing unit testing.

Disadvantages:

 It’s difficult to write good unit tests and the whole process may take a lot of time
 A developer can make a mistake that will affect the whole system.
 Not all errors can be detected, since every module it tested separately and later
different integration bugs may appear.
 Testing will not catch every error in the program, because it cannot evaluate every
42
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

 Execution path in any but the most trivial programs. This problem is a superset of
the halting problem, which is undecidable.

 The same is true for unit testing. Additionally, unit testing by definition only tests
the functionality of the units themselves. Therefore, it will not catch integration
errors or broader system-level errors (such as functions performed across multiple
units, or non-functional test areas such as performance).

 Unit testing should be done in conjunction with other software testing activities, as
they can only show the presence or absence of particular errors; they cannot prove a
complete absence of errors.

 To guarantee correct behaviour for every execution path and every possible input,
and ensure the absence of errors, other techniques are required, namely the
application of formal methods to proving that a software component has no
unexpected behaviour.
Unit Testing Techniques:

1. Black Box Testing - Using which the user interface, input and output are tested.
2. White Box Testing - used to test each one of those functions behavior is tested.
3. Gray Box Testing - Used to execute tests, risks and assessment methods.
Integration Testing:- It tests integration or interfaces between components, interactions to
different parts of the system such as an operating system, file system and hardware or
interfaces between systems.

Fig 6.2 Figure: - 6.3

 Also after integrating two different components together we do the integration testing.
As displayed in the image below when two different modules ‘Module A’ and
‘Module B’ are integrated then the integration testing is done.

 Integration testing is done by a specific integration tester or test team.

 Integration testing follows two approach known as ‘Top Down’ approach and

43
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

‘Bottom Up’ approach as shown in the image below:

 Below are the integration testing techniques:

1. Big Bang integration testing: - In Big Bang integration testing all components or
modules are integrated simultaneously, after which everything is tested as a whole. As per
the below image all the modules from ‘Module 1’ to ‘Module 6’ are integrated
simultaneously then the Testing is carried out.

Fig 6.4

2. Top-down integration testing: Testing takes place from top to bottom, following the
control flow or architectural structure (e.g. starting from the GUI or main menu).
Components or systems are substituted by stubs. Below is the diagram of ‘Top down
Approach”

Fig 6

44
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

3. Bottom-up integration testing: Testing takes place from the bottom of the control flow
upwards. Components or systems are substituted by drivers. Below is the image of
‘Bottom up approach’:

Fig6.6

4. System Testing: - System Testing (ST) is a black box testing technique performed to
evaluate the complete system the system's compliance against specified requirements. In
System testing, the functionalities of the system are tested from an end-to-end perspective.
System Testing is usually carried out by a team that is independent of the development
team in order to measure the quality of the system unbiased. It includes both functional
and Non-Functional testing.

Fig 6.

45
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

PRACTICAL-7
To perform various white box and black box testing techniques
White Box Testing:
White box testing techniques analyze the internal structures the used data structures, internal design, code
structure and the working of the software rather than just the functionality as in black box testing. It is also
called glass box testing or clear box testing or structural testing.
Working process of white box testing:
 Input: Requirements, Functional specifications, design documents, source code.
 Processing: Performing risk analysis for guiding through the entire process.
 Proper test planning: Designing test cases so as to cover entire code. Execute rinse-repeat until
error-free software is reached. Also, the results are communicated.
 Output: Preparing final report of the entire testing process.

Testing techniques:
 Statement coverage: In this technique, the aim is to traverse all statement at least once. Hence, each
line of code is tested. In case of a flowchart, every node must be traversed at least once. Since all lines
of code are covered, helps in pointing out faulty code.

 Branch Coverage: In this technique, test cases are designed so that each branch from all decision
points are traversed at least once. In a flowchart, all edges must be traversed at least once.

 Condition Coverage: In this technique, all individual conditions must be covered as shown in the
following example:

1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
In this example, there are 2 conditions: X == 0 and Y == 0. Now, test these conditions get TRUE and
FALSE as their values. One possible example would be:
 #TC1 – X = 0, Y = 55
 #TC2 – X = 5, Y = 0

Path Testing:

In the path testing, we will write the flow graphs and test all independent paths. Here writing the
flow graph implies that flow graphs are representing the flow of the program and also show how
every program is added with one another as we can see in the below image:
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

And test all the independent paths implies that suppose a path from main() to function G, first set the
parameters and test if the program is correct in that particular path, and in the same way test all other
paths and fix the bugs.

Flow graph notation: It is a directed graph consisting of nodes and edges. Each node represents a sequence of
statements, or a decision point. A predicate node is the one that represents a decision point that contains a
condition after which the graph splits. Regions are bounded by nodes and edges.

Loop Testing: Loops are widely used and these are fundamental to many algorithms hence, their In the loop
testing, we will test the loops such as while, for, and do-while, etc. and also check for ending condition if
working correctly and if the size of the conditions is enough.

47
 Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

For example: we have one program where the developers have given about 50,000 loops.

1. {  
2. while(50,000)  
3. ……  
4. ……  
5. }  

We cannot test this program manually for all the 50,000 loops cycle. So we write a small program that helps
for all 50,000 cycles, as we can see in the below program, that test P is written in the similar language as the
source code program, and this is known as a Unit test. And it is written by the developers only.

1. Test P  
2. {  
3. ……  
4. …… }  

Nested loops: For nested loops, all the loops are set to their minimum count and we start from the innermost
loop. Simple loop tests are conducted for the innermost loop and this is worked outwards till all the loops
have been tested.

Concatenated loops: Independent loops, one after another. Simple loop tests are applied for each.
If they’re not independent, treat them like nesting.

Advantages:
1. White box testing is very thorough as the entire code and structures are tested.
2. It results in the optimization of code removing error and helps in removing extra lines of code.
3. It can start at an earlier stage as it doesn’t require any interface as in case of black box testing.
4. Easy to automate.

Disadvantages:
1. Main disadvantage is that it is very expensive.
2. Redesign of code and rewriting code needs test cases to be written again.
3. Testers are required to have in-depth knowledge of the code and programming language as opposed
to black box testing.
4. Missing functionalities cannot be detected as the code that exists is tested.
5. Very complex and at times not realistic.

Black Box Testing:

Black-box testing is a method of software testing that examines the functionality of an application based on
the specifications. It is also known as Specifications based testing. Independent Testing Team usually
performs this type of testing during the software testing life cycle.
This method of test can be applied to each and every level of software testing such as unit, integration,
system and acceptance testing.
48
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Generic steps of black box testing

o The black box test is based on the specification of requirements, so it is examined in the beginning.
o In the second step, the tester creates a positive test scenario and an adverse test scenario by selecting
valid and invalid input values to check that the software is processing them correctly or incorrectly.
o In the third step, the tester develops various test cases such as decision table, all pairs test, equivalent
division, error estimation, cause-effect graph, etc.
o The fourth phase includes the execution of all test cases.
o In the fifth step, the tester compares the expected output against the actual output.
o In the sixth and final step, if there is any flaw in the software, then it is cured and tested again.

How to do Black Box Testing

Here are the generic steps followed to carry out any type of Black Box Testing.

 Initially, the requirements and specifications of the system are examined.

 Tester chooses valid inputs (positive test scenario) to check whether SUT processes them correctly.
Also, some invalid inputs (negative test scenario) are chosen to verify that the SUT is able to detect
them.
 Tester determines expected outputs for all those inputs.
 Software tester constructs test cases with the selected inputs.
 The test cases are executed.
 Software tester compares the actual outputs with the expected outputs.
 Defects if any are fixed and re-tested.

Types of Black Box Testing

There are many types of Black Box Testing but the following are the prominent ones -

 Functional testing - This black box testing type is related to the functional requirements of a system;
it is done by software testers.
 Non-functional testing - This type of black box testing is not related to testing of specific
functionality, but non-functional requirements such as performance, scalability, usability.
 Regression testing – Regression Testing is done after code fixes, upgrades or any other system
maintenance to check the new code has not affected the existing code.
49
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Tools used for Black Box Testing:

Tools used for Black box testing largely depend on the type of black box testing you are doing.

 For Functional/ Regression Tests you can use - QTP, Selenium

 For Non-Functional Tests, you can use - Load Runner, Jmeter

Black Box Testing Techniques

Following are the prominent Test Strategy amongst the many used in Black box Testing

 Equivalence Class Testing: It is used to minimize the number of possible test cases to an optimum
level while maintains reasonable test coverage.
 Boundary Value Testing: Boundary value testing is focused on the values at boundaries. This
technique determines whether a certain range of values are acceptable by the system or not. It is very
useful in reducing the number of test cases. It is most suitable for the systems where an input is
within certain ranges.
 Decision Table Testing: A decision table puts causes and their effects in a matrix. There is a unique
combination in each column.

Advantages of Black Box Testing

 Tester can be non-technical.

 Used to verify contradictions in actual system and the specifications.
 Test cases can be designed as soon as the functional specifications are complete

Disadvantages of Black Box Testing

 The test inputs needs to be from large sample space.

 It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and
difficult
 Chances of having unidentified paths during this testing

PRACTICAL-8
Testing a Website

Web testing is the name given to software testing that focuses on web applications. Complete testing of

a web-based system before going live can help address issues before the system is revealed to the public.

50
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Documentation testing

We should start with the preparatory phase, testing the documentation. The tester studies the received
documentation (analyses the defined site functionality, examines the final layouts of the site and makes a
website test plan for further testing).

The main artifacts related to the website testing are analysed on this stage:

 Requirements
 Test Plan
 Test Cases
 Traceability Matrix.

Functionality Testing

Functionality Testing of a Website is a process that includes several testing parameters like user interface,
APIs, database testing, security testing, client and server testing and basic website functionalities. Functional
testing is very convenient and it allows users to perform both manual and automated testing. It is performed
to test the functionalities of each feature on the website.

Web based Testing Activities includes:

Test all links in your webpages are working correctly and make sure there are no broken links. Links to be
checked will include -

 Outgoing links
 Internal links
 Anchor Links
 MailTo Links

Test Forms are working as expected. This will include-

 Scripting checks on the form are working as expected. For example- if a user does not fill a
mandatory field in a form an error message is shown.
 Check default values are being populated
 Once submitted, the data in the forms is submitted to a live database or is linked to a working email
address
 Forms are optimally formatted for better readability

Test Cookies are working as expected. Cookies are small files used by websites to primarily remember
active user sessions so you do not need to log in every time you visit a website. Cookie Testing will include

 Testing cookies (sessions) are deleted either when cache is cleared or when they reach their expiry.
 Delete cookies (sessions) and test that login credentials are asked for when you next visit the site.

51
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Test HTML and CSS to ensure that search engines can crawl your site easily. This will include

 Checking for Syntax Errors

 Readable Color Schemas
 Standard Compliance. Ensure standards such W3C, OASIS, IETF, ISO, ECMA, or WS-I are
followed.

Test business workflow

This will include

 Testing your end - to - end workflow/ business scenarios which takes the user through a series of
webpages to complete.
 Test negative scenarios as well, such that when a user executes an unexpected step, appropriate error
message or help is shown in your web application.

Usability testing

Usability Testing has now become a vital part of any web based project. It can be carried out by
testers like you or a small focus group similar to the target audience of the web application.

Test the site Navigation:

 Menus, buttons or Links to different pages on your site should be easily visible and consistent on all
webpages.

Test the Content:

 Content should be legible with no spelling or grammatical errors.

 Images if present should contain an "alt" text

UI (User Interface) testing

User Interface (UI) testing is provided to verify the graphic user interface of your website meets the
specifications.

Here are some verifications for UI testing of a website:

 Compliance with the standards of graphical interfaces

 Design elements evaluation: layout, colors, fonts, font sizes, labels, text boxes, text formatting,
captions, buttons, lists, icons, links
 Testing with different screen resolutions
 Testing of localized versions: accuracy of translation (multilanguage, multicurrency), checking the
length of names of interface elements, etc.
 Testing the graphical user interface on target devices: smartphones and tablets.

52
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

Compatibility (Configuration) testing

Compatibility (Configuration) testing is performed to test your website with each one of the supported
software and hardware configurations:

 OS Configuration
 Browser Configuration
 Database Configuration

Cross-platform testing allows evaluating the work of your site in different OS (both desktop and mobile):
Windows, iOS/Mac OS, Linux, Android, and BlackBerry etc.

Cross-browser website testing methods help to verify the correct work of the site in different browser
configurations: Mozilla Firefox, Google Chrome, Internet Explorer, and Opera etc.

Database Testing:

Database is one critical component of your web application and stress must be laid to test it thoroughly.
Testing activities will include-

 Test if any errors are shown while executing queries

 Data Integrity is maintained while creating, updating or deleting data in database.
 Check response time of queries and fine tune them if necessary.
 Test data retrieved from your database is shown accurately in your web application

Performance testing

This will ensure your site works under all loads. Software Testing activities will include but not limited to -

 Website application response times at different connection speeds

 Load test your web application to determine its behavior under normal and peak loads
 Stress test your web site to determine its break point when pushed to beyond normal loads at peak
time.
 Test if a crash occurs due to peak load, how does the site recover from such an event
 Make sure optimization techniques like gzip compression, browser and server side cache enabled to
reduce load times

Security testing

Security Testing is vital for e-commerce website that store sensitive customer information like credit cards.
Testing Activities will include-

 Test unauthorized access to secure pages should not be permitted

53
Software Engineering Lab Karan Gupta
BTCS 506-18 1904018

 Restricted files should not be downloadable without appropriate access

 Check sessions are automatically killed after prolonged user inactivity
 On use of SSL certificates, website should re-direct to encrypted SSL pages.

54