19 March 2013 Change Requests in Software Engineering

Download 25,93 Kb.
Date conversion15.02.2017
Size25,93 Kb.

Scott Ning

Professor Jones

SE 459

19 March 2013

Change Requests in Software Engineering

The possibility of making changes during the project development lifecycle is very likely. Clients may change their minds and request modifications to the originally-agreed-upon project requirements, technologies can change, the importance of the project’s features may alter, or even external factors may influence change requests. While these are among the many reasons for changing the original list of requirements, there will most definitely also be a continual cycle of change requests even after the deployment of a project, during its maintenance phase. Whether using engineering practices such as Agile, Waterfall, or Spiral, the notion of change is almost unavoidable in any project and being prepared to handle changes is a very important aspect of a project’s lifecycle. Therefore, knowing the way these practices handle such changes is extremely useful, and even more useful when understanding Agile’s approach compared to its counterparts. Recognizing the similarities and differences between other engineering practices’ and Agile’s change principles, benefits, more-welcoming change processes, change management, fluidity and locking of changes, values and beliefs, and influences on business and cost, is essential.

Agile embraces change and accepts the idea that requirements will evolve throughout a project. Due to this acceptance, Agilists are not limited and locked out of changes, but rather, they are able to “strive to truly manage change, not to prevent it” (Agile Requirements Change Management 2). In contrast, the Waterfall approach does not allow room for changes; requirements are locked and, thus, this brings forth a “painful change management process” (Waterfall - The Monkey's Paw of Software Development 2). Agile believes in flexibility while Waterfall believes in structure; Agile expects requirements to change versus Waterfall requires that requirements are clearly defined initially. Therefore, the values regarding change between these two practices differ through the fact that “[i]n Agile, you get the product you need and in Waterfall, you get the product that you initially asked for” (2).

Many Agile values assist its fluidity of changes. One value that Agile practices is the concept of simplicity and one way that simplicity can be achieved is through the delivery of only necessary functionality and delivering them in increments, thus keeping complications to a minimum and keeping models simpler. As conveyed in Bhakti Satalkar’s article, Agile Model, “[i]f the system is complex, then it will take a lot of time to incorporate these changes” (14). In an Agile world, because the delivery of a project’s functionality is done at consistently shorter intervals and developed in smaller batches, as opposed to Waterfall’s longer and bigger delivery periods, changes can easily be introduced into each set of deliveries. Therefore, this allows more room for adapting to the changing circumstances.

Another Agile value that assists its fluidity of changes is the belief of always delivering the highest business value first. According to Jeff Sutherland’s online article, Agile Principles and Values, customer satisfaction is vital and in order to succeed, change must be planned for. To accomplish this and “[f]or teams to create products that will please customers and provide business value, teams must respond to change.” As opposed to the opposite, even “when traditional projects finish on time, on budget, with all features in the plan, customers are often unhappy because what they find is not exactly what they wanted.” As a result of following this value, Sutherland claims, customers are much happier (22-23).

But in order to know the highest business value, teams must communicate efficiently and seek it out. Sutherland references Humphrew’s law, saying that “customers never know what they want until they see working software. If customers do not see working software until the end of a project, it is too late to incorporate their feedback.” This is where another Agile value supports a more fluid change management; communication, feedback, reviews are imperative for determining a customer’s satisfaction and the steps that lead to such satisfaction. Sutherland explains that this “is why they have established processes, such as reviews and retrospectives that are specifically designed to shift priorities regularly based on customer feedback and business value.” Because Agile values communication and feedback during a project lifecycle, Agile will have teams seek customer feedback so that the new information can be incorporated into the project during development (22-23).

These Agile values enable many benefits for many parties, and more importantly, to the business stakeholders. Business stakeholders, specifically, are allowed more fluidity to “add new requirements, change priorities, or rework existing requirements whenever they want” (Agile Requirements Change Management 13). Because newer and more appropriate requirements or functionality can be accomplished much easier, and without disagreement, the many business stakeholders’ requests are much more often fulfilled. Therefore, this extraordinary flexibility, in-turn, can also strengthen relationships. Building relationships is important and therefore, Agile’s approach to change positively influences much business stakeholders and their values (The Process of Change - The Agile Change Agent 6).

Another benefit to Agile’s more-welcoming change process is that it strives to keep costs minimal and the cost of change is generally lesser than other alternative engineering practices. Their strategy for keeping costs at a minimal is due to their strict minimalistic-doing behavior; Agilists do not waste time, effort, and costs on implementing any unnecessary functionality. Agilists understand that “requirements evolve over time” and “any early investment in detailed documentation will only be wasted” (Agile Requirements Change Management 1). Because of this, Agilists simply do just enough initial requirements and stay within project scope; they follow the idea of focusing only on necessities and since those are “all you really need early in a project, so that’s all you should do” (1). Therefore, extra wasteful costs can generally be better avoided.

In relation to change management, because of their belief of only doing what needs to be done and not solidly locking requirements, change requests are deemed as a need and can be more welcomingly adapted into their project and project’s costs. Unlike Agile, Waterfall freezes requirements, making change requests more costly, difficult, and overall, really unwelcomed. According to James Christie’s article, Usability and Traditional Development Lifecycles, Christie explains that many factors within the Waterfall principles discourage change; whether it is soft costs such as an already-determined state-of-mind or hard costs such as the tedious and time and effort consuming process of modifying contracts and project plans, changes are difficult to make during the Waterfall development lifecycle. Christie states that “I don't say it's impossible, but that it would be difficult to do because of the mind-set that the Waterfall encourages. The way that contracts are written, and project plans defined, for such projects is a powerful discouragement to early usability testing and iteration” (5). All these overhead processes that need to be modified, simply for granting a change, can drastically lower overall productivity.

While an Agilist’s approach to alterations evidently brings forth benefits for managing costs, it also brings forth uncertainty. One of which is that the cost and time for the project would be less clear. “It isn’t clear how much the system will cost up front. As the requirements change, the cost must also change” (Agile Requirements Change Management 15). Business stakeholders would not be able to present an upfront and solid estimate of the costs for a project. While this may seem unusual compared to Waterfall’s concrete estimate for costs, it may actually present many benefits. In an Agile situation, “stakeholders don't need an estimate up front because of the increased level of control which they have. Would you rather have a detailed, and very likely wrong, estimate up front or would you rather be in control and spend your money wisely?” (15) Being able to dynamically determine the amount to spend and the needs or changes that should be addressed, stakeholders can have projects accomplished in ways that would satisfactory in a cost-efficient perspective.

The Waterfall approach, on the other hand, invests a good amount of time analyzing and determining the precise requirements and scope of a project. Waterfall binds a project to a fixed price, a fixed contract, and approval-based decisions. As noted in an online article, Waterfall Development, Development cannot be started “until all of the designs have been approved, because it is very costly to change design after we are in development” (2). This proves to be a very big disadvantage because, as stated in the article, “[b]y the time we actually got to coding, the requirements were often already obsolete. But, we had to keep moving forward because of contract requirements. By the time we actually delivered the system, if it actually got delivered, it was millions of dollars over budget, years past due, and was no longer what the customer needed” (8). This suggests that Waterfall strongly disallows change due to the time, effort, and costs initially invested on the project. In fact, in this scenario, the project not only suffered from a hard cost of wasting millions of dollars, but the final delivery wasn’t even needed by the customer any longer. Therefore, very dissimilar to Agile, Waterfall may not always fulfill the needs, or at least, the eventual needs and satisfaction of business stakeholders.

Of course, making modifications while practicing the Waterfall principle is not impossible, but it is definitely considered as extremely challenging and inefficient. This is because “the only way to amend something which has been already developed is to go back and start again” (The Advantages and Disadvantages of Waterfall Software Development 6). Within the Waterfall approach, since parts of the project is hard to change and once a stage is completed, there is no turning back. If a problem exists or a different functionality must be implemented, it can only be fixed or added by completely backtracking and designing and developing an entirely new system, which can introduce much overhead, be very costly, and be very time inefficient. Because of this, Business stakeholders would, of course, dislike the idea of starting a project from the beginning again, especially when much time, money, and effort was already invested previously. This is the reason for Waterfall’s strong discouragement of change and its extreme challenge and expense.

However, the Waterfall approach can sometimes be a better choice than Agile under certain situations where the environment is stable and there is definitely no room for changes. This can even, in fact, be beneficial to developers in the sense that the developers would have a clearer understanding of the goals that need to be accomplished. Since the goals are already set in stone, they can have a clear focus on what to strive for. And due to the locking of the inability to make changes, projects may be easier to manage and, unlike Agile, a project will not “easily lose its way” (Agile vs. Waterfall Methods: Which Should You Choose 9). Therefore, due to the possible heavy amounts of changes that need to be adapted for, if Agile is not executed properly and successfully, confusion can increase and productivity will decrease, generating a disadvantage for Agile.

Another engineering practice that closely follows Agile’s idea of handling changes is the Spiral methodology. Similar to Agile, the Spiral methodology is more flexible to and can accommodate change. And dissimilar to Waterfall, Spiral does not have problems handling new requirements during the development phase; the fluidity of changes is possible and there is no locking of the ability for requesting and making changes. Due to Spiral’s better acceptance of the welcoming of changes, a Spiral environment is also able to enjoy the similar benefits that the stakeholders enjoy within an Agile environment.

According to John Sullivan’s book, Definitive Guide To Enterprise Change Management, due to this methodology’s nature of having multiple phases and phases that are “short and eventually followed by additional requirements analysis and design stages, the newly discovered requirements are readily accommodated” (66). Sullivan explains that these short incremental stages allow for more flexibility since they are short. And the immediate analysis, design, and review of when each stage is complete, can provide the team with valuable knowledge and feedback. Sullivan also states that “[t]his information is especially useful when business processes change in response to the new system. Business users do not need to anticipate all possible changes in their work patterns early in the development effort” (66). Therefore, both Agile and Spiral do not have heavily invested initial requirements, but rather, they both do what they can in the early development phase and adapt for anything new through the project lifecycle.

The Spiral methodology also presents a similar slight disadvantage that Agile has, compared to Waterfall. Similar to Agile being able to “easily lose its way,” Spiral can also easily have the same side effects if it is not executed properly. As conveyed by Sullivan, the “drawback of the Spiral methodology is that it does not define a fixed number of cycles, which can lead to undisciplined requirements gathering.” Such undisciplined actions include “determining that they can address it in a later cycle. In addition, unnecessary features might be added and eventually discarded.” Therefore, this causes an unstructured approach to tackling the project. And “[w]ithout a fixed design… frequent changes to applications cause ripple effects” (66). These “ripple” effects, as how Sullivan describes, is the same effects that Agilists may experience when confusion is high and structure is lacking, which, would also eventually lead to a decrease in productivity. Therefore, in a Spiral environment, if the amount of change requests that happen increases, then the risk for side effects happening heightens, thus causing less-than optimal performances from team members.

Understanding the differences between how the Waterfall, Spiral, and Agile engineering practices view, approach, and handle change will evidently present more of the benefits and drawbacks of each of these approaches. Both Agile and Spiral practices are more lenient towards changes, as opposed to how Waterfall strongly discourages them. Whether hard costs such as wasting time, effort, and money, or soft costs such as the decrease of overall productivity, are involved, all three of these practices have obvious reasons for being or not being incorporated into a project. Situations where a team envisions that a project would necessitate for many changes may lead the team into deciding against using the Waterfall method and possibly lean them more towards an Agile approach; because the request for even a simple change can bring about more hard and soft costs under Waterfall, Waterfall may not be the best decision when changes are expected within a project development lifecycle.

However, if the changes are less evident, the advantages are more prominent, and certain values can be justified, Waterfall can be a possible approach as well. As long as the team is aware of the similarities and differences, benefits and drawbacks, and values and influences of how each of these practices manages changes, they would have a solid foundation of deciding which engineering approach to choose. Therefore, each of these engineering practices are valid and depending on the circumstances, having a balanced perspective, and recognizing that change requests may or may not occur during the project development lifecycle, teams can make better decisions on which practice to follow.

Works Cited
Satalkar, Bhakti. "Agile Model." Buzzle. Buzzle, 20 Feb. 2013. Web. 17 Mar. 2013. .
Sutherland, Jeff. "Agile Principles and Values." Agile Principles and Values, by Jeff Sutherland. Microsoft, n.d. Web. 17 Mar. 2013. .
"Agile Requirements Change Management." Agile Requirements Change Management. N.p., n.d. Web. 16 Mar. 2013. .
Nayab, N. "Agile vs. Waterfall Methods: Which Should You Choose?" Brighthub Project Management. Bright Hub PM, 12 July 2012. Web. 17 Mar. 2013. .
"The Advantages and Disadvantages of Waterfall Software Development." , Waterfall Development, Waterfall Methodology from Www.My-Project-Management-Expert.com. N.p., n.d. Web. 16 Mar. 2013. .
Sullivan, John. The Definitive Guide To Enterprise Change Management. N.p.: Realtimepublishers, 2004. Print.
Peter. "The Process of Change - The Agile Change Agent." The Process of Change. N.p., 19 Dec. 2011. Web. 16 Mar. 2013. .

Christie, James. "Usability and Traditional Development Lifecycles (Waterfall & V Model) - Software Testing Club - An Online Software Testing Community." Usability and Traditional Development Lifecycles (Waterfall & V Model) - Software Testing Club - An Online Software Testing Community. N.p., 12 Nov. 2008. Web. 16 Mar. 2013. .

Toddcharron. "Waterfall - The Monkey's Paw of Software Development." Web log post. Planning for Failure. N.p., n.d. Web. 16 Mar. 2013. .
Blake. "Waterfall Development." InQbation. N.p., n.d. Web. 16 Mar. 2013. .

The database is protected by copyright ©sckool.org 2016
send message

    Main page