THE SPEED CASH SYSTEM

1. INTRODUCTION
1.1 OVERVIEW

The Speed Cash System is used to transfer money from one place to another within a day. This is basically used to speed up the money transfer. The necessary information for the money transfer from the source bank to the destination bank is sent in the form of file on daily basis. This file contains the information like remitter details, beneficiary details and DD (Demand Draft) details, etc. Basically the remitter is a person who sends the money and the beneficiary is the person who receives the money. If the remitter has already an account with the bank, the deduction at the back end should happen instead of cash dealings. Once the file is received, it is processed and the data is put into the database. Then it is again processed and DD is printed. The printed DD will be handed over to the concerned person.

3. ANALYSYS
3.1 SYSTEM REQUIREMENT SPECIFICATION 3.1.1 INTRODUCTION

This Project is to create an e-News and Metrics generation tool for Marketing Programs Team. This system generates and sends a newsletter to the target groups for technical awareness, new products, services, updates and security patches provided by ABC Company. The system should also generate analysis reports to improve their marketing strategies. The project has been planned to be having the view of distributed architecture, with centralized storage of the database. The application for the storage of the data has been
1

planned. Using the constructs of MS-SQL Server and all the user interfaces have been designed using the ASP.Net technologies. The database connectivity is planned using the SQL Connection methodology. The standards of security and data protective mechanism have been given a big choice for proper usage. The application takes care of different modules and their associated reports which are produced as per the applicable strategies and standards that are put forwarded by the administrative staff.

3.1.2 EXISTING SYSTEM Problem Definition It is time consuming process as the user has to type the dbase commands. He has to

remember all the commands which are difficult. It is limited to a single system. A user who wants only to have some information has to contact the administrator

every time. Using the MS-Access they are able to store only 2500 records only.

Project Objective Cyber security Division undertakes the auditing of the web sites prior to hosting on the production server. It has to perform application vulnerability assessment for the applications on the various web sites. These audits were performed for the requests submitted by various user groups / departments. The objective of the system is to automate the audit application Status Monitoring Process to speed up the workflow. Application Audit Status Monitoring System will keep track of all the websites submitted by the user group(s) and assign the audit levels to the concerned auditors to audit the site vulnerabilities. Reminders will be sent to the concerned user groups to take necessary actions on the paused audits waiting for the response.

For self assessed sites/applications state web coordinator can upload report and certificate itself, if coordination finds sites without vulnerabilities he/she can allow site clear for hosting otherwise assignment life cycles follows. Authentication and session management includes all aspects of handling user authentication and managing active sessions. Authentication is a critical aspect of this process so, allow only strong password, change password after some time and not allow old passwords. Various groups to keep track of the current status of the audited application software websites basically will use the information. 3.1.3 PROPOSED SYSTEM

The development of the new system contains the following activities, which try to automate the entire process keeping in view of the database integration approach. 1. 2. 3. 4. 5. User friendliness is provided in the application with various controls. The system makes the overall project management much easier and flexible. It can be accessed over the Internet. Vast amount of data can be stored. There is no risk of data mismanagement at any level while the project development is

under process. 3.1.4 SCOPE This Document plays a vital role in the development life cycle (SDLC) as it describes the complete requirement of the system. It is meant for use by the developers and will be the basic during testing phase. Any changes made to the requirements in the future will have to go through formal change approval process. The developer is responsible for:

1) Developing the system, which meets the SRS and solving all the requirements of the system? 2) Demonstrating the system and installing the system at client's location after the acceptance testing is successful. 3) Submitting the required user manual describing the system interfaces to work on it and also the documents of the system. 4) Conducting any user training that might be needed for using the system. 5) Maintaining the system for a period of one year after installation.

3.2

SOFTWARE / HARDWARE REQUIREMENTS

3.2.1 SOFTWARE REQUIREMENTS:

WINDOWS NT 4 | 2000 | 9.X | ME Visual Studio .Net 2002 Enterprise Edition Internet Information Server 5.0 Visual Studio .Net Framework (Minimal for Deployment)
4

SQL Server 2000 Enterprise Edition

3.2.2 HARDWARE SPECIFICATIONS

PIII 500MHZ or above 128MB RAM 100MB Free Hard disk space STD Color Monitor Network interface card or Modem (For Remote Sources)

3.3 MODULES The system after careful analysis has been identified to be presented with the following modules:

The modules involved are: 1. 2. 3.

5

Administration Accountholder Reports

4.

Authentication

3.3.1 ADMINISTRATOR

In this module the Administrator has the privileges to add information about the Bank, Branch, transaction type , Payment Mode, Country, State, City, Location. He can search all the info about the Accountholder, Bank etc... 3.3.2 ACCOUNTHOLDER

This is the person who is having his account in the particular bank. After entering his user name and password he can successfully enter in his page and see his account info, personal detail, information about the different type of transaction made by him. He can also modify his detail and can change his password. 3.3.3 REPORTS

This module contains all the information about the reports generated by the admin based on the particular Account holder, all request made by Account Holder. 3.3.4 AUTHENTICATION

This module contains all the information about the authenticated user. User without his username and password cant enter into the login if he is only the authenticated user then he can enter to his login and he can see the quotation and give the quotation for the particular products.

3.3.5 INPUTS & OUTPUTS: The main inputs, outputs and major functions of the system are as follows

Inputs: Head operator enters his or her user id and password. Operators enter his or her user id and password. Technicians enter his or her user id and password. Sub technicians enter his or her user id and password. User requests the reports. User requests the search. Head operator can edits the personal details and so on. Outputs: Head operator receives personal details. Operator receives the personal details. Technicians receive personal and technical details. Users receive requested reports. Displays search result.

ACCESS CONTROL FOR DATA WHICH REQUIRE USER AUTHENTICATION The following commands specify access control identifiers and they are typically used to authorize and authenticate the user (command codes are shown in parentheses) USER NAME (USER) The user identification is that which is required by the server for access to its

file system. This command will normally be the first command transmitted by the user after the control connections are made (some servers may require this). PASSWORD (PASS)
7

This command must be immediately preceded by the user name command, and, for

some sites, completes the user's identification for access control. Since password information is quite sensitive, it is desirable in general to "mask" it or suppress type out.

3.3.6 GUIs In the flexibility of the uses the interface has been developed a graphics concept in mind, associated through a browser interface. The GUIS at the top level have been categorized as 1. 2. Administrative user interface The operational or generic user interface The administrative user interface concentrates on the consistent information that is practically, part of the organizational activities and which needs proper authentication for the data collection. The interfaces help the administrations with all the transactional states like Data insertion, Data deletion and Date updating along with the extensive data search capabilities. The operational or generic user interface helps the users upon the system in transactions through the existing data and required services. The operational user interface also helps the ordinary users in managing their own information helps the ordinary users in managing their own information in a customized manner as per the assisted flexibilities.

Project Instructions: Based on the solution requirements, conceptualize the Solution Architecture.

Depict the various architectural components, show interactions and connectedness and show internal and external elements. Discuss suitability of typical architectural types like Pipes, Filters, Event Handlers, and Layers etc.
8

Identify the significant class entities and carry out class modeling.

Carry out Detailed design of Classes, Database objects and other solution

components. Distribute work specifications and carry out coding and testing.

3.4

FUNCTIONAL REQUIREMENTS

3.4.1 OUTPUT DESIGN Outputs from computer systems are required primarily to communicate the results of processing to users. They are also used to provide a permanent copy of the results for later consultation. The various types of outputs in general are:
9

External Outputs, whose destination is outside the organization,. Internal Outputs whose destination is within organization and they are the Users main interface with the computer. The outputs should be defined in terms of the following points:

operational outputs whose use is purely within the computer department. Interface outputs, which involve the user in communicating directly with

3.4.2 OUTPUT DEFINITION Type of the output Content of the output Format of the output Location of the output Frequency of the output Volume of the output Sequence of the output

It is not always desirable to print or display data as it is held on a computer. It should be decided as which form of the output is the most suitable. For Example: Will decimal points need to be inserted Should leading zeros be suppressed. Input Media: In the next stage it is to be decided that which medium is the most appropriate for the output. The main considerations when deciding about the output media are:
10

The suitability for the device to the particular application. The need for a hard copy.

The response time required. The location of the users The software and hardware available. Keeping in view the above description the project is to have outputs mainly coming

