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

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.

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

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.

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.

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.

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) (ii) provide accurate and timely financial information on the actual and budgeted revenue. 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.

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.

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.

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

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

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

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

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.

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

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 the accuracy 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 :

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

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

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

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

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 ,

begin with a summary of findings and recommendations, followed by documented details. The report contains the following sections: (i) (ii) (iii) Cover letter briefly indicates to management the nature, general findings, and recommendations to be considered . Table Of Contents specifies the location of the various parts of the report management quickly. Overview is a narrative explanation of the purpose and scope of the project, the reason for undertaking the feasibility study and the departments 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

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 of internal design include a specification of architectural structure, the details of algorithms and data structures and the test plan.

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 packaging scheme 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 multivalued dependency. A partial dependency exists when an attribute of a relation is functionally dependant on only one attribute of a concatenated key. Transitive

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 be possible 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.

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

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 multiattribute

Second Normal Form:

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:

 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

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:

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

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.

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 a geographically 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

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

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.

Dataflow diagram

EXE Bill Submission C U T I V Monetary Request E e Payment c u

0
Monetary Queries

Fund Monitoring System

Fund Allocation

MA N A G E M E N T E x

Abstract Level DFD (Level 0 DFD)

LEVEL 1 DFD

Proposal Refusal Data File Employee Dtata File Allocation Data File
1

Allocation Details Signing Authority

2

Fund Granted

Fund Allocation Process

Allocatio n ID

Fund Distribution Process

Bill No
Auth Id

Expanse Details Proposal ID

Fund Request Proposal

Expanse Doc

Bill Submission Process

Report

Expanse Info

Modules And Descriptions:

(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 distributions 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.

(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

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 of expenditures on schemes and also to secure itemized control on expenditure.

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 sub items, 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

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.

 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

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:

 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 desired subjects. 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.

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

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:

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 gives the information regarding who heads the particular employee or under whom is this employee acting as a subordinate.

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.

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 is required 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

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.

Entity Relationship Diagram:

Tables And Structures:

The tables constructed for this system are as follows:

TNAME -----------------------------Bill_subm Bill_subm_detail Dept

TABTYPE ------TABLE TABLE TABLE

CLUSTERID ---------

Dept_fund Dept_vs_plan Emp_auth Fund_allocation Fund_proposal Plan

TABLE TABLE TABLE TABLE TABLE TABLE

1) Table Bill_subm Name ------------------------------Bill_no Deptno Eno Bill_amt Sub_dt Ref_plan_no Null? -------NOT NULL Type ---NUMBER(3) NUMBER(3) VARCHAR2(7) NUMBER(10,2) DATE NUMBER(3)

Bill_des

VARCHAR2(50)

2) Table - Bill_subm_detail Name ------------------------------Bill_no Particlars Amt Ref_bill_no Bill_dt Sl_no Null? ------Type ---NUMBER(3) VARCHAR2(35) NUMBER(10,2) VARCHAR2(5) DATE NUMBER(3)

3)

Table Dept Name ------------------------------Deptno Dname Null? -------NOT NULL Type ---NUMBER(3) VARCHAR2(30)

4) Table Dept_fund Name ------------------------------Deptno Amt_allocated Doa Null? -------Type ---NUMBER(3) NUMBER(10,2) DATE

Propo_exp Amt_distr Act_exp Last_updt Over_exp

NUMBER(10,2) NUMBER(10,2) NUMBER(10,2) DATE NUMBER(10,2)

5)

Table Dept_vs_plan Name ------------------------------Null? ------Type ----

Deptno Plan_no Plan_amt

NUMBER(3) NUMBER(3) NUMBER(10,2)

6)

Table - Emp_auth Name ------------------------------Eno Ename Deptno Under_emp Amt_allocated Doa Emp_active Amt_validity Docket_no Amt_used Null? -------NOT NULL Type ---VARCHAR2(7) VARCHAR2(15) NUMBER(3) VARCHAR2(4) NUMBER(10,2) DATE CHAR(1) DATE VARCHAR2(5) NUMBER(10,2)

7)

Table - Fund_allocation Name ------------------------------Year Amt Amt_bal Null? -------Type ---NUMBER(4) NUMBER(10,2) NUMBER(10,2)

8)

Table - Fund_proposal Name ------------------------------Prop_no P_date Eno Amt_request Null? -------NOT NULL Type ---NUMBER(5) DATE VARCHAR2(7) NUMBER(10,2)

Prop_type Plan_no Other_info Appr_rem Rej_rem App_amt App_final

CHAR(1) NUMBER(3) VARCHAR2(15) VARCHAR2(15) VARCHAR2(15) NUMBER(10,2) CHAR(1)

9)Table - Plan Name ------------------------------Plan_no Plan_nm Fund_amt Eno Null? -------NOT NULL Type ---NUMBER(3) VARCHAR2(30) NUMBER(10,2) VARCHAR2(7)

Tools And Platform:

Input Screen

A.

Form For The Main Screen.

B.

Input/ View Department Form where funds are distributed

C.

Form for Fund allocation Entry Screen.

D.

Form For Signing Authority

E.

Plan wise Fund Distribution To Departments

F.

Bill Submission Form

G.

Fund Proposal Form

Output Screen : Validations And Security

The application provides high level of security that includes:

 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 result is 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.

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 Volume In this test, we create as many records as would normally be Stress testing The purpose of stress testing is to prove that the

not cause a hardship to the user. produced to verify that the hardware and software will function correctly 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 errorhandling 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:

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 Backup relates to procedures to be used when

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

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.

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.

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

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.

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:

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 Most Specific Conditions and loops with Logical. Test cases are

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

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 o File errors (empty, missing, overflow) I/O errors (device not ready, parity)

o o o

Arithmetic Operations (overflow) Resource Allocation (memory) Task Communication, Creation

Suspicion Testing It is used when o o o o o Programmer is less experienced Module having high failure rate Failed inspection Late change order Designer/Programmer feels uneasy 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

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?

 system operation?

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

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. ii. created. The function or performance characteristics conform to specification and are accepted or A deviation from specification is uncovered and a deficiency list is

Alpha, Beta And Pre-Beta Testing

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 the management in efficient decision-making. Integration of the application with SAP.

 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: