<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Polarion on Software Factory</title><link>/tags/polarion/</link><description>Recent content in Polarion on Software Factory</description><generator>Hugo</generator><language>en</language><atom:link href="/tags/polarion/index.xml" rel="self" type="application/rss+xml"/><item><title>Polarion/Jira integration</title><link>/use/howto/plan/jira-polarion/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/use/howto/plan/jira-polarion/</guid><description>&lt;h2 id="overview"&gt;Overview&lt;a class="td-heading-self-link" href="#overview" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Get traces of requirements and tests impacted by Agile activities&lt;/p&gt;
&lt;pre class="mermaid"&gt;---
config:
 theme: neutral
 layout: elk
---
 graph LR
 %% Définition des sous-graphes
 subgraph Polarion
 R1(Requirement)
 R2(Requirement)
 end

 subgraph JIRA
 E(Epic)
 S1(Story)
 S2(Story)
 end

 %% Relations
 E --&amp;gt; R1
 E --&amp;gt; R2
 E --&amp;gt; S1
 E --&amp;gt; S2
 S1 --&amp;gt; R1
 S2 --&amp;gt; R2 


 %% Application des styles
 class Polarion,JIRA system;
 class R1,R2,E,S1,S2 item;

 %% Ajustement de la direction
 linkStyle default stroke:#000000,stroke-width:1px;&lt;/pre&gt;
&lt;p&gt;In an Agile project, stories and epics serve as developmental artifacts. They
are instrumental in organizing sprints and are not designed to store long-term
data about needs. Therefore, it is logical to link these Agile artifacts to
requirements.&lt;/p&gt;</description></item><item><title>Polarion/Tests integration</title><link>/use/howto/plan/polarion-test-results/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/use/howto/plan/polarion-test-results/</guid><description>&lt;h2 id="concept"&gt;Concept&lt;a class="td-heading-self-link" href="#concept" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Import data from automatic test execution result files to produce conformity matrixes&lt;/p&gt;
&lt;pre class="mermaid"&gt;---
config:
 theme: neutral
 layout: elk
---
graph LR
 %% Sous-graphes
 subgraph Polarion
 R(Requirement)
 TC(Test Case)
 TR(Test Run)
 end

 subgraph Gitlab-ci
 AT(automatic tests)
 end

 %% Relations
 AT --&amp;gt;|&amp;#34;&amp;amp;lt;optional&amp;amp;gt; import&amp;#34;| TC
 AT --&amp;gt;|&amp;#34;import&amp;#34;| TR
 R --&amp;gt; TC
 TC --&amp;gt; TR
 

 class Polarion,Gitlab-ci system;
 class R,TC,TR,AT item;&lt;/pre&gt;
&lt;p&gt;Test results can be imported using two XML file formats:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://github.com/testmoapp/junitxml" class="external-link" target="_blank" rel="noopener noreferrer"&gt;JUnit file format&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;XML from Vivaldi (See Distributed Systems document)&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="junit-like-format-for-test-results"&gt;JUnit-Like Format for Test Results&lt;a class="td-heading-self-link" href="#junit-like-format-for-test-results" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;JUnit is a commonly used format for reporting test results in XML format.
Polarion supports the import of JUnit XML reports, enabling the automatic creation
or update of test runs and test results within Polarion. +
This document primarily focuses on the JUnit-like format and elaborates on the
structure necessary for importing into Polarion.&lt;/p&gt;</description></item><item><title>Traceability, conformity and conformance</title><link>/use/practices/code/traceability/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/use/practices/code/traceability/</guid><description>&lt;h2 id="overview--expected-benefits"&gt;Overview &amp;amp; Expected Benefits&lt;a class="td-heading-self-link" href="#overview--expected-benefits" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Software engineering projects that work with system engineering face key
challenges in communication, development processes, and compliance with
specifications.&lt;/p&gt;
&lt;p&gt;Five specific areas of focus typically arise and require careful attention.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Specification Transfer and Collaborative Development Processes&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;One of the primary challenges is the effective transfer of specifications from
the system engineering team to the software development team. Clear
communication and collaborative documentation are essential to ensure a mutual
understanding of requirements. Misinterpretations at this stage can lead to
significant setbacks later in the project. In a co-engineering environment,
collaboration between system and software teams is essential. Both teams must
engage in parallel activities throughout the development phase. This means
aligning their engineering efforts and providing real-time feedback to ensure
that the project adheres to system specifications.&lt;/p&gt;</description></item></channel></rss>