Draft PWS IDEAS - 7 Nov 2024 FINAL.pdf

CUI

Controlled By: DISA Controlled By: SD / SD22 CUI Category: PROCURE Distribution/Dissemination Control: FEDCON

POC:

Page 1 of 39 Pages

PERFORMANCE WORK STATEMENT (PWS)

Award/Mod Effective Version Date 7 Nov 2024

Contract Number: To Be Determined (TBD) Task Order Number: TBD Contractor Name TBD Tracking Number: TBD Follow-on to Previous Contract and Task Order Number:

HC104720C0004

1. Contracting Officer’s Representative (COR).

a. Primary COR. See DITCO Additional Text G1 - Points of Contact

b. Alternate COR. See DITCO Additional Text G1 - Points of Contact

c. Property Administrator See DITCO Additional Text G1 - Points of Contact

2. Contract or Task Order Title. Integrated Defense Enterprise Acquisition System (IDEAS) – Tier 2 / Tier 3 Support

3. Background. The Defense Information Systems Agency (DISA), a Combat Support Agency, engineers and provides command and control capabilities and enterprise infrastructure to continuously operate and assure a global net-centric enterprise. DISA directly supports joint warfighters, national level leaders, and other mission and coalition partners across the full spectrum of operations. DISA’s Procurement Services Directorate (PSD) purchases telecommunications and information technology (IT) products and services for the military, other Defense Agencies, and Federal Organizations.

In order to fulfill its mission, DISA PSD requires contract writing systems for both telecommunications and IT (also referred to as Traditional) contracting. DISA PSD established the Enterprise Business Modernization (EBM) project in January 2004 to meet the following objectives for DISA PSD’s contract writing system:

• Create a single integrated procurement solution that is uniformly implemented and readily accessible worldwide.

• Share consistent data, services, and processes across business functions and systems applying the tenets and principles of net-centricity.

• Provide accurate and easily retrievable information for all PSD contracting functions and associated external users.

• Reduce operational costs while increasing procurement efficiency.

The resultant contract writing system capability, IDEAS-O&M, was deployed in 2009 for DISA PSD’s telecommunications products and services contracting. The modernized solution for IDEAS is called IDEAS-Next Generation (NG) is under development in an effort to make the existing code and processes compliant with the Department of Defense (DoD) mandated Business Enterprise Architecture (BEA), specifically the Procurement Data Standards (PDS) and Purchase Request Data Standards (PRDS) that support the Procure to Pay (P2P) business model.

Page 2 of 39 Pages

IDEAS is being developed using an agile development methodology taking advantage of the Appian Business Process Management (BPM) commercial off-the-shelf (COTS) tool.

The current IDEAS solution is built on the Appian platform and BPM is hosted in the Impact Level 5 (IL5) Appian Government Cloud (AGC), a commercial cloud offering that sits atop of the Amazon Web Services Government Cloud, West region. In summary, the underlying BPM that supports the application, the database on which the business data resides, and the technical architecture supporting all are contained in the AGC. The AGC environment consists of 4 instances to manage the development and support effort.

• Development – used by the developer team to configure the Appian BPM tool to resolve business issues.

• Staging – used to perform low level testing taking advantage of an agile development mindset.

• Performance – is a higher testing environment with “close to real” data which can be used for end-to-end testing, testing of resource intensive IDEAS features, user acceptance testing (UAT), and perhaps as a fail-over when there is a need to shut down the Production environment for maintenance.

• Production – the layer the user sees as part of their business requirement.

Any legacy functionality of the IDEAS-O&M solution that still needs to communicate with other legacy systems still in use at DISA takes advantage of a Data Integration (DI) layer used to move data from the various P2P systems. The DI relies on a series of web services that either receive or transmit data amongst the systems. This layer resides in the DISA offered Stratus cloud environment although it also connects to the IDEAS database in AGC to store its data schemas. The technical environment in the Stratus cloud includes a Virtual Operating Environment supporting the Production Suite for the operators, and a Staging Suite for system functional verifications and UAT. There is no end user capability in the DI; only web services moving data between systems.

The DI will be sunset when all legacy contracts are transitioned out of IDEAS-O&M.

The Scrum development process and sprint cycles are currently managed using an Appian BPM Artifact Management Tool developed exclusively for IDEAS. If DISA mandates a different tool to manage the technical effort, the contractor shall use the new tool as provided by the Government.

4. Objectives: The objective of this requirement is to provide solution definition, software development, testing, integration, production support, and expertise for IDEAS and the DI Layer. This includes providing support and expertise for: DoD Business Enterprise Architecture, Telecommunications Contracting, System Integrations, Data Warehousing, transactions occurring between systems, user training, governance documentation, and reporting capabilities.

IDEAS system integration support shall include accommodating the Defense Pricing and Contracting business systems office’s Application Program Interface (API) as it evolves, maintaining existing integrations (e.g., Federal Procurement Data System – Next Generation (FPDS-NG), Defense Logistics’ Agency (DLA) Global Exchange (GEX)/EDA, etc.), and establishing new or updated integrations for IDEAS-NG as DISA modernizes its other business systems (e.g., Oracle Financials integration using the PDS and PRDS as they apply to the flow of contract data in the DoD P2P process.

IDEAS software development support shall include all phases of the Software Development Lifecycle (SDLC), including concept development, planning, requirements definition and analysis, systems design and development, coding and testing, deployment, implementation, integration, troubleshooting, security posture, documentation, and software application maintenance necessary to sustain and/or modify the system baseline. Responsibilities include managing the IDEAS’ code baseline as it interacts with users, the hosted environment, and external systems. The IDEAS baseline may change because of changes to Laws, Regulations and Policies (LRPs), user preference, latent defects, change requests, security requirements, or to accommodate new releases of the COTS products used by the system (e.g., Appian BPM, Red Hat Linux, Web Logic, Apache, etc.) or expansion of the types of business processes supported by IDEAS.

IDEAS production support shall include troubleshooting and resolving user problems and identification of opportunities to improve processes or business process models in the system.

Page 3 of 39 Pages

IDEAS reporting capabilities shall be augmented / developed to support customer requirements and or to improve the availability, timeliness, and quality of IDEAS data. The reporting capabilities were created using Appian’s BPM tool and enhanced by Java software code. Reports access data through associated system components such as web and integration software. It is imperative to minimize or even eliminate any and all specialty code that may negatively impact regular upgrades to the Appian BPM version. The Government’s goal is to strive to stay within no more than 2 major versions away from the current Appian BPM.

The contractor shall work closely with other members of the team to include IDEAS engineers, Government subject matter experts (SMEs), stakeholders, Government test team, hosting, security, and end-users.

5. Scope. The contractor shall provide software development support for IDEAS-O&M and IDEAS-NG in the DISA’s Business Systems Portfolio Management Office (PMO). The contractor shall provide a solution, product consulting, and programming to:

(1) Implement new system capabilities by the configuration of COTS software;

(2) Implement change requests;

(3) Sustain deployed capabilities in the IDEAS-O&M and IDEAS-NG solution by rapidly troubleshooting and resolving software issues impeding the execution of deployed contracting capability (i.e. correct Tier 3 defects);

(4) Provide technical expertise to ensure high availability of the IDEAS applications to meet the DISA mission;

and,

(5) Receive and respond to problems reported by the users (i.e. correct Tier 2 incidents). This support shall address issues with the core Appian BPM components in the IDEAS solution, as well as its integration components in Java.

The IDEAS platform has approximately 500-person primary contracting user base, which includes contracting personnel in three general time zones, Europe – 10% (which includes Southwest Asia), continental United States – 80%, and Pacific region – 10%. Each field office has technical support personnel who are responsible for most Tier 1 activities (e.g., client PC operation, network connectivity). The contractor shall provide remote tier 2 and 3 technical support to all users worldwide. Different types of contracting users will conduct different types and amounts of transactions in the contracting systems, and consequently will have different levels of impact on support.

IDEAS also maintains an internet-facing capability used by commercial activities outside the DoD network (DoDNet). These vendors are pre-authorized for access by PSD and can only log in to IDEAS via Tier 2 assigned username and customer selected password. This non-common access card (CAC) log in capability is reinforced by multi-factor authentication via email.

The contractor shall modernize and sustain the existing application, system integrations, and reporting capabilities.

These areas are comprised of distinct key application and operational capabilities that include:

Telecommunications Contracting Orders against Indefinite Delivery (ID) Contracts Inquiry Quote Order (IQO) Contracting Blanket Purchase Agreement (BPA) Inquiry, Quote, Order (IQO)

System Integrations Financial Accounting Management Information System (FAMIS) Federal Procurement Data System – Next Generation (FPDS-NG) Contract Opportunities (SAM.gov)Clause Logic Service (CLS) Data Variable Transaction Set (DVTS) (Contractual Online Procurement System (COPS)) COPS Inventory of Service (IOS) (COPS) DLA Global Exchange Services (GEX)) Procurement Data Standard (PDS) Validation Service Order Management Conformed Contract View (CCV) Telecommunications Service Request (TSR) Services (DISA Storefront (DSF)) DISA Marketplace (DMP)

Page 4 of 39 Pages

Notification Service (Contract Support System (CSS)/Status of Acquisition Message (SAM)/Telecommunications Status Information (TSI)) Standard Financial Information Structure (SFIS) Service (US Standard General Ledger (USSGL)) Data Migration Service (Electronic Document Management System (EDMS)/(CSS)) AutoFile Service (EDMS/CSS) PRDS Service (DISA Financial Management Ledger) Electronic Document Access (EDA) Worldwide Online System (WWOLS)

Reporting and Metrics Standard Reports Ad-Hoc Reports and Queries Data Warehouse

