DO-332 Model-Based Development

Object-oriented software is widely used to manage complexity, promote reuse, and organize behavior around classes and components. In avionics, however, features such as inheritance, overriding, polymorphism, dynamic dispatch, exception handling, and reusable frameworks can make the effective software behavior harder to determine from a local code review. 

This creates a certification question: if an operation can be inherited, overridden, or selected at run time, how does the project prove which implementation can execute and whether every relevant behavior has been verified? 

DO-332 addresses that question. It is the Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A. DO-332 does not replace DO-178C. Instead, it identifies additions, modifications, and deletions to lifecycle objectives when object-oriented technology or related techniques require additional assurance guidance.

DO-332 provides a common framework for evaluating and accepting object-oriented technology and related techniques within an airborne or ground-based software lifecycle. In Europe, the related EUROCAE designation is ED-217. The practical purpose is to help applicants use modern software techniques without losing the determinism, traceability, verification completeness, configuration control, and reviewability expected under DO-178C or DO-278A. 

A DO-332 program may use class hierarchies, encapsulation, inheritance, virtual operations, polymorphism, dynamic binding, generic constructs, reusable software components, exceptions, or other related techniques. The exact applicability depends on the actual architecture and implementation. The project must identify the techniques used, define appropriate constraints, and plan how technology-specific risks will be reviewed and verified.

Traditional software assurance often assumes that a reviewer can follow control flow and data flow through explicitly called procedures. Object-oriented designs can distribute behavior across interfaces, base classes, derived classes, collaborating objects, and reusable frameworks. The method that executes at one call site may depend on the run-time type of the object rather than only on the visible source statement. 

This design flexibility can improve modularity and maintainability, but it can complicate certification evidence. Teams must show that all feasible dispatch targets are known, that inherited and overridden behavior remains consistent with requirements, that object interactions do not create unintended coupling, and that requirements-based testing and structural coverage reflect the effective implementation. 

DO-332 was created to bring structure to these questions. It allows teams to use object-oriented technology while making the resulting behavior, dependencies, verification activities, and configuration evidence understandable to engineering and certification reviewers.

In a DO-332 lifecycle, the assurance argument must address more than the contents of individual source files. A requirement may be implemented across an interface, a class hierarchy, several concrete operations, and interactions with other objects. A small change to a base class can affect multiple derived classes and test scenarios even when those files are not edited directly. 

A practical workflow begins by identifying the object-oriented and related techniques used by the software. The team defines architecture and coding constraints, traces requirements to meaningful design and implementation elements, verifies every relevant effective behavior, evaluates structural coverage and coupling, controls reusable components and libraries, and maintains the exact configuration of requirements, source, tools, tests, results, and problem reports used for certification review.

Inheritance allows a class to reuse behavior from a parent class. Overriding allows a derived class to replace that behavior. Polymorphism and dynamic dispatch allow the operation selected at a call site to depend on the run-time object type. These mechanisms are useful, but they can hide the full set of behaviors that must be reviewed and tested. 

A credible DO-332 strategy should make the effective call targets visible, restrict unnecessary dynamic behavior, and show that requirements and verification cases cover the implementations that can actually execute. The project should also define how changes to a base class, interface, or dispatch rule trigger impact analysis across affected software components and evidence.

DO-332 also addresses related techniques that can introduce similar assurance concerns. Depending on the design, these discussions may involve generic programming, type conversions, exception handling, dynamic memory management, reusable components, overloading, or other mechanisms that change how behavior and dependencies are resolved. Some related-technique guidance can be relevant even when the software is not primarily described as object oriented. 

The important point is not to create a generic list and assume every item applies. Teams should inventory the techniques actually used, map them to the applicable DO-332 objectives and project standards, and define evidence proportionate to the software level and approved certification strategy.

Best match for traceability coverage and checking whether tool requirements are linked to verification artifacts.

Check traceability coverage before certification review.

DO-178C remains the core airborne software assurance framework. DO-332 supplements selected objectives when object-oriented technology or related techniques are used. Requirements traceability, verification completeness, structural coverage, data and control coupling analysis, configuration management, software quality assurance, change control, and Development Assurance Level considerations remain part of the certification picture. 

 The main difference is the additional attention given to effective object-oriented behavior. The project must show not only which requirement maps to a class or component, but also which implementation can execute, which inherited or overridden behavior is involved, which tests cover the feasible paths, and which baseline contains the evidence reviewed together.

Traceability is difficult when behavior is spread across class hierarchies and collaborating objects. A simple requirement-to-file link can be too coarse. Teams may need bidirectional relationships from requirements to architecture or design elements, classes or components, implementation changes, verification cases, test results, structural coverage evidence, defects, reviews, and configuration baselines. 

This is where a connected lifecycle platform becomes valuable. If the evidence is maintained across disconnected documents, source repositories, modeling files, test exports, and spreadsheets, change impact becomes fragile. A modification to an interface or base class can affect downstream implementations, tests, coverage, assumptions, and review records. Teams need a practical way to see those relationships without creating an unmaintainable network of low-value links.

IBM Engineering Lifecycle Management can help teams manage the evidence chain behind a DO-332 workflow. IBM DOORS Next can capture software requirements, maintain reviews and baselines, and link requirements to development, design, and test artifacts. IBM Rhapsody can support UML-based software architecture and object-oriented design, while IBM Rhapsody Model Manager can help teams collaborate on, review, configure, and connect model elements within the broader lifecycle. 

IBM Engineering Test Management can organize requirements-based test plans, test cases, execution records, and results. IBM Engineering Workflow Management can support work items, source changes, defects, approvals, and configuration workflows. IBM Engineering Lifecycle Optimization - Method Composer can help process owners document and publish consistent engineering methods, including roles, tasks, work products, review criteria, and tool guidance for regulated software teams. 

For teams using object-oriented technology under DO-332 expectations, the challenge is not only writing or modeling software. The harder challenge is proving how requirements connect to class structures, effective implementations, tests, results, coverage, defects, change records, reusable components, and approved baselines. Softacus can help teams configure IBM Engineering Lifecycle Management so those relationships are easier to manage and easier to explain during review. 

Softacus can support the practical setup of DO-332-oriented workflows across the IBM ELM toolchain. In DOORS Next, this can mean structuring software requirements and link types so teams can trace them to meaningful design, development, and test artifacts. In IBM Rhapsody and Rhapsody Model Manager, it can mean helping teams organize UML design collaboration, model reviews, configuration awareness, and traceability between class or component views and the rest of the lifecycle.

DO-332 connects modern object-oriented software engineering with the assurance discipline expected under DO-178C. It helps teams use inheritance, polymorphism, reusable components, and related techniques without losing control of effective behavior, dependencies, verification, and configuration evidence. 

For aerospace and defense teams, the real challenge is not simply choosing an object-oriented language or modeling tool. It is maintaining a clear line from requirements to architecture, implementation, verification results, change records, defects, and approved baselines. IBM ELM can support that connected lifecycle, and Softacus can help teams configure it in a way that is practical, auditable, and easier to maintain.