The Between Waterfall And Agile Software Development

* As explained in the text, scope creep is very common in projects. A formal change control management is difficult to enforce and more often overlooked near the end of the project when scope creep is more common. Recommend strategies to enforce change control

* As explained in the text, scope creep is very common in projects. A formal change control management is difficult to enforce and more often overlooked near the end of the project when scope creep is more common. Recommend strategies to enforce change control

The article Scope Management in Agile Versus Traditional Software Development Methods (Israr Ur Rehman, et al, October 2010, NSEC ’10: Proceeding for the 2010 National Software Engineering Conference) discusses the importance of scope management, it’s role and impact on a project, and how it alone can lead projects toward failure. “A well-defined and well managed scope is very important for a qualitative, cost effective and timely completion of the project (page 1). The replacement of traditional software development (Waterfall) by agile software development methods is very apparent in cost, resources and time for the work.

* As explained in the text, scope creep is very common in projects. A formal change control management is difficult to enforce and more often overlooked near the end of the project when scope creep is more common. Recommend strategies to enforce change control

The project will be managed using a modified waterfall technique. In this approach, the initial two phases of the

First, let’s take a look at Agile, in particular the role of scope. Several traditional software development models came about in the 1960s, such as incremental, spiral and waterfall modelling. Over time it was realized that the software development team did not realize all of the needs up front. Thus, the customer was was not delivered what was expected. It’s essential to have an outline of who, what, when and where but this is often a transforming list.

In addition, defining requirements can be difficult and sometimes early assumptions are flawed. Some opponents of Waterfall argue that it is impossible to fully understand the system requirements until the development phase and that some performance issues cannot be predicted or are not evident until the testing phase. Waterfall is not well-suited for custom software projects that rely heavily on continuous customer feedback and changing needs because communication and collaboration is not always stressed; once the requirements are established, the customer may have little contact with the development team until delivery. (Chatterjee, 2010) Because Waterfall projects are not based upon small iterations that can be easily and promptly modified, occasionally critical errors are found in the late stages of a Waterfall software development project that require scrapping the project and starting over; a very costly and disappointing result. Another negative is that some programmers believe that Waterfall is out-of-date and that it does not accommodate for the unknown factors that are a constant challenge in designing leading edge technology. Developers who abide by

Nowadays, the economy evolves rapidly and levels of competition force companies to adopt new approaches In order to keep up with market changes. Many large and medium scale companies have multiple projects and programs in progress, and they are using PMO as an essential part to apply to project management practices. Over time, many companies with long histories of successful PMO and project management practices may want to accelerate their project performance and adopt Agile as a new approach for their projects. As a result, this change can play an important role to raise different type of problems and difficulties between the existing PMO and Agile development team (Agile developers).

This “inspect-and-adapt” technique reduces the development cost and release time for the project is kept

Application requirements are provided by stakeholders and users for all development efforts. This is true for both agile and waterfall development projects. The difference is the amount of requirements that are provided. In the waterfall approach, all requirements are provided at the beginning of the project (Israr Ur Rehman, 2010, p. 2). Specifically, for a new application, the expectation is that stakeholders are able to provide all the requirements for the new application. Stakeholders, project managers, business analysts, users of the application meet to identify and document the requirements. Detailed application documentation is created, reviewed and signed off by the appropriate stakeholder (Ove Armbrust, 2011, p. 239). Following the agile methodology, requirements are defined for the phase to be delivered. The goal is to break up the application into iterations and define the requirements for the iterations or stories (Ove Armbrust, 2011, p. 239). In the agile implementations, the requests are stored in a backlog. This is the list stories remaining to be developed. Requirements documentation generated from a waterfall project is extensive; in contrast to agile where the documentation is limited to the story or stories to be developed (Ove Armbrust, 2011, p. 239). In my experience, the requirements documentation has been stored in a central repository to be referenced during the project.

Several adaptations to the traditional approaches like agile, interactive, phased, extreme, etc have been made but each will be expected to meet the requirements of the project objectives, timeline, resources, and deliveries of the stakeholders. Other industry standard certifications like ISO9000 and regulations like the Sarbanes-Oxley have also influenced methodologies and processes used by several organisations (Kerzner, 2003). Generally, managing projects should involved five major process which include the project initiation, planning, execution, monitoring and controlling, and then project closing. See Fig. 2 below.

and new demands from users (Uikey & Suman, 2012). The SDLC focuses on the prime

Lack of project planning is the most widely acknowledged primary cause of scope creep resulting in project failures (Munns & Bjeirmi 1996, 81-87). Therefore a good project planning process, following the PMBoK guideline (scope management and control) would increase the probability of project success. A formal Change request procedure is always a good way to handle scope creep or any changes coming from internal or external sources. A change request process is outlined below in figure -1 which could be used as a generic change control process within the scope of scope management process.

As it is with all decisions we make in the day, there are often multiple opportunities which often times lead to a single outcome. Such decisions as, “Do I take the turnpike today” can have such a profound impact on the outcomes. Will you hit traffic on turnpike and as a result miss a meeting. If you go the backway do you make the scheduled meeting? On any given day the same approach you have always taken can backfire. Keeping this in mind we must learn how the business methods we implement can often lead to the same outcome. What differs is the process

In a paper titled “Software Development Lifecycle Models”, Nayan B. Ruparelia describes many of the different options when developing software including the Waterfall model. The Waterfall model was one of the first true models documented for software development and “has underpinned all other models” (Ruparelia 2010) since inception. Originally developed by Herbert Benington in 1956 and later adjusted by Winston Royce in 1970 (Ruparelia 2010), the Waterfall method became an important and widely used process to get software into the workplace. The model follows a pattern of evaluation, requirements, analysis, design, development, validation, and deployment. Royce’s model also allowed for “iterative feedback” (Ruparelia 2010) that allowed a group to move to a preceding step if feedback was needed. One of the key tenants of the Waterfall method is heavy planning and documenting with a key goal of minimizing risk during coding. Also, collaboration is low across phases as each group in a phase would play a different part in terms of requirements and validation. Traditionally, the Waterfall model is used to develop large and complex software rollouts that require different experience levels and backgrounds to accomplish the overarching goal. Once the software is coded and deployed, the documentation allows for better understanding of what took place if a process needed to be revisited. Other variations of the Waterfall model have been documented but the original version is