The IDEAS requirement consists of the following task areas:

Task Area 1 - Task Order Management Task Area 2 - Software Support for Telecommunications Contracting Task Area 3 – Production Support for Telecommunications Contracting Task Area 4 - System Administration and Cybersecurity Task Area 5 - Software Support for Traditional Contracting (Optional Task) Task Area 6 - Production Support for the Traditional Contracting (Optional Task) Task Area 7 - Migration Support to Cloud or Software as a Service Platform (Optional Task).

Task Area 8 – DI Server Support (Optional Task)

The Government may require surge support during the base or any option period, and surge modifications will be within the scope of the contract and provide increased support for the defined task areas of this PWS. Surge support over the life of the contract will not exceed 40% of the contractor’s total proposed cost/price for the base and all option periods, excluding any six-month extension of services pursuant to Federal Acquisition Regulation (FAR) 52.217-8.

6. Performance Requirements. The contractor shall use a Government provided software tool (e.g., JIRA) to effectively manage and execute the agile Scrum methodology to analyze requirements, decompose large requirements into logical sub artifacts, create user stories for Epic (i.e. large encompassing stories that must be decomposed into children stories), level artifacts and technical specifications, coordinate with the appropriate SMEs (both technical and functional) to receive approved acceptance criteria for Epic/Task/Subtask level artifacts, set Story Points and establish a waterline, develop and test software, create test scripts and implement UAT, and keep artifact statuses updated (artifacts are the method for identifying a change with software which will be deployed to Production). To maintain predictable velocity, the contractor shall complete the artifacts directed by the COR in each software sprint, and team members are encouraged to collaborate towards requirements completion. User stories and design documentation shall be maintained within artifact tracking tool. Appian BPM process models and other "source code" level documentation shall include the artifact number, date, name of the developer, and a short summary of every change (i.e. solution provided). The technical release documentation shall trace all changes between original sources (e.g. Change Request number), artifact(s), modules, and test scripts and shall document all changes and procedures necessary to place a given release into production.

Each assigned task will have one or more associated artifacts. The IDEAS software development sprints are typically planned as 2-6 week sprints resulting in monthly software releases. The COR has final approval regarding the work to be accomplished in each sprint.

The contractor shall serve as an active member of the Change Advisory Board (CAB) and the Configuration/Change Control Board. The contractor is responsible for defining user stories, maintaining the product backlog, and prioritizing the product back-log to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the features or components. The contractor shall collaborate with the development teams from legacy, DI and BPM to ensure the artifact tracking tool (e.g. JIRA) and IT Service Management (ITSM) are actively maintained and reflect the status of each artifact or ticket. The contractor shall also collaborate with contract

Page 5 of 39 Pages specialists (CS), contracting officers (KOs) and other key stakeholders to ensure requirements are understood and properly defined so that an appropriate t-shirt size, or level of effort, can be designated for each artifact and story points associated to each user story.

The contractor shall respond to artifacts to change the system configuration and reports. The contractor shall lead the Scrum process and other meetings to define, build, test, document, and deploy updates to the Appian BPM platform.

The contractor shall ensure lead-time for understanding and responding to unique CAB approved requests. The planning for functionality requested by the CAB may include the contractor’s recommendations to minimize rework and cost. If a change is beyond the contractor's capacity to complete in the assigned sprint, the contractor shall provide a detailed implementation recommendation and schedule during the weekly sprint review meetings.

Complex tasks may require additional documentation and coordination prior to coding. These tasks are assigned to a sprint for development of a specification prior to the implementation sprint. The contractor shall work with SMEs to create, and receive approval on, user stories, functional specifications, or technical specifications. Additionally, the contractor shall maintain a software development and product roadmap as defined in subtask 6.1.1 of this PWS.

As legacy application functions transition to IDEAS, the contractor shall provide IDEAS application development support including performing analysis and development using Java Development Kit to support Java and Java Script; maintaining code integrity using Team Foundation, SourceSafe, Subversion or equivalent; maintaining web services using Oracle Web Logic; performing development using cloud-based environments; and subject matter expertise in Scrum development practices. This support is intended to provide integration support between IDEAS and other in-ternal and external business systems.

If a change results in a latent defect found during operation at some future time, and analysis determines the contractor's personnel made the errant change, the defect shall be corrected by contractor personnel without affecting software sprint/release velocity.

6.1. Task 1 – Task Order Management. The contractor shall provide the planning, direction, coordination, and control necessary to accomplish all requirements in this PWS. The contractor shall designate key personnel responsible for the schedule, and technical performance for the contract and shall serve as a primary Point-of- Contact for both management and technical matters. In addition, the contractor shall attend monthly Program Management Review meetings where the status of the work and associated deliverables are reviewed in the context of the business processes supported by the system.

The Task Order Management Plan, submitted as part of the contractor’s proposal, shall be updated as changes occur or upon request from the COR.

The Task Order Management Plan (TOMP) shall include at a minimum:

Organization Management structure/control (by name and job title) Task Order execution plan

Identification of Non-Disclosure Requirements. All DISA Contractors must execute a DISA-provided contractor non-disclosure agreement (NDA) for all services contracts regardless of award amount. The NDA must be signed within one week of contract/TO award. The DISA contractor is responsible for obtaining and maintaining NDAs for each contractor employee assigned to the contract/TO.

6.1 Deliverables:

Task Order Management Plan Non-Disclosure Agreements

6.1.1 Subtask 1 – Program Reporting. The contractor shall maintain and provide input into an Integrated Master Schedule (IMS). The IMS will align to the Program Manager’s (PM) monthly sprint schedule and define the specific tasks associated to the items in the product roadmap. Additionally, the IMS shall highlight interdependencies

Page 6 of 39 Pages between contractors and tasks that pose a risk to the Government. The IMS shall be updated weekly and reflect the most current state of the development and support efforts.

The contractor shall maintain a software development and product roadmap to plan out new capabilities, functionality changes, system maintenance, and/or product upgrades. The software schedule shall include current sprint, sprint +1, and sprint +2. The contractor shall be up-to-date with development software within 180 calendar days. Thereafter contractor shall be no more than two minor versions behind. The contractor shall provide a roadmap of the artifacts scheduled to be worked on for the next 90 calendar days. Based on the product backlog and change requests, the contractor shall provide a roadmap as far out as possible with data that is available at each sprint. The roadmap shall be updated at the beginning of each monthly sprint when the waterline is established and regularly updated as changes occur. The contractor shall use the roadmap to help articulate issues with staffing, requirements, and prioritization.

The contractor shall provide a weekly status report outlining the progress of current and future tasks for all active tasks with completion status. The report shall also identify any issues and risks, dependencies, and/or engineering updates that require Government interaction for resolution and/or impact delivery. The update shall outline what work has been performed, what problems have been encountered that may impact schedule, potential solutions for any problems, and projected tasks for the next week. The update shall also include metrics on the programs performance with regard to capabilities provided to the customer and the outcome from those capabilities. In addition, the weekly status report shall include proposed changes to the schedule as detailed in the management plan as well as property accountability, technical accomplishments, issues and risks, and planned activities for the next reporting period. Any issues requiring Government response or action shall be brought to the Government’s attention within 60 minutes of identification, and status captured in weekly reports.

The weekly status report shall contain tickets and artifacts received and the actions taken during the reporting period. It shall correlate actions taken to other tasks or solutions that address resolving the reason for the artifact.

Any Government Tracking System (GTS) epics in development should be correlated to program requirements as appropriate. Since the artifacts are assigned via the GTS. Since the artifacts are assigned via the GTS Database and the contractor’s Team Lead or designee will enter results into the GTS, metrics associated with the responsiveness, quantity, and duration of the artifacts will be extracted directly from the GTS. The status report shall include a cumulative tally of all artifacts assigned to the most recently completed release that have not been previously reported. This tally shall include the release identifier, total number of artifacts assigned to a release per category, the category (i.e. established within the GTS such as CAB Request, Defect, Requirement), and a total sum of total artifacts across all categories. Further, the report shall contain a sum of artifacts (per category and overall total) that were planned for each sprint (i.e. above the waterline after sprint planning using story points), as well as the sum of artifacts that are accepted in UAT (per category and overall total) and placed into production with the scheduled release. The bottom of the table shall include totals for each column. This table shall be provided in Microsoft Excel and/or comma separated value format. A notional example is provided below:

Waterline Deployed Release CAB Defect Requirement Total CAB Defect Requirement Total

10.3 17 4 9 30 17 5 7 29

10.3.1 3 3 3 3

10.4 22 9 4 35 22 9 4 35 Totals 39 16 13 68 39 17 11 67

This report shall contain the total number of open tickets by system name. The report shall identify how many tickets were opened during the work week and how many tickets were closed during the work week. The report shall identify any ticket that was not closed based on the criticality and resolution times specified in the performance standards of this PWS. The contractor shall be flexible with evolving reporting requirements to support emerging guidelines provided by DoD, DISA management and DISA customers. In addition, this report shall contain all open tickets by system name listed in order of prioritystarting with highest priority, and further sorted such that the

Page 7 of 39 Pages earliest ticket of a given priority is at the top for that priority grouping. This report shall contain the ticket #, priority level, associated tickets, descriptions, corrective action, date opened, and date closed with the user, as well as trend and other data the contractor's analysis suggests would be pertinent. It shall correlate actions taken to other tasks or solutions that resolved similar tickets. If the contractor has detected a trend, this report shall include a brief summary of the trend, associated tickets, pertinent distribution of causes, and recommended corrective action to prevent similar troubles. The contractor shall use their expertise in BPM to recommend changes to form labels, help text, data validation, and process models. The Government will review these recommendations and provide guidance when appropriate.

The Contractor shall submit the Monthly Status Report collating all relevant information from the weekly status report since the previous MSR and other deliverables from other tasks.

6.1.1 Deliverables:

IMS

Software Development and Product Roadmap Weekly Status Report Monthly Status Report

6.1.2 Subtask 2 – Contract Transition. The contractor shall provide a written Transition-Out Plan 90 calendar days prior to contract expiration. The contractor shall provide all materials and support necessary to accomplish a seamless and expeditious transition of the tasks identified in this PWS to the incoming contractor. The contractor shall deliver a Transition-Out Plan which includes electronic copies of the following: all in-progress working files, historical files for all tasks, Concept of Operation (CONOPS) procedures, and final phase out meeting with Government, incumbent and the new contractor, and documented lessons learned throughout the life of the contract.

The Transition Plan shall be delivered to the Government 90 calendar days before the end of the contract period of performance.

6.1.2 Deliverables

Transition Plan

Deliverables for Task Area One (1):

PWS

Task#

Deliverable Title Format Due Date Distribution/Copies Frequency and Remarks

6.1 Monthly Status

Report (MSR)

Contractor format, Government approved

Due within 2 business weeks after month end

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Monthly and can consolidate multiple deliverables throughout the PWS into the

MSR.

6.1 Task Order

Management Plan

Contractor format, Government approved

Due with Technical proposal

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Update due as changes occur or upon request from the Government.

Page 8 of 39 Pages

6.1 Non-Disclosure

Agreements

Government format Due 5 business days of contract award

Standard Distribution* and email to ACOR, Tech Lead, and Product Owner

Once after due date.

Update(s) due as changes occur or upon request from the Government

6.1.1 IMS Contractor format, Government approved

Initial due 60 days after contract award then at the beginning of each 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

On the Monday following each 2-6 week sprint release

6.1.1 Software

Development and Product Roadmap

Contractor format, Government approved

Initial due 60 days after contract award then at the beginning of each 2-6 week sprint

Standard Distribution* and email to ACOR, PM, Tech Lead, and Product Owner

On the Monday following each 2-6 week sprint release

6.1.1 Weekly Status

Report

Contractor format, Government approved

Initial due 10 days after contract award then every Friday.

Standard Distribution* and email to ACOR, Tech Lead, and Product Owner

Weekly

6.1.1 Change Request

Documentation

Contractor format, Government approved

1st Business Day of the Month

Standard Distribution* Monthly

6.1.1 Configuration

Management Plan and Procedures

Contractor format, Government approved

Initial due 60 days after contract award

Standard Distribution* Once at due date

6.1.2 Transition Plan Contractor format, Government approved

90 calendar days before contract expiration

Standard Distribution* Once at due date

*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer; 1 copy of the transmittal letter with the deliverable to the Primary COR.

6.2. Task 2 – Software Support for Telecommunications Contracting. The contractor shall respond to requirements that are generated by the Government. Artifacts are the method for identifying a change with software, which will be deployed to Production. The contractor shall properly record user stories, issue(s), acceptance criteria, testing, and software solutions to create an IDEAS knowledge base within the GTS (e.g., JIRA). The contractor shall follow the SDLC process when completing artifacts to include: requirement decomposition, elicitation, completion of user stories and specifications, development, unit testing, integration testing, and UAT.

Page 9 of 39 Pages

6.2.1. Subtask 1 - Software Support. The contractor shall employ the agile Scrum process to define, build, test, document, and deploy updates to the IDEAS. This process agility shall support system change frequency as short as a single day, but typically scheduled for 2 to 6 week sprint cycles. These artifacts may emerge from CAB Change Requests, Requirements based on LRP changes, PMO requirements, or changes to requirements in the system's security posture. Check points are inherent in the agile development process; however, it is extremely important that new capability software components are uniquely identified during the process. User stories, use cases and/or functional specifications shall capture features to be deployed and will be used by the Government as a basis for testing and acceptance.

The contractor shall attend the Scrum process meetings and other meetings to define, build, test, document, and deploy updates to the Appian BPM platform. The contractor shall ensure lead-time for understanding and responding to unique CAB approved requests. The planning for functionality requested by the CAB may include the contractor’s recommendations in order to minimize rework. If a change is beyond the contractor's capacity to complete in the assigned sprint, the contractor shall provide a detailed implementation recommendation and schedule in the project plan and it will be discussed during the weekly sprint review meetings. These tasks are assigned to a sprint for development of a specification prior to the implementation sprint. The contractor shall create, and receive approval on, user stories, functional specifications, or technical specifications, and may consult with SMEs in the accomplishment of this task.

The contractor shall provide a project plan and employ the agile Scrum process to design the necessary capability.

This design shall include all necessary artifacts and appropriate sizing / complexity documented in artifact tracking tool with the required elements for planning, development, and testing. The project plan shall include logical milestones for the deployment.

In addition, the contractor shall respond upon identification to production support issues that cause work stoppage or operational problems with IDEAS and ensure the Production Suite operates without interruption to functional users.

Software defects that result in work stoppage or impact to business operations shall result in an unplanned software Hot Fix. Correcting defects identified through production support that do not result in work stoppage shall be prioritized and assigned to current sprint or sprint +1 by the Government depending on the impact to business operations. The contractor shall provide production support (i.e. Tier 2) activity in identifying the root cause of production support malfunctions and creating Tier 3 artifacts (i.e. software code changes) to permanently resolve and prevent them. The contractor shall input all actions taken to resolve artifacts into artifact tracking tool. The contractor shall coordinate with the Tier 2 production support team to ensure minimal rework or downtime during software changes and to ensure the Tier 2 activity understands planned system changes. The contractor shall join in UAT for releases to ensure proposed changes are acceptable to the users. The contractor shall provide release notes and, host release reviews for functional users to illustrate system changes.

The primary deliverable of this task is a detailed project plan, release documentation, process models, functional specifications, interface control documents, system configurations, software code, database schemas, system operating manual, and user release notes from this task.

Release documentation shall include a work plan with recurring updates, release test plans, release test results, UAT plan with user test scripts, process models, functional specifications, interface control documents, system configurations, software code, database schemas, system operating manual, request to promote, and user release notes from this task. Release notes, which include all artifacts with associated problem descriptions, solutions, and deployment instructions. The contractor shall provide post release, and additional information regarding outstanding actions, risks, or issues to the Government. This will allow the Government to fully understand the work that has occurred, post release issues, risk, or outstanding actions, and forecast what is being planned for the future. The information shall be provided at the post release meetings (typically held the first business day after a release).

The System Operating Manual shall capture information sufficient to install, operate, and maintain IDEAS shall be provided and maintained.

Actual software code shall be installed on the virtual machine architecture currently set up to support IDEAS, thus

Page 10 of 39 Pages maximizing efficiency of development, testing, performance, and availability to the customer; and provided as a tagged code segment via the Government managed code repository or delivered on Digital Video Disc or other mutually agreed upon format.

The contractor shall provide user release notes prior to a software release being deployed into the production environment. The release notes shall include a summary of the added functionality, the change requests, bug fixes and associated artifacts included within the release. The user release notes shall be written at the user level and not a technical description of the release. The contractor shall develop, update, and maintain all IDEAS user-facing documentation. This documentation shall be rendered and delivered using standard office applications such as MS Word, Power Point, Excel, and Visio, as well as other visual presentation applications such as Adobe PhotoShop and TechSmith Camtasia following the Government’s style guides. The contractor shall join in the SDLC along with users and developers to understand user needs, struggles, and system behavior so documentation can be provided that makes the users as productive as possible. Typical engagements and meetings include participating in user training, release reviews, general meetings, and UAT. The contractor shall monitor each release as it approaches UAT to draft release notes from the release plan (e.g. Software Forge, JIRA) for all user visible artifacts. These release notes shall explain the changes visible to the user in language understandable by the user audience, as well as the respective ticket numbers (artifacts, incident, change request, etc.) associated with each item. These notes shall be posted in the specified repository and the Government notified once posted for review and publishing.

The contractor shall initiate a formal request to promote to the Government prior to executing a software release.

The request to promote shall be accompanied by a document that highlights the artifacts to be released, the proposed date and time of the release, the release version, the names of external systems impacted, implications to the security posture, confirmation that all artifacts were tested, deployment instructions, rollback procedures and confirmation that resources needed for the release are scheduled or available. The request to promote requires review and sign-off from the Information System Security Manager (ISSM), technical lead and PM.

The contractor shall ensure compliance to the DPAP guidance and policy for Telecommunication and Traditional contracting. The contractor shall work closely with contracting stakeholders in order to better understand the business needs. The contractor shall interpret, analyze, and translate Telecommunication and Traditional contracting business needs and problems into requirements. The contractor shall ensure requirements are agreed upon and approved by the contracting stakeholders prior to translating to the technical teams. A specification document shall be used to define contracting requirements, capture stakeholder input, and serve as concurrence between key business stakeholders and the technical teams. The contractor shall provide subject matter expertise to the contracting stakeholders and technical teams when requirements are unclear or non-compliant with DPAP guidance, inefficiencies exist in business rules, or process flows and to assist with defining level of effort to help facilitate proper prioritization by both the functional and technical teams. Develop and support data migration strategies from systems that are non- compliant with DPAP to compliant processes within IDEAS. Contractor shall provide documentation and test data supporting interoperability certification within a suite of DPAP compliant systems.

Contractor shall work closely with other systems in the P2P process to ensure interoperability in compliance with DPAP guidance and policy.

