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.

Every iteration of ASD is a software project in itself. 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. The requirements with highest priority are chosen by peer review and on-site customer participation. These are now used in the next iteration.

Pros

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

Cons

1. The requirements for the next iteration along with its completion date and budget are known since each iteration is quick. However, completion date and budget for the whole project is not always clear.
2. The management has to be willing to let go of micro management.
3. It requires competent and trustworthy team members.
4. In the case of large scale development efforts and mission critical software, success of Agile methods is still under doubt.
5. It is unsuitable for telecommuters
6. It 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 shall deliberate on how it ensures that the deliverables are/aren’t robust.

What is Robustness?

First of all lets see what Robustness means

Robustness is defined as "the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance. A system, organism or design may be said to be "robust" if it is capable of coping well with variations (sometimes unpredictable variations) in its operating environment with minimal damage, alteration or loss of functionality." (From Wikipedia)

Nowadays software is becoming the centerpiece of life itself. Thus we want the software to be as robust as possible.

Robust design is one which leads to robust software.

Now, Lets continue to the deliberation.

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 thus 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 built 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]

• Due to the lowered distribution costs nowadays (thanks 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 developers to prefer his/her own process. [3] This may lead to inefficiency and sloppy software, coded to meet the end of the 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 and 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 methodologies are 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 Leonardo da Vinci's Mona Lisa, this is to be compared with the 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