PROJECT WORK TRACKING SYSTEM

Synopsis:

This project is about to automate the status tracking of various projects

dealt by Enterprise software Solutions. This system typically enables the top level
management to keep track of the status of the projects under their control. Some of
the critical activities that can be performed with this system are monitoring the
completion status of project documents, to alert PL’s indicating the documents
completion dates. PL allocates projects to TL, PL of a particular client with project
code, project name and start date of the particular project. The system keeps tracks of
the documents that have to be completed with in a particular duration. Mail system is
implemented in this project which enables effective communication between PL,TL
and TM. PL can upload documents to Team members and respective TM can view,
download and delete the same upto his needs. PL can update , delete the projects to
his needs and he can release workers from the project once if it is finished. The
system helps the PL, TL, TM to view the status of the project and helps in tracking
information about the project.
SYSTEM ANALYSIS

2.1 Feasibility Study

In the feasibility study phase, the feasibility of the project is

analyzed, and a proper solution is put forth, with a very general plan for the project and
some cost estimates, for feasibility analysis is operational technical and economical.

Operational feasibility

Operational feasibility is looked at in view of solution fitting in with current

operations, this test of feasibility asks, whether the system will work when developed and
installed?
Is their sufficient support for the project from the management?
Are current business methods acceptable to the users?
How will the solution affect the end users works environment?
Will it produce any poor result in any respect?
This project has sufficient support from the management. The end user’s work
environment is equipped with this software. They are ready to accept this software hence
it is behaviorally feasible, since the project can be handled easily.

Technical feasibility

Technical feasibility analyses whether the required technology and manpower is

available or not, this test of feasibility asks.
Is the technology needed for the proposed system available?
Can the system be expanded and developed?
Are their guarantees of accuracy, reliability, ease of access and data security?
 The technology and the man power for the proposed system is available hence it
is technically feasible.

Economic feasibility

The software being made should definitely yield benefits, greater than the
Cost of expenditure in creating the software, the software as for its objective is
concerned, will certainly yield better fruits, as it is designed for the purpose of Managing
money and other inputs and output of the system. Also the system Greatly reduces the
time factor it also reduces the maintenance cost of the records significantly.

2.4 PROPOSED SYSTEM

This system is used to track the project status .The main thing used in the
project is the mail system. These status and reports can easily shared between the Project
Leader, Team Leader and Project Leader. The System is maintained by J2EE technology.
The datas are stored in database automatically.

2.5 ADVANTAGES OF PROPOSED SYSTEM

 Documents can be distributed to the particular client easily.

 Security can be given, so that the users only view the status.
 Report generation is made easier.
 Effective Mailing system enables reliability.
 It takes less processing time.
 The process involves full fetched scalability.
 Data retrieval is faster by using J2EE technology.
SYSTEM CONFIGURATION

3.1 H/W System Configuration

Processor - Pentium –III

Speed - 1.1 GHz

RAM - 256 MB (min)
Hard Disk - 20 GB
Floppy Drive - 1.44 MB
Key Board - Standard Windows Keyboard
Mouse - Two or Three Button Mouse
Monitor - SVGA

SOFTWARE CONFIGURATION

OPERATING SYSTEM : Windows XP.

TECHNOLOGY : Java Server Pages (JSP).

DATABASE : MS-ACCESS (or) MY SQL.

WEB SERVER : Apache Tomcat 6.0.

ABOUT THE SOFTWARE

JAVA:
Java is used as front-end tool for developing the project. To run Java there
is no need to have any particular operating system, as it is platform independent. This
must have certain hardware and software installed on your computer. The key
considerations were summed up by the Java team in the following list of buzzwords:
 Simple
 Security
 Portability
 Object-oriented
 Robust
 Multithreaded
 Architecture-Neutral
 Interpreted
 High Performance
 Distributed
 Dynamic

THE JAVA 2 ENTERPRISE EDITION:

The Java 2 Platform, Enterprise Edition (J2EE), has rapidly established a

new programming model for developing distributed applications. This model is based on
well-defined components that can automatically take advantage of sophisticated platform
services. These components can be developed according to standard guidelines,
combined into applications, deployed on a variety of compatible server products, and
reused for maximum programmer productivity. This model is intended to both
standardize and simplify the kind of distributed applications required for today's
networked information economy.
 J2EE Platform Benefits :

With features designed to expedite the process of developing distributed
applications, the J2EE platform offers several benefits:

 Simplified architecture and development

 Freedom of choice in servers, tools, and components
 Integration with existing information systems
 Scalability to meet demand variations
 Flexible security model

HYPER TEXT MARKUP LANGUAGE (HTML):

HTML was specifically developed to use along with the Hyper Text
Transfer Protocol (HTTP) to encode documents for display on the World Wide Web.
HTML is defined in the HTML Standard, currently Version 4.0x. HTML
standards are recommended by the World Wide Web Consortium, W3C. W3C also
oversees the standardization of technologies related to the World Wide Web and
publishes the HTTP (Hypertext Transfer Protocol) standards. HTML is initials for Hyper
Text Markup Language. HTML is pronounced one letter at a time as if you are spelling
the word HTML. It is not pronounced as "hit mill" and it is NOT a programming
language. HTML cannot be used to write programs and it cannot control the precise
layout of a web page.
Web browsers are used to view HTML documents. Two popular web
browsers are the Netscape Navigator 4.x and the Microsoft Internet Explorer 5.x.
Browsers control the layout of a web page.
JAVA SCRIPT:

