Update on Activities at USC Center for Software Engineering

David Klappholz
Associate Director, New Jersey Center for Software Engineering

The New Jersey Center for Software Engineering is a university affiliate of Prof. Barry Boehm's Center for Software Engineering at the University of Southern California. The purpose of our affiliation with USC is to foster collaboration between USC CSE and NJCSE researchers and to bring awareness of developments at USC to the New Jersey software community.

As an essential aspect of NJCSE's affiliation, one or two NJCSE members regularly attend the USC CSE Annual Research Review in early February. This year the Review was held on Tuesday, February 6. It was followed, as is usual, by a three-day (February 7-9) Focused  Workshop, with this year's focus on COTS-Based Systems (CBS); as is also typical, the Focused Workshop was co-sponsored by the Software Engineering Institute (SEI) at Carnegie Mellon University. This year the Annual Research Review was also preceded by a two-day (February 4-5) review of the activities and status of CeBase (Center for Empirically-Based Software Engineering), an NSF grant held jointly by Prof. Boehm of USC and Prof. Vic Basili of the University of Maryland. Attendees included members of the three sponsoring organizations, including their three directors, Prof. Boehm (USC CSE), Prof. Basili (UMD), and Steve Cross (SEI), as well as representatives of USC CSE's Affiliates program, which includes such commercial/industrial organizations as Microsoft, IBM, Rational, Motorola, Hughes, Sun, Telcordia, Boeing, and Lockheed Martin, and such government/FFRD organizations as FAA, USARL, and JPL.

The most interesting aspect of this year's activities was the discussion of what the software development world has learned since the beginning of the COTS revolution, i.e., the move away from pure custom development towards the use of Commercial Off The Shelf components (COTS), with entire systems of applications consisting of COTS components tied together with "glue code." Among the important issues raised were the following:

• Choice of COTS components must be done not only on the basis of features, performance, and cost, but also on the basis of evaluations of the financial health of the companies producing those COTS components, and the levels of customer service provided by those companies. (COTS product documentation is often incomplete and/or inaccurate. Successful producers of consumer-market COTS products are more likely to be long-lived, but less likely to be helpful; producers of niche-market COTS products are less likely to be long-lived, but more likely to be helpful.)

• Requirements must often be tailored to features and performance characteristics of available COTS products -- or the use of COTS may be impossible; claims of COTS component features and performance must be carefully tested, in-house, by potential integrators, using benchmarks specific to systems/applications into which COTS components are to be integrated.

• Requirements must be constantly revisited as development with COTS progresses; as a result, the waterfall lifecycle model cannot be used in the context of COTS-based development; additionally, more sophisticated lifecycle models, e.g., iterative, incremental, spiral, etc., must be adapted for use in COTS-based development.

• Non-synchronized COTS-based-product version release and COTS-component version release make release planning far more difficult than without COTS; in fact, new versions of COTS components may be missing features specifically needed in software products into which earlier versions have been integrated; new versions may not perform as required by software products into which earlier versions have been integrated. Finally, COTS products are often terminated by their producers.

• Reduction in total cost for COTS-based vs. custom development is often illusory, especially given the version-synchronization problem discussed in the previous point; specifically, the added cost of product maintenance and evolution often exceeds savings during the development phase. As a result, the best argument for COTS-based development is usually speed of development of feature-rich products. (I.e., products with features achievable using COTS would take far longer to bring to market without the use of COTS components.)

• Cost-estimation methods, scheduling methods, process metrics and process maturity metrics are, as yet, either unavailable or far less sophisticated for COTS-based development than are their custom-development counterparts.

• COTS-based software is often especially vulnerable to security problems because: the source code is known by the COTS component developers, but not by the COTS-based product developers; security is often just an afterthought in commercial-market COTS components; the widespread use of popular COTS components makes them prime targets for hackers; etc., etc.

During the course of both the Annual Research Review and the Focused Workshop, demonstrations were given of software products developed through USC CSE research and available either through CSE or from commercial developers. Of particular note are COCOMO, CSE's cost-, effort- and schedule-estimation model/tool, and EasyWinWin, a recently-commercialized requirements-engineering tool. 

Information about COCOMO, including the COTS-based version, COCOTS, as well as software downloads, are available at http://sunset.usc.edu/research/cocomosuite/index.html and associated web pages. 

Information about Easy WinWin, and university-produced  WinWin software may be found at http://sunset.usc.edu/research/WINWIN/index.html.

Information about Easy WinWin, the commercial version of WinWin, is available from http://www.groupsystems.com.

Information about MBASE, a tool for Model Based Architecting and Software Engineering, may be found at http://sunset.usc.edu/research/MBASE/index.html.