cots-Based Systems (cbs) Functional Density — A Heuristic for Better cbs Design

Abstract. The conventional rationale for using COTS (commercial off-the-shelf) components is that the more a software system is built from COTS products, the lower the cost of initial development. Less under-stood is that during the long term sustainment phase – from deployment through retirement – the cost of maintenance of a COTS-based sys-tem generally increases as the number of COTS products used increases. There exists then a tension between the imperative to maximize the use of COTS components to ease CBS development yet minimize the use of COTS components to ease CBS maintenance. A heuristic called the “CBS Functional Density Rule ” is proposed to reconcile these two con-flicting views. A corresponding metric for characterizing the “efficiency” of a given CBS design relative to another called the “COTS Functional Density ” is then suggested. The paper concludes with suggestions for additional research to further validate the empirical foundations of the proposed heuristic and associated metric. 1 CBS Economics- The Conventional View In the past decade, the total annual value of dollars spent on software around the globe has continued to skyrocket. In 1993, that number (excluding related software services) was estimated to be minimally some $70 billion [1] – by 2002, that number is predicted to balloon to over $127 billion [2]. If you consider software goods and related software service industries together, the trend is even more dramatic. In 1981, global expenditures for the combination were already at $30 billion – by 1995, they exceeded $400 billion [3]. Looked at another way, in 1970, the average size of a software system was about 25 thousand source lines of code. In 1996, the average size had grown to 1.25 million sloc [4]. During that same period, it is estimated that at most 5 % of all software projects worldwide were completed on time and within budget – even worse, upwards of 75 % of software projects initiated either were never completed, or were completed too late to be of any value [5]. The trend implied by the increasing dollars spent on software coupled with the consistently high rates of software project overruns and cancellations is not encouraging