Ads
  

The Effects of Reuse on Software Size

The Effects of Reuse on Software Size

Several software programs are derived from previous programs. This may result in savings of cost and/or time, and it may result in increased quality. But reuse can also cost more, take longer, and yield lower quality.

Just about anything can be reused - code, test code, test cases, test procedures, documentation, design specifications, designs, requirements specifications, and so on.

Reuse terminology contains:

●  New code - code developed for a new application without including large portions of previously written code
●  Modified code - code developed for a previous application that is suitable for a new application after a modest amount of modification
●  Reused code - code developed for a previous application that is suitable for a new application without change of any kind
●  Legacy code - code developed for a previous application that is believed to be of use for a new application

Why is it "modified" if you change it only a little bit? Completely reused code has the same documentation, the same test procedures and code, and only one copy to maintain in the configuration management library. If only one line of executable code is changed, tests and documentation must change as well.

When using legacy code, beware that it may have poor documentation, it may lack test code or procedures, it may not be designed well, and it may have lax quality standards.

The first step in estimating systems that may reuse code is to separate new code from modified and reused code. This is because modified and reused code can almost never just be added in - there are changes required for the integration, and size and effort increases to accommodate those changes. An instance appears in Table 1.

Separate New, Modified, and Reused Lines of Code

How do you count how much of a component is modified or reused? Look at Component 4 and Component 5 in Table 2. A rule of thumb is to examine the smallest level known for a unit or module (usually about 100 LOC). If the unit is not changed at all, it is "reused". If the unit has changed, by even one comment or executable statement, it is "modified". If more than 50% of the unit is changed, consider it to be "new". Moreover, once the modified code has been identified, you may want to separate it into categories representing the type of modification. A commonly used approach is to separate modifications for the sake of correcting defects from the modifications for adding enhancements. Table 1 might look something like Table 2 once this separation is made.

Different Kinds of Modified Code

After estimating the total delivered size, reused code will be converted to "equivalent" new code. The conversion process is based on how much less effort will be expended for reused or modified software than for new software. Generally a conversion factor is established to reflect the amount of effort saved by reuse. Assuming that there is historical justification of the conversion factors, a simple calculation can then be done. Returning to the example in Table 3, we can apply reuse factors indicating that reused software takes only about 30% as much effort as new software, and modified software takes about 60% as much effort as new software. This shows that the total effort to develop these 5,121 LOC will be comparable to that of producing 3,567 lines of new code.

Reuse factors come from experience. The 30% and 60% factors were observed on hundreds of projects. On the other hand, these are averages, and the range is wide. The best indicator of size and effort in your organization is actual data from the organization - keeping track of estimates and actuals in a historical database.

Typical reuse factors are shown in Table 4.

Applying Reuse Factors

Typical Reuse Factors

Becoming More Accurate with Reuse


We can get more accurate if we are willing to look more closely at the process and the reuse characteristics. Returning to our example, the first step is to examine the process and then determine the percent of the total effort expended in each step in the development of new code.

Suppose that we know that our organization spends 18% of its time in requirements, 25% in design, 25% in code and test, and 32% in integration (there are only four life cycle phases in this example).

As shown in Table 5, new code will require that every bit of that effort must be expended. On the other hand, modified and reused code will require less effort.

Instead of 100%, let's say that modified code requires only 20% of requirements effort, and reused code requires only 10%.

Instead of 100% of design effort, we'll say that only 40% will be required for modified software and no design (0%) is required for reused software. The 40% is because we may have to plan how to test the modified software, and maybe we must design the rest of the software in a special way. The value of pure reuse begins to become apparent.

Instead of 100% of the coding and unit testing effort required for new software, modified software requires only 70%, and, again, reused software is essentially "free". For only "pure" reused code will this be zero. If just one single line of code is changed, then it has been modified.

Integration effort doesn't get a break, even with modified or reused code. Even for pure reused code, integration often requires 50% -100%.

For each phase of the process, the effect of reuse can be determined after the percent of effort for each reuse category is determined. Table 5 shows that inclusion of reused and modified code wherever possible is indeed a size, effort, schedule, and cost savings.

Applying an Accurate Estimating Method to Reused and Modified Code

Estimation of Effort


After the size of a software product has been estimated, we can proceed to estimate the effort required to create it. Such is the topic of "Estimating Duration and Cost".


Tags

modified software, quality standards, reused code, reused software
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus