Team Pavlov’s Dogs:
Mike Abegg – Team Leader
Chris Ballenger - Quality Assurance
Tom Scarborough – Designer
Alex Towell - Developer
1
Client
 Dr.
Michael G. Dudley
 Psychology Department
2
Psychology Department’s
Problem
Psych 111 students are required to
participate in six credit hours of
experiments designed by faculty and
students
 Posted in the basement of Alumni Hall
 Participants must sign up for an experiment
compatible with their schedule
 Bring a participant card to the experiment
 Experimenter stamps the card as proof of
participation
 Teachers evaluate cards for grade
3
Psychology Department’s
Problem

Cumbersome and insecure
 Lost participation cards
 Forged participation cards

Inconvenient
 Excess paperwork
 Must travel to Alumni Hall
 Grades generated manually
4
Psychology Department Needs
A system for managing the experiment
participation pool that is convenient,
secure, less error prone, and
automated.
 No lost/forged participation cards
 Nearly paperless
 No travel-time
 Automated report generation
5
Client Specified Requirements

Web-based
Rules for Using Participants from the SIUE Department of Psychology Participant Pool




Multi-user
Compatibility
 Existing system
 Existing workflow



Participant recruitment
o Researchers must use the provided recruitment forms.
o Forms will be posted only on the provided recruitment boards in the main hall of the psychology department.
o No undue inducement or enticements for participants are allowed on the recruitment forms. For example, phrases like
"Only 10 minutes" or "Easy Experiment!" are not allowed. This is to ensure voluntary participation.
o Include all the information that is asked for on the sign up sheets
o If you are not going to use one of the lines on the sign up sheet, cross it out rather than leave it blank
o The contact information you provide must be accurate. If you prefer not to give out your personal phone number or email address, you must make an effort to actively follow up on any messages or e-mails sent to whatever addresses you
provide.
o Sign up sheets and cover sheets must stay on the recruitment board until after the experiment has been run. If you need
to have access to them during your experiment, make a copy for yourself and leave the originals on the board.
Procedure for awarding credit
o The participant pool is a limited resource shared by many people; you may only award as much credit and run as many
participants as have been approved by the participant pool coordinator
o Experiment cards will be given to psychology 111 students the first week of class. These cards are used to keep track of
the credit they receive from participating in experiments. It is their responsibility to keep track of these cards.
o Once a participant has signed an informed consent form, you should stamp their card (using the stamp provided to you)
next to the row on the card for your experiment. Do not stamp a blank row. Participants should fill in the study
number, date, time, place, and # of credits before you stamp their card.
 We are required to provide credit to the participants before they actually participate in the experiment. This
prevents them from feeling pressured to stay in the experiment if they feel uncomfortable about it.
o Please sign your initials over the stamp.
o If a participant does not have his/her card, you may stamp anything that contains all the information provided above.
Additional (blank) cards can be obtained in the main Psychology Department office (AH-0118).
o If you find a lost card, hold onto it until your experiment is finished. If the lost card has not been claimed by that time,
please bring it to the participant pool coordinator's office (Dr. Rose, AH 0123).
o At the end of your experiment, you must return the stamp to the coordinator's office immediately, along with the
appropriate stamp return form. If you lose a stamp, you will have to replace it. Experiment stamps are a limited
resource that must be managed responsibly.
Missed Appointments by Participants
o Researchers are required to keep track of participants who do not show up or are late for their experiments. A penalty
equal to the amount of credit awarded by your experiment will be imposed for an unexcused absence
o An absence is excused if the participant canceled the experiment either by crossing out their name on the sheet or by
contacting the experimenter at least one hour in advance of the appointment. Thus, it is critical that participants be able
to contact experimenters at any time.
o A form has been provided for you to keep track of penalties. Once a week while your experiment is being run, fill out
this form and turn it in to the student working in the psychology resource center (AH 0302a). The resource center is
only open Monday thru Thursday. All penalties must be turned in not later than Thursday of each week. You may put
them in the Resource Center mailbox that is in AH-0118 if a resource center worker is not available.
Missed appointments by Experimenters
o If for any reason you must cancel an experimental session, it is your responsibility to personally contact each participant
who had signed up for your experiment as soon as possible (at least 24 hrs. in advance).
o If you cannot talk to a real person (not just leave a message) before the scheduled time of the experiment, you are
responsible for giving full credit to the participant if they actually show up for the experiment.
o You are responsible for arranging that credit be given to students who show up for appointments that you have
canceled; no one else will do this for you
o Collecting data from the participant pool is a privilege, not a right, and we must treat the participants with the same
amount of respect that we wish to receive from them
Other Responsibilities
o Appropriate appearance and conduct
o Adherence to all human participant guidelines and IRB regulations
o Thorough debriefing of participants
o Careful training and monitoring of all student assistants and others who will be coming in contact with human research
participants
Failure to adhere to the participant pool coordinator’s instructions for using the participant pool will result in loss of access to the pool for
a duration to be decided by the participant pool coordinator and the department chair.
6
Analysis Methods
Interviewed client
 Contextual inquiry

 Observed Psychology 111 students signing
