供給プロセス群 (SPL)

4.2.1. SPL.1 サプライヤー入札

プロセスID SPL.1

プロセス名 サプライヤー入札

プロセス目的 サプライヤー入札プロセスの目的は、顧客からの引き合いおよび提案依頼書

（RFP）に対応するための窓口を確立し、提案書を準備し、提出し、関連する契 約／合意を確立するまでの業務を確認することである。

プロセス成果 このプロセスを適切に実装した場合の成果は、以下のとおりである。

1) 情報伝達窓口が、顧客からの引き合いおよび提案依頼書に対応するために確 立され、維持されている。

2) 提案書を提出するか否かを決定するために、提案依頼書が定義された基準に 従って評価されている。

3) 予備調査または実現可能性調査の必要性が決定されている。

4) 適切な要員が、提案作業を実施するために識別されている。

5) サプライヤーからの提案書が、顧客依頼に対応するために準備されている。

6) 合意について正式確認が実施されている。

基本プラクティス SPL.1.BP1: 情報伝達窓口の確立 顧客からの引き合いまたは提案依頼書に対応 するために、情報伝達窓口を確立し、維持する。[成果 1]

SPL.1.BP2: 顧客からの引き合いの審査 契約が妥当であることを確認するために、

リーダーとなる適切な要員を迅速に識別して、顧客からの引き合いを審査する。[成 果 1]

SPL.1.BP3: 顧客への提案に対する評価基準の確立 提案書を提出するか否かを

適切な基準に従って決定するために、評価基準を確立する。[成果 2]

SPL.1.BP4: 顧客の提案依頼書の評価 提案依頼書を適切な基準に従って評価 する。[成果 2]

SPL.1.BP5: 予備調査の必要性の決定 入手可能な要件に基づいて確定見積り

を作成できるように、予備調査の必要性を決定する。[成果 3]

SPL.1.BP6: 要員の識別および指名 業務に対して適切な能力を持つ要員を識別 し、指名する。[成果 4]

SPL.1.BP7: サプライヤー提案回答書の準備 顧客依頼に対応するために、サプライ ヤー提案回答書を準備する。[成果 5]

SPL.1.BP8: 合意確認の確立 顧客およびサプライヤーの利害を守るために、正式に 合意を確認する。[成果 6]

備考 1: コミットメントは書面で合意し、証拠にすべきである。権限のある署名者のみが契 約に対してコミットできるようにすべきである。

アウトプット 作業成果物

02-01 コミットメント／合意文書 → [成果6]

08-12 プロジェクト計画書 → [成果4]

12-04 サプライヤー提案回答書 → [成果5]

13-04 情報伝達記録 → [成果1,6]

13-15 提案レビュー記録 → [成果3,4]

13-19 レビュー記録 → [成果2]

4.2.2. SPL.2 製品リリース

プロセスID SPL.2

プロセス名 製品リリース

プロセス目的 製品リリースプロセスの目的は、対象顧客への製品のリリースを制御することである。

プロセス成果 このプロセスを適切に実装した場合の成果は、以下のとおりである。

1) 製品リリースの内容が決定されている。

2) リリース製品が構成された品目から組み立てられている。

3) リリース文書が定義され、生成されている。

4) リリースの納入の仕組みおよび媒体が決定されている。

5) リリースが定義された基準に基づいて承認されている。

6) 対象顧客へ製品リリースが可能である。

7) リリースの確認（書）が得られている。

基本プラクティス SPL.2.BP1: リリースの機能的な内容の定義 各リリースに含むべき機能を識別した リリース計画を確立する。[成果 1, 3]

備考1: この計画は、識別した機能に影響を与える各アプリケーションパラメーターが、どのリ リースで有効となるかを示すべきである。

SPL.2.BP2: リリース成果物の定義 リリース対象成果物を定義する。[成果 1]

備考 2: リリース対象成果物には、プログラミングツールを含むことがある（記載がある場 合）。自動車業界用語において、「リリース」は、サンプルA、B、C等を指すことがある。

SPL.2.BP3: 製品リリースの分類および番号体系の確立 製品リリースの分類およ

び番号体系を、リリースの用途および期待事項に基づいて確立する。 [成果 2]

備考3: リリース番号には、以下を含む。

 主要リリース番号

 フィーチャーリリース番号

 不具合修正番号

 アルファまたはベータリリース

 アルファまたはベータリリースとしての反復回数

SPL.2.BP4: ビルド作業およびビルド環境の定義 一貫性のあるビルドプロセスを確 立し、維持する。[成果 2]

備考4: すべての関係者は、指定した一貫性のあるビルド環境を使用すべきである。

SPL.2.BP5: 構成された品目からのリリース製品のビルド リリースは、完整性を確保 するために構成された品目からビルドを実施する。[成果 2]

備考5: 該当する場合、リリース前にソフトウェアリリースを正しいハードウェアリビジョン上にプ ログラムすべきである。

SPL2.BP6: リリース製品に対するサポートの種類、サービスレベル、および期間の伝

達 リリース製品に対するサポートの種類、サービスレベル、および期間を識別し、伝達 する。[成果 3]

SPL.2.BP7: リリース用の納入媒体の種類の決定 製品の納入媒体の種類を、顧

客ニーズに従って決定する。[成果 4]

備考6: 納入媒体の種類には、中間媒体（適切な媒体に格納して顧客へ納入する）、

直接媒体（パッケージの一部としてファームウェアで納入する等）、または両方の混在があ

る。リリース製品は、サーバー上に置いて電子的に納入することもある。また、リリース製品は 納入前に複製の作成が必要な場合もある。

SPL.2.BP8: リリース媒体に対するパッケージの識別 各種媒体に対するパッケージを 識別する。[成果 4]

備考 7: ある種の媒体に対するパッケージは、物理的または電子的保護を必要とする

（例：特定の暗号化技法）。

SPL.2.BP9: 製品リリース文書／リリースノートの定義および生成 リリースを支援す るためのすべての文書が生成され、レビューされ、承認され、利用可能であることを確 実にする。[成果 3]

SPL.2.BP10: 納入前に製品リリース承認の確保 製品リリースに対する基準をリリー ス前に満足させる。[成果 5]

SPL.2.BP11: 一貫性の確保 ソフトウェアリリース番号、紙ラベル、および EPROM ラベル（該当する場合）との間の一貫性を確保にする。[成果 5]

SPL.2.BP12: リリースノートの提供リリースの主要な特性を詳細化した情報によっ

て、リリースを裏付ける。[成果 6]

備考 8: リリースノートには、序文、環境要件、インストール手順、製品起動、新規フィー チャーの識別、ならびに不具合解決、既知の不具合、および回避策の一覧を含む。

SPL.2.BP13: 対象顧客へのリリース製品の納入 受領確認を以って、製品を対象

顧客へ納入する。[成果 6, 7]

備考9: 受領確認は、手渡し、電子的手段、郵送、電話、または配送サービス業者を通じ

て行う。

備考10: 一般的に、SUP.8 構成管理プロセスが、これらのプラクティスを支援する。

アウトプット 作業成果物

08-16 リリース計画書 → [成果1,3]

11-03製品リリース情報 → [成果1,3,4,6]

11-04 製品リリースパッケージ → [成果2,3,6]

11-07 暫定的解決策 → [成果6]

13-06 納入記録 → [成果6,7]

13-13 製品リリース承認記録 → [成果5]

15-03 構成ステータス報告書 → [成果2]

18-06 製品リリース基準 → [成果5,7]