Sometimes this means a wholesale
change to different tools, languages, or processes, and that may mark the end of a good
DSMproject. Given the all too common alternative way of asserting authority??”?¬?ring
large numbers of people??”this is perhaps the lesser of two evils.
In all of these cases, our suggestion would be to make a good end of it. If the change
is inevitable, there is nothing sacred about a particular DSM solution. Fight bad ideas
by all means, and make sure those in charge understand the productivity bene?¬?ts of
DSM, but look at the situation with a healthy dose of realism. If the use of this DSM
solution is going to stop, it is time to wrap up the loose ends. Although there will
obviously be limited resources for this task, make the most of what you have.
Make sure that the ?¬?nal versions of theDSMsolution components are recorded and
that the components themselves are stored. The models themselves are assumed to be
under good version control and so should present no extra problems. If your tool
support is based on a framework that is tightly integrated with an IDE, or for other
reasons may later be challenging to reconstruct, it may be a good idea to make a disk
image or a virtual machine containing a working environment. Should it later be
necessary to resurrect the DSM environment, for example, to allow some ?¬?nal bug
?¬?xes to a released product, this will allow those changes to be made much faster and
with more certainty that no unintended differences are introduced.
Pages:
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675