Reusable Integrated Components of Patterns
TOOLS '00 Proceedings of the Technology of Object-Oriented Languages and Systems (TOOLS 34'00)
Designing electronic reference documentation for software component libraries
Journal of Systems and Software
Scenario-Oriented Design for Single Chip Heterogeneous Multiprocesso
IPDPS '05 Proceedings of the 19th IEEE International Parallel and Distributed Processing Symposium (IPDPS'05) - Workshop 10 - Volume 11
High-level modeling and simulation of single-chip programmable heterogeneous multiprocessors
ACM Transactions on Design Automation of Electronic Systems (TODAES)
Towards an effective integrated reuse environment
Proceedings of the 5th international conference on Generative programming and component engineering
ACM Transactions on Software Engineering and Methodology (TOSEM)
| Hi-index | 0.00 |
Something is seriously wrong with reuse. If there is a motherpie-and-applehood topic in software engineering, reuse is it. Everyone believes in it; everyone thinks we should be doing more of it. Reuse does have the potential our industry attributes to it. But the question that keeps recurring is this: why hasn't that potential already been achieved? Most software engineering literature points the finger at management. Don Reifer, for example, has conducted lots of industrial strength studies of businesses that practice reuse (D. Reifer, 1997), and to him the conclusion is clear: the companies that succeed at reuse do so because of managerial commitment, while the ones that fail lack such commitment. Several others say much the same thing. R. Prieto-Diaz turns the problem around and asserts that companies that fail at reuse do so because they treat it as a technical problem. The author disagrees. It seems to him that reuse's fundamental problem is clearly not a lack of managerial commitment. Based on his own experiences, the author thinks reuse hasn't succeeded to the extent we would like because there aren't that many software components that can be reused