San Francisco International Airport AIRLINE PASSENGER ...mission.sfgov.org/OCA_BID_ATTACHMENTS/FA49279.pdf · International (ACI) passenger count. SFO has four terminals (1, 2, 3,

San Francisco International Airport

AIRLINE PASSENGER PROCESSING SYSTEM (PPS)

PROJECT

SCOPE OF WORK

SFO Passenger Processing System Project

Scope of Work Page 2 of 55

TABLE OF CONTENTS

1.0 Introduction ............................................................................................................ 5

1.1 Project Overview .............................................................................................................. 5

1.2 Project Objectives ............................................................................................................ 7

1.3 Project Expansion ............................................................................................................ 7

1.4 Scope of Work Overview.................................................................................................. 8

1.5 Related Projects ............................................................................................................... 8

2.0 Reference Documents ........................................................................................ 10

3.0 Terms and Acronyms.......................................................................................... 10

4.0 Roles and Responsibilities ................................................................................ 17

5.0 Project Management Requirements.................................................................. 24

5.1 Project Management Plan .............................................................................................. 24

5.2 Project Execution ........................................................................................................... 25

5.3 Project Closeout Requirements ..................................................................................... 26

6.0 Discovery/System Requirements Validation ................................................... 28

6.1 General Requirements ................................................................................................... 28

6.2 Shared Use System and CUSS Kiosks ......................................................................... 28

6.3 AODB ............................................................................................................................. 28

6.4 RMS ................................................................................................................................ 29

6.5 System Requirements Review ....................................................................................... 30

7.0 System Design ..................................................................................................... 30

8.0 Hardware and Software Procurement .............................................................. 33

9.0 System Installation and Test ............................................................................. 33

9.1 Installation and Test Overview ....................................................................................... 33

9.2 Test Lab Environment Installation ................................................................................. 34

9.3 Preliminary Acceptance Test – Test Environment ........................................................ 35

9.4 Training Environment Implementation ........................................................................... 36

9.5 Validation Testing in Training Environment ................................................................... 37

9.6 Production Staging Environment Implementation ......................................................... 38

9.7 Validation Test in Production Staging Environment ...................................................... 38



9.8 Server Implementation in Primary and Secondary Production Environments .............. 39

9.9 Validation Test in Production Environments .................................................................. 40

9.10 Cutover Readiness Review ............................................................................................ 40

9.11 System Cutover .............................................................................................................. 40

9.12 Endurance Test .............................................................................................................. 40

9.13 Final System Acceptance............................................................................................... 42

10.0 Technical Resource ............................................................................................ 42

11.0 Expansion/Professional Services (Optional) ................................................... 43

12.0 Testing .................................................................................................................. 43

12.1 Test Activities ................................................................................................................. 43

13.0 Training ................................................................................................................. 44

13.1 General ........................................................................................................................... 44

13.2 Types of Training............................................................................................................ 45

14.0 Submittals and Documentation ......................................................................... 47

14.1 Submittal Media Requirements ...................................................................................... 47

14.2 Submittal Quantities ....................................................................................................... 47

14.3 Submittals ....................................................................................................................... 47

14.4 Submittal Schedule ........................................................................................................ 51

15.0 Warranty/Maintenance Services ........................................................................ 52

15.1 1st Level Maintenance ................................................................................................... 53

15.2 2nd Level Maintenance .................................................................................................. 53

15.3 Software Maintenance ................................................................................................... 54



TABLE OF TABLES

Table 1 Project Lifecycle Roles & Responsibilities.......................................................... 18

Table 2 Submittal Delivery Schedule ............................................................................... 51

TABLE OF FIGURES

Figure 1 SFO Terminals and Boarding Areas ................................................................... 5

Figure 2 Future Organization Chart ................................................................................. 18

Figure 3 Training Lab ....................................................................................................... 37



1.0 INTRODUCTION

1.1 Project Overview

San Francisco International Airport (“SFO,” of “Airport”) is an international Airport 13 miles

(21 km) south of downtown San Francisco, California, United States, in San Mateo

County. It has flights to points throughout North America and is a major gateway to Europe

and Asia. SFO is the largest Airport in Northern California and the second busiest in

California, after Los Angeles International Airport. In 2014, it was the seventh busiest in

the United States and the twenty-fifth busiest Airport in the world by Airports Council

International (ACI) passenger count.

SFO has four terminals (1, 2, 3, and International) and seven concourses arranged

alphabetically in a counterclockwise ring. Terminal 1 (Boarding Areas B and C), Terminal

2 (Boarding Area D), and Terminal 3 (Boarding Areas E and F) handle domestic flights

(including pre-cleared flights from Canada). The International Terminal (Boarding Areas

A and G) handle international flights and some domestic flights.

Figure 1 SFO Terminals and Boarding Areas

The changing nature of the airline industry and the business environment require SFO to

be a flexible environment allowing any combination of preferential use and shared use

resources. The type of use designated for a resource will change over time and the IT



environment must be sufficiently flexible and scalable to support this change quickly and

cost effectively. To facilitate this flexibility, a set of Integrated Systems (referred to as the

“Passenger Processing System Project, or “PPS Project”) will be deployed including:

1. Shared Use System

a. Check-in and boarding functions

b. Local Departure Control System

2. Common Use Self Service Kiosks

3. Resource Management System

4. Airport Operational Database

The hardware in the ITB was recently upgraded for all passenger processing workstations

and some associated equipment. This project will consist of implementing new server

hardware (either on-premise or off-site) and all software associated with these systems

to support existing locations. However, software licenses will be enterprise wide and

support all potential users at the entire Airport. The end user devices and peripherals in

the ITB will be reused. Following successful implementation in the ITB, systems will then

be expanded in to include all terminal buildings in a schedule developed by SFO

management. This optional expansion may include the provision of new end user devices

and peripherals and implementation support from the contractor.

Airport Operational Database Services (AODB) comprise an integrated set of capabilities

that support real-time messaging, storage and retrieval of information from all PPS related

systems. It provides service capabilities that represent the master source of all flight data.

The AODB solution must provide a REST API for data and service integration to the

Airport’s enterprise domain data structure and the contractor must provide on-going, on-

site technical resource to further develop direct data and service integration.

A Resource Management System (RMS) will be provided to assist SFO Operations in

assigning resources including gates, ticket counters, baggage claim carousels, baggage

makeup conveyors and remote aircraft parking. The RMS will provide planning functions,

‘best fit’ recommendations, and real-time conflict warnings to assist SFO Operations in

the management of these resources.

The Shared Use System (SUS) will allow multiple airlines to operate at a particular

location (gate or ticket counter position) using either a browser based web client,

CUTE/CUPPS applications, and/or virtualized airline application of choice, with a

common set of compatible hardware, increasing the flexibility and efficiency of the facility.

Contractor’s solution must support all three (3) technologies. An integrated Local

Departure Control System (LDCS) will facilitate charter operators and other airlines and

carriers who do not have access to a departure control system when operating at SFO.



Common Use Self-Service (CUSS) kiosks will be situated in various locations throughout

the facility to assist in the check-in function. The Common Use Self-Service (CUSS) will

allow multiple airlines to operate the kiosks using airline CUSS compliant applications, a

browser based client, and/or an API driven, standard user interface browser based client

provided by the contractor. The Airport Operational Database (“AODB”) is the heart of

the integrated systems and will support real-time data warehousing and retrieval of data

from PPS related systems.

The Integrated Systems, all Ethernet-based, will use passive (cabling and pathway) and

active (local area network) components being provided as part of the SFO Premises

Distribution System (PDS). Unless directly specified, the installation of an SFO passive

communications infrastructure (cable plant and pathway) and active communications

infrastructure (local area network equipment) will be provided by SFO. The solution’s

application servers may be hosted on-site in SFO data centers or may be hosted off-site

at contractor’s hardened data centers or a hybrid combination of the two.

1.2 Project Objectives

SFO wishes to achieve the following objectives through the implementation of this project:

1. Provide the most advanced, reliable, flexible and forward looking shared use

technology which encourages Airline use and enhances the passenger

experience.

2. Maximize use and flexibility of flight operations, resources and facilities.

3. Acquire technology that provides SFO the flexibility to expand in the future.

4. Implement a support solution that provides high levels of service and continuous

operations.

5. Provide greater operational visibility and resource maximization.

6. Implement one solution for the entire Airport.

7. Implement a solution and pricing model that is financially appealing to the airlines

and the Airport.

1.3 Project Expansion

1. This procurement incorporates implementation activities primarily in the ITB but

includes priced options for expansion services.

2. This project focuses on the ITB and replacing the existing systems. A few locations

in the other terminals that are supported by these systems today are also included.

SUS Hardware and CUSS kiosks in the ITB were recently upgraded. The scope of

this project includes implementing new server hardware, COTS software and all

application software associated with the systems in the ITB. Software licenses will



be enterprise wide and perpetual. The end user devices, and peripherals in the

ITB will be reused. The Contractor will need to provide only enough hardware to

ensure adequate sparing for the ITB operations and maintenance.

3. Following successful implementation in the ITB, it is anticipated systems will be

expanded to include all terminal buildings, subject to a schedule to be developed

by SFO management. Later implementations will include T1, which is currently

undergoing renovation. The extent of shared use in T1 is still being determined,

but the following scope will be included:

a. a portion of the check-in area and the gates will use the shared use passenger

processing technology;

b. AODB and RMS will be expanded to include the management of all shared use

resources in T1; and

c. Common Use Self Service Kiosks will be deployed in T1.

4. The contractor will provide optional unit pricing to support new hardware and its

implementation throughout the Airport. No additional application software licensing

fees will be required.

1.4 Scope of Work Overview

At a minimum, the scope of work includes the following:

1. Project Management

2. Requirements Validation

3. Design

4. Hardware

5. Software

6. Implementation

7. Testing

8. Training

9. Cutover

10. On-going, on-site technical resource

11. Submittals

12. Warranty/Maintenance

1.5 Related Projects



Terminal 1 Center and Boarding Area B

1. The T1 Center is a complete renovation of the check-in lobby, security

checkpoint and boarding area for Terminal 1. The project will be executed

in three (3) phases, which will eventually result in a new, twenty-four (24)

gate multi-airline terminal. The T1 phases will be executed over the next

five (5) years, with the first nine (9) gates in Boarding Area B (BAB) opening

in Quarter 1 of 2019.

2. The T1 Program is staffed with two design/build teams, with T1C’s Design

Build team led by Hensel Phelps (HP), and BAB led by an Austin

Commercial and Webcor (AW) joint venture. Both HP and AW have

selected Rosendin Electric as their Special Systems Core Trade (SSCT).

Rosendin Electric will be responsible for the execution of all PPS related

systems in T1.

3. All applications procured under the PPS contract must be sized to support

the entire T1 terminal operations. All hardware and support services will be

procured through the T1 program, but the applications will be driven by the

head end systems of the PPS. SFO may choose to exercise options under

the PPS contract to support implementation in T1.

Information Display System

1. SFO will procure a new Information Display System (“IDS”) supporting all

Airport display requirements. The IDS will also support Americans with

Disabilities Act (ADA) requirements for broadcasting public messaging

information to the traveling public in visual format, visual paging, as a

supplement to the audio broadcast system provided by others. This

information will include public announcements, personal pages, and flight

information specific to individual gate areas. The IDS will also support

commercial advertising, news broadcasts, full motion video displays and

wayfinding displays. The PPS Contractor is responsible for integrating with

the 3rd party IDS to allow agents to control displays above the ticket and

gate counters from the PPS workstations.

Revenue Enhancement and Customer Hospitality (REACH)

1. The REACH program will include interior design upgrades and technical

enhancements to some areas of the ITB. It is scheduled for substantial

completion at the end of 2018, with detailed design taking place in 2017.

Terminal 3 West



1. The Terminal 3 West (“T3W”) project will renovate the remaining portion of

the Terminal 3 check-in lobby that was not addressed during the T3 East

project, and will also renovate portions of Boarding Area F (BAF). This

terminal and boarding area are exclusively used by United Airlines, and only

contain a single common use check-in location that is included in the scope

of PPS project.

2. It is not currently anticipated that the T3W project will require additional

shared use passenger processing workstations for check-in counters or

gates.

Airport Information Integration Solution (AIIS)

1. The Airport’s ITT group will procure an AIIS platform which is scheduled for

Quarter 4, 2017. The objectives of the solution are to realize business

transformation capabilities through interconnected systems, centralized

collection of data, analysis and the electronic distribution of information. The

Contractor will be responsible for coordinating PPS integration with the AIIS

by making PPS data available for collection and analysis.

On-Going Enterprise Network Enhancements

1. The Airport’s distribution and Data Center networks are being upgraded with

new Juniper equipment on an on going basis. Current projects include: Data

Center upgrade project, access switch refresh, SONET ring upgrade

project, Cisco PPS9K distribution and core switch replacement project.

Additional data on these projects will be delivered to the PPS Contractor

following award of contract.

2.0 REFERENCE DOCUMENTS

Passenger Processing System - System Specification Document (SSD)

PMI PMBoK v5.

3.0 TERMS AND ACRONYMS

Acronym Full Phrase Brief Description

A-VDGS Advanced Visual

Docking Guidance

System

Intelligent Sensors and system to collect and

distribute real-time gate and flight data.




ADA Americans with

Disabilities Act (2008)

An Act of Congress signed into law in September

2008 modifying the ADA (1990), which prohibits,

under certain circumstances, discrimination

based on disability.

AIIS Airport Information

Integration Solution

A software architecture model used for

interconnecting information systems, centralizing the

collection of data and the analysis and distribution

information.

AODB Airport Operational

Database

A single database used to store flight schedules,

resource assignments, and other Airport data.

AOS Airport Operational

Services

A composite of solution services comprising business

services, user interfaces and a centralized database

used to store and share flight schedules, resource

assignments, and other Airport data with other

Airport systems.

API Application

Programming Interface

A set of routines, protocols, and tools for building

software applications.

ATP Acceptance Test Plan A plan with test objectives and test procedures to

test all system and functional requirements in

order to accept the system.

AVI Automatic Vehicle

Identification

Technology that uses optical character

recognition on images to read vehicle registration

plates.

BHS Baggage Handling

System

A physical conveyer transportation system for

Airport baggage between the check-in positions

and airside baggage makeup.

BIC Baggage Input Console Device used by baggage handlers to input the

flight number of bags being unloaded and put

onto a baggage carousel

BPP Boarding Pass Printer Device for printing a boarding pass at Airport

check-in or kiosks

https://en.wikipedia.org/wiki/Software_architecture

https://en.wikipedia.org/wiki/Optical_character_recognition

https://en.wikipedia.org/wiki/Optical_character_recognition

https://en.wikipedia.org/wiki/Vehicle_registration_plate

https://en.wikipedia.org/wiki/Vehicle_registration_plate




BTP Bag Tag Printer Device for printing bag tags at Airport check-in or

kiosks

BSM Baggage Source

Message

Message with specific format for notifying airline

systems and baggage handling systems of bag

tags that have been issued.

CD Compact Disc Storage media which may be used for delivery of

electronic documentation

COTS Commercial Off-the-

Shelf

Software application that is built ready-made for

sale by a vendor. The software can be enhanced

by user, when necessary.

CRR Cutover Readiness

Review

A system life cycle review used to determine the

readiness of systems to move from test to

operational production capabilities

CUPPS Common Use Passenger

Processing System

Software and hardware standards designed to

allow a single passenger processing station to

serve multiple airlines. These standards overhaul

the original Common Use Terminal Equipment

(CUTE) standards.

CUSS Common Use Self-

Service

Software and hardware standards developed to

allow a single self-service kiosk to serve multiple

airlines.

DBMS Data Base Management

System

Software system used for storing and retrieving

data in the system

DDC Digital Device Controller PC attached to a display device for controlling the

content of that display

DVD Digital Video Disc Storage media which may be used for delivery of

electronic documentation

Gantt A type of bar chart,

devised by Henry Gantt

in the 1910s, that

Chart that illustrates a project schedule showing

start and finish dates of terminal elements and

summary elements of a project.




illustrates a project

schedule.

GIDS Gate Information

Display System

Displays at Airport departure gates which provide

information on departing flights, weather at

destination city , waitlists, etc.

HVAC Heating, Ventilation,

and Air Conditioning

The mechanical devices used to heat, cool, and

exchange air in an Airport to provide a

comfortable, healthy environment.

IATA International Air

Transport Association

The international association whose membership

is airlines.

ICD Interface Control

Document

Document used to define the design of interfaces

between two systems

IDS Information Display

System

A display system that portrays flight information,

gate assignments, advertising, wayfinding, visual

paging and other information as required.

IOC Initial Operating

Capacity

The point in time a system(s) goes live in an

operational environment

IT Information Technology The study, design, development,

implementation, support, and management of

computer-based information systems,

particularly software applications and computer

hardware.

ITB International Terminal

Building

The Airport terminal where the systems will be

installed

ITT Information Technology

and

Telecommunications

The Airport organization at responsible for

overseeing all information technology systems

and infrastructure installed at the Airport

LAN Local Area Network A computer network covering a smaller physical

space, such as an Airport terminal, without the

need for long-distance cabling




LDCS Local Departure Control

System

A check-in system that manages passenger seat

assignments, baggage, and boarding for airlines.

LEC Local Exchange Carrier A regulatory term in telecommunications for the

local telephone company.

MAC Moves, Adds, and

Changes

An alteration of Airport network indicating that

cabling has been added, moved, or altered.

MPEG Moving Picture Experts

Group

A working group of authorities that was formed

to set standards for audio and video compression

and transmission.

MPOE Main Point of Entry The demarcation point at which the public

switched telephone network ends and connects

with the customer's on-premises wiring.

NOC Network Operations

Center

Location where a network’s day to day

operations is managed.

NTP Notice To Proceed Notice given to a Contractor that they may

proceed to start work on a project.

O&M Operations &

Maintenance

A life cycle phase of a system after successful

implementation.

PDS Premises Distribution

System

The planned physical cabling system designed to

transmit voice and data within a campus.

PPS Passenger Processing

System Project

SFO has designated this as the name for this

project to replace existing systems at the Airport

PMP Project Management

Plan

A document used at the start of the

implementation phase to organize the work

associated with building a system.

RAID Ramp Area Information

Display

Displays housed in baggage make up areas and

other locations on the apron level that provide

flight related data to ramp personnel.

https://en.wikipedia.org/wiki/Regulatory

https://en.wikipedia.org/wiki/Telecommunication

https://en.wikipedia.org/wiki/Working_group

https://en.wikipedia.org/wiki/Experts

https://en.wikipedia.org/wiki/Audio_compression_(data)

https://en.wikipedia.org/wiki/Video_compression

https://en.wikipedia.org/wiki/Public_switched_telephone_network

https://en.wikipedia.org/wiki/Public_switched_telephone_network

https://en.wikipedia.org/wiki/On-premises_wiring




RIDS Ramp Information

Display System

A system that displays flight, gate, and other

pertinent information to ramp crews via exterior

dynamic signs and monitors.

RMS Resource Management

System

A computer system that uses the planned flight

schedule and operational updates to allocate

check-in counters, gates, and bag belts to certain

flights. It is often used in conjunction with a

common use system.

SDD System Design

Document

Life cycle document that describes the detailed

design of a system

SDR System Design Review A life cycle review to review the design of a

system

SFO San Francisco

International Airport

Airport owned and operated by the City and County

of San Francisco, California and situated in San Mateo

County, California.

SIEM Security Information

and Event Management

Software products and services combine that

security information management (SIM) and

security event management (SEM). They provide

real-time analysis of security alerts generated by

network hardware and applications.

SMI System Manager

Interface

Interface to a system management module for

administrators to manage an application

SPCR Software

Problem/Change

Request

Document that describes a problem or a

requested change to a software application

SRR System Requirements

Review

Life cycle review that reviews the documented

requirements of a system.

SSD System Specification

Document

High level system architecture and requirements

document.

SSR Special Service Room A room where a business houses servers and

wiring, which may serve as a distribution point for

multipair cables from the main distribution frame

https://en.wikipedia.org/wiki/Security_information_management

https://en.wikipedia.org/wiki/Security_event_manager

https://en.wikipedia.org/wiki/Main_distribution_frame




SUS Shared Use System System that allows airlines to operate on a shared

hardware environment. Airlines may use their own

browser based web client, virtualized proprietary

applications, or IATA CUTE/CUPPS applications, or an

LDCS application. For detailed

description/requirements see SSD Section 11.3.

T1 Terminal One One of the Terminals at SFO Airport

T1C Terminal 1 Center Center area of Terminal 1 at SFO

T3W Terminal 3 West Area of Terminal 3 at SFO

TDM Time Division

Multiplexing

A method of transmitting and receiving

independent signals over a common signal path

by means of synchronized switches at each end

of the transmission

TRR Test Readiness Review A life cycle review to ensure a system is

implemented and ready for acceptance testing

USB Universal Serial Bus An industry standard that defines the cables,

connectors and communications protocols used

in a bus for connection, communication, and

power supply between computers and electronic

devices

VLAN Virtual Local Area

Network

The virtual segregation of a single physical LAN

into multiple LANs operating on the same

infrastructure.

VM Virtual Machine An emulation of a particular computer system.

Virtual machines operate based on the computer

architecture and functions of a real or

hypothetical computer, and their

implementations may involve specialized

hardware, software, or a combination of both.

https://en.wikipedia.org/wiki/Technical_standard

https://en.wikipedia.org/wiki/Communications_protocol

https://en.wikipedia.org/wiki/Bus_(computing)

https://en.wikipedia.org/wiki/Computer

https://en.wikipedia.org/wiki/Emulator

https://en.wikipedia.org/wiki/Computer_architecture

https://en.wikipedia.org/wiki/Computer_architecture

https://en.wikipedia.org/wiki/Computer_hardware

https://en.wikipedia.org/wiki/Software




VRF Virtual Routing and

Forwarding

A technology that allows multiple instances of a

routing table to co-exist within the same router

at the same time.

WAN Wide Area Network A computer network covering a vast area, in

contrast to a LAN. WANs often require leased

external cables and stretch over distances

measured in miles.

WBS Work Breakdown

Structure

A work breakdown structure, in project

management is a deliverable-oriented

decomposition of a project into smaller

components. It is a key project deliverable that

organizes the work into manageable sections.

WS Workstation A workstation is a special computer designed for

technical or scientific applications. Intended

primarily to be used by one person at a time, they

are commonly connected to a local area network

4.0 ROLES AND RESPONSIBILITIES

The parties using PPS applications are as follows:

1. Airport ITT – primarily responsible for LAN, server, system administration and

support.

2. PPS Technology Contractor – responsible for designing, providing and

maintaining PPS applications.

3. Airlines – primary users of Shared Use System and provider of flight information

to the Airport.

4. SFOTEC – Private contractor responsible for day to day use and resource

allocation using the PPS applications, and any successor.

5. PPS Support Contractor - Responsible for Level 1 Maintenance activities for PPS

systems.

6. Global Network Operations Center (GNOC) – 24/7 call center responsible for

taking all airline calls associated with the PPS systems, creating trouble tickets

and forwarding to the appropriate party for resolution.

https://en.wikipedia.org/wiki/Routing_table

https://en.wikipedia.org/wiki/Project_management

https://en.wikipedia.org/wiki/Project_management

https://en.wikipedia.org/wiki/Deliverable

https://en.wikipedia.org/wiki/Work_(project_management)

https://en.wikipedia.org/wiki/Computational_science

https://en.wikipedia.org/wiki/Local_area_network



7. Terminal Systems – Responsible for the Airport’s relationship with the airlines

and providing applications for efficient passenger processing operations.

The diagram below depicts the reporting structure of these parties and their primary

responsibilities during the PPS contract.

Figure 2 Future Organization Chart

The table below depicts the roles and responsibilities of all parties throughout the project

lifecycle.

Table 1 Project Lifecycle Roles & Responsibilities



ROLES AND RESPONSIBILITIES

SFO ITT

PPS Tech Contractor

AIRLINES SFO

TECH

PPS Support

Contractor GNOC

Terminal Systems

Owns all existing and subsequent purchases of hardware and software licenses

X

HARDWARE PROCUREMENT

All server hardware for all applications

X

Existing shared use WS and peripheral hardware

X

Existing CUSS Kiosk Hardware X

Expansion Hardware for all systems in new locations

X

New User/admin workstations for AODB/RMS

X

SOFTWARE PROCUREMENT X

Operating system, DBMS, VM software, all required COTS software

X

Shared Use Platform software (w/LDCS)

X

Self Service Kiosk Platform Software

X

AODB Application Software X

RMS Application software X

Airline passenger processing applications

X

Airline self-service kiosk applications

X

Hosted middleware kiosk application w/ API

X

IMPLEMENTATION

LAN provisioning and maintenance

X

Internet Connection X

Airline Connections X X X

AIIS Integration X X




SFO ITT

PPS Tech Contractor

AIRLINES SFO

TECH

PPS Support

Contractor GNOC

Terminal Systems

Space for Test lab, production staging and training platform servers on premise

X

Space for 2 geo diverse production server platforms on premise

X

Optional - Off premise hosting facility

X

Space for training and test facility

X

Space for storage and staging of all equipment (new or reused)

X

Installation of all servers, operating systems and VM software

X

Coordinates with airlines for WAN connections

X

Shipping and delivery of any new equipment

X

Staging and configuration of all hardware (new and reused)

X

Asset tagging X

Implementation of applications

X

Installation of any new hardware

X

System testing X

User, Admin & Support Training

X

Cleanup of Facility X

Transition planning X

System cutover X

Submittals X

OPERATIONS AND MAINTENANCE

Support Functions




SFO ITT

PPS Tech Contractor

AIRLINES SFO

TECH

PPS Support

Contractor GNOC

Terminal Systems

Answer help desk phone calls 24 hrs/day, receives problem reports from users

X X

Creates Trouble tickets X X

Tracks trouble tickets until resolution (non-network related)

X

1st level maintenance- initial problem triage, pulls and replaces faulty hardware, calls vendor for 2nd level support if problem unresolved

X

Preventative maintenance X

Keep operating system software current to latest releases

X

Keeps application software current to latest releases

X

Implements software fixes/patches

X

Monitors all systems X X X

Receives alerts and event notifications for all applications

X X X X

Runs statistics and reports for all apps

X X

Views dashboards for PPS applications

X X X

Asset management quarterly reports/updates

X

Routine MACs of hardware X

Measures and reports Service Levels monthly

X

2nd level maintenance - trouble shooting all problems not resolvable by 1st level maintenance

X




SFO ITT

PPS Tech Contractor

AIRLINES SFO

TECH

PPS Support

Contractor GNOC

Terminal Systems

Software warranty, fixes, updates and maintenance

X

24x7 2nd level customer support

X

Quarterly Service Level Reports

X

On-going, on-site technical resource

X

Hardware warranty/maintenance for new hardware

X

Hardware warranty/maintenance of reused hardware

X

Ordering replacement spares for faulty(reused) equipment

X

Ordering replacement spares for faulty(new) equipment

X

Fixes any airline WAN issues X

Fixes any airline host problems X

Keeps airline applications current

X X

System Administration Functions

PPS software change management

X

PPS user access and account management

X

Configuration Management of all hardware and software

X X

Network Management/Monitoring

X

Server Management Monitoring

X X

Password administration X

Defines user roles and privileges

X X




SFO ITT

PPS Tech Contractor

AIRLINES SFO

TECH

PPS Support

Contractor GNOC

Terminal Systems

Administers user roles and privileges

X

Reports operational issues to Help Desk

X X X

SHARED USE SYSTEM

Facilitates Shared Use operations at ticket counters and gates

X

Activates new ticket counter/gate locations

X

Facilitates Shared Use operations in airline back office

X

Adding/Removes airline applications

X

Replace consumables stock at ticket counters and gates, as needed

X X

CUSS Kiosks

Activates/Deactivates kiosk X

Configures groups of kiosks X

Configures splash screen, add/delete logos

X

Adds/Removes airline applications

X

Support passengers with kiosk operations

X

Replaces consumable stock in kiosks

X X

RMS

Facilitates RMS Ramp Tower Operations

X

Facilitates RMS seasonal resource scheduling

X

Adds/Changes/Deletes resources in RMS

X X

Updates business rules in RMS X X




SFO ITT

PPS Tech Contractor

AIRLINES SFO

TECH

PPS Support

Contractor GNOC

Terminal Systems

AODB

Facilitates AODB real time operations- manual flight updates

X

Facilitates Seasonal Flight Scheduling

X

Updates business rules of AODB

X

Integrates AODB with new applications and AIIS

X

Adds new interfaces/sources of data

X

5.0 PROJECT MANAGEMENT REQUIREMENTS

5.1 Project Management Plan

The Project Management Plan (PMP) is a formal, approved document that

defines how the project is executed, monitored, controlled and closed. The

Contractor shall submit a Project Management Plan (PMP) that must be in

conformance with PMBoK5 for approval by the Airport two weeks after notice

to proceed. The PMP shall include the following:

1. Restatement of scope that aligns with the proposed solution.

2. WBS structure at the task level.

3. Task descriptions of each discrete activity, including the following for each

task:

a. WBS number;

b. narrative description;

c. planned start date;

d. duration;

e. planned resources (staff, bill of materials, lab time, shipping, etc.); and



f. dependencies (including dependencies upon other tasks, Airport, and

3rd party tasks).

4. Project schedule in Gantt format showing dependencies and critical path.

5. Description of project controls to be used for cost, resource and schedule

management.

6. Stakeholder register with contact information.

7. Communications plan for maintaining an excellent dialog with Airport

organizations. This should include the following:

a. Project kickoff and orientation meeting

b. Escalation criteria for open issues, which might affect delivery

c. Weekly email status report (from kickoff until final acceptance) which

identifies:

i. the activities completed in the last week;

ii. the activities planned for the next three weeks, including Contractor,

Airport and 3rd party activities;

iii. unresolved issues which might affect schedule or budget;

iv. open action items;

v. changes to risk register;

vi. current schedule for completion and earned value calculations; and

vii. open action Items.

8. Quality management plan

9. Risk management plan including risk register and risk mitigation approach.

5.2 Project Execution

The Contractor will provide an on-site project manager for the duration of the

project execution.

Contractor shall conduct a project kickoff meeting three (3) weeks after notice

to proceed. Contractor will review its project plan, project schedule,

communications plan, and problem escalation procedures, and introduce

Contractor staff.

Throughout the project the contracter is required to abide by ISO 20000

standard for IT service management.



Throughout project execution, the Contractor is responsible for conducting

monthly status review meetings reporting on scope, schedule, resources, and

quality and risk mitigation.

Contractor will provide written weekly status reports. At the discretion of Airport,

a weekly teleconference will be conducted to review the emailed project status

reports.

5.3 Project Closeout Requirements

Clean Work Site

1. The Contractor shall always keep the site free from accumulations of waste

material or rubbish caused by its employees or work. Remove all crates,

cartons, and other waste materials or trash from the working areas at the

end of each working day. Flammable waste material must be removed from

the working areas at the time of generation. All rubbish and debris,

combustible or not, shall be discarded on a daily basis in covered metal

containers, and removed from the premises at least weekly and legally

disposed.

2. The Contractor shall be responsible for the general cleaning and

maintenance of the premises and for the coordination and direction of the

cleanup work of its employees.

3. The Contractor shall be responsible for creating and maintaining an

inventory of all displaced equipment, which shall remain the property of the

Airport.

Substantial Completion

1. Following completion of Endurance Testing, the Contractor shall prepare

and issue a Certificate of Substantial Completion, containing:

a. the date of substantial completion;

b. a list of items to be completed or corrected by the Contractor (aka the

“Punch List”);

c. the timeframe within which the Contractor shall complete or correct the

work of the above listed items; and

d. the time and date SFO will assume possession of the work or designated

portion thereof.



2. SFO personnel or their authorized agents will perform an inspection after

receipt of written certification. The substantially completed inspection shall

include, but not be limited to:

a. the project’s contracted work and any additional change orders;

b. all equipment and systems tested and shown operational in the

presence of the SFO Project Manager;

c. all documentation has been delivered, reviewed and approved by SFO

personnel; and

d. all training has been conducted.

3. Upon completion of the inspection, SFO staff will prepare and submit to the

Contractor a list of items to be completed or corrected, as determined by

the inspection, along with the designated timeframe for completion.

4. Should the SFO Project Manager consider the work to be not substantially

complete, SFO will immediately notify the Contractor, in writing, stating all

reasons. The Contractor shall complete the work, and then send a second

written notice to SFO staff certifying that the Project, or designated portion

of the Project, is substantially complete. SFO staff shall then re-inspect the

work upon Contractor’s request at a scheduled re-inspection time.

Final Inspection

1. The Contractor shall submit written certification that:

a. the Contract Documents have been reviewed;

b. the Project had been inspected for compliance with the Contract

Documents;

c. the work has been completed in accordance with the Contract

Documents;

d. the equipment and systems have been tested during the substantial

completion phase and are shown operational in the presence of the SFO

Project Manager; and

e. the Project is completed, and is ready for final inspection.

2. When the SFO Project Manager determines the work is finally complete and

in accordance with the requirements of the Contract Documents, SFO staff

shall request the Contractor to provide Project Closeout submittals.



6.0 DISCOVERY/SYSTEM REQUIREMENTS VALIDATION

After Notice to Proceed (NTP), and concurrent with PMP development, the Contractor will

meet with SFO staff and conduct site surveys, and Airport interviews to refine the

requirements contained in the System Specification Document (SSD). For each of the

application systems, requirements validation includes at a minimum the activities listed

below.

6.1 General Requirements

Validate that locations for system head ends and servers for all five (5)

platforms have ample space and environmental conditions to support system

servers.

Validate Training Environment is large enough to handle all training equipment

and training needs.

Validate staging area is sufficient for systems implementation needs.

Validate airlines to be supported for all systems.

6.2 Shared Use System and CUSS Kiosks

Validate locations of existing shared use equipment.

Determine if there are any new ticket counters or gates for shared use to be

implemented.

Determine if there are any new CUSS kiosks to be implemented.

Validate that SFO LAN connectivity is available to support new locations.

Validate airline host connectivity methodology with each airline.

Determine how much new equipment is required, including consideration of

space necessary to accommodate equipment.

Determine detailed interface requirements with RMS, AODB, IDS, VoIP

system, and BHS and the use of AIIS to accomplish the end to end interface

requirements.

6.3 AODB

Validate locations for AODB workstations to be installed.



Validate hardware requirements for AODB.

Determine all systems and users that need to interface to the AODB and

determine the data to be exchanged, data validation rules, workflow procedures

and business rules for the interface. Determine means of integration (e.g. point

to point or through AIIS). This information for each interface will be documented

in an Interface Control Document.

Determine what events trigger alerts to other systems and operations

personnel.

Validate technical requirements for airline flight data feeds and seasonal flight

schedule feeds.

Determine priorities and trumping rules for multiple sources of similar data.

Validate standard dashboard and reporting requirements.

6.4 RMS

Validate locations for RMS workstations to be installed.

Validate hardware requirements for RMS.

Validate what resources are to be managed by RMS.

Determine all systems that need to interface to the RMS and determine the

data to be exchanged, data validation rules, workflow procedures and business

rules for the interface. Determine means of integration (e.g. point to point or

over the AIIS). This information for each interface will be documented in an

Interface Control Document.

The Contractor shall carry-out all work required to develop and implement the

rule-base for the RMS.

The Contractor shall provide, at a minimum, the following services related to

knowledge engineering:

1. determination of the constraints of each resource;

2. conduct personnel interviews as necessary and work closely with the

various personnel involved;

3. develop system logic;

4. define rules in the RMS;



5. document rule development process in detail such that another party could

update the rule-base without duplicating effort or consulting Contractor;

6. determine what events trigger alerts to other systems and operations

personnel.

6.5 System Requirements Review

Any clarifications/discrepancies related to system architecture, use cases, data

structures, functional requirements, phasing, integration and reports found

during requirements validation shall be clarified and incorporated into an

updated System Specification Document (SSD). In addition, the Contractor will

update the Hardware Requirements Document and COTS Software License

Requirements Documents provided with their proposal. Contractor will conduct

a System Requirements Review (SRR) with the Airport prior to proceeding to

system design phase.

7.0 SYSTEM DESIGN

After successful SRR, the Contractor will proceed with system design for all

required applications. The Contractor shall develop the following design

documentation.

System Design Document (SDD): The SDD will describe the system

architecture, functional capabilities, and all aspects of system communications,

system interfaces, system security, system software, system hardware, system

performance and system maintainability. Contractor is responsible for

coordinating with SFO personnel, system vendors, and airlines, as required, to

develop system interfaces to the PPS applications.

Interface Control Document: An ICD will be developed for each application. The

ICD will describe in detail all the interfaces to each system. Data exchanged,

the mechanism for exchange and business rules and triggers for the interface

shall be included.

Hardware and System Software Requirements Document: Contractor will

reuse existing workstations, and peripherals for the new software systems to

be implemented. However, some new hardware, in addition to the system

servers, may be required to meet all requirements and sparing. The Contractor

shall provide SFO with a bill of materials for required hardware and COTS

system software necessary for the PPS implementation. This will be an update

to the document provided in the Contractor’s proposal based on final



requirements and design activities.

The Contractor shall complete the PCI-DSS Security Standards Council

Prioritized Approach Tool 3.1 (or most current version) where applicable for all

software, hardware, and networking to indicate progress towards PCI-DSS

compliance, along with other security requirements, as outlined in the SSD.

Any contractor providing an off-site hosted solution architecture, must comply

with AICPA Trust Service Principles. The hosting facility must comply with TSP

Section 100, Trust Services Principles, Criteria, and Illustrations for Security,

Availability, Processing Integrity, Confidentiality, and Privacy. Contractor must

submit a SOC2/Type2 report prior to System Design Review.

Provide mechanical drawings illustrating the following for all new equipment:

a. CUSS kiosks: Illustrate how any new CUSS kiosks will be installed including all

CUSS kiosk components, power distribution, network distribution, ADA

compliance, and anti-tampering considerations. Millwork shall be coordinated

with SFO personnel.

b. Shared Use Workstations: Illustrate how any new Shared Use Workstations will

be installed including all workstations, monitors, keyboards, BTP, BGR, BCR,

and/or passport readers, power distribution, network distribution, ADA

compliance, and anti-tampering considerations. Millwork shall be coordinated

with SFO personnel.

Acceptance Test Plan (ATP): Contractor shall develop an ATP that

encompasses all testing required for SFO to fully accept the PPS systems.

The test plan shall address the functional requirements, system interfaces,

system access and security requirements, system admin functions, system

performance, system monitoring and reporting functions for each system. The

test plan shall identify test procedures, test steps, test sequences and test

acceptance criteria with a sign off area for each test by Airport representatives.

Even if systems interface across the AIIS, the test plan must include end to end

testing between the systems.

Training Plan: The Training Plan shall address types of training, course

syllabuses, number of classes of each type, and who is to be trained. The

Contractor shall develop a comprehensive training plan for all users of the PPS

and system administrators. The Training Plan will cover user training, system

administration, system configuration and system maintenance. A schedule for

the delivery of all training courses accommodating staff shift requirements must

be included in the submittal.



Configuration Management Plan: Contractor shall develop a Configuration

Management Plan for tracking and controlling changes in the software. It shall

cover procedures for revision control and the establishment of baselines. It

shall identify the following:

a. Configuration identification - Identifying configurations, configuration items

and baselines.

b. Configuration control - Implementing a controlled change process. The

contractor shall follow the Airport’s written Change Management process

when software or hardware changes are made to the production

environment.

c. Configuration status accounting - Recording and reporting all the necessary

information on the status of the development process.

d. Configuration auditing - Ensuring that configurations contain all intended

parts and are sound with respect to their specifying documents, including

requirements, architectural specifications and user manuals.

e. Build management - Managing the process and tools used for builds.

f. Defect tracking - Making sure every defect has traceability back to the

source.

Disaster Recovery Plan: The Contractor will document the process or set of

procedures to recover and protect the PPS systems in the event of a disaster.

It will specify procedures to follow in the event of a disaster and actions to be

taken before, during and after a disaster. The primary objective is to protect the

organization if all or part of its operations and/or computer services are

rendered unusable. The plan shall minimize the disruption of operations and

ensure that some level of organizational stability and an orderly recovery after

a disaster will prevail. A disaster recovery plan must answer at least three basic

questions: (1) what is its objective and purpose, (2) who will be the people or

teams who will be responsible in case any disruptions happen, and (3) what

will these people do (the procedures to be followed) when the disaster strikes.

System Transition/Cutover Plan: The PPS project must be implemented with

no loss of operations for the Airport. A highly detailed transition plan is critical

to ensure a smooth cutover to the new applications. Contractor shall deliver a

Transition/Cutover Plan describing schedule for system implementation,

testing, Airport coordination activities and tasks for cutover to operational

service. It shall include implementation in the production environment and after

successful testing, data migration/Data Base loading of the live PPS. A

schedule of activities for both Contractor and Airport staff will be included.

https://en.wikipedia.org/wiki/Revision_control

https://en.wikipedia.org/wiki/Baseline_(configuration_management)



Dependencies between tasks will be included. The Transition plan/Cutover

must address the following:

a. prerequisites to system cutover;

b. site readiness criteria;

c. notification plan and procedures to all stakeholders involved in cutover

process;

d. responsibilities of all parties involved in cutover;

e. schedule of step by step activities to migrate from old systems to the new

ones;

f. tasks and dependencies of all Contractor, Airport and 3rd party

responsibilities;

g. measures to ensure there are no outages of existing system; and

h. fall back process and procedures if cutover does not go smoothly.

Following completion of design and all required documents, the Contractor will

conduct a System Design Review (SDR) to obtain approval of the design and

deliverables. The Contractor shall not proceed with system build or

implementation until written Airport approval of the design and submitted

documentation is received.

8.0 HARDWARE AND SOFTWARE PROCUREMENT

Following successful SDR, the Contractor will proceed with ordering all hardware and

COTS software required for systems implementation. Quantities must be documented in

the Hardware and Systems Software Requirements Document and approved by SFO.

9.0 SYSTEM INSTALLATION AND TEST

9.1 Installation and Test Overview

There are five (5) environments that must be installed and tested for each

system regardless of whether servers are hosted on-premise or off-site. They

are: Test Lab Environment, Training Environment, Production Staging

Environment, Primary Production Environment and Secondary Production

Environment. It will be up to the Contractor to determine if systems are

implemented sequentially or concurrently. The sequence of installation and test

for each system is as follows:

1. Installation of test lab environment;



2. Preliminary Acceptance Test in Test Lab;

3. Installation of Training Environment;

4. Validation Test in Training Environment;

5. Installation of all systems in Production Staging Environment (w/ sampling

of all devices, displays and peripheral types);

6. Validation Test in Production Staging Environment;

7. Server installation in the two (2) Production Environments;

8. Validation Test of Production Environments;

9. Cutover Readiness Review;

10. System Cutover in accordance with Transition/Cutover Plan;

11. Endurance Test; and

12. Final System Acceptance

9.2 Test Lab Environment Installation

The Airport will provide a Test Environment on site to be used by the Contractor

for the PPS system testing. The test lab will be used for system acceptance

testing prior to system implementation. Post cutover, the test lab will be used

for testing of software fixes, new hardware and/or new releases of software.

The test lab must be kept current and operational throughout the life of the

project. The space will have sufficient network connections and adequate

power to meet all test requirements. However, the space may not be used as

the Contractor’s office space. Contractor will install all the PPS applications in

the Test Environment. The server environment for the test lab will be in the

primary Data Center or Contractor’s hosting site. Peripherals to be used during

any testing will be collocated with training peripherals in the training lab.

Contractor shall complete test lab installation and PPS configuration in

accordance with the schedule agreed upon with the Airport.

Contractor will provide and implement the following system components within

the test lab environment at a minimum:

all System Head Ends/Servers;

one (1) Ticket Counter and Gate Counter setup with all required devices;

one (1) CUSS Kiosk with Boarding Pass and Bag Tag printing capabilities

and appropriate printing stock;

one (1) Input Workstation for AODB/RMS;



one (1) System Admin/Monitoring Workstation;

airline host connectivity; and

connectivity to other 3rd party systems and websites needed for full

functional and integration testing of the applications. If integration is

through the AIIS, contractor must still coordinate end to end testing with

the 3rd party system(s).

Contractor shall provide all required patch cables and attachment hardware as

needed.

Any additional test lab environment requirements will have been coordinated

with the SFO Project Manager during system requirements validation.

The Contractor shall install all COTS software, application software, and any

test data in the test lab. Contractor will conduct a Test Readiness Review (TRR)

to ensure resources are available and everything is in place for initial

acceptance testing.

9.3 Preliminary Acceptance Test – Test Environment

Using the Acceptance Test Plan approved at SDR, testing will be conducted in

two phases, Functional Testing and System Testing for each application.

Functional Testing will test all functional requirements and system interfaces

from the SDD and ICDs. Upon successful completion of functional test, system

tests will be performed.

System Test includes the following:

1. System Security Requirements;

2. System Administration Requirements;

3. System Access and Privilege Requirements;

4. System Failover and Recovery; and

5. System Performance Requirements.

Airport personnel will observe all testing and initial all tests that are successfully

completed. Contractor will create a punch list of items for correcting prior to

further implementation in other environments.

Following completion of testing, Contractor shall deliver a test report

documenting test activities and any issues found during testing. Airport will



determine if system is ready for implementation in the other environments and

commencement of training.

9.4 Training Environment Implementation

Following successful preliminary acceptance test, the Training Environment will

be implemented. SFO will provide space adequate to accommodate training

needs for the PPS project. Servers for Training Environment will be located in

the primary Data Center or the Contractor’s hosting site. Workstations and

peripherals will be located in a training room provided by the Airport.

The Training Environment will be used throughout the life of the project. Initially

it will be operated to train users, maintenance personnel and system

administrators on the new PPS systems prior to Initial Operating Capability

(IOC). Following Final System Acceptance, the Training Environment will be

used for ongoing training of airline operational staff and other new staff as they

matriculate into SFO operations.

At a minimum, the Training Environment will consist of the following

components provided by the contractor:

1. one (1) full suite of application servers to support all applications

(redundancy is not required). These servers will not be in the training room

but in a controlled server room environment with the production servers;

2. full suite of application software and training database(s) as appropriate to

meet training requirements;

3. one (1) fully configured check-in desk;

4. one (1) fully configured gate counter;

5. one (1) fully configured gate podium;

6. twenty (20) shared use system workstations with attached shared use

peripherals;

7. one (1) AODB/RMS workstation;

8. one (1) system monitoring workstation;

9. modular furniture for twenty (20) positions;

10. one (1) instructor desk; and

11. one (1) white board.

Any additional equipment, system interfaces, design requirements or furniture



will be determined during requirements validation phase.

Below is a notional floor plan of a room layout with suitable space and hands-

on equipment for adequate training. This suggests the project requires about

1000 ft2 and would be best situated near both ITB and T1 for the convenience

of the airline student. The room will be needed throughout the life of the

contract.

Figure 3 Conceptal Training Lab

9.5 Validation Testing in Training Environment



Following implementation of the Training Environment, a validation test will be

conducted to ensure all applications are accessible from the training room and

working properly. Sufficient tests should be executed to ensure:

1. all system interfaces are working properly;

2. all devices are accessible and working properly; and

3. basic functions of all applications are working properly.

It will not be necessary to test system administration, system performance,

system security, or system failover or recovery in the Training Environment.

After successful Validation testing of the Training Environment, SFO will

authorize commencement of training and moving forward with production

environments implementation per the Transition/Cutover Plan.

9.6 Production Staging Environment Implementation

The purpose of the Production Staging Environment is to have a clean

environment for staging of new, fully tested releases or fixes of passenger

processing systems and new hardware devices. All new releases and hardware

will have been fully tested in the test lab prior to being installed in the Production

Staging Environment.

The Production Staging Environment will be an exact duplicate of the current

redundant production environment with respect to software releases, COTS

software and one each of each type of device, or peripheral used in the

operational production environment (except for redundant servers).

The servers for the Production Staging Environment will be in a server room

provided and designated by SFO or at the Contractor’s hosting site. All

peripheral devices will be in another Airport location to conduct validation

testing of all new releases and fixes. Contractor will provide production

equipment for the Production Staging Environment. The Contractor will be

responsible for installation of the PPS software after successful completion of

Acceptance Testing in the Test and Training Environments.

9.7 Validation Test in Production Staging Environment

Following initial implementation of the Production Staging Environment a

validation test will be conducted to ensure all applications are accessible and

working properly. Enough tests should be executed to ensure:

1. all system interfaces are working properly;



2. all devices are accessible and working properly; and

3. basic functions of all applications are working properly.

It will not be necessary to test system administration, system performance,

system security, or system failover or recovery in the staging environment.

After successful validation testing of the Production Staging Environment, SFO

will authorize moving forward with production environments implementation

per the Transition/Cutover Plan.

After Full Operational Capability of the PPS systems, any new releases, fixes

and new hardware will be tested in the Production Staging Environment, after

successful testing in the test lab. Strict configuration management of this

environment is required. The only change to the environment will be that of the

new release or fix to be tested. Testing of the new capability and regression

testing are required to ensure there are no impacts to the production system.

Once testing is approved, that will become the new production environment

configuration.

9.8 Server Implementation in Primary and Secondary Production

Environments

The Contractor will provide production equipment and all COTS and application

software for the PPS in both the primary and secondary server rooms

designated by SFO or at the Contractor’s hosting site(s). The Contractor will

be responsible for installation of the PPS server hardware, COTS software and

application software after successful completion of Validation Testing in the

Production Staging Environment. Production environment implementation will

consist of all activities necessary for systems operation except for peripheral

and device connectivity. At a minimum, this includes:

1. servers;

2. COTS software;

3. application software;

4. network VLAN configuration;

5. System Monitoring Workstations;

6. System Administration Workstations;

7. Airline Host Connections; and

8. other System and Website Connections/Interfaces.



9.9 Validation Test in Production Environments

Following implementation of the production environments a validation test will

be conducted to ensure all applications are accessible and working properly.

Tests will be executed to ensure the following:

1. all interfacing systems are reachable;

2. system failover and recovery tests are successfully completed;

3. system monitoring functions are reporting based upon the outlined

parameters in the system specification; and

4. System administration functions are operational based upon the outlined

parameters in the system specification.

9.10 Cutover Readiness Review

Following successful validation testing in the production environments,

Contractor will conduct a Cutover Readiness Review (CRR). At the CRR, SFO

will review acceptance test reports, all validation tests, punch list of any

software defects, and ensure training has been conducted and no major issues

will prevent system cutover. The Airport will review the Transition/Cutover plan

and determine if all resources are available, if all stakeholders are prepared for

cutover to commence, and that all actions necessary to transition from the old

systems to the new have been completed. Review of the fallback procedures

for each system and devices will be conducted to ensure no loss of operational

capability should any issues occur during cutover.

9.11 System Cutover

Upon the Airport’s written approval of the CRR, Contractor will cut over the PPS

systems. All data migration from old system to new system will be implemented.

As systems, devices and peripherals are cutover each evening, per the planned

schedule, basic functional tests will be performed. Upon successful completion

of system cutover, Preliminary System Acceptance and Initial Operating

Capability will be granted and the Airport will begin beneficial use of the new

PPS system.

9.12 Endurance Test

Following System Cutover, the system will undergo endurance testing for a

period of 60 days. During this period the Contractor will provide on-site

personnel to support systems operation from 4am to 1am each day, including



weekends and holidays.

The Contractor shall monitor all systems during endurance testing in

conjunction with SFO.

The Contractor shall record incident data and performance metrics to provide

a continuous log of systems performance. The log shall include:

1. date and time for all entries;

2. name of individual making entry;

3. environmental conditions;

4. activities in process;

5. description of all alarms, responses, corrective actions, and causes of

alarms, and classification of alarm type;

6. description of all equipment failures;

7. description of all software errors;

8. description of all maintenance and adjustment operations performed on

system;

9. daily and weekly tabulations of performance data; and

10. daily entries of performance data shall be reviewed by the SFO Project

Manager’s representative designated to observe monitoring of system.

The SFO Project Manager may terminate endurance testing at any time when

the system fails to perform as specified. Upon termination of endurance test

period, the Contractor shall commence a corrective period, identify all failures,

determine causes, and resolve all issues. The Contractor shall submit a report

explaining the nature of each failure, corrective action taken, results of tests

performed, and recommended point for resumption of endurance testing.

After submission of endurance testing report ,SFO will schedule a review. At

the review meeting, the Contractor shall perform verification tests to

demonstrate that all failures have been corrected.

Based on the report and review meeting, the SFO Project Manager will approve

resumption of the endurance test.



9.13 Final System Acceptance

System must run for sixty (60) contiguous days without major outages or loss

of functionality due to PPS software, hardware or other direct Contractor

responsibilities. After endurance testing is complete, tabulated records will be

reviewed with the SFO Project Manager.

Following the endurance test, Contractor will conduct a post-test reassessment

workshop. Any operational anomalies, user interfaces or system performance

issues will be discussed and a plan and schedule for resolution developed.

Final system acceptance will occur no earlier than sixty (60) days post

completion of system cutover. To obtain final acceptance the following must be

completed:

1. all punch list items from endurance testing;

2. resolution of post cutover issues;

3. delivery of all documentation;

4. all training complete; and

5. delivery of all Software Licenses.

10.0 TECHNICAL RESOURCE

1. Following Final System Acceptance the contractor will provide an on-going,

on-site technical resource to SFO. This will be one person full time on site

for the life of the contract (5 years). The activities planned for this technical

support include PPS application integration with AIIS and the development

of other related business services. A technical resource from the Contractor

will develop and implement new business and technical services related to

Shared Use, AODB, RMS and CUSS. As an example, developing and / or

enhancing direct data and service integration from the AODB to the Airport’s

enterprise data hub and data domain structure. The Contractor shall

provide technical services to develop direct data and service integration of

PPS applications within the Airport’s enterprise domain data structure. The

technical resource should have at least 5 years software development

experience, be knowledgeable of the software architectures of the proposed

products, and expertise with web services, message brokers, data hubs and

implementing Rest APIs.



11.0 EXPANSION/PROFESSIONAL SERVICES (OPTIONAL)

Following Final System Acceptance the contractor will provide professional services to

SFO upon request. The activities planned for this technical support include but are not

limited to:

1. PPS system application enhancements

2. PPS application implementation in other locations at the Airport

3. Additional training

4. Further PPS application integration with AIIS. The Contractor shall provide

professional services to develop direct data and service integration within

the Airport’s enterprise domain data structure.

Staffing levels will be agreed upon based on the scope of activities to be determined

following IOC.

12.0 TESTING

Testing will be conducted at specific points in the implementation process as defined in

the previous section. This section covers general activities applicable to all testing.

12.1 Test Activities

The Contractor's Quality Assurance organization shall review all formal test

procedures prepared by the Contractor and deliverable under the Agreement

to assure the tests cover all requirements and that there is consistency between

the conducted test, the test results and specification requirements

The contractor is responsible for conducting end to end testing between PPS

applications and all systems accessing PPS data or interfacing directly to a

PPS application. For example, AODB makes flight data available on the AIIS

and IDS uses that data. Even though the systems are not directly connected

the PPS contractor must conduct end to end testing to varify IDS is able to

access the data it requires from AODB.

Documentation verification is required for all tests. Where documentation is

not in accordance with the installed system, the system shall not be considered

accepted until the system and documentation correlate.

The Contractor shall cooperate with and provide SFO representative(s) the

opportunity(s) to participate in any or all the tests.

Test Reports: For each test, the Contractor shall prepare a test report



document that shall certify successful completion of that test. Within seven

calendar days of test completion, Contractor shall deliver the test report to the

SFO Project Manager in electronic format for review and acceptance. At a

minimum, the test report shall contain:

1. summary of test results;

2. a listing and discussion of all discrepancies between expected and actual

results, all failures encountered during the test and their resolution;

3. complete copy of test procedures and test data sheets with annotations

showing dates, times, initials, and any other annotations entered during

execution of the test;

4. signatures of persons who performed and witnessed the test.

Test Resolution: Any discrepancies or problems discovered during these tests

shall be corrected by the Contractor at no additional cost to the project. The

system or service shall be re-tested to validate that the problem or defect has

been resolved.

13.0 TRAINING

13.1 General

The Contractor shall fully instruct the SFO designated staff and airline

personnel in the operation, administration and maintenance of all products,

equipment and systems. Training shall be accomplished in a classroom setting

augmented by individual instruction as necessary. The Contractor shall provide

all training aids, e.g., notebooks, manuals. The Contractor shall keep a log of

all personnel receiving and completing training for each system and note the

type of training received.

All training shall be completed a minimum of two (2) weeks prior to system cut

over. Training schedule is subject to the SFO Project Manager’s approval and

shall have sufficient flexibility to accommodate Airport operations and shift

operations. Each training class must be offered at least once during each shift.

Training shall be conducted by experienced personnel and supported by

training aids. An adequate number and amount of training material shall be

provided by the Contractor. The following is considered a minimum.

1. functional flow-charts, overall block diagrams, and descriptive material for

all software;



2. schematic drawings for each of the hardware components;

3. all procedure manuals, specification manuals, and operating manuals; and.

4. as-built drawings.

Participants shall receive individual copies of technical manuals and pertinent

documentation at the time the training is conducted. Training shall be

scheduled such that SFO and other relevant personnel can participate in all

courses with no overlap.

At least four (4) weeks before the final training course is offered to SFO and

airline personnel, Contractor shall provide the SFO Project Manager with a

final course schedule and syllabus for review and approval.

The selected Contractor shall conduct the required training at times and

locations as determined by the SFO Project Manager. The class schedules

must accommodate shift schedules of SFO and airline personnel and must be

approved in advance. If twenty (20) days or more elapses between training

and system cutover, selected Contractor must retrain all previous trained

personnel of those involved.

Each course outline shall include, in addition to the subject matter, a short

review of the prerequisite subjects (where appropriate); how this course fits into

the overall training program; the course objective; the standards of evaluation;

and any other topics that will enhance the Training Environment.

The Contractor shall deliver a video recording of each training course to the

SFO Project Manager. All course materials shall be provided to the Airport for

use in future training and course videos shall be delivered on a USB storage

device two weeks prior to training..

Contractor will offer additional/refresher training sessions on new releases as

part of the warranty/maintenance fee throughout the warranty period.

13.2 Types of Training

Training shall include, but not be limited to, the following personnel groups:

1. system users;

2. technicians and maintenance personnel; and

3. System administration and monitoring.

User Training: System users shall be instructed in all aspects of system



operations for every PPS application. User training shall be conducted in the

Training Environment. Training for RMS and AODB users shall include two (2)

weeks of on-the-job training following IOC. Users must learn how to create and

edit business rules for these applications and how to operate/create both

seasonal and day to day schedules. SFO staff will be trained by Contractor

personnel experienced in the use and operation of these systems.

Technician Training: Training for maintenance technicians shall be provided

on site, and shall include, but not be limited to, installation, operation,

renovation, alteration, inspection, preventive maintenance, and maintenance

service on each system and its hardware components. Training shall be such

that maintenance technicians are able to troubleshoot problems and repair the

modules, assemblies and boards. This class will include an in-depth trouble

diagnostic tutorial with a trouble-shooting flow chart.

System Administration and Monitoring Training: This training shall cover all

PPS system administration and monitoring functions; provide an overview of

the complete system structure including hardware, software and networks; and

describe all functions and applications needed to perform system

administration. At a minimum, system administrators must be able to:

1. monitor system operations;

2. access system logs containing warnings and error notifications;

3. run audit and system health statistics, and print reports;

4. understand user roles and user account configuration and management;

5. manage and configure PPS and COTS software;

6. develop, add, edit, and configure user profiles, reports and dashboards.

System Administrator Training shall include both classroom work and on-the-

job training.

1. Classroom Training: Classroom training provided by the Contractor shall

describe all systems, software and applications and support programs and

include a functional overview of the complete software system. The course

material must include Rule Base editing for AODB, RMS, and IDS, adding

resources/displays to RMS and IDS, creating and scheduling display

formats in IDS and any other data base maintenance activities not

performed in day-to-day operations.



2. On-the-Job Training: An additional two (2) weeks of on-the-job training shall

be provided for system administrators and shall commence no later than

two weeks following IOC. The Contractor shall provide SFO-specified

trainees with daily training assistance by a Contractor Engineer. The

Contractor shall answer all questions regarding the operation,

administration, and monitoring of the system software and equipment.

14.0 SUBMITTALS AND DOCUMENTATION

The work under this section shall include all labor and materials necessary to complete

the writing, editing, assembling, packaging and delivery of product and system

documentation, and training manuals in accordance with the requirements of this scope

of work. All documentation must be provided in paper and electronic media.

14.1 Submittal Media Requirements

All documentation (text, graphics, illustrations, etc.) shall be delivered in both

electronic and hardcopy formats. The documentation shall be produced in MS

Office format as well as Adobe PDF files. The electronic documentation shall

be delivered such that the document "reads" as though the document were in

printed form.

14.2 Submittal Quantities

One (1) electronic version of all submittals and hard copies of training material

for each student shall be delivered to the SFO Project Manager.

14.3 Submittals

Submittal Log: The Contractor shall create and maintain a log of all submittal

items including descriptions of items, dates submitted, response dates and

status of submittals.

Contractor Contacts: The Contractor shall submit company contact information

two weeks after Notice to Proceed including organizational chart as applicable

to this project, and project management and technical staff names, emails and

cell phone contact information.

Project Management Documentation: Within two (2) weeks of the Airport’s

issuance of a Notice to Proceed, Contractor shall deliver a Project Management

Plan to SFO Project Manager.

Weekly Status Reports from kickoff through final acceptance.



System Specification Document: Contractor shall deliver an updated System

Specification Document after conducting site surveys and validating system

requirements with the Airport.

Hardware and System Software Requirements Documents: For any installation

and procurement required by SFO that is not the Contractor’s responsibility as

defined in the contract, the Contractor shall provide the SFO Project Manager

with the installation and procurement requirements. This will be an update to

the lists provided in Contractor’s proposal based on final requirements and

design activities. For each type of product required for the PPS, the Contractor

shall provide all minimum and recommended requirements, including features,

performance, and sizing requirements.

System Design Document (SDD): The Contractor shall deliver an initial SDD

after a successful SRR. A final SDD will be delivered after Configuration

Workshops are completed. SDD must include business, functional and

technical requirements, including but not limited to : business rules for PPS,

CUSS, RMS, AODB, and documentation of security architecture and measures

to comply with security requirements.

SOC2/Type2 Report: Any contractor providing an off-site hosted solution

architecture, must comply with AICPA Trust Service Principles. The hosting

facility must comply with TSP Section 100, Trust Services Principles, Criteria,

and Illustrations for Security, Availability, Processing Integrity, Confidentiality,

and Privacy. Contractor will submit a SOC2/Type2 report prior to System

Design Review.

PCI-DSS Security Standards Council Prioritized Approach Tool 3.1.

Interface Control Document (ICD): Contractor shall deliver an ICD describing

all the interfaces to the system as described in the contractors Project Plan. It

includes user interfaces as well as systems that interface with the application.

Each interface description should include the purpose of the interface, a

mapping of functional requirements in the SSD that the interface helps meet,

data elements exchanged, and the business rules that govern the exchange of

information. The business rules should cover formatting, sequencing, error

detection, commands, performance characteristics, and workflows (normal,

alternate and exceptional), performance requirements and availability

requirements. Triggers for data exchange must be identified. Although some

systems may communicate using AIIS, and not directly interface, the

description of how that end to end communication is accomplished is required.



Acceptance Test Plan and Test Procedures: The Contractor shall create and

submit for SFO Project Manager approval a PPS Acceptance Test Plan. The

test plan shall address the functional requirements, system access and security

requirements, system admin functions, system performance, system

monitoring and reporting functions, and cover each user’s ability to use the PPS

with full functionality.

Test Plan shall include a traceability matrix referencing specification

requirements in the SSD to specific tests/test procedures.

Test Format: At a minimum, each test will detail the following:

1. Test objective.

2. Traceability matrix referencing specification requirements in the SSD the

test addresses.

3. Step by step functional procedures.

4. Any test equipment needed for the test. Test equipment is to be identified

by manufacturer and model. Interconnection of test equipment and steps of

operation shall be defined.

5. Expected test results required to comply with specifications.

6. Record of test results with witness initials or signature and date performed.

7. Pass or fail evaluation with comments.

8. The test procedures shall provide conformity to all specification

requirements. Satisfactory completion of the test procedure is necessary

as a condition of system acceptance.

Acceptance Test Reports

1. Test result reports for Test Environment, Training Environment and

production environment tests conducted will be delivered.

2. Acceptance test records will be created and submitted by the Contractor

and will document the system performance and any malfunctions. A punch

list of items to be corrected will be included. The causes of malfunctions and

failed tests shall be corrected prior to final acceptance.

3. The final test records shall be submitted once all faults are corrected and

the system passes all tests. The final test records shall include passed tests

with initials by the Airport representative(s) monitoring the test.

Transition/Cutover Plan: Contractor shall deliver a Transition/Cutover Plan

describing schedule for implementation, and Airport coordination activities and



tasks for cutover to operational service. It shall include implementation in the

production environments and subsequent to testing server infrastructure, data

migration/Data Base loading of the live PPS, and transition of staff operations

from old to new system operations. The PPS project must be implemented with

no loss of operations for the Airport. It will be important to have a very detailed

transition plan to ensure a smooth cutover to the new applications. At a

minimum, Transition/Cutover plan will include the following:

1. Prerequisites to System Cutover.

2. Site readiness criteria.

3. Notification plan and procedures to all involved in cutover process.

4. Responsibilities of all parties involved in cutover.

5. Measures to ensure there are no outages of existing system.

6. Fall back process and procedures if cutover does not go smoothly.

7. WBS structure at the task level:

a. Task descriptions of each discrete activity to include the following for

each task:

i. WBS number

ii. Narrative description

iii. Planned start date

iv. Duration

v. Planned resources (staff, lab, etc.)

vi. Dependencies (including dependencies upon other tasks, Airport,

and 3rd party tasks)

vii. Cutover schedule in GANTT format showing dependencies and

critical path. A schedule of activities for Contractor, 3rd parties and

Airport staff will be included.

Training Plan and Syllabus: Contractor shall submit a training plan with course

syllabus and training schedule to accommodate Airport staff schedules.

Training Manuals: The Contractor shall submit training manuals and course

material as indicated in the training section of this document.

System Documentation: The Contractor shall submit User Manuals, System

Administration Manuals, Operations Manuals and Maintenance Manuals and

System Customization Guide for user configurable items.



Software Licenses:

1. The Contractor shall provide software licenses for each type of COTS

provided by the Contractor for the project. The software licenses shall be

suitable for the quantities of users and equipment defined for the project.

2. The Contractor shall provide application software licenses for the

applications they provide for the PPS contract. All licenses shall be issued

to SFO. They shall be enterprise wide and perpetual licenses. The licenses

will allow any number of Airport users in any Airport location to use the

applications with no additional fee.

Disaster Recovery Plan.

System Configuration Management Plan.

Product Cut Sheets.

As-Built Documentation.

Quality of Service Reports (during operations).

Trouble Call Lists/Response Escalation Plan.

Recommended Maintenance Schedule.

Backup Copy of Software Source Code.

Project Close-Out Memo.

14.4 Submittal Schedule

The following table depicts required delivery schedule of all submittals.

Table 2 Submittal Delivery Schedule

Submittal Due Date

Project Management Plan 2 weeks after NTP

Project Status Reports weekly

Submittal Log 2 weeks after NTP

Contractor Contacts 2 weeks after NTP

Updated System Specification Document 2 weeks prior to SRR

Updated Hardware and COTS Software Requirements

Document 2 weeks prior to SRR

System Design Document 2 weeks prior to SDR



Submittal Due Date

Interface Control Document 2 weeks prior to SDR

PCI-DSS Prioritized Approach Tool 2 weeks prior to SDR

SOC2/Type2 Report 2 weeks prior to SDR

Acceptance Test Plan and Procedures 2 weeks prior to SDR

Training Plan and Syllabus 2 weeks prior to SDR

Transition/Cutover Plan 2 weeks prior to SDR

Test Report 1 week following each test

activity

Training Manuals 1 week prior to training

System Documentation 1 week prior to CRR

Software Licenses IOC

Disaster Recovery Plan 2 weeks prior to SDR

Configuration Management Plan 2 weeks prior to SDR

Product Cut Sheets IOC

As-Built Drawings IOC

Trouble Call Lists 2 weeks prior to CRR

Monthly QOS Reports Monthly during O&M

Recommended Maintenance Schedule IOC

Backup Copy of Source Code 1 week following Final

System Acceptance

Close Out Memo 1 week following Final

System Acceptance

15.0 WARRANTY/MAINTENANCE SERVICES

The Contractor shall provide five (5) years of warranty and maintenance service on all

software, and labor installed as a part of the PPS Contractor scope. The five (5) year

Warranty Period shall start upon the "Date of Final System Acceptance” of the entire PPS.

The date upon which the Airport received beneficial use of any or all portions of the PPS

shall not trigger the Warranty Period for any portion of the PPS. The Warranty Period

shall not commence until the entire PPS has been accepted by the Airport through Final

System Acceptance procedures. Warranty includes all products supplied as part of

Contractor solution, including all product upgrades and new releases produced during

the warranty period and their installation at no additional cost. For system fixes, no

additional costs will be incurred by SFO for Contractor restoring system to normal

operations. Warranty service and repair work shall be performed by personnel who have

been trained, certified by the contractor to work on their installed products and

experienced in the operation and maintenance of the installed system.



The PPS Contractor shall be responsible for the provision of all software, and hosting

hardware (servers) patches and updates. A list of all patches and updates, with vendor

recommendations, shall be submitted to the Airport for review and approval prior to

production installation. All updates must be tested and approved within the PPS testing

and production staging environments prior to installation. To avoid interruptions in

service, all successfully tested patches must be scheduled for installation through the

Airport’s change management process. Within thirty (30) days of contract certification,

the Contractor shall develop a written proposal for a standardized test and

implementation plan to test, validate and implement patches and updates. The SFO

Project Manager shall review the proposed test plan within fifteen (15) days of receipt and

either approve the plan or work with the Contractor to modify the proposal. When

approved, the Contractor will use the approved plan to deploy the patches and

updates. Critical and security patches shall be deployed on a monthly basis. However,

patches which are required to protect the systems from an imminent risk shall be reviewed

and deployed as soon as possible. The PPS Contractor shall provide the Airport with a

monthly list of recommended updates, patches and their criticality. All patches and

updates which are not considered critical or security related shall be reviewed and applied

to the system as soon as possible, but no later than 90 days after release. The application

of critical or security related patches will be prioritized above all other updates.

15.1 1st Level Maintenance

First level maintenance will be performed by SFO personnel. First level

maintenance functions include answering trouble calls regarding the PPS and

creating trouble tickets. If not resolved by Airport staff, 1st level maintenance

will call the PPS Contractor help desk if it appears to be a software problem.

First level maintenance will pull and replace faulty hardware, perform

preventive maintenance and replace consumable stock as required, and

monitor and receive system alerts.

15.2 2nd Level Maintenance

Second level maintenance will be performed by the PPS Contractor. The costs

for 2nd level maintenance are to be included in software license fees. Second

level maintenance functions include the following:

When 1st level maintenance has failed to resolve an issue and calls for support,

Contractor shall attempt to diagnose and repair the problem remotely.

Contractor shall be available 24x7 for handling trouble calls. Trouble calls will

be divided into two categories:



a. Minor Faliures: these are defined as failures or problems, which do not

affect the overall safety, security, or operation of the Airport. For

example, the loss of a redundant workstation would typically be

considered non-critical.

b. Major Failures: these are defined as failures or problems, which do affect

the overall safety, security, or operation of the Airport. The failure of a

system interface resulting in the loss of functionality of the PPS would

be example of critical item requiring immediate remedy.

Minor Failures: On a minor failure, the Contractor must respond within 1 hour

to isolate the problem. The Contractor must close out the trouble with their

service manager within 24 hours or escalate to SFO’s support point of contact.

Major Failure: On a major failure, the Contractor must respond within 30

minutes on a 24x7x365 basis to trouble shoot. If the Contractor cannot resolve

the problem within four (4) hours remotely, the Contractor must respond on-site

to major failure calls within twelve (12) hours of the initial call. All major failure

repairs must be completed prior to the technician leaving the site.

Escalation: If a major failure is not resolved within 4 hours, the Contractor must

notify SFO management personnel in verbally and in writing and provide status

reports every 2 hours until the issue is resolved.

15.3 Software Maintenance

The Contractor must provide PPS software maintenance support during the

warranty period.

The Contractor is required to correct all known software bugs reported by 1st

level maintenance. The Contractor will implement a Software Problem/Change

Request (SPCR) process for reporting and correcting software issues.

The Contractor is required to maintain all application software, COTS software

and firmware at its most current release following system acceptance. This

applies to all software products supplied by the Contractor.

Software updates must be scheduled with ITT ahead of time, and must follow

the approved SFO ITT change management process. If they are downloaded,

Airport must be advised with two (2) weeks advance written notice that a new

software release is available and that notice must outline all of the

enhancements, fixes, and remaining known problems. Airport may elect not to

load one or more releases and exercising this option shall not void the software



support warranty.

Security patches and other patches which effect stability and security of the

PPS environment must be implemented within thirty (30) days of release.

However, patches which are required to protect the systems from an imminent

risk shall be reviewed and deployed on an expedited basis, i.e.immediately).

The test lab environment may be used for debugging and testing fixes to

issues. After successful test in the test lab all software will be loaded and tested

in the Production Staging Environment. Functional and regression tests will be

run to ensure no negative impacts to other aspects of the system will occur.

The Contractor will maintain configuration management of all software currently

in production environment at all times. This includes application and COTS

software CM.