SBIS REUSE STRATEGY Last updated: 22 March 1994 Jeffrey S. Poulin First draft: 17 November 1993 Loral Federal Systems-Owego Rt. 17C, MD 0124 Owego, NY 13827 poulinj@lfs.loral.com ii SBIS Reuse Strategy CONTENTS ________ SBIS REUSE STRATEGY . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Reuse Terms and Methods . . . . . . . . . . . . . . . . . . . . . . . . 2 SBIS Reuse Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Personnel Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 Software Development Manager . . . . . . . . . . . . . . . . . . . . . 6 SBIS Reuse Coordinator . . . . . . . . . . . . . . . . . . . . . . . . 6 Project Reuse Leads . . . . . . . . . . . . . . . . . . . . . . . . . . 7 SBIS Reuse Working Group . . . . . . . . . . . . . . . . . . . . . . . 7 Librarian/Reuse Development Team . . . . . . . . . . . . . . . . . . . 8 Application Developers . . . . . . . . . . . . . . . . . . . . . . . . 8 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Application development . . . . . . . . . . . . . . . . . . . . . . . . 8 Finding and retrieving existing assets . . . . . . . . . . . . . . . 12 Control of shared resources . . . . . . . . . . . . . . . . . . . . . 13 Constructing a domain framework . . . . . . . . . . . . . . . . . . . 14 Legal Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 14 Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Observable data . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Reuse Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Measuring Reusability . . . . . . . . . . . . . . . . . . . . . . . . 21 Addendum: Available Reusable Assets . . . . . . . . . . . . . . . . . . 23 Addendum: Application Programming Interface (API) List . . . . . . . . 25 Addendum: Reuse Library Contact Information . . . . . . . . . . . . . . 27 Addendum: SBIS GOTS/COTS Analysis Report . . . . . . . . . . . . . . . 29 Addendum: A Reusable Software Inspection Checklist . . . . . . . . . . 32 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Contents iii iv SBIS Reuse Strategy SBIS REUSE STRATEGY ___________________ OVERVIEW ________ The Sustaining Base Information Services (SBIS) Reuse Strategy consists of two phases. In the first phase, we will provide collections of utility soft- ware (string functions, abstract data types) for developers. Developers will use these general-purpose software to lay the foundation for the first incre- ment of applications. In the second phase, we will analyze the area of Army Management Information Systems (MIS) based on our SBIS experience and iden- tify reusable components to make into a core set of application building blocks. Since this process requires a thorough understanding of the target computing and customer environment, or domain, we plan to initiate this anal- _______ ysis after SBIS Increment One. This strategic approach will lead to the con- struction of a framework (domain architecture) which allows developers to quickly assemble these building blocks into SBIS applications. We have the goal of institutionalizing reuse, or fully integrating reuse __________________ activities into the SBIS development cycle. This means that at every phase of every iteration in the SBIS development process, we look for reuse oppor- tunities. Every member of the SBIS team has an assigned responsibility for ensuring this happens; managers must support and encourage, reuse leaders must actively pursue, and developers must take the initiative. This strategy will make reuse "Business as Usual (BAU)" on the SBIS program. The SBIS Reuse Strategy consists of: o An overview of reuse concepts, to include the experiences and foundation for the strategy o Organizational support, to include personnel requirements and responsi- bilities of key individuals in the SBIS reuse organization o A description of how reuse fits into the SBIS software development process o A discussion of how we will measure reuse on SBIS, to include an explana- tion of the metric terms used by the groups involved o A list of currently available reusable software and resources. The SBIS reuse strategy builds on lessons learned in the IBM corporate reuse program, recognized in industry as one of the best in the industry. It com- plies with the vision and strategy for the Department of Defense [16], the Army [60], and the SBIS Program Office [28]. The strategy tailors the Federal Systems Company Reuse Steering Group Guidelines and the Owego Site Reuse Operating Procedure [29] to meet the specific demands and requirements of the SBIS customer. SBIS Reuse Strategy 1 BACKGROUND __________ REUSE TERMS AND METHODS Reuse Terms We normally consider "software" reuse as the use of existing source code com- ponents to develop new applications [22]. However, reusable software compo- nents can take many other forms, including: o Executable programs o Code segments o Documentation o Requirements o Design and architectures o Test data and test plans o Knowledge and experience Unfortunately, no one has yet provided a good definition of reuse in these non-code areas, much less define a good way to quantify that reuse [48]. However, studies indicate that code-based software metrics serve as a reli- able secondary indicator of work done in these areas [56] and therefore, until we can develop a reliable method for assessing reuse in these other areas, we will focus our efforts on code reuse. With that in mind, we define a reusable component as a software module, or Computer Software Unit (CSU). More formally, we define a reusable component as a group of logically-related (or inter-related) functionally-related Ada library units (Ada packages) that provide logically-related or functionally- related services. A reuse component may take the form of a reusable "building block" that offers primitive operations on top of which programmers can develop more complex and specific capabilities. A reuse component may also consist of something more elaborate than building blocks by offering some general-purpose services to meet a specific need. Such a component usually consists of a generic Ada package or a collection (family) of functionally-related Ada packages. A reuse component may consist of multiple inter-related Ada packages and provide different levels of abstractions [30]. Reuse takes place when a developer in one application team simply uses a com- ponent provided by another application team rather than develop it again. Planned versus Unplanned Reuse Reuse takes two primary forms in an organization; either it happens by acci- dent (opportunistic reuse) or the organization plans and designs reuse into their development process (systematic reuse) [22]. Almost every organization practices opportunistic reuse by salvaging old information in some ad-hoc fashion. People routinely save a little time by modifying something similar to their current need. However, the benefits to this white-box reuse, or copying and modifying assets, has limitations. The _________ new asset must undergo the same testing, configuration management, mainte- 2 SBIS Reuse Strategy nance, documentation, and all the other requirements as a new asset. In other words, white-box reuse achieves a marginal savings during development only. On the other hand, an organization that practices systematic reuse plans and formally integrates reuse into a well-defined software development process. In formal reuse, developers focus on the use of black-box assets, or unmodi- _________ fied software components. This means the developer does not alter the source files of the reusable asset; if necessary, the developer makes all behavior modifications through parameter passing, generic instantiations, or (in the case of object-oriented languages such as Ada 9x), inheritance and polymorphism. The benefits to black-box reuse greatly exceed those of white-box reuse. This occurs because the developer knows the component func- tions correctly and can avoid a lot of effort, especially in the unit test through maintenance phases. Furthermore, because the developer does not even need to know how the component implements the desired function, this raises the level of abstraction required to program, accelerates the learning curve, lowers the perceived software complexity, and reduces the effort required to enhance and maintain the final product. In the case of SBIS, the SBIS team has committed to making formal, systematic reuse a key part of application development. The Scope of Reusable Software Many characterize reuse as vertical or horizontal, depending on attributes of ________ ___________ the software and the domain. Most programs make use of a standard set of domain-independent, general- purpose utility software. This utility software provides a good example of horizontal reuse, or reuse across domains. Most programmers have experience __________________ in horizontal reuse by way of mathematical subroutines or I/O libraries. Although horizontal reuse has stable and low risk benefits, these benefits have upper limits due to the generally small size and scope of domain- independent software. Although an accepted upper bound sets this limit at around 20% of an application, the National Institute of Standards and Tech- nology (NIST) helps expand these opportunities by sponsoring national and industry standard interfaces between products [19]. The SBIS team plans to get the maximum benefit from horizontal reuse opportunities provided by Open System Standards through the use of Application Programming Interfaces (APIs) developed for access to POSIX operating system services and Commercial-Of- the-Shelf (COTS) products [33]. See the attached list of SBIS APIs for more information. SBIS Reuse Strategy 3 Amount of Application Application- *-* *-* *-* *-* *-* *-* 100% Specific | |...| | | |...| | | |...| | *-* *-* *-* *-* *-* *-* Domain- *-------* *-------* *-------* 85% Dependent | | | | | | | Ops & | | Info. | | MIS | | Plans | ... | Mgt | ... | | | | | | | | | | | | | | *-------* *-------* *-------* Domain- *-------------------------------------------* 20% Independent | | | Utilities, ADTs, System Services, etc. | | | *-------------------------------------------* 0% Figure 1. The Three Classes of Software. A typical application will consist of up to 20% general-purpose domain-independent software and up to __________________ another 60% of reusable software built specifically for that appli- cation domain. The remainder of the application will consist of custom software written exclusively for the application and having relatively little utility elsewhere. Vertical reuse, on the other hand, takes place within a domain or a family of _______________ related systems. Vertical reuse has a tremendous potential benefit when building many applications within a related area, such as SBIS, because each application can make use of common objects and operations. An accepted figure for reuse potential in the SBIS domain of business applications ranges from 75% to 90% [35]. We expect to exploit these opportunities during the second phase of this strategy by building a framework consisting of a domain- specific architecture and software. Within this domain architecture we plan to develop domain-specific resources for areas such as: o Resource Management (10 applications) o Logistics (13 applications) o Operations and Plans (11 applications) o Personnel (18 applications) o Information Management (16 applications) o Installation Management (2 applications) o Engineering (4 applications) o Legal (10 applications) 4 SBIS Reuse Strategy Consumer/Producer Relationships Reuse involves not only the use of assets from another application team or program. A successful reuse program requires someone to produce sharable assets in the first place [7]. In short, a reuse consumer seeks to reduce ______________ costs through reuse of work products; a reuse producer works to increase the ______________ reusability of work products. Everyone in a reuse program has responsibility for reuse consumption and for identifying opportunities for production. Once identified, the most cost-effective method for producing and maintaining shared assets depends on the ability to pass control of those assets to a central team that performs this function for the entire program. SBIS REUSE PHILOSOPHY _____________________ To successfully insert, or institutionalize reuse, we do not want to overtly ________________ distinguish between reusable code and application-specific code. Using shared software should come as naturally and as easily as working with any other SBIS software. Although we will logically have reusable collections of software, the physical implementation will mirror the process and tools used for all application code. We will use the same configuration management tools, the same file structure, and the same source code control system for reusable software as we do for all software. The term "reuse library" does not, therefore, refer to a tool, but rather to the collection of components used and reused to build SBIS applications. These collections of software include: o Motif GUI libraries o APIs to COTS software o Existing Ada utility libraries o Domain-specific software we create This approach has a solid foundation in view of experiences gained through a plethora of library-centric reuse programs [41], [23], [46], [36], [34]. In addition, we have witnessed impressive software reuse successes in specific application areas (e.g., avionics, flight control, OSI telecommunications, distributed applications, management information systems, simulation, client- server telecommunications) through the use of software engineered for use within those areas [38], [3], [10], [21], [40], [54]. We also note that many of these documented successes occur independent of complex library systems or elaborate tools [58], a finding verified on previous IBM FSC Owego contracts [37], to include the Circuit-Card Assembly and Processing System (CCAPS) [9]. Because the use of generic, domain-independent software provides the founda- tion for but not the key to high levels of reuse on specific projects [5], [49], we do not want to focus on this activity. On the other hand, many requirements for achieving high levels of reuse within a domain require anal- ysis and experience which we can only achieve after some initial development [20], [34]. To give the application developers time to gain this experience, we plan to conduct our analysis of SBIS after completion of the first incre- ment of initial applications. This will allow us to base our domain analysis [1], [51] on tangible evidence and to build a solid domain framework for future deliverables [59]. SBIS Reuse Strategy 5 PERSONNEL REQUIREMENTS ______________________ A successful reuse program requires management commitment, emphasis, and con- tinued support. The manager's prime contact, the SBIS Reuse Coordinator, has _______________________ overall responsibility for the reuse organization and progress. The SBIS Reuse Coordinator works regularly with a member of each application develop- ment team who has the additional responsibility of Project Reuse Lead for ____________________ that SBIS application. The Project Reuse Leads help their respective appli- cations by hunting for reuse opportunities and, by working with the SBIS Reuse Coordinator, identifying assets for use by their counterparts on other applications. The remainder of this section will discuss in more detail responsibilities of each of these people; it follows the IBM and LFS-Owego Reuse Operating Procedure in terms specific to the mission and organization of SBIS [29]. SOFTWARE DEVELOPMENT MANAGER The Software Development Manager has sole responsibility for maintaining emphasis on the SBIS reuse program. The manager does this by personal involvement and demonstrating commitment through allocation of resources and by requesting regular reuse status reports. The manager must: 1. Designate one technical person to serve as the full-time SBIS Reuse Coor- dinator and ensure that each SBIS application team has a part-time Project Reuse Lead. 2. Allocate time to the SBIS Reuse Coordinator to educate and train each member of the development staff as necessary. 3. Allocate resources to the Librarian/Reuse Development Team for the iden- tification, development, and maintenance of inter-project reusable compo- nents (software developed during a project that provides common services). 4. Regularly request and track the SBIS software reuse metrics.(1) As part ______________________________________________________________ of this task, establish baselines and reuse goals for each application in support of the first increment reuse goal of 15% and the second increment reuse goal of 55%. SBIS REUSE COORDINATOR The SBIS Reuse Coordinator has primary responsibility for the implementation of the SBIS reuse program and serves as the focal point for sharing informa- tion among application teams. In this role, this full-time person has to know generally about all available software and constantly acquire and process who-does-what and who-needs-what. The SBIS Reuse Coordinator: 1. Leads the SBIS reuse effort. 2. Applies the guidance given in this reuse strategy with enthusiasm and discretion. 3. Identifies opportunities for inter-project reuse. --------------- (1) See the Measurements section of this strategy. ____________ 6 SBIS Reuse Strategy 4. Plans for and coordinates reuse education and training. 5. Works with Project Reuse Leads to evaluate reuse experiences from pre- vious applications for use on current projects. 6. Publicizes available sharable resources as appropriate. 7. Ensures easy access to sharable resources. 8. Ensures sharable resources comply with the SBIS configuration management policy so that all projects using an asset receive notification of any changes made to the asset. 9. Works with software management and project management on all SBIS reuse issues. 10. Ensures all shared assets have no legal restrictions for use on SBIS. 11. Participates in application requirements reviews, design reviews, and inspections to help identify reusable components. Provides management with technical evaluations of reuse versus new development trade-offs. 12. Assists management in coordinating the development of inter-project reus- able components. 13. Captures and analyzes the reuse metrics and provides regular status reports to management. 14. Leads the SBIS Reuse Working Group. 15. Interfaces with the Owego site reuse champion. 16. Interfaces with the Owego representative to the FSC Reuse Steering Groups regarding FSC reuse strategy/processes. 17. Interfaces with external reuse organizations such as the US Army Reuse Center (ARC). The SBIS Reuse Coordinator also has primary responsibility for searching government-owned reuse libraries for assets that meet SBIS requirements and for ensuring the assets originating in the SBIS program and destined for gov- ernment libraries receive appropriate testing, validation, documentation, and other reusability requirements. This reduces the need for multiple accounts in these external reuse libraries and makes a single point of contact for any communication with the organizations that run the libraries. PROJECT REUSE LEADS Each application team will have a part-time "Project Reuse Lead." This person works with the SBIS Reuse Coordinator to find needed assets and help other application reuse leads locate assets whenever possible. The Project Reuse Lead has responsibility for all reuse activities within the SBIS application and for reporting that activity to the SBIS Reuse Coordinator. The Project Reuse Lead evaluates reuse experiences from other applications for use on the current project and serves as a member of the SBIS Reuse Working Group. SBIS REUSE WORKING GROUP The group comprised of all Project Reuse Leads forms the nucleus of the SBIS Reuse Working Group; other members include representatives from the Army Reuse Center (ARC). The SBIS Reuse Coordinator chairs the Reuse Working Group on behalf of the Software Development Manager. The SBIS Reuse Working Group promotes software reuse; it identifies, reviews, and approves reuse components, tracks reuse metrics, and coordinates and controls reuse develop- ment. The group meets once per month or as needed to provide a forum for SBIS Reuse Strategy 7 representatives from across SBIS to identify reuse components and to discuss issues related to existing components. LIBRARIAN/REUSE DEVELOPMENT TEAM Once we identify assets common to several SBIS applications, we need to place responsibility for final design, development, support, and configuration control of these assets with the SBIS reuse librarian. As the collection of shared resources grows, the librarian will need help from a dedicated team of 1-3 developers to assess Design Change Requests (DCRs), prioritize requests for new assets, and control modifications to the existing shared (reusable) assets. This group will grow until the end of Increment One, when it will form the nucleus of all domain analysis efforts. As a support organization, this group will report directly to the SBIS Software Development Manager and will fall under the operational control of the SBIS Reuse Coordinator. APPLICATION DEVELOPERS Every member of the SBIS development team must remain aware of assets avail- able in the SBIS Repository or used in other applications and must incorpo- rate those assets into their modules and other work products. Developers must also help identify modules and other work products that might find use on other SBIS applications and bring them to the attention of their Project Reuse Lead and other members of the technical staff. Every person has a role and should participate in the development and implementation of the software reuse strategy, implementation of application reuse plans, and in the final evaluation of project reuse achievements. PROCESS _______ APPLICATION DEVELOPMENT As the development teams move through the development cycle, they must take every opportunity to examine where they can save effort through the use of existing resources. This applies equally to information such as designs and test cases as it does to source code. As the team iterates through the development cycle, the Project Reuse Lead examines available resources and tries to locate existing work products rather than re-develop them. When examining available resources, the first "Priority of Use" goes to Gov- ernment Owned Software (GOTS) that meets the current requirement. The Project Reuse Lead should work with the SBIS Reuse Coordinator to locate GOTS software in one of several DoD reuse libraries. The SBIS coordinator will search these libraries and work with government library experts to identify candidate components. The second priority of use goes to COTS products, because we can often purchase commercial packages at less cost than it takes to develop them. In either case, upon completing an examination of an existing component or product, the team lead must complete a a SBIS GOTS/COTS Analysis Report form to record the findings of the analysis and provide rationale for any decision to the Army. An addendum to this strategy con- 8 SBIS Reuse Strategy tains a sample SBIS GOTS/COTS Analysis Report. New development will take place, therefore, only if existing components do not meet requirements [32]. Other than emphasizing the use of existing assets throughout, the basic soft- ware development process remains unchanged. The applications define require- ments through Joint Application Development (JAD) sessions with the customer and perform design activities in accordance with sound software engineering principles [50] and object-based techniques [6]. However, application team _________________________ members may tailor requirements, designs, or other application work products _____________________________________________________________________________ based on knowledge of existing assets [52]. ______________________________________ In other words, designers and developers should actively work to modify the application to make use of previous work. This may mean making a business decision as to whether to possibly postpone, drop, or change the details of a specific requirement. Benefits to the application include allowing applica- tion programmers to develop within a consistent framework and allowing them to make maximum use of resources. Benefits to the customer include ensuring a consistent look, feel, and behavior of applications and reducing the overall cost of the application. SBIS Reuse Strategy 9 +---------------------------------------------------------------------------+ | Table 1 (Page 1 of 3). Reuse Milestones | +------------------+--------------------------------------------------------+ | PHASE | TASK (1) | +------------------+--------------------------------------------------------+ | Planning and | o Designate Project Reuse Lead | | Business Engi- | o Project Reuse Lead (PRL) contacts SBIS Reuse Coor- | | neering Phase | dinator | | | - PRL reads and understands the SBIS Reuse | | | Strategy | | | - PRL identifies COTS/GOTS reviewers/evaluators | | | and forms a reuse team | | | o Establish file structure and management plan for | | | configuration and Repository management | | | - PRL contacts the CCC Database administrator | | | - Define/grant directory and file system access | | | modes | | | o Conduct preliminary reuse opportunity assessment | | | based on search of available asset collections | | | o PRL meets with SBIS Reuse Coordinator to define | | | search parameters and jointly search external GOTS | | | reuse libraries | | | - Obtain identified GOTS software and place in | | | CCC | | | o Conduct initial market survey of applicable COTS | | | products | | | o Prepare hard/soft catalog of available assets | | | o Set application reuse goals | | | - Application goal must support the Increment | | | One goal of 15%. | | | - Application goal must support the Increment | | | Two goal of 55%. | +------------------+--------------------------------------------------------+ | System Design | o Present findings and rationale of preliminary | | Review | design review and reuse goals | | (SDR)/Preliminary| | | Design Review | | | (PDR) | | +------------------+--------------------------------------------------------+ 10 SBIS Reuse Strategy +------------------+--------------------------------------------------------+ | Requirements | o Review for large areas of reuse by examining | | Analysis Phase | related SBIS applications. | | | - Meet with other PRLs | | | - During Increment One, coordinate design activ- | | | ities to consolidate common functions | | | - During subsequent increments, examine compo- | | | nents of the domain library | | | o Identify and select reusable process and data | | | models | | | - Use SBIS Repository and Teamwork to locate | | | existing models | | | o Identify candidate GOTS and COTS software compo- | | | nents from market analysis | | | - Make list of candidate GOTS/COTS software | | | o Prepare software metric collection plan with SBIS | | | metric coordinator | | | - Understand required observable data and tool | | | support | | | - Understand derived metrics and reporting fre- | | | quency | +------------------+--------------------------------------------------------+ | FD Analysis and | o Review for detailed design reuse candidates and | | JAD | potential for function common to other SBIS appli- | | | cations | | | o Evaluate and select, via a through a formal trade | | | study, reusable GOTS and COTS software components | | | from the list of candidates | | | o Document GOTS/COTS decisions by completing a reuse | | | analysis report on selected/rejected components | | | o Make estimate of final reuse level and make com- | | | mitment to the application reuse goal | +------------------+--------------------------------------------------------+ | Critical Func- | o Present findings and rationale from Requirements | | tional Require- | Analysis Phase | | ments Review | | | (CFRR)/Critical | | | Design Review | | | (CDR) | | +------------------+--------------------------------------------------------+ SBIS Reuse Strategy 11 +------------------+--------------------------------------------------------+ | Design and | o Meet with other Project Reuse Leads to identify | | Development | joint cross-application reuse opportunities | | Phase | - Review for code reuse candidates within the | | | application | | | - Analyze and select components for code reuse | | | o Complete reuse analysis report on | | | selected/rejected components | | | o Integrate selected components into application | | | o Ensure new development adheres to sound software | | | engineering principles and characteristics of | | | reusable software | | | o Review New Reusable SLOC for compliance to Army | _________________ | | reuse guidelines and submission to Army Reuse | | | Center | | | o Collect and prepare initial software metric data | | | - Update application reuse estimate | | | - Compare final reuse level to goal | | | o Review test case reuse candidates | +------------------+--------------------------------------------------------+ | Integration and | o Select test case candidates | | Test Phase | o Complete collection of software development data | | | and calculate reuse metrics | | | o Integrate and test reused components with other | | | software | +------------------+--------------------------------------------------------+ | Deployment Phase | o Measure performance against reuse goals | | | o Assess reuse metrics and impact | | | o Submit components built for reuse to the Army | | | Reuse Center | +------------------+--------------------------------------------------------+ | NOTE: | | (1) Each task takes place on every iteration. | +---------------------------------------------------------------------------+ Table 1 contains a list of tasks for the SBIS Reuse Coordinator and Project Reuse Leads, organized by lifecycle phase. To effectively accomplish these tasks, the Project Reuse Leads must actively participate in design reviews, inspections, and team meetings. They ensure that the development process includes an awareness of reuse at every stage, and thereby save effort both through the use of existing assets and by identifying candidates for future shared resources. FINDING AND RETRIEVING EXISTING ASSETS The ease of locating and acquiring components ultimately depends on how much developers will use them. Due to the limited size of the initial set of reusable components and the fact that most developers actually prefer a hard- copy catalog rather than a electronic search tool [34], the SBIS Reuse Coor- dinator will initially provide paper catalogs of the expected sharable assets, with softcopy available on request. Since the success of these col- lections depends on the familiarity that the individual developers have with 12 SBIS Reuse Strategy them [5], the Software Development Manager must maintain a strong emphasis on their use, especially early in the SBIS program. The SBIS Repository will further support SBIS asset management by providing search and retrieval support for all SBIS assets. In effect, it will serve as the catalog of reuse components for SBIS. The Repository will include information about reuse components such as the component names, types, func- tional abstract, size, component category, a hierarchy of where-used relationships, and where the developer can find it. The Repository will provide search capability for locating candidate reuse components and will also support identification of components and instances of reuse for metrics calculations. The Repository augments other CASE tools for the purposes of measuring and tracking reuse. The SBIS configuration management tool and the UNIX file system at the Soft- ware Development Facilities (SDFs) will use the same directory structure. The directories will take the following form: Description Directory CCC configuration -------------- ------------------- ------------- unit test ///work work //common/work work //reuse/work work string test //dev/... dev /common/dev/... dev /reuse/dev/... dev S/W integration //test/... test /common/test/... test /reuse/test/... test As the size of the SBIS software and shared asset collection grows, we will investigate the use of existing or specialized reuse library tools, such as the Reuse Library Framework (RLF) or InQuisix, to aid in the location and retrieval of assets. CONTROL OF SHARED RESOURCES The Librarian/Reuse Development Team, under the control of the SBIS Reuse Coordinator, makes any and all changes to shared components. This team also has requirements definition, design, and development responsibility for any- thing intended as a shared asset. This ensures prevention of duplication of efforts and maintains version control. As we develop or identify sharable assets or collections of assets, we place assets and information about the assets in the SBIS Repository under SBIS Configuration Management (CM) and control. Changes to these assets must pass through the CM process using an Engineering Change Proposal (ECP) for action by the Reuse Development team. SBIS Reuse Strategy 13 CONSTRUCTING A DOMAIN FRAMEWORK After completion of SBIS Increment One, the SBIS Reuse Working Group, Librarian, Reuse Development Team, and Owego personnel knowledgeable in domain architectures and domain analysis techniques will meet to assess the SBIS domain. We also expect participation and key input from members of the Army Reuse Center (ARC), DISA/CIM Reuse Program, the Software Engineering Institute (SEI), and the Army Reserve Component Automation System (RCAS). Using knowledge gained from previous programs such as the Standard Installation/Division Personnel System Version 3 (SIDPERS-3) [61], RCAS [2], and the DISA/CIM domain analysis studies [13], [14], we will prepare a frame- work for SBIS applications that will lead to large scale reuse. We generally define an application framework as having three major compo- nents. 1. an architecture, or rules defining the structure of applications within _____________ the problem domain, 2. a relatively small set of components engineered and designed to fit the __________ architecture and that have interfaces that comply with the composition rules defined by the architecture, and, 3. tools that help the programmer build applications using the domain know- _____ ledge contained within the architecture and the components; these tools include component interconnection mechanisms ("glue code") and environ- ments such as layout editors and browsers. LEGAL CONSIDERATIONS ____________________ The SBIS Reuse Coordinator will ensure all legal issues on assets located in the SBIS Repository have cleared Owego counsel and developers can use them without restrictions. By screening assets in advance, the SBIS Reuse Coordi- nator removes this inhibitor from the developer. The SBIS team will follow all Owego policies on supplying software to the government, to include the guidelines in the IBM Reuse Methodology: Legal Issues for Developers [26] and ___________________________________________________ the IBM Federal Systems Company Legal Guidelines [42]. _____________________________________________ In short, the customer owns everything we develop under the SBIS contract except Licensed Programs and software developed at our own expense, e.g., pre-existing reusable software such as Karlsruhe and RADAS. We give these to the Army with "Restricted Rights," which allows the Army to use the software on SBIS but does not allow them to put the software into the Army Reuse Center reuse library nor use them on other programs. Of course, the Army would like to have complete ownership of all software used on SBIS. This provides some rationale for why SBIS developers should give priority of use to GOTS software coming from the Army reuse library; we want to reduce the use "Restricted Rights" software as much as possible. 14 SBIS Reuse Strategy MEASUREMENTS ____________ Reuse percent (represented by Reuse%) serves as the de facto industry ______ standard metric for reuse consumption [45], [47]. Although we did not include Reuse% as one of the 13 SBIS measurements, we need to track it to know how we progress towards our SBIS reuse goals. The following sections first define the observable data needed to compute the SBIS reuse metrics, then give the equations for the metrics derived from this data. These metrics comply with the IBM Reuse Methodology Measurements Standard [27] upon which DISA/CIM in part based their reuse metrics [15], and the FSC metrics, with small modifications primarily due to differences in terminology. OBSERVABLE DATA SBIS will use Source Statements (SS) for all units for measurement. The ________________________ definition of a SS will comply with the Software Engineering Institute standard [44] used by DISA/CIM and adopted for use by PMO SBIS. These defi- nitions reflect the new (fall 1993) Owego Definitions, which distinguish the term Source Lines of Code (SLOC), which refers to physical lines of code ________________________________ (including comments and blank lines), from the term Source Statements (SS), _________________________ which refers to logical lines of code (essentially a semi-colon count in Ada) [31]. We will collect these metrics at the software module, or Computer Software Unit (CSU), level of granularity. We calculate reuse metrics from the following observable data elements which IBM [25] and other companies [11] have used for many years. We can usually measure these observable data directly from the product. Observable data may also come from historical files that we collected for a variety of reasons related to managing the software development process. Historical data that organizations normally collect include costs for software development, defect rates, and maintenance costs. SOURCE STATEMENTS (SS). The total logical lines of code in the product source files. This count does not include the use of any binary modules, automatically generated code, nor code from COTS products.(2) CHANGED SOURCE STATEMENTS (CSS). The total lines of new or changed code in a new release of a product, and not intended as part of a reusable module. If any part of a module contains a new, changed, or deleted line, then consider the entire module a changed asset and count all SS in --------------- (2) This corresponds to the IBM Shipped Source Instructions (SSI) (which does ___________________________ not include reused code) plus Reused Source Instructions (RSI), to FSC's _________________________________ Total SS plus "retained" SS, and to DISA/CIM's SLOC. Note that DISA uses ________ ____ the unit of measure "SLOC" to also refer to all the SLOC in the applica- tion source files, and that FSC uses the term "Total SS" to mean all SS except for reused (e.g., retained) SS. SBIS Reuse Strategy 15 the module as CSS. CSS will not play a major role in the early incre- ments of the SBIS program.(3) REUSED SOURCE STATEMENTS (RSS). The total lines originating from outside an application that the application uses. RSS includes only completely unmodified reused software components; also called "black-box" reuse.(4) BASE SS (BSS). The total lines previously existing on the current contract/program. For subsequent versions (or "releases") of an applica- tion, all code from previous versions counts as BSS.(5) ADAPTED SS (ASS). The total lines copied and modified from another product for use on the current product; also called "white-box" reuse.(6) NEW REUSABLE SOURCE STATEMENTS (NRSS). The total lines an application team creates not only for its own application but also for use by other teams.(7) SOURCE INSTRUCTIONS REUSED BY OTHERS (SIRBO). The total lines of an application's code that other applications actually reuse, multiplied by the number of applications using the code. If a team writes a 100 SS "reusable" module and no one uses it, then SIRBO equals 0. If 5 other teams use it, then SIRBO equals 500. (8) GENERATED SOURCE STATEMENTS (GSS). The total lines of code from auto- matic code generators. Although the DISA metrics do not track these SS, the IBM metrics allow programs to optionally track and report generated code in addition to the other metrics. Ada source lines created by the AIX Interface Composer (AIC) count as GSS. --------------- (3) This corresponds to the IBM Changed Source Instructions (CSI) (which does ___________________________ not include reused code), to FSC's Total SS minus "unchanged" SS, and to ________ DISA/CIM's New Custom SLOC. _______________ (4) This corresponds to the IBM Reused Source Instructions (RSI), to FSC's _________________________________ Retained-Leveraged SS (retained SS originating from a different _________________________________________________________________________ contract/program), and to DISA/CIM's Verbatim Reuse SLOC. _________________ ___________________ (5) This corresponds to the IBM Product Base, and to FSC's Retained-Base SS. ____________ ________________ (6) This corresponds to the IBM Changed Source Instructions (CSI), to FSC's ___________________________ Total SS minus "new" and "changed" SS, and to DISA/CIM's Adaptive Reuse _________ ______________ SLOC. ____ (7) This comes from the DISA/CIM New Reusable SLOC. _________________ (8) This comes from the IBM SIRBO and corresponds to the sum of all uses of _____ DISA/CIM's New Reusable SLOC and to the sum of all uses of NRSS, as _________________ defined above. 16 SBIS Reuse Strategy COTS. The total lines of code from the source files of purchased tools and products, exclusive of commercial utility libraries such as the Booch components, which count as RSS. No known metric program tracks SS from COTS products as reuse. SOFTWARE DEVELOPMENT COST (NEW CODE COST). A historical average of the cost of writing one line of new code. We require this cost for esti- mating reuse cost avoidance; obtain the value from the SBIS Team program office. SOFTWARE DEVELOPMENT ERROR RATE (ERROR RATE). A historical average of the number of errors per lines of code experienced during the maintenance phase of a product. We require this rate to estimate maintenance cost avoidance; obtain the value from the SBIS Team program office. SOFTWARE ERROR REPAIR COST (COST PER ERROR). A historical average of the cost to fix errors in code during the maintenance phase of a product. We require this cost to estimate maintenance cost avoidance; obtain the value from the SBIS Team program office. To clarify, Reused Source Statements (RSS) indicate the source instructions an organization uses but does not develop or maintain. RSS come from com- pletely unmodified components. Programmers normally locate these components in the SBIS Repository. Source statements from prior releases of an applica- tion ("Base Source Statements (BSS)") and source instructions from partially modified components do not count as RSS. Source Instructions from a reused component count once per organization independent of how many times one calls or expands (in the case of a macro) the component. The use of COTS products does not count as reuse (e.g., the source code of the Oracle database system). We count a component as reuse when an application team that did not develop _____ and does not maintain the component uses the component. REUSE METRICS Reuse Percent Reuse% indicates the portion of an application that we attribute to reuse. The importance of Reuse% comes from the ease of calculation and ease of understanding. REUSE PERCENT OF AN APPLICATION: To calculate the Reuse% of an application (or first release of a application): Reuse%Percent equals > times 100 percent Application Example: If an application consists of 100k SS, of which 35kSS ____________________ came unmodified from the SBIS Repository, then find the Reuse Percent of the application by: SBIS Reuse Strategy 17 Reuse%Percent equals <35%kRSS over 100%kSS> times 100 percent equals 35 percent ADAPTIVE REUSE: In addition to Reuse%, we will track the amount of software copied and modified from sources external to each SBIS application. We will track this metric separately from Reuse% in accord with [27] and [15]. We use the same formula for calculating adaptive reuse as we do for Reuse%, but substitute Adapted Source Statements (ASS) for Reused Source Statements in _________________________________ ________________________ the equations: Adaptive%Reuse%Percent equals times 100 percent Example: If an application consists of 100k SS, of which 10kSS came from ________ software that the application developers customized from sources external to the application, find the Adaptive Reuse Percent of the application by: Adaptive%Reuse%Percent equals <10%kRSS over 100%kSS> times 100 percent equals 10 percent Reuse Cost Avoidance Business needs ultimately drive the decision of whether to reuse a component or to develop it from scratch. To determine the approximate financial benefit derived from SBIS reuse, we use the Reuse Cost Avoidance metric. ____________________ Reusing software requires less resources than new development, but does not come free. The developer still must search for, retrieve, and assess the suitability of reusable components before finally choosing the appropriate part for integration into the product. Although reuse requires effort to understand and integrate reusable components, studies show that the cost of this effort consists of only about 20% of the cost of new development [57], [17]. Based on this relative cost of reuse, we estimate the financial _________________________ benefit attributable to reuse during the development phase of an application: However, we typically spend only about 40% of the software life cycle in development [18]; significant maintenance benefit also results from reusing quality software. We may estimate this benefit as the cost avoidance of not fixing errors in newly developed code We can represent this savings as: The total Reuse Cost Avoidance becomes: 18 SBIS Reuse Strategy Example: If an application has a historical new code development cost of $100 ________ per line, a historical error rate of 1.5/kSS, and a cost to fix an error of $15k, then we calculate the RCA for integrating 20k RSS into an application by: cabove cabove COST AVOIDANCE DUE TO ADAPTIVE REUSE: Although adapting software does not allow us to benefit from Service Cost Avoidance, we still experience a Devel- opment Cost Avoidance. The amount of benefit depends greatly on the amount of effort required to understand the software and make the modifications; it especially depends on the proportion of the component modified. Since the developer must still search for the component and must comply with all the testing and integration requirements as for newly developed code, the savings amount to only about 40% of new development [57], [17]. Therefore, we esti- mate the total cost avoidance due to adaptive reuse: Example: If an application has a historical new code development cost of $100 ________ per line, then we calculate the cost avoidance for copying and modifying 10k ASS into an application by: < > cabove Reuse Value Added (RVA) The previous two metrics measure how much organizations consume reusable software; they do not measure reuse production. The RVA provides a a metric that reflects positively on application teams that both reuse and develop reusable code. Furthermore, the RVA not only takes into account writing reusable software but also the success of the software; e.g., whether or not other applications actually use it. ___ The RVA takes the form of a ratio, or productivity index. A normal produc- tivity index has a value equal to one, which reflects the output we expect from one team. Therefore, applications with no involvement in reuse have an RVA=1 , which means the application contributes one application's worth of software to SBIS. SBIS Reuse Strategy 19 The productivity index increases both through reuse and reusing; an RVA=2 would indicate the application contributes approximately twice the software as the same application would without reuse. In this case, the organization doubled its productivity (e.g., effectiveness) either directly (by reusing software) or indirectly (by maintaining software that other organizations use). This gives a general indication of the multiplicative effect of planned reuse on a program such as SBIS. To represent the total effective- ness of an application: equals over Example: A application team maintains 80kSS and uses 20 kSS from the SBIS ________ Repository. In addition, five other applications reuse a 10kSS Ada generic package the application team developed and maintains for all SBIS developers. The RVA of the application team equals: over 80%kSS equals 1.9> In this example, the RVA of 1.9 indicates the application team became approx- imately 1.9 times more effective than the same team without reuse. Note that the SBIS Reuse Development Team, which has the mission of devel- oping shared software, will have an extremely high productivity index, or value for the RVA metric. This high RVA indicates the tremendous programming leverage they provide to SBIS and the Army. Implementation The SBIS Integrated Software Engineering Environment (ISEE) includes two software metric packages, AdaMAT and LOGISCOPE, to assist in reporting all software metrics. Although these tools analyze and compute a wide variety of metrics on modules or CSUs, we primarily need the number of SS in each module for computing the above reuse metrics. Acquiring and reporting reuse metrics will also require knowing which application uses and reuses each module. To determine module use, each Project Reuse Lead will use LOGISCOPE and AdaMAT to maintain an architecture list of components used by the applica- _________________ tion. The architecture list will contain the modules used by the applica- tion, the number of source statements in each module, and whether or not the application "reused" the module. The Project Reuse Lead will note on the architecture list which modules the application developed or maintained and which it acquired from other sources. This method, similar to the one used by FAA, quickly yields the reuse status of an application. To roll up the numbers for an SBIS-wide Reuse%, the SBIS Reuse Coordinator simply sums the RSS values and the Total SS values provided by each Project Reuse Lead. The Reuse% equation above will yield the overall SBIS Reuse%. 20 SBIS Reuse Strategy When to measure The reuse leads need to constantly monitor progress towards their goals. The SBIS Reuse Coordinator will compile a reuse report detailing the three reuse metrics and submit it to the Software Development Manager once per quarter, or when required. Figure 2 shows an example chart depicting the progress of the Reuse% and Adaptive Reuse Percent metrics for the SBIS program [15]. +---------------------------------------------------------------------------+ | | | | | | Goal | | | ---- | | | 55% | | | | | | | | | | | | | *------ Reuse% | | | | | | | *----------* | | | | | | | ------* | | | *----------- Adaptive Reuse | | | *-----* | | | ------* | | | | | 0% *----------------------------------------------|--------- | | | Mar Apr May Jun Jul Aug Sep O|t Nov | | | | | | +---------------------------------------------------------------------------+ Figure 2. Tracking reuse on SBIS. The Reuse% metric and the amount of adap- tive reuse charted over time. MEASURING REUSABILITY The 13 SBIS metrics do not include a measure of reusability. Although no standard for measuring reusability of software exists, most practical work in the field has taken place at the University of Maryland [4], [8] or in relation to the effects of certain characteristics of software on reliability and maintenance [43]. Most findings attribute a high correlation between the McCabe [39], and Halstead [24] complexity metrics and the reusability of software; our SBIS software analysis tools (LOGISCOPE, AdaMAT) support both of these metrics. During application development Project Reuse Leads have responsibility for identifying assets they think have potential for use in other applications. They will base this assessment on the analysis provided by the SBIS metric tools and their experience. The PRLs may use the list of general character- istics of reusable software provided below and the Ada reuse checklist in the addendum to aid in their assessment. SBIS Reuse Strategy 21 When appropriate, we will submit these components to the Army Reuse Center (ARC) for inclusion in the Army-wide reuse library. Upon completion of our SBIS domain analysis and development of shared components, the SBIS team will make the domain-specific assets available to the ARC. Prior to submission, we will fully test, validate, and document the components in accord with SBIS and FSC standards to ensure they meet ARC reuse library acceptance criteria [12]. As discussed above, we expect to develop all code for reuse at the Computer Software Unit level, or CSU. Some characteristics of reusable software We must develop all reusable software, especially black-box assets, with the interests of the reuser in mind. In general, the design and implementation of reusable software mirror the desirable characteristics of good software engineering techniques. Specifically, characteristics of reusable software that contribute to their usability include [55]: EASE OF UNDERSTANDING The component has thorough documentation, including self- documenting code and in-line comments. FUNCTIONAL COMPLETENESS The component has all the required operations for the current requirement and any reasonable future requirements. RELIABILITY The component consistently performs the advertised function without error and has passed repeated tests across various hardware and operating systems. GOOD ERROR AND EXCEPTION HANDLING The component isolates, documents, and handles errors consistently. It also provides a variety of options for error response. INFORMATION HIDING The component hides implementation details from the user, for example, internal variables and their representation. It also clearly defines the interfaces to other operations and data. HIGH COHESION AND LOW COUPLING The component exhibits high cohesion (it performs a well-defined ________ function or group of function) and low coupling (it has minimal ________ dependencies on other components). PORTABILITY The component does not depend on unique hardware or operating system services. 22 SBIS Reuse Strategy ADDENDUM: AVAILABLE REUSABLE ASSETS ___________________________________ We will use Government-Owned reuse libraries whenever possible to provide code that meets SBIS requirements. However, we will also "seed" the SBIS development environment with collections of software extracted from the FSC Federal Reuse Repository (FRR) Corporate Reuse Environment (CRE) tool. The FSC FRR currently contains fifteen software reuse libraries, comprised of 941 Ada, C, and REXX components totaling approximately 250,000 SSs. FSC devel- oped or licensed these components to support FSC projects, but most of these generally apply to any project. FSC also provides ten document libraries in FRR, comprised of 90 miscellaneous reusable document components which have editable, browsable, and printable files. o ARTE using AIX/6000. All 45 ARTE 6000 components originated from the companion library ARTE using Ada/370 version 1.2.0 and but run under the IBM AIX Ada/6000 com- piler. ARTE provides Ada string, real-time, communications, and synchro- nization routines; 14 of these components follow standards defined in the ARTEWG Catalog of Interface Features and Options (CIFO) 3.0. o Booch Ada. The Booch Ada collection, one of the most active FSC libraries, contains an impressive collection of 501 reusable Ada components developed by one of the industry leaders in software reuse, Grady Booch. The collection consists of robust, general purpose implementations of tools and abstract data types, with simple and complex utilities. o Booch Enhanced Ada. These 62 reusable Ada components originated from the companion library, Booch Ada. IBM developers modified the original Booch components to include new features and apply performance enhancements. These enhance- ments include the addition of generics, improved efficiency of routines, and improvements in memory management. o General Purpose Ada. These 42 Ada components originated from various projects both in and outside of FSC. The collection contains miscellaneous routines for data compression, delays, event and control tasks, I/O, sorting, and math- ematics, among many others. The collection also includes several rou- tines which follow POSIX and NUMWG standards. o Karlsruhe. The Karlsruhe library contains 119 reusable Ada components developed at the University of Karlsruhe for IBM. The components contain Ada imple- mentations of abstract data types, numeric routines, and various utility packages. o RADAS. SBIS Reuse Strategy 23 The Real-time And Distributed Ada Services (RADAS) library, developed within FSC, contains 13 reusable Ada components, including command proc- essing services, a GDDM interface, and timing sequence maintenance. RADAS provides various real-time and distributed Ada integer/string and ASCII/EBCDIC conversions and services. o AAS Common Components The AAS Common Components library contains nine reusable Ada components developed by and used on the Federal Aviation Administration (FAA) Advanced Automation System (AAS) project in Rockville, Maryland. This collection consists of List and Array routines, Hash functions, String parsing, a message sequence manager, and an AVL Tree manager. o MIL-STD-2167A Templates. The 18 components which make up this library contain BookMaster templates for creating MIL-STD-2167A compliant documents. We will add WordPerfect templates as we convert them from the BookMaster versions. This col- lection includes requirements specifications, software test procedures, an operator's manual, and interface design documents. o SBIS User Interface (under development) A collection of shared SBIS System Main Menu Screens. Developed in accordance with the SBIS Style Guide, these Ada routines will provide the main screens and menus that drive the SBIS system. 24 SBIS Reuse Strategy ADDENDUM: APPLICATION PROGRAMMING INTERFACE (API) LIST ______________________________________________________ The SBIS APIs provide SBIS applications a standard set of sharable software to achieve consistent, portable access to system services such as data man- agement, networking and the operating system. The following contains a list of available APIs, their sizes in SS, and a brief description of each. o Application Data Management (15k SS) The Application Data Management (ADM) API provides SBIS applications with a consistent interface to SBIS databases (Oracle) and legacy databases (e.g. DB2, DataCom,...). o POSIX (11.5k SS) The Portable Operating System Interface (POSIX) API provides SBIS appli- cations Ada bindings to operating system services. o IRDS (4.8k SS) The Information Resource Dictionary System (IRDS) API provides custom developed SBIS Repository software an API to SBIS repositories. SBIS applications will not use this API; they exist for applications related to the SBIS Repository. o Network (10.2k SS) The Network Transport layer API provides SBIS applications Ada bindings to network transport layer services (transport layer refers to the OSI stack). These binding provide a consistent interface to 3 different network protocols (TCP/IP, GOSIP, SNA) by following the POSIX 1003.12 standard. o X.400 (600 SS) The X.400 Message Handling System (MHS) API provides SBIS applications Ada bindings to electronic mail services. o X.500 (82O SS) Provides SBIS applications Ada bindings to OSI X.500 directory services. Directory services allows applications to query the locations of objects in a a distributed heterogeneous environment at run time. Examples of objects include files, print queues, processors, etc. o RPC/DCE (2k SS) The Distributed Computing Environment (DCE) Remote Procedure Call (RPC) API provides SBIS applications Ada bindings to RPC services. When SBIS implements DCE, these services will allow an application to use multiple processors during execution. o FTAM (800 SS) SBIS Reuse Strategy 25 The File Transfer, Access and Management (FTAM) API provides SBIS appli- cations Ada bindings to remote file system services (e.g. legacy file systems). See the POSIX Operating System APIs for access to local files (and those accessible through a distributed file system). o OLTP (3.5k SS) The On-Line Transaction Processing (OLTP) API provides SBIS applications Ada bindings to TopEnd OLTP services. These services will allow an application to direct TopEnd to coordinate access/updates to multiple SBIS legacy databases within a single transactions (i.e. 2 phase commit). 26 SBIS Reuse Strategy ADDENDUM: REUSE LIBRARY CONTACT INFORMATION ___________________________________________ - DISA/CIM DSRS library The Defense Information Systems Agency, Center for Information Management sponsors reuse services and a DoD reuse repository. DISA/CIM 500 N. Washington St. Falls Church, VA 22046 Voice (703)536-6900 Fax (703)536-7480 - Army Reuse Center (ARC) DSRS library The reuse center for the US Army, ARC offers reuse services and products through their reuse repository. Army Reuse Office (ARC) Ft. Belvoir, VA Voice (703)285-6368 - Air Force DSRS (AFDSRS) reuse library The Air Force counterpart to the ARC, the AFDSRS contains approximately 1950 components of which 600 come from commercial software packages (such as Booch). Air Force DSRS (AFDSRS) SSC/SSB, Bld. 856 Gunther Air Force Base Montgomery, AL 36114 Voice (205)416-5857 - STARS (Software Technology for Adaptable, Reliable Systems) A long term software research program sponsored by the Advanced Research Projects Agency (ARPA), part of which studies Domain- Specific Software Architectures (DSSA). STARS Technology Center Suite 400 801 North Randolph Street Arlington, VA 22203 - CARDS (Central Archive for Reusable Defense Software) CARDS provides a library of domain-specific software for Command, Control, and Communications (C3) for the US Air Force. CARDS 1401 Country Club Road Fairmont, West Virginia 26554 Voice (800)828-8161 SBIS Reuse Strategy 27 - ASSET (Asset Source for Software Engineering Technology) Sponsored by ARPA as part of the STARS program, ASSET works closely with CARDS and distributes CARDS products to non-CARDS participants. ASSET 2611 Cranberry Square Morgantown, WV 26505 Voice (304)594-3951 - FSC Federal Reuse Repository (FRR) The CRE tool manages the FRR and provides a central repository for FSC's reusable assets. Contact CREHELP at HOUVMSCC. CRE User Support FSC-FSSC Houston Voice tl.260-7515 (CRE Hotline) Commercial 1(713)282-7515 28 SBIS Reuse Strategy ADDENDUM: SBIS GOTS/COTS ANALYSIS REPORT ________________________________________ SBIS GOTS/COTS ANALYSIS REPORT Date:__________ Application Name: _____________ GOTS or COTS: ____________ Name of Tool: ___________________________________________________ Author of Tool: _________________________________________________ Copyright Date: ___________________ Version Number: ___________________ Revision Number: __________________ Platform of Execution: __________________________________________ Memory Requirements: ______________________ Space Requirements: _______________________ Cost: _____________ Estimated Source Statements: _____________ Contacts for this Tool: _________________________________________ SBIS Applicability: _____________________________________________ Other Related / Required Tools: _________________________________ References: _____________________________________________________ SBIS Reuse Strategy 29 SBIS REQUIREMENTS: (the tool must meet all requirements) Will this tool run on an AIX/UNIX Platform (development)?: (RISC/6000, AIX OS 3.2.4, ...) Will this tool run on an NCR Platform (production)?: (NCR 3450/3550 using UNIX SVR4, ...) Does the tool have a Motif or Character-based GUI?: Will the vendor accept a Floating license or Concurrent-Use license policy?: If communications related, does the tool appear on the approved NIST/JTIC validation list?: If an ancillary/supporting tool (e.g. statistical pkg.), does it support the writing and saving of macros?: If an ancillary/supporting tool (e.g. statistical pkg.), does it support the use of Remote Procedure Calls (RPCs)?: Does this tool work with Oracle Release 7.0?: Has Owego Engineering group Ok'd the use of this tool?: If GOTS, does the tool have Ada run time dependencies on the NCR platform?: If GOTS, does it comply with the SBIS Standards and Conventions and does it meet the SBIS requirements?: 30 SBIS Reuse Strategy You must meet all SBIS Requirements (answered "YES" to all questions on the previous page) before proceeding with the analysis of this tool. ANALYSIS: Capabilities / Function: _________________________________________ ________________________________________________________________________ ________________________________________________________________________ ________________________________________________________________________ Limitations: ____________________________________________________ ________________________________________________________________________ ________________________________________________________________________ ________________________________________________________________________ Go / No Go Decision: ____________________________________________ ________________________________________________________________________ ________________________________________________________________________ ________________________________________________________________________ Other Related Information: ______________________________________ ________________________________________________________________________ ________________________________________________________________________ ________________________________________________________________________ Analyst: __________________________ Date Analysis Report Completed: ___________________ Name of Responsible PMO-SBA: __________________ Date Analysis Report submitted to PMO-SBA: __________________ SBIS Reuse Strategy 31 ADDENDUM: A REUSABLE SOFTWARE INSPECTION CHECKLIST __________________________________________________ The following checklist comes from the Federal Systems - Owego "FSC OP 29-14-P/O on Software Reuse"[29] . You can use it for reusable software inspections in conjunction with the SBIS Ada programming style guide. The values in the right column of the checklist indicate the importance of the criteria. 1. Necessary condition for passing inspection 2. Desirable but not necessary 3. Nice to have 32 SBIS Reuse Strategy +---------------------------------------------------------------------------+ | Table 2 (Page 1 of 8). Reusable software inspection checklist | +--------------------------------------------------------+------------------+ | DESIGN | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 1. Component exhibits high cohesion and low cou- | | | pling. | | +--------------------------------------------------------+------------------+ | - Embodies single functional abstraction | 2 | +--------------------------------------------------------+------------------+ | - Interfaces are "simple, few" | 2 | +--------------------------------------------------------+------------------+ | - No hidden side effects | 1 | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 2. Component avoids unnecessary dependencies on | 2 | | system | | | hardware or software. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 3. All hardware and software dependencies are doc- | 1 | | umented. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 4. Component is functionally complete. | 3 | +--------------------------------------------------------+------------------+ | - Abstraction provided by the component is | | | complete | | | and consistent for a given level of | | | design. Consider | | | the following function types: | | | o Creation (initialization) | | | o Termination | | | o Conversion | | | o State query | | | - Boundary conditions | | | - Evaluation of contents of an | | | object | | | o I/O representation for debugging | | | purposes | | | o State change | | | | | | Note: An example of a package that might be | | | accepted even if | | | it is not "complete" is a trigonometry | | | package without an arccosine. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ SBIS Reuse Strategy 33 +--------------------------------------------------------+------------------+ | 5. Component contains all essential functions; for | 1 | | example, | | | push and pop functions for STACK. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 6. Exceptions and exception handling | | +--------------------------------------------------------+------------------+ | - Exceptions are used for infrequent situ- | 2 | | ations. | | +--------------------------------------------------------+------------------+ | - Exceptions are used to handle partitions | 2 | | of the domain | | | of the function for which behavior is | | | undefined. | | +--------------------------------------------------------+------------------+ | - Exceptions handled locally if appro- | 2 | | priate. | | +--------------------------------------------------------+------------------+ | - Within reason, for every exception | 2 | | declared, a | | | function is defined that indicates | | | whether the | | | exception would be raised. | | +--------------------------------------------------------+------------------+ | - If appropriate, a function is provided | 3 | | that will | | | return all available information when an | | | exception | | | is raised. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 7. Parameterization | | +--------------------------------------------------------+------------------+ | - Subprogram interfaces are sufficiently | 1 | | parameterized. | | +--------------------------------------------------------+------------------+ | - Generic parameters are used appropriately | 3 | | to: | | +--------------------------------------------------------+------------------+ | o Parameterize configuration. | | | o Eliminate unnecessary checks. | | | o Provide formal subprograms parame- | | | ters as | | | user hooks (boundary condition | | | determination | | | and handling) with appropriate | | | default | | | subprograms to handle "normal" case. | | +--------------------------------------------------------+------------------+ 34 SBIS Reuse Strategy +--------------------------------------------------------+------------------+ | - Default initialization of private types | 3 | | is provided. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 8. Function provided is parallel with other units | 3 | | of | | | that type and family. | | +--------------------------------------------------------+------------------+ SBIS Reuse Strategy 35 +---------------------------------------------------------------------------+ | Table 2 (Page 4 of 8). Reusable software inspection checklist | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 9. Component represents abstraction of real | 1 | | problem. | | | - Encompasses both long-term and short-term | | | need. | | +--------------------------------------------------------+------------------+ | 10. Function is not misrepresented; operator names | 1 | | indicate the operator function. For example, do not | | | overload | | | '+' with '-'. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 11. Component is inherently different from existing | 1 | | components; it adds value. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | CODE | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 1. Component compiles without error. | 1 | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 2. Single entry and exit for each subprogram. | 1 | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 3. Code correctly implements function. | 1 | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 4. Ada typing | 2 | +--------------------------------------------------------+------------------+ | - Parameters typed and constrained to | | | satisfy the | | | domain. | | | - Subtypes used when appropriate. | | | - Use of predefined types is avoided. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 5. Naming conventions | 3 | +--------------------------------------------------------+------------------+ 36 SBIS Reuse Strategy +--------------------------------------------------------+------------------+ | - Mnemonics are meaningful to someone | | | familiar | | | with the problem other than the author. | | | Useless | | | characters and words are eliminated. | | | - Use of abbreviations is limited and | | | appropriate. | | | - Attributes are used where possible. | | | - Component names conform to applicable | | | standards. | | | - Type and object names are nouns, for | | | example: | | | o Type names end in _TYPE | | | o Constant names end in _CNST | | | - Subprogram names are verb phrases. | | | Boolean | | | function names are phrases of the form | | | "to be." | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 6. WITH is used only where required. | 1 | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 7. Use of USE is minimized. Fully qualified names | 2 | | are | | | used. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 8. Within a family of components, such as various | 3 | | queue | | | implementations, subprogram names and parame- | | | ters are | | | identical where possible. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 9. Optional compiler features | | +--------------------------------------------------------+------------------+ | - Avoided where possible | 2 | +--------------------------------------------------------+------------------+ | - Documented when used | 1 | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 10. Indentation and presentation rules | | +--------------------------------------------------------+------------------+ | - Follow style guide | 3 | +--------------------------------------------------------+------------------+ | - Format is consistent and readable | 1 | +--------------------------------------------------------+------------------+ SBIS Reuse Strategy 37 +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 11. Use of symbolic parameters is maximized; use of | 2 | | literals | | | is avoided. | | +--------------------------------------------------------+------------------+ 38 SBIS Reuse Strategy +---------------------------------------------------------------------------+ | Table 2 (Page 7 of 8). Reusable software inspection checklist | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | DOCUMENTATION | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 1. Commentary adds value--is necessary and com- | 1 | | plete. As a | | | rule, commentary is included for all modules, | | | subprograms, | | | and compound language constructs. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 2. Specification | | +--------------------------------------------------------+------------------+ | - Meaning of each subprogram and all of its | 1 | | parameters | | | is clear. | | +--------------------------------------------------------+------------------+ | - Prolog | 1 | +--------------------------------------------------------+------------------+ | o Format is clear. | | | o Abstract is concise and helps to | | | differentiate | | | component from others in its | | | family. | | | o Keywords are appropriate. | | | o User notes are necessary and com- | | | plete. | | | o All dependencies are fully docu- | | | mented. | | | o All assumptions for correct opera- | | | tion are | | | documented. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 3. Body | 1 | | - Abstract provides meaningful information | | | about | | | implementation. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 4. Statistics | 1 | +--------------------------------------------------------+------------------+ | - File content is accurate and complete. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ SBIS Reuse Strategy 39 +--------------------------------------------------------+------------------+ | 5. Potential user can tell what component does and | 1 | | how to use | | | it. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 6. Exceptions potentially raised by component are | 1 | | documented | | | in component prolog or exception section of | | | specification. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 7. Exceptions that are handled by component are | 1 | | documented. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | TEST | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 1. Test cases are available for review for code | 1 | | units only. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 2. Tests provide sufficient coverage. | 2 | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 3. Tests results show no priority 1 or 2 errors; | 1 | | all other | | | errors are documented. | | +--------------------------------------------------------+------------------+ | | | +--------------------------------------------------------+------------------+ | 4. Prolog is defined for test program. | 3 | +--------------------------------------------------------+------------------+ 40 SBIS Reuse Strategy REFERENCES __________ [1] Arango, Guillermo, "Domain Analyis Methods," working paper, Schlumberger ______________ Laboratory for Computer Science. [2] Arya, Pamela K., "Software Reuse on RCAS," Proceedings of the 6th Annual _____________________________ Workshop on Software Reuse, Owego, NY, 2-4 November 1993. ___________________________ [3] Bailin, Sidney C., "KAPTUR: Domain Engineering Tool," 6th Annual Work- ________________ shop on Software Reuse, Owego, NY, 2-4 November 1993. _______________________ [4] Bailey, John W. and Victor Basili, "Software Reclamation: Improving Post-Development Reusability," 8th Annual National Conference on Ada _______________________________________ Technology, 1990. ___________ [5] Banker, Rajiv D., Robert J. Kauffman, and Dani Zweig, "Repository Evalu- ation of Software Reuse," IEEE Transactions on Software Engineering, ______________________________________________ Vol. 19, No. 4, April 1993, pp. 379-389. [6] Booch, Grady. Object Oriented Design with Applications. _________________________________________________ Benjamin/Cummings, Redwood City, CA. [7] Barnes, B.H. and T.B. Bollinger, "Making Reuse Cost Effective," IEEE ____ Software, Vol 8., No.1, Jan, 1991, pp. 13-24. _________ [8] Caldiera, Gianluigi and Victor R. Basili, "Identifying and Qualifying Reusable Software Components,," IEEE Software, Vol. 24, No. 2, February ______________ 1991, pp. 61-70. [9] IBM Federal Systems Company, "Software Reuse Strategy," Circuit-Card ____________ Assembly and Processing System (CCAPS), IBM Document No. 119A822-40, _______________________________________ Version 4.1, 4 March 1988. [10] Ciardi, Mauro, Pierpaolo Marangoni, Cinzia Sternini, "SIP Library Project: A New Methodology for Designing OSI Systems Implementations," Eleventh International Conference on Computer Communication, Genoa, _________________________________________________________________ Italy, 28 Sept- 2 Oct. 1992, pp. 83-88. [11] Daskalantonakis, M.K., "A Practical View of Software Measurement and Implementation Experiences within Motorola," IEEE Transactions on Soft- __________________________ ware Engineering, Vol. 18, No. 11, November 1992, pp. 998-1010 _________________ [12] DiBona, Robert M., Frederick A. Springford, and Jean J. Croteau, "RAPID Center Standards for Reusable Software," U.S. Army Information Systems _____________________________ Engineering Command, 3451-4-012/6.4, October 1990. ____________________ [13] DISA/JIEO/CIM, "Domain Analysis Guidelines for the DoD Software Reuse Initiative," Defense Information Systems Agency, Joint Interoperability __________________________________________________________ Engineering Organization, Center for Information Management, Document ______________________________________________________________ 1222-04-210/30, 8 May 1992. References 41 [14] DISA/CIM, "Domain Analysis and Design Process, Version 1," Defense _______ Information Systems Agency, Center for Information Management, Document ______________________________________________________________ 1222-04-210/30.1, 30 March 1993. [15] DISA/JIEO/CIM, "Software Reuse Metrics Plan," Defense Information ____________________ Systems Agency, Joint Interoperability Engineering Organization, Center ________________________________________________________________________ for Information Management, Version 4.1, 4 August 1993. ___________________________ [16] Department of Defense, "DoD Software Reuse Initiative: Vision and Strategy," United States Defense Technical Information Center, 15 July ___________________________________________________ 1992. [17] Favaro, John, "What price reusability? A case study," Ada Letters, Vol. ____________ 11, No. 3, Spring 1991, pp. 115-24. [18] "Software Engineering Strategies," Strategic Analysis Report, Gartner __________________________ Group, Inc., April 30, 1991. [19] Gaska, Marilyn T., "An Open Systems Perspective on Horizontal Reuse," Proceedings of the 6th Annual Workshop on Software Reuse, Owego, NY, 2-4 _________________________________________________________ November 1993. [20] Gish, J.W., and K.E. Huff, "Managing Software Reuse," Electro/92, Vol ___________ 5., 1992, pp.16-21 [21] Gomaa, Hassan, "A Reuse-Oriented Approach for Structuring and Config- uring Distribute Applications," Software Engineering Journal, Vol. 8, _____________________________ No. 2, March 1993, pp. 61-71. [22] GAO, "Software Reuse - Major Issues Need to Be Resolved Before Benefits Can Be Achieved," United States General Accounting Office (GAO), ___________________________________________________ GAO/IMTEC-93-16, January 1993. [23] Griss, Martin, "Software Reuse: From Library to Factory," IBM Systems ____________ Journal, Vol. 32, No. 4, 1993, pp. 548-566. ________ [24] Halstead, Maurice H. Elements of Software Science. Elsevier North- _____________________________ Holland, New York, 1977. [25] IBM, "IBM Corporate Programming Measurements (CPM)," V 4.0, IBM Internal ____________ Document, 1 November 1991 _________ [26] IBM, "IBM Reuse Methodology: Legal Issues for Developers," IBM Document _____________ Number Z325-0689, 2 October 1992. _________________ [27] IBM, "IBM Reuse Methodology: Measurement Standards," IBM Corporation _______________ Document Number Z325-0682, 2 October 1992. __________________________ [28] Federal Systems Integration and Management Center, "Sustaining Base Information Services (SBIS) Strategic Reuse Plan," Program Management __________________ Documentation 90063ARE-09, 6 June 1993. ___________________________ 42 SBIS Reuse Strategy [29] IBM Federal Systems Company, "FSC OP 29-14-P/O on Software Reuse," Oper- _____ ating Procedure, Issued 30 April 1992. ________________ [30] IBM Federal Systems Company, "Ada Software Reuse on AAS," Document STN ____________ P0015B, 16 May 1993. _______ [31] IBM Federal Systems Company, "Owego Software Metrics," Document Number ________________ Preliminary, 2 June 1993. ____________ [32] IBM Federal Systems Company, "SBIS Software Development Methodology Plan," Sustaining Base Information Services Program Management Documen- _________________________________________________________________ tation, 30 September 1993. _______ [33] IBM Federal Systems Company, "SBIS Profile (SBP)," Sustaining Base _______________ Information Services Program Management Documentation CDRL A032, 7 _____________________________________________________________________ October 1993. [34] Isoda, Sadahiro, "Experience Report on Software Reuse Project: Its Structure, Activities, and Statistical Results," Proceedings of the ____________________ International Conference on Software Engineering, Melbourne, Australia, __________________________________________________ 11-15 May 1992, pp. 320-326. [35] Jones, T.C. "Reusability in Programming: A Survey of the State of the Art," IEEE Transactions on Software Engineering, Vol. SE-10, No.5, Sep- __________________________________________ tember, 1984. [36] Lubars, Mitchell D. and Neil Iscoe, "Frameworks Versus Libraries: A Dichotomy of Reuse Strategies," 6th Annual Workshop on Software Reuse, ______________________________________ 2-4 November 1993, Owego, NY. [37] Luckey, Peter H. and Frank G. Dupont, "Rapid Prototyping in Ada in the Rational Environment Emphasizing Software Reuse," Proceedings of the __________________ Washington Ada Symposium, McLean, VA, 25-28 June 1990, pp. 71-75. _________________________ [38] Margano, Johan, and Lynn Lindsey, "Software Reuse in the Air Traffic Control Advanced Automation System," Joint Symposia and Workshops: _______________________________ Improving the Software Process and Competitive Position, 29 April-3 May ________________________________________________________ 1991, Alexandria, VA. [39] McCabe, T.J., "A Comlexity Measure," IEEE Transactions on Software Engi- ___________________________________ neering, SE-2, 1976, pp. 308-320. ________ [40] Miller, Lawrence and Alex Quilici, "A Knowledge-Based Approach to Encouraging Reuse of Simulation and Modeling Programs," Proceedings of _______________ the 4th International Conference on Software Engineering and Knowledge ________________________________________________________________________ Engineering, Capri, Italy, 15-20 June 1992, pp. 158-163. ____________ [41] Neumann, Valerie A. "Moving Beyond Library-based Reuse," 6th Annual ___________ Workshop on Software Reuse, Owego, NY, 2-4 November 1993. ___________________________ [42] O'Brien, Thomas P., "IBM Federal Systems Company Legal Guidelines," Internal Report, 2 April 1992. ________________ References 43 [43] Oman, Paul and Jack Hagemeister, "Constructing and Testing Software Maintainability Assessment Models," Proceedings of the IEEE Conference __________________________________ on Software Maintenance, Orlando, FL, November 1992, pp. 337-344. ________________________ [44] Park, Robert E., "Software Size Measurement: A Framework for Counting Source Statements," Software Engineering Institute Technical Report, ____________________________________________________ CMU/SEI-92-TR-20, September 1992. [45] Poulin, Jeffrey S. and Joseph M. Caruso, "Determining the Value of a Corporate Reuse Program," Proceedings of the IEEE Computer Society _____________________________________________ International Software Metrics Symposium, Baltimore, MD, 21-22 May 1993, _________________________________________ pp. 16-27. [46] Poulin, Jeffrey S., and Kathryn P. Yglesias, "Experiences with a Faceted Classification Scheme in a Large Reusable Software Library (RSL)," Sev- ____ enteenth Annual International Computer Software and Applications Confer- ________________________________________________________________________ ence, Phoenix, AZ, 3-5 November 1993, pp. 90-99. _____ [47] Poulin, Jeffrey S., Debera Hancock and Joseph M. Caruso, "The Business Case for Software Reuse," IBM Systems Journal, Vol. 32, No. 4., 1993, ____________________ pp. 567-594. [48] Poulin, Jeffrey S., "A Method for Assessing Cross Life-cycle Reuse," Proceedings of the 6th International Workshop on Software Reuse, Owego, _________________________________________________________________ New York, 2-4 November 1993. [49] Poulin, Jeffrey S., "Balancing the Need for Large Corporate and Small Domain-Specific Reuse Libraries," to appear, Reusability Track of the ________________________ 1994 ACM Symposium on Applied Computing (SAC'94) Phoenix, Arizona, 6-8 ________________________________________________ March 1994. [50] Pressman, R.S. Software Engineering: A Practitioner's Approach. _____________________________________________________ McGraw-Hill, 1992. [51] Prieto-Diaz, Ruben, "Domain Analysis for Reusability," Proceedings of _______________ COMPSAC '87, 1987, pp. 23-29. ____________ [52] Ramamoorthy, C.V., V. Garg, and A. Prakash, "Support for Reusability in Genesis," IEEE Transactions on Software Engineering, Vol. 14, No. 8, __________________________________________ August 1988, pp. 1145-1154. [53] Reifer, Donald J. Software Management, Fourth Edition. IEEE Computer ____________________________________ Society, Los Alamitos, CA, 1993. [54] Sixtensson, Anders, and Wenchuan Ye, "Object-Oriented Technology and Reuse in Telecommunications Applications-practical experiences," Pro- ____ ceedings of 2nd International Conference on Technology of Object- ________________________________________________________________________ Oriented Languages and Systems, Paris, France, 25-29 June 1990, ___________________________________ pp.433-41. [55] STARS, "Repository Guidelines for the Software Technology for Adaptable, Reliable Systems (STARS) Program," CDRL Sequence Number 0460, 15 March 1989. 44 SBIS Reuse Strategy [56] Tausworthe, R.C, "Information models of software productivity: limits on productivity growth," Journal of System Software, Vol 19, No. 2, Oct, ____________________________ 1992, pp. 185-201. [57] Tracz, Will, "Software Reuse Myths," ACM SIGSOFT Software Engineering ________________________________ Notes, Vol. 13, No. 1, Jan 1988 p. 17-21. ______ [58] Tracz, Will, "Software Reuse Technical Opportunities.," Proceedings of _______________ DARPA Software Technology Conference, Los Angeles, CA, April 28-30, ________________________________________ 1992. [59] Tracz, Will, Lou Coglianese, and Patrick Young, "A Domain-Specific Soft- ware Architecture Engineering Process Outline," ACM SIGSOFT Software ______________________ Engineering Notes, Vol. 18, No. 2, April 1993, pp. 40-49. __________________ [60] US Army, "The Army Strategic Software Reuse Plan," Office of the _____________ Director of Information Systems for Command, Control, Communications & ________________________________________________________________________ Computers (ODISC4), 31 August 1992. ___________________ [61] Vitaletti, William and Ernesto Guerrieri, "Domain Analysis Within the ISEC RAPID Center," Proceedings of the 8th National Annual Conference on ____________________________________________________ Ada Technology, Atlanta, GA, 5-8 March 1990. _______________ References 45 DSMTB2451W TABLE SPLIT ON PAGE 10. DSMTB2451W TABLE SPLIT ON PAGE 11. DSMTB2451W TABLE SPLIT ON PAGE 33. DSMTB2451W TABLE SPLIT ON PAGE 34. DSMTB2451W TABLE SPLIT ON PAGE 36. DSMTB2451W TABLE SPLIT ON PAGE 37. DSMTB2451W TABLE SPLIT ON PAGE 39. DSMBEG323I STARTING PASS 2 OF 2. DSMTB2451W TABLE SPLIT ON PAGE 10. DSMTB2451W TABLE SPLIT ON PAGE 11. DSMW32708E TEXT EXCEEDS RIGHT PAGE BOUNDARY ON PAGE 21. DSMTB2451W TABLE SPLIT ON PAGE 33. DSMTB2451W TABLE SPLIT ON PAGE 34. DSMTB2451W TABLE SPLIT ON PAGE 36. DSMTB2451W TABLE SPLIT ON PAGE 37. DSMTB2451W TABLE SPLIT ON PAGE 39.