PROJECT REPORT

ON

ONLINE CASE MANAGEMENT SYSTEM

CONTENTS

Chapter

1
1.1
1.2
1.3
1.4

Chapter

2
2.1
2.2
2.3
2.4
2.5
2.6
2.7

Chapter

3
3.1
3.2
3.3
3.4

Chapter

4
4.1
4.2
4.3
4.4
4.5

Chapter

Introduction
Problem Definition
Purpose
Project Requirement
Tools and Platforms Hardware and Software Requirements

8
8
8
8

System Analysis
Identification of need
Feasibility study
Project planning
Project scheduling
Software Requirement Specification (SRS)
Software engineering paradigm
Data Models (DFD & ER)

10
11
13
14
17
26
28

System Design
Data integrity and constraints
Database design
User interface design
Test cases

31
36

Coding
Sample project coding
Comments and Description of Coding segments
Error handling
Parameters calling/passing
Validation checks

Testing

39
39
40

5.1
5.2
Chapter

Testing Techniques and Testing Strategies used

Debugging

46
48

System Security measures

6.1
6.2

Database/data security
Creation of User profiles and access rights

Chapter

Cost Estimation of the Project

Chapter

Reports

Chapter

Future scope and further enhancement of the Project

Chapter

10

Conclusion
Bibliography

49
50

Chapter 1

Introduction

Online Case Management System (OCMS) is a Online Portal for Advocates, very useful to
all the Advocates. It keeps information about an advocates clients, opponents, cases no., case
status, next hearing date etc. There are reports and transaction. It tracks hearings previous
date, next date and court name. To ensure a strong control over all the cases one requires a
reliable and viable System. This most effective and efficient Technique, which can track and
feed the required information online and let not miss any case in any court.

1.1

Problem Definition

The proceess related to a case like managing clients, managing cases, keeping case
documents etc. are generally paper based. It consume lots of time. Sometimes advocate may
lost case related documents or he can forget and miss his cases in court.
It is required to Design of a Computerized Automated Case Management System, make
it easy to use system by keeping all his information online and can retrieve form anywhere
when needed.

1.2

Purpose

Online Case Management System supports storing information about an advocates

clients, opponents, cases no., case status, next hearing date etc.

It also supports processes like fees from the clients, generates invoice, and send SMS
automatically to the clients.

It focuses on storing and processing (insertion, updation) by using web pages.

1.3

Project Requirements

Automate manual paper work done at the time of client registration, case entry, case
documents that has to be submitted at the time of hearing in court.

Eliminate paper work.

1.4 Tools and Platform

Back-End :

MySQL Database Server 5.6

Front-End:

PHP5

Other Technology:

HTML5, CSS, Javascript, JQuery, AJAX.

Hardware requirements:
Hardware
Processor
Memory (RAM)
Hard Disk Space
Monitor
Pointing device
CD-ROM drive

Minimum Requirements
Intel Pentium 4, Pentium Dual core, Core 2 duo and
higher.
512MB Minimum; 1024 MB Recommended or Higher.
3 GB for the database and the client software.
VGA or higher resolution. 800x600 or higher resolution
required for the MySQL Server graphical tools
Microsoft Mouse or compatible
Required for installation purposes only.

Software requirements:
Operating System: Windows 8/Windows 7/Windows vista/Windows xp/Linux/Unix.
Application software: Dream Weaver CS4, MS-Office Word and Notepad++.

Chapter 2

System Analysis
System analysis is a process of collecting factual data, understand the process involved,
identifying problems and recommending feasible suggestions for improving the system
functioning. This involves studying the business processes, gathering operational data,
understand the informational flow, finding out bottlenecks and evolving solutions for
overcoming the weaknesses of the system. Analysis also includes subdividing of complex
process involving the entire system, identification of data store and manual processes. The
major objectives of the system analysis are to find answers for each business process: what is
being done, why it is done and how it can be improved? It is more of a thinking process and
involves the creative skills of the system analyst. It attempts to give birth to a new efficient
system that satisfies the current needs of the user and has scope of the future growth within
the organizations constraints. The result of this process is a logical system design. System
analysis is an iterative process that continues until a preferred and acceptable system
emerges.
In business, system analysis and design refers to the process of examining a business
situation with the intent of improving it with a better procedures and methods. It is the
process of gathering and interpreting the facts, diagnosing problems and using the
information to recommend improvements to the system.
Since Online Case Management System is a web based system that is why it has to be
a user friendly and interactive one. When I started to develop Online Case Management
System, my first work was to understand the system. So I discussed the system with my
guide and tried to collect some meaningful, factual data about the system which helped me to
develop the system. Along with collecting data, I was trying to identify the problems and its
possible solution related to the system to be developed. I designed a logical model of the
system and broken the complex process of the system into some other processes.

2.1 Identification of Need

Working of the Present System:
The current manual system uses paperwork to keep records. All information about clients ,
case entry, documents are done manually in paper. Sometimes files are lost or cannot be
submitted to the court when needed.
Disadvantages of Present System:
1. Consume much time and hard to operate and maintain.
2. Since, all the work is done in papers so it is very hard to locate a particular record
when it is required.
3. The physical files occupy too much space to store and can have the chance of missing.

Proposed System:
1. It is automated computerized web based software system.
2. It uses latest technologies like PHP and MY SQL.
3. The system provides better data management facilities.
4. The system provides security measures to access to information lowering data security
threats.

5. Attractive User Interface

6. Searching is easy and fast
7. Reduction of data entry and processing errors.
8. Reduce paper use.

2.2 Fessibility Study

A feasibility study is undertaken to determine the possibility or probability of either
improving the existing system or developing a completely new system. It helps to obtain an
overview of the problem and to get rough assessment of whether feasible solution exists. This
is essential to avoid committing large resources to a project and then repent on it later.
After studying the proposed system thoroughly and the initial investigation is done, we
are in a state to determine exactly how the candidate system will be looked like by defining
all the expected performances. Thus, a feasibility study comes into play in order to select the
best system which will fulfill well the performance requirements. The feasibility study
basically entails

Identification

Description

Evaluation of the candidate system

Selection of the best system to fulfill the requirements.

If we carry out the feasibility study thoroughly, it will become convenient for us, on the
part of the developer to design and implement the system with least effort.
In fact, many feasibility studies are disillusioned by both the developers as well as the
users. When for the first time ,the feasibility document is being prepared, the developer
reaches a position that he or she can almost depict the true picture of the system. Basically,
the feasibility study aims to overlook the confusion occurred during the system development.
It tends to answer three obvious main questions:
a) Is there any better way to accomplish which will more effectively fulfill the users
requirement ?
b) What will be the additional cost that will be incurred /or saving in pursuing that
particular alternative/those alternatives ?

c) Which one will be recommended ?

A better system need not necessarily the biggest one or will be most visible in the
business environment. It actually aims to fulfill well the users requirements and
expectations.
The feasibility study is needed to
1) Answer the question whether a new system is to be installed or not?
2) Determine the potential of the existing system.
3) Improve the existing system.
4) Know what should be embedded in the new system.
5) Define the problems and objective involved in a project.
6) Avoid costly repairs at a later stage when the system is implemented.
7) Avoid crash implementation of a new system.
8) Avoid the Hardware Approach i.e. getting a computer first and then deciding how to
use it.
There are three aspects in feasibility study portion of the preliminary investigation.
1. Technical feasibility.
2. Economic feasibility and
3. Operational feasibility of the project.
Technical Feasibility

