Pair Programming Sarah Lee Grace Uchida Masis Nguyen Michael Hart Jeramy Zapotosky

Problems to Address System-as-is o Pairs usually restricted to no repeats o Tough for professors to quickly check pairings, enforce rules, very repetitious, and tedious manual process o Tedious peer evaluations through the EEE survey tools

Methods to Solve Problems Interview o Gain insight from professors who use pair programming in their courses Prototype o Created based on interviews with professors Cognitive Walkthrough o Each team member will walk through the interface and perform all functionalities o Note any pros, cons, and problems with the interface Refine Prototype o Enhance the interface based on feedback from cognitive walkthrough Usability Study o Experiment with selected professors and students to test the interface

Project Progress Created interview questions Interviewed professors o Jacobson, Thornton, Pattis Sketched mockups on how the protoype should look Created first prototype as standard Windows desktop application Transferred the desktop application into a web prototype

Interview Questions Are students paired for the entire quarter? Or do students change partners for each project? How do you currently organize pairs in the class? How do you handle a class with an odd number of students? What kind of restrictions do you place on pairings? How do you handle grading and evaluation for the pairs? What kind of information or reporting would you be interested in seeing throughout the quarter?

Interview #1 - Alex Thornton Students are required to switch partners for each project. Students pick their own partners and whoever's left gets paired by the Professor or TA. If there is one student left, allows the student to work alone or make a team of 3. Uses Professor Kay's evaluation method but always assigns the partners the same score unless a trend of complaints is seen. Software would primarily take work off T/A's plate. Software could encourage students to pair up earlier rather than last minute. Emphasizes allowing people to self select rather than automatic pairing. Emphasizes that existing resources such as EEE should be used to gather student and class information.

Interview #2 - Norm Jacobson Students should pick their own partners in person o In-person contact is better than randomly selecting on a website since they will need to work closely with their partners o Solution: Students find partners in person and use the online interface to input/select the name of their partners Important: automatic notifications o When to evaluate o If the student does not have a partner Report o Statistics on numerical evaluations  percentage that thought their partners were good/helpful o How many students still need to be paired Evaluations o Short answer questions are more important

Interview #3 - Rich Pattis Student pairing policies are relatively free o Repeated pairings are allowed o Students do not have to change partners for every project o If there is only 1 student left unpaired, allow the student to work alone or form a group of 3 o Policies might change if there is a system to assist management Currently does not have peer evaluation enabled. Grades are the same for both partners in a pair Desired functionality o Automatically computed average evaluation scores o Encouragement for students to perform pair programming Worries o Privacy issues--will the system be too intrusive/paternalistic?

Insights Gained Professors favor customization because every professor is different Professors tend to allow exceptions in a class with an odd number of students (solo projects or groups of 3) Professors prefer students to find partners on their own (in person) instead of pairing students automatically Professors might want statistical information from student evaluations

Problems Encountered Unable to contact one professor for interviewing Conflicts in user interests o Example: Jacobson disagrees on system-to-be's function of having students be paired up through the online interface with an accept/deny request.

Decisions How to improve/finalize the prototype for testing Who will be selected for usability testing o Professors o Students Where the testing will take place (for students) o Testing for professors will take place in their office How to overall prepare for the final report/presentation/prototype

Prototype 1.0 Developed in Visual Studio using C#. Early version ran locally New version runs on the web:

Problems that CW Will Address Completeness: Are all the needed features there? Organization of Functionality: Does where each function is placed make the system easy to understand and use? Cognitive: Would users be familiar with any terminology and easily recognize features? Balance of Versatile & Simple: Does the system balance ability for customization of surveys while not making it overly complicated?

Cognitive Walkthrough Team will evaluate the prototype: Jeramy, Sarah and Grace do the evaluation. Tasks to be performed: o Add an existing class o Create a new class o Create a new class with specific pairing.

Task 1 Tester will navigate through the existing class list: 1.Add Computer Science: Operating Systems class 2.Set options to not allow solo projects, prevent repeats and setup evaluations. 3.Add a new Project titled "Memory Allocation." 4.Setup dates from: June 4th, 2010 to June 11th, Do not modify partnering deadline. 6.Have the System automatically pair partners.

Task 2 Tester will create a new class: 1.1. Add CS 113: Computer Game Development 2.Set options to allow solo projects, prevent repeats and setup evaluations. 3.Add a new Project titled "Solo Game Project." 4.Setup dates from: August 12th, 2010 to Sept 2nd, Set the partnering deadline to August 27th, Have the System automatically pair partners.

Task 3 Tester will create a new class: 1.1. Add Informatics 113:Requirements Analysis 2.Set options to not allow solo projects, allow repeats and setup evaluations. 3.Add a new Project titled "Req't Doc 1" 4.Setup dates from: December 4th, 2010 to Dec 8th, Set the partnering deadline to December 6th, Pair Bobby Abreu and Shawn Abner.

Task 4: Evaluations Directly following completion of task 3: User will set up a custom evaluation using any variety of scaled and open ended questions.

Task 5: Student's View Repeat Task 3 change #6: 6. Allow student pairing. 1.Sign in as Bobby Abreu 2.Pair up with Shawn Abner 3.Evaluate Shawn

Usability Testing A week prior to actual test will run a pilot test with a few pilot users just to tweak and modify the test. Testing will be performed on professors initially interviewed: Jacobson, Pattis, and Thornton. Testing will be lead by student who did interview. Additionally Jeramy will do notetaking in the background. Screen capture will be used while tests are being run. Tasks will be more refined versions of tasks 1-4 from the CW.

Timeline