Agile versus Waterfall - Essay Example

?AGILE VERSUS WATERFALL Agile Versus Waterfall Affiliation Introduction System development is a team based activity which is completed by following a particular project management approach. In this scenario, a project management approach is a map which guides the software development team all the way through the project life cycle. It tells project management team what tasks they need to perform at certain level/stage of project life cycle (Hughes & Cotterell, 2002). In addition, there are many project management approaches that are used in different project scenarios. Every project management approach has similar stages but they are completed in different ways. This paper presents an analysis of two different project management approaches in the context of an e-commerce web site. This paper basically compares and contrasts agile and traditional project management approaches. In this scenario, we are going to manage the development of an e-commerce web site. I have been assigned the responsibility of a project manager to manage our company’s e-commerce Website where customers can browse the company’s products, place orders, and interact with the company’s customer service representatives. We have been given a deadline of three months to complete this project and we have approximately twelve people in the team. There are three offshore developers in Ireland and two QA testers in Dallas, TX. In addition, the remaining project team and the product owner are in San Diego, CA. 1. Comparative Analysis of Agile and Traditional Project Management Without a doubt, agile project management approach has been developed to deal with a variety of issues and pitfalls those were not addressed by the traditional project management approach effectively. In this scenario, some of the important issues can include delivering high quality software promptly under quickly and continuously changing business environment and requirements. It is believed that agile project management approaches have an excellent reputation in the IT and software sector. The research has shown than more than 69% of IT firms are adapting one or more of agile methodologies for use in common project management as well as organizational development (Lucia & Qusef, 2010). In spite of all the attractions that have been brought by the agile project management approaches, a large portion of state-of-the-art organizations (in all the categories e.g. packaged software, web-based software, or software/hardware systems) still adopt the traditional approaches to project management that have already been used for so many years. One of the most attractive features of this traditional project management approach is its support for the requirements documentation. In this scenario, this documentation includes requirements documents and specification documents. However, it depends on the firms who they use these terms. In fact, in many cases these two terms may indicate the same thing and are identical, or in some cases they can indicate the completely different parts of the process. In this scenario, the title of the document is not important, however its intended idea and information is delivered in some way with the purpose that the technical team could get an idea of the intended solution to a market problem that is being resolved with what goals. Normally, smaller project and updates can have a limited set of documents, while a larger, riskier project can require more documentation (Product Arts1, 2012; Kotonya & Sommerville, 1998; Product Arts, 2009). The research has shown that the requirements engineering process heavily depends on documentation for knowledge sharing while agile project management approaches are based on face-to-face collaboration and communication between developers and customers in order to reach similar goals. In this scenario, agile project management approaches do not take into consideration the documentation aspect effectively. On the other hand, in traditional project management approach there is minimum customer communication which can raise a number of issues related to requirements change or misconceptions. Hence, the mitigation of these issues can become a challenge at the final stages. It is believed that traditional project management approach is suitable for large size projects while agile project management approaches are designed for the management of small scale projects (Paetsch, 2003; Rehman, ullah, Rauf, & Shahid, 2010). 2. Selection of a Project Management Approach In case of our e-commerce web site development, I will choose agile project management approach. As discussed above, this project involves the development of an e-commerce web site and we have proper mechanisms for communication with the customer. In addition, we have been given a deadline of only three months to complete this project. In this scenario, the selection of an agile project management approach can help us complete this project in time. On the other hand, traditional project management approach is a step by step approach. We cannot initiate an action until its pre-requisite or associated tasks are not completed. Figure 1Traditional Project Management Approach 3. Pitfalls and Misconception in selected Approach Customer/Stakeholder Involvement Though, agile project management approach highly promotes customer involvement throughout the project life cycle. However, in some cases this involvement becomes a challenge, such as: agile project management methodologies require the customer to be always accessible to respond any issues and questions raised by the software development team. On the other hand, any delay in the response will surely cause delay in the software development process. In addition, a large number of organizations reported that achieving onsite customer representation is difficult (Sillitti & Succi, 2012; Cao & Ramesh, 2009). Complete Knowledge In some cases, there may be a representative for all the project stakeholders. For that reason, he cannot provide suitable answers to all questions, unless he is the domain expert and have knowledge of how the application should work and the input/output data required. This situation becomes more critical when the size of the project increases (Sillitti & Succi, 2012). In many cases the customer does not have the power to take decision and he needs to take permission of top management, which can take a lot of time. Documentation Agile project management methodologies hardly have complete and dependable requirements documentation. Additionally, asking questions to other team members will surely delay work, due to the time required to clarify a large project. However, these long term problems are reduced as agile methods often generate compact and clean code (Paetsch, 2003; Moccia, 2012; Davies, 2013). Non-functional requirements Agile project management approaches do not effectively deal with non-functional requirements. In this scenario, systems users describing the system requirements what they want the system to do usually do not take into consideration associated non-functional requirements such as maintainability, resources, safety, performance and portability. In fact, in some cases non-functional requirements can be related to functional requirements and are hard to explain. However, the majority of non-functional requirements should be identified in development for the reason that they can have an effect on the selection of programming language, database or operating system (Paetsch, 2003). Mitigation and Solutions One of the most effective solutions to deal with all the above mentioned issues is to combine some of the useful features of traditional project management approach with agile project management approach. For instance, in case where we need to ask questions again and again and need more knowledge from the customer. We can use proper documentations and we can document all the requirements given by our customers. In this scenario, this documentation will be served as a guide for other software developers who will join our software team in coming era. In view of the fact that an e-commerce web site is based on many non-functional requirements such as usability requirements so it can be useful for us to use documentation. We can document all the non-functional requirements in a document and implement it in a proper manner. The use of limited documentation can help us deal with a number of serious challenges. References Cao, L., & Ramesh, B. (2009). Agile Requirements Engineering Practices: An Empirical Study. IEEE Software , 60-67. Davies, R. (2013). Agile Requirements. Retrieved October 14, 2013, from http://www.methodsandtools.com/archive/archive.php?id=27 Hughes, B., & Cotterell, M. (2002). Software Project Management GLASGOW: MCGRAW-HILL PUBLISHING COMPANY, 2002. (3rd ed.). Glasgow: McGRAW-HILL Publishing. Kotonya, G., & Sommerville, I. (1998). Requirements Engineering Processes and Techniques. New York: John Wiley and Sons. Lucia, A. D., & Qusef, A. (2010). Requirements Engineering in Agile Software Development. Journal of Emerging Technologies in Web Intelligence, Volume 2 Issue 3, 212-220. Moccia, J. (2012). Agile Requirements Definition and Management. Retrieved October 14, 2013, from http://scrumalliance.org/articles/398-agile-requirements-definition-and-management Paetsch, F. (2003). Requirements Engineering in Agile Software Development. University of Calgary. Alberta, Canada: University of Calgary. Product Arts. (2009). Agile Requirements – So What’s Different? Retrieved October 13, 2013, from http://www.product-arts.com/attachments/article/204/Agile_Requirements_-_So_What's_Different.pdf Product Arts1. (2012). A Tour of Requirements Documents. Retrieved October 12, 2013, from http://www.product-arts.com/articlelink/138-a-tour-of-requirements-documents Rehman, I. U., ullah, S., Rauf, A., & Shahid, A. A. (2010). Scope management in agile versus traditional software development methods. NSEC '10 Proceedings of the 2010 National Software Engineering Conference (p. 10). ACM. Sillitti, A., & Succi, G. (2012). 14 Requirements Engineering for Agile Methods. Retrieved October 12, 2013, from http://www.agile-itea.org/public/papers/sillitti-succiV2.pdf Read More