Technical Feasibility determines whether the work for the project be done with the
present equipment, current procedures, existing softwares technology and available
personnel?

If new technology is needed then what alternatives will be needed in the present
structure and work ethos?

This will require a close examination of the present system.

The technical feasibility should ask questions related to:

a) Adequacy of available technology
b) Adequacy of hardware.
c) Available of computer.
d) Operating time and support facilities, etc.

Technical feasibility determines whether the technology needed for the proposed system
is available and how it can be integrated within the Online Case Management System and
Technical evaluation must also assess whether the existing system can be upgraded to use the
new technology and whether the Online Case Management System has the expertise to use
it.
Economic feasibility
Economic feasibility looks at the financial aspects of the project. Economic feasibility
concerns with the returns from the investments in a project. It determines whether it is
worthwhile to invest the money in the proposed system. It is not worthwhile spending a lot of
money on a project for no returns.To carry out an economic feasibility for a system, it is
necessary to place actual money value against any purchases or activities needed to
implement the project.
The Online Case Management System plans to acquire the necessary hardware and
software requires for the system and there is no hindrance whether economical or otherwise
towards its purchase. A brief description of the hardware and software required in the system
is given later in the report.
Operational feasibility
Operational feasibility covers two aspects. One is the technical performance aspect and other
is the acceptance within the Online Case Management System. Operational feasibility
determines how the proposed system will fit in the current operations and what, if any job
restructuring and retraining may be needed to implement the system.
In the system operational feasibility checks, whether the user who is going to use the
system is able to work with the softwares with which the system is coded and also the mind
of the user going to use the system. If the user does not understand or is able to work on the
system further development is of waste.

2.2.1 Feasibility Report

The basic outcome of the feasibility study is the feasibility report .The feasibility report is
given to the management in order to evaluate the impact of the proposed changes on the
area(s) .It is nothing but a formal document for the management .It should be brief enough
and preferably written in a simple form (non-technical) so that anybody can understand it.
For the feasibility report, no standard format is followed. The analyst usually makes it in
a format which suits the particular system as well as the management.
But, generally
Feasibility
Studythe
feasibility report begins with the summery of all the findings and the recommendations. The
summery information depicts the highlight of the proposed system .The management reviews
it later on. The feasibility report basically contains the followings :

Cover letter presents briefly the nature, general findings and the recommendations to
be considered.

Table of Contents gives the various parts and their respective locations on the report.

Overview is the narration of the purpose and scope of the project. It also includes the
name of the person who did the feasibility study, when it begun, and the other
necessary information that explains well how the study is being carried out.

Detailed finding gives the method present in the manual system or the proposed
system(new system).The system efficiency as well as the operating costs are also
given here.

Economic justification contains the study of economic comparisons and an overview

of the cost estimation .A return on investment analysis is also included here.

Recommendations suggests the most beneficial and cost-effective candidate system.

Conclusion gives the other remarks after having the entire study .

Appendixes documents all the memos and the data compiled during the investigation.
The appendix is added at the end of the feasibility report.

2.2.2 Conclusion
The above observations made from the feasibility study recommends that the proposed
computerized storing of car information & car sales report is feasible for its development
and implementation.

2.3 Project Planning

Once a project is found to be feasible, software project managers undertake project planning.
Project planning is undertaken and completed before any development activity starts. Project
planning consists of the following activities :

Estimation
The following project estimates have to be estimated.

Cost: How much is it going to cost to develop the software?

Duration:

Effort:

How long is it going to take to develop the product?

How much effort would be required to develop the product?

The effectiveness of all other planning activities such as scheduling and staffing are
based on the accuracy of these estimations.

Scheduling

After the estimations are made, the schedules for manpower and other resources have to be
developed.

2.4 Project Scheduling

Pert Cart
The Program (or Project) Evaluation and Review Technique, commonly abbreviated PERT, is
a model for project management designed to analyze and represent the tasks involved in
completing a given project. It is commonly used in conjunction with the critical path method
or CPM.
PERT is a method to analyze the involved tasks in completing a given project, especially
the time needed to complete each task, and identifying the minimum time needed to complete
the total project.
PERT was developed primarily to simplify the planning and scheduling of large and
complex projects. It was developed for the U.S. Navy Special Projects Office in 1957 to
support the U.S. Navy's Polaris nuclear submarine project. It was able to incorporate
uncertainty by making it possible to schedule a project while not knowing precisely the
details and durations of all the activities. It is more of an event-oriented technique rather than
start- and completion-oriented, and is used more in projects where time, rather than cost, is
the major factor. It is applied to very large-scale, one-time, complex, non-routine
infrastructure and Research and Development projects. An example of this was for the 1968
Winter Olympics in Grenoble which applied PERT from 1965 until the opening of the 1968
Games.
This project model was the first of its kind, a revival for scientific management, founded
by Frederick Taylor (Taylorism) and later refined by Henry Ford (Fordism). DuPont
corporation's critical path method was invented at roughly the same time as PERT.

Feasibility
Study

Analysis

Design

(30 hours)

Initial
Investigatio
n

Testing

Coding

(30 hours)

Start
Implementation
Post implementation

Finish

Gantt Chart
A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt charts illustrate
the start and finish dates of the terminal elements and summary elements of a project.
Terminal elements and summary elements comprise the work breakdown structure of the
project. Some Gantt charts also show the dependency (i.e., precedence network) relationships
between activities. Gantt charts can be used to show current schedule status using percentcomplete shadings and a vertical "TODAY" line as shown here.
Although now regarded as a common charting technique, Gantt charts were considered
revolutionary when they were introduced. In recognition of Henry Gantt's contributions, the
Henry Laurence Gantt Medal is awarded for distinguished achievement in management and
in community service. This chart is used also in Information Technology to represent data
that have been collected.
A common error made by those who equate Gantt chart design with project design is that
they attempt to define the project work breakdown structure at the same time that they define
schedule activities. This practice makes it very difficult to follow the 100% Rule. Instead the
WBS should be fully defined to follow the 100% Rule, then the project schedule can be
designed.
Although a Gantt chart is useful and valuable for small projects that fit on a single sheet
or screen, they can become quite unwieldy for projects with more than about 30 activities.
Larger Gantt charts may not be suitable for most computer displays. A related criticism is that
Gantt charts communicate relatively little information per unit area of display. That is,
projects are often considerably more complex than can be communicated effectively with a
Gantt chart. Gantt charts only represent part of the triple constraints (cost, time and scope) of
projects, because they focus primarily on schedule management. Moreover, Gantt charts do
not represent the size of a project or the relative size of work elements, therefore the
magnitude of a behind-schedule condition is easily miss communicated. If two projects are
the same number of days behind schedule, the larger project has a larger impact on resource
utilization, yet the Gantt does not represent this difference.

1.Initial Investigation
(30 hrs)
2.Feasibility Study
(30 hrs)
3.System Analysis
(60 hrs)

4.System Design
(100 hrs)

5.Coding
(160 hrs)

6.Testing
(30 hrs)
7.Implementation
(20 hrs)
8.Post Implementation
(30 hrs)
9.Finish

