CRIME RECORDS MANAGEMENT SYSTEM PROJECT REPORT
PROJECT REPORT
PROJECT SOURCE CODE
ABSTRACT
The proposed system applies to all Police stations across the
country and specifically looks into the subject of Crime Records Management. It
is well understood that Crime Prevention, Detection and Conviction of criminals
depend on a highly responsive backbone of Information Management. The
efficiency of the police function and the effectiveness with which it tackles
crime depend on what quality of information it can derive from its existing
records and how fast it can have access to it.
It is proposed to centralize Information Management in Crime for
the purposes of fast and efficient sharing of critical information across all
Police Stations across the territory. Initially, the system will be implemented
across Cities and Towns and later on, be interlinked so that a Police detective
can access information across all records in the state thus helping speedy and
successful completion to cases. The System would also be used to generate
information for pro-active and preventive measures for fighting crime.
The
project has been planned to be having the view of distributed architecture,
with centralized storage of the database. The application for the storage of
the data has been planned. Using the constructs of SQL server and all the user
interfaces have been designed using the DOT Net technologies. The
standards of security and data protective mechanism have been given a big
choice for proper usage. The application takes care of different modules and
their associated reports, which are produced as per the applicable strategies
and standards that are put forwarded by the administrative staff.
CONTENTS
1.
Introduction
1.1 Introduction to Project
1.2 Organization Profile
2.
System
Analysis
2.1. Analysis
Model
2.2. Existing
System
2.3. Problem
Statement
2.4. Proposed
System
3.
Software
Requirement Specification
3.1. Product
Overview
3.2. Hardware
Requirements
3.3. Software
Requirements
3.4. Performance
Requirements
4.
System
Design
4.1. Introduction
4.2. Data
flow Diagrams
5.
Testing
6.
Technical
Notes
6.1. DOTNET
Framework
6.2. C# Introduction and Overview
7.
screens
8. Conclusion
9. Future Improvement
Introduction
1.1. Introduction to Project
Overview
The
entire project has been developed keeping in view of the distributed client
server computing technology, in mind. The specifications have been normalized
up to 3NF to eliminate all the anomalies that may arise due to the database
transaction that are executed by the general users and the organizational
administration. The user interfaces are browser specific to give distributed accessibility
for the overall system. At all proper levels high care was taken to check that
the system manages the data consistency with proper business rules or
validations. The authentication and authorization was crosschecked at all the
relevant stages. The user level accessibility has been restricted into two
zones namely. The administrative zone and the normal user zone.
Why new system?
Ø The
system at any point of time can provide the details of the police station and
the employees.
Ø The
system at any point of time can provide the details of victims and the
registered FIR’s
Ø The
system at any point of time can provide the details of evidence and their
sequence
Ø The
system at any point of time can provide the details of existing charge sheets
and their statuses.
2.1. Analysis Model
The
model that is basically being followed is the WATER FALL MODEL, which states
that the phases are organized in a linear order. First of all the feasibility
study is done. Once that part is over the requirement analysis and project
planning begins. If system exists one and modification and addition of new
module is needed, analysis of present system can be used as basic model.
The
design starts after the requirement analysis is complete and the coding begins
after the design is complete. Once the programming is completed, the testing is
done. In this model the sequence of activities performed in a software
development project are: -
- Requirement Analysis
- Project Planning
- System design
- Detail design
- Coding
- Unit testing
- System integration & testing
Here
the linear ordering of these activities is critical. End of the phase and the
output of one phase is the input of other phase. The output of each phase is to
be consistent with the overall requirement of the system. Some of the qualities
of spiral model are also incorporated like after the people concerned with the
project review completion of each of the phase the work done.
WATER
FALL MODEL was being chosen because all requirements were known beforehand and
the objective of our software development is the computerization/automation of
an already existing manual working system.
2.2 Existing System:
The
existing system contains the about all the police stations that are registered
as per the jurisdiction of the system. It also gets integrated with the
employees who are working in these stations along with their designation.
2.3. Problem Statement:
The
existing system doesn’t have system security. That means, the user can login in
to system any where in the world. But the data in this system is not for
public. To avoid this problem, the proposed system is developed as MAC enabled
website. That means, the user can access the website in that system only, so
that we can avoid the information leakage problem.
2.4. Proposed
System
The
system after careful analysis has been identified to be presented with the
following modules:
Ø Police stations registration module:
This module maintains the information about all the police stations that are
registered as per the jurisdiction of the system. It also gets integrated with
the employees who are working in these stations along with their designation.
Ø Victims FIR registration module:
This module maintains the information related to the first investigation report
of the crime sequences that have taken place. The Fir registers all that a data
that is necessary for the investigation to take place in proper length. It
identifies the crime category and the crime nature.
Ø Investigating evidence registration module:
This module makes a collection of information related to all the evidences that
become categorically important under the normal sequence of the investigation,
this module dynamically concentrates upon the changes that take place while the
system of investigation is under process.
3. Software Requirement Specification
3.1.
Overview
Purpose:
The main purpose for preparing this document is to give a general insight into
the analysis and requirements of the existing system or situation and for
determining the operating characteristics of the system.
Scope
of the Development Project:
Database
Tier: The
concentration is applied by adopting the Oracle 9i Enterprise
User
Tier: The use interface is developed is a browses specific
environment to have distributed architecture. The components are designed using
HTML standards and Java server pages power the dynamic of the page design.
Developer
Responsibilities Overview:
The developer is responsible for:
- Developing
the system, which meets the SRS and solving all the requirements of the
system?
- Demonstrating
the system and installing the system at client's location after the
acceptance testing is successful.
- Submitting
the required user manual describing the system interfaces to work on it
and also the documents of the system.
- Conducting
any user training that might be needed for using the system.
- Maintaining
the system for a period of one year after installation.
3.2. Hardware Requirements:
- PIV 2.8 GHz Processor and Above
- RAM 512MB and Above
- HDD 20 GB Hard Disk Space and Above
3.3. Software Requirements:
- WINDOWS OS (XP / 2000 / 200 Server /
2003 Server)
- Visual Studio .Net 2005 Enterprise
Edition
- Internet Information Server 5.0 (IIS)
3.4. Performance Requirements:
Performance is measured in terms of the output
provided by the application.
Requirement
specification plays an important part in the analysis of a system. Only when
the requirement specifications are properly given, it is possible to design a
system, which will fit into required environment. It rests largely in the part of the users of
the existing system to give the requirement specifications because they are the
people who finally use the system. This
is because the requirements have to be known during the initial stages so that
the system can be designed according to those requirements. It is very difficult to change the system
once it has been designed and on the other hand designing a system, which does
not cater to the requirements of the user, is of no use.
The
requirement specification for any system can be broadly stated as given below:
·
The system should be able to interface with the existing system
·
The system should be accurate
·
The system should be better than the existing system
The
existing system is completely dependent on the user to perform all the duties.
4. SYSTEM DESIGN
4. System design
4.1 Introduction
4.1 Introduction
Software
design sits at the technical kernel of the software engineering process and is
applied regardless of the development paradigm and area of application. Design
is the first step in the development phase for any engineered product or
system. The designer’s goal is to produce a model or representation of an
entity that will later be built. Beginning, once system requirement have been
specified and analyzed, system design is the first of the three technical
activities -design, code and test that is required to build and verify software.
The
importance can be stated with a single word “Quality”. Design is the place
where quality is fostered in software development. Design provides us with
representations of software that can assess for quality. Design is the only way
that we can accurately translate a customer’s view into a finished software
product or system. Software design serves as a foundation for all the software
engineering steps that follow. Without a strong design we risk building an
unstable system – one that will be difficult to test, one whose quality cannot
be assessed until the last stage.
During
design, progressive refinement of data structure, program structure, and
procedural details are developed reviewed and documented. System design can be
viewed from either technical or project management perspective. From the
technical point of view, design is comprised of four activities – architectural
design, data structure design, interface design and procedural design.
4.2 Data Flow Diagrams
A
data flow diagram is graphical tool used to describe and analyze movement of
data through a system. These are the
central tool and the basis from which the other components are developed. The transformation of data from input to
output, through processed, may be described logically and independently of
physical components associated with the system.
These are known as the logical data flow diagrams. The physical data flow diagrams show the
actual implements and movement of data between people, departments and
workstations. A full description of a
system actually consists of a set of data flow diagrams. Using two familiar notations Yourdon, Gane
and Sarson notation develops the data flow diagrams. Each component in a DFD is
labeled with a descriptive name. Process
is further identified with a number that will be used for identification
purpose. The development of DFD’S is
done in several levels. Each process in
lower level diagrams can be broken down into a more detailed DFD in the next
level. The lop-level diagram is often
called context diagram. It consists a single process bit, which plays vital
role in studying the current system. The
process in the context level diagram is exploded into other process at the
first level DFD.
The
idea behind the explosion of a process into more process is that understanding
at one level of detail is exploded into greater detail at the next level. This is done until further explosion is
necessary and an adequate amount of detail is described for analyst to
understand the process.
Larry Constantine first developed the
DFD as a way of expressing system requirements in a graphical from, this lead
to the modular design.
A DFD is also known as a “bubble
Chart” has the purpose of clarifying system requirements and identifying major
transformations that will become programs in system design. So it is the starting point of the design to
the lowest level of detail. A DFD
consists of a series of bubbles joined by data flows in the system.
4.2.1 Dfd Symbols:
In
the DFD, there are four symbols
1.
A square defines a
source(originator) or destination of system data
2.
An arrow identifies
data flow. It is the pipeline through
which the information flows
3.
A circle or a
bubble represents a process that transforms incoming data flow into outgoing
data flows.
4.
An open rectangle
is a data store, data at rest or a temporary repository of data
4.2.2 Constructing
a DFD:
Several rules of thumb are
used in drawing DFD’S:
Process should be named and numbered for an
easy reference. Each name should be
representative of the process.
The direction of flow is from top to bottom
and from left to right. Data
traditionally flow from source to the destination although they may flow back
to the source. One way to indicate this
is to draw long flow line back to a source.
An alternative way is to repeat the source symbol as a destination. Since it is used more than once in the DFD it
is marked with a short diagonal.
When a process is exploded into lower level
details, they are numbered.
The names of data stores and destinations
are written in capital letters. Process and dataflow names have the first
letter of each work capitalized. A DFD typically shows the minimum contents of
data store. Each data store should
contain all the data elements that flow in and out. Questionnaires should
contain all the data elements that flow in and out. Missing interfaces redundancies and like is
then accounted for often through interviews.
4.2.3 Silent
Feature of DFD’s
1.
The DFD shows flow
of data, not of control loops and decision are controlled considerations do not
appear on a DFD.
2.
The DFD does not
indicate the time factor involved in any process whether the dataflow take
place daily, weekly, monthly or yearly.
3.
The sequence of
events is not brought out on the DFD.
4.2.4 Data Flow:
1)
A Data Flow has
only one direction of flow between symbols.
It may flow in both directions between a process and a data store to
show a read before an update. The later
is usually indicated however by two separate arrows since these happen at
different type.
2)
A join in DFD means
that exactly the same data comes from any of two or more different processes
data store or sink to a common location.
3)
A data flow cannot
go directly back to the same process it leads.
There must be at least one other process that handles the data flow
produce some other data flow returns the original data into the beginning
process.
4)
A Data flow to a
data store means update (delete or change).
5)
A data Flow from a
data store means retrieve or use. A data flow has a noun phrase label more than
one data flow noun phrase can appear on a single arrow as long as all of the
flows on the same arrow move together as one package.
ER-Diagrams
·
The entity
Relationship Diagram (ERD) depicts the relationship between the data objects.
The ERD is the notation that is used to conduct the date modeling activity the
attributes of each data object noted is the ERD can be described resign a data
object descriptions.
·
The set of primary
components that are identified by the ERD are
u
Data object u Relationships
u
Attributes u Various types of
indicators.
·
The primary purpose
of the ERD is to represent data objects and their relationships.
Unified
Modeling Language Diagrams
·
The unified
modeling language allows the software engineer to express an analysis model
using the modeling notation that is governed by a set of syntactic semantic and
pragmatic rules.
·
A UML system is
represented using five different views that describe the system from distinctly
different perspective. Each view is defined by a set of diagram, which is as
follows.
·
User Model View
i. This
view represents the system from the users perspective.
ii. The
analysis representation describes a usage scenario from the end-users
perspective.
Structural
model view
u In this model the data and
functionality are arrived from inside the system.
u This
model view models the static structures
.
Behavioral
Model View
u It represents the dynamic of behavioral as
parts of the system, depicting the interactions of collection between various
structural elements described in the user model and structural model view.
Implementation
Model View
u In
this the structural and behavioral as parts of the system are represented as
they are to be built.
Environmental
Model View
In
this the structural and behavioral aspects of the environment in which the
system is to be implemented are represented.
UML
is specifically constructed through two different domains they are
u
UML Analysis
modeling, which focuses on the user model and structural model views of the
system.
u
UML design
modeling, which focuses on the behavioral modeling, implementation modeling and
environmental model views.
Use
Case Diagrams
The actors who have been
identified in the system are as follows:
1.
Investigating
officer
2.
Administrator
3.
Writer
Investigating
officer: He is the actor who can practically work upon the
existing data in the police station only for view purpose.
Administrator:
He is the actor who has the full-length potentiality and privilege to carry out
transactions upon the system. He is authorized to maintain consistency within
the information.
Writer:
He is the actor who can enter all the details of the crime or evidence. Once
entered cannot be edited. Only the administrator can edit or delete the record
from the database.
Use case Description:
|
Use
case name
|
Login Information
|
|
Participating
actors
|
Administrator,
Investigator, Writer
|
|
Flow
of events
|
Provides username and
password
|
|
Entry
Condition
|
Users must know the
username and password
|
|
Exit
condition
|
User successfully logged
into the system
|
|
Quality
Requirements
|
Should provide proper
error messages while login into the system.
|
|
Use
case name
|
Register Victims
|
|
Participating
actors
|
Administrator, Writer
|
|
Flow
of events
|
User will enter the
Victims information
|
|
Entry
Condition
|
User should know the
details of the victim
|
|
Exit
condition
|
Victim details are
successfully inserted into the system.
|
|
Quality
Requirements
|
Display proper error
messages while insertion.
|
|
Use
case name
|
Register Victims FIR
|
|
Participating
actors
|
Administrator, Writer
|
|
Flow
of events
|
User will register the
FIR
|
|
Entry
Condition
|
User should know the
details of the FIR
|
|
Exit
condition
|
FIR details are
successfully inserted into the system.
|
|
Quality
Requirements
|
Display proper error
messages while insertion.
|
|
Use
case name
|
Register Crime charge
sheet
|
|
Participating
actors
|
Administrator, Writer
|
|
Flow
of events
|
User will register the
crime charge sheet
|
|
Entry
Condition
|
User should know the
details of charge sheet.
|
|
Exit
condition
|
Charge sheet details are
successfully inserted into the system.
|
|
Quality
Requirements
|
Display proper error
messages while insertion.
|
|
Use
case name
|
Register Investigation
Evidence
|
|
Participating
actors
|
Administrator, Writer
|
|
Flow
of events
|
User will register the
investigation evidence
|
|
Entry
Condition
|
User should know the
details of evidence.
|
|
Exit
condition
|
Evidence details are
successfully inserted into the system.
|
|
Quality
Requirements
|
Display proper error
messages while insertion.
|
|
Use
case name
|
Register Police Station
|
|
Participating
actors
|
Administrator
|
|
Flow
of events
|
User will register the
police station.
|
|
Entry
Condition
|
User should know the
details of police station.
|
|
Exit
condition
|
Police station details
are successfully inserted into the system.
|
|
Quality
Requirements
|
Display proper error
messages while insertion.
|
|
Use
case name
|
View all crime details
|
|
Participating
actors
|
Investigator
|
|
Flow
of events
|
User can view all the
crime details.
|
|
Entry
Condition
|
Display the details of
crime and evidences.
|
|
Exit
condition
|
Evidence and crime
details are successfully displayed.
|
|
Quality
Requirements
|
N/A
|
6.
Testing
1. The process of executing a system with the intent of finding an error.
2. Testing is defined as the process in which defects are identified, isolated, subjected for rectification and ensured that product is defect free in order to produce the quality product and hence customer satisfaction.
3. Quality is defined as justification of the requirements
4. Defect is nothing but deviation from the requirements
5. Defect is nothing but bug.
6. Testing --- The presence of bugs
7. Testing can demonstrate the presence of bugs, but not their absence
8. Debugging and Testing is not the same thing!
9. Testing is a systematic attempt to break a program or the AUT
Testing Methodologies:
• Black box Testing: is the testing process in which tester can perform testing on an application without having any internal structural knowledge of application.
Usually Test Engineers are involved in the black box testing.
• White box Testing: is the testing process in which tester can perform testing on an application with having internal structural knowledge.
Usually The Developers are involved in white box testing.
• Gray Box Testing: is the process in which the combination of black box and white box tonics are used.
6.1
STLC (Software Testing Life Cycle)
Test Planning:
- Test Plan is defined as a strategic
document which describes the procedure how to perform various testing on
the total application in the most efficient way.
- This document involves the scope of
testing,
- Objective of testing.
- Areas that need to be tested.
- Areas that should not be tested.
- Scheduling Resource Planning.
Types of Testing:
- Regression Testing: is one of the best
and important testing. Regression testing is the process in which the
functionality, which is already tested before, is once again tested
whenever some new change is added in order to check whether the existing
functionality remains same.
- Re-Testing: is the process in which
testing is performed on some functionality which is already tested before
to make sure that the defects are reproducible and to rule out the
environments issues if at all any defects are there.
- Static Testing: is the testing, which is
performed on an application when it is not been executed.ex: GUI, Document
Testing
- Dynamic Testing: is the testing which is
performed on an application when it is being executed.ex: Functional
testing.
- Alpha Testing: it is a type of user
acceptance testing, which is conducted on an application when it is just
before released to the customer.
- Beta-Testing: it is a type of UAT that is
conducted on an application when it is released to the customer, when
deployed in to the real time environment and being accessed by the real
time users.
- Installation Testing: it is the process
of testing in which the tester try to install or try to deploy the module
into the corresponding environment by following the guidelines produced in
the deployment document and check whether the installation is successful
or not.
Conclusion
Conclusions
/Project Summary
The Crime Records Managing System is a web-based application for
primarily providing training to the employees who provide customized solutions
to meet organizational needs.
This
application software has been computed successfully and was also tested
successfully by taking “test cases”. It is user friendly, and has required
options, which can be utilized by the user to perform the desired operations.
The software is developed using Java
as front end and Oracle as back end in Windows environment. The goals that are
achieved by the software are:
ü Instant
access.
ü Improved
productivity.
ü Optimum
utilization of resources.
ü Efficient
management of records.
ü Simplification
of the operations.
ü Less
processing time and getting required information.
ü User
friendly.
FUTURE
IMPROVEMENT
- This System being web-based and an
undertaking of Cyber Security Division, needs to be thoroughly tested to
find out any security gaps.
- A console for the data centre may be
made available to allow the personnel to monitor on the sites which were
cleared for hosting during a particular period.
- Moreover, it is just a beginning; further the system may be utilized in various other types of auditing operation viz. Network auditing or similar process/workflow based applications...
1 comment:
I think everyone should know such information like you have described on this post. Thank you for sharing this explanation.Your final conclusion was good.
Document Management Software India
Document Management Software Chennai
Document Management Software
Post a Comment