REVENUE RECOVERY SYSTEM

INTRODUCTION

REVENUE RECOVERY SYSTEM

ABSTRACT

The main objective of this project is to prepare a software

module by which the District Collectors will get awareness about the
Revenue Collection from time to time in a particular Revenue Year.
Existing System
Revenue Recovery is one of the major tasks that are
being performed by District Collector. The main task of the District
Collector is to collect the Revenue from various heads such as Library
cess , stamp duty, educational cess etc
Usually Revenue is getting collected at village level,
mandal level and District Level reports are getting generated on monthly
basis, quarterly basis, half yearly basis and Revenue year(August-July)
basis.
In the existing system it was cumbersome to Revenue
Department to generate monthly, quarterly, half yearly and yearly basis
by manually and it is difficult to monitor all these levels by District
Collector.
Proposed System
Keeping the above typicality view we are proposed to
prepare a software module which generate all the required statistics. By
using this software module the District Collectors will get awareness
about the revenue Collection entries from time to time in a particular
Revenue Year.
This module will generates various reports based on
Revenue Recovery Collection entries made by the Mandal Revenue
Officers (mros), Village Revenue Officers (vros) working under the
District Collector.

Users of System
A. Administrator
B. District Collector
C. Mandal Revenue Officer
D. Village Revenue Officer

FEASIBILITY REPORT

FEASIBILITY REPORT

TECHNICAL FEASIBILITY:
Evaluating the technical feasibility is the trickiest part of a feasibility
study. This is because, at this point in time, not too many detailed design
of the system, making it difficult to access issues like performance, costs
on (on account of the kind of technology to be deployed) etc. A number of
issues have to be considered while doing a technical
analysis.
i)

Understand

the

different

technologies

involved

in

the

proposed system:
Before commencing the project, we have to be very clear about
what are the technologies that are to be required for the
development of the new system.
ii)

Find out whether the organization currently possesses the

required technologies:
o Is

the

required

technology

available

with

the

organization?
o If so is the capacity sufficient?
For instance
Will the current printer be able to handle the new reports and
forms required for the new system?

OPERATIONAL FEASIBILITY:
Proposed projects are beneficial only if they can be turned into
information systems that will meet the organizations operating
requirements. Simply stated, this test of feasibility asks if the system will
work when it is developed and installed. Are there major barriers to
Implementation? Here are questions that will help test the operational
feasibility of a project:

Is there sufficient support for the project from management from

users? If the current system is well liked and used to the extent

that persons will not be able to see reasons for change, there may
be resistance.

Are the current business methods acceptable to the user? If they

are not, Users may welcome a change that will bring about a more
operational and useful systems.

Have the user been involved in the planning and development of

the project?

Early involvement reduces the chances of resistance to the system

and in

General and increases the likelihood of successful project.

Since the proposed system was to help reduce the hardships

encountered. In the existing manual system, the new system was
considered to be operational feasible.
ECONOMIC FEASIBILITY:
Economic feasibility attempts 2 weigh the costs of developing and
implementing a new system, against the benefits that would accrue from
having the new system in place. This feasibility study gives the top
management the economic justification for the new system.
A simple economic analysis which gives the actual comparison of costs
and benefits are much more meaningful in this case. In addition, this
proves to be a useful point of reference to compare actual costs as the
project progresses. There could be various types of intangible benefits on
account of automation. These could include increased customer
satisfaction, improvement in product quality better decision making
timeliness of information, expediting activities, improved accuracy of
operations, better documentation and record keeping, faster retrieval of
information, better employee morale.

SYSTEM REQUIREMENT
SPECIFICATION

OVERVIEW
Overview of the project
STUDY OF THE SYSTEM
In the flexibility of uses the interface has been developed a
graphics concepts in mind, associated through a browser interface.
The GUIs at the top level has been categorized as follows
1. Administrator Interface Design.
2. User Interface.
3. Security Authentication.
4. Reports.
5. General end-users.
The administrative user interface will maintain the different users details,
the interface helps the administration with all the transactional states like
which users sending the mails, and which users receiving whishing mails,
users details information history. And the statistics of the system in
difference stratagies.
NUMBER OF MODULES
The system after careful analysis has been identified to be
presented with the following modules:
The Modules involved are
1. Admin Module
2. District Collector Module
3. Mandal Revenue Officer Module
4. Village Revenue Officer Module
5. Report Module

Modules Description
1. Administrative Module:
In this module the role of Administrator is to maintain all the
details of various states information like number of districts of
a state, collector of that district, number of mandals, mro of
those mandals, number of villages, vros of those villages ,
revenue types information etc .
2. District Collector Module:
This module is all about a revenue information of a District
viewed by a District Collector. Here Collector can view the
detailed reports of revenue collected on various revenue types
like library cess, educational cess etc.. on monthly basis,
quarterly basis, half yearly basis and a particular revenue year
(Aug-July) basis.
He can also see the detailed report of a particular village
revenue, a particular mandal revenue collections .
3. Mandal Revenue Officer Module:
In this specified module the Mandal Revenue Officer will enter
the details of revenue collected on various revenue types like
library cess, educational cess etc and will submit to District
Collector.
He can also monitor Village Revenue Officers under him and
gets a clear idea about the revenue collected on various
revenue types .
4. Village Revenue Officer Module:
In this specified module the Village Revenue Officer will enter
day to day details of revenue collected on various revenue types
like library cess, educational cess etc and will submit to his
superior officer ie Mandal Revenue Officer .
5. Report Module
In this module various revenue reports are getting generated
like monthly, quarterly, half-yearly, yearly basis of a particular
district.
This module is much help-full for a District Collector to get
awareness about the revenue collection from time to time in a

particular revenue year.

PROCESS FLOW

ARCHITECTURE DIAGRAM

1. THE PRESENTATION LAYER

Also called as the client layer comprises of components that are

dedicated to presenting the data to the user. For example:
Windows/Web Forms and buttons, edit boxes, Text boxes, labels,
grids, etc.
2. THE BUSINESS RULES LAYER
This layer encapsulates the Business rules or the business logic of
the encapsulations. To have a separate layer for business logic is of
a great advantage. This is because any changes in Business Rules
can be easily handled in this layer. As long as the interface between
the layers remains the same, any changes to the
functionality/processing logic in this layer can be made without
impacting the others. A lot of client-server apps failed to implement
successfully as changing the business logic was a painful process
3. THE DATA ACCESS LAYER
This layer comprises of components that help in accessing the
Database. If used in the right way, this layer provides a level of
abstraction for the database structures. Simply put changes made
to the database, tables, etc do not affect the rest of the application
because of the Data Access layer. The different application layers
send the data requests to this layer and receive the response from
this layer.
4. THE DATABASE LAYER
This layer comprises of the Database Components such as DB Files,
Tables, Views, etc. The Actual database could be created using SQL
Server, Oracle, Flat files, etc.
In an n-tier application, the entire application can be implemented
in such a way that it is independent of the actual Database. For
instance, you could change the Database Location with minimal
changes to Data Access Layer. The rest of the Application should
remain unaffected.

SDLC METHODOLOGIES

This document play a vital role in the development of life cycle (SDLC)
as it describes the complete requirement of the system. It means for
use by developers and will be the basic during testing phase. Any
changes made to the requirements in the future will have to go
through formal change approval process.
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, A
spiral Model of Software Development and Enhancement. This model
was not the first model to discuss iterative development, but it was the
first model to explain why the iteration models.
As originally envisioned, the iterations were typically 6 months to 2
years long. Each phase starts with a design goal and ends with a
client reviewing the progress thus far. Analysis and engineering
efforts are applied at each phase of the project, with an eye toward
the end goal of the project.
The steps for Spiral Model can be generalized as follows:
The new system requirements are defined in as much details as
possible. This usually involves interviewing a number of users
representing all the external or internal users and other aspects
of the existing system.

A preliminary design is created for the new system.

A first prototype of the new system is constructed from the

