GeeCON Prague 2014*
The moose likes Agile and Other Processes and the fly likes RUP - Normal Process ! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "RUP - Normal Process !" Watch "RUP - Normal Process !" New topic
Author

RUP - Normal Process !

Manas Ahlaad
Ranch Hand

Joined: Nov 07, 2001
Posts: 165
Hello All,

How to induce RUP techniques in the existing process ?
TIA


Manas<br />Today If You are not Confused,You are just not thinking Clearly !<br />---------------------------------
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Why do you want to? What does your current process look like? What do your co-workers think about the current process and about RUP?


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
Manas Ahlaad
Ranch Hand

Joined: Nov 07, 2001
Posts: 165
1.my current process does not mandate UML diagrams.
2.my process does not define milestones at any phase.
3.my process does not suggest to use component based architecture.
since I think all these can be of much value addition to the process I wanted to know how to induct RUP into my existing process
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
1.my current process does not mandate UML diagrams.
What benefit do you think you will gain from mandating UML diagrams? Are your team already using incompatible or confusing forms of diagram?
If this important, why not just add somthing like this requirement to your existing process: "where diagrams are used to communicate software designs, they shall use the UML"?
2.my process does not define milestones at any phase.
This is an important omission, but I still don't think you can just "buy in" a development process and expect it to provide a canned solution with details such as this. The only way to decide on the milestones for a particular project is to understand the project.
3.my process does not suggest to use component based architecture.
Surely choice of architecture is a design issue, not a process issue. I can't believe that any sensible process makes such gross design suggestions. Once again, what benefit do you think you will gain by adding this to your process?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Manas Ahlaad
Ranch Hand

Joined: Nov 07, 2001
Posts: 165
1.my current process does not mandate UML diagrams.
What benefit do you think you will gain from mandating UML diagrams? Are your team already using incompatible or confusing forms of diagram?
If this important, why not just add somthing like this requirement to your existing process: "where diagrams are used to communicate software designs, they shall use the UML"?

Actually,I wanted to tell that my process does not mandate diagrams (may not be UML).It just talks about filling documents does not consider techincal issues ,e.g. communicating design ideas.
2.my process does not define milestones at any phase.
This is an important omission, but I still don't think you can just "buy in" a development process and expect it to provide a canned solution with details such as this. The only way to decide on the milestones for a particular project is to understand the project.

I too agree that process is not a plug-in.But there should be some authority or document which may atleast say that "every phase should have milestones such as this"
3.my process does not suggest to use component based architecture.
Surely choice of architecture is a design issue, not a process issue. I can't believe that any sensible process makes such gross design suggestions. Once again, what benefit do you think you will gain by adding this to your process?

yeh , I do agree.But, there should be some diagram which communicates how did you view your requirements at first.
The suggestion you gave ,"where diagrams are used to communicate software designs, they shall use the UML". we too thought of adding such a statement. But I doubt ,to what extent will it mandates people to do diagramming.
altered emphasis to separate questions from answers -- Frank
[ October 18, 2002: Message edited by: Frank Carver ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Manas, in my experience it is best when process issues are self-imposed by a team (as opposed to imposed on the team by a manager/document/something else outside the team). There doesn't need to be an authority forcing the team to work a specific way if the team *wants* to work that way.
What we currently are trying is a weekly Process-Tuning-Workshop. Here the whole team sits together for an hour (I expect it to becoming even shorter once we get used to it), discussing current issues and solutions.
The output of the workshop is *one* flip-chart page, containing catchwords for what works well and should be continued to be done, the current problems and, most importantly, a handfull of things the team decided to try till the next workshop to (at least partially) solve the problems.
The flip-chart page then is put up at a generally visible place (the kitchen, for example) and used as a starting point for discussions at the next meeting.
We just had our second workshop this week, so I don't know how well it will work out over time. The last workshop was rather constructive, though - certainly more promising than anything else I tried till know...
(BTW, the format of our workshop is heavily influenced by the "reflection workshops" mentioned by A. Cockburn in his book "Agile Software Development".)
Manas Ahlaad
Ranch Hand

Joined: Nov 07, 2001
Posts: 165
ilja,
good work.
keep going !
manas
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by manas ahlaad:
ilja,
good work.
keep going !
manas

Thanks!
One question though - did the description help you in any way?
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
there should be some diagram which communicates how did you view your requirements at first.
I find this a little puzzling. What sort of diagram might you use for requirements? It may be that we have different meanings for the word "requirements". (see some of the recent analysis/design threads for discussion of this point.)
I can imagine using diagrams to share solution design ideas, or even some of the information about existing systems and processes discovered during analysis. Are requirements not essentially just a collection of "must do" and "must not do"?
If your requirements are not in terms of "must do" and "must not do", how do you propose to ever test that the delivered system meets the requirements ?
The suggestion you gave ,"where diagrams are used to communicate software designs, they shall use the UML". we too thought of adding such a statement. But I doubt to what extent will it mandates people to do diagramming.
I have to ask what benefit you think you will get from the diagrams.
If you focus on the benefits, and make those part of your process, the developers can then be free to gain those benefits in whatever way works best for them. If diagrams turn out to be the best way to get results, they can use diagrams. If notes on index cards or a central shared whiteboard work better, they can use those.
Mark Milan
Ranch Hand

Joined: Oct 02, 2002
Posts: 59
Originally posted by Ilja Preuss:
Manas, in my experience it is best when process issues are self-imposed by a team (as opposed to imposed on the team by a manager/document/something else outside the team). There doesn't need to be an authority forcing the team to work a specific way if the team *wants* to work that way.

What you are describing here sounds like a team buying in to a particular process because they chose it (I could be interpreting you incorrectly). Unfortunately, the reality is that some organizations require a certain process to be followed, for whatever reason (standard compliance?). Some customers may not particularly like the idea of not having milestones, especially one that says "Product Delivered".
If an organization's Development process is flexible enough, then teams can work within it to achieve their goals, using their favourite design/programming methods. Mandating that "designs must use UML diagrams" places a restriction on the process*.
In Manas' case, having a Development Process that includes milestones/phases/requirements/etc is (IMO) a good thing, but insisting on UML is a decision that needs to be made by the project team.
Mark
*It can be argued that having a process is a restriction...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Milan:
What you are describing here sounds like a team buying in to a particular process because they chose it (I could be interpreting you incorrectly).

You are interpreting me correctly! In fact, they even don't choose a particular process, but specific practices and techniques (though I regularly try to infiltrate XP techniques; I even got them to mandate me holding a short Planning Game presentation - I plan to make it so convincing that they *have* to let a whole workshop follow... ).
Unfortunately, the reality is that some organizations require a certain process to be followed, for whatever reason (standard compliance?).

Yes. And some of the most effective teams in such circumstances are those that find a way to work around the imposed process to follow their own one.
I think that Alistair Cockburn is right when he says that every project needs it own adapted process.
Some customers may not particularly like the idea of not having milestones, especially one that says "Product Delivered".

Certainly. And a team aware of that problem should be able to work out a solution, so I think.
In Manas' case, having a Development Process that includes milestones/phases/requirements/etc is (IMO) a good thing

Certainly - and I would expect the team to find that out rather early, once they start to reflect about their process.
Mark Milan
Ranch Hand

Joined: Oct 02, 2002
Posts: 59
Ilja, Thanks for agreeing with my thoughts, but to return to the Manas' question - "How to induce (sic) RUP techniques in the existing process"
I remember a good example (perhaps given by Ilya?) about a Customer Requirement that took the form of "In screen X, show form Y, then go to form Z". Because the customer had actually included design in the requirements (failing to separate Analysis & Design), much time was wasted over how all the 200+ screens would look, rather than looking at the problem of "a web based system to (easily) do XX".
The question is - "how to introduce RUP?". Remember that RUP is a commercial version of UP, which comes with a whole bunch of costly tools. In the interests of Agile & XP, is this the "best" solution? Perhaps the questions to be asked of Manas' organization are: "What Process Currently Exists", "What Process Should Be Instituted", and "What Tools Will Help Conform With The Process". The question as it stands seems to have eliminated the analysis portion.
I'm not knocking RUP and the CC toolset (there are other who can do a better job than I ), but if your dogma/mantra is XP, then is RUP right for you?
Mark.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Milan:
Ilja, Thanks for agreeing with my thoughts

You're welcome!

I remember a good example (perhaps given by Ilya?)

I think it was Frank, but I'm not sure.
Because the customer had actually included design in the requirements (failing to separate Analysis & Design), much time was wasted over how all the 200+ screens would look, rather than looking at the problem of "a web based system to (easily) do XX".

In fact, even "web based" *might* already be to implementation specific for my taste...

The question is - "how to introduce RUP?". Remember that RUP is a commercial version of UP, which comes with a whole bunch of costly tools. In the interests of Agile & XP, is this the "best" solution?

I am a little bit confused. Isn't it the "interest of the project" that should matter?
Perhaps the questions to be asked of Manas' organization are: "What Process Currently Exists", "What Process Should Be Instituted", and "What Tools Will Help Conform With The Process". The question as it stands seems to have eliminated the analysis portion.

Yes, perhaps...
I'm not knocking RUP and the CC toolset (there are other who can do a better job than I ), but if your dogma/mantra is XP, then is RUP right for you?

If your *dogma* is XP, I think you don't really understand what XP is...
If you think that XP could help you to improve your software development process, but your company has buyed into "it needs to be costly and aapproved by a big company to be good", you possibly should take a look at the XP plugin or RUP: http://www.rational.com/tryit/rup/seeit.jsp#dnd7
Mark Milan
Ranch Hand

Joined: Oct 02, 2002
Posts: 59
Originally posted by Ilja Preuss (originally posted by me!):

In the interests of Agile & XP, is this the "best" solution?

You're right - the project matters. But let's not forget that unfortunately, real life pops its head up and there are other concerns besides doing the job right in the most elegant manner. Things like how much money your organization is willing to spend on tools, customer timelines, yada, yada, yada.
Utopia is a great place to program, but some of us are not there yet. You are correct to point us along the right path.
Mark.
Manas Ahlaad
Ranch Hand

Joined: Nov 07, 2001
Posts: 165
Ilja, surely that description helped me !
Coming to Frank's question, i will no more make it confusing , coming straight away to the point.
My organization is ISO certified, but the process adopted here does not talk about technical things.they talk about filling documents such as weekly activity reports, review meeting reports .. stuff like that. The responsibility of making the process technology oriented is given to some of our developer including me.
people will listen to words is those words are in process documents otherwise we can not question them.
Now when we went through entire SDLC 4 times in 4 real time projects for last 2 years.What I observed is some of the developers are not at al concentrating on design areas . proper analysis of requirements is not there. changes are made at coding stage and is not reflected in design. no iteration is done like that.
for all this to happen , i thought of including some guidelines for all the developers and include the guidelines as a document (put it as a process document so that people will have to adopt it and follow it) .
Then started actual struggle, what should i write in the document. that
"people should do good requirement analysis"
"people should draw diagrams"
people will laugh at me if i write something like this.
what do you do if you are given this responsibility
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I sympathise. Some people still insist that ISO certification has something to do with producing good products, when it is actually all about producing repeatable products. For an assembly line or a burger franchise that's great. For software which must meet different needs for every customer, that's crazy.
First, anything you put in such a document has to be both achievable and testable. So "just do good design, right" is out
Second, if you want to squeeze good software practices into your process, you should begin by looking at the results you want, and specify them first. But remember, documents and drawings are of no use to a customer who just wants a working, robust, maintainable system.
Perhaps at the start, just introduce some sort of customer acceptance process, and show how that is used to produce specific achievable, testable goals for each delivery. Then specify that if the customer's goals all pass, the delivery is complete.
If this seems good, you can look at a process for breaking down these "functional requirements" into achievable, testable sub-goals, which can be worked on by development teams.
Remember. It's no use just asking for something to be done, if you have no way of testing whether it was done well or badly. Mandate a diagram and you'll get one, but it could be a picture of Mickey Mouse or something just as useless.
Manas Ahlaad
Ranch Hand

Joined: Nov 07, 2001
Posts: 165
Thanks Frank !
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16101
    
  21

Personally I get REAL cynical about any software product that costs more than the machine it runs on.
I took the RUP tour not long ago and an admittedly superficial impression of it was that its main features were that it contained a set of basic design-process rules that I was already expected to know by the time I left college and a document-organization system which I could probably have implemented more effectively using Lotus Notes.
The actual UML part, is I believe, actually a discrete Rational product distinct from the RUP system, though it plugs into RUP. My (once again superficial) view of products like Rational Rose and Together/J is that they're great if your goal is to totally wallpaper your cubicle (and maybe the next 8 in line), but they have no sense of proportion - both at the component and method levels, they represent mainline and "helper" constructs as though they all carry equal weight, which does absolutely no good in attempting to home in on things (admittedly, determining what has weight is rather dependent on what you need to analyze at the time!).
They also seemed to want to replace the IDE I normally used with their own, less capable one, though I think(?) that some products do tie in to a greater or lesser degree to the industry standards such as Microsoft's Visual Studio.
In a case where adding some structure to the software design and lifecycle process is needed and you would like to be guided by proven processes, something like RUP may be beneficial. My concern is when instead of a guide it is a God (as in "You WILL be beaten until your morale improves!" ). Overall, if your shop has good talent and you have confidence in them, I'd recommend having THEM formulate a design process that meets YOUR organization's needs, not force-fit them to someone elses. You could then take the money saved on RUP and do something like buy 100 hours (US) of secretarial services and get some decent documentation written up.


Customer surveys are for companies who didn't pay proper attention to begin with.
Manas Ahlaad
Ranch Hand

Joined: Nov 07, 2001
Posts: 165
Thanks Tim !
.... I'd recommend having THEM formulate a design process that meets YOUR organization's needs...
As Frank says, we can not formultate design process since its purely intellectual thing.
What do you say? If we can do it,any guidelines?
TIA
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16101
    
  21

"Formulate" may not be the best word here - a "Formula" implies a mathematically rigid construct, and that's the main thing I advise against. One of the best ways I know to kill quality and productivity is to kill morale, and one of the best ways to kill morale is to attempt to reduce people to interchangeable cogs in a mindless machine.
Companies keep trying to do it, though. It's one of the oldest and most fallacious of the "Holy Grails" of software. Consider: if it can be done by mindless automatons, someone can write a program to do it, therefore people don't need to do it at all. So if I was to make a Rule #1, I think it would be: "Inventory the interests of your people". Rule #2 would be "Expect surprises". People often take an interest where you least expect it.
By and large, I got a lot of benefits out of the writings of people like Ed Yourdon and Fred (Mythical Man-Month) Brooks. No small amount of the RUP can be traced back to souch sources. I don't swallow everything they say unconditionally, however. Some concepts (like Brook's Chief Programmer Team) haven't panned out, and others - as I've said - may or may not work depending on your organization (the "YMMV" effect).
My own preferences go something like this:
1. When designing a project, DO get a good visualization of what the project is for. DON'T, however attempt to microscopically define all the goals. I've seen the Heisenberg effect in just about every software project I've worked with. It's just not worth the extra effort to pin down things which are likely to change anyway. The important thing is to never lose sight of the ultimate objective but never to confuse the forest with a specific set of of trees.
2. One thing I do agree with RUP is that milestones are important. I'm not much a believer in deadlines, but by breaking up a project into small deliverables, you keep the enthusiasm alive (both with developers AND the target audience), can spot trouble more easily, have places to fall back to in the event of failure, can better predict the REAL amount of time required to deliver, and reap various other benefits besides.
I am, BTW a big believer in prototypes and "proof-of-concept" projects. I neither believe in the "code and go - we're wasting programmer time" attitude that gave Fred Brooks problems in the OS/360 effort nor in the "design-first/code-after" approach. Rather, I favor design-and-try efforts going on more or less in parallel, but always keeping the target firmly in sight. The advantage here is that firstly, if you prove the concept early, you're less likely to commit resources to an impossible goal, and secondly, you keep the coder-types enthusiastic (reportedly the biggest challenge in managing software development ISN'T motivation, it's preventing DE-motivation). Thirdly, since this is the Real World we're dealing with, sometimes you may find it expedient to capture a prototype and use it as a validator for a production component, a fallback for a failing production component, or sometimes even make it BECOME a production component (if time/budget/management-interest blocks the more polished product).
I am, for myself a proponent of informal polling and a believer that well-designed systems come as much from the water cooler as from the staff room. Not all organizations are going to be happy with that idea, however. Like I said, the best plan is the one that works for YOUR organization. That's both a learning experience and a journey along a road that continually changes.
Manas Ahlaad
Ranch Hand

Joined: Nov 07, 2001
Posts: 165
Ilja, Frank, Tim
Thanks for your valuable inputs !
Manas
 
GeeCON Prague 2014
 
subject: RUP - Normal Process !