 |
|
The Rational Unified Process: An Introduction is a good overview of Rational's prescription for whole-project health. The process is unified as in "Unified Field Theory." Thesis, Antithesis, and Synthesis, (or Booch, Jacobson, and Rumbaugh, as they are known today) twine in a celestial dance to the Spheres, Rectangles, Clouds, and stray pointers that make up UML and its increasingly ambitious extensions, additions, and heroic leaps of faith.
Rational visualizes the elements and modalities of code and projects in a fashion found compelling by increasing numbers of corporate customers. It's a vision embodied in several software suites, including the eponymous Rational Unified Process, for which this book is designed to serve as the introduction. Face it, you are going to run into Rational on the job. This volume is a good place to get know about it.
The book is not an independent assessment of Rational. Editor Philippe Kruchten is lead architect of the Rational Unified Process product. The thrust is the process of processes, specifically process in software projects, as viewed by Rational and supported by its project-management toolsets.
The tone is set for the book in Chapter One, which is Grady Booch's "Software Development Best Practices." Booch lists 19 "Symptoms and Root Causes of Software Development Problems." Booch clearly hasn't worked anywhere I've worked, because missing from his list are "Moron from acquired business unit appointed director," "Manager owns nice suit but can't follow logical proof," and "Inept team member keeps job by threatening suicide."
All of us have our own notations, albeit hastily scribbled, for the steps and players of a project or computational process. Believing, as nerds tend to do, that the methods used to describe program objects and execution steps are suitable for managing human social units, Rational's scientists, to their credit, have elevated napkin scratching and whiteboard scrawls to an art form, and given our industry a certain shared vocabulary of icons for these familiar entities. They've also made a few not entirely obvious comments about software testing that can't do any harm by their addition to the literature.
However, I found nothing new in this volume that was helpful, and nothing helpful that was new. I summarize here at random from The Rational Unified Process:
One should cope with risk by a policy of risk avoidance, risk transfer, risk acceptance, risk mitigation and contingency planning.A metric is a measurable attribute of an entity.
If you must hit the market early, you can shorten the construction phase and lengthen the transition phase.
In other words, if you can't dazzle them with brilliance, baffle them with ISO-9001. The first two of the above are self-referential and the third is a tautology. We don't need more planning gurus -- we need more software engineers with liberal arts educations and a minor in Formal Logic.
Here are more hastily excerpted gems, with my comments in parentheses:
The following are examples of iteration goals [in the Transition Phase]:1. Fix all severity 1 problems discovered at beta customer sites.... This may be related to credibility in the market.
(Fix the major problems your beta sites report? What a concept! This could revolutionize software development.)
In building a base plan, you must assess trade-offs between staff, schedule and project scope.
(You mean, I have to carefully marshal my resources? Didn't Sun Tzu say this umpteen years ago? Doesn't anyone read classics anymore?)
The scary thing is that statements like these may come as news to some folks working for your company. Apparently, they are the intended audience, those people who know nada about software development yet are managing projects (and who also, one assumes, have purchase authority for project management software).
A good idea, well-positioned within the technology of the time and in accordance with the genuine needs of an informed user group, designed and executed by a team sharing a vision and managed by an inscrutable, diplomatic, restrained, and benevolent management team... In such a case development, delivery, installation, training, and maintenance are simplicity itself and demand no special tools at all.
It's the worst-designed programs that you spend the most time debugging, and it's the worst thought-out projects that are laden with fashionable project-management tools. In my worm's-eye view, you will always find management using these tools on the screwed-up projects.
Assuming I'm correct in my assessment, we can probably expect the Rational Unified Process to be mandated by law in the near future. With that in mind, The Rational Unified Process: An Introduction is a mercifully short introduction.
-- Jack Woehr