Electronic Workbook; Brooks Wrap-Up
Tom Kelliher, CS 319
Sept. 15, 2000
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.
Chapter 4 of Sommerville.
- Electronic workbook.
- Brooks wrap-up.
Introduction to requirements engineering.
- Considerations: Workbook, e-mail archive.
- Workbook possibilities: Network drive, public folders, other?
All project documents go into the workbook. Organization.
- E-mail archive possibilities: public folder (CC: e-mail to
email@example.com), hack-in an e-mail interface to WWWboard SW,
All project-related e-mail is to be archived. No attachments.
Comments on the presentations:
- Relevancy judgement.
- Presentation style.
- Reasonable assumptions: Everyone's read the essay, so don't
regurgitate it back at us.
- Not particularly relevant.
- Today's sharp tools: Reuse, objects in OOP methodologies.
- Release methodology:
- Component playpen: pure development, no control.
- System integration: nearing release, management control, drives
revisions for integration problems, regression test failures only.
- System release: strict management control, fixes only to correct
- 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
- Top-Down design: aka step-wise refinement.
- Conceptual integrity.
- Doesn't eliminate re-design (throw one away).
- System debugging:
- Use debugged components.
- Use plenty of scaffolding.
- Add one component at a time.
- 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.
- Take in the whole view.
- Documentation for the user:
- Domain and range.
- User manual.
- Required configuration for minimal performance level.
- 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!
Thomas P. Kelliher
Fri Sep 15 08:55:41 EDT 2000