aspose file tools*
The moose likes Agile and Other Processes and the fly likes  XP vs RUP questions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark " XP vs RUP questions" Watch " XP vs RUP questions" New topic
Author

XP vs RUP questions

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

1. Are there phases in XP like we have it in RUP( Requirements, Analysis). If yes, what are they? Are they same as in RUP.

2. XP is said to be light weight process because it requires less documentation. So, I want to know what are the documents that are required in RUP but not in XP.

3. RUP is an iterative process and XP an evolutionary process. What is the difference between iterative and evolutionary process. Isn't there a feedback in RUP as well.

Thanks.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Pradeep Bhat:
Are there phases in XP like we have it in RUP( Requirements, Analysis). If yes, what are they? Are they same as in RUP.


Requirements and Analysis aren't phases in RUP, they are workflows that are present in all the four phases of RUP: http://www.delphidevelopers.com/engineering/process/rup/rup_phases.JPG

XP has an Exploration Phase of up to two weeks, which matches roughly the Inception phase of RUP - the goal is to get a feel of the scope of the project and decide wether it's feasible.

Elaboration and Construction are more intermingled in XP: Let more of the design evolve instead of deciding about it early, be open to changing feature requests late in the project, start testing and deployment early.

Because of the early and frequent releases an XP team strives for, a RUP-like transition phase doesn't make much sense to me. The Customer might want the team to produce some high level documentation before it dissolves, though.

XP is said to be light weight process because it requires less documentation. So, I want to know what are the documents that are required in RUP but not in XP.


I'm no RUP expert, but as far as I know RUP, as a process *framework*, doesn't actually require anything. It's just that it suggests so many artifacts that most teams seem to end up producing tons of detailed use cases, UML diagrams, test plans etc. pp.

RUP says "you might need A, and perhaps B, possibly C, D might be a good idea, E sometimes is quite valuable, etc. pp."

XP says "you are quite save if you start with X. Figure out the rest as you go."


RUP is an iterative process and XP an evolutionary process. What is the difference between iterative and evolutionary process.


I have to think about this. As far as I know, there actually is a difference between iterative and incremental processes. Need to research that, though. (I think Alistair Cockburn has written something about it somewhere on the web...)


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
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Pradeep Bhat:
2. XP is said to be light weight process because it requires less documentation. So, I want to know what are the documents that are required in RUP but not in XP.

I'm afraid it's not that simple. RUP doesn't dictate what documents you must produce and neither does XP. They are both based on the idea that you should use common sense to figure out what documents to produce and at what stage. The problem with RUP is that people got it all wrong and started to create huge lists of required documents scattered over a pure waterfall plan, thinking that they're now following industry best practices. It didn't help that Rational's consultants tried to sell all sorts of gigantic tools to "help" the process, effectively making everything very formal and bureaucratic.

Philippe Kruchten, the father of RUP, has many times said that people got RUP all wrong and has tried to correct the misunderstanding but after doing RUP the wrong way for several years, people don't seem to be too willing to listen.

I wouldn't say XP requires less documentation. I'd say XP requires doing only those pieces of documentation that the customer is willing to pay for and those pieces which the developer believes will help him in doing his job well.

Originally posted by Pradeep Bhat:
3. RUP is an iterative process and XP an evolutionary process. What is the difference between iterative and evolutionary process. Isn't there a feedback in RUP as well.

There should be a feedback loop in RUP as well, but all too often the so-called "RUP projects" are nothing but iterative, i.e. the development team isn't really given the opportunity to improve on their work based on feedback.

In iterative development you take small steps, get feedback, and improve on the mistakes (fix the design, adjust schedule, etc.). In evolutionary development you build the whole system in small parts while keeping whatever you've got at a certain point in time fully functional. Combining the two, and turning the knobs to eleven, you've got the basic recipe for an agile development process.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Thanks Ilja and Lasse.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Well, I knew it was Cockburn - and thanks to Google I now also know that it was in this forum: http://www.coderanch.com/t/130153/Agile/Incremental-vs-Iterative


