INTRODUCTION

There is an old saying that HUMAN MEANS ERROR. Especially in case of maintaining numerals, we become so serious not committing any error. Banking system is always fighting with it. Now days some banks are also maintaining their data and daily transactions through computer system. Using computers gave us following features: 1. 2. 3. 4. 5. 6. Guarantee of no error Data Security Data Privacy Data Consistency Atomicity of data Faster Processing

Keeping all the things in mind, really the computer system was alternate method to apply. Now a days everything is going to be branded or computerized is precedes their names. So for bank it was the best possible solution.

1.1 RECOGNITION OF NEED:

Before starting to develop a project one must know what the problem is, before it can be solved. The basis system is recognition of a need for improving an information system or procedure. This need leads to a preliminary survey or an initial investigation to determine whether an alternative system can solve the problem. Defining the problem is a very important step in any problem solving process. The following steps are based on the definition of the problem that comes as a result of this step.

1.2 NEED OF THE PROPOSED SYSTEM

1.2.1USER REQUIREMENT SPECIFICATION
Following table describes the set of objectives and requirement for the system from the system from users perspective. USER CURRENT Staff Members PROBLEMS -Have to manually feed in all the records with corresponding dates. -Have to keep updated version locally of their Account Reference -Not able to get -A lot of time will be saved verification would be easy and quick. DESIRABLE FEATURES -Maintained a new banking system on computers will help the staff members with computer generated updates and also printable copy available for reference

Holders or their records Customers quickly -Have to wait much to verify their identity.

1.2.2 PROBLEMS OF EXISTING SYSTEM

Banks previous system was a manual system and had a lot of limitations that had reduced the efficiency of the employees as well as the bank. It was not only the progress of the bank economically but was also affecting the goodwill of the bank and the bank was not living up to the expectations of the customers. Some of the common problems faced by the existing system are follows:
1.

Data redundancy and inconsistency: The files created by different employees over a long period of time, the various files were likely to have different formats. Moreover the same information was duplicated in several places. This redundancy led to higher storage and access cost and in addition it led to data inconsistency that is the various copies of same data may no longer agree. Data Isolation: Because data was scattered in various files, and files may be different formats, it is difficult to write new application programs to retrieve data correctly. Integrity Problem: That data values stored in the records must satisfy certain types of consistency constraints. The problem

2.

3.

arise when constraints involves several data items from different files.

4.

Atomicity Problems: In manual system it is crucial to ensure that once a failure has occurred and has been detected, the data is restored to consistent state that existed prior to the failure. Security Problems: Almost very employee of the bank was allowed to access all the data. Thus it was possible that data might loose its privacy, 6. Concurrent access anomalies: So that the overall performance of the system is improved and a faster response time is achieved, many systems allow many users to update data simultaneously. In such an environment interaction of concurrent updates may result in inconsistent data.

5.

These difficulties, among others have prompted the development of this software.

1.2.3 Benefits of newly proposed system:

Thus the bank needs to get software for the system Then that would overcome the above mentioned problems. Thus it was decided to develop a system with following features: 1. Performance: It was ensured that the system being developed is very quick in receiving the data and retrieving the information back to the user i.e. MIS department of the company. 2. Efficiency: It was made sure that the system being developed is handled by multiusers and is extremely efficient with no data duplications. 3. Control: Control of the system was rendered to a single user and was not meant for multiple user access. 4. Security: It was the need of the bank to restrict the access to certain modules of the software and database and to restrict the access to common user. 5. Software: The Banking System was developed specially in C++ because it is a user-friendly language and is very easy to access.

6.

Personnel: It was made sure that some modules of the system are made single user so that there is no overutilisation of staff.

This software is divided into different modules, each performing a different function, in order to make software more efficient and easy to use. This software will help in: Storing various details. Keeping records of transactions. Saving a lot of time. Verification would be easy and quick. Computer generated updates and records and also printable copy available for reference. Modifying Details of transactions changed by employee time to time. Deleting the records of those customers who left the organization at any instance.

1.3 DESIGN METHODOLOGY

The required system has been developed on the basis of the System Development Life Cycle approach. The basis for development has been each and every' phase of System Development Life Cycle as it is. A summary of System Development Life Cycle is given below. The different steps in system development life cycle are: 1. Recognition of needwhat is the problem. 2. Feasibility study 3. Analysis 4. Design 1.3.1 Recognition of need: The idea for change originates in the environment or form within the firm. Environment based ideas originate form customers. Vendors, government sources and the like. For example, new unemployment compensation regulation may make it necessary to change the reporting procedure, format and contents of various reports, as well as file structures. Customer's complaints about the delivery of orders may prompt an investigation of the delivery schedule. When

investigated, each of these ideas may lead to a problem definition as a first step in system development life cycle process. Ideas for change may also come from within the organization top management, user, and analyst. As an organization changes its operations or faces advances in computer technology, someone within the organization may feel the need to update existing applications or improve procedures. Here are some examples: An organization acquires another organization. A local bank branches into the suburbs. A department spends 80% of its budget in one month.

Two departments are doing essential the same task and each department head insists the other department should be eliminated.

A request for a new form discloses the use of bootleg. A report reaches a senior vice president and she suspects the figures. The company controller read an IRS audit report and starts thinking. An executive read about decision support system for sales forecasting and it gives him an idea. Many of these ideas lead to further studies by management request

often funneled downward and carried out by lower- management.

I User-originated ideas also prompt initial investigation. For

example, a banks head teller has been noticing long customer lines in the lobby. She wants to know whether they are due to the computers slow response to inquiries, the new tellers' limited training or just a sudden increase in bank business. To what extent and how quickly a user-originated idea is converted to feasibility study depend on several factors: The risk and potential return. Management's bias towards the user. Financial costs and the funds available for system works. Priorities of other projects in the firm. All these factors are crucial for a prompt response to the user request for change. A system analyst is in a unique position to detect and even recommend changes. Experience and previous involvement in the user area of operation make him a convenient resource for ideas. The role and status of an analyst as a professional add credibility to the suggestions made.

1.3.2 Feasibility Study:

Depending on the results of initial investigation, the survey is expanded to a more detailed feasibility study. Feasibility study is a test of a system proposal according to its workability, impact on the organization, ability to meet users need and effective use of resources. It focuses on three major questions: -1. What is the users need and how does a candidate system meet them? 2. What are the resources available for given candidate system? Is the problem worth solving? 3. What are the likely impacts of the candidate system on the organization? How well does it fit within the organizations master plan? Each of these questions must be answered carefully. They revolve around investigation and evaluation of the problem, identification and description of the candidate system, specification of performance and the cost of each system and final selection of the best system. The objective of a feasibility study is not to solve the problem but to acquire a sense of its scope. During the study, the problem definition is crystallized and aspects of the problem to be included

in the system are determined. Consequently, costs and benefits are estimated with greater accuracy at this stage. The result of the feasibility study is a formal proposal. This is simply a report- a formal document detailing the nature and scope of the proposed solution. The proposal summarizes what is known and what is going to be done. It consists of the following: Statement of the problem. - A carefully worded statement of the problem that led to analysis.

Summary of findings and recommendations. - A list of all major finding and recommendations of the study. It is ideal for the user who requires quick access to the results of the analysis of the system understudy. Conclusions are stated.

Details of findings. - An outline of the methods and procedures undertaken by the existing system, followed by coverage of the objective and procedures of the candidate system. Included are also discussions of output report file structures and cost and benefit of candidate system. Recommendation and conclusions. - Specific recommendations regarding the candidate system, including personnel assignment, cost, and project schedules and targets dates. After management reviews the proposal, it becomes a formal agreement that paves the way for actual design and implementation .This is a crucial decision point in the life cycles.

Many projects die here, whereas the more promising ones continue through implementation. Changes in the proposal are made in writing, depending on the complexity, size and cost of the project. It is simply common sense to verify changes before committing the project to design.

1.3.3 Analysis:
Analysis is a detailed study of the various operations performed by a system and their relationship within and outside of the system. A key question is: What must be done to solve the problem? One aspect of the analysis is defining the boundaries of the system and determining whether or not a candidate system should consider other related systems. During analysis, data are collected on available files, decision points and transactions handled by the present system. Finally, details related to justification of the system and an estimate of the impact of the candidate system on the user and the organization are documented and evaluated by management as a step towards implementation. The final report prior to the implementation phase includes procedural flowcharts, record layouts, and a workable plan for implementing the candidate system. Information on personnel, money, hardware, facilities and their estimated cost must be close to actual cost of implementation.

In some firms a separate group of programmers do the programming where as other firms employ analyst-programmer that do analysis and design as well as code the programs.

1.3.5 Implementation:
The implementation phase is less creative than system design phase. It is primarily concerned with user training, preparation and file conversion. When the candidate system is linked to other terminals, the telecommunication network and tests of the network along with the system are also included under implementations. During the final testing, user acceptance is tested, followed by user training. Depending on the nature of the system, extensive user training may be required. Conversions usually take place at about same time the user is being trained or later. In the extreme, the programmer is falsely viewed as someone who ought to be isolated form other aspect of system development. Programming is itself design work, however. The initial parameters of the candidate system should be modified as a result of the programming efforts. Programming provides a "reality test" for the assumption made by the analyst. It is therefore a mistake to exclude programmers from initial system design. System testing checks the readiness and accuracy of the

system to access, updates, and retrieve data from new files. Once the programs become available, test data are read into the computer and processed against the file provided for testing. If successful, the program is then run with live data. Otherwise a diagnostic procedure is used to locate and correct errors in the program. In most conversion's, a parallel run is conducted where the new system runs simultaneously with the "old" system. This method though costly provides added assurance against errors in the candidate system and also gives the user staff an opportunity to gain experience through operation. In some cases, however, parallel processing is not practical.

1.3.6 Post implementation and maintenance:

After the installation phase is completed and the user staff is adjusted to the changes created by the candidate system evaluation and maintenance begin. Like any system, there is aging process that requires maintenance of hardware and software. If the new system inconsistent with the design specification, then changes have to be made. Hardware also requires periodic maintenance to keep in tune with design specifications. The importance of maintenance is to continue to bring new system to standards. User priorities changes in organizational requirements or environmental factors also call for

system enhancement.

1.3.7 Project termination:

A system project may be developed at any rime prior to implementation although it becomes more difficult when it goes past the design phase. Generally projects are developed if after a review process, it is learned that: Changing objectives or requirements of the user cannot be met by the existing design. Benefits realized from the candidate system do not justify commitment to implementation. There is sudden change in the user budget or an increase in design cost beyond the estimate during feasibility study. The project greatly exceeds the time and cost schedule. There are many reasons for a new system does not meet user requirements: User requirements were not clearly defined or understood. The user was not directly involved in the crucial phases of system development. The analyst, programmer or both were inexperienced. User training was poor

 Existing hardware proved deficient to handle the new application. The new system left user in other departments out of touch with information that the old system had provided.

SYSTEM DEVLOPMENT LIFE CYCLE

Organization Based

Source of ideas

Environment Based

Organization

Impetus For Change

Govt. rules And Regulations

Top Management

Recognition of need Feasibility Study

Consumers

User

Union

Analysis System Analyst Design

Competition

Implementation

Post Implementation

Maintenance

Feasibility Study
2.1 Need of Feasibility Study:
Depending on the results of initial investigation the survey is expanded to a more detailed feasibility study. Feasibility study is a test of a system proposal according to its workability, impact on the organization, ability to meet user needs and effective use of resources. It focuses on three major questions:1. What are the users demonstrable needs and how does a candidate system meet them? 2. What are available for given candidate system? Is the problem worth solving? 3. What are the likely impacts of the candidate system on the organization? Feasibility study is earned out keeping in mind there main aspects of project to be developed. These are: Economic feasibility Technical feasibility Operational feasibility Many feasibility studies are disillusioning for both user and analysts. The study often presupposes that when the feasibility document is being prepared the analyst is in a position to evaluate

solutions. If the feasibility study is to serve as decision-making documents, it must answer three key questions:

Is there a new and better way to do the Job that will benefit the user and what is recommended? (Technical feasibility). What are the cost and savings of the alternatives.(Economic feasibility) Whether the newly developed system be easily operated by the user and what all manpower investment he will have to make (Operational feasibility).

2.2 Common aspects of feasibility study are: A system required performance is defined by describing its output in a user acceptable format and at a higher level of details than what was described in the initial investigation. This involves three steps: 1. Statement of constraints. 2. Identification of specific system objective. This phase builds on the previous phase in that much of the work may already have been done.

2.2.1 Statement of constraints:

Constraints are factors that limit the solution of the problem. Some constraints are identified during initial investigation and are

discussed with the user. There are general constraints that might have a bearing on the required performance of a candidate system. 2.2.2 Identification of specific system objectives: Once the constraints are spelled out, the analyst proceeds to identify the systems specific performance objectives. They are derived from the general objectives specified in the project derived at the end of the initial investigation. The steps are to state the systems benefits and then translate them into measurable objectives. In our scenario, the candidate system anticipated benefits are as follows: 1. Improved reservation and cancellation schedule. 2. Cost reduction 3. Physical space reduction. 4. Improved customer service.

2.3 Steps in feasibility study:

1) Form a project team and appoint a project leader. 2) Prepare system flow charts. 3) Enumerate potential candidate system. 4) Describe and identify characteristics of candidate system. 5) Determine and evaluate performance and cost effectiveness of each candidate system. 6) Weight system performance and cost data.

7) Select the best candidate system. 8) Prepare and report final project directive to management.

2.3.1 Form a project team and appoint a project leader:

The concept behind a project team is that future system user should be involved in its design and implementation. Their knowledge and experience in operations area are essential to the success of the system. The project team for our project consisted of analyst and user staffenough collective expertise to devise a solution to the problems. An outside system consultant and an information specialist joined our project team until the job was Complete. Projects are planned to occupy a specific time period ranging from weeks to several months.

2.3.2. Prepare system flow chart:

The next step in feasibility study is to prepare generalized system flowchart for the system. Information-oriented charts and data flow diagram prepared in the initial investigation were also reviewed at this time. All other flow chart needed for detailed evaluations were complete by this stage.

2.3.3 Enumerate potential candidate system:

This step was undertaken to identify the candidate system that is capable of producing the output indeed in the generalized flowchart. This requires a transformation form logical to physical

system models. Another aspect of this step was consideration of the hardware that can handle the total system requirement. An important aspect of hardware is processing and main memory. There is large number of computers with differing processing size, main memory capability and software support.

2.3.4 Describe and identify characteristics of candidate systems:

Considering the candidate, team began a preliminary evaluation in an attempt to reduce them to a manageable number. Technical knowledge and expertise in the hardware/ software area are critical for determining what each candidate system cannot and can do. Determining and evaluate performance and cost effectiveness of each candidate system. Each candidate system performance is evaluated against the system performance requirement set prior to the feasibility study. They are usually evaluated in qualitative terms based on the subjective judgment of the project team. The cost encompasses both designing and installing the system. It includes user training, updating the physical facilities and documenting. System performance criteria are evaluated against the cost of each system to determine which is likely to be most cost effective and also meets the performance requirement. Costs are easily determined when the benefits of the system are

tangible and measurable. An additional factor to consider is the cost of the study design and development.

2.3.5 Weight system performance and cost data:

In some cases the performance and cost data for each candidate system show which system is the best choice. This outcome terminates the feasibility study. Many times this situation is not so clear cut. Following procedure is followed for weighting candidate system: 1. Assign a weighting factor to each evaluation criterion based on the criterion's effect on the success of the system. 2. Assign a quantitative rating to each criterion qualitative rating. For example rating (poor, fair, good, very good, excellent) may be assigned relative values (1, 2, 3, 4. 5, 6). 3. Multiply the weight assigned to each category by the relative rating to determine the score. 4. Sum the score column for each candidate system.

2.3.6 Select the best candidate system:

The system with highest total score is judged the best system. This assumes the weighting factors are fair and the rating of each evaluation criterion is accurate. Most feasibility studies select from more candidate system. In any case management should not make the selection without having the experience to do so. Management cooperation and comments were however encouraged.

2.3.7 Feasibility report:

The culmination of the feasibility study is a report directed to management; it evaluates the impact of the proposed changes on the area in question. The report is a formal document for management use, brief enough and sufficiently non-technical to be understandable, yet detailed enough to provide the basis for system design. There was no standard format for preparing feasibility report. Analyst of the company decided on the format that would suit the user of the system. The feasibility report of our project started with summary of findings and recommendations followed by documented details. A generalized report contains the following sections: 1. Cover letter formally presents the report and briefly indicates to management the nature of the system. 2. Table of contents specifies the location of the various parts of report. 3. Overview is the narrative explanation of the purpose and scope of the project, the reason for undertaking the feasibility study. 4. Detailed findings outline the method used in the present system. The system effectiveness as well as efficiency as well as operating cost are emphasized. 5. Economic justification determines whether project developed is

as per the cost estimates. 6. Recommendations and conclusion suggest to the management the most beneficial and cost effective system. 7. Appendixes. Feasibility study is done so that an ill - conceived system is recognized early in definition phase. During system engineering, however, we concentrate out attention on four primary areas of interest:

Economic Feasibility: An evaluation of development cost weighted against the ultimate income or benefit from the developed system.

Technical Feasibility: A study of function, performance and constraints that may affect the ability to achieve an acceptance system.

Legal Feasibility: A determination of any infringement/violation/liability that could result from the development of the system. Alternatives: An evaluation of alternative approaches to development of the system.

Once the solutions to the problem are identified then it is important to justify the solutions. To do this it is necessary to determine whether the solutions are feasible.

2.4 EVALUA TING PROPOSED SOLUTION:

After looking at the broad alternative solutions, a short list of solutions is kept. These solutions are further evaluated to find out the following:

Their economic feasibility: To find this it was asked whether finances are available for implementing the proposed solution and whether the money spent is recovered by the savings or by better user satisfaction. Their technical feasibility: To find this, it was asked whether the technology needed is available and if available whether it is useable. Their operational feasibility: To find this, it was asked whether the proposed solution can fit in with existing operations and whether the right information at the right time is provided to users.

2.5 ECONOMIC FEASIBILITY:

Economic feasibility concerns returns from investments in a project. It determines whether it is worthwhile to invest the money in the proposed project or whether something else should be done with it. Some organizations, especially those with large projects, place great emphasis on economic analysis. It is not worthwhile spending a lot of money on a project for no returns, especially if there are many other things, which could be done with that money.

To carry out an economic feasibility study, it is necessary to place actual money values against any purchases or activities needed to implement the project. It is also necessary to place money against any benefit that will accrue. A cost-benefit analysis is necessary to determine economic feasibility. The primary objective of cost-benefit analysis is to find out whether it is economically worthwhile to invest in the project. If the returns on the investment are good, then the project is considered economically worthwhile. First listing all the costs associated with the project performs cost-benefit analysis. Costs consist of both direct costs and indirect costs. Direct costs are those incurred in buying equipment, employing people, costs of consumable items, etc. Indirect costs include those involving time spent by user in discussing problems with system analyst.

2.5.1 Economic analysis:

Economic analysis of is the most frequent used method for evaluating the effectiveness of a candidate system. More commonly known as cost/benefit analysis, me procedure is to determine the benefits and savings that are expected from a candidate system and compare them with cost. If benefits over-weigh the cost, then the decision is made to design and implement the system. Otherwise, further justification or alteration in the proposed system will have to be made if it is to have a chance

of being approved. This is an ongoing effort that improves in accuracy at each phase of the system life cycle During the economic feasibility study of Banking System the following cost elements were considered :

Hardware cost: - relates to actual cost of computer and peripherals like printer, disk drive, and tape units).Developing the total cost of the system is generally difficult when the system is shared by the various users. Personnel cost: - includes staff salaries and benefits as well as pay for those involved in developing the system. Cost incurred during the development of a system is one time cost and are labeled development cost. Facility cost: - are expense incurred in the preparation of the physical site where the application or the computer will be in operation. This includes wiring; flooring, etc. These costs are treated as one time cost. Operation cost: - includes all cost associated with dayto-day operation of the system. The amount depends on the number of shifts, the nature of the application and the caliber of the operating staff. Supply cost: - are variable cost that increase with

increased use of paper-ribbon, disks .They should be estimated and included in overall cost of the system. Cost benefit analysis is a procedure that gives a picture of the various costs, benefits and rules associated with the system. The determination of the cost and benefit entails the following steps:1. Identify the cost and benefits pertaining to the given project. 2. Categorizing the various costs and benefits for analysis. 3. Selecting a method of evaluation. 4. Interpret the result of the analysis. 5. Take action.

2.5.2 Cost and benefit identification:

Certain cost and benefits are more easily identifiable than others. For example, direct cost, such as the price of a hard disk, are easily identified from the company invoice payment or cancelled checks. Direct benefits often relate one to one to direct cost, especially savings form reducing cost in the activities in question. Other direct cost and benefits however may not be well defined, since they represent estimated cost. A category of cost and benefit that is not easily discernible is opportunity cost and opportunity benefits. These are the costs or benefits forgone by selecting one alternative over another. They do not show in the organization accounts and are therefore not easy to

identify. The costs and benefits of the developed system are classified as follows: Tangible or intangible cost and benefit Direct or indirect costs and benefits. Fixed or variable cost and benefits. Savings versus cost advantages. While conducting an economic feasibility study for the developed project some of the major point was considered. Some of these points are mentioned below: That the developing cost of these project does not exceed the budget of the of the bank and is well unto the financial expectations of the bank. It was also made sure that the cost of implementation of the system was not very high. A special consideration was made to ensure that the maintenance cost of the system was not very high. A special user manual is provided along with the project so that The Company does not have to incur a separate cost for training the operators of the system. A special training session was conducted for the operators of the