up for experiments

Usability studies
 Paper prototypes

Feedback from client
7
Users

Participants
 Psych 111 students who participate in
experiments

Experimenters
 Psych students/faculty who design and
conduct experiments

Coordinators
 Administrator
 Generate participation reports
8
Basic Workflow Model
Experimenter
Participant
Experimenter
Experiment Experimenter posting an experiment
Posts
Selects
Experiment
Participant signing up for an experiment
Experimenter conducts an experiment
Conducts
Experiment
Participant
Participates
Coordinator
Evaluates
Experiments
Experiment
Experiment
Produces
Participant partakes in an experiment
Coordinator evaluating experiments
and produces a report
Report
9
Workflow
Experimenter Posting Experiment
Experimenter has experiment
ready to post
Experimenter fills out
experiment description and
schedule
Experimenter makes
experiment available for
participation
10
Workflow
Participant selecting experiment
Participant needs to find an
experiment to participate in
Find the list of experiments
Eliminate incompatible
experiments
Based on schedule and
experiment restrictions
Find an experiment they like
Sign up for an experiment
time slot
Student name,
class/section/instructor
11
Workflow
Experimenter conducting experiment
Participant participating in experiment
Experiment has been completed
Experimenter is prompted to indicate if the participant
participated
Experimenter marks if they did or did not
12
Workflow
Coordinator making report
All experiments have been conducted
Sort participants by class and section
For each participant
For each experiment they participated in
If they participated add the experiment’s value to
their participation score, if they did not subtract
Write out the participant’s score
Print out report
13
Consolidated Workflow Model
Users
Coordinator
Coordinator makes participation report
Report
Experiments
Experiment
Experimenter
Experiment
…
Experiment
Participant
Experiment
Participation
14
Requirements
Design Requirements

Built from analysis
All users need the ability to register with the system and submit and update user details (including
contact details). Participants and experimenters will be able to select their role at registration time but
only participants will be active without coordinator approval. Registration can be opened and closed by
the coordinator, when the registration is closed no new users may be registered unless done manually
by the coordinator.
Experimenters:


Thoroughly defined
Reciprocal feedback
with our client
Experimenters need the ability to post and conduct experiments. Some experimenters will conduct
experiments posted by other experimenters (for instance several experimenters conducting the same
experiment, it would be submitted only one time (for instance by a team leader) but conducted by more
than one experimenter). Some experimenters will only post experiments for others to conduct (like a
faculty member who will have several grad students run a particular experiment). By default the person
submitting an experiment would own it (be able to schedule time slots, be able to update details, ect...)
but they would have the ability to give other experimenters co-ownership. Experimenters will have the
ability to limit availability to a select list of students. Participants will only be able to sign up for an
experiment after the coordinator approves it. The number of credits it is worth is 1 credit per hour.
To conduct an experiment an experimenter will have to schedule one or more time blocks with it. As far
as our system is concerned the actual conducting of the experiment will simply be the experimenter
confirming that the participant showed up and did what was expected of them (or not) for the given
time block after the time block has expired (after it has started). An experimenter will also have the
option of denying retaking an experiment on the occasion that a participant fails to show up, but by
default they will be able to retake.
Experimenters should be able to cancel and update experiment details and time blocks (with restrictions
and notifications). On the event that an experimenter cancel’s an experiment all actively registered
participants will receive full credit from the experiment.
Participants:
Participants need to be able to set up and update a weekly availability schedule and search for
experiments that are compatible. From the resulting experiments a participant should be able to sign up
for time slots to participate in the experiment. Participants should be able to cancel their participation,
no later than 24 hours before hand, or requiring experimenter approval after that. As part of the
registration process a participant will need to fill out a demographic survey, experiments will be filtered
based on this. Some experiments may have additional requirements that the system cannot filter
automatically, in these situations the user should be alerted to them and required to read and confirm
15
Use Cases
Use Cases
Use Cases Applicable To All User Types
Returning user logs into the system


