there is no good statistics about this, I don't know what your professor is pointed to.
but for small UI oriented desktop applications usually rapid prototyping and similar methods  is the best
there are some RUP extensions that fit this model.

the problem with SLDC is lack of iterations.
I think the iterative incremental software development  is a proved concept today.

forgot to add some thing,
if you can get the customer to sign the result of SLDC life cycle documents and stick to them,
thats much better than RUP because you will get paid much easier.

Thanks to all for their advice and concern, here are some statistics I
found interesting:
www.ambysoft.com/surveys/agileMarch2007.html

Some findings include:

1. 69% of respondents indicated that their organizations are doing one or
more agile projects. Of those that hadn't yet started, 24% believed their
organizations would do so within the next year.
2. 44% indicated a 90%+ success rate at agile projects, 33% indicated between
75 and 90%. It appears that agile seems to be working out.
3. Co-located agile projects  are more successful on average than
non-co-located, which in turn are more successful than projects involving
offshoring.
4. 98.6% of agile teams worked adopted iterations, and 83% had iteration
lengths between 1 and 4 weeks.
5. Smaller teams had higher success rates than larger teams.
6. 85% of organizations doing agile had more than one project completed, so
it's gone beyond the pilot project stage in most organizations.

I have some questions,
1- Is it possible that we customize RUP so that have an agile RUP methodology?
2- What is the main diffrence between RUP and agile methodologies like XP? What I see is the Elaboration phase(RUP has but not agiles). Can you mention more?(I don't mean pair programming, or less documentation,...)
3- How can you ignore the elaboration phase from enterprise projects? Don't you think on big projects  refactorying architecture would be very expensive?

1. The agile version of RUP is published before as dX methodology, which is so poor in comparison with other proposed agile methodologies (since the goal of an Integrated methodology like RUP is so different with agiles, therefore this mixture can not work properly;) )
2. Most important concepts proposed by agilists are their proposed practices (12 important principles), which are proposed before too, but are gathered by first proposed agile methodologies (like XP). First agile methodologies do not include precise process, but gradually they ll include processes too. They do not include extensive modeling during development, and are mostly suitable for small size projects  and small teams. Their proposed processes are different from Integrated methodologies, like RUP. This topic can be discussed deeply later:)
3. As you found out, there are reasons which makes agile methodologies unsuitable for large  scale projects, including those you mentioned. That is, the risk of using agile methodologies in such projects is high.

There's a page in RUP process  guidance (the set of RUP documents) that compares the best practices that the RUP is based upon, to the practices that form Agile methodologies. I'm not sure for 2002 version, but I've definately seen this in RUP 2003.

The article throughly discusses the compatibilities an incompatibilities of the Agile methodologies with RUP.

this DJJ is a reputable magazine and I think the survey can be used as good resource
do you know a similar statistics about all methodologies (not only agile ones) ?

Well, for small projects  with the following features, traditional SDLC
(waterfall) is the best:
1- Requirements do not change
2- You know the risks and they are small
3- Design is simple

RUP unlike waterfall is iterative but is so heavy and must be
customized and is good for big projects.

RAD mostly uses prototyping and is good when you need to deliver fast.

JAD is good for collaborative projects. You are face to face with
customer.

Agile methods  emphasize on delivery, face-to-face communication but
not much of documents. Most agile teams are located in a single office.

Returning to your question  waterfall is best for small projects that
you know its ups and downs.

If you care about documents go for RUP and if you don't care much then
depending on some other factors you can choose others.

Regarding modification, whatever methodology you choose you will
definitely will modify  it for your needs. Obviously if the project is
small then you do not need to produce a lot of documents related to
waterfall methods.

