Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
VI. DEVELOPMENT OF STANDARD COMMERCIAL VERSUS SPECIAL COMMERCIAL PRODUCTS DOD has expressed a desire to use off-the-shelf commercial products because they are expected to be less costly. It is expected that perfor- mance of commercial products will be optimized to increase competitive- ness. User cost wild be lower because of a large commercial customer base over which to amortize costs for development, continuous improve- ments, and maintenance. Furthermore, the DOD may benefit from having more vendors compete for their business. This section examines the way vendors select standard products for development and the implications in cost, continuing supports, and improvements. PRODUCT DEVELOPMENT VERSUS SYSTEM INTEGRATION It is assumed in this discussion that off-the-shelf commercial pro- ducts can be used through system integration to construct system solu- tions. Most vendors supply both standard products and system integration services. Some vendors supply only the integration functions, using other vendors' products. System integration adds value to the product and in some cases results in modifications of the product to meet system require- ments. When standard products are used, the responsibility for continuing maintenance and improvements almost always can be passed to the product developer. Thus in this discussion we assume that off-the-shelf commer- cial products are standard products suppl fed by vendors to implement one or more transPort-leve] protocols for the DOD. CRITERIA FOR SELECTION OF STANDARD PRODUCTS The product vendor's choice to develop a standard product is governed by market requirements, economic opportunities, and other design consider- ations. In the case of data transmission products, market requirements include competition, connection to the installed base of products, market growth, and satisfaction of the standards requirements of customers. Often the vendor will develop a product that supports several proto- cols as options. Usually only one or two protocols will be selected for primary support, and all other options are considered for secondary sup- port. The primary protocols selected for implementation are based upon the largest potential market for the vendor. These protocols become the vendor's standard products. Standard products are announced for sale and supported on a continuing basis. Implementations of secondary protocols are often adaptations of the implementations of standard protocols and may -39 -
be suboptimal with respect to performance and continuing vendor support. Often secondary implementations are created when an REP is issued and the vendor who wishes to respond to the REP must create a special product to do so. This committee believes that, in general, future standard data transmission products will be either TP-4 or vendor-unique protocols and TOP will be a special product. STANDARD VERSUS SP EC IAL PRODUCT Within the OS] architectural model, seven layers are defined, each of which will have protocols defined for interconnection of systems. These protocols are controlled by standards. TP-4 is an example of a protocol for the transport layer. These protocols will be implemented on many ven- dor systems that have different systems architecture, different operating system architectures, and, therefore, differences in the specifics of the layer interface. The vendor systems will be designed to optimize the spe- cific environments that each vendor has determined are most important to satisfy the major market objective for that vendor's particular computer architectures. This determines the vendor's standard system and architec- ture. Support of special requirements will frequently be designed as modifications to a standard system, using translators and other techniques to bridge the differences in layer interface definitions, operating sys- tems structure, and protocols. Most support activity, optimization of performance and resource usage will be directed at the standard system architecture selected by the supplier. Special-Product Process Special-product development is initiated to meet customer specifica- tions. The specifications, schedule, and cost assume that special pro- ducts are released using an existing version of the software system (oper- ating system, language, communications, and data manager). Support for the special product is conditioned on a support contract. The special product is tested and released with that system. This provides the fastest availability of the product, since the schedule will only include the time to develop the product and test it with the selected system. It is likely that by the time a product and its software system are deliv- ered, a newer version of the software system containing code corrections and added functions and other new products will have been released. Addi- tional cost to the customer is required if the vendor is to modify the special product to operate on this new version of software. This occurs frequently in a rapidly developing technology. If the special product is not modified, operational and maintenance expenses may increase. Standard-Product Process A standard product is developed to meet the market requirements of a market area. The development of a standard product generally has a target date that is used as a basis for scheduling system development, fabrica- tion, and testing into a planned software system release. The product then is included in the test and integration plan for the system release and integration into a systems test procedure to assure operation with -40-
the other parts of the software system. The standard product then becomes a part of the software system, and as new releases of the system are made, the product is tested as a part of the integrated system to assure that it still operates with the revised, new system. The product may also be enhanced to satisfy new requirements or resolve problems of the earlier version. The product then will operate with the latest software system release. The integration process complicates the development process. The increased complexity may result in a longer development schedule or may require more resources than special products require since (~) the cycle may involve a longer product requirement definition, (2) additional plan- ning and integration testing may be needed to coordinate the product design with other system activities, and (3) there is the possibility of up to twelve months' delay in scheduling a software system release, which for most vendors generally occurs at 6- to 12 month intervals. The pro- duct may be maintained with a corrective code released in intermediate system fabrication and integrated into the following software release. Different categories of support may be available and these categories may vary by product. The support categories may range from no support to full unlimited warranty. CONCLUSION The committee concludes that there are significant benefits for the Department of Defense in using standard commercial products that meet the department's operational needs: Costs to the DOD for development, production, and maintenance are significantly lower because (~) vendors spread the cost over a much larger user base, (2) commercial vendors have to be efficient in their operations in view of the competition in the market, and (3) vendors look for ways to upgrade their product to meet competition. The department may get additional useful products because vendors integrate the protocol function into their corporate software and hardware product lines. Thus the DOD may be able eventually to use standard com- mercial software application products that are built on top of, and thereby take advantage of, the transport protocols. The DOD will thereby have a wider sel ect i on of standard commercial applic at i on products to c house from. By depending on industry to manage the development, maintenance, and upgrade of products, the DOD can use its scarce management and technical resources on activities unique to its mission. -41-
!
