- Shopping Bag ( 0 items )
For many people methodology implies extensive overhead, extraneous tasks, and the stifling of creativity. In reality, however, adopting a methodology simply means using certain techniques and executing certain tasks that will produce the best results.
You may be familiar with one of several development methodologies tested over the past several years, particularly if you have developed ARC/INFO applications. The methodology discussed below is both a combination of and variation from methods used in developing GUIs (graphical user interfaces) and client/server application software. It is also somewhat different from traditional methods used in developing ARC/INFO applications because ArcView GIS is a new generation product.
The proposed structured methodology for developing ArcView GIS applications is comprised of the following stages.
In the remainder of this chapter, the four stages are described and illustrated through a hypothetical scenario. This scenario assumes that we are GIS consultants to a large metropolitan bank. Our task is to develop an application showing characteristics of mortgage applicants and recipients withindesignated geographic areas.
Because the techniques and procedures for each stage in the recommended methodology have been applied in developing many software applications, detailed information is available in numerous publications on software development methodologies. See the concluding section of this chapter for a list of publications. Next, it should be mentioned that development methodology is only one part of implementing a GIS project. Other issues such as hardware, data sets, staffing, and procedures must also be considered, but are beyond the scope of this book.
The requirement study stage begins upon recognizing that a solution is required for a particular problem. Its purpose is to develop a specification document describing what the software will accomplish, but without explaining how the software will work.
The specification document is the bedrock of your application. The more accurate and complete the foundation, the better your final product will be. Managers and analysts often ignore this stage in favor of writing program code because they prefer seeing a tangible outcome as early as possible. Nevertheless, experienced software developers would assert that you are doomed to fail if you ignore a study of software requirements.
Two distinct activities occur during the requirement study phase: problem analysis and product description. These activities are not carried out in serial fashion, but rather the product description evolves as the problem analysis progresses.
Because the purpose of analysis is to acquire a complete understanding of the problem, most of the analyst's time is spent in meeting with people who are knowledgeable about the problem. In the course of product description, the analyst develops the specification document that explains exactly what a software application can do to resolve the now clearly defined problem.
First Faire Bank's Requirements
During a meeting with First Faire Bank (FFB) managers, we learn that the bank president Donald Zinger is concerned about recent media attention on alleged discriminatory lending practices by other banks in surrounding counties...
|Ch. 1||Introduction to Spatial Analysis||1|
|Ch. 2||Spatial Data||43|
|Ch. 3||Quantification of Spatial Analysis||81|
|Ch. 4||Single Layer Operations||119|
|Ch. 5||Multiple Layer Operations||153|
|Ch. 6||Point Pattern Analysis||187|
|Ch. 7||Network Analysis||215|
|Ch. 8||Spatial Modeling||265|
|Ch. 9||Surface Analysis||309|
|Ch. 10||Grid Analysis||353|
|Ch. 11||Decision Making in Spatial Analysis||387|