Applying Standard Software Development Practices to Geographic Information Systems

Treating GIS as IS. As the GIS industry matures and more organizations move from a data focus to an applications focus, the importance of successful GIS software development grows. This paper presents the importance of utilizing IS tools, resources, and methodologies during the development of GIS projects. Several development tools including Requirements, Lifecycle Models, Risk Management, and Change Order Processes will be reviewed. Specific applications of these tools to GIS projects will be discussed. This paper can serve as a toolkit for GIS project managers, allowing them to reference and link to numerous resources, organizations, and publications providing information about IS development tools.

Time to Treat GIS as IS

The geographic information systems (GIS) industry is moving very quickly into a new and exciting period of end-user application development.  Therefore, in many organizations, GIS has the opportunity to finally become the application for everyone that we have been hearing about for the last 15 years. Executives and managers in both the public and private sectors are demanding that the benefits of GIS be spread past the two or three GIS experts in the Engineering or Data Processing department. Recent developments in the GIS industry have created a new category of applications that is satisfying this demand.

These applications are not standard commercial packages, such as ArcInfo, AutoCAD or Intergraph.  But instead, these applications are specifically designed to run on multiple desktops throughout the entire organization, from Administration Offices to public access counters, and can be implemented on the Internet and/or Intranet sites. This category of highly sophisticated, yet "ATM" easy-to-use, enterprise GIS applications is the catalyst for a new revolution of productivity. 

The new semi-custom enterprise GIS applications are created specifically for an individual organization's workflow and data information demands.  They are created in many different GIS and non-GIS application languages. These new applications are uniquely constructed and sophisticated.  The applications are big budget items and typically have a high profile.  While these organizational GIS applications are new to the GIS industry, their life cycle development is well known to the IS industry.

Information Systems (IS) is a well-developed industry with standard practices that have been refined and proven over the last 40 years. People involved in developing and shipping software, and in implementing commercial applications, have a well structured group of tools for development of software such as: lifecycle development models, code version software (CVS), defect tracking, requirements gathering, use cases  and other practices that are all associated with the IS industry. These software development standards were created and formalized to reduce the failure rate of IS projects. IS development firms are certified by grade using the Software Engineer Institute's (SEI) Capability Maturity Model (CMM).  The CMM is based on five levels of using standard development tools. The IS industry is also moving closer to certifying individuals for software development, once again based on knowing and using standard development practices.

Now the question for the GIS project manager is "If you are going to develop and implement a big budget, high profile enterprise-wide software system, why not follow and practice the existing IS industry standards?  These IS standard practices are taught at the college level and fill the bookstores' computer sections, yet are foreign to some GIS project managers.  The problem is that most GIS end-users are not aware of which processes to follow, or else they choose not to practice them at all.  Now is the time to start treating GIS like IS.

There are many geographic information systems being developed with front end "Needs Analysis" studies and GIS database practices, such as metadata and standard feature classifications. But although they are becoming prevalent, these planning practices are still not being incorporated into most GIS projects.  Instead, the processes and standards that are being developed in GIS all focus on the data. If you go to any GIS conference you will hear seminars about the importance of collecting metadata. But have you ever heard a passionate lecture on defect tracking and code version control , which is the equivalent of metadata on the software applications side of GIS?  The GIS applications that you need are just as critical as the high-budgeted GIS databases you must have, and in general, their development process is foreign to a large number of GIS coordinators.  By adopting some of the IS industry's practices in this area, GIS end-users could begin to reap the full benefits of their system.

Six Tools For Developing GIS

Building and Maintaining Requirements

Building and maintaining requirements has been documented as one of the most system critical components for software success or failure.  In its most basic form, gathering requirements is accomplished by programmers talking to end-users.  This generates the most fundamental requirements that the application must accomplish.

Requirements fall into two categories: functional and non-functional requirements. At TDC, we also like to include assumptions and responsibilities in the requirements document. Once the requirements document is generated, it must be reviewed.  Ambiguity must be removed from the document and standard testing criteria used to rate each requirements statement.

Not all requirements are created equal. Requirements must be prioritized and possibly even removed or setback for the next release.  Upon initial completion of requirements documentation, it is vital that a gatekeeper committee be able to maintain the integrity of requirements.  As new requirements are presented they must be rigorously analyzed and tested. It must be decided if they will be included in the requirements document and if so, at what priority level.

Lifecycle Models

The process for developing software from the initial concept to the first initial release can be accomplished using several different standard development models.  Different projects have different needs and selecting the correct design model accomplishes the quickest development time.  Following are some of the most common lifecycle development models and a brief list of the pros and cons of each model.

Waterfall Model

The Waterfall Model is a step-by-step process that works and is considered to be a well-understood technical process. If your project is well defined with requirements and system architecture and you have a similar experience with like projects, then the Waterfall Model, with its limited amount of management and planning efforts, will produce the desired results in the shortest amount of time.

The disadvantages of the Waterfall Model are that, while every step is well defined, each step also builds on the work of the previous steps before it.  Therefore, it is very hard to correct earlier errors, or in this case “swim upstream,” using the Waterfall Model.  If requirements are not built correctly in the beginning steps, it is very difficult to correct errors that may occur in the later steps of the waterfall.

Spiral Model

The Spiral Model breaks a software project up into mini-projects. Each mini-project addresses one or more major aspects of the whole project until all components have been addressed. The Spiral Model is excellent for poorly developed requirements and architecture while producing a highly reliable system. However, it requires a significant amount of management and planning time and needs sophisticated, experienced developers.

Spiral models are very good for GIS development considering the fact that most mapping projects are ongoing and continuously developing, the technology is in a rapid state of development, and end-users are never sure of the total capabilities of GIS for building good front end requirements.

Code and Fix Model

The Code and Fix Model is the most frequently used model.  If you haven't explicitly chosen a model, then you are using code and fix. This model is the most inefficient, expensive and painful way to develop applications.  Code and fix typically happens when managers and programmers get a brief description of the application and then code around the clock until the project is complete. The larger the application and project are, the more painful this model is to use.

A classic description of this model is a project that has one “gonzo programmer locked up in a closet” with no one else knowing when the application will be done or what it will look like when it is complete.  Code and fix requires absolutely no management time, and needs none of the requirements building, review testing, or other tools mentioned in this paper.

The only time code and fix should be used is when an application takes less than one day to complete.

Staged Delivery Model

Staged Delivery is actually a modified Waterfall Model.  Staged Delivery allows major feature components to be delivered in incremental phases of software delivery. This model works well at covering some of the shortfalls of the classic Waterfall Model. It allows planning and design components to be integrated into different phases of the project, as opposed to trying to complete them at the beginning of the project.

Staged Delivery also helps clients and managers feel good about delivering useful components earlier in the project.  This is very important to GIS projects in that the directors and department heads, who generate funding, can see early success, justify large expenses and the long timelines of GIS projects.

One major disadvantage to the Staged Delivery approach is that it is time-consuming to continually update and reinstall the application on the end-user side. This includes system setup, retraining, documentation and bug tracking.  If too many staged releases are implemented, end-users can be upset with the amount of disruption and downtime.

Designed to Schedule Model

The relationship between features/requirements, schedule, and budget is direct. If one or all of these factors change, one of the other two will have to change as well.  With in-house projects where the budget and schedule may not be set in stone, requirements and features can grow. However, with contracted fixed-price projects if there is a change in features, then there needs to be a change in schedule and/or fees; and if there is a change in fees then schedules need to be adjusted or features need to be trimmed.

Designed to Schedule dictates that the schedule of delivered functions has priority over cost and requirements.  The major disadvantages of the Designed to Schedule Model are that it requires heavy management supervision, does not allow for midcourse corrections and works poorly with adding requirements, and when the system architecture is not clearly and correctly developed.

Commercial Off-the-Shelf Software Model

One option for acquiring applications is to purchase commercial off-the-shelf (COTS) software. The major advantage with COTS is that risks are minimized as far as budget and scheduling are concerned. COTS also offers the advantage of having built-in support resources and a possible pool of other users to serve as a knowledgebase.

Disadvantages to COTS are the possible limits of fitting the software to your requirements, its ability to integrate with your environment and its ability to mature and develop with additional features.  Also, because of its canned functions and features, a large amount of training may be required to accomplish end-user processes.

Software Request Change Order Process

Once requirements have been developed, refined, and documented we can assume that this major component of software development has been put to bed for the project. However, this is not always the case. Recent studies show that the typical project experiences about a 25 percent change in requirements during development.  Studies have also shown that feature creep is the most common source of costs and schedule overruns.

While it is nearly impossible to stop all changes, we have found the following tools to be most productive in managing change: change board/requirements committee, software request change order processes and databases, and just saying no. The change board in conjunction with the request change order process database, provides a bureaucratic buffer that kills most irrational change requests and is critical for refining and documenting valid changes.  Another benefit of this structured change order process is that it provides a communication device for all parties involved, including those on the periphery of the project.

Defect and Enhancement Tracking

