graph LR R[顧客<br>要件] I[マイコン<br>情報] M[BSW他<br>現成果物] O[顧客への<br>成果物] P1([派生要求<br>設計]) P2([派生<br>設計]) P3([派生<br>実装]) P4([派生<br>テスト]) P5([マイコン<br>分析]) C1([要求<br>レビュー]) C2([設計<br>レビュー]) C3([実装<br>レビュー]) C4([テスト<br>レビュー]) I --> P5 --> P2 P1 -.- C1 P2 -.- C2 P3 -.- C3 P4 -.- C4 R --> P1 --> P2 --> P3 --> P4 --> O M -.->|調査| P1 M -.->|流用| P2 M -.->|流用| P3 M -.->|流用| P4
3 車載組込みソフトウェアのプロセス
製品の特性や構造は，テスト対象としてテストの要件につながる．開発プロセスは，主にレビュー要件につながる．
3.1 派生開発のプロセス
組込みソフトウェアの開発ライフサイクルは，古来よりV字モデルが定着している．ここでは，V字モデルについては取り扱わない． 現実の活動は，派生開発が主なので対象を絞り込む．
3.1.1 ビジネス上の特殊性
車載組込みソフトの派生開発は，ビジネス上の背景から制約がある． 派生開発は，発注側がらの請負開発であり，派生要件だけでなく納期や品質基準などが設定され，開発側の工夫には限界がある． 正確には，試作的な場合と，量産品の場合でことなるが，両者の契約上の違いは不明確なため，量販品相当の対応が見られる（課題）．
3.1.2 派生開発のプロセス
製品によりプロセスが異なるが，大まかなプロセスはfig-life0 「派生開発のライフサイクル」に示すようなタスク（活動）の連鎖で表現できる．この図の角形は成果物（情報），丸形はタスク（活動）を表現している．表記はDFD（データフローダイアグラム）を使っている．
3.2 要求分析/要求設計
一般的な要求分析は，マーケティングなどの調査から進めるが，車載部品の 派生開発の基本は，部品購入先に対する一種の「請負開発」になっている．
- 何を：派生によって追加変更する機能
車種や仕向，法規制の変化，コストダウンなど個別で色々． - 何時迄に：部品として車載組込み時期から逆算したソフトの納期
時代と共に短縮化される傾向にあるが，作業内容が決まっているので限界に近い納期． - いくらで：設定された予算内
実際の部品コスト（原価）ではなく，技術研究費の予算内．
車載部品の組込み派生開発の要求分析は，限られた手持ち工数で，期間内に達成できるか？などプロジェクトマネージメント要素と，実現のための技術的な見通しの２要素がある．
graph LR R[顧客<br>要件] M[BSW他<br>現成果物] HR[保有リソース] PK[過去の実績データ] P1A([派生要求<br>仕様設計]) P1B([見積と調整]) O1[[要求仕様]] O2[[プロジェクト<br>計画]] M -.- P1A --> O1 R --> P1A --> P1B --> O2 HR -.- P1B --> |調整|P1A PK -.- P1B -->|調整<br>確定|R
3.3 マイコン分析
当該製品に用いる ECU や電子制御用 IC の詳細仕様は，同じ品名であってもチップの製造ロットによって微妙に異なる．その情報はチップメーカからリリース単位で伝えられる． ハードリアルタイム制御に対して影響の有無を確認し，対応する必要がある． この派生要件は，顧客からの要件とは非同期に発生する．
graph LR I[マイコン<br>情報] M[BSW他<br>現成果物] S5A[[ヘッダファイル<br>メモリ配置<br>仕様]] S5B[[定数変更<br>周期タスク変更<br>仕様]] P5A([変更箇所<br>抽出]) P5B([静的変更]) P5C([動的変更]) I --> P5A --> P5B --> S5A P5B -.- M P5A --> P5C --> S5B P5C -.- M
Figure 3.3 の静的変更と動的編の意味は，
静的変更とは
I/Oレジスタの新たなフラグ追加/変更など，機能的な変更．動的変更とは
I/O後の待機時間の変更や，ジッタ時間巾など動作に関連する変更．
3.4 派生設計
派生設計は，ベースとなる元の設計に対する変更なので，元の設計対象製品や用いた手法によって多様である．抽象化してタスクの成果物に着目すると，
- 外部仕様の変更
外部仕様とは，入出力のインタフェースやメモリ配置/レジスタ配置など，プログラム外部とのインタフェースのこと． - 構造仕様の変更
プログラムの構造とは内部構造の意味で，関数やテーブルなど要素の構成と識別を定義したもの． - 要素仕様の変更
要素仕様とは，構成要素である関数やテーブルのインタフェースや機能（処理）を定義したもの． ハードリアルタイムの場合，要素構成は機能分割ではなく，周期タスクなどで特別なナレッジが必要である． - テスト仕様の変更
テスト仕様とは，当該プログラムの動作を確認するテストについて定義した仕様で，テストレベルと呼ばれ単体，結合，統合，受け入れなどに分割される．
3.5 派生実装
製品の実体であるコードの変更とそのテスト（単体/単機能テスト）．この活動は，派生設計の粒度（詳細化のレベル）によってタスクの内容に差がある． 粒度の差は，変更前の構造や処理内容に対する経験的なナレッジの差が影響する．
3.6 派生開発のテスト
単体テストは，実装段階と，エビデンス（記録）用全分岐テストで行うのが一般的．
車載組込みソフトは，要素間の結合による機能の実現ではなく，周期タスクによる挙動のサンプリング制御によって動作する．この仕組みのため，一般的な結合テストで評価できない． 複雑な振る舞いにつういては，派生の影響が生じないよう，レビューが多用されている． 実機テストは，派生開発によって変化した部分を中心に，評価ボードで確認テストを行う．そのテスト設計は属人的で共通化された特別な技法は知られていない．
3.7 レビュー
派生開発は，伝統的に変化点管理と呼ばれる影響分析を行い，変更が製品の特性に影響を与えない範囲でのみの派生開発を行うレビューが行われる． ハードウェアに対する変化点管理は，長期的な信頼性（故障率）の変化を中心に行う．ソフトの場合は，過去のトラブルからのべからず集や，周期タスクの性能などが用いられる．
製品個別の属人的なタスクであり，経験とスキルによって左右される． 一部ではあるが，MISRA準拠のコードチェックなどは自動化ツールが用いられている．