• Have the interfaces between components been defined?
  • Is the workload for the Implementation Team balanced?  Have potential bottlenecks been identified and work redistributed, or contingency plans been created?
  • Have subsystem dependencies been defined?  Are they correct?  Are there instances of dependencies crossing more than one layer boundary?
  • Are there unnecessary dependencies to low-level subsystems? If subsystems in middle layer re-export interfaces from subsystems in lower layers, you should not short-circuit the middle layer by, importing the subsystems in the low layer.
  • Is it possible to reduce the number of dependencies to subsystems in lower layers? By letting subsystems in the middle layers, re-export interfaces from subsystems in lower layers, you can reduce the number of dependencies to the lower layer subsystems.
  • Are there too many layers (be suspicious of more than seven)?
  • Is the ratio between the number of subsystems and the number of components appropriate? For example, five subsystems and 1,000 modules is probably a sign that something is wrong.
  • Does the amount of source code correspond to the number of design classes in the design model? For example, 100,000 lines of code for 10 design classes is probably a sign that something is wrong.
  • Is the implementation effort close to what was estimated? If not, examine the hypothesis for the previous estimate, and obtain data on past productivity performance. Use some costing model to recompute the development cost and schedule.
 

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)