Administrative

1
05/24

• Administrative
• Upcoming due dates
• individual design assignment on the web now, due
  6/5 at noon
• prototype / demos in class 5/31
• Last time
• pair programming exercise
• This time
• quick note on the demo and deliverable for next
  week
• reviews and audits
• two presentations
• Next time
• Demos
• Quick retrospective / summary / perspective
• read but do not summarize Pressman

2
Group Presentation

• Now you have your first main code deliverable.
  Your goals in the presentation are
• explain your design (briefly)
• explain your goals/contract for the first
  deliverable (what is in scope, what is out of
  scope, why)
• show that your code achieves those goals
  (demonstrate a complete use case, including
  failure cases)
• Your audience really is your classmates
• have been working on different approaches to the
  same problem
• know the basic problem parameters
• are interested in knowing what you thought was
  easy and hard, and how you solved the hard parts
• Keys to a successful demo
• keep it short (15 minutes maximum, not including
  setup)
• your demo should be completely staged (that
  doesnt mean faked)
• leave as few variables uncontrolled as you
  possibly can
• know what inputs you are going to use to
  demonstrate the flow script it!
• arrange not to spend a lot of time doing data
  entry

3
Marciniak, Reviews and Audits

• A variety of "review forms" including reviews,
  audits, inspections, walk-throughs, formal
  inspections
• They vary in purpose, scope, and method
• "formality" is used more often in the paper
• Most general definition (paraphrased from p. 256)
• "a process during which a work product is
  presented to interested parties for comment or
  approval"
• But the big question why are these review forms
  important?

4
Reviews

• Examples code review, design review
• This is actually the worst-defined of the
  categories discussed in the paper, probably
  because the term is so vague.
• In practice the term is used for almost anything
  that satisfies the definition on the previous
  slide
• often a more specific term might work as well
  for example "code review" is usually conducted as
  what is described in the paper as an "inspection"
  and "design review" often looks very much like an
  "informal walk through"

5
Inspections

• "Static technique relies on visual examination of
  the product to detect errors, violations of
  standards, etc."
• This is often what a formal code review looks
  like
• code is emailed to a third party outside the
  project
• more-or-less formal sign-off on the correctness
  of the code
• required step in releasing a product
• On the other hand, design reviews tend to be more
  informal and interactive

6
Audits

• "Independent examination of a work product to
  assess compliance with standards, specifications,
  contractual agreements"
• Examples
• Amazon asking for audit of its CRM system
• Target auditing performance characteristics of
  its web site to determine contractual compliance
• Academic programs audited periodically
• Tax audits

7
Scheduled Reviews of Large Projects

• Large projects often have periodic internal
  reviews that are built into the project schedule
  itself.
• Two main purposes
• give everybody a look at the big picture
• allow PMs to synchronize the process efficiently
• identify co-ordination problems early in the
  process
• The main idea every so often the project
  benefits from broad communication rather than
  communication by pairs

8
Management Reviews

• Arguably different from other kinds of review
  processes
• Or maybe the same as the scheduled review (except
  it's not built into the project schedule)
• in fact, often it is done more for ongoing
  project than for first-release
• Goals management regains the big picture,
  participants in the project understand the
  project's role in the organization's larger goals

9
Walk Throughs

• Narrow scope, informal in nature
• "Designer or programmers leads members of the
  development team through a segment of
  documentation or code"
• (for what purpose?)
• Some informal code and design reviews could be so
  described
• Informal walk throughs are extremely valuable in
  "unblocking" an engineer or providing
  perspective, and the work environment should be
  set up to encourage this
• Walk throughs are almost always for the authors'
  benefit

10
Summary

• Reviews are important
• really
• from the lowest to highest level of a system
• In doing any kind of review it is important to
  make clear
• what is the process (formal, informal, what is
  done ahead of time as opposed to at the meeting)
• who is responsible for what?
• what is the purpose
• who has control over / responsibility for making
  changes or adjustments