The trouble with the construction analogy
I always wondered why the RUP is so often compared to the process of constructing a building. I understand the motivation, to present people new to the RUP with an analogy to something they're more familiar with. After all, it's about producing something concrete using a similar role set and vocabulary. As with a software system, one must first have the foundation ready (the architecture in the software case) before building the walls and the roof. But in most other respects, the two processes do not correspond very well. For example, the software architect deals with problems such as the internal workings of a software system.
The house architect, on the other hand, is more concerned about visual and functional design, which pretty much equals the concerns of a system analyst in the software world. Delving further into the two processes easily reveals other divergences. My main objection to comparing the two is that the building process can be a totally predictable waterfall process (see Figure 1), while a software development process can't!
Figure 1. A traditional waterfall construction process
A civil engineer would probably disagree and argue that problems are just as common during building projects as in software projects. And they probably are. However, the fact is that civil engineering relies on a number of well-known physical laws of nature, and again, software engineering doesn't!
Thinking about this prompted me to wonder if we couldn't find a better analogy to introduce people to the RUP framework than comparing it with a construction process. It seems to me that although the RUP does share the basic goals and strategies of engineering processes, the actual process to achieve those goals has more in common with the creative approach required by artistic disciplines such as making movies, authoring books, or even writing an article like this one. So after I outline the essential principles of the RUP, I'll describe how each of these principles has its counterpart in the moviemaking process.
Contrary to what many people believe, the RUP framework isn't a miracle cure for bad software development practices. The RUP is based on common sense, harvested from the best practices of numerous successful software projects. What's interesting is that similar practices exist in areas other than software development.
The sole reason for using any kind of process for any type of development (software or nonsoftware) is to mitigate risk. In particular, the RUP is used to mitigate the risks associated with software development. By conforming to a well-defined and proven set of rules, we aim to increase the probability of a successful result. After all, if software development were a straightforward and predictable business, why would we bother with the extra effort?
Some of the risks associated with software development are the same as for any other type of development and include the following:
- lack of resources for carrying out the project
- insufficient funding
- not enough time and too much to do
- immature, slow, or nonagile organizations
These are examples of administrative risks that can be resolved by economic means, organizational change, or educational efforts.
But there are also risks that are associated with the unpredictable nature of software development, such as these:
- unknown technologies
- undiscovered requirements
- complicated architecture
The latter are examples of risks of a more technical nature that have to be dealt with in other ways. The RUP gives us these primary strategies for handling such risks:
- Develop iteratively.
- Manage requirements.
- Use a component architecture.
- Model visually.
- Continuously verify quality.
- Manage change.
These strategies are often referred to as the best practices of the Rational Unified Process. Generally interpreted, these rules aren't limited in their usefulness to the world of software development but rather are quite universal and can be used to tackle problems in various situations. In the next sections we'll take a closer look at each of the best practices by discussing how they may translate to the moviemaking business. Toward the end of the article I'll mention a few other types of projects that might benefit from the application of the RUP best practices.
Creating something innovative, whether a motion picture or software, requires many iterations to be performed on the same artifacts during the discovery process of building the final product.
With a waterfall development strategy (as seen in Figure 1), projects cycle through the various phases in a sequential manner, postponing confrontation with potential problems until the product has been built and tested. All the problems that have been hidden in the requirements, design, and coding suddenly surface at the very end of the project and become painfully real. Iterative development, on the other hand, allows projects to proceed by small steps, or increments, to gradually build a more complete system.
As shown in Figure 2, each iteration in the RUP is a pass through the disciplines. (A discipline in the RUP can be described as a grouping of interrelated activities and the artifacts or deliverables they produce.) Each pass, which is like a mini waterfall, explores a new portion of the requirements set and offers a chance to correct defects and rework the result of the previous iteration. With each iteration, the solution is coming closer and closer to the final product.
Figure 2. The RUP's iterative development process
You would think that making a movie is a pretty straightforward process of first writing a script, then figuring out how to put the words into motion, doing the filming and editing, and finally watching the result. This would be a traditional waterfall approach. But just as the waterfall approach fails when we're writing software, it would fail in making a movie as well. Luckily (for moviegoers), this isn't how a motion picture is made.
Instead, the process is much more iterative. The actors start working with the script, and revisions arise out of that interaction. For example, the script for the blockbuster Lord of the Rings, based on J.R.R. Tolkien's classic masterpiece, was rewritten almost every day after interaction with the actors. Director Peter Jackson described the creative process as a controlled chaos. Before the end of the project, the script had been rewritten many times. Each time (or iteration) resulted in an incremented (and better) version that more closely resembled the final version.
Another essential task whenever a new product of any kind is developed is ensuring that it meets the needs of its intended users. The ultimate objective is to reduce the risk of building a system that isn't useful -- that is, that doesn't meet users' needs. This can be a troublesome task since users sometimes have only a vague idea of the product under development, requirements aren't equally important or simple, and, of course, all these parameters (and others) change over time. Hence, an initial set of requirements isn't likely to be good enough, but an active requirements management strategy can iteratively improve the requirements into something that will satisfy users.
The RUP enforces requirements management throughout the lifecycle. This means that requirements are iteratively and incrementally identified, documented, evaluated, and refined. Functional requirements are described in terms of use cases. Nonfunctional requirements, which are often of great importance in a software system, are also identified and managed. These are properties of the system that aren't described as use cases but usually have a great impact on them, involving the system's usability, reliability, performance, and supportability.
As moviemakers work with the script and the actors, they must think in terms of meeting the needs of their audience. What kind of emotional response do they want the movie to evoke? What kind of experience do they want the audience to have? Where do they want the story to take viewers? The movie script is fine-tuned through many iterations to match the director's vision of meeting these functional requirements.
If the functional requirements of software have their counterpart in movies, can a movie also have nonfunctional requirements? The answer (not surprisingly) is yes. Maybe (for commercial reasons) the movie must be viewable by children under 18 and no longer than 120 minutes. Although these requirements aren't directly related to the story line, they'll have an impact on the final result -- just as nonfunctional software requirements must have on a computer system. In the same way, these requirements must be identified and addressed in the process of making the movie.
A component is a replaceable piece of software that fulfills a clear function. The RUP encourages the use of components to assemble a system. Component-based development has these advantages: it facilitates reuse both within the system and by other systems, it provides a convenient abstraction in the system design, and it enables efficient parallel development. Furthermore, a well-structured component-based architecture makes a system more scalable and easier to maintain.
The most obvious equivalent of a component in a movie is a scene. A film is typically made up of a number of scenes unified in a coherent structure that realizes the director's vision. Each scene is fully replaceable, meaning that it's possible to replace it, alter it, or even remove it without compromising the whole picture (if that's what the director wants).
Developing a computer application of considerable size without using a component-based architecture, something that's still done today, is like shooting a movie in only one take. This is how the 2002 drama Russian Ark by Aleksandr Sokurov was made -- the whole movie (2 hours, 16 minutes) is one continuous shot. Given that it's pretty hard to make even a ten-minute continuous scene, Sokurov's achievement is truly heroic. Going back to the software world, the RUP principle of component-based architecture relieves software developers of the need to be heroes on impossible quests.
Another not-so-obvious movie equivalent to software components is exemplified by Pixar's latest success. In making the computer-animated adventure Finding Nemo, the modelers were challenged with the task of creating natural-looking surging and swelling water. (More or less the whole story of Finding Nemo takes place in an underwater world.) The problem was not only to accurately simulate the movement of water, but also to capture how light refracts through it, the way particles dance around, the colors of different types of water, and so on. This had never been achieved to that extent before in computer animation.
As soon as the project was launched, the design department started experimenting with water modeling. They did extensive studies, consulted experts on oceanography, made sketches and drawings, and most important of all, made prototypes based on their increasing knowledge of the problem. The prototypes were then exposed to the director's critical eye, and the final result of the hard labor was a design template covering every conceivable water simulation in the movie. This template was a fundamental component of the film's architecture; other components (templates) resolved different problems, such as the motion patterns of fish and plants.
In the realm of software development, design templates tell designers how to deal with the most significant problems. Without a solid architecture, or design template, there really isn't much point in moving on in the project. Until these kinds of issues can be resolved, designers will never be able to meet the requirements.
A model is a simplified representation of a real-world entity or process, intended to help us imagine and flesh out the real-world version. At some point early in the development of software, there's a need to understand the interaction between the system and its users. The developers have two options: they can implement the software as they guess it should work, or they can create a model of it, which can then be exposed to potential users, designers, and testers, whose feedback can in turn alter the model.
This type of model, describing how a user interacts with the system, is usually referred to as a use case model. The point of creating use case models is to mitigate the risk of building the wrong system. There are other types of models in the RUP, each one used to mitigate a certain risk. The underlying assumption is that it's preferable to discover flaws and weaknesses in a model of the system rather than in the real thing. Working with models is the cheapest way of making mistakes.
Modeling is usually a somewhat theoretical exercise that can help us understand complex system behavior by simplification. Prototyping is a more hands-on type of modeling that can involve a mock-up, test-of-principle, or actual working version of a specific area of the design. Prototypes are used to generate information that can demonstrate certain aspects or characteristics of a system. The RUP encourages architecture teams to prove their architectural concepts by executing prototypes.
In the early stages of a movie project, all that exists is a script. But just as in the software case, the director needs to see the product before it's completed. As with the RUP, the solution is to build a model of the story. This is known in the film industry as visualization, and it can be achieved by various techniques: traditional actor acting, puppet acting, storyboarding, and even 3D computer graphics. If storyboarding (a concept that also exists in the RUP, by the way) is used, the model consists of a sequential series of sketches illustrating stages or scenes. From the storyboards, the director can decide if a scene seems too long or should be removed, or if something is missing. The storyboards can be filmed and edited, and temporary sound effects and music can be added, just to further enhance the model's usefulness.
In both software development and moviemaking, modeling is a dynamic, chaotic, and creative process. Many times it's a question of doing things over and over again until a satisfying result is achieved.
There is a time and a place for everything, in everyday life and during a software development project. The RUP is divided into four phases, each one focusing on a certain aspect of the development cycle: Inception, Elaboration, Construction, and Transition. In each of these phases the RUP best practices give us the opportunity to verify the progress and quality of the project.
In the Inception phase, the focus is on understanding the objectives of the project. That's achieved by exploring the requirements to a degree where it's possible to identify major risks and other difficulties that are more or less likely to occur later on. The question to be answered before the end of this phase is whether the project is worth doing at all. To move on with a worthless project can only be a waste of time and money that could be invested in something of value instead. These kinds of fundamental questions must be dealt with as early as possible.
Once the project has a go to continue, it enters the Elaboration phase. Here, the focus is on establishing a solid design foundation (the architecture) and mitigating the major risks of the project. After analyzing the requirements set, it's essential to shape the architecture from the requirements that have the most impact on the architecture. Only when the architecture is set and proven to meet the significant requirements is it safe to flesh out the system's functionality. Thus, you're stuck in the Elaboration phase until you've proven that your architecture will hold.
To summarize, in the RUP, the quality of the latest increment is verified in every iteration. We start out by verifying that we've understood the problem and that a solid business case exists. If not, we either continue until we reach those checkpoints or we close the project, saving time and money. We also verify that a foolproof architecture has been established before we move on to fleshing out the system's functionality.
In a movie project, the director primarily uses the modeling tools in his or her toolbox to catch problems with a diverging story line, scenes that don't fit together, or a tempo that just isn't right. When problems are found early, it's easier to do something about them. In moviemaking as in software development, the general rule is that the earlier a flaw is discovered, the cheaper it is to fix. The best practice of continuously verifying quality can facilitate this.
I think we all agree that change is necessary but inconvenient. Requirements will almost inevitably change over time, for a number of different reasons -- stakeholders change their minds, developers gain a deeper understanding of the requirements, the effects of design decisions become evident, and so forth. Identifying the need to change something is one thing, but making the change is something else. One of the reasons that waterfall development so often fails is that it's unable to handle change. An iterative and incremental methodology, by contrast, facilitates continuous change, iterating toward a better solution.
Making a feature film is a vast undertaking that involves managing a huge crew and a substantial budget. Communicating well about needed changes is vital to the success of such a project. Imagine that the director wants to improve the final scene. Although it comes at the end of the movie, the need for improvement can be identified early since quality is continuously verified on all levels. Do the screenwriters have to update the script? Who will review and approve it? Does the scene have to be modeled again? If so, will storyboards, 3D graphics, or plastic models be used? Does the set need to be modified, or does a new set need to be built? Do we have to scout for a new location? Do we need to call the special effects guys? How does this affect our budget? Do we have to ask for more time and money? These are the kinds of questions that result in changing plans and therefore must be addressed, preferably in an iterative manner.
One of the key artifacts in the RUP framework is the project plan. The project plan details the tasks, schedule, cost, resources, milestones, and deliverables needed to complete the project. Progress is tracked against the plan and measured by work completed -- by milestones reached and results delivered. The plan is conceived early in the project and frequently updated throughout the lifecycle.
The project plan, like the rest of the RUP framework, is easily adaptable to projects other than software development. Let's take a look at a very rough movie project plan as an example. See Figure 3.
Figure 3. A movie project plan, structured similarly to a software development project
In this example, activities related to making a movie are substituted for the RUP disciplines. Developing the screenplay is analogous to writing requirements, filming corresponds to implementation, and producing the movie is more or less like project management. Dividing the timeline into four phases puts the focus on different aspects of the movie project at different times. We also see that the activities run in parallel, typically exchanging information and work packages in a highly efficient, cross-functional manner -- just like in the RUP.
Applying the RUP to other kinds of projects
The principles of the RUP aren't unique to either software development or movie creation. They're applicable to any situation where uncertainty is the number-one problem. In this type of situation, it's impossible to calculate the outcome in advance, no matter how much time and effort you put into it. To be even more general, the principles of the RUP can be used for managing projects with the following characteristics:
- projects that produce some kind of deliverable
- projects in which the solution is more or less unknown
- projects where unpredictability is a key factor
Here are some examples of projects where using the RUP principles could be beneficial:
If you were to write a book on C++ programming, you would certainly aim for a deliverable (the book itself). The structure and contents of the book, its key chapters, and the educational method it employs are examples of the unknown or unpredictable aspects of the book project. First of all you would determine the target audience and write a short description of each chapter. After that, you might detail the most critical chapters and have them reviewed before proceeding with the remaining parts. The final steps would be completing the book and sending it to potential publishers.
If you were to conduct a study on how to improve the test capabilities of a software organization, you would probably be expected to produce some sort of report. Initially you would need to understand the problem and make a rough time plan as well as secure the resources you would need during the investigation. Then you would try different methods to reduce the major uncertainties before you could update and communicate your plan with your increased understanding of the problem. Having eliminated the high risks, you might move on and conduct the bulk of your study. Finally, you would write your report and gain agreement from your client. It's no coincidence that many study methods are based on principles similar to the RUP's.
If you were to implement the RUP in an organization, you would typically start with identifying risks and opportunities and creating a high-level adoption plan where you'd outline the distribution of your adoption effort over a number of projects. You would probably start with implementing the most critical parts (depending on the status of the target organization) of the RUP for the first project, saving the not-so-critical parts to implement in later projects. The deliverable would be a documented RUP process configuration as well as a more capable development organization.
The RUP provides a framework of rules and practices that mitigate the unpredictability of software development. Furthermore, the basic principles of the RUP can be transferred to solve just about any other kind of unpredictable problem, such as making a movie or writing a book. Conforming to the RUP doesn't make software development -- or moviemaking -- easier, but then, that isn't the idea. Overall, it's a harder road to take compared to traditional development. The effort is justified, though, by the rewards: improved product quality and a more predictable development effort.
Learn
- See "Writing a book with RUP and IBM Rational RequisitePro" by Christophe Tournier (Rational Edge, October 2003) for details of how one person used the RUP to develop a nonsoftware project.
- Get Refer to Adopting the Rational Unified Process: Success with the RUP by Stefan Bergstrand Lotta Rerg (Addison Wesley, 2004) for practical advice on introducing the RUP framework into your organization.
- Read the IBM Rational whitepaper The Essence of an Effective Development Process for a good introduction to the RUP.
- To learn more about the Rational Unified Process framework, visit the RUP area on developerWorks Rational. You'll find technical documentation, how-to articles, education, downloads, product information, and more.Rational books at discounted prices
- Get Rational books at discounted prices from the Developer Bookstore.
Discuss
- Participate in the discussion forum.
- Share your questions and views on this article with the author and other readers in theRational discussion forums.
- Get involved in the developerWorks community by participating in developerWorks blogs.
Mats Wessberg is a RUP generalist and has worked with the adoption, implementation, and configuration of the Rational Unified Process methodology. He has also been a project manager and a process engineer in RUP-based organizations. He holds degrees in mathematics and computer science. Mats can be reached at mats.wessberg@consolidate.se.
Comments (Undergoing maintenance)
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
