The STRICOM Integrated Development Environment (IDE) Robert L. Wittman Jr. Lead Modeling and Simulation Engineer MITRE CORPORATION 3045 Technology Parkway, Orlando, FL 32826 321-235-7601
[email protected]
Cynthia T. Harrison OneSAF Project Director U.S Army Simulation, Training and Instrumentation Command (STRICOM) 3045 Technology Parkway, Orlando, FL 32826 407-384-3845
[email protected] Abstract. OneSAF is the next generation simulation system planned to equip the Army with an entity level simulation to span training and analysis uses. The Army intends to use the simulation across the Advanced Concepts and Requirements (ACR), Training, Exercises, and Military Operations (TEMO), and Research, Development, and Acquisition (RDA) domains. OneSAF will be an HLA compliant entity level simulation and will allow the simulation of individual battlefield components like soldiers, tanks, helicopters through aggregate units to the Brigade level. These units will be capable of operating in either a completely automated mode or under the control of a human role player. The Simulation Training and Instrumentation Command (STRICOM) as the materiel developer of OneSAF is employing a number of innovative development concepts in order to manage the complexity and risk associated with the project. This paper describes one of these innovative concepts, that of the STRICOM Integrated Development Environment (IDE), for producing a software intensive simulation system. The IDE is a single facility that houses the entire workforce of two separate projects: OneSAF and the Common Training Instrumentation Architecture (CTIA). Currently a variety of domain representatives, domain experts, system, software, simulation and knowledge engineers work along side government employees in this IDE facility. This paper describes the management, supporting technologies, benefits, and challenges associated with the establishment and usage of the STRICOM IDE. 1.
INTRODUCTION
The One Semi-Automated Forces (OneSAF) Objective System (OOS) is the United States (U.S.) Army’s next generation, composable, Brigade and below entity based simulation system currently under development by the Simulation, Training and Instrumentation Command (STRICOM). It is being developed to provide an integral simulation service to the Advanced Concepts and Requirements (ACR), Training, Exercises, and Military Operations (TEMO), and Research, Development, and Acquisition (RDA) domains. With requirements ranging from closed-form analytical support to command level human in the loop training, OneSAF will be a High Level Architecture (HLA)/Distributed Interaction Simulation (DIS) compliant entity level simulation providing a common solution for a broad range of user requirements. In order to realize the OneSAF vision an innovative collaborative development facility has been established to promote a team-based approach to simulation system development. This facility is called the STRICOM Integrated Development Environment (IDE). This paper describes the OOS Team’s management, roles and responsibilities, benefits, and challenges associated with the establishment and participation within the STRICOM IDE.
The OneSAF concept originated in January 1996 following an extensive study that came to the conclusion that the Army was caught in a wasteful spending cycle, making identical or similar enhancements to legacy simulations across three different user domains. Furthermore, it was determined that none of the existing legacy simulations were capable of being extended to provide comprehensive support of emerging Army functional requirements and technical standards. Realizing this, the Army decided the best approach for overcoming the problems associated with the multitude of aging simulations was to create a single general-purpose Brigade and below entity level simulation. This solution relies on using lessons learned from successful simulation projects like the Modular Semi-Automated Forces (ModSAF) simulation, and the Close Combat Tactical Trainer (CCTT) SAF [7]. The OOS development effort has evolved over the past 5 years and is now culminating in the completion of the Block A activity. Block A development focuses on the OneSAF product line architecture and initial implementations of the various products and components. Block A will be followed by Blocks B-D on approximately annual increments which add “militarily useful” capabilities
to enable OneSAF to meet its requirements of replacing a variety of legacy simulation systems to include ModSAF/OneSAF Testbed Baseline, Janus, CCTT SAF and the Brigade/Battalion Battle Simulation (BBS). This paper describes one crucial aspect of STRICOM’s vision of creating a highly productive team by creating an environment where the OOS developers can create processes and exploit technologies to openly and quickly exchange critical developmental information. 2.
THE STRICOM IDE
The STRICOM IDE currently houses the OneSAF and Common Training and Instrumentation Architecture (CTIA) programs. These two programs owned by the Project Manager Warfighters’ Simulation (PM WARSIM) and Project Manager Training Devices (PM TRADE) respectively represent a unique approach to collaborative development within STRICOM. The IDE currently houses over 12 contracting organizations, government project directors, project managers, chief engineers, and staff engineers accounting for over 150 modeling, simulation, and technology workers co-located in a collaborative development facility. The IDE focuses on enhancing inter-team collaboration to increase system and architectural understanding of the interfaces and component functionality and reduce rework due to misunderstandings. The remainder of this paper looks at the tools and technology the OOS developers are employing within the STRICOM IDE. 3.
OOS DEVELOPMENT WITHIN THE IDE
This section describes the OneSAF Objective System development approach, the current set of OOS task order teams working within the IDE, and the OOS IDE management construct. 3.1 OOS Development OOS Block A development concludes at the end of FY 2002 with the OOS documented Product Line Architecture, demonstrable system infrastructure software, and an initial set of simulation support tools. Block A serves to prove the architecture and position the program to begin full-scale model development in Block B. Block B immediately follows Block A and concludes at the end of FY 2003. Its goal is to provide the first “military useful” capabilities within the OOS. In general terms, the threshold for Block B is to support Janus and JCATS (MOUT) capabilities. Block C (end of FY 2004) and then Block D (end of FY 2005) build on the Block B capabilities to replace the OneSAF Testbed Baseline, CCTT SAF, and
BBS. Blocks C and D provide growth across the levels of military functionality represented within the simulation system, the level of human input necessary to control the simulated entities, and the maturity and breadth of the tools to construct, execute, and analyze simulation events. 3.2 OOS Task Orders The OOS acquisition team was challenged by the Army leadership to create an IDE that provides the processes and supporting tools in which a wide variety of organizations participate collaboratively in the evolution and creation of the OneSAF Product Line. The PM OneSAF was tasked to break the program up into a variety of different contracts allowing companies with specific domain expertise to compete for specific modeling and simulation development or integration type tasks rather than large overarching type contracts. The IDE supports this approach by offering a development facility where task order teams can interact and communicate. The current OOS task order efforts include: Architecture & Integration Task Order: In the spring of 2001, the OneSAF Architecture and Integration (A&I) contract was awarded to SAIC. The responsibilities associated with the A&I contract include the full definition of the OOS Product Line Architecture, integration of Government identified reusable products, and implementation of key product line components and data necessary to fully exercise and prove the Product Line Architecture. A fundamental goal of the Block A activity is to support significant model development activity in the following Blocks B-D. Knowledge Acquisition/ Knowledge Engineering (KA/KE) Task Order: Aegis corporation won the Knowledge Acquisition/Knowledge Engineering (KA/KE) task order in 2001. KA/KE provides the early definition of battlespace information based on authoritative sources, to support battlespace model development in future blocks. KA/KE Tools Task Order: GRCI, Inc. won the KA/KE Tools task in 2001. This task order leverages the Functional Description of the Mission Space (FDMS) tool developed under the Defense Modeling and Simulation Office’s sponsorship to store and manage KA/KE products. After Action Review Task Order: Acusoft Corporation won the After Action Review (AAR) task order in 2001. This task order leverages an existing COTS product, Powerstripes, as the starting point for the OOS AAR product. After Action Review Interface Task Order: Four team members comprise the After Action Review Interface (AARI) task order team: SAIC, Logicon, Acusoft, and Tapestry Solutions. This task order began in 2001 and provides a public interface to
OOS to promote the reuse of AAR systems in current use and other externally developed AAR systems. Military Scenario Development Environment Task Order: Acusoft Corporation won the Military Scenario Development Environment (MSDE) task order in 2001. This effort leverages the Commanders Exercise Initialization Tool (CEIT) initially created for the Close Combat Tactical Trainer (CCTT) program to develop simulation independent scenarios capable of being utilized by multiple simulation programs. Environmental Runtime Component Task Order: SAIC won the Environmental Runtime Component (ERC) task order in 2001. This effort leverages the Warfighters’ Simulation (WARSIM) synthetic environment runtime database format and services as a reuse starting point for development of the OneSAF runtime environment. Environment Data Model Task Order: Lockheed Martin won the Environmental Data Modeling (EDM) task order in 2001 to provide a data model of all OneSAF relevant environmental features and their attributes. This data models serves as input to the development of the synthetic environment runtime databases and model components to ensure that the runtime databases provide the appropriate environmental features and attributes as required by the simulation. C4I Adapter Task Order: Northrop/Grumman won the C4I Adapter task order in 2002. The WARSIM C4I interface, which currently only addresses the upper tactical internet/Army Battle Command Systems (ABCS), provides the basis for OOS extension to address the lower tactical internet/Force XXI Battle Command Brigade and Below (FBCB2) system. 3.3 OOS IDE Management Construct The primary management construct for the IDE is provided by a single, technical oriented Integrated Product Team (IPT). The IPT membership includes the technical management from the STRICOM team along with the technical leads from each of the Task Order teams. The IPT convenes on a weekly basis and provides an environment for IPT members’ questions and concerns to be rapidly raised and discussed with all relevant parties and actions to be assigned as appropriate to any/all relevant stakeholders. It is also the forum in which the risk items are raised and status provided as a result of the risk management board activities. The IPT focuses on providing status on technical progress and identifying and addressing potential problems before they become actual programmatic issues. 4.
SUPPORTING TECHNOLOGY
This section illustrates the technology used to keep the OOS team members focused on development while supporting appropriate local and remote
information access. While web-based technology enables remote team interactions, team members that reside within the IDE have a great advantage over those at remote sites as they can share direct human interaction with minimal overhead and effort. The IDE’s ability to allow direct sharing of architectural, design, and developmental concepts is essential in the conceptually complex world of software-based simulation development. Frederick Brooks [2] devotes chapters 4-8 (p.41-87) to illustrate the critical importance of initiating and sustaining conceptual integrity within large-scale software development projects. The IDE’s technology bent for web-enabled tools is no accident. As the OOS matures the current IDEcentric development environment is expected to transition to a hub-based strategy with the boundaries of the IDE shrinking as external users and developers play a more prominent role in the OneSAF open source development philosophy. 4.1 OOS Computer/Network Configuration and Installation Computers, networks, and web access offer critical infrastructure to support this information sharing theme as well as accelerate software development. When these assets work in unison information and software development progresses at a steady pace. When these assets fail to perform or produce unnecessary overhead progress slows, developers moral drops, and software development quickly grinds to a halt. The OOS effort has avoided these grinding halts by actively managing and adapting to the team-based environment. One example of this is shown through the evolution of the OOS computer and network administration responsibilities. Initially, a general computer and network task order won the responsibility to install and support the IDE computer and network complex. As the IDE tenets’ computational and networking requirements increased in number and complexity the stability of the computing complex suffered. Therefore, the responsibility for supporting the complex also evolved into a collaborative team-based effort. To streamline this teaming arrangement the OOS management team reallocated specific system administration responsibilities to the various task orders. Once this occurred, the infrastructure stabilized and OOS development regained its initial momentum. The current hardware support for the IDE revolves around Intel-based Personal Computer platforms (model year 2001+) supported by Windows 2000 and Linux operating systems. The Local Area Network uses TCP/IP technology over 100 Mbps CAT5 wiring.
4.2 OOS Software Development Tool Support In 1997, Edward Yourdon authored a book titled, “Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible” Projects” [9] presenting lessons learned from software development projects burdened with huge functional expectations, or saddled with a lack of funding or a lack of qualified developers. Yourdon devotes an entire chapter of his book to software developmental tools and technology. The chapter’s opening sentiment [9, p. 188] is provided below as it accurately reflects the government’s expectation of adequately prepared software developers to successfully complete the OOS. “In the best of all worlds, the software developers will have had a chance to learn, experiment, and practice with high-powered tools in a less-risky environment; indeed, in the best case, advanced tools have already been deployed throughout the organization, and are part of the culture and infrastructure of the organization. And in this case, we wouldn’t need to have any discussion about tools and technology at all; we would simply pick up our tools and go to work on the … project.” The remainder of this section discusses the tools and technology currently employed by the OOS program within the IDE. The paragraphs below describe this technology in the context of figure 1. Electronic Process Guide, www.onesaf.net
Xemacs (Editor) Ant(Make Utility)
DOORS (Requirements Management)
CVS & Tortoise CVS (CM)
XML Spy (XML IDE) Together Enterprise/Control Center (UML/Java & C++ IDE) JUnit (Dynamic Unit Test)
WebRT (Peer Review, Defect, Trouble Report & Action Item Tracking)
1st Page 2000 (HTML IDE)
Java 2 SDK (Sun-provided Java Software Base) System Engineering Analysis
Design Implementation
System Test
Figure 1: OneSAF Objective System Developmental Tools The OneSAF A&I tool selection process prioritized web-based collaborative development, flexibility, and low cost while still providing maximum functional capabilities. Early after moving into the IDE the A&I team put the toolset into place. These tools, now in their tenth month of use, have proven effective. This is not to say that challenges have not been encountered. However, as bumps are encountered the A&I tools team uses the web to document Frequently Asked Questions (FAQ) and “How To” documents describing OneSAF tool oriented processes, identified bugs, and their workarounds. The following list describes the tools presented in figure 1:
Electronic Process Guide (EPG): Starting at the upper left the OneSAF Electronic Process Guide details the system and software developmental processes that guide the OneSAF developmental process. The guide resides on the OneSAF website https://www.onesaf.net. Allowing developers web enabled access to the process guide supports the concept of easy access to drive higher compliance with the OneSAF system and software development processes. The Electronic process guide uses html links to appropriate standards, process descriptions, and developmental standards thus relieving the users from stacks of documents and time consuming referencing. Concurrent Versioning System (CVS): CVS 1.10.8 provides revision control for all software development, web-based information, and other information within OneSAF. CVS allows documenting changes and tagging these changes as part of a specific baseline. Developed as a software development revision control tool OneSAF expands its utility and uses it to manage and track all aspects of OneSAF data as part of its configuration management processes and tools. CVS supports distributed development and is open source. These qualities are critical for OneSAF development. More information can be found at http://www.cvshome.org [3]. Tortoise CVS: Tortoise CVS version 0.43 provides a front-end Graphical User Interface (GUI) that integrates with the Windows Explorer interface. This allows non-technical users to access and configuration manage information in consonance with the OneSAF IDE processes. Although accepting responsibility to manage and use Tortoise and CVS has not always been easy and popular, the OneSAF task orders have accepted it and now use it on a weekly if not daily basis. A process “how to” guide developed by the A&I shows users how to take advantage of the CVS tool. For more information on Tortoise CVS see http://www.cvsgui.org/TortoiseCVS [3]. Dynamic Object-Oriented Requirements System (DOORS): DOORS version 5.1 provides automated support for the OneSAF’s rigorous requirements analysis and tracking process accessible by all task order participants within the IDE. DOORS allows requirements storage, retrieval, and creating and maintaining linkages between user, system, and implementation requirements. Currently the OneSAF DOORS installation stores the OneSAF Operational Requirements Document (ORD), the OneSAF Technical Requirements Document (TRD), The OneSAF Operational Concepts Document (OCD), the OneSAF Reuse Direction Guide (RDG) and the Product Line Requirements Specification (PLRS). For more information on DOORS please access http://www.telelogic.com [3]. Together Control Center: The Together Control Center version 5.01. The together control center
allows integrated access to a user configurable suite of software development tools. These tools span the software development lifecycle from analysis through test. For more information see http://www.togethersoft.com.
memory and CPU-based performance issues, Winrunner a GUI testing tool, Buildboy a build verification and notification tool, and cygwin a unix emulation of the windows platform [6].
Java: Sun’s Java version 2.0 along with the Software Development Kit Version 1.3.1 provides the Java basis for OneSAF development within the IDE. OneSAF Development leads are tracking the progress of JDK 1.4 through the beta-test process and anxiously await its stabilization. As soon as this occurs the transition to JDK 1.4 will begin. Several JDK 1.4 features impact OneSAF development these include: design-by-contract, logging, crossapplication cut/copy/paste and drag-and-drop, via the Swing Data Transfer Architecture. For more information see http://www.javasoft.com [3].
4.3 OOS Reuse Repository and Experimentation Lab
XEMACS: A variety of different source code editors can be used within the Together Control Center. XEMACS is specified due to its support of the Java language and preponderance of users [3]. Ant: Ant version 1.3 offers an easy to use “make” utility for creating XML based build files outside of the Together Control Center. For more information see http://www.jakarta.apache.org [3]. Junit: Junit version 3.7. Junit provides an automated test environment for OneSAF development. Junit integrates with the Together Control Center using the XPTest Building Block Version 1.3. For more information on Junit see http://www.junit.org [3]. XML Spy: XML Spy version 4.0 provides the OneSAF users within the IDE the ability to create XML Data Interchange Formats (DIF) that are one of the cornerstones of OneSAF development. XML Spy features a format checking and validation tool to cross check a document against its DIF. XML Spy supports both Data Transformation Definitions and XML Schemas. For more information on XML Spy see http://www.xmlspy.com [3]. 1st Page 2000: 1st Page 2000 version 2.0 offers web page authoring tools to the OneSAF IDE user community. Each task order owns and updates their respective web pages. These pages fall under and are accessible from the http://www.onesaf.net. home page. A process “how to” guide developed by the A&I shows users how to take advantage of the 1st Page tool. For more information on 1st page see http://evrsoft.com [3]. WebRT: WebRT 1.0.1-4 gives OneSAF an open source web-based defect tracking tool. OneSAF’s web-enabled use of the tool spans defect, issues, risks, and action items across the task order members within the IDE [3]. Other Tools available within the OneSAF Integration Lab include: OptimizeIt used to identify
The OneSAF program, since its initiation, has viewed reuse as critical to avoiding past mistakes and leveraging lessons learned. While this does not always mean actual code reuse, although it can, it does mean reusing successful concepts, designs, and products as well as learning from mistakes in the past. The reuse repository and experimentation laboratory store and allow access to this important information across the OneSAF task orders. These two libraries offer a wealth of documentation as well as actual military and commercial simulations and tools. The reuse repository effort began in the spring of 2000, well before the A&I contract award. The Architecture-Integrated Product Team (A-IPT) under the leadership of STRICOM and the OneSAF Chief Engineer investigated a number of simulation systems under development and legacy simulation systems looking for “golden nuggets” to serve as starting points for OneSAF development. The effort resulted in the Reuse Direction and Guidance (RDG) document and the reuse repository. The RDG mandates and recommends products for reuse within OneSAF. The reuse repository supports the OneSAF RDG by providing access to RDG listed products as well as offering access to complete fielded and developmental products from other simulation programs including WARSIM, Close Combat Tactical Trainer (CCTT), COMBATXXI, and the OneSAF Testbed Baseline (OTB) [7]. The OneSAF experimentation lab also plays an important role in OneSAF development. This lab offers OneSAF developers the opportunity to experience both commercial and military simulations to leverage and extend the best practices as well as avoid existing shortcomings. Over twenty commercial and military simulations currently reside within the OneSAF lab environment [8]. By providing and encouraging hands on experimentation with legacy and emerging simulations the government expects OneSAF developers to apply the right information at the right time within the OneSAF development cycle. With the educational and developmental process well underway, the Block A deliver offers an opportunity to capture the advantages and disadvantages of this approach. 5.
CONCLUSIONS
This section highlights the benefits and challenges of creating an IDE to boost OOS team performance.
5.1 Benefits The IDE has been essential for OOS development on a number of fronts. First the proximity of knowledge, system, and software developers to one another offers a great opportunity to share process and product oriented information. Exchanges between the KA/KE team (military subject matter experts) and the modeling infrastructure software development teams provide clear examples of this benefit. Initially, a number of non-location based barriers separated these two groups. They spoke different languages and came from different military and software development cultures. Had there also been a physical proximity barrier the flow of communications would have been slowed if not completed eliminated. The day to day contact at meetings, within the halls, etc. clearly played an important role in allowing these to two groups to exchange meaningful information. The benefit of these two groups communicating is emerging in the format and content of the knowledge acquisition documents. The full benefit of these modeling type information exchanges will not be realized until later blocks when military useful functionality is implemented. The ability to view and manage communication and collaboration is a second clear advantage to colocation. As architectural development progressed and interfaces between architecture components evolved it became clear that a number of task orders, responsible for the different components, needed to negotiate appropriate interfaces. Because management sees the amount of day-to-day communication and collaboration among stakeholders they can facilitate additional interaction when deemed necessary. This type of intervention occurred on a number of occasions.
First, there is inherent management complexity within the multiple task order concept. This complexity manifests itself in the number of task orders, the conciseness of boundaries between task orders, and the understanding of the overarching vision between all task orders. As in any complex system (the task order system in this case) the objectives, boundaries, and interfaces must be actively managed. Organizational cultural differences among the task order participants must also be respected. Particularly with regard to the selection and use of tools and technology. Whereas an organization may rely on a specific technology and be in a position to mandate its use within the IDE another may not understand, use, or be proficient at the technology. As discussed earlier, technology should not handcuff or slow users’ progress. The challenge for management is threefold: 1) To decide how much flexibility each task order should be allowed to have in tool selection and use, 2) How much effort should be given to educating the various organizations on the mandated tools, and 3) How much time will be necessary to support the training and acceptance of a specific tool. In conclusion the IDE provides the OOS development and user community a single facility to collaboratively negotiate and develop the Army’s next generation Brigade and below entity-based simulation system. Although the IDE does not provide a silver bullet guaranteeing success, it does provide a number of important benefits that have already resulted in early architectural development successes.
A third benefit to OOS developer co-location revolves around system and software interface definition, understanding, and maturity. As system and software interfaces come to life the IDE community actively participates in their maturation. Participation in the process includes initial peer reviews, actual use of the interface, and comment, defect, and issue submission against system, software, and other developmental products. While the early looks and peer review process can be humbling, the alternative of waiting to strike perfection at the expense of feedback not only frustrates users but rarely creates perfection in any eyes other than the developer.
REFERENCES 1.
Blanchard, Kenneth (Ph.D.), Carew, Donald (Ed.D.), Parisi-Carew, Eunice (Ed.D.). (1990). The One Minute Manager Builds High Performing Teams (Achieving Excellence Through Team Building. William Morrow and Company, Inc., NY, NY.
2.
Brooks, Frederick. (1995) The Mythical Man-Month: Essays On Software Engineering. Addison Wesley Longman, Inc.
3.
Gugel, Susan. (2002, January) OneSAF Technology Tools Overview.
4.
Gugel, Susan (2002, January) OneSAF Tools web page.
5.2 Challenges
5.
Although the IDE provides several benefits, it should not be considered a “silver bullet” [2] for complex simulation or software development. Even when using an IDE there remain a number of challenges to account for.
“One Semi-Automated Forces (OneSAF) Operational Requirements Document (ORD) Version 1.1”, 21 May 2001.
6.
Rosack, Ed. (2002, March) OneSAF Integration & Test - Lab Tools web page.
7.
Rosack, Ed. (2002) OneSAF System Integration & Test - Legacy Applications web page.
System
8.
Wittman, Robert; Harrison, Cynthia. (2001) “OneSAF: A Product Line Approach to Simulation Development”, 01E-SIW-061, 2001.
9.
Yourdon, Edward. (1997) Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible” Projects. Prentice Hall, Upper Saddle River, NJ
