File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Waterfall to RUP Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Waterfall to RUP" Watch "Waterfall to RUP" New topic
Author

Waterfall to RUP

HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
If a project decides to move from a Waterfall methodology to a RUP phase is there a proven track of doing the transition ?
The people have stayed the same; the disciplines may be largely the same- Business Process modelling , etc. Is it just a question of tightening deadlines to deliver smaller releases ? The team may never know they are now working in RUP! Though it would be kind to tell them eventually.
Going over the Waterfall with RUP
With a bit of creative thinking, a moderately iterative approach can be made to "appear" as a waterfall framework, if that is the externally imposed development approach.


regards
[ September 26, 2003: Message edited by: HS Thomas ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
These points make me think that it would be difficult to work with RUP
Waterfallish.
The GOOD points of RUP
  • Heavily uses UML.
    UML is a good tool since it makes it easier for both customer and developer since it gives them modelling tool that both can understand.
  • Iterative
    This means that the development goes through several cycles where the product can be refined which helps in improving the quality of the product. The iteration also makes it easier to introduce modifications to the different disciplines. Also, iteration gives us a mechanism where problems are detected earlier in the development process. The earlier problems can be detect and correct the better since the further into the development we are the more costly it will become to correct the problems.
  • Control
    RUP gives a control over the project; this will help project managers to manage the development especially if the project is large.

  • The not so good point of RUP (a.k.a the Bad stuff)
  • Requires knowledge
    Not like SSDAM, which was designed so that everybody could use it.
  • Only really deal with software development
  • More for developers than customer
  • Do not have as much user/customer interaction as say E.T.H.I.C.S and Soft system methodology.

  • These points make me think that it would be difficult to work with RUP
    Waterfallish.

    regards
    [ September 26, 2003: Message edited by: HS Thomas ]
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by HS Thomas:
    [QB]The GOOD points of RUP
    Heavily uses UML.
    UML is a good tool since it makes it easier for both customer and developer since it gives them modelling tool that both can understand.

    Customers typically do understand UML??? That's news to me...

    Control
    RUP gives a control over the project; this will help project managers to manage the development especially if the project is large.

    What kind of control are we speaking about here? Can you give examples?

    Requires knowledge
    Not like SSDAM, which was designed so that everybody could use it.

    What kind of knowledge is required by RUP, but not by SSDAM?

    Only really deal with software development
    More for developers than customer

    What's wrong with concentrating on specific aspects?

    Do not have as much user/customer interaction as say E.T.H.I.C.S and Soft system methodology.

    What's E.T.H.I.C.S? Google doesn't seem to recognize it as an acronym...
    What do you do in SSM, but not in RUP regarding user/customer interaction?
    These points make me think that it would be difficult to work with RUP Waterfallish.

    Well, of course the whole point of transitioning from Waterfall to RUP *is* to not work waterfallish any longer, so it seems to me...


    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
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    E.T.H.I.C.S. Methodology - Enid Mumford
    Effective Technical and Human Information Computer-based Systems
    E.T.H.I.C.S Methodology
    Like Soft Systems methodologies, it concentrates heavily on user involvement in systems design.
    I think I am right in saying that you can use UML at a very high level(business level) or a low-level (machine diagram) to model just about nearly anything.In XP only UML for programming level is used.
    In RUP you could use UML for Business Process Modelling.(What are sequence diagrams after all but a form of time-lines with processes attached).
    What do you do in SSM, but not in RUP regarding user/customer interaction?

    In my experience most customer reps and some users can communicate with SSADM tools: DFDs , Entities and attributes , E-R diagrams. etc.
    I have only experience of RUP in it's (amongst other things) adoption stage from Waterfall.
    regards
    [ September 26, 2003: Message edited by: HS Thomas ]
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    I'll save you some time, Illja.

    Here is Martin Fowler's thoughts on Customers and Models :
    "good wine and a paper napkin�two of the world�s best design tools".
    What's a model for ?
    Customers typically do understand UML??? That's news to me...

    Customers typically don't. But customer reps ought to understand high-level business process UML mdlling for better communication.
    What kind of control are we speaking about here? Can you give examples?

    RUP can be tuned to OO projects than Waterfall can ever be.
    Testing and development can take place in smaller phases of work whereas larger phases are required with Waterfall to see the benefit/product.
    That does imply that RUP,used properly, gives better control.

    regards
    [ September 28, 2003: Message edited by: HS Thomas ]
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    I'd say stages 4 and 5 of ETHICS are similar to XP.
    When trying to make sense of RUP I'd look for something that includes stages 1 to 3 of ETHICS.
    regards
    [ September 28, 2003: Message edited by: HS Thomas ]
    Lasse Koskela
    author
    Sheriff

    Joined: Jan 23, 2002
    Posts: 11962
        
        5
    I'd say stages 4 and 5 of ETHICS are similar to XP.
    I'd say they're not. This is the first time I've read about ETHICS, but I can't find anything particularly similar between ETHICS stages 4-5 and extreme programming.
    When trying to make sense of RUP I'd look for something that includes stages 1 to 3 of ETHICS.
    Again, I would not. ETHICS is just a process, and one that trusts on big design up-front and prototyping, it seems. Why would one try to make sense of a process framework (RUP) by looking at a process instance--unless that particular process instance would be somehow the most common?
    In the end, a RUP instance and XP (as well as any other process) both cover all stages of ETHICS, they cover the software development project from inception to delivery--even though you might not be able to see them as separate stages anymore.


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

    Joined: May 15, 2002
    Posts: 3404
    I admit I have a problem in determining the role of the Customer in RUP or XP. Capturing user stories via Role-playing does not seem enough.Change a few actors and you get a different script, it seems to me.
    The advantage of XP is that immediate feedback is given which is a huge plus. If customers or more importantly customer reps don't need to understand UML then there does not seem to be enough to link the Customer system describing processes and system development processes. Even Bob Martin said here that he doesn't utilise Use Cases (and that means CRC cards as well ) but that may be because he is a big enough personage to have contact with the business people who matter (but who may not be doing the actual tasks ,and, Bob is bound to be working with very experienced developers).
    RUP prescribes processes but not the tools that go with it. XP comes with tools for the developer. There doesn't seem much said in RUP or XP for the Customer (reps) process or toolset which makes for poor analysis.
    RUP (and XP) seems mainly for system developers. If Customer reps do not need to understand UML then I cannot see how they'll be trying to go from UML to BPEL4WS either, for instance.

    Hope this explains my dilemma. If someone says that Customer reps at least DO need to understand UML I wouldn't have this dilemma.
    I've been coming at this from all angles without getting any answers.
    Getting immediate feedback with a tested system seems to be the key, and it will work as long as the Customer understands that is the sum of his/her role in systems development. I wouldn't want to work in an environment(again) where capable Analysts left in droves(leaving the crud behind) and all because their role wasn't particularly well-defined.

    Immediate feedback seems to be the key to their involvement.

    regards
    [ September 29, 2003: Message edited by: HS Thomas ]
    Lasse Koskela
    author
    Sheriff

    Joined: Jan 23, 2002
    Posts: 11962
        
        5
    Why do you think Use Cases and CRC cards go hand in hand or did I misunderstood you?
    Regarding the customer and UML issue; I would consider myself very, very lucky for getting a customer who understands UML. Not because I would draw UML diagrams for him but because that would indicate that she probably knows other "technical" stuff as well. At least to some degree. Heck, maybe she's even an ex-software engineer!
    It is my opinion that Use Case diagrams are not that intuitive for a non-techie to read. Yes, only basic notations are used in a typical whiteboard artifact but I still think that plain English would work better for the customer. The Use Case diagram illustrates reasonably well how different functionalities compose the complete system, but isn't that closer to "implementation details" than "requirements specification"?
    I don't know. Maybe I haven't used Use Case diagrams enough to see their true value.
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by HS Thomas:
    I admit I have a problem in determining the role of the Customer in RUP or XP.

    I can't speak for RUP, but http://c2.com/cgi/wiki?CustomerResponsibilities should give you a good grap for XP.
    If customers or more importantly customer reps don't need to understand UML then there does not seem to be enough to link the Customer system describing processes and system development processes.

    I don't follow you. Are you saying that UML is the only language capable of transporting that knowledge???
    Even Bob Martin said here that he doesn't utilise Use Cases (and that means CRC cards as well)

    No, it doesn't. I am quite sure that he uses CRC cards as a design tool. Like Lasse, I don't see the connection to Use Cases.
    but that may be because he is a big enough personage to have contact with the business people who matter (but who may not be doing the actual tasks)

    *Perhaps* it isn't because he is a "big enough personage", but rather because he refuses to work in a different way. Perhaps that actually *makes* him a "big personage"...
    There doesn't seem much said in RUP or XP for the Customer (reps) process or toolset which makes for poor analysis.

    You are right that XP is mostly silent on how the Customer knows what he wants to be build. It *does* require, though, that he *does* know, so some form of analysis is implied.
    RUP (and XP) seems mainly for system developers. If Customer reps do not need to understand UML then I cannot see how they'll be trying to go from UML to BPEL4WS either, for instance.

    XP has a *very* strong focus on communication between Customer and developers. You seem to imply that not enforcing the usage of UML is a weak point - I don't see any reason for this. I'd think that ongoing oral communication is much better in fostering mutual understanding.

    I wouldn't want to work in an environment (again) where capable Analysts left in droves (leaving the crud behind) and all because their role wasn't particularly well-defined.

    Can you elaborate on this problem?
    I think the best definition for the role of an analyst in XP is "help the Customer understand what he needs, using all the tools which seem to be adequate".
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Originally posted by Lasse Kosekela :
    I would consider myself very, very lucky for getting a customer who understands UML. Not because I would draw UML diagrams for him but because that would indicate that she probably knows other "technical" stuff as well. At least to some degree. Heck, maybe she's even an ex-software engineer!

    I must have been lucky! Previously you couldn't keep customer reps away from diagrams / modelling. Heck , given the chance they'd tell you how to program as well.
    The fact they were international Analysts who'd commute to get business processes to hang together indicates why I have very high expectations of any customers I work with. Some of these Analysts started their careers as programmers. These guys learnt the hard way to trust nothing.
    UML would be nothing but a walk in the park to them.
    Design and Design Patterns , they would trust experience when they came across it.
    XP, now I'm not sure how they'd cope with that. You see they needed the breaks to keep up with moving business requirements. I can't envisage a Customer/Customer rep who's always face to face - E-mails can be dodged so can mobile phone calls. Unless you implement a workflow system for analysts to respond to give immediate feedback. (By constantly Testing, huh ).
    regards
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Originally posted by Illja Preuss:
    No, it doesn't. I am quite sure that he uses CRC cards as a design tool. Like Lasse, I don't see the connection to Use Cases

    I associated CRC Cards as a way of deriving Use Cases (and Abuse Cases)
    by role-playing out scenarios. A good way of recording all that oral communication. Final written reports would also be expected.
    Can you elaborate on this problem?

    Thinking about it, it was probably a problem to do with identifying skills gaps and transfering knowledge, both business and technical.
    Now Enid Mumford and the ETHICS methodology would have an answer here.

    I think RUP and XP work on the premise that the Customer would know. What if they don't and once you start thinking about changing patterns of work which would leave them further bogged, stressed and in limbo, I respect a methodolgy that looks at this as well.

    I don't know much about ETHICS methodolgy either.
    I'd hope such an extension of RUP would be included some time in the future. Perhaps EUP does ?
    But I see I am not going to win the Customers need UML argument.
    UML isn't part of the skills gap of a Business Analyst.
    And there's no point in using RUP Waterfallish though the article in the first post suggests you can.

    regards
    [ September 29, 2003: Message edited by: HS Thomas ]
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    To be a real party pooper and go back to the original question ... what tracks are there for successful transition from waterfall to something else? I outlined some of the steps our team took to become more agile. I take pains to say we don't "do XP" but we improved over what we used to do by quite a bit.
    http://www.surfscranton.com/architecture/StoryProcess.htm


    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
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    A proven track.
    I have to take a look at Requisite Pro.
    Actually I note that RUP does say time is required "to learn".
    But what should be learnt isn't clear and by whom.
    Originally posted by Stan James:
    ========================================
    Some of the ideas come from XP and other AgileMethodologies. But we are careful to not say we are "doing XP." XP has 12 (or so) major practices, and we are trying only a few.

    I see you have started even smaller than XP, I think.

    regards
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    http://c2.com/cgi/wiki?CustomerResponsibilities
    Thanks Illja this link helps as well.
    Thinking about it my ex-Customer reps would have loved XP if it helped them concentrate better on their business responsibilities.
    Can you consider Test Driven Development a kind of workflow for systems development ? Immediate feedback would also require some planning.
    regards
    [ September 29, 2003: Message edited by: HS Thomas ]
     
     
    subject: Waterfall to RUP
     
    Similar Threads
    Organizational Patterns of Agile Software Development -
    How To Answer This Interview Question?
    redesign the HLD & LLD?
    what is the most used process
    newbie