📄 rationalunifiedprocess.html
字号:
<head><title>Rational Unified Process</title></head><body><h1><img src="logo.gif"> Rational Unified Process</h1>The methodology formerly known as Objectory (MFKAO). See <a href="http://www.rational.com/products/rup/prodinfo/whitepapers/dynamic.jtmpl?doc_key=100420">http://www.rational.com/products/rup/prodinfo/whitepapers/dynamic.jtmpl?doc_key=100420</a> <em><a href="http://c2.com/cgi/wiki?BrokenLink">BrokenLink</a> - is this the correct one: <a href="http://www.rational.com/products/rup/whitepapers.jsp">http://www.rational.com/products/rup/whitepapers.jsp</a> ?</em>
<hr>
Which explains it weightiness. -- <a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<p>There's an introductory book on it by Phillipe Kruchten <a href="http://www.amazon.com/exec/obidos/ISBN=0201604590/portlandpatternrA/">ISBN 0201604590</a> . It's a nice overview book, but RUP is certainly aimed at heavyness. --<a href="http://c2.com/cgi/wiki?MartinFowler">MartinFowler</a>
<p><DL><dt> <dd><strong>Q:</strong> If I'm going to read one book on RUP, should I read this one? I'd assumed I'd go to the source (Jacobson), but perhaps this is unwise. I ask because it is rumored that my company will be adopting RUP.
<dt> <dd><strong>A:</strong> Yes, this is a good book to start with. It is an overview similar in scope to <a href="http://c2.com/cgi/wiki?ExtremeProgrammingExplained">ExtremeProgrammingExplained</a>. If you're looking for <em>details</em> however, go straight to the source (Jacobson).
<p></DL>Any opinions on the usefulness of <a href="RationalUnifiedProcess.html">RationalUnifiedProcess</a>? It seems to be rather much documentation to produce in every iteration. Is it useful even for large projects or will creativeness suffer? -- <a href="http://c2.com/cgi/wiki?FredrikRubensson">FredrikRubensson</a>
<hr>
I have the book, and flipped through it (i.e., did not read carefully and critically. I actually thought they did a good job at writing. As the XP people have noticed by now, and Ron commented on <a href="http://c2.com/cgi/wiki?CrystalClear">CrystalClear</a>, any methodology looks awfully large when you try to write it down in any amount of detail. So what I found were fairly reasonable discussions of requirements changing, use of prototypes, etc. ... I say that, but then I have been accused of not reading books with enough of a critical eye...
<p>Regarding documentation, every methodology I have ever seen - with the specific exceptions of XP and <a href="http://c2.com/cgi/wiki?CrystalClear">CrystalClear</a>, advises more documentation to be done than any successful project team I have interviewed has been able to do. I did meet a person whose project was cancelled because they were actually made to produce all that documentation. Mostly I meet teams who are told to produce all that documentation, and simply produce a percentage, and the project managers are content, because they get the software they need in a tolerable time frame, with at least a little documentation. --<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<p>Perhaps the project manager should make a tiny subset of the documentation mandatory? I feel documents like <a href="http://c2.com/cgi/wiki?RequirementsSpecification">RequirementsSpecification</a> including <a href="http://c2.com/cgi/wiki?UseCases">UseCases</a>, ArchitecturalOverview<a href="http://c2.com/cgi/wiki?edit=ArchitecturalOverview">?</a>, CodeComments<a href="http://c2.com/cgi/wiki?edit=CodeComments">?</a>, TestPlan<a href="http://c2.com/cgi/wiki?edit=TestPlan">?</a> and ProjectEvaluation<a href="http://c2.com/cgi/wiki?edit=ProjectEvaluation">?</a> should be mandatory. (Somewhat depending on the development context. Speculative software are less likely to need a detailed specification than internal software written to do a specific task. -- <a href="http://c2.com/cgi/wiki?FredrikRubensson">FredrikRubensson</a>
<p><hr>
In the company I work with, we've been using RUP for some time with great success. They key thing about RUP is that you don't take it wholesale and produce every artifact that it defines. You start with a Development Case that defines what you think will be useful to your project. To me this fits well with the philosphy of XP - keeep it simple, only do what needs to be done, etc.
<p>The problem I see with XP is that it is too developer centric, it sees the primary focus of a project as the developers. I believe this is a dangerous attitude to have, since the primary focus of a system must be the customer/user.
<p>Much of what is in XP is in RUP, I see it as a light weight extension of RUP focused on the construction phase - though the user stories focus on requirements. -- Alastair Thomson
<p>Why do you say XP focuses on developers? It strikes me as one of the most customer-focused methodologies I know of. It's certainly the only one I'm aware of that 'mandates' an <a href="OnsiteCustomer.html">OnsiteCustomer</a> -- <a href="http://c2.com/cgi/wiki?JohnBrewer">JohnBrewer</a>
<hr>
<em>They key thing about RUP is that you don't take it wholesale and produce every artifact that it defines.</em>
<p>It now seems fairly clear that RUP can be configured into something like XP if you need to be seen to do RUP. -- <a href="http://c2.com/cgi/wiki?KeithBraithwaite">KeithBraithwaite</a>
<hr>
Reading the Rational RUP Whitepaper, I got very frustrated. It seems like in RUP, the Construction Phase (aka Coding) is supposed to be boring and mechanical. This sounds like a very thoughtless evaluation. From the whitepaper:
<p><em>It is easy to argue that the elaboration phase is the most critcal of the four phases. At the end of this phase, the hard "engineering" is considered complete and the project undergoes it's most important day of reckoning....</em>
<p>Stupid me, I thought the most critical part of a project was whether it delivered its required functionality or not. Here is more:
<p><em>The construction phase is, in one sense, a manufacturing process where emphasis is placed on managing resources and controlling operation to optimize costs, schedules and quality.</em>
<p>I thought <a href="http://c2.com/cgi/wiki?TayloristManagement">TayloristManagement</a> principles were proven to not work well in software construction (or most other activities, for that matter). It seems like the RUP view of the construction phase is that it should be boring, mechanical and mainly handled by drones. Aren't they dragging the ConstructionMetaphor<a href="http://c2.com/cgi/wiki?edit=ConstructionMetaphor">?</a> too far?
<p>On another note, has anyone studied the possible connection between techniques that are perceived as boring and techniques that resist adoption? Sorry about the steam; a bit of built up tension there. -- <a href="http://c2.com/cgi/wiki?JohannesBrodwall">JohannesBrodwall</a>
<p>It does seem as if techniques that are boring for developers are much easier to get accepted by management. Or is that not what you were asking about...
<p>RUP does seem to carry forward the idea of "seamlessness" that was built into OMT and such: The idea that requirements can merge into design into code in a very uniform way. More recent DocumentTransformationTheoryOfSoftwareEngineeringy<a href="http://c2.com/cgi/wiki?edit=DocumentTransformationTheoryOfSoftwareEngineeringy">?</a> methods (e.g. <a href="http://c2.com/cgi/wiki?CatalysisMethodology">CatalysisMethodology</a>) have rejected this for a much more subtle idea of seamlessness. The old notion resonates well with a <a href="http://c2.com/cgi/wiki?TayloristManagement">TayloristManagement</a> ("software factory") mindset. Of course, <em>we</em> all know that the software factory is the compiler and CD burner.
<p>XP is trivially seamless, as all the deliverables are code. -- <a href="http://c2.com/cgi/wiki?KeithBraithwaite">KeithBraithwaite</a>
<p><hr>
I've read the book. Does everyone agree it's just another heavyweight process? Why bother when we have <a href="ExtremeProgramming.html">ExtremeProgramming</a>? -- <a href="http://c2.com/cgi/wiki?SamGentile">SamGentile</a>
<p>It is claimed, by <a href="http://c2.com/cgi/wiki?UncleBob">UncleBob</a>, most notably, that RUP doesn't have to be heavy weight at all. This suggests to me that Bob has a much deeper and more GnomicUnderstanding<a href="http://c2.com/cgi/wiki?edit=GnomicUnderstanding">?</a> of RUP and how it is meant to be used than anyone I've ever seen try to use it. The real joy of RUP is that it is, like Objectory before it, a <em>proprietary methodology</em>. The book mentioned above just scratches the surface. For the full deal, you have to buy the CD. Think about that, a <em>whole CD</em> devoted to this one method. -- Keith
<p>Right. That's scary! Reminds me of DOD Std 2169! -- <a href="http://c2.com/cgi/wiki?SamGentile">SamGentile</a>
<p><hr>
<p>Sure, the RUP is weighty and complex (sophisticated?), but my experience with using it on two major projects is that if you ask anybody on the project team if they could simplify the part of the RUP they will be working with, they will typically object that it can't be done.
<p>This reflects the by-now widely understood truth that modern software development has become quite difficult and complex. You have to juggle a lot of balls at the same time to make sure every component of a system can do all the things expected of it these days. To paraphrase a great thinker, you can only make your development processes as simple as possible, but no simpler.
<p>Expectations for new systems are now very high in general but software development projects are especially being pressured by increasing amounts of COTS and legacy integration requirements resulting an explosion of one of the trickiest software problems: Excessive system dependencies and logistical management issues. In addition, new software systems now have to scale up to the Internet and as a result are expected to exhibit 24/7 reliability right out of the gate. This is further exacerbated by the expectations people now have after years of coming into frequent contact with good examples of high-quality software systems. These influences ensure that software projects are far more complex (and difficult) than in previous years while the techniques and processes for managing the difficulty and complexity are falling behind. Most current lightweight development methods (read: informal programming techniques) just can't coherently address and manage these issues with reasonable time/cost curves.
<p>If you invest the resources, the RUP (or any well-defined and documented structuring of your development activities) will actually help to mitigate these challenges instead of just helping you tread water. The problems are classic though: The learning curve and finding talented people willing to learn and work together using a common plan. And, XP is not so different based on my one attempt to use it on a non-trivial project. Either way, there's lots to learn, and so little time and few good people. -- <a href="http://c2.com/cgi/wiki?DionHinchcliffe">DionHinchcliffe</a>
<p><hr>
<p><DL><dt> <dd><strong>Q:</strong> So with the online support, the CD, and the books, what's the full price-tag of RUP?
<dt> <dd><strong>A:</strong> ...
<p></DL><hr>
See Also: <a href="ExtremeUnifiedProcess.html">ExtremeUnifiedProcess</a> <a href="http://c2.com/cgi/wiki?RationalCompany">RationalCompany</a>
<p><a href="http://c2.com/cgi/wiki?CategoryMethodology">CategoryMethodology</a><hr><a href="http://c2.com/cgi/wiki?edit=RationalUnifiedProcess">EditText</a> of this page (last edited February 21, 2001)<br><a href="http://c2.com/cgi/wiki?FindPage&value=RationalUnifiedProcess">FindPage</a> by browsing or searching<p><font color=gray size=-1>This page mirrored in <a href="index.html">ExtremeProgrammingRoadmap</a> as of March 31, 2001</font></body>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -