WEBVTT

00:00.000 --> 00:02.000
You

00:30.000 --> 00:32.000
You

01:00.000 --> 01:10.240
It's

01:10.240 --> 01:28.240
Hello.

01:28.240 --> 01:29.240
Hello.

01:29.240 --> 01:31.240
It's working.

01:31.240 --> 01:33.240
You can you can hear me?

01:33.240 --> 01:34.240
You can hear me.

01:34.240 --> 01:35.240
Just speak.

01:35.240 --> 01:36.240
Please call that guy.

01:36.240 --> 01:38.240
Oh, it's all the following.

01:38.240 --> 01:39.240
Okay.

01:39.240 --> 01:40.240
Thank you so much.

01:40.240 --> 01:41.240
Okay.

01:41.240 --> 01:42.240
Sorry.

01:42.240 --> 01:43.240
Say it.

01:43.240 --> 01:45.240
Go from J.

01:45.240 --> 01:46.240
Go from J.

01:46.240 --> 01:47.240
Go from J.

01:47.240 --> 01:48.240
And Puzzle.

01:48.240 --> 01:50.240
Puzzle in the School of the Knowledgeies.

01:50.240 --> 01:51.240
Okay.

01:51.240 --> 01:52.240
Okay.

01:52.240 --> 01:53.240
Hello, everyone.

01:53.240 --> 01:56.240
Today's session is about bezel.

01:56.240 --> 02:00.240
It is an open source software to

02:00.240 --> 02:03.240
three software requirements,

02:03.240 --> 02:05.240
create a possibility matrix.

02:05.240 --> 02:10.240
And it also supports the export of work item in a

02:10.240 --> 02:11.240
design as bomb.

02:11.240 --> 02:14.240
So that is the goal of this session is to

02:14.240 --> 02:17.240
present this tool that can be used to

02:17.240 --> 02:21.240
design and to maintain some work items,

02:21.240 --> 02:25.240
especially in critical software application.

02:25.240 --> 02:29.240
And how we can use this tool to export those

02:29.240 --> 02:32.240
work items in SPDX model three.

02:32.240 --> 02:34.240
That can be consumed by other piece of

02:34.240 --> 02:38.240
the tool chain in critical application.

02:38.240 --> 02:40.240
So my name is Luigi.

02:40.240 --> 02:43.240
I work at red dot and I'm a bullet engineer.

02:43.240 --> 02:47.240
And yeah, the agenda is about like an

02:47.240 --> 02:49.240
introduction of this tool.

02:49.240 --> 02:52.240
Then I will show an example of a

02:52.240 --> 02:54.240
responsibility in a software development

02:54.240 --> 02:57.240
lifecycle with the focus on automotive.

02:57.240 --> 03:00.240
That is a V model.

03:00.240 --> 03:03.240
And then we will see how we can use bezel in

03:03.240 --> 03:06.240
that context of the V model.

03:06.240 --> 03:10.240
And how we can use bezel to export

03:10.240 --> 03:13.240
an SPDX model three.

03:13.240 --> 03:16.240
And then few words around it's testing infrastructure

03:16.240 --> 03:19.240
and test results as ability that can be

03:19.240 --> 03:22.240
of some interest for the audience.

03:22.240 --> 03:26.240
So the tool has been developed at red dot

03:26.240 --> 03:30.240
as part of our approach to functionality

03:30.240 --> 03:34.240
ISO 262 compliance certification.

03:34.240 --> 03:36.240
And its name comes from one of the

03:36.240 --> 03:40.240
integrity level that the standard is describing

03:40.240 --> 03:41.240
that is a AZB.

03:41.240 --> 03:44.240
That was our target for automotive.

03:44.240 --> 03:48.240
And it was presented to a

03:48.240 --> 03:51.240
laser project of Linux Foundation.

03:51.240 --> 03:54.240
That is the acronym of enabling Linux in

03:54.240 --> 03:57.240
safety application.

03:57.240 --> 04:00.240
In 2023, and then we upstream

04:00.240 --> 04:03.240
this tool under the ELISA GitHub.

04:03.240 --> 04:07.240
So actually you can found the tool at the website

04:07.240 --> 04:09.240
that is available on this

04:09.240 --> 04:11.240
quite good.

04:11.240 --> 04:14.240
So the goal of this tool, as I said,

04:14.240 --> 04:17.240
is to be able to create

04:17.240 --> 04:21.240
work items, not only software requirements,

04:21.240 --> 04:23.240
we will see later to create

04:23.240 --> 04:27.240
those requirements to the specification

04:27.240 --> 04:32.240
and to the source code.

04:32.240 --> 04:36.240
So that is a description of how the tool works.

04:36.240 --> 04:39.240
So essentially, in basically you can specify

04:39.240 --> 04:41.240
software components with different

04:41.240 --> 04:44.240
version and you can collect in libraries.

04:44.240 --> 04:46.240
Once you specify software components,

04:46.240 --> 04:49.240
you can define your reference document.

04:49.240 --> 04:52.240
That is the base of your accessibility.

04:52.240 --> 04:55.240
So it can be yours of the specification.

04:55.240 --> 04:57.240
Yours is code, a safety manual, whatever

04:57.240 --> 05:00.240
document makes sense for your project to

05:00.240 --> 05:02.240
develop your disability on top of it.

05:02.240 --> 05:04.240
And once we have that document,

05:04.240 --> 05:10.240
define it, you can start

05:10.240 --> 05:15.240
you can start to create your work items.

05:15.240 --> 05:17.240
The same time you create work items,

05:17.240 --> 05:19.240
you are defining the traceability.

05:19.240 --> 05:21.240
Because you can specify a section of

05:21.240 --> 05:23.240
the reference document that are

05:23.240 --> 05:26.240
quite common naming as pdx,

05:26.240 --> 05:28.240
snippet.

05:28.240 --> 05:31.240
And you can attach on top of those snippets

05:31.240 --> 05:33.240
of your work items.

05:33.240 --> 05:35.240
So here, the description of which

05:35.240 --> 05:37.240
work item you can specify in

05:37.240 --> 05:39.240
the relationship that you can create

05:39.240 --> 05:40.240
inside the tool.

05:40.240 --> 05:42.240
So we can have multiple level of

05:42.240 --> 05:44.240
software requirements,

05:44.240 --> 05:48.240
nested in any way.

05:48.240 --> 05:51.240
And then we can create a test specification.

05:51.240 --> 05:54.240
Test case is justification and

05:54.240 --> 05:55.240
documents.

05:55.240 --> 05:58.240
And we can also link test results to test case

05:58.240 --> 06:01.240
is because basic comes with its own

06:01.240 --> 06:02.240
test infrastructure.

06:02.240 --> 06:05.240
But it is also able to trace test cases

06:05.240 --> 06:08.240
that are executed on external testing

06:08.240 --> 06:10.240
infrastructure.

06:10.240 --> 06:14.240
A quick overview of the work items.

06:14.240 --> 06:17.240
So essentially for software requirements,

06:17.240 --> 06:20.240
you can create an hierarchical mapping.

06:20.240 --> 06:22.240
So you can have multiple level of

06:22.240 --> 06:24.240
software requirements.

06:24.240 --> 06:26.240
Test specification are essentially the

06:26.240 --> 06:29.240
description of how to test

06:29.240 --> 06:31.240
software functionality.

06:31.240 --> 06:33.240
It comes with some information around

06:33.240 --> 06:35.240
the pre-condition, maneuver,

06:35.240 --> 06:38.240
and the expected behavior of your test.

06:38.240 --> 06:40.240
That is really disconnected by the implementation

06:40.240 --> 06:43.240
that is supposed to be described

06:43.240 --> 06:45.240
by the test case.

06:45.240 --> 06:47.240
So that is referred to the implementation.

06:47.240 --> 06:49.240
It can be also usually as

06:49.240 --> 06:51.240
embedded as a remote file.

06:51.240 --> 06:53.240
But it can be also some local

06:53.240 --> 06:55.240
file in your instance.

06:55.240 --> 06:59.240
And then we have a custom work item that

06:59.240 --> 07:01.240
is justification.

07:01.240 --> 07:03.240
We added this work item to provide

07:03.240 --> 07:05.240
the completeness of analysis.

07:05.240 --> 07:07.240
So there are software specification that

07:07.240 --> 07:09.240
not refer to multiple things that are

07:09.240 --> 07:11.240
really general purpose.

07:11.240 --> 07:14.240
So to provide that in

07:14.240 --> 07:16.240
further access or a document that

07:16.240 --> 07:18.240
described that your analysis is

07:18.240 --> 07:20.240
really complete, you can leverage

07:20.240 --> 07:22.240
this work item to say.

07:22.240 --> 07:24.240
For example, this section is related to

07:24.240 --> 07:26.240
another software component.

07:26.240 --> 07:27.240
We will take care of that in

07:27.240 --> 07:29.240
other analysis.

07:29.240 --> 07:32.240
And then document is a general

07:32.240 --> 07:34.240
purpose work item that can be

07:34.240 --> 07:37.240
of two types, file and text.

07:37.240 --> 07:39.240
In case of text, you can specify

07:39.240 --> 07:42.240
as an impact of the file.

07:42.240 --> 07:46.240
So imagine that you can refer the implementation

07:46.240 --> 07:49.240
of an API inside the file to

07:49.240 --> 07:51.240
your software specification.

07:51.240 --> 07:53.240
So you can specify it really.

07:53.240 --> 07:56.240
In bite range, where is this

07:56.240 --> 07:57.240
API?

07:57.240 --> 07:58.240
And doing that,

07:58.240 --> 08:00.240
basically also provide an

08:00.240 --> 08:02.240
automatic validation of the link.

08:02.240 --> 08:04.240
So each time you open the mapping,

08:04.240 --> 08:06.240
it will check the link is valid.

08:06.240 --> 08:08.240
So if the file change up

08:08.240 --> 08:10.240
three more or whatever you have your

08:10.240 --> 08:11.240
source code or file,

08:11.240 --> 08:13.240
now you will be notified because

08:13.240 --> 08:17.240
it will be like an invalid link.

08:17.240 --> 08:19.240
And the document can be

08:19.240 --> 08:22.240
mapped to the reference document

08:22.240 --> 08:25.240
with any kind of relationship type

08:25.240 --> 08:27.240
defined by SPDX model three.

08:27.240 --> 08:30.240
And actually, we can have only

08:30.240 --> 08:32.240
a flat level of document mapped

08:32.240 --> 08:34.240
to the specification,

08:34.240 --> 08:37.240
but the idea is to have an

08:37.240 --> 08:38.240
hierarchical mapping.

08:38.240 --> 08:40.240
So we can describe

08:40.240 --> 08:42.240
scenario like we have just

08:42.240 --> 08:43.240
as an example.

08:43.240 --> 08:46.240
We can trace the training data set of

08:46.240 --> 08:48.240
an M model to the AI model and

08:48.240 --> 08:49.240
to the specification.

08:49.240 --> 08:52.240
So just a possible application.

08:52.240 --> 08:55.240
And then we have a test run.

08:55.240 --> 08:57.240
So of test result as you

08:57.240 --> 08:59.240
want to name it.

08:59.240 --> 09:01.240
To the one, we can also link

09:02.240 --> 09:05.240
the test run configuration.

09:05.240 --> 09:08.240
And we have test run configuration

09:08.240 --> 09:10.240
because usually test cases

09:10.240 --> 09:12.240
are things that can be

09:12.240 --> 09:14.240
configurable.

09:14.240 --> 09:16.240
So the behavior of a test case

09:16.240 --> 09:18.240
can change with some parameters.

09:18.240 --> 09:19.240
So just imagine,

09:19.240 --> 09:20.240
I don't know,

09:20.240 --> 09:21.240
LTP, a suite.

09:21.240 --> 09:24.240
You can specify multiple parameters

09:24.240 --> 09:26.240
and you can really run

09:26.240 --> 09:29.240
change the behavior of the same test case.

09:29.240 --> 09:31.240
So that is the support,

09:31.240 --> 09:33.240
the test run configuration in a

09:33.240 --> 09:34.240
Yammer file that can be

09:34.240 --> 09:35.240
predefined,

09:35.240 --> 09:37.240
can be very usable.

09:37.240 --> 09:39.240
And it can be also

09:39.240 --> 09:41.240
used to map to external test

09:41.240 --> 09:43.240
infrastructure.

09:43.240 --> 09:44.240
So in,

09:44.240 --> 09:45.240
in fact,

09:45.240 --> 09:47.240
we have two kind of mapping

09:47.240 --> 09:49.240
as you saw before.

09:49.240 --> 09:50.240
There are

09:50.240 --> 09:51.240
more items that are

09:51.240 --> 09:53.240
directly mapped to the reference document.

09:53.240 --> 09:56.240
And that is the first point

09:56.240 --> 09:57.240
is a direct mapping.

09:57.240 --> 09:58.240
For those,

09:58.240 --> 10:00.240
we define not the mapping

10:00.240 --> 10:02.240
in terms of section and offset

10:02.240 --> 10:04.240
to the reference document

10:04.240 --> 10:05.240
that is translated

10:05.240 --> 10:07.240
later in a byte range in

10:07.240 --> 10:08.240
SPDX.

10:08.240 --> 10:10.240
And any relationship

10:10.240 --> 10:12.240
is also provide

10:12.240 --> 10:14.240
an information about

10:14.240 --> 10:16.240
the completeness percentage.

10:16.240 --> 10:17.240
So you can specify

10:17.240 --> 10:20.240
if a work item is enough

10:20.240 --> 10:22.240
itself to map

10:22.240 --> 10:24.240
that part of your specification.

10:24.240 --> 10:25.240
Because the goal of this tool

10:25.240 --> 10:27.240
at the end is to clarify gaps

10:27.240 --> 10:28.240
and that can

10:28.240 --> 10:30.240
is done in two ways.

10:30.240 --> 10:32.240
With these variables

10:32.240 --> 10:34.240
and with the section

10:34.240 --> 10:35.240
that doesn't have any mapping.

10:35.240 --> 10:37.240
So if you have a public instance of this tool

10:37.240 --> 10:39.240
so for any new contributors

10:39.240 --> 10:41.240
should be quite easy to understand

10:41.240 --> 10:44.240
the opportunity to collaborate

10:44.240 --> 10:47.240
and in case of indirect mapping.

10:47.240 --> 10:49.240
So if you have a nest

10:49.240 --> 10:50.240
at work item,

10:50.240 --> 10:52.240
we are calculating

10:52.240 --> 10:54.240
the completeness percentage

10:54.240 --> 10:56.240
in a waterfall

10:56.240 --> 10:58.240
in a waterfall way.

10:58.240 --> 11:00.240
So there is another section

11:00.240 --> 11:02.240
around a broken mapping

11:02.240 --> 11:04.240
because you know,

11:04.240 --> 11:06.240
anything in software development

11:06.240 --> 11:08.240
is in continuous evolution.

11:08.240 --> 11:10.240
So our software specification

11:10.240 --> 11:12.240
is going to change.

11:12.240 --> 11:14.240
Now we can have some broken mapping

11:14.240 --> 11:15.240
about the tool itself

11:15.240 --> 11:17.240
can help you automatically fix those things.

11:18.240 --> 11:22.240
Another thing that I wanted to share

11:22.240 --> 11:25.240
about it is about the version control.

11:25.240 --> 11:27.240
So this tool

11:27.240 --> 11:29.240
helps you to keep track of any changes

11:29.240 --> 11:31.240
on the work item

11:31.240 --> 11:33.240
and on the mapping that you are defining.

11:33.240 --> 11:35.240
So you will see

11:35.240 --> 11:37.240
each component about

11:37.240 --> 11:39.240
the version that is a combination of two numbers.

11:39.240 --> 11:41.240
The first one refer to the information

11:41.240 --> 11:42.240
of the work item,

11:42.240 --> 11:44.240
the second one refer to the information

11:44.240 --> 11:46.240
that we have into the relationship.

11:46.240 --> 11:48.240
So if the completeness change

11:48.240 --> 11:50.240
or the section the mapping change,

11:50.240 --> 11:52.240
you will see a change in the second number.

11:52.240 --> 11:54.240
And you can navigate the history

11:54.240 --> 11:58.240
and that can be also exported as part of the

11:58.240 --> 12:00.240
SPDXS bomb.

12:00.240 --> 12:02.240
Other few key points

12:02.240 --> 12:04.240
before moving into the

12:04.240 --> 12:06.240
core of the topic.

12:06.240 --> 12:08.240
So this tool comes with

12:08.240 --> 12:10.240
web user interface

12:10.240 --> 12:13.240
and with an HTTP

12:13.240 --> 12:14.240
API.

12:14.240 --> 12:17.240
So each section that you perform on the web user interface

12:17.240 --> 12:18.240
can be done

12:18.240 --> 12:20.240
automatically workflow

12:20.240 --> 12:22.240
with the RSTPI.

12:22.240 --> 12:24.240
It comes with a container file

12:24.240 --> 12:26.240
you can deploy it just running

12:26.240 --> 12:28.240
a batch file

12:28.240 --> 12:30.240
thanks to last collaboration

12:30.240 --> 12:32.240
that we had with a new project

12:32.240 --> 12:34.240
last weeks.

12:34.240 --> 12:36.240
And it is also a

12:36.240 --> 12:38.240
multiple mapping view

12:38.240 --> 12:42.240
so you can have multiple teams working in parallel

12:42.240 --> 12:43.240
on different topics.

12:43.240 --> 12:45.240
So someone can work on requirements,

12:45.240 --> 12:47.240
someone work on test specification,

12:47.240 --> 12:49.240
someone can implement test cases

12:49.240 --> 12:52.240
and stuff like that.

12:52.240 --> 12:53.240
OK.

12:53.240 --> 12:56.240
So I'm moving to the core of the topic.

12:56.240 --> 12:59.240
Let's see,

12:59.240 --> 13:01.240
the important of having the accessibility

13:01.240 --> 13:03.240
in safety critical application.

13:03.240 --> 13:05.240
So that is just the definition

13:05.240 --> 13:07.240
from Wikipedia.

13:07.240 --> 13:09.240
Anyone, I'm sure that anyone

13:09.240 --> 13:11.240
know the benefit of having accessibility

13:11.240 --> 13:15.240
just let me remark few things.

13:15.240 --> 13:18.240
What is a safety critical system

13:18.240 --> 13:20.240
essentially is a system

13:20.240 --> 13:23.240
whose failure or malfunction may result

13:23.240 --> 13:24.240
in one of those

13:24.240 --> 13:27.240
outcomes like that

13:27.240 --> 13:28.240
or serious injury of people

13:28.240 --> 13:30.240
loss of several damage

13:30.240 --> 13:31.240
to a keep-minded property

13:31.240 --> 13:33.240
and environmental harm.

13:33.240 --> 13:35.240
So we are dealing with that kind of

13:35.240 --> 13:37.240
application.

13:37.240 --> 13:39.240
And all the standards

13:40.240 --> 13:42.240
around those applications.

13:42.240 --> 13:44.240
No, I mentioned just few

13:44.240 --> 13:46.240
for automotive,

13:46.240 --> 13:47.240
aeronautics.

13:47.240 --> 13:49.240
There are many.

13:49.240 --> 13:51.240
Anyone is requiring

13:51.240 --> 13:53.240
accessibility.

13:53.240 --> 13:55.240
And can be used

13:55.240 --> 13:57.240
to establish and demonstrate

13:57.240 --> 13:59.240
control over the process

13:59.240 --> 14:02.240
and to simplify the impact analysis.

14:02.240 --> 14:04.240
So you know which requirement

14:04.240 --> 14:07.240
is affected by some problem

14:07.240 --> 14:10.240
that can also go back to the source code

14:10.240 --> 14:12.240
and understand where the problem is

14:12.240 --> 14:14.240
what can happen.

14:14.240 --> 14:16.240
And it was a bit,

14:16.240 --> 14:17.240
you can also help you

14:17.240 --> 14:18.240
while I had to get upset

14:18.240 --> 14:19.240
and to estimate an important

14:19.240 --> 14:21.240
because you should know

14:21.240 --> 14:24.240
what remains to be done.

14:24.240 --> 14:27.240
And that's the

14:27.240 --> 14:29.240
my personal representation of the

14:29.240 --> 14:30.240
V model.

14:30.240 --> 14:34.240
So let's see

14:34.240 --> 14:36.240
which artifacts.

14:36.240 --> 14:38.240
So a bit quick overview of

14:38.240 --> 14:40.240
the software development

14:40.240 --> 14:42.240
lifecycle, then we will see

14:42.240 --> 14:44.240
which artifacts we usually create

14:44.240 --> 14:46.240
and how we can trace those artifacts.

14:46.240 --> 14:49.240
So we have a verification branch

14:49.240 --> 14:51.240
and a validation branch.

14:51.240 --> 14:54.240
And the life of the project

14:54.240 --> 14:56.240
is in the horizontal line.

14:56.240 --> 14:58.240
So we start from a project

14:58.240 --> 14:59.240
requirement definition

14:59.240 --> 15:01.240
and the project should be

15:01.240 --> 15:03.240
for the market at the end of

15:03.240 --> 15:05.240
acceptance testing.

15:05.240 --> 15:07.240
That is the ideal workflow.

15:07.240 --> 15:10.240
And so that is the design phase

15:10.240 --> 15:12.240
when we specify project requirements

15:12.240 --> 15:14.240
that then can be explored in

15:14.240 --> 15:16.240
the system requirements.

15:16.240 --> 15:18.240
The architectural design

15:18.240 --> 15:20.240
is generating other kind of requirements

15:20.240 --> 15:23.240
to the software requirements.

15:23.240 --> 15:25.240
That are usually also

15:25.240 --> 15:27.240
in the low-level requirements.

15:27.240 --> 15:29.240
And from that time we can start

15:29.240 --> 15:33.240
building and design of our test cases.

15:33.240 --> 15:36.240
And then there is the verification

15:36.240 --> 15:38.240
the verification phase

15:38.240 --> 15:41.240
on the right side of the branch.

15:41.240 --> 15:43.240
Now where we have unit testing

15:43.240 --> 15:45.240
that are related to the

15:45.240 --> 15:47.240
software model design

15:47.240 --> 15:49.240
and continuing to accept

15:49.240 --> 15:50.240
testing.

15:50.240 --> 15:53.240
So let's see the artifacts

15:53.240 --> 15:54.240
that we can generate.

15:54.240 --> 15:56.240
So in that phase we can generate

15:56.240 --> 15:58.240
a sense of requirement.

15:58.240 --> 16:00.240
And here we have

16:00.240 --> 16:02.240
source code and test cases.

16:02.240 --> 16:04.240
And in the middle we have

16:04.240 --> 16:05.240
test specification,

16:05.240 --> 16:07.240
we generate test specification.

16:07.240 --> 16:09.240
And in the test phase we generate

16:09.240 --> 16:10.240
test reports,

16:10.240 --> 16:11.240
bugs,

16:11.240 --> 16:12.240
change requests,

16:12.240 --> 16:13.240
bug fixes,

16:13.240 --> 16:15.240
like metric request,

16:15.240 --> 16:17.240
so piece of code.

16:19.240 --> 16:22.240
That is a possible

16:22.240 --> 16:24.240
possibility that we can put

16:24.240 --> 16:26.240
in place with those work items.

16:26.240 --> 16:28.240
So we can have

16:28.240 --> 16:30.240
requirements that are generated

16:30.240 --> 16:32.240
by the top-level work items.

16:32.240 --> 16:34.240
And that can be

16:34.240 --> 16:37.240
not ever but can be refer to the

16:37.240 --> 16:38.240
source code.

16:38.240 --> 16:40.240
Then we have test specification

16:40.240 --> 16:42.240
that refer to the requirements.

16:42.240 --> 16:44.240
And test cases that refer to

16:44.240 --> 16:46.240
test specification.

16:46.240 --> 16:47.240
Test reports that

16:47.240 --> 16:49.240
links to the test cases

16:49.240 --> 16:51.240
and bug change requests

16:51.240 --> 16:54.240
fixes that link back to the test reports

16:54.240 --> 16:56.240
but can also link to the source code

16:56.240 --> 16:59.240
and to build version.

16:59.240 --> 17:05.240
So that is a possible

17:05.240 --> 17:07.240
possibility with the view model.

17:07.240 --> 17:11.240
Let's see what we can put in place

17:11.240 --> 17:13.240
with using this tool.

17:13.240 --> 17:17.240
So essentially if we use a project

17:17.240 --> 17:19.240
that is an example for

17:19.240 --> 17:22.240
using a project requirements.

17:22.240 --> 17:23.240
But we can do the same

17:23.240 --> 17:24.240
analysis for using

17:24.240 --> 17:26.240
another kind of requirement.

17:26.240 --> 17:28.240
So if we use a project requirement

17:28.240 --> 17:29.240
as a reference document,

17:29.240 --> 17:32.240
we can trace to that system requirements.

17:32.240 --> 17:34.240
So it's a software architecture

17:34.240 --> 17:36.240
requirements and

17:36.240 --> 17:38.240
low-level requirements.

17:38.240 --> 17:40.240
And we can define

17:40.240 --> 17:42.240
also the possibility of test specification.

17:42.240 --> 17:44.240
So that is the design phase.

17:44.240 --> 17:46.240
So everything that comes in the design phase

17:46.240 --> 17:48.240
can be covered by

17:48.240 --> 17:50.240
the traceability that this tool

17:50.240 --> 17:52.240
is able to provide.

17:52.240 --> 17:54.240
That's why we are interested in

17:54.240 --> 17:55.240
specific create

17:55.240 --> 17:57.240
a design as bomb.

17:57.240 --> 17:59.240
And we can also link

17:59.240 --> 18:01.240
other kind of documents

18:01.240 --> 18:03.240
to our reference document

18:03.240 --> 18:05.240
to our specification and

18:05.240 --> 18:06.240
justifications.

18:06.240 --> 18:08.240
But as I said before,

18:08.240 --> 18:10.240
this tool comes with a

18:10.240 --> 18:12.240
test infrastructure.

18:12.240 --> 18:14.240
So you can also link

18:14.240 --> 18:16.240
test cases.

18:16.240 --> 18:18.240
So you can link

18:18.240 --> 18:20.240
test cases to test specification.

18:20.240 --> 18:22.240
And test reports to test cases.

18:22.240 --> 18:24.240
So you can run the test from

18:24.240 --> 18:25.240
within Basile.

18:25.240 --> 18:28.240
And your report inside the tool.

18:28.240 --> 18:31.240
So the bomb that we are generating

18:31.240 --> 18:34.240
is around all those work items.

18:34.240 --> 18:43.240
So let's see.

18:43.240 --> 18:47.240
How we are exporting those

18:47.240 --> 18:50.240
those work items in SPDX

18:50.240 --> 18:51.240
model tree.

18:51.240 --> 18:54.240
So essentially we have a library

18:54.240 --> 18:57.240
and software component that is

18:57.240 --> 19:00.240
the API is like a file

19:00.240 --> 19:02.240
inside the DS bomb in SPDX.

19:02.240 --> 19:05.240
And it's connected to the reference document

19:05.240 --> 19:08.240
with this described relationship.

19:08.240 --> 19:11.240
And each snippet of the reference document

19:11.240 --> 19:14.240
is related to the reference document

19:14.240 --> 19:17.240
to the relationship contains.

19:17.240 --> 19:19.240
So that is the default BI,

19:19.240 --> 19:20.240
or not.

19:20.240 --> 19:21.240
So as an open source tool,

19:21.240 --> 19:23.240
anyone can change it

19:23.240 --> 19:26.240
based on their needs.

19:26.240 --> 19:28.240
And then we have software requirements

19:28.240 --> 19:31.240
that can be nested.

19:31.240 --> 19:34.240
So we have the first

19:34.240 --> 19:36.240
the top level one that is connected

19:36.240 --> 19:38.240
to the snippet of the reference document

19:38.240 --> 19:40.240
with a requirement for relationship.

19:40.240 --> 19:43.240
And each one comes with a complete

19:43.240 --> 19:47.240
and special stage that in SPDX is

19:47.240 --> 19:49.240
a kind of Boolean at the moment.

19:49.240 --> 19:51.240
Information where you have a

19:51.240 --> 19:53.240
special stage,

19:53.240 --> 19:56.240
because it's a better way to describe gaps

19:56.240 --> 19:58.240
and clarify,

19:58.240 --> 20:01.240
clarify contribution opportunities.

20:01.240 --> 20:02.240
But let's see.

20:02.240 --> 20:04.240
And then we can have nested

20:04.240 --> 20:06.240
level of software requirements

20:06.240 --> 20:08.240
that can be related to the parent one

20:08.240 --> 20:13.240
with the generates relationship type.

20:13.240 --> 20:17.240
We have also export test specification

20:17.240 --> 20:20.240
and those are trace

20:20.240 --> 20:23.240
of using the test relationship

20:23.240 --> 20:25.240
that can be referred to requirements

20:25.240 --> 20:28.240
or to a snippet of the specification.

20:28.240 --> 20:31.240
And we have test cases.

20:31.240 --> 20:35.240
So there is a test case relationship

20:36.240 --> 20:39.240
that we are using to connect test cases

20:39.240 --> 20:41.240
to test specification or requirements

20:41.240 --> 20:44.240
or directly to this snippet.

20:44.240 --> 20:46.240
So there are projects for the one

20:46.240 --> 20:48.240
is not mandatory to create requirements

20:48.240 --> 20:51.240
or not required to trace test specifications.

20:51.240 --> 20:53.240
So these two are

20:53.240 --> 20:55.240
help you to specify

20:55.240 --> 21:00.240
the workflow that better fit your projects.

21:00.240 --> 21:02.240
And then we have

21:02.240 --> 21:05.240
justification and documents that are

