A 1998 framework for multi-participant AM/FM/GIS applications development

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.

Implementing the application development framework model
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.

Application development methodology design
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.