FME OnM-Ecodomus OnM-API Support DRAFT SOO.pdf

GSA Ecodomus, FME and Alfresco API Solicitation Number: To be added by the Contracting Office

GENERAL SERVICES ADMINISTRATION (GSA)

OFFICE OF ADMINISTRATIVE SERVICES (OAS)

OFFICE OF INTERNAL ACQUISITION (OIA)

ORDER ID NUMBER: {{Solicitation No.}}

Siemens Ecodomus, Safe Software’s Feature Manipulation Engine Server (FME) and Alfresco API Support

Statement of Objectives (SOO)

General Services Administration Office of the Chief Information Officer (OCIO)

Public Buildings Information Technology Services (PB-ITS) Center for Building Information Programs

NOTE: This Solicitation is herein competitively issued under the {{Contract Vehicle}}:

SIN: 54151S

NAICS Code:541511

{{Solicitation Issue Date}}

Table of Contents

1. Background 2

1.1 Application Overview 3

1.1.1 The BDR API 3

BDR API Technical Description 3

1.1.2 Siemens Ecodomus 4

Ecodomus System Architecture 4

1.1.3 FME Server 6

Current FME Environment 7 System Interconnection 8

2. Scope 8

3. Objectives 10

3.1. FA1: Operation and Maintenance Objectives 10

3.2. FA2: Program Documentation Management Objectives 12

3.2.2. Communications and Meeting Support Objectives 13

3.3. Contingency Plan Objectives 13

3.4. FA3: Enterprise Quality Program (EQP) 14

3.5. DevOps 14

3.6. Software Code Quality 15

3.7. FA4: Tier II-III Helpdesk Services 15

3.8. Help Desk 16

3.9. Training 17

3.10. FA6: Security Compliance 17

3.11. FA7: Enhancement Support 17

3.11.2. Technical Roadmap Subtask 17

3.11.3. Enhancements Subtask 18

3.11.4. Work Estimates Subtask 20

4.0 Labor Requirements 20

5.0 Deliverables 22

5.1 Inspection and Acceptance 25

5.2 Constraints 25

5.2.1 Accessibility 25

5.2.2 Access Control 25

5.2.3 Authentication 25

5.2.4 Personnel Security Clearances 25

5.2.5 Non-disclosure Agreements 25

5.2.6 Sensitive Data, etc. 25

5.2.7 Data isolation requirements or hardware sharing restrictions. 26

6.0 Vendor Technical Environment Responsibility 26

7.0 Place and Period of Performance 26

7.1 Telework / Operating Status 26

8.0 Phase-In/Phase-Out Overview 27

8.1 Phase-In 27

8.2 Phase-Out 28

9.0 Travel 29

10.0 Government Furnished Equipment (GFE)/ Government Furnished Information (GFI) 29

11.0 GSA IT Security/Access Control/Authentication 29

11.1 Homeland Security Presidential Directive (HSPD-12) and Background Investigations Requirements 31

11.2 Contractor Staff Reporting Requirement 31

11.3 Privacy Act 33

11.4 Protection of Information 33

11.4.1 Internal Contractor or Government Information Systems - IT Security Requirements 33

11.4.2. Mobile Application - IT Security Requirements 33

11.4.3 Safeguarding Sensitive Data and Information Technology Resources 33

11.4.4 Cloud Information Systems – IT Security and Privacy Requirements 34

12.0 Administration 35

12.1 GSA Electronic Invoicing 35

12.2 Delivery Schedule 35

12.3 Inspection and Acceptance 35

12.4 Cancellation of Orders 36

12.5 Unauthorized Commitment 36

12.6 Personal Services 36

13.0 Contract Type 36

1. Background

The General Services Administration’s (GSA), Office of the Chief Information Officer – Office of Public Buildings Information Technology Services (PB-ITS) in support of the users of all business lines within Public Buildings Service (PBS), 1800 F Street, NW, Washington, DC is seeking to maintain the continuity of operations and maintenance (O&M) services for the Siemens Ecodomus application (and its associated licensing), Safe Software’s Feature Manipulation Engine Server applications (and they’re associated licensing) and an Application Programming Interface (API) built on Hyland’s Alfresco Electronic Content Management System (ECMS). This application collection is primarily managed by the Center for Building Information Programs which serves as the agency-wide originator of transformational building information applications.

These applications support the mission of GSA by providing an enterprise interface to the single repository of current, pending and previous building conditions, the Building Document Repository (BDR, managed by GSA IT). These applications also contribute to achieving the GSA Strategic Objectives including improving the way Federal agencies buy, build and use technology. Lastly, in support of PBS's mission to "To provide effective and sustainable workplace solutions for federal agencies at the best value for the American Taxpayer”, these applications are intended to provide an enterprise means of producing and saving the virtual reflection of all current characteristics of the PBS owned and leased inventory.

1.1 Application Overview

The following is a technical description of the three major components that require O&M services.

1.1.1 The BDR API

