It was interesting to read the introduction chapter. Does the Mikado development address all areas of software development viz. Requirements, desing , development and delivery?
Or Is it just applicable predominantly to the "Design and Development" of software?
I take the liberty of answering your question. :-)
The Mikado Method is primarily to make code changes to existing systems, and it shines in situations where you have a lot of entangled dependencies to keep track of. We've mostly used it for just that when implementing new features, or just changed the way things work, as in refactorings/restructurings. This is what the book is about.
We have also used a Mikado-like dependency graph to keep track of things needed for e.g. deliveries, but this is not in the book.
We strongly believe that dependency graphs are good for making models of the world that help us understand how things are connected and to act upon that information. We encourage you to try the next time you have a problem. Software development, deliveries, refurnishing a room, or something completely different. :-)
Joined: Oct 10, 2011
Yes I like dependency graphs too. Along those lines, I've used one of the maven plugins that reports dependencies amongst modules and have found it useful. It
will tell us if discrepancies exist in the project modules etc. It's good to know that such a tool is part of Mikado!
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com