Examples of Trends from the Configuration Management Discipline


With iterative development, the features to be implemented for a given iteration are determined at the beginning of the iteration. The implementation of these features and requirements takes place during the iteration. Toward the conclusion of the iteration, these new features are integrated with the previously developed code. At the end of the iteration, a stable, executable release is created that is ready for thorough testing. Some configuration management tools tell you how many lines were inserted, deleted, or changed since a prior baseline. If you plot these numbers during the course of an iteration, you should expect to see a trend, as shown in Figure 15-3, where you can see that the number of lines inserted (in other words, new lines of code entered) ramps up quickly at the beginning of the iteration. The number of changed lines follows a similar trend, although the actual number of changed lines probably lags inserted lines (especially early in the project's life cycle). The key point in Figure 15-3 is that trends should ramp down quickly before the end of the iteration as code is integrated with the rest of the system and checked in. The exact shape of the curves may differ from project to project, and even from iteration to iteration within the same project. But a common theme is that code changes should trend down toward the end.

Figure 15-3. A normal trend of code changes during an iteration


Be vigilant for situations such as the one illustrated in Figure 15-4 where the code change trends start normally but do not trend down at the end. A release produced at the end of an iteration with code change trends such as shown in Figure 15-4 is likely to experience problems during testing. The code never stabilized in this iteration. This is a somewhat common situation that occurs in teams who are unaccustomed to iterative development. In this scenario, there is a strong temptation to extend the iteration's end date. You should strongly resist this urge. Instead, you should quickly shorten the list of features or requirements planned for implementation during this iteration. With practice, the team will learn to recognize in the second half of the iteration if it will be able to complete the planned work by the end of the iteration. As soon as the team realizes it cannot get everything done, enough work should be removed from the iteration to enable the trends to resemble Figure 15-3.

Figure 15-4. An example of code change trends that did not stabilize


Interestingly, the trend of code changes over a project's entire life cycle should tend to resemble the trend within an individual iteration. Figure 15-5 shows an example of the code change trends over the life cycle of a hypothetical project.

Figure 15-5. Code change trends over the entire project life cycle


Defect Trends on Iterative Projects

One of the advantages of iterative development is that independent testing can begin after the first iteration is completed, typically in the Elaboration phase. (Note that the developers can perform some testing even sooner. By "testing," I mean independent testing performed by test engineers.)

I prefer using a simple, three-level rating for defect priorities:

  • Priority 1: Serious, showstopping defects that either make the system unusable or prevent a key part of its functionality from performing as it should. A defect in this category needs to be corrected as soon as possible, before the system is released to users. If a priority 1 defect is discovered after release, an emergency release should be made, correcting the defect.

  • Priority 2: Defects that are a major inconvenience but that have workarounds. The system can still accomplish its primary functions, although the problem caused by the defect is annoying and, in some cases, is disruptive or causes extra work for users.

  • Priority 3: Minor defects, such as spelling errors, inconsistencies in the user interface, formatting errors, or minor problems that do not inhibit use of the system.

Certainly, it is ideal to fix all defects prior to release. But if this is not possible, focus on the highest-priority defects first. As a matter of principle, I prefer never to release software with a known priority 1 defect. If you must release software with known defects, provide the users with release notes. Also follow up with discussions or verbal contact with key customer and user representatives to discuss the defects (as well as any information that helps avoid or work around the defect). Release notes are seldom read, so this verbal follow-up is extremely important. Many users can tolerate some defects if they are notified about them in advance and know that corrections are forthcoming.

Figure 15-6 shows typical defect trends over a project's life cycle. As the software is tested, defects are discovered and logged in a defect-tracking system. During Elaboration and the earlier Construction iterations, the focus is on establishing and proving the system's architecture, eliciting the proper features to build, and then building the system's main functionality. As the highest-priority risks (such as determining a viable architecture) are retired, attention can begin to turn to working on the defects detected. As a result, the number of open defects reaches a peak during Construction but tapers off rapidly in the later Construction iterations and Transition.

Figure 15-6. Defect trends over a project's life cycle





Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

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