DISAFY27LEGACY - SSN - Draft PWS 06262026.docx

PERFORMANCE WORK STATEMENT (PWS)

1. Contracting Officer’s Representative (COR).

a. Primary COR:

Reference G1, Points of Contact

b. Alternate COR:

Reference G1, Points of Contact

c. Property Administrator:

Reference G1, Points of Contact

2. Contract Title. Legacy Application Software and Development 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.

The primary legacy systems include the Contract Support System (CSS), Contractual Online Procurement System (COPS), Financial Accounting and Budget System (FABS), and the Defense Information Technology Contracting Organization (DITCO) Web. Other subsystems include but are not limited to: Rates and Tariffs File System (RTFS), Joint Hawaii Information Transfer System (JHITS), and the Delivery Ticket Invoicing (DTI) process.

CSS is a web-based application used by the contracting staff and budget analysts to enter procurement, funding, contractor and user information. CSS provides standard reporting and tracking capability of procurement, funding, contractor information using a central Oracle database. Specific modules within CSS are Procurement Information (PI), Customer/Contractor Information (CCI), Telecommunications Status Information (TSI), Employee/User Identification (ID) Information, and Exception Handler. Related CSS modules include but are not limited to all application, processes, and details of pertinent information related to these services. Many of the related CSS modules execute from the File Transfer Protocol (FTP) server within the adTempus scheduler. Examples of related CSS modules include, for instance:

· COPS IOS application

· CSS TSI Document Processor application (to include the maintaining the DITCO Automatic Digital Network System mailbox)

· CSS Telecommunication Status Information (TSI) Exception Handler lite application

· CSS TSI Status of Acquisition Messages (SAMs) Email / Electronic Document Management System (EDMS) / Web application

· CSS TSI SAMs Import application

· CSS TSI Telecom Macros

· CSS TSI Tech Refresh (TR) / SAMs Import/Distributor application

· CSS Admin Tool consisting of Employee/User Identification (ID) Information and Customer/Contractor Information (CCI)

DITCO Web is the PSD contract tracking system used to track status of contracts awarded as well as requirements in process, monitor and assign workload, and ensure new awards and modifications are processed in a timely manner.

Related modules include but are not limited to:

· CSS Reports

· Web Email Import

· WebPost application

COPS is an online and batch processing system used to establish, manage, change or discontinue telecommunication services and equipment. An Inventory of Service (IOS) is a detail of pertinent information related to those services and equipment. COPS records contain data fields describing service, location, equipment, mileage, and costs. Batch applications are used to generate the IOS and other reports. COPS will be phased out as SD2 migrates to an approved, modernized system using a Migrate/Sync web service.

FABS supports both vendor payment and customer billing. Monthly reports are produced and are provided to Joint Enterprise Services Directorate (JESD)/DISA’s customers. Customer billing data consists of monthly recurring charges, non-recurring charges, DISA managed program charges, overhead charges and other billing type information. Information from FABS is used by customers to plan, program, budget, and execute funds. Additionally, FABS provides data to the Financial Accounting Management Information System (FAMIS) General Ledger Subsystem so that DISA/ Resource Management (RM) can manage its internal telecommunications budgets and produce financial statements. FABS also manages and tracks the financial aspects (e.g. accounts payables, vendor invoices, vouchers) associated with telecommunication circuits, equipment and services leased from various vendors on behalf of the Government through the Defense Wide Working Capital Fund (DWCF) / Telecommunications Services and Enterprise Acquisition Services (TSEAS) Inventory and Billing Information (TIBI). The contractor shall ensure that DISA’s customers are billed for services provided and vendors are paid according to Account Payable limits for services on behalf of the customer.

RTFS is a mainframe application used to update equipment, mileage, and location records in COPS files based upon Federal Communications Commission (FCC) tariff regulations. Updates reflect carrier changes, circuit reconfigurations, Number Plan Area (NPA) Code splits (e.g., area code 314 split into area codes 314 and 636). New rates are provided by vendor price changes, contract price changes and subscriber rate changes. RTFS also provides inquiry capability to verify current and historical circuit prices.

JHITS is a contract that provides telecommunications service for the Hawaiian Islands. In order to accomplish Customer Billing and Vendor Payment (i.e., DTI), all service orders are interfaced between the commercial provider’s system and the COPS.

