OpenMRS-CS2-Activity

Group Participants

• Stewart Weiss
• Lori Postner

Planning an Initial HFOSS Learning Activity

This activity attempts to solve the following problem. Students in a typical CS2 course have little or no knowledge of FOSS or HFOSS and only elementary coding and software design ability, and do not necessarily know the programming languages in which various (H)FOSS projects are written, but we would like to give them a sufficiently interesting and productive experience in HFOSS so that they will be motivated to become more active in HFOSS projects as they progress in their careers. Our approach to solving this problem is to create a set of prerequisite learning modules followed by a well-defined activity in which they will do usability testing of the OpenMRS project. A challenge is how to accomplish this in existing CS courses with heavily loaded content objectives. Our preliminary planning is described in Test Usability (Activity).

Course targeted for the activity

Computer Science 2

Brief description of the activity

Homework assignment where the students will assess the interface usability and record problems, suggestions for improvement, etc. Pre-req:

• need an introductory understanding of FOSS
• limited knowledge of electronic medical records

Outcome:

• provide feedback on the usability of the interface to the community

Time you expect the HFOSS activity to take

e.g. # classes, # homework assignments, # lab activities, etc.

• several (e.g., 3 to 5) pre-activity reading assignments will be given
• 1 homework - usability tests (requiring about 30 minutes of class time to describe and to give problem and requisite knowledge)

Whether the activity will be completed in class or out of class

• out of class activity in college labs

Relationship of this activity to course goals/objectives

• improve technical communication skills (both oral and written)
• enhance the ability to assess software quality
• understand the relationship between user interface and underlying objects and methods
• understand the difficulty of designing and implementing robust user interfaces and methods of handling errors.

What students will submit upon completion of the activity

Students will submit:

• summary of bugs, enhancements, features (with the intent of contributing back to the community) by completing a template
• description of the process they used to test the interface in a separate prose document
• feedback on what they learned from completing the exercise by completing an evaluation questionnaire
• answers to specific questions about object oriented design related to the OpenMRS user interface

Approach for assessing the student work

• based upon the process and the ability to communicate the process in a written form
  • correctly completing a ticket template
  • correctly identifying bugs versus enhancements versus poor design etc
  • ability to express ideas clearly in their deliverable descriptions (described below)
• not based upon the number of bugs, enhancements, etc. found or suggested
• not a large percentage of the course grade (e.g., 5% of the grade)

Questions or concerns you have about implementing your activity

• what is going to motivate students to test thoroughly?
• how much domain knowledge is necessary?
• much time will it take to thoroughly test?

Support you will need to implement your activity

• documentation on the product
• community support to answer questions regarding the intended use - contact person if person
• departmental buy-in
• departmental system support to install and provide hardware resources for local installation of OpenMRS

Planning Stage 3 Activities

Meetings

The two members of our group will communicate by various electronic media to make progress on planning the activities and fleshing out all details. We have not worked out specific meeting times. The goal is to be prepared for the fall 2016 semester, so the goal is to continue discussions over the next two months.

Specific Tasks

Tasks include:

• defining the exact set of readings, all available online.
• defining the exact set of "field trips" to HFOSS websites in order to learn about how open source communities are organized
• deciding which version of OpenMRS to install on lab machines and having them installed
• testing the installations and trying to find some interesting bugs to use for later exercises.
• creating a spreadsheet template that students will use for documenting their "tickets".
• writing the tutorials to augment the CS2 curriculum related to FOSS.
• writing tutorials about approaches to usability testing
• deciding exactly which parts of the OpenMRS client code the students should test an explore
• writing the exercises
• writing the grading rubric

Resources

There are various resources on the web to facilitate our work. Some include

• http://teachingopensource.org/index.php/How_to_start_contributing_to_or_using_Open_Source_Software
• https://www.gnu.org/philosophy/free-sw.html
• https://opensource.org/faq
• https://icontribute.wordpress.com/how-to-contribute-to-open-source-without-coding/
• http://blog.smartbear.com/programming/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/

Other Notes

Prior related POSSE groups, if any: