Building a DSM solution requires a similar
mindset as it offers a way to ?¬?nd a balance between writing the code manually and
generating it. How the actual decision is made differs between application domains.
In Part III, we describe ?¬?ve DSM cases where the partitioning is done in various
ways, and in Part IV, we give guidelines on how you can do it.
18 INTRODUCTION
Using resources to build a DSM solution implies that development work is
conducted over a longer period within the same domain. DSM is therefore a less
likely option for companies that are working in short term projects without knowing
which kind of application domain the next customer has. Similarly, it is less suitable
for generalist consultancy companies and for those having their core competence in
a particular programming language rather than a problem domain.
Although the time to implement a DSM solution can be short, from a few weeks
to months, the expected time to bene?¬?t from it can decrease the investment interest.
The longer a company can predict to be working in the same domain, the more
likely it will be interested in developing a DSM solution. Some typical cases for
DSM are companies having a product line, making similar kinds of products, or
building applications on top of a common library or platform. For product lines, a
typical case of using domain-speci?¬?c languages (e.
Pages:
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55