John,

We continue.

According to the textbook definition, the operating system-related part of the
development process starts at the software architecture phase. The system
developer may initially have a set of operating system alternatives to choose
from, say an RTOS or Linux or even BSD for all I know. The basic application
functionality and its (logical) requirements on the OS are defined in the
architecture phase. As processing aspects are considered, specific interfaces to
the OS are identified at the technical design stage. Probably at this stage at
the latest, the alternatives have been narrowed down to one operating
system. Extraneous OS functionality, such as communication stacks or file
systems can be eliminated and options can be chosen which defines a specific
OS configuration. Code may have to be developed to bring the OS up at run-
time.

Agree. If we exclude the run-time code, there is no "coding" (as in changing C code) involved.

However, you would expect this complete process above to be executed under some quality management (and the execution of those activities meeting some procedural requirements).

So, it is relevant to formulate the requirements that we would expect to be met for those steps in the context of "selecting and configuring a Linux kernel".

There are then OS-related aspects to the validation activities which
correspond to the various development phases.

==> The system developer selects, configures and tests an operating system:
no development is involved, neither by the system developer nor by the
operating system supplier, and by extension there is no need for a DIA.

I agree that the system developer has the task (and the responsibility) to select, configure and test the operating system.

I do not agree to the statement that "no development is involved".
You describe above a complete development step, and I believe multiple clauses in the standards apply; although, it never results in code.
It only results in a kernel build configuration, and this kernel build configuration is the interface to the operating system supplier.
The system developer wants that the operating system supplier provides "a good implementation" for this kernel build configuration.

That is the implicit DIA here. Then the operating system supplier executes an own "development process" down to the implementation (with his own V model process).

And longer question:
So, does the operating system supplier or the system developer test the operating system?
(I have an assumption here and there is again a certain split of the activities in this area.)

I think a process description should cover these insights above from you, and the assumed responsibilities here.

(If this is part of a DIA or some even more basic overview document on the process is secondary to me; we will figure it out while constructing.)

It is clear though (even if we do not have the description) that we certainly need to have the common understanding, e.g., as you described the overall process above, and one core aspect of it is "who does what". Otherwise, this mapping of ISO clauses/QM standards (ASPICE and such) to described activities is hardly to understand.

As we see in this discussion, already on the higher levels, we assume multiple "V-model like development process" happening in some interweaved and temporally decoupled way.

Documenting that as if it is "one V-model process" will probably distort the whole process assessment and that has impact on results (at least, in comprehensibility, and maybe even in the risk assessment).

There is of course, the possibility that the system developer needs custom OS
functionality, a new feature (or, to use Chris Temple's terminology, a chunk).
In which case, if the system developer can afford it, either party can develop
the feature or enhancement from scratch. Consider what Google has done
with off-tree development of Linux functionality for Android, which they
sometimes got retroactively accepted upstream. In this case, Google would be
making a DIA with itself: between its Android and Linux organisations, which is
foreseen in the definition of a DIA.

Agree. I consider this a completely new and different development process, that needs a DIA in itself.

An organization making a DIA with itself is the default. Usually, the organization using Linux will act internally and as part of the community. That does not invalidate the idea of a DIA. Still activities in the community are different than the activities that are done internally, and in the end, the quality statement comes from understanding how well both activities (internally, and in the community with others) work, and how well they "work together" (interact, are aligned, etc.).

While a system developer must choose an operating system from the flavours
and versions that are available at the time, what ELISA is actually looking at is
the interaction between the user community and the Linux development
community. The user community has the possibility to specify its expectations
on future operating system development: a DIA for future functionality in
general rather than for a specific feature development effort. The operating
system developers then have the possibility of considering the needs of the
user community when adding or modifying OS features.

Agree. That is the upfront development to the development process above.

Summarizing, we identified three "development processes":

1. Understanding the system needs and selecting and configuring the operating system appropriately. Result: kernel build configuration

2. Previous development process of the operating system (without any involvement of the own organization)
Result: source code (relevant here to the system integrator is the source code for kernel build configuration above)

3. Specific development process of the operating system (with involvement of the own organization and a clear goal towards a specific quality level)
Result: New features specifically driven by extensions of 1.

Again, 2. And 3. Intersect but it help in the discussion to separate those.

Do you agree to "all" above?

I let it sink on the mailing list and then see where such basic information must be documented for this process assessment we are executing to be comprehensible. Maybe it is just a scope section, as it is already a split of activities on a very high level, not on individual clauses.


Lukas