Software Factory

The XWARE Software Factory.

CI/CD, ALM traceability and quality gates for safety-critical embedded software. Compliance evidence comes out of daily engineering work, on the tools you already own.

Talk to us 10 golden rules: the guide (PDF, 2 pages)

Standards. ASPICE 4.0, ISO 26262, ISO/SAE 21434, DO-178C, EN 50128, IEC 62304, IEC 61508. Built on. Codebeamer or Polarion, GitHub Actions, GitLab CI or Jenkins. Deployed. In four phases, on your own tools.

One Evidence Chain

The Software Factory is an architecture, a set of rules and a way of working, built on your ALM and CI/CD tools.

The ALM is the system of record.
Baseline pipelines write evidence to it. Pull request pipelines only read it.
QA reads it and cannot change engineering data.
Governance sets how strict each project is, without touching the data.
AI assistants reach it through a controlled interface.
Assessment and audit evidence is a query on the ALM.

Building Blocks

Each block can be deployed on its own, and the value comes from the links between them. Most programmes start with the ALM model and the pipeline, then add gates and dashboards.

ALM Configuration

A tracker model for change requests, modification records, design, test specifications, test runs, static analysis runs and releases, built on your existing template. One system of record, traceable from change request to test result.

Design-to-test Traceability

One vocabulary between the test tool and the design model, links resolved by the pipeline, and consistency checks. No manual linking, no orphan tests, no untested units.

CI/CD Pipelines

Pull request, nightly, weekly and release candidate pipelines, self-hosted runners for licensed tools, and one service account for ALM writes. Fast feedback on every change, and recorded evidence from every baseline.

Unit Testing

A design-based test method, a test harness, a stub library for basic software, and coverage targets by risk class. Unit tests verify the design intent, with coverage measured per unit.

Static Analysis

MISRA or CERT C analysis on every change and every baseline, with a violation baseline for legacy code and suppression tracking. New violations are blocked, and existing debt stays visible.

Quality Gates

Merge, feature and release gates, with thresholds per project and staged enforcement.

Release Management

Criteria on the release, measured values in linked records, and an immutable record per release candidate. Readiness is visible at any time, with the full history of rejected candidates.

QA Dashboards

Dashboard widgets that read the ALM over its REST API: QA overview, verification, build, static analysis, release readiness and registers. An independent QA view with no manual status reporting.

Process Documentation

Organisation-level test, QA and configuration management strategies, work instructions and project plan templates. Rules written down, owned and ready for assessment.

Quality Gates

Three gates decide on evidence the pipelines and the ALM already hold. Thresholds follow the risk class of each project and live in a governance record. If the ALM cannot be reached, the gate fails closed.

Merge Gate

On the pull request, as a required status check

The build succeeds, the selected unit tests pass, coverage meets the threshold, there are no new static analysis violations beyond the project budget, the touched design and test specifications are approved, and the review is done.

Feature Gate

In the ALM, per modification record

The design, the test specification, passing results and coverage are all linked to the change.

Release Gate

In the ALM, per release candidate

All release criteria are met on the immutable evidence of that candidate, and QA signs.

Observe
Gates are computed and shown. Nothing is blocked.
Warn
A failing gate shows on the pull request and flags the release at risk.
Enforce
A failing gate blocks the merge or the release. An approved deviation with an expiry date is the only way past it.

Tests from the Design

Design
The developer updates the behavioural design of the unit. It is reviewed and synchronised to the ALM.
Specify
The test specification is written in the ALM: boundary values, equivalence classes and error cases, reviewed the same way.
Implement
The code and the executable test are written and run locally on the touched units.
Merge
A pull request opens, and the merge gate decides.

Coverage: Targets come from the integrity level: statement and branch coverage at the lower levels, MC/DC where the standard requires it, such as ASIL D, DAL A or SIL 4. Each unit is judged against its own level.
Legacy code: New and changed units follow the full process. Untouched, production-proven code is covered by a documented position and joins the full process the first time a change reaches it.
Static analysis: MISRA, CERT C or your coding standard on every pull request and every baseline. Existing violations are baselined, so only new ones block, and suppressions are tracked against findings.
Host and target: Tests run host-based in CI, with drivers, the operating system and AUTOSAR basic software stubbed from a shared library. Target execution is added where the standard or the risk requires it.

QA Dashboards and Release Readiness

QA sees the state of every project without asking for a status. The dashboards read the ALM over its REST API and add no data entry.

QA overview: what needs attention now, across all projects
Verification: which units meet their coverage target
Build and warnings: whether all variants build
Static analysis: whether findings fall faster than suppressions grow
Release readiness: which exit criteria are met, and why a candidate was rejected
QA registers: open and expiring non-conformities, deviations and audit actions

A rejected release candidate is kept as evidence that the gate worked. Readiness is an indicator, and the QA signature is the decision.

AI Built In

AI works at every step from design to release, and every AI output passes the same gates and human approvals as human work. AI never sets a gate verdict or a rating, and your data stays in your environment or on model endpoints you approve.

AI Code Review

Reviews every pull request next to the human reviewer: coding standard, design conformance, error handling and missing tests. The human reviewer approves.

AI-assisted Authoring

Drafts the implementation from the approved design in the IDE, with assistants such as GitHub Copilot or Claude. The developer owns the code, and the merge gate applies.

Test Generation from Design

Proposes test specifications and drafts executable tests from the behavioural design. The test specification review decides.

Requirements and Design Review

Checks requirements and designs for ambiguity, missing cases and testability before implementation starts.

Sentinel Health Check

Scans ALM, pipeline and review data and raises warnings: changes without verification, requirements changed after review, falling coverage, skipped reviews. QA confirms or dismisses, and a warning never changes a gate.

ALM Assistant

Our MCP server for Codebeamer lets engineers and QA query the ALM in plain language and compare a project with its template, with their own permissions and read-only by default.

Release and Audit Support

Drafts release notes from the ALM and assembles evidence packs for assessments and audits. QA signs.

Standards

The evidence chain is the same in every industry, and the criteria change with the standard. Where a programme combines standards, one chain serves all of them.

Automotive

ASPICE 4.0, ISO 26262, ISO/SAE 21434

Evidence for SWE.3 to SWE.6, SUP.1, SUP.8 and SUP.10, coverage targets by ASIL, and cybersecurity work products under the same gates.

Aerospace

DO-178C, DO-330

Requirements-based test traceability, structural coverage up to MC/DC for DAL A, configuration management and QA records, and tool qualification data.

Railway

EN 50128, EN 50716

Verification and test evidence per SIL, traceability, independent verification and QA records, and configuration management.

Medical Devices

IEC 62304, ISO 14971

Unit verification and software system test evidence per software safety class, traced to the risk controls.

Energy and Industry

IEC 61508 and sector standards

Verification evidence per SIL, coverage targets and tool classification support.

How We Deploy It

Four phases, each ending with a decision you sign off. Rules come first, tools second, enforcement last. Your engineers work in the team from the first sprint, and every pipeline, configuration and document is handed over with its owner named.

Assess
6 to 8 weeks
Interviews, tool walkthroughs and a gap analysis against the applicable standards. You get the gap report, the target architecture, the plan and a proof-of-concept pipeline on one module.
Decide
4 to 6 weeks
Tool evaluation where needed, coverage targets, gate rules, team and ownership. You get a signed strategy, a confirmed toolchain and named owners.
Build
4 to 6 months
ALM configuration, pipelines, traceability, gates, dashboards, process documents and training. You get a working Software Factory on a pilot project, in observe mode.
Run and Extend
Ongoing
Warn, then enforce, project by project, and roll out to more projects on the same template, with handover to your team.

Toolchain

We build on the tools you already own and add only what is missing. Where a vendor tool does not cover a need, we build it and hand it over with its source: API integrations, dashboard widgets, pipeline steps, MCP servers and template tools.

ALM: PTC Codebeamer, Siemens Polarion
Source control and CI/CD: GitHub and GitHub Actions, GitLab CI, Jenkins
Design: Enterprise Architect with LemonTree, AUTOSAR authoring tools
Unit test and coverage: VectorCAST, LDRA
Static analysis: Helix QAC and other MISRA analysers
Compilers and targets: Green Hills, GCC and vendor toolchains, host-based and target execution
Infrastructure: Self-hosted and cloud runners, containers, infrastructure as code on Azure

Download the Guide

10 Golden Rules for a Software Factory That Works, a two-page guide: the rules we apply on safety-critical programmes, each with an example from our work, the ALM-centric architecture that puts them into practice, and a six-question check of where your programme stands. Leave your work email address and the download starts.