DELHI TECHNOLOGICAL UNIVERSITY

(Formerly Delhi College of Engineering)

   Software Engineering - CO 301


Session: 2019-2019

Odd Semester

Submitted to: Submitted By:


Ms. Anjum Shubham Anand

Assistant Professor 2K17/CO/336

Page 1 of 21
 Table of Contents


S.No Experiment Date Signature

10

Page 2 of 21
 EXPERIMENT-1

AIM: To prepare problem statement for bank loan management system.

REQUIREMENTS:

• Software Requirements(Minimum Requirements):

◦ Operating System: UNIX
◦ Text Editor: Visual Studio Code 2017
◦ Front End: HTML5, SCSS, Typescript/Javascript
◦ Language: NodeJS, Python, C++, Bash
◦ Database: MongoDB
• Hardware Requirements:
◦ Minimum Requirements
- RAM: 2GB 

- Hard Disk: 64GB

- Processor: Pentium 4 processor or higher( to run a web

browser)
◦ Optimum Requirements
- RAM: 4GB 

- Hard Disk: 128GB

- Processor: 2nd-generation Core i5 (2GHz+), 3rd/4th-

generation Core i5 processor, or equivalent.


THEORY:

• The aim of Bank Loan Management System is to provide a fast and

robust web application which will assist in an effective management of
loan accounts of the customer.

• In finance, a loan is the lending of money from one individual,

organisation or entity to another individual organisation or entity. Loan
could be provided by an organisation or individual to a person at an
interest rate. In a loan, the borrower initially receives or borrows an
amount of money called Principal from the lender, and is obligated to
repay an equal amount of money to the lender at a later time. Acting as
a provider of loans is one of the principal tasks financial institutions
such as banks and credit card companies.

• Hence bank loan management system is a very efficient process to

handle all loan related transaction in a very accurate and convenient
way. It is very helpful for those banking staffs who are in the charge of
loan management, it provides a very reliable and convenient form for
every loan and EMI related transaction and their related details. It is also
a very user friendly and understandable form of storing customer’s
details & transaction information.

Page 3 of 21
PROBLEM STATEMENT:

Today the need of simplicity has driven application software programming

to a new level. This project is a transaction related information storing
project which will be used by the staffs of a bank for handling their
customers who have loans or want to have loan. Operator need to use the
registration form to create account for the new customers, and EMI details
and the loan_ detail forms are present for dealing with the old customers
or those who are already registered .This application has a user friendly
interface so that the banking staffs can easily and efficiently use the
software and its features. It also incorporates steps for getting the
transaction details on every transaction and next EMI date and remaining
amount details that helps the operators to use the application efficiently.

Usually Loan Department maintains all loan related information and

transaction. Which comes from different branches. At present loan
department section use a paper-based system to store and analyse these
information. Some software like Ms. Word, Ms Excel, Ms Access etc. used
in a limited basis.

To manage all these information a paper based-manual system is not

efficient. In BSB there are several departments and each department has
their own data to process. Therefore huge data collection is going all the
day and managing all these information in a paper based system is very
difficult, time consuming and enormous. So the challenge is to build
software to overcome these problems.

In the paper-based system other problems they face are:

• Documents are very large.

• Stake of files that is very difficult to maintain

• Extra overhead works

• Extra manpower, so more expenses is needed in every step to manage

all of these.

CONCLUSION: 

The proposed bank loan management software is a web application that

keeps track of all the aspects a bank requires, like information about
customers, their loan outstanding loan, their payment history and their
amount. It allows to handle all loan related transaction in a very accurate and
convenient way. It is very helpful for those banking staffs who are in the
charge of loan management, it provides a very reliable and convenient form
for every loan and EMI related transaction and their related details. It is also
a very user friendly and understandable form of storing customer’s details &
transaction information.

Page 4 of 21
 EXPERIMENT-2

AIM: Understanding SRS for Bank loan management system

THEORY:
A software requirements specification (SRS) is a detailed description of a
software system to be developed with its functional and non-functional
requirements. The SRS is developed based on the agreement between
customers and contractors. It may include the use cases of how user is
going to interact with software system. The software requirement
specification document consistent of all necessary requirements required for
project development. To develop the software system we should have a clear
understanding of Software system. To achieve this we need to continuous
communication with customers to gather all requirements.

A good SRS defines the how Software System will interact with all internal
modules, hardware, communication with other programs and human user
interactions with a wide range of real life scenarios. Using the SRS (Software
Requirement Specification) document on QA lead, managers creates test
plan.


