| Project Metadata | Keywords | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Background
DSRD was asked to examine the policies, procedures, and business plan of the Army Reuse Center (ARC). We produced advice and reports on these issues. We also examined the basic rationale for the existence of the ARC - that is the contention that reusing software makes operational and economic sense. We created and presented the following paper to address this question.
Abstract
It is shown that software reuse and, more generally, systems reuse are more than theory, software is being reused in real systems. Not only is the practice of systems reuse an actuality, it is also making good its promises for cost savings. The Army Reuse Center is creating the environment that supports the practice and is providing the cross-system technical support that is needed for continuity.
1 Theory of Reuse
Software reuse is a nice theory. The theory says it's cheaper to reuse software components multiple times than to build for each project. However, there appear to be problems in actually applying this theory to real projects. For example, last year's Software Technology Conference contained nine papers discussing the theory of software reuse [1, 2, 3, 4, 5, 6, 7, 8, 9], and four making some reference to actual applications of software reuse [10, 11, 12, 13], but only two that contain metrics of some sort. One of these presented percentage time savings in student coding [14] and the other listed a very large expected dollar savings without detailing how much would be due to reuse or how the savings were to be achieved [15]. The situation in books is worse, due to the lag in publication times. For example, the classic Prieto-Diaz/Arango book [16] was published in 1991 and contains articles from the late 80's. Only one of these articles discusses actual reuse and, at the time of its writing, no actual reuse had occurred. Shari Pfleeger [17] cites several reports of internal corporate high percentage reuse of code. Thus, despite a natural propensity for skepticism, there are real savings being achieved and with careful execution the application and savings can grow non-linearly.
Software reuse is not new. It is likely that no programmer has rewritten code when he or she could reuse sections of his or her own previous products. That practice is clearly cheaper in terms of personal effort. However, personal experience has taught us that these opportunities are limited, a teaching that colors our views of institutionalized software reuse.
A proper theory of reuse resets our expectations:
1. Reuse is not limited to just code. For example, domain knowledge, architectural structures and documentation can supply components for reuse, expanding the potential scope of savings. For this reason, systems reuse is a better term than software reuse.
2. Conscious collection of well documented components from multiple authors represents a manifold expansion of scope from single author reuse.
3. Properly planned reuse methodology results in improved reliability. Quality assurance practices require that code components must meet or exceed set standards and non-code components must be validated. Testing practices ensure that fielded components have been tested at least once and generally twice, greatly increasing reliability. This reliability increases as more systems reuse the component. Further, components for reuse must be fully documented.
4. By definition, a new system cannot consist solely of reused components. At the very least, the connective tissue among components must be new. Most likely the defining logic of the new system will be new. However, the mundane functions of the system are likely to comprise 50% of the structure and these mundane functions will have been done before! Potentially, they could be supplied by reused components.
2 History
The statement of purpose for the premiere systems reuse organization, the Army Reuse Center (ARC), found in Proposed ARC Reinvention Implementation: Guide to Reimbursable Operations [18], defines organized systems reuse and the ARC's part in it.
The ARC is in the business of providing software development organizations with the products and services to improve their productivity, particularly as relates to software life-cycle development asset reuse. The customer base of the ARC will primarily consist of Army elements, with significant portions from other parts of the [Department of Defense] DOD. Elements of other federal agencies will be targets of opportunity.
Several Army and DOD documents describe the need for such services and furnish estimates for the level of effort required. Among these documents are the following: Software Reuse Policy [19], PEO-STAMIS Reuse Implementation Plan [20], Information Management Software Reuse Policy [21], Intelligence and Electronic Warfare Software Reuse Policy Statement [22], SBIS Reuse Strategy [23], and Memorandum of Agreement between Program Manager, Reserve Component Automation System and Director, Army Reuse Center [24].
In 1989, the Army created the Reusable Ada Packages for Information Systems Development (RAPID) Center. Later, the Center replaced the word "Packages" with "Products" to emphasize the concept of reusing more than just code. RAPID Center personnel developed a tool to classify components and permit retrievals of potentially useful components. They also developed certification procedures, standards and domain analysis guidelines. These concepts and procedures were adopted at the Department of Defense level in the organization now named the Software Reuse Program and the tool has been renamed the Defense Software Reuse System (DSRS). Later, the RAPID Center changed its name and became the ARC, which continues to advance the practice and theory of reuse. For example, the original classification tool is not flawless and the ARC is modifying it to give users alternate methods for classification and search.
3 Issues
Several issues will impact the degree and nature of the success of systems reuse. Among these are industry/government access, legal issues, certification, and maintenance/ownership of stored components. The discipline of systems reuse is not new; however, the methodology, technology and costs associated with employing it are often roadblocks for those who desire to implement it. Proper organization aimed at achieving systems reuse can reduce costs and remove roadblocks. One proposal for the Army's organization is described below.
3.1 Organization
Hartley [25] discusses how the Army might proactively organize itself for systems reuse. The proposal is for a multi-tier system of systems reuse libraries. It is not cost effective for all facilities associated with systems reuse to perform all possible library functions, nor is it necessary. A multi-tier approach provides the needed facilities where they are accessible, while avoiding unneeded replication.
3.1.1 Tier 1: The Army Certification Facility (ACF)
The ACF is the Army Domain Systems Reuse Libraries (ADSRL) for the Army horizontal domain. It is also the interface with the DOD Defense Software Repository System (DSRS) library system. As such it is responsible for standards creation and maintenance and for asset certification within the Army.
3.1.2 Tier 2: ADSRLs
Each vertical domain and the Army horizontal domain will be served by a single logical ADSRL. The adjective "logical" means that multiple domains may be served by one physical library. This arrangement is consistent with the current situation, in which no domain is served by more than one systems reuse library. It permits, but does not require, the creation of new libraries to serve those domains without a separate library. It permits multiple domain services where desired. Thus, growth and changing circumstances are covered, both for expansion and contraction. ADSRLs differ from Army Software Repositories (ASRs) by ADSRL's possession of facilities for identification and evaluation of components within the domain and by possession of facilities for location and extraction of components.
3.1.3 Tier 3: ASRs
This tier represents the de facto situation in which Army activities, projects and contractors have potentially reusable components stored in various formats. Each of these is a software repository, albeit hitherto unlisted and generally undisciplined. Each of these potential components belongs, by its nature, to a particular subdomain. This tier represents the lowest level of Army approved systems reuse collection activities.
Figure 1. Libraries, Repositories and Domains.
3.2 Industry/Governmental Access
The class of Army contractors provides the simplest example of industrial users of the Army's reuse facilities. Subject to the legal issues discussed below, Army contractors provide contractor developed components (through their Army Contracting Officer) for inclusion in the libraries. As they work on Army contracts, they draw on the components in the libraries to provide software at a lower cost to the government through reuse.
Other non-governmental organization access must be performed through an Army organization and will be arranged on a case by case basis. Procedures will have to evolve through experience.
3.3 Legal Issues
There are two basic legal issues - both unresolved:
Intellectual Property What are a library's responsibilities with respect to others' intellectual property rights, and
Liability What is the possible liability resulting from qualifying and distributing reusable components?
The answers to these questions will impose requirements on library processes. The solutions involve imposing restrictions on acceptance of components and on the distribution (allowed extractions) of components. Agreements with component originators must be reached and information on distribution restrictions and disclaimers must be attached to the components. This component pedigree should be part of the certification process. Further, the distribution restrictions must be enforced. These modifications to library processes must be enabled by adequate library systems.
There are several potential classes of rights ownership with respect to software. Software may be wholly government owned, the government may have purchased certain rights (and not others), or the government may have no rights to the software at all (e.g., freeware software). Components of each type could potentially become library assets; however, some classes of rights ownership may be effectively prohibited because the library does not have the mechanisms needed to handle components of that class properly.
Legal issues are confusing and confused, both in case law and in regulations. The Defense Information Systems Agency (DISA) / Center for Information Management Reuse program has instituted a study of these issues which includes recommended actions. The Army should be guided by DISA in these matters.
3.4 Certification
Certification is a substitute for personal discussion of component attributes. For example, if an Air Force aviation organization approached an Army aviation organization, seeking to obtain source code and documentation for an aviation related component, personal discussion concerning the component's advantages, disadvantages, potential flaws, etc., would be possible, appropriate, and perhaps sufficient. However, in an impersonal library situation, personal discussions with experts is not possible and the growth of general reuse implies a volume of reuse that requires the impersonal library situation. Thus formal certification substitutes for the more complete personal discussion to provide a trustworthy mechanism for conveying as much of the needed information about a component as possible.
Certification depends on a common, understood, and accepted set of definitions and standards. The levels of certification inform the user about the depth of the information being conveyed. The component pedigree informs the user about ownership issues, distribution restrictions, etc. Certification is imperfect; however, it is better than nothing. A single point of certification reduces the problem of ensuring consistency and thus confidence. The ACF will be the Army's point of certification.
3.5 Maintenance/Ownership of Stored Components
The ADSRLs have the responsibility of maintaining the components within the libraries, including certain descriptive material. This maintenance consists of protective measures, such as maintaining back-ups; however, it does not include a warranty beyond what is implied by the certification level, if any. A library may store multiple versions of some components or may store only one version (depending on the submitter's discipline, perhaps the latest version).
Subject to legal issues, discussed above, the copy of a component contained in the library belongs to the library. A retrieved copy of the component belongs to the retriever. Legal issues may require maintenance of originator information with all copies. Regardless, courtesy and common sense require maintenance of this information, as the originator is the best source of additional information about the component.
3.6 Metrics
Several kinds of metrics are valuable. Collection of metrics will cost in resources and thus should be designed to collect useful information.
Metrics concerning the internal functioning of the library are important in assessing and improving processes and in determining total reuse costs to compare to benefits. Such metrics begin with raw numbers, e.g., number of components received, cataloged, and certified, and person hours expended. These metrics can be refined as needed. (Refinements will incur additional costs.)
Metrics concerning library usage are the next step in determining the value of reuse. These metrics include numbers of submissions (broken down by category and submitter), number of requests for information, and number of extractions. As reuse grows, extractions will be required from non-Army libraries, mediated by the ACF. Information about these more complex uses will provide additional metrics.
Metrics about actual reuse will be invaluable, because they will represent the benefit side of the comparison of costs and benefits. The library system represents the best focal point for this collection; however, the libraries will not know this information from direct experience. They must rely on reports from the library system users. Desirable metrics would include such things as lines of code used, cost avoided by such use, and cost of adapting the extracted component.
The ultimate metric for the Army will be total dollars spent on reuse activities versus cost avoided by reuse.
3.7 Other Issues
Other issues must be addressed, such as interoperability of reuse libraries, security of classified materials, Freedom of Information Act requirements, and the contradictions between Federal Acquisition Regulation and Defense Federal Acquisition Regulation clauses with regard to software. If incentive fees, royalties, and other fees are to be paid, mechanisms for control and accounting must be defined and instituted.
3.8 Inhibitors
There are several technical inhibitors to successful reuse. Methodologies and standards do not include reuse as an integral part, only as an afterthought. The quality of the (potentially) reusable components is uncertain. Various representations of the components cause uncertainty: if code, what language? if design or analysis, what method or what notation? Despite these problems, technical issues are not major inhibitors of reuse.
As seen in the discussion of issues, the majority of current inhibitors are non-technical:
There is confusion over legal issues, including ownership rights and warranties.
There is a lack of wide understanding/acceptance of a solid reuse economic model.
Standard productivity metrics oppose reuse by limiting the scope to the particular project. Thus, the cost of creating reusable software is not within the project's budget.
There is a perception (rather than reality) in the make vs. buy decision that it is easier/faster to write a component than to find a component.
There is the "Not Invented Here" syndrome.
If reuse means greater productivity, that means fewer personnel and, hence, a smaller empire.
There was little emphasis on reuse in computer science, as taught in school.
Together, these can represent a formidable set of inhibitors to systems reuse.
4 The Proof
Despite the number and complexity of potential reuse inhibitors, systems reuse is being successfully practiced. Before exhibiting a proof that systems reuse is delivering on its promises, it is important to define what is meant by the term "cost savings."
4.1 Defining Cost Savings
Operationally, reuse may be divided into opportunistic and systematic reuse. Salvaging or scavenging one's own earlier code represents opportunistic reuse. On the other hand, designing software in self-contained modules, with future reuse by others in mind, represents systematic reuse. Clearly systematic reuse presents the greatest opportunity for future savings and opportunistic reuse offers a stopgap process. The best program combines both opportunistic and systematic reuse.
The ARC, with the absolutely irreplaceable support of its customers, has projected in Fiscal Year 1994 local savings through systems reuse of over $7 million. The facts behind this statement constitute the existence proof of this article's title.
Cost savings are easier to define than to measure. The savings that accrue to a methodology are the difference in total costs incurred in using that methodology as compared to the total costs incurred in using another methodology, should the difference be positive. For instance, define the following variables:
DCostS i = the cost of developing software system i using the standard methodology,
DCostR i = the cost of developing software system i using systems reuse,
MCostS i = the cost of maintaining software system i (developed using the standard methodology),
MCostR i = the cost of maintaining software system i(developed using systems reuse),
OCostS = the overhead cost of developing software systems using the standard methodology,
OCostR = the overhead cost of developing software systems using systems reuse (e.g., the costs of a systems reuse library),
TCostS = the total cost of developing software systems using the standard methodology, and
TCostR = the total cost of developing software systems using systems reuse.
For each system, the total costs are the life cycle costs, that is the allocated overhead costs plus the development costs plus the maintenance costs. Alternatively, the methodology costs may be stated as the sum of the overhead costs, the development costs and the maintenance costs of all systems. Thus, on a global basis, we have
TCostS = OCostS + SUMi DCostS i + SUMi MCostS i ,
and,
TCostR = OCostR + SUMi DCostR i + SUMi MCostR i , (1)
where the i subscript represents each software system.
If
TCostS - TCostR > 0, (2)
then systems reuse has a cost savings. This is a global savings and is based on all systems. A local development cost savings applies (in the reuse case) to a set, J, of systems with common components that are either reused or reinvented. Here,
SUMi in J DCostS i - SUMi in J DCostR i > 0, (3)
defines the local cost savings. Note that overhead and maintenance costs are ignored. For global cost savings to occur, the overhead and maintenance costs must be included.
It is important to understand what comprises the overhead. In the reuse methodology, overhead includes the efforts outside of any given software project to ensure that assets are properly developed for reuse and are reused properly. These efforts are direct reuse methodology overhead. Indirect overhead includes such things as reuse libraries to store and maintain assets for future reuse and reuse services such as developing and teaching reuse courses.
Planned reuse can save in both the development and in the maintenance costs for common software; however, only development cost savings are calculated here. In theory, reuse savings increase when maintenance costs are taken into consideration. The methodology for computing system development costs is straightforward:
Developing the same software for n different systems costs n times what it would cost to develop the software for one system.
Developing software to be reused by n different systems costs the same as developing the software for one system, multiplied by a factor covering additional time to maximize the reusability of the code and to test the code.
The costs savings is the difference between the two costs. (Notice that if n=1, the savings is negative because developing software for reuse is more expensive than developing software for single use, on a simple cost per line of code basis.
4.2 Actual Data
The ARC contribution to OCostR, the overhead costs of reuse, is the cost of operating the ARC's systems reuse library. Estimates for this cost for Fiscal Year (FY) 94 -98 are given in Hartley, Hyder and Treadwell [18]. These cost estimates decline from $2.2 million in FY 94 to $1.4 million in FY 98.
We will assume that the overhead costs under the standard methodology are negligible. Thus OCostS = 0.
Hartley, Rohardt and Stropky [26] describe the FY 94 systematic reuse projects and their status, including local cost savings. Identifying reuse opportunities was the first step of the Systematic Reuse Process. During this process, the common requirements of the systems that would be in the development phase or initiating development during FY 94 were determined. Scenarios that promised the most reuse possibilities in FY 94 were selected to be proposed to PEO STAMIS and the involved systems.
Based on a high-level domain analysis, the ARC identified seven potential reuse scenarios for systematic reuse in FY 94. These scenarios were:
Military Standard Requisitioning and Issue Procedures (MILSTRIP) Transactions,
Ad Hoc Query,
Catalog Process,
Display Manager,
System/Password Security,
Report Generator, and
File Manager.
After analysis, the File Manager scenario was canceled and two new scenarios were added:
Automated Documents Register, and
Communications (Store/Forward Function).
For each of the approved scenarios, design workshops were held to discuss the technical issues and determine the reuse feasibility in FY 94. During the workshop, participants defined the generic requirements in order to design a generic component. A donor system was assigned to develop the component. The workshop ensured that the potential client systems had input into the design of the component to be developed and that their requirements were met. If necessary, additional workshops were conducted to further define the common requirements.
Once the donor and the client(s) had agreed upon the design of the component, the assigned donor system proceeded with the development effort. The goal of the development effort was to make the component as reusable as possible. Part of this development process was to identify existing components that could meet the common requirements and to re-engineer the components, if necessary. Therefore, donors could still take advantage of opportunistic reuse (reuse of existing components) while actively pursuing planned reuse.
Once the development of the reusable component is completed, the client system(s) will integrate the component within their system(s). The integration may require adaptation or re-engineering by the client system(s) in order to conform to their specific requirements.
Each of the reuse scenarios was discussed at the Systematic Reuse Workshop in January, 1994. Subsequently, the reuse scenarios were discussed in design workshops. Figure 2 is provided as an aid to visualizing the timing of the activities from an overall perspective.
Figure 2. Overview of the timing of systematic reuse activities.
Based upon the results of the systematic reuse activities addressed in this document, Table 1 presents the reuse scenarios that offer reuse possibilities in FY 94. The ARC has laid the groundwork for these scenarios. To help ensure that these reuse projections are met, the ARC must continue its current efforts to facilitate the realization of reuse. Activities to foster the realization of reuse are proposed in Section 3 under each corresponding scenario.
| SCENARIO | DONOR | CLIENT(s) |
| MILSTRIP | SAAS Mod | SMS |
| Ad Hoc Query | JOPES | SMS |
| Password Generator | SAMS-I/TDA | SMS SAAS Mod |
| Report Generator | SIDPERS-3 ARC Library |
SMS SAAS Mod |
Table 1. Projected Scenarios for FY 94.
The estimated cost savings for each scenario is shown in Table 2. The details of this approach are taken from the development of the Army Tactical Command and Control Systems (ATCCS). The cost methodology is a version of the Constructive Cost Model (COCOMO), called the Revised Intermediate COCOMO (REVIC). The basic cost is set at $200 per source line of Ada code. The reuse cost multiplier is 1.38. A more detailed discussion of this subject can be found in the Program Executive Office Standard Army Management Information Systems (PEO STAMIS) document, PEO STAMIS Reuse Implementation Plan [20], Report Number 1213-70-210/15.1, 30 September 1993. In addition to cost savings, return on investment (ROI) metrics would be desirable; however, investment costs have not as yet been well enough defined to permit calculating meaningful ROI numbers.
| SCENARIO | Approx Lines of Code | PROJECTED COST SAVINGS
DCostS i - DCostR i |
| MILSTRIP | 5 K | $ 620 K |
| Ad Hoc Query | 20 K | $ 2480 K* |
| Password Generator | 3 K | $ 972 K |
| Report Generator | 10 K | $ 3240 K |
| TOTAL | 38 K | $ 7312 K |
Table 2. Projected Cost Savings.
* Even though this component already exists, the calculations for this scenario are based on systematic reuse. This reflects the cost associated if the client system were to develop the component capabilities from scratch.
These systematic reuse benefits derive from scenarios where a donor system develops a common component with reuse in mind, and one or more client systems reuse the component. For a client system, the cost savings are reflected in the development cost. For an organization, the reuse benefits are reflected in the number of client systems reusing the component developed by a donor system. The benefits increase when the number of client systems increases. In order to accomplish a return on investment for PEO STAMIS in FY 94, the ARC is trying to maximize the systematic reuse benefits with the scenarios selected for FY 94.
These activities will require at least FY 95 to complete, and possibly FY 96. Thus their savings might be balanced against the roughly $6.4 million overhead costs for those three years. However, additional systematic reuse projects will start in FY 95 and FY 96, carrying their own savings. Thus, a conservative accounting would be to balance the estimated $7.3 million dollars of savings against estimated $4.4 million dollars of costs for FY 94 and FY 95. It is reasonable to assume that reuse of components will lead to maintenance savings; however, another conservative assumption is that there will be no net savings for reuse over standard methodology in maintenance costs. The mathematical statements are
SUMi in J DCostS i - SUMi in J DCostR i = $7.3 M, (4)
OCostS - OCostR = -$4.4 M, (5)
MCostS - MCostR = 0. (5)
Thus, within the Army, for FY 94 and FY 95 there is an estimated net savings of $2.9 million, stated mathematically,
TCostS - TCostR = $2.9 M. (6)
This is at least $1.4 million per year of global savings generated by systems reuse within the Army.
5 Conclusion - the Future
The ARC maintains a library of reusable components. It collects, certifies and classifies these components. It teaches about reuse and how to perform reuse. It supplies personnel to aid in reuse activities. In FY 94, the ARC initiated a program of systematic reuse with PEO STAMIS. The systems under development already had deadlines and budgets. Potential reuse opportunities were limited to functional possibilities. Some systems dropped out of the program because they could not support additional costs to benefit other systems. Despite these real problems, real savings were achieved.
Software reuse and, more generally, systems reuse are more than theory, software is being reused in real systems. Not only is the practice of systems reuse an actuality, it is also making good its promises for cost savings. The Army Reuse Center is creating the environment that supports the practice and is providing the cross-system technical support that is needed for continuity.
Theory says, as systems embrace reuse earlier in their development cycles and as the library of reusable components grows, actual reuse will grow non-linearly. The growth curve will be geometric for several years, then taper off as saturation is reached. What will happen in the future is unknown; however, the ARC has a practical incentive to make the theory into reality. The ARC, along with other similar DOD organizations, is undergoing transition to required reimbursable activity and then to fee-for-service status. The ARC will live or die by its success in making systems reuse pay off for the ARC's customers. The success described here must be just the beginning.
Acronyms
ACF Army Certification Facility
ADSRL Army Domain Systems Reuse Libraries
ARC Army Reuse Center
ASR Army Software Repository
ATCCS Army Tactical Command and Control Systems
COCOMO Constructive Cost Model
DISA Defense Information Systems Agency
DOD Department of Defense
DSRS Defense Software Repository System
FY Fiscal Year
I/TDA Installation/Table of Distribution and Allowances
JOPES Joint Operations Planning and Execution System
MILSTRIP Military Standard Requisitioning and Issue Procedures
PEO STAMIS Program Executive Office Standard Army Management Information Systems
REVIC Revised Intermediate COCOMO
ROI Return on Investment
SAAS Standard Army Ammunition System
SAMS Standard Army Maintenance System
SBIS Sustaining Base Information Services
SIDPERS-3 Standard Installation/Division Personnel System -3
SMS Standard Maintenance System Software
References
[1] Abdel-Hamid, Tarek K. "Modeling the Dynamics of Software Reuse: An Integrating System Dynamics Perspective," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[2] Baxter, Murray B. "Legal Issues and Non-Issues for Reuse Libraries," Proceedings from the Software Technology Conference 1994. 1994.
[3] Huber, Theresa R.. "Reducing Risks for Government Software Reuse Libraries," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[4] Lichota, Randall W. and Paul Valdez. "A Process for Domain-Specific Software Reuse with Application to Command Center Development," Proceedings from the Software Technology Conference 1994. 1994.
[5] Mayes, Gary N. "Evaluating Reusability in Legacy Software Components," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[6] Owens, Ronald L. and Marrea H. Riggs. "A Multifaceted Approach for Systematic Implementation of Software Reuse," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[7] Rathbun, Robert W. "Software Reuse Metrics," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[8] Samadani, Hamid. "Reuse of CASE Components: Army Reuse Center Tackles CASE-Based Reuse," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[9] Johnson, Robert E., Jr. "The Army Software Reuse Program," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[10] Canal, Kathy L. and Michael J. Foley. "Utilization of Reuse for Software Development," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[11] Dowdee, John W. and Paul A. Nussbaum. "Practical Guidelines for Reusing Ada Ground Station Software," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[12] Wickman, Grant R. and James Solderitsch. "A Systematic Software Reuse Program Based on an Architecture-Centric Domain Analysis," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[13] Hudson, Wendy J. "Reuse-based Re-engineering for Army IEW Systems," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[14] Lawlis, Patricia K. and Mark S. Snyder. "An Object-Oriented Software Architecture for Large-Scale Reuse," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[15] Levine, Stanley H. "An Existing Perfect Software Reuse Architecture," Proceedings from the Sixth Annual Software Technology Conference. 1994.
[16] Prieto-Diaz, Ruben and Guillermo Arango. Domain Analysis and Software Systems Modeling, IEEE Computer Society Press, Los Alamitos, CA. 1991.
[17] Pfleeger, Shari Lawrence. Software Engineering: The Production of Quality Software, Macmillan. 1991.
[18] Hartley, Dean S. III, B. Wayne Hyder and Jim N. Treadwell. Proposed ARC Reinvention Implementation: Guide to Reimbursable Operations, K/DSRD-1689, Limited Distribution. Martin Marietta Energy Systems, Inc. 1994.
[19] Software Reuse Policy, Department of The Army, 15 March 1994, Draft.
[20] PEO STAMIS Reuse Implementation Plan, Report Number 1213-70-210/15.1, 30 September 1993.
[21] Information Management Software Reuse Policy, USAISSC Memorandum Number 25-17, 28 October 1993.
[22] Intelligence and Electronic Warfare Software Reuse Policy Statement, PEO IEW Memorandum Number 034, 8 December 1993.
[23] SBIS Reuse Strategy, 2 February 1994.
[24] Memorandum of Agreement between Program Manager, Reserve Component Automation System and Director, Army Reuse Center, 28 February 1994.
[25] Hartley, Dean S. III. Proposed Army Software Reuse Library Strategy, K/DSRD-1757, Limited Distribution. Martin Marietta Energy Systems, Inc. 1994.
[26] Hartley, Dean S. III, Claudia Rohardt and Maria Stropky. Systematic Reuse Status Report, K/DSRD-1756, Limited Distribution. Martin Marietta Energy Systems, Inc. 1994.
1 Work sponsored by U.S. Army Reuse Center under DOE Project Number 1776-1776-A1 with the U.S. Department of Energy and performed by Martin Marietta Energy Systems, Inc.
This manuscript has been authored by a contractor of the U.S. Government under contract DE-AC05-84OR21400. Accordingly, the U.S. Government retains a nonexclusive, royalty-free license to publish or reproduce the published form of this contribution, or allow others to do so, for U.S. Government Purposes.
2 Published at STC '95; Track 10, Reuse; Wednesday, April 12, 1995
3 CACI, Inc. - Federal, under subcontract no. 87KRF091C.
If you arrived here using a keyword shortcut, you may use your browser's "back" key to return to the keyword distribution page.
Return to Hartley's Projects Page