XP uses what I call "nano-increments", function add in a 15-minute to 4-hour session, tested, and then checked in. Those don't get delivered to the user, of course. The "iterations" in XP are hidden - they just happen all the time, part of business-as-usual. In most organizations, both increments and iterations are larger and need to be scheduled / managed.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Incremental -- You develop/deploy in portions.

Iterative -- You cycle between activities, doing a little bit of this then a little bit of that at a time.

What most processes refer to as iterations should really be called increments. I've traced this terminology mistake and from what I can tell it was the RUP folks that got it wrong.

As far as documentation goes, you can travel very light on RUP projects if you choose to do so. At http://www.agilemodeling.com/essays/agileModelingRUP.htm I describe how to apply Agile Modeling within a RUP environment to do exactly that. The RUP folks don't seem to talk about these ideas very much, which is unfortunate. Then again, they're also trying to convince you to by their modeling and documentation tools so it shouldn't be much of a surprise.

- 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>
dinaker prasad
Greenhorn

Joined: Oct 11, 2004
Posts: 27
Frist,
RUP is a plan driven process
where as XP is a Agile[non-plan driven] process

i think thats the biggest difference.
plan driven and agile are completelty different concepts/methodologies.

XP incorporates some[a very little] plan driven framework to achieve discipline and flexibility.

plan driven process are like CMM, CMMI, RUP , where you have anchor points or milestones which guide the project.

in Agile, it depends a lot on feed-back, so the sucess here depends upon the expertise of your architects/PM/any personal working on the project. There is a high risk involved when you are using the Agile process, but these risk are mitigated by working on feedback of expert Architect/PM/etc..


Plan driven is a highly risk driven process,


thanks
Dinaker
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Grady Booch, one of the originators of RUP, sometimes says he can live with customizing RUP to almost be XP all except for "emergent architecture". He characterizes architecture as decisions that are "expensive to change later" and prefers more of the up-front approach to that area.

I see Rational's embrace of most agile ideas as refreshingly open minded and smart marketing, but a little late. The way Rational consultants taught my team to do RUP was far from agile!


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
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
Grady Booch, one of the originators of RUP, sometimes says he can live with customizing RUP to almost be XP all except for "emergent architecture". He characterizes architecture as decisions that are "expensive to change later" and prefers more of the up-front approach to that area.


Well, then the XP answer would be that the typical project can be done in a way that there is near to zero "architecture".

