The Model Driven Software Network
Raise your level of abstraction
Can MDD use an agile approach ?
I looked this morning at all the answer on the topic "Is regeneration from the model every time the only realistic way to get major benefits of MDD ? "
It seems to me there is a large majority of the Model Driven Network members thinks that Model should drive the code generation and that all iterations should be made at model and not code level.
What is Agile software development ? I would say it is a methodology for project management process with frequent inspection and adaptation. The goal is rapid delivery of software in which business and customers needs approaches are aligned with IT. The recommended way to use agile is to promote development iterations, teamwork, collaboration and adaptability throughout the entire project development life-cycle.
The dilemma is: Delivering a project requires teamwork and collaboration between Architects, modelers and developers. I don't think that we can produce software without developers. Developers should not work at model level, and should not also just work at code level. I think that developers can model in order to write their code because this is a lot more productive. If developers models it seems to me they need live code and model synchronization and not only MDD.
If Model should drive the code generation and that iterations should be made at model then is-it possible to use MDD and agile approach together ?
I think that just considering model iteration is too restrictive but .........
My today's question is: Can MDD use an agile approach ?
It seems to me there is a large majority of the Model Driven Network members thinks that Model should drive the code generation and that all iterations should be made at model and not code level.
What is Agile software development ? I would say it is a methodology for project management process with frequent inspection and adaptation. The goal is rapid delivery of software in which business and customers needs approaches are aligned with IT. The recommended way to use agile is to promote development iterations, teamwork, collaboration and adaptability throughout the entire project development life-cycle.
The dilemma is: Delivering a project requires teamwork and collaboration between Architects, modelers and developers. I don't think that we can produce software without developers. Developers should not work at model level, and should not also just work at code level. I think that developers can model in order to write their code because this is a lot more productive. If developers models it seems to me they need live code and model synchronization and not only MDD.
If Model should drive the code generation and that iterations should be made at model then is-it possible to use MDD and agile approach together ?
I think that just considering model iteration is too restrictive but .........
My today's question is: Can MDD use an agile approach ?
Replies to This Discussion
-
Permalink Reply by Rui Curado on -
No problem for me in using ABSE (my own variation of MDSD) in an iterative setup. In fact, architects and developers can work concurrently on the same model. It is just like source code, but working at the model level:
- There is only one working model in a database
- There is a repository of templates (the reusable assets)
- A library is selected into the project.
- Developers can start building the model using the loaded reusable assets
- Developers and/or architects can selectively check-in/check-out parts of the working model
- If a reusable asset is not good enough/buggy/limited, the developers can ask architects to fix it.
- Project management, workflows, issue tracking, building and packaging can be done using the model itself (hence the "E" in ABSE for "engineering" and not a "D" for "Development")
- Model versioning is possible, having each atom its own version.
Unfortunately I've just received the news from the CG2009 committee that ABSE was not selected to be presented at the conference, so I guess you'll not learn more about it so soon.
But my today's answer is : Yes, MDD can use an agile approach.
-
Permalink Reply by Vlad VARNICA on -
Hi Rui,
It seems that your project is very interesting.
Keep going the good job :-)
-
Permalink Reply by Rui Curado on
-
Thanks Vlad!
I'll report back about ABSE here on the community when it is ready for "consumption".
-
Permalink Reply by Sean Kavanagh on -
I think you need to clarify the role of modeller vs. developer. When using Shlaer-Mellor OOA/RD or Executable UML the modeller creates models and Action Language code which must be fully executable (and can be run prior to archetype templates being finished). A developer creates archetype templates to generate the final deployment code. However, both roles overlap and both can follow an agile approach to deliver an application. So my answer to the question is yes if you are using an executable modelling language/toolset.
If you are using plain UML then the answer is probably yes early on but no later, once the gap between models and code diverges enough that changes in a model can't be quickly replicated in the code and changes in the code can't be quickly abstracted back into the model. Most projects which attempt to follow an agile approach using plain UML will at some point make the decision to leave the models behind, at which time they should no longer be claiming to be an MDD project.
-
Permalink Reply by Chris Reynolds on -
I think Sean has it right.
MDD can be agile if-and-only-if the model and code are in sync and a model iteration is straight forward and under the control of the developers.
In fact having just been through a go-live where several requirements surfaced after release (again), I would suggest that in certain circumstances MDD can be very agile.
-
Permalink Reply by Jon Hurwitz on -
I would also say yes, but it strikes me that perhaps the roles of developer vs modeller don't so much need clarifying as muddying! Why not have a modeller-developer akin the the analyst-programmer role? I think the project manager has to be pragmatic and we need not to be too prescriptive about how the tasks are fulfilled or the job title of the person who fulfils them. The split in roles for small agile developments need not mirror the roles for huge infrastructure projects.
However, that doesn't mean that if delevelopers model they need to synchronise the model to the code. On the contrary, if developers can also change the model they are in a perfect position to drive the iteration from the model.
-
Permalink Reply by Rui Curado on
-
"Why not have a modeller-developer akin the the analyst-programmer role? I think the project manager has to be pragmatic and we need not to be too prescriptive about how the tasks are fulfilled or the job title of the person who fulfils them."
Agreed. However some organizations might want to clearly separate roles. Geographically dispersed teams come to mind (in a sub-contracting setup).
-
Permalink Reply by Jon Hurwitz on
-
"However some organizations might want to clearly separate roles. Geographically dispersed teams come to mind (in a sub-contracting setup)."
True. But if the project manager is forced to adopt some strategy because of corporate policy and that makes agile development tougher, let's place the responsibility where it lies and not put it on the back of MDD. I don't think I'd attempt an agile approach with geographically dispersed sub-contractors. (Actually, having tried it once, I don't think I'd ever again take on a geographically distant sub-contractor for any kind of development work, agile or not.)
-
Permalink Reply by Sean Kavanagh on
-
Everyone should be able to model and program in an agile MDD development team allowing new requirements to be modelled and coded by the same person. Roles within such a team should be subject matter based with individuals and/or groups allocated to subject matter Domains (a Shlaer-Mellor concept), e.g. the application proper, user interface, network management, software architecture etc.
Unfortunately, UML does not provide an adequate framework for partitioning a system into subject matter Domains. UML has evolved from an elaborative mindset rather than a translative mindset. Stephen Mellor's attempt to promote Shlaer-Mellor Recursive Design concepts as MDA within the OMG has not been entirely successful in my opinion. UML packages and dependencies is not a adequate alternative to Shlaer-Mellor domains and bridges, i.e. a dependency with a <<bridge>> stereotype can not hope to separate two <<domain>> packages without one or both of the packages becoming heavily polluted by the other. The result being that a UML development team will probably still be partitioned into modellers and developers making an agile MDD approach more difficult.
-
Permalink Reply by Jon Hurwitz on
-
Just because UML doesn't properly support your preferred team split, why should that mean the team will probably be split into modellers and developers? Aren't there many more ways to skin the cat?
I don't know Shlaer-Mellor. If you separate out subject matter domains, do you get problems with knowlege silos?
-
Permalink Reply by Sean Kavanagh on
-
If you can't easily split a whole team into subject-matter roles, most managers will end up allocating some people into process oriented roles and will be quick to identify modelling as one of those roles. Especially since UML modelling has become an increasingly complex skill to perform well.
Since each domain will be modelled, the team as a whole should have regular opportunities to review the other domains that will used in the project. Knowledge will pool around those tasked with capturing that knowledge. However, the benefits should outweigh the risks here.
About
Badge
© 2010 Created by Mark Dalgarno on Ning. Create a Ning Network!