21:05.240 --> 21:08.240
described by the in the SDBOM

21:08.240 --> 21:11.240
with the describes for justification.

21:11.240 --> 21:14.240
Relationship and document can be used

21:14.240 --> 21:16.240
or can select any relationship

21:16.240 --> 21:22.240
from the SDX model 3 definitions.

21:22.240 --> 21:25.240
And also comes with a percentage of

21:25.240 --> 21:28.240
completeness.

21:28.240 --> 21:30.240
Yeah.

21:30.240 --> 21:31.240
Thank you.

21:31.240 --> 21:34.240
And then we have test run that are connected

21:34.240 --> 21:38.240
with evidence for two attes case.

21:38.240 --> 21:41.240
Let me two words around how we are exporting

21:41.240 --> 21:43.240
actually the data.

21:43.240 --> 21:45.240
So essentially we have each work item

21:45.240 --> 21:48.240
which has its own custom information.

21:48.240 --> 21:51.240
So we are exporting the data

21:51.240 --> 21:53.240
in the attribution text information

21:53.240 --> 21:55.240
that has pdx model 3 is providing

21:55.240 --> 21:58.240
at least in the.

21:58.240 --> 21:59.240
And we are collecting.

21:59.240 --> 22:03.240
We are creating a stringified version of

22:03.240 --> 22:08.240
the of the row of our table inside this field.

22:08.240 --> 22:10.240
So anyone can consume all the information

22:10.240 --> 22:11.240
of the work items.

22:11.240 --> 22:13.240
Because some information

22:13.240 --> 22:16.240
overlap with the standard information of

22:16.240 --> 22:17.240
spdx.

22:17.240 --> 22:20.240
So we found useful to have the information

22:20.240 --> 22:21.240
nested that way.

22:21.240 --> 22:23.240
So that I'm open to any input

22:23.240 --> 22:26.240
because that's an open question for me

22:26.240 --> 22:29.240
to have best able to communicate with

22:29.240 --> 22:32.240
other tool that actually are exporting

22:32.240 --> 22:36.240
in spdx.

22:36.240 --> 22:38.240
So let's see how it looks like.

22:38.240 --> 22:41.240
You have your, this is the web page of the application.

22:41.240 --> 22:44.240
You have a software component inside the library.

22:44.240 --> 22:47.240
And you just connect click the exposed to

22:47.240 --> 22:51.240
spdx link and you have your JSON file

22:51.240 --> 22:54.240
in the web page.

22:54.240 --> 22:57.240
And we also support the input.

22:57.240 --> 23:00.240
We start with software requirements to have

23:00.240 --> 23:02.240
a proof of concept to understand

23:02.240 --> 23:05.240
how to extend that later to other work items.

23:05.240 --> 23:09.240
But yeah, actually,

23:09.240 --> 23:11.240
there are some challenges.

23:11.240 --> 23:15.240
How to understand which kind of work items we have

23:15.240 --> 23:18.240
because everyone is specified as a file.

23:19.240 --> 23:22.240
So we are using summary to specify the type.

23:22.240 --> 23:24.240
And we read as we are exporting,

23:24.240 --> 23:26.240
we read from the attribution text,

23:26.240 --> 23:28.240
all the information.

23:28.240 --> 23:30.240
So user can upload that JSON file

23:30.240 --> 23:32.240
and see the list of requirements.

23:32.240 --> 23:34.240
Select the one that's one two important.

23:34.240 --> 23:36.240
Just can import from spdx.

23:36.240 --> 23:41.240
JSON requirement inside the tool.

23:41.240 --> 23:43.240
Two words around test infrastructure

23:43.240 --> 23:45.240
that can be of some interest.

23:45.240 --> 23:48.240
This application comes with a test infrastructure

23:48.240 --> 23:51.240
that allows people to run any kind of test

23:51.240 --> 23:53.240
suite of written in any language.

23:53.240 --> 23:56.240
Again, it's a different kind of test environment.

23:56.240 --> 23:59.240
It can be container virtual machine and physical

23:59.240 --> 24:00.240
order.

24:00.240 --> 24:03.240
How we solve that problem because

24:03.240 --> 24:06.240
that read that we have a project that is

24:06.240 --> 24:08.240
named the TMT test management tool.

24:08.240 --> 24:11.240
That solve both those questions.

24:11.240 --> 24:15.240
Essentially, it is using a YAML file

24:15.240 --> 24:19.240
to create an abstraction of test cases and test plan.

24:19.240 --> 24:22.240
And with that level of abstraction,

24:22.240 --> 24:24.240
we can run any kind of test suite

24:24.240 --> 24:26.240
so that problem is solved.

24:26.240 --> 24:30.240
But this tool also provide a provision system

24:30.240 --> 24:33.240
that can provision container.

24:33.240 --> 24:37.240
The default for basil is a federal container.

24:37.240 --> 24:40.240
So when you spin up an instance of basil,

24:40.240 --> 24:43.240
you can immediately run test on a federal container.

24:43.240 --> 24:46.240
That is the trend automatically in the tool.

24:46.240 --> 24:49.240
But you can also connect the vssh to virtual machine

24:49.240 --> 24:52.240
and to better machine.

24:52.240 --> 24:58.240
TMT is using another project that is FMF

24:58.240 --> 25:01.240
that is the acronym of flexible metadata file.

25:01.240 --> 25:04.240
That is another interesting thing that can help

25:04.240 --> 25:08.240
you to combine together multiple configuration files.

25:08.240 --> 25:11.240
The leveraging hierarchy.

25:11.240 --> 25:15.240
So you can have files inside folder

25:15.240 --> 25:18.240
and you can inherit the configuration from the other files.

25:18.240 --> 25:21.240
So that can be of some interest.

25:21.240 --> 25:22.240
In the last version,

25:22.240 --> 25:26.240
we are enabled the possibility to extend our test suite.

25:26.240 --> 25:31.240
We can trigger the execution or just navigate the result.

25:31.240 --> 25:35.240
TMT is the embedded test infrastructure.

25:35.240 --> 25:39.240
We can also trigger and trace test on GitLab CI GitHub action.

25:39.240 --> 25:43.240
And we can trace existing test run in the CANA CI.

25:43.240 --> 25:46.240
And we can trigger test in the testing format

25:46.240 --> 25:48.240
that is another project from red dot,

25:48.240 --> 25:52.240
that is testing system as a service.

25:52.240 --> 25:55.240
So you can request testing format to have a token

25:55.240 --> 26:00.240
and trigger your test on a data infrastructure.

26:00.240 --> 26:08.240
And that is a quick bit through the map of what we plan to do.

26:08.240 --> 26:10.240
So how we want to extend our work

26:10.240 --> 26:15.240
in terms of SPDX and around this tool.

26:15.240 --> 26:18.240
So if you have any questions,

26:18.240 --> 26:21.240
we are on time.

26:21.240 --> 26:24.240
I have tried to go.

26:24.240 --> 26:27.240
Any questions for us?

26:27.240 --> 26:29.240
Please go.

26:30.240 --> 26:34.240
And I can see where you are trying to do,

26:34.240 --> 26:36.240
which is a lot of it,

26:36.240 --> 26:38.240
a lot of it is about traceability.

26:38.240 --> 26:40.240
So is this,

26:40.240 --> 26:43.240
if I have existing tool,

26:43.240 --> 26:45.240
commercial tool, probably,

26:45.240 --> 26:47.240
with requirements placed,

26:47.240 --> 26:50.240
how easy to be able to transform it

26:50.240 --> 26:52.240
into this place to use battle,

26:52.240 --> 26:55.240
so I can then get traceability doing that.

26:56.240 --> 26:58.240
Safety system is a long time,

26:58.240 --> 27:00.240
so you recognize.

27:00.240 --> 27:01.240
Yeah.

27:01.240 --> 27:04.240
So how can I have enough for SPDX?

27:04.240 --> 27:05.240
Yeah.

27:05.240 --> 27:06.240
Thanks for the rest.

27:06.240 --> 27:07.240
So the question was,

27:07.240 --> 27:12.240
how we can migrate from a vendor tool to basil?

27:12.240 --> 27:17.240
So the thing is that a basil comes with an HTTP API.

27:17.240 --> 27:19.240
So you can create a simple,

27:19.240 --> 27:20.240
if you have,

27:20.240 --> 27:23.240
you can export your data from your vendor tool,

27:23.240 --> 27:26.240
be something or be something.

27:26.240 --> 27:32.240
So I have a 10 years experience in automobiles.

27:32.240 --> 27:34.240
So probably we used the same tools in the past.

27:34.240 --> 27:35.240
Yeah.

27:35.240 --> 27:37.240
I mean, you can export an Excel file,

27:37.240 --> 27:40.240
whatever the format you can export.

27:40.240 --> 27:44.240
And then you can leverage the HTTP API

27:44.240 --> 27:47.240
to inject all your data inside the tool

27:47.240 --> 27:49.240
with a Python script.

27:49.240 --> 27:51.240
I had that demo for the fire project,

27:51.240 --> 27:54.240
where they have already software requirements in file.

27:54.240 --> 27:58.240
And with one under the code line of the Python,

27:58.240 --> 28:00.240
you can replicate the same structure.

28:00.240 --> 28:03.240
They also have multiple level of requirements.

28:03.240 --> 28:07.240
So I was able to be this code line to have the same

28:07.240 --> 28:11.240
traceability in embedded.

28:11.240 --> 28:14.240
There is another use case where you can have

28:14.240 --> 28:17.240
your requirements in file in your GitHub.

28:17.240 --> 28:20.240
There are projects that are working that way.

28:20.240 --> 28:23.240
And you can still use the tool,

28:23.240 --> 28:26.240
now mapping to those files.

28:26.240 --> 28:29.240
And you will be notified on any changes of the file.

28:29.240 --> 28:32.240
So you can reflect automatically the changes in your requirements in embedded.

28:32.240 --> 28:36.240
So that's one way to work.

28:36.240 --> 28:38.240
Thank you very much, ladies.

28:38.240 --> 28:41.240
Thank you.