This issue in 
The Advantages of Reused Software Components
by Nancy Bazilchuk and Parastoo Mohagheghi
Software reuse in a product family approach is commonly thought to lead to fewer product problems, greater productivity and easier maintenance. However, little empirical data has been found to support this assumption - until now. Recent analysis of more than 13 000 problem reports collected by the mobile phone company Ericsson in Grimstad, Norway, has shown that software reuse does result in significantly fewer problems and better stability.
Like most companies, Ericsson-Norway collects a large amount of data relating to its software. Much of this data is awaiting analysis, and represents a mine of information on product characteristics and quality. An analysis by Parastoo Mohagheghi, a PhD graduate from the Norwegian University of Science and Technology, sifted through Ericsson's data to try to answer the question: what effect does software reuse have on product defects and stability? Her answer, discovered with co-researchers from the university, Ericsson-Norway and the Simula Research Laboratory in Lysaker, Norway, is that software reuse significantly improves quality.
Companies like Ericsson are increasingly moving toward component-based software engineering (CBSE), where related products and systems can be assembled from pre-built components. These reusable components can take a variety of forms, from existing software libraries, to free-standing commercial, off-the-shelf products (COTS) or open-source software (OSS), to entire software architectures and their components. CBSE promises many advantages, such as a shortened product development time, reductions in total costs, and - since new software components can be purchased instead of developed in-house - fast access to new technology.
Ericsson engineering teams in Sweden and Norway built two large-scale, distributed telecom systems containing several reused components. One of these systems was evaluated as part of Mohagheghi's doctoral research. The system's platform was developed by a sister Ericsson organisation, and was considered to be a COTS component, although in reality it too could have been evaluated as a reused component. The middleware, component framework, and the business-specific software were all reused components. Data from several releases of the system were collected and analysed, with the results of the analysis of one release presented in an award-winning paper at the 26th International
Conference on Software Engineering in Edinburgh, Scotland (ICSE '04). Mohagheghi's paper examined one release that comprised 470,000 lines of non-commented Code (KLOC), of which 64 percent was in Erlang, 26 percent was in C, and the remainder was in other programming languages like Java or Perl.
|
If a defect in a component is detected during integration or system testing, or later during maintenance, Ericsson programmers write a Trouble Report that describes the defect in detail. The report typically contains information such as the severity of the defect, the assumed origin of the problem, the amount of time needed to correct the defect, and a defect code that assigns the problem to a trouble category, such as coding, wrong design rule, or documentation problem. Mohagheghi and her co-researchers examined 13,000 of these Trouble Reports to compare the quality of the reused and non-reused components.
The analysis showed that reused components had a lower defect density than non-reused ones, with defect density calculated by dividing the number of defects by the number of lines of code. At the same time, however, the reused components had more defects with the highest level of severity than the total distribution, but less of these defects after delivery. Mohagheghi and her co-workers concluded this was because defects in reused components were assigned a higher priority to be fixed. Other researchers have assumed that reused components would change more often than non-reused components because the reused components had to meet the requirements of several different systems. However, Mohagheghi's analysis also showed that reused components were far less likely to be modified between successive releases, as measured by the percentage of code that was modified. This meant the reused components were far more stable than their non-reused counterparts. Mohagheghi has also studied how prone components were to change, as measured by the number of changes in requirements and deliveries for reused and non-reused components in this release, but did not find any significant difference between the two types.
This study was financed by the INCO project (INcremental and COmponent-based Software Development), a Norwegian R&D project in 2001-2004.
Link:
The entire study is available in Mohagheghi's dissertation, available at
http://www.idi.ntnu.no/grupper/su/publ/phd/mohagheghi-thesis-10jul04-final.pdf
Please contact:
Parastoo Mohagheghi, NTNU, Norway
E-mail: Parastoo.Mohagheghi
idi.ntnu.no