Posted by: ahmedashfaque | March 1, 2016

agile and software project planning – part 1


Agile methodology was evolved because traditional waterfall model was not able to address the inherent risks associated with software projects. Waterfall model depends on creating a foolproof project plan and then executing this plan to create software products. But due to a large number of risks, these project plans are not foolproof. A customer may ask for a change in software requirements during project execution and this will result in project execution going haywire. The project tasks will slip from their planned time horizons. These customer change requests mostly happen because of changed market conditions. Since a software project may take more than a year to design and develop a software product, there could be many changes in market conditions in this long time horizon. Definitely this is a big risk which will jeopardize any project plan.

Then one more risk associated with software projects is ambiguous software requirements. Especially when all software requirements are needed to be given to the project team in the beginning of the project; it is difficult for the end users to define their software requirements correctly. Generally end users take time in refining their software requirements. Since the project team does not have much time in gathering software requirements; what they get from the end users is ambiguous software requirements. Ambiguous software requirements will create problems for software designers. Software designers need clear and accurate software requirements for designing the software product. So whenever software designers see ambiguous software requirements, they seek clarifications from end users. This kind of activity surely delays the software design process. This leads to slipping of software design tasks from their planned time horizons. Again the project plan will get jeopardized.

When software designs are complete, the software developers will take these software designs and write their source code. Developing too many pieces of the software product at the same time creates problems in integrating these parts with each other. What happens is that the developers are assigned parts of the software design and they work in parallel so that the software product is developed in least time. Each team of software developers work and develop pieces of software product in isolation to each other. Only after all parts of the software product are developed, integration of these software product parts is done. Integrating software parts this way creates many software integration problems. Sorting out all these integration issues takes a lot of time. This again leads to tasks delays. This again jeopardizes the project plan.

There are many more problems associated with plan driven software projects. We will learn them in the next post.

Advertisements

Responses

  1. […] the previous post we learned about risks on software projects and how plan driven project planning is not able to […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: