The RationalUnifiedProcess seems to promote activities that ''look like'' they add value, but don't. 
----
Consider this, seen in a genuine production model:

(picture in due time)
A diagram with a text note "This diagram shows the Use Case, the Use Case Realization and the trace dependency between them", and indeed it does. There's an ellipse labeled "Foo", another ellipse labeled "Use Case Realization - Foo" and an arrow between them, labeled "<<trace>>".

There are dozens of diagrams like this in the model. 

Someone was able to:
	* produce these diagrams and claim to have done "work"
	* extract money from a client in order to do the above
----
I would be ashamed, ''ashamed'', to do either of those two things.
----
See also TheIllusionOfSoftwareEngineering
----
''(picture in due time) A diagram with a text note "This diagram shows the Use Case, the Use Case Realization and the trace dependency between them", and indeed it does. There's an ellipse labeled "Foo", and another ellipse labeled "Use Case Realization - Foo" and an arrow between them, labeled "<<trace>>".''

Well it's actually worse than that: this is the _recommended_ way to implement Use Case Realization traceability using RationalRose. When I read that, in the RUP manual that ships with the Rational Suite, I thought: They must be kidding!
They weren't. -- ErnestoGuisado

''The problem is that many people in the industry really believe this is the proper way to do software.''

-- sg

----
To me the analysis methodology has some meshing issues. The first iteration entailed modeling all kinds of subsystem communications which I feel would be better off loosely coupled.

----
See also ConsideredHarmful, GotoConsideredHarmful, GotoStillConsideredHarmful,
and Dilbert on ISO 9000 (1995: Sept 25, 26, 27, and Nov 7),
http://www.franken.de/users/bike/lan/dil_Iso9000.html