 |
|
||
|
(It's not as surreal as you might think)
1 - Introduction This talk is probably going to be different from most of the talks you've attended before. Before I get started I'd like to make everybody is aware that this talk is going to contain some satire. By its nature, being based on Alice in Wonderland, which is one of the great satirical works of all time, it pretty much has to. So, if you're easily offended by satirical humor, this talk might not be for you. I'm using satire in this talk to point out a few things about current software development practices that seem like, while they may have started off from good ideas and may still contain some good ideas, but that have acquired a significant amount of momentum in some directions that might be counterproductive. At least, they seem that way to me. In fact, having been involved with software development in one form or another for the better part of the last 30 years, and having spent most of the last 10 of those years teaching OO analysis and design, there's some stuff going on these days that seems downright strange to me. Hence the subtitle "it's not as surreal as you might think". We're going to be talking about things like "code smells" and "designs that figure themselves out from the code" a little later on, and I'd like to make sure everybody knowsI'm not making most of this stuff up. I read a posting on a newsgroup awhile ago that said "a little forethought can add a lot of work because forethought uses imaginary feedback to keep it on track". This is the first time I've ever heard someone postulate that thinking was harmful in software development. So, Alice and I are attempting to use humor to point out what we perceive to be the risks of some of these practices, And at the same time, we're also making some serious points. So, here goes.The presentation is in 3 parts. In Part 1 - Alice, intrigued by the benefits of use case driven development, enters use case land and encounters the dangers of analysis paralysis. In Part 2, seeking to avoid analysis paralysis, Alice meets some XtremelyCuriousCharacters and encounters the dangers of skipping analysis. Finally, in Part 3 - Alice
wakes up and finds a minimal yet sufficient approach to development
that avoids analysis paralysis without skipping analysis Use case driven development as a paradigm of software engineering was pioneered in Sweden during the late 1980s at Ericsson Corporation and was introduced to the world in Ivar Jacobson's book on Object Oriented Software Engineering around 1991. From that moment forward, nearly every development approach began to claim the attribute of being "use case driven", because the benefits of driving software designs from well-understood user requirements seemed so obvious. As the use case buzzword spread, many variants appeared, and much debate ensued over how best to approach use case driven development. Many of those who claimed to be use case driven were not doing anything remotely similar to what Jacobson and his team had proposed (and already used in practice on an extremely large project), but instead, they just tacked use cases on to the front end of whatever they were already doing. Still others made use cases an end goal in themselves, rather than a means towards the end goal of driving software designs from user requirements. As a result, many so called "use case driven" approaches led projects into analysis paralysis, and to the common phenomenon of "thrashing" with use cases. So now, let's join Alice as she enters use case land
Alice was beginning to get
very tired while sitting in the big chair reading. The But the book was over 500 pages long, and didn't contain many pictures, at that.and oh, how sleepy she was getting. And before long, she nodded off.....
As she slept, Alice dreamed of a simple yet elegant development process where first, everyone made their best effort to make sure the requirements were complete and well-understood, then a design was constructed to meet those requirements, then the system was built, and tested against those very same, written, behavioral requirements to make sure the customers got what they wanted. "Goodness" said Alice. A simple, straightforward, step-by-step development process that actually makes sense! I wonder why nobody thought of this before" she said. "It's really such a clever idea!" said Alice to herself.. "It's like writing the user manual first, with a few extra details, and then designing the software to match the user's requirements", she said.
Right at the center of the use case driven development process was a clever little technique called robustness analysis that seemed to link everything else together and make the whole use case driven modeling process work. But Alice, who had been spending lots of time reading books about UML, had mysteriously never encountered this technique before. Alice saw how software structure
and user interface design could all be linked to a simple and
clear expression of the behavioral requirements of the system.
"So, let's see" said Alice. "Use cases describe a dynamic view of system behavior, while classes and objects are about static structure" she said. "And this robustness diagram links the dynamic behavioral requirements directly to the software structure by forcing the analysts to reference objects by name right in the use case text. I wonder if that's what "use case driven" really means, because the software structure can be directly driven from the behavioral requirements" said the clever little Alice. "It certainly seems to make sense to link the static and dynamic parts of the object model together much more sense than to keep the software structure isolated from the behavior descriptions", she mused, "but it doesn't seem very close to code, yet" she said, and she began to follow the path she was on deeper into use case land.
7 - <<includes>> or <<extends>> As Alice walked down the
path, she came upon two men who kept hitting each So Alice asked, politely,
"Would you kindly tell me the best way to get One of them cried out, "The extending use case overrides sections of the extended use case, so when the extended use case changes, all of the extending use cases can inherit the changes without modification!", and the other yelled, "Extends informs the developer that the integration between use cases is one to one, but includes informs the developer that integration is one to many !" On and on they went, jumping
and shouting and hitting each other, and
8 - We're late! We have to start coding! Alice kept walking until suddenly a large white rabbit rushed past, stopped suddenly in front of her, turned in a circle 3 times, and shouted "We're late! We're late! We have to start coding IMMEDIATELY! The Duchess will be FURIOUS!". "Whatever are you doing?", Alice asked. "ITERATING!" said the rabbit, and began to spin around again. "Stop!" said Alice. "Doesn't all that iterating make you dizzy?" she asked. "And can you please tell me how to get from use cases to code?" "Use Cases?" shouted the rabbit. "There's no time for use cases, it's LATE and we have to start coding", he said, and off he rushed. "No use cases?", said Alice. "I wonder how they know what they're supposed to code, without any requirements about how the system is supposed to behave" she said. "Curiouser and Curiouser" said Alice, and then she continued down the path.
9 - Alice wonders how to get from use cases to code... "Oh, how I wish I could find a straightforward way to get from use cases to code", thought Alice, who didn't quite know what to make of the rabbit. "It all makes sense up through the analysis model, but it still seems quite a trick to turn behavioral requirements into software designs", she thought. "It's all very well to identify some objects and identify some behavior, but how do you figure out which objects perform which bits of behavior?" she wondered. "Maybe the answer is waiting down the path" she said to herself, hopefully.
Alice kept walking down the path and soon came upon a Cheshire Cat sitting in a tree. "Excuse me", Alice asked the Cat, "can you tell me how to get from use cases to code?". The Cat grinned, and began to repeat the words "essential, abstract, technology-free, and implementation-independent", but suddenly, as it did so, it began to fade slowly away....
11 - A little too abstract? Alice watched the cat fading away until nothing was left but the grin, but the cat's mouth continued to repeat the words "essential, abstract, technology-free, and implementation-independent", even as it disappeared. Alice was quite startled
by the cat's disappearance. "I've seen a cat without a grin,
but I've never seen a grin without a cat before" she said,
shaking her head slowly.. But I can't possibly see how this is
going to help me get from use cases to code. This is just so abstract
that there doesn't seem to be enough detail there to build a design
from", she said, and walked on. Alice soon came upon an enormous caterpillar, sitting on a giant mushroom, and smoking a hookah. "Hello" said Alice to the caterpillar. "You look very wise indeed, sir, do you think you could possibly help me find out how to get from use cases to code?" "Who are you?" asked the caterpillar, in a sleepy voice, "And why do you want to get to code?" "My name is Alice, thank you very much for asking, sir" said Alice, "and I want to get to code because if I don't, someone is likely to come along and cancel my project, and whatever will I do then, don't you see?" "I do NOT see"
said the caterpillar. "We define an essential use case as: "We were not alone in recognizing the need for such a teleocentric ("purpose-centered") approach to use case modeling and for a move toward abstraction in use case construction" he added, after a time. "Oh, but all these 5 syllable words do make my head spin", I wish you could put it more clearly", said Alice. The caterpillar just sat there, smoking, and after a time, Alice began to feel quite vexed. 'Shouldn't use cases be easy to understand?' she asked the Caterpillar. 'Doesn't it make more sense to just say 'the user does this and the system does that,' instead of rambling on about 'abstract, essential, teleocentricity' and so on?', she asked. "All these buzzwords make me feel very small, indeed", she said, impatiently. "Keep your temper"
said the Caterpillar, "You'll get used to it, in time";
and it put the hookah into it's mouth and began smoking again.
Alice waited, not sure exactly what she should do. In a minute
or two the Caterpillar took the hookah out of it's mouth and yawned
once or twice, and shook itself. Then it got down off the mushroom
and crawled away into the
13 - Are we really supposed to specify ALL this for EVERY use case? Alice wondered whether it would be a very good idea to taste the mushroom as the caterpillar had suggested, but she was feeling quite small, and, as she thought about it, she realized that, not having eaten since breakfast, she was quite hungry indeed. "I'll just try a small taste" she said, and broke off a piece. "Not bad at all" said Alice. "In fact, it's really quite tasty". After eating the mushroom, Alice continued down the path and soon saw a sign marked "This Way to the Template Forest". Not being sure which way to go, she walked in, and soon was surrounded by enormous signs with use case templates written on them. Alice stretched her neck trying to see to the top, and soon she found herself 10 feet tall! She began reading one of the templates. Use Case Name, Actors, Priority, Status, Pre-Conditions, Flow of Events, Basic Path, Alternative Paths, Post-Conditions.. "Goodness!" exclaimed Alice. "Are we really supposed to specify ALL this for EVERY use case?" she asked, and continued reading. Included Use Cases , Extended Use Cases, "Oh NO" ,groaned Alice. "Not THOSE again!", and she kept going. Generalized Use Cases, Activity Diagram, User Interface, Database Mapping, Scenarios, Sequence Diagrams, she continued. "I'm afraid this is worse than my Uncle's income tax forms" she said. "But I'm sure I heard him mention something about using a shorter form next year maybe there should be a short-form for use cases too". Alice kept reading the gigantic use case template..Subordinate Use Cases, View of Participating Classes, Other Artifacts, <Anything else you might want to include. Possibly an analysis model, a design model, or test plans.> "Well, I don't like THAT very much" said the wise little Alice. "Putting 'anything else you might want to include' into a use case template seems like a sure guarantee of never getting to code", she said. "I wonder if this one is any better?" said Alice, looking at another template, and she began to read.CHARACTERISTIC INFORMATION, Goal in Context, Scope, Level, Success End Condition. Failed End Condition, Primary Actor Trigger, MAIN SUCCESS SCENARIO, EXTENSIONS, SUB-VARIATIONS, RELATED INFORMATION, Priority. "Oh, dear me" said Alice. "Where will it ever end?" and she continued on. Performance Target, Frequency, Superordinate Use Case, Subordinate Use Cases, Channel to primary actor, Secondary Actors, Channel to Secondary Actors "Channel to secondary actors?" said Alice, startled. "I can't even think what that might mean, much less specify it for all my use cases. I guess this is what they mean by analysis paralysis. Specifying lots of useless information without ever getting to code. I'd better keep looking" she said, and down the path she went.
OK, this brings us to the end of Part 1, and I hope I was able to shed some light on why use cases became popular, on just what it means to be use case driven, and on how some of the conventional wisdom about use cases is responsible for the all-too-common phenomenon of "thrashing" with use cases that we see across industry today. In the next section of our talk, Alice meets up with some xtremelyCuriousCharacters, who, like her, are determined to avoid falling into analysis paralysis. But Alice finds that some of their methods and philosophies, which include (and I'm NOT making this stuff up, folks), oral documentation, code smells, "The code is the design" and so on, are just a little bit extreme..so let's rejoin her now as her journey through use case land gets curiouser and curiouser.
15 - Alice gets thirsty Alice, who had been walking for some time now, had become quite thirsty. After she walked for a time, she came upon a little clearing, where she saw a table with a little bottle on it. Around the neck of the bottle was tied a paper label with the words DRINK ME beautifully printed on it in large letters, along with the phrase "Guaranteed to avoid analysis paralysis" which was printed in smaller letters. "It's all very well to say DRINK ME, she thought, "and I certainly would like to avoid analysis paralysis my neck is still stiff from those giant templates" she said, but the wise little Alice was not going to just pick up a strange bottle and drink it in a hurry. "No, I'll look first," she said, and see whether it's marked 'poison' or not". However, this bottle was not marked 'poison', so Alice ventured to taste it, and finding it very nice, she soon finished it off.
16 - Alice feels faint... Alice became very dizzy,
and started to see many swirling colors. "What a queer feeling!"
she said. "I wonder if that was such a good idea. Perhaps
I'd better sit down for awhile" she said. As she sat, she
heard someone singing a curious song, and didn't quite know what
to make of it..... 17 - Imagine....(with apologies to John Lennon) Imagine there's no requirements.
It's easy if you try Imagine there's no schedules.
It isn't hard to do You may say I'm an extremer
but I'm not the only one Imagine oral documentation.
I wonder if you can You may say I'm an extremer,
but I'm not the only one
Alice got up, rubbed her eyes, and shook her head vigorously. "I do wonder what can have happened to me" she said. "I knew something interesting was sure to happen. It does any time I eat or drink something around here. But it was much pleasanter at home, really, when everything wasn't upside down all the time. Perhaps I'd better try to find my way back. [ Note: you can find more "Songs of the Extremos" on the web at http://www.SoftwareReality.com/lifecycle/xp/extremers.jsp ]
18 - Pair programming means never writing down requirements Alice, still somewhat dizzy, walked unsteadily down the path until she came to a clearing, where she saw a bunch of programmers, coding in pairs, and singing softly while they worked. An atmosphere of peace and tranquility prevailed in the clearing. Alice paused near a sign that said "The concept of schedule depends on the notion of done-ness, and since software is never done, it's all about developing at a constant velocity". Another sign nearby read: "Written requirements are for cowards -- don't be afraid of oral documentation". "Goodness" said Alice "I never felt afraid when I was writing those requirements downI was just trying to make sure I understood what the client wanted" she said. "All these people seem so happy and sure of what they're doing, programming in pairs and all", said Alice. "But I wonder if they're not blinded by their own faith. Without requirements, how can they be sure they're building the right system?" she said. "Why, you might as well say 'I code what I want' is the same as 'They want what I code'. And Alice, who was feeling a bit stronger by this time, continued down the path.
Suddenly the white rabbit, whom Alice had encountered earlier, dashed up, and began shouting at her: "There's no TIME to write down REQUIREMENTS." said the rabbit, iterating furiously. "And what's more, users never know what they want!", he said, continuing to spin around. "Just have them tell you a story, and CODE IT", he said. "They change their minds several times each morning anyway the only way to keep up is to refactor the code faster than they can change their mind. Why, we can go through 5 iterations in the time it takes a typical user to change his mind, you see if we cant!" he said. "Refactoring?" asked Alice. "I think I've heard of that, somewhere", she said. "It's the latest thing" said the rabbit. "Everybody's doing it", he said. "Design's dead, you know. With enough refactoring, you don't need design. The design figures itself out from the code. Ask the Hatter" he said, and off he rushed again.
Alice, not knowing what else to do, and feeling somewhat shaky again after hearing about designs figuring themselves out from code, decided to follow the rabbit for awhile. On they went, the rabbit pausing every few feet to iterate around in a circle a few times. Eventually the rabbit, rushing ahead at top speed, pulled far enough ahead that Alice couldn't see him anymore. Alice kept walking, and after a time she came to a clearing where she saw the rabbit, along with a large mouse and a little man wearing a big hat, all working furiously over a table and some chairs. When Alice walked up, all the legs from the table and chairs were sitting in a big pile on the ground. Alice watched as the Hatter, the rabbit, and the dormouse each grabbed 4 legs from the pile and screwed them into a chair. The problem was, that the legs were of different lengths, and Alice watched in fascination as they each finished assembling their chair, turned it over, and sat down. The chairs often tipped over, what with the legs being of different lengths and all, and when this happened they all yelled out, in unison "FAILED THE UNIT TEST", flipped the chairs back over, and began unscrewing the legs and tossing them back onto the pile. "What kind of game are you playing?" asked Alice. "It's not a game, we're refactoring the furniture" replied the Hatter. "Why don't you read the documentation for assembling the chairs?" asked Alice. "It's sure to specify which legs should go on which chairs" she said. "It's oral documentation", said the Hatter. "Oh" said Alice. "You mean you don't have any" she said. "No" said the Hatter. "Written documentation is for cowards" he said. "We can refactor very quickly, so we can be brave enough to let the design figure itself out" he added. "Oh yes. The rabbit said I should ask you about that" said Alice. "How can designs figure themselves out from code?" she asked. "You poor, ignorant child" said the Hatter, in quite a condescending tone. "The code IS the design, don't you see? Perhaps you'd better let the Duchess explain it to you" he said, and resumed refactoring the chairs. . Alice remembered some reading she had done as she continued to walk down the path. "I remember reading about refactoring, pair programming, and oral documentation on the internet" she said to herself as she walked. "What was that website again oh, yes, it was called the Wiki Web" she recalled. "I remember reading about some kind of payroll project" she said. "It was called C3 or something like that, I think.but.didn't that project get cancelled?" she said. "It seems like they did an awful lot of bragging about it, considering that it wasn't really that much of a success", she mused. [note: don't take Alice's word for it! Read it yourself at http://c2.com/cgi/wiki?CthreeProjectTerminated ] By this time Alice had come suddenly upon an open place with a little house in the middle of it. Alice walked timidly up to the door, and knocked, but no one answered. Alice could hear a most extraordinary noise going on within a constant howling and sneezing, and every now and then a great crash, as if a dish or kettle had been broken to pieces. "Well, there's no use in waiting out here" said Alice, and she opened the door and went in. The door led right into a large kitchen, which was full of smoke from one end to the other: the Duchess was sitting on a three-legged stool in the middle, nursing a baby: the cook was leaning over the fire, stirring a large cauldron which seemed to be full of soup. "There's certainly too much pepper in that soup!" Alice said to herself, as well as she could for sneezing. The Duchess looked at Alice and said: "Can you smell the code?" "Code?" said Alice, I thought it was soup". "That" said the Duchess, is a Code Smell, and our Goal Donor over there is refactoring the code so it smells better". "What is your code supposed to do?" asked Alice. "Do you have any requirements, or use cases?" she asked. "Who cares for use cases? We don't LIKE written requirements", said the Duchess. "We keep a customer in the room with us, and make him code up acceptance tests. We call him the Goal Donor. That way, we're free to add whatever features we want without any interference from those jerks over in marketing. THEY don't know anything anyway" she sneered. Alice remembered reading
about Goal Donors on the Wiki Web site, where there was some kind
of disagreement between them and management, who were referred
to as Gold Owners. "But, what if the Goal Donor and the Gold
Owner disagree?" Alice asked the Duchess. "The Gold
Owner might inexplicably cancel the project. And anyway, if customers
could code acceptance tests, why would they need programmers?"
she asked, quite perplexed. The Duchess became very angry with Alice. "How DARE you talk such nonsense!" she stormed. But Alice did not back down. She had remembered that she was carrying her new Palm Pilot, which had wireless internet access, and that she had bookmarked a page on the Wiki Website. "It's not nonsense" Alice protested. "Look at what it says, right here" she said. "On this webpage called C3ProjectTerminated. It says that the Goal Donor didn't want the same thing as the Gold Owners. That the programmers kept adding features to the code, while management wanted to turn off the mainframe computers because C3 was a Y2K replacement project. Why, that's nothing but good, old-fashioned featuritis, and quite a nasty case of it, too." she said. "What would have happened, do you think, if the mainframe payroll programs had actually broken in January 2000?" she asked. The Duchess was livid. "You FOOL", she began, "You just don't get it, do you? How much code have YOU written recently?" she asked angrily. But the plucky little Alice still refused to back down. "Featuritis", said Alice, calmly, "is why it's important to write down requirements. So the programmers don't build lots of cool stuff that's not what the client is paying for" she said. "GET OUT!" screamed the Duchess. "You'll have to answer to the Queen!" [note: don't take Alice's word for it! Read it yourself at http://c2.com/cgi/wiki?CthreeProjectTerminated ]
23 - OnceAndOnlyOnce? Alice was not quite ready to leave, however, and by this time she was feeling seriously annoyed by the Duchess' beligerrent attitude. She continued scrolling down the webpage on her Palm Pilot. "It's a pity" said Alice, "that you didn't base all of your lofty claims on a project that was actually a success", she said. "It says here that this C3 project was a Y2K replacement project started in 1996. It was terminated in Feb. 2000 when it was still only paying 1/3 of the people that it was originally intended to pay. And look what it says over herenot only will the client never try this approach again, but it even made the term object-oriented "unutterable by anyone wishing management to take them seriously". "Keep in mind" said Alice, "this Wiki Website isn't MY website, it's YOURS! This reminds me of that story about the emperor who had no clothes on", she said. "Don't you have any other large project success stories to brag about?" she asked the Duchess. The Duchess was speechless. "Get out!" she sputtered. "The Queen will have your head." This piece of rudeness was more than Alice could bear. She turned, in great disgust, and walked off. [note: don't take Alice's word for it! Read it yourself at http://c2.com/cgi/wiki?CthreeProjectTerminated ]
Alice continued walking for a time, and was just in the midst of wondering whether she could use her Palm Pilot to get a map home from wherever this curious place she was lost in was, when two soldiers, who looked strangely like index cards, approached her. "Excuse me, Miss" said the first soldier, "but the Queen of Hearts demands to see how much code you have written". Alice, who was still quite vexed after her unpleasant encounter with the Duchess, replied: "Please tell Her Majesty that nobody has given me any requirements yet, so I don't have any code." The two soldiers looked at each other. "No code" said the first, shaking his head. "The Queen's not going to like that". "No" said the second. "It will be a beheading for sure" he said under his breath to the first soldier, so that Alice couldn't hear him. "You'd better come with us, Miss" he said, out loud, to Alice. Alice, who after all had nowhere else to go, followed the soldiers until they came to a big lawn, where people were playing croquet. Alice could see a castle off in the distance. There was a sound of trumpets, whereupon the two soldiers exclaimed "The Queen, The Queen" and immediately threw themselves face down on the ground. Alice looked up, and there stood the Queen in front of her, with her arms folded, frowning like a thunderstorm. "Well?" said the Queen to Alice. "Where is it? Where's the code?" "May it please Your Majesty" said Alice, in a very humble tone, going down on one knee as she spoke, "I haven't written any code yet, because nobody has told me what the requirements are." The Queen turned crimson with fury, and after glaring at her for a moment like a wild beast, began screaming "Off with her head! Off with ---" "Nonsense" said Alice, very loudly and decidedly, and the Queen was silent. The King laid his hand upon her arm, and timidly said "Consider, my dear, she is only a child!" The Queen turned angrily away from him, and said to Alice "I demand you start coding this minute". "I won't do it!" said Alice, surprised by her own courage. "There's no accountability without written requirements, and my project will get a bad case of feature-itis. I'm NOT going to start coding without requirements." The Queen began to shout again, but the King spoke first. "Before we can behead the child", he said to the Queen, "we'll have to have a trial. " And then in a louder voice, he proclaimed "Trial of Alice to commence immediately!". And with that, the soldiers, who had gotten up off the ground, grabbed Alice by the arms and the whole procession marched off to the courtroom.
25 - You are guilty of BDUF... The King and Queen were seated on their thrones, with a great crowd assembled about them. Near the King was the White Rabbit, with a trumpet in one hand, and a scroll of parchment in the other. In the very middle of the court was a table, with a large dish of cookies on it: they looked so good that it made Alice quite hungry to look at them "I wish they'd get the trial done" she thought, and "and hand round the refreshments". But there seemed to be no chance of this; so she began looking at everything around her to pass away the time. Alice had never been in a court of justice before, but she had read about them in books, and she was quite pleased to find that she knew the name of nearly everything there. "That's the judge" she said to herself, "because of his great wig." The judge, by the way, was the King; and as he wore his crown over the wig, he did not look at all comfortable, and it was certainly not becoming. "Herald, read the accusation!" said the King. On this, the White Rabbit blew three blasts on the trumpet, and then unrolled the parchment-scroll, and read as follows --- "The child named Alice
we do confront "Consider your verdict" the King said to the jury. "Not yet, not yet!" the Rabbit hastily interrupted. "There's a great deal to come before that!" "Call the first witness" said the King; and the White Rabbit blew three blasts on the trumpet, and called out "First Witness!" Alice took the stand, nervously. "Give your evidence" said the King. "Beg pardon, Your Majesty, but I just wanted to write the requirements down before I started coding", said Alice. "Because, I think I should understand them better, you see, if I have them written down, and I can't always follow them as they're spoken.", she said. "Requirements" said the King, "are NOT one of the four important things about software. Those are Coding, Testing, Listening, and Design. That's all there is to software. Anyone who tells you something different is selling something. Designs are only to be recorded on index cards, and these are to be immediately thrown away as they'll be obsolete when the architecture changes in the morning. " "Let the jury consider their verdict," the King said, for about the twentieth time that day. "No, no!" said the Queen. "Sentence first verdict afterwards." "Stuff and nonsense!" said Alice loudly. "The idea of having the sentence first!" "Hold your tongue!"
said the Queen, turning purple. "I won't" said Alice.
"Off with her head!", shouted the Queen, at the top
of her voice. 26 - CMM's dead! Off with her head! The crowd immediately began chanting "Enough of BDUF....CMM's Dead.....Off With Her Head .....Off With Her Head". Alice was surrounded by dozens of index-card soldiers, all beating drums. Alice, who had heard of the Capabilities Maturity Model, but was not personally involved in any effort to reach CMM Level 5 but just wanted a simple and straightforward approach that involved a reasonable amount of forethought and provided a reasonable amount of documentation, didn't understand all the drum-beating about CMM. "What's so bad about trying to find a repeatable development process?" she wondered. All the drum beating and
chanting scared little Alice quite badly. She was sure that she
would be executed soon, although she didn't understand why. She
covered her ears and cowered in fear. 27 - Some serious refactoring of the design.... As the pack of soldiers descended upon Alice, she gave a little scream, half of fright and half of anger, and tried to beat them off. "Who cares for you?" shouted Alice. "You're nothing but a pack of cards!" Suddenly a big gust of wind blew up, refactoring the entire stack of cards, and the design that was scribbled upon them. Alice woke up and found herself back in the big chair in her living room. The window was open, and a strong breeze had sprung up. "Oh, I've had such a curious dream!" she said. "I'm not sure which was worse; getting stuck in analysis paralysis, or jumping straight to code without understanding the requirements. How I do wish there was some straightforward approach that was somewhere in between." she said.
28 - Part 3 Alice picked up another book, this one much thinner than the first, that claimed to talk about use case driven object modeling, for the first book had convinced her that use cases were a good idea. [note: see http://www.iconixsw.com/UMLbook.html ] "Thinner books," she remarked, "are much more appealing than the big fat ones. Goodness knows I don't want to fall asleep and have another dream like that again. Who knows what I'd dream up next time, probably "just-in-time-architecture" or something." she said.
"Hmm," said Alice. "It says on the back cover that this book has Analysis Paralysis alerts to help steer clear of common modeling pitfalls, and also an extensive discussion of requirements and how to design in a traceable manner. And look, it doesn't try to teach everything in the UML User Guide, but focuses on a minimal subset of diagrams", she said. "Look, there are only 4 different kinds of diagrams in the core subset that they use" she said. "I guess this is what they were talking about in the UML User Guide where they said you can do 80% of your modeling with 20% of the UML" said Alice. "Only this book actually tells you which 20% that is". [note: see http://www.iconixsw.com/UMLbook.html
] "Aha" said Alice. "It's that missing link diagram again. Now I can see how important it is. Getting from what to how seems to be one of the most difficult things to do in software development. "That caterpillar and the cheshire cat never got past talking about what the system was supposed to do," she said, "and the rabbit, hatter, and that horrible duchess and queen couldn't think of anything except code", she said. "Although it was pretty funny how afraid they all were of written requirements, wasn't it? I think they just didn't want anybody telling them anything, so they could build whatever they wanted. " said the wise little Alice.
"It's really quite fascinating," said Alice, "how many things go on during preliminary design. Both the use case model and the object model get updated during robustness analysis," she said. ""The use case text is made less ambiguous and more precise, at the same time as new objects are discovered. The static and dynamic parts of the model are linked together, and forced to be consistent with one another, and the behavior descriptions are double checked, to make sure they're correct, they're complete, and they're feasible to build. What an incredibly useful little technique!" exclaimed Alice. "It sure beats trying to jump from requirement-level use case descriptions to design-level sequence diagrams" she added.
32 - Behavior allocation happens on sequence diagrams... "And this looks like the big payoff" said Alice. "A straightforward process for building sequence diagrams where the first three steps can be automated in a script, and the fourth step is simply to focus in on making behavior allocation decisions. Why this takes a lot of the mystery out of object-oriented design," she said. "There's certainly no analysis paralysis here," Alice observed. "everything starts with the use cases; there's a requirements review with the client, then the behavior descriptions get refined during preliminary design, and there's a preliminary design review, which the clients can also attend. After that comes the detailed design, and then there's a critical design review, but the clients don't go to that one, it's just an internal review by the development team. And the the quality assurance folks test what the developers built against the use case text. So, it's 'here's what we think you want, please correct us if we're wrong', then, after those corrections, it's 'OK, we made the changes you suggested, and added a bunch more detail, please tell us if we got it right', and then, after that, it's 'we're going to go ahead and build what you told us you wanted now, then you can verify that we built what we all agreed on'. And you can do it for whatever sized iteration you choose, just for those use cases that you're planning to implement" she said. "It works for both small projects and large ones, and for large and small chunks of functionality within an iteration. There's no confusion about the requirements because everything is written down, and the design traces directly back to the behavior requirements, which can then be used to generate acceptance test plans." "What a relief to find a simple and straightforward process that is both minimal and sufficient" said Alice. "Avoiding analysis paralysis without skipping analysis is possible after all. You can learn a lot in dreams, sometimes" she reflected thoughtfully. "Now if only someone would build a plug-in to RUP that would let my entire project follow this process" Alice mused.
33 And the moral of that is.. "I quite agree with you," said the Duchess; "and the moral of that is -- 'Be what you would seem to be' -- or, if you'd like it put more simply - 'Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise.' " "I think I should understand that better, "Alice said very politely, if I had it written down; but I ca'n't quite follow it as you say it." "That's nothing to what I could say if I chose," the Duchess replied, in a pleased tone. "Pray don't trouble yourself to say it any longer than that," said Alice.
|
||
| ICONIX Software Engineering, Inc. |
|||