Site Map  Search

OOA Home OOD content UML Corrections book Code object Exercise Solutions oriented Resources tutorial Miscellany textbook

Exercise Solutions (Unrestricted)

Chapters 1 2 3 4 5 6 7 8 9 11 12

Chapter 9


Question 9.2
You have been asked to help defend your team’s request for a development budget increase by eloquently and succinctly describing the benefits of correctly and adequately done analysis and design.

[JD. The eloquence is down to you, dear reader. Some of the points you might have covered are:]

  • Without a design there is a greater likelihood that building begins with insufficient thought (conceiving and planning).
  • Without a design it's not possible to apportion work successfully, so the optimal number of implementers is just one, and it'll have to take as long as it takes.
  • Without a design perhaps no thought will be given to modularity and structure and, thus, no maintenance will be possible. The impact of change will be large at the start and will worsen rapidly. And let us not forget that maintenance begins when compiler errors are dealt with, so software corrosion will begin instantly and the product might not make it out of the door. It certainly won't make it past version 2 or version 3.
  • Many other things will not be possible without some kind of design documentation: testing, requirements coverage, impact analysis, ...
  • Without a design, perhaps some thought will be given to structure by the implementer(s); however, it will be difficult to achieve coherence or elegance.
  • Without an appropriate structure, it may not even work properly.
  • Without some strategic design thinking, beneficial aspects of the platform may be underused, and deficient aspects of the platform might be overused.
  • Without a design, if it should ever come to pass that a re-implementation, say in another language, is required, then it is highly likely that the same amount of work will be necessary as was necessary the first time. With a documented design (especially if it was kept up-to-date) a re-implementation should require significantly less time.
  • Although reuse is somewhat difficult to achieve locally (most successful reuse is via non-local frameworks), there is almost no chance of reuse, at the component level or at the framework level, without a quality, documented design.
  • Without an analysis, the design has no input apart from technology skills, technology documentation, requirements and previous designs (unless designs weren't done). Planning and execution of the design activity will be more haphazard. And let's not forget that a 300 KDSI project (1 KDSI = a thousand deliverable source instructions) might have a requirements document that correctly consists of a single paragraph. [It does depend on how you define analysis and requirements, of course. Naturally, this is using the book's definitions. JD]
  • The beginnings of a defined and repeatable process are not obvious if the analysis does not take place. Pragmatically, analysis gives a place to start and something we can definitely do in order to get going.
  • Without an analysis, any correspondence between the nature of the problem and the architecture of the solution is coincidental. Thus the impact of changes in the subject matter upon the design and implementation will be higher than it need be. (There might be cohesion (if a design was done) but it will merely be technical cohesion; conceptual cohesion will be absent or reduced.) Analysis can begin a model, an architecture, and ensure that there will be correspondence between the problem and its solution.
  • Without a documented analysis, the subject matter might be misunderstood. If there is understanding, it might not be consensus understanding.
  • [I might have put down re-use of analysis models or model elements. However, there are so many other factors mitigating against that, that in all fairness, we can't claim that a good analysis will amplify reuse. JD]