Laserfiche WebLink
<br />e <br /> <br />e <br /> <br />e <br /> <br />.003052 <br /> <br />can be both highly effective and efficient for application of a very well-defined <br />and precisely determined domain. However, it takes great effort (and cost) <br />when the system needs to be applied to a different problem (e.g. new basin, <br />new policy. etc.) or when new functionality needs to be added, Another <br />shortcoming is that case-specific implementations cannot evolve over time and <br />adjust to the availability of new sources of data, newly available models or <br />simply new user requirements. Therefore. case specific systems score a "poor" <br />on both extensibility criteria. The modularity of case specific systems is rated <br />as "poor" because they are only ready for use after development is completed. <br />Little functionality becomes available during the development process, These <br />systems are moderately expensive to develop and very expensive to extend, <br /> <br />Generic/Model Centered approaches are not tied to a specific case and are <br />flexible in their application. The downside. however. is that this kind of system <br />often requires very specific data and specific formatting of data, Typically, <br />organizations which for some time have been engaged in monitoring their <br />water resource systems and have assembled a rich collection of data, may find <br />it difficult and expensive to use this data in a model-centered system. Likewise, <br />generic model centered systems are difficult to extend towards inclusion of <br />additional models whereas modification of models can be very difficult to <br />achieve, Generic models are often commercially available, which makes <br />development cost-effective. However, extensibility is moderate (state) to poor <br />(process) generating high extensibility costs, <br /> <br />This alternative has specific advantages in Ihat one has Ihe availability of <br />generic models while the input and output exercises have been tuned to the <br />specific application domain, This type of conceptual design has been applied <br />by many DSS developers, Dedicated DSS tend 10 be very efficient in their <br />coding and are characterized by high performance (speed), The disadvantage <br />of this approach is that embedded pre- and post-processors are often of a <br />dedicated nature. making it hard to apply the system to a slightly different <br />domain, such as a geographically different study location. Also, dedicated DSS <br />architectures are not "open" in that they are not data-centered. Thus, when new <br />data sources become available, the pre-processor may have 10 be rebuilt. <br />Likewise, when new models become available, resources must be spent on <br />redeveloping both the pre- and post processor pans of the system, Although <br />dedicated DSS architectures offer "moderate" opportunities for extensibility, <br />they are rated "poor" on modularity. The reason for this is that. like case- <br />specific systems, dedicated DSS are only ready for use after development is <br />completed, LillIe functionality becomes available during the development <br />process, Due to their "made-to-measure" character. dedicated DSS are very <br />fast and attractive to work with; their development and extensibility COSts. <br />however. are rather high, <br /> <br />Generic/Model <br />Centered Systems: <br />Evaluation <br /> <br />Dedicated Decision <br />Support Systems: <br />Evaluation <br /> <br />DAMES8,c MOOREICA DSWES-32 <br />