GSA has built a one way API to direct documents received from enterprise systems into the Alfresco ECMS. The API enables documents sent to the repository to be automatically filed and tagged with provided metadata. The Alfresco repository targeted to receive from this API, named the Building Document Repository (BDR) is being managed by a different GSA IT organization. The API was originally created for a PBS IT version of Alfresco, called the Central Facility Repository (CFR), and the API created for the CFR is now being pointed to the BDR system and rebranded as the BDR API.

The BDR inventory consists of over 1.9 million documents, consuming nearly 3 terabytes of storage space. Contributors are adding an average of 25,000 documents per month to the inventory. Each document should have representative attributes (metadata) ascribed to it, providing easy recognition of pertinent data points and meaningful search characteristics.

This metadata becomes part of the transactional data that is passed with files that are negotiated through the BDR API.

BDR API Technical Specifications

Hardware x86-64 on vmware

Codehttps://insite.g sa.gov/cdnstatic/in site/Microsoft- Windows-SQL- Server-2019- Hardening-

%5BCIO-IT-

Security-22-122- Initial- Release%5D-08- 01-2022docx.pdf

Java (custom)

Operating System Microsoft Windows Server 2016, 2019

Software Platform/Module Version

Activity Monitor Custom

ActiveMQ 5.15.6

APITokenGenerator Custom

JDK 11.0.16

SQL Server 2019

Tomcat 8.5.82

1.1.2 Siemens Ecodomus

In 2020, the GSA acquired the Siemens Ecodomus platform and integrated the product into the Alfresco framework. Ecodomus provides Digital Twin capabilities to the GSA with visualization, attribute checking and enterprise integration for Building Information

Allen Samuel - IPT Need to add as attachment and not a link.

Modeling (BIM). GSA further developed BIM management capabilities in the system with onsite Remote Process Automation (RPA) capabilities allowing projects to be automatically loaded (or updated) into the platform from GSA’s project management SaaS platform, Kahua. The application is now being redirected to the BDR via both the BDR API and custom components.

Ecodomus System Architecture

Ecodomus App server:

1. Microsoft IIS 10.0

2. EcoDomus 3.2.123, 64bit (COTS)

3. RedHat OpenJDK 11

4. Apache Tomcat 9.0.62

5. BIM LDAP Service 1.0

6. BIM Availability Monitor 1.0

7. BIM Integration 1.0

Details on the Ecodomus Data Schema

● The EcoDomus and EcoDomus_Central schema is the out-of-box schema.

● The BIM schema provides data exchange between EcoDomus and custom BIM applications (BIM Integration, BIM LDAP Service) The following table provides details information on Ecodumus components:

Component Name Technology Components Purpose

EcoDomus

EcoDomus Custom UI Custom Web service

.Net Core .Net Entity Framework

EcoDomus application is the main UI for users, which provides the user interactive interface to complete project/document/BIM model management tasks.

BIM

Connector

Net Core .Net Entity Framework

The BIM Connector desktop software allows the users to export 3D BIM model data to EcoDomus server and generate 3D views for asset validation and management purposes.

BIM

Integration

Alfresco OpenCMIS REST

API

Spring Boot SPring JMS Spring JPA

EcoDomus REST API

The Java program implements the following functions:

● Enterprise Application Push to

Ecodomus

● Document Tracking

● Document Linking to

Components

● BDR API Indicate Ecodomus

Push

● Ecodomus Initiate Alfresco

Archive

● Model Synchronization

● Manually push document/folder

Availability Monitor

Spring Boot SPring JMS Spring JPA

Spring Boot uses Spring Framework to set up a monitor to watch various system resources, such as CPU usage, memory usage, database connection, web services availability. Notifies the team when system resources are critical.

LDAP Sync Service

Spring Boot Spring JPA

The Java program implements the user synchronization between the GSA LDAP server and EcoDomus

1.1.3 FME Server

In August 2020 IBM TRIRIGA (OASIS) SaaS was selected for a replacement for the systems OA (Occupancy Agreement ) Tool and eSMART (the electronic Spatial

Management and Reporting Tool) based on advantages to the OA and Leasing communities. The Spatial Data Management (SDM) business community discovered functionality gaps in the product for their business needs. OASIS relies upon the IBM TRIRIGA CAD Integrator which requires drawings that are in a specific drawing format to initially load drawings into the system and for ongoing operations. This will require major transformations on each drawing. In 2022, GSA acquired the Safe Software’s Feature Manipulation Engine (FME) to support the OASIS effort. The product is being configured to convert the existing eSMART CAD and Oracle Spatial data to CAD files that can be read by the IBM TRIRIGA CAD Integrator. This required that the FME Server be configured with Workspaces that would take content from a native geospatial database and combine it with CAD files, putting elements on specific layers and saving the finished document for user access.

The GSA is required to prepare drawings for migration into OASIS in addition to the continuous preparation of drawings to establish the assignment demographic of space within the federally owned and portfolio leased inventory. GSA enlisted the services of a Contractor to perform configuration and development of the FME Server because of their experience with the US Courts and their high recommendation to the GSA. The Contractor worked closely with Safe Software to begin an effort to have them create a process for the FME Server application to process the data for OASIS data migration purposes. Workspaces have been developed to encompass GSA’s needs to find errors in data configurations and perform clean up on the drawings. This is accomplishing the following objectives:

● Necessary IT documentation must be completed by the contractor to classify and prepare for management of the system.

○ Completion of Enterprise Quality Program (EQP) documentation and SLAM process set up.

○ The Contractor is responsible for licensing the appropriate version of the Safe Software FME Server and Desktop products in addition to working with the appropriate teams to ensure that such products are deployed to the intended user community.

● Changing and putting in place several data standards SDM requires on the target dataset

● Addressing features that address creation and preparation of drawings for OASIS.

● Creation of masked plans that reflect the OA for all tenants on demand.

● Automating key activities and deliverables that are provided to customers for daily operations.

FME Server has been deployed with the specifications listed below in Table 1. This application has listeners that are configured to monitor folders that are on the server that will be updated with various types of content by users. Currently, users map to a drive on the FME Server Windows Virtual Machine. Users of the FME server will have

Allen Samuel - IPT Need to attach documents to explain the CM process.

read/write access to the folders that they need to load and remove data from on the server.

With this contracted effort, the Center for Building Information Programs expects to further solidify the FME Server as the premier integration tool of choice for spatial data and what it’s related to. Additionally, the Ecodomus package and the BDR API for managing and sharing building information, serving PBS employees across the nation.

Current FME Environment The server specifications can be found in Diagram 1 below. Software that has been deployed on the existing infrastructure is also below. Since the Offerer is to be an expert in the use and application of Safe Software’s FME product line, corresponding software to complete the solution will be designated by the Offerer in the course of this effort (also as indicated below).

Software/Operating System

Category: Utility

INT FME Server OS: Windows Server 2019, 2 vCPU, 32 GB RAM, 100 GB OS drive, 500 GB Data/Application drive (to be updated and maintained by the vendor for the life of the contract)

TEST FME Server OS: Windows Server 2019, 2 vCPU, 32 GB RAM, 100 GB OS drive, 5 TB GB Data/Application drive

PROD FME Server OS: Windows Server 2019, 2 vCPU, 32 GB RAM, 100 GB OS drive, 5 TB GB Data/Application drive

INT FME Server: Version 2021.2.1 Build 21797 (legacy version, may be in transition to Version 2022.2.5 )

TEST FME Server: Version 2022.2.5

PROD FME Server: Version 2022.2.5

Diagram 1: FME Server Network High Level Overview

Dataflow, licenses, applications, and server components pertaining to the facilitation of drawing configurations produced by SDM and scrutinized by the software components that are part of this effort are articulated below.

Diagram 2: FME Server Data Exchange

System Interconnection The Offeror is responsible for developing, testing, maintaining and supporting the SQS and these integrations for the life of this contract but is not responsible for the development in other applications to make this connection successful.

2. Scope

The Contractor shall provide all personnel, administration, management and local travel necessary in support of the FME, Ecodomus and BDR API applications and ensure its success by providing support in the following Focus Areas (FA)1:

● FA1: Operation and Maintenance Support

● FA2: Project Management Support

● FA3: Enterprise Quality Program

● FA4: Tier II-III Helpdesk Services

● FA5: Security Compliance

● FA6: Optional Enhancement Support

This work will include but is not limited to software development, integration, testing, routine maintenance, platform and component upgrades, responses to infrastructure changes, defect identification and remediation, requirements development, capturing of enhancements, audit

1 Focus Area 7 (FA7) is covered in Section 5.3.

support, system analysis, impact analysis, documentation, reports, and progress monitoring using reporting procedures and measures of performance. These shall be in accordance with industry best practices, NIST, OMB, GSA and PB-ITS policy and guidance in a manner consistent with CMMI Level III and ISO 9001:2015 practices and protocols.

When possible, the Contractor shall execute processes in a sustainable and repeatable process using an Agile methodology of identifying, describing, testing and delivering technical solutions.

The Contractor shall be responsible for the integration and support of the application including all enhancements made to the application.

3. Objectives