under the category of internal outputs. The main outputs desired according to the requirement specification are: The outputs were needed to be generated as a hot copy and as well as queries to be viewed on the screen. Keeping in view these outputs, the format for the output is taken from the outputs, which are currently beeing obtained after manual processing. The standard printer is to be used as output media for hard copies.

3.4.3 INPUT DESIGN Input design is a part of overall system design. The main objective during the input design is as given below: To produce a cost-effective method of input. To achive the highest possible level of accuracy. To ensure that the input is acceptable and understood by the user.

INPUT STAGES: The main input stages can be listed as below:

11

 Data recording Data transcription Data conversion Data verification Data control Data transmission Data validation Data correction

INPUT TYPES: It is necessary to determine the various types of inputs. Inputs can be categorized as follows: External inputs, which are prime inputs for the system. Internal inputs, which are user communications with the system. Operational, which are computer departments communications to the system? Interactive, which are inputs entered during a dialogue. INPUT MEDIA:

12

At this stage choice has to be made about the input media. To conclude about the input media consideration has to be given to; Type of input Flexibility of format Speed Accuracy Verification methods Rejection rates Ease of correction Storage and handling requirements Security Easy to use Portability Keeping in view the above description of the input types and input media, it can be said that most of the inputs are of the form of internal and interactive. As Input data is to be the directly keyed in by the user, the keyboard can be considered to be the most suitable input device. ERROR AVOIDANCE At this stage care is to be taken to ensure that input data remains accurate form the stage at which it is recorded up to the stage in which the data is accepted by the system. This can be achieved only by means of careful control each time the data is handled. ERROR DETECTION
13

Even though every effort is make to avoid the occurrence of errors, still a small proportion of errors is always likely to occur, these types of errors can be discovered by using validations to check the input data. DATA VALIDATION Procedures are designed to detect errors in data at a lower level of detail. Data validations have been included in the system in almost every area where there is a possibllity for the user to commit errors. The system will not accept invalid data. Whenever an invalid data is keyed in, the system immediately prompts the user and the user has to again key in the data and the system will accept the data only if the data is correct. Validations have been included where necessary. The system is designed to be a user friendly one. In other words the system has been designed to communicate effectively with the user. The system has been designed with pop up menus. USERINTERGFACE DESIGN It is essential to consult the system users and discuss their needs while designing the user interface: USER INTERFACE SYSTEMS CAN BE BROADLY CLASIFIED AS: 1. User initiated interface the user is in charge, controlling the progress of the

user/computer dialogue. In the computer-initiated interface, the computer selects the next stage in the interaction. 2. Computer initiated interfaces In the computer initiated interfaces the computer guides the progress of the user/computer dialogue. Information is displayed and the user response of the computer takes action or displays further information. USER_INITIATED INTERGFACES User initiated interfaces fall into tow approximate classes:
14

1.

Command driven interfaces: In this type of interface the user inputs

commands or queries which are interpreted by the computer. 2. choice. COMPUTER-INITIATED INTERFACES The following computer initiated interfaces were used: 1. The menu system for the user is presented with a list of alternatives and the Forms oriented interface: The user calls up an image of the form to his/her

screen and fills in the form. The forms oriented interface is chosen because it is the best

user chooses one; of alternatives. 2. Questions answer type dialog system where the computer asks question

and takes action based on the basis of the users reply. Right from the start the system is going to be menu driven, the opening menu displays the available options. Choosing one option gives another popup menu with more options. In this way every option leads the users to data entry form where the user can key in the data. ERROR MESSAGE DESIGN: The design of error messages is an important part of the user interface design. As user is bound to commit some errors or other while designing a system the system should be designed to be helpful by providing the user with information regarding the error he/she has committed. This application must be able to produce output at different modules for different inputs.

3.5 FEASIBILITY STUDY

15

Feasibility is an important phase in the software development process it enables the developers to have an assessment of the product being developed. It refers to the feasibility study of the product in terms of outcomes of the product, operational use and technical support required for implementing it. Feasibility study should be performed on the basis of various criteria and parameters. The various feasibility studies are: Economic Feasibility Technical Feasibility Operational Feasibility 3.5.1 ECONOMIC FEASIBILITY It refers to the benefits or outcomes we are deriving from the product as compared to the total cost we are spending for developing the product. If the benefits are more or less the same as the older system then it is not feasible to develop the product. The product is economical feasible. The scs provides the following benefits to mandamusOrg Name

Reduces the processing time. Reduces the work load.

3.5.2 TECHNICAL FEASIBILITY The system is self-explanting and does not need any entire sophisticated training. A system has been built by concentrating on the graphical uses interface concepts, the application can also be handled very easily with a novice uses. The overall time that a user needs to get trained is less than 15 minutes. The system has been added with features of menu device and button interaction methods, which makes him the master as he starts working through the environment. As the

16

software that were used as developing this application are very economical and are readily available is the market the only time that is lost by the customer is just installation time. 3.5.3 OPERATIONAL FEASIBILITY It refers to the feasibility of the product to be operational. Some products may work very well at the design and implementation but many fail in the real time environment. It introduces the study of human resources required and their technical expertise. This product is operationally feasible as it is designed specifically for scs project name. This provides consistent and integrated data management. It also provides information at all levels of people.

4. DESIGN
4.1 GENERAL DEVELOPMENT METHODOLOGY SDLC Waterfall Model
The Software Development Life Cycle is a logical systematic process used to develop software and information systems through planning, analysis, design, implementation and support. Through these five steps softwares are built that both satisfy a user's needs and meet a company's expectations.

The five traditional steps to the Software Development Life Cycle are: Planning

17

This initial phase starts by defining the need. The purpose of the planning phase is to identify clearly the nature and scope of the business opportunity or problem by performing a preliminary investigation.

Analysis
In the analysis phase we get further information about what the users want and build more in-depth models of what they can expect to achieve with their new system. Design This is when the project really starts to take form. Engineers plan out all the inputs, outputs, interfaces, processes for the project and create the system design specification from this data. Implementation The implementation phase is the phase in which the customer gets to see more than just documents describing their system. The engineers and designers construct the new system and begin testing it and documenting it.. Then after everyone is satisfied that the system is ready they will install the product and convert the customers existing format over to the new version. And the customer does a final evaluation to determine if the system is working as they expected and if that the costs and benefits are as they had planned.

Support In this, the final phase, the team maintains the system and updates it as necessary to keep up to date with its environment. The staff will also fix minor flaws in the program that were not caught in the other phases. Sometime after the project reaches the support phase the customer will decide that it is time for another upgrade of their system, which restarts the process again.

18

Fig 4.1.a. SDLC Life Cycle Model

The relationship of each stage to the others can be roughly described as a waterfall, where the outputs from a specific stage serve as the initial inputs for the following stage.

Fig4.1.b. Waterfall Model

4.2 SYSTEM DESIGN

19

Systems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements

4.2.1 DATA FLOW DIAGRAMS

A data flow diagram is graphical tool used to describe and analyze movement of data through a system. These are the central tool and the basis from which the other components are developed. The transformation of data from input to output, through processed, may be described logically and independently of physical components associated with the system. These are known as the logical data flow diagrams. The physical data flow diagrams show the actual implements and movement of data between people, departments and workstations. A full description of a system actually consists of a set of data flow diagrams. Using two familiar notations Yourdon, Gane and Sarson notation develops the data flow diagrams. Each component in a DFD is labeled with a descriptive name. Process is further identified with a number that will be used for identification purpose. The development of DFDs is done in several levels. Each process in lower level diagrams can be broken down into a more detailed DFD in the next level. The lop-level diagram is often called context diagram. It consists a single process bit, which plays vital role in studying the current system. The process in the context level diagram is exploded into other process at the first level DFD. The idea behind the explosion of a process into more process is that understanding at one level of detail is exploded into greater detail at the next level. This is done until further explosion is necessary and an adequate amount of detail is described for analyst to understand the process. Larry Constantine first developed the DFD as a way of expressing system requirements in a graphical from, this lead to the modular design. A DFD is also known as a bubble Chart has the purpose of clarifying system requirements and identifying major transformations that will become programs in system design. So it is the starting point of the design to the lowest level of detail. A DFD consists of a series of bubbles joined by data flows in the system.
20

DFD SYMBOLS In the DFD, there are four symbols 1. A square defines a source (originator) or destination of system data 2. An arrow identifies data flow. It is the pipeline through which the information flows 3. A circle or a bubble represents a process that transforms incoming data flow into outgoing data flows. 4. An open rectangle is a data store, data at rest or a temporary repository of data Process that transforms data flow.

Source or Destination of data Data flow

Data Store

21

CONSTRUCTING A DFD Several rules of thumb are used in drawing DFDs: 1. Process should be named and numbered for an easy reference. Each name should be representative of the process. 2. The direction of flow is from top to bottom and from left to right. Data Traditionally flow from source to the destination although they may flow back to the source. One way to indicate this is to draw long flow line back to a source. An alternative way is to repeat the source symbol as a destination. Since it is used more than once in the DFD it is marked with a short diagonal. 3. When a process is exploded into lower level details, they are numbered. 4. The names of data stores and destinations are written in capital letters. Process and dataflow names have the first letter of each work capitalized A DFD typically shows the minimum contents of data store. Each data store should contain all the data elements that flow in and out. Questionnaires should contain all the data elements that flow in and out. Missing interfaces redundancies and like is then accounted for often through interviews. SAILENT FEATURES OF DFDs 1. The DFD shows flow of data, not of control loops and decision are controlled

considerations do not appear on a DFD. 2. The DFD does not indicate the time factor involved in any process whether the

dataflows take place daily, weekly, monthly or yearly. 3. The sequence of events is not brought out on the DFD.

TYPES OF DATA FLOW DIAGRAMS 1.

22

Current Physical

2. 3. 4.

Current Logical New Logical New Physical

CURRENT PHYSICAL In Current Physical DFD process label include the name of people or their positions or the names of computer systems that might provide some of the overall system-processing label includes an identification of the technology used to process the data. Similarly data flows and data stores are often labels with the names of the actual physical media on which data are stored such as file folders, computer files, business forms or computer tapes. CURRENT LOGICAL The physical aspects at the system are removed as mush as possible so that the current system is reduced to its essence to the data and the processors that transform them regardless of actual physical form. NEW LOGICAL This is exactly like a current logical model if the user were completely happy with he user were completely happy with the functionality of the current system but had problems with how it was implemented typically through the new logical model will differ from current logical model while having additional functions, absolute function removal and inefficient flows recognized. NEW PHYSICAL The new physical represents only the physical implementation of the new system. RULES GOVERNING THE DFDS PROCESS 1)
23

No process can have only outputs.

2) sink. 3)

No process can have only inputs. If an object has only inputs than it must be a

A process has a verb phrase label.

DATA STORE 1) Data cannot move directly from one data store to another data store, a process

must move data. 2) Data cannot move directly from an outside source to a data store, a process, which

receives, must move data from the source and place the data into data store 3) A data store has a noun phrase label.

SOURCE OR SINK The origin and /or destination of data. 1) 2) Data cannot move direly from a source to sink it must be moved by a process A source and /or sink has a noun phrase land

DATA FLOW 1) A Data Flow has only one direction of flow between symbol. It may flow in both directions between a process and a data store to show a read before an update. The later is usually indicated however by two separate arrows since these happen at different type. 2) A join in DFD means that exactly the same data comes from any of two or more

different processes data store or sink to a common location. 3) A data flow cannot go directly back to the same process it leads. There must be at

least one other process that handles the data flow produce some other data flow returns the original data into the beginning process. 4) 5)
24

A Data flow to a data store means update (delete or change). A data Flow from a data store means retrieve or use.

A data flow has a noun phrase label more than one data flow noun phrase can appear on a single arrow as long as all of the flows on the same arrow move together as one package.

Login DFD

Login Master

Open Login form

Enter User Name and Password

Yes

Check User

Yes

User Home Page

No
Validates Data

Admin Functionalities

25

Login A ccount D etails

Open Form () 1.0.0 M anage C ustom ers 1.0.2

C us tom ers D etails

M anage Em ployees 1.0.4

Em ployee D etails

Log out

Enter Login D etails 1.0.1

Manage Bank and Transactions 1.0.3

Bank D etails Verifies D ata Validates D ata

Customer Registration

Bank Details

Account Types

Manage Customers 1.2.1

Enter Customer Id and Name 1.2.2

