Addison wesley agility and discipline made easy practices from OpenUP and RUP may 2006 ISBN 0321321308

Agility and Discipline Made Easy: Practices from OpenUP and RUP
By Per Kroll, Bruce MacIsaac
...............................................
Publisher: Addison Wesley Professional
Pub Date: May 19, 2006
Print ISBN-10: 0-321-32130-8
Print ISBN-13: 978-0-321-32130-5
Pages: 448

Table of Contents | Index

"The Japanese samurai Musashi wrote: 'One can win with the long sword, and one can win with the short sword. Whatever the weapon, there is a time and situation in which it
is appropriate.'
"Similarly, we have the long RUP and the short RUP, and all sizes in between. RUP is not a rigid, static recipe, and it evolves with the field and the practitioners, as
demonstrated in this new book full of wisdom to illustrate further the liveliness of a process adopted by so many organizations around the world. Bravo!"
--Philippe Kruchten, Professor, University of British Colum bia
"The Unified Process and its practices have had, and continue to have, a great impact on the software industry. This book is a refreshing new look at some of the principles
underlying the Unified Process. It is full of practical guidance for people who want to start, or increase, their adoption of proven practices. No matter where you are today in
terms of software maturity, you can start improving tomorrow."
--Ivar Jacobson, Ivar Jacobson Consulting
"Kroll and MacIsaac have written a must-have book. It is well organized with new principles for software development. I encounter many books I consider valuable; I consider
this one indispensable, especially as it includes over 20 concrete best practices. If you are interested in making your software development shop a better one, read this book!"
--Ricardo R. Garcia, President, Global Rational User Group Council, www.rational-ug.org/index .php
"Agile software development is real, it works, and it's here to stay. Now is the time to come up to speed on agile best practices for the Unified Process, and this book provides
a great starting point."
--Scott W . Am bler, practice leader, Agile Modeling
"IBM and the global economy have become increasingly dependent on software over the last decade, and our industry has evolved some discriminating best practices. Per and
Bruce have captured the principles and practices of success in this concise book; a must for executives, project managers, and practitioners. These ideas are progressive, but
they strike the right balance between agility and governance and will form the foundation for successful systems and software developers for a long time."
--W alk er Royce, Vice President, IBM Software Services-Rational
"Finally, the RUP is presented in digestible, byte-size pieces. Kroll and MacIsaac effectively describe a set of practices that can be adopted in a low-ceremony, ad hoc fashion,

suited to the culture of the more agile project team, while allowing them to understand how to scale their process as needed."
--Dean Leffingwell, author and software business advisor and ex ecutive
"This text fills an important gap in the knowledge-base of our industry: providing agile practices in the proven, scalable framework of the Unified Process. With each practice
able to be throttled to the unique context of a development organization, Kroll and MacIsaac provide software teams with the ability to balance agility and discipline as
appropriate for their specific needs."
--Brian G. Lyons, CTO , Num ber Six Software, Inc.
In Agility and Discipline Made Easy, Rational Unified Process (RUP) and O pen Unified Process (O penUP) ex perts Per Kroll and Bruce MacIsaac share twenty welldefined best practices that you and your team can start adopting today to im prove the agility, predictability, speed, and cost of software developm ent.
Kroll and MacIsaac outline proven principles for software developm ent, and supply a num ber of supporting practices for each. You'll learn what problem s each
practice addresses and how you can best leverage RUP and O penUP (an open-source version of the Unified Process) to m ak e the practice work for you. You'll find
proactive, prescriptive guidance on how to adopt the practices with m inim al risk and im plem ent as m uch or as little of RUP or O penUP as you want.
Learn how to apply sam ple practices from the Unified Process so you can
Ex ecute your project in iterations
Em brace and m anage change
Test your own code
Describe requirem ents from the user perspective
Architect with com ponents and services
Model k ey perspectives
W hether you are interested in agile or disciplined developm ent using RUP, O penUP, or other agile processes, this book will help you reduce the anx iety and cost
associated with software im provem ent by providing an easy, non-intrusive path toward im proved results--without overwhelm ing you and your team .


Agility and Discipline Made Easy: Practices from OpenUP and RUP
By Per Kroll, Bruce MacIsaac
...............................................
Publisher: Addison Wesley Professional
Pub Date: May 19, 2006
Print ISBN-10: 0-321-32130-8
Print ISBN-13: 978-0-321-32130-5
Pages: 448

Table of Contents | Index

Copyright
Praise for Agility and Discipline Made Easy
The Addison-Wesley Object Technology Series
Foreword
Preface
About the Authors
Chapter 1. Leveraging Key Development Principles
Where Do the Practices Come From?
Using Practice Descriptions
Adopting the Practices: Iterative Development, Levels of Ceremony, and Agility
Key Development Principles
Unified Process Lifecycle
OpenUP/Basic
Rational Unified Process (RUP)
eXtreme Programming (XP)
Scrum
Summary
Chapter 2. Demonstrate Value Iteratively
Practice 1. Manage Risk
Practice 2. Execute Your Project in Iterations
Practice 3. Embrace and Manage Change
Practice 4. Measure Progress Objectively
Chapter 3. Focus Continuously on Quality
Practice 5. Test Your Own Code
Practice 6. Leverage Test Automation Appropriately
Practice 7. Everyone Owns the Product!
Chapter 4. Balance Stakeholder Priorities
Practice 8. Understand the Domain

Practice 9. Describe Requirements from the User Perspective
Practice 10. Prioritize Requirements for Implementation
Practice 11. Leverage Legacy Systems
Chapter 5. Collaborate Across Teams
Practice 12. Build High-Performance Teams
Practice 13. Organize Around the Architecture
Practice 14. Manage Versions
Chapter 6. Elevate the Level of Abstraction
Practice 15. Leverage Patterns
Practice 16. Architect with Components and Services
Practice 17. Actively Promote Reuse
Practice 18. Model Key Perspectives
Chapter 7. Adapt the Process
Practice 19. Rightsize Your Process
Practice 20. Continuously Reevaluate What You Do
Chapter 8. Making Practical Use of the Best Practices
Which Practices Should I Adopt First?
Start with the Basics
Adopt Related Practices
Practices Supporting Iterative Development
How Can RUP and EPF Help Me?
Choosing the Right Pilot Project
Conclusions
Appendix A. The Eclipse Process Framework (EPF)
Why EPF?
What Is EPF?
Potential Users of EPF
Extensible Process Content
Software Process Engineering Metamodel
Extensible Process Engineering Tools

Participating in the Development of EPF
Appendix B. IBM Rational Method Composer (RMC)
Process for a Variety of Projects
Process for the Enterprise
How the Practitioner Uses RMC


How a Project Manager Uses RMC
How Process Managers Use RMC
Guiding Principles for Evolving IBM Rational Method Composer
Glossary
Bibliography
Index


Copyright
Many of the designations used by m anufacturers and sellers to distinguish their products are claim ed as tradem ark s. W here those designations appear in this
book , and the publisher was aware of a tradem ark claim , the designations have been printed with initial capital letters or in all capitals.
IBM, ClearCase, O bjectory, PurifyPlus, Rational, Rational Unified Process, RequisitePro, RUP, SUMMIT, and SUMMIT Ascendant are registered tradem ark s of
International Business Machines Corporation in the United States, other countries, or both.
Special perm ission to use and reproduce ex cerpts and im ages from the RUP product in Agility and Discipline Made Easy is granted by International Business Machines
Corporation.
Eclipse is a tradem ark of Eclipse Foundation, Inc.
Som e of the m aterial in this book is adapted from The Rational Unified Process Made Easy (Per Kroll and Philippe Kruchten, © 2003 Pearson Education).
Kroll/Kruchten, The Rational Unified Process Made Easy, p. 146 Figure 8-3, p. 302 Figure 15-5, © 2003 Pearson Education, Inc. Reprinted by perm ission of Pearson
Education, Inc., publishing as Pearson Addison-W esley. All rights reserved.
Material in the introductions of Chapters 27 previously appeared in Per Kroll and W alk er Royce, "Key Principles for Business-Driven Developm ent," The Rational Edge,
O ctober 2005. Used with perm ission.
The authors and publisher have tak en care in the preparation of this book , but m ak e no ex pressed or im plied warranty of any k ind and assum e no responsibility
for errors or om issions. No liability is assum ed for incidental or consequential dam ages in connection with or arising out of the use of the inform ation or program s

contained herein.
The publisher offers ex cellent discounts on this book when ordered in quantity for bulk purchases or special sales, which m ay include electronic versions and/or
custom covers and content particular to your business, training goals, m ark eting focus, and branding interests. For m ore inform ation, please contact:
U.S. Corporate and Governm ent Sales
(800) 382-3419

For sales outside the United States please contact:
International Sales

Visit us on the W eb: www.awprofessional.com
Library of Congress Cataloging-in-Publication Data
Kroll, Per.
Agility and discipline m ade easy : practices from O penUP and RUP / Per Kroll, Bruce MacIsaac.
p. cm .
Includes bibliographical references and index .
ISBN 0-321-32130-8 (pbk . : alk . paper)
1. Com puter softwareDevelopm ent. 2. Software engineering. I. MacIsaac, Bruce. II. Title.
Q A76.76.D47K746 2006
005.1dc22
2006003472
Copyright © 2006 Pearson Education, Inc.
All rights reserved. Printed in the United States of Am erica. This publication is protected by copyright, and perm ission m ust be obtained from the publisher prior to
any prohibited reproduction, storage in a retrieval system , or transm ission in any form or by any m eans, electronic, m echanical, photocopying, recording, or
lik ewise. For inform ation regarding perm issions, write to:
Pearson Education, Inc.
Rights and Contracts Departm ent
75 Arlington Street, Suite 300
Boston, MA 02116
Fax : (617) 848-7047
Tex t printed in the United States on recycled paper at Courier in Stoughton, Massachusetts.

First printing, May 2006.

Dedication
To Natasha, Per's wonderful daughter, conceived at the same time as this bookalmost
and
To Mary MacIsaac, Bruce's grandmother, who turns 112 as this book is completed


Praise for Agility and Discipline Made Easy
"The Japanese sam urai Musashi wrote: 'O ne can win with the long sword, and one can win with the short sword. W hatever the weapon, there is a tim e
and situation in which it is appropriate.'
"Sim ilarly, we have the long RUP and the short RUP, and all sizes in between. RUP is not a rigid, static recipe, and it evolves with the field and the
practitioners, as dem onstrated in this new book full of wisdom to illustrate further the liveliness of a process adopted by so m any organizations
around the world. Bravo!"
Philippe Kruchten, Professor, University of British Colum bia
"The Unified Process and its practices have had, and continue to have, a great im pact on the software industry. This book is a refreshing new look at
som e of the principles underlying the Unified Process. It is full of practical guidance for people who want to start, or increase, their adoption of proven
practices. No m atter where you are today in term s of software m aturity, you can start im proving tom orrow."
Ivar Jacobson, Ivar Jacobson Consulting
"Kroll and MacIsaac have written a m ust-have book . It is well organized with new principles for software developm ent. I encounter m any book s I
consider valuable; I consider this one indispensable, especially as it includes over 20 concrete best practices. If you are interested in m ak ing your
software developm ent shop a better one, read this book !"
Ricardo R. Garcia, President, Global Rational User Group Council, www.rational-ug.org/index .php
"Agile software developm ent is real, it work s, and it's here to stay. Now is the tim e to com e up to speed on agile best practices for the Unified
Process, and this book provides a great starting point."
Scott W . Am bler, practice leader, Agile Modeling
"IBM and the global econom y have becom e increasingly dependent on software over the last decade, and our industry has evolved som e
discrim inating best practices. Per and Bruce have captured the principles and practices of success in this concise book ; a m ust for ex ecutives, project
m anagers, and practitioners. These ideas are progressive, but they strik e the right balance between agility and governance and will form the
foundation for successful system s and software developers for a long tim e."

W alk er Royce, Vice President, IBM Software Services-Rational
"Finally, the RUP is presented in digestible, byte-size pieces. Kroll and MacIsaac effectively describe a set of practices that can be adopted in a lowcerem ony, ad hoc fashion, suited to the culture of the m ore agile project team , while allowing them to understand how to scale their process as
needed."
Dean Leffingwell, author and software business advisor and ex ecutive
"This tex t fills an im portant gap in the k nowledge-base of our industry: providing agile practices in the proven, scalable fram ework of the Unified
Process. W ith each practice able to be throttled to the unique contex t of a developm ent organization, Kroll and MacIsaac provide software team s with
the ability to balance agility and discipline as appropriate for their specific needs."
Brian G. Lyons, CTO , Num ber Six Software, Inc.


The Addison-Wesley Object Technology Series
Grady Booch, Ivar Jacobson, and Jam es Rum baugh, Series Editors
For m ore inform ation, check out the series web site at www.awprofessional.com /otseries.
Ahm ed/Um rysh, Developing Enterprise Java Applications with J2EE™ and UML
Arlow/Neustadt, Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML
Arlow/Neustadt, UML 2 and the Unified Process, Second Edition
Arm our/Miller, Advanced Use Case Modeling: Software Systems
Bellin/Sim one, The CRC Card Book
Bergström /Råberg, Adopting the Rational Unified Process: Success with the RUP
Binder, Testing Object-Oriented Systems: Models, Patterns, and Tools
Bittner/Spence, Use Case Modeling
Booch, Object Solutions: Managing the Object-Oriented Project
Booch, Object-Oriented Analysis and Design with Applications, 2E
Booch/Bryan, Software Engineering with ADA, 3E
Booch/Rum baugh/Jacobson, The Unified Modeling Language User Guide, Second Edition
Box et al., Effective COM: 50 Ways to Improve Your COM and MTS-based Applications
Buck ley/Pulsipher, The Art of ClearCase® Deployment
Carlson, Modeling XML Applications with UML: Practical e-Business Applications
Clark e/Baniassad, Aspect-Oriented Analysis and Design
Collins, Designing Object-Oriented User Interfaces

Conallen, Building Web Applications with UML, 2E
Denney, Succeeding with Use Cases
D'Souza/W ills, Objects, Components, and Frameworks with UML: The Catalysis(SM) Approach
Douglass, Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns
Douglass, Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems
Douglass, Real Time UML, 3E: Advances in The UML for Real-Time Systems
Eeles et al., Building J2EE™ Applications with the Rational Unified Process
Fowler, Analysis Patterns: Reusable Object Models
Fowler, UML Distilled, 3E: A Brief Guide to the Standard Object Modeling Language
Fowler et al., Refactoring: Improving the Design of Existing Code
Gom aa, Designing Concurrent, Distributed, and Real-Time Applications with UML
Gom aa, Designing Software Product Lines with UML
Heinck iens, Building Scalable Database Applications: Object-Oriented Design, Architectures, and Implementations
Hofm eister/Nord/Dilip, Applied Software Architecture
Jacobson/Booch/Rum baugh, The Unified Software Development Process
Jacobson/Ng, Aspect-Oriented Software Development with Use Cases
Jordan, C++ Object Databases: Programming with the ODMG Standard
Kleppe/W arm er/Bast, MDA Explained: The Model Driven Architecture™: Practice and Promise
Kroll/Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP
Kruchten, The Rational Unified Process, 3E: An Introduction
LaLonde, Discovering Smalltalk
Lau, The Art of Objects: Object-Oriented Design and Architecture
Leffingwell/W idrig, Managing Software Requirements, 2E: A Use Case Approach
Manassis, Practical Software Engineering: Analysis and Design for the .NET Platform
Marshall, Enterprise Modeling with UML: Designing Successful Software through Business Analysis
McGregor/Syk es, A Practical Guide to Testing Object-Oriented Software
Mellor/Balcer, Executable UML: A Foundation for Model-Driven Architecture
Mellor et al., MDA Distilled: Principles of Model-Driven Architecture
Naiburg/Mak sim chuk , UML for Database Design
O estereich, Developing Software with UML, 2E: Object-Oriented Analysis and Design in Practice

