ABC Company Project Report

A Project Report on
ABC Finance Company

Submitted in Partial Fulfillment of Requirement

For the VI sem MCA Project

Under
Visvesvaraya Technological University, Belgaum
Karnataka

By

Srinivas G
1RZ10MCA33

Under the guidance of

R. V. COLLEGE OF ENGINEERING
MYSORE ROAD, BANGALORE 560 059
June 2013

Mr. Navin kumar
Senior Consultant
Capgemini India Pvt Ltd
A1 Technology Park,
Pune 412114

Dr. B Renuka Prasad
Asst. Professor
R.V.College of Engineering
Mysore Road
Bangalore 560059

R.V. COLLEGE OF ENGINEERING
DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS
AFFILIATED TO VISVESVARAYA TECHNOLOGICAL UNIVERSITY BELGAUM
APPROVED BY ALL INDIA COUNCIL FOR TECHNICAL EDUCATION NEW DELHI
BANGALORE - 560059

JUNE 2013

CERTIFICATE

This is to certify that the project entitled ABC Finance Company Submitted in
Partial Fulfillment of the VI sem MCA Project is a Result of the Bonafide Work
Carried Out by

Srinivas G
1RZ10MCA33

During the Academic year 2013

Principal
R. V. College of engineering
Bangalore - 560059
Dr. B Renuka Prasad
Asst. Professor
Department of MCA
Mysore Road
Bangalore 560059
Dr. Sumithra Devi K.A
Professor and Director
Department of MCA
Mysore Road
Bangalore 560059

UNDERTAKING BY THE STUDENT

I, Srinivas G, 1RZ10MCA33, hereby declare that the project ABC Finance
Company is carried out and completed successfully by me and is my original work
as assigned by the company.

Srinivas G
(1RZ10MCA33)

ACKNOWLEDGEMENT

I express my sincere gratitude to our beloved Principal, Prof.
B.S.Satyanarayana, RVCE, Bangalore, for all the encouragement and permitting me
to do this project at Capgemini India Pvt Ltd, Pune.
I express my sincere thanks to Dr. Sumithra Devi K. A., Director,
Department of MCA, for her inspiring guidance and encouragement throughout
the course of work.
I express my sincere gratitude to my external guide Mr. Navin kumar, Senior
Consultant at Capgemini India Pvt Ltd, Pune for his guidance, throughout the
project.
I express my sincere thanks to my internal guide Dr. B Renuka Prasad, Asst.
Professor, Department of MCA, for his extra support, inspiring guidance and
encouragement throughout the course of work.

Srinivas G
1RZ10MCA33

INDEX
College Certificate i
Company Certificate ii
Undertaking of the student iii
Acknowledgement iv
List of Figures v
List of tables vi
Synopsis vii
Page No.
CHAPTER 1: PREAMBLE
1.1 Introduction 1
1.2 Project Description 1
1.3 Literature Survey 2
1.4 Features of the Project 6
1.5 Platform used in Implementing Project 6
1.6 Timeline of the Project 7
1.7 Dissertation 8
1.8 References 8
CHAPTER 2: SOFTWARE REQUIREMENT SPECIFICATION
2.1 Introduction 13
2.2 General Description 19
2.3 Functional Requirement 20
2.4 External Requirement 21
2.5 Performance Requirement 22
2.6 Design Constraint 23
CHAPTER 3: DESIGN DOCUMENT SPECIFICATION
3.1 Architectural Design 15
3.2 Detailed Design 26
CHAPTER 4: TESTING AND RESULTS
4.1 Testing 38
4.2 Results 44
4.3 Conclusion and Future Enhancement 52
ANNEXURE 53
BIBLIOGRAPHY 61
LIST OF FIGURES
Figure No. Particulars Page No
1.1 Overview of project 1
1.1 Timeline of the Project 7
3.1 E-R Diagram of Application module 17
3.2 E-R Diagram of Payments module 18
3.3 Level-0 DFD 19
3.4 Level-1 DFD 20
3.5 Level-2 DFD 21
3.6 Structure chart 22
4.1 Snap shot of Blank Field 44
4.2 Snap shot of loan details 45
4.3 Snap shot of loan condition 46
4.4 Snap shot of repayment period condition 47
4.5 Snap shot of updated details 48
4.6 Snap shot of blank field 49
4.7 Snap shot of loan details 50
4.8 Snap shot of options 51
A.1 Blank field 53
A.2 Loan details 54
A.3 Loan Condition 55
A.4 Repayment Period 56
A.5 Updated details 57
A.6 Blank field 58
A.7 Loan details 59
A.8 Options required 60
LIST OF TABLES
Table no. Particulars Page No.
3.1 Applications master Table 22
3.2 Payments master Table 24
3.3 Error codes 35
4.1 Test Cases 39
SYNOPSIS
ABC finance company is a company which provides loans to its customers. Based on the
functionality the system can be divided into two subsystems.
1. Applications. 2. Payments.
The Applications are used when ever a customer comes to avail a loan, he/she is asked to
give the required details which his/her Personal details and Rating details [DOB,
Salary/month, Assets Value (Rupee value of any vehicles, property he/she owns),].Using
the rating details we calculate an amount ( the maximum amount of loan, which the
company can provide the customer). If he/she is fine with that amount, we carry on with
further processing.
The customer is asked to give the loan details (Loan amount the customer is planning to
take, and also the repayment period). Based on the loan details we calculate the EMI and
convey it to the customer. The customer can make inquiry for the EMI any number of
times (i.e., for any permutations and combinations of Loan amount and repayment
period). Once the customer decides upon the amount he is planning to take and the
repayment period, he's provided with an automatically generated customer number which
is a must for any further transaction with the company.
When the customer comes to make his loan repayments, payments department attends
him/her. The customer is allowed to pay his EMI through Cash or a Cheque. We have
some pre-defined rules according to which surcharges are levied on customers who do
not make the payments regularly. If at any point of time, the due amount to date (that
should have been paid by now, but not paid), is greater than 4 times his EMI then, his
tenure is cancelled and he will be subject to juridiction. A warning letter will be sent to
the customer when the total amount due becomes greater than 3 times the EMI.
ABC Finance Company June 2013
Department of MCA RVCE Page 1 of 61

Chapter 1
PREAMBLE

1.1 Introduction

ABC finance company is a finance company which provides loans to its
customers. To improve its efficiency, they chalked out a plan to automate its entire
process. Based on the following specifications we were required to develop the
system for them.

The objective was to create a system, that calculates the maximum amount of
loan one can take depending on his income and wealth, and the EMI amount for
certain repayment period. And if the customer chooses to take the loan, then create a
new loan account. On certain time of every month generate report on the new loan
accounts. An automatic payment interface for user to pay EMI, and again, every
month calculate and adjust interests, generate report, and based on the status, generate
letter to certain customers. Overall the complete system was automated.

