Wiki Home

Analysis Paralysis

Namespace: WIN_COM_API
A list of things to avoid analysis paralysis.
From Use Case Driven Object Modeling with UML: A Practical Approach by Doug Rosenberg and Kendall Scott. ISBN 0201432897
  • Don't try to write Use Cases until you know what the users will actually be doing.
  • Don't spend weeks building elaborate, elegant use case models from which you can't build a reasonable design.
  • Don't spin your wheels worrying about when and where "uses" or "extends" is called for.
  • Don't let people persuade you to use complicated tools and techniques that might not be appropriate for your project.
  • Don't try to do DetailedDesign on Robustness Diagrams.
  • Don't waste time trying to perfect your Robustness Diagrams as your design evolves.
  • Don't try to allocate behavior among objects before you have a good idea what the objects are.
  • Don't try to start drawing Sequence Diagrams before you've completed the associated Robustness Diagram.
  • Don't focus on "get" and "set" methods to the detriment of real methods.
  • Don't do State Diagrams for objects with two states.
  • Don't model what you don't really need to model.
  • Don't do State Diagrams just because you can.
  • Don't get bogged down in grammatical inspection.
  • Don't address multiplicity too early in the project.
    DO use the iterative model for project development.
  • Break the project into sub-projects early in the analysis
  • Treat each sub-project as a project in itself
  • Factor new knowledge gained from a sub-project into the rest of the sub-projects -- Jim BoothOffsite link to
    Category Anti Pattern
  • ( Topic last updated: 1999.11.04 01:09:22 PM )