Proposal

See Index.

This document describes the project the Polaris team proposes for the Analysis group assignment.

The application will provide fault-tolerant, real-time, high-performance web-based voting using the IRV (Instant Runoff Voting) algorithm, ensuring results that are more representative of the entire population than the more common majority-wins algorithm.

In many elections, the winner is decided by a simple plurality; i.e., each voter votes for one candidate, and the candidate who receives the most votes wins. While this "winner takes all" approach may at first seem fair, further analysis can produce counterexamples.

A better way of conducting an election is to use IRV, which lets voters indicate their 1st choice, 2nd choice, 3rd choice, et cetera. After the voting is done, the candidate with the fewest number of first-choice votes is eliminated. The votes for this candidate are eliminated from the rankings; for example, voters who had the eliminated candidate as their first choice now have their second-choice candidate get their first-choice vote. Then, the next candidate with the fewest number of first-choice votes is eliminated, and votes for this candidate are similarily removed from the rankings.

This continues until there is only one candidate remaining, who is declared the winner.

The group is exploring several alternatives, but the primary configuration is:

• EJB using JBoss, PostgreSQL, and Windows 2000

As this is a group of five, some extra work is required. In order of the most amount of extra work being first, there are several options being considered:

• Add another implementation in .NET using Visuals Studio .NET 2004, Postgres, and Windows 2000
• Keep the single implementation but deploy it on two operating systems: Windows and Linux
• Keep the single implementation and provide security as a third quality attribute
• Keep the single implementation and add more application functionality: betting on the outcome of the election

The reason for not chosing one of these options up front is that the team is unsure of both the work required to do the first implementation, as well as the work required to do any of the extra options.

To avoid committing to too much work, the team will work on the first implementation and then decide, based on the progress, which of the extra options the team will pursue.

The first two options will allow interesting comparisons of the different configurations (e.g. EJB vs. NET or EJB on Windows vs. EJB on Linux) and will be favored. However, due to the potentially unrealistic amount of work required to implement the first two options, especially given the acadmic environment, the team may choose one of the last two options.

See the Requirements.