SOFTWARE REQUIREMENT SPECIFICATION (SRS)

1. INTRODUCTION
A. PURPOSE
To handle all loan related transaction in a very accurate and
convenient way. It is very helpful for those banking staffs who are in
the charge of loan management, it provides a very reliable and
convenient form for every loan and EMI related transaction and their
related details. It is also a very user friendly and understandable form
of storing customer’s details & transaction information. The data
gathered would also help in opening up new scopes for banking
trends of our customers and better prediction of success rates of
loans later in the development phase.

B. GOALS AND OBJECTIVES

• Customer account is created and maintained with all the proper
customer details and loan related information.

• All the equally monthly instalment related transaction information is

showed in the customer receive form.

• The entire customer related information for those customers who

have missed their EMI are shown in the defaulter list.

• Very easy to handle and operate.

• As primary key is present so data duplication is blocked.

Page 5 of 21
 C. SCOPE

The web application is used for maintaining all the processes and
activities of BLMS. The main focus of the system right now would be
efficient loan management and EMI generation system though while
developing the system, there shall be space for further addition of
other features.

2. GENERAL DESCRIPTION
A. PRODUCT DESCRIPTION
The system that is going to be developed is Bank Loan Management
System (BLMS). This is a web-based application system that is to be
used by the banks and it’s respective branches as a way to efficiently
manage their loaning system. The need for a good efficient loaning
system is essential as it not only will allow the bankers to keep track
of instalments and pay logs of customers but also customers would
be able to easily pay off their dues without financially restraining them
much.

The system will keep track of payment logs of all customers and a
crude data analysis on this loan data would be essential in later
phases of development to come up with a precise algorithm to
predict optimum rate of interests that benefit both the Bank and the
end user, coming up and development of more flexible financial
options and establishing a good loan success rate. A good loan
success rate could be defined as ratio of loans that didn’t defaulted
over total loans disbursed. The software will make substantial
development in field of banking, hence making the sector more open
to the general populace.

B. USER DESCRIPTION
1. System Owner: The Bank

2. System Users:

- Administrator: Has full privilege on system functionality

- Branch Admins: Have read/write privilege on a branch’s database

- Staff: Have basic privilege to perform basic functionalities and

system functions as assigned by Branch Admins

- Customer: Can view their account information, can look up their

transaction history, their impending EMI date if any with amount
and apply for loan online

- Public: Can apply for creation of a new account, view the bank
homepage and benefits related to registering an account along
with contact information regarding every branch of the bank.
Public users can also look up addresses of all the branches of the
bank.

Page 6 of 21
 C. DESIGN CONSTRAINTS
The developed product should have an aesthetically simplistic UI.
Titles should be short and descriptive and short text should be used
in body which could be later expanded by viewer in a full read mode.
The web app should be light and needs to be able to handle
concurrent requests. The response time of every synchronous
request should be smaller than 100ms. API’s or endpoints with a
higher response time should be made asynchronous.

3. SYSTEM FEATURES
A. FUNCTIONAL REQUIRMENTS
- Account Creation: New users can apply for opening of a new account.
They are required to submit their basic information along with govt ID
proof. This account is to be verified by the Branch Admin.

- Login: The system provides a highly secure login gateway to

authenticate and authorise rightful owners of an account by the
means of username/password, OTP to their registered mobile
phones/emails and an authentication code as a part of 2 step login.

- Loan application: A loan request is dispatched from the user end.

This proposal is verified in the Loan Department. The result of the
verification is send to the management. Then the management
decides whether the proposal is accepted or denied and the
customer is constantly updated about his proposal’s status.

- Loan Processing: When the proposal is accepted, the detail ed

information of the loan proposal is to collected and sent to Not Due
section in the loan Department. This section is responsible for giving
money for the loan and maintains the related information and
transaction. A new account number and loan number opened for
that user in the Not Due section which contain sanction amount,
instalment amount, interest during construction period amount etc.

- Loan Analysis: Over Due Section collects instalment amount from

the client. This section also collects other charge from the client.
After collecting the amount from the client, this section updates the
current loan balance and also sends the information to Not Due
section. Loan recovery balance report is prepared here. If anybody
fail to give the instalment for a long time than this section takes
necessary steps, like- Re-phase/Write-off etc.

- Payment Gateways: All payment gateways would be 256-Bit

encrypted to ensure state of art security for all it’s clients. Customers
can feel extremely safe and all their payment and other confidential
information would be encrypted before being stored into the Bank’s
database.

Page 7 of 21
 B. NON-FUNCTIONAL REQUIREMENTS
- Availability: The website should be available for 24 hours a day. In
case of a hardware failure or database corruption, a replacement page
will be shown.

- Security: Data like personal details, login ID and passwords must

remain confidential. To keep those data safe, there is a need for a
highly sophisticated algorithms. The system must automatically logout
all customers after a period of inactivity. A lot of focus should be on
making the payments gateway extremely secure by using 256-Bit
encryption.

- Performance: The system should be minimalistic and the user should

not have to wait long enough for any of their requests. It should have
socket connections wherever required for smooth and real time
updates and longer tasks should be made asynchronous.

- Reliability: The system operations should be reliable enough to store

sensitive data due to the importance of data and the damages that
can be caused by incomplete and incorrect data.

- User Satisfaction: Whatever information is provided should satisfy

the user. User satisfaction is one of our main concerns of our website.

- Backup: To maintain all records a backup system should be there.

4. REQUIREMENTS:

A. Software Requirements(Minimum Requirements):

- Operating System: UNIX

- Text Editor: Visual Studio Code 2017

- Front End: HTML5, SCSS, Typescript/Javascript

- Language: NodeJS, Python, C++, Bash

- Database: MongoDB

B. Hardware Requirements:
• Minimum Requirements
- RAM: 2GB 

- Hard Disk: 64GB

- Processor: Pentium 4 processor or higher( to run a web browser)

• Optimum Requirements
- RAM: 4GB 

- Hard Disk: 128GB

- Processor: 2nd-generation Core i5 (2GHz+), 3rd/4th-generation

Core i5 processor, or equivalent.


CONCLUSION: The concept of SRS has been understood and SRS for Bank
Loan Management System has been made.

Page 8 of 21
 EXPERIMENT-3

AIM: To draw a sample Entity Relationship Diagram for Bank Loan

Management System.

THEORY:
ER or (Entity Relational Model) is a high-level conceptual data model
diagram. Entity-Relation model is based on the notion of real-world entities
and the relationship between them.

Entity relationship diagram displays the relationships of entity set stored in a

database. In other words, we can say that ER diagrams help you to explain
the logical structure of databases.

CONCLUSION: The concept of an Entity relationship diagram is understood

and an ER diagram for blood bank management system has been drawn.

Page 9 of 21
 EXPERIMENT-4

AIM: To draw data flow diagram for Bank Loan Management System.

THEORY:

A data flow diagram (DFD) maps out the flow of information for any process
or system. It uses defined symbols like rectangles, circles and arrows, plus
short text labels, to show data inputs, outputs, storage points and the routes
between each destination. Data flowcharts can range from simple, even
hand-drawn process overviews, to in-depth, multi-level DFDs that dig
progressively deeper into how the data is handled. 

Higher level DFDs are partitioned into low levels-hacking more information
and functional elements. Levels in DFD are numbered 0, 1, 2 or beyond.

• LEVEL-0 DFD: It is also known as context diagram. It’s designed to be

an abstraction view, showing the system as a single process with its
relationship to external entities. It represents the entire system as a
single bubble with input and output data indicated by incoming/
outgoing arrows.

• LEVEL-1 DFD: In 1-level DFD, context diagram is decomposed into

multiple bubbles/processes.in this level we highlight the main functions
of the system and breakdown the high level process of 0-level DFD
into subprocesses.

• LEVEL-2 DFD: 2-level DFD goes one step deeper into parts of 1-level
DFD.It can be used to plan or record the specific/necessary detail
about the system’s functioning.

A. LEVEL-0 DFD

Page 10 of 21
B. LEVEL-1 DFD

CONCLUSION:
The concept of Data flow diagram has been understood and data flow
diagrams for Blood Bank management system has been drawn.

Page 11 of 21
 EXPERIMENT-5

AIM: To Draw a use case diagram for bank loan management system.

THEORY:

A use case diagram at its simplest is a representation of a user's interaction

with the system that shows the relationship between the user and the
different use cases in which the user is involved. A use case diagram can
identify the different types of users of a system and the different use cases
and will often be accompanied by other types of diagrams as well. The use
cases are represented by either circles or ellipses.

A use case diagram is a simple diagram which gives us an overview about

the use of a system- 

• It only summarises some of the relationships between use cases, actors,

and systems.

• It does not show the order in which steps are performed to achieve the
goals of each use case.


USE CASE ACTOR DESCRIPTION