system free of cost. Special efforts were made to ensure that the overall development of the project does not exceed the overall budget limitations of the company. It was made sure that the employment of new of new staff for the development of the system was aptly qualified so that the company does not has to waste money on providing future training. It was also made sure that the company does not have to install too many new hardware and software for the implementation of new system. A special effort was made to reduce the project development overheads to minimum.

2.6 TECHNICAL FEASIBILITY:

This evaluation determines whether the technology needed for the proposed system is available and how it can be integrated within the organization. Technical evaluation must also assess whether the existing system can be upgraded to use technology and whether the organization has expertise to use it. Technical feasibility centers on the existing computer system (hardware, software etc) and to what extent it can support the proposed addition. For example, if the current computer system is operating at 80% capacity-an-arbitrary ceiling-then running another application could overload the system or require additional hardware. This involves financial considerations to accommodate

technical enhancements, if the budget is a serious constraint, then the project is judged not feasible. Some of the new hardware requirements of the new system are:

System Requirements:
HARDWARE: 1. 2. 3. 4. 5. 6. Pentium Processor 128 MB RAM 40 GB Memory Space Keyboard Mouse Color Monitor

SOFTWARE: Operating System: Any of the below given os can be used: 1. WINDOWS 98 2. WINDOWS 2000 3. WINDOWS XP Software Needed: 1. Turbo C++/Visual C++

SYSTEM ANALYSIS

3.1 DATA COLLECTION Information gathering is an art and a science. The approach and manner in which information is gathered requires person with common sense with knowledge of when to gather and what channels to use in securing information. 3.1.1 What kind of information is to be gathered? The different types of information are:

Information about the firm Information about the user staff Information about workflow.

Data collection:
The data collection process has the following tools during the phase of system analysis. The phases are:1. Familiarity with the present system through available documentation such as procedures manual, documents and their flow, interviews of the user staff. 2. Definition of the decision making associated with managing the system. This is important for determining what information is required of the system. Conducting interview clarifies the decision point and how decisions are made in the user area. 3. Once decision points are identified, a series of interviews might be conducted to define the information requirements of the

users. The information gathered is analyzed and documented. Discrepancies between the decision system and information generated from the information system are identified. This concludes the analysis and set the stage for system design.

3.1.2 Types of information 3.1.2.1 Information about the firm

Information about the organizations policies, goals, objectives and structure explains the kind of environment that promotes the introduction of computer based system. Company policies are guidelines that determine the conduct of business. Policies are translated into rules and procedures for achieving goals. A statement of goals describes management commitment to objectives and the direction system development will follow. Objectives are milestones of accomplishments towards achieving goals. Information from employees manuals, orientation, pamphlets, annual company reports help the analyst from opinions about the goals of the organization. After the policies and goals are set, a firm is organized to meet these goals. The organization structure, via the organization chart, indicates management directions and orientations. The organization chart represents an achievement-oriented structure. It helps us to understand the climate in which candidate system will be

considered. In gathering information about the firm analyst should watch for correspondence between what the organization claims to achieve and actual operations.

3.1.2.2 Information about staff:

Another kind of information for analysis is knowledge about the people who run the present system- their job functions and information requirements, the relationship of their jobs to the existing system and the interpersonal network that holds the user group together. We are actually focusing on peoples roles, authority relationships, job status and functions information requirement and interpersonal relationships. Information of this kind highlights die organization chart and establishes a basis for determining the importance of the existing system for the organization. In short the major focus is on to find out what the people the analyst is going to be dealing with and what each person expects to get out of a the system before it goes through design phase and final implementation.

3.1.2.3 Information about work flow:

Workflow focuses on what happens to the data through various points in a system. This can be shown but a data flow diagram or a system flowchart. A data flow diagram represents the information

generated at each processing point in the system and the direction it takes from source to destination. The information available from such charts explains the procedures used for performing tasks and work schedules. 3.1.3 Where does in formation originate? Information is gathered from two principal sources: personnel or written documents from within the organization and from the organization environment. The primary external sources are:1. Vendors. 2. Government documents 3. News papers The primary internal sources are:1. Financial reports 2. Personnel staff 3. Professional staff. 4. System documentation or manuals. 5. The user or user staff. 6. Reports and transaction documents. Hardware vendors are traditional sources of information about system and software. Other equipment manufacturers provide

information about competitive systems. A third source that has experienced tremendous growth during the past decade is the software house. Other external sources of information are government documents, technical newspaper and professional journals. Internal sources of information are limited to the user staff, company personnel and various reports. An important source of information is the key employee who has been in the user area for years and is familiar with present activities and applications.

3.1.4 Tools of information gathering

Onsite Observation Interviews Questionnaires 3.1.4.1 Onsite observation: One of the major information gathering tools used in information gathering is onsite observation. It is the process of recognizing and noting people, objects and occurrences to obtain information. The analysts role is that of an information seeker who is expected to be detached from the system being observed. This role permits participation with user staff openly | and freely. The major objective of onsite observation is to get as close as possible to the real system being studied. For this reason it is

important that the analyst in knowledgeable about the general make up and activities of the system. The following question can serve as a guideline for on-site observation: 1. What kind of system is it? What does it do? 2. Who runs the system? Who are the important people of it? 3. What is the history of the system? How did it get to its present stage of development? As an observer the analyst follows a set of rules. While making observations he she is more likely to listen than talk and listen with a sympathetic and genuine interest when information is conveyed. When human observers are used four alternative observation methods are considered: 1. Natural or contrived 2. Obtrusive or unobtrusive 3. Direct or indirect 4. Structured or unstructured Some common problems encountered with onsite observation are: Intruding into user area often results in adverse reactions by the staff. Therefore adequate preparation and training are important.

Attitudes and motivations of subjects cannot be readily observed- only the action that results forms them. Observations are subject to errors due to observer's is interpretation and subjective selection of what to observe. Unproductive, long hours are often spent in an attempt to observe specific, one time activities or events.

In deciding to use an on-site observation several questions are considered: What behavior can be observed that cannot be described in other ways? What data can be obtained more easily or more reliably by observation that by other mean?

What assurance can be given that the observation process is seriously affecting the system or the behavior being observed?

What interpretation needs to be made about observational data to avoid being misled by the obvious? How much skill is required and available for actual observation? For onsite observation to be done properly in a complex situation it can be very time-consuming. Proper sampling procedures must be used to ascertain the stability of the behavior being observed.

3.1.4.2 Interviews:

The interview is face to face interpersonal situation in which a person called the interviewer asks a person being interviewed questions designed to gather information about a problem area. The interview is the oldest and most often used device for gathering information in system work. It has qualities that behavioral and onsite observations do not poses. It can be used for two main purposes: 1. as an exploratory device to identify relations or verify information. 2. To capture information as it exists. Validity is no small. Special pains are taken to eliminate interview bias. Such an assumption stresses the voluntary character of the interview as a relationship freely and willingly entered into by the respondent. If the interview is considered a requirement the interviewer might gain the respondent time and attention, but cannot be certain of the accuracy of the information gathered during the interview is considered a requirement, the interviewer might gain the respondents time and attention, but cannot be certain of the accuracy of the information gathered during the interview. In an interview since the analyst and the person interviewed meet face to face, there is an opportunity for flexibility in eliciting

information. The analyst is also in a position to observe the subject. In contrast, the information obtained through a questionnaire is limited to the subjects written responses to predefined questions. There are four primary advantages of the interview: 1. Flexibility makes the interview a superior technique for exploring areas where not much is known about what questions to ask. 2. It offers a better opportunity than the questionnaire to evaluate the validity of the information gathered. 3. It is an effective technique for eliciting information about complex subjects and for probing the sentiments underlying expressed opinions. 4. Many people enjoy being interviewed, regardless of the subject. They usually cooperate in a study when all they have to do is talk.

3.1.4.3 Questionnaire:
In contrast to the interview is the questionnaire this is the term used for almost any tool that has questions to which individuals respond. It is usually associated with self administer tools with items of the closed or alternative type. By its nature a questionnaire offers the following advantage: 1. It is economical and requires less skill to administer than the interview.

2. Questionnaires can be administered to a large number. Of individuals simultaneously. 3. The standardized wording and order of the question and the standardized instructions for reporting responses insures uniformity of questions. 4. The respondent feels greater confidence in the anonymity of a questionnaire than in that of an interview. In an interview the analyst usually knows the user staff by name, job function or other identification. With the questionnaire respondent give opinions without fear that the answer will be connected to their names. 5. The questionnaire places less pressure on subjects for intermediate subjects for intermediate responses. Respondents have time to think the questions over and do calculations to provide more accurate data. The advantage of self-administered questionnaire outweighs disadvantages, especially when the cost is a consideration. The principal disadvantages are a low percentage of return. Another disadvantage is that many people have difficulty in expressing themselves in writing, especially when responding to essay question. Types of questionnaire Interviews and questionnaire vary widely in form and

structure. Interviews range from highly unstructured, adhere neither the questions nor the respective responses are specified in advance, to the highly structured alternatives in which questions and responses The unstructured alternative: The unstructured alternative is a relatively non-directive information gathering technique. It allows respondents to answer questions freely in their own words. Responses are spontaneous rather than their own words. They are self revealing and personal rather than general and superficial .The role of the analyst as an interviewer is to encourage the respondent to talk freely and serve as a catalyst to the expression of feeling and opinions. Structured Alternative in the structured approach, the questions are presented with exactly same wording and in the same order to all subjects. If the analyst asks a subject "would you like to see a computerized approach to solving your problem?" And asks another subject, How do you feel about computers handling your problem? the responses may not be the same even though the subject both have the same opinion. Standardized questions improve the reliability of the responses by ensuring that all subjects are responding to the same questions. are fixed-

3.1.5 Questionnaire

{From management point of view} The data for the development of this software was collected by using the user-friendly approach i.e. questionnaire. Some of the questions that were asked form the managers were as follows: 1. What different features are included in this software? Enquiry Addition Deletion Report Edit Others (specify) 2. Does the company want to protect its data from outside intervention by the use of password?

Yes No SQL C++

3. in what language does the company wants to develop it software?

Oracle 8i Java

4. Whether the company wants the software to be:

Local area network based

Single user based 5. How much time is the company willing to devote to the completion of this project?

1 month

2 month Not decided 6. What is the expected budget of the firm for the developing of this Project?

7. Should the account number be generated automatically? Yes No 8. What should be the date format?

 26/11/85

26th Nov 1995

Nov 26, 1985 9. What all report should be generated?

List of all employees. List of all projects List of employees (experience wise) List of all employees (training wise)

