Project Docu

8/2/2019 Project Docu

1/89

INTRODUCTION

There is an old saying that HUMAN MEANS ERROR. Especiallyin 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. Guarantee of no error

2. Data Security

3. Data Privacy

4. Data Consistency

5. Atomicity of data6. 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.


2/89

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.


3/89

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

PROBLEMS

DESIRABLE

FEATURESStaff

Members

-Have to manually

feed in all the

records with

corresponding

dates.

-Have to keep

updated version

locally of their

Reference

-Maintained a new banking

system on computers will

help the staff members with

computer generated updates

and also printable copy

available for reference

Account

Holders or

Customers

-Not able to get

their records

quickly

-Have to wait much

to verify their

identity.

-A lot of time will be saved

verification would be easy

and quick.


4/89

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.

2. 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.

3. Integrity Problem: That data values stored in the records must

satisfy certain types of consistency constraints. The problem


5/89

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.

5. 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.

These difficulties, among others have prompted the development of

this software.


6/89

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.


7/89

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.


8/89

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


9/89

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


10/89

often I

funneled downward and carried out by lower- management.

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.


11/89

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 meetthem?

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


12/89

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.


13/89

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.


14/89

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


15/89

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 staffis

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


16/89

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


17/89

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


18/89

Source of ideasOrganizationBased

Environment

Based

Impetus

For

Change

Organization

Top

Management

User

System Analyst

Govt. rules

And

Regulations

Consumers

Union

Competition

Recognition ofneed

Feasibility Study

Analysis

Design

Implementation

PostImplementation

Maintenance


19/89

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


20/89

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


21/89

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.


22/89

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 generalizedsystem 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


23/89

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


24/89

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.


25/89

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


26/89

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 importantto justify

the solutions. To do this it is necessary to determine whether the

solutions are feasible.


27/89

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:

Theireconomic 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.

Theirtechnical feasibility: To find this, it was asked whether

the technology needed is available and if available whether it

is useable.

Theiroperational 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 timeis 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.


28/89

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


29/89

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 day-

to-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


30/89

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


31/89

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


32/89

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


33/89

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. Pentium Processor

2. 128 MB RAM

3. 40 GB Memory Space

4. Keyboard

5. Mouse

6. 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


34/89

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


35/89

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 theintroduction 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


36/89

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


37/89

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


38/89

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


39/89

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.


40/89

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:


41/89

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 theinterview.

In an interview since the analyst and the person interviewed meet

face to face, there is an opportunity for flexibility in eliciting


42/89

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.


43/89

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 essayquestion.

Types of questionnaire

Interviews and questionnaire vary widely in form and


44/89

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 are fixed-

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 questionsimprove the reliability of the responses by ensuring that all

subjects are responding to the same questions.

3.1.5 Questionnaire


45/89

{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

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

SQL

C++


46/89

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?


47/89

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


48/89

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


49/89

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.


50/89

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, toassess 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


51/89

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".


52/89

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

Business

Conditions

Business

Conditions

PeoplePeopleDevelopment

Environment

Development

Environment

TechnologyTechnology

ProductProduct

ProcessProcess


53/89

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 importantmetrics.

Following steps given above, a simple defect distribution can be

developed. For the pie-chart noted in the figure, eight causes of


54/89

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 size-

oriented 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 otherprojects, lines of code is chosen.

A set of simple size-oriented metrics can be then developed

for each project:


55/89

- 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

months)

Cost

(in

Rs)

Pages of

Documentation

Errors

Banking

System

1226 6 .. 189 ..

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-


56/89

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


57/89

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.2Logical 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


58/89

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


59/89

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:


60/89

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.

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

A

B C


61/89

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. Asquare: defines source or destination of system data.

2. An a rrow: 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

A

B C

o

p q


62/89

DFD At Level 1:

Display

message

and

status

Display Screen to

enter the Password

Interact

with users

Configure

system by

Administr

ator

Configuration

Information


63/89

DFD Level 2: Expanding interact with users

Interactwith user

AboutScreen

s

Configure

System

ScreenDetails

Adding/Editing

Particular

Information


64/89

DFD Level 3: Particular Information

Particular

Information

Account

Account

Number

Account

Type

Amount

Configure

System

NameAddress


65/89

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.


66/89

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 thatis 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


67/89

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.

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

EntryFunction

A

Function

B

Exi

t


68/89

condition is no longer true, the program continues with the next

structure. Do-while or do-until are some of such functions.

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:

Entr

yFunction

A

Con

diti

onExit


69/89

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 that is external to the program.

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.

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


70/89

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: to ensure that all the functional

requirements, that customers would use to accept the

product are covered.

3. Testing documentation: to ensure that all the

functional requirements, acceptance requirements are

covered.

4. Performance and acceptance testing: to ensure


71/89

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 oftesting where individual components (which may be functions

routines/programs) are tested to ensure that they operate correctly.

In a properly designed system, each component


72/89

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


73/89

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


74/89

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


75/89

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.


76/89

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++


77/89

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.


78/89

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:


79/89

I. Few tools and techniques are available for maintenance.

II. 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


80/89

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

labor-intensive nature. Altering the code no matter how slight, must be manu

introduced into each program because there is no easy way of making sure th

the changes will interface with all the programs. It is an error prone process th

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 softwa

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.


81/89

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) The users should be able to access the profile.

b) The user should be able to visit all sections and take

functiona

Documents

Project Docu