Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Integrating Analytical COTS Software Into Operational Environments

Integrating Analytical COTS Software Into Operational Environments



|Views: 133|Likes:
Published by Ted
Document describing the issues surrounding integrating commercial off the shelf software into operations environments, such as police dispatch, military operations centers, etc.
Document describing the issues surrounding integrating commercial off the shelf software into operations environments, such as police dispatch, military operations centers, etc.

More info:

Published by: Ted on Nov 24, 2007
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF or read online from Scribd
See more
See less



Integrating Analytical COTS Software into OperationalEnvironments: A Practical Guide
Ted Driver Analytical Graphics, Inc.
This paper outlines lessons learned during the integration of a COTS software analysistool, AGI's Navigation Tool Kit (NavTK), into a military operational environment. NavTK replaced contractor-specific software in the GPS Operations Center (GPSOC),which focuses on GPS receiver operational issues for the U.S. Air Force 2
SpaceOperations Squadron (2SOPS). Using NavTK, GPSOC analysts produce routine, dailyreports and graphs as well as analyze specific scenarios.
Although contractor-created software can be highly customized to solve particular operational problems, COTS software offers several advantages. Dozens, if not hundreds,of individuals develop COTS software, whereas a contractor-developed tool may be built by only a handful of people. This extra developer set behind the COTS tool providesexpertise that benefits both the software and the end user. Furthermore, a contractor-developed tool frequently has little room for expansion if the problem changes in scope,and enhancing it can take a significant portion of the contract budget. Therefore, preciousresources are shifted from solving operations problems into software development.Along with that, contractor-developed software typically either belongs to the contractor or is not delivered as part of the contract. Therefore, when the contract is up, operationsmay lose a contractor—and its operational software—to a contract recompete, whereasthe COTS tool remains. Because COTS provides continuity, operators becomeaccustomed to it and can produce faster and better analysis products.
Specific Issues with COTS usage
Operations groups planning to integrate COTS software into an operational environmentfor the first time will face several issues including:
Operations always comes first
Hardware considerations
COTS software customization
Shadow operations
Operational procedures
System setup and software installs
 Network permissions, user profiles, common data files, and regularly updateddata1
COTS software licensing
Operator/analyst training
Decision criteria for operations cutover to the new software
 New requirements and the software update process
 New release integration and test
Operations always comes first
This point cannot be overstated. Every operator will tell you, “No matter what happens, Icannot interrupt Ops." A typical operations environment is a buzz of activity, andstopping the center for a week to install, configure, and test new software is not anoption. Installation must be done without causing interruptions, which slows transition toa crawl. So, if you look at the schedule for integrating COTS software and wonder whyit's moving to the right, just look at the title of this section.
Hardware considerations
Initially, the operational environment might not have enough hardware to support aCOTS tool, since ops centers are frequently configured to strictly support operations andhave few excess processors available. Therefore, you should look at the current hardwareconfiguration and a plan to upgrade it if possible. Sometimes, contractor-providedsoftware must run by itself on specific hardware. In this case, a complete hardwarereplacement might be necessary. Fortunately, COTS software typically runs on modernmachines with popularly available operating systems. Computers are relativelyinexpensive and can be purchased in quantity for substantial discounts. When buyinghardware to support COTS tools, never buy the minimum or even the recommendedhardware configuration. Upgrading to a superior configuration will be well worth theextra cost, because upgrading computers at this time will minimize future disruptions of operations.
Operational simulation environment
One way to lower the risk of installing COTS in an operational environment is to purchase hardware and set up a “laboratory” of sorts. The COTS tool can then beinstalled, configured, and used as a training site prior to actual operations. As a side benefit, all future upgrades can be made in the simulation environment, assuring thesoftware works properly. Don't be fooled, though; operational simulation environmentswill at least double hardware and software expenses, and maintenance costs can be high.But the knowledge gained without interrupting operations can be priceless.
COTS customization
While COTS software significantly reduces overall contract costs for operations, somecustomization is generally necessary to meet specific needs of each environment. Theamount will depend on the operations performed and the operators’ skill levels.If the operational environment is mainly an analysis shop with few repetitive tasks,customization can be minimal, since COTS tools are best in these situations. On the other hand, if many of the same products are produced daily, more customization is likely,since a COTS tool cannot know what daily products are necessary, and should be2
configured to allow as few keystrokes as possible for the operator performing repetitivetasks. Daily product generation can become tedious, and after an operator becomesaccustomed to the process, attentiveness may drop. This problem can be compoundedwhen the process involves multiple steps, so minimizing steps in daily proceduresdecreases the chance for error.A second reason to customize for differing skill levels is that highly skilled operators maycreate scripts to automate the tool’s behavior or for defining complex reports on severalcriteria from multiple data sources. Typically, these customizations will be created byindividual operators and used for their own purposes. The usual sharing of scripts andanalysis reports may occur and will allow other skilled operators to become more fluentwith the tool. This is the lowest-cost customization—it will happen naturally over time,as each operator defines his or her own special tools.Less-skilled operators may use customizations developed by others. Usually, this will bea simple interface sometimes referred to as the "One Big Button" approach, since it doesmuch of the work with a single button. Ideally, this would completely eliminate humanerror—assuming the customization took every possible operational case into account.Three key points to note: A skilled set of individuals conversant in the ops environmentmust create the custom analyses, reports and graphs; extra people cost extra money; andthe customization requires extra time for development and testing. Typically, severalcycles of revisions occur to customize engineering and report/graph creation, ops review,ops comments and changes, reengineering, ops re-review, etc.
Obviously, skilled operators will cost more than less-skilled, but the money saved on labor may well be spent on customizing software, additional training, and a loss of productivity.
Shadow operations
Typically, running real operations from the operational simulation environment will bedifficult at first. To test the new software and hardware, operations must be performed on both old and new tools. This is called shadow operations or shadow ops. The operator onduty or someone next to him or her performs the same duties on both systems untileveryone becomes comfortable with the new system. Though the operators would have been trained in the use of the tool by this point, shadow ops provides direct experience inrunning the tool day-in and day-out.Implementing shadow ops requires additional hardware, which can cause problems if space or budgets are limited. Configuration issues must also be addressed—will the newhardware be included on the current network? Will it be on a new network? How willshadow ops be run? By doubling the work of the current operator? Adding more peopleto the ops schedule to handle the work? How will all of the operators become qualified onthe new system? A good shadow ops plan must address all these issues.
Operational procedures
Most operational environments have procedures that describe in detail how to produce a particular analysis or output. In transitioning to a COTS tool, these procedures will haveto be updated. The high-level processes that describe required elements for a particular 3

Activity (3)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
verbomania liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->