Computerized Integrated Police Database Management System - DOC by msv19261

VIEWS: 0 PAGES: 77

More Info
									          SUMMON/WARRANT REGISTER MAINTAINED RECEIVED AT THE
                           POLICE STATION


                          PROJECT REPORT SUBMITTED TO




                                 Jiwaji University ,
                                      Gwalior



                IN PARTIAL FULFILLMENT FOR THE AWARD OF DEGREE OF
                      MASTER OF COMPUTER APPLICATIONS (MCA)


                                     2008
                                      BY
                               APOORVA BHARGAVA




Project Coordinator                                      Project Guide

( D.N.Goswami)                                         {Mr. S. Madhu }
 Head,
SOS in Computer Science
Jiwaji University ,
Gwalior – 474 011.
                                  S.O.S. in Computer Science & Applications
                                               Jiwaji University
                                              Gwalior – 474 011




{this certificate must be typed on HOD‟s letter head }




                                                 CERTIFICATE




This is to certify that { Name of Student }, student of M.C.A. (Final Semester), January 2008 –
June 2008 session of this institute has completed his final semester project entitled
……………………………………………………………………...
Undertaken at ……………………………………………………………………….

He has submitted a satisfactory project report for the award of degree of Master of Computer Applications (MCA) of Jiwaji
University , Gwalior .
                            GOVERNMENT OF INDIA
   MINISTRY OF COMMUNICATIONS & INFORMATION TECHNOLOGY

               DEPARTMENT OF INFORMATION TECHNOLOGY


          National Informatics Centre
      This is to certify that Apoorva Bhargava ID.N0: 10506a student of MCA from Jiwaji

      University, Gwalior(Institute/University)

      has done/is doing his/her full-semester project training at CIPA Division, NIC, New

      Delhi, from Jan,2008 to June,2008.


      The project work entitled Summon/Warrant Register Maintain Received at the Police

      Station.embodies the original work done by Apoorva Bhargava during

      his/her above full semester project training period.




Project Guide/HOD                                    Head, Training Division
                                     DECLARATION




       I, APOORVA BHARGAVA , hereby declared that the project entitled “Common Integrated
Police Applications” which is being submitted in partial fulfillment of the requirements for the awards
of degree of M.C.A. is an own record carried out by me under the supervision of Mr. S.Madhu
(Scientist-C). The matter embodied in this project has not been submitted so far for the award of any
degree or diploma.


Apoorva Bhargava
M.C.A. –6 th Semester
JIWAJI UNIVERSITY
GWALIOR,MP-474011




                               ACKNOWLEDGMENT

I would like to take up this opportunity to express my profound sense of gratitude and respect to
all those who helped me throughout the duration of this project.



First of all, I express my sincere gratitude to Dr. Ambreesh Kumar (DDG) for giving me an
opportunity to work on “CIPA Project”.


Special thanks to Mrs. Santosh Wadhwa (Technical Director) and Mr. S. Madhu(Scientist-C) project
guide for all the help and guidance extended to me by her in every stage during my training. Their
inspiring suggestions and timely guidance enabled me to perceive the various aspects of the project in a
new light.
Last but not the least, I would like to make a special mention of the support, help and encouragement I
received from my team members which were critical in the development of this project and without
which I would not have been able to complete the project.


My greatest thanks go to National Informatics Center, Delhi for giving me the opportunity to work
with them and providing me with necessary resources for our project.




                                                                        APOORVA BHARGAVA

                                                                        ROLL NO. - 1539

                                                                                M.C.A. VI Sem




                                           PREFACE


This project report provides an elaborate coverage of the salient features of developing software,
its capabilities, and its limitations and of course all software development process followed.
Common Integrated Police Application (CIPA) is Application software developed by NIC for
State Police, designed to automate the processes at the Police Station level relating crime and
criminals in a work flow manner, with an objective to reduce the manual records keeping and
faster information retrieval.
The process starts with the registration of Cases, and capturing of developments taking place from
time to time during its investigation and prosecution stages. It also facilitates maintaining a very
comprehensive database of various Criminals and Gangs needed by the Police Station.
Although the benefits of automating the Police Stations would be a long list, but some of them are
mentioned below:

      Providing a computer generated copy of the FIR to the Complainant
      Keep track of the status of cases.
      Supervision by the senior officers.
      Reduction in the manual Records Keeping.

The functionalities provided in the software at present can broadly be classified into the following
modules:

      Registration
      Investigation
      Prosecution
      Information
      Output Reports/Queries
      Administration

        Software Administration
        Change Password
        Police Station Management




Module Description: Police Station Management (Summon/Warrant received for the Police
Station)
The POLICE STATION MANAGEMENT module of the software includes the following sub-modules:

      Summon
      Warrant

The Summon/Warrant Register module facilitates Police Stations in maintaining the register which
records the Summons & Warrants received for the Police Station. Various details of the Summons
& Warrants falling under its jurisdiction viz. Handed-over for execution, Executed & submitted,
Returned etc.
The Summon/Warrant Register module facilitates Police Stations in maintaining the        register for
Summon/Warrant that issued against Accused, Witness so that these records helps the Court in
providing Evidence of the case in PS. This register maintain the records for summon/warrant
issued against the Accused/Witness whose records are maintained in the PS. Separate series is
also generated for Summon and warrant, initialized yearly. We save the records like Registration
Date, Registration Type, Registration Type Serial No, Location(State, District, P.S.), Date of Issue,
Date of Receipt, Received from(Place), Date of Presence in Court, Court Type, Court Name, Court
File No, Issue To(Accused, Witness) and also maintained the personal details of Accused or
Witness. Personal details like Name, Sex, Address, Parentage, Nationality, etc. When these
records are saved then further progress events happen.
The progress button opens windows for the THREE sub-Events viz.

   40210: Handed over for execution
   40211: Executed & Submitted
    40212: Returned,    in the same sequence.

If we maintain these records manually, then this is a complex task and consumes more time and
efforts. Summon/warrant register makes our task much simpler & easier and helps a lot in
tracking the Summons & Warrants issued to whom.

Software and Hardware Requirement

    Hardware Recommended
    Intel Pentium processor at 500 MHz or faster
    Minimum512 MB memory
    Maximum 1GB Memory
    Software Recommended
    Software: Java, Swings
    Editor: Net Beans IDE 5.5.1
    DBMS: PostgreSQL
    Operating system: Linux




Table of Contents
1    Introduction .................................. Error! Bookmark not defined.Error! Bookmark not defined.
  1.1     About NIC ............................ Error! Bookmark not defined.Error! Bookmark not defined.
  1.2     Brief description of Project .. Error! Bookmark not defined.Error! Bookmark not defined.
     1.2.1     Introduction .................. Error! Bookmark not defined.Error! Bookmark not defined.
     1.2.2     Purpose ......................... Error! Bookmark not defined.Error! Bookmark not defined.
     1.2.3     Scope ............................ Error! Bookmark not defined.Error! Bookmark not defined.
     1.2.4     Benefits ........................ Error! Bookmark not defined.Error! Bookmark not defined.
     1.2.5     Functional Requirements ............ Error! Bookmark not defined.Error! Bookmark not
     defined.
     1.2.6     Transaction Handling in CIPA .... Error! Bookmark not defined.Error! Bookmark not
     defined.
  1.3     System Requirements ........... Error! Bookmark not defined.Error! Bookmark not defined.
  1.4     Tools & Technology Used ... Error! Bookmark not defined.Error! Bookmark not defined.
2    System Analysis: .......................... Error! Bookmark not defined.Error! Bookmark not defined.
  2.1     Information Gathering .......... Error! Bookmark not defined.Error! Bookmark not defined.
  2.2     Existing System.................... Error! Bookmark not defined.Error! Bookmark not defined.
  2.3     Software Requirement Specifications (SRS) ............... Error! Bookmark not defined.Error!
  Bookmark not defined.
     2.3.1     Need for SRS ............... Error! Bookmark not defined.Error! Bookmark not defined.
     2.3.2     Software Function Overview ...... Error! Bookmark not defined.Error! Bookmark not
     defined.
  2.4     Feasibility Study................... Error! Bookmark not defined.Error! Bookmark not defined.
3    System Design:............................. Error! Bookmark not defined.Error! Bookmark not defined.
  3.1     Logical Design: .................... Error! Bookmark not defined.Error! Bookmark not defined.
  3.2     Physical Design: ................... Error! Bookmark not defined.Error! Bookmark not defined.
  Software Design Architecture: ......... Error! Bookmark not defined.Error! Bookmark not defined.
  3.3     Database Design:.................. Error! Bookmark not defined.Error! Bookmark not defined.
  3.4     Screen Shots ......................... Error! Bookmark not defined.Error! Bookmark not defined.
4    Coding & Reports ........................ Error! Bookmark not defined.Error! Bookmark not defined.
5    System Testing And Implementation .......... Error! Bookmark not defined.Error! Bookmark not
defined.
  5.1     Testing.................................. Error! Bookmark not defined.Error! Bookmark not defined.
  5.2     Implementation: ................... Error! Bookmark not defined.Error! Bookmark not defined.
