Exercise Solutions (Restricted)
These are the exercise answers that are not available to visitors without a password. There used to be a change log recording the build up of this file as the chapters were uploaded, one by one. That change log has been cleared now that all the chapters are up.
I have made a start (May 2005) on building up the main diagrams of the case studies, in editable form (Visio). See diagrams.
In common with the book I have used the «entity» stereotype for the classifier boxes in analysis models. If that is at odds with your preference, consider just omitting a stereotype for analysis classifier boxes (and perhaps take a look at this note on the term "entity").
Chapters 1 2 3 4 5 6 7 8 9 11 12
There have always been those who would prefer to do the minimum of planning (including none at all) prior to coding. Recently, new positions have been introduced into the willingness-to-plan spectrum that runs from refusal, through resistance and acquiescence, to welcome. Agile modelers, XP (eXtreme Programming) moderates and XP extremists would be examples of new positions. Present the case for up-front analysis and design, and the case against.
The case for up-front analysis and design:
- Building the right system
One half of Barry Boehm's succinct distinction of analysis from design. Not being clear about what the problem really is leads inevitably to a sub-optimal or useless solution. [Jerry Weinberg's book are excellent sources of examples of this, especially "Are Your Lights On?" JD]
Just because you're a programmer and you've been hired to work on an accounting system doesn't mean that you understand double-entry bookkeeping. [This has probably improved over the years. The pride (unjustified) of the programmer has tended to reduce. The attitude, "I program computers, therefore I have a mystical ability that most don't possess" has been steadily crumbling to a more realistic attitude. JD]
Almost as bad as misunderstanding the problem is unshared understanding of the problem. If we're both working on solving a problem but I'm actually solving a different problem to the one you are, our solution must lack integrity.
- Continuity, limiting the impact of change
Systems are easier to understand and assess if there is a continuity between the shape and content of the problem, and the shape and content of its solution. We humans form model and analogs to help ourselves understand things. The more easily and more obviously that a software system is a model of something more meaningful to us than bit patterns in memory chips, the better. [We can't use our senses on software. JD]
- Building the system right
The other half of Barry Boehm's distinction. Creating a design up front gives goal and direction to the solution. In no other discipline than software "engineering" would anyone propose just piling up the bricks and hoping a nice building results, or that by moving the bricks around afterwards, the building can be tweaked until it's tolerably useful.
- Structure, work breakdown
It's impossible to allocated the building task and arrange their interaction if you have no overall plan or structure. Work will be duplicated and work will be forgotten.
- Integrity and consistency across a system
Without a guiding plan, there is a much stronger probability that the parts of the system built by different teams will follow different conceptual schemes, and future enhancers and extenders will have a much harder job. This isn't quite the same as an earlier point on shared understanding of the problem; this is about shared vision of the structure and style of the solution.
- Gauging and engaging
When programming your own class, you simply must have available an accurate and dependable specification of the interfaces of the other classes and of the type system. This is impossible to achieve if everyone just lurches straight into programming.
- Observable, debatable, communicable concepts and plans
Designing and building large, industrial-strength systems isn't easy. No-one can do it alone. Trying to debate and contrast the possibilities with nothing to point at but the code, is very difficult, whether it's an internal monologue or a dialogue and so on. And the same applies to reasoning with our future selves.
The case against big analysis and design up front:
- Most analyses and designs for software-intensive systems are of such poor quality that having them is worse than not.
- Separating the specification from the building leads, in some organizations, to analysts and designers whose only skills lie in earning more and in advancement.
- Sometimes there is such a disparity between the language and conceptual basis of the specifications, and that of the build technology, that one is put in mind of someone assembling a circuit board based on a document from a marketing "think" tank. [I blame, partially, an early overemphasis on analysis needing to be implementation-independent. JD]
- Analysis paralysis
Having perhaps encountered difficulty in overcoming the inertia of getting any analysis phase going at all, one then finds an enormous momentum to carry on analyzing forever.
- Linear (waterfall) process models wrongly assume that it's even possible to design without building. We, of course, no longer believe in linear process models. [I think this is one of the areas where the engineering analogies break down. It is possible to completely plan the building of a typical bridge from typical materials in advance of any building activities. As yet, this isn't the case in software. JD]
- Even spiral model development processes can suffer over-the-top, unworkable designs if their spirals, their macro management spirals, are too big. If big designs are done in the absence of any building (staged development, essential mockups, etc.) whatsoever, there is a strong danger that they will be unworkable. (From the Wiki entry on BDUF :
"No plan survives its first contact with the enemy." [Field Marshal von Moltke]
"In preparing for battle I have always found that plans are useless, but planning is indispensable." [Eisenhower]
"The documentation is nothing; the documenting is everything." [Gerald Weinberg].)
Department Y of government agency X is going to replace their ailing port arrivals analysis and alert system. Chester Drawers Furniture Emporium wants to improve its operation; orders sometimes get lost, customer complaints are mis-recorded and unpaid bills are not systematically followed up, for example. Department Y currently uses a mainframe system written in APL. Chester Drawers have nothing other than people, paper and four-function calculators. Your consultancy is helping both organizations decide how to proceed. What kinds of analysis and design activities do you suggest would significantly benefit each organization?
The likelihood is that you will have to more than systems analysis for Department Y. It will be challenging to analyze their computer-based system, and anyway, it's being replaced because it isn't working. Trying to begin the modeling of a new system by analyzing an ailing and difficult to analyze, old, computer system is a non-starter. You would probably suggest that although there are certain to be algorithmic nuggets that must be extracted from the old system, understood, and possibly replicated somewhere in the new system, a subject matter analysis -- ports, arrivals, threats, etc. -- is where the structure and content of the model should begin.
Chester Drawers, on the other hand, is in a situation that is closer to the computerization era where a lot of our systems development ideas and techniques began. It will be beneficial to do a significant amount of systems analysis, and probably a little subject matter analysis as well. A good systems analyst doesn't just analyze; (s)he goes on to improve the system. And how does (s)he do that? In part, it's by developing an understanding of the problem the system was trying to solve.