2026-0085 Support NIRIS Development (NS) - THU 16… at EMW · The Hague

Note that some required qualifications have changed, These have been highlighted in the Requirements section.

Previously proposed candidates were non-compliant for the following reasons:

• Following technical evaluation against the mandatory selection criteria, the candidate does not meet the requirement of at least 5 years of professional experience in software development; the submitted CV evidences professional experience from 2022 onwards (approximately three to four years), below the mandatory threshold.
• Following technical evaluation against the mandatory selection criteria, the candidate does not meet the requirement of at least 3 years of professional experience in Java-based software development, including modern frameworks and backend service development; the submitted CV evidences an extensive career focused almost entirely on C#/.NET, with only a single incidental reference to Java (circa 2008) that falls well short of this threshold.
• The CV was assessed as compliant with the mandatory screening criteria. However, the subsequent technical interview did not confirm the required proficiency in Angular-based front-end development. The SOW mandates at least 2 years of experience with TypeScript and/or Angular-based front-end development; the interview assessment identified gaps in foundational Angular concepts, and the demonstrated depth in this area was assessed as inconsistent with the level of seniority and independent delivery capability required for the position.
• This candidate does not meet the minimum requirement of five years' experience as a full-stack developer.
• The candidate is an infrastructure engineer / Linux administrator, while the role requires a software developer with full-stack Java/backend, web frontend, integration, DevOps, testing, and interoperability experience.

BIDDING INSTRUCTIONS

Bidders shall submit a proposal (all four parts in one document) clearly providing the following information:

a. Cover page with the following information: company name; name(s) of assigned contractor personnel; role(s) and responsibilities assigned to each profiled contractor personnel.

b. Evidence of successfully delivering one to three projects of similar scope to the statement of work within the last five years. Each evidence shall demonstrate proof of performance and be comparable in size and scope to the requirements of this role. Additionally, ensure to include a detailed case study that highlights the Purpose, Objective, Output and Outcome (PO3) mentioned in Annex C. Evidence shall display the ability to manage and deliver standard conformance criteria and test reference components for NIRIS by following customer requirements.

c. CVs of the proposed contractor personnel for the project.

d. Detailed effort estimation (exclusively provided for evaluation purposes) covering the following: A breakdown of estimated effort per work package expressed in FTE, where 1 FTE represents one full-time resource working one standard working day (7.6 hours).

Deadline Date: Thursday 16 July 2026

Requirement: Support NIRIS Development

Location: Remote, with occasional on-site work at NCIA The Hague (NLD)

Period of Performance: 24 August 2026 – 31 December 2026

Required Security Clearance: NATO Secret

Introduction

The NATO Information and Communication Agency (NCIA) located in The Hague, The Netherlands, is the Interoperability Assurance Authority for NATO.

In light of this responsibility, the C2 Service Centre is looking for a service contract which can provide NCIA with supporting the continued development, maintenance, and evolution of the Networked Interoperable Real-Time Information Services (NIRIS) software.

Objectives

The list below defines the overarching objectives of the engagement and establishes the intended outcomes that the Contractor is expected to achieve through the delivery of the different work packages described in this document. These objectives serve as the guiding principles against which all deliverables shall be measured. The Contractor is expected to align their approach, methodology, and resource planning with these objectives throughout the duration of the engagement.

Under the direction and guidance of the Solution Architect, Service Delivery Manager, Test Manager, and Project Manager, the services to be provided are related to the development, update, maintenance, and testing of NIRIS software modules. It is envisioned that these services shall be provided by one experienced software developer.

a. Develop, update, and maintain NIRIS software modules in accordance with agreed requirements, priorities, technical direction, and project planning.

b. Develop and update Java software components supporting the continued evolution and sustainment of the NIRIS software baseline.

c. Support the full software development lifecycle of NIRIS, including analysis, design, implementation, integration, testing, defect resolution, and documentation.

