Record Finance net System

8/6/2019 Record Finance net System

http://slidepdf.com/reader/full/record-finance-net-system 1/61

FINANCE MANAGEMENT SYSTEM

DONE AT

CCSIT, PUDUKAD

Submitted in partial fulfillment of the requirement for the award of degree of

MASTER OF COMPUTER APPLICATIONS

Project R eport

Submitted by

VIDYA RAVINDRAN Reg.No:CPAIMCA025

CENTRE FOR COMPUTER SCIENCE AND INFORMATION

TECHNOLOGY

UNIVERSITY OF CALICUT

PUDUKAD, THRISSUR

KERALA

UNIVERSITY OF CALICUT



DECLARATION

I, VIDYA RAVINDRAN(Reg No:CPAIMCA025) here by declare that the entire

work embodied in this dissertation has been carr ied out by me and no part of it has been

submitted f or any degree or di ploma of any institution previously .This project work is

FINANCE MANAGEMENT SYSTEM submitted in Centre For Computer Science And

Information Technology ,Pudukad is a record of or iginal work done by me under the

su per vision and guidance of Mr s.DIVYA, lecturer in CCSIT Pudukad.

VIDYA RAVINDRAN

Place :

Date :



ACKNOWLEDGEMENT

A part f rom the eff orts of me, the success of this project depends largely on the encour agement

and guidelines of many other s. I would like to take this opportunity to express my sincere

gr atitude to all people who make me to com plete this project successfully through their timely

guidance, help and su pport.

.It is great pleasure f or me to acknowledge the assistance and contr ibutions to Miss.

Dhanya M.V, Associate coordinator, CCSIT, Pudukad f or her prom pt and timely help in the

official clear ances and valuable suggestions dur ing the development of this project.

I am highly gr ateful to my project guide Mr s.DIVYA ,Lecturer of CCSIT ,Pudukkad

who had given valuable suggestions and encour agements f or the successful com pletion of the

project.

A part f rom those mentioned here, I have to thank many other s who have directly or

indirectly helped me in the com pletion of this project. Without their cooper ation this project

would not have been possible.

Finally, yet im portantly, I express my heartiest gr atitude to Almighty god, my Parents,

f r iends f or their love and blessings to com plete the project successfully.

Sincerely,

VIDYA RAVINDRAN



SYNOPSIS

The project µFinance Management System¶ aims the com puter ization

of existing manual system and fulfills the needs of user s. This is used to manage all tr ansactions

in systematic way. High s peed, accur acy and secur ity are main o b jectives of this project. This

project consists of var ious functions of the financing system. This project involves var ious

oper ations like account open, deposit, withdr awal, loan issuing, loan closing etc.

This system is gener ally classified into three modules:

Initial Setup

Transaction

Gold loan

The descr i ption of each module is given below:

Initial setu p module contains account open entr y and interest setting oper ations.

Tr ansaction module contains deposit entr y and withdr awal entr y oper ations.

Gold loan module contains gold loan lending, gold loan repayment and gold loan closing

oper ations.

The project µFinance Management System¶ is designed and developed in Windows

environment by using Visual Basic 6.0 as f ront end and Oracle as back end.

.

.



CONTENTS

1.Introduction

1.1 Project profile

2.System analysis

2.1 Existing system

2.23 Proposed system

2.3 Need f or com puter ization

2.4 Feasibility study

3.System s pecification

3.1Sof tware s pecification

3.2Hardware s pecification

4.System design

4.1 Table design

4.2.EER Diagr am

4.3Dataf olwdiagr am

4.4 Class diagr am

4.5Usecase diagr am

4.6Sequence Diagr am

4.7 Activity diagr am



5.Coding

5.1 Features of the language

5.2 Functional descr i ption

6.Testing

6.1 Introduction to testing

6.2 Levels of testing

7.Im plementation

8.Future enhancement

9.Conclusion

A ppendix

Bibliogr a phy



1.INTRODUCTION

1.1 PROJECT PROFILE

.This all help the management to maintain details regarding the sof tware,hardware that

have,been installed in the system and to helped to tr ack . When the need ar ises the management

may know the exact configur ation of the system.This sof tware will give su pport to manage

systems in a fir m easily by an administr ator . The project µFinance Management System¶ aims

the com puter ization of existing manual system and fulfills the needs of user s. This is used to

manage all tr ansactions in systematic way. High s peed, accur acy and secur ity are main

o b jectives of this project. This project consists of var ious functions of the financing system. This

project involves var ious oper ations like account open, deposit, withdr awal, loan issuing, loan

closing etc.

This project contains three modules as:

Initial Setup

Transaction

Gold loan

The Initial Setu p module has two oper ations. They are:

ACCOU NT OPEN ENTRY

INTEREST SETTING

ACCOU NT OPEN ENTRY: Here a new account is opens f or a customer . Customer

details are stores into acc_open_entr y table and issues an account number to the

customer .

INTEREST SETTING: Here an interest r ate is set f or each account ty pe. The details are

stored into inst_ set table.



The tr ansaction module has two oper ations. They are:

deposit entr y

withdr awal entr y

DEPOSIT ENTRY: This is use f or depositing amount into an account. We enter s

account no, deposit date, deposit amount etc f or this purpose. The details are stores in the

deposit_entr y table.

WITHDRAWAL ENTRY: This is use f or withdr awing amount f rom an account.

Account no, withdr awal date, withdr awal amount etc are enter s into the withdr aw _entr y

table.

The gold loan module has three oper ations. They are:

gold loan lending

gold loan repayment

gold loan closing

GOLD LOAN LENDING: This is the process of issuing gold loan to a customer .

Account no, loan no, loan f rom date, loan to date, item details etc are enter s into the

gold_loan_lend and gold_loan_ item tables.

GOLD LOAN REPAYMENT: This is the process of repaying the gold loan. Loan no,

repayment date, repayment amount etc are stores into the gold_loan_close table.

The project µFinance Management System¶ is designed and developed in Windows

environment by using Visual Basic 6.0 as f ront end and Oracle as back end



2.SYSTEM ANALYSIS

System Analysis is the detailed study of the var ious oper ations per f or med by the system

and their relationshi ps within and outside the system. Analysis is the process of break ing

something into its parts so that the whole may be under stood. System analysis is concerned with

becoming aware of the pro blem, identifying the relevant and most decisional var iables, analyzing

and synthesizing the var ious factor s and deter mining an optimal or at least a satisfactor y

solution. Dur ing this a pro blem is identified, alternate system solutions are studied and

recommendations are made about committing the resources used to design the system

System Analysis is the process of gather ing and interpreting facts and diagnosing pro blems

and using the inf or mation to recommend im provements on the system. System Analysis is a

pro blem solving activity that requires intensive communication between the system user s and the

system developer s. System Analysis or Study is an im portant phase of any system development

process. The system is studied to the minute, detailed and analyzed. System Analyst plays the

role of an interrogator and dwell deep into the work ing of the present system. The system is

viewed as a whole and the inputs to the system is identified.

A detailed study of this process must be made by var ious techniques like inter views,

questionnaires, etc. The data collected f rom var ious sources must scr utinize to arr ive to a

conclusion. The conclusion is an under standing of how the system functions. This system is

called the Existing System.

Now the existing system is sub ject to close study and pro blem areas

are identified. The designer functions as a pro blem solver and tr ies to sort out the difficulties that

the enterpr ise faces.



Here in this project, a detailed study of the existing system is carr ied along with all the

steps in the system analysis. An idea of creating a better project was carr ied out and the next

steps were f ollowed.

2.1 EXISTINGSYSTEM

Existing system ref er s to the system that is being f ollow till now. Presently all the work are

done manually, where data are stored in pa per files.. They handle many files regarding the

detailes of a customer s. The situation is ver y difficult to maintain . The manual process take a

lot of time and there is a chance of error occurrence. A lot of com plexity is involved in var ious

oper ations like search, calculation of interest etc when the number of customer and loans are

increased Maintain all files is s pace and time consuming. For getting details about the systems

we want search diff erent departments .Movement management is also a time consuming

process.

LIMITATIONS OF EXISTING SYSTEM

Lack of accur acy.

Com plexity of calculations.

Needs a huge amount of stor age s pace.

Human eff ort is high.

Error s may occur because of manual calculation.

Data secur ity is not fully guar antee

.



2.2 PROPOSED SYSTEM

The proposed system should be ca pable of overcoming the pro blems in the present system. The

proposed system is the com puter ized ver sion of existing system. It should satisfy the needs of the

end user .All the requirement should be considered while developing the new system. The new

system should be easy to incorpor ate changes.The user should be able to make changes without

any difficulty at any time.All the f eatures are available online this will help the admin to check it

when he is outside the organization. The system is easy and user f r iendly.We can check about the

system ver y easily.

This system involves var ious financial oper ations like account opening, deposit and withdr awal

entr y, gold loan lending, gold loan repayment and closing.We can easily search the details of

customer s.When a new customer is introduced, his details are stored efficiently and accur ately .

ADVANTAGES OF PROPOSED SYSTEM

