1. SARAH LEE GRACE UCHIDA MASIS NGUYEN MICHAEL HART JERAMY ZAPOTOSKY INF 132 Pair Programming

2. Pair Programming The System As Is o Pairs formed in discussion by students  Usually restricted to no repeats. o Tough for professors to quickly check pairings, enforces rules, very repetitious and tedious manual process. o Tedious pair evaluations through the EEE survey tools.

3. Software 1.0 System to Be: Two Main Parts 1.Forming Pairs 2.Keeping Track of Past Pairing Information Professor’s View / Students View o Pairing o Evaluation

4. Professor’s view Multiple Class / Discussion View Setup of Pairing Constraints Ability for Various Ways of Pairing Summary & History

5. Multiple Discussion & Class View Professors are likely to have: o Multiple Classes each quarter o Each class will have multiple labs

6. Setup of Pairing Constraints Professors need to restrict rules of pairing. For Example o Only 2 people per pair o No repeat partnerships and/or max repeats o Solo Projects allowed? o Start & End dates o No Change After Date Professors can override these rules for exception such as approving 3 way partnerships, new students, solo, etc.

7. Ability for Various Ways of Pairing Professor manually pairs Automatic Random Pairing – subject to rules Allow students to pair with each other

8. Summary & History Current Pairings – Who’s Paired? Unpaired? o Send “nagging” emails to those that are unpaired. Class summary How has person x been graded? How has person x graded others? Who hasn’t filled out Evaluations

9. Student’s View Pairing o Allow students to see other possible partners. o Sends a pairing request that can be accepted/ rejected o Apply for exceptions Evaluation o After End date partners will evaluate each other o Survey that has total of 100 pts based on five 20 pt questions o Open ended section for comments

10. HCI Problems Organization of Functionality o What’s screen that follows login? What info is displayed? o How are other functionalities grouped? o Do we have all the constraints on pairings? o Efficient? Navigability? Too many clicks/ menus Sociability of Pairing Program o Are students going to use this to find partners? How to load in Class Student Info How Summary information is presented and outputted for Professors. o What kind of Info and the different types of summaries Planning for the Future (next versions of system)

11. Methods to Solve HCI Problems Interview Prototype Cognitive Walkthrough Refine Prototype Usability Study

12. Interviews Interviewees: 2-4 ICS professors recommended by Professor Kay. Duration: 15-20 minutes Location: UCI campus. Initial interview with primary customer (Professor Kay) already completed. Interviews will only address one subgroup of users--the ICS professors who would use the software specifically for paired programming. Interviews will include questions on how this software might be scaled to other non-technical (another user subgroup) paired student scenarios for “version 2.0”.

13. Interview Questions Interviews will be semi-structured and recorded by note taking by one or more team member. Questions will include: o What is your current process for pairing students? o What restrictions do you impose on student pairings? o What is your current process for peer evaluations? o Would you be interested in using software that assists in student pairing and peer evaluation? o What kind of information / reporting would be useful to you as an instructor? o Other specific UI and functionality questions will be asked based on our initial interview with Professor Kay.

14. Prototype A prototype will be made based on the information gathered from conducted interviews. Prototype will be web based and use Flash. Functionality will be very limited but include predefined scenarios that simulate functionality

15. Cognitive Walkthrough Team members will create a document about common tasks that would be performed by users including: o Finding a student to pair with o Creating a 3 person group o Completing a peer evaluation o Viewing who has not been paired o Viewing students' pairing history throughout the quarter Each team member will access the prototype and attempt to perform each task Each member will note pros, cons, and problems with current prototype while trying to complete tasks Based on the notes, team will alter/enhance the current prototype and prepare it for a usability study

16. Usability Study Usability study will be performed on interviewees on the UCI campus The same task list used in the cognitive walkthrough will be reviewed, refined, and reused in the usability study Each participant should be able to finish the task list in 10-15 minutes Each experiment will be recorded via screen capture software Exit interview will be conducted (5 minutes) to get overall reaction to the refined prototype

17. Gantt Chart