Fairfax Va Meeting

1
Cultural Resources Focused Working Group
EESOH-MIS
Fairfax Va Meeting 19-20 May 2004
2
Cult Res FWG Overview

• Introductions
• Goals and Objectives of the Cult Res FWG
• Membership, Responsibilities, Support FOAs and
  Contractors
• EESOH-MIS Overview
• Portal http//www.eesoh.com/portal/
• NGMS Support
• Background
• SDSFIE and FUG
• GeoBase, IVT, MDS
• Other Cult Res efforts DoD, Army, Navy
• Action Plan, Tasks, Schedule
• Funding and Coordination

3
Overview (continued)

• Overview of MCRAD Development Parson Support
• Requirements Definition
• Defining user community
• Defining processes
• Applications Development
• Prototype Application Viewer http//pompeii.cevp
  .com/website/mcrad_home.htm
• The Data Model
• Entity Relationship diagram
• Domains and Attributes
• Data
• Mission Data Sets
• Data Stewards QA/QC
• Data Loading and Sharing Rules
• Other issues Heritage Assets, Documents
  Management

4
Cult Res FWGMembership

• FWG Membership
• Name, Organization, Email address

5
Cult Res FWGGoals and Objectives

• Overview of this module
• Purpose statement (e.g., The XXXXXX Module will
  be used by ___________ to do _____________________
  .)

6
Status of Enterprise Environmental, Safety and
Occupational Health Management Information System
(EESOH-MIS)

7
BackgroundIntegration Strategy

• ESOH MIS working group
• Support ESOH MS IPT
• Establish long term integration/interface
  strategy
• Incorporate Safety into EESOH MIS MOA
• Both near term and long term efforts
• Maximize CCS/AFSAS/ACES Data Sharing
• Enter once, use many
• Illness, activity info, HAZMAT authorization,
  facility info, equipment, controls PPE,
  demographics, etc.
• WEB-Based, through AF Portal
• Enterprise wide information analysis reporting
• Activity based, risk based, compliance based
  information
• Drill Down MAJCOM ? Installation ? Facility ?
  Activity (GEOBASE Common Installation Picture)

8
BackgroundDevelopment Approach

• Develop as part of Air Force modernization
  program
• Improve and standardize business practices
• Integrated, multimedia system vs multiple
  stovepiped systems
• Command Core System (CCS)
• Air Program Information Management System (APIMS)
• Air Force Environmental Management Information
  System (AF-EMIS)
• Hazardous Materials Management System (HMMS)
• Air Force Restoration Information Management
  System (AFRIMS)
• Multiple MAJCOM specific environmental databases,
  spreadsheets, etc
• Air Force Safety Automation System (AFSAS)

9
Overview

• Summary
• What are We Doing?
• Why are we Doing IT?
• Who is doing IT?
• When are We Doing IT?
• How do We Define Requirements?
• Issues?
• Conclusions

10
Summary

• Environment, Safety, and Occupational Health
  Management Information System (EESOH-MIS)
• Integrated
• Corporate
• Phased development/deployment of 16-18
  environmental applications

11
Summary

• Air Force Global Combat Support System -
  Information Framework (AF GCSS-IF) is the hosting
  agency
• Centrally hosted within AF GCSS-IF framework on
  DISA servers
• No downloaded components security issue
• Certificate of Networthiness (CON) and
  Certificates to Operate (CTOs) are not required
• Accessed through the Air Force Portal
• All test and implementation personnel must obtain
  their own password for https//my.af.mil
• Microsoft Internet Explorer (IE) 6.0 Browser

12
What are We Doing?

• EESOH-MIS
• improving standardizing business practices
• Integrated, multimedia system vs. multiple
  stovepipe systems
• Internal and external Air Force interfaces
• Is NOT an incremental adaptation and interfacing
  of existing legacy systems
• Strategic goals
• Integrated solution
• Adaptable
• Standardized
• Shared information

13
What are We Doing?
Architecture
14
Why are We Doing IT?

• Global Combat Support System - Air Force (AF
  GCSS-AF)