Enter Bank Id 1.2.3

Enter Address 1.2.4

Enter Account Type 1.2.5

Validates Data

Validates Data

Validates Data

Enter User Name and Password

Enter Email Id

Enter Min Balance 1.2.7

Submit

Customer Details

1.2.5

1.2.6

Admin Employee Registration

26

Bank Details

Manage Employees 1.4.1

Enter Emp Id and Name 1.4.2

Enter Branch Id 1.4.3

Enter Address 1.4.4

Enter Date of Joining 1.4.5

Validates Data

Validates Data

Validates Data

Enter User Name and Password

Enter Email Id

Enter DOB 1.4.7

Submit

Employee Details

1.4.5

1.4.6

4.2.2 USE CASE DIAGRAMS

27

 The unified modeling language allows the software engineer to express an analysis model using the modeling notation that is governed by a set of syntactic semantic and pragmatic rules. A UML system is represented using five different views that describe the system from distinctly different perspective. Each view is defined by a set of diagram, which is as follows. User Model View i. ii. users perspective. This view represents the system from the users perspective. The analysis representation describes a usage scenario from the end-

Structural model view In this model the data and functionality are arrived from inside the system. This model view models the static structures.

Behavioral Model View It represents the dynamic of behavioral as parts of the system, depicting the interactions

of collection between various structural elements described in the user model and structural model view.

Implementation Model View In this the structural and behavioral as parts of the system are represented as they are to

be built.

Environmental Model View

28

In this the structural and behavioral aspects of the environment in which the system is to

be implemented are represented.

SYSTEM NAME UML is specifically constructed through two different domains they are

UML Analysis modeling, which focuses on the user model and structural model views

of the system? UML design modeling, which focuses on the behavioral modeling, implementation
Use case 1

modeling and environmental model views.

Use case 2

Actor

Actor

Use case n

Use case Model USE CASE FOR ADMIN ACTIVITIES

29

Lg o in R g te C s m rs e is r u to e

M n g C s m rs a a e u to e

T n a tio s ra s c n A m istra r d in to R p rts eo

Sa h e rc

Mn g Bn s aae ak L gO t o u

CUSTOMER ACTIVITIES

R g te e is r Lg o in

U d teP oile pa r f s

T n a tio s ra s c n C s mr u to e S tu ta s

S ac erh

R q e ts eus L gO t o u

30

4.2.3 CLASS DIAGRAMS

31

4.2.4 SEQUENCE DIAGRAMS

Sequence Diagrams Represent the objects participating the interaction horizontally and time vertically. SEQUENCE FOR USER LOGIN

leader

: A count H c older

theC k hec

:C k hec

bank : B ank

giveR elaventInfo

