This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi, I need to write a paper on differences between XP and RUP. I need to do component analysis ,ie, break each model and analyse each component of the 2 models, also holistic synthesis and analysis. I know the various process components or workflow of RUP are Project management flow, business modelling flow, requirements flow, analysis and design flow, implentation flow, and so on... Can anybody please let me know what are the various components of XP? And how do i compare the components of both the models? Thanks, Priyha
Hi "Priyha", Welcome back to the JavaRanch. I saw your recent posts in the XML forum. To get us bartenders to stop bugging you about complying with the naming policy, you need to click on the "my profile" link above, then click on the "View/Update Profile", then change your Publicly displayed name to "Priyha Jootu" or something like that. As for the components of XP, first off, they're not called that in XP. XP has "practices" (12 originally but if I'm not mistaken, I think they added a couple or so since). http://www.objectmentor.com has a bunch of articles on XP and I think it has some that touch on comparing it with RUP, including one on dX (XP turned upside down), which is supposed to be a minimal subset of RUP, sort of a compromise between XP and RUP. Some of the best places to find information about XP are: http://c2.com http://www.xprogramming.com http://www.extremeprogramming.org There is also a whole series of books about eXtreme Programming published by Addison-Wesley As for doing a "holistic synthesis and analysis", well, I know what the individual words mean but frankly, I have no clue what the phrase even means.
Well, I guess you are in some trouble now, as XP *is part of* RUP in the meanwhile: http://www.objectmentor.com/processImprovement/xpRupResourceCenter/index OTOH, I would see XP rather as a "philosophy", less as a strongly defined methodology. The core of XP are the principles "Communication", "Simplicity", "Feedback" and "Courage". The practices are just that - practices meant to be used to learn how the principles can get realized. "They are just rules", meant to be tried out, reflected about and finally be broken...
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
Alistair Cockburn has written volumes on the relative merits of different methods. I find him very balanced and unbiased. XP and RUP are not really apples to apples. XP focuses very strongly on the activities of developers in producing executable software. Many people believe XP tells you not to do something (like write documentation) but it really allows you to do anything you have to do OUTSIDE of developing code. Of course many XP fans will let you know that such things are probably pointless time wasters but don't let them bully you. RUP covers a broader playing field than just writing code with many activities that go on before and after and around XP. And as mentioned before, RUP is a framework designed for customization and allows something very close to XP as a RUP implementation.
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
Joined: Jul 11, 2001
Another characterization: RUP seems to say something like: "In most projects you will need this, probably that, perhaps those etc. Don't worry, we have a solution for every problem." The drawback: Many people seem to have problems with identifying all the things they *don't* really need. XP is more along the lines of: "This minimal set of practices is a good starting point. It won't kill your project, you will probably learn some interesting things if you didn't try it before, and with the rapid feedback you will soon find out how to adapt it to your actual needs and what you need to add."