| GISdevelopment.net ---> GITA 1998 ---> Application |
A 1998 framework for multi-participant AM/FM/GIS applications development
Geoffrey B. Ehler* & Rick Petrecca**
*Technical Consultant, Convergent Group
6200 South Syracuse Way, Suite 200, Englewood, CO 80111
Geoff.Ehler@cvg-grp.com
**Systems Analyst, Department of Public Works
City of Indianapolis, 200 East Washington Street, Rm 2441
Indianapolis, IN 46204
rpetrecc@indygov.org
Geoffrey B. Ehler* & Rick Petrecca**
*Technical Consultant, Convergent Group
6200 South Syracuse Way, Suite 200, Englewood, CO 80111
Geoff.Ehler@cvg-grp.com
**Systems Analyst, Department of Public Works
City of Indianapolis, 200 East Washington Street, Rm 2441
Indianapolis, IN 46204
rpetrecc@indygov.org
Proiect Overview
Over the past decade, the City of Indianapolis/Marion County has made a substantial investment in geographic information system (GIS) technology, but has realized only limited benefits from that investment. In October 1996, the City/County commissioned Convergent Group to develop and deploy specific applications to demonstrate how to fully leverage the existing GIS technology.
In January 1997, working with Systems and Computer Technology Corporation, the consultant was selected to provide direction for leveraging and enhancing the existing GIS technology at the City of Indianapolis/Marion County. Working with city executives and staff, the consultant developed a long term strategic plan for enterprise-wide municipal GI S, addressing areas such as data update and maintenance procedures, workflow and business re-engineering, applications development, system architecture design, and management issues. The plan focuses on the following objectives for the GIS program:
- Provide an accurate, up-to-date GIS database accessible to all potential users throughout the city;
- Provide easy-to-use desktop access to GIS data and applications across the enterprise;
- Use GIS technology to improve the efficiency of City/County operations and to expand the City/County’s ability to deliver services to the public;
- Provide a common management structure to guide all GIS-related initiatives within the City/County; and
- Develop applications to integrate the GIS with the Internet and provide information for public access.
The objectives of this paper are to discuss how the standard application development model was designed, as well as how it was implemented within a proprietary programming language environment. [n addition, issues such as operational impact, requirements gathering and documentation, coding standards, multiple developer environments, and deployment considerations will be addressed. Establishing these standards helps to ensure that user requirements are clearly documented and understood, allows for consistency between applications, and will reduce development effort.
Approach
Combining the development staff from the consultant and the City into a single team has been a unique situation for each of the partners. While Indianapolis has worked with contract developers in the past, it was always for contracts to develop specific applications. Similarly, the consultants’s experience was either as an outsourcing contractor/consultant or as an appl ication developer for a specific appl ication from cradle to grave. The challenge presented was to integrate two distinct application development staffs into a cohesive whole. A whole in which all members of the team could fill in for each other on development projects and one where a project could be handed off from one member to another with no loss. An additional goal was to develop an environment where the project team could maximize code reuse. The team members recognized that the only way to achieve this goal was through efficient communication; our ability to communicate would be enhanced by the adoption of common standards, conventions, and methodologies.
Establishing coding standards and practices
Commercial Configuration Management Tools
Software configuration management (SCM) can be defined as a system utility that is able to track issues such as version control, workspace management, build management, and process control (Babich, 1986; IEEE, 1987). Version control supports project organization, historic code changes, and parallel development teams. Workspace management allows individual developers the ability to simultaneously work on portions of code within a software engineering project. The creation of deliverable code and install files is addressed by build management. Finally, process control attempts to enforce an organizat ion’s coding standards within the software development Iifecycle.
The City of Indianapolis currently has an ESR1-based GIS solution which includes ARC/INFO, ArcView, and MapObjects/Visual Basic as the primary end-user environments. While ARC/lNFO and MapObjects are directly supported by third party configuration management softwares such as ClearCase, Visual Basic Enterprise, and LBMS Process Engineer, there are currently no commercially available SCM tools for ArcView and its proprietary programming language, Avenue. Seeing this as a shortcoming, the Indianapolis development team deemed it necessary to design the basic SCM functions to support the large number of software engineers on the project team.
The primary focus of the development team was to set standards for applications coding including not only the establishment of coding styles, but also developing script libraries for code reuse. Additionally, the issue of cooperative application development within the GIS programming environment was addressed. A set of graphical user interface (GUI) standards was also proposed, which will allow each application to follow a consistent and standard “look and feel”.
Coding Styles
Coding style can be defined as both the informal and formal rules of programming as adopted by developers. This allows subsequent programmers to easily follow the flow of code written by others. By setting coding styles, this will aid in the use and reuse of existing code. Coding styles that were established included standard headers, comments, notation, variable naming, script naming, and code management. Adherence to these standards wi II promote the open interchange of scripts and code between on-site and off-site developers.
Cross Referencing of Code
The cross reference and management of scripts within the software development environment allows programmers to maintain a “clean” application by eliminating unneeded code. This function will allow developers to search for specific code called by other scripts or linked as the result of an action taken within the application GUI. This aids in the reuse and customization of enhancements to an application.
Use of ArcView Extensions
ArcView provides a way for sharing customization through the use of Extensions or application plug-ins. Extensions provide a convenient way to distribute a set of related tools, along with the necessary components. The project team plans to use Extensions regularly, allowing for custom installations of applications by “loading” or “unloading” Extensions at application startup. This will allow custom functionality to be modular. As application requirements are developed, the designer can use those tools that already exist to develop new applications, make use of existing developed functionality, and eliminate the redundancy of similar functions in separate projects. This will also allow for similar applications, that are built on top of existing applications, to have functionality added through use of this modular code.
Use of ActiveX components and DLLs
In a similar fashion to the use of Extensions in ArcView, ActiveX components and dynamic link libraries can be used to develop modular applications using MapObjects/Visual Basic. For applications developed using Visual Basic, the project team plans to follow the same methodology of reuse of code. In fact, as DLLs may be called from within an ArcView application, creation and use of DLLs and ActiveX components will help provide even greater modularity.
Graphical User Interface
Project developers established a set of standard GUI elements that will be present in almost all end-user applications. Developers will use these standards as a “template”, incorporating any applicable tools c)r features as deemed necessary or as defined within the functional requirements as set forth by application users. The GUI will be developed and approved by the end user prior to final design layout. Examples of these GUI elements include application menus, buttons, tools, message boxes, as well as their associated position, name, and design within the application interface.
System Environment Variables
Environment variables are established to ensure that the final application will run independently of the machine it was developed on. These variables are used in lieu of hard-coded paths to data sources or external file locations, allowing the source path to be modified depending on each end user’s personal computing environment. This will enable the application to be extremely portable from machine to machine existing in differing departments with unique networking situations including mobile computing environments.
Application Development Workflow
The issue of how developers take an application from its initial stages into final application deployment is known as application development workflow. This process allows the designers, testers, and installers to keep control of the application throughout it’s life cycle. It was agreed that the following generic steps should be followed when developing applications:
- Functional requirements specifications (FRS) are to be gathered through user interviews/meetings;
- From the FRS an application is designed and developed and refined through user feedback;
- An application is then tested, through formal and informal testing methods; any bugs, errors, omissions are noted and sent back to the developer for further refinement;
- After final testing is completed and executive sign-off has been received, the application is moved into the deployment area for installation; and
- Any installation issues must be resolved, and if necessary, the application design may need to be reviewed and reworked.
Following the identification and development of coding standards, the project team constructed an application development framework model for use within the ArcView GIS programming environment. This framework was developed as an “Extension” or plug-in to ArcView and is available over the City and the consultant’s network to developers both on- and off-site. This Extension wil I be used as a template for application developers to utilize in authoring and developing Avenue scripts. The appl icat ion development framework extension is constant] y in a state of refinement and enhancement., incorporating the coding standards set forth by the project. Currently this model includes features that:
- Gathers some basic information about the project and stores it in a project level object tag (Figure 1).
This information is used by the Extension to help automate tasks;
- Automatically creates a basic “About” script and adds calls to it to all the GUIS;
- Creates all new scripts with the standard header and names the scripts according to the naming standard adopted by the project team;
- Includes a cross reference tool which creates a cross reference report as well as inserting the cross reference information into the script headers;
- Allows insertion of comments into the header or body of the script formatting the comments according to adopted conventions;
- Includes a tool to allow a user to export scripts to a script library and a corresponding import tool
which presents the script header information to the developer so they know what the script does prior
to importing it (Figure 2);
- Includes an “autosave” function and a new compile button which writes the script to disk in addition to compiling the script; and
- Basic version control functions.
The goal of establishing a standard application development methodology is to promote consistency between al I project developers including on- and off-site personnel. This methodology will also ensure that the end system reflects the customer approved requirements, ensures interact ion between the City personnel and off-site consultant developers, guarantees that applications meet functional, performance, and interface requirements, and serves as a working model for meeting tasks outlined in the scope of work.
Application Evaluation/Identification
This phase helps consultants, engineers, and City staff identify if an employee’s task and work could be completed more efficiently and cost-effectively using geographic information systems (GIS) as a tool. Many issues that may hinder the ability to complete the proposed application are investigated within this phase. The type of software that will be used to complete the application is defined, as well as cost and availability of the chosen development platform. Based on the departments that will be using the end product, individuals signing-off on the completion of critical deliverables are identified.
Application Requirements/Functional Requirements Specification (FRS)
The Functional Requirements Specification (FRS) phase of application development is designed to outline the requirements that the application will need to meet. User interviews will be conducted with specified end users. The application functionality is outlined into specific capabilities, and requirements for each capability are also outlined. Issues addressed in this phase include the scope of the distribution, the operational environment such as network issues and configurations, data requirements, and hardware requirements of the application. The Application Interface Specification section outlines the Graphical User Interface (GUI) window element requirements. Lastly, the application design is reviewed, refined, and authorized.
Application Development
Here, steps are outlined to define how an application is developed from start to finish. These include the following tasks:
- Designate specific coding assignments outlined in the FRS to development personnel;
- Compile benchmark and milestone schedule;
- Design configuration management plan for multi-developer environment;
- Develop application modules following outlined coding standards;
- Establish and document generic “hooks” in the application for use in on-line help;
- Use and document use of existing code modules for generic procedures; and
- Hold weekly review sessions with application development team to review application schedule and technical issues.
The testing phase consists of comprehensive test planning and procedures. The test procedures are outlined and performed, and areas of improvement are defined. After enhancements are completed, the application is analyzed for compliance to outlined requirements. Requirements verification includes visually inspecting all aspects of the application, analyzing test data, demonstrating test cases, and conducting formal acceptance testing. Finally, the applications receive acceptance test sign-off.
Help Documentation
The help documentation phase allows the developers and technical staff to complete the help authoring process. On-line and hard copy help materials are typically required for each application. The procedures established are outlined below:
- Develop on-line and hard-copy help documentation after application passes requirements verification;
- Develop technical documentation for future error tracking and enhancements; and
- Develop a glossary of terms and descriptions that are used throughout the help files and application GUI.
To ensure that the application has been accepted by executive staff, to verify all requirements have been met, and to fulfill the project scope of work, a previously defined individual will recognize the application as being complete by signing an acceptance agreement document. This will allow the project team to reach closure with the development cycle for each application.
Application Deployment
The application installation phase completes the roll-out of the software to appropriate personnel in a three-phase deployment strategy. The three-phase approach is used to provide a structure that is conducive to user feedback at manageable levels. The user feedback can then be used for bug fixes and future enhancements. At each deployment phase, training material is developed and user training is scheduled and completed. The release phases are outlined below:
- Phase I - Beta release for core users to monitor initial feedback and to protect against unforeseen bugs or user errors stemming from design;
- Phase 2- Point release for initial roll-out; and
- Phase 3- Enhancement and final release after refining application requirements, based on application evaluation and assessment.
Applications are to be supported by not only initial training, but also via a help desk and phone support line. Bug reports and functional issues will be entered into an automated user support system, allowing effective and timely resolution. Any software bugs will be evaluated and resolved if necessary, including re-distribution of updated software.
Future directions
The GIS project team was able to incorporate most of the application development methodology and coding standards within the development framework as an ArcView Extension. However, some issues still remain, such as improvements in version control, project documentation capabilities, and adding rollback functionality to the Extension’s “autosave” feature. Porting the application framework to MicrosoR Visual Basic (for developing applications with MapObjects) will be accomplished partially through using the extensibility model of VB5 and partially through the incorporation of commercially available software engineering tools.
Summary and Conclusion
In the initial stages of development of “high return” applications for the City of Indianapolis, the GIS project team identified the need for software configuration management (SCM) in applications development. GIS applications developers located at the City and off-site consultants have collaborated on the design of a standard application development methodology and coding rules. Working in a proprietary GIS applications development language, the project team had to design their own SCM utilities for use in the development process. The SCM tool was developed for ArcView’s Avenue coding language, and has been implemented both within the City and at remote development sites.
While coding standards and methods have been established and are expected to be referenced in future GIS applications development for the City of Indianapolis, there remain several unresolved issues. For example, while most of the application development principles and standards have been incorporated into the Extension framework, some portions have yet to be fully integrated. This, however, does not imply that these principles are not addressed while developing applications. It is reasonable to presume that as the project matures, these issues will be addressed and developers will have complete access to the full suite of automated tools based on all of the established principles.
Through the implementation of both applications development and coding standards, the GIS project team was able to form a cohesive development group who share code regularly. The process of setting these standards has allowed the team to deliver well-defined and clearly understood end user applications, consistent GUI design, and decreased application development time.
References
- Babich, W. A., 1986. Software Configuration Management : Coordination for Team Productivity, Addison-Wesley: Reading, Massachusetts.
- IEEE, 1987. Guide to Software Configuration Management, IEEE/ANSI Standard 1042-1987, 92 pag,es.