Page-Jones, Fundamentals of Object-Oriented Design in UML
Pohl, Object-Oriented Programming Using C++, 2E
Pollice et al. Software Development for Small Teams: A RUP-Centric Approach
Q uatrani, Visual Modeling with Rational Rose 2002 and UML
Rector/Sells, ATL Internals
Reed, Developing Applications with Visual Basic and UML
Rosenberg/Scott, Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example
Rosenberg/Scott, Use Case Driven Object Modeling with UML: A Practical Approach
Royce, Software Project Management: A Unified Framework


Rum baugh/Jacobson/Booch, The Unified Modeling Language Reference Manual
Schneider/W inters, Applying Use Cases, 2E: A Practical Guide
Sm ith, IBM Smalltalk
Sm ith/W illiam s, Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software
Tk ach/Fang/So, Visual Modeling Technique
Tk ach/Puttick , Object Technology in Application Development, Second Edition
Unhelk ar, Process Quality Assurance for UML-Based Projects
W arm er/Kleppe, The Object Constraint Language, 2E: Getting Your Models Ready for MDA
W hite, Software Configuration Management Strategies and Rational ClearCasereg;: A Practical Introduction

The Component Software Series
Clem ens Szypersk i, Series Editor
For m ore inform ation, check out the series web site at www.awprofessional.com /csseries.
Cheesm an/Daniels, UML Components: A Simple Process for Specifying Component-Based Software
Szypersk i, Component Software, 2E: Beyond Object-Oriented Programming


Foreword
Since that first day when the first software developm ent team collaborated to deliver the first econom ically viable software-intensive system , there has been and

continues to be a philosophical as well as a pragm atic battle over how best to organize a team and how to orchestrate its work . At one ex trem e are those who
advocate high-cerem ony processes involving rigidly defined artifacts and a strict ordering of activities; at the other ex trem e are those who em brace low-cerem ony
processes involving a fierce focus on coding, with everything else considered irrelevant or inconsequential. The pendulum has swung between these two ex trem es
for years.
The good news is that, with decades of ex perience in delivering software-intensive system s behind us, it is now possible to identify what has work ed for successful
organizations and reject what is com m on am ong unsuccessful ones. This is the essence of the Unified Process, in both the Rational Unified Process (RUP) and its
sim pler open-source version, O pen Unified Process (O penUP): RUP and O penUP are both sim ply elaborations of a sm all set of best practices that have proved
them selves in practice.
In this book , Per and Bruce ex plain the six k ey principles that serve as the foundation of RUP and O penUP. For each of these principles, the authors discuss the
points of pain that each principle addresses, the contex t for that principle, and pragm atic advice on applying it. Since no single process can work in the sam e
fashion for every conceivable com bination of dom ain and developm ent culture, the authors go on to describe how each of these principles can be adapted across
the full spectrum of low- to high-cerem ony use.
Per and Bruce are well suited to this task : both have engaged in a m ultitude of projects over the years, and both have been deeply involved in the form ulation of
RUP and O penUP. I can think of no authors better qualified to bring you the essence of these processes.
Grady Booch
IBM Fellow


Preface
The goal of this book is to describe a set of well-defined practices that you and your team can start adopting today. You can choose to adopt only one practice or
adopt all of them over a period of tim e. The practices in this book have been shown to im prove the quality, predictability, speed, and/or cost of software
developm ent.

Why We Wrote This Book
During m ore than a decade of assisting com panies in im proving their software developm ent practices and leading the developm ent of the Rational Unified Process
(RUP), we have had the opportunity to see what work s and what doesn't. W e have seen the rewards of successful adoption of RUP, and we have seen the
challenges that projects and team m em bers m ay encounter along the way. O ver the last few years, we have also learned a lot from the agile m ovem ent, with its
increased focus on people and low-cerem ony approaches to software developm ent. More recently, we have also been k ey drivers of an open source project, the
Eclipse Process Fram ework (EPF), which includes the O pen Unified Process (O penUP)an open-source version of the Unified Process. O ne of the objectives of EPF is
to create a repository of industry practices, which are custom izable and can be assem bled into a set of out-of-the-box processes reflecting different developm ent

styles. Through all of this work , we have gained valuable ex periences in what work s and what doesn't, as well as how to pack age that k nowledge into pragm atic
practices that can be easily adopted.
W e have found that m any com panies view im proving their software developm ent capabilities as a staggering task . It seem s to be lik e eating an elephant: where
do you start, and how do you go about it? The answer? You pick a tender spot and tak e one bite at a tim e. The "tender spot" is where you have the m ost pain; the
"one bite at a tim e" is one or two practices, one or two software disciplines, and/or one or two tools. In other words, tak e "good bites." You don't want to chok e on
them . You want to be just a little bit hungry for the nex t bite.
This book describes a num ber of "good bites" that will allow you to start im proving your software developm ent capabilities today. You can tak e one bite or a larger
num ber of bites, all based on your appetite.
W e want to reduce the initial anx iety and cost associated with tak ing on a software im provem ent effort by providing an easy and unintrusive path toward im proved
results, without overwhelm ing you and your team . At the sam e tim e we want to show early results that k eep the m om entum going, thus m aintaining the interest
and com m itm ent of everyone involved.
The practices in this book are written independently of any one specific process. Tak en together, however, they do cover m any k ey aspects of RUP and O penUP.
W e believe that this book will be an asset for projects and com panies interested in adopting som e or all of RUP or O penUP. Each of the practices described in this
book distills k nowledge from RUP, O penUP, and other sources to provide pragm atic guidance on how to solve a particular software developm ent problem . They help
you in your software im provem ent effort by attack ing one problem at a tim e. Each practice describes how O penUP and RUP can help you adopt the practice and also
references other m ethods such as eXtrem e Program m ing (XP) [1] and Scrum , [2] so that you can understand differences and sim ilarities in relation to other
m ethods. This book can also be valuable for projects and com panies with no interest in RUP or O penUP. You can sim ply tak e any num ber of the practices in this
book and adopt them on their own.
[1]

1 See Beck 2004.

[2]

2 See Schwaber 2002.

What Will You Learn from This Book?
This book will fam iliarize you with the following:
A num ber of k ey principles for software developm ent, which have been validated by thousands of successful software projects of different sizes in a variety
of industries.

A num ber of concrete practices that you and your team can adopt today that support the k ey principles. Each of the practices described provides inform ation
on the following categories:
- The problem the practice addresses
- How you practically go about adopting the practice
- Related practices
- W here to read m ore about the practice
- How to increm entally adopt practices with m inim al risk , and how to leverage RUP and O penUP

Who Should Read This Book?
This book is aim ed specifically at the following readers:
All m em bers of a software developm ent team who would lik e to learn som e practices that can be applied today.
Team m em bers who would lik e to learn RUP or O penUP, one practice at a tim e. This book does not give you an understanding of the com plete RUP or
O penUP, but if you have understood the practices described in this book , you have com e a long way in learning about RUP and O penUP.
Managers, process engineers, and others who want to understand how key practices can be adopted in their organization, one practice at a tim e.

Structure and Content of This Book
The book is divided into eight chapters. Chapter 1 provides an overview of six k ey principles for software developm ent that are used as a base for the structure of
this book . Chapter 1 also provides an overview of RUP, O penUP, XP, and Scrum .
Chapters 2 through 7 review each of the six k ey principles in turn. For each principle, we describe a num ber of practices that support it. Most practices can be
adopted individually, allowing you to understand how to m ak e quick im provem ents in your developm ent without having to im plem ent too m uch change. Chapter 8
describes how to adopt and benefit from these practices.

How to Read This Book
This book can be read using any of three approaches:
1. Read only the parts that m ak e sense for your team . Start by reading Chapter 1. Determ ine which k ey principle you think would add the m ost value to you
and your team . Go to the corresponding chapter. Look through the practices listed for that chapter, and read those you find of m ost interest. Does the
problem addressed by each practice coincide with a problem you are facing, and is it worth fix ing? If so, share those with your team m em bers and get
agreem ent to adopt the ones that pertain to your situation.
O nce you have adopted the identified practices, use the sam e approach to identify the nex t set of practices to read up on. This approach is described in
m ore detail in Chapter 8.

