Attach 4-Task 3 Delphi-Prism Development and Support 2024 (Draft ver 2).pdf

Information Technology Support Services (ITSS)

Task Statement of Work

Delphi/Prism Development and Support

Enterprise Services Center 6500 South MacArthur Boulevard

Oklahoma City, OK 73125

22 September 2022

1.0 Introduction and Overview

2.0 Background

3.0 Description of Work

A. Provide Agile Teams

B. Development:

C. Code Quality and Standards Compliance

D. Test, Integration and Deployment

E. Quality Control and Production Support

F. Access Control Group

4.0 Definitions/Acronyms

5.0 Performance Outcome(s)/Deliverable(s)

5.0.1 Task 1: Quality of Team Development Team self-evaluation Report

5.0.1.1 Team self-evaluation Grading ................................... Error! Bookmark not defined.

Task 2: Configuration/Change Management Policy

Task 3: Code Quality and Standards Adherence

Task 4: Engineering

Task 5: Test Scripts

Task 6: Businesss Value

Task 7: Development

Task 8. Productivity

5.0.2 Task 9: Production Support Tickets

5.0.3 Task 10: Submission of Team Self-Assessment ............. Error! Bookmark not defined.

5.0.4 Task 11. Team Predictability:

5.0.5 Task 12: Submit, Monitor, and Oversee Vendor Service Requests (SR)

5.0.6 Task 13: Delivery Review Status Reports

5.0.7 Task 14: Customer satisfaction

5.0.8. Task 15. Access Control Services

6.0 Reference Documents (if applicable)

7.0 TPWS Support Requirements (if applicable)

8.0 Place of Performance

9.0 Work Schedule

10.0 Training

11.0 Travel

12.0 Privacy and Security Requirements

13.0 Government Furnished Property (if applicable)

Reference PWS 6.3

14.0 Government Surveillance - Inspection and Acceptance Criteria

15.0 Technical Exhibits:

Technical Exhibit 1 - Performance Requirements Summary

Task Performance Work Statement (TPWS) Development

Task Reference No.: Task 3 Development Type: Labor Hour

1.0 Introduction and Overview

The mission of the ESC Engineering and Solution Delivery Branch is to provide the US Department of Transportation (DOT) and the Federal Aviation Administration (FAA), and other governmental agencies with sound and cost-effective systems consistent with DOT and FAA goals and programs meeting the information needs of customers both internal and external.

2.0 Background

Engineering and Solution Delivery Branch provides a wide variety of information technology and business services to the FAA, DOT, and other government agencies including Commercial Off the Shelf (COTS) configuration, support, application administration, information technology consulting, project management, life cycle software development, and ongoing maintenance and operations support.

The Engineering and Solution Delivery Branch provides development support, including system design, programming, implementation and system support for the Mike Monroney Aeronautical Center (MMAC), the FAA, and the DOT. In the Spring of 1997, the Office of Financial Management (OFM) and the FAA’s MMAC accounting system managers determined that the Departmental Accounting and Financial Information System (DAFIS) was nearing the end of its life cycle. The OFM decided to conduct a study to look at the evolution of DAFIS to a system that would meet the current and future needs of the Department. After an evaluation team and a study with an operations capability demonstration (OCD) of 25 “super scenarios” which assimilated the Departments most complex business processes as defined by the operating administration and incorporated the DOTs functional evaluation criteria, the results were the high percentage of expected results successfully demonstrated by Oracle financials, the DOT Deputy Chief Financial Officer (DCFO) endorsed the evolutionary migration to Oracle federal financials, which is called the DOT Delphi program.

ESC selected the Unison (previously Compusearch) PRISM product as the COTS solution for acquisition management. In 2001, Oracle Compusearch Integration (OCI) was released using Oracle’s Application Programming Interfaces (APIs). Oracle consultants were obtained to write custom APIs to support obligations and deobligations within PRISM. In 2006, Oracle’s APIs were released thus providing an automated supported process through Unison’s web services.

This ability must be maintained through maintenance releases of software packages to appropriately account for obligations and deobligations through the PRISM acquisition system.

ESC financial and administrative systems currently includes 21 Department of Transportation (DOT) and non-DOT agency departments as customers. Additional customers may be added or removed through the course of this task.

ESC continues active marketing to cross-customer service of other federal agencies through the Center of Excellence (COE).

Development efforts are driven by federal regulations and federal customer requirements. Efforts may include new development third party software releases, data fixes, database upgrades, and re-engineering of current business processes for new and existing customers.

3.0 Description of Work

ESC Development must provide highly productive Oracle e-Business Suite and Unison Procurement development services using the Scaled Agile Framework (SAFe) 4.0 or higher to help move ESC towards its envisioned state of technologically innovative, state-of-the-art, electronic and customer-centric architecture to support ESC’s mission. ESC contractors work alongside other government contractors and federal employees to accomplish projects as assigned by ESC. For some development efforts, there will be a number of Agile teams from several contractors working in parallel in a collaborative environment. These development teams will be supplemented by separate teams responsible for architecture and design, processes and practices (methodology), Continuous Integration and Continuous Delivery (CI/CD), testing, quality assurance and training development for capability.

ESC contractors must work within a technical architecture and design specified by the government, and within the Agile process and Software Development Lifecycle (SDLC) frameworks defined by the government team. Additional teams include government employees functioning as Product Owners, Product Managers, Business Owners, and Subject Matter Experts (SMEs). Product Owners and Product Managers may be contractors, in which case all inherently Governmental roles must be completed by the Business Owner. Teams may also have participation from Independent Validation & Verification (IV&V) teams. ESC development contractors are expected to work well in these team environments and demonstrate a highly collaborative and cooperative attitude.

The contractor must provide the necessary functional and technical analysts personnel with the system applications experience and federal experience to analyze customer’s business requirements and incorporating those requirements into applications. Applicable labor categories which may be utilized by the SOW:

Application Engineer I, II, III, IV, V Application Systems Analyst I, II, III, IV, V Application Systems Analyst/Programmer I, II, III, IV, V Functional Analyst I, II, III, IV, V Information Engineer I, II, III, IV, V

Systems Analyst/Programmer I, II, III, IV, V Scrum Master I, II Technical Writer I, II

As technology changes, if necessary, the government may incorporate additional labor categories.

An Agile Team is comprised of a Product Owner, a Scrum Master, a Technical Writer, and a Development Team. ESC may utilize each labor category to fulfill these roles, or may choose to augment the team with other resources for completion of modified tasks. The roles and responsibilities of each entity follow the framework as outlined in both the Scrum Guide (Schwaler and Sutherland, July 2016) and the Scaled Agile Framework 4.0 or higher (SAFe 4.0, Dean Leffingwell, 2016).

The team is self organizing within their respective team and responsible for completing their work with priority set by the Product Owner

• The team estimates the size and complexity of the work

• The team determines the technical design in their area of concern, within the architectural guidelines

• The team commits to the work they can accomplish in an iteration or Program Increment (PI) timebox

• The team is responsible for value and builds to continuously improve the quality of their deliverables

• The team is continuously committed to finding ways to improve

ESC requires flexibility in the sizes of Agile Development Teams. These members are to be highly versed self-organizing, self-managing, cross-functional teams focusing on system analysis, programming, testing, documentation, and application development. Team members must work in collaboration with other teams for smooth deployment of projects, defects/break fixes, and customer requirements. At times, ESC may pull together a short-lived team of cross functional team members for project work.

The tasks identified in the following sections describe the work that must occur in order to accomplish the ESC mission. ESC contractor must provide contractors that are able to perform the tasks as described, while conforming to expectations outlined above, and with expert level ability in the technologies as listed in Reference Document 005. As the technical landscape evolves, the skills of the contractor’s teams must also evolve. At all times, teams will be required to look at business process re-engineering to accomplish requirements within the framework of the commercial off the shelf software (COTS) functionality instead of writing custom code.

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration http://en.wikipedia.org/wiki/Software_development_methodologies http://en.wikipedia.org/wiki/Iterative_and_incremental_development http://en.wikipedia.org/wiki/Iterative_and_incremental_development between self-organizing, cross-functional teams that contain all the skills necessary on the team to deliver valuable solutions. SAFe promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.

SAFe is a framework that guides teams throughout the development cycle as introduced in the Agile Manifesto and Principles in 2001.

Agile Dev/Ops, which is a clipped compound of development and operations, is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. The team draws work from the program backlog and iteration backlog.

A. Provide Agile Teams

a) Contractor must provide Agile Development team members for the purpose of responding to specific application development requirements ESC identifies. The contractor’s work must conform to the architecture and design provided by the ESC Architecture and Design team and the Agile processes set up by the ESC Processes and Practices team.

b) Contractor must provide an Agile DevOps team capable of deploying code. The contractor must partner with Information Technology (IT) operations staff to ensure that software runs according to business requirements. The contractor must support and deliver practical processes and foster collaboration between development and IT operations. The contractor must be working in DevOps-mode and must be proactive in monitoring rather than reactive to alerts. Under the DevOps model, developers must continue to have visibility to the code even after it goes to production. Developers must participate in the delivery of the code from creation to running in the pipeline to deployment and then maintenance. Contractors must be required to work with software vendors, opening service requests and monitoring the status of those requests.

c) The skills of the team members must evolve over time as the technical landscape evolves.

An individual must only serve on a team when that person’s skills match the needed work and may require the rotation of duties within the team.

B. Development:

a) The contractor must be responsible for development teams performing the full suite of development tasks using Agile methodologies to include Extreme Programming Development practices, Scrum Project Management concepts and KANBAN Board frameworks. These practices include but are not limited to: participating in creating user stories for both business functionality, technical requirements and defining acceptance criteria; estimating the size of stories; solution design; development; and testing. The following additional knowledge required is outlined by teams.

b) The contractor must assist in the documentation of user stories, including acceptance criteria to fulfill, and the definition of done for a story, that deliver the value to the customer.

http://en.wikipedia.org/wiki/Self-organization#Self-organization_in_agile_software_development http://en.wikipedia.org/wiki/Cross-functional_team http://en.wikipedia.org/wiki/Timeboxing

c) The contractor must develop code and other artifacts against the user stories documented as assigned by the government.

d) The contractor must provide traceability of all corrected defects back to the original User Story and Features.

e) The contractor should regularly validate their user interface mockups and perform usability testing with requirements personnel, including subject matter experts and regular users.

C. Code Quality and Standards Compliance

a) The contractor must develop code that does not add new technical debt to a release;

however, there may be instances where technical debt is unavoidable and may be incurred with the government’s approval. In these cases, the contractor must actively work to decrease technical debt; the contractor must correct any defects identified by testers, code reviewers, automated tools, or as part of the CI/CD activities etc.

b) The contractor’s work must conform to the architecture and standards provided by the Government and the Agile processes set up by the ESC Processes and Practices team.

This must include providing input to any documentation required to maintain compliance with FAA and ESC standards, as specified by ESC.

c) The contractor must architect, develop, and deploy software in accordance with industry best practices. The contractor must stay fluent with industry best practices as they evolve.

Solutions should follow the Enterprise Architect’s solution if available.

d) The contractor’s code must meet functional and non-functional requirements, meet database development requirements, meet testing requirements, and be deployable and fully tested in preparation for ESC Independent Validation & Verification (IV&V) review.

e) Applications are developed in accordance with web application security standards and industry best practices as defined by the National Institute of Standards and Technology (NIST) and Open Web Application Security Project (OWASP).

1) Contractor teams will maintain adherence with all Federal and Agency information security policies, standards, and guidelines.

a. Development processes will incorporate the Risk Management Framework (RMF) and Security Systems Development Lifecycle as defined by NIST SP 800-37 and NIST 800-64.

b. Projects will incorporate applicable security controls as defined by NIST SP 800-53, and implemented by agency policy.

c. Source code must align with standards outlined in Executive Order (EO) 14028, “Improving the Nation’s Cybersecurity” and related government-wide initiatives/requirements.

d. Any utilization of cloud components must comply with the FedRAMP security standards and have listed FedRAMP authorization.

e. Source code will be subject to compliance and vulnerability scanning by Federal employees. The contractor will be responsible for fixing any vulnerabilities or weaknesses identified by scanning.

f. Development teams will use branding and design standards in accordance with FAA policy.

g. The contractor must ensure that defect corrections are fully tested before User Acceptance Test (UAT) deployment.

D. Test, Integration and Deployment

a) The contractor must be responsible for creating test cases that follow test-driven development principles, with automated test scripts and non-automated test scripts, to support test automation activities, thoroughly testing the code.

b) The contractor must collaborate with other teams to support test-driven, continuous code integration.

c) The contractor must share test scripts (manual and automated) as needed with other testing entities.

d) The contractor must work to increase the coverage, quality, and speed of existing tests, and must hold new tests to the highest standards.

e) The contractor must assist with crafting validation steps (both positive and negative testing) for user acceptance testing on an as-needed basis.

f) The contractor must support the activities of the Configuration Management team to ensure the automatic build and deployment process works effectively across all environments, including the contractor’s dev/test enclave. Deployment and testing in the dev/test environment should mimic closely the actions performed for deployment and testing in staging and production.

g) The contractor must thoroughly test changes before committing them into the CI pipeline.

h) The contractor must use their DevOps personnel to perform deployments of some or all code directly to production, as directed by the Government. This includes writing and maintaining their deployment scripts. In some or all cases, this deployment may be done without direct involvement from the Integration and Configuration or IT Operations teams.

All code must successfully pass automated integration and testing before deployment.

i) The contractor may be required to provide configuration management/librarian support, managing packages, and version control for migration of packages through the instance management cycle. Requests for this support will be made in writing by the CO or COR and will include an estimated number of hours needed for support.

j) The contractor must support scheduled testing activities, for example financial system Month-end and Year-end. Year-end production support will be done in conjunction with the Federal closeout team.

k) The contractor must provide end user training and support for new functionality introduced into the system as required by the Government.

E. Quality Control and Production Support

a) The contractor must respond to production incidents, including but not limited to, breakages of functionality, system outages, performance problems, or user complaints.

This responsibility includes, but is not limited to, investigating and triaging incidents, rolling systems back to earlier states, developing and deploying fixes (on software they may or may not have developed), engaging with other Agile contractor teams and federal employees to fix related systems, providing knowledge transfer to other contractors and federal employees, production validation, and running incident retrospectives to ensure permanent fixes after initial deployment and during the warranty period.

b) The contractor working on the financial and procurement systems will provides help desk support to production users. This support provides accounting and technical support for financial and procurement systems. The contractor must have working knowledge of procurement and accounting cycles and provides support for these cycles following the appropriate systems’ work instructions guidance.

c) The contractor will accomplish the analysis of customer requirements utilizing applicable tools. Services will include, strong financial business analysis of existing and converted financial data, designing, recommending and implementing workflow changes to meet the business data requirements, utilization of core system capabilities to resolve problems, documentation support, and troubleshooting program logic, as well as the ability to work independently and transform functional requirements into technical specifications. The contract support services include administrative responsibilities and the requirements to administer the task and support any maintenance requirements in support of existing core system.

d) The contractors must provide the necessary support with the required skillsets including knowledge of generally accepted accounting principles, Oracle financial applications, Oracle reports and Discoverer, which includes but is not limited to General Ledger, accounts payables, accounts receivables, project accounting Fixed assets, purchase and federal financials. The system also includes e-invoicing (iSupplier), G-Invoicing, oracle reports, and Splash BI. The Delphi team averages over 3,0000 request per year.

e) The contractor must provide the necessary support with the Oracle financial applications experiences to analyze customers accounting and purchasing business requirements and incorporating those requirements into Oracle financial applications and purchasing applications utilizing knowledge of Oracle financials workflow solutions. The contractor must provide the necessary support with the required skill sets within the different teams of the program. The basic knowledge required for all teams is the knowledge of Oracle Financials and the use of on-line and/or batch processes including interfaces using SQL version 10g or higher, PL/SQL version 10g or higher, TOAD, FTP, Oracle Enterprise Manager (OEM), Service Oriented Architecture (SOA), and JAVA as well as knowledge of Agile Processes. PRISM team requires a working knowledge of programming experience using Microsoft .Net, Visual Basic, Active Server Pages (ASP), Oracle Stored Procedures (PL/SQL), and HTML or similar experience, Oracle database (11 or higher) experience including SQLnet, Triggers, Views, and Oracle SOA. Experience with Windows OS.

F. Access Control Group Contractor may be responsible for staffing the Access Control Group, ensuring the Roles and Responsibility Matrix is adhered to, and submitting approved tickets to grant access for approximately 3,000 requests per year.

The contractor must, in fulfillment of all development, generate detailed data analysis, generate workflow solutions, extensions, business process changes, and other endeavors that does not change the core product. The contractor must use the available hardware and software provided by the FAA, as tools in the development process.

The contractor must accomplish the analysis of requirements utilizing applicable tools. Services must include, business analysis of existing and converted data; designing, recommending, and implementing workflow changes to meet the business data requirements and documentation support; as well as utilizing extensions, business process changes, and other endeavors that does not change the core product as required.

The contract support services include administrative responsibilities and the requirements to administer the task supporting any conversion requirements for implementation to the core system as well as existing core system requirements for new or existing customers. Provide troubleshooting, researching, developing, training, and maintaining various functions and processes of applications as defining customer requirements and working with various Agile teams of government, other contract employees, and end user customers. Contractors must possess the knowledge, skill, experience, and sufficient authority to develop, maintain and sustain web, terminal, client, console, and database based applications.

Provide and produce documentation for applications, user training guides in accordance with ESC’s ISO 9000 or higher guidelines and policies. All development must be in accordance with defined coding standards, 508 Compliance, FISMA, NIST-SP 800-53, Executive Order (EO) 14028, “Improving the Nation’s Cybersecurity,” and related government-wide initiatives/requirements. and utilizing Information Technology Infrastructure Library (ITIL).

The contractor must provide the necessary support with the financial and procurement applications experience to analyze customers accounting and purchasing business requirements and incorporating those requirements into applications utilizing knowledge of workflow solutions in support of financial and purchasing applications. Contractor must provide working knowledge of federal financial accounting and applicable Office of Management and Budget (OMB) Circulars, including, but not limited to; OMB Circular A-123 Internal Controls; OMB Circular A-127 Policies and Standards for Financial Management Systems; OMB Circular A-134

Financial Accounting Principles and Standards and OMB Circular A-136 Financial Reporting Requirements. All accounting recommendations must follow the Generally Accepted Accounting Principles (GAAP).

The contractor provides support in conjunction with other Agile teams and end users. This can be delivered in the method of formal education, chalk talks, knowledge transfer sessions, communities of practice, or lab situations to provide outside knowledge to the operations and maintenance working team members. The contractors on this task should be up to date on additional skill sets required during the duration of this contract task order. Contractor must provide working knowledge and fully support Agile Manifesto Principles and Values as outlined in the Manifesto for Agile Software Development (agilemanifesto.org) and the principles behind the Agile Manifesto.

Technologies/Software included in this task order, or its current version, is listed in Attachment 005, but is not limited to the versions as listed. Contractors are required to know the software and keep abreast of all technology as the landscape changes. All future releases or new software will be utilized and considered within the scope of this task order.

The contractor provides knowledge transfer support in conjunction with the Agile team members.

This can be delivered in the method of formal education, chalk talks, knowledge transfer sessions, or lab situations to provide outside knowledge to the other team members.

The contractor must provide support in the area of documentation support. Responsible for attending meetings by multiple teams, documenting meeting minutes and providing documentation writing support. In addition, support is required to capture metrics and logging metrics as outline by the government.

The contractor must, in fulfillment of this task, generate system programs and/or program form changes as required by program managers and/or analyst. The contractor must utilize established standards and/or procedures as defined by the FAA in the performance of this task and as defined by established change management processes, and quarterly release schedule, if applicable. The release management strategy typically calls for 4 scheduled releases per year. Additional releases are accomplished on a ad hoc basis.

ESC utilizes an instance strategy concept throughout all migrations of development. In accordance with the Instance Management Plan, the following diagram shows the management of the multiple instances required to run in these larger systems. Tickets must be submitted to the Enterprise Data Center following the Configuration Management work process for database, application administration, and system administration requirements.

Figure 3.

4.0 Definitions/Acronyms

508 Compliance

• In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities. The law (29 U.S.C. § 794 (d)) applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Under Section 508, agencies must give disabled employees and members of the public access to information that is comparable to access available to others.

CCB: Configuration Control Board

CEMLI: Configuration, Extension, Modification, Localization and Integration

CI/CD: Continuous Integration and Continuous Delivery

CMIS: Contract Management Information System

• Provides management, tracking and reporting on the Aeronautical Center Federal Information Processing Support Services and Office Automation contracts, as well as contract employee time by task and system. Which also includes the ability for contract employees to enter their daily hours expended on specific projects for the organization, providing management with the ability to track how much time each employee spends on a specific task or system.

CMMI: Capability Maturity Model Integration

• CMMI is a process improvement training and appraisal program and service administered and marketed by Carnegie Mellon University and required by many DoD and U.S.

Government contracts, especially in software development. CMMI can be used to guide process improvement across a project, division, or an entire organization.

COR: Contracting Officer Representative

COTS: Commercial Off The Shelf

CCB: Configuration Control Board

Dev/Ops: DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure

DOT: Department of Transportation

EDC: ESC Enterprise Data Center

ESC: Enterprise Service Center

Extreme Programming (XP): Software development engineering practices that include, but are not limited to, concepts of whole team, planning gamed, small releases, customer tests, collective code ownership, code standards, sustainable pace, metaphors, continuous integration, test-driven development, refactoring simple design and pair programming.

FAA: Federal Aviation Administration

FISMA: Federal Information Security Management Act

• The Federal Information Security Management Act is United States legislation that defines a comprehensive framework to protect government information, operations and assets against natural or man-made threats.

FMLoB: Financial Management Line of Business

ISS: Information System Security

IAW: In accordance with

ISO 9000: International Organization for Standardization

ITIL: Information Technology Infrastructure Library – a set of detailed practices for IT service management

KANBAN: A method of visualizing and managing work. The system contains a series of defined states that work moves through, prograss of individual items are tacked, flow is measured, (cycle time of when items enter the system to the time they leave) and Work in Progress (WIP) limites are agreed upon by the Agile Team and changed when necessary to improve flow.

KSN: Knowledge Sharing Network

NIST-SP 800-53

• National Institute of Standards and Technology Special Publication 800-53. Security and privacy controls for Federal Information Systems and organizations.

POA&M: Plan of Action and Milestones

SAFe: Scaled Agile Framework is an Agile software development framework designed by Scaled Agile, Inc. The Scaled Agile Framework (SAFe®) is a freely-revealed knowledge base of integrated patterns for enterprise-scale Lean-Agile development

SCRUM: A lightweight project management framework that fosters quick, iterative, incremental advancement of the solution capabilities and facilitates countinous improvement (CI) in support of higher productivity, quality, and better outcomes.

SDLC: Software Development Lifecycle

Security Standards: There are many sources of (1) best practices in software development. The FAA recommends the use of the DOD Application Security and Development Security Technical Implementation Guide (STIG) guidance for implementing secure coding standards and other aspects of software. The Defense Information Security Agency (DISA) STIG is available online at:

http://iase.disa.mil/stigs/Documents/U_Application_Security_and_Develop ment_V3R10_STIG.zip http://iase.disa.mil/stigs/Documents/U_Application_Security_and_Development_V3R10_STIG.zip http://iase.disa.mil/stigs/Documents/U_Application_Security_and_Development_V3R10_STIG.zip

FAA Branding Requirements:

https://employees.faa.gov/tools_resources/web/requirements/templates_bran ding/

NIST SP 800-95 Guide to Secure Web Services (as amended)

NIST SP 800-44 version 2 Guidelines on Securing Public Web Servers (as amended)

MITRE, CWE and CERT Secure Coding Standards:

http://resources.sei.cmu.edu/library/results.cfm?as_q=inmeta:gsataxonomyo utput~Secure%20Coding

Open Web Application Security Project (OWASP) code compliance https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_Chec klist

CERT

https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+ Coding+Standards https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Sec ure+Coding+Practices

SOP: Standard Operating Procedures

SR: Service Request

SSP: Shared Service Provider

Warranty Period: Development must require a warranty period of 30 days which begins after production deployment. If the change impacts monthly, quarterly or annual processes, the contractor must provide support during the first production process, i.e., first month-end, first year end closing, etc. The warranty period must be provided by contractor for all work performed. Any non-conforming products requiring rework must not impact the current capacity of the established teams and will be the responsibility of the contractor.

5.0 Performance Outcome(s)/Deliverable(s)

ESC contractor team members must assist with a team Iteration Status Report every 2 week Sprint iteration and the evaluation must be discussed with the contractor. The purpose of the delivery evaluation and discussions is to enhance product performance and to tie team activity https://employees.faa.gov/tools_resources/web/requirements/templates_branding/ https://employees.faa.gov/tools_resources/web/requirements/templates_branding/ http://resources.sei.cmu.edu/library/results.cfm?as_q=inmeta:gsataxonomyoutput%7ESecure%20Coding http://resources.sei.cmu.edu/library/results.cfm?as_q=inmeta:gsataxonomyoutput%7ESecure%20Coding https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_Checklist https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_Checklist https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices back to the program increment planning (PIP). It is anticipated that ESC agile teams must provide their team Iteration Status Report along the following dimensions:

• Functional or technical production support must respond to customers identified on the incident ticket assignments within the timeframe outlined in the appropriate system’s operating procedures with problem resolution or an estimated problem resolution date. All production system incidents/ticket test results must be documented according to operating procedures

• Business Satisfaction. Each feature completed by the team must have a self-evaluation be evaluated by the entire team. At each iteration review, the functionality must be evaluated by a wider audience of Government employees.

• Productivity. Team velocity, story point completion, and fulfilling value-added solutions to reach iteration goals and business objectives provides a relative measure of productivity. A team’s velocity is the rate at which the team is completing user stories and delivering them to the product owner or in the case of a contractor assigned product owner, business owner. A team’s velocity is measured by the sum of story points for each story completed during a sprint. An average of 60 story points per iteration will be considered average rating. Although measures such as velocity and story point completion cannot be used directly in an Agile process to measure performance, the Government must be able to measure if business objectives are completed within a specified timebox, and note any unproductive behavior.

• Team Predictability: As outlined in the SAFe 4.0 Framework, the predictability should range between 80% and 100% for each program increment (PI). This is derived by achieving iteration program goals under business value. At the end of the program increment (PI), the team should have achieved at least 80% of their PI goals. A team may achieve more than 100% due to stretch objectives, however, continuing predictability ranges above 100% indicate a team that is not properly planning their workload.

• Process and Continuous Improvement. ESC teams must be assessed on the processes they implement, their conformance to ESC processes, their contribution to SDLC and other required frameworks, and their use of retrospectives to continuously improve these processes.

• Iteration and Program Reviews (System Demonstrations): As outlined in the SAFe 4.0 Framework and the Scrum Guide a fortnightly demonstration of the subject sysem must be conducted in order to ensure quick and timely feedback from stakeholders on the value of the product being delivered.

The following deliverables are in direct relation to the items listed above.

5.0.1 Quality – Iteration Status Report

Task 1. Configuration/Change Management Policy.

a. Deliverable(s): All contractors are to ensure configuration/change management (CM) procedures are followed in accordance with established configuration management policy. This includes requirements gathering, documentation, analysis, programming, testing, and migration of programs as documented in the Quality Assurance section of the iteration report.

1. No evidence of work being performed outside of established procedure

Task 2: Code Quality and Standards Adherence.

a. Deliverable(s): Contractor code must be evaluated by ESC teams and IV&V providers. Code must be evaluated against standards published by ESC including design standards and architecture.

Automated code review tools and review of incident responses must also be used to validate code quality and ensure code is maintained in Government code repository. Deviances are documented on the team iteration report.

a. Deliverable(s): Code meets acceptable standards when reviewed by IV&V team.

1. Code meets standards.

2. Code is maintained appropriately in Government code repository

Task 3: Engineering

a. Deliverable(s): Utilization of sound systems engineering utilizing applicable tools and engineering design following ESC design standards, ensuring all team products meet coding and Enterprise Architecture design solutions, if applicable, and documented on the team iteration report.

1. Utilization of sound systems engineering utilizing applicable tools and engineering design following ESC design standards, ensuring all team products meet coding and Enterprise Architecture design solutions, if applicable.

Task 4: Test Scripts.

a. Deliverable(s): Test Quality and Test Coverage. Because automated tests are a key component of this process, test scripts must be treated as deliverables under ESC. These test scripts must be assessed for their quality and for the extent to which they test the appropriate functions. This evaluation must be performed by the IV&V team or ESC employees and documented on the iteration status report by the team.

1. Test Scripts are submitted to the IV&V team for acceptance of successful execution before User Acceptance Testing (UAT) migration.

Task 5: Businesss Value

a. Deliverable(s): Stories and features completed by teams will be evaluated by government Product Owner(s) for the quality of business value delivered (inherent in determining satisfaction towards meeting Acceptance Criteria and the Definition of Done).

Evaluations may include feedback from ESC Product and Project Managers (PMs), Business Advisors (BAs), and Subject Matter Experts (SMEs) for qualitative measurement and documented on the iteration team self-evaluation.

1. Team provides a basic Business Satisfaction & Value by completing and providing proof of pulling/working stories for points and tying them back to business values 98% of the time.

Task 6: Development

a. Deliverable(s): All development deliverables are on time and documented in accordance with project timeline and in accordance with mutually agreed upon timeline changes. This deliverable is reportable under Business Value on the team self-evaluation.

1. Development meets delivery date 98% of the time.

2. Missed dates must be announced at the System Demonstration.

Task 7. Team Predictability:

a. The predictability should range between 80% and 100% for each program increment (PI). The team should have achieved at least 80% of their PI goals. A team may achieve more than 100% due to stretch objectives, however, continuing predictability ranges above 100% indicate a team that is not properly planning their workload.

1. Deliverable(s): Team delivers no less than 90% of their program increment business objective. Measurement is at the end of the program increment. Iteration accomplishments are reported on the Iteration Status Report.

5.0.2 Production Support Tickets Quality

a. Production Support tickets are worked within the timeframes outlined in the system’s operating instructions.

1. Deliverable(s): Production support tickets are responded to within the timeframe outlined in the systems’ operating instruction, AMKWI-240-00015 98% of the time.

2. Deliverable(s): Tickets are maintained in accordance with operating instruction AMKWI-240-00015 98% of the time.

c.: Submit, Monitor, and Oversee Vendor Service Requests (SR).

a. Custom off the shelf software (COTS) product SRs are frequently required for support assistance throughout the implementation process. Contractors submit service requests for tracking and classified are by severity. Each SR requires different levels of availability by the contractor.

Severity 1: Complete loss of service for mission critical operations where work cannot reasonably continue. – This level of service request is worked 24/7 until resolved. Contractor must be available.

Severity 2. Significant or degraded loss of service or resources.

This level of ticket must be worked in 3-4 days. While not worked 24/7, it is a priority and may be escalated to work 24/7 as necessary.

Severity 3. Minor loss of services or resources. Worked 1-2 weeks.

Severity 4. No work being impeded at this time – information is requested or reported.

1. Deliverable(s): No SRs timed-out or closed due to “customer abandoned” is allowed.

2. Deliverable(s): SR’s status must be given at System Demonstrations.

5.0.3 Delivery Review Status Reports.

a. Delivery Review reports are due to the COR 3 days after completion of delivery reporting on the specific development.

1. Deliverable(s): Reports are provided with no deviations

5.0.4 Customer satisfaction.

a. All contractors are to ensure tickets worked receive favorable response. Help desk tickets received 98% favorable response from customer on Monthly Customer Satisfaction Survey.

1. Deliverable(s): Random sampling of work must be performed to ensure compliance with policy.

5.0.5 Access Control Services

a. Access control officers submit access control tickets for new, modified, exiting users to the system

1. Deliverable(s): User access requests are accomplished within established timeframe of Normal – 3 days, Critical/High – 1 day, Emergency

– Immediately (< than 1 day)

2. Deliverable(s): Conducts quarterly security system review.

6.0 Reference Documents (if applicable)

Document No. Description Distribution

001 Configuration/Change Management Plan

Attached in Solicitation

002 Documentation Required for Development

Attached in Solicitation

003 AMK-210 Process Flow Attached in Solicitation

004 AMK-210-WI-00016 New Development & Operations Process

Attached in Solicitation

005 AMKWI-240-00026 SR:

Creating, Working, Closing Oracle Service Requests

Attached in Solicitation

