Final Report Presentation

• Audit
  • schedule some time
  • Everyone must be present and must be able to describe every aspect of the project (code, tests, builds, etc.)

• Customer Eval (didn't say much here, but it's the customer that does it so...)

• Final Report
  • no need for status report
  • Chance to step back and take a look at the last 8 (6) months. Lessons learned (1 or 2 insights), show that you get what SEG is (especially what is hard about SEG).
  • Identify what went wrong and successes. The post mortem is an opportunity to improve the process to demonstrate what you learned.
  • Code review and inspection (not in blame/feel defensive way, but as a learning opportunity)
  • Impact Assessment
    • think about customer (how will he maintain, possible modifications the customer will make)
    • Write this in a way that it could be addressed to the customer
  • QA report (possibly 2 or 3 of them)
    • Don't need to show that all tests are passing and no bugs, but show stabilisation
    • give context for numbers (what does it mean to have 10 bugs, etc.)
  • Member contributions
    • Major roles and responsabilities, not too much detail (one highlight). This is not where you complain about team, nor where you request grade adjustments.
  • The final reports are kept for many years and are reviewed by accreditation bureaus regularly. This project course is used by accreditors to evaluate the program.

• Next Course (April 7th)
  • final good bye
  • post mortem for course (chance to make suggestions or complain/compliment)

-- Jordan Mc Manus? - 09 Mar 2005