2. Read the parts that are relevant for your role. Note that since software developm ent is a team effort, it is good to be at least som ewhat fam iliar with
practices for other roles. The list below identifies the chapters and practices that probably are the m ost applicable for each of the roles on a software team .


- Project Manager: read Chapters 1 and 8 and Practices 14, 710, 1213, and 1920.
- Architect: read Chapter 1 and Practices 1, 2, 1011, 1518, and 20.
- Analyst: read Chapter 1 and Practices 12, 710, 12, and 20.
- Developer: read Chapter 1 and Practices 12, 59, 1112, 1418, and 20.
- Tester: read Chapter 1 and Practices 12, 49, 12, and 20.
3. Read the book from start to finish to learn as m uch as possible about practices applicable for all m em bers on your team

For More Information
To learn m ore about or to download EPF and O penUP, go to the Eclipse Foundation W eb site at www.eclipse.org/epf/.
RUP is delivered through the product IBM Rational Method Com poser (RMC). Additional inform ation about RUP or RMC, including a data sheet and a product dem o,
can be obtained from IBM at .com /software/awdtools/rm c/.
Inform ation about the Rational Software Global User Group Com m unity can be found at .php.Academ ic institutions can contact IBM
for inform ation on a special program for including RUP in a software engineering curriculum at .com /university/.

Acknowledgments
The ideas and thoughts synthesized in this book have been derived from m any sources. W e have learned a lot from the m any talented individuals inside and
outside IBM who have helped shape RUP and m ak e it work in the trenches. W e have also learned from the agile com m unity, Eclipse, and the various process
com m unities. W e especially appreciate those who challenged our ideas, helping us to evolve and sharpen what we present in this book .
This book would not have been written if not for the RUP product and its current product team : Am anda Brijpaul, Ricardo Balduino, Trevor Collins, Carlos Goti,
Michael Hanford, Peter Haum er, Margaret Hedstrom , Kelli Houston, Russell Pannone, Thierry Paradan, Cecile Peraire, Dan Popescu, Michael Stern, Pawan Rewari,
Jim Ruehlin, Jeff Sm ith, John Sm ith, and Gordon Schneem ann.
O ver the years, the Rational field team s and technical ex perts have accum ulated a lot of ex perience in im plem enting and using RUP. W e are grateful for the m any
perceptive review com m ents and ideas from these ex perts, who have added m any insights into what does and does not work out in the trenches. W e would
especially lik e to recognize David Alvey, Kurt Bittner, Bill Cottrell, Peter Eeles, Bill Higgins, Kelli Houston, Saif Islam , W alk er Royce, and John Sm ith.
O ur ex ternal reviewers provided invaluable feedback , forcing us to rethink the structure and content of the book and hopefully helping us to create a book that is
easier to read and addresses the m ost relevant issues for a book about agility and discipline. These insights were provided by Scott Am bler, Joshua Barnes, Lisa

Crispin, Jim Dunion, Ivar Jacobson, Philippe Kruchten, Tom Poppendieck , Dan Rawsthorne, Chris Sosk in, Christoph Steindl, Garth Richm ond, Dave Thom as, David
Trent, and Michael Vizdos.
Heath Newburn, Ted Rivera, and Scott W ill assisted us through their deep ex pertise in testing, each contributing a practice to this book , for which we are m ost
grateful.
Catherine Southwood and Deborah Fogel deserve special thank s for m ak ing a proper m anuscript out of our scribbles, as did Mik e Perrow.
W riting a book always tak es m ore tim e than you think it will, and we want to thank our wives and k ids, Susan and Natasha Kroll, along with Kathy, Blaise, and
Courtney MacIsaac, for being patient with the m any week ends and nights spent writing and rewriting the book .
Finally, m any thank s to our editor, W illiam Zobrist, for corralling us through the writing process; to Mary O 'Brien, for tak ing on this book ; and to the production and
m ark eting team s at Addison-W esley, notably Tyrrell Albaugh, Stephane Nak ib, and Kim Silvestro, for helping us to get this book out.


About the Authors

Per Kroll is the project leader on the Eclipse Process Fram ework Project, an open-source project, and developm ent m anager for RUP and IBM Rational Method
Com poser. He is responsible for IBM Rational's strategy in the process area, including integration between m ethods and tools, and m ethod integration within IBM.
Per has twenty years of software developm ent ex perience in supply chain m anagem ent, telecom , com m unications, and software product developm ent. He is the
coauthor of the highly acclaim ed The Rational Unified Process Made Easy (Addison-W esley).
Per lives in Los Gatos, California, with his wife, Susan, daughter, Natasha, and golden retriever, Copper. He enjoys running, playing floorball (a com m on Nordic
sport centered around beating other m iddle-aged m en over the shins), hik ing, and any type of board gam e. He is k nown to have an occasional beer, and he loves
to dance.

Bruce MacIsaac is the technical lead and m anager for RUP and O penUP content developm ent at IBM Rational. O ver the last twenty years, Bruce has served in a
variety of m anagem ent and technical roles, leading both sm all and large software developm ent team s. More recently, he developed the first version of IRUP, the
IBM internal-tailored instance of RUP, co-developed the initial version of O penUP, and led the m igration of RUP to its m ost recent incarnation in Rational Method
Com poser. He is now responsible for realizing IBM process strategy, integrating ex isting m ethods in a scaleable fram ework , and developing new content to cover
the needs of different k inds of projects and businesses.
Bruce left the rain of Vancouver, British Colum bia, in 2004 with his wife, Kathy, and children, Blaise and Courtney, to dry out in San Jose, California. He enjoys
roller-blading, sk iing, tennis, and all styles of dance. Although Bruce and Per enjoy m any of the sam e things, they are easy to tell apartBruce has m ore hair and is
a better dancer.

Chapter 1. Leveraging Key Development Principles
This book provides a set of software engineering best practices that your project can start using right away to im prove the way you develop software. The practices
can be adopted individually, but they also support each other. This m eans that you can pick a set of practices to adopt and be able to m ak e sense of them without
having to adopt all of the practices. As you adopt m ore and m ore of the practices, you will start to notice the synergy am ong them . Each practice becom es a piece
of a puzzle, and tak en together, though not com plete, they constitute the back bone of a process that is iterative, agile, and scales to your project needs. See the
Preface for how to use this book .
Practices can be adopted individually.


Where Do the Practices Come From?
W e have chosen the best practices in this book based on principles gleaned from a huge num ber of successful projects and distilled into a few sim ple guidelines
that we call k ey developm ent principles (see the section Key Developm ent Principles later in this chapter). Grouping the practices under these k ey developm ent
principles allows you to identify proven principles that address the issues your project is facing and review the practices supporting each principle to see how you can
m ak e progress toward adopting the principle. W e will discuss the topic of adoption in m ore detail in Chapter 8, "Mak ing Practical Use of the Best Practices."
These practices borrow from a large num ber of iterative and agile processes, all sharing a focus on iterative developm ent; continuous integration; early and
continuous testing; addressing custom er needs; people and team collaboration; and m inim izing process overhead.
OpenUp is an open-source version of the Unified Process.

The practices capture m uch of the thought that was form ative in the creation of the Open Unified Process (OpenUP), especially its m ost agile and lightweight form ,
O penUP/Basic, targeting sm aller and collocated team s interested in agile and iterative developm ent. O penUP is a part of the Eclipse Process Framework [1] (EPF),
an open source process fram ework developed within the Eclipse open source organization. [2] It provides best practices from a variety of software developm ent
thought leaders and the broader software developm ent com m unity that cover a diverse set of perspectives and developm ent needs. Som e of the practices in the
EPF m ay differ from the ones you find in this book , because they were produced by people with a different view of how to develop software or targeted a different
type of project. This is one of EPF's strengths: allowing diversity of ideas, while encouraging learning from each other, thereby driving unification and evolution of
best practices. W e believe that reading this book will help you gain insights into k ey aspects of O penUP/Basic as well as EPF; see the section O penUP/Basic later in
this chapter and Appendix A for m ore detail.
[1]

www.eclipse.org/epf/.

[2]

www.eclipse.org.

EPF is an open source process framework.

RUP is a continually evolving process framework that extends EPF.

The k ey developm ent practices also have a strong connection to RUP. RUP is a continually evolving process fram ework . It started in 1987 as the O bjectory
Process [3], a use-case-driven and object-oriented process, and in 1996 was integrated with the Rational Process [4], an iterative and architecture-centric process.
Since 1996, it has integrated best practices from a broad set of sources, including processes for testing, configuration m anagem ent, agile developm ent, serviceoriented architecture, and business engineering [5] RUP ex tends EPF with in-depth process content for specific technologies and tools, such as J2EE and IBM tools;
for specific dom ains, such as pack aged application developm ent, system s engineering, and program m anagem ent; and for process m aturity standards and
fram ework s, such as SEI CMMI.
[3]

See Jacobson 1992.

[4]

See Devlin 1995.

[5]

See Appendix B and Kroll 2001 for the history of RUP.

Som e of the practices in this book are m ore appropriate for projects that need to follow a higher-cerem ony process, m ak ing them better reflect RUP than the
lighter-weight guidance in EPF. W e believe that RUP users will find the practices in this book valuable, because they articulate a clear set of principles for developing
software. Unfortunately, too m any RUP users do not adhere to these principles (see Key Developm ent Principles later in this chapter) and so m isinterpret the
underlying spirit of RUP.

XP, Scrum, Agile Modeling, Crystal, Agile Data Method, and DSDM have influenced this book.

O ther iterative and agile processes, including eXtrem e Program m ing (XP), [6] Scrum , [7] Agile Modeling, [8] Crystal, [9] Agile Data Method, [10] and Dynam ic System s
Developm ent Method (DSDM) [11] have influenced the practices in this book , just as they have influenced RUP and O penUP.
[6]

See Beck 2004.

[7]

See Schwaber 2002.

[8]

See Ambler 2002.

[9]

See Cockburn 2002

[10]

See Ambler 2003.

[11]

See Stapleton 2003.


Using Practice Descriptions

Each k ey developm ent principle is discussed in its own chapter and contains the practices that support that principle. For ex am ple, the principle Dem onstrate Value
Iteratively is supported by the practice Manage Risk , which gives concrete guidance on one of several practices that will help you to adhere to the principle
effectively. Each practice description discusses the following:
Problem: the problem that the practice addresses
Background: back ground inform ation
A pplication: how to apply the practice
Comparison with other practices: how the practice com pares with practices found in m ajor iterative and agile developm ent processes, including XP and
Scrum
A doption: how to im plem ent the practice at different levels of adoption
Related best practices: additional supporting practices
A dditional information: additional reference inform ation available in O penUP and RUP, and in book s relevant to the practice
There m ay be practices that do not fit your project or organization at this tim e for technical, cultural, business, or other reasons. You m ay find that you are already
following other practices. Most practices can be adopted at different levels, allowing you to adopt m ore practices over tim e as well as im plem ent them at a higher
level. W e believe that gradually adopting a distinct set of practices at a level appropriate for your organization will enable you to start im proving today, and to
continue im proving over subsequent projects, without requiring that you change everything at once. See the following section for m ore inform ation on the different
levels of adopting a practice.
Before we dive into the practices, let's discuss the process of adopting the practices: iterative developm ent, levels of cerem ony and agility, followed by the k ey
developm ent principles. W e will then provide an overview of the Unified Process lifecycle, followed by an overview of O penUP/Basic, RUP, XP, and Scrum in turn.


Adopting the Practices: Iterative Development, Levels of Ceremony, and Agility
A k ey aspect of this book is to allow you to m ove increm entally from where you are today to where you would lik e to be a couple of years from now, adopting the
practices at your own pace.

Levels of Adopting the Practices
Each practice can be adopted at three different levels: basic, interm ediate, and advanced. The basic level represents a level of adoption we think m ost projects can
adhere to with lim ited investm ents, that is, with a lim ited sk ill set and with no or sm all am ounts of tool investm ents. This level thus represents a reasonable
starting point on your journey toward im proved ability to develop software effectively, but it is not necessarily an acceptable end goal. As you m ove to the
interm ediate and advanced levels of adoption, you will have to m ak e additional investm ents in building sk ills and/or tools. For som e team s and practices, the basic
or interm ediate adoption level is preferable. O ther team s should aim at adopting advanced-level practices for m ax im um productivity.

Each practice can be adopted at three levels: basic, intermediate, and advanced.

Process Map
To understand the level that is appropriate for your team , we will use a process m ap (see Figure 1.1) characterized by two dim ensions discussed below: [12]
[12]

See Chapter 3 in Kroll 2003 for an in-depth discussion on the process map.

Low ceremony/High ceremony [13] dim ension on the horizontal ax is. Low ceremony produces m inim um supporting docum entation and has little form ality
in the work ing procedure; High ceremony has com prehensive supporting docum entation, traceability m aintained between artifacts, Change Control Boards,
and so on.
[13]

Cockburn refers to "Ceremony" as "Methodology Weight." See page 123 in Cockburn 2002 for an interesting discussion on this topic.

Waterfall/Iterative dim ension on the vertical ax is. Waterfall is a linear approach with late integration and testing; Iterative is a risk -driven developm ent
approach with early and continuous im plem entation, integration, testing, and validation of software that delivers concrete value to the stak eholders.

Figure 1.1. Process Map for Process and Practice Comparison.
By organizing processes and practices along two dimensionsLow ceremony/High ceremony and Waterfall/Iterativeyou can compare them and analyze which are
more suitable for your project or organization. Agility translates to being in the lower-left quadrant on the map.

(Adapted from Kroll 2003.)

Agility and Ceremony
Agility is the ability to respond rapidly to risks and change.

W e define agility as the ability to respond to risks rapidly; changing requirements or stakeholders needs, or other changes impacting the application we are building. [14] Agility
translates to being in the lower-left quadrant in our process m ap. Iterative developm ent provides us with the rapid and tim ely feedback we need to understand
when and what to change, and the low cerem ony provides us with the ability to ex ecute changes rapidly.

[14]

Compare Larman 2004, page 25, "agilityrapid and flexible response to change."

So, do we always want to be in the lower-left "agility" corner? If you are two developers building an application with a short life span, you m ay choose to save tim e
by not docum enting m any of the requirem ents or the design. This m ay allow you to be m ore productive and to m ak e rapid changes to the application. However, if
you are doing distributed developm ent with twenty people in different tim e zones, you will probably be m ore productive if you docum ent the requirem ents and k ey


design decisions. But the added cerem ony will add tim e and cost when you have to im plem ent a change. You therefore choose to m ove to the right on the process
m ap to gain productivity, while losing agility. By deploying the right tools, however, you can counter this loss and reduce the cost of change, allowing you also to
m ove down on the scale.
Most projects [15] benefit from being as low as possible on the waterfall/iterative ax is to ensure rapid feedback , but not so low that the cost associated with the
overhead of each iteration becom es prohibitive. O ne of the aim s of iterative developm ent is to reduce the overhead cost of each iteration so that you can do m ore
iterations, and m any of the practices in this book help you achieve that goal. As Professor Barry Boehm points out in Get Ready for Agile Methods, with Care, [16] each
project should choose the appropriate level of cerem ony to fit its specific needs (Boehm used the term "agile" to m ean roughly the sam e as what we refer to as
"cerem ony.") This m eans that each project should be as agile as possible based on its specific characteristics, but not m ore agile.
[15]

A few projects with very well understood requirements and architecture, facing very limited risk, are exceptions to this rule and may benefit from waterfall development.

[16]

See Boehm 2002.

Most, but not all, advanced practices lead to higher levels of cerem ony. If your project is better off following a low-ceremony process, you should probably not adopt an
advanced practice if it leads to higher level of ceremony. O n the other hand, there are m any reasons why projects m ay benefit from m ore cerem ony, including large
project size, regulatory requirem ents, distributed developm ent, com plex projects, long application life span, or com plex stak eholder relations. In som e cases an
advanced adoption level leads to less cerem ony and shorter and m ore frequent iterations, which is probably beneficial for m ost projects that are willing to tak e on
the investm ent.

Where Does a Level of Adoption Take You on the Process Map?
W e describe the levels of adoption for each practice, as well as giving an indication of the direction in which the adoption level will tak e you on the process m ap.
Let's look at ex am ples of som e of the sym bols we use:

If the arrow goes down and to the left, it m eans that adopting the practice at this level will lead to, or enable you to have, shorter iterations with a decreased level
of cerem ony. This is typical for m any of the practices at the basic level but could also be true for the interm ediate and advanced levels.

If the arrow goes down and to the right, it m eans that adopting the practice at this level will lead to, or enable you to have, shorter iterations, while increasing the
level of cerem ony or learning curve for new team m em bers. This outcom e m ay be desirable if your project needs m ore cerem ony, or if team m em bers need to
build m ore sk ills, but if that is not the case, your project should consider not adopting the practice at this level.

If the arrow goes up and to the right, it m eans that adopting the practice at this level will increase the level of cerem ony you are work ing with, as well as the
overhead associated with doing shorter iterations, potentially forcing you to increase the iteration length. These are typically not good changes for a project, but the
benefits of im plem enting the practice m ay be valuable enough to counteract the drawback s.


Key Development Principles
The practices in this book are organized according to six fundam ental principles observed by IBM to characterize the m ost successful projects in the software
developm ent industry. [17] Many of the following principles (see Figure 1.2) are found to som e degree in m ost iterative and agile processes:
[17]

These six principles are an evolution of what IBM Rational previously called the 6 Best Practices.

1. A dapt the process.
2. Balance stak eholder priorities.
3. Collaborate across team s.
4. Dem onstrate value iteratively.
5. Elevate the level of abstraction.
6. Focus continuously on quality.

Figure 1.2. Principles for Business-Driven Development.
These six principles characterize the software development industry's best practices in the creation, deployment, and evolution of software-intensive systems.
They have been derived by IBM through workshops with thousands of development managers and executives and by synthesizing input from a large number of
technical leaders within IBM who are working with software development organizations across all industries.

Six fundamental principles characterize the most successful projects in the software industry.

Each of these principles is described in a separate chapter giving an overview of the principle, outlining the patterns of behavior that best em body each principle,
and listing the m ost recognizable anti-patterns that can harm software developm ent projects. The prim ary focus of each chapter is a set of supporting practices that
will help your team to adhere to the principle. To provide a m ore logical sequence for the book , we have chosen to present the chapters in a different order from
the alphabetical order in which the principles are listed above. There is no particular significance to the ordering of practices within a chapter. The principles and
their supporting best practices are listed below in the order in which they appear in the book .
Each principle and supporting practices is described in a separate chapter.

Demonstrate value iteratively.
Each iteration should deliver increm ental capabilities that are assessed by stak eholders. This enables you to get feedback from stak eholders as well as on
progress m ade so that you can adapt your plans as required. Iterative developm ent also allows you to focus each iteration on addressing the k ey risk s that
the project is currently facing, allowing you to increase predictability.
Practice 1 Manage risk .
Practice 2 Ex ecute your project in iterations.
Practice 3 Em brace and m anage change.
Practice 4 Measure progress objectively.
Focus continuously on quality.
Continuously im proving quality requires m ore than just testing to validate fitness for use. Rather, it involves all team m em bers throughout the
lifecyclehaving them build quality into the process and the product. An iterative approach focuses on early testing and test-and-build autom ation throughout
the lifecycle as a m eans to reduce the num ber of defects, provide fact-based quality m etrics early on, and allow you to plan and adapt your product m ore
effectively based on reality.
Practice 5 Test your own code.
Practice 6 Leverage test autom ation appropriately.

Practice 7 Everyone owns the product.
Balance stakeholder priorities.
There will always be m any com peting stak eholder priorities, such as producing a solution rapidly and inex pensively versus addressing all the business
requirem ents. W e need to work closely with the stak eholders to m ak e sure that we understand their priorities and to prioritize the right projects and the
project requirem ents. W e also need to strik e the right balance between leveraging ex isting assets and building custom software, ack nowledging that in
som e cases the form er m ay require com prom ising on what requirem ents to address.
Practice 8Understand the dom ain.


Practice 9Describe requirem ents from the user perspective.
Practice 10Prioritize requirem ents for im plem entation.
Practice 11Leverage legacy system s.
Collaborate across teams.
W e need to enable people to work at their best. This m eans that we need to equip talented people with the right sk ills, break down walls that prevent a
project team from collaborating effectively, and put in place the right environm ents to facilitate m eaningful collaboration. As software becom es increasingly
critical to how we run our business, we also need to m ak e sure that we work well together across business, software, and operational team s.
Practice 12Build high-perform ance team s.
Practice 13O rganize around the architecture.
Practice 14Manage versions.
Elevate the level of abstraction.
Com plex ity is a m ajor enem y to project success, and m inim izing the am ount of code, data structures, com ponents, m odel elem ents, or other constructs
hum ans produce during a project is crucial to reducing com plex ity. You can achieve this goal by reusing ex isting assetssuch as business m odels,
com ponents, patterns, and servicesinstead of custom -building new ones. You can also leverage higher-level languages, fram ework s, and tools that can
generate code from higher-level m odels; autom ate unit testing; and m anage the com plex ity of configuration m anagem ent. Another approach to reducing
com plex ity is to prom ote im plicity. You can do this by refactoring, k eeping code and m odels clean, and im plem enting k ey aspects of the architecture first in
what we call architecture-driven developm ent.
Practice 15Leverage patterns
Practice 16Architect with com ponents and services
Practice 17Actively prom ote reuse
Practice 18Model k ey perspectives

A dapt the process.
More process is not necessarily better. Rather, you need to adapt the process to the specific needs of your project, based on size, com plex ity, needs for
com pliance, and so on. In addition, you need to adapt the process to different lifecycle phases, so you m ay, for ex am ple, use less cerem ony at the start of
a project and m ore cerem ony toward the end. You m ust also continuously im prove the process, for ex am ple by assessing how well it work s at the end of
each iteration.
Practice 19Rightsize your process
Practice 20Continuously reevaluate what you do


Unified Process Lifecycle
Throughout this book you will see references to the Unified Process lifecycle. This is the lifecycle used in RUP and O penUP, and all other processes part of the
Unified Process fam ily. It is one of several lifecycles supported in the EPF. Even though the practices in this book typically apply to any iterative lifecycle, they work
particularly well with the Unified Process lifecycle.
The Unified Process lifecycle divides a project into four phases: Inception, Elaboration, Construction, and Transition.

The lifecycle describes the tim e dim ension of project, that is, how a project is divided into phases and iterations. It divides a project into four phases: Inception,
Elaboration, Construction, and Transition, each ending with a well-defined m ilestone. [18] Each phase has specific objectives:
[18]

See Kroll 2003 for an in-depth overview of what is done in each phase.

1. Inception. Establish the scope of the system , including a good understanding of what system to build, by reaching a high-level understanding of the
requirem ents. Mitigate m any of the business risk s and produce the business case for building the system and a vision docum ent to get buy-in from all
stak eholders on whether or not to proceed with the project. This is sim ilar to what m any agile processes refer to as Iteration 0.
2. Elaboration. Reduce m ajor risk s to enable cost and schedule estim ates to be updated and to get buy-in from k ey stak eholders. Mitigate m ajor technical
risk s by tak ing care of m any of the m ost technically difficult task s. Design, im plem ent, test, and baseline an ex ecutable architecture, including subsystem s,
their interfaces, k ey com ponents, and architectural m echanism s such as how to deal with interprocess com m unication or persistency. Address m ajor business
risk s by defining, designing, im plem enting, and testing k ey capabilities, which are validated with the custom er. Do not define and analyze all requirem ents
at this tim e, as doing so would lead to waterfall developm ent. Detail and analyze only the requirem ents required to address the above risk s.
3. Construction. Undertak e a m ajority of the im plem entation as you m ove from an ex ecutable architecture to the first operational version of your system .

