自動車ソフトウェア開発ライフサイクルの理解：ALM

(Understanding Automotive Software Development Lifecycle: ALM)
純粋なソフトウェア開発とは異なり、自動車ソフトウェアは自動車というハードウェア製品に依存するアプリケーション開発です。したがって、自動車ソフトウェア開発プロセスの確立/転換初期において、次の前提を明確にする必要があります：自動車ソフトウェア開発のライフサイクルは一般的なソフトウェア開発ライフサイクル（SDLC）ではなく、より広義のアプリケーションライフサイクル管理（ALM）に属します。（以下ALMと表記）
Unlike pure software development, automotive software is application development tightly coupled with physical vehicles. Therefore, when establishing or transitioning development processes, a key premise must be emphasized: The lifecycle of automotive software development follows not the standard Software Development Life Cycle (SDLC), but the broader framework of Application Lifecycle Management (ALM). (Hereafter abbreviated as ALM)
Wikipediaによると：
According to Wikipedia:
アプリケーションライフサイクル管理（ALM）とは、コンピュータプログラムの製品ライフサイクル管理（ガバナンス、開発、保守）である。これは要件管理、ソフトウェアアーキテクチャ、プログラミング、テスト、保守、変更管理、継続的インテグレーション、プロジェクト管理、リリース管理などを包含する。ALMはSDLCよりも広範な視点を持ち、SDLCが開発段階（要件～変更管理）に限定されるのに対し、ALMは開発終了後もアプリケーションが廃棄されるまで継続し、複数のSDLCを跨ぐ可能性がある。
（https://en.wikipedia.org/wiki/Application_lifecycle_management）
Application Lifecycle Management (ALM) is the product lifecycle management (governance, development, and maintenance) of computer programs. It spans requirements management, software architecture, programming, testing, maintenance, change management, CI/CD, project management, and release management. ALM provides a broader perspective than SDLC: while SDLC is confined to development phases (requirements to change management), ALM extends beyond development until the application's retirement, potentially encompassing multiple SDLCs.
（https://en.wikipedia.org/wiki/Application_lifecycle_management）
ALMの複雑性への対応：VDAの「プラグイン」概念
Addressing ALM Complexity: VDA's "Plug-in" Concept
ALMの複雑性に対し、各産業は異なる対応策を採用しています。ドイツ自動車工業会（VDA）が提案するソリューションの一つが「プラグイン」概念です。これは製品を階層（Layer）に分解するアプローチであり、システム階層が全体を統括し、ソフトウェア・ハードウェア等の部門が各役割を分担します（下図参照）。
To manage ALM's complexity, industries adopt varied strategies. The German Automotive Industry Association (VDA) proposes a "Plug-in" concept, decomposing products into hierarchical layers. The system layer provides overarching governance, while departments (e.g., software/hardware) assume specialized roles (see diagram below).

出典：ASPICE 4.0 | Source: ASPICE 4.0

自動車ソフトウェア品質システムを構築する際、ASPICEの標準要件をすべて受け入れる必要はありませんが、ALMの複雑性を考慮して階層化し、具体的なソフトウェア開発ツール群に実装することは非常に重要です。代表的な例として、シーメンスのPolarion ALMはALMを管理するツールの一つであり、以下の図に示すように、システムエンジニアリングとソフトウェアエンジニアリングの各プロセス領域をカバーしています。

When building an automotive software quality system, while it's not necessary to fully adopt all ASPICE standard requirements, it is essential to consider the complexity of ALM through layering and implement it in specific software development tool sets. As a representative example, Siemens' Polarion ALM is one of the tools for managing ALM, which covers various process areas of systems engineering and software engineering as shown in the following figure.

出典：Teamlive | Source: Teamlive

Polarion ALMデータベーステーブル構造

Polarion ALMを理解するには、公式サイトで直接そのデータベーステーブル構造を確認できます。これにより、ユーザーは二次開発を容易に行うことが可能です。ウェブ版とPDF版の2種類があり、内容は非常に詳細で、各種SQLクエリ文をそのまま書くことができます。
ウェブ版のリンク：
https://almdemo.polarion.com/polarion/sdk/doc/database/TablesReferenceIndex.html
表示画面は以下の通りです――

