For the tool itself, ?¬?rst look what the tool provider offers in terms of user
documentation. All but the most primitive DSM environments and frameworks
should have abstracted tool behavior from issues relating to individual modeling
languages, so the tool??™s functions and behavior can be described once for all modeling
languages. In addition, it is also useful if you can provide some initial documentation
that describes things in terms of your modeling language. This can help make things
more concrete and reduce the danger of new users feeling unsure about which
metalevel they are on. Something that has worked well in our experience is to provide
step-by-step instructions to building a simple model, just a little more than ???Hello
world.??? Outlining a second task, without the step-by-step instructions, is a good way
to nudge users onward from rote repetition to actually learning and understanding how
to do things themselves.
Simply providing people with a tool, a language, and documentation goes a long
way to helping most of them become productive in the new environment. Different
people, however, learn in different ways, and for some the best way is a more formal
training session. A disproportionately large number of software developers learn best
by reading, but DSM also opens the doors to people who have not traditionally been
perceived as developers.
Pages:
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667