• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

what is the most used process

 
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In terms of number of projects, what do experts think is the most used process(wrt to software Engineering).
What process is more applicable to the size and scope of project, those comments are also welcome.
Your bets about which will have longer lifespan, please give that input aswell.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I suspect that, sadly, the most used process is still "none."
 
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Among those projects I took part in, I found that people usually start think about the process at the very beginning. However, as time goes on, or maybe when the deadline is round the corner, people start rushing out a *workable* system, and put aside the process.
I guess, large firms, like IBM, SUN, etc, may still have the stardard guidelines on the process, however, the rest may not.
Nick
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ernest Friedman-Hill:
I suspect that, sadly, the most used process is still "none."


I was going to say "death march", but I suspect that's really the same answer....
 
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

guess, large firms, like IBM, SUN, etc, may still have the stardard guidelines on the process, however, the rest may not.


yes true most big companies use some sort of rup/standardised process. They skipped over waterfall, because that has a bad name in the industry (wonder why)
Management, again i came back to management, tell customers they are using rup, uml and all sorts of diagrams associated with RUP. Then in reality what happens is that when the design phase is over and functional and technical designs have to be updated, nothing happens. Developers use waterfall methods, and management preaches they used RUP extensively.
so it is down to perception whether your company uses RUP or any other guidelined process or not.
It is true, i am cynical about the processes, because mostly they end up the same way.
friso
ps. You can replace RUP with any guidelined process.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Then in reality what happens is that when the design phase is over...

In other words, neither the management nor the developers try to avoid the waterfall...
 
friso dejonge
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
true, but have you seen it any other way ?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by friso dejonge:
true, but have you seen it any other way ?


Yes. And I'm sure many of this forum's regulars have seen as well.
Unfortunately it's most often the developers who strive for iterations, rarely the management.
 
Author
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was just looking through this thread - and I realize it is NOT an IFM thread (and I was trying to be a little sensitive and NOT try to bring IFM into every conversation)... however I would like to raise what I think is a relevant point.
If management see the financial benefits of iteration - then they will do more than preach it, they will buy into it. IFM provides a strong financial rationale for iterative development, because iteration is an underlying principle for incremental delivery.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jane Cleland-Huang:
I was trying to be a little sensitive and NOT try to bring IFM into every conversation

Jane, now that you did bring IFM into every conversation ...
...would it be a reasonable guess that IFM would be more easily "understood" by management than the Throughput Accounting method described in Agile Management for Software Engineering? The problem I see with Throughput Accounting is that it takes more CPU cycles to grasp than a typical manager has to spare that it easily gets the shoulder simply because the audience doesn't understand the suggested approach.
 
Jane Cleland-Huang
Author
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well I have to admit that I haven't read this book. Could you give a brief synopsis?
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


The problem I see with Throughput Accounting is that it takes more CPU cycles to grasp than a typical manager has to spare that it easily gets the shoulder simply because the audience doesn't understand the suggested approach.


Does this be too *low level*?
I dont know much about Throughput accounting, but, I think, it is very *painful* for analysts if we need to quatify everything during the fesiability study. In addition, if we consider CPU cycles, how about I/O then? and network? many many things can be involved in fact.
Nick
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some big firms(like Sabre) started using XP. But,many of their developers do it because they had to follow corporate dictate rather than project/people's choice.
I have seen many other projects where there is time crunch to go the way of iterative approach and assiging difficult tasks to experts and easier ones to beginners etc.
[ April 29, 2004: Message edited by: Kishore Dandu ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kishore Dandu:
But,many of their developers do it because they had to follow corporate dictate rather than project/people's choice.


Where do you have this from?
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:

Where do you have this from?


Well, I have it from some friends working in XP environment in a particular company. They are just doing it because of their senior VPs dictate. They say, they would prefer a mix of XP and UP depending on customer and other resources at hand(since they have projects that last different time frames).
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jane Cleland-Huang:
Well I have to admit that I haven't read this book. Could you give a brief synopsis?


Ok. Throughput Accounting is derived from the Theory of Constraints (a software development process always has a bottleneck and everything should be subordinated to exploit that bottleneck until it's no longer the bottleneck) and is supposed to be a much better fit than traditional Cost Accounting, because...
From http ://www.cpaaustralia.com.au/Archive/9808/pg_aa9808_throughput.html:
Eli Goldratt argues that traditional cost accounting is 'public enemy number one' of productivity for two reasons. First, by using by efficiency rates as local performance measures, and measuring the volume variance, traditional cost accounting encourages the accumulation of inventories. Second, the cost accounting approach emphasises local cost reduction - a flawed strategy for continuous improvement, as costs can only be reduced to a certain minimum level. The goal of organisations is to make money now and in the future; therefore, an organisation's objectives from a throughput perspective will be to maximise throughput (sales, not production), minimise inventory and minimise operating expense.
Here's a couple more descriptions:
http://www.corbett-toc.com/eng/pag_09.htm
http://www.accountancysa.org.za/archives/1998sep/features/road.htm
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kishore Dandu:
I have seen many other projects where there is time crunch to go the way of iterative approach and assiging difficult tasks to experts and easier ones to beginners etc.

It might be the late hours in Finland, but what are you saying here? That the time crunch prevents from doing X or forces to do X?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kishore Dandu:
They are just doing it because of their senior VPs dictate. They say, they would prefer a mix of XP and UP depending on customer and other resources at hand (since they have projects that last different time frames).


What kind of variance in time frames are we talking about? There are plenty of projects that go on for ages and use XP to their success (think C3, which was a success for a couple of years until management started to dig the ground from under the team). Then again, if the project is going to last for two weeks or a month, would it really be better to use RUP instead (specifically, a tailored instance that's not close to XP)?
In short, I don't see how the variance in time frames should affect the "ideal" process for a project? I do, however, see how certain other aspects would have such an effect (legislative regulations, or life-critical problem domain, for example).
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kishore Dandu:
Well, I have it from some friends working in XP environment in a particular company. They are just doing it because of their senior VPs dictate.


Well, that's of course quite anti-XP. "People and Interactions over Processes and Tools."

They say, they would prefer a mix of XP and UP depending on customer and other resources at hand(since they have projects that last different time frames).


That puzzles me a little bit, too, for several reasons.
First, as Lasse I don't see how time frames would drive me not wanting to do XP. After the first iteration, an XP project actually is in "maintenance mode" and could probably go on forever, or so it seems to me.
And second, if they know that a project would be improved by adding some UP practices to it or even dropping some of the XP practices, XP actually asks them to do so.
 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
SDL (Software Development Lifecucle), combined with some OOAD, some UML diagrams, and some RAD (prototypes) seems to be most common in my limited experience. Iterative process has goods points in theory, but many veterans "powers-that-be" that is "managers and directors" cling to old ways.

UML Distilled points out well the combo-approaches commonly used. Newer IT departments (managers, too) try to include more modern design processes. In time, RUP, UP, Agile model will replace RAD, SDL, and combos, I think.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Note that DOD officially lifted their legendary "waterfall bias" already years ago, realizing that an iterative approach seems to be the only way to avoid multi-billion dollar failures... Even Winston Royce wrote in his classic waterfall paper that waterfall (~SDLC) works for only the simplest of projects and that you should always iterate at least once.

Obviously none of these facts made their way to the ears of the powers that be, which leaves us with what we've got today...
[ July 27, 2004: Message edited by: Lasse Koskela ]
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tom Hennigan:
SDL (Software Development Lifecucle), combined with some OOAD, some UML diagrams, and some RAD (prototypes) seems to be most common in my limited experience. Iterative process has goods points in theory, but many veterans "powers-that-be" that is "managers and directors" cling to old ways.

UML Distilled points out well the combo-approaches commonly used. Newer IT departments (managers, too) try to include more modern design processes. In time, RUP, UP, Agile model will replace RAD, SDL, and combos, I think.



I agree with ur first paragraph. Second paragraph becoming a reality may take some time(except for the expensive consultants from Accenture and Bearingpoint trying to do it)
 
reply
    Bookmark Topic Watch Topic
  • New Topic