Made from design
Requirements
Helped to clarify functionality




Start at login page
In the returning users portion, fill in the username and password
Click ok
The main form appears
New user registers for the system and logs in for the first time







Start at login page
In the new users portion, click the “Register” button
Registration page opens
Fill in the fields listed under new user registration
Fill in the fields listed under demographic survey
Click the submit button
The main form appears
User recovering password






Start at login page
Click “Forgot Password?” link
Password recovery page opens
Fill in username and email
Click ok
Feedback page appears letting the user know that an email has been sent to them
User changes password

Used during usability testing








User logs in
From the main page click profile
My profile page appears
Click the “change password” link
Sub window opens
Fill in old password, new password and verify
Click the accept button
Sub window closes
Participant Use Cases

Helped in interface design
Participant changes their weekly availability schedule
16
Web-based Interface
17
Interface Overview
Main Navigation Menu
Displays main functionality
depending on user type
Main Interaction Pane
Displays the controls for the
functionality that the user has
selected from the main
navigation menu
Consistent Layout
18
Common Controls
Experiment
selection
Session selection
Date Selection
20
Page Relationship and
Functionality Diagram
• User will only have
access to
functionality that is
appropriate for their
user type
• Related functionality
is in the same page
P
E
C
Restrictions
Login
P/E
E/C
C/P
Add/Modify
Experiment
Registration
Main
C/E/P
C/P
P/E
P
Profile
Search
Experiments
Current
Experiments
Availability
Edit
E
Schedule
C/E
Confirmation/
Approval
C
Users
C
Semester
C
Admin
C
Stats
Monthly
Sessions
List Experiments
Profile
Add
E/C
Experiment
Delete
E/C
Experiment
Modify
E/C
Experiment
Search
Weekly
Schedule
Confirmation
Approve
Experimenter
Approve
C
Experiment
Approve Late
E
Cancelation
Confirm
E
Participation
C
Admin
Daily sessions
Detail view
Add
Session
Delete
E/C
Experiment
Modify
E/C
Experiment
Give
E/C
Ownership
E/C
Add session
E/C Add Session
Delete
Session
Adjust
E/C
Status
Cancel
P/E/C
Participatoin
E/C
P
Users
• Pages help define
modules
C
Add User
C
Delete User
E/C
Search
P/E/C
Modify
Profile
Sign up
Ownership
Semester
Close
Registraition
End
C
Semester
C
C
Make Report
21
Module Diagram
• Similar pages
grouped together
P
E
P/E
• Functionality that is
commonly needed
or used by other
modules is identified
C
E/C
Restrictions
C/P
Add/Modify
Experiment
Main
C/E/P
C/P
P/E
P
Search
Experiments
Current
Experiments
Availability
Edit
E
Schedule
C/E
Confirmation/
Approval
C
Users
C
Semester
C
Admin
C
Stats
Search
Confirmation
Approve
Experimenter
Approve
C
Experiment
Approve Late
E
Cancelation
Confirm
E
Participation
Add
E/C
Experiment
Delete
E/C
Experiment
Modify
E/C
Experiment
C
Daily sessions
Detail view
Add
Session
Delete
E/C
Experiment
Modify
E/C
Experiment
Give
E/C
Ownership
E/C
Confirmation
Management
Module
Admin
Add session
Delete
Session
Adjust
Status
Cancel
P/E/C
Participatoin
E/C
P
Users
Weekly
Schedule
Login
Login
Management
Module
Registration
E/C Add Session
E/C
Profile
Admin
Module
Monthly
Sessions
List Experiments
Profile
C
Add User
C
Delete User
E/C
Search
P/E/C
Modify
Profile
Sign up
Ownership
Experiment Management
Module
Session Management
Module
User Management Module
Semester
Close
Registraition
End
C
Semester
C
C
Make Report
Semester
Management
Module
Database
Abstraction
22
Database ERD
User
AvailabilityTimeslot

