A project goes through stages and distinct phases in development cycle. How these phases relate and interact to make the project successful is driven entirely by the needs of the customer. We are going to discuss the models for software development projects here. At one extreme is where one has a clear set of requirements and he is ready to wait for pre-defined time when the provider gives him a turn-key solution. At the other extreme is the completely agile model which lets you develop small increments to the product. These increments are fully functional and robust solution to a small set of requirements. What requirements are to be taken in the next increment is decided entirely based on the customer’s priorities. You have every possible variation to these extreme models in between. How you execute the project would obviously depend on the execution model being followed.

Philosophical Basis (of Models)

The underlying philosophical underpinning of the waterfall model is that you know the “complete” set of requirements of the project to be undertaken. Given the requirements are completely known and understood the phases follow each other sequentially. The model is named waterfall as the execution follows the way a waterfall over several sequential steps flows to next step. Requirements finalization is followed by top level and detailed design followed by development, QA & testing and the release of the complete product. One can clearly see that any plan based on a model like this will go completely haywire if there is any change in the requirements at any time during the complete lifecycle.

This is quite often an unrealistic assumption and things change. Things change and it may be beyond the control of even the customer. He may have needs about some part to be delivered first as the set of requirements for that part may be very important for demonstrating to his own customers/users in turn. Your customer may not completely understand what is needed. This approach of delivering in increments helps the customers in crystallizing his needs.

Several execution models came into being to take care of such real life situations. An “agile” model that can take care of the “change is life” situations has come into being. Projects are done in small increments in time but to the completeness level where this increment is robust like a commercial product is developed. Customer decides on a small set of features based on his priorities. After every increment is delivered and new set of requirements for the next increment is given to developers. They take this through the complete life cycle and deliver the next increment.

There are several ways agile models can be executed. The list below provides a list of few popular agile models (at least I know of :)

There are many models in between with few major to minor variations, however, aligned strongly with Agile Alliance Manifesto

These modifications are based on how often the product/project increments are required. While agile is the way to go when you may be developing something competitive or something new that needs to have a short time to market and must change based on market research inputs, there could be projects that can tolerate less frequent increment.

A project goes through stages and distinct phases in development cycle. How these phases relate and interact to make the project successful is driven entirely by the needs of the customer. We are going to discuss the models for software development projects here. At one extreme is where one has a clear set of requirements and he is ready to wait for pre-defined time when the provider gives him a turn-key solution. At the other extreme is the completely agile model which lets you develop small increments to the product. These increments are fully functional and robust solution to a small set of requirements. What requirements are to be taken in the next increment is decided entirely based on the customer’s priorities. You have every possible variation to these extreme models in between. How you execute the project would obviously depend on the execution model being followed.

Philosophical Basis (of Models)

The underlying philosophical underpinning of the waterfall model is that you know the “complete” set of requirements of the project to be undertaken. Given the requirements are completely known and understood the phases follow each other sequentially. The model is named waterfall as the execution follows the way a waterfall over several sequential steps flows to next step. Requirements finalization is followed by top level and detailed design followed by development, QA & testing and the release of the complete product. One can clearly see that any plan based on a model like this will go completely haywire if there is any change in the requirements at any time during the complete lifecycle.

This is quite often an unrealistic assumption and things change. Things change and it may be beyond the control of even the customer. He may have needs about some part to be delivered first as the set of requirements for that part may be very important for demonstrating to his own customers/users in turn. Your customer may not completely understand what is needed. This approach of delivering in increments helps the customers in crystallizing his needs.

Several execution models came into being to take care of such real life situations. An “agile” model that can take care of the “change is life” situations has come into being. Projects are done in small increments in time but to the completeness level where this increment is robust like a commercial product is developed. Customer decides on a small set of features based on his priorities. After every increment is delivered and new set of requirements for the next increment is given to developers. They take this through the complete life cycle and deliver the next increment.

There are several ways agile models can be executed. The list below provides a list of few popular agile models (at least I know of :)

There are many models in between with few major to minor variations, however, aligned strongly with Agile Alliance Manifesto

These modifications are based on how often the product/project increments are required. While agile is the way to go when you may be developing something competitive or something new that needs to have a short time to market and must change based on market research inputs, there could be projects that can tolerate less frequent increment.

Project Lifecycle

August 11, 2009
By

A project goes through stages and distinct phases in development cycle. How these phases relate and interact to make the project successful is driven entirely by the needs of the customer. We are going to discuss the models for software development projects here. At one extreme is where one has a clear set of requirements and he is ready to wait for pre-defined time when the provider gives him a turn-key solution. At the other extreme is the completely agile model which lets you develop small increments to the product. These increments are fully functional and robust solution to a small set of requirements. What requirements are to be taken in the next increment is decided entirely based on the customer’s priorities. You have every possible variation to these extreme models in between. How you execute the project would obviously depend on the execution model being followed.

Philosophical Basis (of Models)

The underlying philosophical underpinning of the waterfall model is that you know the “complete” set of requirements of the project to be undertaken. Given the requirements are completely known and understood the phases follow each other sequentially. The model is named waterfall as the execution follows the way a waterfall over several sequential steps flows to next step. Requirements finalization is followed by top level and detailed design followed by development, QA & testing and the release of the complete product. One can clearly see that any plan based on a model like this will go completely haywire if there is any change in the requirements at any time during the complete lifecycle.

This is quite often an unrealistic assumption and things change. Things change and it may be beyond the control of even the customer. He may have needs about some part to be delivered first as the set of requirements for that part may be very important for demonstrating to his own customers/users in turn. Your customer may not completely understand what is needed. This approach of delivering in increments helps the customers in crystallizing his needs.

Several execution models came into being to take care of such real life situations. An “agile” model that can take care of the “change is life” situations has come into being. Projects are done in small increments in time but to the completeness level where this increment is robust like a commercial product is developed. Customer decides on a small set of features based on his priorities. After every increment is delivered and new set of requirements for the next increment is given to developers. They take this through the complete life cycle and deliver the next increment.

There are several ways agile models can be executed. The list below provides a list of few popular agile models (at least I know of :)

  • SCRUM
  • Extreme Programming
  • Dynamic System Development Model
  • Rational Unified Process

There are many models in between with few major to minor variations, however, aligned strongly with Agile Alliance Manifesto

These modifications are based on how often the product/project increments are required. While agile is the way to go when you may be developing something competitive or something new that needs to have a short time to market and must change based on market research inputs, there could be projects that can tolerate less frequent increment.

Popularity: 1% [?]

Tags: ,

Leave a Reply

Your email address will not be published. Required fields are marked *