I like Fowler's definition better, though: "architecture" = "the important things". XP mostly handles those by implementing the important features first (assuming that the important things are mainly important because they are vital for the important features).
[ November 02, 2004: Message edited by: Ilja Preuss ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by dinaker prasad:
RUP is a plan driven process


RUP actually is not a process, but a process framework.


plan driven and agile are completelty different concepts/methodologies.


They are on the two sides of a scale. I think a method can also be somewhere in between; and an instance of RUP probably could be far more on the Agile side than most teams seem to understand it.


XP incorporates some[a very little] plan driven framework to achieve discipline and flexibility.


XP actually is very big on planning. It's not *plan driven* at all, though - the plan is not something the reality is supposed to adhere to, but the plan is adjusted to reality regularly.

plan driven process are like CMM, CMMI, RUP , where you have anchor points or milestones which guide the project.


CMM and CMMI aren't processes at all. And as far as I know there is at least one XP team that's CMM level 3 certified.

in Agile, it depends a lot on feed-back, so the sucess here depends upon the expertise of your architects/PM/any personal working on the project.


And that's not true for non-Agile projects???

Plan driven is a highly risk driven process,


I don't think I understand that statement. Would you like to elaborate?
dinaker prasad
Greenhorn

Joined: Oct 11, 2004
Posts: 27
this is what i understand,

basically when we talk about process/frameworks,

a process can be a plan driven [plan driven means we have certain anchor points, certain ways risk assesment methodology] CMM,CMMI are frameworks where you can adopt a plan driven process with certain KPA's.
using win-win sprial or a sprial model is perfect example of plan driven

or a process can be agile.

my point is that this is the most fundamental difference.

some process hybrid[agile&plan dirven] to attain needed displine and flexibility.

when i said plan driven process are highly risk driven. i mean risk is the post important concept here. it would basically drive the project management.

i think any process, plan driven or agile can get CMM, CMMI maturity levels, but these metrics mean little to agile process.

thanks
dinaker
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Sorry to be such a cynic, but I think what draws management to plan-driven processes is a lack of trust in their people. One of the bullets in the agile manifesto is to value people over process. Know your people, know their strengths and weaknesses and let them do what they do best. Plan driven methods tend to treat AD staff as interchangeable coding drones who must be told what to do at every step. I found working that way disrespectful to me and my peers.

Some believe extensive planning is the best way to handle risk, but the agile crowd would certainly disagree. Risk can be defined as uncertainty in the plan. You can try to hammer out uncertainty by planning another week or you can hammer out uncertainty by implementing your best idea and getting some real metrics to help you adjust the plan.
dinaker prasad
Greenhorn

Joined: Oct 11, 2004
Posts: 27
Originally posted by Stan James:
[QB]Sorry to be such a cynic, but I think what draws management to plan-driven processes is a lack of trust in their people.

stan,i agree with you on your above statement but its not totally lack of trust its also because of personal shortfall. personal shortfall has always been the NUMBER 1 risk. In big organizations[like DoD etc] projects have 100-200 people working with schedule spanned over 3-5 years. For situations like these where uncertainity is very, high plan driven process suit the orgranization better.

risk management is not all about planning, its about identify things that can go wrong and fix them before its out of hand. in case of RUP, iterations are totally based on risk. you consider the highest risk items to be addressed first.

In agile process it depends more on people and their feedback on activities. The problem in agile with inexperinced people leading/architecting is their denial that risk exists.

The 5 critical decision factors [represeting 5 dimensions] that can be considered when choosing between a displined process and agile are
1.criticality
2.size
3.Personal
4.Dynamism
5.Culture

there are a couple of supply chain mangement companies who have succesfully adopted a 40%plan driven and 60% agile process. but these percentages depend up those 5 decision factors.

thanks
dinaker
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by dinaker prasad:
personal shortfall has always been the NUMBER 1 risk.


If you accept that, then the question becomes how to handle that?

There seem to be at least two common ways today:

- imposing a formalized process which replaces personal judgement, and therefore makes the only *personal* shortfalls (deviations from the process) very easy to notice, and

- complementing personal judgement with massive, rapid feedback, thereby making the effects of your decisions easy to notice.


In big organizations[like DoD etc] projects have 100-200 people working with schedule spanned over 3-5 years. For situations like these where uncertainity is very, high plan driven process suit the orgranization better.


I don't buy that.

risk management is not all about planning, its about identify things that can go wrong and fix them before its out of hand. in case of RUP, iterations are totally based on risk. you consider the highest risk items to be addressed first.


And Agile processes don't do that?

In agile process it depends more on people and their feedback on activities. The problem in agile with inexperinced people leading/architecting is their denial that risk exists.


The problem with inexperienced people using a plan driven process is that their plan will be wrong - if only *because* they are inexperienced. Therefore especially inexperienced teams need rapid feedback on how they are doing and a way to incorporate new learnings into the project. That is, they need to be highly Agile.

Another typical property of plan driven processes is that they tend to put people on roles, and to describe what those people have to do in detail - what artifacts they are supposed to produce when and how, and when they should communicate to the other team members. That gives management a sense of control (you can check wether someone is doing what he is supposed to do), and the team members a sense of safety (if you are told what to do, and it turns out that it were the wrong things, it wasn't your fault, after all).

I'm far from convinced that it is for the best of the project, though. Especially with an inexperienced team, I'd like everyone to contribute as much to anything as possible. I'd like people to help each other where they can. I'd like people to learn from each other while collaborating closely. I'd see people and their interactions to be much more important than processes and tools. That is, I'd want the team to be highly Agile.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Actually, agile is very risk driven. An agile process, such as XP or Crystal, directly addresses risks such as:
- Ensuring you understand the actual requirements
- Investing money in IT solutions effectively
- Proving that the architecture actually works

There are others, but these ones seem pretty important to me in most situations that I work in.

Before criticizing agile techniques, I highly suggest that people first do some reading and then try them in practice.

- Scott
dinaker prasad
Greenhorn

Joined: Oct 11, 2004
Posts: 27
----------------------------------------------------------------------------
Before criticizing agile techniques, I highly suggest that people first do some reading and then try them in practice.

- Scott[/QB]

----------------------------------------------------------------------------

I dont know if scott comments above is response to my posting.I just want to clarify that i was not criticizing agile techniques nor was i supporting plan-drive processes.

I was trying to make a point that process need to be differenitated as plan driven, agile or hybrid of plan-driven & agile. so if any one is looking at a process framework they need to understand these methodologies and choose the one best fitting their organizational setup and goals.

----------------------------------------------------------------------------
quote:
In big organizations[like DoD etc] projects have 100-200 people working with schedule spanned over 3-5 years. For situations like these where uncertainity is very, high plan driven process suit the orgranization better.
******************************
I don't buy that.
----------------------------------------------------------------------------

well, one of the projects i was working as research assistant which was outsourced[a small part of it] from DoD to my grad school software center was developing a dynamic architecture for their missile program. the team strength was 160 people and they been working on it for last 31/2 years.
during one of the brain storming sessions, i noticed that the strength of 160 was not even close to be being a big team.

the company i work for has team sizes of max 60-80 across various organizations.

All all of these orgranizations drive on 90%Plan-drive & 10% agile process.

thanks
Dinaker
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by dinaker prasad:
All all of these orgranizations drive on 90%Plan-drive & 10% agile process.


And you think they do this because becoming more Agile would be bad for them?
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Ilja Preuss:
Well, then the XP answer would be that the typical project can be done in a way that there is near to zero "architecture".

I like Fowler's definition better, though: "architecture" = "the important things". XP mostly handles those by implementing the important features first (assuming that the important things are mainly important because they are vital for the important features).


I prefer Booch's definition--that the architecture represents decisions that are expensive to change later, i.e. directly tying it to cost.

What's usually misunderstood, though, is that many things don't have to be expensive to change later--something you suggest in your first sentence. A solid approach to OO design (using either principles, emergent design concepts, or both) allows you to add important features late in the game with minimal additional cost.

Nonetheless, there are some things you absolutely should take the time to carefully decide up front--for example, the choice of language. In hindsight, I'm not thinking of any others that, had we had stuck to the rules, we would have had to decide up front. But in practice, I find it worthwhile to spend a small bit of up-front time instead of totally relying on emergent architecture.

Unless you have a top-notch, crack team that are absolute refactoring nazis, you will have a tough time evolving a solid architecture. I've seen too many shops that found this out the hard way.

-j-
[ November 05, 2004: Message edited by: Jeff Langr ]

Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
dinaker prasad
Greenhorn

Joined: Oct 11, 2004
Posts: 27
----------------------------------------------------------------------------
And you think they do this because becoming more Agile would be bad for them?
----------------------------------------------------------------------------

As i said in my earlier posting
The 5 critical decision factors [represeting 5 dimensions] that can be considered when choosing between a displined process, agile and a hybrid of plan-driven & agile are
1.criticality
2.size
3.Personal
4.Dynamism
5.Culture


becoming more agile or less agile depends up on the above factors.

For large size and high complexity systems, what i have noticed is they have more plan-driven activites compared to agile activities.

thanks
dinaker
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeff Langr:
I prefer Booch's definition--that the architecture represents decisions that are expensive to change later, i.e. directly tying it to cost.

[snip]

Unless you have a top-notch, crack team that are absolute refactoring nazis, you will have a tough time evolving a solid architecture. I've seen too many shops that found this out the hard way.


When you define architecture that way, it's a no-brainer to say that emerging architecture is unreasonable - your certainly shouldn't "emerge" something that's hard to change.

Another definition of the term "architecture" seems to be used in the book Agile Software Development in the Large. I haven't read it yet, but from a presentation I remember that she split up a big team into smaller subteams (quite like a "Scrum of Scrums") and did have an "architectural team" that organized code reuse between the other teams. That seems to imply a meaning of "architecture" along the lines of "the parts of the system that are used by a huge amount of the rest of the system"...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by dinaker prasad:
1.criticality


I can see that with highly critical systems you'd probably want more formal feedback than most Agile processes seem to prescribe. I don't think that has anything to do with becoming more plan-driven, though.

But perhaps you meant something different?


2.size


I'd agree in the sense that only small projects actually can be controlled to the point that executing them plan-driven makes any sense at all. For anything a little bit complex (and "big" seems to imply some complexity), it's virtually impossible to understand all the implications upfront, and therefore impossible to come up with a reasonable plan upfront. Therefore big projects need to be highly Agile.

I don't think, though, that for small projects, *not* going Agile has any advantage.


3.Personal


Not sure what you mean by this.


4.Dynamism


I guess you mean how fast you need to change directions? Well, yes, the more you need to be able to change directions quickly, the more Agile you need to be, certainly.

I don't see how being Agile if you don't really *need* to change directions quickly would be a bad idea, though.


5.Culture


With that I can agree.

For large size and high complexity systems, what i have noticed is they have more plan-driven activites compared to agile activities.


Yes, and I think that's mostly because of point 5: culture.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Ilja Preuss:
When you define architecture that way, it's a no-brainer to say that emerging architecture is unreasonable - your certainly shouldn't "emerge" something that's hard to change.


Sorry, those two sections were intended to be exclusive of each other, i.e. I was making two points. The second point was that you really have to use extreme vigilance in order for a system to emerge properly. It takes only a bit of carelessness and laziness to paint yourself into a corner, whereby you end up stuck with a bad emergent architecture (and here, I'm using a looser definition for "architecture"). In other words, I no longer trust most teams to be extreme enough to evolve things that can be evolved.

It's probably still not worded the way I want it...

-j-
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Ilja Preuss:

I like Fowler's definition better, though: "architecture" = "the important things". XP mostly handles those by implementing the important features first (assuming that the important things are mainly important because they are vital for the important features).

For many projects, I think that's a very questionable assumption.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Warren Dew:
Ilja Preuss:

I like Fowler's definition better, though: "architecture" = "the important things". XP mostly handles those by implementing the important features first (assuming that the important things are mainly important because they are vital for the important features).

For many projects, I think that's a very questionable assumption.


Example, please?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Ilja ,

Are there workflows in Xp? thanks
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Pradip Bhat:
Ilja ,

Are there workflows in Xp? thanks


You mean like in http://www.extremeprogramming.org/map/project.html ?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Originally posted by Ilja Preuss:


You mean like in http://www.extremeprogramming.org/map/project.html ?


yes.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Is it risky to use XP for larger projects ?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
XP relies heavily on constant communication which becomes harder and harder with larger teams. Some practitioners have adapted XP to larger groups with good success. Martin Fowler has published some papers on using XP with teams up into 100-150 range at Thoughtworks. With the mods for large teams I guess you could argue whether it's still XP or something new. Another option is to turn your large team into many smaller teams, though there are surely challenges in doing that, too. All in all, giant teams are not an indicator for selecting XP.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Pradip,

in the future please start a new thread for new questions. That makes it much easier to follow the discussions.

Thanks!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
Some practitioners have adapted XP to larger roups with good success. Martin Fowler has published some papers on using XP with teams up into 100-150 range at Thoughtworks. With the mods for large teams I guess you could argue whether it's still XP or something new.


You could argue that. But why would you care?

Another option is to turn your large team into many smaller teams, though there are surely challenges in doing that, too.


Isn't that what Fowler did, too?

It's a common strategy, also with other Agile methods. Google for "Scrum of Scrums", for example.

All in all, giant teams are not an indicator for selecting XP.


It's certainly and advanced skill. Well, managing giant teams is an advanced skill, anyway. Search for the works of Jutta Eckstein for how to do it in an Agile way...
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791

You could argue that. But why would you care?


I'm sure I don't. The discussions in the extremeprogramming list we both read about "what XP is" didn't do much for me. They still don't know.
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by Pradeep Bhat:

3. RUP is an iterative process and XP an evolutionary process. What is the difference between iterative and evolutionary process. Isn't there a feedback in RUP as well.


Hi Pradeep,


Incremental and Evolutionary both create a system in small increments (iterations). Therefore, both are iterative. The difference is in the Agility of the approaches. For incremental approaches you develop in iterations towards the system as it was originally designed. (Ready - Aim - Fire - Fire - Fire).

For evolutionary approaches you assess at the end of each iteration whether the system requirements have changed (normal with most end-users / projects) and readjust the next iteration towards the changed system. (Ready - Aim - Fire - Aim - Fire - Aim - Fire).

In my opinion architecture refers to what is *technically* important for the project (e.g. infrastructure) rather than important requirements.

HTH,

Fintan
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Originally posted by Fintan Conway:


Hi Pradeep,


Incremental and Evolutionary both create a system in small increments (iterations). Therefore, both are iterative. The difference is in the Agility of the approaches. For incremental approaches you develop in iterations towards the system as it was originally designed. (Ready - Aim - Fire - Fire - Fire).

For evolutionary approaches you assess at the end of each iteration whether the system requirements have changed (normal with most end-users / projects) and readjust the next iteration towards the changed system. (Ready - Aim - Fire - Aim - Fire - Aim - Fire).

In my opinion architecture refers to what is *technically* important for the project (e.g. infrastructure) rather than important requirements.

HTH,

Fintan


How much days a iteration normally runs into ? Is there any difference in the number of days in RUP and XP?
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by Pradip Bhat:


How much days a iteration normally runs into ? Is there any difference in the number of days in RUP and XP?


Hi Pradip,

XPers recommend an iteration every 2-3 weeks. RUP does not mandate an iteration length. However if you are creating a lot of documents and spending time on up-front architecture and design, you can spend longer on an iteration in RUP (or spend the same amount of time but produce less software!).

Regards,

Fintan
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Thanks Fintan. Do you links to any website which says that an iteration in XP normally is between 2 to 3 weeks. I want to pass this to my co worker. Thanks.

XPers recommend an iteration every 2-3 weeks.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Is RUP failing because the testing is done late in the project lifecycle?
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Just thought I'd pop in and clear up a few misconceptions:
1. Evolutionary is typically defined as iterative + incremental. XP and RUP are both evolutionary in nature.
2. Agile can be defined as evolutionary done in a highly collaborative manner. XP is definitely agile. RUP can be instantiated in an agile manner, but often isn't (unfortunately).
3. In RUP testing can (and likely should) be done every day. The Test discipline runs through all phases.
4. Test-driven development (TDD) is an important part of XP.
5. You can do TDD on a RUP project if you like, and many people do.
6. Asking the "X vs. Y" question likely isn't a great way to learn. Asking "how do X and Y compare" is likely a much better way to learn because you discover how to use the best of each technique.

- Scott
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Originally posted by Scott Ambler:
Just thought I'd pop in and clear up a few misconceptions:
1. Evolutionary is typically defined as iterative + incremental. XP and RUP are both evolutionary in nature.
2. Agile can be defined as evolutionary done in a highly collaborative manner. XP is definitely agile. RUP can be instantiated in an agile manner, but often isn't (unfortunately).
3. In RUP testing can (and likely should) be done every day. The Test discipline runs through all phases.
4. Test-driven development (TDD) is an important part of XP.
5. You can do TDD on a RUP project if you like, and many people do.
6. Asking the "X vs. Y" question likely isn't a great way to learn. Asking "how do X and Y compare" is likely a much better way to learn because you discover how to use the best of each technique.

- Scott


Thanks for the reply. I will take your advice on comaring X and Y rather than X vs Y.
Anil Vupputuri
Ranch Hand

Joined: Oct 31, 2000
Posts: 527
I wonder if any project implemented using UP/RUP 100% with short timelines. What's the implication if you slip the deadline in UP/RUP?


SCJP 1.5, SCEA, ICED (287,484,486)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: XP vs RUP questions