preliminary design. This is usually a scaled-down system, and
represents an approximation of the characteristics of the final
product.

A second prototype is evolved by a fourfold procedure:

1. Evaluating the first prototype in terms of its strengths,
weakness, and risks.
2. Defining the requirements of the second prototype.
3. Planning an designing the second prototype.
4. Constructing and testing the second prototype.

At the customer option, the entire project can be aborted if the

risk is deemed too great. Risk factors might involved
development cost overruns, operating-cost miscalculation, or any
other factor that could, in the customers judgment, result in a
less-than-satisfactory final product.

The existing prototype is evaluated in the same manner as was

the previous prototype, and if necessary, another prototype is
developed from it according to the fourfold procedure outlined
above.

The preceding steps are iterated until the customer is satisfied

that the refined prototype represents the final product desired.

The final system is constructed, based on the refined prototype.

The final system is thoroughly evaluated and tested. Routine

maintenance is carried on a continuing basis to prevent large
scale failures and to minimize down time.

The following diagram shows how a spiral model acts like:

Fig 1.0-Spiral Model

ADVANTAGES
Estimates(i.e. budget, schedule etc .) become more relistic as
work progresses, because important issues discoved earlier.

It is more able to cope with the changes that are software

development generally entails.

Software engineers can get their hands in and start woring on

the core of a project earlier.

SOFTWARE REQUIREMENT AND

HARDWARE REQUIREMENT

SOFTWARE REQUIREMENTS
Operating System

Windows XP/2003 or Linux

User Interface

HTML, CSS

Client-side Scripting

JavaScript

Programming Language

Java

Web Applications

JDBC, Servlets, JSP

IDE/Workbench

My Eclipse 6.0

Database

Oracle 10g

Server Deployment

Tomcat 5.x

HARDWARE REQUIREMENTS
Processor

Pentium IV

Hard Disk

40GB

RAM

512GB or more

SYSTEM DESIGN

Data Flow Diagrams

A graphical tool used to describe and analyze the moment of data

through a system manual or automated including the process, stores of
data, and delays in the system. Data Flow Diagrams are the central tool
and the basis from which other components are developed. The
transformation of data from input to output, through processes, may be
described logically and independently of the physical components
associated with the system. The DFD is also know as a data flow graph
or a bubble chart.
DFDs are the model of the proposed system. They clearly should show
the requirements on which the new system should be built. Later during
design activity this is taken as the basis for drawing the systems
structure charts. The Basic Notation used to create a DFDs are as

follows:
1. Dataflow: Data move in a specific direction from an origin to a
destination.

2. Process: People, procedures, or devices that use or produce

(Transform) Data. The physical component is not identified.

3. Source: External sources or destination of data, which may be People,

programs, organizations or other entities.

4. Data Store: Here data are stored or referenced by a process in the

System.

Context Level Data Flow Diagram

Level1 Data Flow Diagram for Collector:

Level1 Data Flow Diagram for MRO:

Level1 Data Flow Diagram for VRO:

Level1 Data Flow Diagram for Admin:

Authentication Data Flow Diagram:

E-R DIAGRAM

E - R Diagram

UML DIAGRAMS

UNIFIED MODELING LANGUAGE DIAGRAMS

The unified modeling language allows the software engineer to express an
analysis model using the modeling notation that is governed by a set of
syntactic semantic and pragmatic rules.

A UML system is represented using five different views that describe the
system from distinctly different perspective. Each view is defined by a set
of diagram, which is as follows.
USER MODEL VIEW
This view represents the system from the users perspective.
The analysis representation describes a usage scenario from the endusers perspective.
STRUCTURAL MODEL VIEW
In this model the data and functionality are arrived from inside the
system.
This model view models the static structures.
BEHAVIORAL MODEL VIEW
It represents the dynamic of behavioral as parts of the system, depicting
the interactions of collection between various structural elements
described in the user model and structural model view.
IMPLEMENTATION MODEL VIEW
In this the structural and behavioral as parts of the system are
represented as they are to be built.
ENVIRONMENTAL MODEL VIEW
In this the structural and behavioral aspects of the environment
in which the system is to be implemented are represented.
UML is specifically constructed through two different domains
they are:
UML Analysis modeling, which focuses on the user model and
structural model views of the system.
UML design modeling, which focuses on the behavioral modeling,
implementation modeling and environmental model views.
Use case Diagrams represent the functionality of the system from a
users point of view. Use cases are used during requirements
elicitation and analysis to represent the functionality of the system.
Use cases focus on the behavior of the system from external point
of view.
Actors are external entities that interact with the system.
Examples of actors include users like administrator, bank customer
etc., or another system like central database.

