Adopting the Rational Unified Process: Success with the RUP [Paperback]

Some things in life just seem to happen. Of course, writing a book needs to be planned in detail by the authors, but the starting point of the endeavor to write down our collective experience of helping customers implement the IBM Rational Unified Process (RUP) did not follow any schedule. Suddenly, after years of mentoring, preparing presentations, and writing papers and articles, it just felt like it was time to collect all that information in one placeNto make a baseline.

There are many books about RUP, and some of them bring up implementation matters. Also, there are many books about process improvements in general as well as change in general. However, this is the first book that focuses solely on RUP implementation, that is, how to put RUP into practice.

RUP gives the software development community a common language and a base for a common, more controlled way to develop software. By writing this book we want to help the reader have a better experience working with RUP by suggesting methods of how to adopt it in the best way.

RUP will not yield its intended benefits if not successfully implemented. Succeeding with a RUP implementation can be hard. Although RUP has been around for a while now, some people still struggle with the best way to put RUP into practice. This is a pity because RUP contains so many excellent things! A good working environment for software developers is more than a good chair, a fast computer, and an ergonomic keyboard. A good working environment also encompasses a decent process and appropriate tools. There is no reason that software developers always should work more or less ad hoc. RUP has the answer. Unfortunately, it can be difficult for software developers in general to realize the value of RUP if it is not adopted properly. The power of RUP lies in its implementation!

As for all initiatives for making business processes in which people work more effective, implementing RUP in an organization is all about people. Still, it is easy to underestimate the effort required to change the ways people think about their work. Even if an organization decides that RUP shall be used for all software development, it is hard to enforce that decision. By sharing our best practices with you in this book, we hope that organizations that implement RUP in the future will give the "people issues" the attention they deserve, and then plan the implementation accordingly. It is our firm belief that organizations will benefit even more from RUP as a result.

We have a strong belief in mentorshipNin being fair and helping people to change. They need someone to show them how to do things the new way. People need someone to talk to. Before trying to adopt RUP on your own, use a RUP mentor to give you some hints and advice. This way, some common traps can be avoided, and you can use RUP efficiently from the start. A RUP implementation should not be based solely on a trial-and-error approach.

Who is responsible for the processes in an organization? Management? The project managers? The people working in the processes? We say that everyone is responsible. Of course, the formal responsibility will vary, but everyone just mentioned has a role in the processes and should feel responsible for their results. This book is intended for the following audiences:

Managers who will be in charge of implementing RUP in an organization and/or one or more software development projects.

• Project managers who will both become RUP practitioners and are expected to support and sometimes drive the RUP implementation for the project members. People in this tough position will get support from this book.
• Project members who are RUP practitioners, that is, those who will start work according to RUP (following the guidance of any RUP discipline). This book will give new RUP practitioners a positive attitude toward RUP, which will ease their adoption of it.
• Process and method engineers who will be involved when customizing RUP, selecting subsets of it, and integrating it with other processes and methods.
• RUP mentors, that is, people who will help practitioners get started with RUP by transferring knowledge during actual work.
• Quality assurance professionals who are deeply concerned with processes and their definitions as well as with making sure that work adheres to set standards and is improved if needed.

This is not an introductory book to RUP. It does not even talk much about the content in RUP, with the exception of the real-life examples. We want to focus on the process of implementing RUP. If you need information about what is in RUP, we recommend the Rational Unified Process product itself: The Rational Unified Process, An Introduction, Third Edition, by Philippe Kruchten 2003, or The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP by Per Kroll and Philippe Kruchten 2003.

Nor is this a book about organizational change in general. Such a book would probably include psychological theories and plenty of studies about human behavior during certain circumstances. We are self-taught and have no such academic background. We base our advice regarding how to proceed with the change of implementing a new process on our experiences only.

This book could have been an introductory book to the Process Engineering Process (PEP) included in the RUP product, but it is not. Still, this book and PEP cover the same topic: how to adopt RUP in an organization for its software development projects. So what's the difference between the two? A process, like RUP or PEP, extensively sorts out all the roles, activities, and artifacts that should be involved when engineering software (RUP) or engineering a process (PEP). A book, like this one, may present and talk you through a sometimes overwhelming topic in pedagogical order to help create a deeper understanding, following the main thread.

There are no contradictions in terms of "things that need to be done" when adopting RUP as described in this book and when using PEP. But note that PEP includes a lot of support for developing your own tailored process, apart from "just" implementing things from standard RUP, as this book emphasizes. Still, Chapter 9, "Deciding upon Your Process," discusses the issues of selecting from RUP and adding process information to RUP, and Chapter 10, "Documenting Your Process," presents the options available (including tools) when documenting these decisions. This book is not at all as detailed as PEP. Therefore, read more about PEPNif not before, then at least after you have read this book. And do remember the "soft" aspects of implementing a process.

This book has eleven chapters plus two appendixes, a glossary and a recommended reading section. The obvious choice for approaching this book is to read it chapter by chapter in order. This will tell you how to adopt RUP in an organization. However, the book does not have to be read chapter by chapter. For example, you can start with Chapter 8, which will tell you how to adopt RUP in a single software development project. Cross-references will help you find other information related to what you read in particular chapters. We tried to write this book with a minimum of technical language, and we take a practical approach to the subject, basing all reasoning on our own experiences. Brief overviews of the chapters follow.

Chapter 1, How to Adopt RUP in Your Organization, throws you directly into the core topic of the book. This chapter presents a flow of activities that will make the adoption of RUP easier. This flow will also serve as a navigation tool for the rest of the book, where all activities will be revisited.

Chapter 2, The First Meeting with RUP, gives you a warm-up to the rest of the book through our simple explanation of what RUP is. If you are a practitioner, read this chapter in order to get a good understanding of RUP and an appropriate mind-set. If you are a RUP mentor, read this chapter to see how you can explain RUP to others.

Chapter 3, What Is a RUP Project?, delves into perhaps the most common question when it comes to usage of RUP. We give it an answer.

Chapter 4, Assessing Your Organization, explores how to find out how the organization develops software today as well as what is important to the organization when doing so.

Chapter 5, Motivating the RUP Adoption, discusses the need to motivate the adoption of RUP from an economical aspect as well as the need to motivate the receivers of the new process, that is, the employees in your organization.

Chapter 6, Planning the RUP Adoption, describes the concepts of setting goals, identifying risks and opportunities, and understanding the importance of communicationNand, of course, how to plan for the RUP adoption.

Chapter 7, Obtaining Support from the Organization, gives advice on how an implementation team on the organizational level can support the adoption of RUP in the development projects.

Chapter 8, How to Adopt RUP in Your Project, takes the project view of the adoption. This chapter is also a good starting point for small-scale adoption, where all the process-related work will take place in one or a few development projects.

Chapter 9, Deciding upon Your Process, discusses the topic of RUP tailoring and customization.

Chapter 10, Documenting Your Process, explains how you can physically document (through print publications, Web sites, and so on) the process you have built. The stages that a process documentation undergoes during an implementation are presented.

Chapter 11, A Guide to Successful Mentoring, stems from our firm belief that a process implementation will be faster and more successful when supported by experienced mentors. This chapter describes how such mentorship should be performed.

Appendix A, Experiences from Actual Implementations, provides real-life examples of RUP implementations. Generously, two companies have shared their experiences. In this appendix we summarize their views.

Appendix B, Adding Another Project Management Method to RUP, expands on some details from Chapter 9. Two companies have generously let us show how theyNpartlyNalign their project management method with RUP's project management discipline.

Glossary contains a few terms from the RUP terminology and other items that need to be defined for clear understanding.