Project Plan

1.0 Introduction
1.1 Project Overview
The project is a website for The American Academy that connects with Mechanical
Turk and controls work
flow for contracted labor. For instance, TAA may want to contract for a task suc
h as creating a lesson plan.
People would then be able to bid on the task, and then the work flow would contr
ol the process for
submitting, approving, and paying for the work. We intend to deliver a fully fun
ctional website using Apache
/ MySQL / PHP along with Drupal.
1.2 Definitions, Acronyms, and Abbreviations
Mechanical Turk - An Amazon API that controls work flow and employee management.
Drupal - Drupal is an open source web content management system.
1.3 References
http://en.wikipedia.org/wiki/Scrum_(development)
www.drupal.org
https://www.mturk.com/mturk/
1.4 Overview of Document
This document will outline our organization, individual information and finally
our project plan.
2.0 Project Organization
2.1 Process Model
We will be using a version of â staged deliveryâ process model as described in the So
ftware Project Survival
Guide on pages 53-54. We will be separating this project into 3 phases. The firs
t phase will be about
researching Drupal and Mechanical Turk API. This phase will also include drawing
a relational model for the
objects required in e^2 (for example, what happens when a HIT occurs or complete
s). The second phase will
be the development including Drupal and the Mechanical Turk API. The third phase
will be the
demonstration preparation, for both the class and TAA.
Our milestones for each phase will include research, PHP + Mechanical Turk objec
t relations defined, and
Project Plan
Drupal initial setup for phase 1. For phase 2, Drupal module (our php implemente
d as a Drupal module), and
PHP + Mechanical turk API connection success. Finally our final demonstration ph
ase will be for preparing
our software for specific in class and TAA demonstrations.
2.2 Organizational Structure and Responsibilities
Mike:
Primary Responsibility: Team Lead, Documents, Project Management, Reports and Me
eting Agent &
Minutes
Secondary Responsibility: Mechanical Turk API
Dustin:
Primary Responsibility: Mechanical Turk API
Configuration of PHP with Amazonâ s Mechanical Turk
HIT implementation
Secondary Responsibility: Drupal, PHP module create
Matt:
Primary Responsibility: Drupal, PHP module creation
Objectify the requirements into PHP accessible through Drupal
Steve:
Primary Responsibility: Drupal, PHP module create
Secondary Responsibility: Team Lead, Documents
2.3 Organizational Boundaries and Interfaces
Customer: Gregg Rosan and the employees of TAA are our primary clients. We will
be consulting with
them often with our progress and direction with the creation of the e^2 website.
Course Instructor: Thomas Henderson is the secondary client. He is responsible f
or overseeing the project
direction and ensuring the project follows our time line for the phases.
Mentors: The TAA staff have been gracious enough to provide us with an SVN serve
r and other assistance
Project Plan
with Drupal.
2.4 Reviews, walkthroughs, inspections, and audits
2.4.1 Procedures for reviews, walkthroughs, inspections, and audits
Reviews: We will have weekly meetings to track progress of the members in their
assigned tasks. This will
include an examination of the project state as well as contributing to ideas to
an revisions to the project.
Walkthroughs: During weekly review sessions, members can request or perform spec
ific demonstrations of
their code.
Inspections/Audits: Technical review carried out every week on the code that has
been written.
2.4.2 Schedule of reviews, walkthroughs, inspections, and audits
All review procedures will be done at the weekly meetings. The Instructor has fu
ll access to any of our
documents / procedures.
3.0 Team-specific aspects
3.1 Management Objectives and Priorities
Because we are such a small team and our schedules are so different, we're going
to lack a strong top-tobottom
management structure. There will be a team lead responsible for making sure docu
ments are
submitted on time, and team members responsible for other areas, but no one with
final say on changes. For
this reason, it would be easy for members of the team to veer off into writing c
ode that isn't applicable to the
rest of the team. Of course, individual innovation and experimentation will be n
ecessary since none of us has
all the knowledge required to complete the project. So, to balance these concern
s we're going to impose a
requirement that no one team members can make changes to the actual project requ
irements or software
interfaces unilaterally. Proposed changes will be brought before the entire team
so that everyone stays on the
same page.
3.2 Team name
Timeless Solutions
We had a hard time coming up with a name, so we settled on "Timeless Solutions"
because it sounds
professional even though it's generic.
3.3 Possible Meeting Times
Project Plan
Our best meeting times are Tuesday and Thursday at 2:00 - 3:20 since everyone is
available. This is a good
time for TAA as well. We will be into pairs for pair programming with Matt and M
ike being one group, and
Dustin and Steve being another group. We may split into other groups as well dep
ending on the situation.
We'll also be on Google talk a lot so that we can communicate other times.
3.4 Team's Range of Skills and Experience
Mike Roylance is a skilled database developer and AJAX web services programmer.
He has worked for
Sorenson Communications for 1.5 years as a .Net QA specialist.
Dustin Swede has worked on a website which tracked the personnel of the Universi
ty of Utah microfabrication
lab.
Matthew Ord has a solid foundation in various programming experiences. His exper
tise includes web
programming in Java Servlets/JSPs, and graphics programming in OpenGL. He has ex
perience working as a
QA Test Analyst, giving him knowledge of the software development process in a p
rofessional environment.
Steve Blatnick spends much of his free time developing websites and has had two
internships working on
websites. He worked on a social networking project for fun to learn PHP.
4.0 Preliminary Sketch of Project Requirements
4.1 Overview of Functional Requirements
Basically, the project consists of these major sections:
1. Task Search - Search able Database of Tasks presented in a list.
2. "Shopping Cart" of Tasks - Interface to store a user's tasks.
3. Work flow - Allows tasks to have a work flow on a task by task basis.
4. Task Request Form - allows TAA to create tasks and work flows for those tasks
.
5. Task Suggestion Form - allows users to suggest possible tasks for TAA to revi
ew.
6. Task Acceptance Form - allows TAA to review suggestions and allows them to ge
t started converting the
task into a Task Request Form (see 4)
Project Plan
4.2 Overview of Data Requirements
The database will store all persistent information. TAA will be able to fill in
forms specifying the details of
different tasks, as well as a work flow that influences when new tasks are creat
ed from previous tasks and
phases of a single task.
Users will be able to search and store tasks to do later as well as their curren
t progress on tasks in progress.
They will also be able to view the status of tasks they have completed and are w
aiting for TAA's feedback.
4.3 General Constraints, Assumptions, Dependencies, Guidelines
Our project will be cross platform and cross browser, supporting the major brows
ers such as Internet
Explorer, Firefox, and Safari. Our team uses a variety of Operating Systems whic
h the project should work
on with some configuration: Linux, Windows, and OSX. It will also need to be fas
t enough to bring up
results from the database to the browser within a short time so that the user do
esn't think the link is broken
and to provide a good user experience. If any database access takes too long for
any reason, we should give
good feedback such as a progress bar or timeout page. Hopefully this won't be ne
cessary, but we need good
output in case of one.
Other constraints include making the content work with PHP 5, mySQL, and within
the Drupal framework.
Also, the company prefers we use Mechanical Turk or some other SDK to deal with
money exchanging.
The project will be online and persistent through databases except for searches,
which are lost when the
browser is closed. Carts are persistent so people can add to their cart and come
 back to it later.
4.4 User View of Product Use
The user will log into TAA's website, and depending on what type of account they
have, different types of
tasks will appear for proctors, teachers, etc.
The tasks will be arranged in a sortable list. The user will be provided with a
search bar and some other
parameters to specify what the person is looking for. The list will provide info
rmation such as the task name,
the first part of the task description, the range of money offered, deadlines, a
nd other details.
After clicking on a task in the search list, the user will be taken to further d
etails such as the complete task
description and its parts. Additionally, the type of task would be indicated, su
ch as whether the pay is
provided only for the best product submitted, or whether every valid attempt wou
ld be paid. Some tasks
would list if there is a limit to how many times it can be done by a person, or
how many are left of that task
to be completed. Here the person can add a task to a shopping cart type interfac
e. After the person selects the
link to "check out," they will be able to start a work flow for each task by cli
cking on them. The work flow
varies depending on the number of steps in the task.
Finishing a task brings the person to a page where they are alerted that their p
roject is submitted for review
and awaiting payment. After being paid or not paid for whatever reason, the user
will be sent an e-mail and
Project Plan
their profile summary page will show the project's status