DESIGN AND DEVELOPMENT OF SMART CHEQUE WRITER- CLIENT

MODULE

BY

TAMIM ANAMID: 012112020

This Report Presented in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computer Science & Engineering

UNDER THE SUPERVISION OF

Dr. Mohammad Nurul HudaProfessor & MSCSE Coordinator,

Department of Computer Science and EngineeringUnited International University

UNITED INTERNATIONAL UNIVERSITY

DHAKA, BANGLADESH

APRIL 2013

APPROVAL

This Project titled “Design and Development of Smart Cheque Writer-Client

Module”, submitted by Tamim Anam to the Department of Computer Science and

Engineering, United International University, has been accepted as satisfactory for the

partial fulfillment of the requirements for the degree of MSc. in CSE and approved as to

its style and contents. The presentation has been held on 13 April, 2013

BOARD OF EXAMINERS

Dr. Mohammad Nurul Huda SupervisorProfessor and MSCSE CoordinatorDepartment of Computer Science and EngineeringUnited International University

Dr. Swakkhar Shatabda ExaminerAssistant ProfessorDepartment of Computer Science and EngineeringUnited International University

Dr. Salekul Islam Ex-OfficioAssociate Professor and HeadDepartment of Computer Science and EngineeringUnited International University

ii

ACKNOWLEDGEMENT

First we express our heartiest thanks and gratefulness to almighty Allah for His divine

blessing makes us possible to complete this project successfully.

We fell grateful to and wish our profound our indebtedness to Dr. Mohammad Nurul Huda, Professor and MSCSE Coordinator, Department of Computer Science and

Engineering, United International University, Dhaka. Deep Knowledge & keen interest of

our supervisor in the field of financial business automation influenced us to carry out this

project .His endless patience ,scholarly guidance ,continual encouragement , constant and

energetic supervision, constructive criticism , valuable advice ,reading many inferior

draft and correcting them at all stage have made it possible to complete this project.

We would like to express our heartiest gratitude to Dr Mohammad Nurul Huda, Associate

Professor and MSCSE Coordinator, Department of CSE, for his kind help to finish our

project and also to other faculty member and the staff of CSE department of United

International University.

We would like to thank our entire course mate in United International University, who

took part in this discuss while completing the course work.

Finally, we must acknowledge with due respect the constant support and patients of our

parents.

ABSTRACT

iii

Bank cheque is one of the most important payment methods. Corporate companies, SMEs

pay to it’s customer through bank cheque. One company may have multiple bank

accounts. But, when they handover cheque to party, then there is a possibility of being

over draft the account. In such over draft cheque may decrease the company values and

creates bad impact on customers.

Moreover, Bouncing a check (having it returned due to insufficient funds) is an offense in

the Bangladesh. The account holder may be charged around 50 taka for bouncing cheque.

If the amount is large, the recipient may take legal action against cheque issuer, take him

to court, and may end up in jail.

In order to overcome this problem, the cheque writer application is designed and

developed using Visual Basic.Net platform for necessary security and portability reason.

The software application perform satisfactorily. The future of this cheque writer can be

farther extended with more features.

TABLE OF CONTENTS

CONTENTS PAGE

iv

Board of examiners ii

Acknowledgements iii

Abstract ivCHAPTER

CHAPTER 1: INTRODUCTION 1-1

1.1 : Objective 1

1.2 : Motivation 1

1.3 : Layout 1

CHAPTER 2: LITERATURE OVERVIEW 2-7

2.1: Introduction to Cheque Writing 2

2.2: Existing Problem 5

2.3: Proposed Solution 5

CHAPTER 3: REQUIREMENT SPECIFICATION 8-14

3.1: Use Case Model 8

3.2: Description of Use Case 11

3.3: Data Requirement 13

3.4: Summary 14

CHAPTER 4: DESIGN 15-27

4.1: Design of the Data Model 15

4.2: GUI Design and Reports 20

4.3: Object Model 24

4.4: Database design 25

CHAPTER 5: IMPLEMENTATION 28-35

5.1: Implementation 28

5.2: Software Testing 31

CHAPTER 6: CONCLUTION AND FUTURE SCOPE 36-37

6.1: Conclusion 36

6.2: Contribution 36

6.3: Future Scope 37

Reference 37

LIST OF FIGURES

v

FIGURES PAGE NO

Fig 2.1: Sample Cheque 3

Fig 3.1: Use case diagram(client module) 13

Fig 4.1: Transaction flowchart 17

Fig 4.2: Withdraw flowchart 18

Fig 4.3: Deposit flowchart 19

Fig4.4: Delete transaction flowchart 20

Fig 4.5: Database diagram 26

Fig 5.1: Transaction entry screen 30

Fig 5.2: Cheque print screen 31

vi

CHAPTER ONE

INTRODUCTION

1.1 Objective

Bank cheque is one of the most important payment methods. Corporate companies, SMEs

pay to it’s customer through bank cheque. One company may have multiple bank

accounts. But, when they handover cheque to party, then there is a possibility of being

over draft the account. In such over draft cheque may decrease the company values and

creates bad impact on customers.

1.2 Motivation

A smart cheque writer application is designed and developed for the banks. Bank will

provide this cheque writer project to it’s corporate customer for cheque printing. This

application can be also used by any smart customer of bank to print his cheque. While

printing cheque, the balance of any account is maintained. Customer can check current

balance of his account and available leaf of cheque book, can also generate statement of

the account. He can match the statement with bank’s actual statement. Stop payment for

issued cheque and lost cheque are also be marked with this application and this particular

leaf cannot be used for farther payment. Customer can also maintain beneficiary to track

particular beneficiary for payment. Customer can maintain multiple accounts of different

banks.

1.3 Layout

The cheque writing software has two module, one is admin module and another is client

module. Admin module covers system or configuration related tasks like bank creation,

account creation, cheque book issue stop payment and lost cheque mark. Client module

includes operational tasks like deposit or withdraws transaction, printing cheque, deleting

a transaction and generation of reports.

1

CHAPTER TWO

LITERATURE OVERVIEW

2.1 Introduction to Cheque Writing

A cheque[1] is a document that orders a payment of money from a bank account. The

person writing the cheque, the drawer, usually has a current account or saving account

where their money was previously deposited. The drawer writes the various details

including the monetary amount, date, and a payee on the cheque, and signs it, ordering

their bank, known as the drawee, to pay that person or company the amount of money

stated.

Cheques are a type of bill of exchange and were developed as a way to make payments

without the need to carry large amounts of money. While paper money evolved from

promissory notes, another form of negotiable instrument, similar to cheques in that they

were originally a written order to pay the given amount to whoever had it in their

possession (the "bearer").

Technically, a cheque is a negotiable instrument instructing a financial institution to pay a

specific amount of a specific currency from a specified transactional account held in the

drawer's name with that institution. Both the drawer and payee may be natural persons or

legal entities. Specifically, cheques are order instruments, and are not in general payable

simply to the bearer (as bearer instruments are) but must be paid to the payee. In some

countries, such as the US, the payee may endorse the cheque, allowing them to specify a

third party to whom it should be paid.

Although forms of cheques have been in use since ancient times and at least since the 9th

century, it was during the 20th century that cheques became a highly popular non-cash

method for making payments and the usage of cheques peaked. By the second half of the

20th century, as cheque processing became automated, billions of cheques were issued

annually; these volumes peaked in or around the early 1990s. Since then cheque usage

2

has fallen, being partly replaced by electronic payment systems. In some countries like

Poland cheques have become a marginal payment system or have been phased out

completely.

2.1.1 Check Writing Fields[2][3]

Fig 2.1: Sample cheque

i. Date:

Date format in Bangladesh. is dd/mm/yyyy. There are boxes for each digit of date. We

need to write only one digit at each box like

3 1 1 2 2 0 1 1

ii. Payee:

Name of the person or company to whom we're paying money with the check.

iii. Amount in Numbers:

Write the amount in numbers., e.g. 127.89. Note that the BDT sign is already pre-printed.

Therefore, we don't have to write it again.

iv. Amount in Words:

3

This will be the same amount that we wrote in step 3, e.g., One-hundred twenty-seven

and 89/100.

v. Signature:

Your signature, the same way you wrote it when you opened your bank account. If you

have a joint account, and if there are multiple signatories, any authorized person can sign.

After you write the check, remember to write the date, check number, payee, and the

amount in the check register located at the front of the checkbook.

2.1.2 Check Information

The order of these numbers may differ on your check and may include some special

symbols different than those shown.

i. Check Number:

Each check has a different check number. Please note that the check number appears

twice on the check - once at the top right corner and once at the bottom center.

ii. Routing Number:

This is the routing number of the bank that facilitates electronic clearing of the check.

This number will be the same for many account holders at your bank.

The routing number is always nine digits and begins with a 0, 1, 2, or 3. On a check, this

number is always bracketed.

iii. Account Number:

Your bank account number. This number will be the same on all of our checks.

iv. Account Title:

The title of the account.

4

2.2 Existing Problem

In Bangladesh, we write a check using our checking account. We can write a check up to

the monetary balance you have in our account. However, if we have overdraft protection,

we may be able to write a check for a higher amount. 

Bouncing a check (having it returned due to insufficient funds) is an offense in the

Bangladesh. The account holder may be charged around 50 taka for bouncing cheque. If

the amount is large, the recipient may take legal action against cheque issuer, take him to

court, and may end up in jail.

It is absolutely fine to write a check for small amounts, like 1000/=. Most people in

Bangladesh carry little or no cash with them. Most of the payments are done either with a

credit card or check. However, it is still recommended to to carry some cash at all times,

just in case. Of course, if we are writing checks for small amounts, we will want to

keep your checkbook with us all the times.

Moreover, corporate companies, SMEs pay to it’s customer through bank cheque. One

company may have multiple bank accounts. But, when they handover cheque to party,

then there is a possibility of being over draft the account. In such over draft cheque may

decrease the company values and creates bad impact on customers.

2.3 Proposed Solution

To stop bouncing of a cheque, a system can be designed and developed which will keep

track of issued cheque and available balance for payment . No cheque will be written in

hand. Cheque will be printed by an application which will check available balance of the

account and available cheque leaf befor printing. If the balance is available, only then the

cheque will be printed, otherwise it will show no balance is available. The system will

track beneficiary that which beneficiary has taken how many cheques.

5

The application may have two modules: Admin module & Client module.

2.3.1 Admin Module Features

i. Bank creation: The bank with which I maintain accounts. It includes

information like bank name, address, bank code etc.

ii. Branch Creation: Branch of my account. It covers with Branch name , bank

name, address, phone no, mobile no, email fax, routing no etc.

iii. Beneficiary: Beneficiary of the cheque. I want to store details of the

beneficiary, so that I can track the beneficiary. I can query total number of

cheque disbursed to a particular beneficiary.

iv. Account Creation: Detail information of account like account no, account title,

opening balance, current balance branch of account etc.

v. Cheque Book Entry: Each account has cheque book. I have to maintain

cheque book and its leaf, account of the cheque book etc.

vi. Login/Log Out

vii. Change Password

2.3.2 Client Module Features

i. Deposit : If any amount is deposited at my bank account, then I also need to

deposit it to this software to maintain the balance for respective account.

ii. Print Cheque: When I want to issue a cheque to a beneficiary, then I have to

print the cheque.

iii. Stop Payment: After issuing a cheque, if I want to stop the payment , then I

have to stop the payment it in the software so that cheque leaf and balance can

be maintained. It will reverse the amount.

iv. Audit Log: There will be facility to query for any account or any beneficiary

for balance or payment history.

6

2.4 Summary

In this chapter the introduction of bank cheque and fields of a cheque are discussed. This

chapter discusses the problem of hand writing cheque and proposed solution of the

problem. It also discuss the detail features of proposed solution.

7

CHAPTER THREEE

REQUIREMENT SPECIFICATION

3.1 Use case Model

A use-case model[4] is a model of how different types of users interact with the system to

solve a problem.  As such, it describes the goals of the users, the interactions between the

users and the system, and the required behavior of the system in satisfying these goals.

A use-case model consists of a number of model elements.  The most important model

elements are: use cases, actors and the relationships between them. 

A use-case diagram is used to graphically depict a subset of the model to simplify

communications.  There will typically be several use-case diagrams associated with a

given model, each showing a subset of the model elements relevant for a particular

purpose.  The same model element may be shown on several use-case diagrams, but each

instance must be consistent.  If tools are used to maintain the use-case model, this

consistency constraint is automated so that any changes to the model element (changing

the name for example) will be automatically reflected on every use-case diagram that

shows that element.

The use-case model may contain packages that are used to structure the model to simplify

analysis, communications, navigation, development, maintenance and planning. Much of

the use-case model is in fact textual, with the text captured in the use-case

specifications that are associated with each use-case model element. These specifications

describe the flow of events of the use case.

The use-case model serves as a unifying thread throughout system development. It is

used as the primary specification of the functional requirements for the system, as the

basis for analysis and design, as an input to iteration planning, as the basis of defining test

cases and as the basis for user documentation.

8

The use-case model contains, as a minimum, the following basic model elements.

Actor

A model element representing each actor. Properties include the actors name and brief

description.

Use Case

A model element representing each use case. Properties include the use case name and

use case specification.

Associations

Associations are used to describe the relationships between actors and the use cases they

participate in. This relationship is commonly known as a "communicates-association".

Advanced model elements

The use-case model may also contain the following advanced model elements.

Subject

A model element that represents the boundary of the system of interest.  

Use-Case Package

A model element used to structure the use case model to simplify analysis,

communications, navigation, and planning.  If there are many use cases or actors, you can

use use-case packages to further structure the use-case model in much the same manner

you use folders or directories to structure the information on your hard-disk.

You can partition a use-case model into use-case packages for several reasons, including:

To reflect the order, configuration, or delivery units in the finished system thus

supporting iteration planning.

To support parallel development by dividing the problem into bite-sized pieces.

To simplify communication with different stakeholders by creating packages for

containing use cases and actors relevant to a particular stakeholder.

9

Generalizations

A relationship between actors to support re-use of common properties.

Dependencies

A number of dependency types between use cases are defined in UML. In particular,

<<extend>> and <<include>>.

<<extend>> is used to include optional behavior from an extending use case in an

extended use case.

<<include>> is used to include common behavior from an included use case into a base

use case in order to support re-use of common behavior.

The latter is the most widely used dependency and is useful for:

Factoring out behavior from the base use case that is not necessary for the

understanding of the primary purpose of the use case to simplify communications.

Factoring out behavior that is in common for two or more use cases to maximize

re-use, simplify maintenance and ensure consistency.

