Slashdot Mirror


IBM Donates Parts of Rational to Open Source

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.'"

12 of 168 comments (clear)

  1. This is VERY GOOD news by Work+Account · · Score: 2, Interesting

    I've used Rational(tm) before and thought it was great at what it claimed to do. Much like UNIX(tm) and GNU/Linux(tm) applications, it did one thing and it did it well.

    Now, combining Rational with Eclipse(tm) should make the latter even better!

    --

    If you "get" pointers add me as a friend (116)!
    1. Re:This is VERY GOOD news by sammy+baby · · Score: 2, Interesting
      I mean it has been analysed and designed, and documented, and modelled, and designed again until no stone is left unturned, and BAM! suddenly we are implmenting software? Am I the only guy who thinks this is too good to be true? Nowhere in the Rational Unified Process can I find any diagram, reference to, or project plan, about the "Build" or "Code" stage. Yes, I know there is a "Construct phase" but nothing inside it actually talks about putting hands on keyboard and coding.


      You're probably confused by RUP's use of the term "implementation." When a software architect considers what the functional requirements of the software are, then starts describing classes and subsystems that are supposed to meet those requirements, he's performing one of the disciplines, analysis. When you take into account nonfunctional requirements, performance requirements, et cetera, and further refine the description, you're performing the "design" discipline. The person in the "implementation" role is the one actually developing - and often testing - the components.

      So, the "bam" you're referring to - implementing software - in RUP, that refers to actually writing the damn stuff. If it seems like you magically skipped from analysis and design over the whole meat of the process, it's because you're probably confusing the term "implementation" with "deployment."

      Incidentally: if you look at a diagram of the Phases vs. Disciplines of RUP (there are a lot of them to choose from, and they depend on the type of project you're working on), you'll see the third phase is called Construction. In Construction, there's a lot of "implementation" which starts to taper off right near the end of the phase, and a bunch of "testing" which ramps up right near the end. That's the part you're thinking of.

      But since you asked: the part right near the end of construction is usually where people start to realize it if something is seriously going wrong. So yes, if expensive consultants are going to be summoned, that's probably where.

      (sorry if this is rambling and incoherent - I'm up way past my bedtime)
  2. Hard to Understand by someguy456 · · Score: 3, Interesting

    As an intern at IBM this summer, I found that some of the regulars themselves didn't know what RUP was. In particular, some claimed it was simply a process to follow, some linked it with a special program, others claimed complete ignorance, and others simply waved it off as labeling the pre-existing procedures. I still wonder what RUP is all about...

  3. OK OK I'll admit it -- coders are LAZY my friend by Work+Account · · Score: 4, Interesting

    Look, we are and I'll admit that. I'm not afraid to criticize myself and other developers:

    - Me and other coders are often eager to jump right into projects instead of designing them thoroughly (using RUP for example)
    - Other coders and I often get bored after I figure out the hard part and say the rest is trivial

    It's more of a work ethic. Also, my friends in the gaming industry (Electronic Arts(tm) for example) work 60-80 hour weeks, so it's understandable that they seek out shortcuts.

    Let's agree to work a little harder and/or smarter and not skimp on design! USE RATIONAL!

    --

    If you "get" pointers add me as a friend (116)!
  4. Huh? by 0WaitState · · Score: 3, Interesting

    IBM is "donating" the methods of RUP to open source projects? I thought IBM liked open source?

    As far as RUP goes, it's kind of like communism. Looks good in theory, but goes all pear-shaped when real human beings get involved. Pull the UML out of RUP and leave it at that--the rest is madness, enobling "process" over productivity.

    --

    Remain calm! All is well!
    1. Re:Huh? by arudloff · · Score: 5, Interesting

      People try to make RUP into more than it is. The idea is to take and leave what works for your organization, and build a loose process around it. It's a framework for generating your own applicable process, and all too often companies want to do everything that RUP tells them to do (ignorning the fact that RUP tells you not to do everything..)

      What really needs to be taken from RUP is the idea that an iterative approach reduces risk of failure. The concept of "roles" is helpful, but thats just basic teamwork.

  5. Don't plagiarize buddy by Work+Account · · Score: 3, Interesting

    Look at the 80 character line lengths in the parent post and thus the premature line breaks.

    You obviously copy+pasted this post from somewhere, which isn't cool to do unless you properly attribute it.

    --

    If you "get" pointers add me as a friend (116)!
  6. RUP in practice by Is0m0rph · · Score: 2, Interesting

    My company decided to go with RUP a few years ago. It took months of classes and basically just an iterative process that has very heavy on process and paperwork and is based on UML. Very unproductive in the environment I worked in. A few lines of code changes could result in 40+ hours of paperwork and reviews. So I saw in practice you start with RUP, strip out what you don't like, and you end up with simple iterative process we could have thought of ourselves rather than spending a ton of money on Rational consulting. The Rational products for doing the modeling were crap. Couldn't stand them. I like Rational's ClearQuest for bug tracking and ClearCase for source control but other than that the rest was junk.

  7. Re:Comments on RUP/RUPP by Evangelion · · Score: 2, Interesting


    I use Rose at work, and I find it to be fine to work with -- all I'm trying to do is create a few diagrams, and it makes it relatively easy (relative to Visio) to piece together a class or use case diagram with as little work as possible.

    It's bloated, but as long as your company furnishes you with decent hardware to run it on, that's hardly an issue.

    It needs some work on exporting the diagrams to a useful format (a vector-based diagram export, such as SVG or eps, would be a nice addition) but in general it does a good job of... doing whatever it is it does.

    I can't comment on using it as part of the entire RUP, as we just use it for diagrams.

  8. Re:OK OK I'll admit it -- coders are LAZY my frien by kpharmer · · Score: 3, Interesting

    > 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.

    don't forget "The Law of Unintended Consequences" which shows that:
    1. as accountability goes up attitude, morale, productivity, and efficiency go down
    2. once you hit critical mass on paperwork, process, etc you destroy motivation - there's some point on the curve at which point everyone just says 'who cares' and 'why bother'
    3. it's impossible to really anticipate everything upfront, which means that minor changes that in a system and organization that embraces agility & resilence can be easily handled in stride take 40x as long in an organization afraid of blame.
    4. most of the work is done by the motivated and talented 10% of the staff. these people leave rather than put up with the bureacracy designed to hinder the 90% that are unproductive.

    RUP is a disaster, I've seen it absolutely wreck companies.

  9. Re:The title should have read by OneSmartFellow · · Score: 2, Interesting
    I agree completely. I am forced to use two Rational products in my job here. Clearcase is an abomination. The server seems half-way decent, but the GUI is absolutely attrocious. The only app I use that is worse is Lotus Notes.

    The other Rational product is 'Rose', which as far as I can tell is little more than a collection of graphics. The reverse engineering tool is all but useless. The types of projects you really need to reverse engineer are far too complex for Rose to handle, it dies after chewing up all available memory, and CPU on a quad processor Opteron. The code generation tool is OK, but that's about the only good thing I can say for it.

  10. Re:OK OK I'll admit it -- coders are LAZY my frien by SlowMovingTarget · · Score: 2, Interesting

    If the development team is undisciplined enough to require a formal process, then RUP is one of the least harmful heavyweight processes. But make no mistake, it is heavyweight.

    The truth of the matter is that you can automate much of the gating needed to keep "unauthorized" code from making it into production. The key to your statement is that developers were adding "untested" changes to the code base. Part of the demand of agile processes is that you write code to make a test pass (whether this be an acceptance test or a lower-level unit test). The net effect of this is that disciplined developers write code that is required by the nature of the system, and the nature of the tests. Even at an architectural level, you can automate verification of architectural styles. This tends to require a more significant effort, however.

    With regard to open source, the issue is one of communication. Developers may be in different time zones and may rarely have the opportunity to speak to each other face to face. There is a minimum of process, but it is to coordinate general direction for the project, and even in these cases, working code, proven with tests makes the strongest argument in favor of a particular approach.

    My suspicion is that you are catching the issues you are because people are sitting in a room, face to face, and talking about it. The change documents simply set the agenda for the discussion.