Polarion ALM Database Table Structure
To understand Polarion ALM, you can directly check its database table structure on the official website, which facilitates users to conduct secondary development. Both web and PDF versions are available with detailed content that essentially allows writing various SQL queries directly.
Web version link:
https://almdemo.polarion.com/polarion/sdk/doc/database/TablesReferenceIndex.html
The interface looks like this――

また、PDF形式の完全データベーススキーマは以下のリンクから入手できます：
https://almdemo.polarion.com/polarion/sdk/doc/database/FullDBSchema.pdf
ダウンロードするとこのように表示されます（下図が不鮮明でも問題ありません。PDFは拡大できます）：
Additionally, the PDF format of the full database schema is available at:
https://almdemo.polarion.com/polarion/sdk/doc/database/FullDBSchema.pdf
When downloaded, it appears like this (if the image below is unclear, no problem - the PDF can be zoomed in):

SQLクエリによるトレーサビリティ

上記のデータベース内容は複雑なため、合理的な学習方法としては実際の業務に合わせて各部分を分解して分析することです。最も頻繁に使用されるWORKITEMテーブルを例に挙げて説明します。
例：WORKITEMテーブル概要
WORKITEM（作業項目）テーブルには32のフィールドがあり、ウェブ版とPDF版での表示形式はそれぞれ以下の通りです――
Traceability via SQL Queries
Given the complexity of the above database contents, a more practical learning approach is to break down and analyze each component in the context of actual work. Let's take the most frequently used WORKITEM table as an example.
Example: WORKITEM Table Overview
The WORKITEM table contains 32 fields, with the following presentation formats in the web and PDF versions respectively――

このテーブルの主キー（Primary Key）はC_PKです。さらに、FKで始まるフィールドは外部キー（Foreign Key）として機能し、ここでは4組のフィールド（FK_AUTHOR/FK_URI_AUTHOR、FK_MODULE/FK_URI_MODULE、FK_PROJECT/FK_URI_PROJECT、FK_TIMEPOINT/FK_URI_TIMEPOINT）が、WORKITEMテーブルと他のテーブル（AUTHOR-作成者、MODULE-所属モジュール、PROJECT-所属プロジェクト、TIMEPOINT-タイムポイント）との関連性を示しています。
C_TITLE（タイトル）、C_DESCRIPTION（説明）、C_TYPE（タイプ）、C_STATUS（ステータス）、C_SEVERITY（重大度レベル）などのフィールドは、WORKITEMの各属性に対応しており、前述のASPICE統計学で言及された特性（Characteristic）を記述する変数として機能します。具体的な値は変数値となり、例えばC_TYPE（タイプ）の場合、Polarionでは各プロセス領域の作業成果物を定義することで、作業成果物の列挙値を設定する構成ファイルが生成されています。
The primary key (Primary Key) of this table is C_PK. Additionally, fields prefixed with FK indicate foreign key (Foreign Key) fields, where four sets of fields (FK_AUTHOR/FK_URI_AUTHOR, FK_MODULE/FK_URI_MODULE, FK_PROJECT/FK_URI_PROJECT, FK_TIMEPOINT/FK_URI_TIMEPOINT) establish relationships between the WORKITEM table and other tables (AUTHOR-author, MODULE-associated module, PROJECT-associated project, TIMEPOINT-time point).
Fields such as C_TITLE (title), C_DESCRIPTION (description), C_TYPE (type), C_STATUS (status), C_SEVERITY (severity level), etc., correspond to various attributes of WORKITEM and serve as variables describing the characteristics (Characteristic) mentioned in the previous ASPICE statistics discussion. Their specific values represent variable values. Taking C_TYPE (type) as an example, in Polarion, configuration files containing enumerated values for work products are generated by defining work products for each process area.

プロジェクト実施において、トレーサビリティ関連の問い合わせが頻繁に発生します。例えば：
・「顧客要求のうちシステム要求でカバーされている件数」
・「ソフトウェア要求のテストカバレッジ率」
・「テストの実施率と合格率」
これらはすべてASPICE（VDAソフトウェアASPICE 4.0参照）において明確に定義されており、下図の通りです。
During project execution, various traceability-related queries frequently arise, such as:
• "Number of customer requirements covered by system requirements"
• "Test coverage rate of software requirements"
• "Test execution rate and pass rate"
These are all clearly defined in ASPICE (refer to VDA Software ASPICE 4.0), as shown in the following figure.

Polarionでは、このような複数テーブルにまたがるクエリはUIから直接結果を得ることができず、SQLクエリを自ら記述する必要があります。では、これらのクエリはどのように記述すればよいのでしょうか？本記事では「顧客要求のうちシステム要求でカバーされている件数」という質問への回答を例に解説します。他のケースも同様の方法で対応可能です。
まず結論から示し、その後で解析を行います：

traceability.sql

SELECT W1.C_PK FROM WORKITEM W1, PROJECT proj
WHERE proj.C_ID ='Project_Name'
AND W1.C_TYPE = 'stakeholderRequirement'
AND W1.FK_URI_PROJECT = proj.C_URI
AND EXISTS
(SELECT W2.C_PK FROM WORKITEM W2,
STRUCT_WORKITEM_LINKEDWORKITEMS link
WHERE W2.C_TYPE = 'systemRequirement'
AND W2.FK_URI_PROJECT = proj.C_URI
AND link.FK_URI_WORKITEM = W1.C_URI
AND link.FK_URI_P_WORKITEM = W2.C_URI
AND link.C_ROLE = 'satisfies')

このSQL文は3つのデータテーブルを参照しています：

WORKITEM
PROJECT
STRUCT_WORKITEM_LINKEDWORKITEMS
各テーブルのフォーマットは以下の通りです（Polarion公式サイトより）：

In Polarion, such cross-table queries cannot be directly selected from the interface and require writing custom SQL queries. So how should these queries be written? This article uses the question "How many customer requirements have been covered by system requirements" as an example for explanation, with other cases being similarly approachable.
First presenting the conclusion, then the analysis:

traceability.sql

SELECT W1.C_PK FROM WORKITEM W1, PROJECT proj
WHERE proj.C_ID ='Project_Name'
AND W1.C_TYPE = 'stakeholderRequirement'
AND W1.FK_URI_PROJECT = proj.C_URI
AND EXISTS
(SELECT W2.C_PK FROM WORKITEM W2,
STRUCT_WORKITEM_LINKEDWORKITEMS link
WHERE W2.C_TYPE = 'systemRequirement'
AND W2.FK_URI_PROJECT = proj.C_URI
AND link.FK_URI_WORKITEM = W1.C_URI
AND link.FK_URI_P_WORKITEM = W2.C_URI
AND link.C_ROLE = 'satisfies')

This SQL statement involves three database tables:

WORKITEM
PROJECT
STRUCT_WORKITEM_LINKEDWORKITEMS
The table formats are as follows (from Polarion official website):

WORKITEMテーブル――
WORKITEM table――

PROJECTテーブル――
PROJECT table――

STRUCT_WORKITEM_LINKEDWORKITEMSテーブル――
STRUCT_WORKITEM_LINKEDWORKITEMStable――

まず、指定プロジェクト「Project_Name」における顧客要求の総数を選択します。顧客要求の作業項目(WI)は、WORKITEMテーブル内でタイプ(C_TYPE)が'stakeholderRequirement'として保存されており、WORKITEMテーブルはFK_URI_PROJECTフィールドを外部キーとしてPROJECTテーブル(フィールド接頭辞FKはForeign Key外部キーの略)にリンクしています。したがって、以下の文が得られます。

traceability.sql

SELECT W1.C_PK FROM WORKITEM W1,  /* WORKITEMテーブルから選択 */
PROJECT proj  /* PROJECTテーブルから選択 */
WHERE proj.C_ID ='Project_Name'  /* プロジェクト名を指定 */
AND W1.C_TYPE = 'stakeholderRequirement'  /* タイプが'stakeholderRequirement'の関連者要求を選択 */
AND W1.FK_URI_PROJECT = proj.C_URI  /* 外部キーで関連付け */

次に、これらの顧客要求WIの中で、下流のシステム要求に関連付けられているものをフィルタリングする必要があります。この場合、EXISTS文を使用します。つまり、顧客要求WIがSTRUCT_WORKITEM_LINKEDWORKITEMSテーブルのデータに関連付けられており、かつ関連タイプがシステム要求で、関連関係が「システム要求が顧客要求を満たす」ものである部分を選択します。プロジェクトを跨がない場合はプロジェクト制約を追加する必要があります。以下がEXISTSの制約文とその解析です。

traceability.sql

AND EXISTS
(SELECT W2.C_PK FROM WORKITEM W2,  /* WORKITEMテーブルから選択 */
STRUCT_WORKITEM_LINKEDWORKITEMS link  /* STRUCT_WORKITEM_LINKEDWORKITEMSテーブルから選択 */
WHERE W2.C_TYPE = 'systemRequirement'  /* 関連WIタイプが'systemRequirement'システム要求 */
AND W2.FK_URI_PROJECT = proj.C_URI  /* 同一プロジェクトに制限（プロジェクト跨ぎの場合はこの条件不要） */
AND link.FK_URI_WORKITEM = W1.C_URI  /* 関連関係の受動側はW1の'stakeholderRequirement'関連者要求 */
AND link.FK_URI_P_WORKITEM = W2.C_URI  /* 関連関係の能動側はW2の'systemRequirement'システム要求（FK_URI_P_WORKITEMのPはPrimaryを指す） */
AND link.C_ROLE = 'satisfies')  /* 関連条件は'satisfies'、つまり'systemRequirement'システム要求は'stakeholderRequirement'関連者要求を「満たす(satisfies)」ために存在（プロジェクトのadminで設定可能） */

これら2つのステップを組み合わせると、前述のSQL文が得られます。簡単でしょう？他のトレーサビリティ文も同様に、タイプと関連関係を変更すれば応用できます。
First, select the total number of customer requirements in the specified project "Project_Name". Customer requirement work items (WI) are stored in the WORKITEM table with type (C_TYPE) as 'stakeholderRequirement', and the WORKITEM table links to the PROJECT table (field prefix FK stands for Foreign Key) via the FK_URI_PROJECT field as a foreign key. Thus, we get the following statement:

traceability.sql

SELECT W1.C_PK FROM WORKITEM W1,  /* Select from WORKITEM table */
PROJECT proj  /* Select from PROJECT table */
WHERE proj.C_ID ='Project_Name'  /* Specify project name */
AND W1.C_TYPE = 'stakeholderRequirement'  /* Select stakeholder requirements */
AND W1.FK_URI_PROJECT = proj.C_URI  /* Link via foreign key */

Next, among these customer requirement WIs, we need to filter those that are already linked to downstream system requirements. Here we use the EXISTS statement, meaning we select customer requirement WIs that have relationships in the STRUCT_WORKITEM_LINKEDWORKITEMS table, where the related type is system requirements and the relationship is "system requirements satisfy customer requirements". If not crossing projects, we need to add project constraints. Below is the EXISTS constraint statement and its analysis:

traceability.sql

AND EXISTS
(SELECT W2.C_PK FROM WORKITEM W2,  /* Select from WORKITEM table */
STRUCT_WORKITEM_LINKEDWORKITEMS link  /* Select from STRUCT_WORKITEM_LINKEDWORKITEMS table */
WHERE W2.C_TYPE = 'systemRequirement'  /* Related WI type is 'systemRequirement' */
AND W2.FK_URI_PROJECT = proj.C_URI  /* Restrict to same project (not needed for cross-project) */
AND link.FK_URI_WORKITEM = W1.C_URI  /* Passive side of relationship is W1's 'stakeholderRequirement' */
AND link.FK_URI_P_WORKITEM = W2.C_URI  /* Active side is W2's 'systemRequirement' (P in FK_URI_P_WORKITEM stands for Primary) */
AND link.C_ROLE = 'satisfies')  /* Relationship condition is 'satisfies', meaning 'systemRequirement' exists to 'satisfy' 'stakeholderRequirement' (configurable in project admin) */

Combining these two steps gives us the SQL statement above. Simple, right? Other traceability statements can be similarly derived by modifying the types and relationships.