Use case diagram of client module are given bellow:

Fig 3.1: Use case diagram (Client Module)

10

3.2 Use Case details

Use case name : Login

Precondition : None

Actor : System

Primary path : 1. Key in login Id

2. Key in password

3. Click on Login

Exceptional path : 3.1 Invalid login Id or password, Show “Invalid Login”

Notes : Created on 10 Sep, 2012

Use case name : Add Bank

Precondition : Login

Actor : User

Primary path : 1. Input details of a bank, with which user maintain account

2. Press on Save

Exceptional path : 2.1 Mandatory fields are missing.

Notes : Created on 10 Sep, 2012

Use case name : Add Account

Precondition : Login

Actor : User

Primary path : 1. Input account details including account no, title & type.

2. Select bank of account

3. Input branch details

4. Input minimum balance, current balance, initial balance

and create date

5. Press on Save.

Exceptional path : Mandatory fields are required.

Current balance cannot be greater than minimum balance.

Initial balance cannot be zero and must be greater than minimum

11

balance.

Account create date cannot be greater than current date.

Notes : Created on 10 Sep, 2012

Use case name : Add Beneficiary

Precondition : Login

Actor : User

Primary path : 1. Input beneficiary details

2. Press on Save

Exceptional path : 2.1 Mandatory fields are missing.

Notes : Created on 10 Sep, 2012

Use case name : Add Cheque Book

Precondition : Login

Actor : User

Primary path : 1. Select Account

2. Add cheque book details

3. Press on Save.

Exceptional path : 3.1 Mandatory fields are missing.

Notes : Created on 10 Sep, 2012

Use case name : Do Transaction

Precondition : Login

Actor : User

Primary path : 1. Input Account

2. Input transaction type

3. Select payment mode

4. Input Amount

12

5. Press on Save

Exceptional path : 1.1 Invalid account

No balance available

No cheque leaf available.

Notes : Created on 10 Sep, 2012

Use case name : Delete Transaction

Precondition : Login

Actor : User

Primary path : 1. Input Transaction Id.

2. Press on Save.

Exceptional path : Invalid Transaction Id.

Already honored

Notes : Created on 10 Sep, 2012

Use case name : Stop payment

Precondition : Login

Actor : User

Primary path : 1. Input Transaction Id.

2. Press on Save.

Exceptional path : Invalid Transaction Id.

Already honored

Notes : Created on 10 Sep, 2012

Use case name : Honor Cheque

Precondition : Login

Actor : User

Primary path : 1. Input transaction id or cheque no.

2. Press on Honor

Exceptional path : Already honored

13

Invalid transaction id or cheque no.

Notes : Created on 10 Sep, 2012

Use case name : Print Cheque

Precondition : Login

Actor : User

Primary path : 1. Select Transaction

2. Press on Print Cheque

Exceptional path : 2.1 Invalid Transaction.

Notes : Created on 10 Sep, 2012

3.3 Summary

Use case model and details on f use case model are very important for software

design life cycle. By use case, external tester can test all features of the software.

In this chapter, introduction of the use case and properties of use case are discussed.

The use case diagram of admin module of the software and details of the use case

diagram are presented.

14

CHAPTER FOUR

DESIGN

4.1 Design of Data Model

Data modeling [5] is a process used to define and analyze data requirements needed to

support the business processes within the scope of corresponding information systems in

organizations. Therefore, the process of data modeling involves professional data

modelers working closely with business stakeholders, as well as potential users of the

information system. There are three different types of data models produced while

progressing from requirements to the actual database to be used for the information

system. The data requirements are initially recorded as a conceptual data model which is

essentially a set of technology independent specifications about the data and is used to

discuss initial requirements with the business stakeholders. The conceptual model is then

translated into a logical data model, which documents structures of the data that can be

implemented in databases. Implementation of one conceptual data model may require

multiple logical data models. The last step in data modeling is transforming the logical

data model to a physical data model that organizes the data into tables, and accounts for

access, performance and storage details. Data modeling defines not just data elements,

but their structures and relationships between them. Data modeling techniques and

methodologies are used to model data in a standard, consistent, predictable manner in

order to manage it as a resource. The use of data modeling standards is strongly

recommended for all projects requiring a standard means of defining and analyzing data

within an organization, e.g., using data modeling:

to manage data as a resource;

for the integration of information systems;

for designing databases/data warehouses (aka data repositories)

Data modeling may be performed during various types of projects and in multiple phases

of projects. Data models are progressive; there is no such thing as the final data model for

15

a business or application. Instead a data model should be considered a living document

that will change in response to a changing business. The data models should ideally be

stored in a repository so that they can be retrieved, expanded, and edited over time.

Whitten (2004) determined two types of data modeling:

Strategic data modeling: This is part of the creation of an information systems

strategy, which defines an overall vision and architecture for information systems

is defined. Information engineering is a methodology that embraces this approach.

Data modeling during systems analysis: In systems analysis logical data models

are created as part of the development of new databases.

Data modeling is also used as a technique for detailing business requirements for specific

databases. It is sometimes called database modeling because a data model is eventually

implemented in a database.

4.1.1 Flow Chart

Flowcharts[6] help to assess the flow of data. Flowcharts are primarily used to help

brainstorm ideas in order to build strategies in the planning stage of any new product or

company. As visual representations of the flow of data, flowcharts present key points to

investors, clients, customers, business partners and employees.

Definition

A flowchart graphically represents the sequence of operations or step-by-step progression

of a programming or business model, using connecting lines and conventional symbols.

Function

Flowcharts can be used to determine the key points of a business or program model. It

can also be used to connect those key points and establish relationships between

processes.

Types

16

There are three types of flowcharts: high-level, detailed and matrix. While the high-level

(or top-down) flowchart only gives a birds-eye view of the key points, the detailed and

matrix flowcharts break down the processes and give more key points.

Uses

For a presentation where only the key points are needed, use a high-level flowchart; this

is usually the case with business models. The detailed or matrix flowchart should be used

when more information about the key points and their relationship to each other is

needed.

Shapes

Shapes used in flowcharts include boxes, circles, diamonds and triangles. Each shape

represents a certain action or conclusion of action.

Flow charts of Create Transaction

Flow charts are used to depict the flow of process. While creating a transaction, user give

input the account no. Then it verifies the account no. If the account number is valid then

deposit or withdraw process will be performed on the basis of transaction type.

Fig 4.1: Transaction flow chart

17

Withdraw process will be performed on the basis of payment mode. If the payment mode

is cheque, then it checks the availability of cheque leaf and payment performed through

cheque printing. The withdraw flow chart is given below:

Fig 4.2: Withdraw flow chart

18

Deposit on the account can be performed by simply crediting to the account. We need to

update the deposit on this account so that balance can be maintained. To perform a

deposit transaction it get amount as input and then it adds it with the current balance and

pass a accounting entry.

Fig 4.3: Deposit flow chart

Delete Transaction: When we do a transaction wrongly, then it requires to delete the

transaction. While deleting a transaction it updates the balance of the account and pass a

reverse entry to the GL.

19

Fig 4.4: delete transaction flow chart

4.2 GUI Design and Reports

User interface[7] design or user interface engineering is the design of computers,

appliances, machines, mobile communication devices, software applications, and

websites with the focus on the user's experience and interaction. The goal of user

interface design is to make the user's interaction as simple and efficient as possible, in

terms of accomplishing user goals—what is often called user-centered design. Good user

interface design facilitates finishing the task at hand without drawing unnecessary

attention to itself. Graphic design may be utilized to support its usability. The design

process must balance technical functionality and visual elements (e.g., mental model) to

20

create a system that is not only operational but also usable and adaptable to changing user

needs.

Interface design is involved in a wide range of projects from computer systems, to cars,

to commercial planes; all of these projects involve much of the same basic human

interactions yet also require some unique skills and knowledge. As a result, designers

tend to specialize in certain types of projects and have skills centered around their

expertise, whether that be software design, user research, web design, or industrial

design.

4.2.1 Processes

There are several phases and processes in the user interface design, some of which are

more demanded upon than others, depending on the project. (Note: for the remainder of

this section, the word system is used to denote any project whether it is a web site,

application, or device.)

Functionality requirements gathering – assembling a list of the functionality

required by the system to accomplish the goals of the project and the potential

needs of the users.

User analysis – analysis of the potential users of the system either through

discussion with people who work with the users and/or the potential users

themselves. Typical questions involve:

o What would the user want the system to do?

o How would the system fit in with the user's normal workflow or daily

activities?

o How technically savvy is the user and what similar systems does the user

already use?

o What interface look & feel styles appeal to the user?

21

Information architecture – development of the process and/or information flow of

the system (i.e. for phone tree systems, this would be an option tree flowchart and

for web sites this would be a site flow that shows the hierarchy of the pages).

Prototyping – development of wireframes, either in the form of paper prototypes

or simple interactive screens. These prototypes are stripped of all look & feel

elements and most content in order to concentrate on the interface.

Usability testing – testing of the prototypes on an actual user—often using a

technique called think aloud protocol where you ask the user to talk about their

thoughts during the experience.

Graphic Interface design – actual look & feel design of the final graphical user

interface (GUI). It may be based on the findings developed during the usability

testing if usability is unpredictable, or based on communication objectives and

styles that would appeal to the user. In rare cases, the graphics may drive the

prototyping, depending on the importance of visual form versus function. If the

interface requires multiple skins, there may be multiple interface designs for one

control panel, functional feature or widget. This phase is often a collaborative

effort between a graphic designer and a user interface designer, or handled by one

who is proficient in both disciplines.

User interface design requires a good understanding of user needs.

4.2.2 Requirements

The dynamic characteristics of a system are described in terms of the dialogue

requirements contained in seven principles of part 10 of the ergonomics standard, the ISO

9241. This standard establishes a framework of ergonomic "principles" for the dialogue