d. Develop and conduct unit testing and automated testing of software components to support software quality, maintainability, and regression testing.

e. Support integration and verification activities to ensure that developed or updated software components operate correctly within the wider NIRIS system.

f. Analyse, investigate, and resolve software defects, technical issues, and implementation gaps identified during development, testing, integration, or operational support activities.

g. Develop, update, and maintain software documentation, including technical documentation, design information, test-related documentation, and other project deliverables as required.

h. Contribute to virtual and in-person meetings, reviews, planning sessions, technical discussions, and coordination activities with NCIA stakeholders and project team members.

i. Ensure that all developed, updated, and maintained software components and associated deliverables comply with applicable NCIA development standards, quality requirements, configuration management practices, and agreed project procedures.

j. Update and expand the produced software components and documentation as necessary to accommodate new, revised, or emerging requirements throughout the duration of the engagement.

Scope of Work

The Contractor shall provide the following deliverables classified per service:

A. Service: NIRIS baseline software development, maintenance, release preparation, and Java technology uplift

Deliverable: Updated, maintained, and release-ready NIRIS software baseline aligned with supported Java LTS releases.

Output: Updated, maintained, improved, and release-prepared NIRIS software modules delivered in accordance with agreed requirements, assigned work items, technical guidance, project priorities, release planning, and supported Java Long-Term Support (LTS) runtime requirements. This includes software development, defect correction, stabilization, integration into the relevant NIRIS baseline or release branch, and Java module updates, refactoring, or uplift where required to maintain compatibility with the agreed Java LTS version used by NIRIS.

The deliverable also includes the implementation or integration of agreed functional enhancements within the NIRIS baseline, including CESMO integration and historic track data capabilities, where included in the agreed release scope. For the historic track data capability, this includes enabling users to receive a potentially filtered set of tracks read and processed from storage where NIRIS recordings have previously been saved. The existing RTS subscription mechanism and corresponding user interface shall be enhanced, where required, to support these data sources and to allow filtering based on agreed parameters such as source name, time interval, geolocation, and track number.

Outcome: The NIRIS software baseline remains functional, maintainable, secure, stable, and aligned with the agreed NIRIS roadmap and planned releases, including NIRIS 4.7 and NIRIS 4.8. The deliverable strengthens NIRIS interoperability and operational utility by enabling agreed enhancements such as CESMO integration and historic track data access. This supports both real-time and post-event operational analysis, improves the ability to exchange and consume relevant track information, and increases the value of NIRIS as a data-centric interoperability service. The baseline is prepared for integration, testing, acceptance, and release, while reducing technology obsolescence risk through continued alignment with supported Java runtime versions.

Acceptance criteria:

• Assigned software development, maintenance, uplift, defect correction, and release-related tasks are completed in accordance with agreed requirements, priorities, sprint planning, release scope, or work package timeframe.
• Updated software modules are implemented in line with the agreed technical design, coding standards, configuration management practices, and project guidance.
• Software changes are committed, reviewed, and made available in the agreed configuration management environment.
• Delivered software changes are integrated, or made suitable for integration, into the relevant NIRIS development, baseline, or release branch.
• Implemented changes support the functional and technical objectives of the planned NIRIS baseline or release.
• NIRIS Java modules are reviewed and updated where required for compatibility with the agreed Java LTS version.
• Deprecated, obsolete, or incompatible Java constructs are identified and addressed where applicable.
• Updated modules compile, build, and execute successfully in the agreed development and test environments.
• Implemented changes do not introduce known critical or high-severity defects.
• Development support is provided for defect correction, stabilization, integration, and release preparation activities.
• Release-related technical inputs are provided when required.
• Changes take into account the expected support timelines of both the NIRIS baseline and the Java runtime.

KPIs: Task Completion Rate – percentage of assigned development tasks completed within the agreed sprint, release, or work package timeframe; target ≥ 90%. Code Review Acceptance Rate – percentage of submitted software changes accepted without major rework; target ≥ 90%.

B. Service: Unit testing, automated testing, and software verification support

Deliverable: NIRIS unit and automated test updates.

Output: Unit tests and automated tests developed, updated, or maintained to verify implemented software changes and support regression testing of NIRIS software components.

Outcome: Improved software quality and maintainability through repeatable testing, early defect detection, and strengthened regression test coverage.

Acceptance criteria:

• Unit tests are developed or updated for newly implemented or modified software components where applicable.
• Automated tests are developed or updated to support regression testing of relevant NIRIS functionality.
• Tests are executable in the agreed development, build, or test environment.
• Test results are documented or made available through the agreed tooling.
• Failed tests are analysed and corrected or documented for follow-up.

KPIs: Test Coverage for Delivered Changes – percentage of delivered software changes covered by unit and/or automated tests where technically applicable; target ≥ 85%. Automated Test Execution Success Rate – percentage of automated tests executed successfully after implementation; target ≥ 90%.

C. Service: NIRIS logging and troubleshooting improvements

Deliverable: Enhanced NIRIS logging functionality.

Output: Updated and enhanced NIRIS logging functionality delivered in accordance with agreed requirements, assigned work items, technical guidance, and project priorities. This includes improvements to logging configuration, logging visibility, filtering, endpoint-specific logging, stack trace handling, log compression, logging framework migration where required, and related software corrections or enhancements. The deliverable shall support improved logging per port, endpoint, interface, or relevant NIRIS component, where technically applicable, and shall provide improved mechanisms for filtering, viewing, managing, and analysing NIRIS logs during development, testing, troubleshooting, and operational support activities.

Outcome: NIRIS maintainability, troubleshooting capability, operational support, and runtime behaviour analysis are improved. The enhanced logging capability enables developers, testers, administrators, and support personnel to identify issues more efficiently, isolate failures more accurately, and reduce the time required to investigate defects, interface issues, runtime errors, and operational incidents. The deliverable contributes to improved serviceability of the NIRIS baseline and supports more efficient defect correction, stabilization, integration, testing, and release preparation activities.

Acceptance criteria:

• Assigned logging-related development, maintenance, correction, and enhancement tasks are completed in accordance with agreed requirements, priorities, sprint planning, release scope, or work package timeframe.
• Updated logging functionality is implemented in line with the agreed technical design, coding standards, configuration management practices, and project guidance.
• Software changes are committed, reviewed, and made available in the agreed configuration management environment.
• Logging improvements are integrated, or made suitable for integration, into the relevant NIRIS development, baseline, or release branch.
• Logging can be configured or applied at the agreed level of granularity, such as port, endpoint, interface, component, or service, where technically applicable.
• Logging filters are implemented or improved to allow more efficient identification and analysis of relevant log entries.
• Stack traces are handled in a more user-friendly and operationally manageable way, including collapse, grouping, or improved display where included in the agreed scope.
• Updated modules compile, build, and execute successfully in the agreed development and test environments.
• Relevant technical or operational documentation is updated where the logging functionality, configuration, or behaviour has changed.

KPIs: Task Completion Rate – percentage of assigned logging-related tasks completed within the agreed sprint, release, or work package timeframe; target ≥ 90%. Code Review Acceptance Rate – percentage of submitted logging-related software changes accepted without major rework; target ≥ 90%.

D. Service: NIRIS interface and interoperability support

Deliverable: Updated NIRIS interface and interoperability support.

Output: Updated, maintained, and improved NIRIS interface and interoperability-related software components delivered in accordance with agreed requirements, assigned work items, technical guidance, project priorities, and planned interoperability activities. This deliverable groups work related to supported standards, data providers, data consumers, external interfaces, and interoperability test events. It includes corrections, enhancements, configuration support, integration support, and test-event support for agreed NIRIS interfaces and interoperability capabilities. This may include, where included in the agreed scope: support for interfaces with data providers and consumers; Link 16 / JREAP; OTH-Gold; DIS; VMF; AIS and other agreed formats or standards; OANT/SMAQ integration configuration; analyser limit issues; interoperability testing; CWIX-related test support; TDLITS-related test support; INTEND-related test support.

