CSC/ECE 517 Fall 2007/wiki3 10 sb

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

Comparison between Agile methodology and more traditional design

http://pg.ece.ncsu.edu/mediawiki/images/3/36/Tradvsemerg.jpg

Now that we have a good sense of what an Agile Software Development model means, we delibrate 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 designed 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 of ASD ensure that the code remains robust and reliable even after multiple releases. [3]

• ASD is very well suited for projects where the requirements are constantly changing or are not well defined. [6]

• The lowered distribution costs nowadays (due to the Internet) it is economically feasible to release more versions of incrementally greater value at a high frequency and also gain very valuable feedback. [6]

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. (An 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 bringing together the smaller pieces takes much of time and results into an ineffective product. [5]

• ASD results in an added expense of having more routine code rework and having to maintain all development code close to release-quality, which may prove to be very expensive and even end up in a software with large structural errors [6]

• ASD by definition results in little documentation being produced.

Conclusion

There will never be one perfect methodology. The choice you make should always be dependent on the product requirements. It seems that agile methodology is very well suited for exotic technology,volatile requirements, lack of high-level architecture expertise, or lack of high user experience standards. Besides one can always mix the two approaches. We found a very interesting paper on trying to mix the traditional Capability Maturity Model Integration [CMMI] model with agile methodologies which would then result in a more complete design. [7]

The following series of images, borrowed from [6] for illustrative purposes, really summarize this debatable issue.
You will basically see a series of images, the goal being to design Da'Vinci's Monal Lisa, this is to be compared with a goal of designing a perfect software project

Ad hoc development is development with no design

Traditional approaches aim for this scenario

Agile methodologies aim for this scenario

Traditional approaches may have the following two risks

Agile methodilogies may have the following risk

All in all we must strive for this scenario

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)
[6] Are agile methods good for design?. interactions, Volume 11 , Issue 1, Pages: 14 - 23 .John Armitage
[7] Agile Development: Good Process or Bad Attitude? Richard Turner