CJP (Certifiable Java Programmer), AMSE (Anti-Microsoft Software Engineer)
Author of Posts in the Saloon
Originally posted by Kodo Tan:
Hi all
I have been pondering this for quite some time and maybe you guys can help me on this:
(1) We all know that for MOST modern project management, we should avoid waterfall methodology as it is restrictive, not adaptable to use changes, and other classic bad points about waterfall model easily found in any software project management books.
(2) For OO/J2EE projects, we are advised that one good approach is OOAD or iterative model and blah blah blah.
(3) Now here is my concern: In most projects teams I'm in, if I examine the schedule and resources planning carefully, I think it's more towards waterfall approach than anything else. For instance, for most project schedules, it is quite common to find the following:
(a) Project Initialisation Jan - Feb
(b) Users requirements Feb - Mar
(c) Functional specifications Mar - Apr
(d) Detailed Design Spec Apr - Jun
(e) Code Development Jun - Oct
(f) SIT Oct - Nov
(g) UAT Nov - Dec
(h) Prod Dec
Aren't the above a waterfall approach? If it's an iterative model, then where is
the schedule for iteration? :-)
Isn't it strange if the PLs of the teams use
such "waterfall" approach to schedule and plan resources their stands are supposed to be iterative ? Are they confused :-) or they have
some good project management reasons (that I'm unaware) to do so ?
Shubhrajit
Originally posted by Shubhrajit 1. Requirements definitely should not iterate.
2. Analysis also in my opinion should not iterate. Anyway it should not iterate for 90% of projects as it is directly derivable from requirements.
3. Design can iterate. However a competent SW firm will often freeze the design based on past experience and it is highly unlikely that it would change and thus iteration will not be necessary.
4. Construction will definitely iterate. This is a design principle we almost always follow. This is called a build cycle in the construction phase for iterative processes, and there will be multiple build cycles in the construction phase. In other words a construction phase can be said to constitute of multiple sub phases called build cycles...
5. Integration and System testing should happen only after all iterations ie all build cycles are over.
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
Originally posted by Shubhrajit 1. Requirements definitely should not iterate.
I strongly disagree. If you scotch changing requirements, you will prevent yourself from
- being able to react to changing business environments (after all, most software is developed to change the environment it is supposed to used in)
- using your learning experience of developing and using early versions of the product to improve the final product
IMO a much better strategy seems to be to "embrace change" - being prepared for changing requirements.
2. Analysis also in my opinion should not iterate. Anyway it should not iterate for 90% of projects as it is directly derivable from requirements.
As you might guess, I am disagreeing with this, too...
3. Design can iterate. However a competent SW firm will often freeze the design based on past experience and it is highly unlikely that it would change and thus iteration will not be necessary.
4. Construction will definitely iterate. This is a design principle we almost always follow. This is called a build cycle in the construction phase for iterative processes, and there will be multiple build cycles in the construction phase. In other words a construction phase can be said to constitute of multiple sub phases called build cycles...
I don't think it is a good choice to disunite what you call "designing" and "constructing". IMO coding is just designing at a finer scale (the "constructing" is in fact done fully automated by the compiler) and only by coding I get valuable feedback about the applicability of my larger scale design.
5. Integration and System testing should happen only after all iterations ie all build cycles are over.
So why wouldn't you want to get the very valuable feedback of automated tests from early on???
Shubhrajit
Originally posted by Shubhrajit Chatterjee:
1. Requirements definitely should not iterate.
2. Analysis also in my opinion should not iterate. Anyway it should not iterate for 90% of projects as it is directly derivable from requirements.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep
Originally posted by Doug Wang:
Dont speculate that requirements never change. You will fasten yourself and be of pretty slow response to business changes.
Shubhrajit
I wanted to mean that there should be a requirement control in your project.
You will have to freeze your requirement early on.
After the requirement is frozen and then there is a new requirement, then it should be taken as a scope change from project management perspective. This would result in a new plan for the project.
Why should you want to freeze your requirement ?
1. Suppose you are working on a fixed price contract for your client. Say about a week remains for final delivery when some person comes with a changed requirement which might require a change in the database design... how are you going to cope with it ?
2. You are slightly at ease when you are at a time and material contract. Still, you have to give a time estimate to your client. Now if these kind of requirement changes take place often, you will have a huge schedule slippage, which would not look good from a project management point of view.
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
CJP (Certifiable Java Programmer), AMSE (Anti-Microsoft Software Engineer)
Author of Posts in the Saloon
Shubhrajit
Originally posted by Sanjay Bahal:
Shubhrajit :
1. I think requirements do change- frequently and drastically often. The reason could be as simple as oversight/some manger forgot to give input OR something like the change in business environment.
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Consider Paul's rocket mass heater. |