Hmmm ... I think you can do both.  I used OOSE (from the book, the cut down version of Objectory (prior to it becoming the Rational Process)) in a project ... but it was just me and a bright newbie almost right out of college, with someone added for a last feature.<p>It worked <i>fantastically</i> well, e.g. I had to stop working on the project for a few weeks to attend to the prototype (that I'd hacked up in in a 6 week burnout), and when I came back the newbie had neatly iterated the design and was able to slip right back into coding with no fuss.  By the end of the project my estimates for how long to finish a unit of work were accurate to 30 minutes (by then I'd been programming for two decades, so it wasn't all the process!).<p>On the other hand, I wonder if Objectory/OOSE/Rational Process solves the wrong problem.  If you're going to use imperative OO to build a big complex system, yea ... but maybe you should try e.g. functional programming.  I.e. the other relevant development that came out of Ericsson was Erlang and was for the same problem space (e.g. telephone switches).<p>Still, I feel that if you use parts of it correctly for the right sorts of problems (especially ones that are pretty well understood, e.g. I'd been figuring out for 5 years how to do my project correctly before I had a chance to do it as detailed above) it can be very useful.