techniques with high-level definitions and illustrative applications and examples of the

principles. The principles of the dialogue represent the dynamic aspects of the interface

and can be mostly regarded as the "feel" of the interface. The seven dialogue principles

are:

22

Suitability for the task: the dialogue is suitable for a task when it supports the user

in the effective and efficient completion of the task.

Self-descriptiveness: the dialogue is self-descriptive when each dialogue step is

immediately comprehensible through feedback from the system or is explained to

the user on request.

Controllability: the dialogue is controllable when the user is able to initiate and

control the direction and pace of the interaction until the point at which the goal

has been met.

Conformity with user expectations: the dialogue conforms with user expectations

when it is consistent and corresponds to the user characteristics, such as task

knowledge, education, experience, and to commonly accepted conventions.

Error tolerance: the dialogue is error tolerant if despite evident errors in input, the

intended result may be achieved with either no or minimal action by the user.

Suitability for individualization: the dialogue is capable of individualization when

the interface software can be modified to suit the task needs, individual

preferences, and skills of the user.

Suitability for learning: the dialogue is suitable for learning when it supports and

guides the user in learning to use the system.

The concept of usability is defined in Part 11 of the ISO 9241 standard by effectiveness,

efficiency, and satisfaction of the user. Part 11 gives the following definition of usability:

Usability is measured by the extent to which the intended goals of use of the

overall system are achieved (effectiveness).

The resources that have to be expended to achieve the intended goals (efficiency).

The extent to which the user finds the overall system acceptable (satisfaction).

23

Effectiveness, efficiency, and satisfaction can be seen as quality factors of usability. To

evaluate these factors, they need to be decomposed into sub-factors, and finally, into

usability measures.

The information presentation is described in Part 12 of the ISO 9241 standard for the

organization of information (arrangement, alignment, grouping, labels, location), for the

display of graphical objects, and for the coding of information (abbreviation, color, size,

shape, visual cues) by seven attributes. The "attributes of presented information"

represent the static aspects of the interface and can be generally regarded as the "look" of

the interface. The attributes are detailed in the recommendations given in the standard.

Each of the recommendations supports one or more of the seven attributes. The seven

presentation attributes are:

Clarity: the information content is conveyed quickly and accurately.

Discriminability: the displayed information can be distinguished accurately.

Conciseness: users are not overloaded with extraneous information.

Consistency: a unique design, conformity with user’s expectation.

Detectability: the user’s attention is directed towards information required.

Legibility: information is easy to read.

Comprehensibility: the meaning is clearly understandable, unambiguous,

interpretable, and recognizable.

The user guidance in Part 13 of the ISO 9241 standard describes that the user guidance

information should be readily distinguishable from other displayed information and

should be specific for the current context of use. User guidance can be given by the

following five means:

Prompts indicating explicitly (specific prompts) or implicitly (generic prompts)

that the system is available for input.

Feedback informing about the user’s input timely, perceptible, and non-intrusive.

24

Status information indicating the continuing state of the application, the system’s

hardware and software components, and the user’s activities.

Error management including error prevention, error correction, user support for

error management, and error messages.

On-line help for system-initiated and user initiated requests with specific

information for the current context of use.

4.3 Object Model

The object model represents the static and most stable phenomena in the modeled domain

(Rumbaugh et al.,1991:21). Main concepts are classes and associations, with attributes

and operations. Aggregation and generalization (with multiple inheritance) are

predefined relationships.

Build an Object Model:

1. Identify object classes.

2. Develop a data dictionary for classes, attributes, and associations.

3. Add associations between classes.

4. Add attributes for objects and links.

5. Organize and simplify object classes using inheritance.

6. Test access paths using scenarios and iterate the above steps as necessary.

7. Group classes into modules, based on close coupling and related function.

4.4 Database Design

Database design is the most important factor for a software design. We have used Microsoft

Access as database to make the system very portable. Database is used to store the actual data.

25

The diagram of a physical database is given below. This includes table diagram for both

admin module and client module.

Fig 4.5: Database diagram

4.4.1 Database Details for Client Module

Client module related tables are:

26

SCR_Master: It includes all operational data. Creating any transaction, deleting

transaction, deposit transaction printing cheque are stored in this table.

The fields are given below:

Name Type SizeMaster_Id Long Integer 4AccountNo Text 15Title_ofAC Text 50ODate Date/Time 8Ref Text 3Bank_Code Text 4Dr_Cr Text 1Prefix Text 3ChequeNo Text 8DrAmount Double 8CrAmount Double 8Narration Text 100Amt_Inword Text 100Head Text 25AccountID Long Integer 4Acc_Name Text 50Bank_id Long Integer 4Bank_NM Text 50Branch_Id Long Integer 4Branch_NM Text 50Acc_Type Text 7UserId Long Integer 4User_NM Text 15

4.5 Summary

This chapter describes detail design of the application. The design of the data model,

flowcharts of different procedure, GUI design of the system with reports and database

