Upload
terence-barker
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
1
POOL PARTY PARTICIPATION MANAGEMENT
SYSTEM
Team Pavlov’s Dogs:Mike Abegg – Team Leader
Chris Ballenger - Quality Assurance
Tom Scarborough – Designer
Alex Towell - Developer
2
Client
Dr. Michael G. Dudley Psychology Department
3
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 scheduleBring a participant card to the experimentExperimenter stamps the card as proof of
participationTeachers evaluate cards for grade
6
Client Specified Requirements
Web-based
Multi-user
CompatibilityExisting systemExisting workflow
Rules for Using Participants from the SIUE Department of Psychology Participant Pool 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 e-
mail 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.
7
Analysis Methods
Interviewed client Contextual inquiry
Observed Psychology 111 students signing up for experiments
Usability studiesPaper prototypes
Feedback from client
8
Users
ParticipantsPsych 111 students who participate in
experiments Experimenters
Psych students/faculty who design and conduct experiments
CoordinatorsAdministratorGenerate participation reports
9
Participant
Experimenter Posts
Participates
Basic Workflow ModelExperiment
Participant Selects Experiment
Experimenter posting an experiment
Participant signing up for an experiment
Experimenter Conducts
Experiment
Coordinator Evaluates Experiments
Experiment
ExperimentCoordinator evaluating experiments and produces a report
Produces Report
Experimenter conducts an experiment
Participant partakes in an experiment
14
Users
Experiments
Experiment
…Experiment
Experiment
ReportCoordinator makes participation report
Experimenter posts experiment
Participant selects experiment
Experiment Participation
Experimenter performs
experiment
Coordinator
Experimenter
Participant
Consolidated Workflow Model
15
Requirements
Built from analysis
Thoroughly defined
Reciprocal feedback with our client
Design Requirements
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: 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
16
Use Cases
Made from design Requirements
Helped to clarify functionality
Used during usability testing
Helped in interface design
Use Cases
Use Cases Applicable To All User Types
Returning user logs into the system
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
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
Participant changes their weekly availability schedule
17
The PlanHow we did it.
Incremental Iterative Lifecycle Model Timeline and Milestones Responsibilities Risk management Test Plan Tools
18
Lifecycle Model Two phases
DesignImplementation
Design phase is user centeredContextual inquiryThorough requirementsComprehensive interface design
Iterative Incremental ImplementationComplete the implementation in a sequence of
passesEach pass has it’s own design and testing
periods
19
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
DONE
20
Incremental Iterative Implementationa.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
DONE
21
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
`
Spring Schedule What we did last semester
Requirements Analysis Interface Design HCI Testing
ID Task Name Start Finish DurationFeb 2009
3/222/1 4/122/15 4/53/293/152/8 2/221/25 3/1
6 17d3/21/20093/5/2009Database Design
7 37d4/26/20093/21/2009HCI testing
7d5/2/20094/26/2009Presentation Preparation
1 32d2/20/20091/20/2009Requirements Gathering
29d3/20/20092/20/2009Interface Design
0d2/16/20092/16/2009Project Definition Presentation
0d4/1/20094/1/2009Design and Plan Presentation
0d4/22/20094/22/2009Progress Report Presentation
9d4/1/20093/24/2009Presentation Prep
7d2/16/20092/10/2009Presentation Prep
2 9d2/28/20092/20/2009Requirements Specifiation
5d4/22/20094/18/2009Presentation Prep
Mar 2009 Apr 2009
5/34/193/8 4/26
0d5/5/20095/5/2009Final Presentation 15
4
3
5
11
9
8
10
12 7d5/2/20094/26/2009High Fidelity Prototype
13 12d5/2/20094/21/2009Doocumentation
14
Database Design Planning Documentation
Original Fall ScheduleID Task Name Start Finish Duration
Oct 2009 Dec 2009Nov 2009Sep 2009
10/4 10/25 11/15 12/69/27 11/810/188/30 11/2911/18/23 9/6 11/2210/119/13 9/20
1 8d8/31/20098/24/2009Structure
6 21d9/21/20099/1/2009Behavior
18 13d10/28/200910/16/2009Usability Implementation
19 5d11/2/200910/29/2009Usability Testing
23d11/25/200911/3/2009Advanced Features21
0d8/31/20098/31/2009Structure Completed5
8 13d9/17/20099/5/2009Behavior Implementation
13 13d10/7/20099/25/2009Functionality Implementation
27 0d12/17/200912/17/2009Project Completed
4 1d8/31/20098/31/2009Structure Testing
7 4d9/4/20099/1/2009Behavior Design
11 21d10/12/20099/22/2009Functionality
16 21d11/2/200910/13/2009Usability
26 22d12/17/200911/26/2009Final Testing
3 6d8/30/20098/25/2009Structure Implementation
2 1d8/24/20098/24/2009Structure Design
9 4d9/21/20099/18/2009Behavior Testing
12 3d9/24/20099/22/2009Functionality Design
14 5d10/12/200910/8/2009Functionality Testing
17 3d10/15/200910/13/2009Usability Design
23
24
22 4d11/6/200911/3/2009Advanced Feature Design
14d11/20/200911/7/2009Advanced Feature Implementation
5d11/25/200911/21/2009Advanced Feature Testing
10 0d9/21/20099/21/2009Behavior Completed
15 0d10/12/200910/12/2009Functionality Completed
20 0d11/2/200911/2/2009Usability Completed
25 0d11/25/200911/25/2009Advanced Features Completed
ID Task Name Start Finish DurationOct 2009 Dec 2009Nov 2009Sep 2009
10/4 10/25 12/1311/15 12/69/27 11/810/188/30 11/2911/18/23 9/6 11/2210/119/13 9/20
1 22d9/14/20098/24/2009Structure
6 29d10/12/20099/14/2009Behavior
0d9/14/20099/14/2009Structure Completed5
8 13d9/30/20099/18/2009Behavior Implementation
13 30d11/14/200910/16/2009Functionality Implementation
18 2d12/18/200912/17/2009Project Completed
4 1d9/14/20099/14/2009Structure Testing
7 4d9/17/20099/14/2009Behavior Design
11 41d11/21/200910/12/2009Functionality
16 7d11/18/200911/12/2009Usability
17 29d12/18/200911/20/2009Final Testing
3 13d9/13/20099/1/2009Structure Implementation
2 8d8/31/20098/24/2009Structure Design
9 12d10/12/200910/1/2009Behavior Testing
12 3d10/14/200910/12/2009Functionality Design
14 6d11/19/200911/14/2009Functionality Testing
10 8d10/12/200910/5/2009Behavior Completed
15 0d11/2/200911/2/2009Functionality Completed
Final Fall Schedule
26
Responsibilities
Database
Mike Tom ChrisAlex
JavaScript
Database Abstraction
Session Mgmt. Module
Experiment Searching /
Listing
Confirmations
Experiment Management
Module
User Management
Session Control (PHP)
Security
Administration
Backups
Semester Management
User Listing / Searching
Login ModuleQuality
Assurance
Participation Mgmt. Module
27
Risk Management Time constraints
Complexities of Ajax architecture (days to weeks)
Browser compatibility issues (days to weeks)
Server setup: LAMP(days)
Requirement Changes(weeks to months)
Iterative implementation lets us drop unneeded functionality
Interface should be useable without Ajax features. Ajax should be dropped if not enough time
Do not require Javascript. Resolve CSS issues in first phase
Contract specifies that client is responsible for providing the server (not our problem)
Have client look over the requirements and sign a contract
Risk Mitigation
29
Testing: Design Phase
Database designChecked that our design supports use casesConsulted 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
30
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 phaseFinished implementation: ~3 weeks of dedicated testing of
entire system allotted at end
32
Tools
Programming LanguagesPHP, Javascript, MySQL
Other LanguagesHTML/CSS, Smarty Templates
SVNversion control system
Doxygendocumentation system
Web Software Architecture
Web Server
Database
Web BrowserClient-Side Scripting
AJAX path
Presentation Layer
events
Server-Side Scripting
DOM
Client-side
Server-side
Front-End
Back-End
Server-side scripting
Dynamic website - customize the server’s responseE.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
implementationsWould make Javascript a requirement—deal
breaker
35
Web-based Interface
36
Interface Overview
Main Content Pane
Displays main functionality depending on user type
Displays the controls for the functionality that the user has selected from the main navigation menu
Main Navigation Menu
Consistent Layout
39
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
• Pages help define modules
Login
MainRegistration
Profile
Search
Weekly Schedule
Add/Modify Experiment
Restrictions
Monthly Sessions
Ownership
Add session
P E C
P/E E/C C/P
ProfileC / E / P
Current Experiments
P/E
Availability Edit
P
Confirmation/Approval
C / E
ScheduleE
UsersC
SemesterC
AdminC
StatsC
Search Experiments
C / P
List Experiments
E/CAdd
Experiment
E/CDelete
Experiment
E/CModify
Experiment
Confirmation
Approve Experimenter
C
Approve Experiment
C
Approve Late Cancelation
E
Confirm Participation
E
Detail view
E/CAdd
Session
E/CDelete
Experiment
E/CModify
Experiment
E/CGive
Ownership
SemesterClose
RegistraitionC
End Semester
C
Make ReportC
Users
C Add User
C Delete User
P/E/CModify Profile
E/C Search
Daily sessions
E/C Add Session
E/CDelete
Session
P Sign up
E/CAdjust Status
P/E/CCancel
Participatoin
Admin
40
Module Diagram
• Similar pages grouped together
• Functionality that is commonly needed or used by other modules is identified
Login
Main
Registration
Profile
Search
Weekly Schedule
Add/Modify Experiment
Restrictions
Monthly Sessions
Ownership
Add session
P E C
P/E E/C C/P
ProfileC / E / P
Current Experiments
P/E
Availability Edit
P
Confirmation/Approval
C / E
ScheduleE
UsersC
SemesterC
AdminC
StatsC
Search Experiments
C / P
List Experiments
E/CAdd
Experiment
E/CDelete
Experiment
E/CModify
Experiment
Confirmation
Approve Experimenter
C
Approve Experiment
C
Approve Late Cancelation
E
Confirm Participation
E
Detail view
E/CAdd
Session
E/CDelete
Experiment
E/CModify
Experiment
E/CGive
Ownership
SemesterClose
RegistraitionC
End Semester
C
Make ReportC
Users
C Add User
C Delete User
P/E/CModify Profile
E/C Search
Daily sessions
E/C Add Session
E/CDelete
Session
P Sign up
E/CAdjust Status
P/E/CCancel
Participatoin
User Management Module
Experiment Management Module
Session Management Module
Login Management
ModuleSemester
Management Module
Confirmation Management
Module
Admin Module
Database Abstraction
Admin
Database ERD
Security
Big security concernsCross-site ScriptingSQL InjectionNever trust the end-user’s input
43
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 fileUser will run the scriptSystem will be ready to go
44
Closing thoughts
45
Final Product
Demo!
46
Questions?