Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
News Books Media Book Reviews

Review:The Unified Software Development Process 38

Posted by Hemos from the learn-how-to-do dept.
Thanks to SEGV for the this review of Jacobson, Booch, Rumbaugh's latest effort The Unified Software Development Process. A book designed for those of you who love process (or want to learn development process), click below for more information.
The Unified Software Development Process
author Ivar Jacobson, Grady Booch, and James Rumbaugh
pages 512
publisher Addison-Wesley Publishing Co.
rating 8/10
reviewer SEGV
ISBN
summary A textbook treatment on process in software development. Covers the Unified Process from product launch to architectural baseline, through initial operational capability, ultimately to product release. Information rich but occasionally dry.

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 discussion has been archived. No new comments can be posted.

Review:The Unified Software Development Process More

Review:The Unified Software Development Process

Comments Filter:

  • Three Amigos and the web era (Score:1)

    by Anonymous Coward
    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.

  • Geeks and Process... (Score:1)

    by Anonymous Coward

    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.

  • 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.
  • 3. Check into RCS.
    4. Compile code.
    5. If necessary, debug with gdb.

    You put untested (and on average, likely broken) code into your code repository? You must not be working with many other people. Else you would have people wanting your head on a platter because you busted their compilation after they did an update, making them waste time tracking down errors in your code.

  • XP does have some interesting ideas. There is a book coming out soon by Beck et al. I'll probably end up getting it, although perhaps not all in the coming series.
  • 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?
  • 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. :-)

  • 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?
  • Small apps are good, but when they communicate together (as in the web) the complexity is still there, it's just distributed amoung components.

    I've worked on a large web architecture, involving thin clients, fat clients, servers, CORBA, XML, a broker, services, HTML generators, etc. Even if each component were small (and not all were), the complexity of them all working together wasn't.

    We didn't have a process, and it nearly killed us. We shipped very late, and many hard nights and weekends were required just to do that. We spent the next half year fixing the bugs we shipped.

    I think a process could have helped. Any process, as long as we had some.

    And, as another pointed out, we aren't all developing web apps.

    Finally, remember that the Unified Process is more than the UML. Also, although it really suits the UML, you could probably follow its tenets (as in Fowler's book) without using the entire process, or perhaps without the UML.
  • 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.
  • 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.
  • It's not that I have it wrong, it's that the "idiot employees lacking common sense" aren't programmers in your story, they're management.

    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.

  • 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.

    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.)

  • You're saying that, without "process" (which to me means lots of bureaucratic forms, trainings, meetings, and other time wasters), that company employees lose all track of reality and common sense, such that they don't check whether requirements are correct, and don't test for bugs?

    If you are correct, then my followup theory is that those same employees will remain idiots even with tons and tons of "process".

    (P.S. I've contracted at large companies, and there certainly is a lot of idiocy of various forms in them.)

  • SCRUM is good, but it's a high-risk methodology, sometimes you get a brilliant solution in a very short time, sometimes you get nothing, sometimes you get nothing and all your best people leave.

    Most people look to processes for control and predictability. Project management is risk management - you pick the compromise you're willing to accept and run with it.

    "DeGrace, P. and Hulet Stahl, L. 1990. Wicked Problems, Righteous Solutions. Yourdon Press" is a great overview of "project methods" including the pros and cons of each.
  • All applications developed today are not web applications and even if they were, they are not so simple and trivial that the development process would not benefit from using a modeling language such as UML.

    A single program entity may be fairly simple and it may of course be possible to leverage the development on already built components - which does not remove the total complexity of the environment they shall work in. This can amount to quite complex systems of applications.

    Besides, UML is not restricted to model a program design, anything that can benefit from being modeled (a program design, a business process, or whatever)

    But the book was not about UML either, it was about Rational's Unified Process, something completely different.
    Within that process a good choice for a modeling language could be UML, but I hardly belive that is required - that would be a bit silly.
  • Errr.... No.

    The web provides software and protocols to provide somewhat standardised presentation and connectivity to applications. This statement needs to be heavily qualified to take into account incompatibilities between browsers and web servers, and a host of other non-standard extensions like ActiveX, Java, etc.

    For some types of applications, the web simplifies design and programming. For many (most?) others, things are of similar or greater complexity.

    The web does not make complex procedures and applications simple. If you're trying to design a high speed RDBMS-based application with a a large number of data entry forms and complex processing(or applets, or whatever) and make it easy to use, you are going to need a rigorous design, well designed and normalised database (except where denormalisation is required for speed), and be able to coordinate and manage several programmers or teams of programmers to meet that design. It's possible also that your design requires a flexibility of UI which is too much for current browsers and HTML. This is getting better, but it still has a long way to go.

    Downloaded any CVS trees lately? Do that then tell me apps are getting smaller and simpler with the advent of the web.
  • 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
  • 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.
  • You're saying that, without "process" (which to me means lots of bureaucratic forms, trainings, meetings, and other time wasters),

    Not all process is bad. To be sure, there are Dilbertian employers who have old processes that get in the way. But most processes actually help.

    that company employees lose all track of reality and common sense, such that they don't check whether requirements are correct, and don't test for bugs?

    Funny, after you roundly condemn process you then list a couple of things that go in to the process. Yes, its amazing how often projects forget to do these things. Maybe it didn't seem important, or everyone thought that someone else had done it, or nobody could be bothered to do the actual work instead of getting on with exciting stuff like actual coding.

    Anyway, just how do you check the requirements, or do the testing? You might think it obvious, but walk around any software department and talk to people, and you will find lots of different opinions. Some of them will be seriously wrong-headed. The solution to this is to get your best people together and tell them to write down the way it is done. Then distribute this around the company so that everyone does it right. And thats how you institute process improvement.

    Paul.

  • Bravo on your distinction between the amateur and the professional.



    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 /. has a lot of talented readers, but it's also clear that many of them have the stereotypical tunnelvision attributed to geeks.



    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...
  • As a contractor I've fallen into 3 separate
    projects over the last 5 years where Rose was
    the tool of choice. Never once have I heard
    anyone who has actually used to tool say anything
    good about it. IMHO, it's been an abysmal
    product from its inception. It crashes frequently
    (every version I've used does this and each time, Rational says that it will be fixed in the next version). The code generated (and it takes _months_ to tune to code generator to your existing infrastructure) is uninhabitable!
    The user-interface has always been frustrating and it doesn't integrate well with anything (eg. imake, cvs, SQL, etc.).

    It is and always has been an unusable tool. It's frightening that it commands such a large market share. Shame on Rational for proferring snakeoil like this.

    What we need is a good OS CASE tool for OO. I've seen a few attempts at starting one but (humorously) all I've found so far are web sites containing the development plans!
  • Bear in mind that a number of folks are writing software that is "safety critical" (i.e., airliner avionics, medical equipment, etc). For these sorts of applications, having a solid development process is critical.

    We're not all CGI developers here...
  • What if you have to write a large web application?

    Basically, what you're saying is that you don't have to rewrite the foundations of a web server to have a web application. Okay, I agree with you but still there is a lot of work involved in large applications to model the business process, analyze requirements, create an architecture (yes, architecture is more than just picking which web server to use), etc.

    Granted, you don't need to do all of the artifacts in all of the development phases for a project but UML still has a place in most OO projects. If you are working in a team, the diagrams are best for communicating how the application will work and will be structured. If the application will be enhanced at a later date, you have a collection of documentation (through UML) that hopefully will make it easier which classes would have to be modified, which use cases and scenarios have changed, etc.

    And if you get hit by a truck the UML documentation will allow whoever replaces you to make heads or tails of your code. Sometimes comments just don't cut it to see the overall interaction between objects.

  • >> 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'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.

    ------------------------------

Slashdot Top Deals

"God is a comedian playing to an audience too afraid to laugh." - Voltaire

Close