Concept:
|
White Papers: |
The Rational Unified Process (RUP) is a process framework that Rational Software has refined over the years which has been widely used for all types of software projects-from small to large. Recently a growing number of "agile" processes-such as eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) and the Crystal Clear Methodology-have recently been gaining recognition as effective methods for building smaller systems. (See www.agilealliance.org for further information on the Agile Alliance.)
The following sections are intended to assist those project teams evaluating some of the "agile" practices found in one of these methods to see how they are addressed by the more complete software development process defined by RUP.
The agile community has synthesized a number of "best practices" that are especially applicable to small, co-located project teams. Although RUP is targeted to project teams of any size, it can be successfully applied to small projects. In general, RUP and the processes of the Agile community have a similar view of the key best practices required to develop quality software-for example, applying iterative development and focusing on the end users.
The following sections explain how to apply some of the "best practices"
identified in the agile community to RUP-based projects that would like to benefit
from some of these practices. In this case, the focus will be specifically on
those practices presented by the eXtreme Programming (XP) methodology. (For
more information on XP, please refer to the website: http://www.extremeprogramming.org.)
XP includes four basic "activities" (coding, testing, listening, and designing), which are actually more closely aligned with RUP disciplines. These XP activities are performed using a set of practices that require the performance of additional activities, which map to some of the other disciplines in the RUP. XP's practices, according to Extreme Programming Explained, are:
Activities performed as a result of the "planning game" practice, for example, will mainly map to the RUP's project management discipline. But some RUP topics, such as business modeling and the deployment of the released software, are outside the scope of XP. Requirements elicitation is largely outside the scope of XP, since the customer defines and provides the requirements. Also, because of simpler development projects it addresses, XP can deal very lightly with the issues the RUP covers in detail in the configuration and change management discipline and the environment discipline.
In the disciplines in which XP and the RUP overlap, the following practices described in XP could be-and in some cases already are-employed in the RUP:
The suggestion that good process has to be enforced at the "micro" level is often unpalatable and may not fit some corporate cultures. Strict enforcement, therefore, is not advocated by RUP. However, in some circumstances, working in pairs-and some of the other team-based practices advocated by XP-is obviously advantageous, as each team member can help the other along; for example:
The following XP practices don't scale well for larger systems (nor does XP claim they do), so we would make their use subject to this proviso in the RUP.
Finally, an XP practice that at first glance sounds potentially usable in the
RUP-Simple Design-needs some elaboration and caution when applied
generally.
There's a problem here, akin to the problem of local optimizations, in dealing with what the RUP calls "nonfunctional" requirements. These requirements also deliver business value to the customer, but they're more difficult to express as stories. Some of what XP calls constraints fall into this category. The RUP doesn't advocate designing for more than is required in any kind of speculative way, either, but it does advocate designing with an architectural model in mind-that model being one of the keys to meeting nonfunctional requirements.
So, the RUP agrees with XP that the "simple design" should include running all the tests, but with the rider that this includes tests that demonstrate that the software will meet the nonfunctional requirements. Again, this only looms as a major issue as system size and complexity increase, or when the architecture is unprecedented or the nonfunctional requirements onerous. For example, the need for marshalling data (to operate in a heterogeneous distributed environment) seems to make code overly complex, but it will still be required throughout the program.
When we tailor the RUP for a small project and reduce the artifact requirements accordingly, how does this compare to the equivalent of artifacts in an XP project? Looking at the example development case for small projects in the RUP, we see a sample RUP configuration has been configured to produce fewer artifacts (as shown in Table 1).
XP Artifacts
|
RUP Artifacts
(from Example Development Case for Small Projects) |
---|---|
Stories Additional documentation from conversations |
Vision Glossary Use-Case Model |
Constraints | Supplementary Specifications |
Acceptance tests and unit tests Test data and test results |
Test Plan |
Software (code) | Implementation Model |
Releases | Product (Deployment Unit) Release Notes |
Metaphor | Software Architecture Document |
Design (CRC, UML sketch) Technical tasks and other tasks Design documents produced at end Supporting documentation |
Design Model |
Coding standards | Project Specific Guidelines |
Workspace Testing framework and tools |
Development Case Test Environment Configuration |
Release plan Iteration plan Story estimates and task estimates |
Software Development Plan
Iteration Plan |
Overall plan and budget | Business Case Risk List |
Reports on progress Time records for task work Metrics data (including resources, scope, quality, time) Results tracking Reports and notes on meetings |
Status Assessment Iteration Assessment Review Record |
Defects (and associated data) | Change Requests |
Code management tools | Project Repository Workspace |
Spike (solution) |
Prototypes |
XP itself (it's recommendations and guidance) | |
[Not included in XP] |
Table 1: XP-to-RUP mapping of artifacts for a small project
Although the granularity of the artifacts varies on both sides, in general the artifacts in the RUP for small projects (the type XP would comfortably address) map quite well to those of an XP project.
Note that the Example Development
Case for Small Projects also includes a few artifacts which are not covered
by XP, but are needed on many projects. These include Data
Model, and artifacts related to deployment, such as End-User
Support Material.
The RUP defines an activity as work performed by a role-either using and transforming input artifacts or producing new and changed output artifacts. RUP goes on to enumerate these activities and categorize them according to the RUP disciplines. These disciplines include: business modeling, requirements, analysis and design, deployment, and project management (among others).
Activities are time-related through the artifacts they produce and consume: an activity can logically begin when its inputs are available (and in an appropriately mature state). This means that producer-consumer activity pairs can overlap in time, if the artifact state permits; they need not be rigidly sequenced. Activities are intended to give strong guidance on how an artifact should be produced, and they may also be used to help the project manager with planning.
Woven through the RUP as it's described in terms of lifecycle, artifacts, and activities are "best practices": software engineering principles proven to yield quality software built to predictable schedule and budget. The RUP, through its activities (and their associated artifacts) supports and realizes these best practices - they are themes running through the RUP. Note that XP uses the notion of "practices" as well, but as we shall see, there is not an exact alignment with RUP's concept of best practice.
XP presents an engagingly simple view of software development as having four basic activities-coding, testing, listening, and designing-which are to be enabled and structured according to some supporting practices (as discussed in Extreme Programming Explained, Chapter 9). Actually, as noted earlier, XP's activities are closer in scope to the RUP's disciplines than to the RUP's activities, and much of what happens on an XP project (in addition to its four basic activities) will come from the elaboration and application of its practices.
So, there is an XP equivalent of the RUP's activities, but XP's "activities" aren't formally identified or described as such. For example, looking at Chapter 4, "User Stories," in Extreme Programming Installed, you'll find the heading, "Define requirements with stories, written on cards," and throughout the chapter there's a mixture of process description and guidance on what user stories are, and how (and by whom) they should be produced. And it goes on that way; in the various sections of the XP books (under headings that are a mixture of artifact-focused and activity-focused), both "things produced" and "things done" are described, to varying degrees of prescription and detail.
RUP's apparently high degree of prescription results from its completeness and greater formality in its treatment of activities and their inputs and outputs. XP does not lack prescription but, perhaps in its attempt to remain lightweight, the formality and detail are simply omitted. Lack of specificity is neither a strength nor a weakness, but the lack of detailed information in XP should not be confused with simplicity. Not having details may be fine for more experienced developers, but in many cases, more details are a great help for new team members, and team members that are still getting up to speed with the team's approach to software development.
With Activities, just as with Artifacts, it is important to keep focus on what
we are trying to achieve. Carrying out an activity blindly is never a good practice.
Activities and associated guidelines are there to look at when you need them
to achieve your objectives, but should not be used as an excuse for not having
to figure out what you are trying to achieve. This spirit is well articulated
in XP, and we believe it should be applied by every user of RUP
In the RUP, activities are said to be performed by roles (or, more precisely, by individuals or groups playing roles). Roles also have responsibility for particular artifacts; the responsible role will usually create the artifact and ensure that any changes made by other roles (if allowed at all) don't break the artifact. An individual or group of people may perform just one role or several roles. A role doesn't have to be mapped to a only a single position or "slot" in an organization.
Extreme Programming Explained identifies seven roles applicable to XP-Programmer, Customer, Tester, Tracker, Coach, Consultant, and Big Boss-and describes their responsibilities and the competencies required of the people who will perform them. References are made to these roles in some of the other XP books as well. The difference in the number of roles in XP and the RUP is easy to explain:
When RUP roles are mapped to a small project, the number of XP-like roles that
they correspond to is reduced considerably in that the number of positions,
or job titles, is 5. Table 3 (drawn from the RUP) shows this mapping with the
corresponding XP Role.
XP Role | Example RUP Small Project Team Member | RUP Role |
---|---|---|
Coach Consultant Big Boss |
Sally Slalom, Senior Manager | Project Manager Deployment Manager Technical Reviewer Configuration Manager Change Control Manager |
Customer | Stakeholder (as documented in the Vision) |
Management
Reviewer Technical Reviewer (requirements) |
Customer Big Boss Tracker |
Tom Telemark, Senior Software Engineer | System Analyst Requirements Specifier User Interface Designer Software Architect Technical Reviewer Test Manager Test Analyst and to a lesser extent the developer roles. |
Programmer Tester |
Susan Snow, Software Engineer Henry Halfpipe, Junior Software Engineer |
Designer Implementer Technical Reviewer Integrator Test Designer Tester Technical Writer |
Tracker | Patrick Powder, Administrative Assistant | Responsible for maintaining the Project web site, assisting the Project Manager role in planning/scheduling activities, and assisting the Change Control Manager role in controlling changes to artifacts. May also provide assistance to other roles as necessary. |
Table 3: Mapping XP roles to RUP roles on a small project
The RUP is a process framework from which particular processes can be configured and then instantiated. The RUP must be configured-this is a required step defined in the RUP itself. Strictly speaking then, we should compare a tailored version of the RUP with XP-that is, with the RUP tailored to the project characteristics that XP explicitly establishes (and those that can be inferred). Such a tailored RUP process could accommodate many of XP's practices (such as pair programming, test-first design and refactoring), but it still wouldn't be identical to XP because of RUP's emphasis on the importance of architecture, abstraction (in modeling), and risk, and its different structure in time (phases and iterations).
XP is intentionally directed at implementing a lightweight process for small projects. In doing so, it also includes descriptions (at least in the books) that are not fully elaborated. In an XP implementation there will always be things that will need to be discovered, invented, or defined on the fly. The RUP will accommodate projects that both fit and are beyond the scope of XP in scale and kind. As this roadmap shows, RUP is actually quite compatible with most of the practices described in the XP literature.
Keep in mind that essence of XP is its focus on organization, people, and culture. This is important in all projects and is certainly applicable to those projects using RUP. Small projects could benefit greatly by using these practices together.
Rational Unified Process |