15.3 Code Migration Plan


We captured the results of the analysis described in the previous section in a collection of Rational Rose UML models. A separate model is generated for each increment, which in turn contains a class diagram for each database record in the set. [1]

[1] Database records without associated program elements are not included.

Figure 15-6 shows a diagram for the DB53 record. The record is displayed using the table stereotype defined in Rose. Program elements shown in white must be migrated as part of this increment. Program elements in light gray have already been migrated. Program elements shown in dark gray are scheduled to be migrated and require the use of an adapter. Adapters are required where program elements not already ported need to invoke a program element that is being migrated in the current increment.

Figure 15-6. Database element set

Figure 15-7 shows sample information for each increment in the documentation for the increment package created in Rational Rose. This data includes the number of program elements ported in the increment; the number of adapters required; the number of lines of code ported in this increment, both as an absolute value and as a percentage of the overall system; and the number of lines of executable code ported in this increment, both as an absolute value and as a percentage of the overall system. Following this header information is a description of the percentage of each business object completed at the end of the increment. There is one line for each business object. The number of lines of ported code associated with each business object is given, again as an absolute and as a percentage of the total lines of code in that business object.

We used the information from SAM to generate a series of alternative code migration plans. Each plan is contained in several UML models: one for each increment and a final increment containing the flexible allocation, or isolated program elements. From these UML models for each plan, profiles can be developed that include the lines of code (LOC) allocated to each increment, the number of required adapters, and the completion rate for business objects. Management can then select the profile that best fits the available resources, or request additional profiles, if necessary. As an example, this section contains an initial profile. (Profiles obtained from running the tool against various stakeholder preferences are presented in Chapter 16.)

Figure 15-8 shows the LOC allocation for each increment. In this profile, increment 1 is intentionally small because the main concern is exploring the technical risks associated with the project. The advantage of a small initial increment is that you should be able to routinely apply lessons learned in the first increment to later increments . There is, of course, some management risk in this approach because the cost per line of code developed will be disproportionately high in the first increment. This is a condition that will have to be supported by management fortitude.

Figure 15-8. Size of increments

Figure 15-7 Sample increment output
 NUMBER OF PROGRAM ELEMENTS PORTED: 37 NUMBER OF  ADAPTERS REQUIRED: 8 LOCs PORTED: 92308 (total=1209996 percentage=7) EXECUTABLE LOCs PORTED: 77941 total=1016515     percentage=7) BO COMPLETION (this increment) Orders LOCs: 7897 (total=110611 percentage=7) Inventory LOCs: 3435 (total=165278 percentage=2) WIP_Confirm LOCs: 1146 (total=53331 percentage=2) Requisition LOCs: 1193 (total=80729 percentage=1) : Other LOCs: 0 (total=1309 percentage=0) 

Isolated program elements become part of the flexible allocation and can be assigned to any increment. This is convenient because these isolated program elements can increase the size of increments to map the funding profile. Ideally, the fixed allocation will fall below the projected effort for each increment. Program elements from the flexible allocation can then be added to each increment to bring them up to the projected effort for each increment.

Figure 15-9 shows the number of adapters ”calls from the legacy code to the modernized code ”inverse adapters ”calls from the modernized code to the legacy code ”and program elements being ported and developed in each increment according to this initial profile. The height of each bar shows the combined number of adapters and program elements. Of course, no adapters are included in the flexible allocation.

Figure 15-9. Adapters versus program elements

Figure 15-10 shows the percentage of each business object completed after each increment. In this profile, every increment completes at least one business object. Completing business objects quickly is important to demonstrate early benefits and to finalize parts of the modernized system.

Figure 15-10. Business object completion

Figure 15-11 shows the initial allocation of source lines of code (SLOC) to the business objects. This chart was not part of a specific profile but helped detect business objects that had too much functionality and should be decomposed or that did not have enough and should be merged. For example, it is apparent in Figure 15-11 that Match Doc, Support Records, and System lacked functionality and were eliminated as business objects. The chart can also identify other problems, such as the large number of source lines allocated to System Management.

Figure 15-11. Size of business objects



Modernizing Legacy Systems
Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices
ISBN: 0321118847
EAN: 2147483647
Year: 2003
Pages: 142

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