(a central focus of the exercise) would not be an issue for deaf
users. Colorblind users might find it difficult to distinguish
between the red out of range numbers and the black in range
numbers. The issue of disabled users is mentioned in a later
reflection question. The simplicity of this version will make it
easier for beginning programmers to do the tasks required;
however, some faculty may want to modify this code in the initial version, or require students (especially students with more
skills than beginners) to modify the program during the exercise, to increase its utility for a broader user base. With some
changes, the ethical issues surrounding access to users of different abilities could become the focus of the exercise.
The speed of the simulated patient monitoring is governed
available for all three versions linked to in this paper set that
constant to 1000 milliseconds, or one second. All three scripts
have the same values for the constants that control how often
the vital signs are sampled, the initial values of the vital signs,
the random perturbations of each sign, and the ranges of each
sign. With the values specified in these example programs, the
alarms are tripped in a matter of minutes. (Since random numbers are involved, the behavior varies, but it usually takes more
than a minute but less than 4 minutes for at least one vital sign
to go out of range.)
The alarms are a central issue as the exercise plays out, and
it is crucial that students listen to the alarm often. Students
and the instructor may find it tedious waiting for the alarm to
sound during testing, and the instructor may suggest reducing
timeUnit to speed things up. However, timing for implementations of the second version (described below) should be examined carefully if timeUnit is changed. Version 2 requires a
pause of 30 seconds, and the Version 2 script given in this paper
assumes a one second timeUnit when implementing that pause.
Students should visit the website of Version 1 (or their own
version, or another student’s version, if those are available), and
execute the simulation multiple times. They should be instructed to record their reactions to the program. In our Version 1,
the program is reset by reloading the page into the browser.
No matter how the students get the Version 1, it should be
mentioned (though not necessarily emphasized) that the program is being designed for use with actual patients. (The first
sentence of the specification states this.) However, in its initial
version (and in all the versions in this exercise), a simulated,
virtual patient is being monitored. If students ask about this, the
instructor should suggest that after the software is developed
and tested with the simulated patient, the plan is to use it with
real patients with a minimum of changes.
After examining the execution of the system multiple times,
students will then discuss (either in small groups, or as a class),
the following questions:
1. What was your overall impression of the program?
2. Did you record any failures, or strange behaviors, of the
program you executed?
3. When you executed the program, did the visual and
auditory alarms catch your attention?
4. What did you do after the alarms were activated?
5. Do you have any suggestions for improving a new version?
The instructor should not try to lead this discussion in any
specific direction. However, the instructor should list the suggestions for improvements where all the students can see those
suggestions. It is particularly helpful if at least one student suggestion includes some limits or controls that will allow the user
to turn off the alarms, and/or reset the vital signs readouts. Our
Version 1 includes a loud alarm bell that we expect to be annoying, and we anticipate that at least one student will want to
be able to turn it off somehow during testing. If no student lists
such a change for the new version, the instructor should add to
the list the following change: “Mute the audible alarm after a
A NEW VERSION OF THE PATIENT
During the second phase, the instructor gives the students one
Students will then discuss the following questions, in order,
or more changes to make in the program. Depending on the
time available, and on the students’ development skills, the in-
structor may decide to include several changes; the exercise
is improved if there are multiple changes specified. However,
whether there is one change or several changes specified, this
specific change should be included:
“Modify the program so that the alarm sound ceases after 30
seconds. The visual alarm should continue.”
After students have made this (and perhaps other) changes,
they should test their modified programs, and the programs of
others. Students should record the results of their testing, and
record any impressions they have of the revised functionality.
A second version of this program that is like Version 1 (above),
but includes the change that turns off the alarm sound after 30
seconds (our Version 2) is available at [ 12].
as a class. We do not expect the class discussion to finish this
Figure 2: A screenshot of the Version 1 program after two vital signs
have gone out of range.