wood burning stoves 2.0*
The moose likes Agile and Other Processes and the fly likes RUP Versus RAD!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "RUP Versus RAD!!" Watch "RUP Versus RAD!!" New topic
Author

RUP Versus RAD!!

vijaya bacina
Ranch Hand

Joined: Aug 23, 2005
Posts: 155
Hi can anybody tell me the difference between RAD and RUP?? and usefull links?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
For a pretty good overview of RUP, you could try the Wikipedia description. They also have a page on Rapid Application Development.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
RUP is notoriously hard to nail down. An important activity in RUP is customizing the process by choosing which parts to use and which to ignore. It's so flexible that it can wind up being reasonably compatible with just about any other popular method you can come up with.

I haven't heard much about RAD as described on the Wikipedia for a long time. Except I just filled out a "skills self assessment" at work and it asked how good I thought I was at RAD. Sheesh, not very, thank you.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30136
    
150

I agree with Lasse that RAD is Rapid Application Development in the context of process. In the context of IBM, Rational it is Rational Application Developer (the IDE10). Should lead to some nice confusion!


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
You might find The Agile Unified Process (AUP) to be an interesting instantiation of the RUP.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
vijaya bacina
Ranch Hand

Joined: Aug 23, 2005
Posts: 155
Thanks to all
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3703
    
    5

Originally posted by Scott Ambler:
You might find The Agile Unified Process (AUP) to be an interesting instantiation of the RUP.

I've done the agile process before. It some ways I like it, in other ways I don't. I find that what it really does is encourage team members to be proactive, ergo if you have a team that is all ready proactive its not really neccessary and can be burdensome. Alternatively, if you have a team that only does the bare minimum and never really looks ahead or considers the consequences of their actions, then its a winner.

I've seen that for some people its an enlightening experience that forces them to become more proactive then they were before, others, I feel it just gives them another way to seem productive without being so.


My Blog: Down Home Country Coding with Scott Selikoff
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Scott Selikoff:
if you have a team that is already proactive [an agile process] is not really neccessary and can be burdensome.

How so? I'd be interested in hearing more.

Originally posted by Scott Selikoff:
Alternatively, if you have a team that only does the bare minimum and never really looks ahead or considers the consequences of their actions, then [an agile process] is a winner.

Really? I'd say that with that kind of a team, any process is a loser...

Originally posted by Scott Selikoff:
others, I feel [an agile process] just gives them another way to seem productive without being so.

Would you like to tell us more about how these people seem more productive without being so?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Scott Selikoff:
I've done the agile process before.


Mhh, as there is not one Agile process, but a whole family of processes that simply more or less share a common value system, I wonder what you are talking about. What process exactly did you use?

I find that what it really does is encourage team members to be proactive, ergo if you have a team that is all ready proactive its not really neccessary and can be burdensome.


Every team has a process. An already proactive team might well use its own incarnation of an Agile process, without even knowing. So, like Lasse, I'm not sure how "burdensome" enters the picture.


I've seen that for some people its an enlightening experience that forces them to become more proactive then they were before, others, I feel it just gives them another way to seem productive without being so.


As Agile processes inherently measure progress by delivering running tested software every couple of weeks, I'm not sure how one could seem productive without being so...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3703
    
    5

Since there's was multiple feedback requested, here's some of my stories. I believe we used Agile with Scrum to be specific. I think the tagline from the Scrum website is "It's About Common Sense". The difficulty with common sense is that its not all that common.

The first example of Agile being negative: This is partially related to management who took the notion that there should be daily 10 minute check up meetings to mean that we should have 30-60 minute 8am meetings every single day. The whole concept of the meetings was short, brief, and really only as required. Coming in an hour early to sit around while people talked for up to an hour didn't really increase my productivity. The meetings are really only to encourage people who waits weeks at a time to report problems to others to come forward quicker and get help. If you spend a good amount of time walking to people's desks and handling problems as they come, the meetings aren't as important.

Second example: A lot of feedback I heard from people was "Wow, this works so great, I would have never found out the results of my actions [...] until much later on". In the waterfall model, what we were transitioning from, there's an emphasis on one-piece at a time and people don't tend to consider future actions. Agile forces them to see and consider future actions quicker because of the short iterations. To some, especially those teams that are really bad about never looking ahead, this can be an enlightening experience that they never would have considered before.

And the last example... I've seen people waste *hours* discussing Agile philosophies pretending as if they were getting work done... no make that *days*. On top of that, since we had a daily status meeting, the goal seemed to be who could check off the most things faster which resulted in people inventing tasks for themselves during planning then solving them over the course of weeks. This one you can't really get around, some people are determined to do nothing and finding such individuals can be a daunting task.

Oh and one note, we implemented Agile in proof of concept scenario without having customers or requirements analysts... so the concept of producing 'deliverables' every few weeks was seriously open to interpretation and lead to days/weeks wasted discussing what proper testing is at which point the result was "well do every possible level of testing, unit/system/whitebox/blockbox/etc".
[ January 06, 2006: Message edited by: Scott Selikoff ]
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
The examples you brought up shouldn't be attributed to agile software development, but instead to the organization where you were working.

- Scott
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3703
    
    5

Perhaps, although I merely bring them up to point out that agile is not fool-proof, as in any methodology. I'm sure there are companies out there who've adopted agile that have done far worse, despite the credos of the philosophy.

On the plus side, the story about people suddenly considering their future actions is, I believe, a positive one. Although you can tell people to plan ahead and that what they do has future impact on everyone else, without showing them ways of understanding/overcoming this, they are left to do things their own way, such as: "You mean I don't have to wait months to realize the specification I was designing was inherently wrong for our customers?". These are definitely good and money saving realizations.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Scott Selikoff:
Perhaps, although I merely bring them up to point out that agile is not fool-proof, as in any methodology. I'm sure there are companies out there who've adopted agile that have done far worse, despite the credos of the philosophy.


In my opinion the crux is that adopting the *practices* isn't what makes you Agile - adopting the *value system* is. The practices only teach you a way to implement the value system *iff* you care about the values.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Scott Selikoff:
The first example of Agile being negative: This is partially related to management who took the notion that there should be daily 10 minute check up meetings to mean that we should have 30-60 minute 8am meetings every single day. The whole concept of the meetings was short, brief, and really only as required. Coming in an hour early to sit around while people talked for up to an hour didn't really increase my productivity.


I can imagine that. But the Daily Scrum is meant to be a *Stand Up* Meeting (not a "Sit Down") - for a reason.

The meetings are really only to encourage people who waits weeks at a time to report problems to others to come forward quicker and get help. If you spend a good amount of time walking to people's desks and handling problems as they come, the meetings aren't as important.


Mhh, we do have all developers sitting in one room and pair program regularly - and still the daily stand ups seem to have value. But they never last longer than ten minutes...

I've seen people waste *hours* discussing Agile philosophies pretending as if they were getting work done... no make that *days*.


Seems like a coach might have been a good idea...

Oh and one note, we implemented Agile in proof of concept scenario without having customers or requirements analysts...


I'm don't understand why a proof of concept wouldn't have a customer...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RUP Versus RAD!!
 
Similar Threads
Effectiveness of RUP in RAD projects URGENT
What is DRUP ??
what is the most used process
SCJP
Does Agile and RAD follow same SDLC?