Thursday, 19 February 2015

How-to: Review a Data Design

"the code be more a set of guidelines than actual rules"
(Pirates of the Caribbean)

This is not the only way, nor is it drawn from any particular method; this is just a convenient set of hooks on which to hang our data design meeting this week. You could apply it to any kind of design review, and it works well in the context of much more formal methods.

So my agenda for tomorrow looks like this:

  • Overview of the current data design – schema
    • Walk-through of schema vs. Business Object model/requirements
    • Comments, questions, issues, recommendations
    • Verification and validation of comments is discussed to determine the required action items (corrections, changes and additions)
    • Issues logged; actions assigned to named individuals to enact, research, produce further recommendations
  • Decisions about the schema, next steps.
  • Process for Change Control on-going.
Data Design Review Checklist
  • Well-structured
  • Simple
  • Efficient
  • Adequate
  • Flexible
  • Practical
  • Implementable
I like this set of words; it may not be the most technical or scientific, but it is useful.

  1. Does the data design convey a clear vision of the system that can be used for further development? Does it match the Business Object Model?
  2. Is the data design well-structured to support likely changes?
  3. Does the data design sufficiently describe the system at a high level of detail?
    (no interface or implementation details)
  4. Does the data design cleanly decompose the system?
  5. Is the data design independent of the infrastructure used to develop the system?
  6. Has maintainability been considered?
  7. No duplication in the data design?
  1. Are software requirements reflected in the data design?
  2. Is effective modularity achieved? Have correct slices been identified and are they functionally independent?
  3. Does each item have an understandable name?
  4. Is each association well understood/named?
  5. Is each association’s and aggregation’s cardinality correct?
  1. Does each association reflect a relationship that exists over the lives of the related modules/classes?
  2. Does the data design have adequate coupling and good cohesion?
    (Yes, these are Object Oriented design terms that go beyond the data design, but we'll have that discussion another time!)


Image credit:  Assembly' by Kimchi and Chips (@mimi_son @elliotwoods) and 5,500 ...

No comments:

Post a Comment

At least try to be nice, it won't kill you...