EDMS (Electronic Document Management System) is a system used for the secure storage, retrieval, and management of electronic documents. Support for EDMS is limited. See PWS Section 6.4.2 for additional details.

4. Objectives: The objective of this requirement is to provide technical and development support Database Administration (DBA) support and System Administration (SA) for the contracting and financial management legacy systems. This is a follow-on effort to sustain the current portfolio of legacy systems. SD2 manages and operates a complex group of software applications across a wide range of computing environments, including, mainframe and web-based. This technical and development, DBA and SA support is essential to maintain legacy applications. Analysis of the legacy systems and the data that resides within them will be required as part of the integration effort with related business systems.

Integration support shall include accommodating the Defense Procurement and Acquisition Policy (DPAP) business systems office’s Clause Logic Service (CLS) Application Program Interface (API) as it evolves, maintaining existing integrations (e.g. Federal Procurement Data System – Next Generation (FPDS-NG), Global Exchange (GEX)/Electronic Document Access (EDA), etc.), and establishing new or updated integrations for IDEAS and TSEAS as DISA modernizes its other business systems (e.g. Oracle Financials integration using the Purchase Request Data Standard (PRDS)). Legacy production support shall include troubleshooting and resolving user problems and identification of opportunities to improve processes or business process models in the system. Overall, software development support shall include all aspects of the Software Development Life Cycle (SDLC) necessary to sustain and modify the system baseline. The legacy software development contractors shall work closely with other members of the team to include Government developers, SAs, DBAs, hosting, security, mission partners and end-users. The description of each skill for this effort is provided in section 6 of this PWS under the Tasks.

5. Scope.

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 TBD% of the contractor’s total proposed cost/price for the base and all option periods, excluding any six-month extension of services pursuant to FAR 52.217-8.

The contractor shall provide technical and software development support for DISA’s Business Systems Portfolio Management Office (PMO). The contractor shall provide a solution and product consulting and programming to:

(1) Receive and respond to problems reported by the users (i.e., correct Tier 2 incidents). This support shall address issues with the core legacy systems and involve transactions and indirect dependencies that occur between legacy systems, the Data Integration (DI) server, TIBI, EDMS, DISA Storefront (DSF), Integrated Defense Enterprise Acquisition System (IDEAS), and other systems as indicated in the “System Integrations” paragraph list.

(2) Provide Tier 2 and Tier 3 centralized development support, database support and SA for the contracting and financial management legacy systems.

(3) Sustain deployed capabilities in the legacy systems by rapidly troubleshooting and resolving software issues impeding the execution of deployed contracting capability (i.e., correct Tier 3 defects);

(4) Develop, test and implement change requests to include existing Visual Basic 6.0 (VB6) applications conversion to Web, .net, or appropriate solutions.

(5) Develop and implement new system capabilities.

(6) Provide technical expertise to ensure high availability of the legacy systems to meet the DISA mission.

(7) Maintain and update system documentation such as Standard Operating Procedures.

(8) Create the necessary documentation for decommission.

(9) Modernize and sustain the existing application, data structures, system integrations, and reporting capabilities.

The activities listed above are in support of the legacy contracting and financial systems which involve transactions between IDEAS, TIBI, FAMIS-WCF and DISA StoreFront. The contractor shall provide support to approximately 700-person primary contracting user base, which include personnel in three general locations, 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.

The contractor shall modernize and sustain the existing application, system integrations, and reporting capabilities. These areas are comprised of distinct key applications and operational capabilities that include:

Telecom Contracting

Orders against Indefinite Delivery (ID) Contracts Inquiry Quote Order (IQO) Contracting

System Integrations

AutoFile Service (EDMS/CSS) Clause Logic (CLS) Contract Service (GEX)

COPS IOS (COPS)

CSS TSI SAM email/EDMS/Web CSS TSI SAM Import DISA Direct Store Front (DDSF) Data Integration (DI) Server Data Variable Transaction Set (DVTS (COPS))

EDMS

FABS European Voucher Module (EVM)

FAMIS-WCF

Sam.gov

FPDS-NG

IDEAS

Order Management (CCV) Procurement Data Standard (PDS) Validation Service (GEX) PRDS Service (DISA Financial Management Ledger) Standard Financial Information Structure (SFIS) United States Standard General Ledger (USSGL)

TIBI

Reporting and Metrics

Standard Reports Ad-hoc Reports and Queries Data Warehouse

6. Performance Requirements.

6.1. Task 1 – Contract 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 of the contract and shall serve as a primary Points-of-Contact for both management and technical matters. In addition, the contractor shall participate in 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 contract Management Plan, submitted as part of the contractor’s proposal, shall be updated as changes occur or upon request from the Government.

The TOMP shall include at a minimum:

1. Organization

1. Key Personnel

1. Management structure/control (by name)

1. Contract execution plan

This activity requires IT II, as authorized access is required to access the production, development, and test environments. In response to this effort, the contractor shall submit an appropriate staffing plan commensurate with their technical approach to meet these requirements.

6.1 Deliverable:

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’s) monthly development cycle schedule and define the specific tasks associated to the items in the product roadmap. Additionally, the IMS shall highlight interdependencies between contractors and tasks that pose a risk to the Government. The IMS shall be updated monthly 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 contractor shall provide a roadmap of the artifacts or activities scheduled to be worked on for the next 90 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 development cycle. The roadmap shall be updated at the beginning of each monthly cycle 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 Monthly Status Report (MSR) outlining the progress of current and future 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 MSR 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 monthly reports.