• Clinger-Cohen Act of 1996 (40 USC 1425)
• Web-based systems
• Commanders' NOTAM 00-5, 11 Sep 00, One Air Force,
  One Network
• JCS Capstone Requirements Document, 5 Jun 00
• Command, Control, Communications, Computers and
  Intelligence Support Plan (C4ISP)
• Certificate of Networthiness (CON)
• Certificates to Operate (CTOs)
• Air Force Portal

15
Why are We Doing IT?

• Global Combat Support System - Air Force
• A strong and robust ACS is key to the success of
  the EAF concept and supports the Air Force core
  competency of Rapid Global Mobility.
• Global Combat Support System - Air Force
  (GCSS-AF) is a key enabler of ACS and provides a
  framework for integrating our critical combat
  support information systems and processes
  across functional areas. It will provide
• the warfighter and supporting elements
• with timely, accurate, and trusted ACS
• information to execute the full
• spectrum of
  military operations.

16
Why are We Doing IT?

• Clinger-Cohen Act
• Ensure the interoperability of IT and national
  security systems throughout DoD
• Provide for the elimination of duplicate IT and
  national security systems within and between the
  military departments and Defense Agencies
• Ensure that IT and national security systems
  standards that will apply throughout the DoD are
  prescribed

17
Why are We Doing IT?

• Web-based System
• Commanders' NOTAM 00-5, One Air Force, One
  Network, 11 Sep 00
• providing every airman access to rich training
  resources, simple and intuitive self-service
  web-based tools, and the ability to communicate
  reliably, securely, globally all the time.
• JCS Capstone Requirements Document, 5 Jun 00
• The goal of GCSS is to operate in a web-based
  environment with shared data whereby corporate
  information is readily available to authorized
  users regardless of where the needed data is
  located.

18
Why are We Doing IT?

• C4ISP - Certifications
• Mandated by DOD regulation 5000.2-R
• Necessary requirements to ensure systems will be
  fully supportable once handed over to the
  operating community
• Looks at system-to-system interoperability,
  intelligence support, Joint Technical
  Architecture Air Force compliance, security and
  networthiness
• Certificate of Networthiness
• Describes the relative risks associated with
  fielding a networked system or application
• Certificates to Operate (CTOs)
• Single authorization to proceed with installation
  of the application on base networks - MAJCOM
  specific

19
Why are We Doing IT?

• Air Force Portal
• What is it?
• A gateway or major starting web site
• A web-based front-end to corporate information no
  matter where it resides
• Benefits
• Common interface and access point
• Provide targeted content to specific users
• Access to structured and unstructured data
• Why do we need it?
• Operational need
• Functional Users access to the information
  required to accomplish their mission
• Decision makers need the information now!
• Provides a catalyst for eliminating duplicate
  systems
• When will we have it? CSAF/SECAF 3 Jan 01 memo
• move all unclassified applications to the
  Air Force portal by 1 Jul 01
• How will we access it? httpsmy.af.mil
• Personalization within user role boundaries

20
BackgroundBenefits

• A revolutionary change in doing business
• Web-based front-end to corporate information
• Enables significant cost avoidance
• Developed to reduce operational costs
• Non-ESOH data stewarded by appropriate program
  manager
• Potential for greater exchange of information
• More consistent data
• Minimizes multiple entries of data
• Data Information Knowledge
• Informed decision making to the process owner

21
Architecture
As Is
To Be
Interim
Oracle 9i Unified DB
Oracle 8
Oracle 8
Oracle 8
Oracle 8
Oracle 8
Oracle 8 Site 2
Oracle 8 Site 1
CCS Site Server
Oracle Forms Server/ Oracle Web Cartridge
Web Server
LAN
Web Server
Middleware
Windows clients Oracle Net 8
GCSS-AF Framework
WAN
Independent Site Implementations
Independent Site Implementations
Independent Site Implementations
Browser Clients
Browser Clients
22
ESOH MIS Partnership

• Established a Memorandum of Agreement between
  AFCESA and AFMOA to jointly develop and implement
  ESOH-MIS, signed on 26 Apr 02
• Working with AFSC to include Safety into MOA
• ESOH CCB chartered as the focal point for
  ESOH-MIS automation initiatives
