1. Team Pavlov’s Dogs: Mike Abegg – Team Leader Chris Ballenger - Quality Assurance Tom Scarborough – Designer Alex Towell - Developer 1

2. Client  Dr. Michael G. Dudley  Psychology Department 2

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 schedule Bring a participant card to the experiment Experimenter stamps the card as proof of participation Teachers evaluate cards for grade 3

4. 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

5. 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

6. Client Specified Requirements  Web-based  Multi-user  Compatibility Existing system Existing workflow 6

7. Analysis Methods  Interviewed client  Contextual inquiry Observed Psychology 111 students signing up for experiments  Usability studies Paper prototypes  Feedback from client 7

8. Users  Participants Psych 111 students who participate in experiments  Experimenters Psych students/faculty who design and conduct experiments  Coordinators Administrator Generate participation reports 8

9. Participant Experimenter Posts Participates Basic Workflow Model Experiment Participant Selects Experiment Experimenter posting an experiment Participant signing up for an experiment Experimenter Conducts Experiment Coordinator Evaluates Experiments Experiment Coordinator evaluating experiments and produces a report Produces Report Experimenter conducts an experiment Participant partakes in an experiment 9

10. Workflow Experimenter Posting Experiment Experimenter has experiment ready to post Experimenter fills out experiment description and schedule Experimenter makes experiment available for participation 10

11. Workflow Participant selecting experiment Based on schedule and experiment restrictions Participant needs to find an experiment to participate in Find the list of experiments Eliminate incompatible experiments Find an experiment they like Sign up for an experiment time slot Student name, class/section/instructor 11

12. 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

13. Workflow Coordinator making report All experiments have been conducted 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 Sort participants by class and section Print out report 13

14. Users Experiments Experiment … Report Coordinator makes participation report Experimenter posts experiment Participant selects experiment Experiment Participation Experimenter performs experiment Coordinator Experimenter Participant Consolidated Workflow Model 14

15. Requirements  Built from analysis  Thoroughly defined  Reciprocal feedback with our client 15

16. Use Cases  Made from design Requirements  Helped to clarify functionality  Used during usability testing  Helped in interface design 16

17. The Plan How we did it.  Incremental Iterative Lifecycle Model  Timeline and Milestones  Responsibilities  Risk management  Test Plan  Tools 17

18. 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 18

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 19

20. 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 20 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 21 `

22. Spring Schedule  What we did last semester Requirements Analysis Interface Design HCI Testing Database Design Planning Documentation

23. Spring Deliverables  Final interface design  Final database design  Roles and responsibilities  A working and accessible server*  Hi-fidelity prototype  Documentation: Plan document Design document

24. Original Fall Schedule Final Fall Schedule

25. Fall Deliverables  First Pass: Basic Layout  Second Pass: Inter-Page behavior  Third Pass: Basic Functionality  Fourth Pass: Enhanced Usability  Fifth Pass: Final Product

26. Responsibilities Database MikeTomChrisAlex 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 Module Quality Assurance 26 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 27 RiskMitigation

28. Risk Management (cont.)  Team member have unfortunate event (weeks to month)  Data Lost (hours to months)  Requirement Changes (weeks to months)  Responsibility be reassigned to other team members  Everyone has redundant copy because of SVN  Have client look over the requirements and sign a contract 28 MitigationRisk

29. 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 29

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 phase Finished implementation: ~3 weeks of dedicated testing of entire system allotted at end 30

31. Conflict Resolution  Invite entire team to discuss issue Engage in consensus building  Consult client when appropriate E.g., dispute is over a software requirement  Each team member has been assigned responsibilities… So each member makes the decisions that fall under his scope …But the rest of the team can over-ride him by unanimous vote 31

32. Tools  Programming Languages PHP, Javascript, MySQL  Other Languages HTML/CSS, Smarty Templates  SVN version control system  Doxygen documentation system 32

33. Web Software Architecture Front-End Back-End

34. 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

35. Web-based Interface 35

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 36

37. Major Interface Elements  User Profile  Experiment Search  Listing Experiments  Listing Users  Listing Sessions  Availability Schedule  Experiment Details  Confirmations/Approvals  Administrative Duties 37

38. Common Controls  Experiment selection  Session selection  Date Selection 38

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 39

40. Module Diagram Similar pages grouped together Functionality that is commonly needed or used by other modules is identified 40

41. Database ERD

42. Security  Big security concerns Cross-site Scripting SQL Injection Never 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 file User will run the script System will be ready to go 43

44. Closing thoughts 44

45. Final Product Demo! 45

46. Questions? 46