006 Technology/Software Attached in Solicitation

007 AMKWI-240-00015 Working and Resolving Incidents, Work Orders, Problems, and Requests for Service

Attached in Solicitation

008 AMKJG-214-00005 PRISM:

Creating, Working and Completing Unison Incidents

Attached in Solicitation

009 Team Iteration Status Report Attached in Solicitation

7.0 TPWS Support Requirements (if applicable)

Contractor must provide on-site task lead who cross functions as the supervisor for all development functions to include:

a. Coordinating with the COR on task issues/concerns;

b. Performing work on the task;

c. Providing on-the-job training to new contract employees;

d. Managing contract employees leave, schedules, timecards, telework, etc.

e. Ensuring all contractors have work to accomplish

f. The contractor must collaborate with stakeholders, support contractors, and third party vendors throughout system integration, performance, security, Section 508, system acceptance, user acceptance, usability, and test and evaluation reporting.

g. The contractor must manage all contractor resources and supervise all contractor staff in the performance of work on this task order. The contractor must manage and coordinate its team(s) on a day-to-day basis and ensure plans are communicated to team members.

Likewise, the contractor must ensure that the health and progress against those plans are adequately reported.

h. The contractor must organize, direct and coordinate planning and execution of all task order activities.

i. Vehicles for transparency, such as ESC Knowledge Sharing Network (KSN), must be maintained with data so that reports and charts can be generated as needed, and so that user stories, defects, and tasks and their status are available to stakeholders. Task boards, Agility, and KSN sites, meetings, and demos can be used to share information and report progress.

8.0 Place of Performance

Workstations within the ESC facility located at the Mike Monroney Aeronautical Center in Oklahoma City, Oklahoma must be made available to the contractor and in the Department of Transportation (DOT) and other governmental offices in localities such as Washington, DC as required. Travel to customer’s worksites may be required. Telework is optional with approval of the COR.

9.0 Work Schedule

The contractor personnel may be required to work flexible workdays, including weekends. In this case, the normal work may exceed (40) hours. The MMAC official business hours are 8:30 am to 5:00 p.m (CST) Monday through Friday. The FAA practices Alternative Work Schedules (AWS). However, the task requirements are variable and unpredictable, and may require other than normal periods of work. The contractor must work and have access to the Government's ADP facilities during normal duty hours (0600-1800), Monday through Friday, and any other times determined by the contractor task lead, for the purpose of meeting deadlines or increased workload. Telework may be suspended by the government during certain times for meeting deadlines.

In an emergency situation or upon execution of the organization’s Continuity of Operations Plan (COOP) the COR must provide guidance on work requirements through the contracting officer or COR. In the event communication with the contracting officer is not available, the COR must provide the work requirement to the contracting officer as soon as possible

10.0 Training

Reference PWS 2.12 as well as the following training requirements: In the development, implementation, and maintenance, new application software training may be required.

Contractor support may be required to attend classes at the program site or at the software vendor’s training facility. Contractor must ensure all contract employees are trained in SAFe 4.0 (or higher) Framework.

11.0 Travel

Travel may occur for customer requirements meetings and other customer support needs at the cost of the government. Travel must be paid in accordance with the FTR after advanced approval from the contracting officer through the COR.

12.0 Privacy and Security Requirements

Contractors must meet personnel security/suitability sensitivity levels commensurate with their position sensitivity level and are subject to personnel investigation requirements (e.g., FAA Order 1600.1E & 1600.73). Contractors will be required to sign a Rules of Behavior statement pertaining to system administrator role. Content of all data the contractor works with and results are assumed to be privacy data and will be held confidential.

13.0 Government Furnished Property (if applicable)

Reference 6.3.

Programming manuals and supplies: If services are provided at Government facilities, the Government must make all necessary manuals/documents available for all software/hardware tools required for the contractor support to perform their duties in relationship to executing this task. Also, the Government must provide administrative supplies such as pens, pencils, notepads, etc. All items as identified and furnished by the Government must be returned at the completion of the task. must be applied, the frequency of surveillance, and the minimum acceptable defect rate(s).

14.0 Government Surveillance - Inspection and Acceptance Criteria The Government must evaluate the contractor’s performance on this task in accordance with the Technical Exhibits provided in Section 15.0 below.

The Exhibits are focused on what the Government must do to ensure that the contractor has performed in accordance with the performance standards. It defines how the performance standards must be applied, the frequency of surveillance, and the minimum acceptable defect rate(s).

15.0 Technical Exhibits:

Technical Exhibit 1 - Performance Requirements Summary The contractor service requirements are summarized into performance objectives that relate directly to mission essential items. The performance threshold briefly describes the minimum acceptable levels of service required for each requirement. These thresholds are critical to mission success.

Task Deliverable(s) Applicable Standard(s) Performance Schedule / Requirement (This is the maximum error rate.