Any other (specify 10. What all modification about the records can be made?

Modify Customer record Add Customer record Delete Customer record

11. The report about the employee should be based on? Education

Experience Training Any other (specify)

12. What new hardware should be installed with the system? Printer Scanner Multimedia kit Any other (specify) 13. Should a special user training session be conducted for the employees? Yes No

14. Does the company need a trained executive for the maintenance of software? Yes No

The above given information is totally based on managers and companies requirement and is not affected by user discretion and is totally unbiased.

SOFTWARE PARADIGMS 4.1 Project Metrics:

Software process metrics are used for strategic purposes.

Software project measures are tactical. That is, project metrics and the indicator derived from are used them to adapt to project work. The first application of project metrics on software projects takes place during estimation. Metrics collected from post project are used at a basis from which effort and time duration estimates are made for present software work. As a project progresses measures of effort and time spent are compared to original estimates and schedule. These are used to monitor and control progress. As technical work commences, other project metrics are also used. Production rates represented in terms of pages of documentation, revision hours, function points and delivered source lines are measured. Also, errors uncovered during each software engineering task are tracked. As the software evolves from specification into design, technical metrics assess design quality and provide indicators for code generation and module and integration testing. The aim of project metrics if two fold. First, to minimize the development schedule by guiding the adjustments necessary to avoid delays and mitigate potential problems and risks. Second, to assess product quality on an ongoing basis and modify the technical approach to improve quality. As quality improves, errors are minimized, and as the errors count goes down, the amount of rework

required during the project is also reduced. This leads to a reduction in overall project cost. A new model of software project metrics suggests that every project should measure:

Inputs- measures of the resources (e.g.: people, environment) required to finish the work. output- measure of work products results - measures that point out the effectiveness of the deliverables

In practice, this model can be used for both process and project. In the project context, the model can be applied recursively as each framework activity occurs. Therefore the outputs from one activity become inputs to the next.

4.2 PROCESS METRICS:

To improve a process we measure specific attributes of the process, develop a set of meaningful metrics based on these attributes and then use the metrics to indicators that will lead to a strategy of improvement. However process is only one controllable factor is improving software quality and organizational performance".

Product Product Business Business Conditions Conditions Technology Technology

Process Process

People People

Development Development Environment Environment

According to above figure the candidate system (Banking System) process is at the center connecting other factors that affect software quality and organizational performance. The skill and motivation of people is shown to be single most influential factor in quality and performance. The complexity of product can have a substantial impact and quality and team performance technology. The process exists within the centre or environmental conditions that include the development environment business condition and customer characteristics. The efficacy of a software process is measure indirectly. We drive a set of metrics based on the outcomes that can be derived from the process. Outcomes include measures of errors uncovered before release of the software, defects delivered to and reported by end

users,

work

products

delivered,

time

expanded,

schedule

conformance and other measures. Process metrics are also derived by measuring the characteristics of specific software engineering tasks. Software process metrics give significant benefit as we work to improve overall level of process maturity. However, like all metrics, these can be misused, creating more problems than they solve. Grady suggestsoftware metrics etiquette" that is appropriate for a process metrics program: - Use common sense and organizational sensitivity when interpreting metrics data. - Provide regular feedback to the individuals and teams who have worked to collect measures and metrics. - Don't use metrics to appraise individuals. - Work with practitioners and teams to set clear goals and metrics that will be used to achieve them. - Never use metrics to threaten individuals or teams. - Metrics data that indicate a problem area should not be considered "negative. These data are merely an indicator for process improvement. - Don't obsess on a single metric to the exclusion of other important metrics. Following steps given above, a simple defect distribution can be developed. For the pie-chart noted in the figure, eight causes of

defects and their origin (indicated by shading) are shown. GRADY suggests the development of a fishbone diagram to help in diagnosing the data represented in the frequency diagram. 4.3 SIZE-ORIENTED METRICS: Size-oriented software metrics are derived by normalizing quality and/or productivity measures by the "size" of the software. If a software organization-maintains simple records, a table of sizeoriented measures, such as the one shown in Figure can be created. The table shows each software development project that has been completed over the past few years and corresponding measures for that project. Referring to the table entry for project A: 10,000 lines of code (LOC) were developed with 24 person-months of effort at a cost of Rs.240000. Effort and cost represent all software engineering activities analysis, design, coding, and testing, not just coding. Further information for project A indicates that 300 pages of documentation were developed, 150 errors were recorded before the software was released, and 25 defects were encountered after released to the customer within the first year of operation. Three people worked on the development of software of A. To develop metrics that can be assimilated with similar metrics from other projects, lines of code is chosen. A set of simple size-oriented metrics can be then developed for each project:

- Errors per KLOC (thousand lines of code) - Defects per KLOC - Per LOC - Pages of documentation per KLOC In addition, other useful metrics can be computed: - Errors/person-month - LOC per person-month - Rs. page of documentation The development of candidate system in accordance with size oriented metrics is as follows: Project L.O.C Effort (in Banking 1226 months) 6 Cost (in Rs) .. Pages of Documentation 189 .. Errors

System Size-oriented metrics are not accepted by all as the best way to measure the process of software development. Most of the controversy is about the use of lines of code (LOC) as a key measure. Supporters of LOC measure say that LOC is a factor in all software development projects and can be easily counted; that many existing software estimation modes use LOC or KLOC as a key input, and that a large body of literature and data predicated on LOC already exists. On the other hand, opponents say that LOC measures are programming language dependent; that they penalize well-

designed but shorter programs; that they cannot easily accommodate non-procedural languages, and that their use in estimation requires a level of detail that may be difficult to achieve i.e., the planner must estimate the LOC to be produced long before analysis and design are completed.

SYSTEM DESIGN

5.1 Physical Design: This design phase covers the development of the physical structure of the proposed software. 5.1.1 The process of design:' The design phase focuses on the detailed implementation of the system recommended in the feasibility study. Emphasis is on translating performance specifications into design specifications -the design phase is a transition from user-oriented document (system proposal) to a document oriented to the programmers or database personnel. 5.7.2 Logical and physical design: System design goes through two phases of development: logical and physical design. For a candidate system it describes input (source), output (destination) databases (data stores) and procedures (data flow)-all in a format that meets the users requirements. When analyst prepares logical system design, they specify the user requirement at a level of details that virtually determine the information flow into and out of the system and required data resources. The design covers the following:1. Reviews the current physical system-its data flow, file contents volumes, frequency. 2. Prepares output specification- i.e. determines the format, content and frequency of reports, including terminal specification and

location. 3. Prepares input specification-format, content and most of the input functions. This includes determining the flow of documents frame the input data source to the actual input location. 4. Prepares edit, security and control specifications. This includes specifying the rules for edit correction, backup procedures and the controls that ensure processing and life integrity. 5. Specifies the implementation plan. 6. Prepares logical design walkthrough of the information flow, output, input and control and implementation plan. 7. Reviews benefit, costs, targets dates and system constraints.

5.1.3 Design methodologies:

During the last decade, there has been a growing move to transform the "art" of system analysis and design into an engineering type discipline. The feeling that there has to be more clearly defined logical method for developing a system that meets the user requirements has led to new techniques and methodologies that fundamentally attempt to do the following: 1. Improve productivity of analyst and programmers. 2. Improve documentation and subsequent maintenance and enhancements. 3. Cut down drastically on cost overruns and delays. 4. Improve communication among the users, analyst, designer

and programmer. 5. Standardize the approach to analysis and design. 6. Simplify design by segmentation.

Structured design
Structured design is a data flow based methodology. The approach begins with a system specification that identifies input and outputs and describes the functional aspects of the system. The system specifications then are used as a basis for the graphic representation-data flow diagrams- of the data flow and processes. Structured design partitions a program into small, independent modules. They are arranged in a hierarchy that approximates a model of the business area and is organized into an up-down manner with details show at the bottom. The primary advantages of this design are:1. Critical interface is tested first. 2. Early versions of the design, through incomplete, are useful enough to resemble the real system. 3. Structuring the design .provide controls and improves morale 4. The procedural characteristics define the order that determines processing.

Functional decomposition:

It is a graphic tool for representing hierarchy and it has three elements:1. The module is represented by a rectangle with a name. It is a contiguous set of statements.

2. The connection is represented by a vector linking two modules. It usually means one module has called another module. For example module a call module b and also calls module c.

A B C

3. An arrow with a circular tail represents the couple. It represents data items moved from one module to another. For example o, p and q are couples. Module A calls B, passing o downward. Like wise module A calls module C passing p downward and receiving q back.

A
o p q

5.1.2 Data flow diagrams:

A DFD is one of the first steps in developing software. It has the purpose of clarifying system requirement and identifying major transformations that will become programs in system design. So it is the starting point of the design phase that functionally decomposes the requirement specifications down to the lowest level of details. Some of the commonly used symbols while making a DFD diagram are:
1. 2.

A square: defines source or destination of system data. An arrow: identifies data flow - data in motion. It is a pipeline through which information flows.

3. A circle: represents a process that transforms incoming data flows into outgoing data flows. 4. An open rectangle: is a data store

DFD At Level 1:

Configure system by Administr ator

Configuration Information

Display message and status Interact with users

Display Screen to enter the Password

DFD Level 2: Expanding interact with users

Interact with user

About Screen s

Adding/Editing Particular Information

Configure System

Screen Details

DFD Level 3: Particular Information

Particular Information

Name

Address

Account

Account Number Amount Account Type

Configure System

SYSTEM DEVELOPMENT
6.1 Coding standards 6.1.1 Component coding guidelines Component coding guidelines are a must for making a good, professional and well -defined project. To make our project complete in every aspect we followed the following rules and conventions:

The first convention will be naming of the files. The file name will explain the whole working of the file on its own. The color-coding will be done in order to make the screen look nice and easy to distinguish the items on screen. Extra clicks and escape characters will also be taken care off in order to reduce the complexity of the system. Each menu will show its name distinctly. The variable names will be made short and highly understandable by any one. The system will be very interactive with the user in order to give the exact information whatever the user needs. Before editing anything it will first confirm whether the user wants to update it intentionally or has done it by mistake, this will help the user not to make any permanent changes in the records, if he has done any mistake.

A number of valid commands will be written in the code in order to accept only the appropriate values.

6.1.3 Program coding standards:

Constructing the system components. After completing the designing work the task of developing a coding for the developed design starts constructing a system is similar to constructing a house. Both activities begin with the foundation. The facilities include the tools, hardware, software, programming languages and database engine, etc.

6.1.3.1 Conventions for coding structured programming:A primary goal of structured programming is to create code that is as clear and readable as possible. A program that is clear and readable is easier to develop, test, debug and maintain than one that is not. Programming standards are guidelines adopted by an organization's programming staff so as to produce maintainable and flexible systems. These standards specify conventions for naming data elements and documenting program code. Here are some guidelines that help to create a more readable code. Use only proper structures The basic theory of structured programming is that any program can be written using three logical structures: Sequence

 Iteration

Selection
A program code made up of these structures will have only one entry point and one exit point. This program is executed in a controlled manner from the first statement to last. Sequence The sequence structure is simply a set of imperative statements executed in sequence, one after another. The one exit point is after the last function in the sequence. A sequence may consist of a single or many functions. Simple statements like perform or calls are the prime example for sequence structure.

Entry

Function A

Function B

Exi t

Sequence structure Selecting the selection structure, is a choice between two and only two functions based on a condition. This structure is often referred as if-then-else structure. Iteration: is the continued activation of a module or a set of statements for as long as a stipulated condition exits. When the

condition is no longer true, the program continues with the next structure. Do-while or do-until are some of such functions.

Entr y

Function A

Con diti on

Exit

Iteration Structure USE MODULE THAT RELATE TO THE PROGRAM STRUCTURE CHART Two benefits result when you create module names, which denote the function, associated with it 1. First, the program structure chart becomes a directory to all the modules of the resulting program, by which any future problem modules can be located by studying the structure chat. 2. Secondly, the search for locating these modules becomes very easy in programs, which has so many of such functions and runs into hundreds of lines of codes. Use descriptive data names:

While we create data names, do not abbreviate unnecessarily. Make the name as descriptive as you can with the constraints of programming language. Use comments sparingly: The structure and code of a program should make it easy to understand without comment. However, comments can be useful to overcome language limitations or to provide a reference to documentation Conclusion: Each application software program should be designed to accomplish as much as possible within defined specifications. Always remember that a program is an implementation of a plan to solve a business problem. Hence never concentrate on elegant program design. Instead concentrate on efficiencies and refinements that can easily be easily implemented. that is external to the program.

6.2 Validations Describe all the procedural level validations to be performed in the system. Login Validation - In the login Screen check for valid password. Mandatory Fields - The application to check for inputs in the mandatory field, in absence of data error message to come. Saving - The application to test if the section details are saved before

the user tries to move to other parts of the application or closes the screen. 6.3 Testing: Testing is a process of executing program with intention of uncovering errors in it. Though testing cannot show absence of errors but by not showing their presence it is considered that these are not presentable or at least have been minimized a lot. These were following considerations that were taken for testing the modules:

Preplanning of testing and test case designs. Conformance to requirements. During this phase following testing have been undertaken at different levels, corresponding to their relevance: 1. White box testing: to ensure that all the paths/branches of the code modules are covered. 2. Black box testing: product are covered. 3. Testing documentation: to ensure that all the functional requirements, acceptance requirements are covered. 4. Performance and acceptance testing: to ensure to ensure that all the functional requirements, that customers would use to accept the

That all

the

functionality specified in

customer

requirements is covered. 6.3.1 Approach to testing:

Testing a systems capability is more important than testing its component. This means that test cases should be chosen to identify aspects of the system, which will stop them doing their job. Testing old capabilities is more important than testing new capabilities. If a program is a revision of an existing system, user expects existing features to keep working. Testing typical situations is more important than resting boundary value cases. It is more important that a system works under normal usage condition than under occasional condition, which only arise with extreme data values like volume, size, etc.

6.3.2Testing techniques: Basically three types of testing techniques were followed while developing of this project. These are:1. Functional testing: - functional testing is the basic level of testing where individual components (which may be functions routines/programs) are tested to ensure that they operate correctly. In a properly designed system, each component

should have a precise specification, and test case must be defines to check that the component meets its specification. Unit testing considers each component to be a stand alone entity, which does not require other system components to be present during the testing process. 2. Integrated testing: - a module is a collection of programs, which are interdependent. After each program unit has been tested, the interaction of these programs when they are put together must be tested. A module encapsulation related functions and routines and it should be possible to test a module as a stand- alone entity, without the presence of other system modules. 3. System function testing - system testing is the next step up in the testing process where different modules are put together to from subsystems. Each of the modules may be designed and implemented by different software engineers; hence there may be problem with respect to interface mismatches. Thus, the system test process should concentrate on the detection of the interfacing errors but rigorously exercising these interfaces.

6.3.3 Testing the hardware component:

Often system are developed using an organization existing hardware resources. The same was in our case. In such a situation you need to

test the hardware on which the application has to be run, to make sure that it can handle the added load your application will place on it. Some of the common hardware tests are: 1. Test the access speed: are there enough communication channels to ensure an acceptable response timed when a user logs onto a terminal while running the application. 2. Test the processing speed: does the hardware meet the throughput or turnaround all requirements of the users production schedule does it process transaction at acceptable rate? 3. Test the storage capacity: do the disk drive store the volume required. 4. Test the peak load: when all the users are logged into the

application, doing all possible operations - data entry, processing, printing, backups etc, does turnaround time, access speed or response time decrease to unacceptable level. 6.4 Testing Strategy/Plan of candidate system No special test strategy needed, testing to be done based on the requirement specs mentioned above. The suggested areas are:

Login/logout by Individual users. Appearance of all the features as described above along

with the functional requirements.

Testing of database updating from user inputs. View created as output from the inputs from database. Test validations as mentioned above. Test creating and deletion of rows in the tables mentioned in the section requirements.

Test the users ability to move to any part of the screen.

Test the last updated date of the-application.

Some of the common errors that were encountered during the development of this software were as follows:

Algorithmic errors: is one in which a program module or logic does not produce the proper output for a given input because something is wrong with the processing step. Typical algorithmic errors are: o Branching too soon.
o

Branching too late.

o Testing for wrong condition. o Forgetting to initialize variables or set loop invariant.
o

Forgetting to test for a particular condition.

o Comparing variables of inappropriate data type.

Syntax errors: when checking for algorithmic errors, we should also check syntax errors. We should make sure that we have properly used the constructs of the programming

language.

Computation

errors:

these

errors

occur

when

the

implementation of a formula is wrong or does not compute the result to required degree of accuracy.

Performance errors: they occur when the system-does not perform at the speed prescribed by the requirements. They are timing errors of different sorts.

6.5 Error Handling: Suitable error messages may be displayed while error is encountered while validations are done. Since the above type of validations is simplistic no specific error handling mechanism is described. In most of these error conditions the application would not allow the user to save the information before a correct entry is found.

System implementation
7.1 SYSTEM REQUIREMENTS: HARDWARE: 1. PENTIUM PROCESSOR 2. 256 MB RAM (recommended) 3. 40 GB MEMORY SPACE 4. KEYBOARD 5. MOUSE 6. COLOR MONITOR SOFTWARE: Operating System: Any of the below given Operating Systems can be used for the system generated: 1. WINDOWS 98 2. WINDOWS 2000 3. WINDOWS XP Software Needed: Turbo C++/ Visual C++

Post implementation and maintenance 8.1 Post implementation: Operational systems are quickly taken for granted. Every system requires periodic evaluation after implementation. A post implementation review measures the system's performance against predefined requirements. The post implementation review conducted by our system enforcer helped us to determine how well the system continues to meet the performance specifications. It also provided us with information to determine whether major redesign is necessary. The post implementation review conducted can be considered as an evaluation of a system in terms of the extent to which the system accomplishes the stated objectives and actual project cost exceeds initial estimate, it was a review of major problems that need converting and those that surfaced during the implementation phase. This post implementation review is conducted as per the following steps: 1. Request for review: the company requested to conduct a review session so that all the phases of software development are covered and no portion is left untouched. 2. A review plan: was created around the objectives of reviews. 3. Administrative plan: the review group probes the effect of the operational system on the administrative procedures of the user.

4. Hardware plan: the hardware of the new system is also reviewed so that no system failure is detected at the end moment. 5. Documentation review plan: the reason for developing a documentation review plan was to evaluate the accuracy and completeness of the software developed and documentation compiled till the date of installation of this software. Irregularities prompt action where changes in documentation would improve the format and content. 8.2 Software maintenance: Maintenance is the enigma of system development. It holds the software industry captive, typing up programming resources. Analyst and programmers spend far more time in maintaining the software than they do in writing them. Maintenance of software has two basic features: Maintenance of hardware. Maintenance of coding developed. The problem of software distortion and malfunctioning takes place because software is a handmade product designed in an ad-hoc fashion with few standards; it comes out late; it is poorly documented and therefore it is difficult to maintain. Some of the major problems associated with maintenance section of project development are:

I. II.

Few tools and techniques are available for maintenance. Standard procedures and guidelines are poorly defined and enforced.

III. Programs are often maintained without care for structure and documentation. IV. There are minimal standards for maintenance. Most programmers view maintenance as low-level drudgery, It is obvious that the more carefully a system is thought out and developed, with attention paid to external influence over a reasonable lifetime, the less maintenance will be required. Maintenance can be classified as corrective, adaptive or perfective. Corrective maintenance: means repairing processing or performance failures or making changes because of previously uncorrected problems or false assumptions. Adaptive maintenance: means changing the program function. Perfective maintenance: means enhancing the performance or modifying the programs to respond to the users additional or changing needs. Of these types more time and money are spent on perfective than a corrective and adaptive maintenance together. Our maintenance would cover a wide range of activities including correcting coding and design errors, updating documentation and test data and upgrading user support. Many

activities classified as maintenance are actually enhancements. Maintenance means restoring something to its original condition. Unlike software hardware does not wear out, it is corrected. Although software does not wear out like hardware it ages and eventually fails to perform because of culminate maintenance. Over time the integrity of program, test data and documentation degenerates as a result of modification. One of the biggest problems encountered with software maintenance is its labor-intensive nature. Altering the code no matter how slight, must be manually introduced into each program because there is no easy way of making sure that the changes will interface with all the programs. It is an error prone process that is still perceived by many as more cost effective than writing programs from scratch. Some of the things that have to be kept in mind while maintaining this software are as follows:

Always make sure that the system has sufficient capacity to store the data about all the customers. Make sure that the software is properly shut down before quitting. Make sure that not much fiddling is done with the coding part. Make sure that the printers are properly installed. Make sure that no corrupt floppy disk drives are inserted into the system.

Make sure that an antiviral is used from time to time to protect the system from crashing.

8.3 Reliability: The reliability features that are necessary condition for successful implementation are:
a) b)

The users should be able to access the profile. The user should be able to visit all sections and take functional actions of the various features in the Module. The user combo boxes must show relevant choices for user to choose. The User must be able to save the information entered in the sections when moving across sections. Error messages to be displayed if the user tries to move from one section to other without saving. The user should be able to view and print his/her profile. The viewer should be able to see the date on which the profile was last updated.

c)

d)

e) f)

8.4 Transaction Volume and Data Volume: The volume of data does not seem significant enough to have an impact on the system. This shall be as per the functional requirements detailed above. 8.5 Legal

A note shall be available in the user module "getting started section where in it shall be mentioned that the data gathered from this system shall be kept confidential and within restricted policies of the company and shall not be used for any discriminatory practices. 8.6 Scope of improvement: The Software Requirement Specifications describes the application and its features for use by the user and the Organization

The application aims at capturing detailed profile or the

employees in the organization in order to be able to take relevant operational decisions.

The application would aim at capturing these details

through user module meant for team members which eventually shall be updated into the database for a variety of use described henceforth.

This application is not meant to replace human

intervention in Banking functions related decisions but acts as a support tool to take fact based decisions.

With this inventory in place the organization would

benefit tremendously in terms of availability of information related to Banking functions. This shall provide inputs to various subsystems like: I. Resource Identification/Allocation.

II. III. IV.

Inventory analysis. Reports to Sales and marketing. Training and development (with very useful inputs) Any other uses as planned.

V.

Depending on bank's request the software was developed with some of the basic features that were common to all. Some of the common features that were included in this software were: o Enquiry
o

Addition Edit (modification of existing records)

o Deletion
o

But keeping in mind the growing tendencies of the Bank this software was developed in a manner that it can always adjust to the growing needs of the industry and update its software capabilities as per requirement. Since the banks expect competition form some of the upcoming industries so it had approached us that in the software developed there should always be room for improvement.

8.7 User manual For the efficient working of the software and keeping in mind the

ease of use of user a small training session will be conducted. This was very fruitful for company and its staff. But Use Manual Again not required since all instructions shall be available on the User Interfaces.

COST ESTIMATION
COCOMO MODEL:

In his book Software Engineering Economics", BARRY BOEHM introduces a hierarchy of software estimation models bearing the name COCOMO, for Constructive Cost, Model. BOEHMS hierarchy of models takes the following form: Model 1: The Basic COCOMO model computes software development effort (and cost) as a function of program size expressed in estimated lines of code. Model 2: The intermediate COCOMO model computes software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes. Model 3: The Advanced COCOMO model incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering process. BASIC COCOMO MODEL Software

ab

bb

cb

db
0.38 0.35 0.32 software

Project Organic 2.4 1.05 2.5 Semi-organic 3.0 1.12 2.5 Embedded 3.6 1.20 2.5 The COCOMO models are defined for three classes of projects. Using BOEHMS terminology these are

(1) ORGANIC MODE - relatively small, simple software projects in

which small teams with good application experience work to a set of less than rigid requirements (e.g., a thermal analysis program developed for a heat transfer group) (2) SEMI- DETACHED MODE - an intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements (e.g., a transaction processing system with fixed requirements for terminal hardware and database software). (3) EMBEDDED MODE - a software project that must be developed within a set of tight hardware, software and operational constraints (e.g., flight control software for aircraft) The Basic COCOMO equations take the form: E=ab(KLOC)bb D= cb(E)db Where E is the effort applied in person-months, D is the development times in chronological months, and KLOC is the estimated number of delivered lines of code for the project (expressed in thousands). The coefficients ab and cb and the exponent bb and db are given in above table. The basic model is extended to consider a set of "cost driver attributes" that can be grouped into four major categories : product attributes, hardware attributes, personnel attributes and project

attributes. Each of the 15 attributes in these categories is rated on a six-point scale that ranges from "very low" to "extra high" (in importance or value). Based on the rating, an effort multiplier is determined from tables published by BOEHM, and the product of all effort multipliers results is an effort adjustment factor (EAF), typical value for EAF range from.0.09 to 1.4, the intermediate COCOMO model takes the form: E={ai(KLOC)bi}*EAF Where E is the effort applied in person-months and KLOC is the estimated number of delivered lines of code for the project. The coefficient a and the exponent b is given in above Table. Today, a software cost estimation model is doing well if it can estimate software development costs within 20% of actual costs, 70% of the time, and on its own turf (that is, within the class of project to which it has been calibrated) This is not as precise as we might like, but it is accurate enough to provide a good deal of help in software engineering economic analysis and decisionmaking. 9 Conclusion: The system has been developed as per the requirements of the any bank in general. All the expectations of the industry have been

lived unto. All the problems that were listed in the problem definition have been corrected and certain extra features have been added to make sure changes can be incorporated to the system at latter stages

10. References
E-Balaguruswamy.:Complete reference in C++

JALOTE P.: An Integrated Approach to Software Engineering, Narosa, 2002 RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY, F., and LORENSEN, W.: Object Oriented Modeling and Design, Prentice-Hall, August 2002 NAVATHE, S., B., ELMASRI, R.: Fundamentals of Database Systems, Pearson Education Asia, 2000