A14_MR_-_RFI_Attachment_1_-_PWS_IRWIN_1.pdf

INTEGRATED REPORTING OF WILDLAND FIRE INFORMATION (IRWIN) CONTRACT

1. GENERAL INFORMATION

1.1 CAPACITY-BASED CONTRACTING APPROACH

This contract encompasses a broad range of interagency (DOI, USDA, and other wildland fire partners) systems and applications that are hosted in the AWS cloud and integrated with the IRWIN ecosystem. The precise timing, duration, and scope of system enhancements, integrations, and operational needs may fluctuate over the contract period. To account for these evolving requirements, the Government (DOI, USDA, and interagency partners) is employing a capacity-based contract pricing model. This approach provides the flexibility necessary to adapt to dynamic operational, technological, and funding conditions.

The intent of this capacity-based contracting model is to:

A. Accommodate Variability in Software Development and Data Integration Needs

• Address the inherent uncertainty and evolving nature of software development, cloud hosting, and data integration within the IRWIN framework.

• Ensure that IRWIN remains responsive to new system integrations, technological advancements, and agency requirements.

B. Support Agile Development and Interdependent System Coordination

• Facilitate efficient timing between defining application and integration requirements and executing design, development, and testing work.

• Align capacity planning with iterative development cycles, ensuring seamless data exchange and collaboration among interagency fire management systems.

C. Provide Scalability for Cloud Hosting and Development

• Enable surge capacity when demand increases due to emergency response requirements, expanded system integrations, or agency-driven enhancements.

• Allow for scaling down based on funding constraints or reduced operational demands by adjusting contracted cloud personnel, as directed by the Contracting Officer.

This model ensures that the Contractor is not locked into a rigid, exhaustive list of predefined “shall” statements.

Instead, the Contractor will execute work based on evolving business needs, operational goals, and the general scope outlined in this contract, using a capacity-based approach driven by skilled personnel, expertise, and technological capabilities.

The Government (DOI, USDA, and partners) is acquiring capacity to support various IRWIN-related operations, integrations, and enhancements, ensuring that personnel resources align with the complexity and scope of work required. The work will be coordinated and defined during IRWIN’s cloud planning and management processes, in collaboration with IT development teams, data stakeholders, and hosting service providers.

In this context, ‘capacity’ refers to the availability of human resources with the skills, expertise, and experience necessary to execute the work required for IRWIN’s sustained operations, modernization, and integration with interagency fire management systems. The scope defined in this contract outlines the nature of the work expected during the period of performance, allowing IRWIN to remain a flexible, scalable, and mission-critical system for wildland fire management and decision-making.

1.2 INTRODUCTION

The Integrated Reporting of Wildland-Fire Information (IRWIN) system is a comprehensive interagency initiative managed by the Department of the Interior (DOI), Office of Wildland Fire (OWF). The IRWIN system was designed to provide an “end-to-end” fire reporting capability, offering a coordinated process for the collection and dissemination of incident and event data. Historically, basic fire information such as location, size, environmental conditions, and resources were captured in isolated, stand-alone systems. These disparate systems often resulted in outdated and inconsistent data as conditions evolved over the lifecycle of an incident.

The need for a unified and integrated system became evident when different fire management agencies encountered challenges in providing a single authoritative source of information. IRWIN addresses this issue by enabling the interconnection of these systems, allowing for real-time updates and reducing the need for manual data entry. This integration ensures that accurate and timely information is available across all participating agencies, facilitating better decision-making and resource allocation during wildland fire incidents.

The IRWIN system aims to streamline data collection and reporting processes, ensuring timely, accurate, and consistent information across multiple systems. By interconnecting diverse data sources, IRWIN reduces duplication, enhances data accuracy, and provides a comprehensive view of wildland fire incidents.

1.3 Goals of the IRWIN Capability:

• Consistent Reporting of Data: Establishing a standardized method for data entry and reporting to ensure consistency across all systems.

• Reduction of Duplication Entry: Minimizing redundant data entry efforts by automating the data flow between interconnected systems.

• Speed Access to Data: Enhancing the speed at which data is accessed and shared among systems to improve operational efficiency.

• Increase Data Accuracy: Improving the accuracy of data by validating and cross-referencing information from multiple sources.

• Increase Availability of Data: Expanding the availability of data to support various stakeholders in the wildland fire community.

• Identify Authoritative Sources: Defining and using authoritative data sources to ensure the reliability and integrity of the information.

Presently, IRWIN integrates data from six (6) Computer Aided Dispatch (CAD) systems including WildCAD, Integrated Fire Management (IFM), Wildfire Incident Response System (WiRES), FireBeans, and LA County CAD.

Additionally, it interfaces with four (4) other systems: Wildland Fire Decision Support System (WFDSS), FireCode, Emergency Reporting, and SIT-209, as well as 17 additional systems that read data from the IRWIN API. These systems collectively support various functions such as computer-aided dispatch, business decision support, incident management, financial management, situation analysis, weather conditions, public information, and final fire reporting.

1.4 BACKGROUND

IRWIN is an interagency system managed by the DOI’s Office of Wildland Fire (OWF), integrating wildland fire data from numerous sources including federal, state, and local agencies. The interagency community encompasses the USDA Forest Service, DOI Bureau of Land Management (BLM), National Park Service (NPS), U.S. Fish and Wildlife Service (USFWS), Bureau of Indian Affairs (BIA), and local fire managers via the United States Fire Administration (USFA).

This Performance Work Statement (PWS) describes the tasks required to operate, maintain, develop, modernize, and enhance the IRWIN system and its supporting tools. Deployed in May 2014, IRWIN serves as a data integration service based on standardized data identified by the wildland fire community. The system supports business needs by utilizing data from authoritative sources and facilitating a coordinated approach to data management and reporting.

IRWIN comprises a suite of application programming interfaces (APIs) and commercial off-the-shelf (COTS) tools to support its operation and community understanding. Currently, there are two main APIs: one for incidents and one for responding resources. These APIs and tools are hosted in three distinct environments: the IRWIN test environment (TEST), the operational acceptance test environment (OAT), and the production environment (PROD).

With the award of this contract, an additional development environment (DEV) will be established. All development work will be conducted in the IRWIN DEV environment using government-furnished computers by fully credentialed and onboarded vendor personnel.

All IRWIN environments are hosted using an AWS cloud solution managed by a FedRamp broker. These hosting environments are compliant with National Institute of Standards and Technology (NIST) standards and have undergone the assessment and authorization (A&A) process, obtaining an authority to operate (ATO) that is valid through September 2024.

IRWIN facilitates data exchange through a token-based system, with no direct user interface for the IRWIN API.

Users interact with supporting tools managed by the DOI Office of the Chief Information Officer (OCIO) for security and user management. These tools, hosted in IRWIN environments using AWS, require coordinated efforts between the vendor, government project teams, and extended support staff to ensure seamless integration and data integrity.

The IRWIN application effort requires a collaborative and coordinated teaming approach. The collaborative community is made up of the IRWIN extended teams and the IRWIN core team.

The IRWIN extended teams are the project team(s) of the applications exchanging data through IRWIN. The term extended team is used to refer to all application project teams as a whole or to a specific team. When referring to a specific application project team, that application name is used instead of IRWIN. For example, WFDSS extended team or FireCode extended team.

The IRWIN core team is a highly matrixed agile project team directly responsible for operating, maintaining and developing the IRWIN application. The core team is further broken down into a government project team, development team, an implementation team and hosting team.

1. The IRWIN government project team is responsible for engaging the business community and ensuring business needs and requirements are managed and met. The government project team includes extended support staff for security, budget and contracting support.

2. The IRWIN development team is responsible for developing the IRWIN application and supporting tools. This team is also responsible for addressing, managing and maintaining the security protocols and controls around the application layer. The team is made up of a development coordinator, product owner, technical lead, scrum master, database designer, API developer, observer developer and a managed services representative. This contract is to fill the requirements for this area of responsibility.

3. The IRWIN implementation team is accountable for onboarding new systems, as well as developing documentation to support IRWIN orientation to those new systems. They are also responsible for credentialing and stewarding new partners to the appropriate IRWIN product for their use.

4. The IRWIN hosting team is responsible for the cloud infrastructure. They are accountable for deploying, configuring, managing, documenting and maintaining the IRWIN infrastructure and security controls that support the cloud hosting solution.

Because IRWIN core team is a highly matrixed fluid team and some of the roles and responsibilities have and are expected to flex as the need arises in meeting the business requirements defined by the IRWIN business leads.

Refer to the Table 1 for roles and responsibilities for IRWIN core team members as of October 1, 2018. Because IRWIN team employs a highly matrixed team management approach and uses agile software development techniques, roles and responsibilities are adjusted in order to accommodate development and community requirements/needs.

Table 1. IRWIN Core Team Roles and Responsibilities

Role Description

GOVERNMENT PROJECT TEAM

Project Manager (PM) The Project Manager is responsible for IRWIN Extended Team communication, IRWIN Core Team Scope of Work, Level of Effort and Schedule.

Business Lead (BL) The Business Lead is responsible for the initial engagement activities with the IRWIN Extended Teams and later discovery and workflow analysis. The Business Lead creates the business user stories and prioritizes the business and development backlog user stories. A final responsibility is that the Business Lead will provide user story acceptance at the end of an iteration.

DEVELOPMENT TEAM

Development Coordinator (DC) The Development Coordinator is accountable for core development, and the communication between the IRWIN Core Team, Business Lead, Extended Teams and Project Manager.

Product Owner (PO) The Product Owner leads the IRWIN outreach and collaboration efforts by conveying the vision to the teams, outlining work in the Product Backlog, and prioritizing it based on IRWIN business value. The Product Owner also supports the community through documentation (and coordination of artifacts created by the Development & Implementation Teams) in support of understanding of the IRWIN products.

Technical Lead (TL) The Technical Lead is responsible for the IRWIN Prototyping, planning the development user stories per iteration, and the tasking of development user stories. In addition, the Technical Lead will track the daily core IRWIN development tasks.

Scrum Master (SM) The Scrum Master serves as a facilitator for both the Product Owner and the IRWIN Core team. They highlight immediate awareness of blocks on activity and monitor velocity in work item development.

Database Designer (DD) The Database Designer is responsible for the database design and development, including geodatabase schemas, relationships, referential integrity and tuning.

API Developer (AD) The API Developer is responsible for the IRWIN API development user stories, including data validation and authoritative data source enforcement.

Observer Developer (OD) The Observer Developer is responsible for the visualization of the orchestrated information, as well as business functions such as exporting and analytics.

Managed Services Lead (MS) The managed services lead is accountable for the application and application software updates and maintenance which includes deploying builds on the infrastructure upon approval of an RFC.

Cyber Engineer (CE) The cyber engineer is responsible for ensuring the security and compliance of the IRWIN system, aligning with DOI, USDA, NIST, FedRAMP, and FISMA requirements. This role oversees security documentation, risk management, and vulnerability assessments while ensuring all Plans of Action and Milestones (POAMs) are addressed. The Security Lead works closely with the DOI ISSO, Project Manager, System Architects, and Managed Services Lead to implement security controls, manage incident response, and maintain continuous monitoring. Additionally, they coordinate with the Federal Security team to ensure IRWIN meets evolving cybersecurity standards, supports audits, and integrates security best practices into system operations.

IMPLEMENTATION TEAM

Implementation Lead (IL) The Implementation Lead is accountable for onboarding new systems, as well as developing documentation to support understanding of IRWIN for those systems. They are also responsible for the coordination of credentialing and stewarding new participants to the proper product to successfully engage with

IRWIN.

Implementation Technical Analyst

(ITA)

The Implementation Technical Analyst support the adoption of IRWIN by new systems by demonstrating implementation patterns, testing the initial integration and supporting the reengineering activities of systems through sample code and documentation.

Data Architect (DA) The Data Architect is responsible for the IRWIN data mapping and workflows, data hierarchy and documenting authoritative data sources.

1.5 PERSONNEL REQUIREMENTS

Key Personnel Definition

Certain skilled, experienced, professional or technical personnel are essential for accomplishing the work to be performed. These individuals are defined as “Key Personnel” and are those persons whose resumes were submitted and marked by the vendor as “Key Personnel”. No substitutions shall be made of accepted key personnel except for sudden illness or death, or termination of employment. The Government shall accept substitutions only if in compliance with the “Substitution of Key Personnel” provision identified below.

Substitution of Key Personnel

All contractor requests for approval of substitutions hereunder shall be submitted in writing to the COR and the Contracting Officer at least thirty (30) calendar days in advance of the effective date, whenever possible, and shall provide a detailed explanation of the circumstances necessitating the proposed substitution, a complete resume for the proposed substitute, and any other information requested by the Contracting Officer necessary to approve or disapprove the proposed substitution. The COR and Contracting Officer will evaluate such requests and promptly notify the contractor of approval or disapproval in writing.

Contractor Personnel

The contractor shall be responsible for managing and overseeing the activities of all contractor personel as well as subcontractor efforts used in performance of this effort. The contractor shall provide necessary and sufficient personnel to accomplish all the services within the timeframes specified in this contract. Contractor personnel shall be trained, qualified, and certified under the requirements specified in this contract, and be given full knowledge of the requirements of this contract before starting work. The contractor’s management responsibilities shall include all activities necessary to ensure the accomplishment of timely and effective support, performed in accordance with the requirements contained in the PWS.

1.6 CONTRACTOR QUALIFICATIONS

The Contractor must possess the necessary skills and experience, including a deep understanding of wildland fire business processes, data integration, and systems integration.

Key Personnel:

Development Coordinator Oversees core development and ensures communication between teams.

Technical Lead Plans development user stories and tracks daily tasks.

API Developer Responsible for API development, including data validation and authoritative data source enforcement.

Scrum Master Facilitates team activities and monitors development progress.

Database Designer Designs and manages the database, ensuring data integrity and performance.

Observer Developer Develops tools for visualizing and analyzing data.

Managed Services Lead Manages application updates and maintenance.

Data Architect Oversees data mapping, workflows, and authoritative data sources.

Cyber Engineer Ensures security and compliance, manages risks, oversees documentation, and coordinates with stakeholders to implement controls and meet evolving standards.

Implementation Technical Analyst Demonstrating patterns, testing integrations, and aiding reengineering with code and documentation.

Implementation Lead Mapping workflows, defining hierarchy, and documenting authoritative data sources.

1.7 Scope

This Performance Work Statement (PWS) provides for Development, Modernization, Enhancement (DME), Operations and Maintenance (O&M), and Transition/Migration support for the Department of the Interior (DOI) Office of Wildland Fire (OWF) within the scope of the Product Visions for the identified environments/applications in this PWS.

DOI/OWF seek O&M/DME with accompanying security services for systems/applications, providing a structure that is reliable, maintainable, and available (RMA). The approach offers the necessary redundancy and contingency features, as well as state-of-the-art technology enhancements to improve user experience, minimize service disruption, and ensure security. The system(s)/application(s) will have infrastructure, computing, and related services in place to enable the flexible and scalable delivery of environments, processes, and/or algorithms that can be used by wildland fire or natural resource program agencies. The system(s)/application(s) need to be developed and configured so they can be tested and certified by government specialists.

The Contractor shall be directly responsible for ensuring completion of all tasks under this effort. Specific applications or tools associated with this contract include:

• IRWIN and its associated components broad contractual components

Operations and Maintenance (O&M) Sustained functionality, user support, and maintenance to ensure the continuous, reliable operation of the IRWIN system.

Development, Modernization, and Enhancement (DME)

Planning, designing, and implementing new functionalities and improvements to meet future needs and technological advancements.

Transition/Migration Seamless functionality before, during, and after the movement of systems/applications or transitions to new contractors.

1.8 Government Points of Contact

Name Job Title Phone Email

Brandon Green IRWIN Project Manager (Project Manager; COR) (410) 303-3307 bgreen@ios.doi.gov

Kara Stringer IRWIN Business Lead (406) 471-4600 kstringer@ios.doi.gov

1.9 Period of Performance

Period of Performance Phase In Transition Period: Date of Award (6 months) Base Period 12 months Option Period 1 12 months Option Period 2 12 months Option Period 3 12 months Option Period 4 12 months

1.10 Optional Additional Needs/Requirements

Potential for additional staffing to support increased DME/O&M support (e.g., cloud architecture, system/database/network administration). If exercised, additional needs will be billed at the vendor base labor hour category/rate. If long-term support is necessary for full-time FTE, the increased staffing will be incorporated into upcoming/future Option Periods at a fixed cost; otherwise, it will continue at the agreed labor hour category/rate.

1.11 Place of Performance

The Service Provider team will be located on-site at OWF, NIFC, or virtual. Limited Key Personnel space may be provided if proposed. The Service Provider shall provide its own equipment, software, communications, supplies, and other furnishings for their personnel as necessary to perform the contract that are not otherwise listed under the Government Furnished Property section.

1.12 Travel

Travel and ODCs will be reimbursed based on actual costs with a Not To Exceed (NTE) value. All travel arrangements must be pre-approved by the COR and billed in accordance with FAR Part 31.

Typical Travel Requirements:

Discovery Sessions 2-6 times per year (2 personnel each). These sessions are essential for understanding the requirements and capabilities of new systems and planning their integration into IRWIN.

Strategic Planning Session 1 annually (2 personnel). Strategic planning sessions support long-term planning and decision-making, ensuring that the IRWIN system continues to meet evolving needs.

Integration Testing 1 annually (4 personnel). Integration testing sessions ensure that all systems work together seamlessly, identifying and resolving any issues before deployment.

1.13 Property

The Service Provider is expected to provide all resources necessary to facilitate successful off-site development for this effort. The Service Provider shall also identify in their order proposal all resources necessary for completion of this work, which the OWF is expected to provide or reimburse, including Government Furnished Property and/or Contractor-Acquired Property. Contractor Property used to perform the proposed services should be identified for evaluation purposes but shall not be directly reimbursed and is expected to be covered by the labor hour rate.

2. DESCRIPTION OF SERVICES

All released parts of the application(s) will be supported with O&M concurrently with active DME. The Service Provider must provide a strategy to ensure sufficient resources are available to deliver corrective, preventive, and adaptive maintenance concurrently and without degrading development team velocity.

2.1 Program and Project Management Support

The Service Provider shall be responsible for Program and Project Management support activities for their technical staff as well as in support of all activities contributing to successful contract performance. These tasks may include but are not limited to:

a) Support development and maintenance of product visions/roadmaps, release plans, product/sprint backlogs, sprint planning/reviews/retrospectives, velocity determination and other Agile products.

b) Develop and maintain critical milestone schedules that document the most important schedule issues for management attention.

c) Provide recommendations to address any schedule or cost variance associated with project plans.

d) Support the COR in analysis, classification, and prioritization of reported items (e.g., Jira).

e) Support issues management and tracking (e.g., Jira).

f) Support change management and risk management activities.

g) Coordinate and plan meetings, where appropriate, including program management reviews, and sprint/design reviews.

h) Provide project progress reports and other management documents as specified in project deliverables and as required by the government management.

i) Ensure the integration and synergy between interconnecting system(s) and provide recommendations for simplification of interconnections as they arise.

j) Facilitate adherence to all departmental and bureau policy.

k) Provide status reporting in a format and timing agreed upon by the COR.

l) Report on backlog issue reviews, analysis, estimation, solution design and time estimating as request by

COR (e.g., Jira).

m) Coordinate with the Government regarding system(s) outages and hardware/firmware or interface issues that come to their attention.

n) Create and maintain development information site(s) (e.g., Google Site, Google Drive, or MS SharePoint

Site); develop, design, and create page content. Site design and content must be approved by OWF.

2.2 Development

The Service Provider shall analyze, design, develop, configure, test, and release business applications by applying iterative processes utilizing a form of Agile, and/or Hybrid centered methodology (greater emphasis on Agile) which promotes for short incremental time boxed development and a frequent release capability to the maximum extent practicable within resource constraints. The objective of this development approach is to reduce risk, cost, and schedule and improve product quality through increased emphasis on communication, customer collaboration, faster delivery of working code, and an ability to respond and adapt to change. As a general rule this requires breaking up software development into smaller and manageable iterations (sprints) each of which shall produce defined functionality. Yet with this, there will be a larger overall sprint cycle (annual) for those items that pose a larger impact to the broader community requiring them to develop on their systems. The process shall include a communication and collaboration approach which enhances the probability of successfully delivering an application that meets end user objectives. The process shall directly involve product owner(s) and/or end user collaboration to a high degree into the sprint development cycles to ensure (1) delivered software produces immediate customer satisfaction, (2) delivered software is usable and does not contain unusable or unwanted features and (3) process provides maximum capability to respond to change with minimal impact on development objectives.

2.2.1. Product Vision.

Product vision describes high-level requirements for the functionality of the system(s) and how the application(s) will support the organization (who, what, where, when, why, how). Product roadmap level information is intended to map out the high-level requirements for the system(s). This information describes areas such as compatibility restrictions, system(s) availability, initial module/release objectives, business process models for automation, etc. All available requirements documents are provided via and Attachment…and require validation by the Service Provider to provide product vision context.

The intent of this PWS is to provide a consistent/repeatable velocity to the government sufficient to be able to accommodate a combination of environment/application(s) stabilization and operations and maintenance activities.

The current workload velocity and anticipated transition workload has been accomplished at the equivalent of 1 full time developer, developer, half time business analyst, and ancillary project management support (see 1.4 for potential/addition workload needs).

2.2.2. Validation and Planning.

The Service Provider shall propose the approach and methods to achieve the scope of this PWS and duration for an initial period of Validation and Planning. The objectives of O&M, DME, and transition/migration of this effort is to improve outcomes by placing the project in a position to better plan and execute activities as well as improve our ability to communicate and manage project expectations. To accomplish this, the following deliverables must be accomplished within this period.

2.2.2.1. Product Backlog. The Service Provider team shall decompose available Government furnished business requirements documents and deliver the initial Product Backlog using themes, epics, and/or large user stories. This effort is not necessarily intended to create actionable decomposed user stories for development. This level of decomposition will be handled within the agile development process. However, the Product Backlog shall be minimally sufficient to roughly estimate and produce a Product Roadmap and a Release Plan to be delivered at the end of the Validation and Planning period. This effort will involve direct interaction with the Product Owner and user community as needed to successfully complete the objectives of this work. This effort may include meetings, workshops, and other collaborative exercises required for successfully completing the activity as outlined in the Service Providers proposal. The Service Provider will propose the solution to include schedule, level of effort, and assumptions necessary for the successful completion. The business requirements provided are considered current and accurate therefore collaboration should be primarily focused on areas that require additional clarification in order to provide the best possible deliverable and overall business value within the allotted time frame and to achieve the stated objectives. Excessive or unproductive meetings which involve a rehashing reasonably well-defined requirements is not the objective. This effort shall also produce an approved Sprint Backlog for the first sprint. Acceptance criteria and/or definition of done is required for the first sprint only. This level of story definition is not required for subsequent sprints and instead is completed as part of the backlog grooming and sprint planning process.

2.2.2.2. Initiation Activities. The Service Provider shall use this time kick off the project with DOI so as to establish clear roles and expectations within the total team. In addition, the Service Provider shall provide (host) formal Agile Development training with DOI (e.g., PMs, POs, Key Business Leads, Key SMEs) and Service Provider key members (e.g., PM, SM, BA(s), Lead Developer(s)) to be held with a professional provider for this type of training. Training may be customized for the situation. The training is expected to baseline the whole teams understanding of roles and responsibilities within the agile (hybrid) process moving forward (experienced and inexperienced members) with the objective of facilitating an effective team.

This time should also be used to complete personnel onboarding and to work on any other dependencies or initial activities which might prevent the success of Sprint 1 including initial purchasing and implementation of development tools, platforms, and infrastructure.

2.2.2.3. Product Roadmap and Release Plan. The Service Provider shall create and maintain a Product Roadmap and Release Plan with the government and is responsible for keeping it current with ongoing development and changing requirements. The documents shall logically group functionality into potential major release points and estimate the potential schedule of those releases using current system understanding of estimates and assumptions. Completed review and update of these documents shall be delivered no less than quarterly, or at the request of the COR, and shall represent the evolving understanding of the developed system(s). The Service Provider may combine these documents or use other formats as proposed in the Service Providers methodology without changing the intent of these documents.

2.2.2.4. Styles Guide. The Service Provider shall draft a Styles Guide. The DOI is a highly decentralized organization with diverse stakeholder groups that will be assisting the Product Owner in delivering functionality that meets the requirements for a national system(s). To ensure the development process begins with and is able to maintain consistent user expectation the Service Provider shall create a styles guide document. This document will provide the users insight as to how the screens will look and work such as buttons, error messages, on-line help, search features, etc. This document will facilitate clear up-front expectations in the development process so that developers will have a better understanding of what the user’s want and to minimize future change requests.

2.2.2.5. Coding Standards. In addition to a styles guide, the Service Provider shall develop coding standards guide for developers so as to provide consistency in development. Initial Design.

The Service Provider shall create initial system(s) and architecture design artifacts and provide an initial design review to the DOI for approval.

2.2.3. Backlog Refinement and Sprint Planning

2.2.3.1. Product Backlog. The Service Provider shall effectively communicate with DOI to gain a complete understanding of the product vision and to validate the current business requirements (attachments…) in the creation of agile software development artifacts. The Service Provider shall maintain the product backlog containing functional descriptions (e.g., “user stories”) feeding from the product vision and product roadmap in direct collaboration with the Product Owner and stakeholders. The backlog shall contain the prioritized list of features which describe the technical functionality of the system(s). The backlog will be used for tracking and estimating the development effort. Estimation shall include considerations of complexity, risk, implementation, deployment, and interdependencies. The DOI shall have final approval authority over all backlog content and prioritization. This backlog will feed into the iterative development cycle and act as a living document used to track the status of all identified functionality delivered or to be delivered. This deliverable shall be approved prior to entering into the first development cycle. It is also expected that the process of creating and updating the product or feature backlog is continuous and should not impact the smooth transition between and execution of development cycles. This backlog shall be made available to the DOI Project Manager and Product Owner for review in real time.

2.2.3.2. Refinement. The Service Provider shall propose the specific approach or methodology for creating and maintaining a successful backlog with DOI. The approach shall at a minimum address backlog creation, story decomposition, feature identification and product team communication, feature use case or story point effort estimation, prioritization, quality assurance, testing, user acceptance, and establishment/commitment of iterative functionality (working code); within the limitations identified in this document.

2.2.3.3. Sprint Planning. Planning for the first sprint will be performed and priced as part of initial Validation and Planning activities. Subsequent Sprint Planning will be performed prior to beginning an additional sprint in accordance with this paragraph as part of the development cycles. The Service Provider shall complete Sprint planning with the DOI prior to beginning development which involves the approval of the Sprint prior to entering into development.

The planning process will define the delivered functionality to be provided for each development cycle. Planning shall include consideration in mitigating schedule conflicts and maximizing availability of resources for successful completion of each iterative development cycle. Development cycle shall be based on user stories/feature descriptions selected by DOI in collaboration with the Service Provider. Each backlog item shall also include acceptance criteria and/or a “Definition of Done” (DoD) to pre-define the successful completion of the feature and shall be agreed on by the Product Owner/Product Team prior to development. The Service Provider shall be evaluated for their ability to successfully execute each sprint.

Service Provider shall accurately estimate and efficiently manage Sprint Planning work.

2.2.4. Development Cycle

2.2.4.1. Sprints shall be proposed as three- or four-week fixed time boxed iterations that deliver working code as defined in Sprint Planning. DOI has been successful with three-week sprints. Sprint length and team structure shall be proposed based on company best practice approach and balanced within the constraints of allocated resources.

2.2.4.2. The Service Provider shall design and develop identified Sprint functionality. The Product Owner may be involved with this process to facilitate seamless development to the maximum extent practicable by providing quick feedback to developers on business requirements and intent of product features. This feedback is not intended to create any new functionality within the sprint or development cycle, but to clarify feature questions when they arise. All new features and/or changes to functionality should be placed back into the product backlog for estimation, prioritization, and sprint planning.

2.2.4.3. In maintaining best practices of Agile development, the Service Provider should plan to host frequent short duration meetings during the Sprint cycle to maximize effectiveness of daily activities and to communicate roadblocks to successful development effort to the DOI Project Manager and Product Owner.

2.2.4.4. The Service Provider shall provide an approach to Pre-Functional Quality Testing (Pre-FQT) and/or Quality Assurance based testing to be accomplished within each sprint cycle to ensure product functionality meets end user expectations, and that the new code is not introducing any apparent errors. Automated testing shall be used by the Service Provider and in development. Automated testing shall be accomplished for each sprint. Testing tools shall be made available to DOI in the Service Providers development and test environment for use and/or verification of successful regression testing. Overall, the testing approach should provide TDD both behind scene (IT) and user side (product/FQT). Any changes or bugs identified shall be placed into the product backlog for estimation, prioritization, and sprint planning. Sprint code shall be made available to users in test with the strategy of increasing visibility, enhancing user involvement in testing early on, improving buy in, and reducing remediation or enhancement requests at the final FQT stage of a release.

2.2.4.5. A Sprint review shall be conducted at the end of each Sprint. The review shall include a product demonstration. Identification of needed changes, modifications, or additions should be fed back into the product backlog for estimation, prioritization, and sprint planning.

2.2.4.6. The Service Provider should hold a Sprint Retrospective designed at improving their Sprint cycle deliverables. The DOI Product Owner and Project Manager may also help to provide assistance in removing barriers to optimization of success.

2.2.4.7. The Service Provider shall complete documentation deliverables identified in this call incrementally during Sprint cycles as opposed to waiting until the very end of a release. The intent is to ensure all documentation is priced and completed as part of the sprint process and does not manifest itself in the form of excessive release costs. Incremental documentation should simplify and shorten the cost and delivery of required release documentation.

2.2.4.8. The Service Provider shall propose an initial estimated Sprint Velocity which represents the total number of story points expected to be completed per sprint based on the proposed team size and composition. Service Provider shall include both minimum and target velocity objectives. It is understood that in agile development that this is considered a subjective and potentially fluctuating measure based on each team. Therefore, this will only be evaluated to ensure the Service Provider has a realistic understanding of the proposed team size and composition as it relates to a reasonable measure of achievable and repeatable velocity.

2.2.4.9. To ensure development speed is weighed against development efficiency, the Service Provider shall propose a Development Efficiency Factor. This metric is calculated as the percentage of remediation completed in comparison to total development (e.g., 10 story points of remediation per 50 story points completed in a sprint = 20%). This metric will be considered as cumulative throughout development for performance measurement purposes, however the Service Providers ability to successfully capture and spread-out remediation over each sprint will be considered in the qualitative evaluations of performance. The Sprint Efficiency Factor will be part of the quality metrics the government will use to assess the efficiency of development.

2.2.4.10. A Sprint Report will be provided after completion of each sprint. A sprint report should include at a minimum information on the stories and story points developed, total cost of development, total cost per story point, and ticket categorization metrics including both sprint and cumulative percentage of remediation.

2.2.5. Product Release

2.2.5.1. Service Provider shall support all activities associated with security, vulnerabilities, patching, analysis, testing, documentation, review, and other activities required for successful product release(s).

2.2.5.2. The Service Provider shall conduct a review with the DOI prior to each release. Service Provider shall provide complete user testing and analysis support for the release. Final acceptance for the overall product and release is contingent upon the acceptance of the Final Operation Baseline Release Report (OBRR) and Formal Qualification Testing (FQT) which shall incorporate all of the associated system(s) functionality identified in the specifications for release. The Service Provider shall support the DOI test team in user acceptance. Release testing is required in addition to the Sprint review demonstration provided to the Product Team.

2.2.5.3. Service Provider shall conduct security (vulnerability management and patching), stress, and performance testing prior to release.

2.2.5.4. Service Provider shall provide implementation support and shall be completed in direct coordination with the Implementation team. This support includes release deployment, initial training, initial training materials, change management support, and communications support commensurate to the complexity of the deliverables.

2.2.5.5. Service Provider shall ensure all applicable documentation is delivered for each release.

Complete documentation deliverables are defined in section 3.

2.2.5.6. Service Provider shall provide all minimally acceptable initial training for each release with the intent on delivering development quickly and efficiently. Training and training materials are expected to be improved over time within the O&M process.

2.2.6. Other Support

2.2.6.1. If requested, the Service Provider shall propose communication resources for successful collaboration with DOI as applicable to the approach. Communication resources shall include voice, video, and/or online collaboration tools necessary for project success.

2.2.6.2. If requested, the Service Provider shall propose a development approach which includes development resources necessary to successfully conduct off-site development activities. This may include off-site localized code development so long as the approach allows for the frequent integration or continuous integration of code back into the DOI environment for backup and security purposes.

2.2.6.3. If requested, the Service Provider shall provide DOI an off-site development and test environment resources which mirrors DOI production environment. The Service Provider shall create and maintain test data for testing not otherwise provided or publicly available. All other development tools necessary for collection of business requirements and completion of work shall be supplied as well as part of the cost of development services provided. Service Provider shall propose a strategy for checking in code to DOI on a daily basis to ensure DOI owns, controls, and protects the most current code base on-site.

2.2.6.4. If requested, the Service Provider shall be responsible for developing and maintaining reports leveraging DOI’s Oracle Business Intelligence (OBI) Enterprise Edition investment.

Reporting requirements may include both Repository Data Models (RPD) and BI Publisher requirements. Requirements may include both seamless embedded reports within the application(s) and reporting with the OBIEE dashboard tool. DOI has a core support team which provides overall support for the OBI application(s), maintains environments including MUDE development environments for national application developers, provides limited expert Tier 3 advisory support, and includes Quality Assurance support in the review and approval of changes for promotion to the production server on a weekly basis.

2.3 The Contractor shall provide on-site and remote consulting support to collaboratively design, develop, modernize, and enhance IRWIN to meet the interagency wildland fire community’s needs. Development tasks include but are not limited to:

2.3 Responsibilities Table (Table 2.1)

Responsibilities Annual Release Cadence Facilitating discovery sessions with candidate systems, developing prototypes, performing integration testing, and managing deployment. This structured approach ensures that new features and enhancements are developed, tested, and deployed systematically.

Discovery Sessions Conducting collaborative meetings to understand external systems’ functionality and workflows, document current and future workflows, explore business and data logic, identify authoritative data, and plan integration. These sessions are critical for identifying integration points and ensuring that new systems can seamlessly connect to

IRWIN.

Prototype Development Creating prototypes as necessary to validate integration approaches. Prototypes help identify potential issues early in the development process and allow for iterative improvements.

Data Contracts Defining data contracts based on minimum data input requirements. Data contracts ensure that all integrated systems adhere to the same data standards and protocols, facilitating smooth data exchange.

Validation Logic Implementing validation logic and authoritative data source logic into APIs. This ensures that all data entering the IRWIN system is accurate, consistent, and meets defined standards.

Integration Testing Supporting annual integration testing, documenting test scenarios, facilitating testing, and updating code as needed based on testing outcomes. Integration testing ensures that all system components work together as expected and that any issues are identified and resolved before deployment.

IRWIN Tools and Apps:

User Admin Capabilities Developing and validating capabilities for user admin roles to override validation. This provides administrators with the flexibility to manage exceptions and ensure data integrity.

Data Steward Interfaces Developing interfaces for data steward roles to investigate data collisions. Data stewards play a critical role in maintaining data quality, and these interfaces provide the tools they need to resolve data issues effectively.

Optimal Data Storage Recommending optimal data storage mechanisms to enhance performance. This involves evaluating storage options, optimizing data retrieval, and ensuring that the storage architecture supports the system’s performance requirements.

2.4 Operations & Maintenance Support

As part of the O&M process, the Service Provider shall be responsible for planning for and delivering training to system(s) administrators. While initial development release training is expected to be minimally viable for the purpose of conducting an efficient release process, O&M training materials and events are expected to mature and become higher quality over time. If requested, the service provider shall maintain a training plan to support this ongoing and maturing training strategy. DOI will provide subject matter expertise support to assist in the creation and delivery of this training. The service provider is responsible for ensuring the wildfire reporting module remains functional for use while new module(s) development is happening.

O&M tasks involve inheriting and utilizing the IRWIN API code and supporting tools from the incumbent vendor.

The IRWIN API is built using Esri ArcGIS server with a SQL server database. The support tools are based on Esri ArcGIS Online (AGOL) architecture.

2.4 O&M Tasks Table (Table 2.2)

O&M tasks include but are not limited to:

Security Scans: Conducting regular scans of the IRWIN API and supporting tools for potential security gaps.

Documentation Maintenance Maintaining and updating documentation that supports the

IRWIN API and tools.

Code Documentation Ensuring that code documentation for the IRWIN API and supporting tools is comprehensive and up-to-date.

Annual Documentation Providing annual documentation, including testing management plans, project plans, release management plans, and integration specifications.

Data Standards Support Supporting the IRWIN implementation team in documenting data standards and mapping for IRWIN operations.

Hosting Partner Guidance Providing guidance to the hosting partner for software updates, system code enhancements, and infrastructure management.

Code Updates…