The MSR 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. Since the artifacts are assigned via the Government Tracking System (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 the Change Advisory Board (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 development cycle (i.e., above the waterline after development cycle planning using story points), as well as the sum of artifacts that are accepted in User Acceptance Testing (UAT) (per category and overall total) and placed into production with the scheduled release.

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 should 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 adapt to evolving reporting formats 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 priority starting with highest priority, and further sorted such that the earliest ticket of a given priority is at the top for that priority grouping. This report shall contain the ticket number, 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 to recommend changes to form labels, help text, data validation, and process models. The Government will review these recommendations and provide guidance when appropriate.

6.1.1 Deliverables:

*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 Technical Lead, PM and COR.

6.2. Task 2 - Legacy Application Technical and Development Support. This task includes providing centralized Tier 2 and Tier 3 technical and development support for the legacy contracting and financial management systems. The contractor shall utilize contractor furnished development environment, and test on a government furnished testing environment (presently on milCloud 1.0). The contractor shall respond to requirements that are generated by the Government through the CAB, program, security, production support (i.e., Tier 2), or trouble reporting mechanisms in the area of the legacy application, DBA and SA support. This application and database support is essential to maintain legacy applications.

The contractor shall use a Government provided artifact management tool (e.g., GITLab, 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 subject matter experts (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 predicable velocity, the contractor developers are held accountable to complete the artifacts they commit to in each software development, and team members are encouraged to collaborate towards requirements completion. User stories and design documentation shall be maintained within artifact tracking tool. Legacy 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 legacy software development cycles are typically planned for 4-6 weeks but can vary according to the project assigned. Each development cycle will result in a software release. The Government has final approval regarding the work to be accomplished in each development cycle.

The contractor shall serve as an active member CAB and the Configuration/Change Control Board (CCB). The contractor shall be responsible for defining user stories, maintaining the product backlog and prioritizing the product backlog 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, data integration and Business Process Management (BPM) to ensure the artifact management tool (e.g., GITLab, Jira) and Information Technology Service Management (ITSM)+ are actively maintained and reflect the current status of each artifact or ticket. The contractor shall also collaborate with the COR and other key stakeholders to ensure requirements are understood and properly defined so that an appropriate t-shirt size 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 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 and cost. If a change is beyond the contractor's capacity to complete in the assigned development cycle, the contractor shall provide a detailed implementation recommendation and schedule during the weekly development cycle review meetings. Complex tasks may require additional documentation and coordination prior to coding. These tasks are assigned to a cycle for development of a specification prior to the implementation cycle. The contractor shall work with Subject Matter Experts 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 more modern contract and financial systems, the contractor shall provide application development and database support. The contractor shall perform analysis and development to support and maintain code integrity using Team Foundation, SourceSafe or equivalent; perform development using cloud-based environments; and experience in Scrum development practices. This support is intended to provide integration support between IDEAS and other internal and external systems.

The contractor support includes security and accreditation maintenance, which may require access to Information such as Assurance Vulnerability Management (IVAM) and security scan data. This information is currently stored and managed on Secret Internet Protocol (IP) Router Network (SIPRNet) and the contractor shall require access to SIPRNet.

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 release velocity.

The contractor shall properly record user stories, issue(s), acceptance criteria, testing, and software solutions to create a legacy systems knowledge base within the artifact management tool (e.g., GITLab, 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.

This task includes responding to user trouble tickets, analyzing and correcting Tier 2 problems (i.e., specific incidents), escalating/reassigning those which they cannot resolve (i.e., Tier 3 problems requiring software code changes), and following escalated tickets to resolution. Typical Tier 2 problems to be resolved under this task include identifying processes and nodes that have failed to operate correctly, determining the cause of the problem, and correcting the problem for the process instance and/or database. If the problem was caused by a systemic problem in the system, a root cause analysis will be conducted and shall be identified and documented. The contractor shall trace data flowing through the system to determine what input, process, output, constraint or mechanism has failed. The contractor shall escalate issues beyond their ability or authority to Tier 3, or reassign them to the appropriate associated Tier 2 activity (e.g., Integration/interfaces or Defense Enterprise Computing Center (DECC) Hosting Operational Support Team), in accordance with the performance standards in Section 7.0 of this PWS. If escalation or reassignment results in any associated artifact, trouble or problem tickets, those tickets shall be recorded and tracked against the original trouble ticket until resolved. The contractor shall monitor and regularly check and record status of reassigned or escalated troubles until they are resolved or closed.

The contractor shall employ the agile Scrum process to define, build, test, document, and deploy updates to supported systems. This process agility shall support system change frequency as short as a single day, but typically scheduled for planned for 4-6 weeks sprints and can vary according to the project assigned. These artifacts may emerge from CAB Change Requests, Requirements based on law, regulation, or policy (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 participate in the Scrum process and other meetings to define, build, test, document, and deploy updates to the legacy systems. The contractor shall ensure lead-time for understanding and responding to unique CAB approved requests and shall make recommendations to the CAB where appropriate to minimize rework. If a change is beyond the contractor's capacity to complete in the assigned development cycle, the contractor shall provide a detailed implementation recommendation and schedule in the Project Plan (Legacy Applications – CSS Web, DITCO Web, DITCO Internet, COPS / FABS, and any other legacy applications) and it will be discussed during the weekly development cycle review meetings. These tasks are assigned to a cycle for development of a specification prior to the implementation cycle. The contractor shall work with Subject Matter Experts to create, and receive approval on, user stories, functional specifications, or technical specifications.

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 t-shirt 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 within the legacy systems, 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 cycle or cycle +1 by the Government depending on the impact to business operations. The contractor shall assist the 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/prevent them. The contractor shall input all actions taken to resolve artifacts into the 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 support 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 deliverables of this task are 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.

Release documentation shall include a work plan with recurring updates, release test plans, release test results, UAT plan with user test scripts. Release notes which include all artifacts with associated problem descriptions, solutions, and deployment instructions. Post release, additional information shall be provided to the Government regarding outstanding actions, risks, or issues so the Government can fully understand the work that has occurred, post release issues, risk, or outstanding actions, and 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 contractor shall provide and maintain a System Operating Manual which includes information sufficient to install, operate, and maintain the legacy systems.

Actual software code shall be installed on the Staging and Production covered systems’ servers and provided as a tagged code segment via the Government managed code repository or delivered on Digital Video Disc (DVD) 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. This task includes developing, updating, and maintaining all covered systems’ user-facing documentation. This documentation shall be rendered and delivered using standard office applications such as Microsoft (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 task requires participation 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 for all user visible artifacts using the artifact management tool (e.g., Jira). These release notes will 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.

The contractor shall manage the fiscal end of day (EOD), end of month (EOM) and end of year (EOY) activities, including but not limited to 1) planning for the duration of the event, 2) managing the EOY participant lists and maintaining communications with participants for awareness, 3) scheduling and administering weekly status meetings, 4) performing database and AdTempus execution of jobs, 5) managing timely database updates, 6) monitoring the completion of EOY tasks, 7) collecting and tracking issues and problems, 8) documenting lessons learned and recording the incorporation of solutions, and 9) reporting weekly statuses and at the conclusion of the event.

6.2 Deliverables:

*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 Technical Lead, PM and COR.

**The legacy software development cycles are typically planned for 4-6 weeks but can vary according to the project assigned. Each development cycle will result in a software release. The Government has final approval regarding the work to be accomplished in each development cycle.

6.2.1. Subtask 1 - Web Applications Support. The contractor shall perform analysis, design, programming, testing, implementation and documentation in support of the DISA Web environments. This will include all sustainment and modernization efforts. The web applications supported are: FPDS-NG Interface, Accounts Payable (AP) Validation, EDMS Import, Financial Tri-Annual Review, Triannual Review, and Contract Close-out. CSS and the supporting applications will be converted to a web-based application or other appropriate solution as part of the Risk Management Framework (RMF) remediation. This includes developing and maintaining applications to support the integration or redesign of the current products and services to enhance dynamic capabilities. The contractor shall be capable of making changes to the content in order to keep the web pages current. The contractor shall provide technical and software development support for DISA’s Business Systems Portfolio Management Office (PMO). This includes developing and maintaining applications to support the integration or redesign of legacy contracting and financial systems which involve transactions between IDEAS, TIBI, FAMIS-WCF, and DISA StoreFront. The contractor shall assist in submitting a Change Request to the SD2 CCB prior to a software release.

The contractor shall serve as the primary System Manager of the web-based server CSS applications to include related modules. Specific modules within CSS are PI, TSI, Admin (Employee/User ID Information and CCI) and the Exception Handler. As requests for changes and enhancements are approved and prioritized by the PSD CAB, the contractor shall design, program, test, and implement these changes. The contractor shall be responsible for updating and maintaining CSS documentation associated with requested changes. The contractor shall be responsible for all customer inquiries and problems associated with the CSS application, related modules, and database structures. Analysis will be accomplished to determine if these issues with the CSS application and related modules is a user error with input of information or a system problem that would require further analysis, and/or software/database changes required to resolve the problem. The contractor shall assist with the manipulation of data values/records within the Oracle databases to maintain data integrity. This subtask results from the need to maintain validation tables, fix user input errors, and/or change data values (e.g., office symbols, reassigning workload from one person to another, and fiscal year record loads). The contractor shall be required to create ad-hoc reports from the oracle database for the purposes of data integrity validation and root cause analysis. In addition, the contractor shall provide a CSS user list on a quarterly basis to DISA for DISA to perform user validation. The contractor shall create and maintain a separate instance of CSS in order to enhance system data security. This instance will be used by PSD/PLA - Defense Capabilities Contracting Office personnel.

The contractor shall perform analysis, design, programming, testing, implementation and documentation in support of the DITCO Web environment. The contractor shall develop and maintain applications to support the integration or redesign of the current products and services of the web and to enhance dynamic capabilities. The contractor shall make changes to the content in order to keep the web pages current. The contractor shall modernize the DITCO intranet and internet websites to eliminate security vulnerabilities, update content, and streamline the user experience. The rebuilt sites shall be configured to have data driven, template-based pages. The updated sites shall be configured to allow the ability to rapidly incorporate new or changed content or functionality. The contractor shall sustain the web pages based on approved requirements.

In order for Enterprise Business applications to become Net-Centric, the contractor shall develop interfaces with external systems using web services software development techniques. The contractor shall develop and/or enhance web and client-server applications to provide DISA executive/senior leaders with the tools necessary to make Software Deployment decisions relating to contracts/orders procured and/or administered by DISA. The information collected from various database sources will provide Key Performance Indicators (KPI) that will be used to help the organization to define and evaluate how successful it is in terms of making progress towards its long-term goals and objectives. The contractor shall coordinate with DBAs and SAs to resolve any performance or operational impacts to the production and test environments. The contractor shall build, document, maintain, and monitor job schedules of all production AdTempus jobs for successful completion at least 3 times daily on regular business days and resolve all errors from a failed or misconfigured AdTempus jobs. The contractor shall perform application tuning and modifications, monitor application logs, create and modify AdTempus batch scripts and jobs at the Government’s request.