Class Diagram

CLASS DIAGRAM
Class diagrams describe the structure of the system in

terms of classes and objects. The servlet api class diagram will be
as follows.

JSP: Implicit
Objects

Class Collaboration Diagrams

Class Collaboration Diagram

ClassCollobrationDiagram

Use Case Diagrams

UML Diagrams
Unified Modeling Language:

The Unified Modeling Language allows the software engineer to express

an analysis model using the modeling notation that is governed by a set
of syntactic semantic and pragmatic rules.
A UML system is represented using five different views that describe the
system from distinctly different perspective. Each view is defined by a set
of diagram, which is as follows.

User Model View

i. This

view represents

the system

from the users

perspective.
ii. The analysis representation describes a usage scenario
from the end-users perspective.

Structural model view

i. In this model the data and functionality are arrived from
inside the system.
ii. This model view models the static structures.

Behavioral Model View

It represents the dynamic of behavioral as parts of the
system, depicting the interactions of collection between
various structural elements described in the user model and
structural model view.

Implementation Model View

In this the structural and behavioral as parts of the system
are represented as they are to be built.

Environmental Model View

In

this

the

structural

and

behavioral

aspects

of

the

environment in which the system is to be implemented are

represented.

UML is specifically constructed through two different domains they are:

UML Analysis modeling, this focuses on the user model and
structural model views of the system.
UML design modeling, which focuses on the behavioral modeling,
implementation modeling and environmental model views.

Use case Diagrams represent the functionality of the system from a users
point of view. Use cases are used during requirements elicitation and
analysis to represent the functionality of the system. Use cases focus on
the behavior of the system from external point of view.
Actors are external entities that interact with the system. Examples of
actors include users like administrator, bank customer etc., or another
system like central database.

1. system Use Case Diagram

2. Administrator Use Case Diagram

3. Collector UseCase Diagram

4. MRO UseCase Diagram

5. VRO UseCase Diagram

Sequence Diagrams

Operational level
Sequence & Collaboration
Diagrams

Operation-Level Sequence Diagram

1. Login Sequence Diagram

Administrator

login

2: login

User

1: login

3: validate

4: validlogin

5: validlogin

Login Collaborative Diagram

3: validate

login

2: login
5: validlogin

Administ
rator

4: validlogin
1: login
User

2. Present Login User Report Sequence Diagram

Admin

Login

Report

DataBase

login
validate

validLogin
getPresentUsingReport
selectInfo
ReportInfo
ReportOutput

Present Login User Report Collaborative Diagram

2: validate

Login

1: login
Admi
n

3: validLogin

4: getPresentUsingReport
7: ReportOutput
5: selectInfo

Repo
rt

6: ReportInfo

Data
Base

User-Level Sequence Diagrams

1. Admin Sequence Diagram

2. Collector Sequence Diagram

3. MRO Sequence Diagram

4. VRO Sequence Diagram

ACTIVITY DIAGRAMS

ACTIVITY DIAGRAMS
1. Servlet Container

2. Administrator Activity Diagram

3. Collector Activity Diagram

4. MRO Activity Diagram

5. VRO Activity Diagram

Component Diagram

Component Diagram :

Deployment Diagram

Deployment Diagram:

Data Dictionary

Data Disctinory
DISTRICT

MANDAL

VILLAGE

MROPAYDETAILS

REVDEPTDETAILS

REVENUE

REVLOGINMASTER

VROPAYDETAILS