Electronic Workbook; Brooks Wrap-Up

Tom Kelliher, CS 319

Sept. 15, 2000

Administrivia

Announcements

Status reports: Weekly status reports will be due Tuesday, EOD, from each division for the previous week. Contents? Starting 9/19. File in StatusReports folder of EW.

Suggestion: division managers require weekly status reports from staff, due Mondays, EOD. File also.

Division, individual goals.

Assignment

Chapter 4 of Sommerville.

From Last Time

Essay discussions.

Outline

1. Electronic workbook.

2. Brooks wrap-up.

Coming Up

Introduction to requirements engineering.

Electronic Workbook

1. Considerations: Workbook, e-mail archive.

2. Workbook possibilities: Network drive, public folders, other?

   All project documents go into the workbook. Organization.

3. E-mail archive possibilities: public folder (CC: e-mail to limelite@goucher.edu), hack-in an e-mail interface to WWWboard SW, other?

   All project-related e-mail is to be archived. No attachments.

Brooks Wrap-Up

Comments on the presentations:

1. Relevancy judgement.

2. Presentation style.

3. Reasonable assumptions: Everyone's read the essay, so don't regurgitate it back at us.

Sharp Tools

• Not particularly relevant.

• Today's sharp tools: Reuse, objects in OOP methodologies.

• Release methodology:
  1. Component playpen: pure development, no control.

  2. System integration: nearing release, management control, drives revisions for integration problems, regression test failures only.

  3. System release: strict management control, fixes only to correct crippling problems.

The Whole and the Parts

• Bug-proofing the definition:

  The crucial task is to get the product defined. Many, many failures concern exactly those aspects that were never quite specified.

• Testing the specification: Having the developers do this is a recipe for disaster.

• Top-Down design: aka step-wise refinement.
  1. Conceptual integrity.

  2. Doesn't eliminate re-design (throw one away).

• System debugging:
  1. Use debugged components.

  2. Use plenty of scaffolding.

  3. Add one component at a time.

Hatching a Catastrophe

• How does a project get behind schedule? One day at a time.

• Use concrete milestones for assessing schedule adherence.

• Dependency charts and the critical path.

• ``Hands-off'' managing; scheduled and estimated milestone dates.

The Other Face

• Take in the whole view.

• Documentation for the user:
  • Purpose.

  • Environment.

  • Domain and range.

  • Functions.

  • UI.

  • User manual.

  • Options.

  • Required configuration for minimal performance level.

  • Reliability.

• Documentation for basic-maintenance personnel:
  • General testcases.

  • At-the-limit testcases. Reliability.

  • Over-the-limit testcases. Robustness.

• Documentation for overhaul-maintenance personnel:
  • Structure block diagram.

  • Descriptions at the function level.

  • File/data structure explanations.

  • Enhancement/limitation descriptions.

• Programming style:
  • Identifier names.

  • Indentation, whitespace, ASCII graphics.

  • Comments on a paragraph-by-paragraph basis.

  • For functions: purpose, inputs, outputs.

• Aside: concerns regarding storing the documentation online!