Outcome: NIRIS remains interoperable with agreed external systems, data providers, data consumers, and NATO interoperability testing environments. The deliverable supports continued operational relevance of NIRIS as an interoperability service by maintaining and improving its ability to exchange, process, transform, and disseminate information across agreed standards, systems, interfaces, and operational communities. It also supports validation of NIRIS capabilities during interoperability events, customer engagements, and test activities, contributing to increased confidence in the NIRIS baseline, its supported interfaces, and its readiness for operational use.

Acceptance criteria:

• Assigned interface, interoperability, configuration, correction, enhancement, and test-support tasks are completed in accordance with agreed requirements, priorities, sprint planning, release scope, test-event planning, or work package timeframe.
• Updated interface and interoperability-related software components are implemented in line with the agreed technical design, coding standards, configuration management practices, and project guidance.
• Software changes are committed, reviewed, and made available in the agreed configuration management environment.
• Delivered changes are integrated, or made suitable for integration, into the relevant NIRIS development, baseline, or release branch.
• Implemented changes support the agreed provider, consumer, interface, format, protocol, or interoperability objectives.
• Interface-related changes are aligned with agreed interface control documents, standards, configuration requirements, or test-event requirements where applicable.
• Support is provided for agreed standards and formats, such as Link 16 / JREAP, OTH-Gold, DIS, VMF, AIS, or other agreed NIRIS-supported interfaces, where included in the agreed scope.
• OANT/SMAQ-related configuration or analyser limit issues are addressed where included in the agreed scope.
• Support is provided for agreed interoperability events or activities, including CWIX, TDLITS, INTEND, or customer visit test support, where applicable.
• Interface and interoperability changes are tested or made ready for testing in the agreed development, integration, or test environment.
• Implemented changes do not introduce known critical or high-severity defects.
• Updated modules compile, build, and execute successfully in the agreed development and test environments.
• Relevant interface, configuration, test, or release-related technical inputs are provided when required.
• Identified interoperability issues are analysed, corrected, documented, or escalated in accordance with agreed project guidance.

KPIs: Task Completion Rate – percentage of assigned interface and interoperability-related tasks completed within the agreed sprint, release, event-support, or work package timeframe; target ≥ 90%. Code Review Acceptance Rate – percentage of submitted interface or interoperability-related software changes accepted without major rework; target ≥ 90%.

E. Service: NIRIS documentation maintenance

Deliverable: Updated NIRIS software documentation set.

Output: Updated NIRIS software documentation set reflecting implemented software changes, configuration changes, interface updates, test support functionality, release-related updates, and operational impacts. This includes maintenance and update of agreed NIRIS documentation, such as user manuals, governance documentation, internal technical documentation, interface documentation, test documentation, release-related documentation, and other software or operational documentation required to support development, testing, integration, sustainment, governance, and operational use. Documentation updates shall be prepared in accordance with agreed templates, standards, review processes, configuration management practices, and release or project timelines.

Outcome: NIRIS documentation remains accurate, current, consistent, and suitable for development, testing, governance, sustainment, release preparation, and operational use. The deliverable supports effective knowledge transfer, user understanding, technical maintainability, interface management, test execution, release governance, and long-term sustainment of the NIRIS baseline. It reduces the risk of outdated or inconsistent documentation and ensures that implemented changes are reflected in the relevant documentation set in a timely and controlled manner.

Acceptance criteria:

• Assigned documentation update, maintenance, review, and release-related tasks are completed in accordance with agreed requirements, priorities, sprint planning, release scope, or work package timeframe.
• Documentation is updated to reflect implemented software changes, configuration changes, interface changes, test support functionality, and operational impacts where applicable.
• User manual documentation is updated where user-facing functionality, workflows, screens, configuration steps, or operational procedures have changed.
• Governance documentation is updated where project, release, process, compliance, or management information has changed.
• Internal technical documentation is updated where architecture, design, implementation, configuration, deployment, or maintainability information has changed.
• Interface documentation is updated where supported interfaces, data providers, data consumers, protocols, formats, mappings, or configuration parameters have changed.
• Test documentation is updated where test cases, test procedures, test evidence, validation activities, or test-event support information has changed.
• Release-related documentation is updated where required to support release preparation, acceptance, deployment, or operational transition.
• Documentation updates are reviewed in accordance with the agreed review and approval process.
• Documentation is stored, versioned, and made available in the agreed configuration management or document management environment.
• Documentation is clear, consistent, and aligned with the implemented software baseline or agreed release scope.
• Documentation updates do not contain known major omissions or inconsistencies against the implemented changes.
• Required technical or project inputs are provided to support documentation review, release governance, or acceptance activities.

KPIs: Documentation Completion Rate – percentage of assigned documentation updates completed within the agreed sprint, release, or work package timeframe; target ≥ 90%.

Deliverables Compatibility

The deliverables produced under this SOW shall be fully compatible with the NIRIS software baseline, its architecture, and the operational and development environments provided by the NCI Agency. Accordingly, the following requirements shall be met:

All deliverables shall be designed, developed, and integrated in alignment with the existing NIRIS technology stack, architecture, and design principles.

Deliverables related to CESMO integration shall ensure compatibility with the applicable NATO standards and support the exchange, processing, and dissemination of Electronic Surveillance (ES) information within the CESMO network.

The solution shall support interoperability with NIRIS-supported data exchange formats and interfaces, including but not limited to Link 16, VMF, NVG, and other relevant Tactical Data Links (TDLs), as applicable.

Deliverables shall ensure seamless integration with existing NIRIS components and services, including managers responsible for data processing, recording, track identification, visualization, and dissemination.

Deliverables related to historic track data capability shall be compatible with the existing NIRIS data handling mechanisms, including: integration with the RTS subscription and notification services; access to stored NIRIS recordings; support for filtering based on parameters such as source, time intervals, geolocation, track identifiers, and other relevant attributes.

All software components shall be compatible with the NATO Software Factory environment, including development, testing, and integration tools like GitLab, CI/CD pipelines, and artifact repositories.

Where applicable, deliverables shall be packaged using containerization technologies (e.g. Docker) to ensure portability, scalability, and consistency across environments.

Deployment artefacts shall include clear, reproducible instructions, and where relevant, automated deployment configurations.

All developed components shall adhere to existing NIRIS interface definitions, data models, and performance constraints, particularly considering near real-time data processing requirements.

Any additional technologies, frameworks, or tools introduced as part of the deliverables shall be agreed in advance with the NCIA Point of Contact (POC).

All deliverables shall comply with NCIA security policies, secure coding practices, and accreditation requirements, as instructed by the NCIA POC.

Work Packages Delivery Schedule

The list below defines the delivery schedule for all work packages under this statement of work. Each work package represents a discrete and manageable unit of work, comprising one or more deliverables that together contribute to the overall objectives of the engagement.

a. For each work package, the Contractor shall deliver the specified outputs within the indicated target delivery date and in accordance with the defined acceptance criteria. The delivery schedule shall serve as the baseline against which progress is monitored, reported, and managed throughout the duration of the engagement.

b. The Work Packages Delivery Schedule and the scope of outputs may be subject to modification in the event of unforeseen circumstances or changes in the needs and requirements of NCIA customers, provided that such modifications do not affect the total price of the bid. Any such modifications shall be made by mutual agreement between NCIA POC and the Contractor and shall be documented in writing.

c. Any modification to the percentage of individual work packages shall be permitted if agreed between NCIA POC and the Contractor in writing, provided that the total aggregate percentage of all work packages equals 100%.

