Sooner or later the domain changes and software must be modi?¬?ed or updated. This
requires similar domain knowledge and expertise to the initial creation of the DSM
solution. The changes are easier and faster to implement if knowledge of the DSM
solution is already available and the tooling allows incremental changes. The persons
maintaining the existing DSM solution, however, may be different from those who
originally created it. In many cases, this is natural since aDSMsolution can be applied
over several decades.We describe the various roles in DSM creation in more detail in
Section 4.6.1.
Although the creation of aDSMsolution is often kept in-house, the situation with
DSM use can be different. Since the complexity can be hidden, the development
tasks supported by a DSM solution can be outsourced more easily and the potential
group of developers is bigger. DSM can also make the outsourced development
efforts more measurable and comparable since they are based on the same
abstractions??”those created by the company outsourcing.We should note here that a
shared DSM solution cannot be changed separately by each of the companies using
it. Actually, very seldom do companies want to share their languages and generators.
The reason is simple. Your DSM solution shows more than the source code: It shows
how you make the applications and what kind of automation you apply.
Pages:
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85