Two strong entity
types
ID {PK} : Integer
User ID {FK} : Integer
Start Time : Time
End Time : Time
Participation
ID {PK} : Integer
User ID {FK} : Integer
Session ID {FK} : Integer
Status : ParticipationStatus
has Participant
*
1
*
1
is
Participating
Participant
1
*
in
 User
 Experiment
Experimenter
Conducts
3 user types
 Participant
 Experimenter
 Coordinator
Many mapping
tables
*
1
1
PrerequisiteExperiments
ID {PK} : Integer
Experiment ID {FK} : Integer
Prerequisite{FK} : Integer
-PrimaryOwner
*
Owns
User Restriction
1
*
ID {PK} : Integer
User ID {FK} : Integer
Experiment ID {FK} : Integer
has
*
1
«enumeration»UserType
+Freshmen
+Softmore
+Junior
+Senior
+Participant
+Experimenter
+Coordinator
«enumeration»ParticipationStatus
«enumeration»DrinkingLevel
+None
+Moderate
+Heavy
+SignedUp
+Completed
+Missed
«enumeration»RestrictionMode
+Allow
+Deny
+None
1is restricted to
0..1
Restrictions
«enumeration»RelationshipType
+Single
+Dateing
+Married
+Divorced-Single
+Divorced-Dateing
experiment
ID {PK} : Integer
PrimaryOwner{FK} : Integer
Name : String
Credits : Rational
Abstract : String
Description : String
EthnicityRestrictionMode : RestrictionMode
UserRestrictionMode : RestrictionMode
1
«enumeration»EthnicityType
1
Experiment
1
Enumerations
+Caucasian
+Black, African American
+Hispanics
+Asian
+Pacific Islander
+Native American
other experiment
Requires
*
*
ID {PK} : Integer
Experiment ID {FK} : Integer
Experimenter ID {FK} : Integer
Start Time : Time
Location : String
MaxParticipents : Integer
ID {PK} : Integer
User ID {FK} : Integer
Experiment ID {FK} : Integer
1..*
*
«enumeration»StudentType

Owner
Experimenter
Participant
1
Session

ID {PK} : Integer
Student ID {UNIQUE} : String
User Name {UNIQUE} : String
User Type : UserType
First Name : String
Last Name : String
Email : String
Phone Number : String
Password : String
Class : String
Section : String
Gender : Character
DOB : Date
Ethnicity : EthnicityType
Student Status : StudentType
1
Smoker : Boolean
Drinker : DrinkingLevel
Relationship Status : RelationshipType
*
Ethnicity Restriction
ID {PK} : Integer
Experiment ID {FK} : Integer
Ethnicity : EthnicityType
ID {PK} : Integer
Experiment ID {FK} : Integer
Gender : Character
Smoker Status : Boolean
Drinker Status : DrinkingLevel
Relationship Status : RelationshipType
Minimum Age : Integer
Maximum Age : Integer
StudentStatus : StudentType
Other : String
Software Architecture
Presentation
Layer
DOM
Front-End
Client-Side
Scripting
events
Web Browser
Client-side
Server-side
AJAX path
Web Server
Back-End
Database
Server-Side
Scripting
Server-side scripting

Dynamic website - customize the server’s
response
 E.g., depending on user log-in type, client will get
different versions of Current Experiments page.

We could do this with client-side Javascript,
but…
 Would have to work around inconsistent Javascript
implementations
 Would make Javascript a requirement—deal
breaker
Security

Big security concerns
 Cross-site Scripting
 SQL Injection
 Never trust the end-user’s input
Deployment
Final system will be deployed as a
compressed file
 File will be decompressed into the web
root of a configured web server
 Setup script will be included in the
compressed file

 User will run the script
 System will be ready to go
27
The Plan
How we did it.
Tools
 Incremental Iterative Lifecycle Model
 Timeline and Milestones
 Responsibilities
 Risk management
 Test Plan
 Conflict Resolution

28
Tools

Programming Languages
 PHP, Javascript, SQL

Other Languages
 HTML/CSS, Smarty Templates

SVN
 version control system

PHPDoc
 documentation system
29
Lifecycle Model

Two phases
 Design
 Implementation

Design phase is user centered
 Contextual inquiry
 Thorough requirements
 Comprehensive interface design

Iterative Incremental Implementation
 Complete the implementation in a sequence of
passes
 Each pass has it’s own design and testing
periods
30
Design







Analyze the client’s problems and needs
Identify users
Identify existing work flow
Identify essential entities and functionality of the
users’ workflow
Design an interface capable of fulfilling the existing
work flow using these entities and functionality,
and a database capable of supporting the interface
Test the interface with subjects sampled from the
user base (if possible)
Establish modules that will encompass common
areas of functionality
31
Incremental Iterative Implementation
a.k.a. The “Drill”

A series of successive passes

Each pass builds upon the success of the
previous ones

Every pass allows for review and change in
the design if needed

Every pass has it’s own testing component

Provides good milestones

Reduces risk by making it easier to cut less
vital features and maintaining a working
codebase
32
Iterative Incremental Implementation

First Pass, ‘Structure’: HTML skeleton using Smarty
Templates and database implementation

Second Pass, ‘Behavior’: PHP implementation of basic
interfaces and database abstraction

Third Pass, ‘Functionality’: Database Integration

Fourth Pass, ‘Usability’: Common controls and basic
Javascript

