All right, Mr. DeMille, I'm ready for my close-up

Back in January, Brian H. Prince from Microsoft interviewed me about the UML features in Visual Studio Team System 2010. Today, he informed me that the interview is finally live on Channel 9.

posted @ Tuesday, May 26, 2009 6:58 PM | Feedback (0) | Filed Under [ VSTS 2010 (Codename Rosario) It's all about communication. UML Development Community Development Processes ]

Calculating the ROI for Requirements Analysis

My buddy Josh Holmes has written a very excellent post on the Return on Investment (ROI) for software. I recommend it to anyone who sees software as a business, not just a job or a hobby.

Last week, the always-worth-reading Patrick Greene made a comment that made me start thinking specifically about the ROI for Requirements Analysis. Most teams and most managers know they have a requirements problem; but too many of them say, “But we’re too busy to fix it, so we’ll just start coding.” Or “We’d like to fix it, but we can’t, so we’ll just start coding.” Or “Yeah, but our customers won’t answer our questions, so we’ll just start coding.” Or “Our executives want progress, they want us to just start coding.”

And that leads me to name a common, pernicious antipattern, JSC: Just Start Coding. This is not Agile Development, but it masquerades as Agile. It really means, “We’re gonna be late no matter what we do, and our executives are wondering why we’re not coding already. So we’re gonna Just Start Coding, and call it Agile.”

Which is exactly wrong. Good Agile, real Agile, is very requirements-centric. It’s about surfacing requirements and particularly requirements miscommunications quickly and frequently, so that we stay as close to the right path as possible, and waste as little time as possible on wrong paths. Agile makes short, quick moves, and short, quick corrections.

JSC, on the other hand, just makes quick movement, with no mechanism in place for planning and correction. “We’re on the wrong path? Who cares? At least we’re coding!”

And yes, let’s admit the dark side: we developers often contribute to this mess. Coding is comfortable. Requirements analysis (for many of us) is uncomfortable. It’s really easy to ignore nagging doubts and bury your concerns in lots of fun coding challenges. “Well, it doesn’t make sense to me; but this is what they asked for, so this is what I’ll build.” We abdicate responsibility for the wrong requirements.

But I want to follow in Josh’s footsteps, discussing software as a business, not just a job. And for a business, JSC has a cost. A huge cost. And Requirements Analysis can eliminate much or all of that cost. Maybe a little ROI calculation can help us to win executive support to do the job right.

Some Fundamental Assumptions

The ROI calculations that I’ll make are based on three fundamental assumptions: two from industry research, and one from faith.

1. Barry Boehm’s COCOMO II research tells us that poor requirements analysis can add 40% to as much as 100% to your schedule.
2. Many different sources (summarized by Steve McConnell) tell us that the average project is underestimated by roughly 100%.
3. Those were the research; here’s the faith. I contend that with a relatively minor investment of time compared to the overall schedule, your team can drastically improve your requirements, reducing that 40-100% schedule slip to nearly zero.

You can’t fix the tendency to underestimate (though you can make a good start by reading Steve McConnell); but I believe that most of what you need to fix requirements failures is simply paying attention to requirements early and refusing to ignore the obvious failures. I’ve worked on too many teams where everyone knew the requirements were fatally flawed, yet no one did anything about them. Everyone saw those flaws as “just the way things are around here”. They erected a giant SEP field around the requirements flaws, and they Just Started Coding.

I don’t think it has to be that way. I think that we as developers have the responsibility and the power to fix most of our requirements problems, if only we can persuade our managers to let us – and persuade ourselves to try. I’ve written a whole book (coming soon, I hope) on how we can perform better as Analyst-Developers; but to get management to back us, we have to show them a business reason. The assumptions above are part of that reason.

A Tale of Four Projects

To perform my ROI calculations, I’m going to envision four projects. Well, no, not really. Rather, I’m going to envision four different scenarios for the same project:

1. Just Start Coding (Typical). In this scenario, the team starts coding from the earliest possible moment. Management has a target date (they’ll call it an Estimate, but McConnell will call that a delusion). The more likely date is twice as far down the road, per Assumption 2 above; and then because the team fails to do adequate requirements analysis, the final schedule is 1.4 times that doubled schedule, for a total of 2.8 times the expected duration.
2. Just Start Coding (Out-of-Control). This scenario is similar to Just Start Coding (Typical); but the requirements analysis is even worse than usual, adding another 100% to the project. And these are factors, not sums; the final duration is 4 times the expected duration.
3. Analyzed (Time Bound). In this scenario, we assume enough Requirements Analysis at the start to recognize that the project cannot possibly meet the target date; and management tells us that the date is sacrosanct. We must meet that date, even if we have to cut features to do so. It’s always smarter and less error-prone to cut those features at the start than at the end, so we do so. Then we continue a small fraction of Requirements Analysis throughout the duration of the project, likely trimming more features as we go. We hit the target date with a lean but critical subset of the desired features, and a high-quality implementation of those features. We’ll add the other features next time.
4. Analyzed (Feature Bound). In this scenario, we assume enough Requirements Analysis at the start to recognize that the project cannot possibly meet the target date; and management tells us that the features are sacrosanct. We must supply those features, even if we have to slip the date to do so. Our final schedule will be 100% longer than the target; but when we finish, we’ll have the complete set of desired features, and a high-quality implementation of those features.

Obviously, some managers or customers will want Time Bound and Feature Bound. It can’t be done. Break the news to them gently.

Oh, all right, I know: some managers will demand Time Bound and Feature Bound. Let’s call this Scenario 5. It’s the Scenario where you do the analysis right up front, realize there’s no way to succeed, realize that management demands you violate the laws of space and time, and get your resume out on CareerBuilder.com so that you can be working somewhere else when the mandatory overtime and the punitive firings and the lawsuits begin. But since there’s no ROI for Scenario 5, we’ll ignore that scenario as we go forward.

More Assumptions

Next we need a few more assumptions (based on my personal experience, believe them as you will) and some parameters. First, the assumptions:

• Up-front analysis requires only about 10% of the likely schedule. If your target is 6 months and so your likely schedule is 16.8 months (6 * 2 for estimation error * 1.4 for analysis error), then your up-front analysis time is about 1.68 months.
• Because the analysis is work you would have to do to succeed anyway, just pushed to the front of the discussion, it involves the whole team, and yet doesn’t add to the final schedule.
• Analysis is a skill most teams don’t have in abundance. You need a few skilled lead analysts to work with the team, roughly 1 lead analyst per 5 team members.
• Once the initial analysis is done, you need little bits of analysis throughout the rest of the project. That will involve the lead analysts for about 20% of the total remaining schedule.

If you don’t like those assumptions, you can treat them as parameters and vary them; but these values fit with my experience.

As for the parameters, you really only need two:

• How much does an hour of a developer’s time cost you (total)?
• How much does an hour of a lead analyst’s time cost you (total)?

And that’s all you need to know. The rest of the possible factors – duration of the project, team size, etc. – all divide out, because everything is calculated as ratios of time to time, dollars to dollars, and so on. ROI is a relative measure.

And to be honest, you really don’t need to know the absolute costs for developers and lead analysts, just the ratio. As long as the ratio remains constant, you can plug in any values you like.

The Results

So given those assumptions and parameters, what’s the ROI?

Are you sitting down?

My parameters have a lead analyst costing 50% more than a developer. I don’t usually find that to be the case, but I wanted to make analyst costs relatively high to skew the ROI down.

And even with that skew, I ended up with these calculations:

• An Analyzed (Feature Bound) project has an ROI of 652% when compared to a typical JSC project, and 2,081% when compared to an Out-of-Control JSC project.
• An Analyzed (Time Bound) project has an ROI of 1,943% when compared to a typical JSC project, and 3,371% when compared to an Out-of-Control JSC project.

Those are astonishing ROI figures. Unheard of ROI figures.

And of course, those are ideals. Your Requirements Analysis won’t be 100% effective at cutting out lost time. Let’s assume you only cut out half the lost time that’s due to requirements failure. Then you get numbers like these:

• An Analyzed (Feature Bound) project has an ROI of 24% when compared to a typical JSC project, and 776% when compared to an Out-of-Control JSC project.
• An Analyzed (Time Bound) project has an ROI of 364% when compared to a typical JSC project, and 1,116% when compared to an Out-of-Control JSC project.

Still nothing to sneeze at. And I think you can do a lot better than just half. I know I can.

And although I've only calculated ROI based on labor savings, labor costs are not the only costs associated with requirements failures. Requirements failures increase costs across the board. Besides a longer schedule, you get more overtime, higher shipping costs, higher travel costs, missed commitments, lost opportunity costs, interest payments, performance penalties… even costly litigation.

And there's also a cost in quality. Reworked code has more bugs than original code. The rework is done under tighter deadlines, there’s more pressure, and there’s more overtime. Developers cut corners in response. This results in more bugs; and those bugs lead to more delays and even more schedule pressure. There's a nasty feedback effect here, and it can kill a project. Requirements Analysis can cut that feedback loop.

Conclusion

Again, this is not BDUF. I just spent a week at a client’s site, and spec’ed out their major requirements in that week in more useful detail than they had developed in months. Better Requirements Analysis does not mean bigger; it means more thorough. It means recognizing when you have questions, and making sure you answer them. It means identifying priorities and making choices.

And it means some resistance. It’s not by accident that we have a systemic problem with requirements in our industry. But it’s in our power to change that.

My spreadsheet for this ROI calculation is available if you want it. Leave a comment. If you disagree with any of my assumptions, leave a comment about that, too. I want to make the most clear, justifiable case possible to my stakeholders (and to yours!) to convince them that Defining the problem in a comprehensible, verifiable form is necessary to solving the problem.

posted @ Monday, May 04, 2009 7:53 PM | Feedback (0) | Filed Under [ It's all about communication. Development Processes ]

Weird Word 2007/PDF Bugs

Here’s a screenshot of my document in Word 2007:

That’s exactly what I wanted: three columns in different shades. Hurray for Word 2007!

Then I saved as PDF. Here’s a screenshot from Acrobat:

I don’t know why the colors “leaked” like that, but it’s bad.

And while I could imagine this being Acrobat, not word, this is clearly Word’s fault. I added a line to Column C, but made no other changes. Here’s the screenshot from Word:

More of the same strange color leaking. Not acceptable, not in my marketing literature! I hope I can track down a fix or a workaround.

Note: Any suggestions to switch to Google Docs or another alternative will be politely ignored. I love Office. I’m a power user and more. I can’t live without its mountains of powerful features that work exactly the way I expect. But that doesn’t stop me from whining when I want more, especially when I want a bug fixed. For once, I’m the end user, not the developer; and as a developer, I know this unshakable truth: end users whine, no matter what you give them. It’s my turn to whine.

posted @ Wednesday, April 22, 2009 1:05 PM | Feedback (0) |

UML... It's not Rocket Science

If you follow me on Twitter, you may have seen a strange tweet yesterday:

Looking for a word... "Employee" is to "Roster" as "Vehicle" is to _____? "Fleet" doesn't seem quite right.

With a lot of helpful suggestions, especially from @patrickgreene, we settled on “Fleet Manifest”. It’s ideal for what I needed.

But in case you’re wondering why I needed that term, here’s a slide from the UML QuickStart class from 213 Software Studios (click pictures for larger images):

And here’s another:

"Think one through..." is what we'll do after these slides. I'll show you diagrams of the concepts first, so you know what we're trying to accomplish; and then together, we'll think through a live example. And then you and your team will do your own examples, and I'll help you get it right.

These are just a tiny sample of what you’ll get in a full day of intensive hands-on UML training. Email John T. Hopkins at jhopkins@213softwarestudios.com or call (248) 425-8549 for more information.

posted @ Friday, April 10, 2009 3:08 PM | Feedback (0) |

Why I’m loving Windows 7 beta…

…an evolving list:

• Stability. It’s behaving better than Windows XP did on this box. Not that I had many problems (once I dumped some defective NVIDIA software); but it was sometimes slow for long stretches while something somewhere hogged the CPU. Never could figure out what, but it’s gone in Win7.
• Arranging the task bar the way I want it: Outlook, then VS2008, then Paint Shop Pro, then Journal, then IE8. Probably need to add Word, Excel, Powerpoint Presenter, and LoungeWorks.
• Pinning apps to the task bar. This is the equivalent of the old Quick Launch, but easier and more intuitive.
• The MRU lists in the task bar. Oh, man, is this a time saver!
• Pinning files to the MRU lists. Another time saver. I can know that Ulterior Motive Lounge.jnt (i.e., where I draw the Lounge) is always just a couple clicks away.
• Really rich set of previewers in Explorer, even including copying from the preview. Now when I know there’s something I need in a Word doc (in this case, the serial number for my Gateway), I don’t have to open Word to copy it to the clipboard.
• Desktop slideshow. I have Volume I of the Lounge running as my desktop.
• Easily customized desktop icons. (Small quibble here: it seems very hard to make large customized icons. I have succeeded with one. So far, I have failed with three. Still investigating.)
• Speech recognition seems even more reliable than Vista. Without training, it recognized songs from my music catalog better than Vista did after training.
• Speech recognition training is insidious. You think you’re running a tutorial; it knows you’re actually training the computer. Users are much more likely to train their computers with this approach. I want to meet the Evil Genius who came up with this plan! (But! The speech recognition fails for me in one minor but annoying respect: even after training – even after I used the correction system a couple of dozen times – it still can’t recognize “Putumayo”. Now matter how many times I try, it hears “”put a mile”.)
• Stacked icons in the task bar. Great space saver.
• Pinned taskbar items are “real”. In Quick Launch, they were only launch shortcuts: if you clicked them again, they launched again; and each time they launched, they took up space on the “real” taskbar. Now, the pinned icons are the real icons. Click them the first time, and they launch. Click them again, and they take you to the instance you already launched. Right-click, and you can launch another instance, or launch as Admin, or launch from the MRU list, or… Combined with stacked icons, this is a really great space saver. It encourages me to pin more things. I may soon find that I pin all my common apps.
• IE8 tabs all show as stacked icons in the taskbar. This makes it very easy to find a given tab, no matter which window you have opened it in. In XP/Vista, I had to look through multiple IE windows (assuming I had multiple windows open) and multiple tabs within each window to find the one I wanted. Now I click the icon, and select from the list. (And I’m wishing this machine had the graphics horsepower for Aero, so I could see the preview windows!)
• The desktop shows up as one more window in the ALT+TAB list. It’s amazing how obvious this is in hindsight.
• The show/hide desktop button on the end of the task bar. When I need to go to desktop right away. this is even quicker than ALT+TAB.
• Desktop gadgets. With transparency! Right now, I only have clock and calendar. But I’m thinking of more.
• Media Player 12 remembers my prior play list when I have to close and reopen the player. I hate having to save a temporary playlist if I have to reboot after some upgrade; but I hate losing my place in the middle of a great playlist.
• Media Player 12’s hover preview option. Can’t remember what that song is? Hover and find out!
• IE8’s Find is amazingly fast, even on this old machine, and amazingly simple.

More to come, I’m sure…

posted @ Thursday, April 02, 2009 11:23 AM | Feedback (0) |

I blame Microsoft

In a classic Dilbert strip, Tina the Tech Writer is forced to write docs for code that doesn’t exist yet. Her last line: “If you call our tech support, we’ll blame Microsoft.”

Works for me! I blame Microsoft for why I don’t have a new Lounge today. OK, so time spent job searching is a larger factor. But still, I’d rather blame Microsoft.

In particular, I blame Windows 7. Now by and large, I’m loving the Windows 7 beta. It’s a thousand little things I didn’t know I needed, but now I need. And it’s running amazingly well on my old Toshiba Portege M200. Soon I hope to test it on my Gateway, which has a lot more power.

But there’s one area where I’ve found a bug; and it’s a critical bug for the Lounge. In fact, it’s in the critical Lounge application: Windows Journal.

I love Windows Journal. It’s simple, it’s powerful, it’s free with Windows. You grab a Tablet PC pen, and you draw. That simple, and that powerful. Simple, because it just works like a pen and paper. Powerful, because even though it doesn’t have the drawing features of a higher-end paint package like Paint Shop Pro, it has two very powerful features:

1. You can print documents to it. Word docs, Excel spreadsheets, Web pages, whatever: print to Journal, and then you can draw on top of the “printed” document. I use this as a presenter: I print my Powerpoint slides to Journal, and then present from those. As I present, I can hand-write notes in answer to audience questions. This is the only way to present, in my opinion. (Actually, not quite the only way; but that’s an announcement I’m saving until I finish some code…)
2. You can do a text search of your hand-written notes. So not only can you write on your document, you can search for what you wrote. Again, this is great power for a presenter. (But again, look for an announcement soon…)

So I do love Journal. I call it the Killer Tablet PC App Microsoft Doesn’t Know They Have. Journal by itself is reason enough to have a Tablet PC, but Microsoft seldom seems to mention it. (A search for “Windows Journal” on Microsoft’s own site finds more hits for the Journal Viewer than for Journal itself; and Journal seems to have no specific page there, just a couple of “how to” articles.)

And I can’t draw the Lounge without Journal. Every episode, every panel, it’s all done in Journal.

And therein lies the problem: in Windows 7 beta, Journal is broken. When I open old episodes, some of the contents are drawn in the wrong place. Even worse, some aren’t. That means pieces of the episodes actually move around.

As an example, here’s Episode 32 as I drew it in Journal for Windows XP, then pasted into Paint Shop Pro for cropping and converting (click pictures for larger images):

Now it’s not high art, but it all looks like I intended it to look.

And here is how that page looks under Windows 7 beta Journal:

Notice the vertical stripe of missing Ink on the right. That’s bad. But it gets worse. Without me touching the image at all – all I did was switch to Paint Shop Pro to save the screen shot, switch to Live Writer to edit this post, and switch back – I get this:

I’m not sure I can describe all the things wrong with that image. Some parts of it have moved. Some parts haven’t: the panel borders are all drawn the same as the rest of the image, after all; and the nose of the Gremlin in panel 3 hasn’t moved at all. But the tail of the Gremlin has moved into panel 4!

Now a suggestion by Jennifer Marsman made me try an experiment; and her intuition is good: the Ink hasn’t actually moved, it’s just drawn in the wrong place! If I use the Journal selection tool and click in the image, I get this:

Notice how part of the Gremlin and passengers in panel 2 are really exactly where they belong; but they’re drawn to the right of where they belong. (Why only part? I can’t guess. I don’t know the internals of Journal. May be something to do with Grouping.)

Now Stacy Vicknair has asked if this bug is so bad that it stops me from drawing the Lounge? My answer is a definite maybe. See, I’m busy, and I’m lazy. If I draw something well enough once, I try to copy and paste it in other places where I need it. I’ve got 32 Episodes in, plus 3 Lounge-based conference talks and a Lounge book proposal. (Oops! Did I say that?) At this point, I probably draw less than half of each Episode. The rest is paste, resize, and edit. (I even wrote LoungeWorks, a set of Ink tools that give me power features not found in Journal: rotate, mirror, and scale.) But now, if I can’t reliably see where things are, it gets much harder to draw new Episodes. And with most of my time devoted to the job search, “harder” is not a feature for me right now.

I’m posting this in hopes of getting the attention of someone on the Journal team at Microsoft. I really want to use Windows 7, but I must have a working Journal for the Lounge. I’m not a fan of dual-booting, especially when my M200 has a rather small drive. I’ll dual boot if I have to; but I’d be happier to help Microsoft fix this. If anyone knows anyone on the Journal team, please pass the word: I’ll be happy to share the file that shows this bug, if that will help them to fix it.

I’ll also be happy to share another Journal file with an even more painful bug. Actually, I have multiple files with the same problem. They’re Web pages that I printed to Journal (XP) for later markup. If I try to open any of these in Win7 Journal, Journal hangs, and then Win7 terminates it. Worse: the recovery code “helpfully” tries to reopen that file next time I start Journal, and crashes again. Repeat, repeat, repeat, until I move the file so Journal can’t find it.

Journal team, I hope this helps! Contact me if you need more info. If you can’t figure out my email, you can always try @umlguy on Twitter.

posted @ Wednesday, April 01, 2009 5:22 PM | Feedback (2) |

Jaded

Once upon a time, I had a really thorny development problem to solve. I needed to build a histogram of the colors in a true-color image. There was a theoretically easy way to do this. If I had had C# then, the code would’ve looked like this.

int[,,] histogram = new int[256, 256, 256];

for(int y = 0; y < bmp.Height; y++)

{

    for(int x = 0; x < bmp.Width; x++)

    {

        Color clr = bmp.GetPixel(x, y);

        histogram[clr.R, clr.G, clr.B]++;

    }

}

This was the brain-dead simple way to build the histogram. Only one problem: it required 16million 32-bit counts, or 64 megabytes.

64 M*E*G*A*B*Y*T*E*S OF RAM, MAN! ARE YOU MAD? THAT WOULD COST US $50,000!!!!! The whole SYSTEM is supposed to cost under $30,000!!!

Well, OK, for some of you, that just pinpointed the year, more or less. There was no way on Earth we could ship a system with 64 MB. Instead, I built a complex and ultimately failed algorithm to build a sparse histogram. I solved the general problem of sparse histograms – with a solution vaguely like what you’ll see below, but less elegant – but I couldn’t easily ascertain color proximity within the histogram. That was just too difficult. It took me months, and it never worked perfectly. Like Alan Cooper says, the bear danced, but never well.

Today, I am almost never without two memory sticks, a memory card, and a phone that collectively add up to about 3 GB. I sometimes forget I even have the card.

And so today, I could actually build the algorithm above (if I still needed it); and it would run in an insignificant amount of memory.

But why bother? I realized that Microsoft had given me simple tools for building a sparse histogram:

Dictionary<System.Drawing.Color, int> histogram = new Dictionary<System.Drawing.Color, int>();
for (int y = 0; y < bmp.Height; y++)
{
    for (int x = 0; x < bmp.Width; x++)
    {
        System.Drawing.Color clr = bmp.GetPixel(x, y);
        if (histogram.Keys.Contains<System.Drawing.Color>(clr))
        {
            histogram[clr]++;
        }
        else
        {
            histogram[clr] = 1;
        }
    }
}

There it is. It works. It’s maybe not efficient, but it’s simple. It still doesn’t solve my color proximity problem (hey, I’ve gotta keep some of my secrets to myself for a while); but it works, and it took me less time to write than I’ve spent on this blog post.

And when it was done, and I found that it didn’t address the problem I was really trying to solve (trying to figure out why my bitmaps aren’t transparent), I threw it away.

Code that once took me weeks, written more elegantly in minutes, and casually thrown away as trivial.

I am so jaded…

posted @ Thursday, March 19, 2009 5:54 PM | Feedback (0) |

Usability 101: Don't Do This! (I'm Talking to YOU, Microsoft!)

From PowerPoint – 2007, no less!

On one page, we can set the size. X and Y are arranged horizontally, Y first.

On the next page, we can set the position. X and Y are arranged vertically, X first.

This has confused me practically every time I’ve had to edit the size of something in PowerPoint. I know it’s there. I do. But the behavior is so counterintuitive, I just can’t get my brain to think this way. It’s just wrong!

Personally, I would prefer size and position on the same page; but I can see the argument for separating them, since size has so many options.

But changing their layout and order is practically begging users to make mistakes.

Smooth move, PowerPoint team…

posted @ Friday, March 13, 2009 6:54 PM | Feedback (0) |

Stray quote for the day…

By and large the literature of a democracy will never exhibit the order, regularity, skill, and art characteristic of aristocratic literature; formal qualities will be neglected or actually despised. The style will often be strange, incorrect, overburdened, and loose, and almost always strong and bold. Writers will be more anxious to work quickly than to perfect details. Short works will be commoner than long books, wit than erudition, imagination than depth. There will be a rude and untutored vigor of thought with great variety and singular fecundity. Authors will strive to astonish more than to please, and to stir passions rather than to charm taste.

Alexis de Tocqueville (1805–1859), French social philosopher. Democracy in America, vol. 2, pt. 1, ch. 13 (1840).

posted @ Wednesday, March 11, 2009 10:59 AM | Feedback (0) |

Ulterior Motive Lounge Episode 32: Talking with Pilot

Continuing The Project that Time Forgot, a UML case study. (Click images for larger versions.)

On the surface, this Episode may seem almost social. Demented and sad, but social. But if you could join Hacker Girl, reading Geek Girl’s Tablet PC over her shoulder, you might see a different picture:

And you would also see this diagram:

You saw a conversation. Geek Girl hopes that Pilot saw a conversation. But she saw an interview, and a chance to capture and model requirements. Let’s review the notation here and discuss the diagram contents.

• The ellipses are the use cases that a driver performs (indicated by the arrows from Driver to the use cases).
• Dependencies (dashed arrows) with the <<include>> stereotype indicate that one use case includes another within at least one of its scenarios. So in order to Get Destination, the system must Scan GPS IDs.
• The triangle-headed arrows (generalizations) indicate that one use case is a special case of another use case. So Contact Ops via GPS, Get Time from CIS, and Get Weather from CIS each has a special case that uses Voice Command; and each of those special cases is defective.

You might ask: “Why is Maintain Car in this diagram? Aren’t they modeling what the computer systems will do? Does the computer have any role in car maintenance?” And that’s a legitimate question. If the team were modeling the entire business, Maintain Car would certainly be a use case in the model; but why did Geek Girl include it in the system requirements model?

The answer is two-fold:

1. Pilot mentioned reflashing the engines, which is a computer-driven operation. As indicated in Geek Girl’s notes, it’s not clear at this time whether the Park’s computers are involved in reflashes or not. The reflashes may be done by dedicated tools that have no connection with Park systems; but it may be that the Park maintains records about the reflashes. Just in case, Geek Girl wanted to capture this.
2. And building on 1: it’s always best to capture whatever a user says, even if you’re not sure it’s relevant. You can always remove it later. The analyst’s first job is to listen and capture. Analysis and filtering comes later. Don’t filter while you’re listening, filter later!

But then you might ask: “Why did Geek Girl stop there? Why didn’t she include use cases like Fly Helicopter and Rebuild Diesel Ferry Engine?” The answer is that she ignored what I just said, and she filtered now. “Filter later” is a good guideline, but you do have to apply some measure of judgment. Certainly “Watch Your Language” doesn’t involve the computer system, so she knew she could ignore that. Fly Helicopter and Rebuild Diesel Ferry Engine are less clear; but there’s certainly a good reason for leaving them off this diagram: it’s a diagram of Driver use cases, and those aren’t Driver functions. Pilot does them, true; but when he does, he’s not acting in the Driver role. Because remember: actors are roles people or things can play, not the people themselves; and one person or thing may play multiple roles.

If you’re still uncomfortable with the distinction between Maintain Car and Rebuild Diesel Ferry Engine, good! Welcome to the world of requirements analysis! There are no hard and fast rules. There are no clear lines, only guidelines. You have to apply judgment; but as a general rule, err on the side of capturing more information, not less. Geek Girl captured a lot of notes on her Tablet PC, while converting the most clearly relevant ones into a diagram. After the interview, Geek Girl will find time to clean up and reorganize the diagrams, and perhaps rethink the contents.

In Episode 28, The UML Guy adopted a convention of indicating defects via notes on diagrams, as in this earlier diagram of Driver Use Cases:

Harlan Ellison once observed that a lot of dumb behavior can be traced back to the phrase, “It seemed like a good idea at the time.” Well, Geek Girl has decided that The UML Guy’s good idea at the time is a bad idea going forward. Not that the notes are a bad practice: they clearly indicate the defect, and diagram readers can easily see what the defect is. If your goal is printable diagrams which stand on their own, this might be a good practice.

But it has some weaknesses:

• As we find a lot more defects, the diagrams will get cluttered, and it will get harder and harder to arrange the diagrams legibly.
• We have to do extra work to show the defect on additional diagrams.
• Printable diagrams aren’t your goal, or shouldn’t be, in my opinion. To quote myself:

The Model Rule

We saw The Model Rule in chapter 1; but it bears repeating. To use UML effectively, you should never be simply drawing pretty pictures; you should always be editing an underlying model, using the pretty pictures as your user interface. Thus, the model should contain more information than is displayed in any one diagram; and information in one diagram should not explicitly contradict information in another diagram. Information that is found in one diagram but not in another should not be considered a contradiction. Rather, this simply indicates that the former diagram displays more detail than the latter. Details may be omitted from a given diagram to make it more comprehensible.

But how do you keep these diagrams consistent with each other? How do you maintain the underlying model? This is where a good modeling tool proves its worth: a good modeling tool will maintain the model as you create and edit your diagrams. If you are not using some sort of modeling tool, this very mechanical burden will fall on you, rather than on the machine. That’s a poor division of labor: brains should do brain work and machines should do mechanical work. If you do the mechanical work, you will do it imprecisely and inefficiently, and you’ll have no time for brain work. I urge you to investigate and use one of the many UML tools available. A list of UML tools can be found in Appendix B.

• And building on The Model Rule, defect notes on the diagram don’t let your model and your tool help you in managing the defects. As an example, Enterprise Architect from Sparx Systems allows us to add detailed requirements information to each element of the model. Here’s a sample screen shot:

And then you can create a requirements report that lists the defects, as in this snippet:

That’s a lot of power to give up just for the minor benefit of notes on the diagrams. (There’s a lot more power in Enterprise Architect reports than I’ve shown here; and if that’s not enough, EA is an incredibly powerful automation environment. You can build add-ins for it, and also build automation clients that control your EA models. I have one in the works that lets you directly create EA models from Microsoft Word 2007 and Microsoft Office 2007. When I first started using EA, I said, “This is a great UML tool for the price!” Today, I know better: Enterprise Architect is a great UML tool for any price!)

So in place of defect notes on the diagram, Geek Girl prefers to note the defects in the model, as above; and then use a stereotype to show that the use case has a defect. I think that’s a better practice, even if it’s a bit tool-specific. It makes it easier to add the additional use cases that Pilot described in this Episode (omitting the domain objects so we can focus on the use cases and defects). And for me, The Model Rule is more important than printable diagrams, by a long shot.

And as for the last item in Geek Girl’s notes: yes, why is H.G. so hostile? That must wait for an upcoming Episode…

posted @ Wednesday, March 04, 2009 4:06 PM | Feedback (0) |

Spider

A small benefit of being between gigs: I’m sitting here, coding and networking and working and planning, while watching From the Earth to the Moon Episode 5: Spider. If you’re any sort of an engineer, you need to watch this every year (or more) for inspiration. It’s the best, truest picture of engineering I’ve ever seen on screen. And for me, it’s a reminder: my job is not hard. That was hard, and they did it. I can do this.

I also recommend Thomas J. Kelly’s Moon Lander for the story behind Spider. It’s kinda dry, but it’s an amazing look at a period in engineering history when they were inventing and discovering the project management techniques we take for granted today. Oh, and they sent men to the Moon.

posted @ Wednesday, February 25, 2009 12:21 PM | Feedback (4) |

Overlooking the Obvious

I just wanted to rename a Word document while I was working in Word.

You know what comes next. In practically every application out there, I have two choices:

1. Close the app. Navigate to the file in Windows Explorer and rename it. Double-click it to reopen the file.
2. Within the app, do a Save as…. Optionally delete the old file name.

In both cases, both file names now appear in the Most Recently Used list, even though the old file may no longer exist. Yawn. We know how this works.

But can you learned this? Didn’t it seem a little odd?

Can you remember the first time you tried to teach this to your non-geek relatives? Can you remember them saying, “That’s dumb, that’s confusing”? And then you said either, “But it’s easy enough” or “That’s just the way it works.”

Why is it just the way it works? Because we geeks have spent decades telling ourselves that this is normal. It’s a tradition going back at least as far as the Unix mv command, which can be used to move a file to a new folder but can also be used to rename a file. It’s the same way of thinking – a design way of thinking, not a requirements way of thinking – that says “If we have Create, and we have Delete, then we have Edit, because we can always just Delete and then Create again.” We geeks have just accepted “Save As and Delete” as normal.

Well, it’s not normal. We’re overlooking the obvious: if so many users need to be taught a complicated way to rename a file, it’s because users need a simple way to rename a file! Except in a few superior designed programs, we don’t have a way, we have a workaround. It’s just that we know this workaround so well, we think of it as normal.

Talk about not designing for the user experience! Somewhere right now, Alan Cooper is shaking his head in disgust…

Well, not for me, not any more! From now on, every file-based app I write will have a Rename command right up there with Save and Open; and when you rename, it will clean up the MRU list as well.

Ironically, you know what’s one of my favorite features in Visual Studio? It’s the way you can rename a file in the Solution Explorer, and then it asks if you want to rename the class to match the file, and it just correctly applies the rename everywhere (except in comments).

This is so easy, so convenient; yet somehow, I’ve been overlooking that convenience when it comes to my users. Have you?

posted @ Wednesday, February 25, 2009 12:10 PM | Feedback (0) |

You're Selling Software

Update: Fixed a typo and a calculation error.

Josh Holmes has a great post on Return on Investment (ROI). And by “great”, I mean great even by Josh’s usual standards. He worked hard on this one. I was privileged to review three drafts before he published it; and by draft two, I was saying, “Josh, this one’s a winner. I’m going to reference this one a lot.” So stop reading me, and go read what Josh has to say. I’ll be waiting here when you get back.

OK, you’ve read it. Pretty scary, huh? But the scariest part to me is that even though Josh is right, he shouldn’t be. To quote Paul Simon, these are the days of miracle and wonder. To be specific, these are the days of software. I’m not saying this is some grand new revelation; but businesses and software people forget just how much software changes the world. Today, whatever your business may be, you may find that deep under the hood, you’re selling software. Oh, not everybody, by any means. Pastry chefs are still selling pastries, day care workers are still selling child care, and airlines are still selling transportation. But a lot of people who once sold simple goods and services are now selling software, whether they realize it or not.

Let me draw some examples from projects where I’ve worked.

Material Handling

I’ve worked on a number of different material handling projects for a couple of leading companies in the field. This is a long-standing, well-established industry, concerned with moving packages and baggage and loads from one place to another with minimal human effort. If you’re not in the industry, you’ll likely think of it as “conveyor belts”; but there’s a lot more to it. There are conveyor belts, yes, but also…

• Rollers
• Sorters
• Packers
• Stackers
• Scanners
• Lifters
• Diverters
• Carts

And lots, lots more. But yes, it all starts with the simple conveyor belts and rollers that move a box from Point A to Point B.

Except nobody wants those any more. Oh, not nobody, but not enough customers to sustain the industry. Rollers and conveyors from Point A to Point B are a simple, long-solved problem.

No, what customers want today is a system to take a box from Point A to Point Wherever The Label (Or RFID Tag) On The Box Tells Us To Send It. Point A to Point B requires some human to look at the box, decide where it’s going, and put it on the right conveyor. What the customers want is for the computer to “just know” where this box is going.

And it’s more than that: they don’t want the box to have a label that says “Send this to Shipping Dock A”. No, they want it to have a label that says, “This box contains Order #1232. Send it to the right destination.” And sometimes they even want the computer to look at the box and say, “Well, this box contains 50 copies of The Dark Knight, and Tucson needs those; but the truck to Tucson is full, and Orlando needs 70 copies, so we’ll send them there instead, and then reduce Orlando’s outstanding count by 20. The truck for Orlando is at Shipping Dock C, so send this box there. Reschedule Tucson’s fulfillment for their next truck.” In other words, what customers want is not a material handling system, but rather a decision system that controls material handling.

And if your customers want a decision system, that means you’re selling software.

This is news to most of the material handling industry. After all, the hardware to move all those boxes around might range in the millions of dollars, often tens of millions or more. It may occupy literally acres of space. Parts of it may weigh in the tons. Compared to that, the software seems like such an insubstantial, insignificant thing. Even the cost is insignificant, though you can bet the project managers will complain that the cost is too much.

But that’s because – as Josh points out – they see the software as a cost center. It’s not. It’s a profit center. Without that software, those acres of steel and motors and conveyors won’t move those boxes anywhere. Worse, with bad software, they’ll move the boxes to the wrong places. And so without quality software, customers aren’t going to pay for the material handling systems.

Does that mean you’re only selling software? Nope. No line of code ever moved a single box by itself. The code has value because of the sorters and diverters, and the sorters and diverters have value because of the code.

But the difference is this: the material handling project managers know that the sorters and diverters and other equipment are profit centers. They know they’re selling those. But all too often, software is charged as an overhead or a cost center, not a profit center. So rather than try to sell more and better software, they try to skimp on the software costs, cutting schedules and budgets. And as McConnell has documented, the result is usually longer schedules, higher costs, and lower quality.

The software managers in the material handling world need to read Josh’s post, understand it, think about it, and think how they can express the value of their work. A representative material handling system might cost the customer $20 million. If the software to run that system costs $500,000 to build, then cost-center accounting sees that as $500,000 of lost profit. Management will wonder why it cost so much, and wonder how they can cut those costs. What may follow is pressure and effort to cut costs in ways that make software development take longer and cost more.

But if the software managers can see their group as a profit center and can explain it as such to the executives, then the whole picture changes. When they understand that better software leads to more sales or easier sales, executives will want to invest in better software development tools and practices. Josh gives some good starting points toward that culture change. I would add these observations:

• The ROI of software starts with Requirements. Yes, that has become a recurring theme for me. There are good reasons for that. With a foundation of well-defined requirements and a process for accommodating change, software managers can show exactly how much of the customer benefit is directly dependent upon the software. If the system has 100 required functions and 90 of them require custom software implementation, then 90% of the profit of the system is directly dependent upon the software. That 90% is also dependent upon properly functioning hardware as well, so you can’t claim all of that profit as your accomplishment. In the material handling world, I saw a team of nearly 100 assemblers, machinists, construction workers, engineers, and other hardware folks install a system controlled by software written by 10 developers. I think that’s a good rough approximation: software provides 10% of the value of the systems with which it works. (In office systems and other systems not involving device controls, I would say that ratio is more like 50%, maybe higher. This Tablet PC would be useless to me without Windows XP, Journal, OneNote, MS Office, and Visual Studio, which collectively cost more than the Tablet PC.) So in our hypothetical example, the system has a value of $20 million; software is involved in 90% of that value, or $18 million; and software accounts for 10% of the value of those components, or $1.8 million. If the profit margin of the system overall is 50%, then you can argue that the software contributed to $900,000 in profit. These are back-of-the-envelope calculations. A more accurate estimate would require time spent looking at the value of each individual requirement and the percentage of that value contributed by software. But in our hypothetical example, $500,000 of software development costs yielded $900,000 in profit, for an ROI of 80%.
• Hammer home the destructive effects of schedule compression, as described by McConnell. Schedule compression beyond about 20% leads to longer, more expensive schedules with more errors and more dissatisfied customers. If the potential ROI is 80%, the actual ROI will be a lot lower if the schedule compression increases the schedule by 50% and the costs by even more. McConnell explains how this happens, and why it’s almost inevitable.
• There is a way to cut schedules effectively and productively: develop a true software engineering culture and a culture of quality. There is a better way to build software and systems, but “code faster!” isn’t it. Train your teams to be better developers. Improve your requirements process. (No, I’m not done with that theme yet.) Emphasize defect reduction, not schedule reduction, because defect reduction is one of the most effective ways to reduce the schedule.
• Invest for the long haul. Near the end of my first material handling job, the team worked on building a good, well-engineered, reusable and configurable platform that could address a wide range of customer needs. This platform didn’t directly address the needs of any existing customer, so it didn’t receive a lot of management support. Again, this was cost-center thinking: “Why are those programmers wasting money on code we don’t even need?” My second material handling job, nearly a decade later, was with a company which had faced those same issues, asked those same questions, and decided to invest in the software platform anyway. It had some infamous rough spots in its earliest implementations. But by the time I worked there, that baggage handling software was nearly a decade old, and it just worked. Oh, there was always some amount of custom coding for every project; but for the most part, if they knew how many airport docks and how many baggage inducts and baggage claims they had to support, they knew to a high precision how much the software costs would be. And most of those costs were configuration costs. I often said they had Moore’s Law on their side. Moore’s Law says that computing power/speed roughly doubles roughly every 18 months. That means that after a decade of life for that software, server power had increased roughly 128 times; but while airports get larger over time, they don’t grow 128 times in 10 years! The software architecture that was a good solution in 1997 was a great solution in 2007, without any significant upgrade to the software.
• Don’t cling to the long haul. As much as I think the baggage handling company was smart to reuse a successful architecture, you must always consider the competitive advantages offered by new technologies. When the baggage handling company did have to make code changes, their reliance on old tools and technologies made every change more expensive. Periodically reassess the value of an existing investment vs. the potential gains of a new investment.

Vehicle Diagnostic Systems

My most recent contract was a project for building vehicle diagnostic systems. One part of the team built the tool that connected to the vehicle bus and communicated with vehicle systems; the other part built the tools that talked to that tool via Bluetooth and USB, and then interacted with the user and with online systems.

Now with a description like that, you might guess that the company knew they were selling software. And you would be right. Oh, it was a mixed hardware-software product, but they were much more clear on the importance of good software than I found in the material handling world.

And yet – while I mean no offense to a great team and some great people that I’m already missing – the organization didn’t approach this project as a software project. They approached it as a manufacturing project.

A typical mass production manufacturing effort boils down to finding and implementing tools and processes to do the same thing over and over, so that you can sell and serve as many customers as possible for as little cost as possible. The rules are different for custom manufacturing; but for mass production, profit lies in reducing the number and costs of the repetitive parts of the production process.

Let’s say you’re building mailboxes. A traditional home mail box consists of a base, a shell, an end cap, a door, a door pull, a door catch, a flag, a flag stop, two swivels for the door, a swivel for the flag, and 21 rivets:

Every mailbox, according to this design, requires a person or machine to put the parts in place and insert the rivets and swivels. If every rivet and swivel can be inserted in one second and it takes ten seconds to align all the parts, then a single worker can assemble a single mailbox in roughly 34 seconds. If instead the shell, end cap, door catch, and base can be injection molded as a single piece complete with a flag stop and indents where the flag and door attach, and the door and pull can be injection molded as another single piece, then that same worker can assemble a single mailbox in roughly 3 seconds.

But that throughput assumes the worker has materials always ready to hand. Suddenly the process is limited not by the worker’s assembly rate, but by other factors: how quickly can you deliver parts to the worker, and how fast can the worker really work without slowing down due to fatigue? Those questions apply to the riveted design as well, but less so: no matter how fast you deliver the parts for the first design, the riveting is the bottleneck.

Once the parts availability becomes the bottleneck, the industrial process engineer changes focus: instead of trying to improve the design of the mailbox, the engineer must improve the design of the process that delivers parts to the worker. Or perhaps the engineer must design an improved assembly process, maybe improved machinery and tools, that will make less work per mailbox. The company makes money on each mailbox built, not on each step performed by the workers. Whatever your cost and effort is per mailbox, that’s a 1-for-1 cost: one unit of labor per one mailbox sold. If you can reduce that unit of labor, you can increase overall profitability and employ more mailbox workers.

So it’s common for industrial process engineers to invest a large amount of effort designing a more efficient manufacturing process. This effort can be seemingly large; but it’s is a one-time effort. Once it’s done well once, it’s done well for all of the mailboxes produced. So the cost of that process design is amortized over the tens or hundreds of thousands of mailboxes produced, and it reduces the overall cost of production for each mailbox.

This is Industrial Process 101; but here’s where the mistake comes in when you see software development as akin to manufacturing. Software development is like manufacturing, in a sense; but it’s like process design, not piece manufacturing!

The software equivalent of the worker assembling mailboxes over and over all day long is users applying the software over and over all day long. The value to the user (and the user’s organization) increases when the user can get more done with less work, and so get more tasks done in a single day. Just as the industrial process engineer creates value by improving the process and reducing the manufacturing cost, so too does the software team create value by improving the software and reducing the usage cost.

But this means that traditional manufacturing process improvement approaches can be aimed at the wrong targets when applied to software development. In manufacturing, it can be cost effective to spend more money on design process improvement to reduce the money spent on manufacturing; but when traditional manufacturing process improvement approaches are applied to software, often the goal is to spend less money on software development. Yet somehow, we expect those “improvements” to improve the quality of the finished product.

Now I’m not saying there’s no room to cut costs in software development. There are inefficient ways to design industrial processes: if your design team relearned basic facts every time they approached a new production line, or they ignored proven practices from other production lines, then they would waste a lot of time and money on lessons learned and relearned. The same is true for software engineering. Indeed, there’s an entire field of study, Lean Software Development, aimed at improving the development process in a similar fashion to the field of Lean Manufacturing.

But simply applying Lean Manufacturing practices to software development can be misleading – even counterproductive – because Lean Manufacturing aims (in part) to reduce the time required for repetitive processes; and in software development, there are no repetitive processes. Oh, that’s an exaggeration, of course, but it’s close enough to true. Industrial process engineers have repetitive processes, such as reading email, filing reports, printing blueprints, etc. In a similar fashion, software developers have repetitive processes, such as reading email, filing reports, compiling code, etc. But in both disciplines, the key work, the important and most time-consuming work, is brain work: thinking about the problems, proposing ideas, presenting ideas, reviewing ideas, revising ideas, etc. And this is work that virtually never repeats! It will repeat if you keep reinventing the wheel; but a good team should know standard patterns and solutions for common problems, so they can concentrate their efforts on the unique aspects of a new project. The truly repetitive processes – checking email, compiling code – are more amenable to fiscal solutions than process solutions. Buy your developers faster computers and better tools: it’s the closest equivalent to getting the mailbox worker a faster assembly tool.

And I’m going to repeat myself yet again: the most productive way to reduce the cost of software development is to improve your requirements process, followed closely by creating a true software engineering culture and a culture of quality. Those are goals of Lean Software Development and are consistent with Lean Manufacturing. Interestingly enough, they involve creating quasi-repetitive processes: standard processes for doing standard categories of work, while recognizing that ideally no work should ever be repeated. A standard way of testing code, a standard way of reviewing code, a standard way of communicating designs: these can add value if done right. However, they can also become straitjackets that prevent a team from solving a problem. I have a lot more to say on the value of quasi-standard quasi-repetitive processes; but that’s starting to veer pretty far from our topic today.

And that topic, you’ll recall, is ROI. It’s easy to figure the ROI of industrial process engineering:

ROI = (New net profit per part – Old net profit per part) * Number of parts produced / (Cost to design the new process + Initial cost to implement the new process) – 100%

This gets slightly more complex when you factor in time: Number of parts produced in how much time? In early usage, you’ll almost always see a negative return, because (as Josh mentions) there is a certain length of time it takes to recoup the initial investment. Businesses will usually set a time horizon in which to estimate ROI: 1 year, 3 years, maybe longer.

A similar calculation applies to the ROI for better software:

ROI = (New net value of work per user – Old net value of work per user) * Number of users / (Cost to develop the new software + Initial cost to deploy the new software) – 100%

But there’s a complication here. In the typical industrial situation, the same company is both designing the new process and manufacturing the parts. The ROI value is more clear-cut that way, because what matters most is the overall bottom line for the company. The same is true for in-house software development; but when you’re selling custom or shrinkwrap software to external customers, the value of the work and the deployment cost are measured by the customer, while the cost to develop the software are measured by your company. That’s a complication, but more of a deal negotiation concern than an ROI concern. The calculation in this case turns into two calculations:

Customer’s ROI = (New net value of work per user – Old net value of work per user) * Number of users / (Cost to purchase the new software + Initial cost to deploy the new software) – 100%

Your ROI = Cost paid by Customer / (Cost to develop the new software + Initial cost to deliver the new software) – 100%

The Customer’s ROI, along with many other factors, will determine what cost they’re willing to pay; and then that value will determine your ROI. You can make educated guesses of what they’re willing to pay, and then use those in estimating your ROI. And remember: just as with industrial process engineering, the initial return will almost always be negative. You have to prepare your arguments for that moment, when it seems like the system cost a lot and is too difficult to use. Is it really too difficult? Or is it just new and unfamiliar? Unless you’re very good at defining and communicating your requirements, users will always see “new” as “difficult”, and then cling to old and familiar; and in the process, they forget that the old was once new and unfamiliar, too. That’s why these ROI calculations include a deployment cost: that’s not just a cost for physically shipping and installing the code, but also for training the users and answering their questions and correcting their early mistakes. And lest we forget: finding and correcting our early bugs, and deploying corrections for those as well.

Conclusion (For Now)

Well, this has gone a lot further afield and gotten a lot wordier than I originally expected. (Regular readers are probably less surprised than I am.) I could go further, discussing ROI for training, ROI for technology upgrades, ROI for requirements analysis, ROI for architecture, ROI for community involvement, and ROI for employee retention. But each of those is a lengthy essay in its own right, and I’ll need some research before I’m ready to tackle some of those.

But I hope I’ve added some personal experience to Josh’s excellent post. Many projects can be technological successes, yet be seen as costly, not as a valuable investment. The difference: do we calculate and demonstrate an ROI? Or do we let stakeholders see only the cost of the software, without seeing the full return on the software?

posted @ Tuesday, February 24, 2009 3:33 PM | Feedback (0) |

The Analyst's Chorus

I am the mirror, reflecting what you say to me.

I am the mirror, I’ll show you where you want to be.

Talk to the mirror, I’ll tell you what you really said.

Look in the mirror, I’ll draw the picture in your head.

There in the mirror: it’s what you didn’t know you knew.

I am the mirror, and I’m listening… to you.

posted @ Friday, February 20, 2009 4:00 PM | Feedback (0) |

Requirements Patterns and Antipatterns: Checklists

Scoring the Checklists

Each checklist is scored on a 0 to 100 scale.

Point Lists

Point Lists apply to your entire requirements process. Each checked item scores a certain number of points. Check each item that applies, and sum the point points to get a score from 0 to 100.

Sample Point List: Feeding the Dog

□ 50 You have dog food; or you have table scraps.

□ 30 You have the dog.

□ 20 The dog is hungry.

____ Total

In some cases, the list potentially sums to greater than 100; but 100 is the maximum score in any case. For example, the Verification Checklist for Pattern 6, Trained Analysts, provides 100 points for dedicated analysts and 50 points for developers trained in analysis techniques; but a team with both still scores only 100 points.

Percentage Lists

Percentage Lists apply to your set of requirements, or perhaps to a set of one kind of requirement. Each requirement item is scored a 1 if it meets the criteria, or a 0 if it doesn’t (no partial credit allowed). Your score is the percentage of requirement items that scored 1 vs. the total number of items.

Sample Percentage List: Feeding the Dogs

%__ Percentage of all dogs which have been fed.

Partial Percentage Lists

Partial Percentage Lists are Percentage Lists that allow for partial points. Each requirement item receives some number of points based on various questions; and then you determine the percentages that meet different point scores. Full points count for full percentage; but the percentage of partial points are divided to yield a lower score. The final score is the sum of these adjusted percentages.

Sample Partial Percentage List: Caring for the Dogs

□ 1 The dog is fed.

□ 1 The dog is groomed.

□ 1 The dog is exercised.

%__ Percentage of dogs which score 3 out of 3.

%__/2 Percentage of dogs which score 2 out of 3.

%____ Total

posted @ Sunday, February 01, 2009 1:43 PM | Feedback (0) |

Pattern 19. Requirements Archaeology

Problem:

The project is to supplement, upgrade, or replace an existing system, which is the de facto primary source of your requirements.

Context:

Solution:

Reverse engineer models (see the Modeling pattern) and specs for the current system, and review those to identify requirements. Then analyze and organize those “uncovered” requirements, and present your results back to your customer as a form of The Echo Effect. Be ready for your customer to be surprised, as you reveal features they’ve long forgotten, never known about, or just taken for granted. Listen for them to identify legacy features that they don’t need replicated or supported, and then explore those features to be sure there’s nothing there that other features depend upon.

But you need to go beyond such mechanical reverse engineering for two reasons.

1. It’s far too coarse, as our archaeology metaphor shows. Imagine the look on an archaeologist’s face if a contractor showed up at a dig site and said, “Hey, I’ll dig up this whole excavation for you. Let me get my bulldozer.” While mechanical reverse engineering isn’t destructive like the bulldozer, it’s not much more discriminating. The bulldozer piles up a great big heap of earth and stone and rubble, while the mechanical tools pile up a great big heap of classes, relations, tables, columns, nodes, and other artifacts. If you don’t sift through the rubble, you really haven’t learned anything.
2. In my UML classes, I teach that UML isn’t about software design, but rather about system design, where a system is structure with behavior and goals. Well, I’m missing something in that definition: a system is structure with behavior that fulfills some intention. A good mechanical reverse engineering tool should produce a structural model of a legacy system. Modern tools shed a little light on the behavior model of a system. But only a human reader can produce “intentional” models. A mechanical model captures Functional Requirements at best; but an intentional model captures the User Requirements, Business Requirements, Non-Functional Requirements, Constraints, Actors, and Domain Objects that are represented by the Functional Requirements. (See the Categorization pattern for a discussion of these types of requirements.)

There must be new requirements, right? You’re not just replacing the existing system for something to do, right? There should be some reason for replacing it: porting to a new platform, better maintainability, better extensibility, or something. If you’re just suffering from replacement-itis, you should read Joel Spolsky’s essay on rewriting.He makes a good argument for preserving the hard-earned knowledge embodied in legacy systems, and the consequences of replacing working code without a business case.

Discussion:

See also Modeling, The Outline Effect, and The Echo Effect for patterns that work well with Requirements Archaeology.

posted @ Sunday, February 01, 2009 1:13 PM | Feedback (0) |

Ulterior Motive Lounge Episode 31: The Teams Split Up

Continuing The Project That Time Forgot, a UML case study in comic strip form... (Click pictures for larger images.)

After a long hiatus due to weather, illness, work, conferences, and more stuff than I can explain, the Lounge is back.

This Episode gets the ball rolling for Act II, so there’s not much new UML content here yet. But I can give you a few diagrams of the team’s review process. The process starts with some preliminaries, then splits into three threads of operations, each with a separate team:

• Design Review. This team, led by The UML Guy, will create a Design Assessment, summarizing the state of the design and any clear risks and concerns. The details of the Design Review look like this:

• Review the original design spec to determine the intent of the original team.
• Review design documents and updates since the original spec.
• Reverse engineer a design from the code. A good UML tool like Enterprise Architect makes this a lot easier, but not easy. VSTS 2010 will make it even easier, but still not easy. Incorporate this into a design summary.
• Review the design with the dev team and revise until it’s ready for presentation.
• Review the design with the full review team and revise until it’s ready for assessment.
• Create the design assessment.
• Functional Review. This team, led by Geek Girl, will create a Functional Assessment: a description of how well the system performs existing functions, with emphasis on usability and correctness. The details of the Functional Review process look like this:

• Review the existing requirements docs.
• Review outstanding defect reports, and make those the beginning of a functional assessment.
• For each function identified in the requirements, identify actors and user who represent those actors. Interview those users to determine how well the system really works, and update the functional assessment.
• Requirements Review. This team, led by The Reader, will create a Requirements Assessment: a description of what requirements the system covers; and more important, what it doesn’t cover. The details of the Requirements Review process look like this:

• Review the existing requirements docs.
• Assess the quality of the existing requirements. Are they quantified? Are they testable? Are they unambiguously stated in words, diagrams, and tests? Are they assigned business values and priorities? Do they have clearly identified actors and use cases and scenarios and goals for each feature? These and many more questions will help to create the requirements assessment.
• For each actor represented in the requirements or discovered during interviews, identify and interview representative users. Determine whether they have missing requirements, as well as whether they know of or require previously unidentified actors.

For a really thorough review, you probably need at least three more threads of activity:

• Code Review to inspect the code, either completely or through sampling, to identify how well it’s constructed and maintained.
• Quality Review to identify Quality Assurance measures, Testing measures, and the status of each.
• Process Review to analyze the processes followed by the dev team and related teams.

But for simplicity (and to keep most of my focus on my primary message), I’m going to restrict this case study to Design, Functionality, and Requirements. Code will be reviewed under Design, and Quality will be reviewed under Functionality. Process will be reviewed everywhere.

Is this a lot of work? Yep. But it’s a minimal necessary set of activities to review a project for status and risks after you’ve ignored them for a long time. It would be so much easier if you could do these sorts of assessments in real time right from the start as the project proceeds. It would be so much easier if you could report the status and health of the project at the push of a button, based upon the actual work the team does as they do it. Gee, wouldn’t Owner’s life be a lot easier if there were tools to do all that?

Oh, wait a minute… There are tools like that! In fact, there’s a whole category of such tools: Application Lifecycle Management (ALM). And my current favorite is the aforementioned Visual Studio Team System, perhaps the most poorly named product Microsoft produces today. Why poorly named? Because Visual Studio is a developer tool set, particularly a tool set for .NET developers; so when people hear a name like “Visual Studio Team System”, they assume it’s a developer tool set, only bigger and better. They assume it’s about .NET development.

VSTS is not about .NET development. Oh, VSTS includes Visual Studio, and then adds some powerful developer and architect and DBA and tester features; but those features, as powerful as they are, are just the icing on the cake.

The cake is ALM. VSTS is about your process and how you can define it and design it and manage it and track it, all through tools your team – your whole team, not just .NET developers – are already using. Your Project Managers can create task lists and project plans in Excel or Project. Your developers can work on those plans in Visual Studio – or not! If they’re working with Eclipse or other non-.NET tools, developers can use TeamPlain to access their work items. Testers can create and apply test plans. Executives can view summaries and reports and Key Productivity Indicators (KPIs) through a project Web portal.

And all of these tools are updated automatically as the team works, in real time, through the Team Foundation Server: a powerful set of databases, reports, services, and tools that integrate with Excel and Project and Visual Studio and Sharepoint and other tools to provide a seamless process involving all participants.

I didn’t intend this post to turn into an ad for VSTS, so I’ll leave you to explore further if you like. But I can tell you this: even if Owner had known about VSTS, even if he could’ve convinced Cowboy Consultant to look at it, they would’ve turned it down. Owner already balked at spending proper time and money on requirements and design. Cowboy Consultant already demonstrated that he has no patience for anything beyond the code itself. Well, as powerful as VSTS is, it’s not cheap (though I think it’s well cost justified), and it takes time and effort and training to use it properly. They both would’ve written it off as needless overhead, judging by the attitudes we’ve seen so far.

And those attitudes are going to lead to some mighty big problems pretty soon. Dinosaur sized, even.

One final note on today’s Episode. You may wonder why Dog is going out into the Park with The Reader and Stick Boy. Well, she’s a dog. She smells things, really interesting things. She wants to investigate, not hang around in some sterile, air conditioned computing center. Dogs gotta be walked, ya know?

posted @ Saturday, January 31, 2009 12:59 AM | Feedback (0) |

Ulterior Motive Lounge: A Map of Carnivore Park

As I’ve written elsewhere, I love maps. And I love a story that includes maps. Maps help me to see where the action takes place; and they give me tantalizing clues to action yet ahead. When I first opened a hardcover of The Hobbit and unfolded the big map of Wilderland, I was hooked.

So for those who love maps like I do, here’s a map of Carnivore Park. (Click picture for a larger image.) This is where the rest of the story takes place; and following it is a map guide that may contain clues to what lies ahead.

Carnivore Park lies within a dormant volcanic island, bought and run by Owner. The volcano cone makes a natural barrier to dinosaurs – and to prying eyes, of course. The west end faces open ocean. The east end faces Central America, though a long way away. The east end beach has been artificially built up, along with two breakwaters. A concrete apron allows cargo and passengers to disembark and take the switchback up the slope to the entrance to The Park.

The interior of The Island may seem natural, but it’s actually nearly 100% sculpted or planted. The topsoil has been imported from rich fertile swamps on the mainland. The river has some contribution from springs and runoff, but is heavily fed by a hidden desalination plant. The ridge through the Park is actually a concrete wall, with interior chambers and bolt holes. The plateaus of the visitor center are partly natural, but largely shaped concrete. Roads run along the ridges, sometimes fenced from the dinosaurs, sometimes separated by “natural” barriers, and sometimes exposed.

The Visitor Port

Ship and helicopter landings.

Carnivore Park

The main park buildings reside on a set of artificially enhanced plateaus. Trees and other obstacles are carefully arranged to block any view of dinosaurs from the Pavilion or the rest of the control area; but the Lodge is elevated so that the higher (and more expensive) storeys have a view into the main Park.

The Pavilion

This is the entry to the Park. It includes the Operations Center, the Gift Shop, the Quick Bite Café, the Boring Exposition, and the Laboratories.

Gift Shop

Souvenir shop. Sells Park merchandise. Also sells LoungeWare.

Quick Bite Café

A cafeteria.Specializes in curried “dinosaur” dishes (actually chicken).

The Boring Exposition

Auditorium named for Wayne H. Boring. Used for reviews and presentations.

Operations Center

The nerve center for the Park.

The Laboratories

A sign on the door reads “Here there be dragons!”

The Lodge

Guest lodging at the Park. Across from The Pavilion.

Drumbeats

Nightclub at the top of The Lodge.

The Food Chain

Restaurant in The Lodge.

The Pool

A place to unwind when not out seeing the dinosaurs.

On The Rocks

Bar near The Pool.

The Petting Zoo

An area near the Pool where small, cute dinosaurs are available for petting and feeding.

The Park

A giant, dormant volcano cone, perfect for confining dinosaurs.

The Garden

Where the herbivores run “free”. Visitors can approach by ascending walking trails.

Carnivore Country

An area where various smaller carnivores roam.

Rex’s Crib

An area set aside for Tyrannosaurs Rex specimens, including extra reinforced fencing and other safeguards.

Raptor Country

An area dedicated to Velociraptors and their prey.

The Backlots

Fenced areas deep within the public viewing areas, well-screened by trees. These are areas where workers prepare and care for dinosaurs (and dinosaur meals) before release into the viewing areas. Each has a number of isolation pens, carefully screened by trees from other pens.

River Country

A boat tour (not yet approved by Money Man) through swamp and river dinosaur habitats. Also passes through The Glasshouse.

The Glasshouse

A large glass enclosure for flying dinos.

The Power Center

Includes a geothermal power station, water pumps, and fence control.

posted @ Saturday, January 10, 2009 1:35 AM | Feedback (0) |

The U-Shaped Curve (A few more reasons why Coding Geekette is right)

posted @ Friday, January 09, 2009 1:18 PM | Feedback (5) |

Ulterior Motive Lounge Episode 30: Touring the Laboratories

Continuing The Project That Time Forgot, a UML case study in comic strip form... (Click pictures for larger images.)

Here, for your convenience, is a larger version of the activity diagram from panel 2:

Figure 1: The Recipe for Growing a Dinosaur

And here is Editor Bill's comment on that diagram: "I hope in the commentary you plan to explain that this activity diagram tells the story of the rest of the Episode." Well, no, Editor Bill. I hoped that by now my readers were UML-savvy enough to figure that out on their own. You're not the only smart reader I have, you know? (Bloody Editor Bill's too smart, keeps figuring out my strategies before I can reveal them. Next thing you know, he's gonna grab my drawing pen. Uh-uh, no way, Editor Bill! This pen is mightier than the sword!)

That diagram is also almost a logical sequencing of the use cases from this diagram from the previous Episode:

Figure 2: Geneticist and Embryologist Use Cases

But that's a use case diagram, and the new diagram is an activity diagram. Which is the right way to show this information? Should we draw use cases, or should we draw activities?

Those who know me might guess that my answer is: Yes. (They've heard it too many times: "Whenever you ask me 'A' or 'B', I'll always answer 'Yes' or 'C'.") But in this case, my answer is more nuanced: "Whichever one communicates better; and that may mean drawing both of them." Which of course is a longer way of saying "Yes."

As I mentioned in Q&A #2: Battle of the Twitter Guest Stars!, one purpose for an activity diagram is to show what happens "inside" a use case. So the Figure 1 could be a diagram of what happens within this hypothetical use case:

Figure 3: The Grow Dinosaur Use Case

Why do I call this a hypothetical use case? Well, to my way of thinking, it's rather large. Based on what The UML Guy has learned about the laboratories, the process from DNA extraction to a dinosaur ready for release into the Park consists of multiple complex operations, possibly iterations of operations, over weeks to months. I like my use cases to be a lot smaller and more atomic than that. The use cases Isolate Sequence, Replicate Sequence, etc., look a lot more like use cases to me. Grow Dinosaur looks a lot bigger, like some large scale business process.

But here's where it gets a lot more complicated, and where I have to stop giving you easy answers. More important, I have to stop giving you just my answers, because I don't want you to be limited by my biases. I want to suggest other ways of looking at use cases. In fact, I'm seriously hoping that some of the Business Analysts in my audience will add comments and start a discussion, so that the rest of you can see the gamut of approaches to use case modeling.

Because here's the thing: many Business Analysts, including many I respect a lot, would say that Grow Dinosaur is about the right size for a use case. In fact, some might even claim that it's too small, and would prefer a more generalized use case like Care for Dinosaurs.

I once heard an experienced analyst say confidently he had worked on a very large system for a client, the largest system he had ever worked on. In fact, it was so large, it had fifteen use cases! Oh, that was for the entire business operations of a multinational corporation, so it had to be big. But just imagine, he said, fifteen use cases!

And I once heard another experienced analyst say just as confidently that the user interface he was modeling wasn't very complex. After all, it wasn't much more than a dozen or two use cases. That's tiny, right? He was used to working with 80 use cases in a system.

And here's the kicker: those two analysts, one who saw 15 as unimaginably huge and one who saw 24 as kind of small, worked for the same very respected consulting company.

In other words, there’s a lot of disagreement in the analyst community over the right level of granularity for use cases. Some see use cases like Shipping and Manage Personnel and Manage Facilities, while others see use cases like Order Supplies and Schedule Repairs. Some see use cases in individual button pushes. Who’s right? I dunno. I gave up trying to answer that question a long time ago. I listen to one point of view, and I say, “Hey, those arguments make a lot of sense!” Then I listen to another point of view, and I say, “Hey, those arguments make a lot of sense!” And then I put them together, and I say, “Hey, this doesn’t make any sense…”

I’ve decided that the difference isn’t in right or wrong, it’s in what level the analyst thinks at and is comfortable thinking at. Those who think at the enterprise level see enterprise use cases like Shipping and Manage Personnel and Manage Facilities. Those who think at the project level see project use cases like Order Supplies and Schedule Repair. Those who think at the UI level see use cases in individual button pushes. And all of those levels are valuable, and none is “right” or “wrong”.

But there’s probably a big difference in the level of documentation for different levels of use cases. The exhaustive level of detail prescribed by, say, Cockburn’s Writing Effective Use Cases may be appropriate for a use case like Manage Facilities; but it’s massive overkill for a use case like Log In. Business analysts have told me horror stories of 15-pages of documentation for Log In; and I’m fairly sure it’s because they were applying enterprise-level documentation practices to application-level use cases.

So in sum, I find the argument over the “proper” granularity of use cases to be pointless. Oh, for a given analysis project, that argument matters: an enterprise analysis effort can’t afford to get bogged down in use cases like Log In and Change Password, or they’ll have thousands of use cases; but an application analysis effort needs more detail than Manage Facilities (and less detail than 15 pages on Log In). But when I see arguments over the “proper” granularity, I can usually resolve them by discovering that the parties arguing are working at different levels.

And far more useful to me is this simple fact: the use case strategy, the use case way of thinking about requirements and solutions, is powerful at all levels of analysis. I’ve used this strategy from way out at the enterprise level all the way down to the level of individual classes. This strategy of saying “Who needs some work done? What’s the work? Who else participates? What information or objects are involved and affected?” has great probative power. If you want to say that Order Supplies isn’t a use case, fine. Call it a feature. Call it a function. Call it a benefit, an operation, a a method. Call it an Apatosaurus for all I care. I don’t care what you call it; I care how I think about it and describe it and figure out how to resolve it. And how I do that is the use case strategy. I’ll call it a use case, and you can laugh at me if you like.

But those who adamantly insist on a “proper” granularity will often also insist on a rule: “Thou shalt not decompose use cases.” And I’m going to completely ignore them when they say that, because to me it means, “Thou shalt not examine use cases at one level and think how they may be realized via use cases at a deeper level.” And as much as I’m loath to use such a black-and-white word as “wrong”, that’s just wrong. When I start to think about the problem at a deeper level, I will think about finer-granularity use cases that make up the use cases from the upper level. For example:

Figure 4: The Grow Dinosaur use case, plus detail use cases

In this use case diagram, I introduced some new UML notation: I added two boundaries. A UML boundary is just a box that groups related diagram elements. In this example, the boundaries represent two different perspectives on the system. Operations needs a strategic view. To them, growing a dinosaur is one task they want carried out: “Yeah, this is Ops Chief. We’re ready to start planning the Back Lot now. Could you start growing us some Velociraptors? Thanks!” From that strategic view, Grow Dinosaur is one use case. Meanwhile, the Laboratory sees a number of complex operations that they carry out on different samples and eggs and newborn dinosaurs. From their more tactical perspective, there are many dinosaur-related use cases. So I used the boundaries to help separate these perspectives while still showing them on a single diagram. To me, there’s great value in thinking at the strategic level and then moving to the tactical level, and even deeper. That means there’s great value in decomposing use cases. Others are free to disagree, but I’m going to keep doing it.

Other comments on today’s Episode…

• Why does Dr. Gene carry around a giant DNA strand? Because I like it! It started life as the spiral staircase from Episode 25; and from there, it kind of grew unexpectedly. Sometimes things grow beyond our plans, and the unexpected happens. The same thing has been known to happen with dinosaur parks. And with comic strips…
• Yes, I have seen UML diagrams adapted into marketing materials. After all, if a diagram communicates, it may communicate to the audience as well. Of course, most UML tools produce kind of bland diagrams, so the art department usually jazzes them up to the point where the modelers may no longer recognize them.
• Editor Bill immediately saw the bad joke in panel 5; and he liked it, so I kept it. You can blame him. (But he wouldn’t let the crocodile say, “Ow!”)
• Cladistics is the hierarchical classification of species based on evolutionary ancestry. You examine the DNA of different species and determine how closely related they are and when they diverged evolutionarily by how closely their DNA matches. It’s also the subject of a fascinating essay by Stephen Jay Gould. (“A fascinating essay by Stephen Jay Gould” may be one of the greatest redundancies I’ve ever written.) To my knowledge, there’s no such thing as cladistic reversal, but it seems like a really clever idea for recreating ancestral DNA by isolating it from descendant species. Hey, you have a better idea for growing dinosaurs, fine, you can open your own park. In my Park, they use cladistic reversal!
• While cladistic reversal is fictitious, the lab equipment in panel 6 is certainly of the highest quality.
• In the second page, notice that many of the dinosaurs have the Name : Class format for their labels, such as we first saw in Episode 15. Remember that we typically omit the name if there’s only one instance of a class in a diagram, particularly if the diagram shows what is true for all instances of the class. But when we want to examine different instances – in this case, different dinosaurs – and tell them apart, then we add names.
• Despite the name (Carnivore Park), all of the dinosaurs in that last scene are herbivores. This is the safe, open section of the Park. Trust me, the carnivores are coming in Act II!

posted @ Wednesday, January 07, 2009 2:22 AM | Feedback (1) |

Manager Rob, The Turtle, and The Tree

Been swamped with work and holiday and illness, too swamped to do a Lounge Episode or anything meaty. So instead, I offer up the best laugh I've had all week: the story of Manager Rob, The Turtle, and The Tree.

There are several things I must say before I get to this story:

• Manager Rob is not the Boring Manager Rob from Jonathan Coulton's Code Monkey. In fact, he gets quite annoyed when I even call him Manager Rob. He's lead programmer on my current project; but due to organizational definitions, that makes him technically a manager. He's not happy about that.
• This is absolutely Rob's story, not mine. I'm just retelling it because I got a laugh out of it. All credit for laughs go to Rob. If you have yawns, they're my fault, because this was hilarious when Rob told it.
• Parts of this story are kind of vague, for reasons that will be revealed. And I can honestly say of Manager Rob that he's feeling much better now...
• The reasons yet to be revealed have nothing to do with alcohol nor any illegal substances. As will be revealed, Manager Rob has a police report to back him up on this claim.

So one day in their reckless youth, Rob and his friend Dusty were driving home from a morning event. (I know it was morning, because they hadn't eaten their lunches yet, as will be revealed.) While no alcohol was involved, they did have the irresponsibility of youth working against them. Both were in shorts and barefoot as they drove. In Michigan, at least, that's a reckless driving ticket in itself. Neither was wearing a seat belt. That's another ticket in Michigan today, though it wasn't then.

Dusty is apparently kind to small children and woodland creatures. I know this, because I try to be kind to small children and woodland creatures, and Dusty outdid me. If I see a turtle crossing a road, I'll stop and help it across. But Dusty went much farther: when he saw a large snapping turtle crossing a nearby ballfield, he decided that turtle needed help. He determined that she needed to live in the lake near their homes. So Dusty had Rob stop the car, and he ran out to the field, picked up the confused turtle (who promptly withdrew into her shell in fright), and set her down on the bench seat between them. Their good deed for the day done, Rob set off down the road again.

Now some turtles might've continued to cower; but that's not in the nature of snappers! No, once she got over the immediate fear, the first thing she did was to stick out head and legs and scurry off the seat and into the driver's side footwell, along with Rob's bare legs and feet. Rob yelled. The turtle scrambled. Dusty scrambled after the turtle. And none of them noticed the curve in the road ahead, nor the ditch that lay beyond that curve, nor the tree that stood in wait for anyone foolish enough to miss that curve.

What happened next, Rob can't exactly say. The reason why he can't say has much to do with the head-sized dent he left in the roof of the car. Today, he's one of the brightest developers I know, so I can testify that he has fully recovered from his concussion; but as he says, some memories of that day just never got written to permanent storage. (Yes, Rob's a geek.) But as best Rob can reconstruct... When the car dipped into the ditch at 60 MPH, Dusty was leaning across the seat, looking for the turtle. The initial jolt tossed Dusty over the bucket seat and into the back seat. Meanwhile, the same jolt launched Rob into the air hard enough to dent the roof with his skull. And while I hate to discourage seat belt use, on that occasion their recklessness probably saved both their lives. While Dusty was tumbling and Rob was airborne, the car hit the tree at some significant fraction of 60 MPH. The dashboard and firewall were driven all the way up to the seat.

The next thing Rob remembers is laying in the passenger seat and realizing there was an accident. He remembered nothing, but the evidence was incontrovertible. He tried to open the door, but couldn't. He rolled down the window. He knows he intended to climb out.

The next thing Rob remembers is sitting on a picnic table bench while the homeowner asked if there was anyone else in the car. In later conversation, Rob learned the homeowner helped him out the window and to the table, but Rob remembers none of that. Rob couldn't remember who would be in the car, but he was sure someone was. The homeowner checked and said there was a blonde guy in the back seat. Rob remembers being confused why Dusty would be in his back seat. Then he remembers how comfortable the grass looked as he lay down on it.

The next thing Rob remembers is being strapped onto the gurney. The police asked him what happened, and Rob was too confused to answer. That led to an immediate reckless driving ticket. Then they took Rob and Dusty (whose nose was pretty smashed) off to the hospital.

When Rob's mom got to the hospital, she told Rob the accident site had been cordoned off as a crime scene. The police were doing a meticulous search for alcohol or drugs. With Rob's and Dusty's lunches strewn around, there was a lot to investigate. Later, Rob's mom had further news: the police were somewhat annoyed to find nothing more they could charge them with. There was not a sign or alcohol or drugs to be found. The reckless driving charge stuck, but that was it.

And she had one more bit of news. "Oh, they found a turtle under the seat." The turtle escaped unharmed.

No turtles were harmed in the making of this story...

posted @ Friday, December 26, 2008 5:34 PM | Feedback (0) |

An Argument for Requirements Analysts

An attempt to trade quality for cost or schedule actually results in increased cost and a longer schedule. Steve McConnell,  Professional Software Development

What has long been known in other businesses is true for software development as well: if you cut corners for shorter schedules or lower costs, you will get longer schedules, higher costs, and higher defect rates; but if you take the right measures to lower defect rates, you can get lower defect rates and shorter schedules and lower costs. As Crosby wrote, “Quality is free.” But it’s free only in terms of ROI, meaning the investment must be made first; and it’s only free if you first define what you mean by “quality”.

Poorly defined requirements are endemic to the software development industry. Boehm’s research on factors that affect development schedules and costs show that:

Again and again, schedule pressures lead teams to start developing before they have sufficient requirements definition.

Among all personnel factors, Analyst capability has the widest range of impact (multiplier range of 2, worst case divided by best case). Teams may tout their application experience as a strength; but application experience has an Influence Range of only 1.51. Application and platform experience combined have an Influence Range of 2.11. Teams would never throw out their domain knowledge and develop for an entirely new platform; but poor requirements practices have almost the same Impact Range.

These teams aren’t foolish, yet they foolishly let a critical aspect of their process get out of control on project after project. A look at their team rosters may give a clue as to why: while there are many roles on the rosters, there may be none with requirements as a primary responsibility. Marketing and sales have requirements responsibilities, but many conflicting responsibilities as well. Lead engineers are supposed to verify requirements; but they are also too busy, and are commonly focused on solutions, not requirements. Designers and developers also focus more on how than on what. Traditionally in software development, analysts have primary responsibility for and are evaluated on the correctness of requirements.

The role of requirements analysts is
to define the problem in a verifiable form,
so that teams may recognize a valid solution.

And next you must ask: who owns that responsibility in your organization? If the answer is "no one" or "I don't know", there's a ripe opportunity to cut your schedules by 30% to maybe even 50%, all while improving your quality.

Code is not enough. It's all about requirements; and that's all about communication.

posted @ Tuesday, December 16, 2008 6:11 PM | Feedback (11) |

Ulterior Motive Lounge Episode 29: Touring the Pavilion

Continuing The Project That Time Forgot, a UML case study in comic strip form... (Click pictures for larger images.)

“We grow dinosaurs!” Big whoop, huh? Like anyone reading the strip hadn’t figured that out before I started Scene 1… It’s hard to surprise the characters in a story when the audience can tell from the promos what the surprise is.

But since The UML Guy has been part of the project before, none of this was a surprise to him. So while the others were taking in the new sights, he was drawing more UML diagrams. His results follow.

We learned a few more specific kinds of scientists on the project:

We added one more category of Employee Actors, Information Staff:

If you’ve ever eaten at a restaurant – certainly if you’ve ever worked at one – you’ll realize we need more detail in our set of Concession Actors, starting with a Restaurant Manager:

And then more specific Restaurant Staff:

We also learned of more systems we’ll need to support the functions described in the Episode:

We added an Information Console, a Laboratory Server, Laboratory Computers, Laboratory Devices, a Commerce Server, and Cash Registers. Note that the Commerce Server has to communicate with the Warehouse Server to schedule deliveries to the rooms and to the mainland.

These new systems complicated the physical Deployment Diagram almost to the breaking point. It’s complex enough that The UML Guy plans to group it, simplify it, and turn it into multiple diagrams when he gets time. But for now, here’s one more look at the single diagram:

We added some new Use Cases for Driver:

And for Guest:

One of those Use Cases, Make Purchase, is complex enough to deserve a dedicated diagram:

We can see from the Episode that there are multiple Classes of souvenirs:

And finally, we have new Use Cases for the Geneticist and the Embryologist. Normally, The UML Guy prefers a single diagram per Actor, focused on the Use Cases for that Actor; but in this case, the Use Cases are closely related and work with related Domain Objects. So he combined the diagrams for now, but may split them later:

That’s it for new UML content for this Episode. Oh, The UML Guy could imagine more, such as Use Cases for the Restaurant Staff and the Souvenir Staff; but Owner just didn’t give enough detail to work with. Those will come out over time.

Other comments on this Episode:

• The sign post in panel 2 probably ought to include Seoul, Ottumwa, Mill Valley, Boston, and Crabapple Cove; but that would’ve made it unreadable.
• It’s not the Dino Dog that’s bothering The Reader in panel 6, it’s the curry. The fastest way to drive him away is to serve him curry. But boy, curried chicken sausage sounds good to me right now!
• Since you insisted (I know you’re thinking it, here’s the recipe for Yabanapple Soup:

Yabanapple Soup (Serves 4)

3 large ripe bananas

1 large sweet potato (sometimes called a yam in America, but not the same as yams elsewhere – it’s a whole different genus and species)

1 large can of chunk pineapple, drained

2 large cans of whole coconut milk (skim if you prefer)

3 tablespoons of honey

1 dash cinnamon

1 dash nutmeg

1. Clean and peel the sweet potato.
2. Boil a pan of water. When boiling, add the sweet potato, and boil until slightly soft. Remove from heat and drain.
3. Peel and slice the banana into quarter-inch slices.
4. Slice the sweet potato into quarter-inch slices, and then into chunks.
5. In a sauce pan, mix coconut milk, sweet potato chunks, banana slices, pineapple chunks, honey, cinnamon and nutmeg. Heat until simmering.
6. Serve hot; or chill and serve with a scoop of ice cream.

• Boy, those are some cool-looking souvenirs in panel 7. Let’s take a closer look:

Wow! Too bad this is just a comic strip, not the real world. Wouldn’t it be great if there were a place where you could buy LoungeWare, especially just in time for Christmas?

• Wayne H. Boring was a famous and popular Superman artist. I love his work, and I couldn’t resist borrowing his name for the pun in panel 8.

Next Episode: a tour of the Labs!

posted @ Monday, December 15, 2008 8:03 PM | Feedback (0) |

Not that I'm ungrateful, but I think you're in the wrong place...

In an effort to understand and better serve my readers, I keep an eye on my referral logs. I like to know who likes what they read here, and then learn what else they read.

But this one has me boggled. One of my most recent referrals is from the headlines page for fanpop's community for The L-Word. It's a link to my recent post for Ship It On The Side.

I appreciate the link. Really, I do. But this site has pretty much nothing to do with the lesbian scene in L.A. Sorry.

posted @ Saturday, December 13, 2008 6:42 AM | Feedback (0) |

Ship It On The Side Episode 3

posted @ Thursday, December 11, 2008 1:45 AM | Feedback (0) |