Peer reviews

1
Peer reviews
and the software process
2
Peer reviews

• A peer review is when one of your co-workers (not
  your boss) reviews your work
• The purpose of a peer review is to ensure quality
• Peer reviews take time that could be spent doing
  other things, but...
• ...well-done peer reviews are worth the time
• Peer reviews should be constructive, not
  destructive
• There are various types of peer review

3
Walkthroughs

• The author presents his/her work in a meeting
• Advantages
• Quick and inexpensive
• Good for information dissemination and training
• Disadvantage
• Relatively ineffective at discovering problems

4
Reviews

• The author distributes his/her work to peers
• Peers examine the work privately
• There is a meeting to discuss the work
• Advantages
• Better opportunity to become familiar with the
  work
• Better at detecting problems
• Disadvantages
• More expensive than a walkthrough
• Participants might not read materials beforehand
• Results can be inconsistent

5
Inspections

• The author distributes and presents work
• Participants are assigned roles
• Facilitator makes sure everyone has read
  materials beforehand
• Advantage
• Very effective at both education and defect
  detection
• Disadvantage
• More expensive than other types of peer review

6
Peer review outcomes

• There are typically three possible outcomes
• Pass -- work is satisfactory as is
• Conditional pass -- identified problems must be
  rectified
• Fail -- work must be redone
• Failure is uncommon, because the author of the
  work decides when the work is ready to be
  reviewed
• Conditional pass is by far the most common

7
Application of peer reviews

• Peer reviews typically refer to code, but...
• ...they can benefit almost any work product
• Requirements specifications
• Architectures
• Designs
• Code
• User interfaces
• Test plans
• User documentation
• Project plans
• Process descriptions

8
Requirements specifications

• The requirements document specifies what the
  program is supposed to do
• It does not describe how it should be implemented
• It should be understandable by non-programmers
• It should describe what actions the user can
  perform
• If the user interface for performing those
  actions is described, it is usually only in
  general terms

9
Architectures

• An architecture is high-level. It specifies
• What language is used
• What platforms are supported
• What the large components are
• How the large components interrelate
• What off-the-shelf components are used (e.g.
  graphics engine)

10
Design

• A design should specify in detail
• What classes are going to be used
• How classes interact with one another
• Important variables and methods in each class
• Arguments and results of each public method
• Designs are usually written in UML

11
Importance of design

• Failure to do a detailed design is a major cause
  of cost overruns
• Coding without planning leads to throwing away
  large chunks of code
• Trying to adapt existing code to a changed design
  leads to errors
• Careful design makes it easy to share coding
  responsibilities
• Design first, then code!

12
Redesign

• Strive for a 100 complete initial design, but...
• ...the initial design is never perfect
• It's OK to redo the design as you go
• Redesigning is a whole lot easier if you have a
  design to start with
• When you decide to redesign, do it as early as
  possible
• The earlier you redesign, the better!

13
Code

• A team should have coding standards
• Naming conventions
• Indentation conventions
• Comment style, etc.
• Standards make it easier to read one another's
  code
• Standards should be simple
• Government coding standards are never simple

14
User interfaces

• A good user interface (UI) is essential to
  customer acceptance
• There are standards that should be followed
• Some people are better at designing user
  interfaces than other people
• User interfaces should be reviewed by peers and
  tested by users
• The UI should be independent of the model code
• This makes it easier to modify or replace the UI

15
Testing in general

• Testing may be
• informal or formal (structured)
• Testing may be
• positive -- test for desired behavior
• negative -- stress test boundary conditions
• ad hoc -- basically random

16
Types of testing I

• Unit testing is testing a class or method in
  isolation
• The main method is a good place to do unit tests
• Every class can have a main method
• Integration testing is testing a new code module
  with the existing code base
• System testing is testing whether the whole thing
  works

17
Types of testing II

• Configuration testing is testing on a range of
  platforms
• Regression testing is using a set of tests that
  worked before with known results
• Often done in batch mode
• May not be as relevant to a game program

18
User documentation

• User documentation may be a separate document or
  may be embedded in the program (or both)
• Some people write better documentation than
  others
• User documentation should be subject to peer
  reviews and user testing

19
Project plans

• Programmers typically underestimate the time
  required to complete a project
• Research shows that programmers can give much
  better estimates if they take the job seriously
• All time must be accounted for--meetings, down
  time, revisions, unexpected problems, etc.
• We don't have much choice one semester
• We need to adjust the project, not the schedule

20
"Process"

• Process refers to how things are done
• Design
• Personnel scheduling
• Reviews and approvals
• Defect tracking
• Change control
• Quality assurance
• Development planning
• System integration
• Testing plans

21
Process in class

• A Process is a point of information transmission
• Process in the workplace is very different from
  process (or lack of process) in coursework
• Your teacher is trying to set up good processes
  (more about this soon!)
• A goal is to make this course more like "real
  life"
• Suggestions for process improvements are very
  welcome

22
Milestones and deadlines

• A milestone specifies when a particular piece of
  work should be done
• Milestones don't show complex interdependencies
• Bad milestones are fuzzy
• Good milestones
• are clear and concise
• leave no room for doubt
• binary either it's finished, or it's not

23
The Waterfall Model

• The Waterfall Model assumes that each phase flow
  into the next
• First you write specs, then you design, then you
  implement, then you integrate, then you test,
  etc.
• In the Waterfall Model, it gets progressively
  more expensive to make changes
• A Spiral Model is more realistic...
• ...but late changes are still more expensive than
  early changes

24
Practice peer reviews

• Today we will do some practice code reviews
• The results will not affect your grade
• You will not be asked to make any suggested
  changes
• Peer reviews are co-operative, not
  confrontational assist the reviewers in finding
  problems
• Please do think about the reviewer's comments
  and whether they can help you improve

25
The End