Project Management Client

(Data Synchronization Tool)

Abstract
Data Synchronization Tool uses Google code gear to avail the facility of working
off line, and providing the data synchronization when connection get reestablish.

Data Synchronization Tool provides APIs for offline application access and data
storage. These APIs let developers build applications that can run even if the web
server can't be contacted, and allow those applications to store data offline using
SQL syntax.

While working online the single point of failure, a user may face getting
disconnected or not getting the net access. For this purpose Data Synchronization
Tool provide the data base schema on the client side by creating a local server and
worker pool which make your web applications more responsive by performing
resource-intensive operations asynchronously. The function of the Google gear in
this project is providing data synchronization with the server and hence the project
provides the facility of working offline.
Existing system

The existing system is the centralized system in which we have browser which access
project management tool that is remote server through a network.

Web browser sends an HTTP request for a file over internet to the web server.
The web server retrieves the requested file and sends the web pages to web browser.
The web browser sends multiple HTTP request to the web server.
As the web server receives the HTTP request for files, the server finds each file and sends
the files to the browser.
The web browser takes the original web page files, follows the instructions given by the
HTML tags in the file to combine the web page and the inserted file content into it web
document the browser display on screen.

In the centralized system we don’t have the facility to work offline.

So As such there is no existing system which provides the facility to work offline.

Problem definition:

In today’s day o day life’s mobility and time management is a biggest concern.

Mobility:-
People while traveling are bound to face problems like net disconnection or no access. For
instance a user while traveling might need to use an application where internet access
would be the prerequisite. at such a point if no net access is possible then the user will be
unable to carry out his work.

Time management:-
Eg:- in a office if the main server goes down then the application will not run further, for
instance a BPO can make use of this project for caching the customers contact information
on local server rather than accessing it every time from the remote server.

Data Synchronization Tool will help to solve these problems to a great extent.
Using the PMC user can use his web based application offline while on the move as the
local server will make the web application run offline. Applications that are more than just
static files have data that is typically stored on the server. For the application to be useful offline,
this data must be accessible locally. The Database module provides a relational database for
storing data.

In Data Synchronization Tool as the database is provided or cached on the client’s machine
(local server) so user need not access the remote server again and again for the same page
or the database. Hence time is saved and also cost is reduced.

t
Key contents
The first thing you need to run a web application offline is the ability to start it without an
Internet connection. This is the purpose of the Local Server module.
For a fast introduction to taking web content offline, work through the tutorial Enabling Static
Files to Work Offline using Gears. You will be introduced to the Local Server API and the
manifest file, the key components that cache your application's resources and make it available
offline.
Storing User's Data
Applications that are more than just static files have data that is typically stored on the server.
For the application to be useful offline, this data must be accessible locally. The Database
module provides a relational database for storing data. On the Architecture page you will find a
discussion of strategies for designing the local storage that your application needs.
When an offline application reconnects, you will need to synchronize any changes made in the
local database with the server. There are many different approaches to synchronizing data, and
there is no single perfect approach. The Architecture page describes some strategies for
synching.
An additional feature of the Google Gears database is Full-Text Search, providing a fast way to
search text within a database file. Read the details here.
Performance
When synchronizing large amounts of data, you may find that the database operations begin to
affect the responsiveness of the browser. The Worker Pool allows you to move your database
operations to the background to keep the browser responsive.
The Worker Pool is useful for any expensive operations that slow down the UI.

Google Gears: Enabling Offline Web Applications

Google Gears is an open source browser extension that lets developers create web
applications that can run offline.

Features
Google Gears consists of three modules that address the core challenges in making
web applications work offline.
Local Server
Cache and serve application resources (HTML, JavaScript, images, etc.)
locally
Database
Store data locally in a fully-searchable relational database
Worker Pool
Make your web applications more responsive by performing resource-
 intensive operations asynchronously
http://code.google.com/apis/gears/design.html

Proposed system

When you add a local data store to your application, you will have a single place
through which all data storage and retrieval requests pass.
 Figure: Data Layer
For example, if your AJAX application issues a JSON request directly to the server to
get all the accounts for a user, you might change this to instead ask an intermediate
object for all the accounts for the user. This object could then decide whether to retrieve
the data from the server, the local store, or some combination of both. Similarly, when
the application wants to update the user's accounts, the app does so by calling the
intermediate object. The intermediate object can then decide whether to write the data
locally, whether to send the data to the server and it can schedule synchronization.
You can think of this intermediate object as a data switch layer that implements the
same interface as the data layer. As a first step, you can make the data switch forward
all your calls to the data layer that interacts with the server. This step is useful since it is
the code path that is followed when Google Gears is not installed or if the user doesn't
want to enable the application to work offline. Note that a data switch is not strictly
necessary (for example Gear Pad does not have a data switch layer).

If the application is not structured with a data layer and adding a data layer is not an
option, it is still possible to isolate the data layer by intercepting all the calls to the web
server just before they are sent. For example, you could intercept a form submit (listen
to the submit event) and decide if the application should use the local data store or the
data on the server.
Implementing this approach involves finding all functions and methods that send
requests to the server, and rerouting them. The challenge is that this method requires a
lot of extra work, like parsing URLs, iterating over forms as well as generating the same
result as the server would. In practice you end up reimplementing large parts of the web
server on the client side. Regardless, this can be a viable option for existing AJAX
applications that can't be otherwise rearchitected.

Data Synchronization
No matter which connection and modality strategy you use, the data in the local
database will get out of sync with the server data. For example, local data and server
data get out of sync when:
• The user makes changes while offline
• Data is shared and can be changed by external parties
• Data comes from an external source, such as a feed
Resolving these differences so that the two stores are the same is called
"synchronization". There are many approaches to synchronization and none are perfect
for all situations. The solution you ultimately choose will likely be highly customized to
your particular application.
Below are some general synchronization strategies.

Manual Sync
The simplest solution to synchronization is what we call "manual sync". It's manual
because the user decides when to synchronize. It can be implemented simply by
uploading all the old local data to the server, and then downloading a fresh copy from
the server before going offline.
Manual sync requires that:
• The amount of data is small enough to download in a reasonable amount of time.
• The user explicitly indicates when he or she is going offline, typically via a button
in the user interface.
The problems with this method and with the offline mode it creates are:
• Users don't always know the state of their network connections. Internet
connections may die unexpectedly or be intermittent, for example, on a bus.
• Users may forget to synchronize before going offline.
Manual sync can be a good way to get started as it is relatively easy to implement.
However, it requires the user to have awareness and involvement in the synching
process.

Background Sync
In” background sync", the application continuously synchronizes the data between the
local data store and the server. This can be implemented by pinging the server every
once in a while or better yet, letting the server push or stream data to the client (this is
called Comet in the Ajax lingo).
The benefits of background synching are:
• Data is ready at all times, whenever the user chooses to go offline, or is
 accidentally disconnected.
• The performance is enhanced when using a slow Internet connection.
The downside is that the sync engine might consume resources or slow down the online
experience with its background processing (if it's not using the Worker Pool). Using
Worker Pool the cost of synching is minimized and no longer affects the user's
experience.

Figure: Background sync architecture

Analysis and design

Scrum techniques for Pmc

Scrum is an agile software development method for project management.

Characteristics of Scrum
• A product backlog of prioritized work to be done;
• Completion of a fixed set of backlog items in a series of short iterations or sprints;
• A brief daily meeting or scrum, at which progress is explained, upcoming work is
described and impediments are raised.
• A brief sprint planning session in which the backlog items for the sprint will be
defined.
• A brief sprint retrospective, at which all team members reflect about the past
sprint.
Scrum is facilitated by a Scrum Master, whose primary job is to remove impediments to
the ability of the team to deliver the sprint goal. The Scrum Master is not the leader of
the team (as they are self-organizing) but acts as a buffer between the team and any
distracting influences.
Scrum enables the creation of self-organizing teams by encouraging co-location of all
team members, and verbal communication across all team members and disciplines
that are involved in the project.
A key principle of Scrum is its recognition that fundamentally empirical challenges
cannot be addressed successfully in a traditional predictive or planned manner. As
such, Scrum adopts an empirical approach – accepting that the problem cannot be fully
understood or defined, focusing instead on maximizing the team's ability to deliver
quickly and respond to emerging requirements.
Sprint planning
Prior to every sprint the Product Owner, the Scrum Master and the Team decide what
the team will work on during the next sprint. The Product Owner maintains a prioritized
list of backlog items, the product backlog, that can be reprioritized during sprint
planning. The Team selects items from the top of the product backlog. They select only
as much work as they can commit to finishing. The Team then plans the architecture
and design of how the product backlog could be implemented. The product backlog
items are then broken down into tasks that become the sprint backlog.

Scrum Roles
Several roles are defined in Scrum; these are divided into two groups; pigs and
chickens, based on a joke about a pig and a chicken [1]:
A pig and a chicken are walking down a road. The Chicken looks at the pig and says
"Hey, why don't we open a restaurant?" The pig looks back at the chicken and says
"Good idea, what do you want to call it?" The chicken thinks about it and says "Why
don't we call it 'Ham and Eggs'?" "I don't think so" says the pig, "I'd be committed but
you'd only be involved"
So the pigs are committed to building software regularly and frequently, while everyone
else are chickens that are interested in the project but are really irrelevant because if it
fails they're not a pig, that is they weren't the ones that committed to doing it. The
needs, desires, ideas and influences of the chicken roles are taken into account, but not
in any way letting it affect or distort or get in the way of the actual Scrum project.
[edit] Pig Roles
Pigs are the ones committed to the project and the Scrum process; they are the ones
with their bacon on the line.
[edit] Product Owner
Represents the voice of the customer to ensure the Scrum Team works with the right
things from a business perspective.
[edit] Scrum Master (or Facilitator)
Ensure that the Scrum process is used as intended. The Scrum Master is the enforcer
of rules and sprints of practice. The master protects the scrum team from impediments
and distractions
[edit] Scrum Team
A small team of 5-9 people with cross-functional skills to do the actual work.
[edit] Chicken Roles
Chicken roles are not part of the actual Scrum process, but must be taken into account.
An important aspect of Agile approach is the practice of involving users, business and
stakeholders into part of the process. It is important for these people to be engaged and
provide feedback into the outputs for review and planning of each sprint.
[edit] Users
The software is being built for someone! Never forget that software that is not used, is
like a tree falling in the forest - was it ever written?
[edit] Stakeholders
The people that will enable the project, but not directly involved in the process. This
includes Executives.
[edit] Consulting Experts
These are people that provide expertise that is not required on every sprint. Often these
chickens will become a pig as part of the Scrum Team during some sprints.

Scrum terminology
Scrum Master: The person or persons in charge of the tracking and the daily updates
for the scrum (equivalent to a project manager). Sometimes referred to as a Scrum
Facilitator.
Scrum Team: A cross-functional team (developers, B.A.s, DBAs, and testers)
responsible for developing the product.
Product Owner: The person responsible for maintaining the Product Backlog via
continuous interaction with Clients and Stakeholders.
Story: A customer focused description of valued functionality.
Product Backlog: The stories to be completed.
Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of
stories that the team has committed to.
Burn Down Chart: Daily progress for a sprint over the sprint's length.
INTRODUCTION TO PROGRAMMING TOOLS
1. JAVA SCRIPT
JavaScript is a scripting language most often used for client-side web development. It
is a dynamic, weakly typed, prototype-based language with first-class functions.
Currently, "JavaScript" is an implementation of the ECMAScript standard.
Despite the name, JavaScript is essentially unrelated to the Java programming
language; though both have a common debt to C syntax. The language was renamed
from LiveScript in a co-marketing deal between Netscape and Sun in exchange for
Netscape bundling Sun's Java runtime with their browser, which was dominant at the
time. The key design principles within JavaScript are inherited from the Self
programming language.
"JavaScript" is a registered trademark of Sun Microsystems, Inc. It was used under
license for technology invented and implemented by Netscape Communications and
current entities such as the Mozilla Foundation.
The primary use of JavaScript is to write functions that are embedded in or included
from HTML pages and interact with the Document Object Model (DOM) of the page.
Some simple examples of this usage are:
• Opening or popping up a new window with programmatic control over the size,
position and 'look' of the new window (i.e. whether the menus, toolbars, etc. are visible).
• Validation of web form input values to make sure that they will be accepted
before they are submitted to the server.
• Changing images as the mouse cursor moves over them: This effect is often
used to draw the user's attention to important links displayed as graphical elements.
Because JavaScript runs on the client rather than the server, it can respond to user
actions quickly, making an application feel more responsive. Furthermore, JavaScript
code can detect user actions which HTML alone cannot, such as individual keystrokes.
2. MY SQL
MySQL is a multithreaded, multi-user SQL database management system (DBMS)[2]
which has, according to MySQL AB, more than 10 million installations.[3] The basic
program runs as a server providing multiuser access to a number of databases.
MySQL is owned and sponsored by a single for-profit firm, the Swedish company
MySQL AB, which holds the copyright to most of the codebase. This is similar to the
JBoss model. It is dissimilar to the Apache project, where the software is developed by
a public community and the copyright to the codebase is owned by its individual
authors.
MySQL is popular for web applications and acts as the database component of the
LAMP, MAMP, and WAMP platforms (Linux/Mac/Windows-Apache-MySQL-
PHP/Perl/Python), and for open-source bug tracking tools like Bugzilla. Its popularity for
use with web applications is closely tied to the popularity of PHP and Ruby on Rails,
which is often combined with MySQL. PHP and MySQL are essential components for
running popular content management systems such as WordPress and Drupal blogging
platforms. Wikipedia runs on MediaWiki software, which is written in PHP and uses a
MySQL database.

HARDWARE AND SOFTWARE REQUIREMENTS.

Software Requirements:

Platform: Any browser and any Os.

Hardware Requirements:

• Min. 2GB Hard Disk.

• 512 MB RAM.

• LAN and Internet connection.