CSC/ECE 517 Fall 2007/wiki3 10 sb: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 32: Line 32:


===ASD doesn’t promote robust design===
===ASD doesn’t promote robust design===
#ASD allows individual developer to prefer his/her own process. [3] This may lead to inefficiency and sloppy software, coded to meet the end of iteration. If a suitable incentive system is not in place ASD may backfire. (A suitable incentive system may backfire too)
*ASD allows individual developer to prefer his/her own process. [3] This may lead to inefficiency and sloppy software, coded to meet the end of iteration. If a suitable incentive system is not in place ASD may backfire. (A suitable incentive system may backfire too)


#ASD depends largely on teamwork, self-organization, personal empowerment to achieve robust architechture[3]
*ASD depends largely on teamwork, self-organization, personal empowerment to achieve robust architechture[3]


In case of large projects, ASD promotes creation of software in a modular form by small teams or individuals in multiple iterations. However, there are multiple sources of evidence which suggest that the final step in bring together the smaller pieces takes much of time and results into an ineffective product. [5]
*In case of large projects, ASD promotes creation of software in a modular form by small teams or individuals in multiple iterations. However, there are multiple sources of evidence which suggest that the final step in bring together the smaller pieces takes much of time and results into an ineffective product. [5]


==Conclusion==
==Conclusion==

Revision as of 05:14, 12 November 2007

Assignment
The Agile debate. Perhaps the most prominent controversy in o-o design today is whether it is possible to do a robust design with as little advance planning as agile methodologies recommend. Research this issue, on the Web and in the ACM DL, and report (fairly) on the major arguments of both sides, and on the evidence for both positions.

Agile software development

Agile software development (hereafter ASD) is a model in Software Engineering to develop software through multiple iterations throughout the life-cycle of project. The result is a complex, high-speed, self-correcting methodology that occurs under conditions of high uncertainty, high change and high stress resulting into delivery of value to customer along with providing an adequate quality of life to team members.

Each iteration of ASD is an entire software project. The iteration includes planning, requirements analysis, design, coding, testing, and documentation. At the end of every iteration we have a deliverable product. Only at this point of time, the project requirements are re-evaluated and the requirements with highest priority are chosen by peer review, and on-site customer participation.

Pros

  1. Emphasize face-to-face communication.
  2. Requirement changes at any stage are welcome, since they can be incorporated in next iteration [1].
  3. A working software is delivered at the end of every iteration
  4. Agile infuses positive environment and promotes culture of motivation, collaboration and trust.
  5. Continuous attention to design

Cons

  1. The requirement for next iteration along with its completion date/budget are known since iteration is quick. However, the project completion date/budget is not always clear.
  2. The management has to be willing, to let go of micro management.
  3. Requires competent and trustworthy team members.
  4. Success of Agile methods in case of large scale development efforts and mission critical software’s is under doubt.
  5. Unsuitable for telecommuters
  6. Produces very little written documentation

Now that we have a good sense of what an Agile Software Development model means, we would elaborate on how it ensures that the deliverables are/aren’t robust.

ASD promotes robust design

  • ASD is a continuously self correcting process. The traditional model tries to do things right at the first time, however ASD tries to do things right at the first place as well, and fosters learning by looping in future iterations. [2]
  • Problems are design to be wicked and intractable and they can only be solved through repetitive emergent process and refinement, thus leading to a far better solution than granted by traditional models. [3]
  • ASD keeps room for future scalability of software. Software build on ASD principles remains lean, modular and scalable with every iteration. The waterfall model however produces code that is “fat”, monolithic and not scalable. These combined features dof ASD ensure that the code remains robust and reliable even after multiple releases. [3]

ASD doesn’t promote robust design

  • ASD allows individual developer to prefer his/her own process. [3] This may lead to inefficiency and sloppy software, coded to meet the end of iteration. If a suitable incentive system is not in place ASD may backfire. (A suitable incentive system may backfire too)
  • ASD depends largely on teamwork, self-organization, personal empowerment to achieve robust architechture[3]
  • In case of large projects, ASD promotes creation of software in a modular form by small teams or individuals in multiple iterations. However, there are multiple sources of evidence which suggest that the final step in bring together the smaller pieces takes much of time and results into an ineffective product. [5]

Conclusion

Teams using Agile software development may not have a robust structure in the first iteration/version, however as the developmenet goes on, the code grows more robust and reliable unlike waterfall where the code deteriorates on every release.

References

[1] Extreme Programming Explained: Embrace Change, K. Beck, Addison-Wesley,2000
[2] Ad Hoc Practices or Sound Principles, Lan Cao and Balasubramaniam Ramesh
[3] Agile Software Process and Its Experience, Mikio Aoyama [4] Theoretical reflections on agile development methodologies, Sridhar Nerur, VenuGopal Balijepally, 2007 [5] Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. Boehm, B.; R. Turner (2004).