d. Each work package is considered complete only upon full acceptance of all associated deliverables and acceptance criteria.

2026 BASE: 24 August 2026 – 31 December 2026

WP 01 (45%): A1 – NIRIS baseline software development, maintenance, release preparation, and Java technology uplift. Target delivery date: 22 December 2026.

WP 02 (15%): B1 – Unit testing, automated testing, and software verification support. Target delivery date: 22 December 2026.

WP 03 (10%): C1 – NIRIS logging and troubleshooting improvements. Target delivery date: 9 October 2026.

WP 04 (16%): D1 – NIRIS interface and interoperability support. Target delivery date: 30 November 2026.

WP 05 (14%): E1 – NIRIS documentation maintenance. Target delivery date: 22 December 2026.

Payment Milestones and Proofs of Deliverable

The following proofs of deliverable are expected from this statement of work:

The payment shall be dependent upon successful acceptance of the deliverable completion report and the Delivery Acceptance Sheet (DAS).

Final payment for each deliverable shall be determined in accordance with the extent to which the defined KPIs for that deliverable have been achieved (Annex B).

KPI validation shall be performed by NCIA POC.

The Contractor may invoice one or more work packages together, provided they have been formally accepted.

The invoiced amount shall be equal to the sum of the agreed total bid percentages stated in the latest agreed Work Packages Delivery Schedule.

Invoices shall be accompanied with a Delivery Acceptance Sheet signed by the Contractor and the NCIA POC, or the assigned Service Delivery Manager.

The work packages cannot be invoiced before their defined payment milestone.

A – WP 01: Upon formal acceptance of NIRIS baseline deliverables.

B – WP 02: Upon formal acceptance of testing and verification deliverables.

C – WP 03: Upon formal acceptance of logging improvements deliverables.

D – WP 04: Upon formal acceptance of interoperability deliverables.

E – WP 05: Upon formal acceptance of documentation deliverables.

No payment shall be made for partially completed or non-accepted work packages.

Coordination and Reporting

The Contractor shall deliver the defined deliverables under the guidance of the NCIA POC, in coordination with the Project Manager, Service Delivery Manager, and relevant technical leads within the NIRIS project.

The Contractor shall primarily deliver the services remotely, unless a specific deliverable explicitly requires on-site execution at an NCIA-designated location.

The development and delivery of the deliverables shall follow an Agile approach, with activities planned, tracked and reviewed through agreed Sprint planning, execution, and review mechanisms.

The Contractor shall: participate in regular coordination activities, including sprint planning, daily stand-ups (as required), sprint reviews, and other project meetings; maintain up-to-date progress tracking through the agreed tools (e.g. Jira or equivalent); communicate proactively any risks, issues, or deviations impacting the delivery of the agreed deliverables.

For each deliverable to be considered complete and eligible for acceptance and payment, the Contractor shall submit a Deliverable Completion Report to the NCIA POC. The Deliverable Completion Report shall include, as a minimum: summary of the work performed; description of the delivered functionality or outcome; evidence of completion (e.g. code commits, test results, deployment artefacts, documentation); traceability to the agreed requirements and acceptance criteria.

The Deliverable Completion Report shall be subject to review and validation by the NCIA POC. The NCIA POC shall provide formal feedback, including: acceptance or rejection of the deliverable; evaluation against the defined acceptance criteria and applicable KPIs; identification of any required corrections or follow-up actions.

Only deliverables formally accepted by the NCIA POC shall be considered complete and eligible for payment in accordance with the defined payment milestones.

Security

Performance of the services described in this SOW requires a valid NATO SECRET security clearance prior to the start of the engagement.

It is the responsibility of the contracting company to obtain and maintain the security accreditation of all individuals working on this arrangement.

Constraints

All the documentation provided under this statement of work shall be based on NCIA templates or the format agreed with the NCIA POC.

All scripts, documentation and required code shall be stored under NATO Software Factory platforms and tools.

Practical Arrangements

This is a deliverables-based contract.

The Contractor shall be provided a user account for access to the NATO Software Factory (Azure DevOps).

This SOW requires scheduled travel on site in NCIA The Hague, twice per year or per request in any other European sites. The travel, lodging and associated expenses for travel are included in the total price of the bid, such that NCIA shall not be invoiced.

Extraordinary Travel (Purchaser Directed Travel) may be required to other NATO or non-NATO locations as necessary. In the event of such unforeseen meetings being called, the cost of all travel and subsistence will be addressed through a contract amendment. Extraordinary Travel expenses will be reimbursed in accordance with Article 5.5 of AAS+ Framework Contract. Such costs will be set as a separate PO line with a not to exceed value to cover and reimburse actual expenses upon submission of all receipts and invoices in line with NCIA processes.

The services depicted in this SOW are expected to be carried by either one contractor personnel or a team of contractors for the duration of the agreement. It is up to the bidder to propose the size of the team that delivers the services and produces the deliverables within the timelines allocated.

ANNEX B – KPI-TO-PAYMENT MAPPING MODEL

This Annex establishes the mechanism by which the achievement of defined Key Performance Indicators (KPIs) shall be mapped to the payment due for each deliverable under this Statement of Work. It describes how KPI results will be evaluated and applied for the purpose of determining the final payable amount.

Overall Payment Model

For each deliverable:

70% Fixed Payment shall be released upon formal acceptance, subject to the deliverable meeting the applicable acceptance criteria.

30% Variable Payment shall be contingent upon KPI performance.

Each KPI applicable to a deliverable shall be assigned an equal weighting within the 30% variable payment component (KPI Weight). The proportion of each KPI Weight payable shall be determined in accordance with the KPI scoring bands set out below.

Meets or exceeds target (100%): 100% of KPI weight

Minor deviation (90–99%): 90% of KPI weight

Moderate deviation (80–89%): 75% of KPI weight

Significant deviation (70–79%): 50% of KPI weight

No compliance (< 70%): 0% of KPI weight

Total Payment = Fixed Component + Variable Component

Fixed Component = 70% of deliverable value.

Variable Component = Sum of (KPI Weight × Percentage of KPI weight).

QUALIFICATIONS

Each contractor personnel must meet the following requirements

• At least 10 years of professional experience in software development, with a focus on full-stack systems.
• Proven ability to communicate effectively in English, both orally and in writing, in a clear, structured, and professional manner.
• Demonstrated experience in working within Agile/Scrum environments, including participation in sprint planning, execution, and review activities.
• At least 3 years of professional experience in Java-based software development, including experience with modern frameworks and backend service development.
• At least 2 years of experience working with web technologies, including TypeScript and/or Angular-based front-end development.
• At least 2 years of experience working with software integration, including RESTful services, messaging systems, or data exchange interfaces.
• At least 2 years of experience working with near real-time or data-intensive systems, including data processing, filtering, and dissemination.
• At least 1 year of professional experience working with containerization technologies (e.g. Docker), including building, packaging, and deploying Linux-based containers.
• At least 3 years of experience with DevOps and CI/CD practices, including use of tools such as GitLab, automated pipelines, and artifact repositories.
• Demonstrable experience in software testing practices, including unit testing, integration testing, and, where applicable, automated testing.
• Experience in defining acceptance criteria, test scenarios, or validation approaches for software deliverables.
• Demonstrable knowledge or experience in interoperability and data exchange standards, particularly within defence or similar domains (knowledge of Tactical Data Links is mandatory).
• Experience working with distributed systems and multi-component architectures, including integration of multiple data sources.
• Familiarity with secure software development practices and working within controlled or regulated environments.
• The contractor personnel must be a national of a NATO member nation.
• Must hold a valid NATO SECRET security clearance as from the start date of the contract.