1.2 Project Description
Based on the functionality the system can be divided into 2 subsystems.
APPLICATIONS
PAYMENT
Figure 1.1 Overview of project

Applications
Whenever a customer comes to avail a loan, he/she is asked to give the
required details which include his/her Personal details and Rating details [DOB,
Salary/month, Assets Value (Rupee value of any vehicles, property he/she owns),].
Using the rating details we calculate an amount (the maximum amount of loan, which
the company can provide to the customer). If he/she is fine with that amount, we carry
on with further processing.

The customer is asked to give the loan details (Loan amount the customer is
planning to take, and also the repayment period). Based on the loan details we
calculate the EMI and convey it to the customer. The customer can make inquiry for
the EMI any number of times (i.e., for any permutations and combinations of Loan
amount and repayment period). Once the customer decides upon the amount he is
planning to take and the repayment period, hes provided with an automatically
generated customer number which is a must for any further transaction with the
company.

Payments
When the customer comes to make his loan repayments, payments department
attends him/her. The customer is allowed to pay his EMI through Cash or a cheque.
We have some pre-defined rules according to which surcharges are levied on
customers who do not make the payments regularly. If at any point of time, the due
amount to date (that should have been paid by now, but not paid), is greater than 4
times his EMI then, his tenure is cancelled and he will be subject to jurisdiction. A
warning letter will be sent to the customer when the total amount due becomes greater
than 3 times the EMI.

1.3 Literature Survey

Literature Survey on Mainframes
Mainframe is a very large and expensive computer capable of supporting
several thousands of users simultaneously. In the hierarchy that starts with a simple
microprocessor (in watches, for example) at the bottom and moves to supercomputers

at the top, mainframes are just below supercomputers. In some ways, mainframes are
more powerful than supercomputers because they support more simultaneous
programs. But supercomputers can execute a single program faster than a mainframe.

"A mainframe is a continually evolving general purpose computing platform
incorporating in it architectural definition the essential functionality required by its
target applications." - Anonymous.

Bulk data processing such as census, industry and consumer statistics,
enterprise resource planning, and transaction processing, big companies like Banks,
Insurance Companies, Travel and Retail Sector, Telecom Companies employ
Mainframes for processing their business data. Today, thousands of people around the
globe book flights do Electronic Money Transfers; swipe their credit-cards for
purchases. These transactions are processed in a snap by a Mainframe computer.

Literature Survey on History of mainframes
From 1952 into the late 1960s, IBM manufactured and marketed several large
computer models, known as the IBM 700/7000 series. The first-generation 700s were
based on vacuum tubes, while the later, second-generation 7000s used transistors.
These machines established IBM's dominance in electronic data processing. IBM had
two model categories: one (701, 704, 709, 7090, 7040) for engineering and scientific
use, and one (702, 705, 7080, 7070, 7010) for commercial or data processing use. The
two categories ($2M USD in the mid-1950s), scientific and commercial, generally
used common peripherals but had completely different instruction sets, and there were
incompatibilities even within each category.

All that changed with the announcement of the System/360 (S/360) in April,
1964. The System/360 was a single series of compatible models for both commercial
and scientific use. The number "360" suggested a "360 degree," or "all-around"
computer system. System/360 incorporated features which had previously been
present on only either the commercial line (such as decimal arithmetic and byte
addressing) or the technical line (such as floating point arithmetic). However, models
were upward compatible and most were also downward compatible. The System/360
later evolved into the System/370, the System/390, and the 64-bit zSeries, System z,

and zEnterprise machines. System/370 introduced virtual memory capabilities in all
models other than the very first System/370 models.

Today, the mainframes hold almost 70% of the entire data stored in the planet.
It can support over 25,000 users. 95% of Fortune 500 companies use Mainframe.

Literature Survey on Operating System of mainframes
IBM initially sold its computers without any software, expecting customers to
write their own; programs were manually initiated, one at a time. Later, IBM provided
compilers for the newly developed higher-level programming languages Fortran and
COBOL. The first operating systems for IBM computers were written by IBM
customers who did not wish to have their very expensive machines ($2M USD in the
mid-1950s) sitting idle while operators set up jobs manually. These first operating
systems were essentially scheduled work queues. Later, IBM created Share Operating
System and provided it to customers under the name IBSYS. As software became
more complex and important, the cost of supporting it on so many different designs
became burdensome, and this was one of the factors which led IBM to develop
System/360 and its operating systems.

Today, there are five common versions of operating systems, which is called MVS
(Multiple Virtual Storage).

MVS/370 :24 bit address space and limits user address space to 16 MB.
MVS/XA : 31 bit address space and limits user address space to 2 GB.
MVS/ESA :Lets each job access to more than one 2 GB address space.
OS/390 : A rebranded version of MVS with added UNIX System Service.
Z/OS: Uses a 64 bit addressing.(Zero Downtime OS)

Literature Survey on COBOL
COBOL is one of the oldest programming languages, created by a committee
of researchers from private industry, universities, and government during the second
half of 1959. Its name is an acronym for Common Business-Oriented Language,
defining its primary domain in business, finance, and administrative systems for
companies and governments.

COBOL programs are in use globally in governmental and military agencies
and in commercial enterprises, and are running on operating systems such as IBM's
z/OS and z/VSE, the POSIX families (Unix/Linux etc.), and Microsoft's Windows as
well as ICL's VME operating system and Unisys' OS 2200. In 1997, the Gartner
Group reported that 80% of the world's business ran on COBOL with over 200 billion
lines of code in existence and with an estimated 5 billion lines of new code annually.

The American National Standards Institute (ANSI) produced several revisions of the
COBOL standard, including:
COBOL-68
COBOL-74
COBOL-85
COBOL 2002
IN Mainframe, COBOL, PL/I and C are the prime programming languages, where
COBOL is used at 90% of time. All languages are embeddedto COBOL.

Literature Survey on JCL
Job Control Language (JCL) is a scripting language used on IBM mainframe
operating systems to instruct the system on how to run a batch job or start a
subsystem.

In both JCLs the unit of work is the job. A job consists of one or several steps, each of
which is a request to run one specific program. To Compile, Run, Create, Delete, Edit
a file or anything system related, JCL is used to access the resource.

Literature Survey on CICS
Customer Information Control System (CICS) is a transaction server that runs
primarily on IBM mainframe systems under z/OS and z/VSE.

CICS is middleware designed to support rapid, high-volume online transaction
processing. A CICS transaction is a unit of processing initiated by a single request
that may affect one or more objects. This processing is usually interactive (screen-

oriented), but background transactions are possible. Even a front end written by Java
or dot net can be connected to s Mainframe through CICS.

CICS provides services that extend or replace the functions of the operating system
and are more efficient than the generalized services in the operating system

Literature Survey on DB2
Short for Database 2, a family of relational database products offered by IBM.
DB2 provides an open database environment that runs on a wide variety of computing
platforms. A DB2 database can grow from a small single-user application to a large
multi-user system. Using SQL, users can obtain data simultaneously from DB2 and
other databases. DB2 includes a range of application development and management
tools.

DB2 is unparalleled for using very large database, and thats why DB2 is widely
used in mainframe, mainframe databases often contain tables with millions of records.
With the flexibility of SQL, DB2 is used almost everywhere mainframe is used.

1.4 Features of the Project:

The main features of the project are
End to End solution for ABC finance company. It handles the loan
processing from beginning to end of the customer.
It provides user friendly interface for customers of the finance company.
Helps to build an interactive Loan processing system.
Provides many criteria for evaluating customers loan.
Helps to calculate different operations in loan availing process.

1.5 Platform used in Implementing the Project:
IBM Mainframe Z/OS system with basic configuration.
Basic desktop to access remote Mainframe system
Operation System : MVS(Multiple Virtual Storage)
Business Logic : COBOL programs

Database : IBM DB2
Server : IBM Mainframe Z/OS system
System Environment : Mainframe.

1.6 Timeline for the Project:

Analysis of core
modules and
Database Design

Designing or
Architecture

Development of
Core Modules(
Coding)

Gradual
implementation
Practices

Testing,
Maintenance and
Documentation

February
2013
March 2013 April 2013 May 2013 June 2013

Fig 1.2: Time line for the project.

Timeline of the project helps to analyze the time taken by the different modules of the
project. Requirement, Design, Coding and Testing are the different phases of this
project.

In the first month we started with requirement and design phase. First fifteen days we
worked with some mainframe examples. Next fifteen days we started planning our
project. In the second month we started coding and thus we started testing. In this
project we got the requirements by studying the previous research works. More time
spent on learning the mainframe platform.

In the third month, we were done with the requirement phase concentrated on coding
and design phase. In the 4
th
month more time spent on coding. In the 5
th
more time
spent on coding and testing.


1.7 Dissertation:

Chapter 2 starts with Software Requirement Specification. Here we discuss on
purpose of the project and scope of the project. Then we specify different definitions,
acronyms and abbreviations used in the project. Later we discussed on overview of
the project. In this scope we discussed on architecture of the project and the key
components of the system and the project.

Chapter 3 is about Design Specification. This specifies actual working of the
project. The project follows Procedure Oriented Approach. Here we specify the E-R
diagram of the project. We explain the design part with the help of Data flow
diagrams and all DFD diagrams.

In later part we specify main modules of the project. In Detailed Design we
specify logical part of the project. This will includes algorithm and mathematical
computation results.

Chapter 4 is about Testing and Results. Testing deals with different test cases
and testing methods used in the project. In results we specify screenshots of different
results of the project with explanations.

1.8 References:
www.mainframegurukul.com
IBM Mainframe Handbook, Alexis Leon.
DB2 Developers Guide, Third Edition, Craig S. Mullins
CICS Handbook, Kageyama
COBOL PROGRAMMING, M K Roy


Chapter 2

Software Requirements Specification

2.1 Introduction

The scope of this project is limited to a banking domain with mainframe
access. Though several thousand customers as well as operators can work with this
application simultaneously, without mainframe access, its not possible. So, the
application can only be run within the ABC Finance company only, even though the
branches scattered within the globe.

2.1.1 Purpose

The main purpose of the project is to develop a processing system for the ABC
Finance Company on the IBM mainframes. The project aims to provide all solutions
to the requirement of the customer availing a loan in the finance company.

2.1.2 Scope

The project is developed mainly for the financial sector where the transactions
take place in a large numbers. In order to handle the large amount of transactions we
need an efficient system to be used for the development. The IBM mainframe systems
can handle millions of transactions per second and hence we develop our processing
system for the ABC Finance Company on the main frame system.

2.1.3 Definitions, Acronyms and Abbreviations

JCL: Job Control Language.
3270: Terminal used to connect to Mainframe
VSAM: Virtual Storage access Method
MVS: Multiple Virtual Storage.

CICS: Customer Information Control System.

2.1.4 References

o www.mainframegurukul.com
o IBM Mainframe Handbook, Alexis Leon.
o DB2 Developers Guide, Third Edition, Craig S. Mullins
o CICS Handbook, Kageyama
o COBOL PROGRAMMING, M K Roy

2.1.5 Overview

This project is concerned with the development of a software for the finance
company which comprises of overall transactions between the customer and the
company. The finance company project can be broadly divided into two categories
namely. They are:
1. Application processing.
2. Payments processing.

The application processing deals with the customer applying for the loan in the
finance company. The company gathers the required information from the customer
for the processing of the loan. The gathered information is processed for the
calculations for the maximum loan amount that the customer is eligible. The
payments processing deals with the payment of the EMI by the customer to the
finance company. The customer has to pay the EMI at specified date to avoid
different circumstances which leads to increase in the loan amount to be payed to the
finance company. The Customer Information Control System(CICS) will be used as
the front end to the project. The IBM DB2 will be used as the backend for the data
storage. The Finance company project will be developed on the IBM Mainframe
system


2.2 General Description

2.2.1 Product Perspective

The product which we are going to develop serves all the needs for the loan
processing in the finance company. The CICS screen will be developed for the
customer to enter the required information for the loan processing. The CICS acts as
an interface between the User and the Mainframe system. The mainframe system
refers to IBM Z/OS system which is the platform for the development of the finance
company project. The COBOL is the programming language used on mainframe
system. The JCL (Job Control Language) acts as an intermediate between COBOL
and the Mainframe system.

2.2.2 Product Functions

o This product functions involve :
o Rating Routine
o Date Routine
o Applications Processing functions
o Payments Processing functions
o Reports generation functions
o EMI functions
o Batch processing
o Online Processing

2.2.3 User Characteristics

The application users must know the functioning of the software for effective
usage.
The user in this project is the finance company customers.
The customer's purpose is to avail a loan which he needs based on his inputs given
to the finance company

2.2.4 General Constraints

The developer needs complete prior knowledge about the finance sector to
develop a good software. The customer's requirements tend to change dynamically
and the developer should be able to handle such requirements. Reusability of the
codes which is one of the major pros is possible only if there are no interface
changes/modifications within the solution. Developing the plans to execute workflows
can be sometimes consuming.

2.2.5 Assumptions and Dependencies

The system does not expect its users to have technical expertise of any sort, its not
meant to be used by layman either. The users are assumed to be aware of the usage
of the software which is one of the major assumptions.

The system design is based on the current version of the requirements and any
changes to the latter impacts the solution.

2.3 Functional Requirements

2.3.1 Introduction

Functional Requirements specify the key functions to be performed by the proposed
system. These describe the functionality or services that the system is expected to
provide.

2.3.2 Input

The customer information serves as the input for the finance company software.
The monthly salary, asset values and other major information serve as input for the
software.


2.3.3 Processing

The CICS accepts the input and submits to the COBOL program for execution.
The Cobol program processes the input using rating routine and other routines.
The payments updation is done through the batch processing.

2.3.4 Output

The maximum loan amount is given as the output on the cics screen.
The EMI is calculated and given as the output on the cics screen.
The payments transaction are generated as a report which forms the output for the
batch processing.

2.4 External Interface Requirement

2.4.1 User Interfaces

This project uses IBM mainframe Z/OS system for the development of the finance
company software. The different technologies used by the mainframe system are:

JCL for submitting jobs on mainframe system.
MVS is the operating system on mainframes.
VSAM is used as a source of data storage.
Defining/Declaring variables.
Modification/Execution of codes.

2.4.2 Hardware Requirement

IBM Mainframe Z/OS system with basic configuration.
Basic desktop to access remote Mainframe system.


2.4.3 Software Requirement

Operation System : MVS(Multiple Virtual Storage)
Business Logic : COBOL programs
Database : IBM DB2
Server : IBM Mainframe Z/OS system
Environment : Mainframe Environment.

2.5 Performance Requirements

The software should be compatible enough to handle the unexpected conditions. The
software developed should give valid result for all valid inputs.
As it is the financial sector the amount of dataflow in and out of the system and data
security is the major issue.

2.6 Design Constraint

2.6.1 Standard Compliance

The results should be accurate and in the proper format.
Design of the system takes measures for invalid input to ensure reliability.

2.6.2 Hardware Limitations

Mainframe system can be afforded only by big organizations and it is very costly.
To install and run a mainframe system we need 1 month.


Chapter 3
Design Document Specification

3.1 Architectural Design
An Architecture design defines the components or building blocks that form
the entire system. It is a formal design of a system, organized in a way that supports
reasoning about the structural properties of the system. The design of the ABC
Finance company gives the functionalities of the entire system in a descriptive
manner.

Problem Specification

ABC finance company is a finance company which provides loans to its
customers. To improve its efficiency, they chalked out a plan to automate its entire
process. Whenever a customer comes to avail a loan, he/she is asked to give the
required details which include his/her Personal details and Rating details [DOB,
Salary/month, Assets Value (Rupee value of any vehicle, property he/she owns).
Using the rating details we calculate an amount (the maximum amount of loan, which
the company can provide to the customer). If he/she is fine with that amount, we carry
on with further processing.

When the customer comes to make his loan repayments, Payment department
attends him/her. The customer is allowed to pay his EMI through Cash or Cheque. We
have some pre-defined rules according to which surcharges are levied on customers
who do not make the payments regularly. If at any point of time, the due amount to
date (that should have been paid by now, but not paid), is greater than 4 times his EMI
then, his loan service is cancelled and he will be subject to jurisdiction. A warning
letter will be sent to the customer when the total amount due becomes greater than 3
times the EMI. The development of this new system contains the following activities,
which try to develop the web-application entire process keeping in the view of
database integration approach. The purpose of developing finance system is to
provide an easy access to the customers to avail loans with more security and

flexibility. This system provides the customer to save lot of his time. This system also
gives loans to the customers after verifying each and every document so that fake
customers cannot avail loans.

E-R diagram

An Entity-Relationship Model in software engineering is an abstract and
conceptual representation of data. Entity-relationship modeling is a relational schema
database modeling method, used to produce a type of conceptual schema or semantic
data model of a system, often a relational database, and its requirements in a top-down
fashion. Diagrams created using this process are called Entity-Relationship diagrams.

In this application the entities are Customer, Loan, payments, and applications.
The attributes for each entity are shown in the figure below. The relationship between
customer and loan is applies loan. The payments and customer entities interact
through the relationship makes payments. The relationship generate exists
between customer number and loan entities. The cardinality ratio for each relationship
is specified below.

Entity: An entity may be defined as a thing which is recognized as being capable of an
independent existence and which can be uniquely identified.

Attribute: Attributes are the characteristics of the entities. The customer entity is
characterized by cust_num, first_name, last_name, DOB, pincode, salary and asset
value. These characteristics become the attributes of customer.

Relationship: A relationship captures how two or more entities are related to one
another. Relationships can be thought of as verbs, linking two or more nouns. The
cardinality ratio for a binary relationship specifies the number of relationship
instances that an entity can participate in. The possible cardinality ratios for binary
relationship types are 1:1, 1:N, N:1 and M:N.


Primary key: An entity is uniquely identified by a key called primary key. The
customer entity is uniquely identified by its cust_num attribute. The primary key
attribute is denoted by underlining the attribute.

Foreign key: A foreign key is a table column whose values exclusively represent a
relationship between tables. A foreign key is a column whose values are derived from
the primary key of some other table.

E-R DIAGRAM

Figure 3.1 E-R Diagram of Application module

The Entity Relationship Diagram in the above figure explains the attributes of the
entities Customer Number and LOAN. The attributes of the Customer Number entity
are cust_no and cust_no_timestamp. The attributes of the LOAN entity are cust_num,
loan_amt, loan_dt, emi_amt, repay_period and loan_stat.


Figure 3.2 E-R Diagram of Payments module

The Entity Relationship Diagram in the above figure explains the attributes of the
entities Customer and Payment. The attributes of the Customer entity are cust_num,
first_name, last_name, dob, pin, src_code, addr_line. The attributes of the Payment
entity are cust_no, pay_st_dt, pay_end_dt, pay_dt, loan_amt, paymode, curr_pay_amt,
curr_due_amt, emi_amt and pymt_stat.


Data Flow Diagram

A data flow diagram (DFD) is a graphical representation of the "flow" of data
through an information system, modeling its process aspects. A DFD shows what
kinds of data will be input to and output from the system, where the data will come
from and go to, and where the data will be stored. It does not show information about
the timing of processes, or information about whether processes will operate in
sequence or in parallel.

Zero Level DFD

Figure 3.3 Level-0 DFD

This Context level data flow diagram represents the overall description of the system
specifying the external entities that interact with the system. Here the entire system is
shown as a single process, and gives no clue about the internal organization, which is
explained in next level.


Level 1 DFD

User Input

User Input

User Input

Invalid Input

Invalid
Input

Invalid
Input

Latest Cu-
stomer No

Check
DOB

Result

Calculate Max Loan
Amount

Result

Calculate
Age

Result

Calculate
EMI

EMI

Latest
Cust No
Update Cust
No
Insert
New
Loan
Record

Latest Cu-
stomer No

Invalid
Input

Valid
Input

Output

Latest Cu-
stomer No

1.0
Personal
and Rating
Details
1.3
Loan
Details
1.2
Rating
Routine
1.1
Date
Routine

User

CUST_NUM_GE
NR
1.4
Confirm
Loan
Details

APP_MSTR

Level 1 Data flow diagram shows the loan availing process and the data flow
between them. It shows all the major high-level processes of the system and the
interrelation between them. The major processes involved here are payment
processing of the customer and application processing.

LEVEL-2 DFD


Level 2 of the DFD shows the detailed view of the processing steps during availing
loan. It contains modules as max loan calculation, EMI calculation and customer
number generation. It depicts the functionalities of these modules.


Structure charts

A structure chart is a top-down modular design tool, constructed of squares
representing the different modules in the system, and lines that connect them. The
lines represent the connection and or ownership between activities and sub activities
as they are used in organization charts.

Figure 3.6 Structure chart

Data definitions/Dictionary

APPLICATIONS MASTER TABLE LAYOUT

LN FIELD NAME PIC VALUE REMARKS
01 APPLN-RECORD. (Application layout)
05 CUSTOMER-
NUMBER
X(10) Primary Key
10 NAME.
15 FIRST-NAME

X(20)

15 LAST-NAME

X(20)
10 ADDRESS.
15 ADDR-LINE-1

X(30)
15 ADDR-LINE-2

X(30)
10 PIN-CODE 9(06)
10 SOURCE-CD X(02)
10 DOB

9(08)
10 FILLER
REDEFINES DOB

15 DOB-CCYY

9(04)
15 DOB-MM

9(02)
15 DOB-DD

9(02)
10 ACT-LOAN-AMT

9(07)
10 ACT-REPAY-
PERIOD
9(03)
10 EMI-AMOUNT

9(07) COMP-3
10 LOAN-DATE

9(08)
10 FILLER
REDEFINES
LOAN-DATE


15 LOAN-CCYY

9(04)
15 LOAN-MM

9(02)
15 LOAN-DD

9(02)
Table 3.1 Application master table

Description: The Application master table stores details such as cust_num, name,
address, pincode, salary, DOB and asset value. The primary key is cust_num.

PAYMENTS MASTER TABLE LAYOUT

LN FIELD NAME PIC VALUE REMARKS
01 PYMNT-RECORD Payments Layout
10 CUSTOMER-
NUMBER
X(10) Primary Key
05 TERM-START-DT 9(08) COMP-3
05 TERM-END-DT 9(08)
05 FILLER
REDEFINES
TERM-END-DT

10 TERM-END-CCYY 9(04)
10 TERM-END-MM 9(02)
10 TERM-END-DD 9(02)
05 LOAN-AMOUNT 9(07)
05 TOTAL-AMOUNT 9(07)
05 AMOUNT-REPAID 9(07)
05 EMI-AMOUNT

9(07)
05 CURRENT-DUE-
AMT
S9(07)
05 CURR-PAY- 9(07)

AMOUNT
05 PAY-DATE 9(08)
05 FILLER
REDEFINES PAY-
DATE

10 PAY-CCYY 9(04)
10 PAY-MM 9(02)
10 PAY-DD 9(02)
05 PAY-MODE X(02)
05 CHEQUE-
DETAILS.

10 CHEQUE-NBR X(07)
10 CHEQUE-DATE 9(08)
10 BANK-NAME X(20)
Table 3.2 Payment master Table
Description: The Payments master table stores details such as cust_num, term
_start_dt, term_end_dt, due_amount, total_amount.payment_mode, bank
_name and cheque_details. The primary key is cust_num

Module specification
o Applications Processing
Max loan amount calculation.
EMI calculation.
o Payments Processing
Future Date calculation

Module 1: Applications processing

o Module Name : Max loan amount calculation.
o Input: DOB, salary and asset value.
o Output : Max loan amount.
o Purpose : To calculate max loan amount of the customer.


o Module Name : EMI calculation
o Input : Loan amount and Repayment Period.
o Output : EMI
o Purpose : To calculate the EMI for the customer.

Module 2 : Payments Processing

o Module Name : Future date calculation.
o Input : DOB and Repayment Period.
o Output : Future Date
o Purpose : To get the future date for loan payment.

Assumptions

The details given by the customer is valid.
The loan amount doesnt exceed max loan amount
The due date is valid as per customers information.

3.2 Detailed Design

Application Online
Whenever a customer comes to take a loan we enter into this program by typing in the
transaction ID for APPLICATIONS.
In this program there are 3 functions.

Function 1: To calculate the maximum amount of loan that the company can
give to the customer (This is based on his age, salary, etc).
Function 2: To calculate the EMI based on the loan amount and the
repayment period.
Function 3: To generate a customer number for customers those availing the
loan.


The program functionality should reach Function 2 if and only if Function 1 is
complete. And similarly, the functionality should reach Function 3 if and only if
Function 2 is complete.

Function 1:

When the screen is thrown for the first time, the user is asked to enter the personal
details and rating details of the customer. Once the customer enters the details and
presses enter, then the following validations should take place.

(Do the validations in the order mentioned. If at any point any validation fails, the
logic developed should be such that the program does not do any further validations.
It should throw the map with appropriate error message and cursor position.)

PERSONAL DETAILS:
NAME
FIRST NAME VALIDATION:
Valid values are alphabet
LAST NAME VALIDATION:
Valid values are alphabet

ADDRESS
LINE1:
Valid values are alphanumeric characters
LINE2:
Valid values are spaces, low values and alphanumeric characters.

PIN NUMBER:
This should be numeric and greater than 100000.

SOURCE CODE:
TV Television
RD Radio
IN Internet

FD Friend
NP Newspaper
ZZ Others

Rating Details(Function 2 & 3)

DOB:
Should be a valid past date
Age should be >=20 yrs and <=50yrs.
Call date routine to calculate the age. If difference in months > 6, add 1 to
difference in years else age will be = difference in years.

SALARY/MON:
This cannot be blank.
Should be numeric and greater than equal to 5000

ASSETS VALUE:
Valid values are spaces, low-values, zeros or any positive numeric value.

CONFIRM RATING DTS:
This should be Y. This is the last check, which confirms that all the details
provided above are correct.

Once all these validations are passed, this program LINKs to the rating routine. Input
to this routine will be DOB, Salary/Mon, Assets value and function that hold value
R. Output will be an amount, which is the maximum loan amount that the company
can give to the customer and the return code. If return code is zero then the amount
value is moved to the map field MAX LOAN AMOUNT. If not the error message is
moved to the message field of the map.

Until this point all other fields except those mentioned above will be protected. But
once this amount is calculated (& return code is zero), then the above-mentioned
fields are made protected and the rest of the fields (LOAN AMOUNT, REPAYMENT

PERIOD & CONFIRM LOAN DETAILS) are made unprotected and the map is
thrown, prompting the user to enter loan details.

Function 2:
LOAN DETAILS
LOAN AMOUNT:
Valid values are numeric values greater than equal to 10000.
This amount cannot be greater than the Max Loan Amount calculated.

REPAYMENT PERIOD:
Valid values are numeric values between and including 6 240 months. This
is the period in which the customer is planning to repay the loan amount.

If the values in both the above fields are valid, then the program LINKs to
rating routine. The input to this routine will be Loan Amount, Repayment
period and function that hold value E. The outputs of this program are an
amounts and a return code. The amount is the EMI for the specified loan
amount and repayment period. If the return code is zero, then the amount
values are moved into the map fields EMI AMOUNT. If not error message is
moved into the message field of map.

Function 3:
Unprotect The CONFIRM LOAN DETAILS field and throw the map again to the
screen. Receive the map with user response and check the CONFIRM LOAN
DETAILS field.
CONFIRM LOAN DETAILS:

Valid values are Y, N or blank
If this field is Y:
Generate a customer number for the customer automatically and move it to map
variable. And also write a record into the APPLICATION MASTER FILE for that
customer number with all the relevant details. Also write a record for this customer
number into Payments Master file with all relevant details.

Protect all the fields (Loan Amount, repayment Period and Confirm Loan Details) and
throw the map.

If this field is N or blank:
Only Unprotect the LOAN DETAILS fields and throw the map. User can re-enter
either the LOAN AMOUNT or REPAYMENT PERIOD or both and recalculate the
EMI as many times as he want.

At any point if the user presses PF3/clear the control should go back to CICS. If any
key other than ENTER, CLEAR, PF3 is pressed it should be treated as an invalid key

Automatic generation of Customer Number:

The first record of the APPLICATION MASTER FILE is the control record. The
control record holds the value of the last generated customer number. Read this file
and increment the value present in the file by 1. Assign this value to the customer as
the customer number. Also rewrite the control record with the incremented value (last
generated customer number).


1 ABC FINANCE COMPANY DATE : MM / DD /
YY
2 APPLICATIONS DEPARTMENT TIME : HH : MM
AM
3
4 CUSTOMER NUMBER : 9999999999
5 *************************************************************
************************************************************
6 ************************************* P E R S O N A L D E T A I
L S ***********************************************
7 FIRST NAME: XXXXXXXXXXXXXXXXXXXX LAST NAME:
XXXXXXXXXXXXXXXXXXXX
8 ADDRESS L1: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
9 ADDRESS L2: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
10 PIN: 999999 SOURCE CODE: XX
11 *************************************************************
************************************************************
12 *************************************** R A T I N G D E T A I
L S *************************************************
13 DOB : MM - DD - CCYY
14 SALARY/MON: RS. 9999999 ASSETS VALUE: RS.
999999999999
15
16 CONFIRM RATING DTS: X MAX LOAN AMOUNT: RS.
9999999999
17 *************************************************************
************************************************************
18 *************************************** L O A N D E T A I L
S **************************************************
19 LOAN AMOUNT: RS. 9999999 REPAYMENT PERIOD: 999
MONTHS
20 EMI AMOUNT: RS. 9999999
21 CONFIRM LOAN DETAILS: X
22 *************************************************************
************************************************************
23
24 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXX


RATING ROUTINE

FUNCTIONS:
R - To calculate the maximum amount of loan that the company can provide.
E - To calculate the EMI.

Input to the program:
Salary/month (R/E).
AGE(R)
Assets Value (R).
Loan Amount (E).
Repayment Period (E).
Function (R/E).

Output from the program: (R/E)
Calculated Amount
Return Code

When the control comes to the program, check for the function. If it is
anything other than R or E then return to the calling program with an
appropriate return code.

If the function = R:
Move the values present in Salary/month, DOB, Assets Value and Loan
Amount due to temporary variables and do the following:

Calculate the maximum loan amount using the following formula:

Max Loan Amt = [(5 * Salary/month)*(55-Age)] + [0.3 * Assets Value].
Pass the control back to the calling program with RETURN CODE 000.

If the function = E:
Move the values present in Salary/month, Loan Amount and Repayment
period to temporary values and do the following:

Calculate the EMI using the following formula: (Round off the EMI amount)

X = Loan Amount + {Loan Amount * n/12 * r}
EMI = X/n.

Where,
Present Value = Loan Amount
r Rate of interest per annum/100.
n Repayment period in months

Rate of interest:

For loan Amount in the range Rate of interest per year
10000 2Lakhs 13.5%
2Lakhs 5Lakhs 12%
5Lakhs 10Lakhs 11%
10Lakhs 20Lakhs 10%
20Lakhs and above 09.5%

If the EMI calculated is greater than 2/3rds the salary/month pass the control back to
the calling program with appropriate RETURN CODE.

If EMI calculated is less than equal to 2/3rds the Salary/month, pass the control back
to the calling program with RETURN CODE 0 and error message spaces.

COPYBOOK LAYOUT

RATING ROUTINE COPYBOOK:
(PREFIX: RTRTN-)

INPUT-VARIBLES
MONTHLY-SALARY 9(07)
DOB 9(08)
FILLER REDEFINES DOB
DOB-CCYY 9(04)
DOB-MM 9(02)
DOB-DD 9(02)
ASSETS-VALUE 9(09)
LOAN-DUE-AMT 9(09)
LOAN-AMOUNT 9(07)
REPAY-PERIOD 9(03)
FUNCTION X(01)
88 VALID-FUNCTION VALUE R, E

OUTPUT-VARIABLES
CALC-AMOUNT 9(07)
RETURN-CODE X(03)

DATE ROUTINE
(Valid Date range: 1901 2300)
FUNCTIONS:
VP Validate a date (Date should be valid and less than equal to current date).
FD Calculate a future date (For a given date and number of months).
DF Difference between 2 dates (In months and Years).

Input to the program:
In-Date1
In-Date2 (this will be passed only when we need to get the difference between
the dates)
Months

Function

Output from the program:
Out-Date
Diff-YYMM
Return code

Before sending the control back to the calling program, if there is any error,
move appropriate return code else, move 000 to RETURN CODE.

Logic to be followed for getting the future date:
Based on the number of months, increment the year part and months part
appropriately.

Example:
1 month future date from 31st March will be 30th April
1 month future date from 30th March will be 30th April
1 month future date from 30th April will be 30th May.
1 month future date from 28th / 29th Feb will be 28/29th March respectively.

Logic to be followed for getting the difference between 2 dates:
Get the difference between the dates in months and then calculate the no of
years and months respectively.

COPYBOOK LAYOUT

DATE ROUTINE COPYBOOK:
(PREFIX: DTRTN-)

INPUT-VARIABLES
IN-DATE1 9(08)
FILLER REDEFINES IN-DATE1
IN-CCYY1 9(04)
IN-MM1 9(02)
IN-DD1 9(02)
IN-DATE2 9(08)
FILLER REDEFINES IN-DATE2
IN-CCYY2 9(04)
IN-MM2 9(02)
IN-DD2 9(02)
MONTHS-FOR-FUTURE-DT 9(03)
FUNCTION X(02)
88 VALID-FUNCTION VALUE VP FD DF
OUTPUT-VARIABLES
OUT-DATE 9(08)
FILLER REDEFINES OUT-DATE
OUT-CCYY 9(04)

OUT-MM 9(02)
OUT-DD 9(02)
DIFF-YYMM 9(04)
FILLER REDEFINES DIFF-YYMM
DIFF-YY 9(02)
DIFF-MM 9(02)
RETURN-CODE X(03)

Table 3.3 Error Codes

Whenever a customer comes to take a loan we enter into this program by typing in the
transaction ID for APPLICATIONS. When the screen is thrown for the first time, the
user is asked to enter the personal details and rating details of the customer. Once the
customer enters the details and presses enter, then necessary validations should take
place. Once all these validations are passed, this program LINKs to the rating routine.
Input to this routine will be DOB, Salary/Mon, Assets value and function that hold
001
PLEASE ENTER PERSONAL AND RATING DETAILS & PRESS
ENTER
002 FIRST NAME CANNOT BE BLANK OR NUMERIC
003 LAST NAME CANNOT BE BLANK OR NUMERIC
004 INVALID ADDRESS PLEASE CHECK
005 INVALID PIN PLEASE CHECK
006 INVALID SOURCE CODE PLEASE CHECK
007 INVALID DOB PLEASE CHECK
008 INVALID DAY PLEASE CHECK
009 INVALID MONTH PLEASE CHECK
010 INVALID YEAR PLEASE CHECK
011 INVALID AMOUNT PLEASE CHECK
012 CONFIRM RATING DETAILS SHOULD BE Y
013 PLEASE ENTER LOAN DETAILS AND PRESS ENTER
014
ENTER Y TO CONFIRM LOAN OR ENTER NEW LOAN DETAILS
TO RECALCULATE EMI
015 CONFIRM LOAN DETAILS SHOULD BE Y OR N OR
016
LOAN AMOUNT CANNOT BE GREATER THAN MAX LOAN
AMOUNT
017 REPAYMENT PERIOD SHOULD BE BETWEEN/INCLUDING 6 - 240
018 DETAILS UPDATED.THANK YOU. HAVE A NICE DAY!
019 INVALID KEY PRESSED. ENTER/PF3/CLEAR VALID KEYS
020 GOOD BYEHAVE A NICE DAY!
021 AGE CANNOT BE MORE THAN 50 YRS OR LESS THAN 18 YEARS
022 SORRY, LOAN CANNOT BE ISSUED
025 SEPERATOR SHUOLD BE -
027 CRITICAL ERROR. INVALID FUNCTION PLEASE CHECK

value R. Output will be an amount, which is the maximum loan amount that the
company can give to the customer and the return code.
Design Decision

In the development of the above application, the procedure oriented approach has
been used. Procedure oriented approach emphasizes on organizing the
functionality into smaller procedures that change our data. In this approach
procedures or functions do not have an intrinsic relationship with the data they
operate on instead can directly access any shared data.

Logic Design

The PDL below is described in terms of a pseudo code. This pseudo code
describes the design plan that has been taken for the implementation of the actual
application. This code gives a detailed description of the proposed plan of coding
the final product.

Max loan amount calculation

Begin :
Enter the inputs on the cics screen
Validate input
If invalid input
Error message
Else
Calculate max loan amount
End-if
End :

EMI calculation

Begin :

Enter the inputs on the cics screen
Validate input
If invalid input
Error message
Else
Call rating routine for EMI calculation
If valid values
Returns the EMI to main program
Else
Error message
End-if
End-if
End


Chapter 4

TESTING AND RESULTS

4.1 Testing:
Automation of Loan processing system in ABC Finance company deals with
functioning of finance company in loan processing to the customers.
The application has been created on Mainframe in z/OS. It will run smoothly under
z/OS and MVS 3.8. To run in Operating system below MVS 3.8 needs some tweaking
of data, because those operating systems support COBOL 74 standard.

System Requirement
Operating System
z/OS
CICS Region
Map, PPT, PCT, PLAN entry should be made prior running the
program
DB2
Tables should be created with respective qualifier and the first entry of
CUST_NUM_GENR should be inserted prior running the program

Functional Testing
The objective of this test is to ensure that each element of the application meets the
functional requirements of the project as outlined in the Project Specification.
This stage will also include Validation Testing - which is intensive testing of the new
Front end fields and screens. CICS Standards; valid, invalid and limit data input;
screen & field look and appearance, and overall consistency with the rest of the
application.
The third stage includes Specific Functional testing - these are low-level tests which
aim to test the individual processes and data flows.
All the stages of the functional testing are done and the system passed it successfully.


Integration Testing
This test proves that all areas of the system interface with each other correctly and
that there are no gaps in the data flow. Final Integration Test proves that system works
as integrated unit when all the fixes are complete.
The system has passed the integration testing successfully.

User Acceptance Testing
This test, which is planned and executed by the Business Representative(s), ensures
that the system operates in the manner expected, and any supporting material such as
procedures, forms etc. are accurate and suitable for the purpose intended. It is high
level testing, ensuring that there are no gaps in functionality.

Black Box Testing
Black box testing assumes the code to be a black box that responds to input stimuli.
The testing focuses on the output to various types of stimuli in the targeted
deployment environments. It focuses on Validation Tests, Boundary Conditions,
Forced Error Tests, Reproducibility Tests, Performance Tests, Globalization, and
Security-Related testing. The descriptions of test cases including test data are enlisted
below.

Test
Case
Id
Test Case Description Excepted Result Actual Result
Pass/F
ail
1 Functional
Press enter
without
entering any
details on the
screen.
It should display
PLEASE
ENTER
PERSONAL
AND RATING
DETAILS AND
PRESS
ENTER.
It displays
PLEASE
ENTER
PERSONAL
AND RATING
DETAILS
AND PRESS
ENTER.
Fail

2 Functional
If first name
is equal to
low values,
spaces,
numeric or
alpha-numeric
It should display
FIRST NAME
CAN NOT BE
BLANK OR
NUMERIC
It displays
FIRST
NAME CAN
NOT BE
BLANK OR
NUMERIC
Pass
3 Functional
If last name is
equal to
spaces,
numeric,
alpha-
numeric, low
values
It should display
LAST NAME
CAN NOT BE
BLANK OR
NUMERIC
It displays
LAST NAME
CAN NOT BE
BLANK OR
NUMERIC
Pass
4 Functional
If address
line1 is equal
to low values
or spaces
It should display
INVALID
ADDRESS
PLEASE
CHECK
It displays
INVALID
ADDRESS
PLEASE
CHECK
Pass
5 Functional
If pin code is
equal to low
values ,spaces
or less than
100000
It should display
INVALID PIN-
PLEASE
CHECK
It INVALID
PIN-PLEASE
CHECK
Fail
6 Functional
If source code
is not equal to
TV,RD,IN,F
D,NP,ZZ
It should display
INVALID
SOURCE
CODE-PLEASE
CHECK
It displays
INVALID
SOURCE
CODE-
PLEASE
CHECK
Pass
7 Functional
If DOB
Separator is
not -
It should display
SEPARATOR
SHOULD BE -

It displays
SEPARATO
R SHOULD
BE -
Pass

8 Functional
If date of birth
is given in
invalid format
It should display
INVALID
DOB-PLEASE
CHECK
It displays
INVALID
DOB-PLEASE
CHECK
Pass
9 Functional
If customers
age is not
between 18 to
50
It should display
AGE CAN
NOT BE MORE
THAN 50
YEARS OR
LESS THAN 18
YEARS
It displays
AGE CAN
NOT BE
MORE THAN
50 YEARS OR
LESS THAN
18 YEARS
Fail
10 Functional
If salary is
alpha numeric
or less than
5000
It should display
INVALID
AMOUNT-
PLEASE
CHECK
It displays
INVALID
AMOUNT-
PLEASE
CHECK
Pass
11 Functional
If
confirmation
flag is not
equal to y
It should display
CONFIRM
RATING
DETAILS
SHOULD BE
Y
It displays
CONFIRM
RATING
DETAILS
SHOULD BE
Y
Pass
12 Functional
If loan
amount is
equal to
spaces or
Blank or less
than 10000
It should display
INVALID
AMOUNT-
PLEASE
CHECK
It displays
INVALID
AMOUNT-
PLEASE
CHECK
Pass
13 Functional
If loan
amount is
greater than
Max Loan
Amount
It should display
LOAN
AMOUNT CAN
NOT BE
GREATER
It displays
LOAN
AMOUNT
CAN NOT BE
GREATER
Fail

THAN MAX
LOAN
AMOUNT
THAN MAX
LOAN
AMOUNT
14 Functional
If repay
period is not
between 6 and
240
It should display
REPAYMENT
PERIOD
SHOULD BE
BETWEEN/INC
LUDING 6-240
It displays
REPAYMENT
PERIOD
SHOULD BE
BETWEEN/IN
CLUDING 6-
240
Pass
15 Functional
If
confirmation
loan details is
not equal to
y n or
It should display
CONFIRM
LOAN
DETAILS
SHOULD BE
Y OR N OR

It displays
CONFIRM
LOAN
DETAILS
SHOULD BE
Y OR N
OR
Pass
16 Functional
If loan is
successfully
processed
It should
generate a new
customer no,
create a new
record for that
loan, insert into
APP_MSTR
table, display
new Customer
No with message
DETAILS
UPDATED
THANK YOU..
HAVE A NICE
DAY.
It generates a
new customer
no, creates a
new record for
that loan,
inserts into
APP_MSTR
table, displays
new Customer
No with
message
DETAILS
UPDATED
THANK
YOU.. HAVE
A NICE
Pass

Table 4.1 Test Cases

DAY.
17 Functional
If loan is not
successfully
processed
It should display
"SORRY LOAN
CANNOT BE
ISSUED".
It displays
SORRY
LOAN
CANNOT BE
ISSUED
Fail
18 Functional
If user presses
any key
except
ENTER,
CLEAR or
PF3
It should display
INVALID KEY
PRESSED.
ENTER/PF3/CL
EAR VALID
KEYS
It displays
INVALID
KEY
PRESSED.
ENTER/PF3/C
LEAR
VALID
KEYS
Pass
19 Functional
If user inputs
N or in
the loan
confirmation
field
Loan Amount
and Repayment
Period should be
unprotected.
Loan Amount
and
Repayment
Period gets
unprotected.
Pass

4.2 Results

Figure 4.1 Snap shot of Blank field

The Application screen is displayed where all necessary fields are to be filled and then
the confirm rating details value should be entered. If the confirm rating details is not
entered then we get an message which tells us to enter the value (Y/N) in the confirm
rating details field and then press enter.

Figure 4.2 snapshot of loan details

The above screen displays the error message when the loan details field is given
empty. The loan details field is a mandatory field and should have valid numeric
values.

Figure 4.3 Snap shot of Loan condition

The above screen shows the validation for the maximum loan amount that a customer
can avail from the finance company. The loan amount should not be less than 10000
and greater than maximum loan amount.


Figure 4.4 Snap shot of Repayment period condition

The above screen is displayed when the invalid repayment period value is entered in
the repayment period field. The repayment period should be between 6 months to 240
months.


Figure 4.5 Snap shot of updated details

The above screen is displayed when all values are successfully entered with proper
validation. This message specifies that the details have been updated into the
database.


Figure 4.6 Snap shot of Blank field

The above screen displays the validation for the name field where numeric values are
invalid. The message prompts to enter the valid values.


Figure 4.7 Snap shot of Loan details

The above screen displays the validation for loan amount field where it cannot be
blank. Valid numeric values should be entered.


Figure 4.8 Snap shot of options

The above screen displays the different options to calculate EMI, to enter new loan
details and to confirm the existing loan details


4.3 Conclusion and Future Enhancement

Conclusion

The purpose of our project is to provide an elegant system satisfying the requisites
and attaining goals. We have designed the project so that it can be easily understood
by any person irrespective of his knowledge in computer science. The Real Time
Gross Settlement is expected to function as per the requirements and we expect that it
will satisfy the needs of the user.

The Automation of Loan Generation and Servicing project for ABC Finance
Company was successfully designed and is tested for accuracy and quality. During
this project we have accomplished all the objectives and this project meets the needs
of the organization. The developed project will be used in granting loans, retrieving
and generating customer number for the concerned requests.

Future Enhancement

It is not possible to develop a system that makes all the requirements of the user. User
requirements keep changing as the system is being used. Some of the improvements
that can be done to this system are:
As the technology emerges, it is possible to upgrade the system and can be adaptable
to desired environment.
As this project is based on procedure-oriented design, any further changes can be
easily implemented.
Security can be improved using emerging technologies according to the requirements.
Adding recovery module to roll back the transaction


Annexure

Figure A.1 Blank field


Figure A.2 Loan details

Figure A.3 Loan condition


Figure A.4 Repayment period condition


Figure A.5 Updated details


Figure A.6 Blank field


Figure A.7 Loan details


Figure A.8 Options required


Bibliography
[1] Kageyama. "CICS complete Guide fifth edition.
[2] Vikas, IBM MAINFRAME HANDBOOK , second edition

[3] Tata McGraw Hill COBOL PROGRAMMING Roy Dastidar, second edition

[4] Sams DB2 Developers Guide Fourth Edition

[5]Web www.wikipedia.com/mainframes/cics/

[6] Web www.ibmmainframeforum.com

ABC Company Project Report

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ABC Company Project Report

Загружено:

Авторское право:

Доступные форматы

A Project Report on

ABC Finance Company

Вам также может понравиться