Pair Programming

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

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

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

4. Project Progress • Created interview questions • Interviewed professors • 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

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

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

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

8. Interview #3 - Rich Pattis • Student pairing policies are relatively free • Repeated pairings are allowed • Students do not have to change partners for every project • If there is only 1 student left unpaired, allow the student to work alone or form a group of 3 • 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 •  Automatically computed average evaluation scores • Encouragement for students to perform pair programming • Worries • Privacy issues--will the system be too intrusive/paternalistic?

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

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

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

12. Prototype 1.0 Developed in Visual Studio using C#. Early version ran locally New version runs on the web: http://www.doanthangthien.org/inf132/

13. 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?

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

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

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

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

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

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

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

21. Timeline