Shri G.S.

Institute of Technology & Science Indore

Department of Computer Engineering

Session 2010-2011 SOFTWARE ENGINEERING PROJECT REPORT ON BANK MANAGEMENT SYSTEM

SUBMITTED TO: Ms. Sonika Tomar

SUBMITTED BY: Ritubala kachhwahe(AB 34059) Sonam Rawat(AB34076)

ACKNOWLEDGEMENT

We would like to take this opportunity to express our gratitude to all those who helped us in this project, especially our guide Ms. Sonika Tomar for her valuable guidance and experience. Her persistent encouragement, everlasting patience and invaluable inspiration helped us a lot in moulding the present shape of the project. We are grateful to our college authority for enabling us to complete this project. We are also thankful to our college library for providing us with adequate information on this subject.

INDEX
SERIAL NO TOPIC Introduction 1.1 Purpose 1.2 Project Scope 1.3 DevelopersResponsibilities General Characteristics 2.1 Product Functions Overview 2.2 Users of Project 2.3 General Assumptions Specific Requirements 3.1 Functional Requirements 3.2 External Interface Requirements 3.3 System Requirements: 3.3.1 Software 3.3.2 Hardware 3.4 Non-functional Requirements 3.4.1 Reliability 3.4.2 Maintainability 3.4.3 Robustness 3.4.4 Security 3.5 Feasibility Analysis 3.5.1 Technical 3.5.2 Temporal 3.6 Use-Case Diagram 3.7 DFD (level 0,1,2) Design 4.1 High level design(Structure chart) 4.2 Detailed design 4.2.1System Overview 4.2.2Design Considerations 4.2.2.1Assumptions 4.2.2.2General Constraints 4.2.2.3Goals and Guidelines 4.2.3System Architecture 4.2.4Policies and Tactics 4.2.5Detailed System Design Coding Principles Testing PAGE NO. REMARKS

1.

2.

4-5

3.

6-12

4.

26-35

5. 6.

36-37
3

INTRODUCTION

PURPOSE:The purpose of this System is to develop software application to assist a airline with transactions related to making ticket reservations, which includes reserving, canceling,updating and rescheduling tickets. Minimizing repetitive work done by the system administrator and employee. Reducing effort and frustration for travelers in scheduling a trip,especially by reducing the search effort for the flight they need to take.The final objective of the project is to meet the requirements of its customers.

PROJECT SCOPE:As todays customer is tending towards comfort.He want to do all his works only sitting in his home.Thus this type of systems has a huge scope in the present and the future.Since it has built for customers comfort.Thus in todays busy life schedule this system is very much useful and efficient.

DEVELOPERS RESPONSIBILITES:The main Responsibility of a software developer is to fully analyze the problem and gather the required information about the customers requirements concerning the system.And to develop a system which is cost effective, reliable and secure from both customer and the organisations viewpoint.The developer must be capable to complete the project within given schedule.The main responsibility of developer is to develop the project in such a way that it is compatible with different environment and any future modification in the project must be feasible.

GENERAL CHARACTERISTICS

PRODUCT FUNCTIONS OVERVIEW:The major functionalities provided by the project are Reservation for a particular destination. Cancelling the reservation Updating different details for eg. Personal details,Filght related details. View status of any flight Rescheduling flights in case of delay etc.

USERS OF PROJECT:All the users who are authenticated and have basic knowledge to deal with computer system and the internet can be the users of the project.

GENERAL CONSTRAINTS:The computer system must have required memory space available in it for storing database etc. The system must have Visual Basic installed in it. The ARS is an independent application.The facility for the interface with any other application is not provided. The way of payment is through debit card only

GENERAL ASSUMPTIONS AND DEPENDANCIES:It is a domestic based airline reservation system. There is no division of seats ( Business class/First Class/Executive Class). No meal is provided during the journey.

SPECIFIC REQUIREMENTS FUNCTIONAL REQUIREMENTS:1.The system must be capable of identifying the customer,employee and the administrator for security purpose. 2.The system must handle databases in order to avoid any redundancy and inconsistencies. 3.Once the user has done the reservation it must provide a unique PNR number.
5

4.Proper updation must be done in the databases in case if any changes done by administrator or employee or some delay in the schedule. 5.Proper checks must be applied in case of cancellation,updation etc.For eg. At the time of cancellation it must ask for customers PNR number,match it with existing database information,if it matches only in that case he must be able to proceed.