LOGIN Admin, Branch Admin, Allows the user to login to the loan management
Customer portal.

APPLY_LOAD Customer Customer can apply for a loan of his desired

amount along with certain information.
APPROVE_LOAN Branch Admin Branch Admin after reviewing the loan data, can
approve it and money gets sanctioned to the
user’s loan account.

DECLINE_LOAN Branch Admin Branch Admin after reviewing the loan data, can
reject it and same is reflected to customer’s end.

APPROVE_ACCOUNT Admin When a user creates an account, his account is

approved by the admin

REJECT_ACCOUNT Admin Admin can reject an account’s proposal by a user

APPOINT_BRANCH_AD Admin Admin can appoint a new branch admin from

MIN existing staff members

REMOVE_BRANCH_AD Admin Admin can remove any of the existing branch

MIN admins.

GENERATE_REPORTS Admin Admin can generate system reports

GENERATE_TRANSACTI Branch Admin Branch Admin can generate transaction reports for
ON_REPORTS each of his actions.

TRACK STATUS Customer Customer can track real time status of his current
requests like account approval, loan approval etc.

PAY_INSTALLMENT Customer Customer can pay his due instalment from Bank’s
portal.

Page 12 of 21
CONCLUSION:
The concept of a use case diagram has been understood and a use case
diagram along with a use case table for Bank loan management system has
been drawn.

Page 13 of 21
 EXPERIMENT-6

AIM: To write a program to count lines of code in a c++ file.

Theory:
Here, we’re interested in calculating the total lines of code in a certain c++
file. Easiest way to do this would be to utilise the inbuilt fstream library of
c++ which is very flexible and powerful when it comes to file handling and
manipulation. We open a file in read only mode and count the instances of
‘\n’ throughout the file to get a count of total number of lines in our program.

Code:

#include <iostream>

#include <fstream>

