Fortunately, there exists good work elsewhere on the topic of introducing
change, and that can be applied equally successfully to DSM introduction.
When thinking about deploying your DSM solution, take the time to sit down with
two people. First, you need someone from your IT department, who has been responsible
for rolling out new technology. If you look how much time and energy goes
into something as simple in theory as updating Windows, you should get an understanding
that deploying DSM is more than just putting a tool license on everyone??™s
desk and the metamodel on a ?¬?le server. Of course, Windows is an unfair example:
most of the work there is checking all possible applications for compatibility with
the new version. This is not a problem in DSM: the results of DSM??”the source
code??”will look the same as previous source code and run on exactly the same
platform. Instead, the change is more like moving from writing documents in LaTeX
to writing them in a word processor, or from writing HTML in a text editor to creating
it with FrontPage. You are moving from a textual language to a new tool with its own
graphical user interface ???language.??? The IT department will understand the issues of
tool deployment and training related to the new tool, language, and process, and you
can learn a lot from them.
Pages:
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657