pilot study of a configuration management application in a gis environment november 28, 2006

Montgomery County, MarylandDepartment of Technology Services (DTS)Geographic Information Systems (GIS)

Pilot Study of a Configuration Management Application in a GIS Environment

November 28, 2006

ESRI Mid-Atlantic User Group Conference 2006

November 28, 2006 Montgomery County, Maryland DTS GIS ESRI-MUG 2006 Conference

2

Presentation Outline

Introduction GIS Organization Customer – Public Safety 911 Issues and Challenges (for GIS and CM)

Configuration Management Overview CM Processes and Fundamentals Software Development versus Data Management CM Application in a GIS Environment

Implementation Process Improvements for GIS and CM Parallel Development and Repeatable Processes Improved Quality Control and Quality Assurance

How You Can Get Started For GIS CM and GIS Industry


3

Chief Information Officer (CIO)Alisoun Moore

Chief Technology Officer (CTO)Mike Knuppel

Enterprise Applications Enterprise Services Enterprise Infrastructure Telecommunications

• Project Requirements• Application Development

• “e-Montgomery”• Enterprise Systems Services• Geographic Information

Systems (GIS)

• Client Computer Support• Help Desk Services• Server Support• Public Safety Support

(24/7 DTS Support)

• Host Operations• Data Security• Fibernet / Wide Area

Network (WAN) Support

• Telephone Services• 800 Mhz Radio

Management and Repair• Engineering Services

Decentralized Technology Teams Across County Government; Often use Workgroups to Enable Teamwork and Collaboration

• Also, Other Departments and Agencies May Have Small Technology Teams as Well• Health and Human Services (HHS)• Department of Liquor Control (DLC)• Department of Finance• Department of Public Works and Transportation (DPWT)

MCG Department of Technology Services


4

County-wide GIS Services

GIS Team 14 GIS Specialists 8 Servers 90+ Databases 200+ Layers

Services Produce Maps for County County and Enterprise -Wide

Geospatial services (Web, Geo databases)

Special projects Board of Elections Board of Education Public Safety Etc.

The Customer – Public Safety Public Safety Data System (PSDS) Emergency 911 System Data Center Operations

24 X 7 Police and Fire/Rescue Geo Data

Critical Data Maps in all Police Cars & Fire

Apparatus, Stations Dispatch Vehicle Routing Address Verification & Location


5

Issues and Challenges

Operational GIS Process, Procedures

Social Comfort Zones

Data Nature of Geo Data

Changing, Growing Database Integrity

Missing, Null fields Data Accuracy

Wrong police beat assignments

System Complexity (Business Systems vs. GIS Systems) Mainframe: Traditional, tabular, data

entry, long time GIS: New, non-traditional, complex,

constantly changing, no long-term testing

Public Safety Data Data Experts and Specialists

In GIS, not Public Safety Nature of Data

Public Safety in Infancy stage


6

Phases of Commitment

Time

Co

mm

itm

ent

Awareness

Understanding

Trial Use

Begin to Adapt

Institutionalize

Carnegie Mellon University, Software Engineering Institute (SEI), from D.R. Conner and R.W. Patterson “Building Commitment to Organizational Change”, Training and Development Journal, 18-30; April 1982.


7

Receptiveness to New Technology

2.5 %

13.5 %

34 % 34 %

16 %

0

5

10

15

20

25

30

35

Innovators EarlyAdaptors

EarlyMajority

Late Majority Laggards

Carnegie Mellon University, Software Engineering Institute (SEI), from E.M. Rogers “Diffusion of Innovation”, Free Press, New York, NY; 1983.


8

Configuration Management

Engineering Discipline Processes and technologies to identify and control items Engineering, Software Development, IT fields Standards: DOD, MIL, IEEE, ISO…

What is CM? Identification of the system being created or released Control over the items making up the system and changes to the system Auditing and analyzing what is being created and released Reporting and tracking events on the system

Where is CM in the GIS field? Does not exist No case studies Little or no resource information


9

CM Fundamentals

1. Identification Identify configuration items of a

system Requirements, deliverables, end

products, pieces of a deliverable, code, designs, executables, tools, test cases

Create a baseline (snapshot)

2. Control Control changes to configuration

items Version control, change control,

build management (software), release engineering

CM Tools

3. Audit Analyze the baselines and

processes Assign action items for issues

and non-compliance CM Improvement

4. Status Accounting Report on events Systematically collect, record

and report meaningful CM data Measurable, repeatable

Includes metrics, audit results, history, tracking effort, traceability


10

The CM Challenge for GIS

Data Production Group GEO Load for PSDS is not

Software Development Lifecycle of Software Development

is not the same as Data Mgt Spiral Model – maybe

CM Tools GIS data managed by GIS

software Proprietary database Incompatible tools

CM tool like ClearCase cannot recognize the ArcInfo data structures

CM Methodologies Around for Software Development Shared terminology Shared culture and discipline


11

Software Development vs. Data Management

Software Development

CM Processes: exist, tried-tested,

improved

CM Tools: exist, tried-tested,

improved

Models, Patterns, Terminology established

Data Management

CM Processes: No case studies

CM Tools: Not created for DM

Models: Database Management

Models, Data Management Techniques are used

versus


12

What Can Be Done?

GIS Side Formalize Processes

Data Management Quality Control / Assurance According to industry AND to

department culture Team Receptiveness

Automate as much as possible Writing scripts; documenting expert

procedures Leverage in-house expertise

Ensure 100% Data Integrity Goes back to issues with missing

fields, links, keys or null values

CM Side Match CM concepts to GIS

processes Identification of layers, modules Control changes at high level Report on changes per release

Establish business rules to enforce CM concepts

Apply CM tools where applicable Problem Management Version Control

Scripts and automated QC tools SQL stored procedures Not for layers or workspaces Maybe for workspace baselines


13

Configuration & Process Management for GIS

Improvement Goals Decrease Mean Time Between

Deliveries Frequent deliveries = better QC

and management of changes Error fixes manageable per delivery

Establish Release Dates Consistent delivery schedule

increases customer satisfaction, trust and manages expectations

Don’t keep customer waiting Always know when new Geo Data

is arriving

QC Automation Catch systematic errors with tool Decrease manual labor efforts

GIS Data Management Process Formalize the Process

GIS has control over this process Re-use current ideas and move

forward with progress Add new process design, make

formal procedures, repeatable

Requirements Management Communication with End-Users on

requirements Quarterly CAB Meetings

Freeze Requirements Change Control Process for new

requirements

Public Safety Requires Frequent Updates to Map & Geo Data


14

Change Control

Change Advisory Board (CAB) Quarterly Meetings with Key

Personnel DTS GIS DTS Public Safety Support Police Department Fire/Rescue Services

Requirements Freeze & Sign-Off Requirements Form

Change Management Change Request Form

Requirements Changes DTS Issues Tracking System

Data Changes Specific Police/Fire Data Changes

Data Repositories (Directories) Source

Master copy of all layers Owner can copy over data No edits made in source directories

Workspace Copy from Source directory to

Workspace directory Owner makes edits QA/QC on layer in workspace

before copy back to Source Release

Final QA/QC on layer(s) to be released

Only 1 Owner GIS Manger authorizes release


15

GIS Source Server - Responsibilities

Category # Layers OwnerBasemap 22 Lian

Census 7 Lian

DEM 3 Lian

DHCA 1 Lian

DHHS 1 Dan

Elections 7 Vicky

Environmental 7 Lian

Finance 3 Lian

Fire 14 Vicky

Grids 6 Barb

Historic 2 Barb

Landuse 5 Barb

Locations 19 Tim

Metadata 177 Lian

OCE 10 Carol

Category # Layers OwnerOrthophotos 6 Apollo

Permitting 3 Lian

Planning 5 Yanli

Police 4 Vicky

Political_mc 4 Celina

Political_other 1 Celina

Property 3 Lian

DPW&T 9 Barb

Recreation 4 Dan

Regional 2 Celina

Schools 10 Tim

Sheriff 2 Celina

Utilities 15 Carol

USPS 2 Celina


16

Parallel Development & Repeatable Process GIS Work on Mainline Branch

Copy from Source to Workspace Edits Made in Workspace Directory Only

Public Safety Release on PS Branch Allows for Parallel Working Environment

Data Freeze Copy from Source to Staging Area (PSDS) Final QA/QC on ALL Layers

Release Dates Established Quarterly Regular Intervals, Do Not Change

Mainline Development

GIS Data Freeze GIS Data Freeze

GIS DM Process

PS Conversion Process

Release A-PS

GIS QC Process

Release A

GIS DM Process

Release B Release C

Release B-PS Release C-PS

GIS DM Process

GIS QC Process GIS QC Process

PS Conversion Process PS Conversion Process

Public Safety Branch (for delivery only)

GIS Data Freeze

Repeatable Process GIS Data Management Quality Control Process Automation when possible Lifecycle of the GIS DM/QC Process – from

release to release Repeat after each GIS product Release

Public Safety Release Process Consists of a snapshot of the GIS product

Release Conversion process applied Lifecycle ends with delivery to Public Safety Repeat upon next GIS Release product


17

Automated QA/QC Concept

CM Implications on GIS System Development Life-Cycle Create Manage Publish Maintain

Automated QA/QC in Public Safety Database Development Matching Geo Databases between

Development and Production Version Control Data Acceptance

QA/QC and Output Process Source Code Revisions Data Preparation Map File Conversion Tiling Output Delivery


18

GIS Public Safety Data Delivery Process1. Data Readiness

• Create Data Layer• Topology Check• QA/QC Automation

• Arc/Info & GeoDB• Tier 1 – Data Owners• Tier 2 – QC Team• Tier 3 – Final QC

• QA/QC Report & Fixes• Agency Owner QA

• Police / FRS• Sign off from Customer

• Data Freeze

2. Pre-Conversion• Copy Layers from Source to Staging Area• Add Common Convert Items• Run Convert Tools, AML to Copy Source Fields to Converted Items• Drop Unnecessary Fields (Keep Convert ID#, etc.)• Replace “null” With “.” For Each Converted Layer• QA/QC: Unique ID, Full Population, Null Values• LUT Tables (street type, turn tables, etc.)

3. Conversion• One AML Calls All Routines• No Menu Selection (no prompts)• QA Conversion Results

• e.g., Layer / Feature / Text Conversion• Link With Source Layer to Check Attribute Conversion

4. Post-Processing• Single AML to Create ply, lin, pnt files (PLP)• Batch Program to Delete or Create PLP Directories• QA the PLP Output Files; Feature Count by Layer• Batch Program to Move PLP Files to Associated Directories• QA “Clines” Line Files

5. Tiling / Output• Automated Tiling• QA Tiled PLP Files Per Subdirectory – Feature Count Must Match by Layer• Public Safety Check List• Public Safety Export List• Notify PSDS Team• Police/FRS On-site Validation• User Feedback

Data Freeze

Ready For Release to PSDS


19

MCG/DTS: GIS CM for Public Safety

CM Analysis October 2005 for Public Safety February 2006 for GIS

GIS CM Stage Between “Trial Use” & “Begin to

Adapt”

CM Plan

Change Advisory Board (CAB) Requirements Management Change Control Process Issues Tracking (Problem Tickets)

Formalized Process Edit/Update Geo Data QA/QC Layers and Databases Streamline Delivery Process

CM Tools In-house scripts Forms Issues Tracking System

(enterprise-wide)

CM Tools Needed in GIS Software:

-Change Tracker-Versioning of Layers


20

Your Roadmap to GIS CM

Create a CM Plan Use Existing Templates as a

Guideline

Assessment & Risk Analysis Management Support How Receptive is Team?

Start Changing Mindset Now Get Used to Formalized Procedures

(such as CM)

Establish CAB or CCB

Implement Manual Processes for Operations/Business

Use CM Tools When Possible: AML, Scripts,

Stored Procedures, Documents

Use Version Control Forms, Lists, Spreadsheets Track Changes on High Level Excludes: Data Edits, Layer

Versioning **

** Need support from GIS Software vendors

Need Integrated CM Tools in GIS Software

CM Acceptance in GIS Industry

Plan According to Your Organization’s Needs


21

Contact Information

Department of Technology Services (DTS) - GIS21 Maryland Ave., Suite 350Rockville, MD 20850-2390

Enterprise Applications Division, Geographic Information Systems (GIS) Apollo Teng, GIS Manager [email protected] 240-777-2883

Yanli Gong, Sr. GIS Specialist [email protected] 240-777-2886

Enterprise Services Division, Public Safety (PS) Heba Elbadawi, Public Safety Configuration Manager [email protected] 240-773-7234

Presentation Can Be Downloaded from the DTS GIS Website athttp://www.montgomerycountymd.gov/content/gis/docs/mug06_CM.ppt


22

Supplements

CM Plan Outline Template

Change Advisory Board Process Flowcharts Requirements Form (Template) Release Plan and Schedule (Template)

Change Control Process Change Request Form (Template) Issues Tracking - Sample Problem Ticket


23

CM Plan Outline (Sample 1)

Introduction Purpose CM Overview Scope Definitions, Acronyms, Abbreviations References

Management & Organization Organization Responsibilities CM Policy Procedures, Methodology & Tools

Configuration Management Process Configuration Identification

Identification Methods Labeling Conventions Project Baselines CM Repositories

Configuration Control Change Control Change Advisory Board (CAB)

Configuration Status Accounting Peer Review CM Status Reports CM Logs and Database

Audit and Review Function Configuration Audit (FCA) Physical Configuration Audit (PCA)

Project Media Library

Vendor / Contractor Control If applicable

Resources, Schedules, Points of Contact CM Roll-Out Schedule Geo Data Delivery Plan & Schedule

CM Risks and Opportunities

Supplemental Information


24

CM Plan Outline (Sample 2)

Introduction

CM Management Organization Responsibilities Project CM Dataset CM Developed Application CM Final Product CM Applicable Policies, Directives, Procedures

CM Activities Configuration Identification

Identification Methods Naming, Labeling Conventions Acquiring Configuration Items

Configuration Control Change Process: Request, Evaluate,

Approve, Implement Change Control Board (CCB)

Configuration Status Accounting Configuration Audit and Review

Function Configuration Audit (FCA) Physical Configuration Audit (PCA)

Interface Control

Records Inventory

Resources and Points of Contact Software Resources Training Requirements in Support of the

Plan

CM Plan Maintenance

References


25


26

Department of Technology Services (DTS) Enterprise Applications Division (EAD) GIS Configuration Management

Requirements Specifications and Sign-Off

For CM Use

GIS-RQ v1.0

This form is used to document the requirements needed and requested changes to the Public Safety Geo Data in the CAD System for the next scheduled Geo data load as specified below. This form shall be filled out during (or shortly thereafter) the GIS Quarterly Change Advisory Board (CAB) Meeting (previously called the GIS Quarterly Review Meeting) and sign-off signatures shall be obtained by members of the Joint Public Safety / GIS Change Advisory Board (MCPD, MCFRS, DTS GIS, DTS PSDS). (1) All requirements to be considered for the target PS Geo Data release shall be documented in this form by DTS PSDS PM or CM at the time of the PS GIS CAB Meeting. (2) DTS PSDS CM shall request the sign-off from MCPD and MCFRS to signify requirements freeze and accuracy, with DTS GIS and DTS PS as witnesses. (Additional requirements details may

still be obtained during impact analysis and/or data development). (3) DTS GIS shall publish the following: a) Target Release Work Plan and b) Target Release Schedule. The Work Plan and Schedule are a resulting effort of the GIS Impact Analysis of the

requested data changes (requirements) and shall document for each requested requirement if the requirement will be or will not be included in the target release. The Work Plan and Schedule shall be submitted to the end-users, referencing the requirements by “Req ID”. A requirement may be included in a release with modifications, based on the resulting GIS Impact Analysis. Such modifications must also be documented and communicated to the end-users in the submitted Work Plan.

Change Advisory Board Meeting Information

Date of Meeting: Meeting Location:

Attendees Public Safety (DTS):

GIS (DTS): MC Police Department:

MC Fire and Rescue Service: Target Release Information

Requirements Specifications ID: GIS-RQ-<CustomProp>

Planned Release Type: Full Partial (specify data layer):

Planned Release Name: (Final Release Name shall be identified in the Work Plan)

Planned Release Date or Month: (Final Release Date shall be listed in the Work Plan)

List all requirements discussed and agreed upon during the CAB Meeting for the Target Release. For each requirement, provide (1) a brief high-level description of the requirement, (2) the requestor’s department (MCPD or MCFRS), (3) a

detailed description of the requirement describing what is needed, and (3) the severity (or impact) of not having this implemented item. Requirement ID format = GIS-<Release_ID>-R<Seq#> Requirements Specifications

Requirements ID

Item Req By Requirements Severity / Impact

GIS-<CustomProp>-R001






Release Work Plan and Schedule

For CM Use

GIS-WP v1.0

This form is used to document the work plan and schedule for the next scheduled Geo data load as described below. This form shall be filled out upon completion of the requirements review and impact analysis by the GIS team and shall be submitted to the Joint Public Safety / GIS Change Advisory Board (MCPD, MCFRS, DTS GIS, DTS PSDS). (1) All requirements to be considered for the target PS Geo Data release shall be documented in the CM form titled “Requirements Specification and Sign-Off” (filename GIS-RQ-<release>

where <release> is the target geo data release version). Sign-off of the requirements specs is required by all members of the GIS CAB. (2) DTS GIS shall perform a review of all documented requirements and conduct an impact analysis of each described requi rement. (3) Upon completion of the impact analysis, DTS GIS shall publish the Work Plan and Schedule describing any deviations, if any, from the agreed upon requirements. The Work Plan and

Schedule shall explicitly note which requirements will be or will not be a part of the target release; furthermore, any requirement included in a release with modifications from the original baselined requirement shall be noted in this form.

(4) If there are no deviations from the original baselined requirements, this form is to be submitted to the users. (5) If there are deviations from the original baselined requirements, sign-off signatures must be re-obtained in the section following the schedule.

Target Release Information

Corresponding Requirements Specifications ID: GIS-RQ-xxxx

Work Plan ID: GIS-WP-<CustomProp>

Release Type: Full Partial (specify data layer):

Release Name:

Release Date or Month:

Work Plan and Schedule Document the work plan for the target release, including the Planned Dates for a) data freeze, b) interim data deliveries, if needed, c) PSDS

data delivery for user test purposes and d) expected PSDS Production deployment. Document the “Next Steps” and any coordinating efforts required for this target release. The Plan 1. <Release Name>

1.1. Data Freeze: _________________ 1.2. GIS Delivery to PSDS: _________________ 1.3. Questions or Comments

1.3.1. Next Steps 1. <Release Name>

1.1. Requirements Specifications Matrix For each requirement listed in the Requirements Specification form, identify the Approval Status of the requirement. This matrix is to be filled

out by the GIS Manager documenting the results of the requirements review and impact analysis. Use one of the following status codes

Status Description of Status APPROVED Requirement shall be included in the target release

APPROVED WITH COMMENTS Requirement shall be included in the target release, but with modifications FUTURE Requirement will be included in a subsequent release (not this release)

REJECTED Requirement will not be implemented

Requirement

