This following page presents a historic summary number of methodologies created specifically for use in the design and implementation of Geographic Information Systems. They were developed so that issues specific to GISs were formally addressed: issues that were not addressed in general software design models of the time.
The first design methodology specifically for GISs was presented in 1972 by Roger Tomlinson (See figure 2.01) (Calkins 1982, p, 92). The methodology follows a traditional, linear waterfall model structure. The steps are broken down into four stages, each proceeding in sequence. The four stages of the methodology are described below.
Stage one begins with an assessment of the vision and goals of the project. The second step of this stage defines the organization's functional needs and requirements followed by the identification of data needs. Stage one concludes with the definition of specifications for the objective system. The steps of stage one reflect the first three steps of the traditional waterfall model. A feedback mechanism is shown that returns the project back to the beginning. This feedback mechanism allows the specifications to be compared with the initial definitions of objectives and requirements.
Stage two is a departure from the traditional waterfall model. The steps in this stage identify the current situation of the organization. These include hardware and software resources and the culture and structure of the organization. These steps identify the resources and constraints of the GIS project.
Stage three involves the comparison of the system specification derived in stage one with the resources and constraints identified in stage two. Necessary modifications are made to the initial specification and a revised design of the system is derived. The implications of the system's implementation in the organization are assessed. A notable inclusion is step 24, which calls for the description of user education needs (See figure 2.01). This is an important step, which is often omitted. As exemplified by this model, consideration of the organizational context has been recognized as an essential component of GIS design and implementation from the beginnings of GIS-specific design methodologies.
The final stage, stage four, entails a final evaluation of the system. From this point, the project proceeds in one of three directions. The system can be implemented, if it is deemed satisfactory. The project can return to the first step of stage one to reassess the original requirements of the system. The other alternative path is to stage three, where an alternative system can be defined to meet the previously determined needs.
This methodology is straightforward and simple to follow. It has served as the starting point for the development of subsequent GIS design methodologies. However, this methodology contains certain characteristics that may lead to some of the problems.
In the initial definition of requirements, user involvement is not specified. This aspect of the methodology has led to a number of unsuccessful GIS design projects where requirements were not satisfactorily defined (Calkins 1982, p. 95). To obtain an adequate assessment of an organization's needs and requirements, representatives from all levels of the organization must be explicitly involved, users in particular.
A second problematic characteristic of this methodology is the placement of user education needs in a step toward the end of the design process. An organization cannot accurately assess its needs and requirements unless it has a knowledge of GIS concepts and capabilities. The education of all participating members of the organization must take place early in the process. Also, the diagram implies that users are regarded as outsiders to the process.
The feedback mechanisms in this methodology are important and necessary. Returning the process to the objectives and requirements definition is crucial to ensure that the project is on the right track. The feedback paths in this particular methodology can be improved upon, however. In this methodology, only the intangible specifications of the objective system are compared with the initial requirements; a physical product is not available. A tangible product gives users and other organization members an increased ability to assess the strengths of a system.
An issue related to the feedback mechanisms is the lack of a means for changing requirements if necessary. Often users will incrementally discover requirements during the process, particularly when they see a physical product. In this methodology, a change to the requirements would require repeating all of the steps from the beginning. Although this is possible, a great deal of time would be consumed. A feedback mechanism that allows for less time-consuming and disruptive requirements changes would be an improvement.
This methodology partially meets only two of the requirements: (1) an iterative feedback mechanism exists, however, it does not enable interaction with a tangible product; and (2) user education is specified, but not until step 24 toward the end of the process; participants may be inadequately educated during the early stages of the project. The other requirements (i.e., organization-wide participation, emphasis on communication, and effective group-work environments) are not explicitly addressed.