Does anyone have experience with RequisitePro or other aspects of RUP?

February 1, 2005 8:52 AM

Does anyone have experience with RequisitePro or other aspects of RUP? We're considering getting it here and I would be the guinea pig that gets the training and etc. Good idea or bad? Any experiences you could relate?
posted by Red58 to computers & internet (5 comments total)

This may be a good place to start.
posted by voon_42 at 9:37 AM on February 1, 2005

My biased opinion is that RUP's primary goal is not producing good software. RUP is all about accountability and communication. It's intended for large projects with a lot of people and inherent complexity, or situations where it's absolutely necessary to be able to document and track every decision on the project.

The biggest problems I've seen with RUP projects are when teams adopt a kind of "cargo cult" mentality that follows all of the process no matter what. The process becomes more important than the software it creates, and people spend more time and energy figuring out how to dothings in the right way than they do actually fixing problems.

One project I worked on spent a huge amount of money on high-priced RUP consultants. The project ground to a halt when every bug turned into confusion about whether the solution was to send it to the analysts, the designers, or the coders. Tracking changes through the process took more effort than making them. They solved the problem by instituting a short meeting of the whole team every day to focus on actually fixing problems. They did the meeting standing up, so that no one had any incentive to ramble on. The RUP consultants grumbled, but the software shipped on time.

Having said that, there are a lot of things in RUP that can help you produce good software if you use them right. The key is to adopt the parts of RUP that solve real problems that you're already having. For example, any type of requirements document is better than none, and so Requisite Pro is a good thing if you've been having problems understanding what your requirements are and how they connect with what you're actually building.

So take a skeptical view on RUP, try to find the parts of it that can actually help you, and adopt them progressively to see if they actually work on your project.

(On Preview: voon_42 links to an article that pretty much nails it. Read it carefully. Send it to your manager.)
posted by fuzz at 9:51 AM on February 1, 2005

Echoing the skepticism, it's the process, not the tools. I worked in a place where they bought into the tools, but couldn't really bring themselves to adopt the process, and ended up with the worst of both worlds: waterfall-style development with insufficient documentation. And a big bill from Rational.

Conversely, you could get a lot of bang for your buck from changing your processes without any software tools at all.

Make sure that there isn't someone hoping the tools will do all the work.

Realise that you're proposing huge change and that it takes a couple of years at least to bed in big changes to development practise.
posted by i_am_joe's_spleen at 10:48 AM on February 1, 2005

Oh boy. Your question is too vague to be easy to answer. RUP is a daunting prospect to those who haven't met it before, because it attempts to manage the entirety of any peceivable software project. It's possible and desirable, if you're new to it, to cherry pick. It's also theoretically possible to apply the RUP methodology without spending a dime with IBM/Rational. The tools are just that, tools.

I'd suggest taking a step back and ask what problem, specifically, you're trying to solve. What's the biggest weakness in your current methodology? Concentrate on that. If you can't clearly and concisely explain what you want to achieve in a simple paragraph, buying into a system like RUP isn't going to help.

Read up on the RUP process and especially UML and decide if it fits, before commiting to particular tools. If your organization doesn't unanimously buy into an implementation plan and a development strategy, you're doomed.

It's perfectly possible to cherry-pick at RUP and the associated tools to refine your process as your organization evolves. The mistake most often made is when organizations take it as gospel, don't think hard enough about the context in which their applying it (their own particular organizational challenges) and whither in analysis paralysis. Rational/IBM don't emphasise selective application however, because they want to sell licenses for the entire tool suite.

And it has to be said that the tools do vary in their overall quality. The summer I spent in front of Test Manager was one of the most frustatrating in my career, but if you've the budget, Clearquest might be the best bug management system in the known universe. Requisite Pro is fussy and dense, but powerful in expert hands and if sufficient resources are devoted to it. Rose is their most popular tool for a reason, it works.

Finally, it's rumored Microsoft are seriously eyeing the development frameworks and CASE tools market. It's an area they've been conspicuously absent from until now. They've been exposing sympathetic audiences to early beta versions of some of their stuff. If you're not in a hurry, you might want to see what they're offering in a year or two.

sorry, it's late, rambling a bit here...
posted by normy at 4:12 AM on February 2, 2005

Agree with everything that's been said here. RUP is a great methodology and you don't need to adopt the whole shebang to get started. For instance, I worked on a pilot project for implementing RUP and the Rational tools into my workplace. After much thought and discussion, we limited the scope of the pilot to 2 disciplines as identified by Rational (Analysis and Design, and Project Management). and a handful of artifacts (Use Case Diagrams, Use Case Spedifications, Vision Document and a few others).

As for ReqPro: It's an interesting tool, but sometimes there is just too many bells and whistles. I went from tagging requirements in the use case documents, to using ReqPro to save the use case documents only, to not using ReqPro but still using the Rational Use Case template. We tend to use Rational Rose primarily now and ReqPro gathers dust.
posted by smcniven at 6:57 AM on February 2, 2005