6.2.1.1 Subtask 2 – IDEAS Backlog Support. There is stakeholder interest in reducing the IDEAS Product Backlog, which has been growing considerably due to the need to address higher priority artifacts. This underlying subtask addresses a surge in the development effort to address an estimated 50 to 70 additional high priority story points in the Product Backlog over an 8-month period, as per the PMO direction. The contractor shall complete the artifacts related to AutoMod-AutoCAR (AMAC) and migration of Portal features to Tempo. Successful completion of the AMAC and Portal to Tempo artifacts may include additional, unidentified artifacts based on dependencies and any unforeseen events while completing the aforementioned artifacts, but PMO will verify with the customer before execution. After successful completion of AMAC and Portal to Tempo artifacts, at the discretion of the PMO, work may begin on other high priority artifacts deemed necessary. The planned releases for these artifacts will coincide with the regular six-week release schedule with the potential for a shorter quick release cycle as determined by the Program Management Office. Further, the contractor shall add a section to the deliverables annotated in 6.2.1 and 6.2.3, specifically for the artifacts deployed in support of this subtask.

6.2.1 Deliverables:

Project Plan

Page 11 of 39 Pages

Release Documentation Process Models Functional Specifications Interface Control Documents System Configurations Software Code Database Schemas System Operating Manual Request to Promote Document Specification Document

6.2.2. Subtask 2 – Technical Refresh Support. The contractor shall provide support services for changes due to the commercial migration path of the Appian COTS software. This will involve analyzing existing process models against new Appian releases for incompatibilities and superseded features. Once approved by the Government, the contractor shall refactor the necessary applications to ensure continued stability. This refactoring shall be incorporated with the IDEAS release schedule (2-to-6-week sprints) and follow the SDLC process for integration and UAT of refactored code.

6.2.3 Subtask 3 - Training. The contractor shall provide a user guide and a training manual to be used during the semi-annual training session. The user guide and training manual shall be updated and delivered with each sprint release to ensure changes to the system are reflected. The contractor shall conduct semi-annual training sessions onsite with the user community. Contractor shall travel to DISA locations (i.e. Fort Meade, Scott Air Force Base, Hawaii, Germany, or Bahrain) to support system training for new users.

The annual training schedule, to include locations for travel, shall be coordinated and approved at least a month in advance with the COR.

6.2.3 Deliverables:

User Guide Training Manual

6.2.4 Subtask 4 – Compliant Telecom New Development. In order to achieve full operational capability, DISA must enhance IDEAS to provide for compliant contracting processing capability for DISA’s telecommunications contracts. Specifically, business process changes must be implemented in IDEAS to be able to write contracts that are compliant with current procurement and financial policies. These changes are required to support the integration, in a compliant framework, with other systems in the P2P business area which include, but may not be limited to, the Financial Accounting Management Information System (FAMIS) and DISA Marketplace (DMP). Enhancements will be performed on an Agile Sprint software development framework planned on the release schedule below implemented with the use of features in the latest Appian version. The contractor shall utilize agile scrum in the development of Telecom modules.

New Modules to be developed and associated integration work include, but are not limited to:

• EMSS FAMIS Integration Testing / Bug Fixing (discovered during tests)

• Auto Mod (MRC & OCC) - The Auto Mod change addresses the need to fund, via auto-modifications, line items that are for the purpose of Other Charges and Credits (OCCs).

• PRDS Phase II DMP & FAMIS Integration Updates - PRDS Integration Updates encompasses all the changes that must be made to the PRDS XML sent to IDEAS from DMP and FAMIS for Tariff Mass Mod, Auto Mod MRC, Auto Mod OCC.

• Tariff Disposition

• Tariff Mass Mod - The Tariff Mod Funding change addresses the Contracting Office (PSD) need fund, via auto-modifications, line items that are subject to tariff pricing.

• Auto Mod – MRC & OCC Error Handling

• Routing Rules for Phase II - The Routing rules changes addresses the routing of approvals for the capabilities above.

Page 12 of 39 Pages

• Phase II DMP & FAMIS Integration / E2E Testing

• Return of Excess Funds

• Tariff Mass Mod Error Handling

• Migration II to Compliant Telecom

Capability Breakdown for IDEAS-NG. (not inclusive of all requirements)

Capability Handshake(s)1

• BEA Phase 2 development work, to include Updating the PR process and CAN process in accordance with DMP requirements, updating the Funds Certification / Obligation process, Closeout HS9 development, and finishing the PR Amend/Cancellation functionality.

1,2,3,5,9

• End-to-End BEA testing with DMP and FAMIS, to include an in-depth hands-on user training with PSD 1,2,3,5,9

• Pricing Schedule – BEA MRC Phase III. Performed in addition to Auto-Mod effort. IDEAS to generate and send the pricing schedule to DMP upon Award release.

Includes MRC process flow for messages and increases in funds obligation.

• Type Action Updates to handle the following type actions included in the PRDS xml: DISCONTINUE, TEMPORARY, and RE-AWARD’ 1

• Continue implementation tech debt / hardening to environment – implement lessons we expect will be learned from integration with new DISA MarketPlace (DMP) system

1,2,3,5

• CLIN/SLIN Updates. Adjustments to the CLIN/SLIN structure, including allowing DTI to be marked at the CLIN level instead of contract level. Outstanding decision needed on NOC/R&A at the CLIN level.

Examples of upcoming requirements (not inclusive of all requirements)

Task Handshake(s)2

• Update Return of Excess Funds -. allow CS/KO to return excess funding on the conformed PR upon Award/Mod release. Epic includes any technical GEX updates and general updates.

1,2,3,9

• Complete user-initiated Mass Mods for Tariff updates – implement lessons learned from integration with new DISA MarketPlace (DMP) system 1,2,3

• Other Charges and Credits (OCC). IDEAS to handle when FAMIS sends a call when a vendor submits an invoice that exceeds the funds obligated due to OCCs. Final design and level of effort depends on currently outstanding decision if this will follow the MRC process or requires creation of a contract modification.

1,2,3

• Mass Mod PDS. Perform PDS validation for Mass Mods from policy and compliant perspective on every modified Award. Final design and level of effort depends on business decisions that will be finalized within the next few months.

2,3

• Migration Utility & Migration Strategy. Final design depends on business decisions that will be finalized within the next few months. 1,2,3,5

• Updates to the Order Number. Additional business cases awaiting from FAMIS to consider the changing of the purchase request order number for the life of the Award/Contract.

1,2,3,4,9

1 Implementation of Handshake solution(s) require end-to-end testing with the ordering and or financial systems.

2 Implementation of Handshake solution(s) require end-to-end testing with the ordering and financial systems.

Page 13 of 39 Pages

Task Handshake(s)2

• Updates to the NOC / R&A process. Additional business cases for the Notice of Completion and Receipt/Acceptance process that the IDEAS team will need to adapt for and update.

• Next Generation BEA Reporting. Updates and enhancements to the Procurement Administrative Lead Time (PALT) report to be used to answer customer complaints, regulatory requirements, and drive workload. MRC reports to include statuses and history of funding obligations, FPDS, Closeout, and various Workload reports

N/A

6.2.4 Deliverables:

Project Plan Release Documentation Process Models Functional Specifications Interface Control Documents System Configurations Software Code Database Schemas System Operating Manual Request to Promote Document Specification Document

Deliverables for Task Area Two (2):

Deliverable Title

Format Due Date Distribution/Copies Frequency and Remarks

6.2.1 Project Plan Contractor format, Government approved

6 weeks after award of contract

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.1 Release

Documentat ion

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.1 Process

Models

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.1 Functional

Specificatio ns

Contractor format, Government approved

Every 2-6 week sprint

Standard Distribution* And email to the Tech Lead and Product Owner

1x every 2-6 week sprint

6.2.1 Interface

Control Documents

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.1 System

Configurati ons

Contractor format, Government approved

Every 2-6 week sprint

Standard Distribution* and email to the Tech Lead and Product Owner

1x every 2-6 week sprint

6.2.1 Software

Code

Contractor format, Government approved

Every 2-6 week sprint

Standard Distribution* and email to the Tech Lead and Product Owner

1x every 2-6 week sprint

Page 14 of 39 Pages

6.2.1 Database

Schemas

Contractor format, Government approved

Every 2-6 week sprint

Standard Distribution* and email to the Tech Lead and Product Owner

1x every 2-6 week sprint

6.2.1 System

Operating Manual

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.1 Request to

Promote document

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.1 Specificatio

n Document

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.3 User guide Contractor format, Government approved

2 business days prior to a sprint release

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Update due as changes occur or upon request from the Government

6.2.3 Training

Manual

Contractor format, Government approved

2 business days prior to a sprint release

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Update due as changes occur or upon request from the Government

6.2.4 Project Plan Contractor format, Government approved

6 weeks after award of contract

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.4 Release

Documentat ion

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.4 Process

Models

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.4 Functional

Specificatio ns

Contractor format, Government approved

Every 2-6 week sprint

Standard Distribution* And email to the Tech Lead and Product Owner

1x every 2-6 week sprint

6.2.4 Interface

Control Documents

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.4 System

Configurati ons

Contractor format, Government approved

Every 2-6 week sprint

Standard Distribution* and email to the Tech Lead and Product Owner

1x every 2-6 week sprint

6.2.4 Software

Code

Contractor format, Government approved

Every 2-6 week sprint

Standard Distribution* and email to the Tech Lead and Product Owner

1x every 2-6 week sprint

6.2.4 Database

Schemas

Contractor format, Government approved

Every 2-6 week sprint

Standard Distribution* and email to the Tech Lead and Product Owner

1x every 2-6 week sprint

6.2.4 System

Operating Manual

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.4 Request to

Promote document

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

Page 15 of 39 Pages

6.2.4 Specificatio

n Document

Contractor format, Government approved

Every 2-6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer;…