AUTOMATING THE BANKING PROCESS MC1804 Software Project Development Lab Anna University lab manual download - Computer Programming

Latest

C C++ Java Python Perl Programs Examples with Output -useful for Schools & College Students

Saturday, January 29, 2011

AUTOMATING THE BANKING PROCESS MC1804 Software Project Development Lab Anna University lab manual download


AUTOMATING THE BANKING PROCESS MC1804 Software Project Development Lab Anna University lab manual download
AUTOMATING THE BANKING PROCESS

Problem Statement


Previously the banking operations were done manually by the workforce. Owing to this time taken for each transaction was more and thereby the customers were forced to wait for a long time to transact their banking business. In order to expedite the banking transaction in an efficient way, the automation of banking was felt necessary and also to cope up with the pace with which the banks in the developed countries progress.

In view of this, computerization in banking industry has been introduced in a phased manner. Now almost all the banks in India have fully computerized their banking operations with a view to giving better customer service and handle more volume of work with ease.

Computerization of banking operations have helped the banks in improving their Management Information System (MIS).Based on this management information system ,the bank could analyze their business data and take effective business decisions.

This project aimed at easing the tedious manual task of banking activities, allows the user (customer) to perform a number of operations. Initially the customer can create an account for which there’s a database which maintains all the records of the accounts. An administrator maintains this database.

While creating an account, the customer has to submit proofs of his identity like birth certificate, permanent address etc. Having created an account, the customer has to deposit a minimum amount and a passbook is issued for the same.

The customer can deposit an amount to his account by filling a challan and waiting to be called by no. given, he can pay the amount to the cashier by cash or cheque the transaction will take place accordingly.

He/she can also withdraw an amount from his account in the same format as above. The only difference is that he has to collect he money. Here the cashier has to first confirm whether he has enough money to be withdrawn, else he is informed accordingly.

The customer can also transfer his account to another branch or to another bank for which user has to inform with proper detailed letter to the manager. The transfer takes place eventually and the particular data in this branch is transferred to other. Every transaction made by the customer is recorded by making an entry in the passbook and in the customer database.

The customer can also avail loans under the various schemes from the bank under the consent of the manager who makes the verification and scrutiny of the submitted documents.

To view the details of his account, the customer can request for the required information from the administrator who maintains the customer database.
                     
Thus the tedious manual tasks of maintaining records, performing calculations every time a transaction is made and updating the database is being simplified by this project, thereby saving time, cost and resources.
Documentation

Use Case Specification: < Deposit >

1. Brief Description

The deposit use case is meant for depositing money in the account.

2  Flow of Events

2.1  Basic Flow

1.      Customer gets the form and fills it
2.      Customer gives the form to the teller and gets token no
3.      Teller gives the details of the customer to the cashier.
4.      Teller calls the token number and customer waits for their number to be called.
5.      If the token number is equal to called number then the customer approaches the cashier.
6.      If deposit is money , then the customer gives the money to cashier.
7.      Cashier enters the details like a/c no, date and amount into the form.
8.      Connection is established with the database through server and ADODC.
9.      If connection is established properly then display ‘connection established successfully’ in the form else display ‘connection not established successfully’ in the form.
10.  Details of customer is passed to the database.
11.  Database is updated.
12.  Cashier gives receipt to the customer.
13.     If deposit is cheque , then the customer gives the cheque to cashier.
14.     Cashier enters the details like a/c no, date and  cheque number  into the form.
15.     Details of customer are passed to the database.
16.     Database is updated.
17.     Cashier gives receipt to the customer.
18.     If deposit is an invalid cheque then cheque is returned back.

            Alternative Flows


2.2.1   < Improper Details >

·         If the cheque is given
·         Check for the proper signature
·         If any overwritten just discard the cheque.

3.     Special Requirements

None


4. Preconditions

Requirement of saving the money in safer way.


5. Post conditions
The money being saved in his account.         

6 Extension point

Issue of the tokens and Updation of passbook

6.1        <name of the extension point>

Issue of tokens
Updation of passbook


Use Case Specification: <OPENING AN ACCOUNT>

Brief Description:
“Opening an account” is the use case, which mainly focuses on the client to open the account in the Bank.

Flow of Events

Basic Flow

·         Client requests for the opening form to the Manager.
·         Client fills the form with the details like name, address, phone, occupation, annual income, introducer’s name and account number and submit it with the necessary documents to the Manager.
·         Manager verifies the documents.
·         If Manager is satisfied, then he gives the confirmation to the client as well as to the Cashier.
·         Cashier enters the details like name, address, phone, occupation, annual income, introducer’s name and account number given by the client into the form and clicks the submit button.
·         Form requests for the connection to the server.
·         System will establish the connection with the ADODC object.
·         ADODC will establishes the connection with the database.
·         Database will check whether the connection is successful or not. If it is successful then it sends the message “ connection is successful” to the form. Else it sends the message as “connection is unsuccessful” to the form.
·         Form will send the information to the database. Database Object will create a dB for the client.
·         “Database created” will be sent to the cashier by the database.
·         Client pays the minimum balance to the cashier.
·         Cashier will enters the balance details into the form.
·         Form will pass the information to the database. Database will update and sends the message “ dB updated” to the cashier.
·         Cashier will issue the passbook to the client.