R es ponse time can be greatly im proved.

Com plex calculations can done more easily and accur ately.

R educe error s and s peed u p the processing.

Less stor age s pace is required.

Data entr y and retr ieval is more easy.

Less human eff ort.

Ensure data integr ity and minimize data redundancy



2.3 NEED FOR COMPUTERISATION

The existing system is time consuming. Adding and deleting details according to

the changes is ver y difficult. The over all maintenance by the administr ator is a difficult

jo b. Giving su pport request to the vender s also need many pa per work s. It is difficult to

manage all the activities. Workload is ver y high f or the officials. They cannot get any

idea about the system if they are outside the organization. It is ver y time consuming one

to keep var ious records and to search var ious inf or mation. It will provide accur acy. It

will avoid high degree of human error s.It will s peedu p your activities. Time consuming

system.

2.4 FEASIBILITY STUDY

A f easibility analysis usually involves a thorough assessment of the oper ational(need),

financial and technical as pects of a proposal. Feasibility study is the test of the system proposal

made to identify whether the user needs may be satisfied.

using the current sof tware and hardware technologies, whether the system will be cost eff ective

f rom a business point of view and whether it can be developed with the given budgetar y

constr aints. A f easibility study should be relatively chea p and done at the earliest possible time.

Depending on the study, the decision is made whether to go ahead with a more detailed analysis.

When a new project is proposed, it nor mally goes through f easibility assessment.

Feasibility study is carr ied out to deter mine whether the proposed system is possible to develop

with available resources and what should be the cost consider ation. Facts considered in the

f easibility analysis were.

y Technical Feasibility



y Economic Feasibility

y Behavior al Feasibility

2.4.1 Technical Feasibility

Technical Feasibility deals with the hardware as well as sof tware requirements.

Technology is not a constr aint to ty pe system development. We have to find out whether the

necessar y technology, the proposed equi pments have the ca pacity to hold the data, which is used

in the project, should be checked to carr yout this technical f easibility.

The technical f easibility issues usually r aised dur ing the f easibility stage of

investigation includes these

y This sof tware is r unning in windows 2000 O per ating System, which can be easily

installed.

y The hardware required is Pentium based ser ver .

y The system can be expanded.

2.4.2 Economical Feasibility

This f easibility study present tangible and intangible benefits f rom the pref ect by

com par ing the development and oper ational cost. The technique of cost benefit analysis is of ten

used as a basis f or assessing economic f easibility. This system needs some more initial

investment than the existing system, but it can be justifiable that it will im prove quality of

ser vice.

Thus f easibility study should center along the f ollowing points:

Im provement resulting over the existing method in ter ms of accur acy, timeliness.

Cost com par ison



Estimate on the lif e expectancy of the hardware

Over all o b jective

Our project is economically f easible. It does not require much cost to be involved in the over all

process. The over all o b jectives are in easing out the requirement processes.

2.4.3 Operational Feasibility

This analysis involves how it will work when it is installed and the assessment of

political and manager ial environment in which it is im plemented. People are inherently resistant

to change and com puter s have been known to facilitate change. The new proposed system is ver y

much useful to the useful to the user s and there f or it will accept broad audience f rom around the

world.



3. SYSTEM SPECIFICATION

The system s pecification descr ibes the s pecifies the requirements f or a system and the methods

to be used to ensure that each requirement has been met. The hardware and sof tware should be

configured based on the system s pecification. The proper configuar ation of the com plete system

optimizes the per f or mance of the system.

3.1 SOFTWARE REQUIREMENTS

In order to im plement a new system,the choice of a processor with maximum possible s peed is

made.There should be sufficient memor y to store data and sof tware tools f or efficient processing.

O per ating System : Windows 2000/XP/other higher Windows ver sions

Front-End : MICROSOFT VISUAL BASIC 6.0

Back-End : MS SQL SERVER 2005

3.2HARDWARE SPECIFICATION

In order to im plement a new system the choice of a processor with

maximum possible s peed is made. There should be sufficient memor y to store data and sof tware

tools f or efficient processing.

The selection of hardware is ver y im portant in the existence and proper work ing of any sof tware.

When selecting hardware, the size and requirements are also im portant.

Processor : Pentium III or above

Processor S peed : Minimum 1.0 GHz,R ecommended:

: 2.0 GHz or faster

Pr imar y memor y(cache memor y) : Minimum 512MB.R ecommended



: 2.0 GB or More

Secondar y memor y : Minimum 5 GB or above

Pher i pher als : Mouse,K eyboard

Hard Disk Ca pacity : 20GB or Above

