Agile methods are one of the most recently conceived methodologies for developing software intensive systems. Agile methods refer to a family of methods that tend to favor working code over documentation, individuals over tools, collaboration over negotiation and thriving in volatile environments over following a plan ("Agile Manifesto" 2001). However, agile methods are not indicated for all projects; project managers, with organizational support, must decide if agile methods will provide the most benefit over conventional software engineering methods for developing new software intensive projects. What I hope to ascertain is that agile methods are probably not appropriate for large, stable, well understood, long lasting projects but are well suited for rapidly deployed systems that require responsive, flexible development with smaller, short-term projects. The additional prerequisites are that the software provider's organization must be willing to support such methods and that there is sufficient collaboration from a knowledgeable customer base. This paper will briefly present background material for the introduction and motivation for agile methods. Next, the critical factors that influence the selection of software development methodology is discussed, comparing agile and conventional methods. Then, using these observations, a single software development application is examined to determine if agile methods would be appropriate.
Methodologies are one of four major factors that need to be taken into consideration in the field of software engineering (Nance, slide 40, Session 1). Methodologies are an organized, documented set of rules and practices that provide a framework to guide a software project from concept, requirements collection, and design, through implementation maintenance and retirement of the product. Rico (n.d.) describes five major periods covering 50 years of computer history (mainframe, midrange, micro, internet and personal) and identifies 32 of the foremost methodologies that emerged within each time period. His work shows that essentially, methodologies evolved as a reaction to a) failures or inadequacies of earlier methods, b) opportunities arising from the revolution in technology or c) changes in business perspectives including information-age economics. Conventional methodologies, such as Structured and Object Oriented (OO) methodologies are also known as heavyweight methodologies because they typically include numerous rules, and documents, require a lot of time to develop and bureaucratic in nature (Fowler, 2003; Cockburn n.d.). However, even with the structured nature of these methodologies, the majority of software projects developed has not produced software products that are within budget; meet their performance goals; or success criteria (Nance, slide 15, Session 1). Other names for heavy weight methodologies include plan-driven, rigorous, predictive and "thick". In contrast, lightweight methodologies have few rules and practices; strive for a compromise between no process and unwarranted process, favor working code over excessive document and collaboration over contract negotiation (Constantine, 2002; "Agile Manifesto" 2001). Light weight methodologies go by names such as agile, adaptive and "thin". These light weight or agile methods are characterized by small releases, collaborative communications between developers and customers, simplicity and their ability to react quickly to changing requirements (Abrahamsson, 2003; "Agile Manifesto" 2001). Figure 1, Evolutionary map of agile methods, depicts the evolution of agile methods in time. . Figure 1. Evolutionary map of agile methods. Source: Abrahamsson (2003), figure 1 page 246.
Selecting a methodology
Deciding what software development methodology to implement depends on many factors such as project priorities and project types. Project priorities would include factors such as scheduling, quality and...
References: Abrahamsson, P., Warsta J., Siponen M., & Ronkainen, J. (2003). New directions on agile methods: a comparative study. 25th International Conference on Software Engineering (ICSE '03). Retrieved June 13, 2005 from Web Site: http://csdl.computer.org.ezproxy.umuc.edu/dl/proceedings/icse/2003/1877/00/18770244.pdf
"Agile Manifesto" (2001). Manifesto for agile software development. Retrieved Jun. 18, 2005, from http://www.agilemanifesto.org.
Alleman, G. B., Henderson, M., & Seggelke, R. (2003). Making agile development work in a government contracting environment - measuring velocity with earned value. Agile Development Conference (ADC '03), pp. 114. Retrieved June 15, 2005 from University of Maryland University College, Information and library services Web Site: http://www.umuc.edu/library
Ambler, S. W. (2005). Examining the cost of change. Retrieved Jul. 16, 2005, from Agile Modeling Web site: http://www.agilemodeling.com/essays/costOfChange.htm.
Anderson, D. (2004). Agile management for software engineering. Upper Saddle River, NJ: Prentice Hall.
Cockburn, A. (n.d.). A methodology per project. Retrieved Jul. 22, 2005, from http://alistair.cockburn.us/crystal/articles/mpp/methodologyperproject.html.
Constantine, L. L. (2002). Process agility and software usability: toward lightweight usage centered design. Retrieved Jul. 12, 2005, from the usage-centered design resource Web site: http://www.foruse.com/articles/agiledesign.pdf.
Please join StudyMode to read the full document