| New forum for Rational Edge readers |
|---|
| At the end of this article, you'll find a link to a new forum created specially for readers of The Rational Edge ezine. Get ready to add your thoughts about this article or other topics you've found in our pages. |
If you're a process engineer, process analyst, or a team leader looking to standardize on a commercially available framework for your organization's software development efforts, this article is for you. My objective is to point out the similarities and differences between the Rational Unified Process®, or RUP®, and the Microsoft Solutions Framework (MSF).
Yes, both embrace process disciplines, roles, principles, best practices, and artifacts. But in some cases these elements have different definitions and purposes. That means it's hard to directly map a RUP element to an MSF element, but I can nevertheless present similarities and suggest ways to compare the two frameworks.
The current 7.0 version of RUP defines itself as a process for Software Engineering arranged in disciplines and phases. RUP was based on best practices of software engineering. In addition to containing all basic elements of a development process (roles, tasks, activities, artifacts, workflow), RUP features a broad conceptual library about elements related to software engineering. As noted by Per Kroll and Philippe Kruchten,1 RUP defines a way of developing software that is iterative, architecture-centered, and driven by use cases. RUP is currently available as part of IBM Rational Method Composer, which allows you to tailor the process environment to your specific organizational needs. You can learn more about RUP by visiting the IBM Rational Website.2
The current 4.0 version of MSF defines itself as an approach for projects that defines a set of principles, models, disciplines, concepts, guides, and practices already proven by Microsoft. Microsoft does not classify MSF as a methodology; rather, MSF serves as an extensive guide and a collection of best practices for software development.3
First glance: A high-level mapping of MSF to RUP
At first, mapping both frameworks seems a trivial task -- a matter of analyzing the phases, milestones, iterations, and artifacts. But closer look at the overall classification of phases and disciplines shows that this mapping is not as direct as it seems. Let's consider two ways to compare the two frameworks at a high level.
Because both of the two frameworks use similar terms, we might be tempted to map RUP's cycle of software development to MSF's concept of an iteration: that is, 1 RUP development cycle = 1 MSF iteration. This comparison would equate the four phases found in each framework to each other, as follows:
RUP Inception = MSF Envisioning
RUP Elaboration = MSF Planning
RUP Construction = MSF Developing
RUP Transition = MSF Stabilizing and MSF Deploying
MSF describes an iterative process, indicating that, for small and trivial projects, a single iteration would be sufficient, while for bigger projects more iterations would be necessary until the product is complete and achieves the quality required. We can say that each MSF iteration has as its objective a "final" delivery with all necessary artifacts.
A development cycle according to RUP has several iterations, and at the end of each iteration we have a partial "internal or external" release, and only at the end of the development cycle we will have a "final" release with all complete artifacts.
In my opinion, however, this is the wrong way to compare RUP and MSF.
I believe a better way to compare these frameworks involves mapping a RUP iteration to an MSF iteration, which leads to mapping the MSF phases against the RUP disciplines. This approach would suggest that at the end of each RUP iteration, we would have an external release already completed, since at the end of a MSF iteration a "stable" and "complete" release is generated.
In any case, as we can see, the mapping is not as direct as we might at first imagine it would be. If we had the opportunity to compare two projects solving the same problem, one using MSF and the other using RUP, the phase by phase seminaries would possibly not be apparent.
Another challenge in comparing RUP and MSF has to do with different visions or process models.
To put it simply, RUP describes a development process in terms of phases that have iterations. Each iteration involves disciplines in which we find roles, tasks, and artifacts. At the end of an iteration we will have an iteration milestone, and at the end of each phase we have a phase milestone.
The set of phases, iterations, and disciplines comprise the full RUP-based lifecycle, as shown in Figure 1. At the end of this lifecycle we have a "complete" release.
Figure 1: The RUP lifecycle
By contrast, MSF is divided into two different process models: "Team Model" and "Process Model." Both models can be classified as descriptions that visually present the project arrangement in terms of teams and activities through a lifecycle. "Team Model" defines people who will work in the project and their respective activities, and "Process Model" deals with the sequencing of the project activities, at a high level. The MSF Process Model is divided into phases, each one of which describes a set of by-products and milestones that should be achieved.
Figure 2: The MSF Team Model and Process Model
Other elements of the processes defined by RUP and MSF are easier to compare. For example:
MSF uses the general term "deliverables," while RUP defines three different types of "work products": deliverables, artifacts, and results. Most of the MSF artifacts can be mapped to the RUP artifacts. But the opposite is not always true, because RUP has several artifacts that currently do not exist in MSF.
In RUP, a work product is always the result of a task that contains details on how the task will be executed, while for MSF the artifacts are results of a phase, having less details on how that artifact will be produced.
A comparison of roles between RUP and MSF reveals one of the main differences between these process frameworks. It is very important to recognize the different concepts which this term "role" defines.
The team model in MSF, known as "Team Role," is based on sets of activities, while the roles described in RUP are based on responsibilities.
As shown in Figure 2, MSF has six roles and defines them as "team roles." These can be mapped against the RUP roles, an example of which is provided in Table 1. RUP has a larger number of roles associated with the development disciplines (Business Modeling, Requirements, Analysis & Design, Implementation, Tests, Deployment) and support disciplines (Configuration and Change Management, Project Management and Environment).
Despite these differences -- namely that the definition of roles in MSF is less detailed than the roles description in RUP -- it is possible to perform a role mapping between both frameworks, as shown in the Testing example presented in Table 1.
| MSF Team Role | RUP Role |
|---|---|
| Testing | Test Analyst |
| Test Designer | |
| Test Manager | |
| Tester |
For MSF, the word "discipline" refers to a more comprehensive and generic set of processes than in RUP. RUP associates disciplines with "steps" of a development process, and these are divided into different subjects, as described in the next section.
Table 2 presents what are classified as disciplines in both MSF and in RUP.
| MSF Disciplines |
|---|
| Project Management Risk Management Readiness Management |
| RUP Development Disciplines |
| Business Modeling Requirements Analysis & Design Implementation Tests Deployment |
| Support Disciplines |
| Configuration and Change Management Project Management Environment |
There is no direct mapping for activities, tasks, and steps between the two frameworks. An "activity" in RUP is related to a workflow with an arrangement of tasks.
Each task in RUP activities is detailed in steps. That means that in RUP we have a larger abundance of details for "how" the process will be executed. Figure 3 shows an example of a RUP workflow within the Requirements discipline. For each activity, we can drill down for more details on tasks, roles, and steps. For most RUP disciplines, you will find diagrams which show groupings of tasks that often are performed together, as illustrated in Figure 4.
Figure 3: Activity diagram illustrating the RUP Requirements discipline
Figure 4: Typical activities in the RUP Requirements discipline
By contrast, MSF defines the workflows in a more superficial way for each of the three disciplines. As a matter of fact, these workflows are simply called "process steps," as shown in Figure 5.
Figure 5: "Process steps" in the MSF Readiness Management discipline
For the purposes of this article, I will not discuss all the remaining key concepts of both frameworks in detail. However, it is worth mentioning that the MSF key concepts Customers, Stakeholders, Solution, Baselining, Scope, and Tradeoff are named differently in RUP. This should not cause any confusion, but the RUP terminology uses a different name for similar key concepts. Specifically, RUP defines the method elements as key concepts, and the main ones being "role," "work product," and "task."
Again, there should be no confusion between the RUP and MSF principles. In fact, one can argue that both frameworks are based on similar principles.
MSF uses eight principles:
- Foster open communications
- Work toward a shared vision
- Empower team members
- Establish clear accountability and shared responsibility
- Focus on delivering business value
- Stay agile, expect change
- Invest in quality
- Learn from all experiences
As a process framework, RUP is iterative, architecture-centric, and use-case driven. This is incorporated into the six RUP principles:
- Adapt the Process
- Balance Competing Stakeholder Priorities
- Collaborate Across Teams
- Demonstrate the Value Iteratively
- Elevate the Level of Abstraction
- Focus Continually on Quality
We can say that both MSF and RUP are different in some aspects and alike in others. RUP has a greater abundance of detail and content related to a development process, while MSF treats similar concepts in a less detailed, more general way.
One important point to mention is that there are two common tailorings of MSF, one for Agile and one for CMMI. For RUP, there are tailorings for small projects or for large projects, as well as other tailorings for different necessities -- e.g., RUP for SOA Governance, RUP for COTS development, RUP for Java and .Net environment, and so on.
We can say that RUP is a complete process framework, because it documents who does what, when, and how. One of the main differences between MSF and RUP is related to "how" -- in other words, MSF frequently offers no guidance regarding how to reach a certain objective (produce an artifact, perform a task). For example, MSF says that you must perform a functional specification, but it does not what technique should be used, which notation, etc.
Both frameworks strongly advocate the early mitigation of risks. On this point, RUP offers extensive guidance by showing you the prioritization technique of use cases and architecture stabilization.
Special thanks to Ricardo Balduino for help in translating this article from the original Portuguese, and to both Ricardo and Scott Ambler for their careful technical review.
1 Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy, Addison-Wesley Professional: 2003. ISBN-10: 0321166094.
2 The Process and Portfolio Management section of the IBM Website offers a range of resources, at: http://www.ibm.com/software/rational/offerings/lifecycle.html. For specific details on the Rational Unified Process, read the paper available at: ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/rup_bestpractices.pdf
3 To learn more about MSF, visit http://www.microsoft.com/technet/itsolutions/msf/default.mspx
IBM Rational Unified Process
http://www.ibm.com/developerworks/rational/products/rup
MSF Process Model
http://download.microsoft.com/download/2/3/f/23f13f70-8e46-4f44-97f6-7dfb45010859/MSF%20Process%20Model%20v.%203.1.pdf
Microsoft Solutions Framework 3.0 -- Overview
http://download.microsoft.com/download/2/3/f/23f13f70-8e46-4f44-97f6-7dfb45010859/MSF_v3_Overview%20Whitepaper.pdf
Dear Reader: A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
Sandra Sergi Santos graduated from Mackenzie University and completed her post-graduate work at Fundação Armando Álvares Penteado, in Sao Paulo, Brazil. Having worked in the field of software development for fifteen years, she has industry experience in the financial and telecommunication sectors, and is a process expert in IBM Rational tools implementation and projects coordination. A certified Project Management Professional and Scrum Master, she is also certified in the IBM Rational Unified Process, IBM Rational SCM Tools, and requirements management. She currently works as a software engineer specialist for the Rational brand for IBM Brazil, and can be reached at ssergi@br.ibm.com.
Table of contents
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