JavaScript enables you to embed commands in an HTML page. JavaScript

is powerful and simple. HTML provides a good deal of flexibility to page authors,
but HTML by itself is static, after being written, HTML documents can’t interact
with the user other than by presenting hyperlinks. Scripting languages act as the
glue that binds every thing together. JavaScript mainly provides a fairly complete
set of built- in functions and commands, enabling you to perform math
calculations, manipulates strings, play sounds, open new windows and new URLs,
and access and verify input to your web forms.
JavaScript can also set the attributes, or properties, of web page elements
and other objects present in the browser.
This way you can change the behavior of plugs–in or other objects without
having to rewrite them. JavaScript commands

MACROMEDIA DREAMWEAVER:

 Macromedia Dreamweaver 2.0 is one of the HTML Editor.

 It also includes DHTML effects.

 It is used to connect the forms to Servlets.

 It is used to Hyperlinks the web pages.

 It is used to create Templates.

It is used to attach Sound files and Animation files along with our Source.

The JAVA SERVER PAGES (JSP):

Java Server Pages ™ technology is the Java ™ platform

Technology for building applications containing dynamic Web

Content such as HTML, DHTML, XHTML and XML.

The Java Server Pages technology enables the authoring of Web pages

that create dynamic content easily but with maximum power and

flexibility.

Advantages:

 Write Once, Run Anywhere ™ properties.

 High quality tool support.

 Reuse of components and tag libraries.

 Separation of dynamic and static content.

 Support for scripting and actions.

 Web access layer for N-tier enterprise application architecture(s).

JSP page:

A JSP page is a text-based document that describes how to process a request to create a
response. The description intermixe template data with some dynamic actions and
leverages on the Java Platform.The features in the JSP technology support a number of
different paradigms for authoring of dynamic content. JSP pages can be used in
combination with Servlets, HTTP, HTML, XML, Applets,JavaBeans
components and Enterprise JavaBeans components to implement a broad
variety of application architecture(s) or models.

 Maximum performance and scalability through its unique design with the
Windows NT multi-threaded architecture.
 Central and easy-to-use the Graphical User Interface (GUI).
 Automatic authentication of users by the Operating System.

ENTERPRISE JAVABEAN (EJB):

EJB is a standard server side component model for component

transaction monitors. It automatically takes in to account many of the

requirements of business systems-security, resourse

pooling, persistence, concurrency and transasction integrity.

Overall goals:

The Enterprise JavaBeans (EJB) architecture has the following goals:

• The Enterprise JavaBeans architecture will be the standard component

architecture for building distributed object-oriented business applications in the Java
programming language. The Enterprise JavaBeans architecture will make it possible to
build distributed applications by combining components developed using tools from
different vendors.

• The Enterprise JavaBeans architecture will make it easy to write applications.

Application developers will not have to understand low-level transaction and state
management details, multi-threading, connection pooling, and other complex low-level
APIs.

• Enterprise JavaBeans applications will follow the “Write Once, Run Anywhere”
philosophy of the Java programming language. An enterprise Bean can be developed
once, and then deployed on multiple platforms without recompilation or source code
modification.

• The Enterprise JavaBeans architecture will address the development, deployment

and runtime aspects of an enterprise application’s life cycle.

• The Enterprise JavaBeans architecture will define the contracts that enable
tools from multiple vendors to develop and deploy components that can inter operate at
runtime.

• The Enterprise JavaBeans architecture will be compatible with existing

server platforms. Vendors will be able to extend their existing products to

support Enterprise JavaBeans.

• The Enterprise JavaBeans architecture will be compatible with other Java

programming language APIs.

• The Enterprise JavaBeans architecture will provide interoperability between

enterprise Beans and Java 2 Platform Enterprise Edition (J2EE) components as well as
non-Java programming language applications.

• The Enterprise JavaBeans architecture will be compatible with the

CORBA protocols.

Enterprise Bean Provider

The Enterprise Bean Provider is the producer of enterprise beans. The system
output is an ejb-jar file that contains one or more enterprise beans. The Bean Provider is
responsible for the Java classes that implement the enterprise bean’s business methods,
the definition of the bean’s remote and home interfaces and the bean’s deployment
descriptor.
The deployment descriptor includes the structural information of the enterprise
bean and declares all the enterprise bean’s external dependencies.

Application Assembler

Assembler combines enterprise beans into larger deployable application

units. The input to the Application Assembler is one or more ejb-jar files produced by the
Bean Provider(s). The Application Assembler outputs one or more ejb-jar files that
contain the enterprise beans along with their application assembly instructions. The
Application Assembler inserts the application assembly instructions into the deployment
descriptors.
The Application Assembler can also combine enterprise beans with other types of
application components (JSP) when composing an application. The EJB specification
describes the case in which the application assembly step occurs before the deployment
of the enterprise beans. However, the EJB architecture does not preclude the case that
application assembly is performed after the deployment of all or some of the enterprise
beans.

Deployer

The Deployer takes one or more ejb-jar files produced by a Bean Provider or
Application Assembler and deploys the enterprise beans contained in the ejb-jar files in a
specific operational environment. The operational environment includes a specific EJB
Server and Container. The Deployer is an expert at a specific operational environment
and is responsible for the deployment of enterprise Beans.The Deployer uses tools
supplied by the EJB Container Provider to perform the deployment tasks. The
deployment process is typically two-stage:

• The Deployer first generates the additional classes and interfaces that enable the
container to manage the enterprise beans at runtime. These classes are container-specific.
• The Deployer performs the actual installation of the enterprise beans and the
additional classes and interfaces into the EJB Container.

EJB Server Provider

The EJB Server Provider is a specialist in the area of distributed

transaction management, distributed objects, and other lower-level system-level
services. A typical EJB Server Provider is an OS vendor, middleware vendor, or
database vendor. The current EJB architecture assumes that the EJB Server
Provider and the EJB Container Provider roles are the same vendor. Therefore,
it does not define any interface requirements for the EJB Server Provider.
EJB Container Provider:

The EJB Container Provider provides

• The deployment tools necessary for the deployment of enterprise beans.

• The runtime support for the deployed enterprise bean instances.

The focus of a Container Provider is on the development of a scalable, secure,

transaction-enabled container that is integrated with an EJB Server. The Container
Provider insulates the enterprise Bean from the specifics of an underlying EJB Server by
providing a simple, standard API between the enterprise Bean and the container. This
API is the Enterprise JavaBeans component contract. The Container Provider typically
provides support for versioning the installed enterprise Bean components.The Container
Provider typically provides tools that allow the system administrator to monitor manage
the container and the Beans running in the container at runtime.

Persistence Manager Provider

The Persistence Manager interacts with the Container to receive

notifications related to the lifecycle of the managed beans. The current EJB architecture,
however, does not architect the full set of SPIs between the Container and the
Persistence Manager. These interfaces are currently left to the Container Provider and
Persistence Manager Provider.

System Administrator

The System Administrator is responsible for the configuration and administration

of the enterprise’s computing and networking infrastructure that includes the EJB Server
and Container. The System Administrator is also responsible for overseeing the wellbeing
of the deployed enterprise beans applications at runtime.

.
 4.SYSTEM DESIGN

4.1 DATABASE DESIGN

Database design is the first design in the designing of the system. It forms
the bases on which the whole system has to be designed. If the database is carried out well
then the design of the modules can be carried out easily without any worry about the data.
The main objective of the data base design is to structure the data in such a way that is free
from the program modules. The two main objectives the database design are listed below,

Database Integrity

It means that the database should be valid at all times and give the user the exact
details, which he wants. The integrity of the database can be questioned when there is more
that one copy of the data. In such a case the data at all the places should be updated
simultaneously so that the database gives the exact information whenever it is queried.
Thus the system satisfies the database integrity.

Database Independency

This ensures that the data is independent of the application. The application
program must be independent of the database. If this is ensured, then the application can be
modified in the future without any change to the database. This change also doesn’t affect
the other application in the system. Similarly a change made to the database does not affect
any programs if data independence is ensured. This database independency is satisfied by
the current system.

TABLES
TABLE: EMP_PERDET:
Company can have profile details of every Employee.

FIELD NAME DATA TYPE SIZE CONSTRAINTS

name Text 50 Not null
age Int 50 Not null
gender Text 50 Not null
quali Text 50 Not null
exp Text 50 Not null
plat Text 50 Allow null
role Text 50 Not null
userid Text 50 Primary key
pass Text 50 Not null
mail Text 50 Allow null
cont Int 50 Allow null

TABLE: LOGIN
Login details have the credentials of employee to login.

FIELD NAME DATA TYPE SIZE CONSTRAINTS

name Text 50 Not null
userid Text 50 Primary key
pass Text 50 Not null
role Text 50 Not null

TABLE: PJDET
This table contains complete details about the new project,members assigned and
status of project.

FIELD NAME DATA TYPE SIZE CONSTRAINTS

pjcode Text 50 Primary key
pjname Text 50 Allow null
envi Text 50 Allow null
ctname Text 50 Allow null
stdate Text 50 Allow null
tlcode Text 50 Allow null
actstdate Text 50 Allow null
actenddate Text 50 Allow null
taskno Text 10 Allow null
grptype Text 10 Allow null
membr_inv1 Text 50 Allow null
membr_inv2 Text 50 Allow null
membr_inv3 Text 50 Allow null
membr_inv4 Text 50 Allow null
membr_inv5 Text 50 Allow null
status Text 100 Allow null

TABLE: DOCUSTORED
The uploaded documents regarding projects are displayed in this table.

FIELD NAME DATA TYPE SIZE CONSTRAINTS

name Text 50 Not null
Filename longblob 0 Not null

TABLE: PLMAILS
The mails sent to Project Leader are stored in this table with date and time of mails.

FIELD NAME DATA TYPE SIZE CONSTRAINTS

code Int 50 Primary Key
afrom Text 255 Not null
pluserid Text 255 Not null
subject Text 255 Not null
message Long text 0 Not null
mdate Text 50 Not null
mtime Text 50 Not null

TABLE: TLMAILS

The mails sent to Team Leader are stored in this table with date and time of mails.

code Int 50 Primary Key

afrom Text 255 Not null
tluserid Text 255 Not null
subject Text 255 Not null
message Long text 0 Not null
mdate Text 50 Not null
mtime Text 50 Not null

TABLE: TMMAILS

The mails sent to Team Member are stored in this table with date and time of mails.

