Watchbill Project Management

  Home

Table of Contents

• 1. Project Management
  • 1.1. Work Statement
  • 1.2. Release Plan
  • 1.3. Project Status
• 2. Architecture
  • 2.1. Implementation-independent Models
  • 2.2. Alternatives Analysis
• 3. Testing
  • 3.1. Stragegy
  • 3.2. Test Plan
• 4. Documentation
  • 4.1. Developer' Guide
  • 4.2. Installation Guide
  • 4.3. Troubleshooting Guide
  • 4.4. Reference Manual
  • 4.5. User Manual
  • 4.6. Tutorial

1. Project Management

1.1. Work Statement

Political organizations operate on skilled and unskilled volunteer labor. This is stretched to the limit in the few weeks before an election. There is need to identify the roles which must be filled, when they must be filled, who can fill them, and who will fill them. And there is need to identify empty slots, or if someone is out sick, so there alternatives can be found.

In the military (e.g., Navy and Coast Guard) this is known as a "watchbill". In factories it may be known as a "shift roster".

Provide a "watchbill" or "shift roster" system for tracking who works what roles on what shifts.

1. Update, view, and report over a sliding window which starts 2 days prior to current date and extends 2 weeks forward from current date.

2. Main view is a grid with roles down left side, dates and shifts (e.g., 3 8-hr shifts per day), and a person's name in the cell.

3. Person's name in cell may be an alias or nickname, but must be hyperlinked with a database of data such as full name, phone, email,

4. "Canned" reports:
   1. Roster for specific shift
   2. Roster for a given person, over full two weeks.
   3. Lookahead (e.g., 2 day) for cells not filled

5. Ad hoc reports (read only) must be defined, saved, found, and run by end users.

6. Updates/edits:
   1. Copy previous week.
   2. Cell-by-cell change of person, by entering either alias or staff id. If alias is used, and there are duplicates, then provide selection list with staff full name.
   3. Batch load of roles.
   4. Batch load of date-shift-role-staff, from csv file.

7. Support these volumes:
   1. Approx 1000 people involved (i.e., may show up in a cell). All of them are authorized to see the views and reports.
   2. Approx 100 people are authorized to edit the cell contents. All of them are also authorized to create and run reports.
   3. Approx 10 people are authorized to run batch uploads and edits.

8. Architecture constraints:
   1. Functionality i scomposable, thus can run in batch mode. Thus model-view-controller internal architecture.
   2. Edits and Views primarily web-based.
   3. Platform: Linux preferred.
   4. Language: Python prefered. Java ok.
   5. DBMS: Postgresql preferred. Oracle, MySQL, or SQLite ok.
   6. Security: OpenSSL, HTTPS, X.509 certs for server and client

9. Schedule: Must be available for installation and use within 2 weeks for selection.

1.2. Release Plan

-

Release	ECD	Actual
1.0	2009-07-10	TBD

1.3. Project Status

• Design History

2. Architecture

2.1. Implementation-independent Models

See models

2.2. Alternatives Analysis

NOTE Remaining sections are primarily for cases where Alternatives Analysis resulted in "make".

3. Testing

3.1. Stragegy

Do test-driven development. That implies:

• A user requirement is not committed until an acceptance test is defined and agreed.
• Processes are composable, and can thus be run by other processes (e.g., run as batch or in testsuite).
• Prepare test harness for automated testing.
• Develop testsuite for unit-test and for use-case test.
• Run tests to success prior to code checkin.

Do code reviews at:

• Preliminary Design Review (PDR): Whenever modules and internal interfaces are being defined.
• Critical Design Review (CDR): After testsuite runs for all committed features, but prior to release.
• Periodic: Randomly selected, or high-risk section of code.

When code can pass automated tests it becomes a release candidate (rc). Make a branch for the release. Iterate beta tests in the branch, until customer is satisfied. As needed. tag a specific rc with rc, e.g., "R1_0rc2". When customer accepts beta test, tag with .

3.2. Test Plan

4. Documentation

4.1. Developer' Guide

How to ramp up new team member. Software architecture. Development life cycle (rqmts...testcase...test..code...retest).

4.2. Installation Guide

How to install and configure.

4.3. Troubleshooting Guide

Symptoms, root cause analysis, and solutions. Retain history of problems/resolutions. Typically starts empty and fills in over life of tool.

4.4. Reference Manual

Formal definition of APIs. Preferably auto-generated from code.

4.5. User Manual

Explanation of how to perform Use Cases.

4.6. Tutorial

Informal introduction for first-time users.