다음을 통해 공유

NASA: The Good News About COTS

  • 아티클

You’ve heard the stories. Organizations pin their hopes for improving software systems on commercial off-the-shelf (COTS) products only to be burned by poor quality, lack of service, and failures to deliver on time. The propulsion system failure aboard the U.S. Navy’s guided missile cruiser USS Yorktown is just one example. That failure, which led to the Yorktown being towed back to port, was attributed to a COTS product that failed due to a “divide by zero” problem. But it isn’t just the military that has these problems. In 1999, Hershey Food Corporation’s revenue fell 12%, a drop that was largely attributed to an inability to get products to market in time for Halloween and Christmas. Corporate insiders blamed the delay on a new installation of a COTS enterprise resource planning (ERP) system.

The reaction to these well-publicized failures—particularly in the defense community—is not unexpected. Programs are hesitant to use COTS products. They don’t want to take the chance of becoming another sad story.

The truth is, however, that there are a lot of success stories out there. Consider NASA’s new Control Center System (CCS)—the ground-based command and control system for the Hubble Space Telescope. The CCS unifies the functions for telescope command, engineering data processing, data archiving, data analysis, spacecraft and ground system monitoring, and simulation. This replacement system for the original Hubble capability integrates 30 COTS and GOTS (government off-the-shelf) components with one million lines of legacy code and one half million lines of custom code.

Because of the ready availability of the COTS and GOTS components, a prototype for the new system was built in three months. This prototype was invaluable, since it provided a rapid demonstration of the concepts for the system, the end-to-end flow of information, and the new user interface. The first production release of the new system was delivered one year after proof of concept, with many more releases delivered in the ensuing four years. This represented greater productivity than previous systems. The new system provides capabilities that the old, primarily custom-coded system could not, while reducing the number of custom lines of code by more than 50 percent.

NASA has shared a number of factors it found key to its success:

  1. NASA established a clear design philosophy favoring the use of COTS products. NASA adopted an “80-20 rule” that stated that if a COTS or GOTS product met 80 percent of the functional requirements, it would be adopted pending final approval for deferring the remaining 20 percent of requirements.
  2. NASA employed a software architecture that supported upgrading or replacing components without destroying the integrity of the system. NASA accomplished this by encapsulating COTS and GOTS products behind abstract interfaces that minimize the effect on other system components when a product or the way it is used changes.
  3. NASA developed clear component-selection criteria that allowed it to make COTS and GOTS selections efficiently, but emphasized hands-on use as the final arbiter for product selection. Products that passed the initial selection but failed the hands-on evaluation were quickly dropped.
  4. NASA hired experts who were knowledgeable about the new products to train personnel in design and implementation.
  5. NASA reevaluates COTS and GOTS products at each product release. The project has found that some products were successful in the CCS from their initial selection, some were failures and were replaced, and many fell in between. NASA performs periodic reassessments and reevaluations of COTS and GOTS products to replace under-performing products with better ones to improve system capability and long-term viability.

Successful use of COTS products is not limited to the federal sector, either. The Boeing Company has put together a system to manage its commercial airplane configurations and parts.  The system is large and complex, with many interrelationships with other Boeing business processes and systems. The Boeing system includes several large COTS applications, COTS infrastructure, plus custom-built integration software and vendor-supported COTS customizations.

Like NASA, Boeing found that using COTS products changes the way systems should be built. For Boeing, as for NASA, a strong architecture was a key. Boeing found that it needed to carefully consider the current and future architectures and direction of COTS products in making product selections. Boeing also started with a loosely defined, flexible set of critical requirements—not the carefully detailed set that is often central to the development of a custom system. The lack of initial rigidly specified requirements allowed Boeing to use COTS products as is, even when that meant refining requirements and changing Boeing business processes. Thus requirements were formed through negotiation of stakeholder needs and knowledge of the capabilities and embedded business processes of available COTS products. What also mattered was Boeing’s focus on identifying rock-solid vendors who offered scalable products that supported Boeing’s integration standards and were committed to the success of the Boeing system.

NASA and Boeing successfully built complex systems based on COTS products because they didn’t practice business as usual. They changed their business and engineering processes to make the best use of the available COTS products. And they recognized the need for sustained engineering and management effort, such as evaluating new product releases to determine system impact and actively monitoring emerging technology, to keep the products and the system current.

These are only two of a growing number of success stories. In fact, even the Hershey story has a happy ending. A subsequent upgrade to the ERP system has gone smoothly, with the enhanced capabilities reducing costs and processing times.

Source: https://www.sei.cmu.edu/news-at-sei/features/2003/1q03/feature-1-1q03.htm

Comments