Talk:Rational unified process

Quality Assurance / Control

That's surprising Quality Assurae/Control is nowhere in RUP. Unless it is everywhere instilled in all disciplines. When a stream only exists virtually, it has a strong probability not to be deployed correctly. This is probably one of the major weaknesses of RUP. —Preceding unsigned comment added by 84.103.192.89 (talk) 17:05, 10 September 2009 (UTC)

One of the 6 best practices on which RUP is based is "Continuously verify quality". In combination with risk-driven iterations and the emphasis on architecture, the overall focus on quality is quite strong.

WUT?--193.63.27.196 (talk) 14:12, 6 October 2009 (UTC)

Business Modeling discipline

"They must also ensure a common understanding of the target organization between customers, end users and developers." They refers to software engineers. Is this intentional or a bad choice of words? If intentional that would explain all that failed software engineering projects even with RUP. Shouldn't that be the responsibility of a different role (a Manager Role, an Analyst Role?) Lippmj (talk) 19:53, 22 January 2009 (UTC)

Iterative

"is an iterative software development process" :: this is not true, iterative is the default but is not 100% necessary e.g. you can take the roles and templates and processes from RUP in a waterfall way and still be using RUP. So the word "iterative" is very awkward.

If you are not practising risk-driven iterative development, you are not using RUP. —Preceding unsigned comment added by 65.96.212.244 (talk) 07:02, 2 June 2009 (UTC)

Discussion prior to June 2006

In the RUP 2000 we changed workers to role and core workflow to disciplines, hence my small edits. Also the link to the Rational Software company is now defunct. (from Philippe Kruchten, one of the original developers of RUP).

---

its a good read, im learning the stuff.

one comment, the limitations section seems to jump to past tense... had vs has and was vs is.

should this be changed?

---

I'm not a fan of RUP/UP and I was surprised that the tone of this article seems to show a bias towards the methodology & product: there are no links to critical articles, the "limitations" section says if you think there are limitations then you don't understand the methodology (!!!).

I think it could easily be made into a well-rounded article that presents UP/RUP as a methodology without seemingly endorsing it, or giving the impression that it is universally accepted.

---

This is my first contribution (before I got a username), hope it's OK. I'm not the ideal person to write this as I'm not (yet) a Software Engineer and have never applied the RUP! However I've got an exam involving it tomorrow and thought it would be good revision. Sorry it's incomplete I realised I'd better start on Language Processing and Computer Systems (which is also in the exam), great :)

there should be explanation of the phases if it is an exam point of view

---

In section "Manage requirements" there was this comment at the end: "not really". I don't think it fits well in the article. A concensus should first be made and then, the "Manage requirements" should be reedited, imho.

---

Since I've worked with this method before, I took a stab and condensing and clarifying the material. I removed some comments that seemed POV and others that seemed redundant. I also reorganized a bit while updating the grammer and style. I was impressed with how thorough the article was and the excellent use of diagrams. Great first contribution! -- Jareth 18:02, Jun 21, 2005 (UTC)

---

I don't get "Ala ma kota" (looks like Polish) at the end of "Background of the Rational Unified Process". Is that of any use?

---

Do you think the Microsoft Solutions Framework is something that is related to the Rational Unified Process and can be added to the "See also" section? --Marc Hoeper 12:31, 29 November 2005 (UTC)

---

That what was "RUP", Rational Unified Process was renamed Unified Process (UP) and is now publicly held with Object Management Group (OMG) its custodian. Wouldn't it be better to rename this page as Unified Process, specify the origin and also what is RUP. RUP is now (as far as I know) a commercial product of IBM. --Werner BEROUX 18:58, 8 Mai 2006 (UTC)

---

I'm sorry, but I don't believe that's correct. OMG does not own the Unified Process, no one does. The term Unified Process (UP) is used by those who are using a RUP-like process but don't want to mention Rational. Unless there is some significant proof, this needs to be restored quickly. Mjchonoles

RUP approach

I have updated the paper to reflect numerous changes in RUP Version 7.0, including terminology changes and concepts from the Unified Method Architecture as proposed for the OMG standard Software Process Engineering Metamodel (SPEM) version 2.0, new delivery processes, and the fact that the RUP is now part of the IBM Rational Method Composer product.

Cecile Peraire, software development methodologist on the IBM RUP team.

---

May somebody inform me where I can be updated about all the news related to RUP (i mean only process without any tools). Currently I can't find the RUP detailed description on IBM site. It is really strange, they (IBM) base the products on something I can't read. In addition I have to say that if this article was updated according RUP 7.0, it corresponds only MSF 3.0 with some of its wrong concepts (it still looks like an old waterfall model).

So is IBM RUP is something new or it is "comertial" process suitable only for IBM software.

---

Michael Mutafian (Program Manager), Celenia Software --X4.mike 10:16, 4 July 2006 (UTC)

UP verses RUP

I have created a new (albeit short) Unified Process article. I do not want to belittle RUP, but I think with all these different flavors of UP being invented the Unified Process needs to be more than a REDIRECT to the RUP article.--GFLewis 19:08, 4 July 2006 (UTC)

As I have noted in Talk:Unified Process I have a problem with the implication that RUP is a derivative of UP. RUP is the original. I think it would be better to extend the history section here to cover the development of derivatives and include the table of them that you have put in the UP article. Then drop the UP article. It may also have been better to have had the Unified Process page as just a disambiguation page linking off to RUP and the others. FredThwaites 23:58, 15 July 2006 (UTC)

My primary sources for creation of a separate article were Agile and Iterative Development by Craig Larman (2004) and The Unified Process Explained by Kendall Scott (2002). Neither Larman nor Scott use the word derivative, but they do use the words specialization and/or refinement. From Larman:

The Unified Process (UP) is a popular iterative process framework, particulary its refinement in the Rational Unified Process. (Larman, p. 173)

The UP is an iterative process framework--a general process description that can and should be refined into a more detailed process description for an organization or project, such as the RUP. A UP specialization may itself be a more detailed process framework (as is the RUP) or a concrete process description for one particular project. (Larman p., 175)

Although Rational had Rational Unified Process and a commercial product in mind from the start, they also wanted to communicate and promote the idea of a process more public domain and open--a generalized Unified Process. This was consistent with their open Unified Modeling Language initiative. Hence, Ivar Jacobson wrote the first book to present this view, The Unified Software Development Process (1999) working from a draft of the RUP specification and product being developed by Kruchten's team. Since then, many books have been written under the appellation of simply "Unified Process" to signify similiarity to the RUP and adoption of its major ideas (the best practices, the phases, the disciplines, and so forth), while not necessarily being strictly the Rational process. (Larman, p. 207)

From Scott:

The Rational Unified Process (RUP) is an example of a specialized version of the Unified Process that adds elements to the generic framework. (Scott, p. 1)

Scott's book is a little dated and he is using the old terminology (i.e. Worksflow vs Disciplines). However, in an appendix he lists and describes elements which he claims are part of RUP but not UP:

• The nine Workflows (Project Management, Business Modeling, Requirements, Analysis and Design, Implementation, Test, Configuation and Change Management, Enviroment, Deployment)
• Five artifact sets (management set, requirements set, design set, implementation set and deployment set)
• RUP defines approximately twice as many workers as the Unified Process (according to Scott)

--GFLewis 21:01, 30 July 2006 (UTC)

Here is another reference in support of the precept that RUP and UP are not the same thing. This from no less than Philippe Kruchten in the preface (page xiv) to The Rational Unified Process: An Introduction, 3rd edition:

The Rational Unified Process is a specific and detailed instance of a more generic process described in the textbook The Unified Software Development Process.

--GFLewis 21:35, 30 July 2006 (UTC)

While I havn't got access to all the references above, I am about 1/4 of the way through Applying UML and Patterns, 3rd edition also by Larman which takes a similar viewpoint. On the basis of the above and my current reading I'd like to put my concern on hold, and will comment back when I finish.

--FredThwaites 21:52, 12 August 2006 (UTC)

Refactoring, July 2006

Proposed outline for a refactoring of this article

1. Background
2. History (No content for this yet.)
3. Phases and Milestones
   1. Inception
   2. Elaboration
   3. Construction
   4. Transition
4. Disciplines and Workflows (This section needs cleanup. It is using the old terminology.)
   1. Business Modeling Discipline (The paragraph beginning with "Organizations are becoming more dependent..." is interesting, but I am not sure what it has to do with the RUP or why Business Modeling is the only one of the disciplines that seems to require a separate justification section.)
   2. Requirements Discipline
   3. Analysis and Design Discipline
   4. Implementation Discipline
   5. Test Discipline
   6. Configuration and Change Management Discipline (No content for this yet.)
   7. Environment Discipline (No content for this yet.)
   8. Deployment Discipline
   9. Project Management Discipline (No content for this yet.)
5. Best Practices
   1. Develop software iteratively
   2. Manage requirements
   3. Use component-based architecture
   4. Visually model software
   5. Verify software quality
   6. Control changes to software
6. The Rational Unified Process Software Product (Has the RUP been absorbed into the Rational Method Composer, or is it still sold as a standalone product?)
7. Criticisms (or Limitations?)
8. See Also
   1. Refinements and Variations
      • Open Unified Process, etc.
   2. Alternative Approaches
      • Extreme Programming, etc.
   3. Related Topics
      • Software Engineering, etc.
9. References
   1. Books
   2. External Links

Other comments

• The introduction needs to make it clear that the RUP is both (a) a process framework and (b) a software product from IBM.
• The sentence "A typical project using the RUP will go through several iterations" makes no sense.
• The sentence "Dividing the project into iterations ... needs more guidance and effort than the traditional sequential approach" is neither true nor a principle of the RUP.

--GFLewis 20:40, 5 July 2006 (UTC)

---

I have taken a first cut at this, but it still needs more work.--GFLewis 03:48, 9 July 2006 (UTC)

Disciplines

I have added stubs for the two missing disciplines (Project Management and Environment). GFLewis 10:00, 11 August 2006 (UTC)

Absence of Criticisms

It seems to me that this article is quite biased in favor of RUP. There are no links to critical articles, and the limitation sections simply states that if there are some problems with RUP then it's because users didn't understand it.. —Preceding unsigned comment added by 82.54.86.48 (talk) 11:00, 14 January 2008 (UTC)

Agreed. The article reads like the RUP propaganda you encounter in the field, when someone pushes for it. Having the "party line" in the article is fine of course, but there must be organized critisism somewhere out there. Bertrand Meyer has some nasty things to say about UML, for example. JöG (talk) 09:47, 16 February 2008 (UTC)

What does Meyer's critique of the UML have to do with RUP? —Preceding unsigned comment added by 65.96.212.244 (talk) 06:38, 2 June 2009 (UTC)

Re: Absence of Criticisms

I am going to add a reference to an academic article that finds that there is a competing methodology that is superior to RUP - URDAD User:Adrianwilford (User talk:Adrianwilford) 09:25, 04 May 2008 (UTC)

Re: Absence of Criticisms

I added the Criticisms section and also renamed the "Alternative frameworks" section to "Competing frameworks and methodologies" Adrianwilford (talk) 14:09, 4 May 2008 (UTC)

IBM Rational Unified Process versus Rational Unified Process

At what point did the Rational Unified Process get relabeled the IBM Rational Unified Process? With a redirect from RUP to IBM RUP? I see that IBM has acquired a federally registered trademark on the phrase. SunSw0rd (talk) 17:25, 19 March 2008 (UTC)

When IBM bought Rational, I believe. I'm not sure of the date, if that's what you're looking for. Merenta (talk) 22:37, 27 April 2008 (UTC)

Re: Absence of Criticisms

Hi, please could I have some comment on my criticisms section, is it sufficiently objective? I mentioned the business analysis comparison because that is what I know about, I am not qualified to be a critic on the rest of RUP - please can someone else contribute here? Adrianwilford (talk) 08:08, 6 May 2008 (UTC)

---

Just ABOVE the criticisms, the sentences 'As the RUP must be customized for each project by a RUP process expert, the project's overall success is highly dependent on the abilities of this one person.' are in my experience simply wrong. I was involved with RUP as a company that sold it for Rational in around 1998, and in a couple of methods and process for several years before that.

