Audit Report (Civil) for the year ended 31 March 2007
In the manual system, the
was responsible for the up-to-datemaintenance of RoR and ‘Register of Mutation’ in respect of lands in allvillages within his jurisdiction.Based on the outcomes of pilot study, it was decided to computerise villageform 7/12, Form 8a and Form 6 (
) or Mutation Register. GOGdecided (1998) to hand over the project to NIC for system study, softwaredevelopment, implementation and all technical support including training forCLR scheme. The software package for computerisation of land recordsknown as “
” was developed by the NIC in UNIX platform. NeitherUser Requirement Specifications (URS) were obtained by the NIC nor hadNIC done proper system study/analysis. Further, the NIC did not prepareSystem Requirement Specifications (SRS) report for software for acceptanceby the department after its evaluation. Not assessing the users requirementsresulted into some of the important provisions of the Land Recordsmanagement not getting provided for in the system as on conversion of ‘agricultural land’ into ‘non agricultural land’, system should remove/withholdall details such as name of farmers, type of land, irrigation facilities, crop, etc.from the RoR. However, sample RoRs, in respect of agricultural land,converted into non-agricultural land revealed that all these details are stillpersisting in RoRs.
3.3.8 Change Management Control
Changes/amendments to the package (system) need to be properly authorised,tested, accepted and documented. These procedures were not followed and nochanges were documented. Even, history of the different versions of thedifferent Modules of the system issued by NIC was not maintained and SMCwas not having any record for the changes in the system made by the NIC,when the amended versions were released. It was observed that changes forremoving ‘bugs’ or for any other requirement to improve the functionalitywere directly made by the NIC at the request of the end-users. No recordswere kept of these changes and different versions of the modules were in usein various e-Dhara kendras.
3.3.9 Input controls
The objective of
is to ensure that the procedures and controlsguarantee that (i) the data received for processing are genuine, complete, notpreviously processed, accurate and properly authorised and (ii) data areentered accurately and without duplication.
is a process forchecking transaction data for any errors or omissions and to ensure thecompleteness and correctness of input. Lack of such data validation checks inthe Software coupled with inadequate and ineffective input controls likesupervisions, etc. resulted in irrelevant and incorrect data being fed in thesystem; thus putting a question mark on the reliability of the data. Somefindings arrived at by analyzing the data are illustrated below.
On conversion of ‘agricultural land’into non-agriculturalland, the system wasnot removing/ withholding details of farmers, type of land,irrigation facilitiesand crops, etc.Irrelevant andincorrect data beingfed in the system dueto lack of datavalidation coupledwith inadequate andineffective inputcontrols.