EXTERNAL INTERFACE REQUIREMENTS:User Interfaces:The interface must be easy to understand. The user interface includes: SCREEN FORMATS/ORGANIZATION:- The very first interface to the user asks him whether he is a customer,an employee or and administrator. If Employee logs in then the next window provides him with different options like reservation,cacellation,updation and other authenticated work options. If administrator logs in it must be given with the options of updation flight status and analyzing different databases. If Customer logs in it must provide options for reservation,cancellation,updation,view flight status etc. WINDOW FORMAT/ORGANIZATION:- When user selects one of the options given to him another window get opened either regarding options or information.The user can jump on the next window only after fulfilling all the requirements of the present window or he can go back to previous window according to his requirement. DATA FORMAT:- The data must be entered in particular format by the user.The data entered must be in alphanumeric. END MESSAGES:-If any wrong information is entered by the user then proper error messages must be displayed which gives information to the user about his mistakes in the in the form fill-up.It must again ask for the same details from the customer.For e.g. if wrong PNR number is entered then it display proper message.

Hardware Interfaces:The system must basically support certain input and output devices. Their s are as follows. Name of Description of Purpose Item Key board To accept data from user like PNR number, personal details, flight details etc.. Printer To print the bookings mode E.g.: Destination chosen with date and timings etc. Source of Input/ Destination of output Source of Input Destination of Output

Software Interfaces:Not applicable since the product under considerations is an independent one.

DESIGN CONSTRAINTS
SOFTWARE CONSTRAINTS:Based completely on Windows functionality platform. The software should be portable and must be inaccessible to unauthorized users.

HARDWARE CONSTRAINTS There must be required memory space available on disk for storing the Keyboard and printer must be there for taking input and providing output. ACCEPTANCE CRITERIA:1.The project must be easy to use. 2.The project must complete in given budget and given schedule. 3.The project must fulfill all the requirements specified by its users.

databases.

NON-FUNCTIONAL REQUIREMENTS:Reliability:The ARS must be reliable in the sense that if multiple users log in then in this case consistency must be maintained i.e. changes to the database must be atomic. 2. The ARS should be available for 24 hours in a day.

Maintainability:-

At the time of developing the project,this requirement is also taken care.Since the system uses small number of resources thus its maintainance is not so much critical. Enough disk space must be available since the databases are expanding with time continuously. We must explain the functioning of the project properly to the user so that its maintaince becomes easier to him. Robustness:-. ARS shall be robust enough to have a high degree of fault tolerance. For example, if the user enters a negative number of passengers or a value too large, the system should not crash and shall identify the invalid input and produce a suitable error message. ARS shall be able to recover from hardware failures, power failures and other natural catastrophes and rollback the databases to their most recent valid state.
8

Security:1. Only system administer has the right to change system parameters, such as pricing policy etc. The system should be secure and must use encryption to protect the databases. 2. User needs to be authenticated before having access to any personal data.

FEASIBILITY ANALYSIS:Technical:The ARS must be feasible in given technical facilities.It must use the present hardware for its proper functioning.No additional requirement must be there. Present equipment must be sufficient to built the project. Temporal:The project must be feasible in given time limits.A particular time schedule is given to the developer and he must be able to complete the project within the given time limits.This comes under temporal feasible. Economical:The project must be feasible in given cost.The project must be financially feasible.No any loss will be there in developing the project.

4.DESIGN:

Detailed design
4.2.1 SYSTEM OVERVIEW Provide a general description of the software system including its functionality and matters related to the overall system and its design
1.Reservation-:customer can book a flight according to its requirements. 2.Cancellation-:if he 3.Updation 9

a)in regarding to customers personal information b) in regarding to flights related information 4. flight status -: to clarify the status of flight

AIRLINE RESERVATION SYSTEM

TRANSACTI ON

ADD FLIGHT

REMOVE FLIGHT

ENQUIRY

RES ERV

CAN CELL A

UP DAT IO

F.N O

ADD

F.N O

RE MO VVE

I/P PNR NO

DB

10

4.2.2 DESIGN CONSIDERATIONS: ASSUMPTIONS AND CONSTRAINTS

Describe any assumptions or dependencies regarding the software and its use. These may concern such issues Following are strictly needed in development of the project

software and hardware-:

Microsoft Visual Basic(6.O) Microsoft Access 2007

Operating systems--:Operating system should be compatible with all the operations provided by the system.
End-user characteristics -: End user must have a basic idea of the all application softwares to operate it in Convenient way. Possible and/or probable changes in functionality-: General constraints Describe any global limitations or constraints that have a significant impact on the design of the system's software . Such constraints may be imposed by any of the following End-user environment -: In user system should installed all required software Availability or volatility of resources-: Interoperability requirements Interface/protocol requirements-: The first interface to the user that is in general a login prompt must asks him whether he is a customer ,an employee or an administrator. because different tasks and option are provided to different kind of interactors When user selects one of the options given to him another window get opened either regarding options or information.The user can jump on the next window only after fulfilling all the requirements of the present window or he can go back to previous window according to his requirement.

Security requirements (or other such regulations) There is some specific user name and password is provided to Each kind of user, if anyone wants to use the system he must be authenticated firstly, not allowed any unauthorized user. Memory and other capacity limitation The system which uses the software to be developed should have a sufficient memory to keep the databases consistently And for future expands.

Goals and guidelines :

Describe any goals, guidelines, principles, or priorities which dominate or embody the design of the system's software. Such goals might be:
11

Tha goal of design and design engineering is to produce a model or representation that exhibits firmness,commodity and Delight. Design should be in such a manner that can help in further coming stages. Emphasis on speed versus memory use. To accomplish this a designer must practice diversification and convergence . Design engineering for computer software changes

SYSTEM ARCHITECTURE
This section should provide a high-level overview of how the functionality and responsibilities of the system were partitioned and then assigned to subsystems or components. This Airline Reservation system basically works on data centered architecture. We use a centered database in which all information regarding to flights ,customers and other neccsary information are kept .this information is accessed frequently by other components for mak ing reservation Deletion and updation.

This section should provide a high-level overview of how the functionality and responsibilities of the system were partitioned and then assigned to subsystems or components. This Airline Reservation system basically works on data centered architecture. We use a centered database in which all information regarding to flights ,customers and other neccsary information are kept .this information is accessed frequently by other components for mak ing reservation. 1.A design must exihibit an architecture that (a) has been created using recognizable architectural styles or patterns (b)is composed of components that exhibit good design characteristics (c)can be implemented in an evolutionary fashion 2.A design should be modular 3.A design should contain distinct representation of data,architecture,interfaces and components. 4.A design should lead to use of proper data structures and exhibit independent functional characteristics.

12

Policies and tacties

Describe any design policies and tactics that do not have sweeping architectural implications i.e. they would not significantly affect the overall organization of the system and its high-level structures but which nonetheless affect the details of the interface and implementation of various aspects of the system.
Choice of which specific product to use (compiler, interpreter, database, library, etc. ...) * Engineering trade-offsoding guidelines and conventions *The protocol of one or more subsystems, modules, or subroutines *The choice of a particular algorithm or programming idiom (or design pattern) to implement *portions of the system's functionality *Plans for ensuring requirements traceability *Plans for testing the software *Plans for maintaining the software *Interfaces for end-users, software, hardware, and communications *Hierarchical organization of the source code into its physical components (files and directories). How to build and/or generate the system's deliverables (how to compile, link, load, etc. ...)

5.CODING PRINCIPLES Coding principles helps us to maintain good coding practice along with concrete product development. Coding principles also helps us to write excellent quality of code with huge difference to overall performance and scalability of your application. Following are the most important Coding Principles which can save a lot for us when we are writing quality application for the client. Ensuring these coding principles we can save development time, management time and conquer lots of other bottlenecks which generally arise in later development phases. a)Dont Repeat Yourself (DRY) The concept here is that anything we use in our code should have a single, unambiguous representation. This means if we are storing a number, only store it in a single place. Multiple representations are also a great way to generate bugs if we forget to change some of them. This also applies to code; dont repeat chunks of code that do the same thing have a single version and put it in a function. b)Test as you write As much as possible, test the code as we write it. These tests will often be quick and easy ones, such as checking that the value of pi were using is really what it should be, but if you perform these little checks while youre working on that piece of code, youll save yourself a lot more effort having to come back later and fix bugs. Youll find that you can perform a lot of simple tests very quickly as you go along; once youre in the habit, you really dont spend a lot of time doing it. c)Reduce dependencies as much as possible A dependency is a connection between two chunks of code, for example, using the same variable, and the more of these your code has, the more things you have to keep track of. When writing and debugging a chunk of code, the last thing we want is arbitrary other chunks being able to interact with it, because itll very quickly become unmanageable. Much better would be for each chunk of code to be highly decoupled from the rest of the code, with only very specific connections to the rest of the program. d)Validate your data At some point, someone will feed garbage into our carefully crafted code. In fact, part of our testing should be feed garbage input into your code to check that it recognises it! If your code is validating the
13

data it is given then it should be able to deal intelligently with this that is to tell the user what has gone wrong and why. Assertions are an ideal way to make the program stop as soon as something is wrong. They work by asserting that something is true and if it isnt then the program stops. e)Handle errors nicely Asserts are a great way of validating data and are very useful during development, however once a program is in the hands of the users you want your error handling to be a little nicer than stopping the program immediately. There is nothing more frustrating than a program that just dies without warning or explanation. Most modern languages have support for handling problems your code encounters using Exceptions. Exceptions are generated when something goes wrong and bubble up until they are caught and dealt with. f)Keep It Simple The simpler your code is, the easier it is to construct and maintain. So, subject to the constraints of our objectives, the simpler you can make your code the better. This has a connection to premature optimisation because optimised code tends to be less simple. g)Tidy up after yourself Once you start to leave one or two things unfixed, it becomes much easier to leave just one more, and soon your code is a wreck. There should not be a single error in the code youre building .The upadation should be done as soon as possible. h)Learn new tools We should have more than one tool. In general, you want to have a good, broad selection of tools with which to write your code. A good way to acquire this is to try to learn the occasional new tool as you go along. These can be useful pieces of software, new techniques or whatever; the important thing is that it gives you at least one more good option for writing your code. i)Dont program by coincidence Programming by coincidence is what happens when you just get started coding without thinking about what it is you actually want to achieve. To avoid this, realise that a bit of planning and careful thought (including as the project progresses) is a very good thing. j)Code entropy Disordered code is bad, because its more likely to contain bugs. Higher entropy is more disordered which is bad. So you should try to keep the entropy of your code as low as possible. This means taking care to keep things neat and tidy as you write the code. It also means fixing bugs and refactoring messy bits of code.

6.TESTING: TEST SUITE: COLLECTION OF TEST CASES:

TEST CASE 1:

FOR LOGIN FORM: INPUT: Login name,Password REQUIREMENT:The login name and password should be appropriate as defined in the code. CONDITION 1:Login Name should be the same as in the code and corresponding password should be provided. EXPECTED OUTPUT:Successful login has been done by the user. CONDITION 2:Login Name same but password doesnt match. EXPECTED OUTPUT:Login cant be done. CONDITION 3:Login name and password both donot match as given in the code.
14

EXPECTED OUTPUT: Login cant be done. TEST CASE 2: FOR : INPUT: Account Number ,Amount to be withdrawn REQUIREMENT: Balance should be greater than Rs. 1000 CONDITION 1: If Balance >= 1000 EXPECTED OUTPUT : The balance is reduced by an amount that is entered by the customer and it receives that amount. CONDITION 2: If Balance < 1000 EXPECTED OUTPUT : The transaction cannot be done successfully. TEST CASE 3: FOR CANCELLATION OF A FLIGHT INPUT : PNR no REQUIREMENT:It should be match with user stored P.N.R. NO and never less than zero. CONDITION 1 : If customer provide appropriate PNR NO. EXPECTED OUTPUT : The CANCELLATION has bee done successfully . CONDITION 2 : If PNR NO entered is a negative number or not matched with customers stored one. EXPECTED OUTPUT : The transaction cannot be done successfully. TEST CASE 4: --ADMIN TASK TO ADD A NEW FLIGHT: INPUT:new flight no REQUIREMENT:flight no should be unique and not clash with previous one. CONDITION 1:If flight no is unique EXPECTED OUTPUT:successfully added new flight CONDITION 2:If flight no is not EXPECTED OUTPUT:Check Book is not issued to client

15