Hi Lukas, Kate
I agree with Lukas, it is reasonable to attach the DIA directly in a refinement iteration of the sheet, to avoid having another document which would have to be kept synchronized with it.
Your proposal to split the „Observed Execution of Linux Kernel" column makes sense, and should not be too difficult either
Lets try to define the contents of each column precisely (gave it a shot based on Lukas suggested column titles)
- “Activity executed by Linux Kernel Development Community”
- This column contains the aspects of the activity the standard requires to be performed, that we see executed by the Linux Kernel development community.
- It can contain things we don’t currently observe in the Kernel development community, but that make sense to be upstream activities and can reasonably expect to
be adopted by the community
- “Evidences from that execution”
- This column contains evidences we found to argue that the activities described in the column “Activity executed by Linux Kernel Development Community” are performed
- The evidence we currently have might be insufficient, or the activity in question is not yet performed in the Linux Kernel development, in that case we have a [gap]
- “Activity needed to be covered by the User”
- This column contains
- the aspects of the activity the standard requires to be performed, that we see executed by the user of the Kernel and
- the verification activities that we impose on the user to monitor and verify the Activities described in column “Activity executed by Linux Kernel Development Community”
are performed at the sufficient quality.
- Columns “Activity executed by Linux Kernel Development Community” and “Activity needed to be covered by the User” combined cover the Intent of the standard as interpreted
in the reference process “Interpretation of the Standard” column
- Everything in this column constitutes as a [gap] if not performed by the user
- Interface (artefacts) between Community and User
- This column contains all artifacts for the addressed activity the Kernel development community generates:
- From the activities described in column “Activity executed by Linux Kernel Development Community”
- Additional Artifacts needed for the user to perform the activities described in column “Activity needed to be covered by the User”
- Additional artifacts needed by the user to perform the verification activities described in column “Activity needed to be covered by the User”
Best regards,
Jochen
Von: Kate Stewart <kstewart@...>
Gesendet: Montag, 11. Mai 2020 16:02
An: Lukas Bulwahn <Lukas.Bulwahn@...>
Cc: Copperman, Elana (Mobileye) <Elana.Copperman@...>; development-process@...; Jochen Kall <Jochen.Kall@...>; MacGregor John (CR/AEX4) <john.macgregor@...>
Betreff: Re: [development-process] "Pseudo-DIA" between the Linux Kernel Development Community and its Users
toggle quoted message
Show quoted text
On Mon, May 11, 2020 at 8:23 AM Lukas Bulwahn < Lukas.Bulwahn@...> wrote:
Hi Elana,
Regarding the “template of a suitable Pseudo-DIA”, I think we need to ensure that Jochen’s columns (“the template”) covers my five points:
a. a specification of the scope, i.e., the development of an item or element
b. a definition of two parties involved in the development of that scope
c. description of activities
d. assignment of activities to each party,
e. evidences that the assignment meets the actual reality of executed activities among the two parties
f. description of resulting evidence or work products that need to be created by one party and provided as input to the other party for further activity.
I believe a. and b. can be generally covered and does not need a further column.
From my memory on Management Aspects, one proposal could be to split:
“Observed Execution of Linux Kernel” can be split into “Activity executed by Linux Kernel Development Community”; “Evidences from that execution”; “Activity needed
to be covered by the User”; “Interface (artefacts) between Community and User”.
I think we need to agree on suitable column names for that and we could then adjust the tables accordingly. Jochen, Kate and I can try to figure this out for
the Management Aspects.
Just so I'm clear here, this would be a new document, or would it be a refactoring of the one that Jochen and I were working on?
Lukas
Thanks to all for your inputs and feedback.
Lukas - can you put together a template DIA based on these conclusions, and store in Google docs?
It would be good to see a list of specific responsibilities for each party (Linux developer vs "user"), going beyond the definitions already
discussed.
Hi Lukas,
Most other safety standards (that I deal with at least) don't address the specific problem areas of volume manufacturers who rely on suppliers to supply and/or develop parts of their safety-critical systems. A significant part of the group also doesn't have
that background either. That's why I sent the email with the links before the telco.
Simply understanding how a DIA works in a normal supply chain (i.e. without open source) might be a good first step. I mean which divisions of labour (and responsibility) are possible and what the obligations and responsibilities would be for both customer
and supplier to achieve a seamless chain of evidence sufficient to satisfy a safety case might be a good first step (although, given my obvious bias, I might also say qualifying for QM rather than satisfying a safety case ;-) )
Cheers
John
BTW, if you post the document on the ELISA Tech Google Drive, we could put our comments there as well.
Mit freundlichen Grüßen / Best regards
John MacGregor
Safety, Security and Privacy (CR/AEX4)
Robert Bosch GmbH | Postfach 10 60 50 | 70049 Stuttgart | GERMANY |
www.bosch.com
Tel. +49 711 811-42995 | Mobil +49 151 543 09433 |
John.MacGregor@...
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Christian Fischer, Dr. Stefan Hartung,
Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe Raschke, Peter Tyroller
> -----Original Message-----
> From: development-process@... <development-
> process@...> On Behalf Of Lukas Bulwahn
> Sent: Donnerstag, 7. Mai 2020 15:24
> To: development-process@...
> Subject: Re: [development-process] "Pseudo-DIA" between the Linux Kernel
> Development Community and its Users
>
> The quick question after the meeting today:
>
> Where is more explanation needed?
>
> More explanation on the abstract description of the concept of a "Pseudo DIA"
> (maybe someone has a better word?)?
>
> Or should I provide some more examples of potential activities, how they may be
> described as split between the two organizations, and how the overall argumentation
> of fulfilling a procedural requirement can be described in such a way where the
> activities are split among Kernel Community and User?
>
> Do you have some specific process step in mind that might serve as a good
> example? I am happy to pick those suggestions and try to describe that as a
> Pseudo-DIA example.
>
> Lukas
>
>
>
|
