It seems that every few years our industry greets yet another link in the evolutionary chain representing the art and science of software design. With each new methodology that graces the bookshelves of techie bookstores everywhere, we benefit by the additional perspectives and techniques offered. Coalescing vague user requirements and the ever present marketing wish lists into a single, detailed design document that can actually be brought to life as a software system is no less challenging than trying to simultaneously give nine excitable housecats a shampoo in your bathtub. It can be done, but it ain't pretty.
From waterfalls to structured techniques all the way to our currently beloved object oriented analysis and design, we've seen a lot of approaches to tackling this problem. For my money, there's still charm and grace in the lowly cocktail napkin, but I freely admit that my prejudice may have something to do with the beverage that's served with it. Nonetheless, when it comes time to fire up the compiler and crank out some code, the last thing I want in front of me is a herd of unruly little pieces of paper, none connected by anything more logical than a paperclip. Programming is a complex endeavor, and the challenge has always been in finding a way to represent these complexities in a manner cohesive enough to show the big picture and yet detailed enough to implement the most minute details. A tall order, to be sure, and that's why some of the best minds in our business have made a career out of analysis and design techniques.
Unfortunately, there's been another phenomenon that invariable accompanies the introduction of each new methodology. Once the programming community has embraced the newest darling of the design circles, a form of evangelism takes place. Everyone who's anyone just knows that this and only this new approach can save us from the mire of details we face in developing new systems. All other approaches are now officially antiquated, and no one but second rate programmers use them. If you wish to be perceived as competent at your craft and just cool in general, you'd better get this methodology on your resume, and fast.
While there are certainly a lot of programmers with more road behind them than I have, I've seen and worked with a lot of these paradigms over the years. In fairness, I have to say that each new approach to software design has brought a number of good things to the party. However, at every step of the way I see both strengths and weaknesses. Some approaches give a better overview of the system as a whole. Some bring clarity to the low level details necessary for those of us who actually write the code. Others shine in their ability to highlight relationships in a simple and meaningful manner. In short, I have not seen, nor do I believe currently exists, the holy grail of software design, that approach which is perfect in every way, shape and form.
I realize that the previous statement alone is enough to get me burned at the stake in many circles. Programmers tend to be a zealous lot, and woe to the hapless stranger who criticizes one of their deeply held beliefs. I know. I have a few of my own. However, before you break out that charcoal grill and lighter fluid, consider this. I don't think that any of the approaches I've seen over the years are bad ones. They all have value in my eyes. I simply hold that a dogmatic and exclusive manner of choosing the design approach for your project is not always in your best interests, regardless of what the advertising departments at the popular publishing houses would have you believe. And you, sir. Yes, you in the back. Put down that book of matches, and keep your hands where I can see them.
If you've read any of the popular design books over the years, you've no doubt recognized the fact that there are consistent, recurring components that appear in all methodologies. One of the most obvious of these is the symbolic presentation of the various pieces of the puzzle. Graphical representation is one of the easiest ways to communicate complex relationships and interactions, and each new design book takes advantage of this. Each design technique will also have its own glossary of terms, and while they may be offered up in separate books, you'll also find rules for both the analysis and implementation phases. Sometimes, though certainly not always, you'll find a unified set of symbols that serve for both phases. Of course, while all models have a fair amount in common, each will also have bits and pieces unique to their own approach.
If you want to select a methodology for your next project, and you're willing to consider alternatives to simply taking the latest and greatest one on the market, there are a number of variables to consider in finding the perfect fit. First, it's extremely important that you take a good look at the shop where you work and make a realistic assessment of how deeply into the process you can go. If you're working in an environment dominated by time to market considerations (or just impatient and inept management), you're not going to have the time you need to write an 800 page analysis and design document. You're going to have to find a way of organizing your requirements and thoughts quickly and in a small amount of paper. Conversely, if you work for a large engineering firm that typically takes the time to do an extremely thorough and well documented design phase, you should probably slip those cocktail napkins back into your desk drawer before anyone sees them. The rule is very simple. You have to have a design approach that will actually survive in your organization. If the level of detail and time required to implement aren't in synch with the norm in your shop, it's gonna fail miserably. Sound too obvious to state? If experience is any teacher, I can assure you from my own observations that it's not obvious at all.
In addition to the level of detail that you can realistically pursue, you need to consider the nature of the system under development. Is it heavily data-centric? Is the focus on myriad and intertwining processing paths? Is it a real time system? Communications oriented? Multimedia? While you'll doubtless find that you can use any of the analysis and design methodologies from the past ten years or so, further study will reveal that some have strengths which play into your needs quite well. It may be in the way that execution paths are documented, how relationships are organized, or perhaps even the particular set of diagrams offered, but without a doubt, some will speak to you and others will not. The important thing is to evaluate all the approaches you can find, without prejudice, and identify the components that are relevant and useful to your current endeavor.
The availability of software modeling tools is another important consideration. It's been a long time since I drew out diagrams by hand, and I can assure you it will be even longer before I do it again (white boards don't count). If you can find a product that will help you integrate the various components of your design, your life will be improved immeasurably. Furthermore, depending on your programming group, you might even wish to consider software that will do some level of code generation, or diagram generation based on existing code. Both of these features are a mixed blessing, but have their place. If you can find tools that both automate your design process and integrate with your project management system, you're ahead of the game for sure. Of course, if you can't find a suitable software system, then you know what your next development project is.
So, having evaluated as many design approaches as possible and determined how much time for details you have, you're now ready to call for a drum roll and announce the winner, right? Oh, sorry, but thanks for playing and we do have some nice parting gifts for you. Yes, it was a trick question. In an overwhelming majority of cases, there is not a single winner. Rather, it's time to put on your cowboy hat, fish out those cigarette papers & tobacco and roll your own. Just make sure you do it outside. Most programming shops these days are no smoking zones.
The truth of the matter is that worldwide, it is the dwindling minority of programming shops that can afford the luxury of doing a full blown analysis and design phase by the book, following all of the steps precisely as presented by the authors. Typically we just don't have that kind of time. Now we all know that when it comes to design and implementation it's a pay now or pay later scenario. Take shortcuts on the design and you'll be burning plenty of the midnight oil trying to get that last five percent of the system done, not to mention the maintenance nightmares you'll encounter. A thorough, complete and detailed design phase will more than pay for the time spent up front in the hours you save in these areas.
And yet, none of that matters. Here in the real world, we work for people who are business experts, not professional software developers. You can talk until you're blue in the face, but you'll never convince them that all of this preliminary work is doing anything but costing time that will negatively impact the delivery date (their only concern). We aren't perceived as being productive and moving the project forward until we start coding. Sad and frustrating, but true. As a result of this, we are almost never given the time we need to do a complete and detailed design phase.
This is why it's important to learn how to roll your own design methodology. While any of the systems that have been on the market over the years will do a good job for you when pursued to completion, most of them come up short if you don't follow the approach completely. The authors can hardly be blamed for this. In each case they are solving a problem, that of a cohesive approach to software design, and it's unfair to judge their efforts without following their instructions as presented. It's no different than taking a recipe for pizza (you just knew there would be a pizza in here somewhere, didn't you?), leaving out the ingredients for the crust and then complaining because it's a little hard to handle. What else would you expect?
However, with the condensed time frame we usually have to get a project out the door, there is still considerable benefit to be gained from an organized and disciplined approach to design. Just because you can't follow all of the steps doesn't mean that there are no rules. It just means that the list of rules is a bit more concise.
For example, you may decide that for your particular system data relationships are a key factor. Consequently, look into the best approach for entity relationship or object diagrams that you can find and toss that into the pot. In a similar fashion, determine the other types of diagrams that directly represent the fundamental aspects of your system. Not every project needs state transition diagrams, for instance, but they're invaluable when you do. Of course, this applies to all diagram types as well as the other aspects of each methodology. Pull the pieces from each that you need, and then to keep your approach consistent document them in a design guidelines spec that all participating developers will use. Have a preliminary meeting to discuss the components that are to be present in each section of the design, be it diagrams, tables, paragraphs, etc. and you're on your way.
You'll find that your approach will refine itself from project to project as you identify the things that work well and eliminate those which don't. Keep an eye out for anything new on the market, and when you see another component that you can add to your system, plug it in. The end result will be a design methodology that is fine tuned to the realities of your organization and staff. It may not be by the book, but in the end it's important to remember that it's results, not dogma, that we're paid to provide.
Top 