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

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 5: Line 5:
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.
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.
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===
===Pros===
#Emphasize face-to-face communication.
#It Emphasizes face-to-face communication.
#Requirement changes at any stage are welcome, since they can be incorporated in next iteration [1].
#Requirement changes are welcome at any stage, since they can be incorporated in the next iteration [1].
#A working software is delivered at the end of every iteration
#A working software is delivered at the end of every iteration
#Agile infuses positive environment and promotes culture of motivation, collaboration and trust.
#It infuses a positive environment and promotes a culture of motivation, collaboration and trust.
#Continuous attention to design
#It results in continuous attention to design


===Cons===
===Cons===
#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.
#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.
#The management has to be willing, to let go of micro management.
#The management has to be willing to let go of micro management.
#Requires competent and trustworthy team members.
#It requires competent and trustworthy team members.
#Success of Agile methods in case of large scale development efforts and mission critical software’s is under doubt.
#In the case of large scale development efforts and mission critical software, success of Agile methods  is still under doubt.
#Unsuitable for telecommuters
#It is unsuitable for telecommuters
#Produces very little written documentation
#It produces very little written documentation


==Comparison between Agile methodology and more traditional design==
==Comparison between Agile methodology and more traditional design==
http://pg.ece.ncsu.edu/mediawiki/images/3/36/Tradvsemerg.jpg
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.  
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 [http://en.wikipedia.org/wiki/Robust 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 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]
*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]
*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 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]
*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]
*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 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 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, personal empowerment to achieve robust architechture[3]
*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]
*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]
Line 50: Line 62:


==Conclusion==
==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.
There will never be one perfect methodology. The choice you make should always be dependent on the product requirements.  
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]
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]


==Summary==
The following series of images, borrowed from [6] for illustrative purposes, really summarize this debatable issue.<br>
The following series of images, borrowed from [6] for illustrative purposes, really summarize this debatable issue.<br>
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<br><br>
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<br><br>
Ad hoc development is development with no design<br>
Ad hoc development is development with no design<br>
[[Image:1_adhoc.JPG|center]]<br>
[[Image:1_adhoc.JPG|center]]<br>

Latest revision as of 18:27, 28 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.

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]

Summary

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