{
  "id": "page:library-v-model",
  "_kind": "Page",
  "_file": "wiki/library/v-model.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "title": "V-Model Methodology (Library)",
    "displayName": "V-Model Methodology (Library)",
    "slug": "library/v-model",
    "articlePath": "wiki/library/v-model.md",
    "article": "\n# V-Model Methodology\n\n**Creator**: Evolved from waterfall in the 1980s\n**Year**: Classic verification/validation\n**Category**: Verification & Validation / Testing\n**Process ID**: `methodologies/v-model`\n\n## Overview\n\nThe V-Model is an SDLC model where execution happens in a sequential V-shape. It's also known as the Verification and Validation model. The left side of the \"V\" represents decomposition of requirements and system specifications, while the right side represents integration and validation. Each development phase has a corresponding testing phase designed in parallel.\n\nThis methodology is particularly well-suited for:\n- Safety-critical systems (aerospace, automotive, medical devices)\n- Regulated industries requiring compliance documentation\n- Projects requiring rigorous testing and traceability\n- Systems where failures have high consequences\n\n## Key Principles\n\n1. **Verification and Validation**\n   - **Verification**: \"Are you building it right?\" (process correctness)\n   - **Validation**: \"Are you building the right thing?\" (product correctness)\n\n2. **Testing Parallel to Development**: Test design happens during corresponding development phase\n\n3. **V-Shape Mapping**: Each development phase maps to a testing phase\n   - Requirements Analysis ↔ Acceptance Testing\n   - System Design ↔ System Testing\n   - Architectural Design ↔ Integration Testing\n   - Module Design ↔ Unit Testing\n\n4. **Early Test Planning**: Test cases designed before code is written\n\n5. **High Discipline**: Rigorous documentation and phase completion criteria\n\n6. **Traceability**: Complete bidirectional traceability from requirements to tests\n\n## The V-Model Structure\n\n```\nLEFT SIDE                          RIGHT SIDE\n(Decomposition)                    (Integration/Validation)\n\nRequirements ───────────────────→ Acceptance\nAnalysis                          Testing\n    ↓                                 ↑\nSystem      ───────────────────→ System\nDesign                            Testing\n    ↓                                 ↑\nArchitectural ─────────────────→ Integration\nDesign                            Testing\n    ↓                                 ↑\nModule      ───────────────────→ Unit\nDesign                            Testing\n    ↓                                 ↑\n         Implementation\n         (Coding Phase)\n```\n\n## Process Flow\n\n### Left Side: Decomposition & Test Design\n\n#### 1. Requirements Analysis + Acceptance Test Design\n- Gather and document functional requirements\n- Identify non-functional requirements\n- Define acceptance criteria\n- Design acceptance test cases in parallel\n- Create requirements-to-test traceability\n\n**Outputs**:\n- Requirements Specification\n- Acceptance Test Plan\n- Traceability seed\n\n#### 2. System Design + System Test Design\n- Define system architecture and components\n- Specify interfaces and data flows\n- Select technology stack\n- Design system test cases in parallel\n- Map design elements to tests\n\n**Outputs**:\n- System Design Document\n- System Test Plan\n- Architecture diagrams\n\n#### 3. Architectural Design + Integration Test Design\n- Break components into modules\n- Define module interfaces\n- Specify communication protocols\n- Design integration test cases in parallel\n- Create interface test specifications\n\n**Outputs**:\n- Architectural Design Document\n- Integration Test Plan\n- Module interface specifications\n\n#### 4. Module Design + Unit Test Design\n- Design classes, functions, and algorithms\n- Specify internal data structures\n- Define error handling strategies\n- Design unit test cases in parallel\n- Create detailed code specifications\n\n**Outputs**:\n- Module Design Specifications\n- Unit Test Plans\n- Code-level specifications\n\n### Bottom: Implementation\n\n#### 5. Implementation (Coding)\n- Implement modules per design specifications\n- Conduct code reviews\n- Perform static analysis\n- Ensure coding standards compliance\n- Prepare for testing\n\n**Outputs**:\n- Source code\n- Code review reports\n- Static analysis results\n\n### Right Side: Integration & Validation\n\n#### 6. Unit Testing\n- Test individual functions and classes\n- Validate module design correctness\n- Achieve target code coverage\n- Fix defects and retest\n\n**Validates**: Module Design\n\n#### 7. Integration Testing\n- Test module interactions\n- Validate interface contracts\n- Verify data flows\n- Test error handling across boundaries\n\n**Validates**: Architectural Design\n\n#### 8. System Testing\n- Test end-to-end system functionality\n- Validate system-level requirements\n- Test non-functional requirements\n- Verify system integration\n\n**Validates**: System Design\n\n#### 9. Acceptance Testing\n- Validate all requirements are met\n- Conduct user acceptance testing\n- Verify business objectives achieved\n- Obtain customer sign-off\n\n**Validates**: Requirements Analysis\n\n### Final Phase: Traceability Matrix\n\n#### 10. Traceability Matrix Generation\n- Map requirements through design to implementation to tests\n- Perform coverage analysis\n- Identify gaps\n- Generate compliance reports\n- Document complete traceability\n\n**Outputs**:\n- Traceability Matrix\n- Coverage Reports\n- Compliance Documentation\n\n## Usage\n\n### Basic Example\n\n```javascript\nimport { process } from './v-model.js';\n\nconst result = await process({\n  projectRequirements: `\n    Build a patient monitoring system that:\n    - Monitors vital signs (heart rate, blood pressure, temperature)\n    - Alerts medical staff when values exceed thresholds\n    - Records all measurements with timestamps\n    - Provides real-time dashboard\n  `,\n  safetyLevel: 'critical',\n  traceabilityRequired: true,\n  testingRigor: 'exhaustive'\n}, ctx);\n\nconsole.log(`Success: ${result.success}`);\nconsole.log(`Requirements: ${result.requirements.total}`);\nconsole.log(`Modules: ${result.moduleDesign.moduleCount}`);\nconsole.log(`All Tests Passed: ${result.testResults.allPassed}`);\nconsole.log(`Requirements Coverage: ${result.traceabilityMatrix.requirementsCoverage}%`);\n```\n\n### With Compliance Standards\n\n```javascript\nconst result = await process({\n  projectRequirements: `\n    Automotive braking system controller:\n    - Anti-lock braking system (ABS)\n    - Electronic stability control (ESC)\n    - Brake force distribution\n    - Emergency brake assist\n  `,\n  safetyLevel: 'critical',\n  traceabilityRequired: true,\n  testingRigor: 'exhaustive',\n  complianceStandards: ['ISO 26262', 'MISRA C'],\n  existingArtifacts: {\n    sensors: ['wheel_speed_sensor', 'brake_pressure_sensor'],\n    actuators: ['brake_actuator']\n  }\n}, ctx);\n```\n\n### Standard Software Project\n\n```javascript\nconst result = await process({\n  projectRequirements: `\n    E-commerce checkout system:\n    - Shopping cart management\n    - Payment processing\n    - Order confirmation\n    - Email notifications\n  `,\n  safetyLevel: 'standard',\n  traceabilityRequired: true,\n  testingRigor: 'thorough'\n}, ctx);\n```\n\n### Inputs\n\n| Field | Type | Required | Default | Description |\n|-------|------|----------|---------|-------------|\n| `projectRequirements` | string | ✅ Yes | - | Project requirements document or description |\n| `safetyLevel` | string | No | 'standard' | Safety criticality: 'standard', 'high', or 'critical' |\n| `traceabilityRequired` | boolean | No | true | Generate full traceability matrix |\n| `testingRigor` | string | No | 'thorough' | Testing thoroughness: 'basic', 'thorough', or 'exhaustive' |\n| `existingArtifacts` | object | No | null | Existing design or code to integrate |\n| `complianceStandards` | array | No | [] | Standards to comply with (ISO 26262, DO-178C, etc.) |\n\n### Outputs\n\n```javascript\n{\n  success: true,\n  durationMinutes: 180,\n  safetyLevel: 'critical',\n  testingRigor: 'exhaustive',\n  requirements: {\n    total: 25,\n    functional: 18,\n    nonFunctional: 7,\n    details: { functionalRequirements: [...], nonFunctionalRequirements: [...] }\n  },\n  systemDesign: {\n    componentCount: 5,\n    interfaceCount: 8,\n    details: { components: [...], interfaces: [...], dataFlows: [...] }\n  },\n  architecture: {\n    moduleCount: 12,\n    interfaceCount: 15,\n    dataFlowCount: 20,\n    details: { modules: [...], interfaces: [...], dataFlows: [...] }\n  },\n  moduleDesign: {\n    moduleCount: 12,\n    details: [...]\n  },\n  implementation: {\n    modulesImplemented: 12,\n    filesCreated: 45,\n    codeReviewsPassed: true,\n    staticAnalysisPassed: true,\n    details: { modules: [...], codeReviewDetails: [...], staticAnalysisResults: {...} }\n  },\n  testResults: {\n    unitTests: { totalCount: 150, passedCount: 150, passed: true, coverage: 95 },\n    integrationTests: { totalCount: 45, passedCount: 45, passed: true },\n    systemTests: { totalCount: 30, passedCount: 30, passed: true },\n    acceptanceTests: { totalCount: 25, passedCount: 25, passed: true },\n    allPassed: true,\n    summary: { totalTests: 250, totalPassed: 250, allTestsPassed: true }\n  },\n  traceabilityMatrix: {\n    requirementsCoverage: 100,\n    designCoverage: 100,\n    testCoverage: 95,\n    implementationCoverage: 100,\n    gaps: [],\n    complianceStatus: 'compliant',\n    requirementTraces: [...]\n  },\n  artifacts: {\n    requirements: 'artifacts/v-model/requirements-specification.md',\n    acceptanceTestPlan: 'artifacts/v-model/acceptance-test-plan.md',\n    systemDesign: 'artifacts/v-model/system-design.md',\n    // ... more artifacts\n  }\n}\n```\n\n## Safety Levels\n\n### Standard\n- Regular software projects\n- Standard testing practices\n- Basic traceability\n- Code reviews and static analysis\n\n### High\n- Business-critical applications\n- Enhanced testing rigor\n- Detailed traceability\n- Multiple code review rounds\n- Comprehensive static analysis\n\n### Critical\n- Safety-critical systems (medical, automotive, aerospace)\n- Exhaustive testing at all levels\n- Complete bidirectional traceability\n- Formal code reviews and inspections\n- Advanced static analysis and verification\n- Compliance documentation\n- Independent verification and validation (IV&V)\n\n## Testing Rigor Levels\n\n### Basic\n- Core functionality testing\n- Happy path scenarios\n- Basic edge case coverage\n- Minimum acceptable coverage\n\n### Thorough (Default)\n- Comprehensive functionality testing\n- Happy path + edge cases\n- Error handling validation\n- Good coverage (80%+)\n- Integration and system testing\n\n### Exhaustive\n- All possible scenarios\n- Boundary value analysis\n- Equivalence partitioning\n- Statement and branch coverage (95%+)\n- Mutation testing\n- Security and performance testing\n\n## Breakpoints\n\nThe V-Model process includes breakpoints for human review at critical phases:\n\n1. **Requirements & Acceptance Test Design Review**: Review requirements and acceptance test plan before system design\n2. **System Design & Test Review**: Review system architecture and system test plan\n3. **Architecture & Integration Test Review**: Review detailed architecture and integration test plan\n4. **Module Design & Unit Test Review**: Review module specifications and unit test plans\n5. **Implementation Review**: Review code, code reviews, and static analysis before testing\n6. **Test Results Review**: Review all test results before traceability generation\n7. **Traceability Matrix Review**: Final review of complete traceability and coverage\n\n## Integration Points\n\n### Compatible Methodologies\n\n1. **TDD/ATDD**\n   - V-Model provides the test design framework\n   - TDD/ATDD provides the test implementation approach\n   - Unit and acceptance test designs from V-Model feed into TDD cycles\n\n2. **BDD/Specification by Example**\n   - Requirements phase can use Example Mapping\n   - Acceptance tests can be written in Gherkin\n   - Combine V-Model structure with BDD collaboration\n\n3. **Domain-Driven Design**\n   - Use DDD for system and architectural design phases\n   - Bounded contexts map to system components\n   - Ubiquitous language in requirements\n\n4. **Waterfall**\n   - V-Model is essentially waterfall with parallel test design\n   - Use for sequential, phase-gated projects\n   - Enhanced with verification and validation\n\n5. **Agile (Adapted)**\n   - Apply V-Model within sprints for feature development\n   - Maintain traceability in agile context\n   - Use for regulated agile projects\n\n## When to Use V-Model\n\n### Ideal For\n\n✅ Safety-critical systems requiring validation\n✅ Regulated industries (medical, aerospace, automotive)\n✅ Projects requiring complete traceability\n✅ Fixed requirements with low change likelihood\n✅ Projects with clear scope and specifications\n✅ Compliance-driven development\n✅ Systems where testing costs are lower than failure costs\n\n### Not Ideal For\n\n❌ Rapidly changing requirements\n❌ Early-stage startups with uncertain product direction\n❌ Highly innovative projects requiring experimentation\n❌ Projects with tight time-to-market constraints\n❌ Small projects where V-Model overhead isn't justified\n\n## Advantages\n\n- ✅ Early test planning reduces defects\n- ✅ Complete traceability ensures nothing is missed\n- ✅ Clear phase boundaries and deliverables\n- ✅ Excellent for compliance and auditing\n- ✅ Defects caught early through parallel test design\n- ✅ High quality through rigorous verification and validation\n- ✅ Well-documented process\n\n## Disadvantages\n\n- ❌ Rigid and inflexible to changes\n- ❌ High overhead and documentation burden\n- ❌ Long time before working software\n- ❌ Testing happens late (despite test design being early)\n- ❌ Difficult to handle unclear or evolving requirements\n- ❌ Not suitable for small or agile projects\n\n## Best Practices\n\n### Do's\n- ✅ Design tests in parallel with development phases\n- ✅ Maintain bidirectional traceability throughout\n- ✅ Conduct thorough reviews at each phase gate\n- ✅ Use formal inspection techniques for critical systems\n- ✅ Document everything comprehensively\n- ✅ Involve test engineers from requirements phase\n- ✅ Use automated traceability tools\n\n### Don'ts\n- ❌ Don't skip test design phases\n- ❌ Don't allow requirements changes without impact analysis\n- ❌ Don't proceed to next phase with unresolved issues\n- ❌ Don't skip traceability updates\n- ❌ Don't compromise on testing rigor for schedule pressure\n- ❌ Don't forget backward traceability (tests → requirements)\n\n## Example Artifacts\n\n### Requirements Specification\n```markdown\n# Requirements Specification\n\n## Functional Requirements\n\n### FR-001: User Authentication\n**Priority**: Critical\n**Description**: System shall authenticate users via username and password\n**Acceptance Criteria**:\n- Valid credentials grant access\n- Invalid credentials are rejected with error message\n- Account locks after 3 failed attempts\n\n**Traceability**:\n- Acceptance Tests: AT-001, AT-002, AT-003\n- System Design: Component-Auth\n```\n\n### Traceability Matrix\n```markdown\n# Traceability Matrix\n\n| Req ID | System Design | Architecture | Implementation | Unit Tests | Integration Tests | System Tests | Acceptance Tests | Status |\n|--------|--------------|--------------|----------------|-----------|------------------|-------------|-----------------|--------|\n| FR-001 | Comp-Auth | Mod-Login | auth/login.js | UT-001, UT-002 | IT-005 | ST-010 | AT-001 | ✅ Complete |\n| FR-002 | Comp-Auth | Mod-Session | auth/session.js | UT-003, UT-004 | IT-006 | ST-011 | AT-002 | ✅ Complete |\n```\n\n## Compliance Standards Support\n\nThe V-Model implementation supports various compliance standards:\n\n### ISO 26262 (Automotive)\n- ASIL-level safety requirements\n- Hardware-software interface specifications\n- Safety validation testing\n- Complete traceability documentation\n\n### DO-178C (Aviation)\n- Software level determination\n- Requirements-based testing\n- Structural coverage analysis\n- Verification and validation activities\n\n### IEC 62304 (Medical Devices)\n- Software safety classification\n- Risk management integration\n- Verification and validation documentation\n- Traceability matrix\n\n### MISRA (Automotive/Embedded)\n- Coding standards compliance\n- Static analysis integration\n- Code review requirements\n\n## References\n\n### Original Sources\n- [V-Model on Wikipedia](https://en.wikipedia.org/wiki/V-model)\n- [SDLC V-Model Tutorial](https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm)\n- [TeachingAgile: V-Model](https://teachingagile.com/sdlc/models/v-model/)\n\n### Standards and Compliance\n- [ISO 26262 Road Vehicles Functional Safety](https://www.iso.org/standard/68383.html)\n- [DO-178C Software Considerations in Airborne Systems](https://www.rtca.org/content/publications)\n- [IEC 62304 Medical Device Software](https://www.iso.org/standard/38421.html)\n\n### Related Reading\n- \"Software Testing\" by Ron Patton\n- \"Systems Engineering Fundamentals\" by Defense Acquisition University\n- \"Verification and Validation in Scientific Computing\" by Oberkampf & Roy\n\n## License\n\nThis methodology implementation is part of the Babysitter SDK orchestration framework.\n\nThe V-Model is a public domain software development process model.\n",
    "documents": [
      "specialization:v-model"
    ]
  },
  "outgoingEdges": [
    {
      "from": "page:library-v-model",
      "to": "specialization:v-model",
      "kind": "documents"
    }
  ],
  "incomingEdges": [
    {
      "from": "page:index",
      "to": "page:library-v-model",
      "kind": "contains_page"
    }
  ]
}