CSC/ECE 517 Fall 2009/wiki3 7 f1

From Expertiza_Wiki
Revision as of 02:36, 10 November 2009 by Suze (talk | contribs) (→‎References)
Jump to navigation Jump to search

This wikipedia article focuses on how Agile software development methodology can complement other traditional design methodologies like the waterfall model. We take a few software development practices from the customer, management and development points of view, focus on the limitations of the traditional software development model and discuss how agile development methodologies can be used to complement/overcome its limitations.


Agile vs Traditional Methodologies

The agile manifesto focuses on

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, agile values the items on the left more. The items on the right are what the traditional design methodologies emphasise on.

Some of the advantages of the agile method are explained below:

  • Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.
  • Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.
  • Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.
  • Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.
  • However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.


References

1. XP 2006 Website 2. Agile Development Conference 3. Experience Paper: Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects- Ahmed Elshamy and Amr Elssamadisy 4. Research Paper: Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams, Grigori Melnik, Frank Maurer 5. Rolling the DICE for agile software projects, Bartlomiej Ziolkowski, Geoffrey Drake 6. Incorporating Learning and Expected Cost of Change in Prioritizing Features on Agile Projects, Scott Harris, Mike Cohn

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki3_7_f1&oldid=26508"