design are described in this chapter. The physical schema required for the system and

description of the tables with field details are given in this chapter.

27

CHAPTER FIVE

IMPLEMENTATION AND TESTING

5.1 Implementation Overview:

To make fast, secure and robust, latest and modern methodology and technology is used

to implement the “Smart Cheque Writer”. The technology which is used to implement,

makes this project user friendly, reliable and standard centralized web based system.

5.1.1 Methodology

Object Oriented Programming (OOP): To develop this centralized system,

OOP concept is used to ensure the encapsulation, hiding, re-use and

abstraction.

Model View Controller Architecture (MVC): To ensure data hiding, and

implementing the secure access to database, MVC is used in this project.

Persistent Database Connection: To ensure, maximum database connection

performance for load balancing and increasing performance, oracle persistent

database connection is used in this project.

5.1.2 Technology

MS Access: To make the application simple and light weighted, we have used

MS Access database.

Visual Basic: We have used visual basic to make the software with all version

of windows.

28

Crystal report: We used crystal report to design reports.

After completing the Software Requirement Specification (SRS), Work Flow Diagram,

Entity Relationship Diagram (ERD), the Graphical User Interface (GUI) is designed.

This software’s GUI is designed according to the Constantine and Lockwood described

collection of principles for improving the quality of user interface design. These

principles are

The structure principle. Design should organize the user interface purposefully,

in meaningful and useful ways based on clear, consistent models that are apparent

and recognizable to users, putting related things together and separating unrelated

things, differentiating dissimilar things and making similar things resemble one

another. The structure principle is concerned with overall user interface

architecture.

The simplicity principle. Design should make simple, common tasks simple to

do, communicating clearly and simply in the user’s own language, and providing

good shortcuts that are meaningfully related to longer procedures.

The visibility principle. Design should keep all needed options and materials for

a given task visible without distracting the user with extraneous or redundant

information. Good designs don’t overwhelm users with too many alternatives or

confuse them with unneeded information.

The feedback principle. Design should keep users informed of actions or

interpretations, changes of state or condition, and errors or exceptions that are

relevant and of interest to the user through clear, concise, and unambiguous

language familiar to users.

The tolerance principle. Design should be flexible and tolerant, reducing the

cost of mistakes and misuse by allowing undoing and redoing, while also

29

preventing errors wherever possible by tolerating varied inputs and sequences and

by interpreting all reasonable actions reasonable.

The reuse principle. Design should reuse internal and external components and

behaviors, maintaining consistency with purpose rather than merely arbitrary

consistency, thus reducing the need for users to rethink and remember.

After completing all the above activities, the coding and implementation started.

Client Module

Daily transaction related works like create transaction, printing cheque and delete

transaction are included in client module.

Transaction

Transaction may be deposit or withdraw type. All transaction may be happened here.

30

Fig 5.1: Transaction entry screen

Print Cheque

After creating transaction of withdraws type, we have to print cheque from following

screen.

31

Fig 5.2: Cheque print screen

4.2 Software Testing

Software testing[8] is an investigation conducted to provide stakeholders with information

about the quality of the product or service under test. Software testing can also provide an

objective, independent view of the software to allow the business to appreciate and

understand the risks of software implementation. Test techniques include, but are not

limited to, the process of executing a program or application with the intent of finding

software bugs (errors or other defects).

32

Software testing can be stated as the process of validating and verifying that a software

program/application/product:

1. meets the requirements that guided its design and development;

2. works as expected;

3. can be implemented with the same characteristics.

4. satisfies the needs of stakeholders

Software testing, depending on the testing method employed, can be implemented at any

time in the development process. Traditionally most of the test effort occurs after the

requirements have been defined and the coding process has been completed, but in the

Agile approaches most of the test effort is on-going. As such, the methodology of the test

is governed by the chosen software development methodology.

4.2.1 Testing methods

Static vs. dynamic testing: There are many approaches to software testing. Reviews,

walkthroughs, or inspections are referred to as static testing, whereas actually

executing programmed code with a given set of test cases is referred to as dynamic

testing. Static testing can be omitted, and unfortunately in practice often is. Dynamic

testing takes place when the program itself is used. Dynamic testing may begin before the

program is 100% complete in order to test particular sections of code and are applied to

discrete functions or modules. Typical techniques for this are either using stubs/drivers

or execution from a debugger environment.

4.2.2 The box approach

Software testing methods are traditionally divided into white- and black-box testing.

These two approaches are used to describe the point of view that a test engineer takes

when designing test cases.

33

White-Box testing: White-box testing (also known as clear box testing, glass box testing,

transparent box testing and structural testing) tests internal structures or workings of a

program, as opposed to the functionality exposed to the end-user. In white-box testing an

internal perspective of the system, as well as programming skills, are used to design test

cases. The tester chooses inputs to exercise paths through the code and determine the

appropriate outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing

(ICT).

While white-box testing can be applied at the unit, integration and system levels of the

software testing process, it is usually done at the unit level. It can test paths within a unit,

