| GUIDANCE | ||||||||||||||||||||||||||||||||||||||||||||||||||
| The Pricing Handbook / Appendix 19E
19. Software Pricing 19E. COMMERCIAL-OFF-THE-SHELF (COTS) SOFTWARE
Table of Contents 19E.2 COTS Software Five Panel Model 19E.3 COTS Cost Estimation Model Status 19E.4 COTS Cost Estimation/Pricing Equations 19E.4.1 COTS Qualification Costs 19E.4.3 Glue Code Assembly Costs 19E.5 Impact of COTS on System Testing
19E. COMMERCIAL-OFF-THE SHELF (COTS) SOFWARE
19E.1 Introduction This appendix summarizes the special considerations related to incorporating COTS (commercial-off-the-shelf) software components into a system. These considerations vary so much from standard software development approaches that special versions of software cost estimating models are being created to deal with the peculiarities. If a COTS software product is to be used as a stand-alone item, then some subsections such as those considerations related to "glue code" do not apply. For a COTS software product that will be integrated into a system, all the sections of this appendix apply. The majority of this introduction is extended from the model rationale used by the University of Southern California (USC), Center for Software Engineering (under the direction of Dr. Boehm) for the new COTS version of COCOMO (discussed in section 19E.3). One of the more significant changes in software development practice over the past twenty years is the greatly increased emphasis being placed on building systems incorporating pre-existing software in order to keep overall development and maintenance costs as low as possible. One source of pre-existing software is commercial vendors who supply self-contained off-the-shelf components that can be plugged into a larger software system to provide capability that would otherwise have to be custom-built. The two primary distinguishing characteristics of COTS software are 1) that its source code is not available to the application developer (software developer that will incorporate a COTS component into a larger system), and 2) that its evolution is not under the control of the application developer. The rationale for building COTS based systems is that development time is reduced by taking advantage of existing, market proven, vendor supported products, thereby reducing overall system development costs. In the case of using such components as databases and operating systems, this is almost certainly true. However, there are little data available concerning the relative costs of using the component-based approach. Due to a of the lack of access to product source code and a lack of control over product evolution, there is a trade-off that results using the COTS approach. New software development time can indeed be reduced; however, the cost of software component integration generally increases. Moreover, if integrating COTS components, there will be additional system costs to negotiate, manage, and track licenses to ensure uninterrupted operation of the system. Moreover, using COTS software also brings with it a host of unique risks quite different from those associated with software developed in-house. The true cost of integrating a COTS software component into a larger system includes the traditional costs associated with new software development such as the cost of requirements definition, design, code, test, and software maintenance. In addition, the cost of integration includes: the cost of licensing and redistribution rights; royalties; effort needed to understand the COTS software; pre-integration assessment and evaluation; post-integration certification of compliance with mission critical or safety critical requirements; indemnification against faults or damage caused by vendor supplied components; and costs incurred due to incompatibilities with other needed software and/or hardware. The following sections explain the system development model phases, cost estimation model status, cost estimation/pricing equations, testing/supportability/risk considerations, and licensing schemes for COTS software.
19E.2 COTS Software Five Panel Model The COTS model pictured in Figure 19E-1 represents various activities that address different aspects of turning a set of COTS components into a COTS-based system. This model was obtained from the Software Engineering Institute (SEI) at Carnegie Mellon University, who have authored a number of Special Reports and hosted Workshops devoted to COTS software. This section will cover in greater detail than section 19.2.4, the model’s five phases and outline the some of the cost/risk considerations associated with them.
The COTS Market phase deals with the market survey and analysis activities that determine the viable candidates for a particular component, from both a business and a technical perspective. Discussing the many aspects regarding a market analysis is outside the scope of this appendix. More information can be obtained by referring to DRAFT Air Force Handbook 60-113, Buying COTS Handbook (http://www.safaq.hq.af.mil/eng_ind_env_policy/syseng/policies/ dcotshbc.html). The Air Force Handbook has an extensive section and attachment on conducting a COTS market analysis. The Qualify phase activities investigate the hidden interfaces and other characteristics and features of the candidate products. Per SEI in their article "Component-Based Software Development/COTS Integration," component qualification is a process of determining "fitness for use" of previously-developed components that are being applied in a new system context. Qualification of a component can also extend to include qualification of the development process used to create and maintain it (for example, ensuring algorithms have been validated, and that rigorous code inspections have taken place). Continuing with the SEI article, there are two aspects of component qualification: discovery and evaluation. For discovery, the properties of a component are identified. Such priorities include component functionality (what services are provided) and other aspects of a component's interface (such as the use of standards.) These properties also include quality aspects that are more difficult to isolate, such as component reliability, predictability, and usability. In some circumstances, it is also reasonable to discover "non-technical" component properties, such as the vendor's market share, past business performance, and process maturity of the component developer's organization. Discovery is a difficult and ill-defined process, with much of the needed information being difficult to quantify and, in some cases, difficult to obtain. The most difficult problem in the qualify phase is to determine the characteristics of the available COTS products so that a product which best meets the requirements may be selected. The result of this discovery process is to reveal the necessary information to make a selection and identify possible sources of conflict and overlap, so that the component can be effectively assembled and evolved. The following excerpt from a Crosstalk article describes the selection process. "Experience shows that the selection process for one major product can require three to six months of calendar time, multiple engineers and programmers, access to sophisticated suites of hardware and software environments, and will likely entail the purchase of vendor-provided training classes." March 1998 STSC Crosstalk The rationale behind this time and expense are summarized by Richard D. Stutzke in his paper "Cost Factors for COTS Integration." Typically the COTS capabilities which are of interest to the designer are the completeness of the functions provided, the COTS product’s architecture, and the maturity and expected life of the product. The product’s architecture is particularly important since COTS products often make assumptions about the environment in which they will operate. The product's architecture dependencies also affect the partitioning of the components of the COTS product and their dependencies. These dependencies can have significant cost impacts when the various components are integrated. Dr. Stutzke states that during the evaluation process, the analyst must build a mental model which relates the general and specific knowledge for both the system being built and the COTS product being considered for inclusion into that system. He referred to three models that the analyst must construct to understand a software program:
A key point concerning these models is that knowledgeable people are essential to correctly evaluate COTS components expeditiously. Because individual components are written to meet different requirements, and are based on differing assumptions about their context, components often must be adapted when used in a new system. A March 1998 article in STSC Crosstalk on COTS states that COTS software does not require coding but does require integration with other components. As a result, it starts the life cycle as a partially developed component. The design, construction, and integration and test development stages must be recast to accommodate early COTS software integration and testing as well as to develop "Glue Code" (interface software, configuration files, scripts, utilities, and data files) which is required to make the COTS software deliver its intended functionality. Referring again to the SEI article, components must be adapted based on rules that ensure conflicts among components are minimized. The degree to which a component's internal structure is accessible suggests different approaches to adaptation:
Each of these adaptation approaches has its own positives and negatives; however, White box approaches, because they modify source code, can result in serious maintenance and evolution concerns in the long term. Wrapping, bridging, and mediating (included as part of the "Glue Code") are specific programming techniques used to adapt Grey- and Black-box components. The Assembly phase is the integration of the adapted components into a software architectural infrastructure. Components must be integrated through some well-defined infrastructure that provides the binding that forms a system from the disparate components. This infrastructure supports component assembly and coordination, and differentiates architectural assembly from ad hoc "glue". Referring again to the March 1998 STSC Crosstalk article, waiting until late in the development process to test and integrate COTS products, particularly those that are complex, will not give adequate time to master all their intricacies and complexities. COTS product testing and integration activities must be interwoven into more of the development process stages. Extended from Dr. Stutzke’s paper, Table 19E-1 summarizes two types of potential problems that may occur during the assembly phase. First, it is very difficult to determine exactly how hard it will be to tailor and integrate the COTS product into the new system. As indicated in the table, the steps are first to obtain a detailed, understanding of the component, then the component must be modified and tested. In some cases the product must be documented as well. Table 19E-1. Managing Potential Assembly Phase Problems
The second potential problem is that new versions of the COTS products are often released during the integration process. This can affect the cost of development, therefore some sort of strategy is needed to manage this. The likelihood of new versions increases if the project lasts longer that one year. The particular process used by the development team can significantly affect the cost of integrating COTS components. The three important process areas are installing and integrating the component initially, installing new versions of the components which become available during the integration process, and tracking and controlling the baselines. The Update phase acknowledges that new versions of components will replace older versions; in some cases, components may be replaced by different components with similar behavior and interfaces. These replacement activities may require that glue code be rewritten, and they suggest the advantage of well-defined component interfaces that reduce the extensive testing otherwise needed to ensure that the operation of unchanged components is not adversely affected. Per the SEI article, component-based systems may seem relatively easy to evolve and upgrade since components are the unit of change. To repair an error, an updated component is swapped for its defective equivalent, treating components as plug-replaceable units. Similarly, when additional functionality is required, it is embodied in a new component that is added to the system. This is a highly simplistic (and optimistic) view of system evolution however. The new component will never be identical to its predecessor and must be thoroughly tested, both in isolation and in combination with the rest of the system. As a result, replacement of one component with another is often a time-consuming and arduous task. Wrappers must typically be rewritten, and side-effects from changes must be found and assessed. Dr. Stutzke concluded that the "volatility" of COTS products is a source of significant uncertainty and risk, increasing in magnitude as the length of the system’s planned service life increases. A COTS product is volatile in two ways: features and price. COTS products are market-driven and evolve rapidly in response to consumer and competitive pressures. The vendor adds (and sometimes deletes) features based on many factors. Regarding pricing, maintenance pricing is the most volatile (assuming the initial purchase occurs shortly after the evaluation is completed.) Changes in maintenance price are primarily of interest for estimating the operating costs of the deployed system. Typically, vendors encourage the user to discontinue use of a product they want to retire by increasing the annual maintenance fees (to cover the reduced number of active users.) The may also offer attractive price reductions on the purchase price of new, replacement products. The obsolescence of product features and/or changes in maintenance price may cause significant redesign and refurbishment of the deployed system long before its useful life is over. Of course, these costs impact the lifecycle costs of the system.
19E.3 COTS Cost Estimation Model Status The USC's Center for Software Engineering under the direction of Dr Boehm is in the process of developing a version of COCOMO tailored for the unique requirements of estimating COTS software. This model is called COCOTS (COnstructive COTS). COCOTS is considered experimental and evolving. The latest information on this model can be obtained at website http://sunset.usc.edu/COCOTS/cocots.html. The contents of this section were extended from the information obtained from the COCOTS web site. COCOTS’ goal is the development of a comprehensive COTS integration cost modeling tool. The approach taken was to first examine a wide variety of sources in an attempt to identify the most significant factors driving COTS integration costs, and then to develop a mathematical form for such a model. 19E.3.1 COCOTS Model The current model provides insight into the most important factors that should be considered when estimating the cost of integrating COTS components, regardless of the specific tool or methodology used to perform that estimation. "The model represents a prototype implementation of the first of four submodels being proposed for COCOTS, namely, the glue code submodel. The model is not yet mature enough for the estimates it provides to be used with a high level of confidence. However, the cost parameters contained within the model and the criteria used to rate those parameters as described in the user guide certainly offer much insight into the questions a software cost estimator should be considering when working on a system to be built with COTS components." The USC COTS integration cost model version 1.0 takes the following form: SIZE = KSLOC (1.0 + BRAK/100) PM = A*(SIZE) * EMi
COST = (PM)*($$/PM) Table 19E-2. Definition of Symbols
USC suggests the following procedure when attempting to use their model for a COTS integration cost estimation exercise:
This completes the COTS integration cost estimation procedure. 19E.3.2 Other COTS Cost Models In preparing to create the COCOTS model, USC researched other available COTS models. They discovered that quantitative COTS integration models available for review in the public domain were almost non-existent. Three models were discussed in the COCOTS paper, two by Science Applications International Corp. (SAIC) and one by Loral Federal Systems. USC’s discussion of these models is summarized here to provide further understanding into the cost drivers that influence COTS integration costs. One model proposed by Richard Stutzke of SAIC centered on the issue of COTS volatility, which is, the frequency with which a COTS vendor releases new versions of its software. (This has been identified as one of two primary determinants in the cost of using COTS software, the other being the actual size of the interface or "glue" code needed to integrate a given COTS product.) His model suggested a way to quantify the added cost associated with using a COTS product that has significant volatility. It is included here to assist the analyst if faced with this situation. In brief, Dr. Stutzke proposed the following formula: Extra Cost due to Volatility = CV*AC*IS*(CS + CC) Where : CV = Component volatility (number of new releases of the COTS component over life of the project). AC = Architectural coupling (number of other components which interface with the given COTS component). IS = Apparent interface size in terms of the number of entry points, procedures, functions or other methods used to access the COTS component, weighted by the number of arguments passed. CS = Cost of screening the COTS component and all the other components with which it interfaces to determine the impact of a new release. CC = Cost of making changes to impacted components. As of USC’s writing, no attempt had been made to implement this model. It also addresses only one aspect, although an important one, associated with integrating COTS software. Still another approach to modeling COTS integration costs was taken at SAIC. This second model addressed more the end user costs of using COTS software. The model takes this form: COTS Integration Cost=[(Cost of COTS product licence)*(Number of Licences) +COTS product training cost)+(COTS Interface or glue code cost This model highlights some important sources of cost, but ignored the details of determining the last term, the cost of developing the COTS product glue code. An alternate model that attempts to address the issue of estimating the cost of developing COTS interface code has been described by Tim Ellis of Loral Federal Systems. This model was well into the implementation stage (when the article was written), having been calibrated to a number of internal Loral COTS integration projects, with more continually being added to the model’s calibration database. Mr. Ellis describes the COTS integration model in these general terms:
Where: Size = Size of the COTS interface or glue code in function points. Drivers = Set of seventeen COTS integration cost drivers. LM = Labor-months. P = Productivity. WU = Work units. The greatest influence the Loral model had on the development of the USC COCOTS integration cost model came from its seventeen cost drivers, which served as one of the starting points in the definition of the USC COCOTS model drivers. The disadvantage of the Loral model is that the total size of the COTS component is generally thought to be irrelevant, and the Assessment & Assimilation (AA) and Percentage of Integration & Test Modification (IM) COCOMO parameters were not considered to be adequate descriptors of the factors affecting COTS integration efforts.
19E.4 COTS Cost Estimation/Pricing Equations Estimating the cost of a software system that includes COTS components requires the inclusion of more cost areas than typical software development efforts. Figure 19E-2 provides a general illustration of the standard software development costs included in the Software Cost Estimating Process of section 19.2. Figure 19E-3 shows the four additional cost areas when COTS components are integrated to form a complete system. This section will discuss the general cost equations that can be used to calculate the costs in these four areas. These two figures and the equations in this section were adapted from a briefing given in August 1998 by Dr. Boehm and Christopher Abts titled "COCOTS Software Integration Cost Model."
19E.4.1 COTS Qualification Costs COTS Qualification costs typically have two parts, the initial filtering efforts to identify candidates and then the final selection effort to select the winning COTS vendor. The equation for the filtering effort done during discovery takes the form: Total Effort = (# COTS Candidates)( Average Filtering Effort)
Final selection is based upon the evaluation of the candidate components for certain functionality attributes. The general equation to estimate this effort has the form:
These costs are associated with tailoring the selected COTS components to meet requirements and take the form:
USC uses five adaptation effort complexity levels (very low to very high), differentiated by the difficulty of needed scripts, API iterations, etc. 19E.4.3 Glue Code Assembly Costs This effort takes the form of the equation used in the currently existing COCOTS Glue Code model. Section 19E.3.1 contains additional detail on the variables in this equation. Further information and a copy of this model can be obtained from the COCOTS websitehttp://sunset.usc.edu/COCOTS/cocots.html):
Where: A = Linear scaling constant Size = Size of the glue code in SLOC or Function Points Breakage = Glue code due to changes in the requirements and/or COTS volatility Effort Multipliers = 13 parameters, each with a range from very low to very high b = Architectural scale factor with settings from very low to very high. 19E.4.4 Increased Application Effort Due to COTS Volatility Approximate Application Effort Model:
Where: BRAK COTS = % application code breakage due to COTS volatility BRAK = % application code breakage otherwise EM = Product of Effort Multipliers Using the above four equations added together (which form the basis of COCOTS) would provide an estimate for the COTS software integration effort. This effort could then be converted to a cost estimate by multiplying it by the average cost of a person-month. There are other COTS costs that also must be added in: the costs to obtain and support the COTS components (COTS SW), the maintenance costs for the COTS integration software (COTS SW integration) which can be estimated using the completed version of COCOTS and the costs associated with any required COTS hardware (COTS HW). 19E.4.5 Software System with COTS Components Costs The total cost of a software system that includes COTS components could be estimated by adding together the following: Table 19E-3 Total Cost of Software System
Estimating the cost of obtaining the COTS software for each COTS component would take the following form:
Estimating the cost of obtaining the COTS Hardware would take the following form: COTS HW
Where: i = number of processors, storage, workstation, communications Unit costs vary by quantity, platform, and time. if all the items are not procured at the same time, there will be a need to consider time-phasing of acquisition, implementation, operations & maintenance. The biggest challenge will be the complex, dynamic COTS price structures.
19E.5 Impact of COTS on System Testing This section (extended from the draft Air Force Handbook 60-113, "Buying COTS"), is included in order that the analyst may consider these two questions when pricing a proposal or developing a cost estimate. Does the proposal/estimate cover these tests? Is some testing missing or is there too much testing? An important advantage of COTS software is reduced delivery time. This is realized through the elimination of the research and development phase of the acquisition cycle and subsequent development test and evaluation. In general, testing is not required when the software will be used and maintained by similarly skilled people in the same environment as that for which it was designed and existing data (contractor or other sources) provides reasonable answers to performance and supportability issues. If COTS software components are being integrated into a larger system, then system integration testing and selected component testing would be required. Operational testing is strongly recommended if operational or support environments differ from the contractor's. Further, preselection testing in the Qualify phase should be conducted to minimize technical, operating and support risk. For stand-alone COTS in a commercial-like (same-environment) application, no testing should be required if the application is the same as commercial use of the item. If there is any doubt, an analyst should acquire and qualify a test sample prior to selection. After delivery of a successful item, any deficiencies that appear should be covered by the vendor's commercial warranty. For COTS embedded in a larger system, feasibility testing to qualify a test sample should be done prior to selection and integration into the system. Development Test and Evaluation (DT&E) of the complete system is required. Hardware and software integration tests should be conducted as well as user testing (typically, operational test and evaluation (OT&E)) at the system level. COTS deficiencies that appear during or after system-level testing should be covered by the vendor's commercial warranty. Special considerations for specific testing areas are as follows: Development Testing. Development testing should be conducted at the system level but not at the COTS assembly level since COTS is already developed. If an item does not meet performance standards/requirements, select other COTS or go for a non-COTS design effort. Operational Testing. Selection of COTS items does not automatically mean there will be no need for operational testing. However, operational testing for COTS components (or stand-alone COTS) should be limited or waived if market investigation data and, as applicable, pre-selection qualification testing will satisfy the requirements. Operational testing, as previously mentioned, should be conducted for a system with integrated COTS components. Supportability Evaluation. The impact of COTS on system supportability probably requires testing that should include reliability testing, organizational level maintainability testing, human factors engineering tests, standardization measurements and safety analysis. Compatibility Testing. Follow-on compatibility testing in fielded systems could be conducted for all significant hardware or software revisions to a COTS item. This testing should verify that the interfaces are not violated, and be completed before the Government accepts the change. Reviewing the vendor's service bulletins and engineering change orders (ECOs) can help identify which changes would require testing. Quality Assurance Provisions. A quality assurance provision should be specified for each system-level functional and physical requirement in the contract. However, quality control of individual COTS items should be covered by the vendor's commercial warranties. Π The rapidly changing market and technology of COTS items means that it will have a limited useful life cycle. In their draft Handbook 60-113, the "Buying COTS," the Air Force considers a number of important factors that could impact the cost in the support of commercial items. The Handbook recommends that support requirements should be defined before SIR release. Support requirements should also include an up-front definition of the system support requirements to the item level, a lifetime support strategy and appropriate contract language to implement the support strategy. Acquisition contracts should include support such as maintenance, support equipment and training for the total expected life cycle as well as pre-planned product improvements or when replacements are needed. A market analysis should be performed while the requirements document is still in draft form. If COTS items are to be embedded in a larger system by a prime contractor, be sure that the prime contractor acquires all the required information from the proposed vendors. The preferred method of support for COTS products is through local acquisition and locally-acquired contractor service. Any decision for life-cycle contractor logistics support must be accompanied by adequate planning. In the absence of a formal contractor support agreement, plan for an appropriate level of organic management and support for COTS assets. When determining the support for a commercial item, it is recommended to evaluate original contractor's support, alternate vendors' support, and Government support with regards to impact on competition, operational requirements, total support costs, and support availability. Three major areas of concern in COTS support are configuration management and data; maintenance policy; and sustainability. 19E.6.1 Configuration Management Data Except under very unusual circumstances, it is not wise to demand full design disclosure engineering data, for system support. Even if the vendor was agreeable to selling the data, it would quickly be obsolete because the government would not have design control. Contractors can unilaterally change the design as necessary to suit their customer or market requirements. COTS designs should be documented to the system interfaces level. For COTS software, the government should acquire and maintain appropriate licensing and subscription services (vendor field change orders and software releases) throughout the life of the system. If the Government secures change authority, it must clearly define the limits of what the Government can change, and restrict alterations in any way that would void the licensing or subscription service. Independent software changes by the Government, or a Government freeze to an earlier COTS software version, will turn COTS into a unique product. Employment of COTS will usually lock the government into two-level maintenance: organizational and depot. The most desirable support concept is contract repair, preferably via competition. A good strategy is to price support options while the original buy is still in competition. The riskiest course is an in-house depot repair, which should be selected only under exceptional conditions because it will have to be a specialized operation if even possible at all. The vendor might refuse to sell the data and tools to develop a capability. Because of the design control the Government has had over in-house developmental software, many systems have been maintained and upgraded to serve multiples of their original design life. Market pressures usually send commercial designs more quickly into obsolescence not so easily dealt with. It is not uncommon for this to occur within five years, which means that retrofit funding should be routinely projected approximately at the time of original system fielding. There should be cost estimates for maintenance and eventual replacement of COTS software. Licensing and subscription service represent a significant annual cost, and replacement cost will also be considerable.
This section is extended from the USC COCOTS model’s "COTS Integration Modeling Study", dated June 1997. There are four key COTS integration characteristics that make COTS integration significantly different from other forms of software development (including maintenance). These characteristics require traditional approaches to software development to be significantly revised when considering program risk. The characteristics are:
19E.7.1 COTS Functionality or Performance If the source code can be modified, it’s not really COTS and its future becomes the Government’s responsibility. Even as black boxes, big COTS products have formidable complexity: Microsoft people have indicated that Windows 95 has 25,000 entry points. Resulting Pitfalls
Resulting Recommendations
Interoperability problems can cause COTS integration cost and schedule overruns by factors of four to five. Resulting Pitfalls Lack of COTS interoperability exacerbates each of the previously cited pitfalls. Some additional direct pitfalls are:
Resulting Recommendations The previously cited recommendations on risk-driven processes and co-evolving requirements and architecture are appropriate here. In addition:
Again, COTS vendors respond to the overall marketplace and not to individual users. Upgrades are frequently not downward compatible. Old releases become obsolete and unsupported by the vendor. If COTS architectural mismatch does not happen initially, COTS architectural drift can easily occur later. Current COTS-intensive systems often have higher software maintenance costs than traditional systems, but good practices can make them lower. Resulting Pitfalls Lack of evolution controllability exacerbates each of the previously cited pitfalls. Some additional direct pitfalls are:
Resulting Recommendations The previously-cited risk-driven and architecture-driven recommendations are also appropriate here. In addition:
Vendor behavior varies widely with respect to support, cooperation, and predictability. Sometimes a COTS vendor is not even the developer, just a value-added re-seller. Given the three major sources of COTS integration difficulty above, an accurate assessment of a COTS vendor’s ability and willingness to help out with the difficulties is tremendously important. Experience indicates that the value of a COTS vendor’s support follows a convex curve with respect to the vendor’s size and maturity. Small vendors often lack the capability to support the user; very large vendors have the capability, but not the motivation. Per Dr. Stutzke, designers and managers should realize that there may be a large hidden price to be paid for the use of COTS components incorporated into a software system. The most frequently encountered problem is the need to update the COTS product during integration. Such updates often cause incompatibles to arise between COTS products that previously worked together. Increases in the price of the annual license and maintenance agreements can affect operating costs. Liabilities for damage caused by the failure of a COTS product may be very costly. More difficult to predict is the loss of critical features as the vendor upgrades the product in response to market pressures (including withdrawal of the product from the market, in the extreme case). Such losses can cause significant redesign of the deployed system long before its useful life is over.
Referring again to Dr. Stutzke’s article, the license terms for the COTS products can affect the cost of the overall system and even affect the choice of the architecture. Dr. Stutzke adapted a memo by Gibson and Mankofsky which grouped their license types into the six types shown in Table 19E-4. The names used were defined to be as descriptive as possible since there is no standard terminology used by vendors to refer to these types of licenses. This makes it extremely difficult to compare the costs of products offered by different vendors.
The license costs are primarily of interest in making the "buy or build" decision during the Product Design phase or the Proposal phase (since this is when the price must be determined). The cost of developing the products must be traded against the cost of purchasing the necessary number of copies and integrating them into the system. In-house developed products have a significant non-recurring engineering cost which is paid once. All subsequent copies of the component may; however, be used for essentially no cost for the life of the system, regardless of how many copies of the product are produced. For a COTS product, the non-recurring engineering cost is absorbed by the vendor but the buyer (developer of the new system) must pay a license fee for each copy of the component which is used. Complex trades-off analysis must be made between functionality, cost, schedule, risk, etc., involving not just the development and production cost but also the operating costs of the deployed system when performing a make (develop) or buy (COTS) decision. Other factors may affect the cost of a COTS product. First, discounts may be available if multiple copies are purchased (volume discounts. ) Second, reduced prices may be offered if several related products are purchased together ("bundling"). Third, sometimes the first year of maintenance is provided free with the initial purchase of the product. Fourth, if the product is utilized during the development process, it is possible that an additional warranty must be purchased prior to delivery of the system to the customer. Fifth, there may be liability costs in the event COTS components cause failure in the system during operations. Such costs could cover damage to equipment, injures to personnel and loss of service. Last, there may be refurbishment costs associated with the loss of critical functions as the product evolves in response to market pressures. The functions needed may be removed from later versions of the product. Multiple types of licenses must be mixed to obtain the necessary number of copies of a product. Sometimes a full license is purchased to obtain a complete set of documentation and several other "right to use" licenses are purchased to allow copies of the "full" product to be used on other platforms. Such mixing and matching can have significant impacts on the total cost of a system.
The utilization of COTS software components/products is intended to reduce the cost and schedule of software development programs. If the COTS component is a stand-alone product, it probably will. However, for integrating COTS components into a larger system, there are many factors that must be considered. This appendix has outlined the primary considerations and the basic cost equations that apply to COTS software cost estimating and pricing. |
