In this case, the error is made in the requirement phase. Now, the software is designed according to these faulty requirements. Hence, when the error is found, it becomes a little expensive to revert back the mistakes done in the requirement phase. Now the same concept can be applied to understand why it is highly costly to fix defects found in the construction phase.
Consider an error made in developing phase and the consequent defect is not found until the acceptance testing is done or even till the time when the system has been first implemented. In that case, it will be very expensive to redo the entire work to match the specifications and design needed. Moreover, this one defect may very well propagate to other parts of code and design for which testing is done again to reach the point of confidence in the software quality. Sometimes, it may also happen that the defects that are detected at a very late stage are not even corrected because the cost of fixing that defect is very high.
This greatly depends on how serious the defect detected is. The real question and drive is to minimize Rework. You need to be able to identify when the defect was introduced, then discovered, and then resolved. The most expensive defect escape is to production because the amount of rework is double due to having to go through the cycle again.
After shipping, Company A ran into a common problem: Some customers were quite disappointed by product quality — most frequently, in the areas where the engineers were unable to fix the defects before release. Fixing the defect after shipping requires additional cost. The developers still had to find the defect, and the testers had to verify the fix. In addition, for each fix the writers had to develop release notes, the build engineers had to create a separate branch, and the testers had to do system-level testing to verify no other egregious defects were caused.
Because the product was already released, Company A's additional system testing costs included:. During normal system testing, the testers skipped many of these steps because of insufficient time. They could not skip these steps after release, though — testers had to verify that this fix would not cause problems for other customers.
After the fix, the build engineers merged the fix back into the current development branch, and the testers verified that the fix still worked in the current development branch. Aside from the engineering work, middle management spent significant time tracking the progress of the emergency fix work and reporting that progress to senior management and the customer.
This extra work adds up. After release, Company A estimated that it spent 20 person-days per fix. Company B generally didn't release fixes to its products once the product was in the field, so it had no extra post-release costs. Like the others, Company C did not track defect fix time during the requirements, design, and implementation phases. However, Company C engineers used a build-every-night and fix-any-defects-immediately approach to product development. In effect, the engineers were finding and fixing defects throughout the entire lifecycle.
Using this approach — along with code walk-throughs and peer reviews — they generally shipped a very high-reliability, low-defect product, and were able to avoid most post-release defects costs.
Table 1 shows a summary of the cost to fix a defect during the different parts of the lifecycle, and an estimated cost to the company of a defect. Notice that all three companies had different actual costs to fix a defect. This is because there is no standard cost to fix a defect. For instance, Company B had a less complex, smaller product than Company C, so we would expect different costs to fix. The cost to fix a defect changes for different projects and different organizations.
What we can compare, though, is how the ratio of fix costs changes during the product's lifecycle, which appears in Table 2. According to Pressman 1 , the expected cost to fix defects increases during the product's lifecycle. Table 2 compares Pressman's expected figures to those found during development at Company A, B, and C. Table 2 : Comparison of cost to fix a defect at different times in a project.
There are a few things to notice here. First, even though the cost ratios don't match the generally accepted ratios according to Pressman, one trend is clear: The later in the project you fix the defects, the more it costs to fix the defects. Second, none of these companies tracked their defect cost before coding started. Had they tracked defects found and fixed during requirements and design, they could have tracked the defect cost before coding started.
Armed with that information, they might have chosen different activities designed find more defects earlier. When compared only with Company B, that might make sense, as Company A's product was larger. When compared with Company C's costs, though, Company A's costs seem extremely large. The Systems Sciences Institute at IBM has reported that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to times more than one identified in the maintenance phase Figure 1.
A review or inspection during the design phase can identify a significant number of errors. According to Crosstalk, the Journal of Defense Software Engineering, most failures in software products are due to errors in the requirements and design phases — as high as 64 percent of total defect costs Figure 2. It can be concluded that defect identification is an important process in software development.
At Segue, we conduct reviews to evaluate all phases of a project or software development. We focus our efforts on reviews conducted during the earlier stages of software development for defect detection that are more cost efficient than those at the later stages. Early defect detection allows our project managers to achieve the shortest schedules of projects and provide high quality products to the customers.
0コメント