2.5 Software Requirement Specification

Online Case Management System
2.5.1 Introduction
Online Case Management System (OCMS) is a Online Portal for Advocates to maintain their
Diary of Cases & Clients. Details of all the cases with the Advocate can be entered in
invariably, immediately on filing of the case in the relevant Appellate authority which may
either be an Office or a Court of Law. Later all the subsequent developments taken place such
as the dates fixed for hearing; Date of arguments; or Date for production of any documentary
evidence etc., in each and every case, time to time, can also be entered online.

2.5.1.1 Purpose
The Software Requirements Specification (SRS) will provide a detailed description of the
requirements for the Online Case Management System. This SRS will allow for a complete
understanding of what is to be expected of the Online Case Management System to be
constructed. The clear understanding of the Online Case Management System and its
functionality will allow for the correct software to be developed for the end user and will be
used for the development of the future stages of the project. This SRS will provide the
foundation for the project. From this SRS, the Online Case Management System can be
designed, constructed, and finally tested.
We will use the SRS to fully understand the expectations of this Online Case
Management System to construct the appropriate software. The end users will be able to use
this SRS as a test to see if the constructed system is up to their expectations. If it is not to
their expectations the end users can specify how it is not to their liking and the SRS will be
changed to fit the end users needs.

2.5.1.2 Project Scope

The software product to be produced is an Online case Management System which will
automate the office works of the advocates. This projects aim is to automate the system, prechecking the inclusion of all required material and automatically generate documents in
prinable format, generate fee invoice and send sms to clients related to the case. It supports
the current process but centralizes it and makes it possible for decisions to be made earlier
and easier way.

2.5.1.3 Goals
The main goal of the system is to automate the process carried out in the Advocate
office/Law firm with improved performance .
Some of the goals of the system are listed below:

Manage of clients details.

Maintain detailed information on cases, view next hearing dates etc.

Create the reports of cases, generate invoice of fee payments.

Reduce the work load and save money

Activities like modification , deletion of records should be easier.

2.5.2 Benefits of the system

As with most real world activities, there are numerous benefits to using a software system for
Online Case Management System. The most apparent to this project is the unification of the
entire process. Another benefit of a software system is the use of a central database. This
database is the basis for all actions in the system and can be trivially updated and used to aid
in all of the systems processes, meaning all of the required information is stored in one
central location and thus is easily accessible. This is a far more reasonable storage method
than a paper-based file system, where the time of traveling to and physically searching the
records for the required information could be a burden. Human error could also be a factor in
that mistakes could be made in the filing process which would not occur in a well written
database system and mistakes or changes on physical records can be messy to correct.
Software systems are also much faster at performing certain tasks than humans, meaning that
time can be saved performing processes.

2.5.3 Overview
SRS will include two sections.
Overall Description will describe major components of the system, interconnection and
external interfaces.
Specific Requirements will describe the functions of actors, their role in the system and
constraints.

2.5.3.1 Overall Description

Administrator

Web server

Reporting
Advocates

Database

Figure 1: Model of the system

2.5.4 Memory Constraints

Hardware memory: The growth of university is unpredictable; to resolve the future
problems occurs while enhancing the system is controlled by larger memory as possible. So
the memory constraint in the server side is extended up to 500GB.

2.5.5 Site Adaptation requirements

No site adaptation is necessary in this project. Because the Online Case Management System
is portable. The entire system is transported to wherever it is needed. No external
dependendancies are in place and operation of the system will never change due to location.

2.5.6 User Classes and Characteristics

User Characteristics
The Advocates should have the basic idea to operate (use) the system and he/she already has
the experience to work in the internet (browser). Default Language is English.

User Classes:
Some of the users identified for this system through use case analysis are listed below:

Administrator

Adocates

Design and Implementation Constraints

Some of the design and implementation constraints identified are listed below:

Advocates can view their profile by log in with their password and user ids and can
edit their profile, store client and case related information etc. but cannot edit other
profiles, donot have any access to others profile or modify information.

This system is not support distributed database Facility.

Assumptions and Dependencies

Some functions are already created and informations available for use.

Roles and responsibilities are already established.

Administrator is already created.

2.5.7 System Requirements and Analysis

The following sections will introduce the numerous requirements of the system from the
point of view of different users and will introduce a number of decisions that have been made
regarding implementation. These sections also attempt to somewhat describe the role of each
user group in the system, discussing their individual roles through the functions they can
perform.
User Interface

The user interface for this system will have to be simple and clear. Most importantly,
the ages must be easy to read, easy to understand and accessible.

Screen Name

Description

Login

Log into the system as a Administrator/User

User registration

Here Advocate enter his/her details needed for registarion

into the system

Clients

Advocate store the particulars of the Client Information &

details on correspondence & Permanent address particulars

Case entry

Advocate has to take entry of the Case Number and Year of

filing the case in the respective fields. In the same way, he
has to enter Name of the Court and place of its location in
which he has filed the case, by clicking on the relevant fields
and selecting the appropriate names.
Advocate has to enter the Date of hearing of the case, next
hearing date etc.
Keep fees related information such as how much amount
received and how much remaining. Generate recipt/invoice
of fees.
Set reminder to alert client by automatically sending SMS to
remind about hearing date.

Case proceeding
Fees Transaction

Reminder
Setting

Modification of admin/advocates profile settings

Advocates View Functionality

Registration: Advocates will carry out their own registration, providing the system
with a way to associate a user to their registration(s). This will enable the system to
display personalized information

Registration System: The registration process will be as straightforward as possible,

using an intuitive form layout, with the necessary information being completed in
stages.

Administrator View Functionality

View Completed Registration Details: Viewing all of the recently submitted registration
details is something the administrator will do on a regular basis. A list of all the submitted
registration forms, oldest to newest to prevent some applications remaining unread, will be
viewable, each of which expandable to view the entire details.
System :

Validation: On the completion of each form in the system, the system will use a set of
validation functions to ensure that information is of the right type in each field.

Other Nonfunctional Requirements

Performance Requirements
Some Performance requirements identified is listed below:

The database shall be able to accommodate a minimum of 50000 records of

advocates.

The software shall support use of multiple users at a time.

There are no other specific performance requirements that will affect development.
Security Requirements
Some of the factors that are identified to protect the software from accidental or malicious
access, use, modification, destruction, or disclosure are described below. Specific
requirements in this area could include the need to:

Keep specific log or history data sets

Restrict communications between some areas of the program

Communication needs to be restricted when the application is validating the user or

license. (i.e., using https).

Reliability
Some of the attributes identified for the reliability is listed below:

All data storage for user variables will be committed to the database at the time of
entry.

Data corruption is prevented by applying the possible backup procedures and

techniques.

2.6 Software Engineering Paradigm applied

The Software Engineering Paradigm or the Software Development Strategy applied in the
Online Case Management System is the Iterative Waterfall Model.
An iterative waterfall model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just part of the
software, which can then be reviewed in order to identify further requirements. This process
is then repeated, producing a new version of the software for each cycle of the model.
In the iterative waterfall model, we work iteratively we create rough product or product
piece in one iteration, then review it and improve it in next iteration and so on until its
finished.

Feasibility
study

Requirements analysis
and specification
Design

Coding and unit

testing

Integration and system

testing

Maintenance

This model contains 6 phases

Feasibility study
The feasibility study activity involves the analysis of the problem andcollection of the
relevant information relating to the product. The main aim of the feasibility study is to
determine whether it would be financially andtechnically feasible to develop the product.
Requirement analysis and specification
The goal of this phase is to understand the exact requirements of thecustomer and to
document them properly. (SRS)
System Design
The goal of this phase is to transform the requirement specification into astructure that is
suitable for implementation in some programming language.
Testing

During this phase the design is tested in small modules in isolation from rest of the software
product. Then all the modules are integrated together and tested.
Implementation
Release of software inaugurates the operation and life cycle phase of theoperation.The phases
always occur in this order and do not overlap.

2.7 Data Models

Data Flow Diagram
DFD is the one among the various methods to show the flow of the data within the project. In
this type of representation, the entities are represented with the help of rectangular box and
the process is represented with the help of rounded rectangle or circle. The dataflow is
represented by means of the arrow with the indication of the direction of flow with the help
of the arrow pointer. The data files are shown with the help of rectangle box with one side
open. The data flow diagrams are the tools in the top-down approach, moves from general
requirements to more specific requirements, illustrating the process, movement, and the
storage of data in the system. In DFDs, processes are first identified and then the data flow
between the processes are isolated and derived. Thus processes are focal point of the DFD.
Data Flow Diagrams themselves stress the flow and transformation of the data within a
system.
A DFD is also known as bubble chart , has the purpose of defining the system
requirement and it functionally decomposes the requirement specification down to the lowest
level of detail. It is a graphical tool used describe and analyze the movement of data through
the system manual or automated including the process , stores of data and delays in the
system .The bubbles represent the data transformations and the line represents the flow of
data in the system. The following diagram illustrates the notations and symbols used to
construct the DFD.

DFD Symbols
1. External Entity
The producer or the consumer of information that resides outsides the bound of the
system to be modeled. The following rectangular shape denotes it.

2. Process
It is the agent that performs the transformation of information from one state to
another. The following shape denotes it.

3. The Data Flow

A data flow connects the output of an object or process to the input of another object
or process. The arrows denote flow of intermediate data value within a computation.
The arrowhead indicated the direction of flow of data.

4. Data Store
A repository of data is a passive object within a DFD for later access. A data store
does not generate any operations on its own but merely responds to requests to store
and access data. The following shape denotes it.

Context diagram

E-R Diagram:
The most important consideration in designing the database is how to information will be
used. The various application and procedures that will be used the database introduces the
requirements upon the structure of data.
In a relational database, representation of data and data relationship is a collection of
tables. Each table has one or more columns.
The first step in creating a database is designing it. First plan what we require and what
data they will contain. It also determines how the tables were created. This is a very
important step and deserves careful considerations.
It should determine what things we want to store information about (entities) and how
these things are related (relationship). A useful technique in designing the database is to draw
a picture of the tables. This graphical display of database is called an Entity Relationship
Diagram (E-R Diagram). Usually, each box in E-R Diagram corresponds to a foreign key.

REPRESENT AN ENTITY

REPRESENT AN ATTRIBUTE

REPRESENT KEY ATTRIBUTE

REPRESENT RELATIONSHIP

REPRESENT CARDINALITY

LINKS ATTRIBUTE WITH ENTITY AND ENTITY WITH

RELATIONSHIP

Chapter 3

System Design
The most creative and challenging phase of system life cycle is system design. The system
design describes the final system and the process by which it is developed. It refers to
technical specification that will be applied in implementing the candidate system. Designing
the software means to plan how various part of the software are going to meet the desired
goals. It should be done the performance of the entire system. As a result it may take more
processing time, more coding and extra workload.
System design is a how to approach to the creation of the new system. This important
phase is composed of several steps. It provides the procedural details necessary for
implementing the system recommended in the feasibility. It gives emphasis on translating the
performance requirements to design specifications. System design goes through two phases
of development Logical design and Physical design.

3.1

Data Integrity and Constraints

All data stored in a database must adhere to certain business rules. For example, there may be
a business rule specifying a minimum hourly wage for any employee or another rule stating
that the discount for sale items cannot be more than 100%. In either case if an INSERT or
UPDATE statement attempts to violate the integrity rule, the statement must be roll back and
return an error.

Integrity Constraints
An integrity constraint defines a business rule for a table column. When enabled, the rule will
be enforced by database. To create an integrity constraint all existing table data must satisfy
the constraint.
Default values are also subject to integrity constraint checking (defaults are included as
part of an INSERT statement before the statement is parsed.) If the results of an INSERT or
UPDATE statement violate an integrity constraint, the statement will be rolled back.
Integrity constraints are stored as part of the table definition, (in the data dictionary.)
If multiple applications access the same table they will all adhere to the same rule.
The following integrity constraints are supported by Oracle:

NOT NULL
UNIQUE
CHECK constraints for complex integrity rules
PRIMARY KEY
FOREIGN KEY integrity constraints - referential integrity actions: On Update On Delete
Delete CASCADE Delete SET NULL

3.2 Database Design

Usually a collection of interrelated is refer to as database. The database contains information
about the one particular enterprise. Database is design to manage a large volume of
information. The management of data involves both the definition of structures for the
storage of information and provision for mechanism manipulation of information. In addition
the database is system must provide for safety information stored in the database, despite
system crashes or unauthorized access.The detailed description and usage of each table
described briefly in the following section.

3.2.1 List of Database Tables

Table: admin
Field name
a_id
username
password
firstname
lastname
email
contact
photo
Table: case_type
Field name
ct_id
ctype

Data type
Integer
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar

Size
20
30
100
30
30
30
30
100

Constraints
Primary key
Not null
Not null
Not null
Not null
Unique key
Unique key
Not null

Data type
Integer
text

Size
20
40

Constraints
primary
Not null

Data type
integer
varchar

Size
20
40

Constraints
Primary key
Not null

Table: case_stages
Field name
cs_id
c_stage
Table: court

Field name
court_id
court_name
location

Data type
Integer
Varchar
Varchar

Size
20
50
50

Constraints
Primary key
Not null
Not null

Data type
Integer
Varchar
Varchar
Varchar
Varchar
Varchar
Integer
Varchar
Varchar
Varchar
date
Varchar
Varchar
Varchar
Varchar
Varchar
Integer
Varchar
Varchar
Varchar
Varchar
Integer
Varchar
Varchar
Varchar
Varchar
Varchar
date

Size
20
30
30
20
20
80
20
30
30
50

Constraints
Primary key
Not null
Not null
Not null
Not null
Not null
Not null
Unique key
Unique key
Not null
Not null
Not null
Not null
Not null
Not null
Not null
Not null
Unique key
Not null
Not null
Not null
Not null
Unique key
Not null
Not null
Not null
Not null
Not null

Data type
Integer
Varchar
Varchar

Size
20
30
50

Table: advocates
Field name
adv_id
name
address1
city
state
country
pin
email
contact
photo
dob
office
office_address1
office_city
office_state
office_country
office_pin
username
password
gender
activation
status
enroll_no
speciality
academic_qualificatio
court_of_practice
area_of_practice
practice_since

30
80
30
30
80
20
30
100
30
80
10
30
30
30
50
30

Table: clients
Field name
client_id
client_name
address

Constraints
Primary key
Not null
Not null

city
state
country
pin
email
contact
gender
adv_id
Table: case_entry
Field name
case_no
case_title
ct_id
prov_of_law
court_id
client_id
opp_party
reg_date
year
adv_id

Varchar
Varchar
Varchar
Integer
Varchar
Varchar
Varchar
Integer

30
30
100
20
30
30
30
20

Not null
Not null
Not null
Not null
Not null
Not null
Not null
Foreign key

Data type
Integer
Varchar
Integer
Integer
Integer
Integer
Varchar
Date
Year
Integer

Size
50
100
20
30
20
20
30

Constraints
Primary key
Not null
Foreign key
Not null
Foreign key
Foreign key
Not null
Not null
Not null
Foreign key

Data type
Integer
Integer
Integer
Integer
date
date
Varchar
Integer

Size
20
30
20
20
100
20

Constraints
Primary key
Foreign key
Foreign key
Foreign key
Not null
Not null
Not null
Foreign key

Data type
Integer
Integer
Integer

Size
20
30
20

Constraints
Primary key
Foreign key
Foreign key

4
20

Table: case_proceeding
Field name
prceed_id
client_id
case_no
cs_id
proceed_date
next_hear_date
result
adv_id

Table: case_document
Field name
document_id
client_id
case_no

d_name
document
dat
adv_id

Varchar
Varchar
date
Integer

100
80

Data type
Integer
Integer
Integer
date
Varchar
decimal
decimal
decimal
decimal
Integer

Size
20
20
30

Data type
Integer
Integer
Integer
Varchar
date
Integer

Size
20
30
20
100

Data type
Integer
Varchar
Varchar
Varchar
text

Size
20
30
30
30

20

Not null
Not null
Not null
Foreign key

Table: case_fees
Field name
fee_id
client_id
case_no
date
pay_mode
legal_fees
court_fees
received
balance
adv_id

30
30,2
30,2
30,2
30,2
20

Constraints
Primary key
Foreign key
Foreign key
Not null
Not null
Not null
Not null
Not null
Not null
Foreign key

Table: case_reminder
Field name
reminder_id
client_id
case_no
r_detail
date
adv_id

20

Constraints
Primary key
Foreign key
Foreign key
Not null
Not null
Foreign key

Table: contact
Field name
m_id
name
email
contact
message

Constraints
Primary key
Not null
Unique key
Unique key
Not null

status
date

Varchar
datetime

20

Not null
Not null

Data type
Integer
Varchar
Varchar
Varchar
Varchar
Varchar
Text
Varchar
Datetime
Varchar
Varchar

Size
20
30
30
30
30
30

Constraints
Primary key
Not null
Not null
Not null
Not null
Not null
Not null
Not null
Not null
Not null
Not null

Data type
Integer
Varchar
Varchar
Varchar
Varchar
Varchar
Text
Varchar
Datetime

Size
20
30
30
30
30
30

Data type

Size

Table: message
Field name
msg_id
subject
msg_to
to_name
msg_from
from_name
message
attach
date
status
place

100
20
20

Table: msg_sent
Field name
m_id
subject
msg_to
to_name
msg_from
from_name
message
attach
date

80

Constraints
Primary key
Not null
Not null
Not null
Not null
Not null
Not null
Not null
Not null

Table: chat
Field name

Constraints

id
from
to
message
sent
recd

Integer
Varchar
Varchar
text
datetime
int

10
80
80
30
10

Primary key
Not null
Not null
Not null
Not null
Not null

3.3 User Interface Design

The first step in the user interface design activity focuses on the preparation of input and the
design of output reports in a form acceptable to the user.
User interface design consists of two steps input design and output design.
Input Design
Input designing is a crucial part of any system design. Inaccurate input data are the most
common cause of error in data processing. Data entry can be control by input design. Input
design is the design phase; the expanded data flow diagram identifies logical data flows, data
stores, sources and destinations. The goal of designing input data is to make data entry as
easy as possible. In the case of Online Case Management System management system
much emphasis has been given to this phase. To reduce input errors, either the users are
provided with choices to choose from, or invalid inputs are restricted. Here the chances of
entering invalid data are minimal.
While entering data, the operators need to know the following:

The field that is required to be fill up.

Field sequences, which most match that in the source document

The format in which data field is entered.

Keeping in view the user requirements, the inputs screens have been designed and
developed for easy and error free data entry. Based on the various types of inputs to be fed to
the computer in using the proposed system, all input screens have been designed in real mode
(GUI).
The details of all input screens are shown as follows:

Output Design

Computer output is the most important and direct source of information to the user. Efficient,
intelligible output design should improve the systems relationship with the user and help in
decision making. A major form of output is a hard copy from the printer. The output screens
for displaying the information have been designed in such a way that maximum information
can be viewed using minimum effort and time.
The details of all output screens are shown as follows:

3.4 Test Cases

Unit Test cases
Unit testing verifies the smallest module of the software designed. Using this testing the
entire module can be debugged very easily. The relative complexity of test and the errors
detected as a result its limited by the constrained scrap established for unit testing. The
relative complexity of test and the errors detected as a result its limited by the constrained
scrap established for unit testing.
Unit testing is considered an adjunct to the coding step. After source code has been
developed and verified for the syntax connection, unit test case designed starts.

System Test cases

In the testing process the Demo versions of the software i.e. actual replica of the existing
system will be installed so that the users can use it as they like and give their valuable
suggestion and advice. There after security can be incorporated in the system. In this phase
we will be using both alpha and beta test, which will enable the user to check the whole
system thoroughly. The said Demo version software can be used for a period of 15 days to 1
month and during this period only training of the proposed software will be imported. This
phase will allow the entire user to use the system in a much more efficient way.
The design tests for software and other engineered products can be as challenging as the
initial design of the product itself. The objectives of the testing are the finding of errors with a
minimum amount of time and effort.

Chapter 4

Coding
The input to coding phase is the design document produced at the end of the design phase.
During the coding phase, different modules identified in the design document are coded
according to their respective module specifications.
The objective of the coding phase is to transform the design of a system into code in a
high level language, and then unit test this code.
The software development organizations formulate their own coding standard that suits
them most. The main advantages of adhering to a standard style of coding are as following:
(i)

A coding standard gives a uniform appearance to the code written by different

engineers.

(ii)

It facilitates code understanding.

(iii)

It promotes good programming practices.

Coding standard and guidelines

Good software development organizations develop their own coding standards and guidelines
depending on what suits their organization best and based on the specific types of product
they develop.
Coding guidelines provide only general suggestions regarding the coding style to be
followed. Unlike coding standards, the use of these guidelines is not mandatory. However, the
programmer is encouraged to review them and attempt to incorporate them into his
programming style.

4.1 Sample Project Coding

4.2 Comments and Description of Coding Segments

<html></html > The main container for HTML pages

<head></head> The container for page header information

<title></title> The title of the page

<body></body> The main body of the page

<script></script> The HTML script element is used to insert client side script code into a
document.
This can be achieved in two ways: inserting the code directly as content of this
element or referring to an external file containing script code with the "src" attribute. In the
second case, user agents should ignore the content of the element.

<style></style> tag is used to define style information for an HTML document.

<div></div> tag defines a division or a section in an HTML document.

Canonical PHP tags

The most universally effective PHP tag style is:

<?php...?>

Commenting PHP Code

A comment is the portion of a program that exists only for the human reader and stripped
out before displaying the programs result. There are two commenting formats in PHP:
Single-line comments: They are generally used for short explanations or notes relevant to
the local code. Here are the examples of single line comments.
<?php
# This is a comment, and
// This is a comment too. Each style comments only print "An example with single line
comments";
?>
Multi-lines printing: Here are the examples to print multiple lines in a single print
statement
<?php
# Example
print "This spans multiple lines. The newlines will be
output as well";
?>
Statement
A statement in PHP is any expression that is followed by a semicolon (;). Any sequence of
valid PHP statements that is enclosed by the PHP tags is a valid PHP program. Here is a
typical statement in PHP, which in this case assigns a string of characters to a variable called
$greeting:
$greeting = "Welcome to PHP!";

Expression
The smallest building blocks of PHP are the indivisible tokens, such as numbers (3.14159),
strings (.two.), variables ($two), constants (TRUE), and the special words that make up the
syntax of PHP itself like if, else, while, for and so forth.

4.3 Error handling

Every well-constructed PHP application should have error handling. While there is no
definitive method for handling errors since it varies depending on application needs and a
developer's style, nonetheless, there are some "best practices" that should be implemented in
all PHP applications.
When creating scripts and web applications, error handling is an important part. If code
lacks error checking code, program may look very unprofessional and we may be open to
security risks.
There are different error handling methods:

Simple "die()" statement

Custom errors and error triggers

Error reporting

Using the die() function

The first example shows a simple script that opens a text file:
<?php
$file=fopen("welcome.txt","r");
?>
If the file does not exist you might get an error like this:
Warning: fopen(welcome.txt) [function.fopen]: failed to open stream:
No such file or directory in C:\webfolder\test.php on line 2
To prevent the user from getting an error message like the one above, we test whether the file
exist before we try to access it:
<?php
if(!file_exists("welcome.txt")) {
die("File not found");
} else {
$file=fopen("welcome.txt","r");
}
?>
Now if the file does not exist you get an error like this:
File not found

Creating a Custom Error Handler

Creating a custom error handler is quite simple. We simply create a special function that can
be called when an error occurs in PHP.
This function must be able to handle a minimum of two parameters (error level and error
message) but can accept up to five parameters (optionally: file, line-number, and the error
context):
Syntax
error_function(error_level,error_message,error_file,error_line,error_context)

Trigger an Error
In a script where users can input data it is useful to trigger errors when an illegal input occurs.
In PHP, this is done by the trigger_error() function.
Example
In this example an error occurs if the "test" variable is bigger than "1":
<?php
$test=2;
if ($test>1) {
trigger_error("Value must be 1 or below");
}
?>
The output of the code above should be something like this:
Notice: Value must be 1 or below
in C:\webfolder\test.php on line 6

Exceptions Handling:
PHP 5 has an exception model similar to that of other programming languages. Exceptions
are important and provides a better control over error handling.
Lets explain thre new keyword related to exceptions.

Try - A function using an exception should be in a "try" block. If the exception does
not trigger, the code will continue as normal. However if the exception triggers, an
exception is "thrown".

Throw - This is how you trigger an exception. Each "throw" must have at least one
"catch".

Catch - - A "catch" block retrieves an exception and creates an object containing the
exception information.

Example:
<?php
try {
$error = 'Always throw this error';
throw new Exception($error);
// Code following an exception is not executed.
echo 'Never executed';
} catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
}
// Continue execution
echo 'Hello World';
?>

4.4 Parameter Calling/passing

There are two ways the browser client can send information to the web server.

The GET Method

The POST Method

Before the browser sends the information, it encodes it using a scheme called URL encoding.
In this scheme, name/value pairs are joined with equal signs and different pairs are separated
by the ampersand.
name1=value1&name2=value2&name3=value3

The GET Method

The GET method sends the encoded user information appended to the page request. The page
and the encoded information are separated by the ? character.
http://www.test.com/index.htm?name1=value1&name2=value2

The GET method produces a long string that appears in your server logs, in the
browser's Location: box.

The GET method is restricted to send upto 1024 characters only.

Never use GET method if you have password or other sensitive information to be sent
to the server.

GET can't be used to send binary data, like images or word documents, to the server.

The data sent by GET method can be accessed using QUERY_STRING environment
variable.

The PHP provides $_GET associative array to access all the sent information using
GET method.

<?php
if( $_GET["name"] || $_GET["age"] )
{
echo "Welcome ". $_GET['name']. "<br />";
echo "You are ". $_GET['age']. " years old.";
exit();
}
?>
<html>
<body>
<form action="<?php $_PHP_SELF ?>" method="GET">
Name: <input type="text" name="name" />
Age: <input type="text" name="age" />
<input type="submit" />
</form>
</body>
</html>

The POST Method

The POST method transfers information via HTTP headers. The information is encoded as
described in case of GET method and put into a header called QUERY_STRING.

The POST method does not have any restriction on data size to be sent.

The POST method can be used to send ASCII as well as binary data.

The data sent by POST method goes through HTTP header so security depends on
HTTP protocol. By using Secure HTTP you can make sure that your information is
secure.

The PHP provides $_POST associative array to access all the sent information using
POST method.

<?php
if( $_POST["name"] || $_POST["age"] )
{
echo "Welcome ". $_POST['name']. "<br />";
echo "You are ". $_POST['age']. " years old.";
exit();
}
?>
<html>
<body>
<form action="<?php $_PHP_SELF ?>" method="POST">
Name: <input type="text" name="name" />
Age: <input type="text" name="age" />
<input type="submit" />
</form>
</body>
</html>

4.5 Validation Checks

Vlidation check using html5
1. The 'required' attribute

The simplest change you can make to your forms is to mark a text input field as 'required':
Your Name: <input type="text" name="name" required>

2. Different INPUT types

INPUT type="email"

By changing the input type to email while also using the required attribute, the browser can
be used to validate (in a limited fashion) email addresses:
Email Address: <input type="email" name="email" required placeholder="Enter
a valid email address">

INPUT type="number" and type="range"

The number and range input types also accept parameters for min, max and step. In most
cases you can leave out step as it defaults to 1.
Here you see an example including both a number input, typically displayed as a 'roller' and a
range input displayed as a 'slider':
Age:
<input
type="number"
size="6"
name="age"
min="18"
value="21"><br>
Satisfaction:
<input
type="range"
name="satisfaction" min="1" max="5" value="3">

3. Other HTML5 INPUT types

Other HTML5 input types include:

color

date

datetime

datetime-local

month

search

tel

time

week

4. INPUT patterns for different data types

URL input pattern:
input type="url" pattern="https?://.+"

max="99"
size="2"

IPv4 Address input pattern:

input type="text" pattern="\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}"

Vlidation check using Javascript

Basic Form Validation:

First we will show how to do a basic form validation. In the above form we are calling
validate() function to validate data when onsubmit event is occurring. Following is the
implementation of this validate() function:

<script type="text/javascript">
<!-// Form validation code will come here.
function validate()
{
if( document.myForm.Name.value == "" )
{
alert( "Please provide your name!" );
document.myForm.Name.focus() ;
return false;
}
return( true );
}
//-->
</script>

Data Format Validation:

Now we will see how we can validate our entered form data before submitting it to the web
server.
This example shows how to validate an entered email address which means email address
must contain at least an @ sign and a dot (.). Also, the @ must not be the first character of the
email address, and the last dot must at least be one character after the @ sign:
<script type="text/javascript">
<!-function validateEmail()
{
var emailID = document.myForm.EMail.value;
atpos = emailID.indexOf("@");
dotpos = emailID.lastIndexOf(".");
if (atpos < 1 || ( dotpos - atpos < 2 ))
{

alert("Please enter correct email ID")

document.myForm.EMail.focus() ;
return false;

}
return( true );

}
//-->

Vlidation check using Jquery:

Client-Side and Server-Side Validation
There's two fundamentally different ways to do form validation:
1. Server-side validation occurs only after the form is submitted
2. Client-side validation can occur dynamically, while the user is completing
the form

Server-side validation is the most robust, in that it can't be bypassed by disabling JavaScript
or otherwise modifying the front-end code, and it is important when you are submitting
information directly into a business-critical database with strict requirements.
<script type="text/javascript">
$(document).ready(function() {
$("#myform").validate({
[validation options go here]
});
});
</script>

Vlidation check using PHP5:

PHP - Validate Name
The code below shows a simple way to check if the name field only contains letters and
whitespace. If the value of the name field is not valid, then store an error message:
$name = test_input($_POST["name"]);
if (!preg_match("/^[a-zA-Z ]*$/",$name)) {
$nameErr = "Only letters and white space allowed";
}

PHP - Validate E-mail

The code below shows a simple way to check if an e-mail address syntax is valid. If the email address syntax is not valid, then store an error message:
$email = test_input($_POST["email"]);
if (!preg_match("/([\w\-]+\@[\w\-]+\.[\w\-]+)/",$email)) {

$emailErr = "Invalid email format";

}

PHP - Validate URL

The code below shows a way to check if a URL address syntax is valid (this regular
expression also allows dashes in the URL). If the URL address syntax is not valid, then store
an error message:
$website = test_input($_POST["website"]);
if (!preg_match("/\b(?:(?:https?|ftp):\/\/|www\.)[-a-z0-9+&@#\/%?=~_|!:,.;]*[-a-z09+&@#\/%=~_|]/i",$website)) {
$websiteErr = "Invalid URL";
}

Chapter 5

Testing
Software testing is a critical element of software quality assurance and represents the ultimate
review of specification, design and coding. In fact, testing is the one step in the software
engineering process that could be viewed as destructive rather than constructive.
A strategy for software testing integrates software test case design methods into a wellplanned series of steps that result in the successful construction of software. Testing is the set
of activities that can be planned in advance and conducted systematically. The underlying
motivation of program testing is to affirm software quality with methods that can
economically and effectively applied to both strategic to both large and small-scale systems

Testing Objectives
The testing objectives are summarized in the following three steps:
1. Testing is a process of executing a program with the intent of finding an error.
2. A good test case is one that has a high probability of finding an as yet undiscovered
error.
3. A successful test is the one that uncover an as yet undiscovered error.
Our objective is to design tests that systematically uncover different classes of errors and
do so with a minimum amount of time and effort.

Testing Principles
a) All tests should be traceable to customer requirement.
b) Tests should be planned long before testing begins that is the test- planning can begin
as soon as the requirement model is complete.
Testing should begin in the small and progress towards testing in the large. The first
plan and executed generally focus on individual program modules. As the testing progresses,
testing shifts focus in an attempt to find errors in integrated clusters of modules and
ultimately in the entire system.

The number of path permutations for even a moderately sized program is exceptionally
large. For this reason, it is impossible to execute every combination of paths during testing. It
is possible, however to adequately cover program logic and to ensure that all conditions in the
procedural design have been exercised. To be more effective, testing has highest probability
of finding the errors.
The following are the attributes of a good test:
1. A good test has the high probability of finding the errors.
2. A good test is not redundant.
3. A good test should be best of breed.
4. A good test should be neither too simple nor too complex.
This process has two parts:
a) Planning: This involves writing and reviewing unit, integration, functional, validation
and acceptance test plans.
b) Execution: This involves executing these test plans, measuring, collecting data and
verifying if it meets the quality criteria set in the Quality Plan. Data collected is used
to make appropriate changes in the plans related to development and testing.
The quality of a product or item can be achieved by ensuring that the product meets the
requirements by planning and conducting the following tests at various stages.

5.1 Strategic Approach to Software Testing

The software engineering process can be viewed as a spiral. Initially, system engineering
defines the role of software and leads to software requirement analysis where the information
domain, functions, behavior , performance, constraints and validation criteria for software are
established . Moving inward along the spiral, we come to design and finally to coding. To
develop computer software we spiral in along streamlines that decrease the level of
abstraction on each turn.
A strategy for software testing may also be viewed in the context of the spiral. Unit
testing begins at the vertex of the spiral and concentrates on each unit of the software as
implemented in source code. Testing progresses by moving outward along the spiral to
integration testing , where the focus is on the design and the construction of the software
architecture. Taking another turn on outward on the spiral we encounter validation testing
where requirements established as part of software requirements analysis are validated
against the software that has been constructed. Finally we arrive at system testing, where the
software and other system elements are tested as a whole.
Table Given below outlines the tests that were performed on the system to ensure
correctness and unearth errors, which were subsequently debugged.
Testing
Objectives
Phase

Unit
Testing

The various functions within each program and

the program blocks are tested for proper working.

Module
Testing

A module is composed of various programs

related to that module. Module testing is done to
check the module functionality and interaction
between units within a module

Integration
Testing

Integration testing is done to test the functionality and interfacing

between the modules.

Acceptance
Testing

Acceptance testing is done after implementation to

check if the system runs successfully in the
user environment/site.

Table shows the Tests Conducted on the Online Case Management System management
system

Unit Testing
Unit Testing will be done to test field validations, navigation, functionality of the programs
and its blocks. These tests are applied on various functions within each program and other
critical program blocks.

Module Testing
Module testing will be done to test the interaction between the various programs within one
module. It checks the functionality of each program with relation to other programs within
the same module. It then tests the overall functionality of each module.

Intregation Testing
Integration testing is done to test the functionality and interfacing between the modules. The
system is built up of various modules, which work together to automate the activities of the
Online Case Management System management system. These modules should work together
in a seamless way to achieve the desired results. Integration testing will test for this property
of the modules. The modules display a cause and effect relationship, if data in one module is
changed, then it affects the data to change in some other module also. Integration testing
needs to check if the modifications do not adversely affect some other modules.

Acceptance Testing
Acceptance testing was done after the implementation of the system. The acceptance testing
will check if the system works correctly in the user environment and if the entire user
specified functionalities are present. It also tests if the system adheres to the company
policies and quality standard.

5.2 Debugging
Debugging occurs as a consequence of successful testing. That is, when a test case uncover
an error, debugging can and should be an orderly process that result in the removal of the
error. Although debugging can should be an orderly process, it is still very much an art.
The debugging process will always have one of the two outcomes:

The cause will be found, corrected, and removed, or

The cause will not be found

The software was tested thoroughly before implementation and when errors were found
they were corrected and removed.
After a through testing of the different aspect of the system as described above the
system is ready for implementation.

Chapter 6

System Security Measures

The system security problem can be divided into four related issues
1. Security
2. Integrity
3. Privacy
4. Confidentiality
Security
It refers to the technical innovations and procedures applied to the hardware and the operating
system to protect against deliberate and accidental damages from a defined threat. In
contrast , data security is the protection of data from loss, disclose ,modification and
destruction.
Integrity
It refers to the proper functioning of the hardware and programs, appropriate physical
security and satisfy against external threats such as eavesdropping and wiretapping. In
comparison ,data integrity makes sure that data do not differ from original form and have not
been accidentally disclosed, altered or destroyed.

Privacy
It defines the right of the users and the organizations to determine what information they are
willing to share with or accept from others and how the organization can be protected
against unwelcome ,unfair or excessive dissemination of information about it.
Confidentiality
The term confidentiality is the special status given to the sensitive information in a database
to minimize the possible disclosure of information that characterizes its need for protection.

System security is the technical means of providing such protection .In contrast , privacy is
basically a procedure of how the information available are used.
Data privacy and security are issues that go beyond the scope of system development.
They are actually a social concern . An organization that depends heavily on the use of
databases requires special control to maintain viable information.
These controls are classified into three general categoriesa) Physical Security.
b) Database Security.
c) Application Security.
d) Operating System Level Security.

Physical Security
It refers the security or protection from fire ,flood or the other physical damages.Physical
security is the protection of personnel, hardware, programs, networks, and data from physical
circumstances and events that could cause serious losses or damage to an enterprise, agency,
or institution. This includes protection from fire, natural disasters, burglary, theft, vandalism,
and terrorism.There are three main components to physical security. First, obstacles can be
placed in the way of potential attackers and sites can be hardened against accidents and
environmental disasters. Such measures can include multiple locks, fencing, walls, fireproof
safes, and water sprinklers. Second, surveillance and notification systems can be put in place,
such as lighting, heat sensors, smoke detectors, intrusion detectors, alarms, and cameras.
Third, methods can be implemented to apprehend attackers (preferably before any damage
has been done) and to recover quickly from accidents, fires, or natural disasters.

Database/data security
Registration level authentication and authorization mechanisms should be considered as an
effective means of providing database security. Registration and authorization provides
abstraction .The primary benefit of abstraction is that of a single sign on capability across
multiple databases and database platforms. A single sign-on system should store the database
users credentials (login id and password), and authenticate to the database on behalf of the
user.Database security concerns the use of a broad range of information security controls to
protect databases (potentially including the data, the database applications or stored
functions, the database systems, the database servers and the associated network links)
against compromises of their confidentiality, integrity and availability. It involves various
types or categories of controls, such as technical, procedural/administrative and
physical. Database security is a specialist topic within the broader realms of computer
security, information security and risk management.

Application Security
It refers to the control measures of the application software through passwords ,encryption
and monitoring users on a regular basis. The client was given the application software in
floppies or compact disk, so that if some of the files get corrupted accidentally or
intentionally ,the whole system can again be loaded from backup disks and the database can
be recovered back. Application security is the use of software, hardware, and procedural
methods to protect applications from external threats. Once an afterthought in software
design, security is becoming an increasingly important concern during development as
applications become more frequently accessible over networks and are, as a result, vulnerable
to a wide variety of threats. Security measures built into applications and a sound application
security routine minimize the likelihood that unauthorized code will be able to manipulate
applications to access, steal, modify, or delete sensitive data.

Operating System Level Security

In most operating environment there is lack of audit trails in most off shelf software package.
It is difficult to reconstruct transaction for audit purpose. As more personal computers are
linked to company mainframe so, remote users can access data, the potential increase for
alerting the data deliberately or by mistake.
It is becoming so obvious that the personal computer is adding security problems to
system installations. With the use of microcomputer the corporate environment, the potential
for misuse of information becomes enormous. Many of todays operating system contains
password; a would-be theft can copy at will.

Chapter 7

Cost Estimation of The Project

Estimation of the cost for the development of the software is done using the COCOMO
(COnstructive COst estimation MOdel). COCOMO is a heuristic estimation technique.
The COCOMO Model was proposed by Boehm, 1981. Boehm postulated that any
software development project can be classified into any one of the following three categories
based on the development complexity: organic, semidetached and embedded.
Organic
We can consider a development project to be organic type, if the project deals with
developing a well-understood application program, the size of the development team is
reasonably small and the team members are experienced in developing similar type of
projects.
Semidetached
A development project can be considered to be of semidetached type , if the development
team consists of a mixture of experienced and inexperienced staff. Team members may have
limited experience on related systems but may be unfamiliar with some aspects of the system
being developed.
Embedded
A development project is considered to be of embedded type, if the software being developed
is strongly coupled to complex hardware, or if stringent regulations on the operational
procedure exist.

Basic Cocomo Model

The basic COCOMO model gives an approximate estimate of the project parameters. The
basic COCOMO estimation model is given by the following expressions:
Effort =a1 * (KLOC)a2 PM
Tdev = b1 * (Effort)b2 Months

Where,
a) KLOC is the estimated size of the software product expressed in Kilo Lines of Code.
b) a1, a2, b1, b2 are constants for each category of software product.
c) Tdev is the estimated time to develop the software, expressed in months.
d) Effort is the total effort required to develop the software product expressed in Person
Months.

Estimation of development effort

For the three classes of software products, the formulas for estimating the effort based on the
code size are given below :
Organic

: Effort = 2.4(KLOC)1.05 PM

Semidetached : Effort = 3.0(KLOC)1.12PM

Embedded

: Effort = 3.6(KLOC)1.20PM

Estimation of development time

For the three classes of software products, the formulas for estimating the development time
based on the effort are given below :
Organic

: Tdev = 2.5(Effort)0.38 Months

Semidetached

: Tdev = 2.5(Effort)0.35 Months

Embedded

: Tdev = 2.5(Effort)0.32 Months

Chapter 8

Reports

Chapter 9

Future Scope and Further Enhancement

This system is designed & developed by keeping in mind the various problems that are being
faced by the admin/job consultancies in keeping large records related to job seeker, recruiters
manually. It is an indispensable modern day tool as it is capable of keeping huge amount of
records and eventually retrieving it. As time progresses it will gain more popularity in the
field of any other survey related activities.
As for other future developments, it can be made more secured, better techniques can be
introduced for making it more user-friendly and more accurate. Moreover, if any new scheme
is implemented by the organization the system can be enhanced with little modification of the
existing database.

Chapter 10

Conclusion
The design of the system is done with great effort to understand the need of the users, the
various facilities in the day to day operation of a proposed system which intends to assist
Online Case Management System management system.The tool used for the developing the
system are

Dreamweaver cs4.

Wamp server

The designed software can be run on any IBM compatible machines providing the
minimum hardware and software requirements are satisfied. The software is intended to serve
the need of the proposed institute. The design of the software is made in such an way that the
user can operate the software using both key-board and the mouse. The menus are designed
in a very user friendly manner. There is some definite possibility of enhancement of the
software so as to fulfill the users requirement in future .People having the knowledge of
DBMS based packages can go for further enhancement of the software.

Biblography