6    Conclusion and Further Scope ..... Error! Bookmark not defined.Error! Bookmark not defined.
7    Appendix ...................................... Error! Bookmark not defined.Error! Bookmark not defined.
8    Bibliography................................. Error! Bookmark not defined.Error! Bookmark not defined.




   1. Introduction


       1.1 About NIC

              National Informatics Center(NIC) is a premier Information Technology organization in
India. NIC started functioning in 1977 since then it played a promotional role in developing and
implementing computer based information systems for decision support in the ministries and
department of Central Government. It provides state-of-the-art solutions for the IT needs of the
Government of India at all levels. NIC carries the distinction of being the largest IT Organization in the
Country and has set up a satellite based nationwide computer communication network called NICNET
having over 1400 nodes connecting the National Capital, the State Capitals and the District
Headquarters to one another.

        The IT services of NIC range from Consultancy, Software Design & Development, Office
Automation and Networking Services to Training, Video Conferencing, CAD, EDI, Multimedia and
Internet Services including Web Site Development and Hosting. NIC has a nationwide presence with its
offices spread all across the Country, from Leh to Andaman & Nicobar Islands.
NIC was set up with the objective to promote economic, social, scientific and technological activities,
and also for macro-economic adjustment programme of the Government, through the applications of
IT.
         NIC has emerged as an agent of change in the user organizations by providing extensive training
facilities. The training methodology of NIC includes the use of state-of -art training tools such as
computer-based tutors(cuts) and multimedia systems. NIC is the nodal S&T organization of
Government of India under the planning commission to introduce IT tools for Management Support
System(MSS),Development of Databases(DB),Model Bases(MB)& Knowledge Bases(KB),Decision
Support System(DSS),Geographical Information System (GISNIC).
 Some of the most important note worthy projects, which offer a glimpse of the multifaceted, diverse
activities of NIC, touching upon all spheres of e-governance and thereby influencing the lives of
millions of citizens of India are given below:

            Agricultural Marketing Information Network (AGMARKNET)

            Central Passport System

            Community Information Centers (CICs)

            Computerized Rural Information Systems Project (CRISP)

            Court Information System (COURTIS)

            Department of Agriculture Network (DACNET)

            Examination Results Portal

            India Image

            Land Records Information System (LRIS)

            National Hazardous Waste Information System (NHWIS)

            Public Grievance Redress and Monitoring System (PGRAMS)

            Spatial Data Infrastructure (SDI)

            Training

            Video Conferencing

       Web Site of NIC : http://indiaimage.nic.in/
1.2 Brief description of Project

        Common Integrated Police Application (CIPA) is an Application software developed by NIC for
  State Police, designed to automate the processes at the Police Station level relating crime and
  criminals in a work flow manner, with an objective to reduce the manual records keeping and faster
  information retrieval. The process starts with the registration of Cases, and capturing of
  developments taking place from time to time during its investigation and prosecution stages. It also
  facilitates maintaining a very comprehensive database of various Criminals and Gangs needed by the
  Police Station.

               1.2.1 Introduction:

               The Police functionalities in most of the cases are largely manual. Police stations in the
country keep manual records of events, crimes, investigation etc. The registration and investigation and
other Police tasks most certainly require some degree of automation that would not only improve the
work quality of police but also the efficiency.

               1.2.2 Purpose:

                The main task of computerizing the Police functionalities is to maintain the details
pertaining to all the activities of the Police Stations relating Crime & Criminal. The System will
provide required information to the higher levels periodically and as and when required. The system
will also generate various statuary reports for the smooth functioning of the Police Station. It will also
have the facility for additional reports.




              1.2.3 Scope:

               CIPA (Common Integrated Police Application) focuses on the functional and the day-to-
day work requirements of various Police Stations which includes the Registration of various cases in
form of FIR‟s including Unclaimed Properties, Missing persons reported at the Police Stations, their
investigation by recording the information about the progresses form time-to-time in the case including
coordination of lost and the recovered properties, Disposal/Charge Sheeting by Police, Prosecution
which results in Disposal of Case by the Court etc. CIPA also focuses on the current practices,
procedures and problems at the Police Stations and translates them into broad system specifications and
software requirements.




               1.2.4 Benefits:

               Although the benefits of automating the Police Stations would be a long list, but some of
them are mentioned below:
               Significant reduction in manual register maintenance
               Elimination of duplicate and inconsistent record keeping.
               Facilitate for maintenance of details of Criminals.
               Keep track of the Status of Cases.
               Introducing element of transparency in the working of Police.
               Facilitating Investigating Officer with availability of Records.
               Facilitating supervision by the Senior Officers.
               Generate various other reports required from time to time.
               Faster Response to Public.

               1.2.5 Functional Requirements:

               The Software for the Police Stations has been classified, functionally, broadly into the
       following SIX modules:
            Registration
            Investigation
            Prosecution
            Information
            Output Reports/Queries
            Administration
               Software Administration
                   Police Station Staff Maintenance
                   Backup
                   Restore
                   Beat Maintenance
                   Registration Sequence Court
                   Court
                   Data Transmission to CCIS
                   Reset Update Permission
               Change Password
               Police Station Management




          Registration Module
                The Registration is the starting point of a case, setting the police in motion, which can be
further classified as:
             Cognizable offenses (First Information Report).
             Missing Persons.
             Unclaimed Properties.
             Medico Legal Cases.
            Unnatural Deaths.
            Deserters.
            Non – Cognizable Cases.




          Investigation Module
               This module allows the Investigating Officer (IO) to record the Information about the
developments/progresses taking place from time-to-time in the Case, as and when takes place/made by
the IO, from his Case Diary. „Investigation‟ of a Case in general may consists of the following types of
Progress/Development, taking place at a given point of time during investigation, which are recorded in
various Registers maintained at the Police Station:
            Details of Crime.
            Recording Details Of Victims Arrested/Surrendered Of Accused.
            Interaction with Other Police Stations. Interaction with Various Agencies
               (Finger Print Agencies, Forensic Labs, NCRB Etc.)
            Interaction With The Courts. Details Of Properties Seized/Recovered.
            Seized Property Matched Among Stolen/Involved Properties. Presentation of
               Property in the Court.
            Release of Property to the Authorized Claimant.
            Missing Person Traced.
            Recorded Of Witness Statement.
            Record Of Victims Statement.
            Body Sent For Post Mortem.
            Body Handed Over To Relative After Post Mortem.
            Accused Given Into Police Remand/Sent To Judicial Custody.
            Release of Accused on Bail by Police/Court.
            Generation Of Final Report/Charge Sheet .




          Prosecution
                 This module is designed to record the progress-taking place from time to time in the case
during Prosecution i.e. from filing in the Court, till the Court, in terms of the following activities,
disposes it off:
             Final report/Charge Sheet filed in the Court.
             Hearing of the case held in the Court.
             Summon/Warrant issued by the Court.
             Summon/Warrant executed.
             Accused declared Proclaimed offender or issued Property Attachments Orders
                 by the Court.
             Court disposal form receiver.
              Accused fingerprints sent to FPB/NCRB for record.
              Accused RCN/NCN received from FPB/NCRB.



          Information
        This module will facilitate in maintaining personal records of the criminals and updating it time
to time based on the information received from various sources. The parameters captured are as
follows:
            Personal Records of Criminals.
            Additional details of Criminal, if member of Organized Gangs,
               Terrorist/Militant Organization.
            Profile of Organized Gangs.




          Output Reports/Queries
               This module will facilitate the generation of Reports in the specified format according to
the options. The options in this module are as follows:
            Register maintained in the Police station.
            Periodically reports need to be generated.
            Queries.




          Administration
              This module will be used only by the System Administrator, and will be detailed at the
time of Software Designing. The options in this module are as follows:
            Software Administration

                  Police Station Staff Maintenance
                       This will facilitate us to add or update a member of Staff in the PS. We can also
have a look to the current Staff of the PS.
                  Backup and Recovery of Database.
                  Beat Maintenance.
                  Registration Sequence Court.
                  Court.
                      This facilitate us to add the court type and its name. If in a particular court a new
judge has taken the charge then it can also be updated.
                  Data Transmission to CCIS.
                  Reset Update Permission.
              Change Password
              Police Station Management

Component (Module) Description

Police Station Management(Summon/warrant register maintained for those received at the
PS)
         The POLICE STATION MANAGEMENT Module is preceded by the REGISTRATION,
INVESTIGATION & PROSECUTION module. The POLICE STATION MANAGEMENT module
facilitates us in maintaining a register which records various Summons/Warrants issued against the case
registered in the Police Station. The POLICE STATION MANAGEMENT module of the software
includes the following sub-modules:

            Summon
            Warrant

               Summons are the written order, issued to a person to appear before the court issuing
it. Summons are like a warning or information to the person, either Accused or Witness. Summons can
be issued to both, Accused & Witness.

               Warrants are the written authorization given by court to arrest a person and produce
before the court. Warrants can be bailable or non-bailable. If the Warrant issued to a person returns
three times to the police station then a non-bailable Warrant is issued against the person. Warrants are
always issued to Accused.

               Various details of the Summons & Warrants falls under its jurisdiction viz. Handed-over
for execution, Executed & submitted, Returned etc.

                Keep track of these records manually is a complex task. This automation helps in
