Table of Contents S.No 1.

CONTENTS Introduction Problems with the current system Proposed System Diagrammatical representation of proposed system Feasibility of the product Software model used Programming language used 2. Requirements Analysis Requirements Elicitation 3. 4. Project Metrics Risk Analysis Risk Mitigation, monitoring and management. 5. 6. Software quality assurance Detailed Analysis Analysis Modeling Entity Relationship Diagram (ERD) Level 0 DFD for proposed system Level 1 DFD for proposed system Level 2 DFD for proposed 12 14 16 18 19 20 21 22 23 27 28 29 PAGE NUMBER 4 5 6 7 9 10 11

system Process Specifications (PSPEC) Process activation table (PAT) Data Dictionary Design Concepts 7. 8. 9. Software Coding Software Testing Bibliography

30

31 47 51

PRELIMNARY ANALYSIS

INTRODUCTION Banking system is an advanced software package specifically designed to simplify bank account keeping. It is implemented with the objective to computerize the handbook account maintenance system. It is useful for small branch of a bank.

The software is so simple such that the bank staff will find account maintenance and performing transactions (with control on maintaining a minimum balance ) running in no time. The user need not be trained in using the software or have any past experience of working in the software because it is very user friendly and easy to use. All account details i.e transaction, customer details, and monthly interest is assembled and displayed in easy to read files, which can be customized to viewing preference. They display as much or as little information needed. The software also generates a monthly report on the new accounts opened in a month. This software aims at reducing the workforce, management and clerical task. It increases the relibility and portability of the database storage.

PROBLEM IDENTIFICATION The current manual system includes the following problem : Account maintenance as paperwork is a cumbersome task. Each transaction builds on the shortage in data maintaining space used per account. Each transaction needs access to large database making transaction slow and records difficult to maintain.

Generating monthly interest and adding it to each account manually is very difficult.

Modifying the details of customer is a large process and closing an account and reissuing the account number may lead to chaos. No backup can be maintained as the data is large and duplication of data consumes lot of time.

Large work force required to do small clerical tasks. Analysis on data and access to database tedious.

Maintaining year books requires large storage area.

PROPOSED SOLUTION The software will maintain the database of customers, their accounts and daily transactions, there by increasing the reliability in maintaining data. It would implement ease of portability of data. It would allow quick access to database. It would also generate the monthly interest automatically by refering the database. The software would implement five basic functions : 1. 2. 3. 4. 5. Open account Transaction Customer record Account inquiry List of accounts

OPEN ACCOUNT function takes the following attributes as inputs from the user and appends the new account to the list of accounts . Name Address Name of verifying person Initail Deposit Account number and date are generated automatically. TRANSACTION function takes the following input and deposits or withdraws money from the account as stated by the user and thereby appending the changes made to the account . Account number Type of transaction(deposit/withdraw) Mode of payment(cash/cheque) Transaction amount

CUSTOMER RECORD function gives two choices to the user Edit account Close account ACCOUNT INQUIRY function entertains user inquiry related to the account by displaying the detailed account information after taking the Account Number as input.

LIST OF ACCOUNTS function displays list of all the accounts in the bank. It gives following output Account number Name of account holder Current balance The software also implements the following fuctions : GENERATE INTEREST function calculates the interest to be paid monthly and adds it to the balance in each account. GENERATE REPORT function generates number of new accounts opened in a month. The report is displayed at the end of the month in the list of account function.

DIAGRAMATIC REPRESENTATION OF THE PROPOSED SYSTEM

Banking System
Transaction Open Account Customer Record Account Enquiry
Report Generation

Open Accoun
Date Account No Name Address Name of verifying person Initial Balance

Transaction

Deposit

Withdrawal

Cash

Amount

Cheque

Cash

Amount

Cheque

Customer Record

Edit Account

Close Account

FEASIBILITY OF THE PRODUCT The feasibility of the product is a question that conforms the reality to the ideas. Feasibility test is critical .The dimensions that define the feasibility of project are : ECONOMIC FEASIBILITY The cost incurred in making the software product is nothing in comparison to the amount of expenses made by the hotel to maintain the records. The cost of the software is one long time investment and its maintainability is very easy. The product being complemented by a user manual and documentation is reusable and open to new changes. TECHNICAL FEASIBILITY The software is a newly developed application so it does need any other software or hardware. The technical feasibility is high the software can be deployed on any machine having Turbo C++ Compiler. ENVIRONMENTAL FEASIBILITY The software is simple; the hotel staff will find data maintenance and performing bookings running in no time. The users need not be trained in using the software or have any past experience of working in the software because it is very user friendly and easy to use.

SOFTWARE MODEL USED The Software model used is LINEAR SEQUENTIAL MODEL because of the following reasons: Project being small demands a systematic and sequential approach to software development i.e. system engineering, software requirement analysis, design, code generation, testing and support occur in sequence. All requirements for the project have been explicitly stated at the beginning. There is very little scope of customers deviation from current requirements, coding and testing after detailed analysis is much easy.

Structure is less complex and less innovative with less need of iteration.

PROGRAMMING LANGUAGE USED The coding has been done in Turbo C++. C++ is based on the concept of OOPS (Object Oriented Paradigm) which thereby enhances the functionality of the program with many reusable components like functions etc. Also, C++ is the best choice for this project allowing easy access to what was once the daunting task of mastering the many controls and messages of the windows environment.

REQUIREMENT ANALYSIS
REQUIREMENT ELICITATION It is an approach that helps in overcoming the problem of scope , undestability and volatility of the project by providing the guidelines for requirement gathering activity in an organised manner. INITIATING THE PROCESS The objective and requirements of the software were decided upon by group discussions, interviews and meetings with the customer. This project aims at automating the database and functioning of banking system. The software would benefit the bank management in reducing the workforce and tasks for maintain the records . The user s of the software are primarily the clerical and the managerial staff FACILITTED APPLICATION SPECIFICATION TECHNIQUE (FAST) It is a work product of team of end users and software engineers that help in understanding the software demands completely by generating the following: List of Services: Opening account. Performing transactions. Managing accounts. Generating interests.

List of Constraints: The software cant run on a distributed system. Interest rate for all the types of accounts is same. List of Validation: The account numbers should be generated automatically. While opening account, name and address should not be left blank. Initial deposit should not be less than Rs500. Transaction date should be the current date.

QUALITY FUNCTION DEPLOYMENT (QFD) QFD is a quality management technique that translates the need of the customer into technical requirements for the software. It maximizes customers satisfaction by evaluating the requirements of the customer. Normal Requirements: Editing and maintenance of the customers database. Give account transaction information in the form of passbook entries. Adding interest to the account of all the customers at the end of the month. Maintaining list of all the existing accounts. Expected Requirements: Ease of installation.

 Operational correctness. User friendly. Performance. Exciting Requirements: Availability of a well documented software. Impressive graphics. Report generation at the end of each month.

USE CASE A use case for the hotel system is as follows: The hotel staff observes the main menu to select one of the following options to perform corresponding function: Check in. Check out. Room record. Customer record. Edit. Report. Help. Exit.

According to the choice entered, function is performed. If wrong choice is entered, appropriate message is displayed.

RISK ANALYSIS AND MANAGEMENT

RISK ANALYSIS & MANAGEMENT Identifying potential risks and developing a plan to mitigate, monitor and manage risks is of paramount importance. Risk analysis enables to build a risk table by providing detail guidelines in identification and analysis of risk. This is achieved by risk avoidance risk monitoring risk management and contingency plan. For our project the risk table is a s follows: Categor y Size estimate may PS be significantly low. Risks Probabilit Impa RMMM y ct 60% 2 Ensure that requirements are clearly understood. Choose appropriate sizing technique to determine the software size. 80% 2 Schedule made should be realistic and

Delivery deadline may be tightened.

BU

No. of people may be inadequate to do the job.

PS

60%

Customer will change requirements.

PS

60%

End user may resist the system.

BU

40%

achievable. Monitor that efforts put are according to schedule. Organize task network. Assign backup staff member as third party for testing and review. Update the employers regularly about the status and working assumptions. Get Customers feedback periodically Involve the end users in development of the system. Develop techniques to evoke favorable responses

from the users.

SOFTWARE QUALITY ASSURANCE (SQA) Software quality assurance claims to focus on quality tools that audit the source code to determine compliance with language standards. It is an umbrella activity, applied at each step in the software process. It identifies: Evaluations to be made.

Audit and reviews to be performed. Standards to be maintained. Error reporting and tracking. Measurement of changes made.

DATA MODELING & DESIGNS

ANALYSIS MODELLING The analysis model achieves three primary objectives: To describe what the customer requires. To establish a basis for the creation of software design. To define set of requirements that can be validated.

Entity Relation Diagram

Data Dictionary

Data Flow diagram

State- Transition Diagram

It uses a combination of text and diagrammatic form to depict requirements for data, function and behavior in a way that is relatively easy to understand and review. The following tools have been used to model the system. Entity Relationship Diagram (ERD) specifies the relationships between data objects and attribute of each data object can be described using a data object description.

Data Flow Diagram (DFD) provides an indication of how data are transformed as they move through the system. Also depicts the function that transforms the data flow. PSPEC specifies the work of each process i.e. the description of each function presented in DFD. State Transition Diagram (STD) indicates how the system behaves as the consequence of external events. Data dictionary has been used as a repository that contains description of all data objects consumed or produced by the software.

ENTITY RELATIONSHIP DIAGRAM

Bank Control System

maintai n

Accounts
Stored Transactions in

nee Customers ds

open sperform

CONTEXT LEVEL DIAGRAM

CUSTOMER

Perform transactions maintains Open accounts

ACCOUNTS DISPLAY

Adds interest

BANKING SYSTEM

Inquires account status

CONTROL (management / interest)

Command+ data

genertaes

MONTHLY reports REPORTS DISPLAY

LEVEL 1 DFD

CUSTOMER
RECORDS

Command +data Open accoun CUSTOMER

t1

Store details

data Command+data
Handle query 2 Perform Transctio n 3

Command + data

ACCOUNT DISPLA Y

get information
Modify accoun t 4 Displa y Status 6

data

store

data ACCOUNTS

Add interest
Generat e Interest 5

data

data

REPORT

command+ data

data

REPORT DISPLAY

CONTROL
LEVEL 2 DFD

command+ data

Generat e report 7

Customer

Input details

Customer Records

Deposit Minimum Initial Balance

Check Initial Balance 1.2

Customer details 1.1

Store details

status true
Generat e Account number 1.3

Store new account ACCOUNT Status true

Customer
Input account number
Find accoun t 2.1

ACCOUNTS

current balance

input deposit or withdrawal

Check type of Transactio n 2.2

Compare current balance 2.3

store balance

withdrawal
Calculate new balance 2.4

deposit PROCESS SPECIFICATION (PSPEC) Process Name: Transaction

This process helps the banking staff to perform daily transactions to the customers account as per the customers demand. Banking staff (customer command): Selects transaction from the main menu. Enters account number. if(account exists) do Display account information. Input type of transaction. If(deposit) do Input mode of transaction, amount. Calculate new balance. Store and display changes. done if(withdraw) do Input mode of transaction, amount. Calculate new balance. if(new balance > 500) do Store and display changes. done else do Exit done done done STATE TRANSITION DIAGRAM

account info Entries

Acquiring information

Info obtained Invoke data entry

validated Validating entries Error C Checking for least balance

heck for least balance Reentering info

Display error

Invalid Entry Invoke error display Appending records Suffici

ent balance ensured Updating balance Appending of record Record modified BalanceUpdation Generate interest New Accounts report

Add interest Balance Update

Balance updation Invoke