CD ROM Dr ive : 52 X RW

Monitor : SVGA Color



4.SYSTEM DESIGN

DEFINITION

The most creative and challenging face of the system development is System Design. It

provides the under standing and procedur al details necessar y f or im plementing the system

recommended in the f easibility study. Design goes through the logical and physical stages of

development.

In designing a new system, the system analyst must have a clear under standing of the

o b jectives, which the design is aiming to fulfill. The fir st step is to deter mine how the output is to

be produced and in what f or mat. Second, input data and master files have to be designed to meet

the requirements of the proposed output. The oper ational phases are handled through progr am

constr uction and testing.

Design of a system can be defined as a process of a pplying var ious techniques and

pr inci ples f or the purpose of defining a device, a process or a system in sufficient detail to per mit

its physical realization. Thus system design is a solution to ³how to´ a pproach to the creation of

a new system. Thus im portant phase provides the under standing and the procedur al details

necessar y f or im plementing the system recommended in the f easibility study. The design step

provides a data design, architectur al design, and a procedur al design .

4.1 DATABASE DESIGN

Table design ref er s to outside the logical data str uctures are to be physically stored in the stor age

device. Table design also deals with the design of physical database. A key field deter mines how

the access Is to be im plemented. Suitable key fields are identified var ious tables and are coded

a pproximately. The ty pe, width and size of the fields are identified The designing of the tables in



INTEREST SET TABLE

FIELD TYPE CONSTRAINT

ACC _ NAME VARCHAR2(20)

INST _ RATE NUMBER

DEPOSIT ENTRY TABLE


ACC _ NO NUMBER FOREIGN KEY

DEPT _ NO NUMBER PRIMARY KEY

DEPT _ DATE VARCHAR2(25)

DEPT _ AMT NUMBER

TOT _ BAL NUMBER



WITHDRAW ENTRY TABLE



WITHDRAW _ NO NUMBER PRIMARY KEY

WITHDRAW _ DATE VARCHAR2(25)

WITHDRAW _ AMT NUMBER

CUR _ BAL NUMBER

GOLD LOAN LEND TABLE


LOAN _ NO NUMBER PRIMARY KEY


LOAN _ FROM _ DATE VARCHAR2(25)

LOAN _ TO _ DATE VARCHAR2(25)

TOT _ WEIGHT NUMBER

TOT _ AMT NUMBER



GOLD LOAN ITEM TABLE


LOAN _ NO NUMBER FOREIGN KEY

ITEM _ NAME VARCHAR2(15)

ITEM _ COU NT NUMBER

GRAM NUMBER

GOLD LOAN REPAY TABLE



LOAN _ REPAY _ DATE VARCHAR2(25)

REPAY _ AMT NUMBER

INST _ AMT NUMBER

OTHER _ AMT NUMBER

TOT _ AMT NUMBER

BAL _ AMT _ REPAY NUMBER



GOLD LOAN CLOSE TABLE



LOAN _ CLOSE _ DATE VARCHAR2(25)

CLOSE _ AMT NUMBER

INST _ AMT NUMBER

OTHER _ AMT NUMBER

4.2 ER DIAGRAM

An entity-relationshi p (ER ) diagr am is a s pecialized gr a phic that illustr ates the interrelationshi ps

between entities in a database. ER diagr ams of ten use symbols to represent three diff erent ty pes

of inf or mation. Boxes are commonly used to represent entities. Diamonds are nor mally used to

represent relationshi ps and ovals are used to represent attr ibutes.

Also K nown As: ER Diagr am, E-R Diagr am, entity-relationshi p model

ER DIAGRAM



4.3 DATA FLOW DIAGRAM

A data flow diagram (DFD) is a gr a phical representation of the "f low" of data through

an inf or mation system. DFDs can also be used f or the visualization of data processing (str uctured

design).

There are var ious symbols used in a DFD. Bubbles represent the processes. Named

arrows indicate the data f low. External entities are represented by rectangles and are outside the

system such as vendor s or customer s with whom the system inter acts. They either su pply or

consume data. Entities su pplying data are known as sources and those that consume data are

called sink s. Data are stored in a data store by a process in the system. Each com ponent in a DFD

is labeled with a descr i ptive name. Process names are further identified with a number .

DFD¶s can be hier archically organized, which help in partitioning and analyzing large

systems. As a fir st step, one DFD can depict an entire system, which gives the system over view.

It is called Context Diagr am of level 0 DFD. The Context diagr am can be further expanded. The

successive expansion of a DFD f rom the context diagr am to those giving more details is known

