PWS Software Development Support FINAL jb approved.docx

Software Development Support

VA-25-00000979

PERFORMANCE WORK STATEMENT (PWS)

DEPARTMENT OF VETERANS AFFAIRS

Financial Services Center (FSC) Financial Technology Services (FTS)

Software Development Support Date: October 3, 2024 PWS Version Number: 4.0

Contents

ADDENDUM A – ADDITIONAL VA REQUIREMENTS, CONSOLIDATED 56

ADDENDUM B – VA INFORMATION AND INFORMATION SYSTEM SECURITY/PRIVACY LANGUAGE 62

BACKGROUND

The mission of the Department of Veterans Affairs (VA), Financial Services Center (FSC) is to provide high-quality financial services, exceeding the expectations of our federal customers, inspiring their trust and empowering them to focus on their core missions. The VA FSC Financial Technology Service (FTS) mission is to provide high- quality Information Technology (IT) infrastructure, software engineering, Electronic Commerce, and system support services to the FSC in accordance with the FSC's overall mission. In meeting these goals, VA FSC strives to provide high-quality financial services, exceeding the expectations of our federal customers, inspiring trust and empowering them to focus on their core missions.

The VA FSC is a Franchise Fund site authorized pursuant to the Government Management Reform Act of 1994 (Public Law 103-356). The Act authorizes designated agencies to provide certain common administrative support services on a reimbursable basis both internally and to other Government agencies. In 2006, permanent status was conferred upon the VA Franchise Fund under the “Military Quality of Life and Veterans Affairs Appropriations Act 2006,” Public Law 109-114. Consequently, the VA FSC receives no federally appropriated funding and is required to market VA FSC services to customers. VA FSC provides IT services in support of various initiatives throughout the FSC and VA.

The objective of this acquisition is to acquire IT Software Development Services to include software engineering and development, and developer and architect expertise to perform system development life cycle (SDLC) tasks in the development and support of applications and systems. Some of the applications developed to support the VA- FSC initiatives were developed utilizing Microsoft .NET, Pega PRPC, MS SQL Server, COBOL (mainframe-based), SNYCSORT (mainframe-based), Oracle, BPEL, and Java components. VA-FSC also provides Software Development Services in support of various initiatives throughout the FSC, Other Government Agencies (OGA) and VA. Attachment B contains a sample of projects supported by FSC development teams in 2019. The listing of projects is meant to be illustrative in nature and is not meant to define the scope that will be performed for this task order (TO).

The Government’s objectives are to:

Reduce operational costs Enhance Government operations, particularly in development and support of applications Seek consistency with Development maximum extent practicable.

Allow flexibility in meeting variable demands Improve Government operations, particularly accountability and performance reporting Provide procedural checks and feedback to improve compliance and management control on processes Keep abreast of required technologies, standards and methodologies and propose to the FSC how to stay current with new versions of technologies as well as legislative mandates and other items as they relate to this TO

APPLICABLE DOCUMENTS

In the performance of the tasks associated with this Performance Work Statement, the Contractor shall comply with the following:

1. 44 U.S.C. § 3541-3549, “Federal Information Security Management Act (FISMA) of 2002”

2. “Federal Information Security Modernization Act of 2014”

3. Federal Information Processing Standards (FIPS) Publication 140-2, “Security Requirements for Cryptographic Modules”

4. FIPS Pub 199. “Standards for Security Categorization of Federal Information and Information Systems,” February 2004

5. FIPS Pub 200, “Minimum Security Requirements for Federal Information and Information Systems,” March 2006

6. FIPS Pub 201-2, “Personal Identity Verification of Federal Employees and Contractors,” August 2013

7. 10 U.S.C. § 2224, "Defense Information Assurance Program"

8. 5 U.S.C. § 552a, as amended, “The Privacy Act of 1974”

9. Public Law 109-461, Veterans Benefits, Health Care, and Information Technology Act of 2006, Title IX, Information Security Matters

10. 42 U.S.C. § 2000d “Title VI of the Civil Rights Act of 1964”

11. VA Directive 0710, “Personnel Security and Suitability Program,” June 4, 2010, https://www.va.gov/vapubs/index.cfm

12. VA Handbook 0710, “Personnel Security and Suitability Program,” May 2, 2016, https://www.va.gov/vapubs/index.cfm

13. VA Directive and Handbook 6102, “Internet/Intranet Services,” August 5, 2019

14. 36 C.F.R. Part 1194 “Information and Communication Technology Standards and Guidelines,” January 18, 2017

15. Office of Management and Budget (OMB) Circular A-130, “Managing Federal Information as a Strategic Resource,” July 28, 2016

16. 32 C.F.R. Part 199, “Civilian Health and Medical Program of the Uniformed Services (CHAMPUS)”

17. NIST SP 800-66 Rev. 1, “An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule,” October 2008

18. Sections 504 and 508 of the Rehabilitation Act (29 U.S.C. § 794d), as amended, January 18, 2017

19. Homeland Security Presidential Directive (12) (HSPD-12), August 27, 2004

20. VA Directive 6500, “VA Cybersecurity Program,” February 24, 2021

21. VA Handbook 6500, “Risk Management Framework for VA Information Systems VA Information Security Program,” February 24, 2021

22. VA Handbook 6500.2, “Management of Breaches Involving Sensitive Personal Information (SPI),” March 12, 2019

23. VA Handbook 6500.5, “Incorporating Security and Privacy into the System Development Lifecycle,” March 22, 2010

24. VA Handbook 6500.6, “Contract Security,” March 12, 2010

25. VA Handbook 6500.8, “Information System Contingency Planning,” April 6, 2011

26. VA Handbook 6500.10, “Mobile Device Security Policy,” February 15, 2018

27. VA Handbook 6500.11, “VA Firewall Configuration,” August 22, 2017

28. OIT Process Asset Library (PAL), https://www.va.gov/process/ . Reference Process Maps at https://www.va.gov/process/maps.asp and Artifact templates at https://www.va.gov/process/artifacts.asp

29. One-VA Technical Reference Model (TRM) (reference at https://www.va.gov/trm/TRMHomePage.aspx)

30. VA Directive 6508, “Implementation of Privacy Threshold Analysis and Privacy Impact Assessment,” October 15, 2014

31. VA Handbook 6508.1, “Procedures for Privacy Threshold Analysis and Privacy Impact Assessment,” July 30, 2015

32. VA Handbook 6510, “VA Identity and Access Management,” January 15, 2016

33. VA Directive and Handbook 6513, “Secure External Connections,” October 12, 2017

34. VA Directive 6300, “Records and Information Management,” September 21, 2018

35. VA Handbook, 6300.1, “Records Management Procedures,“ March 24, 2010

36. NIST SP 800-37 Rev 2, “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy,” December 2018

37. NIST SP 800-53 Rev. 5, “Security and Privacy Controls for Federal Information Systems and Organizations,” September 23, 2020 (includes updates as of 12/10/2020)

38. VA Directive 0735, “Homeland Security Presidential Directive 12 (HSPD-12) Program,” October 26, 2015

39. VA Handbook 0735, “Homeland Security Presidential Directive 12 (HSPD-12) Program,” March 24, 2014

40. OMB Memorandum 05-24, “Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors,” August 5, 2005

41. OMB Memorandum M-19-17, “Enabling Mission Delivery Through Improved Identity, Credential, and Access Management,” May 21, 2019

42. OMB Memorandum, “Guidance for Homeland Security Presidential Directive (HSPD) 12 Implementation,” May 23, 2008

43. Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, December 2, 2011, (NOTE: Part A of the FICAM Roadmap and Implementation Guidance, v2.0, was replaced in 2015 with an updated Architecture (https://arch.idmanagement.gov/#what-is-the-ficam-architecture)

44. NIST SP 800-116 Rev 1, “Guidelines for the Use of Personal Identity Verification (PIV) Credentials in Facility Access,“ June 2018

45. NIST SP 800-63-3, 800-63A, 800-63B, 800-63C, “Digital Identity Guidelines,” updated March 02, 2020

46. NIST SP 800-157, “Guidelines for Derived PIV Credentials,” December 2014

47. NIST SP 800-164, “Guidelines on Hardware-Rooted Security in Mobile Devices (Draft),” October 2012

48. Draft National Institute of Standards and Technology Interagency Report (NISTIR) 7981, “Mobile, PIV, and Authentication,” March 2014

49. VA Memorandum, VAIQ #7100147, “Continued Implementation of Homeland Security Presidential Directive 12 (HSPD-12),” April 29, 2011 (reference https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)

50. IAM Identity Management Business Requirements Guidance document, May 2013, (reference Enterprise Architecture Section, PIV/IAM (reference https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)

51. VA Memorandum “Personal Identity Verification (PIV) Logical Access Policy Clarification,” July 17, 2019, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4896

52. Trusted Internet Connections (TIC) 3.0 Core Guidance Documents, https://www.cisa.gov/publication/tic-30-core-guidance-documents

53. OMB Memorandum M-19-26, “Update to the Trusted Internet Connections (TIC) Initiative,” September 12, 2019

54. OMB Memorandum M-08-23, “Securing the Federal Government’s Domain Name System Infrastructure,” August 22, 2008

55. Sections 524 and 525 of the Energy Independence and Security Act of 2007, (Public Law 110–140), December 19, 2007

56. Section 104 of the Energy Policy Act of 2005, (Public Law 109–58), August 8, 2005

57. Executive Order 13834, “Efficient Federal Operations,” dated May 17, 2018

58. Executive Order 13221, “Energy-Efficient Standby Power Devices,” August 2, 2001

59. VA Directive 0058, “VA Green Purchasing Program,” July 19, 2013

60. VA Handbook 0058, “VA Green Purchasing Program,” July 19, 2013

61. Office of Information Security (OIS) VAIQ #7424808 Memorandum, “Remote Access,” January 15, 2014, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28

62. Clinger-Cohen Act of 1996, 40 U.S.C. §11101 and §11103

63. “Veteran Focused Integration Process (VIP) Guide 4.0,” January 2021, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4371

64. VA Memorandum “Proper Use of Email and Other Messaging Services,” January 2, 2018, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28

65. “DevSecOps Product Line Management Playbook” version 2.0, May 2021, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4946

66. NIST SP 500-267B Revision 1, “USGv6 Profile,” November 2020

67. OMB Memorandum M-21-07, “Completing the Transition to Internet Protocol Version 6 (IPv6),” November 19, 2020

68. Social Security Number (SSN) Fraud Prevention Act of 2017 Section 240 of the Consolidated Appropriations Act (CAA) 2018, March 23, 2018

SCOPE OF WORK

The Contractor shall provide project management, research and assessment, development guidelines, technical services, software development and deployment support to the FSC including software engineering, software development, and system solution architect expertise to perform system development life cycle (SDLC) tasks in the development of applications and systems. The Contractor shall provide tier 3 system sustainment support, production and analytical support for all FSC solutions. The Contractor shall provide Center of Excellence support as well as optional mentoring and training. The Contractor shall follow a scaled Agile Methodology such as SAFe and the VIP software development lifecycle established by VA’s Office of Information and Technology (OI&T) Enterprise Program Management Office (EPMO). Change made by VA OIT to VIP and VA implementation of agile development shall be adopted by the contractor. The Contractor shall provide system and application sustainment support for the FSC’s portfolio and features.

The Contractor shall execute the work described above, provide the necessary processes, manage its staff, and develop processes and procedures to improve the FSC’s maturity in the development and maintenance of software systems.

ORDER TYPE

The effort shall be proposed on a Firm Fixed Price (FFP) basis.

PERFORMANCE DETAILS

PERFORMANCE PERIOD

The Period of Performance (PoP) shall be a 12-month base period with four (4) 12-month option periods, if exercised. Additional support may be included via two (2) optional tasks.

Any work at the Government site shall not take place on Federal holidays or weekends unless directed by the Contracting Officer (CO).

There are eleven (11) Federal holidays set by law (USC Title 5 Section 6103) that VA follows:

Under current definitions, four are set by date:

If any of the above falls on a Saturday, then Friday shall be observed as a holiday. Similarly, if one falls on a Sunday, then Monday shall be observed as a holiday.

The other six are set by a day of the week and month:

PLACE OF PERFORMANCE

Tasks under this PWS shall be performed in VA facilities located in the main FSC offices at 8000 Metropolis Drive, Bldg B., Austin, TX 78744 AITC 1615 Woodward Street, Austin Texas 78741, and other local satellite offices within Austin, Texas. Work may be performed at remote locations with prior concurrence from the Contracting Officer’s Representative (COR).

Contractor employees may work off site on a case-by-case basis, with the approval of the COR and/or CO. A Contractor employee may be required by the Government to attend face to face meetings at the main FSC office at no cost to the Government for travel. There shall be no additional cost to the Government for remote workers in terms of travel or labor rates. The Contractor shall identify the Contractor’s place of performance in their proposal submission.

TRAVEL

The Government anticipates travel under this effort to perform the tasks associated with the effort, as well as to attend program-related meetings or conferences throughout the PoP. Travel expenses will be on a Firm-Fixed-Price basis.

The Contractor shall provide a Trip Report which shall include the following:

· Meeting purpose and scope

· FSC attendees

· Meeting topics

· Detailed notes on topics that are of importance to FSC

· Action items

The Trip Report shall be submitted within 3 calendar days of completion of travel.

The estimated number of trips in support of program related meetings for this effort are up to ten (10) events per year. Examples of travel include but are not limited to the following:

One (1) representative to attend three (3) X12 Standing meeting per year (See http://x12.org/x12org/meetings/x12trimt/asc-x12-standing-meetings.cfm) Two (2) representatives to attend one PEGAWorld event per year (see https://www.pega.com/events/pegaworld) One (1) representative to attend a 3-day meeting with regarding EHRM effort

Deliverable:

A. Trip Report

SPECIFIC TASKS AND DELIVERABLES

The Contractor shall perform the following:

PROGRAM MANAGEMENT

STAFFING PLAN

The Contractor is required to provide a sufficient quantity of skilled staff sufficient to perform all of the tasks described within this PWS. The Contractor shall provide a Staffing Plan within 10 calendar days after TO award. The Contractor shall provide a mixture of developer skill levels including but not limited to Junior, Senior and Expert Developers, and Software/System architects. The Staffing Plan will reflect SAFe Agile methodology and industry best practice. The Government shall provide the Contractor information on future changes for development services as soon as practical and confirm as part of the quarterly reviews (see 5.1.6) so that the Contractor may proactively plan adjustments to the Staffing Plan.

The Key Technologies critical to the success of Software Development at the FSC include, but are not limited to, PEGA, Electronic Data Interchange (EDI), Java, and .NET. The Contractor shall identify as key personnel within the staffing plan the lead software / system architects by name to support PEGA, EDI, .NET and Java who will provide expert support to developers across scrum teams within their assigned technologies. Support will include but not be limited to:

a. Establishing and recommending best practices

b. Executing code peer reviews

c. Resolving complex technical issues including defects

d. Aligning solutions with enterprise design patterns

e. Validating security controls have been integrated

f. Implementing and improving upon existing DevSecOps process

g. Verifying that all system documentation is complete and accurate

Normally, scrum teams will include two (2) full time developers but can be up to four (4) developers or one (1) full time developer and a backup resource.

The Staffing Plan will assume FSC office hours are 6AM to 6PM central time Monday to Friday. The Staffing Plan shall include means for working outside normal business hours.

The Staffing Plan shall include administrative staff, management staff, and other resources, such as specialist and subject matter experts, necessary to meet the requirements of the PWS. Any change to staff levels or availability which could impact sprint velocity shall be reported to the government as soon as practical but a minimum of two (2) business days in advance of any realignment.

Deliverable:

A. Staffing Plan

PROGRAM MANAGEMENT

The Contractor shall identify an onsite Program Manager (PM) by name, who shall provide management, direction, administration, quality assurance, and leadership of the execution of this PWS. The PM shall ensure all Contractor personnel are appropriately qualified to perform on this TO. The Contractor’s PM shall provide day-to-day program management guidance and direction to Contractor personnel in the execution of tasks defined in this PWS.

The Contractor shall use VA approved project management and software development methodologies and toolsets, such as VIP that assure that all contract-driven activities are identified, documented, and tracked so that the contract shall continuously be evaluated and monitored for timely and quality service. The Contractor shall notify the FSC COR of any technical, financial, personnel, or general managerial problems encountered throughout the PoP. The Contractor shall migrate to new or revised development methodologies and toolsets as they are approved by the Government.

The Contractor shall input their actual work hours by activity into the VA-FSC’s Activity Based Costing (ABC) Labor Tracking each Government Pay Period or other similar tracking tool designated by FSC. Users have up to the Tuesday following the end of the Pay Period to enter their time in the Portal. Pay Periods close automatically midnight on Wednesdays.

CONTRACTOR PROJECT MANAGEMENT PLAN

The Contractor shall deliver a Contractor Project Management Plan (CPMP) that lays out the Contractor’s approach, timeline, and tools to be used in execution of this TO effort. The CPMP should take the form of both a narrative and graphic format that displays the schedule, milestones, risks, and resource support. The CPMP shall also include how the Contractor shall coordinate and execute planned, routine, and ad hoc data collection reporting requests as identified within the PWS. The initial baseline CPMP shall be concurred upon and updated in accordance with Section B of the TO. The Contractor shall update and maintain the VA Program Manager (PM) approved CPMP throughout the PoP

The Contractor shall deliver a draft CPMP at the kickoff meeting. A final CPMP is due 10 calendar days after the kickoff meeting. Quarterly updates shall be reviewed at the Quarterly Performance Management Review (QPMR) meeting. At a minimum, the CPMP shall include the following:

a. Organizational Chart

b. Roles and Responsibilities document

c. Transition Plan (IN) and timeline

d. Staffing Plan and timeline

Deliverable:

A. Contractor Project Management Plan

INDIVIDUAL PROJECT REPORTING REQUIREMENTS

The Contractor shall continuously monitor project-level activities and shall provide, upon request, input to the FSC PM and/or COR on the following topics:

a. Risk management

b. Requirements definition and management

c. Configuration management

d. Test management

e. Quality control

f. Technical compliance

In addition, the Contractor shall perform the following reporting activities:

a. Provide accurate estimate of duration and/or effort for tasks assigned to contractor’s staff within a given timeframe, normally by end of a specified sprint. Estimate to be recorded in Agility or other government approved product management tool.

b. Weekly report providing status on in-progress work during scrum sessions or other team meetings.

c. Ensure that development tasks have been assigned to qualified staff. Task assignments will be recorded in Agility or other government approved product management tool.

d. Document commitments from development team to complete specified tasks within a given timeframe, normally by end of a specified sprint.

e. Weekly report that shows product team performance relating to level-of-effort, schedule, and release cadence.

The Weekly Status Report is due the first business day of the week by noon central time. Deliveries of this report shall begin within 14 calendar days of contract award.

The Weekly Product Team Performance Report is due the first business day of the week by noon central time. Deliveries of this report shall begin within 14 calendar days of contract award.

Deliverables:

A. Weekly Status Report B. Weekly Product Team Performance Report

TECHNICAL KICKOFF MEETING

A technical kickoff meeting shall be held within 10 calendar days after TO award. The Contractor shall coordinate the date, time, and location (can be virtual) with the Contracting Officer (CO), as the Post-Award Conference Chairperson, the VA PM, as the Co-Chairperson, the Contract Specialist (CS), and the COR. The Contractor shall provide a draft agenda to the CO and VA PM at least 5 calendar days prior to the meeting. Upon Government approval of a final agenda, the Contractor shall distribute to all meeting attendees. During the kickoff-meeting, the Contractor shall present, for review and approval by the Government, the details of the intended approach, work plan, and project schedule for each effort via a Microsoft Office PowerPoint presentation. At the conclusion of the meeting, the Contractor shall update the presentation with a final slide entitled “Summary Report” which shall include notes on any major issues, agreements, or disagreements discussed during the kickoff meeting and the following statement: “As the Post-Award Conference Chairperson, I have reviewed the entirety of this presentation and assert that it is an accurate representation and summary of the discussions held during the Technical Kickoff Meeting for the FSC Software Development Services Task Order.” The Contractor shall submit the final updated kickoff meeting presentation to the CO for review and signature within 3 calendar days after the meeting. The Contractor shall prepare and distribute the meeting minutes of the kickoff meeting to the CO, COR and all attendees within 3 calendar days after the meeting.

Deliverable:

A. Technical Kickoff Meeting Agenda B. Final Technical Kickoff Meeting Presentation C. Final Technical Kickoff Meeting Minutes

WEEKLY/MONTHLY MEETINGS AND QUARTERLY PERFORMANCE REVIEW

The Contractor shall participate in routine and ad hoc status meetings and VA Quality Reviews (i.e., Functional Reviews). The VA Quality Reviews meeting schedule will be defined upon delivery of the project schedule from the CPMP.

The Contractor shall provide a Weekly Progress Report (WPR) which covers all work completed during the reporting period and work planned for the subsequent reporting period. The WPR shall cover schedule, action items, risks, and issues for three areas of work: projects, production support, and division action items. The WPR can be a single report or broken up into multiple reports. The exact format of the report shall be suggested by the Contractor and approved by the Government. The Contractor may deploy a dashboard as an alternative to a static report. The WPR will be delivered on the first business day of the week by noon central time. Deliveries of the WPR should begin within 14 calendar days of contract award.

Developer staff shall enter data as required into Agility or other government approved product management tool. Contractors shall support the creation of a weekly status report in consultation with other stakeholders.

Production Support: At a minimum, the WPR shall contain the following data elements for production support:

a. Number of open production support tickets assigned to development staff including work that was uncovered during the warranty phase of the project.

b. Resolution time/metrics.

c. Total hours spent on all production support tasks by program.

The Contractor shall keep in communication with VA accordingly so that issues that arise are transparent to both parties to prevent escalation of outstanding issues.

The Contractor shall also coordinate with VA FSC team management or coordinators and other key Government personnel for additional progress reviews to relay software development progress and address any issues or concerns as needed.

The Contractor shall convene a monthly Program Development Activity and In-Progress Review (IPR) Meeting with the COR, and other key Government stakeholders. The purpose of this meeting is to ensure all stakeholders are informed, monthly, of the analysis and documentation efforts underway to ensure that management oversight, policy, procedures, contract management, budgets and other development activities are properly coordinated, and remain on budget. The meetings will provide the opportunity for Government and Contractor personnel to discuss SOPs, interpretation of VA regulatory guidance, and other mission-critical activities. The meeting will provide opportunities to identify other activities, establish priorities, and coordinate resolution of identified problems or opportunities. The IPR will be held the first full calendar week of the month and the Program Development Activity report is due 5 calendar days before the IPR meeting. At a minimum, the Contractor shall report on the following division items as part of the monthly Program Development Activity report:

a. Number of staff onboarded by skill set, experience level, and role

b. Number of unfilled positions that are being recruited

c. Total number of project hours consumed by each program by fiscal year to date, and calendar year to date

d. Status on action items

e. Staff members’ current scrum teams' assignment(s). If staff member is assigned to multiple scrum teams, then report is to indicate which assignment is considered the most important.

The contractor shall perform Quarterly Performance Management Reviews (QPMRs) within 5 business days of the end of the quarter. The contractor shall provide a Quarterly Status Report 7 business days prior to each QPMR. The Quarterly Status Report shall address the status of projects progress, schedule, risks, any issues encountered, and shall address any updates made to the CPMP. The Contractor shall conduct QPMRs to discuss and provide in-depth information on the subjects addressed in the Quarterly Status Report. The Contractor shall update the Quarterly Status Report to capture the meeting minutes of each QPMR. The meeting minutes should, at minimum, reflect members in attendance at the QPMR and capture issues discussed, decisions made, and action items assigned. The updated Quarterly Status Report is due 5 business days following the QPMR.

The Contractor shall attend meetings such as change control, scrums, scrum of scrums, and project status meetings to monitor, track, and provide status updates on the project schedule.

Weekly, monthly, and quarterly reports shall be submitted in electronic form in Microsoft Word or other approved formats.

Deliverables:

A. Weekly Progress Report B. Monthly Program Development Activity Report C. Quarterly Status Report

TECHNICAL DEBT BACKLOG

The Contractor shall participate in identifying non-functional requirements related to compliance (Section 508, security, technical standards), technical roadmap, enterprise services, technical refresh, and any known technical gaps for existing products collectively known as technical debt.

The Contractor shall execute requirements reviews with IT and Business stakeholders to capture, review, clarify, and prioritize non-functional epics and user stories regarding technical debt. The Contractor shall create enterprise level epics and user stories which are then applied to multiple products within FSC.

The Contractor shall coordinate with the FSC Project Manager, the Product Owner, and the FSC Configuration Management representative to incorporate Technical Debt Backlog requirements into the appropriate product backlogs, build plans, and sprint plans. These technical debt items may be worked as part of larger projects, or the Government may assign them to projects limited to technical debt items.

Every six (6) months, the Contractor shall conduct a technical review to determine if new non- functional requirements have been created that must be included in the technical debt backlog. Sources of new non-functional items include, but are not limited to, the following:

a. Directives from VA OIT

b. Revisions to the VA Technical Reference Model (TRM)

c. Regulatory changes which impact VA system

The Contractor shall support the following changes as needed to support FSC’s Authority to Operate (ATO) review cycle:

a. Perform static code review and remediate critical, high, and medium findings. Low findings are to be placed in product backlog

b. Perform information assurance review and remediate critical, high, and medium findings. Low findings are to be placed in product backlog

c. Update system documents included in the Authority to Operation (ATO)

d. Update code to most recent version or framework

e. Validate code trunk matches production

f. Validate that all databases are under source control

g. Review and update system documents including Software Design Document (SWDD) and data dictionary

h. Review and update production support documents including the Product Operations Manual (POM)

PROJECT MANAGEMENT

The Contractor shall provide the following Project Management services:

a. Provide a single POC for schedule packages, schedule status updates, resource assignments, problems, issues, and escalations.

b. Coordinate all Contractor development activities.

c. Develop and provide research, decision, and recommendation papers regarding current and future Division operations.

d. Provide short and long-term planning guidance and support in support of Contractor staff and coordinate with FSC project stakeholders.

e. Provide support to FTS supervisors and Division Chiefs on all areas of Division operations, SDLC, research, and special projects.

f. Provide briefings and management reports on as needed basis (i.e., weekly, monthly, and quarterly).

g. Ensure coordination of efforts with other sections within the FSC especially the PMO, FTS Operations and Maintenance Division and FSC Enterprise Architecture.

h. Ensure that all development tasks are completed on time and that accurate and timely status is given to the FSC PM.

i. Coordinate development activities such as meetings, document reviews, creating schedule packages, and ensure adequate planning and closeout activities are accomplished.

j. Ensure the development team is communicating and coordinating effectively with other project stakeholders.

The Contractor shall remain flexible to organize development resources differently as needed to support the development projects under this effort.

CHANGE AND CONFIGURATION MANAGEMENT

The Contractor shall ensure staff follow and improve upon the existing DevSecOps process for change and configuration management. The Contractor shall support FSC Configuration Management and Change Management activities within a Cloud and on-premises environment. The Contractor shall:

a. Conduct quality reviews of all documentation before submitting them to the Government.

b. Maintain current versions of all source code. Source code shall be checked in daily into the FSC source code repository. Maintain source code in designated escrow.

c. Improve the existing DevSecOps solution which enables the continuous integration and deployment of code.

d. Follow VA FSC change and configuration management procedures during each phase of the SDLC.

e. Adhere to VA FSC software development and documentation standards.

f. Provide documentation to ensure future developers and administrators can easily understand the code logic, application usage, and implementation.

g. Provide input on the Configuration Management plan for software configuration processes and procedures related to development, integration, testing and fielding systems.

h. Provide input on appropriate standards of documentation and management control for promotion of software releases from one environment to another.

i. Update the Technical Documentation Package as required to reflect change and configuration management activities.

CENTER OF EXCELLENCE (COE) SUPPORT

The Contractor shall support six (6) SAFe Agile, .NET, Electronic Data Interchange (EDI), Enterprise, DevSecOps, and Pega centers of excellence to provide technical oversight related to the Development and Electronic Commerce Division’s key technology platforms.

The Contractor shall:

a. Provide expert support to the Government on the key technologies including industry best practices and technology trends.

b. Set technology standards for design, coding, and testing for the Key Technologies. The Contractor shall also track and enforce compliance with the technology standards.

c. Be the technical expert to support FTS leadership in communication with vendors and external partners on topics of development platforms.

d. Develop, document, maintain, and enforce .NET, BPEL and Pega Development standards, as well as other standards required for VA use across all FSC products, programs, and projects.

e. Support Enterprise Architecture roadmap by providing technical refresh recommendations.

f. Track new versions of the development platforms and recommend an upgrade schedule to the Government.

g. Identify development training needs related to the development platforms.

h. Maintain Pega and other industry certifications

i. Be the technical liaison to the appropriate vendor. For instance, the Pega Center of Excellence shall be the technical liaison between the Government and Pega Inc.

j. Coordinate and collaborate with other designated personnel assigned to the COE.

k. Provide hands on keyboard support when necessary to resolve complex issues and/or short-term surge capacity.

CONTRACTOR PERSONNEL REQUIREMENTS

The Contractor shall provide program and project manager points of contact who shall be responsible for the performance of the work and work team. The name of these people and an alternate who shall act for the Contractor when the manager is absent shall be designated in writing to the COR. The Contractor’s program and project manager or alternate shall have full authority to act for the Contractor on all contract matters relating to daily operation of this task order.

The Contractor shall provide continuous and uninterrupted support throughout the period of performance. The Contractor shall be responsible for managing its personnel to ensure there are no disruptions in the level or quality of services even if its personnel are unavailable for any reason including vacations, illnesses or terminations.

RESEARCH AND ASSESSMENT, SYSTEM CONFIGURATION AND DEVELOPMENT AND TECHNICAL SUPPORT (T&M)

FSC receives development projects for financial and healthcare systems from VA and other Government agencies throughout the year. The scope and technical requirements of each development effort are unknown in advance. Therefore, FSC needs an agile workforce capable of supporting developing efforts using FSC’s current key technologies and adopting new technology as the IT industry evolves. For each development effort, the Contractor shall follow the VIP Agile development approach outlined below.

RESEARCH AND ASSESSMENT SUPPORT

The Contractor shall provide research and support for the Government’s assessments of future industry system architecture, software development direction, emerging trends, best practices, automated tools, innovative approaches, and contribute, when appropriate, on development issues and technology assessments. The Contractor shall use information obtained from this research to assist FSC leadership in defining and shaping roles, responsibilities, vision, goals, and objectives for development, systems and application sustainment or maintenance, and analysis. The Contractor shall also provide research results with respect to SDLC tools and best practices from private industry. The Contractor shall be prepared to present research findings and recommendations during monthly IPRs, or in written form to include point papers or articles for publication.

DEVELOPMENT GUIDELINES AND TECHNICAL SERVICES

As a Federal Acquisitions Academy Program/Project Management organization, the FSC FTS follows the VIP software development methodology with which the Contractor must adhere.

Under the VIP software development methodology, the acceptable project management methodologies fall under DevSecOps, Agile, Test-Driven Development (TDD) and Agile SCRUM. The Government will inform the Contractor of any changes to the software development methodology.

VIP Guide describes a schedule of incremental deliveries of useable capabilities every three (3) months or less.

The foundational structure for VA Agile development and project management can be found in the VIP Guide. For delivery of all project artifacts, the Contractor shall utilize Agility or a similar VA approved tool for managing project execution details and for the management and storage of artifacts using approved VIP and/or EPMO website templates.

The Contractor shall support Information Technology Infrastructure Library (ITIL) Tier 3 production control processes (particularly incident management and problem management) required to identify problems and provide prompt resolution as needed.

Although primarily focused on the development phase of the SDLC, the Contractor shall be a stakeholder in all phases and play a key role in the planning phase of the project. The Contractor shall elaborate and manage non-functional requirements and complete design activities. The Contractor shall provide SDLC expertise, process and tool recommendations related to the scope of the PWS. Additionally, the Contractor shall coordinate with other SDLC stakeholders, such as the PMO, on process improvements.

The Contractor shall contribute to the tailoring of SDLC processes and tools for the FSC. These tailored SDLC processes will describe the management for all processes, practices, and methods under which the VA FSC systems are designed, developed, tested, integrated, documented, and maintained. Any updates to the FSC SDLC and SDLC processes shall be reviewed by all impacted stakeholders and approved by the Government. The FSC SDLC updates and SDLC processes are owned by the Government. The Contractor shall propose process improvements based on lessons learned to the process improvement team or other group designated by the Government. FSC SDLC updates and SDLC processes include, but are not limited to, the following:

a. Tailoring VA SDLC to improve efficiency of delivery in accordance with VA’s VIP methodology.

b. Improving existing processes, procedures, and methods in support of the SDLC within the Contractor’s scope of activities such as technical design or code reviews.

c. Assuring all resources are trained on and use the SDLC and supporting processes, procedures, tools, templates, and methods.

d. Incorporating new tools to facilitate the use of the SDLC, such as specific document templates and automated tools.

e. Enhancing existing software development best practices, such as source code management, enterprise data management, build and deployment, adoption of new software development approaches and maintaining currency with advances specifically in the Healthcare and Financial sectors.

The current VIP SDLC is the starting point for any SDLC updates and is the foundation for the FSC SDLC processes. The FSC SDLC is continually reviewed and updated. See attachment A for summary of the VIP SDLC.

SOFTWARE DEVELOPMENT AND DEPLOYMENT

The Contractor shall provide software development and deployment support to (a) develop, test, and deploy FSC applications and (b) customize existing applications following the approved SDLC and required tasks below:

AGILE REQUIREMENTS ELABORATION AND DESIGN

The Contractor shall review and elaborate on the derived technical requirements of the solution. The Contractor shall propose non-functional requirements from the technical debt backlog for inclusion in builds with an emphasis on those items where the Government would realize savings by integrating functional and non-functional requirements into a single build. The Contractor shall provide recommendations to the FSC PM on prioritization of non-functional requirements. The Contractor shall inform the PM of any nonfunctional requirement that must be completed prior to the next production release of the solution such as resolving security findings.

The Contractor shall:

a. Participate in elaboration sessions with the FSC PMO, external partners, and customer representatives to finalize functional requirements.

b. Ensure that the information collected (epics, user stories, acceptance criteria and data exchange requirements) is sufficient to deliver the necessary system or application functionality. This includes the ability to translate requirements into terms that can be implemented in system designs.

c. Complete systems analysis for all components of systems or applications, working in close coordination with other project team members to assure effective and efficient systems component integration and address system dependencies.

d. Elaborate and maintain compliance (Section 508, security, technical standards) requirements in the form of Epics and User Stories to ensure that all Contractor-produced or supported applications are fully functional and operate correctly as intended on systems using the VA Federal Desktop Core Configuration, VA 508 guidelines, VA NIST 6500, and the common security configuration guidelines provided by NIST, VA and any other Federal Agency as required by VA or Federal Regulations.

e. Coordinate with project teams to integrate non-functional requirements into the product backlog and establish build and sprint plans that incorporate both functional and non- functional features.

f. Establish initial Unit of measurement (e.g., Story Points) as the estimated relative complexity of user stories.

g. Identify the development and test environment access that is needed for developers no later than five (5) days after the completion of the design. Access requests for new environments will be submitted within five (5) days of identification and at least three (3) days prior to development start.

All technical epics, features, visualizations, user stories, and other sources of requirements information for non-functional requirements shall be input and maintained in Agility or a similar solution specified by the Government. All requirements data is under change control and shall be fully linked to work items that show traceability to design changes, configurable items, test cases and test results.

DESIGN

The Contractor shall apply Solution Architect expertise to develop the appropriate architectures for each project. The Contractor shall abide by standards established by the Enterprise Architecture group. Architecture is started during the planning phases and refined during the project builds. The Contractor shall deliver incremental deliveries of the architecture documentation during the project builds and deliver the final documentation by the end of the project.

The Contractor shall:

a. Elicit business requirements and translate those requirements into technical solutions that may include one or more of the following: Commercial off the Shelf (COTS), Service Oriented Architecture (SOA) components, custom-developed software, EDI, and interfaces.

b. Utilize SOA and microservice principles such as standardized service contracts, service loose coupling, service abstraction, service reusability, service autonomy, service statelessness, service discoverability, service composability, and service scalability.

c. Coordinate system and application designs with the rest of the project stakeholders.

d. Provide software architecture documents to establish a blueprint for the design, including specifications for hardware, software, people, interfaces, integrations, and data resources.

e. Trace Architecture components to functional requirements.

f. Support the VA enterprise management framework. In association with the framework, the Contractor shall comply with OI&T Technical Reference Model (One-VA TRM). One- VA TRM is one component within the overall Enterprise Architecture (EA) that establishes a common vocabulary and structure for describing the information technology used to develop, operate, and maintain enterprise applications. One-VA TRM includes the Standards Profile and Product List that collectively serves as a VA technology roadmap.

g. Validate that the implementation matches the system architecture blueprint during testing.

h. Provide expertise to the rest of the project stakeholders on the solution design and implementation.

i. Utilize Enterprise Standards from the FSC’s Enterprise Architecture (EA) team and provide input into EA standards.

j. Coordinate system and application designs with the FSC EA group and external entities such as other VA organizations (e.g., OI&T Enterprise Operations (EO)).

k. Contribute to the Interface Control Document (ICD) to describe the interface specification for all external interfaces.

l. Create initial Software Design Document (SWDD) to capture detailed solution design prior to increment planning. Maintain and revise the SWDD during the development cycle as additional information regarding actual implementation becomes known.

m. Participate in a Preliminary Design Review (PDR) with enterprise architecture team and the project team prior to Critical Decision #1 and a Final Design Review (FDR) prior to Critical Decision #2. The PDR is a meeting to review and get Government approval for the initial solution design. The FDR is a meeting to review any changes to the solution design that were made during development. These design reviews ensure the documentation is current, under configuration management, communicated to the project team, and approved by the Government.

n. Design BI solutions currently using the Agile project management methodology. Analytics BI solutions and products include but are not limited to advanced visual analytics dashboards, paginated reports, customized analytics applications and/or power apps, etc. to provide modernized reporting capabilities.

o. Provide design and architecture support for the development of data base management, data management systems.

p. Design IT software solutions that solve the problems related to adequate use of data to ensure optimal business outcomes.