In AMDD, I have a question when we're modeling with a purpose suppose the design which we have created works well only in the initial stage of a project and falls apart over new requirements in later stage of a project and it will be too late to fix the design at this stage and there are some cases where requirements in later stage have a need to change original design. How do we handle such cases? Does it mean that we've to spend a lot of time up front for design and analysis which is against AMDD.
Anil, what do you mean with "too late to change the design"? I don't know very much about (A)MDD, but isn't the whole purpose of it that you can change the design at any time, and have it directly reflected in the system?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Oct 31, 2000
What I mean is, we have an existing system which has to enhance for new requirements so we came up with a design which would slightly impact earlier design which is in production so we got to modify old code to cater for new requirements that means old modules have to be tested again. Isn't this against agile modeling?
Joined: Jan 03, 2007
I can't speak much to model driven development, as I've never tried it in practice (and have some reservations about it in theory.)
I can say that the purpose of agile modeling is specifically about adapting to change. The whole point is to allow the existing design and code to accommodate new requirements. That doesn't mean old code will never be touched. Just the opposite in fact... it's about ensuring the the existing code and design can be modified with ease.
In my chapter "Adaptation", I discuss some issues around enterprise architecture that can make adaptation easier or harder. In particular, how you build interfaces that cross the system boundary can make a big impact on how easily you can upgrade your applications.
"Adaptation" operates under the assumption that change is good---a basis of all agile methods---so it shows how to make change as painless as possible.
Joined: Jul 11, 2001
Originally posted by Anil Vupputuri: What I mean is, we have an existing system which has to enhance for new requirements so we came up with a design which would slightly impact earlier design which is in production so we got to modify old code to cater for new requirements that means old modules have to be tested again. Isn't this against agile modeling?
Regarding testing, you are correct that you need to test the full system before every release. In fact Agile teams test much more often - at least once every day, selected tests much more often, up to every couple of minutes.
Of course that only works if most of your tests are fully automated and can be run at the press of a button (or even run fully automatically, for example triggered by a change in the code repository). Extensive suites of fully automated tests are an important prerequisite for every Agile approach to software development.