maintaining these records. While filling the details in this register we must remember that since a case
is registered first, then a summon is issued against a case, a receipt is generated after all these processes
witness has to appear in the court. So there I have put some validations that all these dates must follow
this chronological order, i.e. Registration date must be less than Issued Date, Issued Date must be less
than Receipt Date and Date of Presence in court. I haven't put any validation on Receipt Date and Date
of Presence in Court because sometimes the receipt appeared to a person after date of it's presence in
court.

             The Summon/Warrant Register module facilitates Police Stations in maintaining the
register for Summon/Warrant that issued against Accused,Witness so that these records helps the Court
in providing Evidence of the case in PS. This register maintain the records for summon/warrant issued
against the Accused/Witness whose records are maintained in the PS. Separate series is also generated
for Summon and warrant ,initialized yearly.

               We save the records like Registration Date, Registration Type, Registration Type Serial
No, Location(State, District, P.S.), Date of Issue, Date of Receipt, Received from(Place), Date of
Presence in Court, Court Type, Court Name, Court File No, Issue To(Accused,Witness) and also
maintained the personal details of Accused or Witness. Personal details like Name, Sex, Address,
Parentage, Nationality etc. When these records are saved then further progress events happen.


       The progress button opens windows for the THREE sub-Events viz.
                 40210: Handed over for execution
                 40211: Executed & Submitted
                 40212: Returned, in the same sequence.

 The description of sub-Events are as follows:

               Handed over for execution :

                        After issuing the Summon/Warrant, it is been Handed over to a staff member of
Police station who is going to hand the summon/warrant to the person. Under this Event we capture the
details of when ,i.e.,on which date it is handed and to whom it is handed for execution.

               Executed & submitted:

                     After handing the Summon/Warrant to a police station staff member for
execution. Now that police personnel went to that person's place where he has to execute the
Summon/Warrant. Now there are 4 ways in which he can execute that Summon/Warrant

           1. He will directly handed to the person against which Summon/Warrant is issued.

           2. He will handed to its relatives.

           3. If nobody is there to receive the Summon/Warrant and the place originally belongs to
              that person then he may also pasted it on the wall.

           4. If that place doesn't belongs to that person, means if the address is fake then in that case
              the Summon/warrant is mentioned as Not executed.



                        In case of Not executed proper reason for not execution is noted and further what
steps are need to be taken are noted. Whether the Summon/Warrant is successfully executed or not we
have to capture its submitted date in the police station. If the execution is successful then we capture
the person's arrest date.

                     We save the records under following fields Date executed, Execution type,
Reason,if not executed, Steps Taken, Date submitted to PS, Arrest Date.
               Returned :

                     This event is always followed by 2 other events, namely, Handed over for
execution & Executed and Submitted. Whenever the Police Personnel returns back from the execution
of Summon/Warrant that date is also mentioned in the Station Register.
                     In case of not execution of Summon/Warrant, the court will issue another
Summon/Warrant so Register will maintain that R.C. No. also, to whom it has been returned and, if any
comments are need to be mentioned.
                      All such details are captured in Returned Form under the following fields
Returned Date, R.C. No., Returned To, Remarks.


       1.2.6 Transaction Handling in CIPA

                Need For Transaction Handling
                Transaction is used to represent a logical unit of database processing that must be
completed in its entirety to ensure correctness. Transaction handling is an important concept in the
implementation of the entire application. The need for transaction arose when we try to perform
concurrent operations on a database, and while performing these operations some errors occurs. In such
a situation following problems can arise:
             The Lost Update Problem.
             The Temporary Update (Dirty Read) Problem.
             The Incorrect Summary Problem.


               The result of all these problems is inconsistency. To avoid such inconsistency,
transaction handling is a must. While implementing transaction, four Features/Properties of transaction
called as Acid Properties are kept in mind:

              Atomicity
                    A transaction is an atomic unit of processing; it is performed in its entirety or not
performed at all.

             Consistency preservation
                     A transaction is consistency preserving if its complete execution take(s) the
database from one consistent state to another.

              Isolation
                        A transaction should appear as though it is being executed in isolation from other
transactions. That is, the execution of a transaction should not be interfered with by any other
transactions executing concurrently.

              Durability or permanency
                    The changes applied to the database by a committed transaction must persist in
the database. These changes must not be lost because of any failure. To, implement transaction
handling in our project, Architecture has been designed that is explained in the next section.
Architecture basically consists of few Layers/Levels that provide a framework for the entire application.




1.3      System Requirements
       Hardware Recommended:
               Intel Pentium processor at 500 MHz or faster
               Minimum 512 MB memory
               1GB Memory
       Software Recommended:
               Software: Java,Swings
               Editor: Net Beans IDE 5.5.1
               DBMS: PostgreSQL
               Operating system: Linux




       1.4 Tools & Technology Used

        Technologies and tools are strongly related to the approach of software development. What the
tools can or cannot do significantly impact what principles that can be used, as well as what objectives
that can be fulfilled. While selection of a particular methodology may imply use of certain tools, the
tools themselves often leave significant room for developers to choose how to use them. The selection
has therefore been based mainly on the objectives of the project, while the methodologies were selected
after the tools were selected, due to the fact that technologies and tools poses certain restrictions of how
development can be done.

       Development Environment:
             The software is developed using JAVA Technology and Open Source tools viz. Linux
Operating System and PostgreSQL 8.0 as the RDBMS. It Uses the JDBC (Java Database
Connectivity). Integrated Development Environment (IDE) viz. NetBeans, is being used for the Source
Code development.


       JAVA

      The term Java actual refers to more than just a particular language like C or Pascal. Java
encompasses several parts, including:

    A high level language:
     Java language is a high level one that at a glance looks very similar to C and C++ but offers
     many unique features of its own.

    Java bytecode:
      A compiler, such as Sun's javac, transforms the Java language source code to bytecode that
     runs in the JVM.

    Java Virtual Machine (JVM):
     A program, such as Sun's java, that runs on a given platform and takes the bytecode programs
     as input and interprets them just as if it were a physical processor executing machine code.

       Java Swings
                Swing is a new GUI component kit that simplifies and streamlines the development of
windowing components. Windowing components are the visual components (such as menus, tool bars,
dialogs and the like) that are used in graphically based applets and applications. The Swing component
set is part of a new class library called the Java Foundation Classes, or JFC. JFC. Swing makes up the
bulk of JFC. JFC is also comprised of Java 2D, Drag and Drop, and the Accessibility APIs.
        Swing components are lightweight:
                First, Swing components are designed in accordance with a lightweight component-
design specification that was introduced with JDK 1.1. That means that Swing components don't use
any platform-specific implementations (which AWT programmers often refer to as "peers.") Instead,
Swing creates its components using pluggable look-and-feel (PL&F) modules that are written from
scratch and don't use any peer code at all.


        NetBeans IDE -The NetBeans IDE includes an intuitive GUI Builder as well as
comprehensive support for developing plug-in modules, and rich client applications based on the
NetBeans platform. The NetBeans IDE is an open source integrated development environment written
entirely in Java using the NetBeans Platform. NetBeans IDE supports    development of all Java
application types(EJB,J2SE,Web and Mobile          applications). Among other features are an Ant-
based project system,version control and refactoring. NetBeans 5.5.1 builds on the functionality of
NetBeans5.5 and also provides several bug fixes.
          Using NetBeans, developer can Write and edit source code, See errors while typing, See
           highlighted code syntax, Compile code, Browse class structures, Use drag-and-drop
           utilities for easy building of features, such as graphic objects or creating database
           connections. The NetBeans 3.6 is an open source IDE. It also support for CVS/Version
           control access.

        PostgreSQL is an object-relational database management system (ORDBMS) based on
PostgreSQL,version 4.2,developed at the University of California at Berkeley Computer Science
Department. PostgreSQL is an open source descendant of this original Berkeley code. It supports a
large part of the SQL: 2003 standard and offers many modern features:

              Complex Queries
              foreign keys
              Triggers
              Views
              Transactional Integrity
              multi version concurrency control




   PostgreSQL can be extended by many ways,for example :
           data types
           functions
           operators etc
   PostgreSQL is now the most advanced open-source database available anywhere.

               An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-
Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication,
nested transactions (savepoints), online/hot backups, a sophisticated query planner/optimizer, and write
ahead logging for fault tolerance. It supports international character sets, multibyte character encodings,
Unicode, and it is locale-aware for sorting, case-sensitivity, and formatting. It is highly scalable both in
the sheer quantity of data it can manage and and in the number of concurrent users it can accommodate.
There are active PostgreSQL systems in production environments that manage in excess of 4 terabytes
of data. Some general PostgreSQL limits are included in the table below.


Limit                           Value
Maximum Database Size           Unlimited
Maximum Table Size              32 TB
Maximum Row Size                1.6 TB
Limit                         Value
Maximum Field Size            1 GB
Maximum Rows per Table        Unlimited
Maximum Columns per Table 250 - 1600 depending on column types
Maximum Indexes per Table Unlimited


PostgreSQL has won praise from its users and industry recognition, including the Linux New Media
Award for Best Database System and three time winner of the The Linux Journal Editors' Choice
Award for best DBMS.

       Linux (Operating System) is a UNIX like computer operating system. Linux is one of the
most prominent examples of free software & open source development.
The name ”Linux” comes from the Linux kernel, started in 1991 by Linus Torvalds. Predominantly
known for its use in servers, it is used as an operating system for a wide variety of computer hardware,
including desktop computers, supercomputers, video games and embedded devices such as mobile
phones, routers and stage lighting system. Its wide availability and portability meant that it was widely
adopted, copied and modified by academic institutions and businesses.

Model-View-Controller (MVC) Architecture

        Model-View-Controller architecture is all about dividing application components into three
different categories Model, View and the Controller. Components of the MVC architecture have unique
responsibility and each component is independent of the other component. Changes in one component
will have no or less impact on other component. Responsibilities of the components are:

       Model: Model is responsible for providing the data from the database and saving the data into
the data store. All the business logic is implemented in the Model. Data entered by the user through
View are check in the model before saving into the database. Data access, Data validation and the data
saving logic are part of Model.

        View: View represents the user view of the application and is responsible for taking the input
from the user, dispatching the request to the controller and then receiving response from the controller
and displaying the result to the user. HTML, JSPs, Custom Tag Libraries and Resources files are the
part of view component.

       Controller: Controller is intermediary between Model and View. Controller is responsible for
receiving the request from client. Once request is received from client it executes the appropriate
business logic from the Model and then produces the output to the user using the View component.
ActionServlet, Action, ActionForm and struts-config.xml are the part of Controller.
System Analysis :

       2.1 Information Gathering

       Information about the Firm:

 National Informatics Center (NIC) is a premiere organization of the Government of India in the field
of Informatics Services and Information Technology (IT) applications, and has been instrumental in
steering Information and Communication Technology (ICT) applications in Government Departments
at Central, State and Districts in government services, wider transparency in government functions, and
improvement in decentralized planning and management.

       Information about Project:
     During the analysis, we collected whole information from “Mr. S.Madhu” and “Mrs. Santosh
Wadhwa” whose designations are Scientist-C and Technical Director, respectively, and other staff
members in the CIPA division at National Informatics Center, New Delhi.

       Information Gathering Tools:
       We have collected the information about the current system from:
        Reports
        Personnel Staff
        System Documentation & Manuals

       The main sources of information:
        User of system
        Documents used in the organization.
        Procedure manuals and rule manuals, which specify how an ideal CIPA Software should
          work.
        Recursive discussions in Team.
        Guidelines of Seniors
       While gathering information from the human beings like our seniors or user of system, a
       proper hierarchy should be followed.

After gathering information, there should be recursive discussion in the team after regular interval and
after personal level analysis. As this is the process which can help in break up the needs in minute form.
And thus help us to properly recognize the needs.

2.2 Existing System

       Existing Manual System :

              Reporting of a Case:
                     “Information” in form of a complaint or accusation or commission of a crime or
            unnatural property etc. received at Police Station through someone in person or by any
            communication means with the object of settling the police in motion is called Reporting
            of a Case. To mention the time of commission and the circumstances in which and by
            whom it was committed is not essential in reporting.

              Registration of a case:

               Every information relating to the commission of an offense whether cognizable or non
cognizable as decided by the Station House Officer (SHO) by referring to the 1st Schedule of CrPC
which lays down such distinction; if given in person orally, is reduced to writing and is read over to the
informant and signed by the person giving it.
Information of the commission of a cognizable offense leads to the registration of the First Information
Report (FIR). The Principal object of the First Information Report from the point of view of the
informant is to set the criminal law in motion, and from the point of view of investigating authorities is
to obtain information about the alleged criminal activity so as to able to take suitable steps to trace and
bring to book the guilty. There is no rule or principle of evidence requiring that the victim should
always be the first informant. An FIR, which sets the process in motion, can come from any quarter,
including suo-moto registration by police.

              Investigation of a case:

               After the registration of Case, the Investigating Officer (IO), to whom the Investigation
of the Case has been entrusted, visits the scene of crime. He will record the statements of Victim(s),
Witness (es); collect material evidence & exhibits and seize them by preparing Seizure Memo for each
property Seized; record the details of crime, modus operandi, methods, make sketch/ drawing of scene
of crime etc.‟ record the details of properties stolen, if any, Medico Legal Case (MLC) is made to get
the necessary medical examination done, if the Victim is injured. In case of a dead body necessary
Inquest and/or PostMortem are done. If the seized property requires expert opinion eg. Firearm,
explosive substance , bloodstains etc. the same is sealed and sent to Forensic Science Laboratory (FSL)
for expert opinion Fingerprints lifted from the scene of crime are sent for coordination to Finger Print
Bureau(FPB).

The Investigating Officer (IO) opens the Case Diary (CD) and keeps recording proceedings of the
investigation i.e. findings, progress etc. Section 172(I) CrPC should be maintained and entered day-by-
day by the IO during investigation. Such diary should record clearly and concisely, the steps taken by
the IO, the circumstances ascertained through the investigation and the other information required by
Section 172(i) CrPC. Only such incidents of the investigation shall be included as having bearing on the
case. Crime Details, detailed list of stolen properties or of properties seized during investigation shall
be entered in the first case diary submitted after the related facts were reported to or discovered by the
IO. CD consists of two parts, Part-I describe the investigation progress and results, and Part-II includes
the Witness statements and details. In order to facilitate the IO, some templates can also be prepared,
which may be required to be filled on the spot, like seizure memo, personal search, MLC request form
etc.
The IO effects any arrest at the time of visiting the scene of crime or later during investigation, by
filling the Arrest Form (LLL.-III) giving details of the accused, and recording the articles found in his
personal search. In suitable cases, the fingerprints and the photographs of the accused are taken, and the
fingerprints are sent to the Finger Print Bureau (FPB) for comparison. In bailable cases, as per the
guidelines laid down in 1st Schedule of CrPC, the arrested is released by the IO after taking necessary
Bail bond. In non-bailable cases, the accused is presented before the Court. An entry is also made in the
History Sheet/ Personnel Dossier of the accused to this effect, or an Information Sheet is sent to the
concerned Police Station, if the accused belongs to some other Police Station anywhere in the country.

              Prosecution of a case:

              On completing the Investigation, the IO prepares his Police Report/Final Report/ Charge
Sheet of the case u/s 173 CrPC, and submits it in the court for initiating the Prosecution proceedings,
along with a notice to the complainant. Where IO found that no case is made out, the Final Report is
submitted subject to acceptance of the Court.

       In the manual system, the main problems faced are
        time lag
        accuracy
        maintenance of records
        deviations from uniform procedures etc.




2.3 Proposed System

      The proposed system will take care of all the common activities to maintain uniformity of
procedures. To take care of technological advancement, change requirement is addressed separately.
The functionalities provided in the software at present can broadly be classified into the following
modules:

    Registration

      Investigation

      Prosecution

      Information

      Output Reports/Queries

      State Specific Functions

      Administration

    Registration Module
      The Registration is the starting point of a case, setting the police in motion, which can be
       further classified as:

          Cognizable offenses (First Information Report).
          Missing Persons.
          Unclaimed Properties.
          Medico Legal Cases.
          Unnatural Deaths.
          Deserters.
          Non – Cognizable Cases.


          Investigation Module :

              This module allows the Investigating Officer (IO) to record the Information about the
developments/progresses taking place from time-to-time in the Case, as and when takes place/made by
the IO, from his Case Diary. „Investigation‟ of a Case in general may consists of the following types of
Progress/Development, taking place at a given point of time during investigation, which are recorded in
various Registers maintained at the Police Station:

          Details of Crime.
          Recording Details Of Victims
          Arrested/Surrendered Of Accused
          Interaction with Other Police Stations.
          Interaction with Various Agencies (Finger Print Agencies, Forensic Labs, NCRB Etc.)
          Interaction With The Courts
          Details Of Properties Seized/Recovered.
          Seized Property Matched Among Stolen/Involved Properties.
          Presentation of Property in the Court.
          Release of Property to the Authorized Claimant.
          Missing Person Traced.
          Recorded Of Witness Statement
          Record Of Victims Statement
          Body Sent For PostMortem.
          Body Handed Over To Relative After PostMortem.
          Accused Given Into Police Remand/Sent To Judicial Custody.
          Release of Accused on Bail by Police/Court.
          Generation Of Final Report/Charge Sheet


             Prosecution:

             This module is designed to record the progress-taking place from time to time in the case
during Prosecution i.e. from filing in the Court, till the Court, in terms of the following activities,
disposes it off:

           Final report/Charge Sheet filed in the Court.
           Hearing of the case held in the Court.
           Summon/Warrant issued by the Court.
           Summon/Warrant executed.
           Accused declared Proclaimed offender or issued Property Attachments Orders by the Court.
           Court disposal form receiver.
           Accused fingerprints sent to FPB/NCRB for record.
           Accused RCN/NCN received from FPB/NCRB.

                  Information:

               This module will facilitate in maintaining personal records of the criminals and updating
it time to time based on the information received from various sources. Th parameters captured are as
follows:

         Personal Records of Criminals.
         Additional details of Criminal, if member of Organized Gangs, Terrorist/Militant
          Organization.
         Profile of Organized Gangs.



                  Administration:

              This module will be used only by the System Administrator, and will be detailed at the