An actor always initiates use Cases.  The use case should describe what the actor does and what the system does in response.  It should be phrased in the form of a dialog between the actor and the system.

2.2   Alternative Flows
2.2.1  < Insufficient information>
·         Client requests for the opening form to the Manager.
·         Client fills the form with the details like name, address, phone, occupation, annual income, introducer’s name and account number and submit it with the necessary documents to the Manager.
·         Manager verifies the documents.
·         If Manager is not satisfied with the documents and details provided by the Client then he gives the rejection of opening an account to the Client.

Special Requirements

None.

Preconditions

The precondition for this use case is the client is in need to open the account in a Bank for the various purposes like deposit, withdraw, loan, etc

 

PostConditions

The Post condition will be an account in the bank.

 

Extension Points

None.


Use Case Specification: < Transfer A/C >

Brief Description      

Here in this use case we are going to transfer the account from one to another. The transfer can be from one account no to another or also can be from one branch to another or from one bank to another.

Flow of Events

Basic Flow


1.      Customer approaches the bank for transfer of his/her account.
2.      Bank obtains the letter of confirmation and application from the coustmer.
3.      He/She has to return back the passbook and unused cheque leaf back to the manager.
4.      The bank should apply the interest to the account till date.
5.       The bank then debits the customers account to the extent of etire amount outsanding in his account.
6.      Prepare a credit advice or a mail transfer for the amount outstanding in his account.
7.      The credit advice or an opening form duly signed from the accountholder should be sent to the transferee branch with request to open an account.
8.      The customer should suitably informed so as to enable him to operate his account at the new branch.

Alternative Flows

Improper A/C

1.      The details not matching with the details in the database.
2.      The details to be verified manually if not proper give back to the customer.
3.      Get clear image of the details again.

 

Special Requirements

None

 

Preconditions

The state of this use case arrives when the client has to change his account to some other branch according to flexibility


Post Conditions

The account is being transferred to another account according to his / her wish.

 

Extension Points

None








Use Case Specification: < DATABASE MAINTENANCE >

Brief Description
A database is maintained and manipulated by the administrator to record the account details with respect to each customer.

Flow of Events

Basic Flow

The following are procedures to be followed:
1.      The administrator who maintains the database performs data entry operations.
2.      He request details for entry from the cashier.
3.      The cashier provides the details.
4.      A form is provided for maintenance with options: retrieve, delete, update, exit etc.
5.      Firstly he initiates the database connection with the server through ADODC.
6.      Then he should be prompted with the message: connection successful!
7.      If he has to retrieve the details, he enters the account no in the maintenance form.
8.      Then he clicks the retrieve button on the form.
9.      Now the account no is verified for validation in the database.
10.  If account no is found be valid, then the details are to be displayed for that account; otherwise he should be prompted with the message: invalid account no!
11.  Close the details window.
12.  If he has to update the account, he clicks the update button on the form after entering the account no.
13.  Another form is displayed.
14.  Make the entries that need changes and click save.
15.  Prompt MSG: updating saved!
16.  If memory space is full, msg: less memory space!
17.  Click close.
18.  If he has to delete the account, he clicks delete after entering the account no on the form.
19.  To delete the account, the database is checked for null balance in the account.
20.  If balance is found to be null, then the prompt message: account deleted! Otherwise msg: cannot delete account.
21. Disconnects the connection and clicks exit on the form.

Alternative Flows

<Network failure>

·         If network fails, database connection could not be established.

< Memory full >

·         While saving or updating, if there is no memory space, saving or updating cannot be done.

Special Requirements

 None


Preconditions

 Administrator wants to update the database.


Post Conditions

 Database is updated successfully.

Extension Points

 None


Use Case Specification: < AVAIL LOAN >

Brief Description

The client can easily avail loan by following some constraints specified by the bank.

 

Flow of Events

Basic Flow.

  1. Get the application form for the type of loan you are going to avail.
  2. Fill up the application form.
  3. Submit the form with the necessary details like name, address ,occupation ,annual income, It number, etc. and necessary documents like It, etc . to the manager.
  4. Manager performs the general verification processes like whether he is maintaining the account properly, address verification, etc.
  5. Once Manager is satisfied with all his documents, he asks for the collateral security.
  6. Manager checks the security.
  7. If it is true, then the loan will be sanctioned else the loan will not be sanctioned.
8.      Bank client , thus avails the loan facility.

Alternative Flows

< INADEQUATE DETAILS   >

  1. Manager performs the general verification processes like whether he is maintaining the account properly, address verification, etc.
  2. If the client provides the insufficient details and incorrect documents to the manager, then he will not sanction the loan. He will just reject it with the message of “incorrect details”.

< IMPROPER SOURCE OF REPAYMENT >

  1. Manager checks the security.
  2. If it is true, then the loan will be sanctioned else the loan will not be sanctioned.
  3. Bank client, thus avails the loan facility.
4.      After availing loan, if the client was unable to pay the EMI for more than three months, then the guaranteed person will be asked to pay the EMI on his behalf.

 

Preconditions

Need of money for some purpose.

 

Post Conditions

Satisfaction of getting money.

 

Extension Points

None

No comments:

Post a Comment