code Int 50 Primary Key

afrom Text 255 Not null
tmuserid Text 255 Not null
subject Text 255 Not null
message Long text 0 Not null
mdate Text 50 Not null
mtime Text 50 Not null

NORMALIZATION

The normal forms are used to ensure that various types of anomalies and are not
introduced inconsistencies into the database.
 Unnormalized form

An Unnormalized relation contains non-atomic values i.e. each rows may contain
multiple set of values for some of the columns these multiple values in a single row are also
called non-atomic values. There are no tables in unnormailzed form.

First Normal Form

A relation scheme is said to be in the first normal form (1NF) if the values in the
domain if each attribute of the relation are atomic. In other words only one value is
associated with each attribute and the value is not a set of values or list of values. All the
tables here are atomic.

Second Normal Form

A relation is in Second Normal Form (2NF) if it is in the first normal form and if all
nonprime attributes are fully functionally dependant on the relation key(s). All tables satisfy
the second normal form.

Modular Description

Login screen
An authenticated user having a valid Employee code can login. There are three
users namely Project Leader (PL) and Team Leader (TL) and Team Member (TM).

PL is given permission to add new projects, update/delete the existing projects.

PL is given permission to view the completed and pending documents of the
projects.

Project Leader Login

PL is given permission to add new projects, update/delete the existing projects.

Add New Projects

PL allocates projects with the following details
  Project Name.
 Project code.
 Client details.
 Leader in charge (TL).
 Start Date
 End Date

Update/Delete Projects
PL can update the details of the existing projects and also has the option for
deleting the project when completed.

Allot workers
PL can allot workers needed for the project by their codes according to the
availability and needs of the project.

View Current and Completed Projects

PL can view the status of project. He can keep a track of projects and its updates
from TL and TM.

Release Workers
PL can release workers from the project once it is finished ,so that the workers
can be assigned to the next project.

Team Leader Login

TL is given permission to view the current status of the documents, pending
documents, completed documents, upload documents and view the documents.

Uploading Documents
 TL uploads the documents to the concerned Team members. This can be viewed
and downloaded by team members.

Track of project status

TL also can have a track of current and completed projects and status of team
members working under him by means of MAILING SYSTEM.

Team Member Login

TM is given permission to view the uploaded documents.

Status update

TM can report to his leader by means of updating the percentage of work

completed and also can interact with other employees effectively by means of Mailing
system.

Access to Documents

TM can view, download and delete the documents send to him by his leader
regarding the project.
 4.6 ER-DIAGRAM

Projects
Clients Allot TL
TM

PL Project details Uploads

Allots

Process TM
Update
Status
4.7 DATA DICTIONARY

EMP_PERDET

FIELD NAME DESCRIPTION

Name Employee name
Age Employee age
Gender Employee gender
Quail Employee qualification
Exp Employee experience
Plat Employee platform
Role Employee role in company
Userid Employee user ID
Pass Employee password
Mail Employee mailing address
Cont Employee phone number

LOGIN

FIELD NAME DESCRIPTION

Name Employee name
Userid Employee user ID
Pass Employee password
Role Employee role in company

PJDET

FIELD NAME DESCRIPTION

Pjcode Project code
Pjname Project name
Envi Environment
Ctname Client name
Stdate Start date of project
Tlcode Team leader code
Actstdate Actual start date
Actenddate Actual end date
Taskno Task number
Grptype Group type
membr_inv1 Member involved 1
membr_inv2 Member involved 2
membr_inv3 Member involved 3
membr_inv4 Member involved 4
membr_inv5 Member involved 5
Status Status

DOCUSTORED
FIELD NAME DESCRIPTION
Name Name
Filename File name

PLMAILS

FIELD NAME DESCRIPTION

Code Code
Afrom From
Pluserid Project leader user ID
Subject Subject
Message Message
Mdate Current Date
Mtime Current time

TLMAILS

FIELD NAME DESCRIPTION

Code Code
Afrom From
Tluserid Team leader user ID
Subject Subject
Message Message
Mdate Current Date
Mtime Current time
TMMAILS

FIELD NAME DESCRIPTION

Code Code
Afrom From
Tmuserid Team member user ID
Subject Subject
Message Message
Mdate Current Date
Mtime Current time

DATA FLOW DIAGRAM

A data flow diagram is a graphical representation that depicts information

flow and applied as data move from input to output. The data flow diagram is also known
as bubble chart, it is used to represent software at any level of abstraction; it provides a
mechanism for functional modeling as well as information flow modeling. Various Data
Flow Diagram symbols are:

Source or destination of data

Data Flow

Process that transforms data flow

 Data Store

LEVEL 0

Automation
Employee PL, TL, TM of process information Status Report
Process
.
Data Flow Diagram (DFD)

Help Menu

Login
Re Login Login
Screen
Invalid Password Valid Password

PL
Upload Document

TM Allocates Project
Checks the documents
TL

Add project
Project Status Table

Project Complete
Table
 2. SYSTEM DESCRIPTION

The system for tracking the project process, which involves three phases :-

 Project Initiation Phase

 Regular Mode
 Project Windup

The system helps the PL, TL and TM to view the status of the project and
helps in tracking information about the project and sharing messages by Mailing system.

Project Initiation Phase:

PL allocates project to the concerned Team Leader with Project Name,
code and Start date of the project.

At the initiation phase, each project must complete certain documents in a particular
duration. The PL will get notification about the incomplete documents whenever he
logins.
PL is given permission to add new projects, update/delete the existing
projects and release workers. PL is given permission to view the current status of the
documents, pending documents, completed documents, update the documents, and view
the document categories wise.
PL is given permission to view the completed and pending documents of
the projects.
Regular Phase: -
Regular Phase is other wise termed as execution stage of the project. Team
Members come in to picture. As per the documents completed in phase one, design,
coding and maintainability of the project starts. PL allocates modules to team members.

Team member completes the requirements with in the particular duration.

Role of Team Member: -
 Design
 Implementation
 Maintainability

Project Wind Up: -

The PL performs the process of Project wind up. PL releases the team
members from the project. Discussion about the project is done with other PL for future
enhancements. Standards are checked and project gets released to the Client.
PL reports to the TL about the completion of the project, so as to team
leaders concerned.

Modular Description

Login screen
An authenticated user having a valid Employee code can login. There are three
users namely Project Leader (PL) and Team Leader (TL) and Team Member (TM).

PL is given permission to add new projects, update/delete the existing projects.

PL is given permission to view the completed and pending documents of the
projects.

Project Leader Login

PL is given permission to add new projects, update/delete the existing projects.
Add New Projects
PL allocates projects with the following details
 Project Name.
 Project code.
 Client details.
 Leader in charge (TL).
 Start Date
 End Date

Update/Delete Projects
PL can update the details of the existing projects and also has the option for
deleting the project when completed.

Allot workers
PL can allot workers needed for the project by their codes according to the
availability and needs of the project.

View Current and Completed Projects

PL can view the status of project. He can keep a track of projects and its updates
from TL and TM.

Release Workers
PL can release workers from the project once it is finished ,so that the workers
can be assigned to the next project.

Team Leader Login

TL is given permission to view the current status of the documents, pending
documents, completed documents, upload documents and view the documents.
Uploading Documents
TL uploads the documents to the concerned Team members. This can be viewed
and downloaded by team members.

Track of project status

TL also can have a track of current and completed projects and status of team
members working under him by means of MAILING SYSTEM.

Team Member Login

TM is given permission to view the uploaded documents.

Status update

TM can report to his leader by means of updating the percentage of work

completed and also can interact with other employees effectively by means of Mailing
system.

Access to Documents

TM can view, download and delete the documents send to him by his leader
regarding the project.
MODULES DESCRIPTION
1.Prover
2.Witness
3.Location Proof Server
4.Certificate Authority
5.Verifier
6.Threat Model
Prover:
The node who needs to collect location proofs from its neighboring nodes. When
a location proof is needed at time t, the prover will broadcast a location proof request to
its neighboring nodes through Bluetooth. If no positive response is received, the prover
will generate a dummy location proof and submit it to the location proof server.
Witness:
Once a neighboring node agrees to provide location proof for the prover, this node
becomes a witness of the prover. The witness node will generate a location proof and
send it back to the prover.

Location proof server:

As our goal is not only to monitor real-time locations, but also to retrieve history
location proof information when needed, a location proof server is necessary for storing
the history records of the location proofs. It communicates directly with the prover nodes
who submit their location proofs. As the source identities of the location proofs are stored
as pseudonyms, the location proof server is untrusted in the sense that even though it is
compromised and monitored by attackers, it is impossible for the attacker to reveal the
real source of the location proof.
Certificate authority:
As commonly used in many networks, we consider an online CA which is run
byan independent trusted third party. Every mobile node registers with the CA and pre-
loads a set of public/private key pairs before entering the network. CA is the only party
who knows the mapping between the real identity and pseudonyms (public keys), and
works as a bridge between the verifier and the location proof server. It can retrieve
location proof from the server and forward it to the verifier.
Verifier:
A third-party user or an application that is authorized to verify a prover’s location
within a specific time period. The verifier usually has close relationship with the prover,
e.g., friends or colleagues, to be trusted enough to gain authorization.
Threat Model:
We assume that an adversary aims to track the location of a mobile node. An
adversary can have the same credential as a mobile node and is equipped to eavesdrop
communications. We assume that the adversary is internal, passive, and global. By
internal, we mean that the adversary is able to compromise or control individual mobile
device and then communicate with others to explore private information, or individual
devices may collude with each other to generate false proofs. We assume that the number
of colluders is small compared with that of valid devices. In the worst case, the adversary
could compromise the location proof server to get the stored location proof records.
However, it is not able to take control of the server to work as a colluder, since
once compromised, the attack will be detected promptly and the location proof server will
be replaced by a back-upserver. The same assumption applies to the CA.

PROCESS:
Online Route API
Examples are: Google/Bing route APIs. Such API computes the shortest route between
two points on a road network, based on live traffic. It has the latest road network G with
live travel time information.

Mobile User
Using a mobile device (smartphone), the user can acquire his current geo-location q and
then issue queries to a location-based server. In this paper, we consider range and KNN
queries based on live traffic.
Location-Based Service/Server
It provides mobile users with query services on a data set P, whose POIs (e.g.,
restaurants, cafes) are specific to the LBS’s application. The LBS may store a road
network G with edge weights as spatial distances, however G cannot provide live travel
times. In case P and G do not fit in main memory, the LBS may store P as an R-tree and
store the G as a disk-based adjacency list.

End Users
In this module, there are n numbers of users present. User should register to a particular
group before doing any operations. After registration successful he has to login by using
authorized user name and password. After logged in he will do some operations such as
View Route MAP, View My History, View My Transaction, and List Other Users.

Route-Saver Algorithm for Range Queries Steps

1) Refresh all Previous Settings.
2) Set Val = 0.
3) Run DijkstraAlgorithm to find shortest distance restaurants
4) Fetch all Value Details (Restaurant and Distance)
5) Find shortest distance based on LBS
6) Display all Shortest path based on LBS
 Query

Dijkstra Algorithm to find shortest distance

restaurants

Retrieve all values from Dbase like Restaurent, Distance, and

Location

Store all values

False Fetch all values

Exit from initialized
Variables

True

Display all the Values based on shortest

Distance & based on (Current Location),
uniformly
SYSTEM TESTING
Testing of Product:
System testing is the stage of implementation, which aimed at ensuring that
system works accurately and efficiently before the live operation commence. Testing is
the process of executing a program with the intent of finding an error. A good test case is
one that has a high probability of finding an error. A successful test is one that answers a
yet undiscovered error.

Testing is vital to the success of the system. System testing makes a logical
assumption that if all parts of the system are correct, the goal will be successfully
achieved. The candidate system is subject to variety of tests-on-line response, Volume
Street, recovery and security and usability test. A series of tests are performed before the
system is ready for the user acceptance testing. Any engineered product can be tested in
one of the following ways. Knowing the specified function that a product has been
designed to from, test can be conducted to demonstrate each function is fully operational.
Knowing the internal working of a product, tests can be conducted to ensure that “al
gears mesh”, that is the internal operation of the product performs according to the
specification and all internal components have been adequately exercised.

Unit Testing:

Unit testing is the testing of each module and the integration of the overall system
is done. Unit testing becomes verification efforts on the smallest unit of software design
in the module. This is also known as ‘module testing’. The modules of the system are
tested separately. This testing is carried out during the programming itself. In this
testing step, each model is found to be working satisfactorily as regard to the expected
output from the module. There are some validation checks for the fields. For example,
the validation check is done for verifying the data given by the user where both format
and validity of the data entered is included. It is very easy to find error and debug the
system.

Integration Testing:

Data can be lost across an interface, one module can have an adverse effect on
the other sub function, when combined, may not produce the desired major function.
Integrated testing is systematic testing that can be done with sample data. The need for
the integrated test is to find the overall system performance. There are two types of
integration testing. They are:

i) Top-down integration testing.

ii) Bottom-up integration testing.

White Box Testing:

White Box testing is a test case design method that uses the control structure of
the procedural design to drive cases. Using the white box testing methods, we derived
test cases that guarantee that all independent paths within a module have been exercised
at least once.

Black Box Testing:

 Black box testing is done to find incorrect or missing function

 Interface error
 Errors in external database access
 Performance errors
 Initialization and termination errors


In ‘functional testing’, is performed to validate an application conforms to its
specifications of correctly performs all its required functions. So this testing is also called
‘black box testing’. It tests the external behavior of the system. Here the engineered
product can be tested knowing the specified function that a product has been designed to
perform, tests can be conducted to demonstrate that each function is fully operational.

TESTING METHODOLOGIES

The following are the Testing Methodologies:

o Unit Testing.
o Integration Testing.
o User Acceptance Testing.
o Output Testing.
o Validation Testing.

Unit Testing

Unit testing focuses verification effort on the smallest unit of Software design that
is the module. Unit testing exercises specific paths in a module’s control structure to

ensure complete coverage and maximum error detection. This test focuses on each
module individually, ensuring that it functions properly as a unit. Hence, the naming is
Unit Testing.

During this testing, each module is tested individually and the module interfaces
are verified for the consistency with design specification. All important processing path
are tested for the expected results. All error handling paths are also tested.
Integration Testing

Integration testing addresses the issues associated with the dual problems of
verification and program construction. After the software has been integrated a set of
high order tests are conducted. The main objective in this testing process is to take unit
tested modules and builds a program structure that has been dictated by design.

The following are the types of Integration Testing:

1. Top Down Integration

This method is an incremental approach to the construction of program structure.

Modules are integrated by moving downward through the control hierarchy, beginning
with the main program module. The module subordinates to the main program module
are incorporated into the structure in either a depth first or breadth first manner.
In this method, the software is tested from main module and individual stubs are
replaced when the test proceeds downwards.

2. Bottom-up Integration

This method begins the construction and testing with the modules at the lowest
level in the program structure. Since the modules are integrated from the bottom up,
processing required for modules subordinate to a given level is always available and the
need for stubs is eliminated. The bottom up integration strategy may be implemented
with the following steps:

 The low-level modules are combined into clusters into clusters that
perform a specific Software sub-function.
 A driver (i.e.) the control program for testing is written to coordinate test
case input and output.
  The cluster is tested.
 Drivers are removed and clusters are combined moving upward in the
program structure

The bottom up approaches tests each module individually and then each module is
module is integrated with a main module and tested for functionality.

7.1.3 User Acceptance Testing

User Acceptance of a system is the key factor for the success of any system. The
system under consideration is tested for user acceptance by constantly keeping in touch
with the prospective system users at the time of developing and making changes
wherever required. The system developed provides a friendly user interface that can
easily be understood even by a person who is new to the system.

7.1.4 Output Testing

After performing the validation testing, the next step is output testing of the
proposed system, since no system could be useful if it does not produce the required
output in the specified format. Asking the users about the format required by them tests
the outputs generated or displayed by the system under consideration. Hence the output
format is considered in 2 ways – one is on screen and another in printed format.

7.1.5 Validation Checking

Validation checks are performed on the following fields.

Text Field:

The text field can contain only the number of characters lesser than or equal to its
size. The text fields are alphanumeric in some tables and alphabetic in other tables.
Incorrect entry always flashes and error message.
Numeric Field:

The numeric field can contain only numbers from 0 to 9. An entry of any
character flashes an error messages. The individual modules are checked for accuracy
and what it has to perform. Each module is subjected to test run along with sample data.
The individually tested modules are integrated into a single system. Testing involves
executing the real data information is used in the program the existence of any program
defect is inferred from the output. The testing should be planned so that all the
requirements are individually tested.

A successful test is one that gives out the defects for the inappropriate data and
produces and output revealing the errors in the system.

Preparation of Test Data

Taking various kinds of test data does the above testing. Preparation of test data
plays a vital role in the system testing. After preparing the test data the system under
study is tested using that test data. While testing the system by using test data errors are
again uncovered and corrected by using above testing steps and corrections are also noted
for future use.

Using Live Test Data:

Live test data are those that are actually extracted from organization files. After a
system is partially constructed, programmers or analysts often ask users to key in a set of
data from their normal activities. Then, the systems person uses this data as a way to
partially test the system. In other instances, programmers or analysts extract a set of live
data from the files and have them entered themselves.

It is difficult to obtain live data in sufficient amounts to conduct extensive testing.

And, although it is realistic data that will show how the system will perform for the
typical processing requirement, assuming that the live data entered are in fact typical,
such data generally will not test all combinations or formats that can enter the system.
This bias toward typical values then does not provide a true systems test and in fact
ignores the cases most likely to cause system failure.

Using Artificial Test Data:

Artificial test data are created solely for test purposes, since they can be generated
to test all combinations of formats and values. In other words, the artificial data, which
can quickly be prepared by a data generating utility program in the information systems
department, make possible the testing of all login and control paths through the program.

The most effective test programs use artificial test data generated by persons other
than those who wrote the programs. Often, an independent team of testers formulates a
testing plan, using the systems specifications.

The package “Virtual Private Network” has satisfied all the requirements
specified as per software requirement specification and was accepted.

7.2 USER TRAINING

 Whenever a new system is developed, user training is required to educate them
about the working of the system so that it can be put to efficient use by those for whom
the system has been primarily designed. For this purpose the normal working of the
project was demonstrated to the prospective users. Its working is easily understandable
and since the expected users are people who have good knowledge of computers, the use
of this system is very easy.

7.3 MAINTAINENCE

This covers a wide range of activities including correcting code and design errors.
To reduce the need for maintenance in the long run, we have more accurately defined the
user’s requirements during the process of system development. Depending on the
requirements, this system has been developed to satisfy the needs to the largest possible
extent. With development in technology, it may be possible to add many more features
based on the requirements in future. The coding and designing is simple and easy to
understand which will make maintenance easier.

TESTING STRATEGY :

A strategy for system testing integrates system test cases and design techniques
into a well planned series of steps that results in the successful construction of software.
The testing strategy must co-operate test planning, test case design, test execution, and
the resultant data collection and evaluation .A strategy for software testing must
accommodate low-level tests that are necessary to verify that a small source code
segment has been correctly implemented as well as high level tests that validate
major system functions against user requirements.

Software testing is a critical element of software quality assurance and represents the
ultimate review of specification design and coding. Testing represents an interesting
anomaly for the software. Thus, a series of testing are performed for the proposed
system before the system is ready for user acceptance testing.

SYSTEM TESTING:
Software once validated must be combined with other system elements (e.g.
Hardware, people, database). System testing verifies that all the elements are proper and
that overall system function performance is
achieved. It also tests to find discrepancies between the system and its original objective,
current specifications and system documentation.

UNIT TESTING:

In unit testing different are modules are tested against the specifications produced
during the design for the modules. Unit testing is essential for verification of the code
produced during the coding phase, and hence the goals to test the internal logic of the
modules. Using the detailed design description as a guide, important Conrail paths are
tested to uncover errors within the boundary of the modules. This testing is carried out
during the programming stage itself. In this type of testing step, each module was found
to be working satisfactorily as regards to the expected output from the module.
 In Due Course, latest technology advancements will be taken into consideration.
As part of technical build-up many components of the networking system will be generic
in nature so that future projects can either use or interact with this. The future holds a lot
to offer to the development and refinement of this project.
 Implementation:

The above said testing can be done virtually. In order to implement the
VB .Net for Knowledge Based Decision Support System. Implementation includes all
those activities that take place to convert from an old system to a new one.
Three aspects of implementation are:
1. Training Personnel.
2. Conversion.
3. Point Implementation Review.

TRAINING:
The quality of training received by the personnel involved with the
system in various capacities helps or hinders, and may even prevent, the successful
implementation of an information system. Both system operators and users need
training.

Training System Operators:

The training ensured that they were able to handle all possible
operations, both routine and extraordinary. Training also involved run procedures,
which involves working through the sequence of activities needed to use a new
system on an ongoing basis.

