Perhaps the best way to analyze quality
is to compare the number of errors in the ?¬?nished product. If errors can be decreased
with DSM, we can expect that the quality should be better too. However, often
companies don??™t have the time and resources to conduct carefully planned
comparisons as these need to be objective, have representative applications or
features, and aim for complete data collection. Instead the changes in quality are based
on observations made while conducting individual design tasks and on gut feelings.
For example, in a company specifying insurance products (described in Chapter 6)
with DSM, the CTO recognized fewer errors but could not measure exactly the
reduction ratio. Similarly at EADS (MetaCase, 2006), the Chief Engineer stated that
with DSM ???the quality of the generated code is clearly better, simply because the
modeling language was designed to ?¬?t our terminal architecture. If applications
were coded by hand there would be a lot of errors and the range of error types would be
wider.???
While the studies performed in-house are not usually available, academic studies
could help. Unfortunately, there is a lack of research examining quality in?¬‚uences
QUALITY 27
when moving to DSM. The USAF study reported by Kieburtz et al. (1996) is a
welcome exception: It also compared the reliability of the software built.
Pages:
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72