IBM Donates Parts of Rational to Open Source 168
slashbob22 writes "IBM has decided to contribute portions of the Rational Unified Process to the Eclipse Foundation. From the article: 'RUP is a vast collection of methods and best practices for promoting quality and efficiency throughout software development projects. IBM's donation will also provide a foundation architecture and Web-based tools for the industry to engineer, collaborate on, share and reuse software development best practices.'"
Don't be offensive buddy (Score:2, Insightful)
Granted, Firefox is excellent but Opera has been amazing for at least half a decade and is useable on everything from PCs to cell telephones.
The Rational Unified Process is excelent (Score:5, Insightful)
That's why Rational Rose is such an efficient, consistent, bug-free software.
</sarcasm>
I don't know about other people's experiences, but some of the worst pieces of software I've ever used have been CASE tools (you know the type: UML, lifecycle, etc). Kinds of make you question the usefulness of those tools and processes.
Re:The Rational Unified Process is excelent (Score:4, Insightful)
If your relying on the tools, then your probably missing the point of the process. Tools can aid you in the process, but a process doesn't require tools (not even a commercial 'product' like RUP).
Re:OK OK I'll admit it -- coders are LAZY my frien (Score:5, Insightful)
First, I have personally used the RUP successfully. The success was in spite of the process, not because of it. The excellent people I had on my team made the work a success, and not a paperwork-on-rails approach to software development.
On the upside, the RUP is geared toward control of iterative projects. On the downside, it treats every diagram you draw as though it were as valuable as the working software you really intend to produce. It also adds artificial divisions between roles in the process (the architect sends X to the analyst who elaborates it and sends it on to the developer who extrudes Y...). It tends to reduce communication among team members, and between team members and stakeholders. It's original intent seems to have been to give all the diagrams in the UML a reason for being (and by extension, Rose).
Show me a failing unit test and I'll show you a low-level design awaiting implementation. Running code trumps "managed artifacts" any day.
Re:Huh? (Score:4, Insightful)
Comments on RUP/RUPP (Score:3, Insightful)
However, some of IBM's products that are part of RUPP are shit. Rational Software Architect (the 'visual modeling' part of the RUP process) is the most bloated piece of crap I have ever used. It is unintuitive, a massive memory hog, slow, and overall just a bad piece of software. About the only thing it gets right is that it is UML 2.0 compliant and has all the different models...but I have found that there are many cheaper UML modelers that are better.
Heh in a way it is just like Eclipse (which is what RSA runs on top of) - too much crap that is inaccessible. The trend in software for a while has been adding new features that people don't know about. I believe MS had the same issue with Office in a survey they conducted, where they asked people what features they wanted to see in Office and 95% of the features were already there, but people didn't know about it. For every feature added for functionality, there should be two more added for usability!
Similarly, for a programming process/paradigm to take hold, developers need to be provided with (process-related) tools that are lightweight and approachable. A process that is too rigid, too heavy-weight, etc. will never be adopted - worse yet, some team will start using that process then slowly become lazy and soon they will be in a middleground of incomplete requirements, specifications, design docs, etc.
Pardon me for asking a stupid question, but... (Score:3, Insightful)
Re:Huh? (Score:3, Insightful)
Actually, communism looks awful in theory if you understand a little bit what that theory means.
Re:Two best practices for security (Score:3, Insightful)
2. Thou shalt not let thy buffers overflow.
I hope those are in the Rational Unified Process (perhaps the construction phase of RUP).
If that is your method for preventing security problems, I will *never* use your software.
Security starts with the following best practices:
1) Thou shalt write modular software
1a) Each module shall not run with more priveleges than absolutely necessary
2) Thou shalt rely on platform permissions enforcement wherever possible.
Then we can get to buffer overrun prevention. But if you don't try to manage the possibility before you get there you are lost at the beginning.
Re:Pardon me for asking a stupid question, but... (Score:2, Insightful)
While TFA does not really make it clear which bits of RUP are donated, I imagine IBM is at least donating some instantiation of the process, which includes documented procedures and workflows, along with document templates, etc.
Without this donation, Eclipse could probably use something similar to RUP (I suppose they could use some version of it that happens to be in someone's head - but remember, IANAL), however it would be like Chinese whispers: Like all organisations who define their own processes, they are going to make the same mistakes that everyone else has made time and time again. Very few people are able to simply remember everything that needs to be done from the original idea for a software project, through to the packaging of a product.
Re:OK OK I'll admit it -- coders are LAZY my frien (Score:5, Insightful)
I'm part of the enterprise change control staff at my company, and I can tell you that the more tightly we implement controls, the more often we discover that the problems that arise are from developers implementing untested changes without authorization. If you force them to submit change documents, and don't let the changes get into the code base until the change has been authorized (for that matter, don't let them code until the change has been authorized), then have someone else test the changed software before the code gets pushed up, you've got a three-legged stool to stand on, and you have an auditable process that maintains accountability.
I bet if you look at the submission process of any successful open source project, you'll find the same constructs, maybe just not called out so formally. The basic ideas aren't bad, just some implementations. RUP gives you a framework to design your procedures with.
Re:The Rational Unified Process is excelent (Score:1, Insightful)
Re:+6 insightful if you will (Score:5, Insightful)
Didn't they use the process to create the tools? (Score:3, Insightful)
The tools stand for the process though. If they used RUP to create the tools, then you would expect the quality of the process to be reflected in the tools. If they did not use the process to create the tools you need to ask why not.
So while I agree you don't need the tools for the process, I judge the process itself (I have never used RUP for a project) in part by the tools created with it.
Though really all this proves is the process isn't a silver bullet, something Fred Brooks predicted years before it was dreamed up.
As someone who has supported RUP, Rose, XDE at IBM (Score:3, Insightful)
However, I always saw RUP presented as an array of smaller, compatible processes within the iterative process. IOW you adopt an iterative cycle in your collective workflow (very easy by itself) and pick what you need out of the (admittedly large and overspecific) RUP. Or you take the whole RUP and 'knock-out' what you don't need. RUP the standard anticipates this, even though RUP the product could provide more help in this regard.
With that said, I believe that FOSS projects have suffered greatly by not formally recognizing and docucmenting use cases. Excepting Mozilla and OpenOffice, the evidence abounds. It probably flows from historically "scratching our own itch" and often not maintaining requirements in the first place.