Level: Introductory Colin O’Neill, Principal, OCSolutions
15 Sep 2007 
from The Rational Edge: Organizations can extend the power of RUP by adding a macro dimension to the original notion of iterations. Using evolutions -- multiple, overlapping passes through the RUP lifecycle -- can reduce risk, greatly speed time to market, and improve resource allocation, claims O'Neill, who also proposes illustrations for depicting this macro-iterative dimension.
From The Rational Edge.
The development approach embodied in the IBM® Rational Unified Process® or RUP®, is iterative along both micro and macro dimensions. This article focuses on the macro-iterative dimension, introducing the concept of evolutions, which represent multiple, overlapping passes through the RUP lifecycle. This approach to RUP supports the agile principle of delivering systems to production early and often. Just as each iteration mitigates project risk, each evolutionary release into production reduces organizational risk.
Expanding the concept of iterative development
Iterative development is based on the spiral model developed in the late 1980s by Barry Boehm
1
. Over the years, the RUP Lifecycle Diagram shown in Figure 1 has been the classic way to represent the RUP interpretation of Boehm's model. It shows four phases -- Inception, Elaboration, Construction, and Transition -- each comprised of one or more iterations. Each iteration -- and consequently each phase -- involves building and testing something, whether it's a business process simulation, an architectural prototype, operational code, or a production release. An iteration encompasses all of the disciplines and activities required to achieve a phase milestone
2
, defining a time-limited framework within which to achieve incremental progress toward that milestone.
Figure 1: The widely recognized RUP Lifecycle Diagram
The RUP Lifecycle Diagram depicts RUP along a micro-iterative dimension that adequately represents the effort required for small projects. Although it does not explicitly state as much, the RUP Lifecycle Diagram represents the context for a single project and a complete software development lifecycle
3
. Organizations typically structure and fund projects based on the premise that they will produce a stable, deployed system. If a project needs only one pass through the software development lifecycle to create and deliver such a product to end users, then it is sufficient to break down the effort as a series of iterations contained within phases
4
.
However, many medium and large projects benefit significantly from making multiple passes through the RUP lifecycle; this is true for both shrink-wrapped and custom-developed software. These projects require a macro-iterative dimension that depicts the iterative process as a series of cycles
5
, which I refer to as evolutions
6
.
An evolution represents one pass through all four phases of the lifecycle. It results in a usable product, but the understanding is that the product is not “finished” in a conventional sense. Ongoing evolutions will continue to improve upon the features, architecture, and code of preceding evolutions. Bittner and Spence
7
use this concept extensively to describe parallel development efforts within the context of a single project, urging managers to view the release planning cycle from a macro-iterative perspective and deliver features to end users via a series of multiple evolutions. I will examine this notion below.
The power of evolutions
As marketplace competition grows keener, IT projects are under constant pressure to deliver capability faster to end users. Waterfall development processes are designed to deliver all desired capability at the same time -- an ineffective approach for developing medium-to-large complex systems
8
. It is more effective and less risky to deliver smaller amounts of functionality more often -- in other words, to release a product into production multiple times. This is the basic premise behind the evolutionary approach to RUP. It is also a tenet of an agile, iterative methodology, representing a significant improvement over waterfall in terms of risk, cost, quality, and efficiency.
Benefits of evolutions
Approaching RUP as a series of evolutions offers many important benefits
9
:
-
People stay focused on a short-term goal. The delivery date acts as a motivator to ensure that everyone on a project is aiming at the same target.
-
Team members get gratification and valuable learning experiences early on. Team members get an actual working product right away -- along with a chance to evaluate its strengths and weaknesses.
-
End users can set priorities. The organization and its end user community can make decisions about what capabilities they need right away and which can wait until later releases
10
. They have the comfort of knowing that all the features they want will ultimately be implemented — and setting delivery priorities themselves.
-
The organization benefits overall. More parts of an organization receive beneficial releases into production because they occur more often.
-
Managers can make better use of both fixed and matrixed resources. In a typical Elaboration phase, system analysts, designers, and architects are feverishly occupied, testers are somewhat engaged as they create test cases from use cases, and developers are not very busy. If you plan for multiple evolutions, you can distribute activities across the entire project in a manner that ensures that no one group is either overwhelmed or underutilized at any point in time.
-
Stakeholders remain fully engaged throughout the development and delivery lifecycle. Project managers can leverage and sustain participation from both IT and business contributors in defining and creating the desired solution. Those with special expertise can easily move from one evolution to the next while the project challenges are still fresh in their minds. Typically, the heaviest involvement for business experts is during Inception and Transition; system analysts and architects are deeply involved during Elaboration, and developers are typically heads-down during Construction. If you have non-overlapping iterations with significant time gaps in between, you risk losing these resources to other projects and may need to introduce new participants who were not involved in earlier stages. An evolutionary approach helps maintain project continuity and momentum -- critical requirements for producing high-quality products within short timeframes.
-
The architecture can evolve incrementally. Teams can continuously refine and enhance the architecture instead of attempting to define all architecturally significant components at once.
-
Administrators can better understand and maintain the product. The project manager can treat application administrators as stakeholders, giving them time and opportunity to learn about the product, integrate it into the production environment, and manage it effectively. Following deployment, they can also provide feedback, based on real-world experience and anecdotal evidence, to guide subsequent evolutions.
Collectively, these advantages enable an IT organization to demonstrate to business managers that it can quickly and effectively deliver high-quality products that meet end users' needs. This approach promotes agile practices by preferring working code over excessive documentation and delivering that code into production quickly and often.
Overlapping evolutions: Expanding the macro dimension
Strictly speaking, the order in which you undertake phases in RUP is immutable. Within each phase, you must achieve a major milestone via the execution of one or more micro iterations before the next phase can begin. When you finish all phases, you complete the evolution -- a macro iteration.
However, if you stagger and overlap multiple evolutions, then you can effectively manipulate the phases. For example, you can work on the Construction phase of one evolution while beginning the Inception phase of another. If you release your product into the production environment while beginning another evolution, then you can feed back what you learn from the Transition phase for one evolution into the Inception and Elaboration phases of the new evolution.
Evolutions may overlap by as many as three phases, but not by four; you cannot begin a phase in an evolution before completing that same phase in the previous evolution
11
. Also, overlapping evolutions does involve risk; if there are significant changes to the architecture or the requirements in later evolutions, then these may affect earlier evolutions. An effective change management process can help with this challenge.
The primary advantage of all these micro and macro iterations is that they take place within the context of a single funded project, providing a simple and elegant process for defining, constructing, and delivering information systems. Now, what RUP needs is a simple, elegant way to visually express both the macro and micro dimensions of iterations in a manner that first-time viewers will immediately grasp.
Applying evolutions in a real-world project
Recently, while leading a team through the evolutionary approach on a major RUP project, I developed three possible ways to depict the two iterative dimensions of RUP. In doing so, I applied principles put forth by Edward Tufte
12
, a pioneer in the field of multivariate graphical design. Each method of depiction has different strengths and weaknesses. Before looking at each one, let's begin with a brief description of that RUP project, which I will refer to as Project X.
Project X overview
To stay competitive in the marketplace, a national health insurance provider wanted to create a Web-based, online bill payment system for its two customer markets: 1) individuals and family members, and 2) business customers who provide health insurance to their employees (i.e., employers). Management determined that developing features for individuals and family members would be easier than implementing similar capability for employers. Therefore, they planned their first evolution for the individual and family member market and two subsequent evolutions to address the more complex needs of the employer market.
The medium-sized project consisted of 34 use cases, and some use-case logic from the first evolution would be reused in the later evolutions. However, features for the later evolutions would require mostly new code.
Although plenty of IT staff members were available (augmented by contractors) to support parallel development iterations, business experts and analysts were in limited supply. Many had other commitments and were available for only a short period of time. To optimize use of these professionals, management decided to overlap the evolutions more than for a typical project, which might overlap the Transition and Inception phases of sequential evolutions.
When a particular phase ended in one evolution, that same phase started up in the next evolution. During week 16, three different phases (Elaboration, Construction, and Transition) were underway simultaneously across three evolutions.
The spiral view of Project X
Figure 2 shows one way to depict the macro-iterative approach we used. It shows three evolutions for this project, using cylinders to represent iterations. Note that each cylinder is contained within a spiral that represents an evolution.
Figure 2: Spiral view of Project X**
**Figures 2, 3, and 4 illustrated by Erin King, 2007
The volume of each cylinder reflects the iteration's overall relative level of effort (LOE) in terms of person-hours. Each slice of a cylinder represents a different discipline; according to RUP best practices, all disciplines are involved in each iteration. The thickness of each slice reflects the LOE for different roles within that discipline. This is similar to the way in which the humps in Figure 1 convey variations in LOE required for each discipline across iterations and phases. Notice how discipline slices vary in thickness across different types of iterations
13
.
In the first evolution (I1), the Inception iteration was comprehensive (four weeks long). It established the scope and secured stakeholder buy-in for the entire project. Inception iterations in subsequent evolutions (I2 and I3) were very short. They simply defined the scope and schedule for their respective evolutions. Notice that the third evolution had two consecutive Construction iterations (C3 and C4). This was because of the large amount of coding needed to implement the requirements defined in iteration E3.
Swimlane view of Project X
Figure 3 shows another way to depict the macro-iterative dimension for Project X. It uses swimlanes instead of spirals to represent evolutions and rectangular solids instead of cylinders to depict iterations. The volume of each rectangular solid reflects the iteration's relative LOE. Also note that the positions of iterations on the timeline correspond to those in Figure 2.
Figure 3: Swimlane view of Project X
Although Figure 2 indicates that iterations can be conducted in parallel, it does not show how iterations within and across evolutions are dependent upon one another. Using arrows, Figure 3 shows how the results of one iteration can feed into others, thereby collectively contributing to a complete, automated solution.
In Project X, iteration E1 was six weeks long and produced eight significant use cases. When the team achieved the Elaboration phase milestone (i.e., the architecture and requirements for that part of the system were stable), then architects, programmers, and testers involved in iteration E1 became the lead members for iteration C1. Team members built initial operational capability for features specified in E1 during this iteration, producing a stable, online payment product for individuals and family members. Iteration T1 then allowed subject matter experts to conduct user acceptance testing and sign off on the system before it was released into production.
The project plan developed during iteration I1 indicated that there would be three production releases -- and therefore three evolutions. However, when they planned the second evolution in iteration I2, business stakeholders realized that there would be no business value in deploying the results of Evolution 2 without the features scheduled to be built in Evolution 3. Therefore, they decided to fund and execute Evolution 2 through Transition (including user acceptance testing), but not to make it into a formal production release. That is why, in Figure 3, iteration T2 is translucent and has a dashed border. In this instance, the evolutionary model itself provided great value, allowing the team to avoid unnecessary work and duplication of effort.
Projection view of Project X
Although not as graphically appealing as Figures 2 or 3, Figure 4 conveys similar information, along with an additional parameter: The total number of resources needed at any point in time across multiple evolutions. Dots on the facade of each rectangular solid represent the relative number of resources needed for each discipline within that iteration. When these dots are projected onto the total resources columns (top of figure), the results are additive. This graphic illustrates a very real and little understood risk: To develop systems iteratively at the macro-level, you must anticipate the number and types of resources needed to adequately staff a project during the most intense and hard-to-manage periods when evolutions overlap. Notice how the number of resources in the Implementation and Test disciplines is highest around week 16 when three labor-intensive iterations are conducted simultaneously.
Here's where Project X got interesting. Iteration E3 (which defined the second half of the requirements for employers' online payment capability) was in full swing at the same time as iteration T1 (user acceptance testing for the individuals and family members part of the system) and Construction iteration C2 (to implement the first half of employers' requirements). This presented significant staffing challenges: How could system analysts write use cases while supporting developers and testers involved in previous evolutions? How could testers remain involved in the requirements elicitation activity while immersed in system, integration, and user acceptance test, all at the same time? Although organizing, staffing, communicating, and cooperating across parallel evolutions was confusing at times, the benefits -- speeding time-to-market and maximizing available business resources -- greatly outweighed the effort required.
Figure 4: Projection view of Project X
Project X results: Faster time to market, maximum resource utilization, better software
At the end of the first evolution, less than five months from the start of the project, the online bill payment application for individuals and family members was deployed into production. The actual delivery date was earlier than planned because of efficiencies gained through evolution overlap.
Regardless of how you choose to depict the evolutionary approach, its ability to shorten time-to-market can be vital to project success. In this case, it built confidence within the business community that the IT organization could deliver high-quality solutions quickly. It proved to be an invaluable way to introduce iterative development and RUP into this organization, providing:
- Early delivery of a working system to half the target customer markets
- Ability to improve subsequent versions of the architecture and code
- Maximization of available resources throughout the project
Evolutions offered the team the best of both worlds: Iterations that built and produced something within each phase, and multiple production releases. Had Project X followed only the micro-iterative approach depicted in the RUP Lifecycle Diagram, the team would have serially executed perhaps ten iterations within one lifecycle and taken more time overall. There would have been only one release into production at the very end of the project, and that would have precluded the most significant benefits we achieved through evolutions.
Moving Forward
Although not yet formally recognized in RUP, evolutions provide a valuable mechanism for planning and developing incrementally delivered systems. In my view, development teams should place as much emphasis on the macro-iterative dimension as on the micro-iterative one. Combining larger evolutionary cycles with smaller iterative cycles leads to an extremely powerful and flexible approach for iteratively developing information systems while reducing organizational risk.
This approach is particularly useful for certain types of projects:
- Those constrained by demands for rapid time-to-market or initial product rollouts
- Large projects that inherently require parceling into several evolutions
- Projects whose funding is allocated across fiscal periods or other intervals
Students of RUP have responded favorably to the graphics presented in this article, saying that the three-dimensional renderings helped them conceptualize how parallel activities occur over time and how products are delivered incrementally into production. They also felt that the projection view highlighted how important effective resource management is to a successful evolutionary project; teams must constantly re-examine priorities as resources are engaged during different iterations across multiple evolutions.
My hope is that these illustrations will help RUP champions, project managers, mentors, and practitioners effectively communicate the macro-iterative nature of RUP to IT and business professionals and gain support for the notion of delivering more than one release into production. As these proposals are discussed and vetted within the IT industry, even more useful graphical representations may emerge that will eventually be formally adopted in RUP.
Based on my experience with numerous RUP projects, I believe that dividing medium and large projects into multiple evolutions to maximize resource allocation and provide early releases into production reflects the process's ultimate value. Extending RUP to include the macro dimension will make it more agile and help to differentiate its unique, iterative nature from that of other approaches.
Acknowledgements
Thanks to Peter Haumer, Rolf Reitzig, Bill Nazzaro, Karen Capers, Ben Lieberman, Stephanie Stone, Matt Kear, Jody Frank, and Gene Teglovic for their contributions and insight into various aspects of this article.
Notes
1 Barry W. Boehm, "A Spiral Model of Software Development and Enhancement," IEEE Computer, vol. 21, #5, May 1988.
2 Barry W. Boehm, "Anchoring the Software Process," IEEE Software, vol.13, #4, July 1996.
3 Philippe Kruchten, "Software Maintenance Cycles with the RUP," The Rational Edge, August 2001.
4 Grady Booch, Object Solutions: Managing the Object-Oriented Project, Addison-Wesley, 1995.
5
Best Practices for Software Development Teams, Rational Software white paper, 1998.
6 Kurt Bittner and Ian Spence, Managing Iterative Software Development Projects, Addison-Wesley, 2007.
7 Ibid.
8 Per Kroll, "The RUP: An Industry-wide Platform for Best Practices," The Rational Edge, December 2001.
9 Ibid, Bittner and Spence, 2007.
10 Per Kroll and Walker Royce, "Key Principles for Business-Driven Development," IBM developerWorks, October 2005.
11 Ibid, Bittner and Spence, 2007.
12 Edward R. Tufte, The Visual Display of Quantitative Information, Cheshire, CT: Graphic Press, 1983.
13 Philippe Kruchten, The Rational Unified Process: An Introduction, Addison-Wesley, 2004.
About the author  | | | Colin O'Neill, principal of OCSolutions, has been an IT consultant for twenty years. Since 1995, he has led RUP systems development and integration efforts for a dozen Fortune 500 clients, working hands-on in every phase and discipline. He spent the last year customizing RUP and OpenUP for companies using Rational Method Composer (RMC) and Eclipse Process Framework Composer. You can reach Colin at ceoneill@ocsolutions.com. |
Rate this page
| 
