There seems to be no rational explanation for this; perhaps the main factor is to be
found not from the ?¬?eld or tools themselves, but the mindset of the people who make
them. Anyone who tries to de?¬?ne how others should build systems must be something
of a control freak. Anyone who tries to de?¬?ne how such control freaks should de?¬?ne
their modeling languages must be even more, ah, sure of themselves.
Looking back over the various tools clearly shows that later tools are by no means
better than their earlier counterparts. Although there have been slight differences in
emphasis, all have been attempting to solve the same problem. It thus seems useful to
offer a potted history of the tools, their emphases, and how they fared. Particularly
interesting in the context of DSMis whether the tools could be used by someone other
than their creators.
14.2.1 1970s and 1980s
In the 1970s and 1980s, the search for a solution to the ???software crisis??? (Brooks,
1982) was focused in three directions:
. analysis of the whole process and concepts involved in building information
systems (e.g., Chen, 1976; Brooks, 1982),
. application of more rigor in the early stages of projects by following explicit
methods??”modeling languages and associated processes (e.g., Gane and
Sarson, 1979),
. documentation of the development of systems, often using computers??”an idea
going back as far as the early 1970s (Bubenko et al.
Pages:
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683