paths between units during integration, and between subsystems during a system–level

test. Though this method of test design can uncover many errors or problems, it might not

detect unimplemented parts of the specification or missing requirements.

Techniques used in white-box testing include:

API testing (application programming interface) - testing of the application using

public and private APIs

Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the

test designer can create tests to cause all statements in the program to be executed

at least once)

Fault injection methods - intentionally introducing faults to gauge the efficacy of

testing strategies

Mutation testing methods

Static testing methods

Code coverage tools can evaluate the completeness of a test suite that was created with

any method, including black-box testing. This allows the software team to examine parts

of a system that are rarely tested and ensures that the most important function points have

been tested. Code coverage as a software metric can be reported as a percentage for:

34

Function coverage, which reports on functions executed

Statement coverage, which reports on the number of lines executed to

complete the test

100% statement coverage ensures that all code paths, or branches (in terms of control

flow) are executed at least once. This is helpful in ensuring correct functionality, but not

sufficient since the same code may process different inputs correctly or incorrectly.

Black-box testing

Black-box testing treats the software as a "black box", examining functionality without

any knowledge of internal implementation. The tester is only aware of what the software

is supposed to do, not how it does it. Black-box testing methods include: equivalence

partitioning, boundary value analysis, all-pairs testing, state transition tables, decision

table testing, fuzz testing, model-based testing, use case testing, exploratory testing and

specification-based testing.

Grey-box testing: Grey-box testing (American spelling: gray-box testing) involves

having knowledge of internal data structures and algorithms for purposes of designing

tests, while executing those tests at the user, or black-box level. The tester is not required

to have full access to the software's source code. Manipulating input data and formatting

output do not qualify as grey-box, because the input and output are clearly outside of the

"black box" that we are calling the system under test. This distinction is particularly

important when conducting integration testing between two modules of code written by

two different developers, where only the interfaces are exposed for test. However,

modifying a data repository does qualify as grey-box, as the user would not normally be

able to change the data outside of the system under test. Grey-box testing may also

include reverse engineering to determine, for instance, boundary values or error

messages.

35

Visual testing: The aim of visual testing is to provide developers with the ability to

examine what was happening at the point of software failure by presenting the data in

such a way that the developer can easily find the information he requires, and the

information is expressed clearly.

At the core of visual testing is the idea that showing someone a problem (or a test

failure), rather than just describing it, greatly increases clarity and understanding. Visual

testing therefore requires the recording of the entire test process – capturing everything

that occurs on the test system in video format. Output videos are supplemented by real-

time tester input via picture-in-a-picture webcam and audio commentary from

microphones.

To test the admin module of the application, we have test all screen as visual test, and

functional accuracy. We found all process are working fine and all screen can handle any

exceptional data. The sample cheque print is given

36

CHAPTER SIX

CONCLUSION AND FUTURE WORK

6.1 Conclusion

The Purpose of the Cheque Book Scheme is to permit customer to make payments to

retailers, utilities and others by cheque, as an alternative to paying with cash or by

account transfers.

From the practical implementation of Beneficiary dealing procedure during the whole

period of Practical orientation to the Bank we have reached a firm and concrete

conclusion in a very confident way. We believe that our realization will be in the

harmony with most of the banking thinkers. It is quite evident that to build up an

effective and efficient banking system to the highest level computerized transaction is a

must.

Lastly we would like to say using “Smart Cheque Writer” software it is very helpful to

maintain the cheque book information and balance book with the bank transaction. As a

result Account holder easily understood how much money have in bank accounts and

which cheque book leaf issue to whom for payment.

6.2 Contribution

Restrict the cheque bouncing with automatic balance update while printing the

cheque.

Making the system standalone and user friendly.

Marking stop payment and lost cheque to reverse the payment.

Deleting any unpaid & unissued transaction

6.3 Future Work

37

Following may be added to smart cheque writer in future:

1. Batch printing function to print a sequence of cheques in batch.

2. Voucher print at the time of transaction.

3. Used cheque auto update.

4. User privilege setting.

5. More reports on the basis of user requirements.

References

[1] “Cheque”, http://en.wikipedia.org/wiki/Cheque, date: 15 Sep, 2012

[2] “Securing Banking Instruments.”, http://www.jbsppl.com, date: 15 Sep, 2012

[3] “Cheque Writing Tips”, http://www.immihelp.com/newcomer/writing-a-check-

tips.html, date: 15 Sep, 2012

[4] “Use case”, http://en.wikipedia.org/wiki/Use_case, date: 18 Sep, 2012

[5] “Data Model”, http://en.wikipedia.org/wiki/Data_model, date: 18 Sep, 2012

[6] “Flowchart”, http://en.wikipedia.org/wiki/Flowchart, date: 18 Sep, 2012

[7] “User Interface Design”, http://en.wikipedia.org/wiki/User_interface_design, date: 18

Sep, 2012

[8] “Software Testing”, http://en.wikipedia.org/wiki/Software_testing, date: 18 Sep, 2012

38