Reuse and COTS
Introduction to the concepts of Reuse and Commercial Off-the-Shelf (COTS) products, highlighting how they differ in development costs, time efficiency, and integration challenges based on empirical data and technical issues. Insights from NASA studies and Siemens hardware reuse case study provide valuable perspectives on the practical implications and challenges of implementing reuse strategies in software development.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Reuse: Introduction How differs from COTS? Assume have source code, not a commercial product bought from someone else Ariane 5, Therac-25, British ATC, [Do you have any favorite examples?] Expectation: Significantly lower development costs and time when reuse Costs more to make reusable, but can amortize costs among all users and uses and will come out ahead over time Assumptions: Will be reused enough to recoup extra costs Can easily and cheaply integrate components into a new environment (interoperability)
Reuse: Empirical Data High reuse in some limited environments, not widespread however. NASA Goddard Study Garlan, Allen, and Ockerbloom Performance problems (from large size and complexity) Complexity frequently inappropriate for tasks performed. Trouble fitting components together. In some cases, took significant reengineering to make them interoperate properly. Maintaining synthesized system difficult in absence of low-level understanding.
Reuse: Empirical Data (2) Siemens (hardware ASICS) reuse study Time to build a reusable component can be 120-150% of time needed to develop component for single use (excludes documentation). For reusable component, needed to develop new documentation, which took one to two times the effort of designing the component. Overhead to develop a reusable component (design + documentation) recaptured after fifth use. Frequency of reuse increases with degree of comprehensibility. Habitability even more important: Measure of how at home a potential user of reusable component feels Highly subjective but effect even greater than that of comprehensibility
Reuse: Technical Issues Configuration control problems May change continuously (and developer may be able to check it out of library and change it) Unneeded functionality (interoperability and performance issues) May need to write software utilities (e.g., restrictive wrappers) to restrict functionality Much of savings may be offset by need for more testing (Weyuker) Debugging may be significantly more difficult (Weyuker) Longevity: does potential for reuse decrease over time? Reuse designs rather than finished products?
Reuse: Other Issues and Experiences Does it fit management reward structures? Platforms and reuse at Xerox (success story) One organization within Xerox reports they use half dozen different software platforms to build dozens of different products Achieve approximately 80-90% reuse What is your experience?
COTS (Commercial Off-The-Shelf) Software Main difference from reuse is lack of source code Potential advantages: Reduce front-end acquisition or development costs Amortize costs over large number of users Compensate for lack of expertise (e.g., GPS) Allows for more rapid infusion of new technology But new risk drivers Loss of market control (less control leads to higher risks) High-speed market Must deal with rapid obsolescence (shortened lifetimes) New versions of releases brought to market frequently For government, shift from buyer s market to seller s market
COTS: Management Issues Lower development costs offset by higher lifetime costs? Sustainment costs substantial: need to be planned and managed What if vendor goes out of business or stops producing and will not maintain old versions? Even if escrow agreements, hard to maintain software you did not write and must hire developers expert in that code. Dependency on vendor: Can charge anything or make other demands (see Microsoft monopoly case findings of fact) Higher speed of change requires greater strategic flexibility Need flexible and proactive system evolution management
COTS: Technical Issues Functionality provided may not remain what you need over time. Few parts in a software system are truly independent My need wrappers and patches as substitutes for real source-code- based maintenance. Differences (e.g., timing) may be introduced in new products What happens when support from COTS vendors ceases? Can user change requests be satisifed? May be Trojan horses or security flaws in COTS software and almost certainly will not know until too late.
COTS: Technical Issues (2) Must be accepted as is and may not satisfy user requirements. Compromises may be required. May be difficult or impossible to certify (e.g. safety) Need to defend yourself from mistakes in supplier s code May be developed to commercial not government or safety standards Requires continuous lifetime system engineering effort. Identify and integrate product obsolescence information with technology trends and new user requirements. Your experiences and comments?
Readings and Thoughts Read, summarize, and critique Ariane 5 Accident Report Kruger, Software Reuse [This is an excellent survey of reuse, but it is also very long so you can just skim it if you are not interested in becoming an expert on the topic. You need not write a summary of the Kruger paper.] Weyuker, Testing Components Glass, Reuse: What's Wrong with This Picture? Leveson and Weiss, Making Embedded Software Reuse Practical and Safe Gomez, Lessons Learned from Two Years of On-Orbit GPS Experience on International Space Station OPTIONAL: Goodman, Lessons Learned from Flights of "Off the Shelf" Aviation Navigation Units on the Space Shuttle (Not required but may be of interest to those working with COTS products
Takeaways Reuse and COTS may not be the great solution to all our software problems that some people think. Most component selling companies have disappeared. Everybody reuses their own code to some degree, but much harder to be successful if you didn t write it yourself. May be good reasons to reuse or to use COTS, but be aware of extra costs and requirements. Not as easy as it sounds. Remember, software is very different than hardware.