The contractor shall be responsible for monitoring and ensuring successful completion of all EOD, EOM, EOY, and bill pay processes, jobs, and schedules. The contractor shall mitigate any issues involving EOD, EOM, EOY, and bill pay activities to minimize the impact to the production environment. The contractor shall design, configure, and deploy fixes to correct the issues. The contractor shall document any found or known issues involving EOD, EOM, EOY, and bill pay activities and implement solutions to correct the issues. This after-action report documentation will be included in the Monthly Status Report stated in subtask 6.1.1. If the issues involving the EOD, EOM, EOY, and bill pay activities are systemic, the contractor shall design, configure, and deploy fixes to correct the systemic issues. Web and Client-Server Applications Support will also include supporting all RMF activities.

The contractor shall provide subject matter expertise to respond and resolve operational problems with the legacy systems during normal duty hours (defined as 0700-1700 Central Standard Time) and outside of duty hours as requested by the COR, PMO, or KO due to an operational event that requires contractor support. If the initial request is done verbally, the Government will follow up with a written confirmation. Operational events may involve outages, end of year activities, and deployment issues to production environments. Outside of duty hours will be billed to the contract under its own independent reimbursable Contract Line Item Number (CLIN) on a level of effort basis from a pre-priced hourly rate on a per hour, per incident basis. The hours billed will not be more than 300 hours per contract year for this subtask 6.2.1 of this PWS. The contractor shall provide a report of all outside of duty hours performed.

6.2.1 Deliverables:

*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 Technical Lead, PM and COR.

**The legacy software development cycles are typically planned for 4-6 weeks but can vary according to the project assigned. Each development cycle will result in a software release. The Government has final approval regarding the work to be accomplished in each development cycle.

6.2.2. Subtask 2 - Mainframe Application Support. The contractor shall perform analysis, design, programming, testing, documentation and implementation on the Mainframe applications. This activity requires IT-II, as authorized access is required to access the production, development, and test environments. COPS and FABS are the two biggest Mainframe applications that require daily production support and development to resolve the root cause of common problems. The contractor shall ensure that the COPS online application is available for users to input accurate and consistent information into the system. The contractor shall provide support to the DVTS background processor. The contractor shall work closely with other contractors and Government personnel on all DVTS activities. Batch applications are used to generate the IOS and other reports. The contractor shall ensure that COPS input transactions (DVTS records) are backed-up and maintained for one year. The contractor shall accomplish updates to COPS records and maintain vendor pricing tables on a monthly basis. The contractor shall modify the process to directly interface with the Contracting-Information Technology (CON-IT) system. Currently, information is manually extracted from CON-IT and sent to COPS via FTP. In addition, the contractor shall ensure that all Customer Billing Communication Service Authorization’s (CSA’s) (with CSA determined carrier codes) are generated as a result of COPS Customer Information Control System (CICS) On-line input by account managers and that the appropriate CLIN is created with the current year Program Management/Subscription Cost. The contractor shall be responsible for updating the database with all out-year contract and subscription pricing and apply these rates to active orders within COPS.

The contractor shall provide analysis and error resolution related to the interface of IDEAS and DVTS transactions with the COPS including resolving all daily DVTS error reports and ensure IOS web service calls are successfully closed out within 3 business days. All updates to COPS are accomplished using the COPS Background Transaction Processor. For IDEAS, this will be accomplished via a data transmission method (i.e., FTP or Middleware) to the DECC Ogden Mainframe batch processes. The contractor shall develop batch programs and Job Control Language (JCL) to validate and manipulate the DVTS transaction. Date and Money fields will need to be converted to packed format. Since IDEAS will be storing as Gregorian (i.e., MM/DD/YYYY), it is necessary to convert all dates to a Julian format. The mainframe has the capability to accomplish this function. Data must be accurate in both systems. It is necessary to provide a feedback loop of transactions that rejected within COPS so that information can be corrected within IDEAS. The contractor shall provide COPS testing support to resolve production support issues between IDEAS and COPS as well as testing support for software releases and hotfixes.

The contractor shall support the biannual and annual reviews of COPS and FABS. This may require the contractor to support any third-party auditors and other contractors.