int main() {

int count = 0;

std::string line;

std::string FILE_PATH = “PATH_TO_YOUR_FILE”;

std::ifstream file(FILE_PATH);

while ( std::getline(file, line) ) {

count += 1;

std::cout << “Line count -> ” << count << “\n”;

return 0;

OUTPUT:
Running the following code locally on a sample file template.cpp, we get the
following output (We’re supplying command line arguments in our demo run):

CONCLUSION:

We successfully wrote a working program to calculate lines of code in a c++
file.

Page 14 of 21
 EXPERIMENT-7

AIM: Write a program to perform function point calculation.

Theory:
• Function Point (FP) is an element of software development which helps to
approximate the cost of development early in the process. It may measure
functionality from user’s point of view.

• Steps to calculate the function point are as follows:

• F = 14 * scale

Scale varies from 0 to 5 according to character of Complexity Adjustment
Factor (CAF). Below table shows scale:

0: No Influence, 1: Incidental, 2: Moderate, 3: Average, 4: Significant, 5:
Essential.

• Then we calculate the Complexity Adjustment Factor (CAF):


CAF = 0.65 + ( 0.01 * F )

• Calculate Unadjusted Function Point (UFP):


FUNCTION LOW AVG HIGH
UNITS

EL 3 4 6

EO 4 5 7

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10

Calculate each individual function point to corresponding values in the

table.

• Calculate Function Point


FP = UFP * CAF

CODE:
#include <iostream>

int main() {

    int weights[5][3] = { {3,4,6},{4,5,7},{3,4,6},{7,10,15},{5,7,10} };

    int UFP=0, F=0, rating, i, j;

    char func_units[][30]={

        "External Inputs",

        "External Outputs",

        "External Enquiries",

Page 15 of 21
         "Internal Logical Files",

        "External Interface Files"

    };

    char complexity[3][10] = { 

        "low",

        "average",

        "high"

    };

    float FP,CAF;

    int input[5][3] = { {0,50,40},{0,40,0},{0,35,0},{0,6,0},{0,4,0} };

    for(i=0;i<5;i++) {

        for(j=0;j<3;j++) {

            UFP=UFP+(input[i][j]*weights[i][j]);

        }

    }

    printf("Unadjusted Function Point(UFP) = %d\n",UFP);

    rating = 3;

    F = rating * 14;

    CAF = 0.65 + (0.01*F);

    FP = UFP*CAF;

    printf("Adjusted Function Point = %f\n",FP);

    return 0;

OUTPUT:
For simplicity, all complexity adjustment factors are taken as average.

CONCLUSION:
We’ve written a program to perform function point calculation.

Page 16 of 21
 EXPERIMENT-8

AIM: Write a program to implement basic COCOMO cost estimation model.

THEORY:

COCOMO (Constructive Cost Model) is a regression model based on LOC,
i.e number of Lines of Code. It is a procedural cost estimate model for
software projects and often used as a process of reliably predicting the
various parameters associated with making a project such as size, effort,
cost, time and quality.

The initial estimate (also called nominal estimate) is determined by an
equation of the form used in the static single variable models, using KDLOC
as the measure of the size. To determine the initial effort Ei in person-months
the equation used is of the type is shown below

Ei = A*(KDLOC)B

A and B can be derived from the following table depending on project size:

Software Project A B

Organic 2.4 1.05

Semi Detached 3.0 1.12

Embedded 3.6 1.20

CODE:

#include <iostream>

#include <cmath>

int main() {

    float effort,time,staff,productivity;

    float table[3][4]={

{2.4,1.05,2.5,0.38},

{3.0,1.12,2.5,0.35},

{3.6,1.20,2.5,0.32}

};

    int size, model;

    char mode[3][15]={

        "Organic",

        "Semi-Detached",

Page 17 of 21
         "Embedded"

    };

    printf("Enter size of project (in KLOC) : ");

    scanf("%d",&size);

    if(size>=2 && size<=50) {

        model=0;     //organic

    } else if(size>50 && size<=300) {

        model=1;     //semi-detached

    } else {

        model=2;     //embedded

    }

    effort = table[model][0] * pow(size,table[model][1]);

    time = table[model][2] * pow(effort,table[model][3]);

    staff = effort/time;

    productivity = size/effort;

    printf("\nEffort = %f Person-Month", effort);

    printf("\n\nDevelopment Time = %f Months", time);

    printf("\n\nAverage Staff Required = %d Persons", staff);

    printf("\n\nProductivity = %f KLOC/Person-
Month",productivity);

    return 0;

} 

OUTPUT:

Output of the program assuming KLOC = 200 is as follows:




CONCLUSION:
We’ve successfully written a program to compute the basic COCOMO
estimation of a project based on KLOC count.

Page 18 of 21
 EXPERIMENT-9

AIM: To write a program to get token count in a c++ file.

THEORY:
We use a red black tree (inbuilt std::map library in c++) to store all tokens
and store their count alongside them. Then we simply output the contents of
our map into the output buffer to get count of different tokens. We can also
simply add up the contents of std::map by iterating through it if we’re not
interested in the individual token count.

CODE:

#include <iostream>

#include <string>

#include <vector>

#include <fstream>

#include <map>

std::vector<std::string> get_lines( const std::string &fname ) {

std::vector<std::string> lines;

std::ifstream file(fname);

std::string a_line;

while( std::getline( file, a_line ) ) { lines.push_back(a_line) };

return lines;

std::vector<std::string> split(std::string str, const std::string&

delimiters) {

std::vector<std::string> tokens; std::size_t from = 0;

std::size_t pos = str.find_first_of( delimiters, 0 );

while( pos != std::string::npos ) {

if( pos != from )tokens.push_back( str.substr( from, pos-

from ) ) ;

from = pos+1 ;

pos = str.find_first_of( delimiters, from ) ;

if( from < str.size() ) { tokens.push_back( str.substr(from) ) };

return tokens ;

Page 19 of 21
 int main() {

const auto lines = get_lines( __FILE__ ) ;

std::map< std::string, int > map ;

for( std::string str : lines ) {

const std::string delimiters = " \t\n.'\"(){};=!+-,&<>[]#:\\/";

for( auto token : split( str, delimiters ) ) {

++map[token] ;

for ( const auto& pair : map ) {

std::cout << pair.first << " : " << pair.second << “, ” ;

OUTPUT:
Running the following code locally on a sample file template.cpp, we get the
following output (We’re supplying command line arguments in our demo run):

CONCLUSION: We’ve successfully written and run a c++ program that

counts the number of tokens in a c++ program.

Page 20 of 21
 EXPERIMENT-10

AIM: To design a sequence diagram for each of our use cases for Bank loan
management system.

Theory:
A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place. We can
also use the terms event diagrams or event scenarios to refer to a sequence
diagram. Sequence diagrams describe how and in what order the objects in
a system function. These diagrams are widely used by businessmen and
software developers to document and understand requirements for new and
existing systems.

SEQUENCE DIAGRAM:

CONCLUSION: We’ve designed a sequence diagram for Bank loan

management system.

Page 21 of 21