Slashdot Mirror
Review:The Unified Software Development Process
The Unified Process
This book is the third by the Three Amigos this past year (the other two being the UML user and reference guides). Although recently known for their work on the UML at Rational, the Unified Process is an outgrowth of Jacobson's original work at Ericsson on the Objectory Process.
So what is the Unified Process? I'll quote from the book's glossary:
A sofware development process based on the unified modeling language that is iterative, architecture-centric, use-case driven, and risk-driven. A process that is organized around the four phases: inception, elaboration, construction, and transition, and that is further organized around the five core workflows: requirements capture, analysis, design, implementation, and test. A process that is described in terms of a business model, which in turn is structured in terms of three primitive building blocks: workers, activities, and artifacts.
Essentially, this is the 463 page textbook elaborating on what was briefly described in the second chapter of Martin Fowler's UML Distilled [related review].
Organization
The book itself is well organized. Chapters are broken into logical sections and bite-sized subsections. For example, most chapters in Part II follow this structure: introduction, role, artifacts, workers, workflow, summary, and references. That consistency is a boon to the reader (and not an albatross, as it is deviated from where necessary).
Figures help the reader to maintain a frame of reference (e.g., traveling through the phases and workflows). This is important as the Unified Process can occasionally be confusing, with its repeated iterations and workflows.
The authors provide examples where illustrative and references where beneficial. The appendices are handy, especially the 13 page overview of the UML (which is very well done).
Impartiality
One of my concerns reading this book was the degree of impartiality of the authors. Naturally, being Rational employees they have a vested interest in promoting their Unified Process and UML tools. Happily, I didn't notice an overt conflict of interest. Rational is mentioned a few times, but not obtrusively. And although they mention tool support as being an imperative, that's probably true.
Another area of impartiality is in their references. The authors don't reference their own works exclusively, but instead point the reader in other fruitful directions, including the design patterns literature and even Peter Drucker's writings on management theory.
Impressions
I found that the authors often had useful things to say. Whenever I open to a random page, I find a useful tidbit or two, and I appreciate that. There's nothing radical here, but the structured presentation benefits the content a lot.
This is a book on software process, and a fairly textbook-ish one at that, so I wasn't surprised to find the writing a little dry. In particular, I found the chapters in Part II to be particularly soporific on first read, but then I realize that the internal mechanics of software development don't necessarily make for the most thrilling read. Returning to those chapters to read in measured dosage really does them well.
Minor Drawbacks
I'd like to have seen a little more variation in the examples. I remember quite a few dealing with bank machines, and although that leads itself to a certain stability, it can be hard to get excited over such applications.
Although the index is fairly complete, I recall one omission in particular. The authors discuss three ways the Unified Process addresses the issue of "good enough" software, yet no mention is made in the index. That piqued me when I wanted to look it up.
Finally, although the authors use C++ and Java for the occasional lower level example, they use a directory as a packaging mechanism in the former. I feel a namespace is more applicable.
Applicability
While I was reading this book, I was preparing documents and presentations on software process for my employer. I did find this book to be helpful, and definitely feel that it was a worthwhile read.
This is not a recipe book. It won't lay down everything for you. But it will get you started thinking in the right direction, and aware of the issues involved in an industrial strength software development process.
However, it's important to remember that the Unified Process is not the answer to all process questions. Although it scales well, I believe it can be overkill for small teams, and I assume inadequate for some larger organizations as well.
Recommendation
If process is your thing, then you'll probably want this book. If you lead a team in a medium sized software development organization, and are interested in introducing a more formal process, then this book is a recommended read. Even if you don't end up applying the Unified Process, it simply addresses too many relevant details to be ignored.
I don't recommend this book for casual reading, unless you have an interest in process. A good example might be a developer in a medium sized organization who feels they need a more formal process. A good guideline might be whether you're still interested after reading the glossary quote in the introduction.
You will find the book web page in Addison-Wesley's Object Technology Series.
Purchase this book at Amazon.
TABLE OF CONTENTS
Preface
Part I: The Unified Software
Development Process
1. The Unified Process:
Use-Case Driven, Architecture-Centric, Iterative, and Incremental
2. The Four Ps: People, Project, Product, and Process
in Software Development
3. A Use-Case-Driven Process
4. An Architecture-Centric Process
5. An Iterative and Incremental Process
Part II: The Core Workflows
6. Requirements Capture: From Vision to Requirements
7. Capturing the Requirements as Use Cases
8. Analysis
9. Design
10. Implementation
11. Test
Part III: Iterative and Incremental Development
12. The Generic Iteration Workflow
13. Inception Launches the Project
14. The Elaboration Phase Makes the Architecural Baseline
15. Construction Leads to Initial Operational Capability
16. Transition Completes the Product Release
17. Making the Unified Process Work
Appendix A: Overview of the UML
Appendix
B: The Unified Process-Specific Extensions of the UML
Appendix C: Glossary
Index
This is more of a sorry comment on the state of CASE of tools in general. Some shops still find it's drawbacks and bugs better than any feasible alternative.
Sucks, but it's been this way for years. I recall some seemingly endless number of years ago the big flap about how all the new CASE tools and visual design crap were going to solve everyone's development problems.
Of course, today, all those same problems still exist in one form or another...
There are no silver bullets, and no tool will replace the need for a structured development process. (Unless you're just hacking around...)
Me neither.
Process in itself will not guaruntee results or even good code.
My development experiences in Large Corporate environments (and LARGE CORPORATE PROCESSES) has been very negative. I don't think they (the people developing the processes) have got it right yet. Generally I've gotten several major things out of their works that I didn't learn in school:
1) Large, multiple team projects do require some processes.
2) The iterative approach works well.
3) Processes must be kept to a LOW OVERHEAD.
4) For technical processes (and management) to work -- the management itself must understand the code... I almost think this works best when those running the process are team leaders rather than first level management...
I think _they_ have made alot of money selling business processes to businesses that bought into their story.
Don't know what you're coders do?
Don't know why it's not done _yet_?
Don't know why it takes so many people?
Here -- use our process & you can control their work yourself & make sure its done on time, under budget and correctly...
Again, the preocess isn't there yet. Take what works & leave the rest.
1. Start emacs.
2. Write code.
3. Check into RCS.
4. Compile code.
5. If necessary, debug with gdb.
...and who designed that awkward interface of Rose? Can they possibly nest more obscure windows from with subdialogs of other subdialogs? What a bunch of crap.
I often wonder who benefits most from such a tool.
The programmers depise it, the managers whole-heartedly endorse it, but never use it.
It's one of those unfortunate project checklist items I'm afraid.
I had the 'pleasure' of using Rational Rose for Java on my last project. It has several problems:
1. Large-grained model files, leading to resource contention when two developers want to make a change.
2. BAD code generation. Any comment outside of a method body is erased. Any method whose signature doesn't precisely match the model is commented. Generate two times in a row and kiss that method goodbye.
3. Bugs, bugs, bugs. I lost four hours of work due to Rose not saving (a file was still read-only) but not telling me so. Inner classes (in Java) caused model file corruption. (That's supposed to be fixed in the new '98i' version.)
4. Even when everything worked properly, using Rational Rose was just plain slow. I was constantly switching back and forth between my source code and the model. (Sure, all my public methods and signatures were defined in my design, but not private methods or constants -- and those have to go in the model too, or Rose erases them.)
I can't recommend Rational Rose to anybody. I DO think CASE tools' ability to keep the design documentation in sync with the code is important, though -- for that, I recommend Together (specifically, I use Together/J -- http://www.togetherj.com).
-Jim Little (jiml@inconnect.com)
Amen to that!
The difference which many /.'ers may fail to note, as evidenced by this and other replies, is that some software is actually designed to meet end-user and business requirements, rather than the whim of an individual programmer.
Further, and amazingly enough, some requirements are complex enough that they require more than one programmer to complete, and need to be completed on some kind of predictable schedule so groups of people can coordinate their activities effectively. Thus, some kind of process is necessary. Bad ones slow down development, good ones speed it up.
Lack of process is anarchy in anything larger than a 2 person shop, and the main difference between an amateur and a professional.
Open Source is fun, but it's characteristic lack of enforcable process (in it's most generic form) is probably it's biggest risk. I could care less how (or when) you write *your* software, but when you're writing *mine*... well you get the idea.
The number of comments on these kinds of articles is a consistent and reliable indicator of the "positioning" of the /. audience. Very heavy on low-level coding techniques, and other geek friendly activities and interests (i.e. Star Wars, role playing games, games in general, etc.), much less deep in design, methodology and truly large scale software development.
/.'ers find this kind of topic superfluous and/or booring.
There are some folks with this kind of experience, and I've seen some very astute and well thought out posts, but their numbers are in the minority. As near as I can surmise, most
Some of Rob's earlier polls gave out some interesting metrics, which showed the majority of the audience composed of students (high school/college) and small-shop developers. This probably goes a long way towards explaining this phenomenon.
While this work is interesting, most of it seems to apply to an era of program development that has passed by. The three amigos seem focused on the development of huge apps. My own experience is that these types of apps are slowly being killed by the web.
Most web developers should be able to minimize the size of their programs by leveraging Apache, Dynamic HTML, CGI, etc, in which case most of this UML business is a bit superfluous.
If you are still writing huge apps, then I recommend the UML.
I always find it interesting that so few of us respond whenever someone begins to talk about "methodology"...
Hacking has its place, too -- yet, nothing replaces a quality design.
I'm almost certain their process is a hybrid iterative/incremental method, based on my familiarity with Jacobsen's Objectory process and Booch's writings.
The Rational process is definitely a big-M methodology, so proceed with caution & grains of salt handy.
Also, since they're the stewards of UML, I'm pretty sure they advocate code generation with it, though this seems to be somewhat of a religious issue.
I don't believe code generation tools are at the point where they deliver real business value unless you're working with an amazingly large system with an amazingly large number of developers, and need a generated "code foundation". (By this I mean 1 million++ lines of code and over 12 people on the project). Thankfully, most organizations stay away from those kinds of monster-projects and split them up into digestable sizes.
-Stu
I really like the Three Amigos. They've done some great work, and all have contributed much to the OO cause....
However, I tend to take these processes with a grain of salt. They definitely are about "programming in the large". Many of these big-M methodologies require more documentation than actual code, which is questionable when time to market and flexibility ar requirements. (And when aren't they?)
Far more interesting work is being done in the small-m methodology arena, especially with SCRUM and eXtreme Programming. These methods acknowledge that software development is a complex process yet consists of small, relatively simple concepts. (XP suggests there are four concepts to software engineering: Coding, Testing, Listening and Refactoring. While work in this area is young, I think I agree.)
Check out http://jeffsutherland.org for info on SCRUM, and http://c2.com 's WikiWiki server for info on ExtremeProgramming.
-Stu
I haven't yet read Booch's book (I got it recently), and it's been years since I read half of Rumbaugh's book, so I can't remember it.
But I also find that to be a flaw. Everyone can say "rectangle" is an object in a drawing program derived from "shape", but what about harder domains?
--
Marc A. Lepage
Software Developer
Well, they do make a big deal of saying each iteration goes through the workflows and produces an increment, and there are multiple iterations per phase.
:-)
:-)
In their scheme, it appears that requirements, analysis, and design differ more by level and intent than by content. So in that scheme, each can be viewed as a refinement of the previous. At least, that's my interpretation. I Am Not A Methodologist.
They do say that, for example, that you might analyze 5% of the use-case mass in the inception phase, 20-40% in the elaboration phase, etc. So you're always going back to flesh out more detail at a later phase, if I understand correctly.
I don't recall them speaking too much about code generation. It's not in the index. I'd expect them to recommend it, but it's not a big topic in the book. As always, take with salt.
--
Marc A. Lepage
Software Developer
I think you might be missing the point. It's not about completely automating the task of software development, such that it is like a manufacturing process.
It's about applying process so that you have a foundation from which to be creative.
Let me give an example: it's hard to creatively solve development problems when the gun is to your head to fix bugs that should have been caught earlier, because your organization has no process.
I've worked at large corporations without process. Every success is unrepeatably (that is, luck). And failures abound. For example, if I spend all weekend cleaning up a design that failed because requirements were wrong, and the process didn't check those requirements, I regard that as failure. Not of myself, or even the requirements engineer, but of the process and organization itself.
Perhaps you have not had the misfortune of working in such a place?
--
Marc A. Lepage
Software Developer
Again you have it wrong. The code I fixed was from a good programmer with good intentions. Not an idiot.
However, a lack of general process caused the entire development process to fail, in that respect. There was no incentive to get your component right, because nothing worked.
The shipping date was always "next month" instead of "a year from now". Management thought we could just stay an extra weekend to fix bugs as they arise.
People went off and did their own thing, not what they were supposed to. One team upgraded compilers to make their life easier, screwing up others. Documents were written but quickly fell out of date as they were not updated.
Everyone had the best of intentions. This was supposed to be the "big project that we did right". I only got on it about 2 months before shipping, and saved a major component from disaster.
I argue that more process, enforced, would have prevented this. And I'm not talking Gestapo here. I just want enough of a framework in place so that everyone knows what they're doing, when they are behind, when they've succeeded, etc.
Now I'm at a place where that's true, and I'm happy. My former employer's stock continues to stagnate.
--
Marc A. Lepage
Software Developer
Exactly.
--
Marc A. Lepage
Software Developer
I don't believe that UML (or any other software process) should be reserved for large apps. UML is designed to be an iterative and incremental design, development and implementation process. That means for small projects, you would only have a couple of iterations.
Processes are all about following a standard set of rules so that your work can be repeated by yourself or another person. It's also geared so that you don't rely on just "coding cowboys/cowgirls" to magically pound out some code. UML doesn't restrict programmers from being creative, just a little more careful.
If you want to read a quick book on UML, I recommend "UML Distilled" by Martin Fowler.
Just because you're paranoid, doesn't mean they're not after you!
You and others are arguing for "process" to make up for a lack of common sense in management, I think, and think I'm talking about the lack in programmers. It could be lacking in either place, or both, and okay, okay, sometimes "process" can help somewhat -- but if management is full of idiots, they'll screw up implementing "process", too, for instance by making it high overhead instead of low overhead -- something I really hate, but which is more common than not.
No doubt this is similar to governments using bureaurocracy and endless procedural rules and forms and paperwork to make up for lack of talent in their work force. In the absence of top people, I suppose something has to take up the slack. And that it inevitably makes everything run at about 1% efficiency. And a lot of big companies end up in similar predicaments. Perhaps I should feel sympathy.
However, sympathy is not equal to respect for procedures and "process". My respect goes to executives, managers, and engineers who do a good job regardless of whether there are good rules telling them what to do. My respect goes to those who do a good job even despite bad rules (or no rules) and bad environment (like idiot executives above them).
People who get fanatical about "process" have just gotten mixed up about the basic fact that they are simply a patch-workaround on top of an organizational bug, not an actual bug fix.
Professional Wild-Eyed Visionary
A software development process based on the calcified untried modeling language that is pejorative, ego-centric, useless-case driven, and whiskey-driven. A process that is disorganized around the four fazes: deception, incorporation, destruction, and tradition, and that is further disorganized around the five core workblows: money capture, bank account analysis, resign, temptation and rest. A process that is described in terms of a fictional business model, which in turn is unstructured in terms of three (very) primitive lego blocks: drunk workers, festivity, and alien artifacts.
(Presuming to turn programming into a boss-controlled manufacturing task is like trying to do the same to the creation of fine art -- it utterly misunderstands every issue. Picture race cars made out of cast concrete.)
(Art and programming both will be completely analyzable some time after the mind itself is completely understood.)
Professional Wild-Eyed Visionary
I think the idea was more to compare cathedrals and bazaars as functioning institutions, rather than in the sense of "how do you build them?" Cathedrals are organized, hierarchical entities, with scheduled ceremonies, committees, and managers (in a generic sense). You can't just walk in and suggest changes to a service or set up your own altar... Bazaars, on the other hand, *are* whover shows up and pitches a tent and tries to buy or sell, with no one trying to run the show and tightly regulate things. At least, that's the first-order comparison.
In fact, I think bazaars *do* require a certain amount of behind-the-scenes coordination: most historical Middle Eastern bazaars had officials who regulated weights and measures and prosecuted fraud, in addition to at least some kind of police presence to discourage thieves and robbers from taking whatever they wanted. And the actual construction of cathedrals involved a certain amount of community participation and contribution, from traveling artisans who helped spread Gothic style and techniques throughout Europe, to local citizens contributing their own labor and money to the building.
ESR's point, I think, was mainly to come up with some vivid metaphors to highlight the differences he perceived in software construction practices -- stately, organized, closed institution versus seemingly anarchic free-for-all -- rather than to make some historically [pedantically] accurate comparison. And maybe he had structures like the Cathedral of Cologne in mind, as well: begun in the Middle Ages and not actually finished until the 19th Century. Translated to computer timescales, that's at least a little like the slow progress of the GNU Hurd, or Windows NT 5, or...
-- Peter
-- Keysh (Peter Erwin)
Everyone can erect a tent in a bazaar, but it took a lot of planning, coordination, sweat and blood to build the cathedral of Reims. I never understood why ESR's paper pitted the bazaar against the cathedral, when both are serving totally different functions. If you'd ever been to Reims or Paris and if you'd seen, with your own eyes, the absolutely overwhelming beauty of these majestic edifices, you'd agree that the software world has built nothing but tents yet.
Bravo on your distinction between the amateur and the professional.
/. has a lot of talented readers, but it's also clear that many of them have the stereotypical tunnelvision attributed to geeks.
I'm not one who holds with the connotation that there's any negative aspect to the term amateur, nor do I believe that simply because one is good at an aspect of an effort one is automatically a professional.
The one aspect in this case is generating code. The effort is generating, documenting (gotcha), and testing a product for delivery to a customer. Generation != product creation. If you don't believe me, go work for a shop writing off-the-shelf software for end-users.
I have to admit that I've found several of the comments here regarding the size and content of this discussion both enlightening and disheartening. It's clear that
Development of a real software project can be a humbling experience. It can also be an opportunity to see how gifted people can create a thing larger than the sum of the parts when they work together and use the right tools, like style standards, consistent test methodologies, revision control, and (if we can ever get them right) CASE tools.
Oh, yeah, and if your manager doesn't understand that the muse sometimes has to just be there for you, it can really suck.
You mean you actually read the spec? By the time the spec is written 1) all involved have work long and hard enough on it that they've memorized all of the requirements; 2) it doesn't reflect all the tacit agreements as to what the real requirements are; 3) no document, no matter how exhaustive, is going to be as detailed and unambiguous as real code; 4) what looked good on paper suffers on the computer screen.
Just my embittered two cents worth...
If you post it, they will read.
>> I remember quite a few dealing with bank
;^)
>> machines, and although that leads itself to a
>> certain stability, it can be hard to get
>> excited over such applications.
Rumbaugh's "classic" book was overly simplistic, and Booch's "management overview" book suffered from the same. They're great at describing "tangible" object systems (hot water systems, vehicles etc.) and systems where the major classes are obvious (customer, account, transaction, etc.), but fall apart on real-world examples of abstract problem spaces. I know these "physical examples" are easier to use as illustrations (familiarity of the reader etc.) but they assume that all problems are like this.
Is the new book any better, or are they still relatively naive ?
If not, I'd recommend DeGrace and Stahl ("Wicked Problems, Righteous Solutions" and "The Olduvai Imperative: CASE and the State of Software Engineering Practice") as balancing the hype of all those processes which feature steps like "and then a design miraculously appears". Maybe I should pull my finger out and submit a review
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
I've just started reading the book, so I can't really comment on it. I do have a question, however, for those who have read it.
Does this book effectively address how to effectively implement an iterative process, as oppossed a waterfall process? A lot of contemporary methodologies pay lip service to the idea of iterative design and development (with lots of recursive arrows on the process diagrams), but this is often very difficult to implement in a corporate environment. (Easier on web-based/open source projects.) On my projects where I own everything, I constantly go back and revise specs. But on a large coporate project, changing the spec can be a big deal and take a long time, so it tends not to get done -- once the spec is written, it's set in stone. I suppose tools would help here.
Also, how do the authors feel about using UML tools like RationalRose for code generation? It seems like that could be pretty handy, but I worry that people would start using the diagrams as an implementation tool, instead of a design illustration tool. The diagrams could get too complicated, and hard to understand. What Fred Brookes said about flow-charts might apply here -- a little bit goes a long way. One simple, unclutterd UML diagram could be more useful than lots of really complicated diagrams.
------------------------------
Stephen Molitor steve_molitor@yahoo.com