time of Software Designing. Some of the options in this module may be as follows:

           Master Tables Maintenance
           Backup and Recovery of Database
           Users Account Maintenance

        The proposed system has been developed to achieve the following objectives:
         Elimination of duplicate and inconsistent record keeping.
         Facilitate for maintenance of details of Criminals.
         Keep track of the Status of Cases.
         Introducing element of transparency in the working of Police.
         Facilitating Investigating Officer with availability of Records.
         Facilitating supervision by the Senior Officers.
         Generate various other reports required from time to time.
       Software Requirement Specifications (SRS) :

The last step in System Analysis is the preparation of a document called “Software Requirement
Specification”

       2.3.1 Need for SRS

       There are three major parties interested in a new system: the client, the user, and the developer.
Somehow the requirements for the system that will satisfy the needs of the clients and the concerns of
the users have to be communicated to the developer. The basic purpose of Software Requirement
Specification is to bridge this communication gap. SRS is the medium through which the client and
user needs are accurately specified; indeed SRS forms the basis of software development. A good SRS
should satisfy all the parties. An SRS provides a reference for validation of the final product and
therefore a high quality SRS is a prerequisite to high-quality software.

        Purpose:

 The purpose of this SRS is to address the functional requirements of the proposed Common Integrated
Police Application (CIPA) software, required for implementation at selected Police Stations through
out the country to start with, as per the direction given by the Ministry of Home Affairs. It also includes
the functional requirements of the Reports component within the software. It also forms the basis for all
later references with respect to the System Design, Development and Implementation. It also suggests
various equipments required for the implementation of the software.

        Scope:

The document includes the functional and the day-to-day work requirements of various Police Stations
which includes the Registration of various cases in form of FIR‟s including Unclaimed Properties,
Missing persons reported at the Police Stations, their investigation by recording the information about
the progresses from time-to-time in the case including coordination of lost and the recovered properties,
Disposal/Charge Sheeting by Police, Prosecution which results in Disposal of Case by the Court etc.
During all these activities, the Investigating Officer (IO) has to record all the details during
investigation like crime details, property seized, witness(es) questioned. All these recordings had to be
maintained at a common place so as to refer the case in future. Manual maintenance is difficult and
cumbersome. So, there has to be some automation in generating these Reports. So, the document
focuses on the current practices, procedures and problems at the Police Stations and translates them into
broad system specifications and software requirements.

       Objectives:

The main objective of automating the functionalities of various Police Stations is to maintain the details
of all the activities in different Police Stations related to Crime and Criminal. With this system the
required information is provided to higher levels periodically and various statuary reports are generated
for the smooth functioning of the Police Station. Additional reports can also be generated.
       Benefits :

From a large no. of benefits of automating the Police Stations few of them are listed below:

              Reduction in manual register maintenance.
              Elimination of inconsistent and duplicate record keeping.
              Facilitate for maintenance of details of crimes.
              Keep proper record track of the Status of cases.
              Introducing element of transparency in the working of Police.
              Making Records available to Investigating Officer.
              Facilitating supervision by the Senior Officers.
              Generation of other reports required.
              Active and faster response to public.


       2.3.2 Software Function Overview

              Support of inserting and deleting of rows at run time.
              Support of Sorting, Searching at run time.
              Support for Expressions (a concept developed by our company).
              Support for Nested Data
              Generation of automated Reports at run time.
              Performance Constraints
              Performance constraints are major constraint in our case.

       The system is to be designed for optimum performance. Speedy retrieval and update of the data
       is to be ensured. Factors affecting the overall performance of the product will be taken into
       consideration during the design stage. Some general features and specific performance
       requirement of the system will be as follows:


              The system should have user friendly interfaces.
              The system should be scalable & maintainable.
              The tool used for Report generation should be easy to use

       Hardware/Software Constraints

       Police Stations are proposed to be provided with one server each, along with client PCs and
other peripherals depending on the workload at the respective Police Stations. The CIPA software is
designed on client-server architecture. Development of the application software is proposed to be done
using Java Technologies, and the Open Source Software tools, as proposed by NIC Experts, will be
used for implementation of the application e.g.
       Operating system: Linux
       Web server: Apache Tom Cat
       DBMS: PostgreSQL
       Mail Client/Browser: Mozilla
       Std. Office Automation Software: Open Office




       Database size
       The record length of the various Data files used in the system will be varying depending on the
nature of fields stored in them. The exact record length of the files will be ascertained during the
Database Design. The number of records in each file will also be depending on the number of
transactions taking place of each type. Therefore, an approximation of the hard disk sizing has been
done and put in the hardware requirement.

       Access Privileges
         Provision of a proper authorization system and database security on the application is very
critical. Selected staff members will be assigned a user-id each, by the chosen System Administrator,
for which the password is known only to the authorized person. It is also proposed to define roles for
the users of the Application. Each role will have a defined set of access privileges associated with them.
Working with specific data should be controlled depending upon Role to that User-id. The system will
authenticate the users logging onto the application system and assign the appropriate Role to the User-
id.




       Audit Trail
       Auditing of transaction is to be provided. Sensitive information will have transaction logs,
which will capture the pre-image and post-image of data modifications. Information regarding the users
carrying out these sensitive transactions will also be captured to ensure accountability at every process
level.

       Multi-Lingual Support
      The user interfaces, input screens and reports will support Local languages. However, the
numerical data will be keyed in English only.



2.4 Feasibility Study

       Feasibility study is a test of a system proposal according to its workability, impact on the
organization, ability to meet user needs, and effective use of resources.
System feasibility explains the likelihood that the system will be beneficial to the organization.We did
following feasibility test:
          Technical feasibility
          Operational feasibility
          Economical feasibility

               Technical Feasibility

                During technical analysis, analyst evaluates the technical merits of system concept, while
at the same time collecting additional information about performance, reliability, maintainability and
predictability:
               What technologies are required to accomplish system function and performance?
               What new materials, methods, algorithms or processes are required and what are their
                development risks.
               How will these technology issues affect cost?

                The result obtained from the basis for another go/on-go decision on the test system. If
technical risk is severe, if models indicate that the decision cannot be achieved, if the pieces just won't
fit together smoothly - it's back to the drawing board!

               The projects technical feasibility:
                     The technical issues raised during the feasibility stage of the investigation were:

              N.I.C. has well equipped Labs where all the H/W and S/W tools are available that are
               needed to run the application. So it doesn‟t require extra investment to run the proposed
               application.

              The proposed application will provide all the necessary information to all the users,
               inside and outside the organization, and across the world also if loaded on web.

              Expandability will be maintained in the new system. New modules can be added later on
               the application, if required in the future.


       The application will have User-friendly Forms and Screens, all validation checks. So the new
system guarantees accuracy, reliability, ease of access and data security.

              We have opted Java as development language for developing our project. And in using
lava, we have no technical problems as in our company. Java is the only language, which is used for
developing software. And thus we have a strong hand on this language and also a very talented team.
Hence no overhead incur while using lava as our mainstream language in this project.




           Economical Feasibility
                Among the most important information contained in the feasible study is Cost Benefit
Analysis- an assessment of the economic justification for a computer-based system project. Cost -
benefit analysis delineates costs for project development and weighs them tangible (i.e. measurable
directly in dollars) & intangible benefits of the system. Cost-benefit analysis is complicated by criteria
that vary with the characteristics of system to be developed, the relative size of the project & the
expected return on investment desired as part of company's strategic plan. In addition many benefits
derived from computer-based system are intangible (e.g. better design quality through iterative
optimization, increased customer satisfaction through programmable control & better decisions through
reformatted & pre-analyzed sales data) Direct quantitative comparisons may be difficult to achieve.

               The projects economical feasibility:
                  Hardware and Software Cost
                      Hardware-No new Hardware requirement.
                      Operating system: Linux
                      Software: Java-Free of cost
                      DBMS: PostgreSQL
                      Mail Client/Browser: Mozilla

                The system is very well tested and it will require very less maintenance cost. Just as we
are following iterative model so this will cost a little but it is within reach as we will have no need to do
any enhancements in our core API‟s or so just can add any module to our core API‟s.
          Operational Feasibility

               During operational feasibility, analyst evaluates the operational merits of system
concept, while at the same time collecting additional information about performance, reliability,
maintainability and predictability:
        Is there sufficient support for the project from the management? From users?
        Are current business methods acceptable to the users?
        Will the proposed system cause harm? Will it produce poorer result in any case or area?
          Will the performance of staff member fall down after implementation?

        The projects operational feasibility:
        There was very good response from the top management and from the user, in lieu for
development of the project.
        The users took part actively in investigation cycles, after knowing about the features, that we
provide in this project. Besides it, no harm could be foreseen to developers or to other environment due
to this project. Although it was predicted that this project would definitely increase the productivity of
developers as due to special architecture of CIPA Software which improve the work quality of police
but also the efficiency by computerizing the Police functionalities.
        Hence, with all these economical, technical and operational feasibility study. The. Project
was found feasible to be carried out.