• Responsible for configuration management
• Change requests, upgrades, maintenance fixes, and
  new capabilities
• Integration of other software with ESOH-MIS
• Established a Shared FWG to review and resolve
  cross-functional issues

23
Training

• On-Line Web-Based Training
• Format Web-based self-guided tutorial
• Schedule Concurrent (part of software package)
• On-line tutorial will guide user through
  functions of each media submodule and each
  business practice
• Will include option of downloading text manuals
  which will include business practices instruction
  and tutorials

24
Training

• Business Process Training
• Format Pre-recorded VHS or DVD
• Schedule Coordinated with business practice
  evolution
• Focus on business practices (i.e., media
  management)
• Instruction to users on procedures and
  requirements for managing each environmental
  media program (e.g., Air, HazWaste, HazMat)
• Demonstration of how ACES-EM supports management
  of environmental media

25
ESOH CCB

• Current Co-Chairs AFMOA/SGZ and AFCESA/CEO
• Working to Incorporate AFSC
• Current Members
• AFCESA/CEO, AF/ILEV, AFMOA/SGZE, AFIERA/RS
• Non-Voting Representatives
• SSG/BICE
• 75 MDG/SGPB
• FUG/FWG Leads
• Northrop Grumman (Formerly TRW)

26
Who is Doing IT?
System Integration
27
Who is Doing IT?

• ACES Automation Steering Group (ASG)
• AF/ILE-2 Chairs with MAJCOM representation
• Provides strategic direction
• ACES Configuration Control Board (CCB)
• AFCESA/CEO chairs with MAJCOM representation
• Technical arm of the ASG
• Provides configuration management of CE standard
  systems
• ACES Environmental Integrated Process Team (IPT)
• AFMC/CEVO Chairs with MAJCOM representation
• Functional working group representing the Civil
  Engineering community
• Defines system requirements

28
Who is Doing IT?

• Base, MAJCOM, and AF/ILEV representatives formed
  groups to models the business process of every
  environmental program
• Everything evolves around the business process
• The act of doing something with something
• Define boundaries (starting and ending points)
• Describe where to collect data

29
Who is Doing IT?
Management Organization
30
Status
31
When are We Doing it?
32
When are We Doing IT?
Schedule
33
How Do We Define Requirements?
34
How Do We Define Requirements?
System/Software Process Flow
SRR/SDR
Requirements Definition
Project Startup
Design and Development (Build)
System Acceptance
Project Startup
System Requirements Analysis
System Design
Software Requirements Analysis
Software Design
CSCI/HWCI Integ Test
CSCI Quality Test
Unit Integrate Test
SW Implement Unit Test
System Qualification Test
IEM Standard Process Flow
Customer

• System Req. Review
• SW Specification
• Review

• System Req.
• Contract

• SW Design Review

• Test Readiness
• Review

• System Acceptance

• Approved SW Req.
• Approved Sys. Design

• Agreement to Proceed

• Accepted Test Plans,
• Procedures

System Engineering

• System Req. Analysis
• Allocation (1.2.1)
• System Design (1.2.2)

• System Engineering
• Mgmt. Plans (1.1)

• Eng. Dev.
• Plans (1.2)

• SW Req. Analysis Allocation (1.2.1)

SW Eng. Development

• Implement (1.2.3)

• Unit/Component
• Test (1.2.4)

• Integrate SW Components 1.2.5)

• Qualify Software (1.2.6)

• SW Design (1.2.2)

• Maintain Dev.
• Files (1.1.17)

• Maintain Dev.
• Files (1.1.17)

• Maintain Dev.
• Files (1.1.17)

System Integration Test

• Acceptance Test
• Plan (1.2.8)

• Develop Acceptance
• Procedures (1.2.8)

• Integrate
• System
• (1.2.5)

• Acceptance
• Test (1.2.8)

Baseline Management

• Product
• Baseline
• System
• PCA/FCA

• SW Design Baseline (1.1.7)

• SW
• PCA/FCA

• Software Baseline

Project/Engineering Management (1.1) Risk
Management (1.1.13) Mgmt. And Technical Reviews
(1.1.10, 1.1.11) Subcontract Management (1.1.18)
Requirements Management (1.1.12) Configuration
and Data Mgmt. (1.1.14) Quality Assurance
(1.1.15) S/SEPG (1.1.1) Training (1.1.19)
35
AFCESA Project Managers IPT Chair Reqmts Flow
Chart
Valid? IPT Chair Members
ACES PMO CSRD Prepared
Yes
Requirement User, MAJCOM, HQ, Policy, IPT
ACES PMO Assigns Tracking Number
No
PMO report back to requirement generator
Developer Tech Solution
ACES PMO Assess work, minor maint, major
CCB Approval and Priority
Major request
ACES PMO Fund, work with dev on schedule
Developer
Minor maintenance
36
(No Transcript)
37
(No Transcript)
38
(No Transcript)
39
(No Transcript)
40
(No Transcript)
41
(No Transcript)
42
(No Transcript)
43
(No Transcript)
44
Phase 1

• Issue Significant Schedule Delay and Cost
  Increase
• Schedule Delay (HazMat delay 6 month)
• User testing process (Agile vs Waterfall)
• Application Development Problems
• GCSS-AF Staging
• Concept changes
• Cost Increase (Double original estimated cost)
• GCSS-AF Development Support
• Requirements Definition, Capture, and Increase
• Training
• Data Migration
• More Complex Than Originally Thought

45
Issue?

• Business Modernization Management Program (BMMP)
• This program is chartered to
• Transform and modernize business processes across
  DoD
• Standardize and integrate processes enabled by
  technology and systems
• Capitalize on DoD strengths and infuse leading
  practices into DoD operations

46
Issue?
The Vision The Department of Defense will be
managed in an efficient, business-like manner in
which accurate, reliable, and timely financial
information, affirmed by clean audit opinions, is
available on a routine basis to support informed
decision-making at all levels throughout the
department. Secretary of Defense Donald
Rumsfeld
DoD Domain Areas
Logistics
Acquisition/Procurement
Installations and Environment
Human Resource Management
Finance,Accounting Operations Financial
Management
Strategic Planning Budgeting
Technical Infrastructure

• Fewer spent on business processes and systems
  more available for the war fighting mission
• Men and women in uniform have what they need when
  they need it
• Congress is told, with confidence, where are
  being spent in DoD

47
Issue?

• Business Modernization Management Program (BMMP)
• Development of an enterprise architecture - A
  list of business, technical and systems
  requirements
• End-to-end business scenarios - Functional
  business process validation
• A transition plan - Lays out the key high level
  tasks which must be accomplished to implement the
  architecture
• Activities, business rules and requirements in
  the architecture have been grouped by business
  area, or domain
• Domain leaders will lead the transformation

48
Issue?

• Transition Plan to To-Be Environment

49
Schedule Delays

• User Testing Process
• Agile Development requires greater user
  participation while development continues (Went
  to Waterfall for Testing)
• Agile Development proved too complex for Users
• (Requiring greater application maturity)
• FWG did not review functioning application before
  Beta
• (Built in Review by FWG for testing prior to
  Beta)
• Hosted on EESOH.COM instead of AF-Portal limiting
  number of simultaneous users (Requested proposal
  for increased server bandwidth from NGMS)
• .

50
Schedule Delays

• Application Development Problems
• Did not incorporate all of the requirements
  expected by the users (Imposed more rigid change
  process)
• The requirements have been further refined and
  defined (Requiring use of website CM tool)
• The Hazardous Material Focus Working Group met
  week of March 29th to validate incorporation of
  the minimum expected requirements prior to
  re-initiating Beta testing
• (Additional FWG testing for HM Most complex
  Contains common components)

51
Schedule Delays

• GCSS-AF (fully  compliant software application)
• GCSS procedures inadequate to bring about the
  hosting at the beginning of the year (NGMS
  developed hosting procedures and provided on-site
  assistance)
• Single Sign-on issues which must be resolved
  (NGMS developed procedures and provided on-site
  assistance)
• Concept Changes
• Originally AF-EMIS replacement became replacement
  for HMMS
