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
SFO Passenger Processing System Project
Scope of Work Page 3 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 4 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 5 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 6 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 7 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 8 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 9 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 10 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 11 of 55
Acronym Full Phrase Brief Description
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
SFO Passenger Processing System Project
Scope of Work Page 12 of 55
Acronym Full Phrase Brief Description
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.
SFO Passenger Processing System Project
Scope of Work Page 13 of 55
Acronym Full Phrase Brief Description
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
SFO Passenger Processing System Project
Scope of Work Page 14 of 55
Acronym Full Phrase Brief Description
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.
SFO Passenger Processing System Project
Scope of Work Page 15 of 55
Acronym Full Phrase Brief Description
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
SFO Passenger Processing System Project
Scope of Work Page 16 of 55
Acronym Full Phrase Brief Description
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.
SFO Passenger Processing System Project
Scope of Work Page 17 of 55
Acronym Full Phrase Brief Description
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.
SFO Passenger Processing System Project
Scope of Work Page 18 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 19 of 55
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 Passenger Processing System Project
Scope of Work Page 20 of 55
ROLES AND RESPONSIBILITIES
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 Passenger Processing System Project
Scope of Work Page 21 of 55
ROLES AND RESPONSIBILITIES
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 Passenger Processing System Project
Scope of Work Page 22 of 55
ROLES AND RESPONSIBILITIES
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 Passenger Processing System Project
Scope of Work Page 23 of 55
ROLES AND RESPONSIBILITIES
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 Passenger Processing System Project
Scope of Work Page 24 of 55
ROLES AND RESPONSIBILITIES
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
SFO Passenger Processing System Project
Scope of Work Page 25 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 26 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 27 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 28 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 29 of 55
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;
SFO Passenger Processing System Project
Scope of Work Page 30 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 31 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 32 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 33 of 55
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;
SFO Passenger Processing System Project
Scope of Work Page 34 of 55
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;
SFO Passenger Processing System Project
Scope of Work Page 35 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 36 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 37 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 38 of 55
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;
SFO Passenger Processing System Project
Scope of Work Page 39 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 40 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 41 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 42 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 43 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 44 of 55
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;
SFO Passenger Processing System Project
Scope of Work Page 45 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 46 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 47 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 48 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 49 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 50 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 51 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 52 of 55
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.
SFO Passenger Processing System Project
Scope of Work Page 53 of 55
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:
SFO Passenger Processing System Project
Scope of Work Page 54 of 55
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
SFO Passenger Processing System Project
Scope of Work Page 55 of 55
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.
Top Related