3. System Design :
          3.1 Logical Design:

                 Data flow diagrams :
                     Data flow diagram serves two purposes:
                        1. Provide an indication of how data are transformed as they move through
                             the system.
                        2. To depict the functions (and sub functions) that transform the data flow.

                The DFD provides additional information that is used during the analysis of the
                information domain and serves as basis for modeling of function. A description of
                function in DFD is contained in Functional specification.
Context Level DFD:




                             Complainant                           Incidence place / Public /
                                                                   Hospital/ Witness /Accused



                                      Signed photocopy                  Police inquiry/
                                      of FIR(as                         Investigation
          Diaries                     acknowledgement)                                    Case
          complainant/
          Petition




1 level
DFD:                                                        CIPA
                                                         (Police
                                     Station)
                                            1.
                                        Validate
                                        the
                     Input              User
                                        Input
                          Initiate
  USER                   Data          Variables
                                                                   CIPA
                                                                            Database
               2.            Pass Data
          Call BO              Variables                                 Fetch
          cl-ass for                                                 Data        Insert
          retrieval

                                                            3.
                                                        Logic im-
                                                        plemented for
                                                        data retrieval
                                                        & insertion

                                           Pass
                               Populated
                                           Data


                                4.
                          Template
                          called for              Generated Report       USER
                          final
                          Report




The above DFD generates the Report by following steps:
 First, the user(Police Staff) inputs at the Application (GUI) Layer. The User Inputs are then validated.
After validation is over, Data variables are instantiated and passed on to the BO (Business Object) class
where the Database connectivity is done and also the business logic is implemented. Data is saved in
and fetched from the database and all the Data variables are populated. After that, these populated Data
variables are passed on to the Template class for the final Report generation. This class generates the
Report and pass on to the end user.

      Flowchart :



                                                  START



                                           Enter the User Name
                                              and Password
             Police Station Management




Summon                                    Warrant



  A                                          A




                      Stop




                      A


         Summon/Warrant Register screen



                                No                  Returned
                   Validation                       back to
                      1?                            main
                          Yes                       screen

                   Validation
                      2?
                                                   No


                                         Yes

                                Data committed


                         Progress Button is activated in the
                                  Selected mode



      40210:Handed-over for    40211:Executed &           40212: Returned
            execution             Submitted


                        No       Is Event 40210
                  X
                                    is saved ?
                                         Yes
                                        Y         No     Is Event 40211 Yes   Z
                                                            is saved ?




Event 40210:
     X                Screen of respective
                          Event opens
                                                               Return
                                                               back to
                                                   No          screen
                                     Validation
                                        1?
                                                Yes
                                             Data
                                           committed


Event 40211 :
                         Screen of respective
     Y
                             Event opens



                                                      No        Return
                                       Validation
                                          1?                    back to
                                                                screen
                                             Yes


                                                       No
                                       Empty field
                                       Validation
                                            ?
                                                Yes

                                           Data
                                         committed




Event 40212 :

 Z              Screen of respective
                    Event opens



                                                       Return
                            Validation                 back
                               1?                      to
                                                       screen
                                    Empty field
                                     validation
                                          ?



                                      Data
                                    committed




Validation 1: All Mandatory fields must be filled.
Validation 2: Dates must be in order, i.e. Registration date < Issued date < Receipt date < Presence in
              Court date
VIEW : The main screen opens in non-editable mode.
UPDATE : The main screen opens in editable mode.




   3.2 Physical Design:

       Naming Convention:

       In the above,said module certain naming convention is followed as described below:

          Any new package is registered under gov.nic.cipa.core.client directory.
          All User Interface filenames ends with postfix UI eg ProsRegistrationUI.
          All bean filenames ends with postfix Panel eg. Pros_Header1.
          All Session files ends with postfix Session eg.PSRegSession.
          All business logic filenames ends with postfix BC (Business Classes).
          All filenames that do database handling ends with postfix DAO(Data Access Object).
          All property filenames ends with .properties extensions.
          All DTO (Data Transfer Object) files basically includes all getter and setter methods .Such
           filenames ends with postfix DTO eg. PSRegDTO.
          All objects are prefixed with obj eg. ObjProsRegistrationUI.
          All Variable names should be meaningful and understandable and must starts with small
           case eg. courtType,courtName etc.
       3.3 Software Design Architecture:

        The software is built on the strong foundations of OOP, with Five-Layer architecture, as shown
in the next section Design Architecture.


Request                                                                   Service


                          Graphical User Interface (GUI)




                            Business Objects and Rules




                    Database             Log              Service
                    Manager             Manager           Manager


.                                     PostGreSQL




When the user interacts with the GUI Layer to Fetch/Save/Update data in the database, the flow of
control is from top to bottom. GUI Layer passes the request in the form of DTO variables to Business
Logic Layer.




Business Logic Layer in turn consists of three Internal Layers as shown below:




Request                                                            Service

                             Session Layer
                          Business Class Layer


                       Data Access Object Layer




As shown in the above figure, Business Logic Layer internally passes the DTO variables to its first
Layer which is Session Layer which in turn passes to Business Class (BC) Layer which passes the
request to Data Transaction Object (DAO) Layer. This Layer uses the services of its lower layer which
is Service Layer to obtain the logic for database connectivity and for retrieval of data from the database.
All the above Layers need a medium for carrying data. That medium is Data Transaction Object (DTO)
Variable. DTO variables flow from the top layer to bottom layer carrying the data. Further description
about each layer is given in the next section. Data Transaction Object (DTO) Variables


DTO variables act as medium for carrying the data. DTO flows from the top layer to bottom layer.
Beginning from the GUI layer to DAO Layer, DTO variables are passed as parameter. We consider the
whole structure as different „Pipes‟ in the form of Layers (GUI, Session, BC and DAO) joined together
and DTO Variables as „Water‟ flowing between different „Pipes‟ carrying the required material in the
form of required data.


Database Layer:
It is also called Storage Layer. It deals with defining the Database Schema. Tables and other Database
Structures are developed in this layer. This layer provides access to the stored data. It manages
concurrent requests to read and write to the database. This layer is defined by the database management
system used. CIPA uses PostgreSQL 8.0 as Object relational Data Base Management System
(ORDBMS).

Service Layer:
This Layer is responsible for maintaining Database Connectivity. Along with this, it also takes care of
Log Manager to keep a track of all the user activities which can be helpful in case of any error and
while doing debugging. For maintaining Database Connectivity, it uses Service Manager and Driver
Manager to load the Database Driver for connection with the database. After obtaining the database
connection, it provides this connection to its upper Layer which is Business Logic Layer in the form of
service.

Business Logic Layer:
Business Logic Layer passes the DTO variables it receives from the top layer to its lower layers and
uses the services of its lower layers. Actually, Business Logic Layer is not a single layer. It consists of
three layers as shown above. Description of each of its internal Layers is given below

       Data Access Object (DAO) Layer
                Involves writing the underlying business logic. Its main task is to provide a set Data
Access Objects to the GUI Layer. This layer encapsulates the core functionality of CIPA Application.
This layer consists of components, which manage:
    Execution of pipelined sequence of activities, which could consist of queries.
    Preparation of responses to client requests for data query, update, transformation and retrieval
        activities.
    Responses include execution status information and can also include data.
    Data transformation and delivery management.
    Management of interaction with data resources, Connection to data resources etc. Business
        Class (BC) Layer
    Responsible for initiating the call to DAO Layer with DTO variables passed as parameter. Its
        function is just to receive a call from higher layer and pass that call to lower layer.

     Session Layer
`       Responsible for maintaining the session of the user. Each time the user passes or inputs any
request, call is made to this layer, which in turn passes the control to lower layers. In case if the user
request consists of multiple data access, then the user request is divided into separate calls to lower
layers for data access. In case any error occurs at any lower layer, then the entire transaction is rollback
to maintain consistency of database. Otherwise, the transaction is committed to make all the changes
permanent in the database.



   Application (Graphical User Interface) Layer:

        This Layer also known as Presentation Layer. This layer resides between the user and the
software system. Its job is to capture external event requests and to perform some degree of editing of
incoming data. It also is changed with presenting the event responses to the outside world (e.g. the
screens and reports). The software functionality, which will be provided to the users through the
interface, is described in the application layer. It provides the user interface developed using Java
Swings.

The above section completely describes the Architecture that is used in implementing Transaction in
the CIPA Application. One thing has to keep in mind while using the above Structure/Framework in the
Application. Below is an important Note:

„While passing the request, only the Higher Layer can call their Lower Layer, not in reverse order &
While providing services in the form of Requested Data/Request Completion Indication, only the
Lower Layers can call the Higher Layers, not in reverse order.

   Property files:
       Property files are basically files that contains key-value pair,and having .properties extension.
Here ,In our module we have used several property files to populate labels,combo boxes like direction
combo box etc at run time.

3.4 Database Design:

       Databases :
              CIPA (Common Integrated Police Application ) is a database for automating the
work flow at the police stations. The software is designed for Registration of various Cases, including
Unclaimed Properties/Dead Bodies reported at the police stations, their Investigation, including
coordination of lost and the recovered properties, Disposal/Charge Sheeting by Police, and Disposal of
Case by the court etc.

Tables for Police Station Management Module:

       Data Tables

1.     Table "public.t702_sumwarregister"

       Column                  Type         Modifiers
location                character(7)        not null
sw_type                 character(1)        not null
sw_srno                 integer             not null
bailable                boolean
date_receipt            date
place_receipt           character varying
court_type              character(3)
court_name              character varying
court_fileno            character varying
date_issue              date
date_presence           date
reg_location            character(7)
reg_type                character(1)
reg_type_srno           integer
reg_date                date
person_type             character(1)
person_srno             integer
freezed              boolean
regn_srno            integer

Indexes:
       KEY                                         VALUE
Primary Key       “t702_sumwarregister_pkey" PRIMARY KEY, btree ("location", sw_type,
                  sw_srno)
Foreign Key       "t702_sumwarregister_person_srno" FOREIGN KEY ("location", person_srno)
                  REFERENCES t102_person("location", person_srno)
Foreign Key       "t702_sumwarregister_regn_srno" FOREIGN KEY ("location", regn_srno)
                  REFERENCES t1_registration("location", regn_srno)




   2. Table "public.t702b_sumwarregister"

      Column               Type        Modifiers
location             character(7)      not null
sw_type              character(1)      not null
sw_srno                integer             not null
hand_date              date                not null
hand_to                character(8)
exec_date              date
exec_type              integer
exec_no_reason         character varying
exec_no_action         character varying
submit_date            date
return_date            date
return_rcno            integer
return_place           character varying
return_remark          character varying

Indexes:
      KEY                                             VALUE
Primary Key         "t702b_sumwarregister_pkey" PRIMARY KEY, btree ("location", sw_type,
                  sw_srno, hand_date)




Look-up Tables

   3. Table "public.t1_registration"

              Column             Type                      Modifiers
location                         character(7)              not null
regn_srno                        integer                   not null
 reg_date                       date
 reg_type                       character(1)                    not null
 reg_type_srno                  integer                         not null
mode_of_info                    character(50)
 receive_ps_dt                  character(50)
 receive_ps_tm                  timestamp without time zone
gd_entry_no                     character(4)
gd_entry_dt                     date
gd_entry_tm                     timestamp without time zone
duty_officer                    character(8)
investigating_officer           character(8)
desc_facts                      character varying
 freezed                        boolean
reg_status                      character(3)
read_permission                 boolean

Indexes:
      KEY                                               VALUE
Primary Key        "t1_registration_pkey" PRIMARY KEY, btree ("location", regn_srno)




4. Table "public.t102_person"


              Column            Type                Modifiers
location                        character(7)        not null
person_srno                     integer             not null
regn_srno                        integer              not null
person_type                      character(1)         not null
person_type_srno                 integer
crim_srno                        integer
sex                              character(1)         not null
year_birth                       integer
year_birth1                      integer
deleted                          boolean

Indexes:
        KEY                                                VALUE
Primary Key           "t102_person_pkey" PRIMARY KEY, btree ("location", person_srno)
Foreign Key           "t102_regn_srno" FOREIGN KEY ("location", regn_srno) REFERENCES
                     t1_registration("location", regn_srno)




5.    Table "public.t1021_personal"


          Column             Type          Modifiers
location               character(7)        not null
person_srno            integer             not null
name                   character varying not null
alias                  character varying
parentage              character(1)
parent                 character varying
marital                character(1)
nationality            character(3)        not null
passport_no            character(7)
passport_issue_dt      date
passport_issue_place   character varying
religion               character(3)
category               character(1)
caste_tribe            character(3)
living_status          character(3)
edu_qualif             character(3)
occupation             character(3)
income_group           character(3)
address                character varying
telephone              character varying
juris_dist             character(3)
juris_ps               character(2)
add_verified_by        character(8)
national_id            character(20)
identity_code          character(20)
photograph             bytea
fingerprint            bytea
caste                  character varying
address_perm           character varying
juris_beat             character(2)
add_juris_dist         character(3)
add_juris_ps           character(2)
add_juris_beat         character(2)

Indexes:
         KEY                                            VALUE
Primary Key        "t1021_personal_pkey" PRIMARY KEY, btree ("location", person_srno)
Foreign Key         "t1021_person_srno" FOREIGN KEY ("location", person_srno) REFERENCES
                   t102_person("location", person_srno)


6. Table "public.t015_psstaffcurr"

         Column                Type         Modifiers
location               character(7)        not null
pis_code               character(8)        not null
pis_staffname          character varying
pis_designation        character(4)
date_join              date
place_from             character varying
date_relieve           date
place_to               character varying
photograph             bytea
pis_role               character(5)
belt_no                character(10)
pis_id                 integer
pis_passwd             character varying
pis_rank               character (2)

Indexes:
           KEY                                           VALUE
Primary Key            "t015_psstaffcurr_pkey" PRIMARY KEY, btree ("location", pis_code)




Table "public.t020_courts"

     Column              Type          Modifiers
location            character(7)        not null
court_code          character(3)        not null
judge_name          character varying
court_address       character varying
date_from           date                not null
date_to             date

Indexes:
      KEY                                             VALUE
Primary Key          "t020_courts_pkey" PRIMARY KEY, btree ("location", court_code, date_from)




8. Table "public.t011_state"

  Column              Type         Modifiers
state_code      character(2)       not null
state_name      character varying not null
short_name      character(2)       not null

Indexes:
     KEY                                             VALUE
Primary Key      "t011_state_pkey" PRIMARY KEY, btree (state_code)




9. Table "public.t012_district"

   Column              Type        Modifiers
state_code      character(2)       not null
district_code character(3)         not null
district_name character varying not null

Indexes:
           KEY                                           VALUE
Primary Key              "t012_district_pkey" PRIMARY KEY, btree (state_code, district_code)



 10. Table "public.t013_policestation"

              Column                              Type                        Modifiers
district_code                      character(3)                    not null
ps_code                            character(2)                    not null
ps_name                            character varying               not null

Indexes:
           KEY                                           VALUE
Primary Key               "t013_policestation_pkey" PRIMARY KEY, btree (district_code, ps_code)




Besides above described tables,following tables also exist:

            List of relations
                  Type   Name    Owner
t009_scripts             table   cipa
t010_location            table   cipa
t014_policestationbeat   table   cipa
t015_psstaffold          table   cipa
t016_dutyplace           table   cipa
t031_majminloc           table   cipa
t098_dfreezed            table   cipa
t099_generaldiary        table   cipa
t101_actsection          table   cipa
t10221_physical          table   cipa
t10222_physical          table   cipa
t1031_automobile         table   cipa
t1032_cultural           table   cipa
t1033_numbered           table   cipa
t1034a_currency          table   cipa
t1034b_currency          table   cipa
t1035_narcotics          table   cipa
t103_properties          table   cipa
t1b_scandoc              table   cipa
t1s_regsummary           table   cipa
t2011_accused            table   cipa
t2012_properties         table   cipa
t2013_victim             table   cipa
t201_fir                 table   cipa
t202_missing             table   cipa
t204_mlc                 table   cipa
t205_unnatural           table   cipa
t206_deserter            table   cipa
t207_others              table   cipa
t3                       table   cipa
t3001_casediary          table   cipa
t301_crime             table   cipa
t301b_crime            table   cipa
t3031_fingprint        table   cipa
t3032_infosheet        table   cipa
t3033_bail             table   cipa
t3034_remandcustody    table   cipa
t304_arrest            table   cipa
t304a_seizure          table   cipa
t304b_seizure          table   cipa
t305_witness           table   cipa
t307_matchudump        table   cipa
t310_alteration        table   cipa
t311_transfer          table   cipa
t312_finalreport       table   cipa
t312b_fraccused        table   cipa
t312c_fractsec         table   cipa
t3_caseprogress        table   cipa
t402a_hearings         table   cipa
t402b_hearings         table   cipa
t403_sumwar            table   cipa
t405_procoffn          table   cipa
t406a_courtdisposal    table   cipa
t406b_courtdisposal    table   cipa
t406c_courtdisposal    table   cipa
t5011_criaddress       table   cipa
t5012_criknowns        table   cipa
t5013_cristatus        table   cipa
t5013b_cristatus       table   cipa
t5014a_modusoperandi   table   cipa
t5014b_criintero       table   cipa
t5015_hideouts         table   cipa
t501a_criminal         table   cipa
t501b_criscan             table   cipa
t5021_general             table   cipa
t5022_affiliation         table   cipa
t5023_operationarea       table   cipa
t5024_notices             table   cipa
t5025_political           table   cipa
t5026_employment          table   cipa
t5027_bank                table   cipa
t5031_operationarea       table   cipa
t5032_support             table   cipa
t5033_holdings            table   cipa
t5034_transport           table   cipa
t5035_training            table   cipa
t5036_hideouts            table   cipa
t5037_frontalorg          table   cipa
t503_gang                 table   cipa
t504_village              table   cipa
t504_village _arms        table   cipa
t504_village _arms_h      table   cipa
t504_village _h           table   cipa
t504_village_festival     table   cipa
t504_village_festival_h   table   cipa
t504_village_person       table   cipa
t504_village_person _h    table   cipa
t601_pcrcalls             table   cipa
t701_dutyroster           table   cipa
x01_synccentral           table   cipa
3.4 Screen Shots:

     Run the main application. A Welcome Screen gets opened which includes Login in the form of
      P.I.S. Code and Password




         On logging into the application, main menu screen gets opened. That‟s includes Three
       modules namely-


          Software Administration

          Change Password

          Police Station Management




   On clicking Police Station Management, it displays its submodules as follows:
     Summon
       Warrant




   Police Station Management Module ,basically contains entire information of a summon &
    warrant issued against the case. Information about a new summon/warrant can be maintained as
follows:
   On clicking NEW a new Summon Register Screen pops up .A new form is opened and
    information about a summon can be entered in the respective & mandatory fields and saved.
    Once it is done then Progress button is activated :
4 CODING & REPORTS

              As I have completed my training on the project, that is COMMON INTEGRATED
POLICE APPLICATION (CIPA Software), in NATIONAL INFORMATICS CENTER., working as a
Software Trainee, so I cannot give the code for the project as per company policies.


       REPORT generation is also a part of this module, but due to time constraint this feature is not
introduced yet, but supposed to be implemented in near future.
       System Testing And Implementation:
       5.1 TESTING

               Testing of software deals with checking of the software that whether it is working as it
should be according to the system design. The software should not be performing any functions less
than the required and also not follow something extra or perform unwanted operations. Thus a software
testing deals with the process of verifying that the system works according to the requirement
specifications and the system design.

                 The testing may be done in many ways. On the basis of the knowledge of the software
tester the testing may be divided into two groups. They are:

       BLACK-BOX TESTING

       In Black-Box Testing the tester only knows what the software is supposed to do-he can‟t see
how it operates. If he types in a certain input, he gets a certain output. He doesn‟t know how or why it
happens, just that it does. Means run a test, give input and verify its output and if any bug or
unexpected result you have faced, and ask developer to review its related code.

       WHITE-BOX TESTING

      While in White-Box Testing the software tester has access to the program‟s code and can
examine it for clues to help him with his testing-he scan see inside the box. Thus we can say that in
white-box testing the tester has knowledge about the software that what and how the things are going
on inside the system. Thus he can debug that the certain error is coming from which part of the
software.


       PROCEDURES FOLLOWED IN PROJECT
               I had used the method of Black-Box as well as the White-Box Testing for the purpose of
checking for the exceptions produced and the general errors in coding which were not detectable at
programming time. The test cases are based to test the behavior in a specific condition. They are
formed generally to test each and every part of the code i.e. each statement is executed at least once
when testing the software.

       For Black Box testing, we have made a number of automated test cases, considering all the run
time requirements. These test cases are made in such a way that about every part of code would be
executed by them, at least for once. So the tester can run these test cases without continuously giving
his time to these. As these are capable to run themselves without requiring interaction from tester. And
in between, all the errors faced during test cases execution, are logged into a log file. This is forwarded
to concerned software engineer by the tester. So in this phase, there is a little to do for tester, just he is
responsible only for running this test case unit and for sending them to concerned authority, after their
completion. And so this unit helps in saving the testing time.

        For white box testing, we have followed unit-testing procedure. We, run the component and test
the module for all its strengths and weak points. We check the module for all negative and positive
points, being familiar with its internal working. And on the way, if faced any bug or error, we rectified
it in coding immediately or after proper analysis, depends on severity and stature of it.

         Besides it, we have also followed the static testing technique, to make our code more efficient.
For it, the senior engineers, generally working in same team, are appointed for reviewing of any
particular part of component. This helps us in optimizing our code quality and in rectifies the hidden
bug in our architecture, which is traced out by reviewing of code, due to experience of concerned
appointed engineer.


       5.2 Implementation:

        CIPA Software is likely to run at 20,000 locations and will be mostly used by IT semi-literate
policeman, therefore, the implementation phase will require a significant amount of Training input as
well. More that 1,00,000 personnel are expected to be imparted training in this phase. NCRB has
carried out large number of training programs including Training and Trainers and those officers should
be involved in the piloting and training programs in the states.
Services of outside agencies may be necessary by the respective states for imparting necessary training,
and also for hand holding for some time while starting the actual implementation, especially at the
Police station level. The respective NIC state units may do technical coordination for the
implementation. The Trainers training will be imparted by the Development team, to the identified
personnel from the hired agencies, along with the NIC state unit personnel coordinating from the
implementation.
        However, day to day operation of the software i.e. data entry, reports generations, backups &
restorations etc. will be done by the users only, which can be categorized in three viz. Administrators,
Operations and Officers. Every state has a communication cadre who are trained and well versed in
hardware maintenance and can with a little training on the Application can be Application
administrators.

        The Pilot implementation in selected States/Districts/Police stations will be supported by
NCRB, by providing necessary funding from MPF for hardware/software, training etc. However,
subsequent roll out and integration of the application will be the responsibility of the respective states.
Here, integration shall involve migration of data from existing automated systems, if any; use of
existing hardware, if available; and network requirements at the Police station/District/state levels.

       Various activities performed during Pilot Implementation are as follows:

      Identification of the Agency to be hired by the State govt. for implementation.

      Constitution of the Implementation Team for the State, consisting of personnel identified from
       the concerned NIC State Unit, the DIO of the implementing district, state Police Dept. ,SCRB
       and from the hired agency.

      Training of the Implementation Team by the Development Team on Software installation,
       administrations and operation.

      End user training ( in multiple batches) on software installation, administration and operation by
       the Implementation Team.

      Hardware procurement, installation and operationalization at all the Police stations, the district
       hdqrs., and the state hdqrs, along with the establishing the network connectivity between Police
       stations to districts to state hdqrs.( These activity are initiated as soon as the first level Training
       programs are started).

      Application software installation & operationalization at all the Police stations, the District
       hdqrs. And the state hdqrs by the implementation team.

      Hand holding support on call basis to Police stations by the Agency personnel( based on district
       hdqrs), and monitoring of database accumulation.




       6. Conclusion And Further Scope:
        The project is implemented successfully in 20% of the states & 100% Union Territories, in
India in the respective languages.
        The future plans for the proposed project is its deployment in web version,so that the user can
make query on line and can collect the required information conveniently.

       CONCLUDING REMARKS

       CIPA (Common Integrated Police Application) has been implemented at various Police
Stations across states like Delhi, Kerala, Rajasthan, Punjab, and many other states. Currently, work on
maintenance of CIPA application that includes adding additional functionalities, removing bugs is
going on.
        This also includes implementing the project for all states in their regional languages. For
example, in Delhi, the application is running in English while in Rajasthan, the same application is
running in Hindi.


       FUTURE SCOPE OF THE PROJECT
          Till now, all the work related to Client side i.e. Phase-I of Common Integrated Police
           Application (CIPA) is almost over. The Phase-II i.e. Server side functioning of CIPA
           Project is insight and initial work has already started to launch the Phase-II.

              The Phase-II of CIPA Project includes Java Message Service (JMS), Servlet, Java Server
               Pages (JSP), and Remote Method Invocation (RMI).




       7. Appendix

       Abbreviations & Definitions


  ACP                           Assistant Commissioner of Police
 ADGP             Additional Director General of Police
 ASI              Assistant Sub-Inspector
 CIPA             Common Integrated Police Application
 CrPC             Criminal Procedure Code
 CRO              Crime Records Office
 CPI              Circle Police Inspector
 CP               Commissioner of Police
 DCRB             District Crime Records Bureau
 DSP              Deputy Superintendent of Police
 DCP              Deputy Commissioner of Police
 DIGP             Deputy Inspector General of Police
 DGP              Director General of Police
 DO               Duty Officer
 FIR              First Information Report
 HC               Head Constable
 IPC              Indian Penal Code
 IO               Investigating Officer
 IGP              Inspector General of Police
 KD               Known Depredator
 MLC              Medico Legal Case
 MO               Modus Operandi/Medical Officer
 NCRB             National Crime Records Bureau
 PCR              Police Control Room
 PS               Police Station
 PSI              Police Sub Inspector
 SCRB             State Crime Records Bureau
 SHO              Station House Officer
 SP               Superintendent of Police
 UD               Unnatural Death
 UIDB             Un-Identified Dead Body
 R.C.No           Return from Court Number

Term Definition
Accused                A person charged with a criminal offense, or the state of being so
                       charged
Witness                One who can give a firsthand account of something seen, heard, or
                       experienced
Bail                   To secure the release of by providing security. Security, usually a
                       sum of money, exchanged for the release of an arrested person as a
                       guarantee of that person's appearance for trial.
Cognizable             Offense for which a police officer may in accordance with the first
                       schedule or under any law in force may arrest without warrant.
Non                    Offense for which a police officer has no authority to arrest without
Cognizable             warrant.
Process.               Execution of Summons and Warrants.
Summons                A written order, issued to a person to appear before the court issuing
                       it, are Summons
Warrants               Written Authorization given by court to arrest a person and produce
                       Before the court, are Warrants.
Appeal                 Refer to a higher Court.
Alias                  An assumed name

       8. Bibliography:

      Software Requirement Specification of CIPA.
      Design Document of CIPA.
      www.nic.in
      www.google.com
      Other sites of Java Tutorials.
      System Analysis and Design by Elias M. Awad.
      The Complete Reference Java 2 by TMH.

								
To top