This
pressure mostly can and should be resisted if the variations are small. If a group has a
clearly different domain, this may require either a newmodeling language in the same
DSM solution, or a new DSM solution entirely.
As individual projects move through their own life cycles, there will also be phases
when they are unwilling to adopt new versions of the DSM solution, for fear of
introducing unexpected changes or bugs. To some extent this is justi?¬?ed, although the
risks must be re-evaluated compared to code-based development. Clearly, nobody
would want signi?¬?cant changes to many pieces of code shortly before a release, and in
a way a change to the generator produces that. However, the real danger is not in the
number of changed lines of code, but in the number of places where a person might
make a mistake. In the code-based world, this would be directly proportional to the
number of changed lines. With DSM, the level of risk is measured largely by
the number of lines changed in the generator. If changing that number of lines would
be acceptable in manual coding at the current stage of the project, the generator
change should also be acceptable.
Another possible comparison would be with upgrading to a new version of a
compiler at a late stage of a project. This provides a better match with DSM upgrades,
but there are still some important differences.
Pages:
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670