The Contractor shall assume responsibility to provide support for the operation, maintenance and performance of the FME system, the Ecodomus system and the BDR API. Support for this application includes three environments: Development (DEV, Integration (INT). Test (TEST or TST), Production (PROD or PRD).

The Contractor shall coordinate all technical implementation tasks with Government-designated support teams including server, application, network and/or security teams. This includes all necessary technical support, changes and architectural expertise to maintain the application in compliance with all existing GSA policies and guidelines. Issues that may be discovered through scans, reviews, audits, and regular usage throughout the BPA Call and phase-out periods shall be resolved in the timeframes defined by GSA Policy.

The Contractor shall follow the approved PB-ITS lifecycle methodology for system upgrades, releases, and maintenance activities.

3.1. FA1: Operation and Maintenance Objectives

The Contractor shall ensure the application and all ancillary applications are available for use and shall resolve defects when identified. (In this context ancillary applications include applications such as, for the API, ActiveMQ, Activity Monitor and the APITokenGenerator.

Since this API is in the state of migration and augmentation, such ancillary applications may increase or decrease.) Fixes to defects may include modification of executable code or upgrades to pertinent software. In the event of such changes, the Contractor shall execute software testing and configuration management efforts. The Contractor shall continue to maintain existing interfaces to other applications. The Contractor shall coordinate with the App Ops Team regarding system outages and hardware/ firmware or interface issues.

Identifying and repairing defects resulting from design errors, logic errors and coding errors. The Contractor shall document the defects that are the result of the following operational objectives:

● To address data processing errors, system performance errors, escaped defects from internal Contractor quality control and user acceptance testing (UAT), or reported through a help desk or other incident identification methods.

○ To make corrections to a system stoppage or an inaccuracy in the application, which must be dealt with and issued immediately.

● The Contractor will meet the following objectives of maintenance:

○ To ensure the application is operable using the GSA list of approved desktop and server software.

○ To ensure and test that the application remains equally compatible with GSA-designated desktop operating systems and internet browsers including Microsoft Edge, Google Chrome, and others as required. The current agency standard for desktop operating systems includes Microsoft Windows 10 and internet browsers Microsoft Edge and Google Chrome.

○ To ensure the application remains optimally operational following government and commercial best practices of design, such as the U.S. Web Design System (https://designsystem.digital.gov).

○ To ensure the application is optimally performant and secure following government and commercial best practices of implementation. The Contractor may recommend to Government-designated support teams technical configurations that may improve performance, availability or stability. However, the Contractor shall ensure the application is optimally available given the architecture, toolsets, configurations and resources available within the agency.

○ To notify the Government of hotfixes or end-of-life dates to the operating system, middleware, database or supporting technical platforms (including patches) impacting the usability or having an impact on the application. Contractor shall be responsible for coordinating with the Government to ensure components of the application will be upgraded prior to the end-of-life hardware/software.

○ To ensure the application remains operable following changes to the environment in which the application resides. The application will optimally perform with applied patches in accordance with IT Security Policy and prior to Government-designated published update cycles. The environment changes may result from updates to business rules or processes, government policies, and software and hardware platforms.

○ To accommodate new or evolving user requirements. This generally includes functional or user interface enhancements to a component or service and activities that increase the system’s performance. Updates may include modifications to existing templates or reports. (Note: enhancements are considered those where there are significant structural change(s) or significantly new features are added requiring substantial work and are not included in this category of maintenance and support).

○ To actively perform tasks aimed at increasing the system’s maintainability, such as improving the modular structure of the software systems and updating documentation. This maintenance includes the upgrade of components before they reach end-of-life , frameworks, versions to maintain the technical operation of the information system.

● The Contractor shall meet the objective to support server or data migrations to ensure applications are operational post-migration. Migration activities may include any environment, on-premises server to server, data conversions, on-premises to cloud, application refactoring or other topologies.

● The Contractor shall meet the objective to perform maintenance to ensure the application meets minimum accepted performance targets. Maintaining the system’s performance, maintainability, reliability and security shall follow emerging standards such as the Consortium for IT Software Quality (CISQ) (http://it-cisq.org/standards/), including the updating of documentation and the upgrade of components, frameworks, versions to maintain the technical operation of the information system.

● The Contractor shall meet the objective to deliver corrective responses to security findings ensuring compliance with Government security requirements. Delivery of these corrective security findings shall be conducted within the timeline designated by audit teams, or may follow prescribed deadlines. The Contractor shall ensure the corrective response is within the minimally recommended date. Current policy requires all high and critical findings to be resolved within 30 days.

3.2. FA2: Program Documentation Management Objectives

3.2.1. There is an objective for the contractor to create and maintain a library of files (Knowledge

Base) that document the processing of work products, deliverables and other associated information pertaining to actions performed under this task. The Contractor shall maintain the library within the Government-designated electronic repositories. Examples of filing objectives include, but are not limited to, the following:

● To provide documentation furnishing traceability and rationale for the contractor's technical program decisions.

● To provide the latest version of all specifications, drawings, databases, and software that define or implement the system.

● To provide detailed Standard Operating Procedures (SOPs)

● To provide all configuration management documentation.

● To provide final documentation and software packages utilized in every application release.

● To provide program work products and deliverables.

● To provide updates related to reporting artifacts (including and not limited to data dictionary changes impacts from enhancements) to reporting team and downstream data consumers.

● To ensure government access to all records. Upon completion of the task, the Contractor shall turn over all such records to PB-ITS in approved formats.

3.2.2. C

ommunications and Meeting Support Objectives

● There is an objective for the Contractor to provide the following communication support services to maximize IT efficiency and stakeholder satisfaction throughout the PB-ITS:

● Strategic Communications: proactively deliver an ongoing campaign to identify IT tasks which can be solved by the end user without help desk support; draft communication (e.g. emails, web pages, quick guides) to guide users through self-help steps; and promote that content via email and live training sessions.

● Operational Communication: develop and deliver communications about operational status of systems and tools. Subject matter shall include real-time and future system outages, system updates, and other end-user-targeted information.

● Data Analytics: provide frequent reviews of data such as help desk tickets, web analytics, surveys, inventory etc. to determine audience needs and deliver information for management to achieve strategic goals.

These reviews shall include a report and recommendations for application improvement. Assist with implementing those recommendations and tracking their impact.

● Meeting Support: Attend and support meetings, briefings, etc. on behalf of or in support of the application.

3.3. Contingency Plan Objectives

3.3.1. The contractor shall develop and maintain a Contingency Plan (CP) for the full restoration of application functionality in the event of an unforeseen catastrophic technology event.

Generally part of a larger organization-wide Continuity of Operations (COOP) event, the application is expected to become fully functional without consultation of or intervention by O&M staffing.

3.3.2. The CP must be sufficiently detailed that a restoration could be successfully performed in two isolated scenarios: 1) from virtual machine snapshots and 2) from file backups alone (no snapshots available).

3.3.3. The contractor shall participate in Contingency Planning exercises as requested by the Government. This shall include creating and updating documentation upon request, participating in exercises, and providing support as requested by Government groups.

3.4. FA3: Enterprise Quality Program (EQP)

3.4.1. The Contractor shall follow the Enterprise Quality Program (EQP) for Public Buildings

Information Technology Services (PB-ITS) that provides the foundation for increasing and controlling the quality of IT products and services to PBS. The EQP incorporates sound CMMI processes that will ensure products and services are on time, within budget, and meet the requirements of our PBS customers. The EQP has three distinct areas: Project Management, Quality Assurance and Independent Verification and Validation. PB-ITS continuously works to improve its processes in order to deliver quality products and services for the first time.

3.4.2. The Contractor shall follow the EQP documentation standards. All required deliverables shall be produced in accordance with EQP requirements, GSA PB-ITS EQP Configuration Management Plan (refer to Attachment C), as well as all GSA Security standards.

3.4.3. Documentation shall be included as artifacts for each deliverable consistent with the EQP processes for each given release. Releases may require a complete set of installation scripts, installation files, configuration files, test scripts, Data Dictionary, Entity Relationship Diagrams, Functional Requirements, Installation Plan, Operations Manual, Release Notes, System Design, System Security Plan, Test Plan, User Manual and other supporting documentation.

3.4.4. All documentation is expected to be accurate in content, context, grammar and spelling.

3.5. DevOps

3.5.1. PB-ITS has implemented DevSecOps processes and tools for the automation of application installations. This solution is a collection of open source and standards-based tools currently using JIRA as the front end for project managers and developers with Jenkins and Ansible “under the hood.” The current tool set includes Jira, Jenkins, Ansible, Git, Selenium, and Artifactory.

3.5.2. Releases managed through the DevSecOps process will be required to provide certain artifacts to ensure a compliant build. Those currently include Source Code, Executables and Build Scripts. Build scripts can currently be written using Ansible, Bash, or Powershell.

3.5.3. The Contractor shall provide necessary artifacts to release this application through the DevSecOps process and shall comply with GSA IT DevSecOps Guide and all other GSA policies and guidance. The Contractor shall participate in inter-disciplinary meetings hosted by DevSecOps. The Contractor shall attend training, as requested, in order to attain/maintain efficiency in DevSecOps tools.

3.5.4. The Contractor’s application development methodology and operational processes must conform to PB-ITS DevSecOps processes.

3.6. Software Code Quality

3.6.1. As part of its continuous delivery improvement, PB-ITS will be implementing a software code review process and quality analysis. The Contractor shall be expected to adhere to PB- ITS application coding standards as defined. The Contractor shall adhere to the standards for delivery and create highly maintainable code that is free of critical quality defects.

3.6.2. PB-ITS may also employ Software Code Quality (SCQ), an analysis that will evaluate application risk around robustness (stability, resilience), performance, architectural security, transferability, system maintainability (sustainment) and changeability of applications as they evolve. These measurements are based upon industry best practices and standards related to complexity, programming practices, architecture, database access and documentation. They are derived from standards bodies such as the International Organization for Standardization (ISO), Software Engineering Institute (SEI), Object Management Group (OMG) and the National Institute of Standards and Technology among others.

3.7. FA4: Tier II-III Helpdesk Services

3.7.1. The Contractor shall provide Tier II-III Customer Support Services for the FME, Ecodomus and BDR API applications. The Contractor will also be responsible for logging of trouble tickets, user inquiries, enhancements, and database change requests.

3.7.2. Helpdesk support tiers are defined as:

● Tier I (provided by GSA IT/PB-ITS): GSA will provide simple local and phone support. At this level, the customer may possess a broad understanding of either the FME or Ecodomus systems and may not understand the inner workings. In this case, the specialist would identify a customer’s needs and provide tips on how to manage a problem. BDR API issues will immediately be handled/forwarded to the Tier II or Tier III levels. These solutions will be documented and maintained in the Knowledge Base. Also, log-in issues are resolved here. When a Tier 1 support team member is not able to resolve the issue, they classify the problem and pass it on to the appropriate Tier II specialist.

● Tier II (required of the vendor under this BPA call): involves technical knowledge and is staffed by technicians who have troubleshooting capabilities beyond the Tier I support. If the issue is an existing one, the Tier II specialist will research a solution or a workaround. In cases where there is no solution, it should be logged as an open bug.

If a customer experiences a new issue, further analysis has to be done to see if it can be resolved. If the tech cannot fix the problem at this tier, the problem goes to Tier III.

● Tier III (required of the vendor under this BPA call): This tier engages the technical expertise of those involved in development. This is where the complex issues and any outstanding issues that were escalated in the previous tiers are addressed. Usually, the work performed at this tier results in a system release.

3.8. Help Desk

3.8.1. The Contractor shall utilize the GSA IT Service Desk ticketing system, currently

ServiceNow, to address all requests for application assistance. The Contractor is expected to provide sufficient written resources for Tier I Help Desk personnel to resolve frequent requests without escalation.

3.8.2. A designated legacy Contractor/Government Maintenance Team support email group shall be used called PBSCFRSupport (a Google Group located at pbscfrsupport@gsa.gov) and maintained. The Contractor shall assist in troubleshooting application specific issues and supporting ad-hoc urgent requests such as Federally-designated disaster relief efforts.

3.8.3. Metrics shall be kept and reported regarding the number of Help Desk referrals during the month, capturing details such as user regions, types of requests, times to respond, times to resolve, and overall status including unresolved referrals. The metrics shall be submitted as part of the monthly report. Success of issue resolution shall be coordinated with the Government PM, making every effort to resolve each issue prior to closing each ticket.

Every ticket should ultimately resolve into one of the following resolution statuses:

● Issue Fully Resolved: The issue was fully resolved by an existing policy directive, personalized support, standard operating procedure (SOP) or other pre-existing solution.

● New Issue – No Enhancement Needed: The issue was not previously documented and was fully resolved by personalized support. No workaround or application patch is needed. The issue must be documented as a new SOP, approved by the Government PM and then communicated to the Help Desk.

● New Issue - No Work-Around Available: The issue was not previously documented and potential solutions were fully explored. No work-around was found to fully address the issue. The Enhancement Log must be updated in order to capture the details of the issue and plan for a full resolution in the future.

● New Issue - Work-Around Communicated: The issue was not previously documented and a work-around was developed to fully address the issue. The Enhancement Log must be updated in order to capture the details of the issue, the work-around that was implemented and plan for a full resolution in the future. The work-around must be documented, approved by the Government PM and then communicated to the Help Desk.

● Issue Abandoned: The resolution effort was abandoned due to events beyond the scope or control of the team. An example might be an issue awaiting an application enhancement that is no longer necessary due to a security directive that prohibits the enhancement. The abandonment must be documented, approved by the Government PM and then communicated to the Help Desk.

3.9. Training

3.9.1. The Contractor shall hold formal training sessions after each major application release and as deemed appropriate based on user feedback. Training sessions should cover new, removed or changed features in the application and related business processes. Training sessions should be well organized and thoroughly explore the scheduled topic(s), should have sufficient documentation to provide to users on a given topic, and all the while providing sufficient time for question/answer time. Training can be recorded so as not to be repeated for future audiences with the same need. A Google Site dedicated to the FME and Ecodomus initiatives can be maintained to communicate recorded training and training materials at all levels. GSA reserves the right to insist that all training be recorded.

3.10. FA5: Security Compliance

3.10.1. C

ontractors entering into an agreement for services to the General Services Administration (GSA) and/or its Federal customers shall be contractually subject to all GSA and Federal IT Security standards, policies, and reporting requirements. The Contractor shall meet and comply with all GSA IT Security Policies and all applicable GSA and NIST standards and guidelines, other Government-wide laws and regulations for protection and security of Information Technology.

3.10.2. S

ee Attachment A.

3.11. FA6: Enhancement Support

3.11.1. E

nhancements are significant modifications to the application that add functionality or features to the application. Enhancements do not include configuration changes, technology upgrades, security or application patches or actions that are required to ensure the application remains operational.

3.11.2.

Technical Roadmap Subtask

● The Contractor shall provide technical guidance in assisting the Government to understand the impacts and requirements of potential changes to the application.

● The Contractor shall draft a technical roadmap for the application, combining program, application and technical requirements as necessary or requested. This summary document shall include a system configuration section that includes all of the components the application is required to run and the operating environment in which it is expected to perform, including Operating System, Database, Middleware, Technical Platforms (if any) and ancillary supporting applications, modules, or software packages. For each component a transition plan including rationale for retirement and proposed retirement dates for support shall be included when known.

The technical roadmap shall document recommended time-frames to ensure all system components remain fully licensed and supported.

3.11.3.

Optional Enhancements Subtask

● The Contractor shall work with the government to establish and manage an

Enhancements Log of suggested application requirements, features and other types of requests to improve the application platform. Contributions may come from many sources, such as the application user community, Government PM, GSA management and contracted application developers.

● The log shall constitute a prioritized list of tasks related to the enhancement of the application. The Contractor shall engage the Government to establish priorities and collaborate on the estimated size of each task. The log shall include proposed requirements and user stories to describe elemental tasks and shall document task objectives, user impacts and acceptance criteria. Tasks may be rolled into containers such as epics and themes as they address objectives of the task. Management of the log shall ensure that stories, descriptions, personas, estimates and test cases meet the objectives of the task.

● From time to time, an Analysis of Alternatives (AOA) may be requested in support of one or more proposed enhancements. The AOA should clearly show an analytical comparison of suitability, risk and cost associated with available and Government suggested solutions.

● Optional Automation of key activities and deliverables that are provided to GSA internal and/or external customers for daily operations may be required via the FME software suite. This can be with a series of workspaces that are able to be employed interactively by the user as long as they are accessible (able to be initiated) to GSA. These could also be configured with Autolisp, .NET, VBA or another web or desktop application or accessing technology, as long as the initiation is GUI based (unless the solution is for an enterprise application.)

Collaboration with the GSA to determine the best course of action for the creation of the following configurable features will be necessary. The options to configure the may be any (or none) of the following:

● Color-coded queries for attribution including (but not limited to) one or many of the following Vacant Space, Agency, OA, Parking & Antenna information/objects, and any other attributes associated with polylines or objects. Such may involve color coding elements as retrieved from PostGIS or color coding polylines based on text entries sitting in the middle of spaces. GSA desires that color-coding have the option of being combined with hatching to further distinguish individual entities on a given report. Such hatching and color-coding will need to be configurable per report initiation.

● Selection and inclusion in the output report of a GSA title block, indicative of the size of the drawing/report that will be produced. The title block will have attribution that can be populated by queries to the drawing or the associated data repository that polygon data was retrieved from.

● Selection of attributes to place as text inside of the space object in the predefined order for GSA.

● Creation of a legend to summarize the types of data attribution that is attributable to the floor in the building based on calculations derived from either OASIS or PostGIS.

● Option to create and place a Controlled Unclassified Information message to be provided by GSA.

● Option to create a date stamp.

● Option to bind the architectural background of the floor plan.

● Option to create a graphic scale (or select an appropriate scale to be imported into the document)

● Option to insert a label (or populate an attribute) that represents the Building ID and Floor Indicator concatenated with the floor level (for example: DC0031 F001)

● Report configurations with all of the above options must have the option to be saved for future use with a specific file naming standard to be disclosed by the GSA.

● Optional Interconnections: Creation of interconnections between FME Server and App Connect and FME Desktop and App Connect. Creation of interconnections between FME and GSA’s National Computerized Maintenance Management System. Creation of interconnections between FME and GSA’s ArcGIS Portal or Online implementations. Interconnection between FME and the BDR system using the BDR API.

● Optional Enhancement of Core Components: Enhancement may be necessary on the BDR API to expand its features. This may require collaboration with one or more GSA Business Lines or with GSA IT (separate from GSA PBS IT) to effect changes in the Alfresco environment. Additionally, work may be required to be performed with Siemens to expand the capabilities of Ecodomus. Lastly, the FME Server/Desktop (Flow/Form) packages may need some expansion of capabilities that requires collaboration with Safe Software that is of such scale and of high interest to the government that the Contractor may be tasked to manage.

3.11.4. W

ork Estimates Subtask

● The Contractor shall develop estimates based on the level of detail available. The

Government may request any one of the following types of estimates:

● Rough Order of Magnitude (ROM) - a high level idea, including the best-that-we-know expectation for the enhancement or its components.

● Level of Effort (LOE) - a comparable estimate based on previous work completed

● Level of Complexity (LOC) - Also known as costing. Estimates provided by the development team that represent the level of difficulty of each user story (impact/change). The LOC also provides insight into the available capacity of the team while also determining if the team’s velocity is increasing over time.

● Impact Analysis (IA) - the estimate examining more specific details or proposed solutions, including their implementation and downstream impacts.

● Once the COR finalizes the enhancement requirements for formal submission to the Government Contracting Officer (CO), the CO will issue an Enhancement Notice and Request for Quote (RFQ) to the Contractor. In response to the RFQ, the Contractor will have 10 business days to submit a System Impact Plan/Software Development Plan (SIP). The SIP must provide details of the proposed technical solution, a description of the impact to the overall system, proposed milestone schedule, and the labor mix utilizing the labor categories and rates contained in the PB ITS Blanket Purchase Agreement (BPA–if the BPA is used to procure these services. Otherwise, the labor rates agreed upon between the Government and the Contractor will be used).

The Government shall review the plan and negotiate any changes required. Upon approval of the Plan and agreement on price, schedule and any other terms and conditions, the Government will issue a modification to the BPA Call, establishing a sub-Contracting Line Item Number (CLIN) and providing funding. Enhancements will be negotiated as firm, fixed price sub-CLINs to the greatest extent possible.

4.0 Labor Requirements

The Contractor shall dedicate personnel who exhibit a professional history of implementing technical solutions and effectively communicating verbally and in writing, including the use of email, word processing, spreadsheet, and presentation tools. Technical writing skills are necessary to support specific areas of the requirements in this task. All applicable GWACs Labor categories can be utilized pursuant to the requirements of the GWAC contract.

The Contractor shall identify personnel deemed “Key” to execute this task with a professional history of working on technical teams. All Team members should exhibit a successful history of working on technical projects for at least three (3) consecutive years, unless additional experience is specified. Key personnel shall be solely dedicated to this task.

Table 4. Key Personnel Experience and Certifications

Key Personnel Experience and Certifications

Position FTE Required Desired

Project Manager (PM)

1 Bachelor's degree in computer science, engineering, information security, or similar discipline. Current PMP certification, 10+ years of experience leading IT software development and O&M projects. Five (5+) plus years of agile project management experience and able to obtain a Public Trust security clearance.

Scrum master, PMI-ACP, or SAFe certification. Master's degree in computer science, engineering, information security, or similar discipline. Experience with organizational transition from waterfall to agile project methodologies.

Scrum Master (SM)/Business Analyst (BA)

1 Bachelor's degree in computer science, engineering, information security, or similar discipline. Current scrum master or PMI-ACP certification. Experience with Agile projects, scrum project methodology, Jira software, requirements management, and software testing.

Must be able to obtain a Public Trust security clearance.

Master's degree in computer science, engineering, information security, or similar discipline. Advanced scrum master certification. IIBA certified.

Software Engineer

1 Bachelor's degree in computer science or software engineering, or similar discipline. Five (5) years of programming/coding experience with JAVA with current JAVA certification. Must be able to obtain a Public Trust security clearance.

Master's degree in computer science or software engineering. Current Scrum Master or PMI-ACP certification.

Software Engineer Lead

1 Bachelor's degree in computer science or software engineering, or similar discipline. Ten (10+) plus years of programming/coding experience with JAVA with current JAVA certification.

Experience with leading software development teams in an Agile/Scrum environment. Must be able to obtain a Public Trust security clearance.

Master's degree in computer science or software engineering. Current Scrum Master or PMI-ACP certification.

** For purposes of clarity, the project manager and scrum master can be the same person, but will be required to perform the work required of both positions. This a notional staffing plan, labor category names may vary, but the required skill sets need to be included by the contractor.

All contractor employees requiring access to GSA information shall meet the minimum personnel suitability standards. These suitability standards are based on a valid need-to-know, which cannot be assumed from position or title, and favorable results from a background check. The contractor shall follow the guidelines established by the Homeland Security Presidential Directive-12 (HSPD-12). HSPD-12 requires a background check performed by GSA and the ability to support the use of PIV cards, including reading and authenticating an individual with a PIV card, and the passing of PIV credentials to other GSA related networks for authentication.

Key personnel are required to have HSPD-12 clearances by GSA prior to start of the transition period to ensure full knowledge transfer.

The Contractor shall ensure a stable workforce during the performance of this contract.

During base award, the Contractor shall make no substitutions to personnel unless the substitution is necessitated by illness, death, or termination of employment. The Contractor shall notify the Contracting Officer (CO) and the Contractor Officer Representative (COR) within fifteen (15) calendar days after the occurrence of any of these events and provide the information required by the paragraph below. The Contractor shall provide a detailed explanation of the circumstances necessitating the proposed substitutions, complete resumes for the proposed substitutes, and any additional information requested by the CO.

Proposed substitutes should have qualifications equal to, or greater than, the person to be replaced.

The GSA CO in consultation with the Contracting Officer Representative (COR) shall evaluate substitution requests and promptly notify the Contractor, in writing, of his/her approval or disapproval thereof. At the discretion of the COR, an interview with the proposed personnel may be required to verify that the proposed substitute has qualifications equal to, or greater than, the person to be replaced. The COR shall notify the Contractor ten (10) business days in advance of the proposed substitution date if the COR chooses to conduct an interview to review the qualifications of the proposed individual. Only the CO has authority to accept or deny personnel substitutions. The CO will notify the Contractor within five (5) calendar days after receipt of all required information of the decision on substitutions.

5.0 Deliverables

Deliverables acceptance will be subject to Government acceptance testing to include required functionality and review of documentation. The Government will review and comment on all drafts and deliverables within fifteen (15) working days of receipt, unless specified differently below. Acceptance or rejection of deliverables shall be made by the Contract Officer Representative (COR) in writing, giving the specific reason(s) for the rejection. The Contractor shall correct the rejected deliverable and return it on the date specified by the COR. While deliverables are under review, Contractors will continue work on follow-on activities to maintain the project schedule.

Table 5. Deliverables

Section Deliverable Description Delivery Schedule

3.1 Defect Documentation

(Root Cause Analysis

(RCA))

The initial report shall be delivered via email to the Government Program Manager and COR.

Each report shall indicate the next estimated update. The Contractor shall make updates to the PM and COR following this schedule and/or when requested by the Government.

3.1.1 Release & Performance

Documentation

The Contractor shall follow the published EQP Guidelines for software submission (see Appendix).

The Contractor shall be responsible to provide the following reports not to exceed the frequency indicated. The format shall follow Government mandated formats provided at the time of the request:

System Inventory Document (SID) annually and as needed after major enhancements or changes

System Security Plan Annual or as-required

3.2.1 . Monthly Status Report Monthly by the 5th calendar day of the month

3.2.2 System Design Document (SDD) annually and

as needed after major enhancement or changes.

3.2.2 REXUS Standard…