Milestone II report: final specifications and detailed project plans

tenderlaΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 4 χρόνια και 4 μήνες)

118 εμφανίσεις

Milestone I
I report: final specifications and detailed project plans

CSE 4904

Tuesday, September 30, 2008

Dan Skorupski

Dan Vingo

1. Introduction

1.1. Background and motivation

We recognized the proliferation of the Internet

and discrepancy between the ease of which many
common activities are accomplishing, such as long distance communication and gathering
information, with the involvement in government and politics. Of course, there are websites for
politicians and a multit
ude of people with opinions, but there is little in watching what legislation is
being considering and politicians or parties who interest you are voting or pushing for against
important issues. We want to build a place where all this information is acces
sible and
comprehensible to the common user and the user can express his or her own opinion right alongside
the powers that be.

1.2. Team members and tasks

We intend to work on separate, mostly independent pieces of the project in parallel till near the en
d of
the project. The following tasks for the team members will be done roughly first to last.

Dan Vingo: Will work on building or integrated an existing user registration and profile
system, then on voting and result analysis, then on added security m
easures such as voting
verification, connection encryption, and fake account prevention.

Dan Skorupski: Will work on gathering legislation data from various sources and inserting it
into the database, then on textual and graphical display of data in the

database, and then on an
integrated discussion system for pieces of legislation.

After these tasks are complete, we will work together to put everything together and add navigation
through everything with an emphasis on user friendliness, then add polish
and looks and a mobile
version if time permits.

2. Overall Description

2.1. Product functions & perspective

The product will provide the following functions:

Retrieve and store legislation from government and other reliable data sources

Various, highly flexible methods of displaying collated and analyzed data in a
comprehensible and fluid format.

Including text lists for a timeline views (and possibly RSS feeds from these)

And spreadsheet format for mostly raw data

And bar charts
, pie charts, and the like

Various views and combinable filters for the advanced users as well as presets for the
common user.

User accounts with name and password, private & optional profile information containing
demographic data, various configura
tion options that may come up and favorite views/places.

Ability to vote integrated into views of data.

A moderated commenting section for various pieces of data.

Moderation functions for users privileged enough

Edit, delete, lock posts and thr

Ban/unban users

Product configuration functions for users privileged enough

Manage data sources, manually modify data

2.2. User classes and characteristics

There will be three classes of users, the common user for most accounts, and the
for those running the site. We assume that the common users are interested in the services provided
and are fairly proficient at using a web browser. The discussion feature will add the moderator user
class, who will have the ability to mo
derate discussion threads and ban users (from discussions only).
The administrators will have the powers of moderators plus high level site administration functions
such as modifying user accounts and legislation data.

2.3. Developing environment

We inten
d to have the product cross
platform to an extent, targeting UNIX
like operating systems
including Linux and OS X. The tools used to develop are going to be Django, a Python
based web
application framework, along with of course, a Python runtime. Our ini
tial development server will
be running Django using a sqlite database and running on a Nginx web server, all running on a basic
Debian install. We'll be using cron for periodic database updates and lxml, the Python bindings for
libxml2, to parse HTML and

XML files. Here, everything but Django and lxml is replaceable (for
example, Nginx for Apache and sqlite for MySQL) so we can switch to underlying systems that better
support high traffic if need be. The front
facing interface will be XHTML provided to
clients and
will utilize, to some degree, Javascript and the useful Prototype and libraries.

2.4. User environment

We expect the user to be using a standards
client, modern web browser (specifically, a "recent"
Firefox, WebKit
based (Safari
/Chrome) or IE8 browser is the baseline) and a decent Internet
connection and computer. If implemented, the browser requirements will be significantly lower for
the mobile version.

2.5. Assumptions and dependencies

As stated above, we will be depending on Django, lxml and standard Python libraries to do what we
need. Due to our initial server setup, we are assuming a low amount of traffic from knowledgeable
users (us and any beta testers). We may integrate existing

Django components, such as
registration or django
forum, so we don't reinvent the wheel.

3. External Interface Requirements

3.1. User interfaces

The user will interact with the product through a web browser pointed at a server serving
pliant XHTML.

3.2. Communication protocols and interfaces

The product will use HTTPS for communicating with clients.

4. System Features

4.1. Description and priority

In order highest priority to lowest:

Retrieval and storage of legislation

Importance: E
ssential. It is the basis for the whole system.

The system will, at regular intervals, retrieve data from government web sites in the form of
XML and HTML, parse that data, and insert new and updated data into the database for use
on the website.

ying collected data to the user

Importance: The system will be useless without being able to view the data.

Users will be able to search through the data using various methods and view results in
various formats. Criteria will include date ranges (such as

"All legislation voted on between 8/0/08
and 8/12/08"), tags (such as "All legislation involving privacy"), and status (such as "All legislation
that failed to pass the Senate"). Users then can view the data related to a piece of legislation, such as
a s
ummary of what it involves, current status, and current votes in the form of numbers and graphs.

User accounts

Importance: Needed to allow further features and provide security.

Users will be able to sign up for an account, provide an email address and
some demographic
information (which may be optional and will be private either way). The user will confirm his or her
email address and then be able to use the website to vote and manage their account.

Voting on legislation

Importance: This is primary
goal of the system

When a user is logged and viewing a piece of legislation, he or she will be able to vote on or
see their current vote.


Importance: Optional feature for fostering a community within the website.

This will provide a discussion thread for each piece of legislation for users to discuss it.

Mobile version

Importance: Optional feature for supporting the growing amount of smart phones and other
portable Internet devices.

This stripped down frontend w
ill provide for the lower performance and capabilities and
smaller screen resolution of mobile devices. The feature set may be reduced in this version.

4.2. Action plan

Here is a brief timeline of our development goals.

October 8th:

ski will done the backend script that parses data sources and updates the database.
Dan Vingo will have implemented a user and profile system.

October 15th:

Skorupski have the done the textual and graphical display of data. Dan Vingo will have
lemented voting and result analysis.

October 22nd:

Skorupski will have implemented basic site navigation and linking, security features. Dan
Vingo will have implemented a moderated comment system. This marks the completion of
all the modules.

ctober 29th:

testing of all implemented modules including bugfixing, bulletproofing, and underlying

November 5th:

Additional features if time permits, or additional development and testing of existing

November 12th:

ion of modules into a cohesive central website.

November 19th:

and bugfixing from here on out.

4.3. Functional requirements

The product should provide the described features in an easy to use and visually pleasing way.

5. Other Nonfunctional Requ

5.1. Security requirements

The application should provide security for the user's preferences and data from client to server
through an authenticated and encrypted connection and on the server end through safe, defensive
programming and using the
correct tools to prevent holes.

5.2. Software quality attributes

The software should be highly reliable and resistant to malformed input from users and from data

5.3. User documentation

The usage of the product should be self
explanatory and

user friendly enough so we will only be
providing a frequently asked questions page available on the website itself.

6. Glossary

This section defines some terms that may be unfamiliar to the less informed reader.

RSS feed:

A regularly updated, uniformly

formatted XML file hosted on the Internet that provides
style headlines and summaries to users.


A XML file with added HTML tags to provide the functionality of HTML with consistency
for users and developers alike.


Standard HTTP with add
ed authentication and encryption using using SSL (Secure Sockets
Layer) or TLS (Transport Layer Security).

compliant web browser:

A browser the strictly adheres to standards such as

7. Mockups

Here are several mockups of t
he website so you may better understand its functionality. These are
only meant to convey the raw, basic functionality and not the final looks or additional features.

7.1. The browse page

This page will be the front page for Direct Congress. Along the top you can see the menu bar present
on all pages allowing the user to navigate the site. Below is a list of legislation that matches either
the default filters and the filters specified b
y the user. Below that is a form allowing the user to
refine their search by modifying filters.

7.2. The view page

This is the page accessible by selecting a piece of legislation from t
he browse page. It displays the
name and description of the legislation being viewed along with a textual or graphical display of the
results of voting on the data. Below that is text representing if you've voted yes or no, or a form
allowing you to vote

if you haven't yet. And last but not least, there is a comment system for
discussing what you are currently viewing.

The profile page will include controls to allow you change things such as your password and
demographic information. The help will incl
ude a short list of frequently asked questions and
answers for the lost or curious user.