Jeffrey S. Poulin, Ph.D.
Loral Federal Systems
Owego, NY
23 April 1995
This article gives an overview of the reuse strategy for the Army Sustaining Base Information Services (SBIS) program. SBIS represents a 10-year contract potentially worth $474 million to improve and standardize the Army's automation of day-to-day business functions. SBIS will overhaul the administrative functions carried out at Army installations by providing software applications in areas such as logistics, finance, personnel, and training. The contract will help prepare the Army to move from proprietary operating environments to open systems standards-based configurations, and may serve as a procurement vehicle for the Defense Information Systems Agency (DISA) and the rest of the Department of Defense (DoD). SBIS will form the architectural foundation upon which DoD builds the Defense Information Infrastructure, a global, end-to-end network for all DoD users.
Software reuse makes up a large part of the Loral Federal Systems (LFS) software development plan for SBIS. The SBIS reuse team, led by Fred Illig (Loral Federal Systems-Springfield, VA), launched the strategy in January 1994 with a joint kick-off meeting with the SBIS Program Office, Army Program Executive Office (PEO), Army Reuse Center, and the DISA Reuse Office. This article will describe the SBIS Reuse Strategy and the accomplishments of SBIS reuse over the past year [3].
The reuse strategy addresses the SBIS goal to achieve a level of 15% reuse on the first "increment" of applications, 55% after the second increment, and a level of 85% by the conclusion of the program. Each increment typically develops from 4-10 software applications over a period of 1-2 years. Making these aggressive reuse goals requires a strategy that brings together lessons learned from many researchers and practitioners of software reuse. This article explains how the SBIS Reuse Strategy provides a comprehensive and achievable framework for meeting these goals.
First, the article discusses the motivation and rationale for the SBIS Reuse Strategy and its two-phase approach for implementation. It then outlines the roles of the people responsible for making reuse happen:
Before introducing the strategy it helps to review the three classes of software that make up a typical software application. These classes come from industry experiences in software development and form the basis of what SBIS will target for reuse. Starting with the most generic class:
Phase 2- Strategic
Figure 1. The SBIS Reuse Strategy: Overview
Figure 1 gives an overview the SBIS Reuse Strategy. Simply put, the strategy makes use of the concepts of horizontal and vertical reuse to attack reuse in two phases.
Phase one puts in place the tactical moves necessary to make the most of horizontal reuse opportunities and to start the domain analysis activities required for phase two. The first phase includes all the efforts needed to institutionalize reuse on the SBIS program. This means establishing the people, processes, and tools required to fully integrate reuse into the SBIS development cycle. In short, by the end of phase one, SBIS will have made reuse "Business as Usual."
Phase two builds the strategic backbone for SBIS reuse. This phase starts after the SBIS development team has worked with the customer and applications for about a year. Developers need this time to understand the SBIS applications, requirements, and trade-offs they must make to build a domain-specific framework needed for vertical reuse. A framework provides developers with the components, rules, and tools to rapidly build an application in the domain.
We have identified several sources of domain-independent software for use on SBIS. Many of these sources contain Government Owned Software (GOTS) that the SBIS program can use without incurring any development cost (the team must still integrate and test the components). The use of GOTS software comes first on the priority list of reusable software. These external reuse libraries include the:
However, if a search request to the ARC does not result in a suitable component, SBIS developers have access via the LFS internal World Wide Web (WWW) to the Federal Reuse Repository (FRR) [2]. This repository contains software and software-related work products including 9 Ada language collections of Abstract Data Types, utilities, and other domain-independent software.
Finally, LFS has developed Application Programming Interfaces (APIs) to access Commercial-Off-The-Shelf (COTS) products and to access Open System Environment (OSE) standard services, such as POSIX operating system services and X.400 messaging. Although not all the APIs have completed development, they will all serve as the common interface for SBIS applications to access COTS products and to access OSE-standard services, such as POSIX, X.400, and X.500. The APIs represent a 50k LOC investment made by LFS in the SBIS program.
Before explaining the second phase of the strategy (which focuses on vertical, domain-specific reuse) it will help to identify the domains within SBIS. We have initially broken down the original 80+ SBIS applications into seven domains. Most of the applications fall into:
The SBIS application architecture calls for applications to consist of collections of separately compiled and running Ada objects that communicate via methods such as Remote Procedure Calls (RPCs). Each Ada object provides a service for use by one or more SBIS applications. The SBIS architecture lays the foundation for phase 2 of the strategy because it clearly identifies responsibilities of SBIS shared (application-independent), domain-specific, and application-specific objects.
The architecture uses the term Service Objects to describe all objects that provide common services to all (or most) SBIS applications. The SBIS development team has already identified and started developing about 30 Service Objects. These objects provide services ranging from scheduling to audit trail and print functions. LFS projects that Service Objects will make up over 20% of the software in the first increment, for a conservative estimated Reuse Cost Avoidance of approximately $7 million.
Figure 2. SBIS common Service Objects
In addition, each SBIS domain (Personnel, Logistics, etc.) will have domain-specific Business Objects specifically built for the 2-18 applications within each domain. For example, the Logistics domain will have a set of "Inventory Control" Business Objects that all or most of the 13 Logistics applications will share. Each of these objects work together according to the rules and conventions of the domain; we call this a domain-specific framework. The SBIS team will build these Business Objects after it gains the necessary knowledge about the domain from customers and logistics experts. The SBIS program also plans to take advantage of work products from previous and other current DoD MIS programs. We also expect to use non-code assets such as lessons learned and domain studies completed by RCAS, SIDPERS, and other programs.
When fully implemented, an SBIS developer will only have to write the logic unique to the application and the "glue" code that brings together the common Service Objects and the domain-specific Business Objects. The architecture specifies that developers will package this logic and glue code in Application Objects. In effect, an SBIS application will consist from 55%-85% of reused software.
Implementing the SBIS Reuse Responsibility requires a team effort and a commitment from all levels. The Software Development Manager "owns" all reuse activities and processes. The SBIS Reuse Coordinator works full-time to ensure all SBIS developers have the reuse-related tools, information, and assets they need. Each SBIS application development team has a part-time Application Reuse Lead to identify reuse requirements and candidate reusable components for each SBIS application.
All of these personnel perform a key role in implementing the strategy. Together, they make up the SBIS Reuse Working Group. To ensure they work together effectively, the SBIS Reuse Working Group shares information through e-mail, an issues database, an extensive collection of data accessible through the internal WWW, and weekly meetings.
Finally, the strategy calls for an SBIS Reuse Development Team to build and maintain Service Objects. Although this team has not yet formed, it will have responsibility for prioritizing and implementing Service Objects. The team will report to the Software Development Manager.
The SBIS reuse process varies little from the well-defined development process used for all SBIS software. The developer must first gather all of the requirements for a component from the various applications that intend to use it. The developer then records the requirements using the on-line functional description template provided by the reuse team.
Next, the developer attempts to locate existing software to meet the requirements. To do this, the developer completes an on-line search request form and submits the form to the ARC, who searches external libraries for candidates. The developer also searches, in priority order, the internal reuse repository and the SBIS CLIN list. The developer evaluates the candidates, selects the best candidate(s), and documents the rationale for the decision using the on-line COTS/GOTS evaluation form. The developer shares the findings at the weekly reuse working group meeting. This ensures all application reuse leads help identify other reuse candidates and share in selecting which component to use.
If the developer cannot locate a suitable candidate, the developer estimates the effort to build the needed component. The developer verifies requirements with the Configuration Management (CM) group, obtains approval for the proposed solution at a System Architecture Meeting (SAM). If necessary, the developer designs, codes, and tests the component in accord with the SBIS Software Development Plan (SDP).
The reuse team provides a number of process documents, templates, and checklists to assist developers. All of the documents reside on the SBIS file system and the internal WWW. The assets include a Reuse Requirements Traceability Matrix, Service Object Requirements Approval Procedure, and Reuse Inspection Checklists for each step of the software lifecycle. Following software quality testing, the SBIS team will provide all potentially reusable software and APIs to to the ARC for use throughout DoD.
Implementation of the strategy requires a sustained effort by the SBIS reuse team. The team produced the detailed processes, schedules, and other items required to support the project reuse leads. The team also holds weekly meetings, supports the on-going development of Service Objects, and forwards reuse across applications by identifying and publicizing reuse opportunities. SBIS's daily efforts implement and continue to build on the ideas put forth in the reuse strategy.
In conclusion, the SBIS Reuse Strategy takes place in two phases. The first phase identifies and makes it easy for SBIS developers to take advantage of horizontal reuse opportunities. We do this by establishing:
Please send comments to the author (e-mail preferred) at: poulinj@lfs.loral.com. Regular mail: MD 0210, Owego, NY 13827; tel: (607) 751-6899, fax: (607) 751-6025. Readers can obtain a copy of the SBIS Reuse Strategy by contacting the Army Reuse Center at (703)806-3866.