Transitioning from Code-Centric to Model-Driven Industrial Projects: Empirical Studies in Industry and Academia

Transitioning from Code-Centric to Model-Driven Industrial Projects: Empirical Studies in Industry and Academia

Miroslaw Staron
Copyright: © 2009 |Pages: 27
DOI: 10.4018/978-1-60566-006-6.ch010
OnDemand:
(Individual Chapters)
Available
$37.50
Current Special Offers
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

Introducing Model Driven Software Development (MDSD) into industrial projects is rarely done as a “green field” development. The usual path is to make a transition from code-centric (CC) development in existing projects into MDSD in a step-wise manner. Similarly to all other software development activities; software quality assurance needs to be adjusted to meet the new challenges arising when using models instead of the code for the mainstream development. In this chapter we present a set of empirical data on the issues related to transitioning from CC to MDSD projects in industry. First; we present results from a set of experiments evaluating how a domain specific notation affects the effectiveness and efficiency of reading techniques used for inspecting models. Second; we present a comparison of productivity increase when changing to MDSD projects from one of the large Swedish companies. Finally we present a short survey on the prioritization of products; projects; and resource metrics in MDSD projects.
Chapter Preview
Top

Background

Based on the roadmap for research on MDSD (France & Rumpe, 2007) it shows that MDSD is not yet a fully established technology and it will still evolve. Therefore, an issue could be raised whether it is mature enough to be adopted or whether it delivers on its promises. The main challenge in the industrial adoption of MDSD is that MDSD needs investments to be effective: the larger the investments, the larger the benefits. In large software projects and in large companies the adoption of MDSD is burdened with all the problems of immature technology (how to justify real expenses based on promises?) and organizational resistance (how do we know that the technology actually improves our way of working?). Herein lies a challenge – how to gradually build up the confidence that using models in a project can help to increase productivity (or quality, or ideally – both). As we are able to show in the case study at Ericsson in Section 3.3, in addition to investing in technology, the investments should also contain costs of coaching (making sure that modeling knowledge is in place), model migration, or gradual migration process.

Complete Chapter List

Search this Book:
Reset