Escolar Documentos
Profissional Documentos
Cultura Documentos
3.1.1
The user
This is the final component of a generic DSS that influences the way a final decision is reached. Differences exist in users cognitive preferences and abilities and the way they arrive at a decision. The user is also known as the manager or decision-maker. Knowing who will use the DSS is important in the designing of it. Individuals can use a DSS for personal support, or they can individually use a DSS or a portion of a DSS in organisational or group support. A new dimension, namely how a group works together is introduced when decisions need to be made collectively. This complicated type of DSS is called a group DSS (GDSS).
3.1.2
When a problem is non-routine and not structured, the DSS needs to be custom-made for the organisation. When similar functional problems exist in different organisations, a generic DSS can be built with the option of some modifications. Such a DSS is called a ready-made DSS. Most DSS are custom-made though.
3.1.3
Sprague & Carlson (1982) identified three levels of DSS technology: specific DSS (SDSS), DSS generators and DSS tools (also referenced by Turban 1995). DSS tools are used to construct DSS generators, which in turn are used to construct SDSS. The DSS tools may also be used to construct tools that are more complicated. Using a DSS generator saves time and money, making the DSS financially feasible.
32
DSS generators
A generator is an integrated package of software that provides a set of capabilities to build a specific DSS quickly, inexpensively and easily (Turban 1995). A DSS generator is an integrated easy-to-use package with diverse capabilities ranging from modelling, report generation, graphical presentation to performing risk analysis. The ideal DSS generator may be a special-purpose language. The specialpurpose language may be used to build a DSS application easily or as an integrated software system constructed around spreadsheet technology.
DSS tools
This is lowest level also called the fundamental level of DSS technology and consists of software utilities or tools. These elements facilitate the development of a DSS generator or a SDSS. Examples include graphics, editors, query systems, random number generators and spreadsheets: elements used to build both SDSS and DSS generators. A specific DSS may be built directly from tools. DSS generators promise to create a platform from which SDSS can constantly be developed without much consumption of time and effort (Sprague & Carlson 1982).
3.1.4
According to Mallach (1994), one should consider the following before starting to design a DSS:
33
Figure 3-1
34
The DSS generator should have three general capabilities (Sprague & Carlson 1982):
3.1.6
A classical DSS development process, including all activities necessary for the construction of a complex DSS, is given in Figure 3-1 (p34). As mentioned earlier, the iterative design process seems to be a better alternative because of the flexibility as well as the short development cycle needed by decisions and decision-makers (Sprague & Carlson 1982). A prototyping process often clears misconceptions between builders and end-users. Mutual learning occurs as the DSS develops. Prototyping provides the following advantages (Turban 1995): Short development time Short user reaction time (feedback from the user) Improved users understanding of the system, its information needs and its capabilities, and Low cost
3.1.7
When end-users are allowed to modify a SDSS to suit their decision needs or the decision needs of the group that they represent, it is better to follow a construction process from the end-users point of view. A suitable construction process developed from an end-users point of view is given by Turban (1995): Phase one Choosing the project or problem to be solved: committed to the process of finding a suitable solution Phase two Selecting software and hardware: Select suitable DSS software and hardware Phase three Data acquisition and management: Acquire and maintain data in the knowledge base Phase four Model subsystem acquisition and management: Build the model base: acquire and include relevant models in the model base Phase five Dialogue subsystem and its management: Develop the user interface Departments involved are
35
Figure 3-2
36
Before starting an ES project many factors should be studied such as the main goal of the system; its constraints; its available support facilities; availability of human experts; user-imposed reliability; maintainability; solution needs; and application needs. Updating and maintaining the knowledge base and enhancing the capability of the inference engine are central to a successful ES (Raggad & Gargano 1999). When the ES is used, the effectiveness of the ES should be continually evaluated and monitored to test if the problem domain has not changed. If the problem domain changes, it can invalidate the recommendations given by the ES. This last aspect will be explored in more detail in the section on knowledge validations (See Paragraph 7.2.1: p130).
3.3
Building a KB-DSS
Building a KB-DSS involves the capabilities, functionality and structures of both DSS and ES with the emphasis on the support of DSS. Factors discussed in Paragraphs 3.1 (p32), 5.5 (p101), 6.3 (p121) and 6.4 (p122) are of relevance. Klein & Methlie (1995) propose a methodology for the KB-DSS implementation process in Figure 3-3 (p40). This design methodology is related to the learning process of users and supports flexible design strategies. It presents the essential characteristics and allows the designer to use and combine a variety of design strategies. It is possible for the user to start with the models, the database, the knowledge base, or by defining the application with displays of results. Klein & Methlie (1995) suggest starting with the user interface and the global logic of the application and its associated variables, adding the other sources as the designer wishes as a function of the application. The methodology for Klein & Methlies (1995) KB-DSS implementation process includes: Understanding the users goals The usual user goals are to Recognise a problem situation Diagnose a problem Generate alternatives Compute criteria Evaluate alternatives, and Select one alternative These goals can more generally be to improve the way the problem is presently solved or facilitate communication between individuals to ease the reaching of a solution. Understanding and defining the problem boundaries Understanding and defining the problem boundaries will identify: The decision-makers The relationship of the decision-maker with the decision structure of the organisation The fixed and controlled decision boundaries as accepted and challenged by the decisionmaker
37
Define a normative decision process for the problem The task of the designer is to analyse the decision processes, make a diagnosis and define an improved process. Defining changes in the decision process Many users will use the KB-DSS. The adoption of a DSS is a social process. Therefore, all the users should assimilate the decision process improvement. Selecting which part of the decision process to support The starting environment of the user should be defined. Functional analysis of the KB-DSS The purpose of this step is to define the main functions and overall architecture or conceptual model of the KB-DSS. Usually a first list of reports, decision models, data structures, input forms and knowledge bases are needed. A first layout of the application user interface should be defined to demonstrate the resources to be used during the problem solving process.
38
39
Figure 3-3
Methodology for the KB-DSS implementation process (Klein & Methlie 1995)
40