An Integrated Software Development Environment for Army Information Systems

  • Jeffrey R. Dmochowski
  • Jeffrey S. Poulin
    • Federal Systems Company
International Business Machines Corporation
Rt. 17C, MD 0124
Owego, NY 13827
JeffD at OWGVM0
PoulinJ at OWGVM0
 
1 November 1993
    Presented at the IBM Integration Center of Competence (ICOC) International Technical Liaison (ITL) on Information/Technology Integration, Thornwood, New York, 1-2 November 1993.

    Background

    In June 1993 the US Army awarded IBM's Federal Systems Company in Owego, New York, a 10-year contract potentially worth $474 million to improve and standardize the Army's automation of day-to-day business functions. The Sustaining Base Information Systems (SBIS) contract will overhaul the administrative functions carried out at 128 Army installations, including 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.

    Goal

    To meet the productivity and quality necessary to produce the SBIS applications, our developers will require an environment containing tools that helped manage all lifecycle stages from high-level data and architecture models through to fully tested and running Ada software. To achieve a high degree of function between the tools as well as within the individual tools, we decided to leverage the existing NIST/ECMA framework technology available in the IBM WorkBench/6000 and Integrator/6000 products.

    Scope

    The Request for Proposals (RFP) released by the Army in the spring of 1992 did not identify many specific requirements for a CASE environment. The environment needed to comply with the National Institute of Standards (NIST) Applications Portability Profile (APP) and all Portable Operating System Interface (POSIX) and Government Open Systems Interconnect Profile (GOSIP) standards. Otherwise, the Army allowed vendors to identify requirements and the tools to best those requirements. Whereas this allowed the IBM team to select the best products on the market (from IBM and non-IBM vendors), the wide scope of what the environment should do and the way to best do it cause a number of difficulties in determining the focus of our toolset.

    The SBIS solution contains a wealth of Commercial-Off-The-Shelf (COTS) products which provide a wide breadth of function in diverse areas such as operating environment, networking, data management, software development, system engineering and office automation. Throughout the course of the proposal, the SBIS Integrated Software Engineering Environment evolved into a core set of software development tools which we integrated into a comprehensive, deliverable unit that scales to changing requirements and technology.

    Environment

    Target Environment

    IBM FSC built its POSIX-compliant, distributed, client-server SBIS target architecture around the NCR 3000 series of computers from its SBIS teammate, AT&T. The NCR dataservers will run UNIX SVR4 which will host about 90 Ada language, MOTIF GUI applications integrated with the Oracle Corporation Version 7 RDBMS. Army users will access these applications through X-terminals connected to the NCR dataservers.

    Development Environment

    The host portion of the ISEE operates under AIX 3.2.4 on RS/6000 Model 570 servers and RS/6000 Model 230 workstations. The ISEE resides on Model 570 process servers and employs NFS client/server technology to distribute processing to a number of Model 230 workstations. Each workstation provides distributed processing capability for up to two software developers. The environment also provides a complete Unix SVR4 testbed for the evaluation, testing and operation of SBIS software in conformance to the options and parameters of the target environment.

    Software Environment

    The software environment provides an integrated software development environment based on the NIST/ECMA Reference Model for tool framework technology. The ISEE framework presents a common user interface and integrated view of the underlying development tool set and central development library.

    Tool Selection Process

    During contract proposal preparation, we obtained as much available information on leading commercial products that met the general functional requirements we felt the environment needed to address. This trade study not only compared the features, costs, and functions of the competing products, but also validated that the tools actually performed the advertised functions.

    To help with the trade study process, we greatly benefited from the use of a DOS based tool called Decision Pad from Apian Software. This product implements Dr. Charles Kepner's Eight Steps to An Effective Decision. The tool automates the establishment and weighting of decision criteria and then allows the user to grade and document alternative candidates against that criteria. The program handles the mathematical calculation and report generation which proved invaluable in distributing the conclusions.

    Because the Army made Open Systems compliance a key part of the proposal, we needed to obtain the most up-to-date information on POSIX and GOSIP validation testing and the results of those tests. While some products had obtained NIST certification in one version of their product, recent or planned releases might invalidate the earlier certificate. In some cases NIST had not published test suites for recently approved standards. In general, failure to comply with an applicable NIST standard would eliminate a tool from consideration.

    Other items that would eliminate a tool included failure to support the tool on one of the target platforms. Because we planned to bid a target environment consisting of hardware from many vendors, the tool usually needed to run on each of the planned target platforms. Failure to support a tool under AIX on the R/6000 or under UNIX SVR4 on the NCR might eliminate a tool early in our trade study.

    Scheduled Integration Tasks

    In preparation for contract award, the CASE integration work progressed and continues in three phases consisting of approximately 20 person-months of effort. Delivery of the first version of the ISEE to the software developers occurred in October 1993.

    Phase I.

    Establish production, RS/6000-based distributed CASE environment consisting of an initial list of approximately 34 critical tools integrated with the WorkBench/6000 framework and customized to Owego Federal Systems Integration (FSI) and SBIS requirements. These tools include the Verdix Ada Development System (VADS) and many of the Cadre Teamwork products. The customized environment also specifies a preliminary configuration management and version control for the software development process.

    Phase II.

    Provide the addition of transparent target development and testing within the environment using the NCR target platform.

    Phase III.

    Integrate and customize approximately 21 less critical RS/6000 based tools into the environment. Complete integration of developer training, help, and user documentation.

    Integrating the CASE Tools

    We created the following nine step process in order to achieve a consistent integration of each of the tools in the ISEE and attain a tangible means of delivering integration:
    1. Installation Preparation
    2. Installation
    3. User Access
    4. RC Initialization
    5. Distributed Client Setup
    6. WorkBench Encapsulation
    7. Custom Tool Integration
    8. SoftDist Packaging
    9. ISEE Electronic Distribution

      10.  
    We repeat this process for each tool involved in the integration effort. After we take a tool through each of the nine steps, it effectively becomes part of the ISEE and we make the tool ready for testing and distribution.

    Installation Preparation

    The first step in our integration process consists of fundamental preparatory task. These involve accessing the tool profile template, creating a tool profile for the tool we will install, completing standardized preparatory work such as creating a file system using the standardized naming convention, and documenting the tool's size. We keep this tool profile under configuration management and use it to document additional custom code and integration performed on the tool throughout its integration lifecycle.

    Installation

    The installation step involves installing the tool using its normal installation procedures and documenting any discrepancies or changes which we had to make in the tool profile. We also capture in the tool profile any options or parameters we had to set during this step.

    User Access

    In this step, we access the standardized user access template to create an access script for the tool. We also place this script under configuration management. The "user access script" takes care of typical processes which the user must follow for each tool whenever a user wants to start the tool. This includes such things as logging the tool access and setting all variables and options to the appropriate values so the tool will function properly.

    RC Initialization

    During this step in the process, we create another script for the tool to handle the starting of any daemon processes associated with the tool. These processes typically handle such tasks as license and database management.

    Distributed Client Setup

    Distributed client setup involves accessing the setup template, creating a custom setup script for the tool and placing it under configuration management. This script handles any custom work which must take place on each machine which will run the tool. Typically, this involves the setting of XWindows resources, fonts and other parameters which the tool requires to operate properly. We then incorporate the script into a master Client Services script which developers and each of the client workstations will use to manage the environment by the ISEE on their machine.

    WorkBench Encapsulation

    In this phase of the process, we actually integrate the tool into the ISEE through the use of the WorkBench framework. We can achieve three levels of possible integration:

    1. Level One Integration

    This simple type of integration involves the encapsulation of the tool so that the user can start and stop the tool from the WorkBench Tool Manager. The tool's source code does not need modification and its appearance and operation remain the same. The tool also does not communicate with the WorkBench Broadcast Message Server. To date, we have integrated the following tools into the SBIS ISEE using this type of integration:
    1. AutoPlan II
    2. CCC
    3. IDEFine
    4. STW
    5. VADSedit

      6.  
    In some cases, we can achieve an additional form of integration may at this level through the creation of new WorkBench object types. The definition of new object types allows the tool to start in an object oriented form. For example, in the case of VADSedit, a language-sensitive Ada source editor, we defined a new type of object called Ada source. When the user selects this type of object from the WorkBench development manager, the ISEE automatically invokes VADSedit with the object as a parameter.

    2. Level Two Integration

    In this type of integration, we use Integrator/6000 to develop a Motif wrapper or interface for the tool. We do not modify the tool's source code but we do replace its user interface with a WorkBench compliant interface. At this level, the tool can communicate with the WorkBench Broadcast Message Server and thus we can slightly modify the tool's operation. We have integrated the following tools have into the SBIS ISEE using this type of integration:
    1. AdaMAT
    2. CMlink
    3. MetaCheck

    3. Level Three Integration

    A level three integration provides of the highest level of integration supported by the WorkBench. To achieve this level of integration, we must modify the tool source code, and therefore the actual tool vendor must usually provide this type of integration as a feature of the tool. At level three, the tool can send and receive messages from the Broadcast Message Server and we can tightly integrate the tool's operation into the framework. We have integrated the following tools into the ISEE at this level:
    1. Teamwork
    2. VADSself
    3. Interleaf
    4. Logiscope

    Custom Tool Integration

    In this step, we achieve additional integration between tools by providing a custom tool integration. We usually complete this integration using one of the following general methods:
  • Modification of the tool's standard Xwindows resources
  • Modification of the tool's configuration files
  • Access to the tool's Authorized Programming Interface (API)
  • Access to the tool's Broadcast Messaging Capability


    • We capture modifications and custom work using any of the above methods in data files which we control under configuration management and document in the tool profiles.

    Xwindows Resources

    Modifying Xwindows Resources provides the the simplest form of additional custom modifications which we can do within the environment. We can make changes to the tool's resources at the system-wide level and/or put the changes under user control. We capture and document system-wide changes for future releases. In the case of user-specific changes, we leave it up the user to maintain these changes.

    Configuration Files

    This form of custom integration usually involves the addition or deletion of menus and options to achieve enhanced usability. We used this method to provide the following integration:
    1. Teamwork / CCC
    2. Teamwork / VADS
    3. Teamwork / Logiscope
    4. AIC / UIL2Ada

    Authorized Programming Interface

    Many modern software tools provide an Authorized Programming Interface (API) which custom written programs can take advantage of to add new functions to the tool. We used elements of this method when providing custom features and to enhance the operation of the following integrations:
    1. Interleaf / CCC
    2. Teamwork / CCC

    Broadcast Message Server

    Broadcast Message Server integration serves as probably the newest and at this point our least used method of integration. In this method, we tailor the sending or receiving of WorkBench BMS messages to achieve enhanced function between tools. We intend to use this method for the following integration:
    1. WorkBench Development Manager / CMlink
    This method usually involves elements of the previous methods to complete the integration.

    SoftDist Packaging and Distribution

    In this phase of the integration process, we use the outputs of all the previous process steps to produce a single, distributable ISEE. We bundle the access scripts, rc initialization and client setup logic together with the actual tool installation to create an integration package. The SoftDist product allows for a controlled, staged distribution of the entire ISEE. As we phase new products and new integration into the ISEE, we will package and it make available via the SoftDist server as a selectable option.

    Open Issues

    We still need to address the following open issues worked as part of our integration effort.

    Integrating with the NCR platform

    We can make the NCR platform available from the WorkBench environment using the WorkBench distributed option. However, the portion of the WorkBench which makes this feature work, the softspc daemon, does not yet exist on the NCR. While the port to the NCR would allow for communication to tools residing on the target machine, we question whether the cost of the port justifies the need and must examine this more closely.

    Data Integration

    While we have made significant progress in utilizing current visual and control integration technology, we have made little progress in the area of data integration. We have considered the benefits that an IRDS data repository such as InfoSpan can provide within the environment. However, the current trend in CASE technology appears to favor the PCTE implementation of data integration. We must address the question of how to proceed in this area very soon. We will no doubt require some type of integration mechanism to interface and integrate these two technologies into our ISEE.

    Summary

    The CASE team has completed the integration of most of the Phase I and Phase II products, completing all basic functions required in the environment. Future work includes integration of remaining Phase III tools, the completion of training and documentation required to transition the environment to the SBIS Software Development Facilities (SDFs) and the continuing investigation of open issues.