Model driven development (MDD) primarily focuses on developing conceptual models during the Software Development Lifecycle with a secondary emphasis on the code by “shifting from programming to the creation of models and transformations between them” ({xbref tag="0" title="Shin, 2019" desctext="Shin, S.-S., 2019. Empirical study on the effectiveness and efficiency of model-driven architecture techniques. Software & Systems Modeling 18, 3083–3096. https://doi.org/10.1007/s10270-018-00711-y" }Shin¹⁵{/xbref}, 2019).

Agile focuses on project delivery practises and techniques which manage the effects of change during a project by focusing on the people, communication, collaboration, feedback and working software ({xbref tag="0" title="Cockburn et al, 2001" desctext="Cockburn, A., Highsmith, J., 2001. Agile software development, the people factor. Computer 34, 131–133. https://doi.org/10.1109/2.963450" }Cockburn et al, 2001¹⁵{/xbref}).

MDD and agile are both concerned about the successful delivery of artefacts during the SDLC.

Incorporating the benefits of agile, which focuses on managing project delivery in the face of change, has been shown to be successful in projects focused on developing models as their primary artefact - where the various agile principles and methodologies have been mapped to their MDD counterparts such as Continuous modelling to Continuous Integration, Test-Driven Modelling to Test Driven Development, Automated batch mode simulation to Automated test regression and other related activities . ({xbref tag="0" title="Zhang, 2001" desctext="Yuefeng Zhang, Patel, S., 2011. Agile Model-Driven Development in Practice. IEEE Software 28, 84–91. https://doi.org/10.1109/MS.2010.85" }Zhang, 2001¹⁵{/xbref})

Among other benefits of agile, is its focus on feedback and collaboration which “reduces the cost of moving information between people” and helps reduce the elapsed time between making a decision to seeing the consequences of that decision” (Cockburn et al, 2001¹⁵)  – which can only help make development teams more efficient and models more effective.

MDD and in particular, The Unified Modelling Language (UML) have been shown to be effective in contributing to requirement elicitation, producing “well-defined semantics and an elegant graphic syntax for expressing rich business requirements” (Shin¹⁵, 2019).

Furthermore, MDD focuses on design abstractions which helps, “alleviating the complexity of platforms and express domain concepts effectively” {xbref tag="0" title="Schmidt, 2006" desctext="C. Schmidt, 'Guest Editor's Introduction: Model-Driven Engineering,' in Computer, vol. 39, no. 2, pp. 25-31, Feb. 2006, doi: 10.1109/MC.2006.58. https://ieeexplore-ieee-org.libezproxy.open.ac.uk/document/1597083" }(Schmidt, 2006)¹⁵{/xbref}, contributing to both the design and analysis phases of the SDLC.

However, one study has shown it less effectiveness in transforming these model to accurate code representations, in particular MDD’s “round-trip engineering” phase which is the synchronization of code and models, “was not perceived as effective or efficient” by the study (Shin¹⁵, 2019) and echoes much earlier concerns raised by Schmidt and Ambler in prior years.

That prior study also highlighted the difficulty of defining Object Constraint Language (OCL) expressions, even within relatively simple scenarios and how Query/View/Transformation (QVT) is a relatively complex specification, contributing to perhaps its perceived effectiveness.

Cockburn et al, advocates that agile development “excels in exploratory problem domains” and “high-change environments” and as such the analysis phase is an incremental iterative and dynamic endeavour which might not be “suited for everyone” suggesting there are limitations.

Research has shown that introducing new people “increased defects in new ASD teams” (Agile Software Development) and conversely when they move away, “Lack of knowledge retention” is an increased risk.

This research also identified the accumulation of “technical debt” which is the result from compromises made by technical teams where the “pressure of delivering in short time-boxed iterations cycles made them take short cuts to speed up delivery.  ({xbref tag="0" title="Elbanna et al, 2006" desctext="Elbanna, A., Sarker, S., 2016. The Risks of Agile Software Development: Learning from Adopters. IEEE Software 33, 72–79. https://doi.org/10.1109/MS.2015.150" }Elbanna et al, 2006¹⁵{/xbref})

Both ideas rely on incorporating the problem space into the correct design for working software.