For small applications, I'd recommend agile methodologies such as XP, AUP or MSF Agile, depending on the team's knowledge and the application at hand. For example if your desktop application being developed using Microsoft's technologies, MSF Agile would be better. For Java-based development  I'd rather go with XP / AUP. (Although I don't have practical experience with AUP)

It's obvious that heavy-weight processes such as RUP are not recommended, because the work required to deploy the process  itself would exceed the work required for the application itself.

Anyway, choosing the process for small applications is highly dependent on the team and its knowledge. Maybe your instructor was assuming that the typical team can be adapted to SDLC easier. This can be the case for a typical, non-professional team, because understanding and adaptation to the process requires less experience and learning. (Maybe!)

Anyway, I don't agree with your instructor.

there are not much similarities, there's no point looking for difference. when RUP iterations are used - in whatever size projects  - in its task breakdown you will end up using agile anyway. size of the project really matters when choosing the process  flow. for instance when you mention enterprise project, is it large  scale? or do you only mean a multi-tier, but even so, when you look at the nature of enterprise you have to have an elaboration, cause it is within its nature to scale  overtime, therefore elaboration will become a key driver at project plan time. this will allow teams to have broader scope of thinking

size of the project always tells you what methodology you need to go for, and how much documentation is required. some people tend to follow academical and theoritical patterns who "may" fall into lot of costs problem but some use both theoretical practices with some level of experience.

what good you might gain from agile RUP , it depends if agile is going to be applied at high level or do you tend to use it at iterations? but keep this in mind that these practices are not written on stone, so you may produce a new methodology that creates more productivity in comparison to its competitors with less cost

There are similarities as both RUP and Agiles are trying to apply best practices; For example iterative development.

As you said RUP could be customized and is not some thing on the stone, So we can have
an agile customized RUP that could be very similare to XP for example. But what I underestad, the major diffrence between RUP(or RUP like) and agiles is that RUP has an Elaboration phase but agiles are applying this requirement by refactorying during all phases of project(Correct me if not)(Ofcourse RUP let you to refactor as well).

About the large  scale and enterprise,I think none is the root reason to see if you need the elaboration phase or not but they are effecting parameters on your decision; If you see the risk of refactorying architecture is not high(By considreing all parameters like large scale, type of project, your company experiences on that type, You architects experiences,...) in your project then it is ok to ignore elaboration but if you can't have any estimation on the risk or you have but you see it is high then better to have the elaboration. Ofcouse the size of project is one the most important parameters on this decision.

once I read some where (in FDD methodology proposed by together) that a methodology should not be more than 10 page!
I have used this over time about RUP
the biggest problem with RUP is it's size
although it has lots of good practices that let you develop software fast. (like what agiles claim)
but since the learning curve is so lengthy, most project managers and their development  team never learn it completely,
and they usually end up using it in wrong way.
the best thing about agile practices are they are usually short and easy to learn, so PM and developers, can learn them and
apply them in their project very fast.

The Functional Modeling stage in DSDM would be very much similar to the elaboration phase of RUP. The goal of both stages are to minimize the technical risks associated with the requirements.

In the elaboration of RUP you need to test your architecture to see whether it has any potential risks for your requirements or not. For example if you are going to have an application on your production site, that for each request should reply for at most 1 sec. and there could be 100 req/sec. then you need to test your architecture in an environment exactly as what you would have in the production to see the risks(any diffrence could face you to major problems later).
It is not only documentation. When you pass the elaboration you should have fixed the architectural risks.
Does DSDM also suggest this? Or it is just architecture documentation?Any more infos on DSDM and your experiences is welcome.

I completely support the idea of applying best practices in both methodologies, at the same time the termonology of enterprise worries me when the attempt to refactoring any portion of subsystems come into place.

Considering that definition of elaboration in RUP looks very idealistic, I would like to point to a few facts that causes RUP's elaboration to win over refactorying. (this is for your point on elaboration for large  scale enterprises which I do not agree with your comment) and this is why:

one is the scalable nature of enterprise systems which requires clear and percise deliverables for each iteration for future added functionalities (new feature). it is required to provide a basis for any future added functioanlity in the system  by focusing on the architecture of the system (again this might sound very idealistic). The other fact is the policy of team rotation which is a reality. This mostly happens in very large organizations with the intention of circulating information among engineers by giving them a big picture of what's going on (some don't like it) or moving teams to new services and replace them by another rotation or co-ops. therefore lack of clear architecute (due to refactorying method) and not having clear and focused documentation for new team will cause cost of time and trouble for new guys to figure out what was going on before. I always say a clear or visualized information (in the form of UML) is much more understandable as oppose to digging into the code. this is why elaboration becomes a key factor in large projects.

you might say refactorying can still produce focused documentations, but I don't agree cause overtime it won't.

on your last point I see we both agree. the decision depends on the size of the projects  and complexity. RUP or any other apprcoah might not be suitable for every process, but an estimate on the project and how it is going to grow surely will give  an understanding as which method is more suitable (which might not neccesarily "seem" to be the proper one at the time). the difference of these two is on how focused they are and depending on the project.