CONVERSION:

Conversion is the process of changing from an old system to a new

one. There are basically four conversion methods:
 Parallel Systems-offers greatest security.
 Direct Cutover- Presents the highest risk.
 Pilot Approach
 Phase-In method
The approach followed for implementing the system was the Pilot Approach.
The working version of the system was implemented in one regional office, so that
 the employees were aware that they were piloting a new system and that changes
could be made to improve the system.

The system would be installed throughout the organization using the phase in
methods. This approach had the advantage of providing a sound training ground
before full implementation.

Post Implementation Review:

After the system is implemented and conversion is complete, review of the

system is usually conducted by users and analysts alike. It is important to determine
whether the system is working, how it has been accepted and whether adjustments are
needed. The review is also important to gather information for the maintenance of the
system.

Review Questions: - The most fundamental concern during the post implementation
review is determining whether the system has met its objective, that is analysts want to
know whether the performance level of users has improved and if the system is producing
the result intended.
CONCLUSION & FUTURE SCOPE:

The “PROJECT TRACKING SYSTEM” has been developed to

override the problems prevailing in the practicing manual system. This software is
supported to eliminate and in some cases reduce the hardships faced by this existing
system. Moreover this system is designed for the particular need of the company to
carry out operations in a smooth and effective manner.

The application is reduced as much as possible to avoid errors while entering

the data. It also provides error message while entering invalid data. No formal
knowledge is needed for the user to use this system. Thus by this all it proves it is
user-friendly.

The main objectives of the system that have attained are

 The new system is user-friendly.

 The processing is very fast whereas the earlier system is too slow.
 Accurate and reliable output can be produced.
 Maintenance and updating of files are also made easy.
 It increases the efficiency and speed of generating report.

The developed “PROJECT TRACKING SYSTEM” is more Versatile, flexible

and updating can be done easily.

SCOPE FOR FUTURE DEVELOPMENT

 More advanced search engine can also be upgraded.
 This application has to be dynamically linked with existing intranet
application.
 ANNEXURE-A.

1. Abbreviations

 OOPS  Object Oriented Programming Concepts

 TCP/IP  Transmission Control Protocol/Internet Protocol

 SOAP  Simple Object Access Protocol

 CLR  Common Language Runtime

 CTS  Common Type System

 CLS  Common Language Specification

 O RDBMS  Ob je ct Re lat ion al D at ab ase M an age me nt Syst em

 MSIL  Microsoft Intermediate Language

 JIT  Just-In-Time

 MFC  Microsoft Foundation Classes

A.2 ONLINE RESOURCES

www.microsoft.com

www.msdn.com

www.roseindia.net

www.softlandindia.com
REFERENCES:

[1] 2011 Census TIGER/Line Shapefiles. (2011).[Online].Available: http://www.census.gov/cgi-

bin/geo/shapefiles2011/main

[2] 9th DIMACS Implementation Challenge on Shortest Paths. (2013). [Online]. Available:
http://www.dis.uniroma1.it/challenge9/data/tiger/

[3] Bing Data Suppliers. (2013). [Online]. Available: http://windows. microsoft.com/en-

HK/windows-live/about-bing-data-suppliers/

[4] Bing Maps API. (2013). [Online]. Available: http://www.

microsoft.com/maps/developers/web.aspx

[5] Bing Maps Licensing and Pricing Information. (2013). [Online]. Available:
http://www.microsoft.com/maps/product/licensing.aspx

[6] Google Directions & Bing Maps: Live Traffic Information. (2013). [Online]. Available:
http://support.google.com/maps/bin/answer.py?hl=en&answer=2549020&topic=1687356&http:/
/msdn.microsoft.com/en-us/library/aa907680.aspx

[7] Google Directions API. (2013). [Online]. Available:

https:// developers.google.com/maps/documentation/directions/

[8] Google Directions API Usage Limits. (2013). [Online]. Available:

https://developers.google.com/maps/faq#usagelimits

[9] Google Map Maker Data Download. (2013). [Online]. Available:

https://services.google.com/fb/forms/mapmakerdatadownload/

[10] OpenStreetMap. (2013). [Online]. Available: http://www.openstreetmap.org/

[11] Statistics of Usage. (2013). [Online]. Available: http://www.quantcast.com

[12] US Maps from Government. (2013). [Online]. Available: http://www.usgs.gov/pubprod/

[13] N. Bruno, S. Chaudhuri, and L. Gravano, “STHoles: A multidimensionalworkload-aware

histogram,” in Proc. ACM SIGMODInt. Conf. Manage. Data, 2001, pp. 211–222.

[14] E. P. F. Chan and Y. Yang, “Shortest path tree computation indynamic graphs,” IEEETrans.
Comput., vol. 58, no. 4, pp. 541–557,Apr. 2009.

[15] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein,

IntroductiontoAlgorithms.Cambridge, MA, USA: MIT Press, 2009.

[16] U. Demiryurek, F. B. Kashani, C. Shahabi, and A. Ranganathan,“Online computation

offastest path in time-dependent spatialnetworks,” in Proc. 12th Int. Symp. Adv.
SpatialTemporal Databases,2011, pp. 92–111.

[17] A. Dingle and T. Partl, “Web cache coherence,” Comput. Netw., vol. 28, pp. 907–920,
1996.