Foreword

Every software development team follows some sort of process, whether intentionally or not. In small teams of one, two, or just a handful of developers, that process is typically lightweight. Very few if any documents are produced, analysis and design does take place but is often informal and transitory , and the project's source code serves as the center of gravity around which all other activities of the project orbit .

In large teams of dozens or even hundreds of developers, typically spread across buildings or flung around the globe, that process is much more prescribed. Many more formal and officially reviewed documents are produced; analysis and design involves the collaboration of a number of nondeveloper stakeholders and is made manifest in meetings, presentations, documents, and other artifacts; and the project's code is just one ”albeit the most important ”of the tangible artifacts that compose the deployed system. This is not to say that lightweight processes and heavier ones are at opposite ends of the spectrum of goodness: Every problem domain, every development culture, and every individual project requires a process that is just right for its specific context.

That said, all successful projects have some fascinating elements in common, no matter what their size. These elements are notably absent in unsuccessful projects. Observe a jelled project and you'll sense a distinct rhythm of cooperative work, with individual developers driving their own activities and artifacts, but at the same time working frictionlessly yet intentionally with other organically formed sets of developers. Such projects are typically quite agile, resilient to change, and adaptable, but also predictable, reliable, and able to craft quality code that really matters. In short, for these projects, the process followed is so much a part of the way its developers work that it is virtually invisible, yet its spirit moves every artifact produced by team members working in concert.

The spirit of the Rational Unified Process, or RUP, is exactly this kind of invisible process. The RUP has evolved over the years to embody the experience of literally thousands of projects in every conceivable domain. Per Kroll and Philippe Kruchten are especially well suited to explain the RUP in an approachable and eminently pragmatic way because they have been the central forces inside Rational Software behind the creation of the RUP and its delivery to projects around the world.

When you talk about process to many developers, there is often an immediate push back because process is so often viewed as something that gets in the way of cutting code. This is simply not so with the RUP, for its very purpose is to reduce the friction of development teams so that they may focus on producing quality systems that are of value. Per and Philippe begin by explaining the spirit of the RUP and then proceed to show how the RUP may be applied to projects of many different shapes and sizes.

After explaining the pragmatics of the RUP, they then discuss several meta topics, including how you can introduce the RUP to an organization and what pitfalls to avoid in doing so. Making the RUP approachable to different stakeholders, they then examine the RUP from the viewpoint of the project manager, analyst, architect, developer, and tester.

The most successful project makes process look easy, but in reality, some really deep currents are at work. In this book, Per and Philippe explain those currents in an approachable and practical way, so that your projects too will follow the spirit of the RUP.

Grady  Booch
Chief  Scientist
Rational  Software  Corporation
February  2003



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net