Software Independent Verification & Validation
Independent evidence that mission-critical software does what it must, and nothing it mustn't.
Weapon and missile defense software has to work the first time it matters. Independent Verification and Validation (IV&V) gives program offices an engineering team that is separate from the developer, whose only job is to find out whether the software is right. Earlier findings cost less to fix, and decision-makers get evidence they can rely on at every milestone.
Verification and Validation, Defined
Verification
Are we building the product right? Does each work product (requirements, design, code, tests) correctly implement the one before it?
Validation
Are we building the right product? Does the software meet the mission need in its intended operational environment?
IEEE 1012, the standard for system, software, and hardware V&V, describes independence in three dimensions:
Technical independence. IV&V uses its own people, tools, and analysis rather than reusing the developer's.
Managerial independence. IV&V reports outside the development organization's chain, so findings can't be suppressed or deprioritized.
Financial independence. IV&V funding is controlled outside the development effort, so budget pressure on development doesn't quietly cut the assurance work.
What We Do
Independent analysis at every stage of the software lifecycle.
Requirements Analysis
Completeness, consistency, testability, and bidirectional traceability from capability documents through software requirements.
Design & Interface Analysis
Architecture, interfaces, timing, and failure-mode reviews, with a focus on safety- and mission-critical functions.
Code Analysis
Independent static, dynamic, and hybrid testing, coding-standard conformance, and weakness identification mapped to the Common Weakness Enumeration (CWE).
Test Analysis & Independent Test
Assess the developer's test coverage and procedures, witness formal testing, and run independent tests where risk calls for it.
Software Safety & Airworthiness
Identify safety-significant software functions, support the system safety process under MIL-STD-882E and the Joint Software Systems Safety Engineering Handbook, and conduct airworthiness assessments.
Security & Assurance Inputs
Software assurance findings that feed the Program Protection Plan (DoDI 5000.83) and cybersecurity T&E.
Release Readiness
An evidence-based recommendation on whether a build is ready for test, fielding, or a milestone decision.
Rigor That Matches Consequence
Not every software component needs the same scrutiny. IEEE 1012 uses integrity levels to scale V&V tasks to the consequence of failure. Software whose failure could cause loss of life, mission failure, or major damage gets the most rigorous analysis, and lower-consequence components get proportionate effort. We agree on the integrity-level scheme with the program at the start, so effort goes where risk is.
Proven Track Record
Operational credibility backed by real-world delivery.
- IV&V on the DEVCOM AvMC Software Mission Assurance contract, on systems from PAE Fires, PAE Maneuver Air, and the Missile Defense Agency
- Select platforms supported across our programs: Aegis, C2BMC, AN/TPY-2, GME, LRDR, THAAD, XBR/SBX, SKA, PAC-3, Gray Eagle, UH-60, AH-64, Shadow UAS, ATEC range targets, Banshee targets, 2S6 VISMOD
- Software safety and airworthiness assessments, plus configuration and cybersecurity management across multiple integration labs
SPECTREIQ Connection: SPECTREIQ automates the JFAC Software Weakness Risk Scoring Process and orchestrates SAST, DAST, fuzzing, and STIG tools, so IV&V analysts spend their time on judgment instead of tool wrangling, with consistent, auditable outputs.
Who We Support
Government program offices responsible for aviation, missile, and missile defense software, plus the safety and T&E organizations that review it. IV&V is engaged by and reports to the government. To protect independence, we don't perform IV&V on software we developed, and we screen every engagement for organizational conflicts of interest (FAR Subpart 9.5).
Standards We Work To
IEEE 1012 (System, Software, and Hardware Verification and Validation)
Defines V&V tasks across the lifecycle, independence in three dimensions (technical, managerial, financial), and integrity levels that scale rigor to the consequence of failure.
MIL-STD-882E (System Safety)
The DoW standard practice for system safety, including the software contribution to system hazards.
Joint Software Systems Safety Engineering Handbook
Implementation guidance for software system safety, used alongside MIL-STD-882E to set the level of rigor for safety-significant software.
Program protection and test policy (DoDI 5000.83 and DoDI 5000.89)
Software assurance findings that feed the Program Protection Plan and cybersecurity T&E rather than sitting in a separate report.
Organizational conflicts of interest (FAR Subpart 9.5)
Independence screening so the IV&V agent has no stake in the software it evaluates.
How an Engagement Works
- 01
Plan
Establish the integrity-level assessment, the IV&V scope, and a Software V&V Plan aligned to the developer's lifecycle and the program's milestones.
- 02
Analyze in step with development
IV&V tasks run alongside each development phase rather than waiting for a finished product.
- 03
Report anomalies continuously
Findings go to the program office as they're found, with severity, rationale, and recommended disposition.
- 04
Summarize for decisions
Phase and milestone reports give leadership a clear, evidence-backed view of software risk.
How to Buy
AMPERSAND services are available through established contract vehicles, so your contracting office doesn't need a standalone procurement.
- MDA SHIELD
- SeaPort-NxG(Navy)
- EWAAC(Air Force)
- GSA Multiple Award Schedule
CAGE 870C8 · UEI FJFHALLBGLW3 · Top Secret facility clearance
Frequently Asked Questions
How is IV&V different from the developer's testing?
Developer testing shows that the software passes the tests the developer wrote. IV&V independently asks whether those were the right tests, whether the requirements were right, and what the developer's process might have missed. The two complement each other; IV&V doesn't replace developmental test.
When should IV&V start?
At requirements. Most costly software defects trace back to requirements and design decisions, and IV&V that starts at integration test can only find them when they're most expensive to fix.
Does IV&V slow a program down?
Planned well, it shouldn't. IV&V runs in parallel with development and delivers findings continuously. Programs often save schedule because problems surface before formal test events, not during them.
Can IV&V support agile or DevSecOps development?
Yes. IV&V tasks map to increments and pipeline stages instead of waterfall phases: automated analysis on every build, plus independent review at each release.
Can a prime contractor hire you for IV&V on their own software?
Independence is the point of IV&V, so we're normally engaged by the government. Primes can bring us in for independent internal assessment, but that isn't a substitute for government IV&V where it's required.
References
- IEEE 1012-2024, Standard for System, Software, and Hardware Verification and Validation — IEEE, 2024
- MIL-STD-882E, Department of Defense Standard Practice: System Safety (Change 1) — DLA ASSIST, May 11, 2012; Change 1 September 27, 2023
- Joint Software Systems Safety Engineering Handbook, Version 1.0 — OUSD(AT&L), archived, August 27, 2010
- DoD Instruction 5000.83, Technology and Program Protection to Maintain Technological Advantage — DoD, July 20, 2020, Change 1 May 21, 2021
- DoD Instruction 5000.89, Test and Evaluation — DoD, November 19, 2020
- FAR Subpart 9.5, Organizational and Consultant Conflicts of Interest — Acquisition.gov
Last reviewed:
Terms explained in the Defense Technology Glossary →DISCUSS INDEPENDENT ASSURANCE
From requirements through release readiness, our IV&V team gives your program office evidence it can rely on at every milestone.