DATA DICTIONARY Name: Passbook Entries Aliases: None Where/How used: Displays transaction records (Output) Account number (Input) Description: Transaction = Date (generated automatically)+ Particular + Deposit (amount) + Withdrawal (amount)+ Interest + Balance. Particular = Initial/cash/cheque Name: List of Accounts Aliases: None Where/How used: Displays accounts (Output) Account number (Input) Description: Account = Account Number + Name of Person + Balance Balance = Amount in the account after last transaction or addition of interest.

Name: Transaction Aliases: None Where/How used: Appends the transaction records (Output) Account number (Input) Type of transaction (Input) Mode of transaction(Input) Amount (Input) Description: Type of transaction=deposit or withdrawal Mode of transaction= cash or cheque PROCESS ACTIVATION TABLE (PAT) PROCESS: TRANSACTION Input events Account no Type of transaction Amount deposited Output events: Display last balance Display new balance Process Activation: Find account Check status(deposit) Calculate new balance 0 0 1 0 1 0 1 1 1 0 1 1 1 0 0 0 0 1 0 1 0 0 1 0

 Store account

DESIGN CONCEPTS Design is a problem solving process with an objective to describe a way to implement the systems functional requirements, respecting the constraints imposed and adhereing to good quality. It has following goals: Ensuring that functionality conforms to requirements. Increasing quality such as usability, efficiency, reliability, maintainability, and reuseability.

Cohesion and Coupling A measure of extent to which related aspects of system are kept together in the same module is cohesion. Coupling defines interdependencies that exist between software modules. It implies if one needs to reuse components, one must import all the modules coupled. Understandability To build a good quality product, the design of the software should be clearly understood. Coupling and Cohesion: High Cohesion and Average Coupling make sure that to understand one component there is no need to refer to other components of the software as well. Naming: Modules are named according to the function they perform. System Documentation: Documentation is systematic, organized and easily understandable.

TESTING

TESTING Testing is done with an objective of finding most errors with minimum amount of time and effort. Unit Testing It focuses verification effort on the smallest unit of software design- the software component or module. Using the component level design description as a guide, important test paths are tested to uncover errors within the boundary of the module. The unit testing was done using white-box testing and the steps were conducted in parallel for multiple components.

WHITE BOX testing in a test case design method that uses the control structure of procedural design to derive test case. We have implemented it in the same way by deriving test cases in our source code. We made sure that all possible paths were executed at least once and excised internal data structure to ensure validity. Basic Path Testing is a White Box testing technique that enables to derive logical complexity and defines basic test of execution paths. The test cases are so prepared so that each execution path will occur at least once Cyclomatic Complexity Cyclomatic Complexity is software metric that provides a quantitative measure of the logical complexity of a program. It defines the number of independent paths in the basic set of program and provides with an upper bound for number of tests that must be conducted to ensure all statements have been tested at least once. The following steps were followed Using code as foundation, a flow graph was drawn. Cyclomatic complexity of the flow graph was calculated. Basic set of independent paths was determined. Test cases were derived. The sample code int row=6, flag ; 1 fstream file ; file.open("INITIAL.DAT", ios::in|ios::binary) ;

while (file.read((char *) this, sizeof(initial))) 2 { flag = 0 ; delay(10) ; gotoxy(7,row) ; cout <<accno ; 3 gotoxy(25,row) ; cout <<name ; gotoxy(57,row) ; cout <<balance ; row++ ; if (row == 23) 4 { flag = 1 ; row = 6 ; gotoxy(4,24) ; cout <<"Press any key to continue..." ; 5 getch() ; clrscr() ; box_for_list() ; 6 } } 8 file.close() ; FLOW GRAPH
7

1 2

R2
8

R1

R2

R3
6

The cyclomatic complexity {V (G)} is V (G) = 3regions V (G) = 9 edges - 8nodes + 2 = 3 V (G) = 2 predicate nodes + 1 = 3 Basis set of linearly independent paths path 1: 1-2-8 path 2: 1-2-3-4-7 path 3: 1-2-3-4-5-6-7

