Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Preferred methodology

 
Vedhas Pitkar
Ranch Hand
Posts: 445
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMHO, there's no one particular "development methodology" which would be applicable to all project sizes & scopes. For me, a mix of the waterfall model & the iterative model would work fine.

Start building on the iterative model, but the phases should be that of a waterfall model. This would ensure that the software is capable of sudden changes & also that everything is well documented.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What makes you want more waterfall?

I would like to wait longer for feedback on any decision.

I would like to discover bugs as late as possible.

I would like to invest in analysis and design for things that might not be built.

I would like to get my software in one delivery, all or nothing.

I'm being sarcastic of course, but I don't want to shut you down. Seriously, what would you like to have more of that waterfall gives you?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I share Stan's puzzlement. I'm especially puzzled by the statement that waterfall is better at allowing sudden changes than iterative development...
 
Pradeep bhatt
Ranch Hand
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Some developers hate change.They will complain when requirements are not fixed. Commonly heard -'Requirements are not known properly. How can we proceed' 'Things have changed suddenly. How can we incorporate it now ?'. I used to think like this before. May be because of this people like waterfall
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I would like to wait longer for feedback on any decision.
I would like to discover bugs as late as possible.
I would like to invest in analysis and design for things that might not be built.
I would like to get my software in one delivery, all or nothing.

Great Stan. You've summed up well the mess I'm in

I would like to invest in analysis and design for things that might not be built.

This makes me think about a program I've just finished. For testing purpose, I received a simulation sheet with all data patterns we may have. I was surprised that there were patterns I didn't even think of, and of course, did not support. I asked and I was told that there were no such patterns. So why did you put that in the doc ? "Well, we might have to support that one day. But not now. We just put everything here". I thought that was wasting both their and my time.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I probably remembered most of that list from the wonderful Waterefall 2006 convention site.

The practice of writing complete use cases and putting them under change prevention, er, control encourages us to put everything we can possibly think of in them. We start to think we're being paid by the pound and make up requirements all day long.

I've only gotten a fraction of the way into agile, but the bits that paid off the biggest were breaking use cases into story sized chunks and prioritizing them with real live index cards. At first a fair number of cards fell off the end of the sorting table, right into the trash. Eventually we just quit making up junk requirements.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic