Overall Project Organization

We use the first 9 weeks of the term for design and construction of projects. Week 10 is reserved for final presentations. A more complete schedule is available.

We will begin with all teams working on a one or two common projects that will be due roughly at the mid-term. That's a very tight schedule, and I will encourage you to scope it appropriately and approach it incrementally, to minimize the risk of not having something good to turn in at the deadline. Project scoping and risk control are core Software Engineering skills

You will have the option of switching to another project of your own choosing (with my approval) in the second half, but I encourage you to at least consider making a second iteration of the same project. Familiarity from the first iteration usually allows the team to work more effectively and focus on all parts of the process.

Project 1: Distributed Decision Making in a Mobile Context

For the first development, all student teams will develop a reduced-functionality prototype of the Distributed Decision Making system.

Background

In a mobile society, there are many situations in which a disturbed group of people (or systems) must work together to agree on a particular decision. Examples might include the members of a company board, members of a sales team, or members of a club. A key step in the decision making process is that of choosing the preferred option among a set of alternatives, typically by some kind of vote.

The goal of the Distributed Decision Making  (DDM) application is to support the process of collectively choosing among a set of alternatives (e.g., voting) event where group members may be travelling and connecting through different mobile technologies (e.g., email, SMS, web browsers).

Basic Requirements

The purpose of this project is to design and build a system that allows a pre-defined set of people to vote on a group decision using asynchronous technologies such as email, SMS, etc. It should allow users to set up vote among alternatives, inform users of the vote, record voter’s decisions, tally results, and inform voters of the outcome. To support different organizational structures and decision-making approaches, the system should allow the users to choose among a variety of voting algorithms. To support individual contexts (e.g., travel) the system should allow users to choose different connections and support the use of a variety of asynchronous communication technologies (e.g., email, web, SMS) for voting.

Voting Algorithms: the best approach for a group to choose among a set of alternatives can vary depending on the group structure and situation (e.g., how much time is needed). To support different decision making approaches, the system should support a set of the more common voting strategies including:

• Decision by majority
• Decision by negative majority
• Decision by ranking

Mobile Decisions: we assume that voters will be connecting to the system using any of a number of asynchronous technologies including email, SMS, and the web browsers. The system should be able to adapt to each voter’s current technology to inform users of the need to vote, record votes, and inform users of results.

Voting is necessarily only one part of the group decision-making process. A complete process necessarily includes activities such as identifying possible issues, discussion alternative solutions, choosing what to vote on, and so on. For the purposes of this exercise, we assume that these processes will not be supported by the DDM system.

Detailed Requirements

We identify three primary user roles for DDM applications:

• Moderator: Moderators use the system to set up and conduct votes on specific issues and monitor progress.
• Voters: use the system to understand what decisions need to be made, record their votes, and see the results.
• Support: people acting in a Support work to ensure that the system meets its security, performance, and other goals.

Moderator Scenarios

Users acting in the role of moderator initiate and control votes using the DMM system. It is assumed that the moderators will have determined exactly what needs to be voted one and the particular voting algorithm that should be used. The DMM system should support the following activities:

• Choose the voting algorithm to be used from a pre-defined set supported by the DDM system.
• Use the DDM interface to define the purpose of the vote and the set of alternatives to be voted on.
• Use the DDM interface to define constraints on the voting process:
• Start and end time
• Rules for ending the vote such as reaching a quorum or majority
• Rules for having the vote count such as a quorum (minimum number of votes)
• Choose how the system addresses incomplete or missing votes such as sending additional notices.
• Provide reports on the progress of a vote.
• Provide reports on the vote results.

Voter Scenarios

Voters use the system to get information on when a vote is needed, acknowledge participation, review the issues, make their votes, and retrieve results. The DMM system should support the following activities:

• Inform the voter of the need for a vote and the voting schedule using the voter’s preferred method of communication.
• Record and return an acknowledgement that the voter is available to vote.
• Inform the voter of the type of vote and the alternatives to be voted on.
• Record votes according to the voting algorithm.
• Provide feedback to the voter concerning incorrect or missing inputs.
• Allow the voter to their vote.
• Provide vote results on completion.

Implied Behavioral Requirements:

Additional functionality is needed to support the above scenarios including the following:

• The system provides staff interfaces appropriate to setting up each kind of vote.
• The system tracks voter’s preferred communication technology and configures communications with that user accordingly.
• The system tracks the progress of the voting process.
• The system applies appropriate algorithms to tally vote results.

Quality Requirements:

A useful voting system will need to meet several quality requirements to support secure, accurate, and timely voting.

• Security: the DMM system should provide basic security to ensure only group members can vote.
• Performance: provide methods for ensuring closure of the voting process (quorum, time, etc.)
• Reliability: the system should track results for anomalies such as lack of acknowledgements or too many votes.

Iteration 1 Prototype

Over the first half of the course, team members will collaborate to develop an initial prototype of the DDM system. The prototype should implement a subset of the DDM requirements but be expandable to include additional functionality.

L0: Minimum Useful Subset

All teams should complete a minimum useful subset as follows:

• Supports one voting strategy
• Supports one voting technology (e.g., email, web browser)
• Records and reports the results of a vote

L1: Version 1

• Support for at least two voting strategies. Includes support for choosing and moderating the different kinds of votes. Also includes voter interface for each.

L2: Version 1.1

• Support for choosing between at least two communication methods.

Resources

• You can find an overview of group decision making activities and voting algorithms here.

Server Setup

Systems has requested that we try setting up any

servers using existing accounts. This means that each team will need to choose one member to host the application in their "public.html" folder. This folder can be accessed over the web as "http://ix.cs.uoregon.edu/~[username]". In it, you can put web code, access MySQL, and so on.

For this to work properly in a team environment, you will want to set up a separate repository for code that is in progress. We can do this in the CIS 422 directory creating a group for each team. Then you would need have the owner copy the current code to the public.html directoy when needed. The best way to do this is, of course, by maintaining something like an SVN repository and downloading the code from the repository. That will allow full backups.