How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering - Essay Example

Running head: Rational Unified Process Review: How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering First and Professor NameCourse Name University NameAbstract The purpose of this essay is to review the article written by Craig Larman, a chief scientist at Valtech, Philippe Kruchten, Rational Fellow, Rational Software Canada, and Kurt Bittner, General Manager, Process and Project Management Business Unit, Rational Software. The article is titled, How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering.

Along with a generalized summarization of the main points of the article, this essay will highlight the main points given within the article that support the concept of iterative software development methodologies. Review: How to Fail with the Rational Unified Process: Seven Steps to Pain and SufferingThe Rational Unified Process (RUP), and subsequently the iterative methodology, has become one of the leading software development processes. In doing so it is seeking to replace the outdated, unrealistic, methodologies outlined by the Waterfall approach.

In the essay entitled, How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering, authors, Larman, Kruchten, and Bittner, outline the key ways many companies fail in their implementation of RUP. In doing so, they successfully demonstrates the key differences in the RUP and the Waterfall approach to software development. Through careful examination of the seven steps by which one can fail with RUP implementation, an outline begins to appear as how RUP can be successfully put into practice.

The Seven Steps and Their Meaning The first step the authors outline in failing to implement an RUP approach is to superimpose “waterfall” thinking. The Waterfall approach mentioned here is the antiquated, methodical, approach to software development. This is where the requirements are given to the developer and deadlines are laid out for when the software is to be completed. This is the opposite of what the RUP, iterative approach calls for. The iterative approach is one that takes into consideration the need for constant change.

It requires that the project be, in part, initiated before any sort of requirements or deadlines can be accurately assessed. So to affectively initiate an RUP approach all previous “waterfall” ideals must be foregone. The next step outlined in the essay is to apply the RUP as a heavy, predictive process. The whole idea behind the RUP is that it is built to allow for the flexibility and change needed to successfully complete software development. The third step is to avoid object technology skills.

This step refers to the training that a company must undergo before implementation of a RUP approach to software development. The training must be thorough and followed by mentorship. The forth step outlined is to undervalue adaptive iterative development. Iterative development embraces change and allows for issues to arise and be overcome before one has gone too far in the development process. To undermine this is to undermine the whole of what the RUP is about. The fifth step discusses mentorship and how if it is avoided the iterative processes will be impossible.

This is due to the fact that iterative is mostly a try and fail approach so mentorship helps guide the developers along in the process of arriving and the best possible solutions. The sixth step mentioned is to adopt the RUP in a big bang, or at the same time. This is unadvisable because RUP is a learning process that takes time and practice before it can be successful. If a company was to try to switch over simultaneously it would be doomed to fail.The seventh and final step is to take advice from misinformed sources.

There are many out there who believe that they are following the RUP approach and yet still go by many of the rigid waterfall practices because they create the illusion of stability and predictability. So it is therefore important when learning about the RUP approach to insure that the authors of said research are adhering to the loose, ever changing foundation upon which RUP is built. All of these steps though they are written to demonstrate how to appropriately fail in adapting the RUP approach, actually do a suburb job of showing how best to implement it.

It seems from the article the best implementation would be to avoid the ideas presented by the waterfall method at all cost since they are the antithesis of what the RUP and iterative approaches stand for.ConclusionOverall, the collective authors did an amazing job of outlining the best way to implement RUP, in their own unique, round about, way. Their use of humor, and easy writing style made the extremely informative essay and easy read, while allowing the reader to gain a wealth of knowledge.

Even the most inexperienced software developer could walk away from this essay with a knowledge of how to, or how to not appropriately begin the arduous, worthwhile, task of implementing the RUP and iterative approach.ReferencesLarman, C., Krchten, P., & Bittner, K. (2001). How to Fail With the Rational Unified Process: Seven Steps to Pain and Suffering. Valtech Technologies & Rational Software.