• Included Cleanup
• Expanded from replacement to APIMS

52
Corrective Actions

• Requirements training being conducted for Focus
  Working Groups
• Implemented monthly management meetings
• Instituted rigorous Change Management process
• Incorporating Earned Value to obtain better
  estimates

53
Conclusions

• Integrated, corporate, Management Information
  System
• AF GCSS IF as the hosting agency
• All test and implementation personnel must obtain
  their own password for https//my.af.mil
• Phased development/deployment of 18 applications
• Phase 1 will be completed by May 04
• Phase 2 begin in FY04
• Cultural Resources Management module in
  requirements identification stage
• Get Involved
• Think outside the box

54
Cult Res FWGMethodology

• Explain how your FWG operated
• Meetings
• Telecons/VTCs
• Comments via RAD tool
• Etc...
• Explain what methods your FWG used to arrive at
  the final list of data requirements and business
  rules

55
Cult Res FWGManagement Challenges

• No Policy Guidance on Data Maintenance
• Data are maintained at installation level
• No centralized repository for QA/QC, back-up
• No Standard Format
• Data are often in state-specific or ad hoc
  formats
• Reporting Needs
• Installation Level to state agencies
• Up the Chain of Command

56
Cult Res FWGManagement Challenges

• Goals
• Create Guidance, protocols, metadata, and
  database structures
• Allow easy cultural resource data sharing
  within and among bases, commands, service
  HQs, and other agencies, including desktop
  GIS viewing
• Data formats vary by state
• Data classes include
• Historic Properties
• Artifact Collections
• Events
• Documents

57
Cult Res FWGData Requirements

• List of data elements with field descriptions (if
  possible)
• If too numerous to list all, group data
  requirements into logical groups with examples

58
Cult Res FWGBusiness Rules

• Business rules describe how data elements work
  together to create a functional module
• If too numerous or complex to show all, give some
  examples to highlight some specific processes or
  problems

59
Cult Res FWGDefining Processes

• Business rules describe how data elements work
  together to create a functional module
• If too numerous or complex to show all, give some
  examples to highlight some specific processes or
  problems

60
Process National Register Eligibility/ Listing

• Business rules describe how data elements work
  together to create a functional module
• If too numerous or complex to show all, give some
  examples to highlight some specific processes or
  problems

61
Process Archeological Site Treatment

• Business rules describe how data elements work
  together to create a functional module
• If too numerous or complex to show all, give some
  examples to highlight some specific processes or
  problems

62
Cult Res FWGDefining Processes

• Business rules describe how data elements work
  together to create a functional module
• If too numerous or complex to show all, give some
  examples to highlight some specific processes or
  problems

63
Process Historic Building Maintenance and
Treatment

• Business rules describe how data elements work
  together to create a functional module
• If too numerous or complex to show all, give some
  examples to highlight some specific processes or
  problems

64
Cult Res FWGDefining Processes

• Business rules describe how data elements work
  together to create a functional module
• If too numerous or complex to show all, give some
  examples to highlight some specific processes or
  problems

65
Cult Res FWGDefining Processes

• Business rules describe how data elements work
  together to create a functional module
• If too numerous or complex to show all, give some
  examples to highlight some specific processes or
  problems

66
Cult Res FWGDefining Processes

• Business rules describe how data elements work
  together to create a functional module
• If too numerous or complex to show all, give some
  examples to highlight some specific processes or
  problems

