1 Component-based Software Engineering ��� New Challenges in Software Development Ivica Crnkovic M��lardalen University, Department of Computer Engineering, V��ster��s, Sweden ivica.crnkovic@mdh.se, http://www.idt.mdh.se/personal/icc tel: +56 70 533 75 57 fax: +46 21 10 41 60 Abstract The primary role of component-based software engineering is to address the development of systems as an assembly of parts (components), the development of parts as reusable entities, and the maintenance and upgrading of systems by customising and replacing such parts. This requires established methodologies and tool support covering the entire component and system lifecycle including technological, organisational, marketing, legal, and other aspects. The traditional disciplines from software engineering need new methodologies to support component -based development. IVICA CRNKOVIC assesses the challenges of this emerging technology and discusses its implications for the software development process. Keywords : Software Components, Software Engineering, Software Architecture, COTS, Component-based development, Component-based Software Engineering

2 Software Development Challenges We are witnessing an enormous expansion in the use of software in business, industry, administration and research. Software is no longer marginal in technical systems but has now become a central factor in many fields. System features based on software functionality, rather than other characteristics, are becoming the most important factor in competing on the market, for example in car industry, the service sector and in schools. Increasing numbers of software users are non-experts. These trends place new demands on software. Usability, robustness, simple installation and integration become the most important features of software. As a consequence of the wider area of software utilisation, the demand for the integration of different areas has increased. We distinguish between vertical integration in which data and processes at different levels are integrated, and horizontal integration in which similar types of data and processes from different domains are integrated. For example, in industrial process automation, at the lowest levels of management (Field Management), data collected from the process and controlled directly, is integrated on the plant level ( Process Management), then is further processed for analysis and combination with data provided from the market and finally published on the Web (Business Management). A consequence of all this is that software is becoming increasingly large and complex. Traditionally, software development addressed challenges of increasing complexity and dependence on external software by focussing on one system at a time and on delivery deadlines and budgets, while i gnoring the evolutionary needs of the system. This has led to a number of problems: the failure of the majority of projects to meet their deadline, budget, and quality requirements and the continued increase in the costs associated with software maintenance. To meet these challenges, software development must be able to cope with complexity and to adapt quickly to changes. If new software products are each time to be developed from scratch, these goals cannot be achieved. The key to the solution to this problem is reusability. From this perspective Component-based Development (CBD) appears to be the right approach. In CBD software systems are built by assembling components already developed and prepared for integration. CBD has many advantages. These include more effective management of complexity, reduced time to market, increased productivity, improved quality, a greater degree of consistency, and a wider range of usability[1]. However, there are several disadvantages and risks in using CBD which can jeopardise its success. - Time and effort required for development of components. Among the factors which can discourage the development of reusable components is the increased time and effort required, the building of a reusable unit requires three to five times the effort required to develop a unit for one specific purpose. (B. Spencer, Microsoft, Presentation at 22nd ICSE, 1999, also an interesting observation about efficient reuse of real-time components, made by engineers at Siemens [2] that, as a rule of thumb, the overhead cost of developing a reusable component, including design plus documentation, is recovered after the fifth reuse. Similar experience at ABB [3] shows that reusable components are exposed to changes more often than non-reusable parts of software at the beginning of their lives, until they reach a stable state.)