Actual Project Documentation

8/2/2019 Actual Project Documentation

1/80

PROJECT DOCUMENTATION

Introduction Of project

Financial Accounting in today's business world, is concerned with collecting,

recording, evaluating and communicating the result of monitory transactions

having some specific purpose and value. Every organization maintain their

accounting information system to know their market value, revenue condition,

asset value, sale value and profit/loss, to identify problems and taking business

decisions at any point in time.

Development of a Budget And Fund Monitoring System for medium sized

organization is accumulation and maintenance of the day-to-day financial

transactions under appropriate heads as instructed by the business firm. The system

must let the accountant to create various accounting heads. Based on the recorded

transactions, system should generate accurate reports, which would reflect the

gross amount allocated after the end of financial year. In addition all possible

reports that would be demanded out of the Fund Allocation system should be

generated.

The realization of the goals of the Vision 2020 requires, among other things, a

growth-oriented and sustainable public finance environment. Sound fiscal policy


2/80

can yield the amount of resources appropriate to the program. However, an

improvement in public services and expanded state development programs depend

crucially on an increase in the efficiency of public expenditure and the

effectiveness with which financial resources are used.

Emphasis is being placed on mainstreaming communication planning within the

Programme of Work and Budget formulation exercise, to ensure effective links

between communication activities and key programmes, and to involve

decentralized offices more fully in the process. Understanding and responding to

the expectations of key target audiences - including government decision-makers,

bilateral donors, multilateral agencies, international financing institutions,

technical counterparts, the scientific and research community, non-governmental

and civil society organizations, the private sector and medium-sized agricultural

producers - will remain a priority.

Modernization of the Revenue Sectors has being the top priority of the

Government, so the State Unit took up the challenge of computerizing the

Treasuries of all the State Districts and the Budget Directorate.


3/80

Company Profile

Corporate Profile:

Established in March 1988, as a Scientific Society of the Department of

Information Technology (formerly, Dept. of Electronics), Ministry of

Communications and Information Technology (formerly, Ministry of Information

Technology), Government of India, The Centre for Development of Advanced

Computing (C-DAC), is primarily an R & D institution involved in the design,

development and deployment of advanced Information Technology (IT) based

solutions.

In a little over a decade since inception, C-DAC has developed and supplied

a range of high performance parallel computers, known as the PARAM

series of supercomputers. C-DAC's development activities in this area have

been mission oriented and driven by its mission objectives, both in

technology and application developments.

Over the years, C-DAC has diversified its activities to address requirements

in various areas, consequently, our expertise also extends to other advanced

areas of Information Technology, enabling IT based solutions in areas like

Financial and Capital market simulation and modeling,Network and Internet
http://www.cdac.in/html/param.asphttp://www.cdac.in/html/about/mission.asphttp://www.cdac.in/html/finance/finidx.asphttp://www.cdac.in/html/nisg/nis.asphttp://www.cdac.in/html/param.asphttp://www.cdac.in/html/about/mission.asphttp://www.cdac.in/html/finance/finidx.asphttp://www.cdac.in/html/nisg/nis.asp


4/80

Software, Healthcare, Real Time Systems, eGovernance, Data Warehousing,

Digital library, Artificial Intelligence and Natural language processing.

As part of its development activities C-DAC has been awarded a number of

sponsored R & D projects, by the Department of Information Technology,

Department of Official Language (DOL), Department of Science and

Technology (DST), Department of Scientific and Industrial Research

(DSIR), Department of Culture, Department of Biotechnology etc.

Vision Of C-DAC:

To emerge as the premier R&D Institution for the design, development and

deployment of world class IT solutions for economic and human advancement.

Mission Of C-DAC:

The Mission Statement as defined below, reflects the fabric and

character of C-DAC and integrates in the fulfillment of C-DAC's Vision.
http://www.cdac.in/html/nisg/nis.asphttp://www.cdac.in/html/medinfo/mercury.asphttp://www.cdac.in/html/rtsg/rtsgidx.asphttp://www.cdac.in/html/egovidx.asphttp://www.cdac.in/html/nisg/nis.asphttp://www.cdac.in/html/medinfo/mercury.asphttp://www.cdac.in/html/rtsg/rtsgidx.asphttp://www.cdac.in/html/egovidx.asp


5/80

To carve out a niche in the global arena of advanced Information

Technology and enhance our brand image.

To continue to create and deploy the finest talent in our quest for

further expanding the frontiers of High Performance Computing and

Communication Technologies and its applications.

To achieve rapid and effective spread of knowledge by overcoming

language barriers using Natural Language oriented computing and

Multimedia Technologies.

To share our vast reservoir of experience for education and knowledge

enrichment in the field of Information Technology.

To utilize the intellectual property thus generated, bring benefits of

Information Technology to Society, by converting it into an exciting

business opportunity and establishing a self-sustaining and wealth

creating operation.

Work Environment:

C-DAC's focus on diversity in research and work creates a competitive

advantage for our customers, our employees, and our company.

Every day, at all levels of C-DAC's business, we strive to create an

environment of trust and respect, where each individual is included and

valued. This environment enables all C-DAC members to develop and

contribute to their full potential.


6/80

The Human Resource group in C-DAC is continuously involved in

effectively implementing its philosophy of employee centric policies, a great

learning platform, freedom to think, evolve and implement and an informal

work culture that is second to none. Thus creating a conducive work

environment to facilitate the C-DAC employees to develop and contribute in

keeping with the stated Vision & Mission objectives of C-DAC.

C-DAC is committed to conducting its business in an ethical, socially

responsible and environmentally sustainable manner. This commitment is

consistent with our corporate objectives and is essential to continued

business success.


7/80

Context Of The Project

The Government recognizes the need to strengthen its financial management

framework to achieve overall fiscal discipline and better resource allocation

and use. This requires measures to :

(i) provide accurate and timely financial information on the

actual and budgeted revenue.

(ii) reconcile and identify variations between planned and

achieved outputs and other performance indicators.

Financial and performance information should be designed to fill the needs

of the various users of this information project and program implementers,

those carrying out the monitoring functions, decision makers, and the public

at large. For this, as well as effective public service delivery, it is necessary

that the line departments are endowed with greater functional freedom and

more important, held accountable for the delivery of services and

performance. The day-to-day financial management intervention by the

Finance Department on behalf of the departments should yield place to a

partnership based on allocation of resources, and utilization of resources,

with the latter job firmly in the hands of the line departments. Towards this

end, the Departments would be delegated enhanced financial powers, and

would over the medium term be held responsible for payments, accounting

and accountability.


8/80

Each and every department and all their administrative units perform certain

core regulatory, promotional, developmental or technical functions relevant

to each one of them. In addition, all of them need certain common support

services to enable them to perform their respective core functions. Such

support functions are housekeeping, security, maintenance, and logistical

support etc. as well professional services. Whenever there is a need for such

services, the government will permit the administrative departments and

units to outsource these services.

Each department will designates a senior officer to serve as advisor (without

line responsibilities or financial auditing authority) to the head of department

on management and efficiency issues, impact of department operations, and

analysis of policies and program implementation and utilization of benefits.

In parallel, the internal organization of departments will be modernized and

streamlined.

The main purposes of such a framework are to provide a realistic estimate of

the margin of resources available to finance the new programs needed to

implement new policies, and prevent expenditure from exceeding available

resources. It is during the annual budget preparation process that new

Sectoral policies should be established, and the available margin of

resources allocated to departments accordingly. Thereafter, the programs

implementing those policies would themselves become on-going programs

and their funding needs would be systematically provided for in the

medium-term framework.


9/80

Existing System

In the existing system, there are at least two layers engaged in the

verification of documents one in the department and another in the

Treasury. The costs of the latter operations remain to be justified in terms of

effectiveness. An alternative is to decentralize, selectively these payment

operations, other than payroll and pensions, in the departments.

Allocation of resources should be in line with the targets set. Inadequate

allocation leads to insufficient infrastructure. Funds transfer should be based

on performance with specific focus.

It has been observed that many Corporate Organizations are unable to fully

utilize the fund allocated to them. The improper use of fund leads to serious

problems that ultimately hamper the Corporate-planning goal that it has set

forth. It is also required that allocated fund should be utilized within the time

frame to achieve the goal of the organization.


10/80

Drawbacks Of Existing System

The present system faces the following drawbacks:

It does not enable proper coordination among different signing

authorities.

There is a lack of fingertip information about the current status of the

allocated fund etc.

It has also been found that there is a need of transparency among the

signing authority to make the entire system workable.

Till now, treasuries have been maintaining manually grant-wise budget

sanctions released from the departments. This leads to a pooling of the

grants and it becomes difficult for the treasury to maintain the expenditure

record in a particular scheme. Hence, a computerized Budget Control

System has been developed to overcome this problem and help the treasury

in maintaining accurate records.

Proposed System

The proposed system is aimed to overcome all the above-mentioned problems. The

present system is manual one and it is in adequate to cater the need of growing client


11/80

database. The new system will be an Internet solution, supported by an intranet

application.

To ensure proper monitoring, the operations that will be computerized from the outset

and establish an online system with simultaneous access to the Department of

Finance.

The major objective of the Project was to bring transparency between the

money allocation to the departments and the actual receipts and payments. In

addition, envisage of an accurate and speedy accounting pattern, proper

budgeting, timely reporting etc.

The purpose of the proposed system is to rectify the above-mentioned problems. It

provides a computerized solution for mapping the financial activities of the

organization facilitating an efficient coordination among the signing authorities .To

achieve the above task the development work can be categorized in two segments.

The accounting of transactions and reporting on them frequently, has to be facilitated

by the recent efforts to strengthen treasury and pay accounts offices. The future in this

regard would be including that the department would be entrusted with accounting

responsibility. A network system would be established linking the computers of

departments, giving enhanced freedom to the line departments to levy, collect, and


12/80

utilize user charges is done within the overall framework of the accounting framework

of the consolidated Fund of the government.

The project has aimed at co-relating money allocated, to the actual payments

and receipts in the case of each department. This would also lend

transparency to all government transactions. Coverage that computerization

would introduce several other invigorating factors such as an accurate and

speedy accounting pattern, proper budgeting and timely reporting.

Structure of the Proposed System

Study of the Existing

System

Problem Identification

Fund Monitoring System

Intranet Application Internet Application

Oracle 8i, Developer 2000


13/80

Intranet Application :

This application will run on local office network and enable fund allocation.

Internet based Application:

This application will enhance the over all process to facilitate the following

objectives

Online bill submission

Online request for monetary aid

Online payment


14/80

The Project has been taken up in a phased manner and the main components

include :

(i) State Annual Budget Grant This module describes the budget

amount for the current year for a specific organization.

Monitoring of the contingency fund, which is spent

throughout the year for expenditures is computerized.

(a) It also enables the management to allot various entitlements to

the executives of different categories. It equips the executives

with financial power required for business transactions.

(b)The funds allocated to the executives are further distributed to

the departments.(c) Plan-wise distribution of the funds are also commenced by the

entitled executives.

(ii) Fund Manager - Each department designates a senior officer to

serve as advisor with responsibilities and financial auditing

authorities to head the department on management and

efficiency issues, impact of department operations, and

analysis of policies and program implementation and

utilization of benefits.


15/80

(iii) Monitoring Of Expenses - The Organizations tentatively

categorizes the expenses into two parts, one being the Planned

Expenses and the other being the General Expenses. Planned

Expenses being the amount spent on specific entitled projects.

The executive is required to submit the bills of the expenses

incurred during transaction. The bills include fooding,

lodging, tours and travels and purchase expenses.

(iv) Fund Re-Allocation/ Cancellation This module has been

developed to monitor the budget release, once it is approved

by the signing authority. It deals with sending as well as

processing of request for monetary aid. It includes emails sent

by the executives to their superiors. Processing results in

acceptance or rejection of monetary request based on certain

grounds.

Based on request processing results the executives sanction

fund and payment is made with the help of core banking. Core

banking enables the executives to bear the transaction

expenses by transferring money directly to the concerned

party in tie up with the executives organization for corebanking or through the executives account.

(v) Budget Control System This user-friendly software having

modular approach has been developed with an objective of


16/80

helping the management with timely data for monitoring of

expenditures on schemes and also to secure itemized control

on expenditure.

Feasibility Study

Feasibility study is a study carried out to select the best system that meets

performance requirements. This entails identification, description, and

evaluation of candidate systems and selection of the best system for the job.

Many feasibility studies are disillusioning for both users and analysts. First,

the study often presupposes that when the feasibility document is being

prepared, the analyst is in a position to evaluate solutions. Second, most

studies tend to overlook the confusion inherent in the system development.

The most successful system projects are not necessarily the biggest or most

visible in a business but rather those that truly meet user expectations.

Feasibility Considerations:

There are basically three considerations involved in the feasibility analysis:

economic feasibility, technical feasibility, and behavioral feasibility.


17/80

Economic Feasibility:

The most frequently used method is the Economic Feasibility for evaluating

the effectiveness of a candidate system. Most commonly known as

cost/benefit analysis, the procedure is to determine the benefits and savings

that are expected from a candidate system and compare them with costs. If

benefits outweigh costs, then the decision is made to design and implement

system. Otherwise, further justification or changes in the proposed system is

made if it is to have a chance of being approved. This method improves theaccuracy at each phase of the system life cycle.

Technical Feasibility :

Technical feasibility centers around the existing computer system and to

what extent it can support the proposed addition. It involves financial

considerations to accommodate technical enhancements. If the budget is a

serious constraint, then the project is judged not feasible.

Behavioral Feasibility :


18/80

People are inherently resistant to change, and computers have been known

to facilitate change. An estimate should be made of how strong a reaction

the user staff is likely to have toward the development of a computerized

system. It is common knowledge that computer installations have something

to do with turnover, transfers, retaining and changes in employee job status.

Therefore, it is understandable that the introduction of a candidate system

requires special effort to educate, sell and train the staff on new ways of

conducting business.

Steps In Feasibility Study :

Feasibility study involves eight steps:

a) Formation of a project team and appointment of a project leader.

b) Preparation of System Flowcharts.

c) Enumeration of potential candidate systems.

d) Description and identification of characteristics of candidate Systems.

e) Determination and evaluation of performance and cost effectiveness

of each candidate system.

f) Judgment of system performance and cost data.

g) Selection of best candidate system.

h) Preparation and reporting of final project directive to management.

Formation of project team and appointment of a project leader


19/80

Projects are planned to occupy a specific time period, ranging from several

weeks to months. The concept to form a team is that future system users

should be involved in its design and implementation. Their knowledge and

experience in the operations area are necessary for the success of the system.

The team consists of analysts and user staff to devise a solution to the

problem.

The senior systems analyst who is the most experienced analyst in the team

is appointed as the project leader. Regular meetings are scheduled to keep up

the momentum and accomplish the mission.

Preparation of System Flowcharts

Information oriented charts and data flow diagrams prepared in the initial

investigation are reviewed at this time. The charts bring up the importance of

inputs, outputs and data flow among key points in the existing system.

Enumeration of potential candidate systems


20/80

This step identifies the candidate systems that are capable of producing the

outputs included in the generalized flowcharts. This requires a

transformation from logical to physical system models. Another aspect of

this step is consideration of the hardware that can handle the total system

requirements. An important aspect of hardware is processing and main

memory.

Description and identification of characteristics of candidate Systems

From the candidate systems considered, the team begins 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 can and cannot do.

Determination and evaluation of performance and cost effectiveness

of each candidate system


21/80

Each candidate systems performance is evaluated against the system

performance requirements set prior to the feasibility study. Whatever the

criteria, there has to be a close match as practicable, although tradeoffs are

often necessary to select the best system.

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 system is likely to be the most cost of each system to

determine which system is likely to be the most cost effective and also meets

the performance requirements.

Costs are more easily determined when the benefits of the system are

tangible and measurable.

Judgment of 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


22/80

feasibility study. Certain procedures are applied to weigh a candidate system

such as assigning a weighting factor to each evaluation criterion based on

the criterions effect on the success of the system, assigning a quantitative

rating to each criterions qualitative rating, multiplying the weight assigned

to each category by the relative rating to determine the score, and summing

the score column for each candidate system.

Selection of best candidate system

The system with the highest total score is judged the best system. Most

feasibility studies select from more candidate systems. The criteria

chosen and the constraints are also more complex.

Preparation and reporting of final project directive to management

The culmination of the feasibility study is a feasibility report directed to

management. The report is a formal document for management use, brief

enough to provide the basis for system design. Analysts usually decide on

a format that suits the particular user and system. Most reports, however ,


23/80

begin with a summary of findings and recommendations, followed by

documented details.

The report contains the following sections:

(i) Cover letter briefly indicates to management the nature, general

findings, and recommendations to be considered .

(ii) Table Of Contents specifies the location of the various parts of the

report management quickly.

(iii) Overview is a narrative explanation of the purpose and scope of

the project, the reason for undertaking the feasibility study and thedepartments involved or affected by the candidate system.

(iv) Detailed Findings outline the methods used in the present system.

The systems effectiveness and efficiency as well as operating

costs are emphasized.

(v) Economic justification details point-by-point cost comparisons and

preliminary cost estimates for the development and operation of

the candidate system.

(vi) Recommendations and Conclusions suggest to management the

most beneficial and cost-effective system

(vii) Appendixes document all memos and data compiled during the

investigation. They are placed at the end of the report for

reference.

System Design


24/80

The process of design involves conceiving and planning out in the mind.

In the software system design, there are three distinct types of activities:

external design, architectural design, and detailed design. Architectural

design and detailed design are collectively referred to as internal design.

External design of software involves conceiving, planning out, and

specifying the externally observable characteristics of a software product.

These characteristics include user display and report formats, external data

sources and data sinks, and the functional characteristics, performance

requirements, and high level process structure for the product. External

design begins during the analysis phase and continues into the design phase.

Requirements definition is concerned with specifying the external,

functional, and performance requirements for a system, as well as exception

handling. External design is concerned with refining those requirements and

establishing the high level structural view of the system.

Internal design involves conceiving, planning out, and specifying the

internal structure and processing details of the software product. The goals

of internal design are to specify internal structure and processing details, to

record design decisions and indicate why certain alternatives and trade-offs

were chosen, to elaborate the test plan, and to provide a blueprint for

implementation, testing, and maintenance activities. The work products ofinternal design include a specification of architectural structure, the details

of algorithms and data structures and the test plan.


25/80

Architectural design is concerned with refining the conceptual view of the

system, identifying internal processing functions, decomposing high-level

functions into sub-functions, defining internal data streams and data stores,

and establishing relationships and inter-connections among data functions,

data streams, and data stores.

Detailed design include specification of algorithm that implement the

functions, concrete data structures that implement the data stores, the actual

interconnections among functions and data structures, and the packagingscheme for the system.

Normalization:

A process known, as normalization is a technique used to group attributes in ways that

eliminates problems. More specifically, the goals of normalization are to minimize

redundancy and functional dependency. Functional dependency occurs when the value

of one attribute can be determined from the value of another attribute. The attribute

that can be determined is said to be functionally dependant on the attribute that is the