1. RUP could be used as is. It did not need to be customised at all. However for newcomers to any process, it was advised to simplify it if this was expedient rather than get everyone lost in a large comprehensive process. There is a fundamental difference between advising to tune it in that circumstance and dictating that it MUST be customised. The emphasis was on using as much as you can and as much as you find useful, if all of it seemd too much at once. Generally the more used and more the gain. Furthermore refining the process in an ongoing way was encouraged as a standard 'Best Practice' for any manufacturing operation, including software. This is not a limitation, its a Best Practice of any enterprise seeming to adopt Quality practices. ... (Updated .. rather than me bleat on, I have found and grabbed the relevant bit from the Rationa Edge article 'What Is the Rational Unified Process?' by Philippe Kruchten re RUP "It is general and comprehensive enough to be used "as is," i.e., out-of-the-box, by many small-to-medium software development organizations, especially those that do not have a very strong process culture. But the adopting organization can also modify, adjust, and expand the Rational Unified Process to accommodate the specific needs, characteristics, constraints, and history of its organization, culture, and domain.".)

2. The Process Engineer (who customises the process) was a 'worker', now 'role'. There has never been any dictate that this must be one person. In fact role sharing was encouraged. The project's success is not dependent on the ability of one person in any way due to RUP. It is quite simply ignorant to make this link.

As with many processes in institutions, when people take it half on board, half understood, and apply their own old pre-conceptions and bureaucracies to the process, they end up reading into it things that are not there at all. This has happened in this wikipedia article.

I suggest people go back the read what IS in RUP, and also understand that no one individual, including those involved in writing books or even helping develop RUP, are sole arbiters of what is RUP. It was a highly collaborative effort involving many people dicussing best practices in a moving landscape 9software development) over a period of time. This landscape moved rapidly as RUP initially was being developed, due to the commercialisation of object-oriented and then web development. RUP is designed to change, and has morphed and branched into many variants that share the 'UP' part of the RUP name.

Finally, regarding the Criticisms section: 'Wolfgang Hesse is a vocal critic of RUP, one of his most famous papers on the subject is "Dinosaur Meets Archaeopteryx?' I have never heard of Wolfgang Hess, and to say his paper is famous is highly subjective. I am not trying to belittle him, but I for one have not heard of it. What makes it 'famous'? - an exaggeration surely.

'Common criticisms of RUP include:' Common? I think not. Some people's, perhaps.

'it is very costly to implement'. Actually in a world where 85% of software project fail, the cost is probably in NOT implementing either it or ANY other reasonably sane method/process. That is my opinion, but many (probably most) experienced people I used to speak to agreed with me. Adopting RUP, or any process SAVES money, ie it has a positive ROI. Most institutions fail to take processes on board properly or at all, and most of their projects fail. Do you see any connection? I certainly do.

- DavidTangye (talk) 05:29, 5 December 2008 (UTC) (Sorry to have edited this several times)

Wikification

I started wikifying this article. I hope to establish more of an overview and less of a series of listings, which I think are far to much details. Such a thing could maybe fit as on Wikibooks, but here it is more important to give a poverfull overview. -- Marcel Douwe Dekker (talk) 13:54, 10 October 2008 (UTC)

Linkfarm removed

I removed the following list of external links, which aren;t acceptabel in Wikipedia articles. If a link has some thing notable to contribute to the article, it should be intergrated in the article itself and added as a reference. -- Marcel Douwe Dekker (talk) 13:27, 5 December 2008 (UTC)

• RUP Word document templates
• Information from developerWorks on Rational Method Composer and Rational Unified Process
• IBM Rational Method Composer Web Site.
• 8rmckit Rational Method Composer Migration Kit
• Free trial: Trial: Rational Method Composer V7.1
• IBM Rational Method Composer (RMC) 7.1 Plug-ins.
• What Is the Rational Unified Process - The Rational Edge, Jan 2001. (pdf)
• Key principles for business-driven development - The Rational Edge, Oct 2005.
• Implementing RUP/UP in 10 Easy Steps (doc).
• Understanding the Unified Process.
• Introducing IBM Rational Method Composer - The Rational Edge, Nov 2005.
• IBM Rational Method Composer: Part 1: Key concepts - The Rational Edge, Dec 2005.
• IBM Rational Method Composer: Part 2: Authoring method content and processes - The Rational Edge, Jan 2006.
• The IBM Rational Unified Process for COTS-based projects: An introduction - The Rational Edge, Aug 2005.
• The Eclipse Process Framework project - The Rational Edge, 2005.
• Eclipse Process Framework (EPF) Web site.
• Iterative Development and The Leaning Tower of Pisa - From The Trench
• A good introduction to RUP
• Transfer UML diagrams from IBM Rational Software Architect to IBM Rational ClearQuest Designer's states

---

Why? I think some of these links are perfectly fine, and some even very beneficial. I think they should be at least kept in the External Links section. — Preceding unsigned comment added by 123.136.106.34 (talk) 15:22, 29 April 2012 (UTC)

Excessive inline bylines

I submitted an edit that was reverted. I rv'd it since I feel it was perfectly valid and am opening a discussion here. In a few places this article has a pattern of providing inline credit for process creation of other processes; e.g. the topic of my above edit, plus ""Objectory Process"...by Ivar Jacobson... the "Booch method" by Grady Booch... the Object-modeling technique by James Rumbaugh". I feel the bylines are unnecessary, uninformative, and distracting for readers. The reverting editor says in his rv of my edit that " The creators matter. Their biographies on Wikipedia point to related work which complements RUP." However I would argue that such material belongs in the respective process pages and including the bylines here interrupts reading flow. I would predict that no RUP article reader who is unfamiliar with one of the above alternate processes would go to (or even be interested in) the respective creator's page without first going to the already-linked-to alternate process page (where all the relevant cites belong, and which themselves link to their creators). It's unnecessary to credit the creators inline here and the average RUP article reader just isn't interested in hearing about the personalities. We don't say "Stroustrup's C++" or whatever each time C++ is linked to. Ripe (talk) 04:31, 13 January 2009 (UTC)

Agree with you in principle but not in the case you cited: IMHO, it is important, that those three names are mentioned in this particular place because of the second half sentence: "who combined forces at Rational Software Corporation in the mid 1990's, and in the process, rationalised their thinking regarding best practices for the software development process." This is important information to the history of Rational and RUP. So I would leave it in its current form Lippmj (talk) 20:09, 22 January 2009 (UTC)

Grady, Jim, and Ivar's primary focus

Grady, Jim, and Ivar's primary focus was the development of the Unified Modeling Language. While they and other individuals (Walker Royce, Dean Leffingwell) certainly contributed to the Rational Unified Process, these contributions were small in comparison to the large experience base assembled by development and field teams from Rational, Requisite, SQA, and Pure-Atria. Philippe Kruchten led the effort to create the Rational Unified Process, and led its continued development for several years. (Dave Bernstein, Rational VP Product Development, 1982 to 2003) —Preceding unsigned comment added by 65.96.212.244 (talk) 06:56, 2 June 2009 (UTC)

You seem to have removed most of the current overview section:

The Rational Unified Process resulted from a merger of the "Objectory Process" as developed by Ivar Jacobson and other methodologies including principally the "Booch method" by Grady Booch, and the Object-modeling technique by James Rumbaugh who combined forces at Rational Software Corporation in the mid 1990's, and in the process, rationalized their thinking regarding best practices for the software development process. Key considerations were the failure of projects using monolithic "waterfall" style methods and also the advent of object-oriented development and GUI technologies, a desire to elevate system modeling (especially object-oriented modeling) into the development practice, and to leverage Quality principles that applied to manufacturing in general into manufacturing software. Many previous methods influenced RUP. For instance the iterative development aspect has roots in the spiral model of Barry Boehm.

The creators and developers of the process focused on diagnosing the characteristics of different failed software projects; by doing so they tried to recognize the root causes of these failures. They also looked at the existing software engineering processes and their solutions for these symptoms.

Project failure is caused by a combination of several symptoms, though each project fails in a unique way. The outcome of their study was a system of software best practices they named the Rational Unified Process.

The Process was designed with the same techniques the team used to design software; it has an underlying object-oriented model, using Unified Modeling Language (UML).

And replaced it with:

By 1997, Rational had acquired Verdix, Objectory, Requisite, SQA, Performance Awareness, and Pure-Atria. Combining the experience base of these companies led to the articulation of six best practices for modern software engineering:

1. Develop iteratively, with risk as the primary iteration driver
2. Manage requirements
3. Employ a component-based architecture
4. Model software visually
5. Continuously verify quality
6. Control changes

These best practices both drove the development of Rational's products, and were used by Rational's field teams to help customers improve the quality and predictability of their software development efforts. To make this knowledge more accessible, Philippe Kruchten, a Rational techrep, was tasked with the assembly of an explicit process framework for modern software engineering. This effort employed the HTML-based process delivery mechanism developed by Objectory. The resulting "Rational Unified Process" (RUP) completed a strategic tripod for Rational:

• a tailorable process that guided development
• tools that automated the application of that process
• services that accelerated adoption of both the process and the tools.

Now you seem to be a real authority in the field of RUP. But if you refocuss an articles introduction like this, I automatically take a close look. It made me wonder a couple of things:

1. Is there no relation between UML and RUP?
2. Were there no input by the three amigos in RUP, and other notable people?
3. Are there any reliable sources to back this new version up?

There are some other more Wikipedia related questions as well.

• I just merged the Six Best Practices wikipedia articles here, which was proposed ha;f a year ago, and now those 6 principles are explained twice. I think we could remove the first listing here.
• The first section hardly gives an overview of RUP, but more a historical sketch. We should rename the "overview" section to "history".
• More historical facts can be add here, and a new overview section could be considered.
• This new section should be related to some kind of reliable source, see Wikipedia:Reliable sources.

I will make some changes myself soon, if there is no respons. -- Marcel Douwe Dekker (talk) 12:09, 2 June 2009 (UTC)

On the relationship of UML and RUP

1. One of the six best practices at the core of RUP is to establish a component-based (modular) architecture. Another of the six best practices is to visually model an application's architecture; the UML was developed in support of this best practice.

2. RUP itself can be unambiguously described using the UML, enabling automation.

The best practices underlying RUP were developed over many years at Rational Software and the companies it acquired. Grady, Jim, and Ivar were certainly significant contributors, but not primary authors. Other notable contributors include Phillipe Kruchten, Phil Levy, Jim Archer, Rich Reitman, Mike Devlin, Dave Stevenson, Jon Hopkins, Walker Royce, Dean Leffingwell, Joe Marasco, Jurt Bittner, Per Kroll, Maria Ericsson, Magnus Chistersson, Stefan Bylund, Hakan Dyrhage, Jas Madhur, and Bruce Katz.

I led Rational's Object-Oriented Business Unit during the development of Rose and the UML, and led Rational's Product Group during the development of RUP.

     Dave Bernstein Dave (talk) 09:09, 19 June 2009 (UTC)

Explanations to the Six Best Practices

I am currently doing a paper in which I conduct research on RUP. I have found that the description for the six best practices in this wikipedia article is not accurate when cross-checked with the IBM Best practices white paper Page 4 ( http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf )

The descriptions in this article are very minimal, and slightly inaccurate compared to what is in the whitepaper (page 4).

I am no expert on writing for Wikipedia, but I do hope that one of the authors/moderators here will take the time and necessary effort to increase the quality of this article.

Thank you. — Preceding unsigned comment added by 123.136.106.34 (talk) 15:18, 29 April 2012 (UTC)

Lack of balance and criticism

Currently this article reads without any criticism of RUP. This is hardly appropriate for a method which has clearly been controversial and which has been attracted plenty of criticism. Whether that criticism is valid or not is something that should be dealt with by showing, using clear references, counter arguments or that the critics lack the evidence which would make their criticisms valid. Even the link with widespread use UML, a widely excoriated modelling technology, is something that has been widely made and so if the supporters of RUP want to disown it they should show clear evidence of separation between the method and the technology that was widely used in conjunction with it.

There was a criticism section, commented out in this edit if nobody is willing to write a further, more accurate criticism statement then I would propose reinstating that and only accepting edits which improve it or add alternative with links to references showing that the new material is more accurate or more notable. N.B. just because material is imperfect is not a justification for removing it if not providing something better. StacksofHoy (talk) 13:23, 22 October 2017 (UTC)

Evidence of Prevalence

Is there any evidence out there for the prevalence of formal software processes like RUP? I ask since all of the 'Further Reading' texts are from at least 10 years ago. Are there no more up-to-date works about it? Jtaylor100 (talk) 15:00, 6 July 2018 (UTC)