67
(No Transcript)
68
(No Transcript)
69
(No Transcript)
70
(No Transcript)
71
(No Transcript)
72
(No Transcript)
73
(No Transcript)
74
(No Transcript)
75
(No Transcript)
76
(No Transcript)
77
(No Transcript)
78
(No Transcript)
79
NHPA Section 106
NEPA/EIAP
Process
Describe Undertaking And Area of Potential Effects
Describe the Action
AF Fm 332
Work Order
AF Fm 813
Request for EIAP Analysis
Potential Effects to Historic Properties?
Screen for Threshold of Analysis
Categorical Exclusion
Identify Consulting Parties
Identify Resources Consulting Parties
Environmental Assessment
Identify Historic Properties
Scoping
Consult on Inventory Results
Finding of No Significant Impact
Evaluate Historic Properties
Prepare Draft Environmental Impact Statement
Determine Impacts
Review Draft Environmental Impact Statement
Consult on Impact Determinations
Apply Criteria of Adverse Effect
Consult on Mitigation Options
Resolve Adverse Effects
Failure to Resolve Adverse Effects
Final Environmental Impact Statement
Memorandum of Agreement
Formal Council Comments
Agree on Mitigation
Record of Decision
PROJECT PROCEEDS
80
CERCLA/ERA
Interagency Resource Letter
Cultural Resource Survey Needed?
Stage IA Survey
Further Investigation Recommended?
Stage IB Survey
Further Investigation Recommended?
Remedial Investigation/ Feasibility Study
Stage II Survey
National Register Eligibility?
Evaluate Impacts
Develop/implement Mitigation Measures
Record of Decision
Remediation Decision/ Remedial Action
81
DECISION MODEL FOR ARCHEOLOGICAL SITE
IDENTIFICATION AND EVALUATION (draft)
82
Compliance andReporting Requirements

• National Historic Preservation Act, Section 106
• Federal Archeological Report
• Native American Graves Protection and
  Repatriation Act
• Archeological Resources Protection Act
• DoD Measures of Merit/ DUSD/IEE Report
• ESOHCAMP
• National Register of Historic Places (Property
  List)
• Heritage Assets Accountability

83
Database Structure

• Tri-Service (now CADD-GIS Technology Center)
  Spatial Data Standards used for starting point
• Intensely evaluated approaches in 17 states
• Attended FGDC subcommittee and interagency
  Cultural Resource Working Group meetings
• Selected Arizona model as kernel
• Initial end product (2002) is an Oracle
  relational model

84
Database Structure
Field Mapping Between Data Models to Develop
Tables and Fields
85
Database Structure
86
Database Structure
mCRAD Military Cultural Resources Analysis
Database
42 Data Tables 31 Domain Tables
87
mCRAD Themes
88
Cult Res FWGApplication Development

• Show examples screens of what you are trying to
  emulate (if possible)

89
Cult Res FWGSample Screenshots

• Show examples screens of what you are trying to
  emulate (if possible)

90
Cult Res FWGSummary

• Comments on process
• Recommendations
• Areas needing additional work
• If CSRD is not ready for submittal, explain your
  plans for future work
• Give milestones to completion of requirements
  definition

91
mCRAT Military Cultural Resources Analysis Tools

• In Development
• Retrieve and display
• data in desktop GIS format
• Focus on basic steps
• Display site locations
• Query each site for data
• Site form, photos, diagnostic artifacts
• Testing pattern, related reports

92
Prototype MCRAD Viewer
93
Ongoing Efforts

• Integrate into SDSFIE Cultural Resources
  Standards
• Integrate in USAF Automated Civil Engineering
  System (ACES-EM)
• Fill gaps in data model (e.g., Measures of Merit)
• Improve functionality
• Continue data population
• Develop report generation capability
• Develop analysis capability
• Integrate with other MAJCOMs, services
• Address web deployment, security, intellectual
  property issues

94
Data Integration

• Initial data integration
• Avon Park AFR, Beale AFB, Langley AFB
• Diverse Cultural Resources
• Expanded to Army and Navy Installations in
  Virginia
• Obtained data from bases, contractors
• Validated data for content and geospatial
  accuracy
• Entered data into new database structure
• Validated or created metadata

95
MCRAD Parsons Support

• HQ ACC task, through Ft Worth CoE
• Dr. Brian Crane is POC, Fairfax VA
• Supported project since 1998
• Current tasks
• FWG Website
• Update MCRAD documentation
• Maintain list of members share info
• Maintain communication, host meetings
• Develop process flow diagrams
• Prepare summary table of MCRAD structure
• Summary report

96
XXXXXX FWG Summary

• Comments on process
• Recommendations
• Areas needing additional work
• If CSRD is not ready for submittal, explain your
  plans for future work
• Give milestones to completion of requirements
  definition

97
(No Transcript)
98
Backup Information