I haven’t read this book since University but I vaguely remembered it as one of the books that taught me system modelling, a skill that I still rely on to this day.
The biggest flaw unfortunately is the association of the act of Analysis with the construction of documents as part of the Analysis phase in a project. I suspect if the book was re-written to rip those words out then the true value that resides here could still shine and we could see that the value in analysis is the increase in understanding and agreement about what to prioritise and what to do next.
Early on in the book we learn that ‘analysis is not very satisfying’ ‘largely because it is so indefinite’ and ‘there are so many compromises to be made that no one is ever completely happy with the result’. And this, I think is why modern software development values a running and deployed system; something definite that we can use to learn if we are happy with the results and direction that we are taking. Constantly talking, conceptualising and building an ever larger model of the potential system without seeing it and having the ability to check if you are conceptualising the right thing does satisfy very few people.
Unfortunately some projects do carry on this tradition with large detailed backlogs, but they tend to avoid the diagrams and data dictionaries that Demarco describes in this book.
"Nobody is an expert estimator. You can’t even take a course in estimating because nobody is willing to set himself up as enough of an authority on the subject to teach it."
"We don’t build our estimating skills, because we don’t collect any data about our past results."
"None of this matters as much as it ought to anyway, since most things we call ‘estimates’ in computer system projects are not estimates at all… nothing more than Wishful Thinking"Demarco goes in to more detail later but reminds us that he provides estimating heuristics.
“A heuristic is a cheap trick that often works well but makes no guarantee. It is not an algorithm, a process that leads to a guaranteed result.”Demarco, on page 9 cautions us that “the analyst should be guided by a rule which seems to apply almost universally” The overriding concern of analysis is not to achieve success, but to avoid failure. Analysis is essentially a defensive business."
Throughout the early sections of the book we learn that analysis phases can go horribly wrong and can cause problems to fail and that large documents can be redundant, wordy, “tedious to read and unbearable to write”. And yet at the time there didn’t seem to be much alternative in Software Development, so looking back on the book today we have to skip a lot of the text.
I think it is still worth learning the concepts of Data Flow Diagrams, Data Dictionary, Decision Tables and Decision Trees. I’m tempted to say avoid Structured English, but Structured English has a mapping to Modern Software Development in the form of Domain Specific Languages and there might be some value in reading about it.
But when we do read about them we have to treat them with less formality than Structured Analysis required:
- DFDs can be useful graphical representations that help you think through flows in a system. I still use them.
- Data Dictionaries can be useful to name and represent concepts, I’ve used the concept to help me design and generate test data.
- Decision Tables and Decision Trees I use far less often but they can provide concise thinking tools
At this point I’ve skipped about 19 chapters. And then the book starts to have more relevance to Modern Software Development.
“The analyst is boss. Instead of being guided by the users’s political and procedural view, the analyst partitions according to his own standard: minimization of interfaces”I think “minimization of interfaces” is a good rule for creating models that are easy to grok and help focus your attention on specific domains, and help you when you model the system in code to create abstraction layers for automated execution.
I think a slightly truncated and amended version of the paragraph provides splendid guidance to testers when modelling a system, assuming that you identify with the analyst in the sentence.
“The analyst is boss. Instead of being guided by [someone else’]s political and procedural view, the analyst partitions according to his own standard.”There. I like that. I do that when I model a system to help me test.
Chapter 20 also provides guidance that we can use when again modelling the system in code to create abstraction layers for automated execution.
- Partition to minimize interfaces
- make sure your objects have small interfaces, this helps limit there responsibility
- Pay attention to names
- the advice given here matches advice you’ll find in books such as Clean Code
- Respect conceptual counting limits
- keep number of classes, methods, packages etc. small (at each level of a hierarchy or partition)
- Be prepared to start over
- refactor and rework as you learn more and actually use your abstractions in earnest.
"The Cardinal Rule of Acceptance Testing : Acceptance tests are derived from the Target Document and from the Target Document alone."And here Demarco clearly mean Target Document to mean Acceptance Criteria.
Thereby ruling out Exploratory Testing except…
Demarco lists the Acceptance Testing as:
- normal path tests
- exception path tests
- transient state tests
- performance tests
- special tests
“It would be naive to think that any system, no matter how complex, could be tested completely by the derived test sets as I have explained them. Clearly some systems require additional tests to deal with their very particular natures.”“some”? Surely, Tom, you mean All, or if you wanted to play it safe “Most”?
“For such special tests I suggest this protocol: Since they cannot be derived from the Structured Specification, they must be placed explicitly in the Structured Specification before it is considered complete. This will maintain the standard that all the criteria for acceptance are contained in the Structured Specification”OK. So what I heard Tom say was:
- do Exploratory Testing on the system
- that way you’ll learn stuff about the system because the Acceptance Criteria are not complete
- create notes to communicate what you tested and what you learned
- we’ll add that information into the stories to make them complete
- “Estimating is different from regurgitating”
- very often our ‘estimate’ is a regurgitation of a ‘right answer’ e.g. “You’ve got a week to do it, how long will it take?” A week? Right Answer - regurgitation
- “Estimating is different from negotiating” - “When you come up with your best estimate of an unknown, it makes no sense at all to let someone, namely your boss, make a counter offer.”
- “Estimations are not subject to bargaining” - “It is well to cultivate an air of stunned disbelief to greet any attempt at bargaining. At the very least, you are now obliged to tell whoever makes the counter offer that the estimate is now his.”
- “estimating is different from dividing a fixed duration into component parts”
A lot of this I use for building models to help me explore the system, but it has clearly also influenced the way I model the system in code to create abstraction code for automated execution.
I’m glad I re-read the book, I’m more glad that I read it early in my career and it provided - along with many of the design books from the 70’s and 80’s a foundation for logical modelling and abstraction that I still use today. But I find it hard to recommend to you, lest you take some of its absolute pronouncements as gospel, when they require a more flexible interpretation for the Modern World of Software Development.