Plan Document
For The Pool Party
Participant Management System
1|Page
Contents
Overview ....................................................................................................................................................... 3
Objective ................................................................................................................................................... 3
Summary ................................................................................................................................................... 3
System Requirements ................................................................................................................................... 4
Development life cycle.................................................................................................................................. 4
Preliminary Design: ................................................................................................................................... 4
Iterative implementation: ......................................................................................................................... 5
User Oriented Design .................................................................................................................................... 7
Contextual Inquiry: ................................................................................................................................... 7
Interface Design: ....................................................................................................................................... 7
Database Design: ...................................................................................................................................... 8
HCI Testing: ............................................................................................................................................... 8
Iterative Implementation .............................................................................................................................. 9
Structure: .................................................................................................................................................. 9
Behavior: ................................................................................................................................................... 9
Functionality: .......................................................................................................................................... 10
Usability: ................................................................................................................................................. 10
Advanced Features: ................................................................................................................................ 10
Test Plan ...................................................................................................................................................... 11
Schedule ...................................................................................................................................................... 12
Spring 2009 Schedule:............................................................................................................................. 12
Intended Fall 2009 Schedule:.................................................................................................................. 13
Current Fall 2009 Schedule: .................................................................................................................... 13
Milestones:.............................................................................................................................................. 14
Deliverables: ........................................................................................................................................... 15
Spring 2009 deliverables ..................................................................................................................... 15
Fall 2009 deliverables ......................................................................................................................... 15
Risk Management ....................................................................................................................................... 16
Ethical Model .............................................................................................................................................. 17
2|Page
Overview
This document will layout our plan to complete the “Pool Party”
application. This document is maintained from the point of view of intention
rather than reality. The plan outlines contingencies, but if these contingencies are
or are not taken it will not be reflected in this document.
Pool Party will be a web-based application used for the Psychology
department’s Participation Pool. This application will primarily keep track of
students’ participation in different psychology experiments. Participation in
experiments is required of the Psychology 111 students.
Objective
The objective of the plan is to ensure the successful completion of the Pool
Party application and ensure the satisfaction of our client. Without such a plan
the completion of this project would be difficult or impossible. In the event that
the project is completed without a plan, its quality would be unsatisfactory. The
plan will provide a framework for success.
Summary
This plan has a number of different parts to it which will outline how the
system is intended to be developed. The system requirements section will consist
of information to describe what is needed to develop and run the system. The
development lifecycle section will cover the process used to design and
implement the system. The test plan section will detail the testing procedures
used to guarantee the overall quality of the system. The risk management section
will discuss what known risks will need to be taken into consideration. The ethical
concerns section will describe the ethical code we will use and any procedures
needed to ensure compliance. Our current schedule for implementation is also
outlined in its own section.
3|Page
System Requirements
Its target system is an apache web server with a Linux OS, but it should be
portable to any web server with PHP and a MySQL database. Users will connect to
the system via a web browser (supported browsers are Firefox, and Internet
Explorer). Though the system is intended to make extensive use of JavaScript, it
will fall back on non-JavaScript methods If the user chooses to disable JavaScript
in their browser.
Development life cycle
The lifecycle model we are planning to use is an agile method adapted from
spiral methodology and iterative development. Like the spiral model we start out
with a heavy analysis/requirements/design phase, and then we switch over to an
iterative and incremental implementation model. This section will briefly describe
the overview of the lifecycle which will be detailed in the following sections.
Preliminary Design:
The first phase of our development life cycle has two components,
functionality and usability. The functionality of the system is determined by
examining the existing system that is in place, other existing components our
system will interact with and by discussing what the client expects from the
system. The functionality is then organized into a user oriented set of functional
4|Page
requirements that the system will need to be able to perform. After the
requirements have been established design of the database will begin.
Once functionality has been determined our focus will shift from what the
system needs to do to how the users will interact with the system to accomplish
these tasks. User interface will be designed with input from the client and if
possible the users themselves. After our design is considered in a somewhat
cohesive form, human-computer interaction testing will be performed for each
component by the user groups who will be using it. Between each batch of testing
any problems found will be analyzed and potential solutions implemented into
the design until we are satisfied that our user groups will be able to accomplish
the tasks they need to.
Because this project is essentially a web front end for a database, and
largely written in PHP (a primarily imperative language) it will not have a typical
object model. Instead it will be divided into modules, with related functionality in
each module, with data being pulled from a database. Because virtually every
module will map directly to a single web page, it is easiest to consider the pages
themselves to be the modules. As a result there is no object diagram for this
project.
Iterative implementation:
Once our design is complete we will begin an iterative implementation
cycle. The key idea with our implementation cycle is to complete the project in
successive passes, making a more powerful and complete system at the end of
each pass. And making noncritical features easily dropped.
The first thing to happen at the beginning of a pass is to analyze the state of
the project after the completion of the previous implementation pass and
determine concrete goals for the new pass, making sure that the originally planed
objective are still feasible and adjusting them if they are not. Next any design
details for the upcoming pass that have not been worked out should be
completed and any new components that may be needed will be designed. After
5|Page
this the new components will be implemented, the person implementing a
component is expected to test their components as they develop them. Once all
components for a given implementation pass have been completed they will be
thoroughly tested, individually and then as a system. A complete system test of all
functionality that should be implemented will be performed at the end of an
implementation pass and the implementation will not be able to move to the next
pass until all defects from the previous pass have been corrected.
Following the final pass of implementation an extended testing period
should begin to find and resolve all defects and/or vulnerabilities. For more
details please refer to the testing section.
6|Page
User Oriented Design
The design of the Pool Party application is focused on the users. The final
design should be very intuitive and easy to follow. The design should mimic the
current workflow of the users but make the process as a whole much easier. The
participants will no longer need to travel to a physical location to sign up for
experiments. Participants will no longer need to keep track of their participation
form or get it stamped. The Experimenters will be able to create experiments
easily and keep track of the number of participants who are signed up with ease.
At the end of the semester the coordinator will be able to generate a report with
just a few clicks. Overall the Pool Party application will make the entire process
less cumbersome.
Contextual Inquiry:
In order to gain a greater understanding of the process needing to be
replicated we performed a contextual inquiry. The contextual inquiry was
performed in a few ways. Two of the group members completed PSYCH 111 in
previous semesters and went through the entire process as a participant. This
provided a good deal of knowledge about the procedure from the standpoint of a
participant. Also, the team went to Alumni Hall and looked at the board where
the experiments were posted to get a feel for how the experiments are organized,
and people signing up we observed. A series of interviews were also conducted
with our client to get more in depth information about what happens in the
background that a participant would not have much knowledge about. From this
we made a basic requirements document, and made some rough entity/object
models.
Interface Design:
Taking the information from the contextual inquiry into consideration we
created a basic interface using Microsoft PowerPoint. This was mainly used to
ensure that all required functionality was present while keeping a make shift GUI
that could easily be modified. The PowerPoint slides would later serve as our
paper prototype used in HCI testing, we chose to do this over a typical paper
7|Page
prototype because having the prototype in a shared electronic file allowed us to
collaborate more effectively. The final design of the interface is described in
greater depth in the design document.
Database Design:
The Contextual inquiry also served as the basis for our Database design.
We focused initially on identifying entity types, and found there to be only two
strong entity types, users and experiments. We then proceeded by identifying all
weak entity types that would allow for the different relationships we identified in
the contextual inquiry.
HCI Testing:
In order to ensure that our interface was easily usable we performed HCI
testing for all three types of user. Multiple sessions were performed for each user
type. The HCI testing for the participant was conducted using actual PSYCH 111
students. This enhanced the testing for the participant portion of the interface
because the test subjects were examples of someone who would actually be using
the system. For the experimenter and coordinator portions of HCI testing we
attempted to find actual experimenters to volunteer as test subjects, but we were
only able to test with one of them. Further HCI testing of the experimenter and
coordinator portions of the interface were performed by lower level computer
science students.
8|Page
Iterative Implementation
There are five implementation passes for this project, they are labeled as
structure, behavior, functionality, usability, and advanced. The end of each phase
should provide a set of deliverables and the system should be closer to the final
deliverable form. If time constraints make completion of all passes unfeasible,
then pass 5 and pass 4 may be dropped without risk of an incomplete system.
Structure:
The first pass of implementation will focus on establishing the structure of
the website, and the layout of the interfaces and the tables of the database. At
this point in the development all interface elements will be placed for all possible
users and usages of the interface. This phase will focus on the look and style, and
be done entirely with Smarty Templates. Though the database should be set up
by the end of this phase it will not have any connection to the interface. The final
result of this phase will be similar to a fully featured prototype, but will lack any
functionality.
Behavior:
The behavior pass will focus on having the layout of the web pages react
properly to a given set of data and on implementation of the database abstraction
layer. Though no connection to the actual database will be established in this
phase, dummy data will passed in via the URL (retrieved by $_GET) or embedded
in the page. Inter-page behaviors will be implemented at this time such as when a
session view page is passed criteria for filtering sessions the appropriate
notification text will be presented.
9|Page
Functionality:
The functionality pass will focus on the connection between the database
abstraction module and the interface. All dummy data will be redirected with an
SQL statement that should provide the appropriate data through the database
abstraction module. Data validation for all inputs should be implemented in this
pass. At the end of this pass the system should be technically capable of
performing all of its functionality; however this does not mean that it will be
highly useable to do so. Also at the end of this phase something akin to a
JavaScript free interface will be complete.
Usability:
The Usability phase will focus on using JavaScript to enhance the usability
of the system. Widgets will be added to pages that dynamically update values,
and help in workflow. Popup boxes with useful data can be used added. Hiding
unnecessary details from the user (such as primary key identifiers) will make the
system less confusing. At the end of this pass our system should be acceptably
useable as to be considered deliverable.
Advanced Features:
The final pass of implementation will focus on adding optional features to
further enhance usability. This will mostly be addition of AJAX features to existing
interfaces to make finding and using information faster and easier. Nothing in this
pass should be vital for the completion of the project, but should be considered
enhancements to make the system better than merely meeting the bare
minimum requirements.
10 | P a g e
Test Plan
There will be sufficient testing of every part of our system both hardware
and software. Since we plan to use an iterative approach, testing will be necessary
to create the best application for each iteration cycle.
Testing in the design phase has consisted of:
 Testing the database design – making sure our design could support the
use cases we came up with
 Testing the interface design – checking the ease of usability with paper
prototypes
 Testing the architecture design – making sure we had the tools to create
a successful application
Testing in the implementation phase will consist of, but not limited to, the
following:
 Testing the code – making sure the application works like it is supposed
to
 Testing the web server and database – making sure the servers can
handle a great number of people, i.e. 100, at a time
 Testing the security – making sure our website can handle various forms
of hacking techniques, i.e. SQL Injection attacks.
At the end of each implementation pass, unit testing will occur. Upon completion
of the final pass, testing of the entire system will take place to ensure every part
of the application can work with the other, before put into production.
11 | P a g e
Schedule
The schedule for the Pool Party application can be divided into two parts,
the Spring 2009 schedule and the Fall 2009 schedule. These two schedules are
detailed below. All passes are described even if they are not active in the current
schedule.
Spring 2009 Schedule:
Feb 2009
ID
Task Name
Start
Finish
Mar 2009
Apr 2009
Duration
1/25 2/1 2/8 2/15 2/22 3/1 3/8 3/15 3/22 3/29 4/5 4/12 4/19 4/26 5/3
1
Contextual Inquiry
1/20/2009
2/20/2009
32d
2
Requirements Specifiation
2/20/2009
2/28/2009
9d
3
Presentation Prep
2/10/2009
2/16/2009
7d
4
Project Definition Presentation
2/16/2009
2/16/2009
0d
5
Interface Design
2/20/2009
3/20/2009
29d
6
Database Design
3/5/2009
3/21/2009
17d
7
HCI testing
3/21/2009
4/26/2009
37d
8
Presentation Prep
3/24/2009
4/1/2009
9d
9
Design and Plan Presentation
4/1/2009
4/1/2009
0d
10
Presentation Prep
4/18/2009
4/22/2009
5d
11
Progress Report Presentation
4/22/2009
4/22/2009
0d
12
High Fidelity Prototype
4/26/2009
5/2/2009
7d
13
Doocumentation
4/21/2009
5/2/2009
12d
14
Presentation Preparation
4/26/2009
5/2/2009
7d
15
Final Presentation
5/5/2009
5/5/2009
0d
The Spring 2009 schedule starts on January 20th and runs until May 7th.
January 20th was when our contextual inquiry began. May 7th is the last possible
day in which our final presentation can be made. The Spring 2009 schedule deals
mostly with the design and plan of the Pool Party application including items such
as contextual inquiry, requirements specification, interface and database design,
HCI testing, prototype creation, presentation preparation and the delivering of
presentations.
12 | P a g e
Intended Fall 2009 Schedule:
Sep 2009
ID
Task Name
Start
Finish
Oct 2009
Nov 2009
Dec 2009
Duration
8/23
1
Structure
8/24/2009
8/31/2009
8d
2
Structure Design
8/24/2009
8/24/2009
1d
3
Structure Implementation
8/25/2009
8/30/2009
6d
4
Structure Testing
8/31/2009
8/31/2009
1d
5
Structure Completed
8/31/2009
8/31/2009
0d
6
Behavior
9/1/2009
9/21/2009
21d
7
Behavior Design
9/1/2009
9/4/2009
4d
8
Behavior Implementation
9/5/2009
9/17/2009
13d
9
4d
Behavior Testing
9/18/2009
9/21/2009
10
Behavior Completed
9/21/2009
9/21/2009
0d
11
Functionality
9/22/2009
10/12/2009
21d
12
Functionality Design
9/22/2009
9/24/2009
3d
13
Functionality Implementation
9/25/2009
10/7/2009
13d
14
Functionality Testing
10/8/2009
10/12/2009
5d
15
Functionality Completed
10/12/2009
10/12/2009
0d
16
Usability
10/13/2009
11/2/2009
21d
17
Usability Design
10/13/2009
10/15/2009
3d
18
Usability Implementation
10/16/2009
10/28/2009
13d
19
Usability Testing
10/29/2009
11/2/2009
5d
20
Usability Completed
11/2/2009
11/2/2009
0d
21
Advanced Features
11/3/2009
11/25/2009
23d
22
Advanced Feature Design
11/3/2009
11/6/2009
4d
23
Advanced Feature Implementation
11/7/2009
11/20/2009
14d
24
Advanced Feature Testing
11/21/2009
11/25/2009
5d
25
Advanced Features Completed
11/25/2009
11/25/2009
0d
26
Final Testing
11/26/2009
12/17/2009
22d
27
Project Completed
12/17/2009
12/17/2009
0d
8/30
9/6
8/23 8/30
9/6
9/13
9/20
9/27
10/4
10/11 10/18 10/25
11/1
9/20
9/27
10/4 10/11 10/18 10/25 11/1
11/8
11/15 11/22 11/29
12/6
Current Fall 2009 Schedule:
Sep 2009
ID
Task Name
Start
Finish
Oct 2009
Nov 2009
Dec 2009
Duration
1
Structure
8/24/2009
9/14/2009
2
Structure Design
8/24/2009
8/31/2009
8d
3
Structure Implementation
9/1/2009
9/13/2009
13d
4
Structure Testing
9/14/2009
9/14/2009
1d
5
Structure Completed
9/14/2009
9/14/2009
0d
6
Behavior
9/14/2009
10/12/2009
29d
7
Behavior Design
9/14/2009
9/17/2009
4d
8
Behavior Implementation
9/18/2009
9/30/2009
13d
12d
9/13
11/8 11/15 11/22 11/29 12/6 12/13
22d
9
Behavior Testing
10/1/2009
10/12/2009
10
Behavior Completed
10/5/2009
10/12/2009
8d
11
Functionality
10/12/2009
11/21/2009
41d
12
Functionality Design
10/12/2009
10/14/2009
3d
13
Functionality Implementation
10/16/2009
11/14/2009
30d
14
Functionality Testing
11/14/2009
11/19/2009
6d
15
Functionality Completed
11/2/2009
11/2/2009
0d
16
Usability
11/12/2009
11/18/2009
7d
17
Final Testing
11/20/2009
12/18/2009
29d
18
Project Completed
12/17/2009
12/18/2009
2d
13 | P a g e
The Fall 2009 schedule starts on August 23rd and runs until December 17th.
August 23rd is the first day of the fall semester. December 17th is the end of finals
week for the fall semester at which time the application must be completed. The
Fall 2009 schedule focuses on the implementation of the Pool Party application
including items such as the creation of a full template skeleton, full interface
layout and testing, PHP implementation, database implementation and
integration, JavaScript implementation (optional), AJAX implementation
(optional), and testing.
Milestones:
Milestones for the Pool Party application have been included in the above
schedules. Each milestone marks the completion of a specific phase of
development in which a working version of the application exists with added
functionality. The milestones for the Pool Party application include the following:
Basic Layout Completed: At this time, we will have all interfaces layed out with
Smarty Templates.
Interface Implementation Completed: At this point we will have added PHP to the
previous phase and will have tested the functionality of the interface.
Basic Functionality Completed: Upon completing this milestone we will have
implemented the database, performed database abstraction and integrated
the database into the application. The product will be in a deliverable state
after this.
Advanced Interface Completed (optional): At this milestone, we will have tested
the functionality of the application with the database implemented, added
common controls and basic Java Script to the application.
Project Completed: Once this milestone is reached all features will have been
implemented and final testing will be completed yielding a finished
product.
14 | P a g e
Deliverables:
The deliverables for the Pool Party application can be divided by semester
as well. The Spring 2009 deliverables and Fall 2009 deliverables are listed below.
Spring 2009 deliverables
A final interface design
A final database design
Responsibility assignments
A working accessible server
A partially working prototype
A completed plan document
A completed design document
Fall 2009 deliverables
First phase: A basic layout of the application
Second phase: A completed interface for the application
Third phase: Basic functionality
Fourth phase(optional): Advanced functionality
Final Testing: Final product
15 | P a g e
Risk Management
Risk Management is important when creating web-based applications
because of varies parts of the system. Some of the risks we may encounter for the
Pool Party applications are:
 Time constraints – schedule is designed to have a working product early
and able to eliminate less important features if necessary by dropping
later passes
 Complexities of Ajax architecture – interface should be useable without
the help of Ajax features and these features should be
compartmentalized into a disposable pass that can be dropped should
there not be sufficient time.
 Browser compatibility issues – browser will not need JavaScript to run
 Server setup: LAMP – getting the server set up before implementation
begins
 Redundant code between PHP and JavaScript – PHP code generates XML
and HTML results and JavaScript, when available, will interface with
those results
 Team members have unforeseen events – either send the team member
a note letting them know of what is needed of them or delegate the item
to different team members
 Unable to contact Client – bring the issue to upper management, this will
be the current instructor
16 | P a g e
Ethical Model
We will be employing the AITP code of ethics in this project. Our largest
ethical concern revolves around using pre-existing code made by persons outside
our group. There are several modules we have considered using. So to ensure
compliance with ethical standards with regards to use of other people’s code we
will do the following:




Site the module’s name
Site the module’s creator(s)
Provide a link to where we acquired it from
Demonstrate that the creator granted permission for its use. We will do this
by either hosting or linking to either a general statement that anyone could
use their code or their granting us permission explicitly.
 All of this will be documented in an ‘Acknowledgments’ page, which would
be accessible from the login screen, and from the root level of the help
documentation we generate.
17 | P a g e