More commonly known as bug tracking, the ability for a team to catalog, document, track, and report on defects, not only after system implementation, but also during development, is critical.  Bug tracking databases can be as simple as a Microsoft Excel spreadsheet or a Microsoft Access database. There are also several good enterprise-wide commercial off-the-shelf bug tracking tools. One of the most important requirements for a bug tracking system is that it can be edited and accessed by multiple users simultaneously.

Bug tracking systems helps manage defects while at the same time; the resulting knowledge base of solutions becomes invaluable for product support and future applications development.

Peer Review

A peer review process is meant to allow individuals to review the work in progress before it gets to the finished stages.  This will help prevent end-user bugs and defects once the product is delivered to the customer.

A review session is for reviewing the product and pointing out potential problems and errors. It is not a problem solving session. Solving problems is usually a distraction that siphons valuable time away from the focus on error detection. Our rule of thumb is that if a problem can be solved with no more than 1 minute of discussion, go for it. But if it looks like the discussion will take longer, note the item in question and ask the author to pursue solutions off-line, after the meeting.  If the author would like to request a problem/solution meeting he can do that at a later time.

The peer review process is not about management intervention.  Managers should never join in the review "just to see what's going on." If the author requests a manager to be present, then it is acceptable for a manager to be in on the review. However, the whole point of the review is for co-workers to check each other's product without management involvement.

Every inspection or review process should follow some basic guiding principles.

1. Check your egos at the door.

2. Critique the products, not the producers.

3. Find problems during the review; don't try to fix them.

4. Limit inspection meetings to a maximum of two hours.

5. Avoid style issues unless they impact performance or understandability.

6. Inspect early and often, formally and informally.

Do not leave inspections and reviews until the last component of the system is developed and you are merely black box testing for bugs. Review and inspections must occur at every major milestone of system development. Formal reviews and inspections should occur after requirements building, major architecture design, individual component construction, and at final system completion. Major review and inspections should also be applied to user interface design, output and printing, and for all documentation.

One More for the Road: In-House Knowledge Base

Knowledge and details are most valuable when they can be easily shared within a group.  Good communications become essential as the project team becomes larger, number of end-users grow, and third party vendors become involved good communications become critical.  Reports need to be made available across the project group.  The amount of knowledge and the effort to disseminate that information becomes exponential relative to its size.

All of the tools mentioned above require documentation and the ability to search and retrieve information easily for anyone within the project team. Creating a Website for either internal and/or external browsing is one of the most powerful and maintainable systems for cataloging knowledge and providing a tool for search and retrieval.

By creating a project Website whereby project team members can review a chronology of the project, e-mails, progress reports, the project schedule, names and e-mail addresses of persons involved in the project, change orders and addenda and so forth, everyone will have easy access to important project information.

Final Conclusions

The use of these system development tools may seem to require a large amount of time and effort in relationship to the actual programming of the GIS application, which is correct. Industry standard estimating tools for system development shows that programming comprises only 1/6 of the total project. Planning task such as requirements and system architecture design comprises a third of the total project. Review, testing and inspections both during development and after implementation consume 50 percent of the software developments schedule.

Failure to integrate and allow enough time for development tools and components other than programming is disastrous. Typically delays come at the end of the schedule, when no one is aware of schedule trouble until almost the end of the project. Late and without warning, this bad news is most unsettling to clients and customers.

REFERENCES OR ACKNOWLEDGMENTS

McConnell, Steve. Software Project Survival Guide. First edition, Microsoft Press Publisher, 1997.
Great book for newbies in software development. Software Project Survival Guide is responsive to the fact that many people in the software industry are thrust into positions of responsibility for the outcome of a software project but are not given any formal or informal training in how to make that happen. Software Project Survival Guide describes the specific steps that successful software projects follow, and it can be read by both technical and non-technical readers.

McConnell, Steve. Rapid Development: Taming Wild Software Schedules. First edition, Microsoft Press Publisher, 1996
The bible. This is a tremendous book on effective scheduling software development, and it drinks deeply from the wisdom of all the classics in the field such as Brook's Mythical Man Month -- and is likely well-informed by McConnell's experiences, good and bad, in Redmond. The nine page section entitled "Classic Mistakes Enumerated" is alone worth the price of admission and should be required reading for all developers, leads, and managers.

Cause, Donald C., and Gerald M. Weinberg. Exploring Requirements: Quality Before Design. Dorset House 1989
Written by two authorities in the field, this book is a collection of ideas developed, refined and tested during their more than sixty combined years of work with both large and small organizations.  The techniques formulated in Exploring Requirements are not merely theoretical; they have been used effectively to develop a wide range of products-from computer software to furniture to books and buildings.