Test cases that will force execution of each path in the basis set Path 1 test case: Attempt to open & read the file which has account details i.e.INITIAL.dat. File could not be open or doesnt exist. Expected result: Nothing will be displayed on screen. Path 2 test case: File containing list of account is opened to read. Row != 23 Expected result: displays 23 rows of each page of list of account Path 3 test case: File containing list of account is opened to read. Row = 23. Expected result: displays 23 rows of each page of list of account and prints press any key to continue.. as a footer.

Graph Matrix A graph matrix is a square matrix whose size (i.e., number of rows and columns )is equal to number of nodes on the flow graph. Each row and columns corresponds to an identified node, and matrices entries correspond to connections (an edge) between nodes. Each row with two or more entries represents a predicate node.

1 2 1 3 1 4 1 5 6 7 1 8 Cyclomatic complexity 2+1=3 Loop Testing

2 1

8 1

1 1 1

Connection 11=0 2 1 = 1 11=0 21=1 11=0 11=0 1 1 =0

It is a white-box testing technique that focuses exclusively on the validity of loop constructs. Simple loops: The following set of tests was applied to simple loops, where n is the maximum number of allowable passes through the loop. 1. Skip the loop entirely 2. Only one pass through the loop 3. two passes through the loop 4. m passes through the loop where m<n 5. n-1, n, n+1 passes through the loop Concatenated loops: These loops were tested using the approach defined for simple loops because each of the loops is independent of the other.

Integration Testing Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components and build a program structure that has been dictated by design. Bottom-up Integration Bottom-up integration testing begins construction and testing with atomic modules. Because components are integrated from the bottom-up, processing required for components subordinate to a given level is always available and the need for stubs is eliminated. A bottom-up integration strategy was implemented with the following steps: 1. Low-level components are combined into clusters that perform a specific software subfunction. 2. A driver is written to coordinate test case input and output. 3. The cluster is tested. 4. Drivers are removed and clusters are combined moving upward in the program structure.

Banking system

Transaction

Query

Cluster 2

Modify Account
Cluster 1

Account display

Help

Open Account

Validation Testing Validation tries to uncover errors, but the focus is at the requirements level on things that will be immediately apparent to the end user. It is achieved through a series of black-box tests that demonstrate conformity with requirements. A test plan outlines the classes of tests to be conducted and a test procedure defines specific test cases that will be used to demonstrate conformity with requirements. Both the plan and procedure are designed to ensure that all functional requirements are satisfied, all behavioral characteristics are achieved, all performance requirements are

attained, documentation is correct, and human-engineered and other requirements are met. Black-Box Testing It is also called behavioral testing, focuses on the functional requirements of the software. It enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program.

Graph-based Testing Method

New menu select

Menu selects (Generation time <1.0 sec) Allows editing of

Open Account window

Valid input create is represented as contains

Documente d text

Create account

Each relationship in the above graph is studied separately and test cases were derived. As the test case begins, the first objective was to achieve node coverage. By this test cases demonstrate that no nodes have been inadvertently omitted and node weights (object attributes) are correct. Next, link coverage was addressed. Each relationship was tested based on its properties. Equivalence Partitioning It is a black-box testing method that divides the input domain of a program into classes of data from which test cases can be derived. It strives to define a test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed. System Testing System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. Although each test has a different purpose, all work to verify that system elements have been properly integrated and perform allocated functions. Recovery Testing Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. If recovery is automatic, reinitialization, checkpointing mechanisms, data recovery, and restart are evaluated for correctness. If recovery requires human intervention, the mean-time-to-repair (MTTR) is evaluated to determine whether it is within acceptable limits.

Bibliography

Bibliography Roger S. Pressman, Software Engineering A Practitioners Approach 5th Edition.

1.

2. Robert Lafore, Turbo C++.

3.

Pankaj Jalote, An integrated Approach to Software Engineering, 2nd Edition.