(U ernam s e Inform ation

, P sw as ord

validateU ser C onfirmY es

() /N o

If Y es () G C ive onfirm ation G oes to P age w M sage ith es

If N () G C o ive onfirm ation G e M age iv ess

SEQUENCE FOR GETTING BALANCE INFORMATION

32

their : Bank

leader : Account Holder

account : CheckingAccount

Balance Lookup : Real

Retrive Account (accountno.) Account

getbalance () balance

setValue () balance

SEQUENCE FOR INSERTING TRANSACTION

bn ak

: Bn ak

th C e k e hc

: Cek hc

ac u t co n

: C ek g co n h c in A c u t

Cs Cek ah h c

(th C e k e hc

g tA o n e mu t a on mu t

()

g tB la c e a ne b la c a ne

()

a d D ra s c n d D T n a tio

(N m e u br

, A on mu t

T n a tio A d d ra s c n d e

a d h q e ra s c n d C e u T n a tio

(N m e u br

, A on mu t

T n a tio A d d ra s c n d e

C s In rm tio a h fo a n

4.2.5 COLLABORATION DIAGRAMS

33

User Login

Data Base

Home 3 : Invalid() 5 : Request() Validate 7 : Home()

2 : Validate Data()

4 : Get Back()

6 : Response()

Login

1 : Login()

User

34

Administrator Register Customers

Data Base 3 : Invalid() 5 : Storage()

Validate

2 : Validate Data() Custom er

4 : Get Back()

1 : Register()

Adm inistrator

Customer Transactions

35

3 : V ate A c u t() alid co n

A c u t In c o n fo

D B se ata a

6 : S rag to e() V ate alid 4 : In valid () 2 : S th D et e etails() File

5 : In valid A o n D ta cc u t e ils()

1 : S dT sa n en ran ctio ()

C sto e u mr

36

4.2.6

ACTIVITY DIAGRAMS

ACTIVITY FOR USER LOGIN

User Enters Username and Password

Rejected System Displays Error Message Accepted User Interact with System

37

ACTIVITY FOR ADDING ACCOUNT HOLDER

User views all Account Holder Info

Click on Add Account Holder

User give all the relavent Info

Click on Submit and Stored in Database

ACTIVITY FOR UPDATE ACCOUNT HOLDER INFO

38

User Select Account Holder ID

System Display Entire Account Holder Info

User Modify Required Fields

Click on Submit and Record is Updated in Database

ACTIVITY FOR DELETING ACCOUNT HOLDER INFO

39

User Select Account Holder ID

System Display Entire Account Holder Info

User Delete the Required Record

Record is Deleted from Database

ACTIVITY FOR SEARCHING ACCOUNT HOLDER INFO

40

User S elect A ccount Holder ID

Click on S earch Button for the Record

Data Not Retrived System Display M essage Data Retrived Display Relavent Data in the G ridView

ACTIVITY FOR ADDING DD INFORMATION ON ACCOUNT HOLDER

41

U e v s a D In s r iew ll D fo

C k o A d D In lic n d D fo

S le t A c u t H e ID e c c o n old r

U e giv all th re v n In fo D Tra a tio sr e e la e t fo r D ns c n

C k o S m a d S re in D ta as lic n ub it n to d a b e

ACTIVITY FOR ADDING CHEQUE INFORMATION ON ACCOUNT HOLDER

42

U e v w a C e u In s r ie s ll h q e fo

C ko A dC e u In lic n d h q e fo

S le t A c u t H ld r ID e c co n o e

U e g ea th re v n In fo C e u T n a tio s r iv ll e la e t fo r h q e ra s c n

C ko S b it a dS re inD ta a e lic n u m n to d a bs

4.2.7

E-R DIAGRAMS

43

The relation upon the system is structure through a conceptual ER-Diagram,

which not only specifics the existential entities but also the standard relations through which the system exists and the cardinalities that are necessary for the system state to continue. The entity Relationship Diagram (ERD) depicts the relationship between the data objects. The ERD is the notation that is used to conduct the date modeling activity the attributes of each data object noted is the ERD can be described resign a data object descriptions. The set of primary components that are identified by the ERD are Data object Relationships Attributes Various types of indicators. The primary purpose of the ERD is to represent data objects and their relationships.

44

45

4.2.8 CONTEXT DIAGRAM

Administrator
Database

Account Holder

Search

Speed Cash System

Report

Authentication

4.2.9 DATA DICTIONARY:

46

Data Dictionary is a catalog a repository of elements in the system. These elements center on data and the way they are structured to meet requirements and organizational need. Analysis use data dictionaries for the following reasons: To manage details of large system. To communicate a common meaning for all system elements. To document the features of the system.

Speed Cash System City Details

Country Details

Location
47

State Detail

Account Status Master

Account Type

Admin Login

48

Bank Branch

Bank Detail

Beneficiary Detail

Branch wise Service

Credit Card
49

Cust Account Detail

Login History

Logout History
50

Customer Detail

Customer Security Detail

Customer Detail

Debit Card Detail

51

Demand Draft

Designation Detail

Emp Master

Feed Back

52

File Process

Fund Transfer Detail

Remitter

Role Master

53

Service Type Detail

Trans Type Details

User Login

7. CONCLUSION
54

The project has been appreciated by all the users in the organization. It is easy to use, since it uses the GUI provided in the user dialog. User friendly screens are provided. The usage of software increases the efficiency, decreases the effort. It has been efficiently employed as a Site management mechanism. It has been thoroughly tested and implemented.

8. FUTURE SCOPE OF THE PROJECT

55

 system.

As the system is scalable, more modules can be added as and when required The database that is used in the system can be connected to the patient information

It can be browser independent so that the site can be opened in any browser. The system contents can be modified to accept new attributes for any criterion.

56