as leveling of DFD. Thus a top down a pproach is used, starting with an over view and then

work ing out the details.

The main mer it of DFD is that it can provide an over view of what data a system would

process, what tr ansf or mation of data are done, what files are used, and where the results f low.



DATA FLOW DIAGRAM

Context diagr am (Level0)



level1



level2



4.4 Class Diagram

In the Unified Modeling Language (UML), a class diagr am is a ty pe of static str ucture

diagr am that descr ibes the str ucture of a system by showing the system's classes, their

attr ibutes, and the relationshi ps between the classes. It represents the static view of an

a pplication. Class diagr am is not only used f or visualizing, descr ibing and documenting

diff erent as pects of a system but also f or constr ucting executable code of the sof tware

a pplication. The class diagr ams are widely used in the modelling of o b ject or iented systems

because they are the only UML diagr ams which can be ma pped directly with o b ject or iented

languages. The class diagr am shows a collection of classes, inter faces, associations,

collabor ations and constr aints. It is also known as a str uctur al diagr am.



ACCOUNT

# ACC NO: INT

+ ACC NAME: STRING

+ CUST NAME: STRING

+ ACC BAL: INT=0

+WITHDARW()

+DEPOSIT()

#UPDATED BAL()

BRANCH

+ BRANCH_NO: INT

+ ADDRESS:STRING

TRANSACTION

+ DATE: DATEACCOUNT TYPE

+ ACC NAME: STRING

+ INTEREST RATE: INT

+ PERIOD: INT

GOLD LOAN

+ ITEM_NAME: STRING

+ ITEM_COUNT: INT

+ GRAM: INT

+ GOLD LOAN LEND()

+ REPAYMENT()

+ CLOSE()

CUSTOMER EMPLOYEE

PERSON

+ NAME: STRING

ORGANIZATION UNIT

ACC HOLDER

# EMP ID: INT + ADDRESS: STRING

CLERK *

MANAGER

0..1

*

*

0..1

SUBDIVISION

WORKS_FOR

0..1*

1..2



4.5 Use Case Diagram

A use case is a set of scenar ios that descr ibing an inter action between a user and a

system. A use case diagr am dis plays the relationshi p among actor s and use cases. A use case

diagr am in the Unified Modeling Language (UML) is a ty pe of behavior al diagr am defined byand created f rom a Use-case analysis. Its purpose is to present a gr a phical over view of the

functionality provided by a system in ter ms of actor s, their goals (represented as use cases), and

any dependencies between those use cases. The main purpose of a use case diagr am is to show

what system functions are per f or med f or which actor . R oles of the actor s in the system can be

depicted. Use Case diagr ams are f or mally included in two modeling languages defined by the

OMG: the Unified Modeling Language (UML) and the Systems Modeling Language (SysML).

In RTPMS modeling Usecase diagr am shows the inter actions of Administr ator , Manager and

User with the system separ ately and ver y clearly. The inter action between the system and its

user s helps to under stand the requirements.

.



CLERK

ACCOUNT OPEN

ENTRY

INTEREST

SETTING

DEPOSIT

ENTRY

WITHDRAWAL

ENTRY

GOLD LOAN

LENDING

GOLD LOAN

REPAYMENT

GOLD LOAN

CLOSING

GOLD LOAN

OFFICER

CUSTOMER



4.6 Sequence Diagram

A sequence diagr am in Unified Modeling Language (UML) is a k ind of inter action

diagr am that shows how processes oper ate with one another and in what order . It is a constr uct of

a Message Sequence Chart. Sequence diagr ams are sometimes called event diagr ams, event

scenar ios, and timing diagr ams. Sequence diagr ams demonstr ate the behavior of o b jects in a use

case by descr ibing the o b jects and the messages they pass. Sequence diagr ams gener ally show

the sequence of events that occur . In FMS sequence diagr ams s pecifies the diff erent events that

occur dur ing the login of each user . These sequence diagr ams descr ibes the events that occur

f rom the login to logout of each user according to their status whether he is an em ployee, or

customer . Each sequence diagr am has its own purpose.

login customer AccountGold loanwithdr awalDeposit

Account

Commit

Commit

Commit

Gold loan

withdrawal

Deposit

time

invalid login



4.7 Activity Diagram

Activity diagr am is another im portant diagr am in UML to descr ibe dynamic as pects of the

system. Activity diagr am is basically a f low chart to represent the f low f or m one activity to

another activity. The activity can be descr ibed as an oper ation of the system. So the control f low

is dr awn f rom one oper ation to another . This f low can be sequential, br anched or concurrent.

Activity diagr ams deals with all ty pe of f low control by using diff erent elements like f ork ,

join.etc. It does not show any message f low f rom one activity to another . Activity diagr am is

some time considered as the f low chart. Although the diagr ams look s like a f low chart but it is

not. It shows diff erent f low like par allel, br anched, concurrent and single.

start

No

valid login

yes

stop

v

Customer approaches

office

Employee login

Choice menu

Account open

entryDeposit Withdrawal Gold loan

Proceed transaction



5.CODING

Visual Basic 6.0 (Front End )

Like the BASIC progr amming language, Visual Basic was designed to be easily learned and

used by beginner progr ammer s. The language not only allows progr ammer s to create sim ple GUI

a pplications, but can also develop com plex a pplications. Progr amming in VB is a combination of

visually arr anging com ponents or controls on a f or m, s pecifying attr ibutes and actions of those

com ponents, and wr iting additional lines of code f or more functionality. Since default attr ibutes

and actions are defined f or the com ponents, a sim ple progr am can be created without the

progr ammer having to wr ite many lines of code. Per f or mance pro blems were exper ienced by

earlier ver sions, but with faster com puter s and native code com pilation this has become less of

an issue.

For ms are created using dr ag-and-drop techniques. A tool is used to place controls (e.g., text

boxes, buttons, etc.) on the f or m (window). Controls have attr ibutes and event handler s

associated with them. Default values are provided when the control is created, but may be

changed by the progr ammer . Many attr ibute values can be modified dur ing r un time based on

user actions or changes in the environment, providing a dynamic a pplication Alternatively, a

Visual Basic com ponent can have no user inter face, and instead provide ActiveX o b jects to other

progr ams via Com ponent Ob ject Model (COM).

This allows f or ser ver-side processing or an add-in module.

In addition to catching error s on the f ly, Visual Basic also partially com piles the code as it is

entered. When you are ready to r un and test your a pplication, there is only a br ief delay to finish

com piling. If the com piler finds an error , it is highlighted in your code. You can fix the error and

continue com piling without having to start over . Because of the inter active nature of Visual

Basic, you'll find your self r unning your a pplication f requently as you develop it. This way you

can test the eff ects of your code as you work r ather than waiting to com pile later .



ABOUT THE DATABASE:

ABOUT SQL

SQL is a relational database management system.A relational database

management system stores data in the f or m of multi ple related tables.It consist of user databases

created by administr ator s f or stor ing and retr ieving data used by database client and system

database that store the inf or mation needed f or SQL Ser ver , enabling it to actual function.

SQL*Plus is an Or acle command-line utility progr am that can r un SQL and PL/SQL commands

inter actively or f rom a scr i pt.

SQL*Plus oper ates as a relatively sim ple tool with a basic command-line inter face.

Progr ammer sand DBAs commonly use it as the default available fundamental inter face in almost any Or acle

sof tware installation.

The Oracle Database (commonly ref erred to as Oracle RDBMS or sim ply as Oracle) is an

o b ject relational database management system (ORDBMS)[ produced and marketed by Or acle

Corpor ation. SQL is a database access, nonprocedur al language. User s descr ibe in SQL what

they want done, and the SQL language com piler automatically gener ates a procedure to navigate

the database and per f or m the desired task .

IBM R esearch developed and defined SQL, and ANSI/ISO has refined SQL as the standard

language f or relational database management systems.The minimal conf or mance level f or SQL-

99 is known as Core. Core SQL-99 is a su per set of SQL-92 Entr y Level s pecification. Or acle9i is

broadly com patible with the SQL-99 Core s pecification.

Or acle SQL includes many extensions to the ANSI/ISO standard SQL language, and Or acle tools

and a pplications provide additional statements. The Or acle tools SQL*Plus and Or acle

Enterpr ise Manager let you r un any ANSI/ISO standard SQL statement against an Or acle

database, as well as additional statements or functions that are available f or those tools.

Or acle SQLJ lets a pplications progr ammer s embed static SQL oper ations in Java code in a way

that is com patible with the Java design philosophy. A SQLJ progr am is a Java progr am



containing embedded static SQL statements that com ply with the ANSI-standard SQLJ

Language R ef erence syntax.

Although some Or acle tools and a pplications sim plify or mask SQL use, all database oper ations

are per f or med using SQL. Any other data access method circumvents the secur ity built into

Or acle and potentially com promise data secur ity and integr ity



6.TESTING

6.1 INTRODUCTION TO TESTING

The test cases gener ated f or and executed on ³Finance Management System´. A real-time

system is one in which the correctness of the com putations not only depends u pon the logical

correctness of the com putation but also u pon the time at which the result is produced. If the

timing constr aints of the system are not met, system failure is said to have occurred. Test cases

are evaluated independent of one another , having no eff ect on the evaluation of the other test

cases.

Sof tware testing can also be stated as the process of validating and ver ifying that a

sof tware progr am/a pplication/ product:

1. meets the business and technical requirements that guided its design and

development;

2. work s as expected; and

3. can be im plemented with the same char acter istics.

Sof tware testing, depending on the testing method em ployed, can be im plemented at any

time in the development process

Dur ing testing if a test case fails, then testing will be sus pended f or all the related

modules of the test case. A log will be prepared where in the error will be reported along with the

descr i ption.



6.2 LEVELS OF TESTING

Unit testing

Unit testing ref er s to tests that ver ify the functionality of a s pecific section of code, usually at

the function level. In an o b ject-or iented environment, this is usually at the class level, and the

minimal unit tests include the constr uctor s and destr uctor s. These ty pe of tests are usually

wr itten by developer s as they work on code (white- box style), to ensure that the s pecific function

is work ing as expected. One function might have multi ple tests, to catch corner cases or other

br anches in the code. Unit testing alone cannot ver ify the functionality of a piece of sof tware, but

r ather is used to assure that the building block s the sof tware uses work independently of each

other . Unit testing is also called com ponent testing.

Integration Testing

Integration testing is any ty pe of sof tware testing that seek s to ver ify the inter faces between

com ponents against a sof tware design. Sof tware com ponents may be integr ated in an iter ative

way or all together ("big bang"). Nor mally the f or mer is considered a better pr actice since it

allows inter face issues to be localized more quickly and fixed. Integr ation testing work s to

expose def ects in the inter faces and inter action between integr ated com ponents (modules).

Progressively larger grou ps of tested sof tware com ponents corres ponding to elements of the

architectur al design are integr ated and tested until the sof tware work s as a system

Validation Testing

Enter ing incorrect values does the validation testing and it is checked whether the

error s are being considered. Incorrect values are to be discarded and the error s are rectified.

Validation will alert the user about the ty pe of data and the null ability of data. Alpha testing is

where the end user tests the system r ather than the developer , but in a controlled

environment. The sof tware is used on a natur al setting with the developer monitor ing the

user using the system. The developer records the error s and usage pro blems encountered

by the user . Af ter the integr ation testing, sof tware is com pletely assembled as a pack age.



Sof tware validation is achieved through a ser ies of black box tests that demonstr ates conf or mity

with requirements.

System Testing

System tests are test designed to ver ify that the finished system meets its requirements. The

purpose of this step is to test the system under realistic condition. It is a combination of diff erent

testing exists recover y testing, secur ity testing, per f or mance testing and stress testing. Testing

per f or med in two ways.-white box testing and black box testing. White box testing is a test case

design method that used the control str ucture of the procedur al design to deliver the test cases.

Black box testing was conducted f or each of the modules and all of them were established to

work properly. . For user acceptance testing, the system was given to the end user to

use. The error s f ound are rectified.

Output Testing

Af ter per f or ming the validation testing, the next step is the output testing of the sof tware.

Since no system could be useful, if it does not produce the required output in the s pecified

f or mat. Ask ing about the f or mat required by them tests the output gener ated or dis played by the

system under consider ation. It¶s real testing phase where the inter faces are evaluated.

GUI Testing

GUI sof tware testing is the process of testing a product that uses a gr a phical user

inter face, to ensure it meets its wr itten s pecifications. This is nor mally done through the use of a

var iety of test cases. Most clients in client/ser ver and we b- based systems deliver system

functionality using a gr a phical user inter face (GUI). When testing com plete systems, the tester

must gr a pple with the additional functionality provided by the GUI. GUIs make testing systems

more difficult f or many reasons: the event-dr iven nature of GUIs, unsolicited events, many ways

in/many ways out and the infinite input domain pro blems make it likely that the progr ammer has

introduced error s because he could not test ever y path.



To gener ate a µgood¶ set of test cases, the test designer must be certain that their suite

cover s all the functionality of the system and also has to be sure that the suite fully exercises

the GUI itself . The difficulty in accom plishing this task is twof old: one has to deal with

domain size and then one has to deal with sequences. In addition, the tester faces more

difficulty when they have to do regression testing.

There are many levels of testing have to be done bef ore im plementing the system.

Unit testing is done here with the MDI main window load by check ing the accur acy of timing

constr aints, loading logos, proper dis play of the subsequent window f or ms.

Module testing is also done with proper test cases.

The inter face testing done with validating the inputs in each text box as required and check ing

proper messages and tool ti ps are provided in a r ight way or not.

Per f or mance testing is the one in which check ing f or the proper events are ha ppening in a r ight

way or not.

Here in the FMS im plementation, the var ious levels of testing remove most of the error s and

irrelevant entr ies to the system. And the validation of the system is also ver y im portant. Bef ore

going to im plement the whole system in to the client area the demo sof tware have to be r un with

the sam ple inputs f rom a r andom number gener ator



IMPLEMENTATION

A cr ucial phase in the system lif e cycle is the successful im plementation of the new

system design. Im plementation includes all those activities that take place to convert f rom the

old system to the new one. The new system may be com pletely new replacing an existing manual

or automated system or it may be im plementation becomes necessar y so that a reliable system

based on the requirements of the clients can be provided. Successful im plementation may not

guar antee im provement in the organization using the new system. But im proper installation will

prevent it. It has been o bser ved that even the best system cannot show good results if the analyst

managing the im plementation do not attend to ever y im portant detail.

The im plementation and maintenance is the last phase of Sof tware Development Lif e

Cycle. Af ter testing is per f or med, that is checked whether the system work s properly, by putting

realistic data items, the system is im plemented in the clients com puter .

Here is the most im portant part that is user tr aining. The work ing of the system is

explained to the user . The main o b jective of this part is that the user can able to under stand the

diff erent process. Only the external work ing is explained to the user , and not the internal logic.

Then check to see whether the im plemented system satisfies the user 's var ious needs.

The ma jor steps f or im plementation are

Installation of hardware if required.

Installation of newly developed sof tware into hardware at the work site.

Tr aining to the user s.

Demonstr ation of all user s by enter ing a test data and tak ing the output .

Prepar ation and distr ibution of oper ational manual.

The new system may be totally new, replacing an existing system or it

may be the modification to the existing system. In either case proper im plementation is essential

to provide a reliable system to meet the organizational requirements.

Maintenance is necessar y to eliminate error s in the work ing system dur ing its work ing

lif e. Af ter a system is successfully im plemented, it should be maintained in a proper manner .

System maintenance is an im portant as pect in the sof tware development lif e cycle.



8. FUTURE ENHANCEMENTS

The scope f or im provements and future enhancements does exist. In the future we

can make more refined ver sions of FMS by adding new f eatures required by the management.

This a pplication is currently an open one, which promises any amount of modules to be

integr ated along with it. This means that the future is in store as as pects can be incorpor ated in

this a pplication such that this can made even more enhanced consider ing the current trends and

the developments the future might off er this is considered as an excellent system with a

promising br ight future in coming year s. New secur ity methods should be developed to avoid the

misuse of the system in wide environment.



CONCLUSION

The FINANCE MANAGEMENT SYSTEM has been developed in Microsof t Visual

Basic 6.0 and all the modules are tested and the system worked with real data successfully.

Com puter ization was proposed as solution to the pro blem of being outdated with fast present

technologies. In this project our aim is to com puter ize the system accordingly that meet the user

needs. The FINANCE MANAGEMENT SYSTEM is work ing better than the existing system

in all as pects.

All eff orts have been put to make sure that the system can handle all the requirements

efficiently. The results are o btained in a timely and consistent manner since each process is

im plemented using modules. The system is liable to further modifications and also provides easy

maintenance. We can im prove the system as when needed by wr iting functions and procedures.

By using other sof tware¶s we can make more attr active.

With the blessing of Lord Almighty, su pport of parents and family and the

immeasur able guidance of internal guide and my project coordinator , I had successfully

com pleted my project with short allotted time. This project gave us encour agement and

confidence to take such work in future



APPENDIX



FORM DESIGN

LOGIN FORM



MDI FORM-FINANCE MANAGEMENT SYSTEM



ACCOUNT OPEN ENTRY FORM (NEW ENTRY)



ACCOUNT OPEN ENTRY FORM (SEARCH)



INTEREST SETTING FORM



DEPOSIT ENTRY FORM



WITHDRAWAL ENTRY FORM



GOLD LOAN LENDIND FORM



GOLD LOAN REPAYMENT FORM



REPORTS



ACCOUNT HOLDER DETAILS



GOLD LOAN LENDING DETAILS



BIBLIOGRAPHY

TEXT BOOK

y Visual Basic .NET Black Book -- Steven Holzer

y The programming language of oracle -- Ivan Bayross

WEBSITE

y www.wik i pedia.com

Record Finance net System

Documents

Transcript of Record Finance net System