now that we are here (I might sound like a fan) but for large scale  projects I have used RM-ODP a lot and I consider it very successful. RM-ODP may not fall into category of software development  processes as it is more like an architecture technique, but within a bigger scope of RUP it might be usable.(worth checking)

XP and RUP are used widely all around the world. Even in google, they use these methodologies in different projects. I believe that they are both useful as you mentioned. That's why they are used globally. But why are we discussing the points declared in management? Because they can be elected and used according to our tastes. It is not at all easy to stand between the conventions declared in books as standards and face the reality and find a way. It needs a kind of experties that managers shall possess.

Just a thought
More than anything, I believe that the management team should be absolutely aware of the amount time they are spending upon management BEYOND CONVENTIONS. The project manager shall know why she/he is logging, monitoring or tracing something. That's our bottle neck. A manager needs confidence, experience and common sense not to mix up conventions with inevitable reality. Conventions are names. Names won't essentially lead us to great products.

What do you think?

I didn't lead you to refactorying, I said enterprise and large  scales are decision parameters. If you have done similar enterprise projects  with nearly the same requirements, Then you may accept the risk of ignoring elaboration and go for refactoring.
Elaboration phase is very important phase that let you to attack architectural risks early. But at some situations PMs and architects could reach to this conclusion that they don't need a large elaboration phase.

processes like this should not be treated as one size fit all t-shirt.
documents might go over certain size. document templates are always under review (by quallity team) to make sure they hold appropriate level of details. temaplate might change based on lessons learnt and reviews.
from project, product and program management view point, the whole thing is a series of iterations. they only see the dates and deliverables (to include customer support team as well) but to system  engineers and solution architects the process  is iteration + refactorying (that's what they end up doing in iterations) and from dev view point it is all of those plus XP.
if you look at how internal sw is released, i.e. 5 as main 5.1 as a target goal for certain date, 5.1.1 to hold certain features and 5.1.1.1a to hold fixes parallel to 5.1.1, refactorying is surely happening to introduce either patches or internal releases with major fixes or reshaping things to match new stuff (which was not visible at the time) - I agree should not happen, but it does
this is reallity and in simple terms, "whatever works for you" , but the important thing is that the big iteration sw dev process should deliver whatever was signed off in the original scorecard, and down there you do XP, you stay over the weekend or over night but it has to be delivered

good point on the second paragraph, that's why all reviews happens in between each iteration

you agree that it takes more than googling to make this choice although it might be a sign of efficiency if it is used widely but again its case by case basis argument

a few comments on the line "Because they can be elected and used according to our tastes." this depends who "we" are and where "we" fit in within the organization hierarchy.

managemenent is not the place to decide on the methodology, although they provide the input like anyone else but they more interested to play with dates and numbers :)

these practices are a common decision made by more than one team of responsibility (QA, PM, CSG, etc). how you deliver a product to customer? this is a key driver to the decision or how the product is going to be released. I'm not trying to make this complicated but once again this is project size and strategy dependent. as you said they are both useful.

funny enough, I have seen very critical projects  (not very big though) that had absolutely no documentation or specific process  and seems like they are doing pretty well - don't ask me how cause I don't know

and about standards, don't forget that standards are written based on real experiences and even they are versioned (don't they?) so decision makers have to be flexible. organizations consider the theory and conventions and implement their strategies to be aligned with their needs in another words, create you own version of e.g. RUP and never publish it

I've never understood these RUP talks! Software development  is not army for God's sake! Just write the freaking code! And if they have to turn the place into an army just to get the company produce anything useful, just leave that company, go somewhere else and actually enjoy doing your work. Life is too short for suffering....

Oh btw enjoy reading this article:
steve-yegge.blogspot.com/.../...-bad-agile_27.html

Finally somebody made a point! Thanks Ara.



Does anybody know one single company that really uses RUP? How many OO programmer are there in Iran? I’m not talking even about the designers.



Just Imagine, you have just joined the project, let’s say the second iteration.

Have you ever tried to read and digest the materials produced by an RUP process  without doing it again yourself?

I think you had bad experiences,
I have seen many organization implemented RUP successfully,
although I have seen much more failed to use it correctly. as I said earlier the biggest pitfall is there are lots of people (project managers) who don't know know technology X (RUP) tried to use it, just because it was buzz word, and they failed.
I have worked with more than 20 companies started using RUP in Iran and among them only 2 project manager knew the different between UML and RUP. so how can one expect these companies to succeed?