Deploy several internal and alpha releases to ensure that the system is usable and addresses user needs. End the phase by deploying a fully functional
beta version of the system , including installation and supporting docum entation and training m aterial (although the system will lik ely still require fine-tuning
of functionality, perform ance, and overall quality).
4. Transition. Ensure that software addresses the needs of its users by testing the product in preparation for release and m ak ing m inor adjustm ents based on
user feedback . At this point in the lifecycle, user feedback focuses m ainly on fine-tuning, configuration, installation, and usability issues; all the m ajor
structural issues should have been work ed out m uch earlier in the project lifecycle.
Each phase contains one or more iterations, each producing a product increment.

Each phase contains one or m ore iterations (see Figure 1.3), which focus on producing a product increm ent, that is, the work ing code and other deliverables
necessary to achieve the business objectives of that phase. There are as m any iterations as it tak es to adequately address the objectives of that phase, but no
more. If objectives cannot be adequately addressed within the planned phase, another iteration should be added to the phase, but this will delay the project. To
avoid such a delay, m ak e sure that each iteration is sharply focused on just what is needed to achieve the business objectives of that phase, but no less. For
ex am ple, focusing too heavily on requirem ents in Inception is counterproductive; so is not involving stak eholders.

Figure 1.3. The Unified Process Lifecycle.
Each of the four phases in the Unified Process lifecycle consists of one or several iterations. Each iteration builds on the result of previous iterations, delivering a
product increment one step closer to the final release. Product increments should include working software, with a possible exception being the product increments
produced in the Inception phase for new applications.

The Unified Process lifecycle provides a great deal of flex ibility. Product increm ents m ay be internal only and m ay be dem onstrated or deployed only to select
project stak eholders. O ther product increm ents m ay also be released for use by custom ers. For ex am ple, som e projects benefit from the deploym ent of several
product increm ents to the production environm ent, which allows end users to adopt the m ost critical capabilities m ore rapidly. You can do this by rapidly m oving into
the Transition phase and having several Transition iterations, each deploying a release into the production environm ent (see Figure 1.4).

Figure 1.4. Incremental Delivery Using the Unified Process Lifecycle.
Projects that deliver product increments into the production environment often rapidly move into the Transition phase. Once in Transition, they deliver a new
product increment to production at the end of each iteration. The milestone at the end of the Construction phase aims at ensuring that all pieces are together so that
the system can be deployed. You should pass this management milestone before undertaking deployments into the production environment.

OpenUP/Basic
O penUP is an open-source process fram ework that over tim e is ex pected to cover a broad set of developm ent needs. [19] O penUP/Basic is a subset of O penUP,
and provides a sim plified set of artifacts relative to RUP and a m uch sm aller set of roles, task s, and guidelines. Let's look briefly at the k ey artifacts, the essentials
of the process, and how these relate to the practices in this book .
[19]

At the time of this book's printing, OpenUP is almost equivalent to OpenUP/Basic, and we have chosen to primarily refer to OpenUP/Basic for the remainder of this book. OpenUP is expected to
grow over time, while OpenUP/Basic will continue to be a small process.
OpenUP/Basic is an agile and iterative process focusing on the needs of small collocated teams.

The project team m aintains a work item list [20] of all work that needs to be done, including requirem ents and change requests to be addressed and random
task s, such as delivering training. At the beginning of each iteration, the team prioritizes which work item s should be addressed within that iteration, and that
subset of the work item list is called the Iteration Plan (see Figure 1.5). The team prioritizes work item s to drive down risk s and to deliver high-priority end-user
capabilities in each iteration.
[20]

Work item list corresponds to product backlog in Scrum; see Schwaber 2002.

Figure 1.5. Managing an OpenUP/Basic Project.
The project manager is responsible for producing a high-level project plan, maintaining a work item list of all things to be done, prioritizing work items into an
iteration plan, and assessing the result of the iterations. The entire team is typically involved in producing each of these artifacts.

See Practice 19.

See Practices 1 and 10.

An iteration is typically a few week s long, and each iteration will deliver an ex ecutable that is one step closer to the final product, with the potential ex ception of the
first iteration. During an iteration, the team will work on defining, designing, im plem enting, and testing the requirem ents listed in the iteration plan, as well as any
other planned work item s. At the end of each iteration, the team will assess what was accom plished and dem onstrate the ex ecutable to stak eholders. The resulting

feedback will enable the team to im prove upon the solution and understand what are the m ost im portant work item s for the nex t iteration. Lessons learned during
the retrospective im prove the process for the nex t iteration.
See Practices 2, 3, 4, and 20.

A vision outlines stak eholder needs and high-level features, establishing a com m on understanding of the dom ain. Functional requirem ents are docum ented as use
cases and scenarios, and other requirem ents are docum ented as supplem entary requirem ents. The requirem ents are increm entally im plem ented by growing the
design and im plem entation in stages, while continuously testing and integrating the code into builds. A strong em phasis is placed on test-and-build autom ation to
enable frequent and high-quality builds.
See Practices 56, 810, 14, and 18.

O penUP/Basic is steeped in the belief that the team needs to tak e responsibility for the end product, to which everybody chips in as needed. To im prove
productivity and quality, the team should reuse ex isting assets, such as patterns and com m on com ponents, as appropriate. O penUP/Basic also puts a strong
em phasis on the architecture; a stable architecture is established early in the project and evolves continuously along with the application. Com ponents and services
are leveraged as appropriate, and the architecture also im pacts how responsibilities are divided within the team .
See Practices 7, 1113, and 1517.

O penUP/Basic is a subset of O penUP, and is delivered through the EPF (see Appendix A). It is also the basis for RUP.


Rational Unified Process (RUP)<title/>
RUP extends EPF with additional process content.

RUP is a widely adopted process fram ework used by tens of thousands of projects ranging from team s of two to team s with hundreds of m em bers, in a broad
variety of industries worldwide. It ex tends EPF with a large volum e of additional process content, allowing developm ent team s to scale their process to do the
following:
Carry out distributed or large-scale developm ent requiring m ore cerem ony, such as requirem ents traceability, analysis m odels, m odel-driven architecture
(MDA), or com prehensive testing of load and perform ance.
Develop system s using IBM tools, providing specific guidance on relevant technologies such as J2EE and .NET, and using IBM and partner tools.
Develop system s adhering to industry standards such as ISO 9001, SEI CMMI, or SO X.
Scale from project-oriented processes to enterprise processes, such as program and portfolio m anagem ent; system s engineering; enterprise reuse;

business m odeling and sim ulation; or enterprise-scale SO A.
RUP follows the Unified Process lifecycle and adheres to the k ey principles described above. RUP em phasizes the im portance of adapting the process to the needs
of your project. Rather than providing one process, such as O penUP/Basic, RUP provides a collection of processes that can either be used out-of-the-box or further
custom ized. These processes are variations built on O penUP/Basic and include processes for Large-Scale Custom Application Developm ent, Com m ercial-O ff-TheShelf (CO TS) Pack aged Delivery (see Figure 1.6), Service-O riented Architecture Developm ent, System s Engineering, Sm all Projects, Maintenance Projects, Portfolio
Managem ent, and so on. More processes are continually being added. RUP allows you to custom ize these processes or build your own process through the product
IBM Rational Method Com poser, which is the delivery vehicle for RUP. The product is described in m ore detail in Appendix B.

Figure 1.6. RUP for Commercial-Off-The-Shelf (COTS) Packaged Application Delivery.
RUP provides many out-of-the-box processes for different types of projects, including COTS packaged application delivery. For COTS development, RUP provides
specific guidance on how to evaluate commercial components or packages, how to deal with a Request for Information (RFI) and a Request for Proposals (RFP), and
how to make trade-offs to balance the many conflicts between stakeholder needs, architecture, program risk, and market concerns.

[View full size image]

RUP provides a collection of processes that can either be used "out of the box" or further customized.

O ne of the k ey ideas behind RUP is that a process is m uch m ore valuable when autom ated by tools. Therefore, a fundam ental aspect of RUP is the tight
integration with developer tools through contex t-sensitive process guidance available within the tools and tool-specific guidance available in the process, which
m ak es RUP an integral part of the developm ent environm ent. RUP is also tightly integrated with tools that allow team s to instantiate their process, enabling
adaptive planning of projects and collaborative software developm ent (see Appendix B for m ore inform ation). Even though RUP is integrated with IBM and other
tools, it does not require the use of any one set of tools.
RUP is described in a variety of white papers and book s. [21] The m ost com prehensive inform ation can be found in the Rational Method Com poser (RMC) product,
which contains detailed guidelines, ex am ples, and tem plates covering the full project lifecycle. However, RUP underwent ex tensive m odernization in 2005, and
m aterial or product versions predating 2006 m ay use different term inology.
[21]

See Kruchten 2003 and Kroll 2003.


eXtreme Programming (XP)

eXtreme Programming (XP) is one of the best-k nown agile processes. Created by Kent Beck , [22] it is considered by m any to be "glorified hack ing," but that is far
from the case. XP is a disciplined approach, requiring sk illed people who are com m itted to adhering closely to a core set of principles.
[22]

Beck 2004.

XP is a disciplined approach, requiring skilled people adhering to a core set of principles.

XP articulates five values to guide you in your project: communication, simplicity, feedback, courage, and respect. Further, it prescribes a set of practices to m ak e these
values concrete. Although it m ay be unclear whether som ebody really adheres to a value, you can easily tell whether som ebody adheres to the practice. XP
practices are divided into primary and secondary. The prim ary practices are listed below.
Sit together helps you to com m unicate m ore effectively by being physically collocated in the sam e room or office space.
Whole team talk s about the im portance of building a cohesive team with a diverse set of sk ills required to com plete the project.
Informative workspace tells you that if an outsider spends 15 seconds in your work space, he or she should be able to get a general idea of how the project is
going. W hat are the issues you are facing and item s you are work ing on?
Energized work guides you in adjusting your work hours so that you function effectively when work ing and avoid burnout.
Pair programming tells you to write all production code in pairs, with each person tak ing turns watching and assisting the other program m er write code.
Stories allow you to specify, in one or two sentences, capabilities that typically tak e one or two days to im plem ent. The custom er prioritizes which stories to
im plem ent and in what order.
Weekly cycle m eans that at the beginning of each week you plan what should be accom plished for that week by assessing status, prioritizing user stories,
and dividing user stories into task s that program m ers sign up for.
Quarterly cycle allows you to step back and determ ine how to im prove process, rem ove bottleneck s, focus on the big picture of where to tak e the projects,
and do coarse-grained planning for the nex t quarter.
Slack is built in to the schedule as task s that can be dropped or by assigning certain tim e slots as slack tim e.
Ten-minute build forces you to trim your autom ated build and autom ated tests so that they tak e no m ore than 10 m inutes.
Continuous integration aim s at reducing the overall cost of integration by forcing it to happen at least once every couple of hours.
Test-first programming tells you to write autom ated tests before writing the code to be tested.
Incremental design guides you in doing a little bit of design every day, but designing only for what you need today rather than for future possibilities.
XP also articulates a set of fourteen principles that function as the bridge between values and practices, guiding you in how to apply the practices effectively in order
to adhere to the values. The principles are hum anity, econom ics, m utual benefit, self-sim ilarity, im provem ent, diversity, reflection, flow, opportunity, redundancy,

failure, quality, baby steps, and accepted responsibility.


Scrum
Scrum [23] was introduced in 1996 by Ken Schwaber and Jeff Sutherland. [24] The term scrum is derived from rugby, in which it refers to restarting play after the
gam e is stuck in a so-called m aul. Scrum focuses on the m anagem ent of a project without describing the specifics of how to undertak e design, im plem entation, or
testing. Consequently, it can be com bined with a num ber of different processes, such as XP or RUP.
[23]

Schwaber 2002.

[24]

Scrum was formalized and presented at OOPSLA'96.

Scrum focuses on the management of a project.

Each iteration is 30 days long and is referred to as a sprint. The sprint starts with a half-day planning m eeting to determ ine what should be done within the sprint.
During the planning m eeting, the Product O wner provides a prioritized Product Backlog, which is an evolving list containing all requirem ents, defects, task s, and
change requests. The developm ent team will then determ ine how m any of the high-priority item s they can tak e on within that sprint, which constitutes the Sprint
Backlog, and a sprint goal is crafted. The sprint goal provides the team with a clear focus by establishing an objective that will be m et by im plem enting the
back log.
After the planning m eeting, the team spends 29 days developing an ex ecutable that delivers increm ental functionality. The sprint ends with a half-day Sprint
Review Meeting, at which the team and m anagem ent inspect the product increm ent together and capture lessons learned. The team will then start the nex t sprint,
delivering an ex ecutable every 30 days that is one step closer to the final product.
During a sprint the team will get together for a daily 15-m inute m eeting, also called scrum . During the scrum , each team m em ber will briefly answer three (and only
three) questions:
1. W hat have you done since last m eeting?
2. W hat will you do between now and nex t m eeting?
3. W hat obstacles stood in the way of doing work ?

The "scrum m aster" m ak es sure that the m eeting is k ept on track , m ak es decisions as appropriate, and is also responsible for ensuring that identified obstacles
are addressed as soon as possible. As issues arise that need further discussion, the scrum m aster sets up additional m eetings with involved parties to continue the
discussion, to ensure that the daily scrum is k ept to 15 m inutes. The scrum m aster also m ak es sure that no outside changes are im posed on the plan during a
sprint, so that the team can focus on ex ecuting the plan without any distracting interruptions.
The team in scrum should have seven (give or tak e two) m em bers. If your team has m ore, split the team into several team s and divide their work so that they can
operate sem i-independently. Scrum team s should be cross-functional so that each team can do the necessary analysis, design, im plem entation, testing, and
docum entation.
Scrum team s are self-organized, m eaning that the team is left loose during the sprint to use whatever approach is considered appropriate to convert the Sprint
Back log to a product increm ent. Managem ent should not intervene. At the end of the sprint, m anagem ent can assess what was done and m ak e changes as
necessary.
Scrum focuses on collaboration. O pen work spaces are preferred, and each team m em ber should attend the daily scrum m eeting in person. No titles or job
descriptions are used, and people are ask ed to leave their egos at hom e.
Scrum focuses on collaboration. Each team member attends the daily scrum meeting.


Summary
This chapter introduces k ey principles and practices that support them . It also presents the fram ework for this book , as outlined below:
Comparison with other methods. For each practice, we describe how the practice is sim ilar to, or different from , other m ethods.
Levels of adoption. Each practice can be adopted at three levels: basic, interm ediate, and advanced. The advanced level typically requires a com bination of
m ore advanced sk ills, m ore advanced tooling, or a higher-cerem ony process.
Process map. For each level of adoption of a practice, we indicate whether the practice enables agility or discipline and whether it enables shorter iterations.
Information in the Unified Process. For each practice, we describe how O penUP/Basic and RUP support these practices.
To enable you to m ak e better use of this fram ework , this chapter provides a sum m ary of the Unified Process lifecycle, O penUP/Basic, and RUP and ex plains how
they fit together in the fam ily of Unified Process m ethods built on EPF and RMC. This chapter also sum m arizes Scrum and XP, because we have chosen to focus on
these m ethods as part of the "com parison with other m ethods" section in each practice.
W ith this back ground, we hope you can now pick and choose a practice chapter of interest and gain valuable insight into how to im prove your process. W e
recom m end that you start with the basic level of adoption and increm entally adopt som e interm ediate and advanced practices based on whether you need to be
m ore iterative, agile, or disciplined.