Preliminary Results CBSE State of Practice and Experience Survey

2 Budapest April 3-4 Component-Based Software Engineering Workshop Why a State of the Practice Survey? CBSE landscape State of the practice Future challenges Survey Workshops Partners experience

3 Budapest April 3-4 Component-Based Software Engineering Workshop Trends Over a 5 Years Period , ,2005 Paul Allen. Component Based Development Strategies. Monthly newsletter from Cutter Information Corp. Vol XI, No 11 and 12.

4 Budapest April 3-4 Component-Based Software Engineering Workshop Sample Characteristics n So far 100 organisations n 125 to 150 expected n European results mainly Europe 71% North America 17% South America 3% Asia 8% Oceania 1%

5 Budapest April 3-4 Component-Based Software Engineering Workshop Sample Characteristics n SMEs well represented

6 Budapest April 3-4 Component-Based Software Engineering Workshop Representative Domains

7 Budapest April 3-4 Component-Based Software Engineering Workshop They are not Newcomers More than 5 years 39% 1-2 years 20% 3-4 years 36% Less than 1 year 5%

8 Budapest April 3-4 Component-Based Software Engineering Workshop Roles

9 Budapest April 3-4 Component-Based Software Engineering Workshop Component Models

10 Budapest April 3-4 Component-Based Software Engineering Workshop Why and How n Business goals n What kind of project are using components? n Inhibitors

11 Budapest April 3-4 Component-Based Software Engineering Workshop Goals

12 Budapest April 3-4 Component-Based Software Engineering Workshop Which Projects are Using Components? 32% 5% 29% 33% 2% 23% 45% 21% 11% 42% 18% 21% 0% 20% 40% 60% 80% 100% 120% R&D ExperimentationPilot ProjectsSelected Key projectsAll projectsOther 3rd 2nd 1st

13 Budapest April 3-4 Component-Based Software Engineering Workshop Inhibitors to the Use of Components

14 Budapest April 3-4 Component-Based Software Engineering Workshop Managerial and Technical Perspectives Managerial 35% Technical 65%

15 Budapest April 3-4 Component-Based Software Engineering Workshop Inhibitors from Managerial and Technical Perspectives 12% 7% 10% 3% 10% 17% 14% 4% 19% 12% 8% 6% 10% 9% 11% 9% 12% 4% 0%5%10%15%20%25% No training in how to practice the use of components Not willing to follow standard development processes or software product standard Cross departmental political barriers Lack of effective software metrics No component library “Not invented here” (NIH) syndrome Quality of components is questionable Not enough components available Lack of management support Other Technical Managerial

16 Budapest April 3-4 Component-Based Software Engineering Workshop Components Accounting 49% 28% 13% 10% 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% Accounting on the basis of component as a cost OtherManagament open to asset-based accounting Components as an asset

17 Budapest April 3-4 Component-Based Software Engineering Workshop Some Preliminary Conclusions n Immature field but widely spread also among SMEs l Quality of components questionable (managerial perspective) n The use of components is not considered an investment l Lack of training (technical perspective) n Less development from scratch (development role) n Web services seem to experiment an increase in the future

18 Budapest April 3-4 Component-Based Software Engineering Workshop For additional information n Pedro Gutierrez n Marisa Escalante n Or check the following addresses: www5.esi.es/cbse/ [on-line questionnaire]

19 Budapest April 3-4 Component-Based Software Engineering Workshop COTS Challenges n Identification, classification and characterisation The difficulties to find suitable COTS in the marketplace; to characterise COTS so that enough information is collected to evaluate COTS; and to classify those COTS in a way that makes selection easier. n Processes and methods The need to have a defined process to manage and execute COTS-based development projects. These projects involve a new manner of developing software systems, with different ways of working at business and technical level n Legal issues the contractual aspects of COTS acquisition. This includes aspects like: which laws apply to COTS, which laws protect COTS users from problems related to COTS products and COTS vendors, how to manage the impact that the COTS contracts and licenses have on the system sales, system maintenance, etc.

20 Budapest April 3-4 Component-Based Software Engineering Workshop COTS Challenges n Cost analysis The evaluation of the economic feasibility of using a certain COTS against other options (subcontracting, developing in-house). These aspects include how to estimate the cost of the system to be developed taking into account: COTS price, evaluation effort, adaptation and integration effort, training, upgrades and maintenance effort; how to estimate the cost of the changes once the system is running, etc. n Change management Managing and controlling the different types of change that may happen in COTS-based development projects: changes to requirements, changes in technology, COTS versions, cultural change caused by the new way of working and roles, etc.

21 Budapest April 3-4 Component-Based Software Engineering Workshop COTS Recommendations ChallengeRecommendation Identification, classification and characterisation Additional support beyond vendors specific identification schemes Processes and methodsResearch There is, but without impacting results Legal issuesRegulation and early impact analysis Cost analysisResearch Change managementDiffusion of existing experience

22 Budapest April 3-4 Component-Based Software Engineering Workshop Legacy Systems n Most of them started as a COTS n COTS you are buying now will become legacy … what are you going to do? n How to integrate COTS with existing legacy systems?

23 Budapest April 3-4 Component-Based Software Engineering Workshop Legacy Systems Questions are asked relative to the difficulties to integrate COTS products into a legacy system because of the system structure imposes more sensible requirements. This project reveals one of the most common problems faced by the COTS user during the integration of COTS within a legacy system that is, the system incapacity to interact with other COTS products. On the other hand, the answers to the question Do you think the introduction of the COTS products can really extend the life of an application was more affirmatives and agreed that a legacy system can be life extended only if the legacy system is well- defined and well-known. Like many other terms in computing, the meaning of term “legacy system” may vary considerably with the context. The classical use of the term often refers to a “less than adequate long-standing system that nevertheless continues to be used”. However, the term has also been used to generally refer to “existing systems”. Using the former definition it is clear that existing systems are not necessarily legacy.

24 Budapest April 3-4 Component-Based Software Engineering Workshop Legacy Systems

25 Budapest April 3-4 Component-Based Software Engineering Workshop COTS and Legacy Systems Additional challenges you consider relevant Prioritisation of challenges Are all of them equally relevant? Recommendations. What are your recommendations for each challenge? Legacy Systems. COTS and legacy integration problems. BIG COTS become legacy in the end.