 | Level: Intermediate Gary Evans, Independent Object Technology Evangelist, Evanetics
18 Nov 2003 With RUP being such a heavyweight process, it may seem like the 800-pound gorilla to the unfamiliar. Gary Evans points out that the philosophy is simple, and that the process exists to serve you, not the other way around. Sound too good to be true? Read on for more.
The demand to reduce complexity in object-oriented software development process and notation has become a continuing refrain. Participants in a recent forum at UML World
1
discussed the complexity of the Unified Modeling Language (UML) in its current form. Implicit in the experts' recommendations on ways to simplify the sprawling mass of UML (the 800-page Version 1.3 specification is available at www.omg.org) was the acknowledgment that you cannot use UML effectively without a process to guide the modeler.
Lightening Up a Heavyweight
Although some companies are experimenting with emerging "lightweight" methodologies designed for use with UML, for most companies the Rational Unified Process (RUP) -- which has the appeal of name recognition and is certainly in no danger of being labeled "lightweight" -- is plenty new and different enough. It represents a significant departure from the waterfall approach still used by so many software companies. And for their development teams, RUP might be the most daring software process and management innovation they have attempted in years, if not decades.
Often, the adoption is not painless. Even after consulting the instructional literature and reading through RUP files, many of my clients are uncertain about how to sequence the steps and unclear about how the steps are connected. What they most want to know is, "What are the minimum steps we must take to be successful with RUP?"
The good news is that RUP really is a tailorable, fairly adaptable, and quite reasonable product for heavyweight companies to use in improving their software development process -- if they understand it. In fact, I wrote this article mainly to demystify the overwhelming mass of information in RUP.
In addition, I've observed that companies often abandon an official process in midstream because it's too difficult to describe and assimilate, relegating it to "shelfware" that sits unused in a manager's office. To save clients from this fate, I've posted a readable, usable, single 8.5" X 11" page, .pdf version of RUP -- a "mini" RUP, if you will -- on my Web site: www.evanetics.com.
Although this document presents a recipe for applying RUP, the really hard part of changing a corporate software process is not in following a checklist -- it's in changing people's mindset. The waterfall process is built around an (unfounded) optimism that it is possible to understand everything at each stage of the development process before moving to the next stage. Look at a waterfall project schedule, and you will immediately see that it has no provision for going back over previously charted ground. Iterative processes, however, are much more honest. We acknowledge within the process that we cannot understand everything at a point in time; rather, we accumulate this knowledge over time, continually revisiting areas we have been to before. Changing how we think about software development is orders of magnitude more difficult than changing how we do development. This article offers a small contribution toward this change.
Understanding the Underlying Principles
RUP is based on a few important philosophical principles: a software project team should plan ahead; it should know where it is going; it should capture project knowledge in a storable and extensible form. Since RUP was born at a software tools company, this emphasis is not a surprise. RUP also incorporates the concept of "best practices" for software engineering, defined by five major properties:
| Property for Best Practices | Description | | Use case driven | Guided by interactions between the system and its users. | | Architecture centric | Founded on a defined architecture, with clear relationships among the architecture components. | | Iterative | The problem and solution are organized into small pieces, so each iteration purposely addresses only one of those pieces. | | Incremental | Each iteration builds incrementally on the foundation built in the previous iteration. | | Controlled | Control with respect to process means you always know what to do next; control with respect to management means that all deliverables, artifacts, and code are under configuration management. |
A Manageable Iterative Development Process
This section lays out the minimal steps for an iterative software development process that I follow in my projects with clients in diverse industries. The description assumes you are familiar with core UML elements such as sequence diagrams and use cases.
Iteration Zero: Getting Started
Iteration Zero, which takes place before development begins, provides an opportunity to explore the breadth and depth of the system's requirements and goals. I usually tell my clients that we will not actually begin building the system until Iteration Three or Four, after we have proven our ideas about appropriate architecture as well as our understanding of the system's business model.
| Steps |
Explanations | |
1. Identify the most significant or visible functional and non-functional requirements for the system.
|
Express the user-visible functional requirements as use cases or scenarios. Use cases alone, however, are not enough. Capture non-functional requirements in a standard paragraph-style document (or family of documents).
2
| |
2. Identify classes that are part of the domain being modeled.
| Discovering classes from the requirements artifacts can be done in several ways -- Class/Responsibility/Collaborator (CRC) cards, data mining, prior domain knowledge, or searching requirements documents for nouns and noun phrases. Experiment with different approaches. In searching for your project's classes, a single technique is seldom sufficient. | |
3. Define the responsibilities and relationships for each class in the domain.
| Responsibilities are the strategic goals of a class. Responsibilities will determine the class's operations; the operations, in turn, determine the class's attributes (i.e., data). Do NOT start with data and try to derive class operations from that. That's called data modeling, not object modeling. | |
4. Construct the domain class diagram.
| The domain class diagram is just a page of class boxes with class names: no relationships, operations, or attributes yet. Together with the responsibility definitions, this diagram lays a foundation for a common vocabulary in the project. | |
5. Capture all identified use case and class definitions in an OO CASE tool.
| You must use a CASE tool for all but the most trivial projects. If you don't use one, you either won't do the models you need to do or you will be overwhelmed by the mass and volatility of the artifacts you produce.
3
I cannot emphasize this enough. Years ago when I worked with a major computer manufacturer, they did a study on all the corporate projects that were more than 50% over budget or 50% over scheduled time. The major causes of these delays were all related to ignoring risk, or assuming that risk would go away. It doesn't. Address the highest risk aspects of your system immediately in early iterations, simultaneously with the most architecturally significant elements. This is absolutely imperative. Don't be tempted to pick the "low hanging fruit" and allow the risks to ripen into major problems. | |
6. Identify the major risk factors, and prioritize the most architecturally significant use cases and scenarios.
| Don't try to embrace every use case or every detail in the beginning. Be selective; focus on those 20% of use cases that give you 80% coverage of your major system functions. During the iterations you can add in the less significant use cases. Decide if you will use a time-box partitioning (fix the iteration duration and select enough use case functionality to fit into that time frame) or scenario partitioning (fix the use case functionality and determine the time needed to carry that functionality to code). | |
7. Partition the major use cases/scenarios across the planned iterations.
| For each iteration, define the goals, staffing needs, schedule, risks, inputs, and deliverables. | |
8. Develop an Iteration Plan describing each "mini-project" to be completed in an iteration.
| Keep the iterations focused and limited (I prefer 3-4 weeks per iteration). Strive to make each iteration a "mini-waterfall" project that enables you to "eat the elephant one bite at a time!" Each iteration description should cover all the software activities in the process: requirements, analysis, design, implementation and test. In addition, each iteration will involve QA, Engineering, Product Management, and other departments -- and each iteration will produce an executable. Iterative development is a "divide and conquer" strategy. If done properly, it allows you to know within days (or maybe weeks) if you are getting off schedule. |
Development: Ten Steps for Subsequent Iterations
In Iteration Zero we have only surveyed the overall size and most prominent characteristics of our project. In RUP this iteration occurs within the Inception phase, when we are trying to reach a "go/no-go" decision on the project. At the end of Iteration Zero we should have a foundation from which we can generate more detail about what our system should do (this is analysis thinking), and how our system will achieve these goals (this is design thinking). In RUP we generate this detail iteratively, which means that we do the following ten steps six times if we have defined six iterations for our project.
| Steps |
Explanations | |
1. Merge the functional flow in the use cases and scenarios with the classes in the domain class diagram by constructing analysis-level interaction diagrams (i.e., sequence diagrams or collaboration diagrams) for each scenario in the iteration.
| The major benefit of dynamic models is that they allow you to discover class operations, which meet the business requirements in your requirements artifacts. If you construct only static models (i.e., class diagrams or object diagrams), then you will have a high risk of failure. Consider a still photograph versus a video -- each has unique properties, and each presents a distinctly different perspective. | |
2. Test and challenge the analysis-level sequence diagrams on paper, a whiteboard, or a workstation screen.
| Follow the flow of messages in the interaction diagrams. Update the class diagram with the operations and data you discover from the interaction diagrams. Don't be concerned about performance or technology issues in this analysis phase. In analysis, we explore problems; in design, we define our solution. Try to keep these phases segregated in your thinking. | |
3. Develop analysis-level statechart diagrams for each class with "significant" state.
| Statecharts describe the "state-space" for a single class. Sequence diagrams describe the messages sent among multiple objects to carry out the work of the use cases. | |
4. Enhance sequence diagrams and statechart diagrams with design-level content.
| In design thinking we identify and add to the class diagram and sequence diagrams any required support or design classes (e.g., collection classes, GUI and other technology classes, datatypes, etc.). In the design activity of each iteration we take performance and technical considerations into account. | |
5. Challenge the design-level sequence diagrams and statechart diagrams on paper, discovering additional operations and data assigned to classes; update the class diagram with these operations and data.
| Design-level artifacts include actual function names and arguments, and actual datatypes and return types. | |
6. Update the OO CASE tool information and redistribute to the project team.
| Update all of the artifacts and diagrams. Add or modify classes as necessary. Re-publish system reports for team members. (Documentation should never be more than 24 hours old!) | |
7. Develop code for the use cases/scenarios in the current iteration from the current diagrams.
| Remember, design is not coding. Design is the necessary preparation for writing code. | |
8. Test the code in the current iteration.
| Testing is continual: test on the largest (project) level as well as on the smallest (unit) level. (For an excellent discussion on this topic, see Scott Ambler's Building Object Applications That Work, Cambridge University Press/SIGS Books, 1998.) | |
9. Conduct an Iteration Review.
| Focus your review on essentials: ask what went right and what went wrong in the iteration. Did you achieve all of the goals listed in your Iteration Plan? Did the iteration take longer than planned? Did you fail to add planned functionality? For any area that did not succeed, ruthlessly determine the root causes of the failure and fix them. Then determine if you can still follow your current project and iteration plans -- if not, then change them, too. Nothing is sacred. If you are not willing to change the remainder of the schedule or iteration content, then you are still in the waterfall mindset. | |
10. Conduct the next iteration (i.e., repeat steps 1-9), adding in the next set of use cases/scenarios. Continue conducting iterations until the system is completely built.
| This is the essence of an iterative, incremental process: do again what you just did (iterate), building incrementally on the base of the previous iteration.
|
 |
Moving Forward
Is this a complete and sufficient list of activities to perform in a minimal version of RUP? Not at all, but it is a manageable roadmap to help you get comfortable with the essential aspects of RUP and UML. As your comfort level grows, you can add or delete artifacts or process steps as you see the need.
Will following this mini-RUP guarantee project success? No, but it should be a useful guide if you are moving to RUP. The basic philosophy is pretty simple: know where you are going, and "eat the elephant one bite at a time." And most important, never, never lose sight of this rule: the process is here to serve you; you are not here to serve the process.
Notes
1
"Defining the UML Kernel," Software Development Magazine, October 2000.
2
For some excellent tips on discovering use cases and writing use case descriptions, see www.williamnazzaro.com.
3
See "Do I really need an OO CASE Tool?" at www.evanetics.com for a brief discussion of what to look for in an OO CASE tool.
About the author | | | Gary K. Evans is the founder of Evanetics, Inc. (www.evanetics.com), a consulting company dedicated to reducing risk on software projects through agile techniques and process. He is the author of over a dozen papers on object technology and tools, and is a frequent speaker at major software conferences. He is an avid soccer player, but loves even more working with small development teams, training them in OOAD and agile RUP, and then working with them side-by-side to deliver the right software faster than they ever thought possible. He can be reached at gkevans@evanetics.com. |
Rate this page
| |