ID Item Req By Approval Status Comment

GIS-xxxx-R001

GIS-xxxx-R002

GIS-xxxx-R003


27


GIS Change Request Form

For CM Use

GIS-CR v1.0

This form is used to document a change request to the requirements or release scope of a Public Safety Geo Data release. This form can be initiated by any of the GIS, MCPD, MCFRS or DTS teams. This form primarily documents a change request to the requirements baseline of a Target Release. All change requests must be submitted to the GIS PS CAB for review and final approval. (1) Fill out the GIS Change Request form, describing the type of change being requested, such as additional or modified requirements. (2) Submit the GIS Change Request form to the PSDS PM or CM for logging. A CM Number will be issued for tracking purposes. (3) If the request originates from the Users, GIS will review and the request and either approve, reject or call another CAB Meeting if necessar y. The PSDS PM or CM will communicate the status

of the change requests to all parties. (4) If the request originate from DTS or GIS, the PSDS PM or CM will communicate with all parties on the change request and it final status.

Contact Information

Submitted By: (MCPD, MCFRS, DTS, etc.)

Date of Request:

Contact Name:

Phone:

Email: Type of Change Request Check the appropriate boxes describing the type of change:

Change to the Requirements Baseline Requirements Specification Form ID: GIS-RQ-<ID>

Add new requirement(s)

Modify existing requirement(s) Specify Requirement ID: GIS-<Release>-<Seq#>

Delete existing requirement(s) Specify Requirement ID: GIS-<Release>-<Seq#> Change Description

Status Tracking

Date Received: Date Reviewed:

Received By: Reviewed By:

Effort Estimation: Value Estimation: (Very Low, Low, Medium, High, Very High) (Very Low, Low, Medium, High, Very High)

Review Results: Approved for Target Release Release Name:

Assigned To:

Planned Completion Date:

Rejected Explain:

Deferred Until Later Future Release:

Return for Additional Information

Closed – Duplicate Request

Closed – OBE/Cancelled


28

Magic Ticket # 159305 has been assigned to the DTS_GIS group by DTS_PS

Incident Number: 159305 Open Date: 7/11/2006 9:36:55 AM Client Name: Trent Bishop Client ID: BISHOT Client Phone: (240)773-7027 Client Department: Police Subject ID: PS_CAD_DATA Subject Description: PS CAD - Data Incident Description: Addressed CADLIVE b 106.2-107.3 / AVS 31.1 Address Discrepancy

1. Flagship Car Wash @ 2100 Chapman Ave, Beat 1A1, Atom 271.

Verizon and the MD tax records show the above locations address listed as 975 Rollins Ave not 2100 Chapman Ave. The manager of the business states that he has documentation from Rockville City Planning that the address should be 2100 Chapman Ave. The 2100 Blk Chapman Ave is not in the address server. The range ends at 2099 Chapman Ave. The building footprint is displaying 975 on the map.

Please create a CPN for the location when the correct address is established. ____________________ J. Miller, 7/14: On Live - Extended street address range from 2099 to 2199. Added CPN. _____________________ J. Miller, 7/14: GIS Team, please correct street addess range and building footprint as described above. Contact Trent Bishop if you have questions.

C. Azevedo, GIS, 9/1/06: The 2100 block is in place on Chapman Ave. and will go into the upcoming delivery.

C. Azevedo, GIS, 10/17/06: Checked the converted data. The 2100 block is in place. _____________________________ J. Miller, 10/31: GIS Team: Trent thinks that the building footprint labeled 975 Rollins, should be labeled 2100 Chapman. Please look at this and relabel it if it is labeled incorrectly. If it is labeled correctly, please give Trent a call.

DTS_GIS - PS ticket assigned to group

pilot study of a configuration management application in a gis environment november 28, 2006

Documents

maryland dts gis esrimug

gis environmentnovember

gis systemsmainframe

specialistsin gis

startedfor gis

gis industrymontgomery

county government

infancy stagemontgomery