Implement Review
3.10 Application of the strategy to the Tanzanian study
3.10.1 DSS extrapolation and uptake
During the development of the Tanzanian DSS it was necessary to be aware of how the system would be instigated within the study regions and who would be the end users. With this in mind, research had to be carried out to help understand why some agricultural DSSs are poorly adopted, and to find ways to ensure that the Tanzanian DSS would be adopted and utilised.
The understanding of scepticism towards computerised management tools is fundamental. The following table (3.6), adapted from Matthews and Stephens (2002) illustrates the reasons why models and DSSs are often dismissed as management tools.
Reasons for poor adoption of Decision Support Systems
• Unclear definition of clients/end users
• No end-user input prior to or during the development of DSS
• DSS does not solve the problems that the client is experiencing
• DSS does not match their decision making style
• Producers do not trust the output due to lack of understanding of the underlying theories of the models utilised
• Producers see no reason to change current management practices
• DSS does not provide benefit over current decision making system
• Limited computer ownership amongst producers
• Lack of field testing
• Cannot access the necessary data inputs
• Lack of technical support
• Lack of training
Table 3.6: Reasons for poor adoption of Decision Support Systems (Matthews and Stephens, 2002)
These points need to be overcome to help ensure the DSS that is produced is successful. Matthews (2002) details seven requirements for the production of successful DSS packages. These are outlined below in Table 3.7.
Requirements for successful DSS packages
1. Address real problems (often complex) not readily solved by rule of thumb (e.g. pest management and irrigation scheduling require decision making on issues that vary from one season to the next. The cost of making a mistake is high and therefore use of DSS may be worthwhile).
2. Address problems that will be costly if the decision is not made correctly.
3. Must be easy to use and output easily understood.
4. Must be targeted at the client.
5. Must not require an experienced computer programmer to operate, or must be part of a system where the operator works as a consultant passing on the relevant outputs in a useable manner.
6. Must be introduced to the client with a thorough training package and continued support.
7. Need to be maintained and updated with changing technology and in response to user demand.
Table 3.7: Requirements for successful Decision Support Systems (Matthews, 2002)
The fundamental parts of developing any computer system are:
1. Have clear objectives from the onset
2. A suitable communication strategy between system developers and the end users
3. A close affinity with the end users to ensure the system that is being developed answers the proposed problem
The DSS was completed and subsequently disseminated to the team in Tanzania where the extension officers have had access to its capabilities and processing. On attaining feedback on the system, further developments and enhancements can be made. Reviews and checks on the system should be carried out also. It was also important to specify to the end users that the Tanzanian DSS only extrapolates potential management options. There is still an element of risk with the application of the specified allocation of resource that is obtained from the DSS, as with any biological system, it is difficult to fully predict its functionality and lifecycle.
3.11 Summary
A sound framework and approach for tackling the development of DSSs is of utmost importance for ensuring a feasible solution to a stipulated objective is achieved.
Various development strategies are present in the literature (Marakas, 2000). This research has taken on board the various strategies outlined in this chapter and has shown how these can be combined to form a single strategy for the development of DSSs as outlined in Figure 3.11. The importance of this combining of strategies helps to give focus to the development of future management systems. Less time will be spent sifting through the numerous available strategies for DSS development, as it is possible to combine the various approaches to form a single strategy.
Anon (1988) sums up the decision stages – see Figure 3.2. This can be further re-iterated by the seven phases of system development as detailed by Taylor (2001), see Table 3.8 below.
The Phases of Decision Support System Development
1. Definition Phase: Precisely define the problem to be solved, its magnitude and who will work on it 2. Requirements Phase: Develop a detailed description of exactly what the development effort will produce. Gather all the relevant information and put it into a requirements document and get client agreement.
3. Evaluation Phase: Determine exactly how you will meet the requirement. What tools will you use?
How will you deploy your development team? Determine time and budget constraints.
4. Design Phase: Create a database model and the design a database and database application that satisfy the terms of the requirements document.
5. Implementation Phase: Build the application and maintain documentation of all processes during development.
6. Final Documentation and Testing Phase: Test the database and application thoroughly, trying out every conceivable input and condition. Primarily try and ‘break’ the system. Determine where the system falls over and document and review the issues.
7. Maintenance Phase: Fix any bugs that arose during testing. Provide updates and enhancements to the system on a rotational basis.
Table 3.8: The seven phases of decision support system development (Taylor, 2001)
There are various key points that should be observed in relation to this general approach. In the context of this project, the important aspects were related to design, analysis, feasibility and implementation. The following tables illustrate some of the questions that needed considering during the production of the Tanzanian DSS. These are general questions that can be used for many project scenarios.
Table 3.9 considers feasibility aspects of the project initiation.
Task Pointers
Determine scope and objectives
-What is the scope of the project?
-Who will be involved in the project?
-Produce a detailed plan for the approach to the project.
Examine existing systems -Gather information from reliable sources with respect to the project in hand.
-What are the functions of the project?
-Is any data involved and what are the frequencies and volumes.
-Evaluate the existing system.
Determine requirements -Analyse the objectives
-Are there any security or legal considerations to be made?
-What are the areas of the system that have the greatest opportunity for improvement?
Evaluate solutions -Consideration of the computer solution
-What packages or equipment are going to be used?
-Design alternatives
-Possible impacts on other systems Prepare development plan -Devise an approach
-Outline an implementation plan
Table 3.9: Feasibility questions and considerations when approaching a project.
Adapted from the Systems Development Cycle (Anon, 1988b)
Table 3.10 considers aspects of analysis in relation to existing products and future products.
Task Pointers
Scope and objectives -Define the requirement of the project in detail and identify issues and how they will be handled.
-Who will be involved?
Analyse existing systems -Gathering information about existing systems and determining their performance and identifying improvements.
Determine detailed requirements
-Analyse performance, functions and information requirements.
-Determine contingency requirements -Develop outline new
system
-Enhancement of systems using acquired information -Outline functions – inputs and outputs
-Select what equipment is to be used for the production of the package.
-Consideration of approach
Table 3.10: Analysis considerations for the production of computer systems. Adapted from The Systems Development Cycle (Anon, 1988b)
Table 3.11 illustrates some of the issues related to the design approach, in the context of this sort of project.
Task Pointers
Produce logical system design
-Cross-referencing between processes outlined in the analysis with those used within the design.
-Ensure progression of the development of the design Produce provisional
designs
-Form initial designs
-Test these against design criteria and check structure requirements.
-Performance estimation and refinement of design Design systems -Physical constraints and design objectives
-Considerations should be made into which systems and approaches should be used – for example what programming languages to implement.
Complete detailed design -Record the initial and final designs -Add justifications to the designs
Outline system test plan -With the final design it is necessary to test it and make amendments.
-Following testing it is possible to upgrade and improve the design.
Table 3.11: Design considerations related to the approach used to produce computer systems. Adapted from The Systems Development Cycle (Anon, 1988b)
Table 3.12 gives rise to implementation considerations – this is an aspect that had to be considered with respect to the production of the DSS.
Task Pointers Set up production
environment
-Installation of hardware, software and network.
-Creation of software environment -Conversion of package development -Conversion of data
Acceptance testing -Testing of the system
-Ensure those using the system understand its capabilities.
-Test the running of the program -Make relevant changes
Changeover -Transfer of system
-Acceptance of the final product by the end-user.
-Production of implementation report
Table 3.12: Implementation consideration for the uptake of newly developed computer systems. Adapted from The Systems Development Cycle (Anon, 1988b)
By having an awareness of these various considerations and factors that might influence the development of DSSs, it is possible to add focus to the DSS that is actually being developed. However it is ultimately the individual developers decision as to what approaches to apply for the development of the system that they are producing.
From the onset of the development of the Tanzanian DSS various frameworks for DSS production were available. It was possible to take the important elements of these frameworks to help develop the singular approach as expressed in this chapter.
Chapter Four