JULY/AUGUST 2005 (Vol. 22, No. 4) pp. 16-18 0740-7459/05/$26.00 © 2005 IEEE Published by the IEEE Computer Society Guest Editors' Introduction: Integrating COTS into the Development Process
Building and evolving software systems is an arduous, costly, lengthy, and complex task. The resulting systems are similarly complex. We're thus constantly searching for ways to reduce such costs, time, and complexity while increasing system functionality and quality. Not surprisingly, our quest for "silver bullets," as described by Frederick Brooks back in 1987, 1 hasn't produced significant improvements. Instead, we've achieved steady, incremental improvements in the enterprise of building and evolving software systems. The complexity of "simple" One strategy that seemed promising when Brooks wrote his article was the notion of "buy not build." Using COTS products is one way to implement this strategy, because software development then becomes the process of "simply" integrating COTS components. However, it turns out that dealing with COTS is a high-risk activity for a variety of reasons. The initial manifestation that integrating is something other than a simple integration activity appears in the form of the architecture mismatch problem. 2 COTS components make several assumptions about architectural issues. Then, when these assumptions conflict or don't match, the simplicity of using COTS quickly disappears in a cloud of complexity and integration scaffolding. The root of the problem is the lack of access to the components' source code and developers. Moreover, we seldom find ourselves in a pure COTS component integration environment, because we usually use a hybrid of specially developed components mixed with COTS components or products. Thus, instead of an endgame activity, using COTS products becomes an integral part of the entire software development life cycle. It transcends social, economic, and development concerns and affects all traditional aspects of software development—requirements engineering, architecture, design, implementation, testing, and long-term maintenance. Over the past decade, data- and control-integration mechanisms and standards have matured significantly. Moreover, COTS products have become end-user programmable, extensible, and interoperable. Although we shouldn't hype the combination of these improvements as a silver bullet, they have led to new avenues for incorporating COTS into software systems. Innovative COTS integration The idea for this special issue of IEEE Software grew out of two recent COTS workshops. The first was the International Workshop on Incorporating COTS into Software Systems (IWICSS), held at the International Conference of COTS-Based Software Systems (ICCBSS 2004). The motivation behind IWICSS was to address the integration of COTS into the entire development life cycle. The second was the Fourth Workshop on Adoption-Centric Software Engineering (ACSE), held at the International Conference on Software Engineering (ICSE 2004). The motivation behind the series of ACSE workshops was to investigate how to extend COTS products to build software engineering research tools. Users are more likely to evaluate and adopt such research tools if they're already familiar with the host COTS, so we need to leverage the COTS products' functionality, cognitive support, and interoperability. The focus articles in this issue explore innovative ways of integrating COTS products into software systems for purposes often unimagined by their creators. They investigate the challenges, risks, and benefits of building COTS-based software systems. "An Active-Architecture Approach to COTS Integration," by Brian Warboys, Bob Snowdon, R. Mark Greenwood, Wykeen Seet, Ian Robertson, Ron Morrison, Graham Kirby, Dharini Balasubramaniam, and Katherine Mickan, presents a mechanism for recognizing COTS products as integral parts of any information system's environment. The authors' ArchWare framework addresses the integration problems of COTS and other components using an active-architectural model that captures the composition and integration of these elements and changes as the system evolves. The goal is to manage both the predicted and emergent changes that result from using COTS components as elements in a system's architecture. Addressing the critical issue of coordinating COTS components is the focus of the next article, "Coordinating COTS Applications via a Business Event Layer," by Wilfried Lemahieu, Monique Snoeck, Frank Goethals, Manu De Backer, Raf Haesen, Guido Dedene, and Jacques Vandenbulcke. Recognizing the need for a dynamic structure within which components can execute and interact, the authors raise the level of the coordination mechanisms. Moving away from the message-oriented middleware prevalent today, the authors use a more appropriate level of abstraction—namely that of business events. These events reside in the problem space and provide an appropriate domain-specific model for coordination and concurrent execution. Another prominent issue in software systems is performance, which is typically addressed at the architecture, design, and implementation levels. Maximizing performance usually requires making trade-offs in the various components when the code is available for manipulation, but this is difficult with COTS components. In "Performance Techniques for COTS Systems," Erik Putrycz, Murray Woodside, and Xiuping Wu use new tracing techniques as the basis for building performance models of COTS components. These models can then be used when reasoning about performance trade-offs in the architecture planning, design, implementation, and deployment stages of built systems incorporating COTS components. A variety of issues are involved in selecting appropriate components for a system, whether they're pre-existing product-line assets, COTS components, or COTS products. As in performance, the problem is exacerbated by the fact that the code isn't available for evaluation the way it is for other assets that we use and reuse. In "Evaluating COTS Component Dependability in Context," Paolo Donzelli, Marvin Zelkowitz, Victor Basili, Dan Allard, and Kenneth N. Meyer provide an empirical COTS evaluation process that addresses risk issues by focusing on the context in which the component will be used. A case study illustrates their approach. Traditional process models assume that development and evolution processes are largely based on a fresh beginning and internal control of the architecture, design, and source code. Based on their experiences of empirically analyzing COTS-based applications, in "Value-Based Processes for COTS-Based Applications," Ye Yang, Jesal Bhita, Daniel N. Port, and Barry Boehm describe a set of value-based processes to minimize the risks of integrating COTS components into an application. They provide guidelines, an associated framework, and a set of processes to support COTS-based application development. Conclusion In the future, COTS products will play an increasingly important role in not only software product engineering but also software engineering tool development. Over the past decade, we've witnessed a consolidation of data, control, and presentation integration techniques, which will significantly ease the integration difficulties of COTS. Investigating the challenges and risks involved in leveraging COTS products in systems and tools will be a hot research topic for years to come. References
| ||||||||||||||||||||||||||||||||||||||||||||