Pedagogical Pattern #14
Peer Review and Corrective Maintenance (PRCM) Pattern
(Version 1.0)
Fernando Brito e Abreu
INESC and Lisbon Technical University (ISEG)
Portugal
fba@tutankhamon.inesc.pt
Intent:
Expose students to:
- software quality techniques
- group dynamics situations
- software maintenance problems
Motivation:
Software developers often have to do maintenance (either
corrective, adaptive or evolutive) on products or parts of
products that they did not produce. This is enforced with OO
technology because of the emphasis on reuse where you tend to
adapt and extend existing components.
"Traditional" programming courses, however, often do not
expose students to maintenance tasks. Systems produced by
students are evaluated "as delivered" and as so graded. Even
if they get back to students for correction, they will still
work on their own products, not anybody else's.
On the other hand, students when faced with group assignments
are tempted to cluster around the same colleagues over and
over again, the ones with whom they feel better because they
share common interests and views and with whom they do not
conflict. Besides not mimicking the real world, this situation
reduces the knowledge and insight sharing with members of
other groups.
Last but not the least, verification and validation techniques
used by students are often restricted to testing
(mostly black-box). Software revisions in general, and software inspection
techniques in particular, although recognized as very
effective and efficient (due to their possible early adoption
on the life-cycle) are seldom taught in OO software
development courses. Enforcement of standardization rules and
conventions is also often forgotten in academic assignments,
although being of capital importance in industrial settings.
Applicability:
This pattern can be used whenever there are team assignments
to produce any software deliverable such as a requirements or
design specification, source code, test battery, executable
system, installation or user manuals.
Structure:
Initial work:
Students are grouped in "n" teams (T1, T2, ..., Tn). Teams
ranging from 2 to 4 elements are usually appropriate. All
teams are given similar effort assignments but preferably
distinct in scope. All assignments have well defined (as
formally as possible) requirements and correspond to the
production of a given software deliverable. These requirements
will be used for deliverable validation. The rules and
conventions for producing the required deliverable are also
formally defined and will be used for deliverable
verification.
After a stated period of time each team Ti must have produced
a prototype Pi of the desired deliverable.
Peer Review:
The peer review session occurs for all groups at the same time
in a special lab class during regular class hours. Each
prototype Pi is reviewed by a team composed of one chosen (by
the team mates) element of team Ti plus all minus one elements
of team Ti+1 (or by T1 for Pn).
By other words, each team is like a node in a ring structure
where all prototypes produced are shifted one position for
review (and maintenance as we will see further on). One
student representing the original producer is present in the
review session, to contribute with his (her) special insight
derived from having been involved in its conception.
The Fagan model of software inspections, or one of its
variants, is a good choice for conducting the review session.
In this formal approach to reviewing, a copy of the
deliverable to be reviewed is distributed to each participant
beforehand to allow an independent verification and validation
process.
The meeting objective is identifying, classifying and
registering defects, not proposing solutions for them. Each
participant has a specific role (moderator, presenter,
recorder, producer) which can be accumulated for review teams
with less than 4 people. Moderator is compatible with any
other role. If possible, producer should not accumulate with
either presenter or recorder, not to bias the review results.
The moderator is responsible for avoiding problem resolution
(which extends the meeting duration) and conflicts. The
presenter is responsible for the meeting pace. The recorder
fills the review report. The producer role is conducted by the
member representing the team which produced the prototype.
The lecturer (or several teaching assistants) offers
assistance wandering around teams and guaranteeing that
interaction between them is kept to a minimum to minimize
chaos. However, (s)he must keep a relatively low profile
during this phase, allowing students to learn from each other,
but helping to reconciliate possible contradicting
conclusions.
This peer review meeting should take between one to two hours.
Each team may complete the review activity at a different
time. As they do so, they are invited to leave the lab, to
avoid disturbing other reviews still taking place.
A copy of the review report is given to the lecturer.
Corrective Maintenance:
After doing a causal analysis based on all the review reports
the lecturer gives a class summarizing the most common defects
and their possible workarounds. Each team is assigned the task
of corrective (defects found) and perfective (requirements not
met) maintenance of the product they reviewed, not the one
they produced. A given schedule for this rework effort is
established.
Consequences:
This pattern:
- requires additional work on the part of the lecturer to
prepare the detailed requirements checklists;
- forces students to record, and to reflect upon, what
happened when they were involved in their work assignments;
- leads students to learn how to delegate and share
responsibilities;
- exposes students to the problems and challenges of
maintenance;
- allows the introduction of software quality principles and
techniques and actual practice for students in exercising
them;
- increases the learning potential by sharing other students'
experiences and knowledge;
- allows students to give and receive critique to and from
peers;
- avoids the frustration of egocentric students when they are
required to redo their first solutions.
Implementation:
Issues to consider:
- This pattern can be used repeatedly within the same course.
An entire course can be organized as a sequence of instances
of this pattern. These instances should not overlap in time.
- The material to be reviewed should not be tiny (see TSL
pattern).
- The rating of a team is split in two parts, one due to the
prototype they produced and other to the rework. A careful
weight of each of the two parts is important. This avoids the
reduction in the willingness of students to provide a
wholehearted improved solution on both phases. Equal weights
can be an appropriate approach.
The review report is composed of:
- a section for the identification of the deliverable being
reviewed, preparation times, date, review duration, etc;
- a section for the identification of the review members (and
their role if formal reviews are used);
- a section for registering and characterizing the defects
found (type, location, description, possible cause);
- a verification and validation (V&V) checklist.
The V&V checklist contains:
- identification of each elementary or atomic requirement
(specific to each assignment) - this allows the detection of
missing forward traceability (stated requirements not
implemented) or reverse traceability (implementation features
not reflected in design).
- identification of each rule or convention to produce (common
to all groups) - this allows the detection of non adherence to
the adopted standards (naming conventions, documentation
guidelines, indentation, use of headers, etc).
Related Patterns:
- EPIC pattern, since it also advocates peer work.
- DIRR pattern, since it also advocates a rework phase, although in a different framework.
Example Instances:
This pattern has been used to teach OMT (Object Modeling Technique) and Object Pascal programming concepts (using Delphi). However, since it is defined in a general way, it can
be used with any kind of software deliverable, either OO or not.
Resources:
The instantiation of this pattern requires the availability of a lab or classroom where several groups of students can work with as few interaction as possible from other groups under
the supervision of one or more lecturers (that have to circulate among the groups). The preferred option is to have an independent table for each group around which its members can sit.