determinant. By definition, all non-key attributes will be functionally dependant on

the primary key in every relation. When one attribute of a relation does not uniquely

define another attribute, but limits it to as set of pre-defined values, it is called a multi-

valued dependency. A partial dependency exists when an attribute of a relation is

functionally dependant on only one attribute of a concatenated key. Transitive


26/80

dependency occurs when a non-key attribute is functionally dependant on one or more

other non-key attributes in the relation

Relations are normalized so that when relations in a database are to be altered during

the lifetime of the database, we do not lose information or introduce inconsistencies.

The type of alterations needed for relations are:

Insertion of new data values to a relation. This should bepossible without being forced to leave blank fields for

some attributes.

Deletion of a tuple, a row of a relation. This should be

possible without losing vital information unknowingly.

Updating or changing a value of an attribute of a tuple.

This should be possible without exhaustively searching

all the tuples in the relation.

Ideal relations after normalization should have the following properties so that the

problems do not occur for relations in the (ideal) normalized form :

No data value should be duplicated in different rows

unnecessarily.

A value must be specified for every attribute in a row.


27/80

Each relation should be self-contained. In other words, if a

row is deleted, important information should not be

accidentally lost.

When a row is added to a relation, other relations in the

database should not be affected.

A value of an attribute in a tuple in a relation may be

changed independent of other tuples in the relation and

other

The idea of normalizing relations to higher and higher normal forms is to attain the

goals of having a set of ideal relations. To determine whether a relation schema is in

one of the desirable normal forms, we need additional information about the real-

world enterprise that we are modeling with the database.

In the process of enhancing the tables in a more normalized form we get higher

normal forms as 1NF, 2NF, 3NF, BCNF, 4NF, 5NF. Each form is an improvement

over the earlier form. A higher normal form relation is asub-set of lower normal form.

The higher normalization steps are based on three important concepts:

Dependence among attributes in a relation.

Identification of an attribute or a set of attributes as the

key of a relation.

Multivalued dependency between attributes.


28/80

First Normal Form:

The first of the normal forms imposes a very basic requirement on relations, unlike

the other normal forms, it does not require additional information such as functional

dependencies.

A domain is atomic if elements of the domain are considered to be individual units.

We say that a relation schema is in First Normal Form

(1NF) if the domains of all attributes of the relation are atomic.

To normalize a relation with composite attributes they need to be converted to

individual attributes. The normalization step consists of first identifying fields within

a composite attribute as individual attributes. After doing this common attributes for a

composite attribute are duplicated, as many times as there are lines in the composite

attribute.

Thus, 1NF removes dependency of non-key attribute on part of a multi-

attribute

Second Normal Form:


29/80

A relation is said to be in 2NF if it is in 1NF and non-key attributes are functionally

dependent on the key attributes. Further, if the key has more than one attribute then no

non-key attributes should be functionally dependent upon a part of the key attributes.

Thus, 2NF removes dependency of non-key attributes on other non-key attributes.

Boyce-Codd Normal Form

If an attribute of a composite key is dependent on an attribute of the other composite

key, a normalization called BCNF is needed. A relation schema R is in BCNF with

respect to a set F of functional dependencies if, for all functional dependencies in F+

(closure of F) of the form , where R, at least one of the following holds

o is a trivial functional dependency

o is a super key for schema R.

A database design is in BCNF if each member of the set of relation schemas that

constitutes the design is in BCNF. To determine whether these schemas are in BCNF,

we need to determine what functional dependencies apply to them.

Often testing of a relation to see if it satisfies BCNF can be simplified:


30/80

To check if a nontrivial dependency causes a

violation of BCNF, compute + (the attribute closure of

), and verify that it includes all attributes of relation

schema R.

To check if a relation schema R is in BCNF, it suffices to

check only the dependencies in the given set of F for

violation of BCNF, rather than check all dependencies in

F+ (closure of F).

Thus, BCNF removes more than one dependent multi-valued dependency from

relation by spitting relation.

Third Normal Form:

There are relational schemas where a BCNF decomposition cannot be dependency

preserving. For such schemas, we have two alternatives if we wish to check if an

update violates any functional dependencies:

Pay the extra cost of computing joins to test for violations.

Use an alternative decomposition, third normal form/

Third Normal Form normalization will be needed where all attributes in a relation

tuple are not functionally dependent only on the key attribute. A table is said to be in


31/80

3NF if it is in 2NF and no non-key attribute is functionally dependent on any other

non-key attribute.

Since BCNF requires that all nontrivial dependencies be of the form , where is

a super key. 3NF relaxes this constraint slightly by allowing nontrivial functional

dependencies whose left side is not a super key.

A relation schema R is in third normal form (3NF) with respect to a set F of functional

dependencies if, for all functional dependencies in F+ of the form , where R

and R, at least one of the following holds:

o is a trivial dependency

o is a super key for R

o Each attribute A in - is contained in a candidate key for

R.

Thus, 3NF removes dependency of an attribute of a multi attribute key on an attribute

of another (overlapping) multi attribute key.

Fourth Normal Form:


32/80

Some relation schemas, even though they are in BCNF, do not seem to be sufficiently

normalized, in the sense that they still suffer from the problem of repetition of

information.

To deal with this problem, we must define a new form of constraint, called a multi-

valued dependency. Use of multi valued dependencies to define a normal form for

relation schemas. This normal form, called fourth normal form (4 NF) is more

restrictive than BCNF.

A data base design is in 4NF if each member of the set of relation schemas that

constitutes the design is in 4NF.The definition of 4NF differs from the definition of

BCNF in only the use of multi-valued dependencies instead of functional

dependencies. Every 4NF schema is in BCNF. If a schema R is not in BCNF, then

there is a nontrivial functional dependency.

Thus, 4NF adds one relation relating attributes with multi-valued dependency to the

two relations with multi-valued dependency.

Fifth Normal Form


33/80

Reduce fourth normal form entities to fifth normal form (5NF) by removing

pairwise cyclic dependencies (appearing within composite primary keys

with three or more component attributes) to three or more parent entities.

This concentrates on problems that arise by representing associations

between multiple entities with interdependencies. Making it 5NF consists of

adding parent tables, one for each meaningful combination that has children

in the original table. A table with such information is 5NF if the information

cannot be represented in multiple smaller entities alone

Domain Key Normal Form

"A key uniquely identifies each row in a table. A domain is the set of

permissible values for an attribute. By enforcing key and domain

restrictions, the database is assured of being freed from modification

anomalies."

This appears to differ from the other normal forms in that it does not seek to

introduce additional tables, but rather ensures that columns are restricted to

valid values.


34/80

Data Flow Diagrams:

Data flow diagrams or the bubble charts are directed graphs in which the

nodes specify processing activities and the arcs specify data items

transmitted between processing nodes. Data flow diagrams can be used at

any desired level of abstraction. A data flow diagram might represent data

flow between individual statements or blocks of statements in a routine, data

flow between sequential routines, data flow between concurrent processes,

or data flow in a distributed computing system where each node represents ageographically remote processing unit.

Data flow diagrams specify data sources and data sinks, data stores,

transformations to be performed on the data, and the flow of data between

sources, sinks, transformations, and stores. A data store is a conceptual data

structure, in the sense that physical implementation details are suppressed

only the logical characteristics of data are emphasized on a data flow

diagram. Data sources, data sink and transformations are depicted by

rectangles, and data stores by open-ended rectangles. The arcs in a data flow

diagram specify flow of data. They are labeled with the names of data items

whose characteristics are specified in the data dictionary.

Data flow diagrams are excellent mechanisms for communicating with

customers during requirements analysis, they are also widely used for


35/80

representation of external and top-level internal design specifications. In

latter situations, data flow diagrams are quite valuable for establishing

naming conventions and names of system components such as systems, files,

and data links.

The DFD model uses a very limited number of primitive symbols,

which are described below:

External entity Process Data store

Data flow Output


36/80

Primitive symbol used for constructing DFDs

Function symbol. A function is represented using a circle. This

symbol is called a processor or bubble.

External entity symbol. A rectangle represent an external entity

such as a librarian, a library member etc. the external entities are

essentially those physical entities which are external to the software

system and interact with the system by inputting data to the system or

by consuming the data produced by the system.

Data flow symbol.A directed arc or an arrow is used as a data flow

symbol. A data flow symbol represents the data flow occurring

between two process or between an external entity and a process in

the direction of the data flow arrow.

Data store symbol. Open boxes are used to represent data stores.

A data store represents a logical file , a data structure or a physical file

on disk.


37/80

Dataflow diagram

Bill Submission

Monetary Queries

Monetary Request Fund Allocation

Payment

Abstract Level DFD (Level 0 DFD)

E

C

U

T

I

V

E

e

c

AN

A

G

E

M

E

N

T

E

0

Fund

Monitoring

System


38/80

LEVEL 1 DFD

Modules And Descriptions:

(i) State Annual Budget Grant This module describes the budget

amount for the current year for a specific organization. Monitoring

FundFund

Allocation

Process

Fund Distribution

Process

Bill

Submission

Process

Si nin Authorit

Allocation DetailsEm lo ee Dtata File

Allocation Data File

Allocation ID

Auth Id

Bill No

Ex anse Doc

Ex anse Details

Expanse

12

3

Report

Fund

Request

Proposal

ProposalID

Proposal RefusalData File


39/80

of the contingency fund, which is spent throughout the year for

expenditures is computerized.

a. It also enables the management to allot various entitlements to

the executives of different categories. It equips the executives

with financial power required for business transactions.

b. The funds allocated to the executives are further distributed to

the departments.

c. Plan-wise distributions of the funds are also commenced by theentitled executives.

(ii) Fund Manager - Each department designates a senior officer to

serve as advisor with responsibilities and financial auditing

authorities to head the department on management and

efficiency issues, impact of department operations, and

analysis of policies and program implementation and

utilization of benefits.

(iii) Monitoring Of Expenses - The Organizations tentatively

categorizes the expenses into two parts, one being the Planned

Expenses being the amount spent on specific entitled projects and

the other the Non- Planned Expenses which specify amount spent

as general expenses . The executive is required to submit the bills


40/80

of the expenses incurred during transaction. The bills include

fooding, lodging, tours and travels and purchase expenses.

(iv) Fund Re-Allocation/ Cancellation This module has been

developed to monitor the budget release, once it is approved by the

signing authority. It deals with sending as well as processing of

request for monetary aid. It includes emails sent by the executives

to their superiors. Processing results in acceptance or rejection of

monetary request based on certain grounds.

Based on request processing results the executives sanction fund and

payment is made with the help of core banking. Core banking

enables the executives to bear the transaction expenses by

transferring money directly to the concerned party in tie up with the

executives organization for core banking or through the executives

account.

(v) Budget Control System This user-friendly software having

modular approach has been developed with an objective of

helping the management with timely data for monitoring ofexpenditures on schemes and also to secure itemized control

on expenditure.


41/80

Data Dictionary:

A Data Dictionary is used to define and record data elements, and processing

logic representations, such as decision tables and structured English, are

used to specify algorithmic processing details. Processing logic

representations are used to precisely specify processing sequences in terms

that are understandable to customers and developers. Entries in a data

dictionary include the name of the data item, and attributes such as the data

flow diagrams where it is used, its purpose, where it is derived from, its subitems, and any notes that may be appropriate. Each named data item on each

data flow diagram should appear in the data dictionary. Data Dictionaries

can be used in conjunction with structure charts to specify data attributes and

data relationships.

The details of the tables and its structures are explained as below:

State Annual Budget Grant: This module describes the budget

amount for the current year for a specific organization. To understand

this module we specify further three divisions namely

Budget amount for the current year.

Department wise fund distribution

Plan wise fund distribution


42/80

The Budget amount for the current year has being specified by the

relation Fund_allocation. This table has the attributes Year, Amount, and

Balance Amount. The attribute year describes the year for which the amount

is being allocated. The attribute Amount specifies the amount being

sanctioned by the treasury for the organization. The last attribute Balance

amount denotes amount left as balance after being used for the specified

objectives.

The department wise fund distribution is a sub module, which gives the

details on how the allocated amount can be distributed to the various

departments. Additional information about the departments can be inferred

from the table dept. This table gives information of the department number

and their respective department names This has been specified in the table

Dept_fund. The attributes related to this table and their descriptions are

given as below:

Deptno Organizations are composed of various

departments, each of which is responsible for performing a

definite task as directed by the governing body. To

differentiate each department from the other to avoid

ambiguity a distinct identification is given to each

department. Normally, the number given to each department

is enough fro the identification of a particular department.

This number is commonly is known as the department

number to any Organization.


43/80

Amt_allocated To have any work done financial support is

main constraint for the completion of the job in an effective

manner. This attribute specifies the amount allocated to each

department for the job. The job is expected to be completed

within the margin of the allocated fund. If in the cases of

extra expenses the case is considered.

DOA This is an abbreviation for the term Date Of

Allocation. It signifies the date on which the transaction of

allocation of fund for the job to a particular department was

done. This attribute only gives the detail of timing related to

the fund allocation.

Propo_exp - A tentative marginal amount is set in order to

present the proposed expences to the senior executives. This

amount is set keeping in mind the overall expences to be

made in the relevance to the project work To be undertaken.

Amt_distr - It is a well-known fact that the organisation

contains several executives and several managers working

under them. The project under study considers that each of


44/80

the individuals whether an executive or a manager has some

or the other signing rights. In other words, they can further

distribute the allocated amount to the employees working

under them. This attribute defines the amount for which the

perticular employee has the signing rights.

Act_exp - It is a common phenomena that any amount

considered as an expenditure is presented in rounded form.

The actual amount to be expended is represented by this

attribute.

Last_updt It specifies the date on which the updation has

been done. It enables the users to view and infer current

information.

Over_exp This attribute specifies the over expenses which

have incurred while working on the project due to higher

price hikes on the products required by the department. This

event seldom occurs because a thorough study is done prior to

request of the fund.

The attributes of the table dept and their explanation are given below:


45/80

Deptno A department number is assigned to each

department of the organization to be uniquely identifiable. In

this table the department number acts as a primary key.

Dname A name is allotted to each department. The

department name given is usually related to the work to be

performed by the department.

The Plan wise fund distribution is another sub module, which

considers the amount to be spent on the plans undertaken by the

organization. With the normal functioning of the organization there are

situations when the authority decides upon the enhancement or extra

curriculum of the organization inmates or expansion of their work area. This

results in evolution of various plans to be commenced for the desiredsubjects. The help of two tables, which are plan and dept_vs_plan, can

explain this sub module. The attributes of the given tables have been stated

below with appropriate explanation. Starting with the table plan:

Plan_no With a number of plans being implemented in the organization,

each plan needs to be identified uniquely. In this table the attribute plays as a

primary key identifying each plan running in the organization.


46/80

Plan_nm The plan name acts as a sub-ordinate to the plan number. With

plan name it makes an easy identification of the plan. It may happen that the

plan name may be same but covering different areas of concern.

Fund_amt The amount being given to departments to carry over the plan is

termed as the fund amount for the plan. This amount is totally spent on the

growth as well as implementation of the plan for the organization.

Eno A plan is always handled and managed properly if an individual heads

it. This individual is a recognized employee of the organization chosen by

the governing body. Under his control all the steps related to implementation

of the plan is done. This attribute gives the identification of that employee

by providing his identity number.

Another table explaining the concept of plan wise fund distribution

is the table dept_vs_plan. This table gives detail of the departments working

on that plan and the amount on which to implement the plan. The attributes

of the table are as follows along with their explanation.

Dept_no This attribute gives the information

regarding the department that will be working on a particular

plan. The attribute gives the number of the department. It is


47/80

possible that more than one department can work on the a

particular plan.

Plan_no The attribute plan number signifies as to which

department will be working on which plan.

Plan_amt Plan amount relates to the amount given to

the department working on the particular plan. As referred

earlier that it may happen more than one department may

handle one plan. This attribute specifies the amount given to

each department working in collaboration to implement that

plan.

Fund Manager: This module describes the authorities of the employees of

the organization. To a certain limit employees are given the signing rights

for a particular amount. Describing the statement it can be explained that an

employee can sanction money to his sub-ordinate to carry out some work to

a limit of particular amount only. This module has been represented in the

table emp_auth, which shows that which employees have the rights of how

much amount. The attributes of the table and explanation are given as below:


48/80

Eno Since the table gives the employee

details it is necessary to uniquely identify each employee

and his signing rights. The employee number in this table

does the job of identifying each employee of the

organization. Thus the employee number in this table is the

primary key.

Ename The attribute shows the name of

the employee. It may be possible that there may be two

people with same name but their identification can be done

through their identity number.

Dept_no Gives the information on the

department number to which the employee belongs.

Under_emp In any organization the

hierarchy of employee stature exists. The head works as a

senior to all his sub-ordinates controlling and taking

appropriate decisions for the department. This attribute givesthe information regarding who heads the particular

employee or under whom is this employee acting as a sub-

ordinate.


49/80

Amt_allocated The attribute refers to the

amount allocated to the particular employee.

DOA The date of allocation specifies

the date on which the allocation transaction was made. It

acts as an additional information for the allocation details.

Emp_active It may happen in many

cases that the signing authority may be debarred from his

authorities due to some valid reasons. In such cases the

authorities assigned to him are taken away leaving him

inactive. The attribute, thus is a kind of report as to whether

the employee is still retaining his powers or is inactive at the

current time period.

Amt_validity Certain organizations

follow a rule of validating the amount allocated to the

employee. This means that the amount has to be used within

the stated time period and its expenses are to be reported

within that time limit.


50/80

Docket_no Each employee keeps the

record of his transactions intact for future reference. This

attribute somewhat serves this purpose. It specifies the

number in which the user keeps his records.

Amt_used From the amount allocated to

the employee some amount is used up for the specified

purposes. His attribute keeps the record of the amount used.

Monitoring Of Expenses: The Organizations categorizes

the expenses into two distinct divisions, one being the

Planned Expenses which is the amount spent on specific

entitled projects and the other is the Non-Planned Expense

which comes under general expenses. The executive isrequired to submit the bills of the expenses incurred

during transaction. The bills include fooding, lodging,

tours and travels and purchase expenses.

Fund Re-allocation / Cancellation: This module has

been developed to monitor the budget release, once it is

approved by the signing authority. It deals with sending as

well as processing of request for monetary aid. It includes

emails sent by the executives to their superiors. Processing


51/80

results in acceptance or rejection of monetary request

based on certain grounds.

Based on request processing results the executives sanction fund and

payment is made with the help of core banking. Core banking enables the

executives to bear the transaction expenses by transferring money directly to

the concerned party in tie up with the executives organization for core

banking or through the executives account. The table giving the details

related to the matter is fund_proposal whose attributes and explanation are

as follows:

Prop_no The proposal number plays the primary key

for the table. Each proposal can be identified uniquely

through this attribute.

P_date The proposal date specifies the day on which

the proposal was requested. It provides with additional

information regarding the proposal made.

Eno This attribute specifies the employee number who

makes a request for the proposal for the allocation of the

fund.


52/80

Entity Relationship Diagram:

Tables And Structures:

The tables constructed for this system are as follows:

TNAME TABTYPE CLUSTERID

------------------------------ ------- ---------

Bill_subm TABLE

Bill_subm_detail TABLE

Dept TABLE


53/80

Dept_fund TABLE

Dept_vs_plan TABLE

Emp_auth TABLE

Fund_allocation TABLE

Fund_proposal TABLE

Plan TABLE

1) Table Bill_subm

Name Null? Type

------------------------------- -------- ----

Bill_no NOT NULL NUMBER(3)

Deptno NUMBER(3)

Eno VARCHAR2(7)

Bill_amt NUMBER(10,2)

Sub_dt DATE

Ref_plan_no NUMBER(3)


54/80

Bill_des VARCHAR2(50)

2) Table - Bill_subm_detail

Name Null? Type

------------------------------- ------- ----

Bill_no NUMBER(3)

Particlars VARCHAR2(35)

Amt NUMBER(10,2)

Ref_bill_no VARCHAR2(5)

Bill_dt DATE

Sl_no NUMBER(3)

3) Table Dept

Name Null? Type

------------------------------- -------- ----

Deptno NOT NULL NUMBER(3)

Dname VARCHAR2(30)


55/80

4) Table Dept_fund

Name Null? Type

------------------------------- -------- ----

Deptno NUMBER(3)

Amt_allocated NUMBER(10,2)

Doa DATE

Propo_exp NUMBER(10,2)

Amt_distr NUMBER(10,2)

Act_exp NUMBER(10,2)

Last_updt DATE

Over_exp NUMBER(10,2)

5) Table Dept_vs_plan

Name Null? Type

------------------------------- ------- ----


56/80

Deptno NUMBER(3)

Plan_no NUMBER(3)

Plan_amt NUMBER(10,2)

6) Table - Emp_auth

Name Null? Type

------------------------------- -------- ----

Eno NOT NULL VARCHAR2(7)

Ename VARCHAR2(15)

Deptno NUMBER(3)

Under_emp VARCHAR2(4)

Amt_allocated NUMBER(10,2)

Doa DATE

Emp_active CHAR(1)

Amt_validity DATE

Docket_no VARCHAR2(5)

Amt_used NUMBER(10,2)


57/80

7) Table - Fund_allocation

Name Null? Type

------------------------------- -------- ----

Year NUMBER(4)

Amt NUMBER(10,2)

Amt_bal NUMBER(10,2)

8) Table - Fund_proposal

Name Null? Type

------------------------------- -------- ----

Prop_no NOT NULL NUMBER(5)

P_date DATE

Eno VARCHAR2(7)

Amt_request NUMBER(10,2)


58/80

Prop_type CHAR(1)

Plan_no NUMBER(3)

Other_info VARCHAR2(15)

Appr_rem VARCHAR2(15)

Rej_rem VARCHAR2(15)

App_amt NUMBER(10,2)

App_final CHAR(1)

9)Table - Plan

Name Null? Type

------------------------------- -------- ----

Plan_no NOT NULL NUMBER(3)

Plan_nm VARCHAR2(30

Fund_amt NUMBER(10,2)

Eno VARCHAR2(7)


59/80

Tools And Platform:

Input Screen

A . Form For The Main Screen.


60/80

B. Input/ View Department Form where funds are distributed


61/80

C. Form for Fund allocation Entry Screen.


62/80

D. Form For Signing Authority


63/80

E. Plan wise Fund Distribution To Departments


64/80

F. Bill Submission Form


65/80

G. Fund Proposal Form


66/80

Output Screen :

Validations And Security

The application provides high level of security that includes:


67/80

Entry of data in the database with required integrity constraints.

Checks incorporated to prevent unauthorized access.

Testing

No program or system design is perfect. Communication between the user and

the designer is not always complete or clear and time is usually short. The resultis errors and more errors. Thus the time comes to put all the pieces into one

system and test it to determine whether it meets the users requirements.

Testing is vital to the success of the system. System testing makes a logical

assumption that if all the parts of the system are correct, the goal will be

successfully achieved. Inadequate testing or non-testing leads to errors that may

not appear until months later. This creates two problems: (i) the time lag

between the cause and the appearance of the problem and (ii) the effect of

system errors on files and records within the system. A small system error can

conceivably explode into a much larger. Effective testing in the early process

translates directly into long-term cost savings from a reduced number of errors.

Another reason for system testing is its utility as user-oriented vehicle before

implementation. The best program is worthless if it does not meet user needs.


68/80

The first test of a system is to see whether it produces the correct outputs. No

other test can be more crucial. The steps followed while conducting these tests

are:

Online Response Online systems must have a response time that will

not cause a hardship to the user.

Volume In this test, we create as many records as would normally be

produced to verify that the hardware and software will function correctly

Stress testing The purpose of stress testing is to prove that the

candidate system doe not malfunction under peak loads. The system is

subjected to a high volume of data over a short time period.

Recovery and Security A forced system failure is induced to test a

backup recovery procedure for file integrity. Inaccurate data are entered to see

how the system responds in terms of error detection and protection.

Usability documentation and procedure The usability test verifies the

user-friendly nature of the system. This relates to normal operating and error-

handling procedures.

The first step in system testing is to prepare plan that will test all aspects of the

system in a way that promotes its credibility among potential users. The test

plan entails the following activities:


69/80

Prepare test plan

Specify conditions for user acceptance testing Prepare test data for program testing

Prepare test data for transaction path testing

Plan user training

Compile /assemble programs

Prepare job performance aids

Prepare operational documents

The purpose of system testing is to identify and correct errors in the candidate

system. In system testing, performance and acceptance standards are developed.

Substandard performance or service interruptions that result in system failure

are checked during the test. The following criteria are used for system testing:

Turnaround time is the elapsed time between

the receipt of the input and the availability of the output.

Backup relates to procedures to be used when

the system is down. The software for the candidate system must be tested for

compatibility with a backup computer.

File protection pertains to storing files in a

separate area for protection against fire, flood ,or natural disaster.


70/80

The human factor applies to the personnel of

the candidate system. During system testing, lightening, air conditioning, noise,

and other environmental factors are evaluated with peoples desks.

After a test plan has been developed, system testing begins by testing program

modules separately, followed by testing modules as a unit. A program module

may function perfectly in isolation but fail when interfaced with other modules.

The approach is to test each entity with successively larger ones, up to the

system test level.

Program Testing;

A program represents the logical elements of a system. For a program to run

satisfactorily, it must compile and test data correctly and tie in properly with

other programs. Achieving an error-free program is the responsibility of te

programmer. Program testing checks for two types of errors: syntax and logic.

A syntax error is a program statement that violates one or more rules of the

language in which it is written. An improperly defined field dimension or

omitted key words are common syntax errors. These errors are shown through

error messages generated by the computer. A logic error on the other hand,

deals with incorrect data fields, out-of range items, and invalid combinations.


71/80

When a program is tested, the actual output is compared with the expected

output. When there is a discrepancy, the sequence of instructions must be traced

to determine the problem. Breaking the program down into self-contained

portions, each of which can be checked at certain key points, facilitates the

process

String Testing:

Programs are invariably related to one another and interact in a total system.

Each program is tested to see whether it conforms to related programs in the

system. Each portion of the system is tested against the entire module with both

test and live data before the entire system is ready to be tested.

System Testing:

System testing is designed to uncover weaknesses that were not found in earlier

tests. This includes forced system failure and validation of the total system as it

will be implemented by its users in the operational environment. The total


72/80

system is also tested for recovery and fallback after various major failures to

ensure that no data are lost during the emergency.

User Acceptance Testing :

An acceptance test has the objectives of selling the user on the validity and

reliability of the system. It verifies that the systems procedures operate to

system specifications and that the integrity of vital data is maintained.

Performance of an acceptance test is actually the users show. User motivation

and knowledge are critical for the successful performance of the system.

Unit Testing:

It focuses on individual software units or groups of related units. It checks if

units does not satisfy the functional specification and intended design structure.

A unit can be compiled, assembled, linked, loaded put under a test case. Unit

depends upon code complexity including the software language, tools,

technology used. The Unit test is normally white-box oriented and the steps can

be conducted in parallel for multiple modules. Every unit is tested to ensure that

information properly flow into and out of the program under test.


73/80

White Box And Black Box Testing

All units are white box tests.

Black box = Product validation = Is the product working right?

It deals with business to be verified by subject matter experts or domain

experts. All engineered products can be tested in one of the two ways:

By knowing the internal working s of the product, tests can be conducted

to ensure that internal operations are performed according to specifications and

all detailed functions are adequately exercised. This is called as White-Box

Testing.

Alternatively, by knowing the specified overall functions that the product

has been designed to perform, the tests can be conducted to check that each

function is fully operational and whether are there errors in each function? This

is known as Black-Box Testing.

White Box Testing

It is a testing category based on knowledge of internal structure and logic of

software. Several sources of errors should be followed:


74/80

Syntax-errors, which are very common. When source code is

written, many typing errors will occur. Many will be uncovered by syntax

checking mechanism, but others will go undetected until testing begins.

Program Control Structure. The tester should be knowledgeable in

programming also. Code checking is an important aspect in this method.

Most Specific Conditions and loops with Logical. Test cases are

derived to ensure that all statements or logical conditions in the program should

get executed at least once during testing. Also there should be Special Case

processing which tends to fall into the cracks.

The data along with the coding standards should be tested. Test

cases should be prepared based on this. Test the data along with the coding

standards followed.

Both the inputs and its outputs are verified. The input data as well as outputs

expected are required to be planned as part of Test Planning.

Other White Box Testing:

Exception testing

It is often crucial for reliable operations, which should be tested for:

o File errors (empty, missing, overflow)

o I/O errors (device not ready, parity)


75/80

o Arithmetic Operations (overflow)

o Resource Allocation (memory)

o Task Communication, Creation

Suspicion Testing

It is used when

o Programmer is less experienced

o Module having high failure rate

o Failed inspection Late change order

o Designer/Programmer feels uneasy

o Later/Bigger the change, more dangerous

Black Box Testing Methods

Black box testing considers the program as a black box. The tests are done to

validate its functionality-what the system is supposed to do, without regard to

the internal workings of a program. This approach is based on external


76/80

specifications and fundamental aspects without knowledge of How the system

is constructed. It is conducted at the software interface .

Black box testing techniques focus on the information domain of the software

deriving test cases by partitioning the input and output domain of a program in

a manner that provides through test coverage.

Black Box testing attempts to find errors in the following categories:

Incorrect or missing functions

Interface errors

Errors in data structures or external data base access

Performance errors and

Initialization and termination errors

The tester should know what to test in the program. This means that the tester

should know the input conditions and their desired outputs. The tester prepares

the data of various types and gets the results.

Because black box testing purposely disregards control structure, attention is

focused on the information domain. Tests are designed to answer the question

such as follows:

How is functional validity tested?


77/80

What classes of input will make good test cases?

Is the system particularly sensitive to certain input values?

How are the boundaries of a data class isolated?

What data rates and data volume can the system tolerate?

What effect will specify combinations of data have on

system operation?

What is the effect of integrating multiple systems/modules?

Comparison Testing:

There are some situations in which the reliability of software is absolutely

critical. In such applications redundant hardware and software are often used to

minimize the possibility of error. Develop independent versions of an

application using the same specification. Each version can be tested with the

same test data to ensure that all provide identical output. Then all the versions

are executed in parallel with real time comparison of results to ensure

consistency. However, only a single version will be used in the delivered


78/80

computer-based system. This forms the Comparison testing or Back-to-back

testing.

Comparison testing is not foolproof. If the specification from which all versions

have been developed is in error, all versions will likely reflect the error.

Validation Testing:

Validation succeeds when software functions in a manner that can be

reasonably expected by the customer. Reasonable expectations are required to

be defined which is user visible or realizable? After each validation test case

has been conducted, one of the two possible conditions exists:

i. The function or performance characteristics conform to specification

and are accepted or

ii. A deviation from specification is uncovered and a deficiency list is

created.

Alpha, Beta And Pre-Beta Testing


79/80

It is impossible for a software developer to anticipate how the customer will

really use the system. There may be instances when the instructions for use of

software may be misinterpreted

Implementation:

Future Enhancement And Limitation

Incorporating Data Warehousing features to enable themanagement in efficient decision-making.

Integration of the application with SAP.


80/80

Integration of mobile technology.

Conclusion

A s more and more tasks and expenditure authority are decentralized, it will be

necessary to ensure that financial management systems and accountability at

local level are strong. This is a very important subject that would affect the

viability of the local governments. State Government will constitute a small

working group to review the adequacy of the financial management and

accountability at local level and make suitable recommendations.

Bibliography:

Coding:

Actual Project Documentation

Documents

Transcript of Actual Project Documentation