Accommodate Change Early in the Project

Change is good. Actually, change is great. Why? Because most modern systems are too complex to allow you to get the requirements and the design right the first time around. Change allows you to improve upon a solution. If there is no change, then you will deliver a defective solution, possibly so defective that the application has no business value. That is why you should welcome and encourage change. And the iterative approach has been optimized to do exactly that.

But change can also have severe consequences. Constant change will prevent project completion. Certain types of change late in the project typically mean a lot of rework , increased cost, reduced quality, and probable delays, all things you want to avoid. To optimize your Change Management strategy, you need to understand the relative cost of introducing different types of changes at different stages of the project lifecycle (see Figure 2.4). For simplicity, we group changes into four categories.

  • Cost of change to the business solution. Change to the business solution involves major rework of requirements to address a different set of users or user needs. There is a fair amount of flexibility in making this type of modification during the Inception phase, but costs escalate as you move into the Elaboration phase. This is why you force an agreement on the vision for the system in Inception.

  • Cost of change to the architecture. When following the RUP, you can make fairly significant architectural changes at low cost until the end of Elaboration. After that, significant architectural changes become increasingly costly, which is why the architecture must be baselined at the end of Elaboration.

  • Cost of change to the design and implementation. Because of the component-based approach, these types of changes are typically localized and can hence be made at fairly low cost throughout the Construction phase. These types of changes are, however, increasingly expensive in the Transition phase, which is why you typically introduce "feature freeze" at the end of Construction.

  • Cost of change to the scope. The cost of cutting scope ”and hence postponing features to the next release ”is relatively inexpensive throughout the project, if done within limits. Scope cutting is greatly facilitated by iterative development; project managers should use it as a key tool to ensure on-time project delivery.

Figure 2.4. The Cost of Introducing Change Varies Throughout the Lifecycle. The cost of introducing a change varies according to the lifecycle phase, and each type of change has its own cost profile. The RUP milestones at the end of each phase are optimized to minimize overall cost of change, while maximizing freedom to make changes. In general, as the project progresses, you should be more careful about introducing change, especially to the overall business solution and the architecture.

graphics/02fig04.gif

These cost considerations mean that you need to manage change. You need to

  • Have procedures in place for approving whether to introduce a change.

  • Be able to assess the impact of change.

  • Minimize the cost of change.

Change approvals are done through a combination of manual procedures, such as Change Control Boards (CCBs), and tools, such as Configuration and Change Management (CCM) software. Assessing the impact of change is primarily done through traceability between tools for requirements, design, code, and test. When changing a class or a requirement, you should be able to understand what other things are potentially affected; this is where traceability saves a lot of grief .

The cost of change is minimized by having procedures in place for managing changes and also by assessing their impact. Again, the right tool support can have a tremendous effect. Automatic synchronization between design and code is an example of automation reducing the cost of change, since it allows you to do some code changes by working on a higher level of abstraction ”the design.

Summary

The cost of change increases the further you are into a project, and different types of changes have different cost profiles. The RUP's phases have been set up to minimize overall cost of change, while maximizing the ability to allow for change. This is why the RUP forces agreement on the overall vision at the end of the Inception phase, a baselined architecture at the end of the Elaboration phase, and feature freeze at the end of the Construction phase. Using the right tools can play a powerful role in managing change and minimizing its cost.



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net