Investments in reusable software. A study of software reuse investment success factors
Authors: David C. Rine
Robert M. Sonnemann
Published in:
· Journal
Journal of Systems and Software archive
Volume 41 Issue 1, April 1998
Pages 17-32
Elsevier Science Inc. New York, NY, USA
Abstract
This research supports the thesis that there is a set of success factors which are common across organizations and have some predictability relationships to software reuse. For completeness, this research also investigated to see if software reuse had a predictive relationship to productivity and quality. The individual success factors were grouped into the following categories: management commitment, investment strategy, business strategy, technology transfer, organizational structure, process maturity, product-line approach, software architecture, availability of components, and quality of components. A questionnaire was developed to measure software reuse capability, productivity, quality, and the set of software reuse success factors. A survey was conducted to determine the state-of-the practice. The data from the survey was statistically analyzed to evaluate the relationships among reuse capability, productivity, quality, and the individual software reuse success factors. The results of the analysis showed some of the success factors to have a predictive relationship to software reuse capability. Software reuse capability also had a predictive relationship to productivity and quality. Based on the research results, the leading indicators of software reuse capability are: product-line approach, architecture which standardizes interfaces and data formats, common software architecture across the product-line, design for manufacturing approach, domain engineering, management which understands reuse issues, software reuse advocate(s) in senior management, state-of-the-art tools and methods, precedence of reusing high level software artifacts such as requirements and design versus just code reuse, and trace end-user requirements to the components which support them.
Copyright © 1998 Elsevier Science Inc. All rights reserved.
http://www.sciencedirect.com/science/article/pii/S0164121297100036
Article Investments in reusable software. A study of software reuse ...
I am.. I'm working on a reuse task for a government agency that funds the development of state systems. The current model does not require nor does it facilitate reuse. I'm looking to curtail the government's generosity - by insisting that a good faith attempt be made to examine candidate reuse assets. Unfortunately - the state agencies are all over the map with respect to system development and reuse maturity. So I've got a baby steps task that will require I get a handle on the systems implemented, their technology basis, and enough information so I can associate a state with a reuse maturity level. Wish me luck - i'll need it. I do need to address government investments in state systems - where the only possible ROI are shareable assets.
Will be happy to keep you apprised.
Based upon my past experiences agencies such as NASA, DoD, Air Force, Navy, CIA, NSA would require a study of reuse as well as steps toward integration into existing systems, coined Technologies Readiness! Within Dod contractors and NASA there are generally 10 steps of phases toward a technology's readiness or reuse. But in the private sector such as with Lockheed Grumman, Raytheon and others they may be limited to 3-4 phases toward technologies readiness due to the importance of investment in these reusable/integratable technologies into existing systems. Most systems where reuse and readiness are practiced are of course existing systems.
I will try to send an attachment to you in awhile!
Questions?
Dave Rine
Software and Systems Engineering
Here are the related technology and manufacturing readiness references I promised. This is related to reusability in real existing systems.
What else do you need?
Dave Rine
Software and Systems Engineering
http://en.wikipedia.org/wiki/Technology_readiness_level
http://www.esto.nasa.gov/files/TRL_definitions.pdf
http://www.nasa.gov/pdf/458490main_TRL_Definitions.pdf
http://en.wikipedia.org/wiki/Manufacturing_Readiness_Level
http://usm.maine.edu/sites/default/files/researchadmin/DOD%20Technology%20Readiness%20Level%20Definitions.pdf
http://www.bnl.gov/techtransfer/docs/Technology-Readiness-Levels-Definitions-and-Descriptions.pdf
http://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-annex-g-trl_en.pdf
http://www.irconnect.com/noc/press/pages/news_releases.html?d=121807
https://www.navalengineers.org/SiteCollectionDocuments/2010%20Proceedings%20Documents/FMMS%202010/Papers/Hanna.pdf
http://www.dtic.mil/ndia/2008science/Day3/09Iverson.pdf
David - Thank you for the terrific papers and references. Lots to digest and consider. I get the sense from looking at the reuse literature that it has not matured much past mining and refining. Reuse seems to have been subsumed by model-based engineering - which is probably appropriate. MBE owns architecture and design pattern reuse. Well designed repositories could be organized such that a reusable black box or clear box components were organized under the design pattern or the composition of design patterns to which they represented a solution instance.
I saw an MBE maturity scale proposed by Bruce Douglass that illustrated concepts he feels are applicable to MBE use. This presentation needs a column added for reuse – to identify at each level – reuse options to support the specification, design, and development / test activities – where assets are selected, employed, and tailored as required vs new asset creation / development.
Since reuse is involved - there is always - the need to consider activities of the two life cycles: asset reuse and asset creation. See my two life cycles paradigm paper attached. Reusable assets don't just come out of thin air - and without a two life cycle concept - I've never seen how reuse could be made to work - beyond hero-driven reuse - a team of people with strong domain knowledge - and a strong understanding of critical component libraries that when used - produce consistent behavior - such as components that implement things like kalman filters, object tracking algorithms, telemetry processing algorithms, etc., In short - components so complicated, that once implemented - are only modified and maintained by highly qualified experts.
I'd appreciate your thoughts on the above.
Regards, W. H.
Simple other questions: Do you include in our realm the years of success of components-based software manufacturing, components reuse, components libraries, etc.?
- Badges
- Science topic
- Similar topics
- Computer Science
- Computer Software
- System Software