Fifth Pass, ‘Advanced Features’: Ajax and other advanced
Features
`
33
Spring Schedule

What we did last semester
 Requirements Analysis
 Interface Design
 HCI Testing
 Database Design
 Planning
 Documentation
Feb 2009
ID
Task Name
Start
Finish
Duration
1
Requirements Gathering
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
1/25 2/1
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
2/8 2/15 2/22 3/1
Mar 2009
Apr 2009
3/8 3/15 3/22 3/29 4/5 4/12 4/19 4/26 5/3
Final Fall Schedule
Original
Sep 2009
ID
ID
1
2
3
4
Task Name
Task Name
Structure
1
Structure
2
Structure Design
3
Structure Implementation
4
Structure Testing
Structure Design
Structure Implementation
5 Structure Completed
6
Behavior
7
Behavior Design
Structure Testing
Start
Start
8/24/2009
8/24/2009
8/24/2009
8/31/2009
8/31/2009
1d
9/1/2009
8/31/2009
7
11
Functionality
Behavior Design
0d
13d
9/14/2009
21d
1d
9/1/2009
9/4/2009
4d
9/5/2009
0d
9/22/2009
10/12/2009
21d
9/24/2009
3d
13d
12d
9/14/2009
9/25/2009
10/1/2009
Functionality Completed
11
Functionality16
12
Usability Design
Functionality17Design
18
Usability
Usability Implementation
10/7/2009
10/12/2009
13d
5d
10/12/2009
10/12/2009
0d
10/12/2009
10/13/2009
11/21/2009
11/2/2009
21d
41d
10/13/2009
10/12/2009
10/15/2009
3d
3d
10/16/2009
10/28/2009
13d
10/5/2009
10/16/2009
14
Usability Completed
Functionality20Testing
11/2/2009
11/14/2009
15
18
5d
30d
0d
23d
11/3/2009
11/6/2009
4d
Advanced Feature Implementation
11/12/2009
11/7/2009
11/20/2009
11/18/2009
14d
7d
Advanced Feature Testing
11/21/2009
11/20/2009
29d
22
Advanced Feature Design
23
Final Testing24
11/14/2009
11/2/2009
11/2/2009
11/19/2009
Functionality Completed
17
10/14/2009
8d
11/25/2009
Advanced Features
Usability
10/29/2009
10/12/2009
11/3/2009
21
16
9/30/2009
4d
10/12/2009
Functionality Implementation
Usability Testing
9/17/2009
29d
10/8/2009
13
19
0d
4d
13 Functionality Implementation
Behavior Testing
15
13d
9/21/2009
9
Behavior Completed
9/14/2009
9/17/2009
9/21/2009
10/12/2009
9/18/2009
9/22/2009
10
9/14/2009
9/21/2009
Behavior Implementation
12 Functionality Design
Functionality Testing
8d
9/21/2009
8
14
22d
9/13/2009
8/31/2009
9/18/2009
9/14/2009
Behavior Completed
8/31/2009
11/2/2009
11/2/2009
11/25/2009
12/18/2009
5d
11/25/2009
11/25/2009
0d
Final Testing
11/26/2009
12/17/2009
22d
Project Completed
12/17/2009
12/17/2009
0d
25
Advanced Features Completed
26
27
Project Completed
12/17/2009
12/18/2009
9/6
9/13
9/20
9/27
8/23 8/30
9/1/2009
Behavior
Behavior Testing
8d
6d
6
9
8/31/2009
1d
9/14/2009
10
Duration
8/30/2009
Structure Completed
Behavior Implementation
Finish
8/23 8/30
8/24/2009
9/14/2009
8/24/2009
Oct 2009
6d
0d
2d
Nov 2009
Sep 2009
Duration
8/25/2009
5
8
Finish
Oct 2009
10/4 10/11 10/18 10/25 11/1
9/6
9/13
9/20
9/27
Dec 2009
Nov 2009
Dec 2009
11/8 11/15 11/22 11/29 12/6
10/4 10/11 10/18 10/25 11/1
11/8 11/15 11/22 11/29 12/6 12/13
Responsibilities
Mike
Alex
Tom
Chris
Database
Abstraction
Confirmations
User
Management
Administration
Session Mgmt.
Module
Experiment
Management
Module
Participation
Mgmt. Module
JavaScript
Database
Experiment
Searching /
Listing
Session Control
(PHP)
Login Module
Security
Backups
Semester
Management
Quality
Assurance
User Listing /
Searching
38
Risk Management
Risk
 Complexities of Ajax
architecture
(days to weeks)

Mitigation
Interface should be useable without Ajax
features

Do not require Javascript. Resolve CSS
issues in first phase

Try to get the server set up before the end
of Spring semester, or use an alternate
server
Time constraints

Create a working version ASAP then
provide iterative enhancements thereafter
Redundant code between PHP
and Javascript
(weeks)

PHP code generates XML and HTML
results (of SQL queries) and Javascript,
when available, will interface with those
results

Browser compatibility issues
(days to weeks)

Server setup: LAMP
(days)


39
Risk Management (cont.)
Risk
Mitigation

Team member have
unfortunate event
(weeks to month)

Responsibility be reassigned to
other team members

Data Lost
(hours to months)

Everyone has redundant copy
because of SVN

Requirement Changes
(weeks to months)

Have client look over the
requirements and sign a contract
40
Testing: Design Phase

Database design
 Checked that our design supports use cases
 Consulted with Dr. Ehlmann (database
expert)

User interface design
 Conducted paper prototype interviews for
participant user interface
 Also did this for experimenter and
coordinator user interfaces, but had
scheduling problems
41
Testing: Implementation Phase

Produce iterative builds that progressively
implement design

Each iteration will have a testing phase, especially
for milestones

A few milestone iterations:
 User interface layout: does interface correctly implement
design?
 Integrated database: application meets client’s
requirements; exhaustive test phase
 Finished implementation: ~3 weeks of dedicated testing of
entire system allotted at end
42
Closing thoughts
44
Final Product
Demo!
45
Questions?
46