first of all the essence of RUP is against the Iranians culture because it promotes promotes discipline and hard work

and also don't forget failing is easier than succeeding, there is an statistics that in US from each 5 new company only one succeed and 4 fail, so if you have seen only 1 out 5 project succeeded using the method X (RUP, XP, SCRUM,...) it is usual, above that is good and below shows a bad result. (and also put the fact that we are in Iran and we will have more problems)

Among those companies that failed using RUP almost all of them never applied iterative incremental aspects of RUP, they defined long inception and elaboration phases and tried to make most of the project in one phase just like water fall and SDLC.

That is my point.

There is nothing wrong with the methodology itself. The question  is does it
apply to our projects  or not? My answer  is, in most cases; it does not.

The methodology should always be selected based on the nature of the
project. The question is who has that knowledge?

Reza made some comments about documentation. I wasn't talking about the
documentation. Documentation is part of the process. I was questioning the
validity of the documents produced within the process; which indirectly
questions the validity of the process  itself.

I am sure neither me nor Ara meant eliminating it. What I was trying to say
was that people usually spend a lot of time on making decisions on how to do
the things without actually doing it. The one and only goal of the software
development is to develop the software in a reasonable time. The software
needs to be valid and reliable. Do we usually follow this path?

You base it on Iran? Iran has its own method:) and that's why most of projects  fail.
RUP is not some thing foolish. If you see documentation is useless in your project then ignore it. RUP is not equal to documentation. But it suggest many document types. You don't need so don't documents so don't use it.Once again RUP is not only documentation.
You may don't need to read the documentations but it doesn't say your managers, ... also don't need them.

The article was superb. Now I know why no googler decides to establish a start-up company. I just wish google had more essence of apple or B&O. The way they are deconstructing management reminds me of a lyric by Sting.
The greatest thing about the google team is not about software but innovation in a variety of things specially in marketing. Look at the way they are bringing security of trade on web, the way they monetize, the way they recruit, their business solutions, the companies they acquire. They provide new services faster than we can pronounce them. All they create is just around one word, "search". It is no surprise that they are growing. It is surprising that they do not restrict themselves with the power. They don't create beautiful products but the beauty is in their vision.

The people who developed RUP are not fool nor colonels(I don't think you mean that) :)
I think I feel what you mean some how, It is because of bad customization of RUP in most of companies. RUP could be very simple, make it simple as much as you want but don't forget the best practices. Attacking risk early & iterative development,... should not make the atmosphere army. Many projects  have failed, and the analysts has found the reasons and now they are proposing solutions and methodologies; one of them is RUP. What is wrong with this?

once again this is project dependent decision............

Development process  is used for all of software projects  because it shows you a road for development. It can be used in different forms such as Pair-Programming , RUP , SCRUM , .... you always use it ,maybe you don't think about it but you do it unconsciously, even you can customize it for yourself (i recommend ) , and that is more important which documents i should create and archive.

But which of those is more suitable !? in my point of view there are infinite aspects which lead to choose one instead of others, or make your road-map among them, so it doesn't mean it is Bad, that is Good or this is Excellent , it means this process is more suitable for you instead of others.



I am going to write some these aspects which can help you to choose your best one , or it is better :
(all of following items are my personal experience in software development  , so maybe you don't believe them)

Project size
Project cost ( applicable )
Project time ( dead-line )
Project domain model complexity
Project architecture complexity
Team size
Team knowledge on domain
Team knowledge on architecture
Team arrangement
Distribution of individual skills
Team knowledge on your development process
Stakeholder knowledge on domain
Volume/Frequency of change requirements
Project will be continued or not !?
...
And let team understand why development process or some documents are important.

no need to get so defensive, you might not care, but the people that are investing in the industry "usually" require a clear and high quality product. this does not apply to software industry only. noone's taking any process' side, all we are saying is that how to use them and how to choose.

writing the 'freaking' code and leaving the company if you no longer like it, might work for you, but the owner of that code needs to hand it over to new guys and the best way for them to understand your code is with the help of some clear and open methods  as oppose to wasting time and reading the code, this has always been waste of time and will remain the same.

I suppose once you started investing your own money on projects  you'll understand. may be this is more a ownership talk as oppose to coders'