Comments
Description
Transcript
CMM レベル 3 に準拠した 車載向けソフトウェア開発プロセスの構築
自 動 車 ハード･ソフト 協調 要求仕様書 総合テスト設計 仕様確認書 総合テスト仕様書 総合テスト報告書 総合テスト 要求仕様書（仕様確認書） ソフト ハードウェア仕様書 担当 ソフトウェア外部設計 システムテスト報告書 システムテスト設計 システムテスト リーダが担当 システムテスト仕様書 ソフトウェア外部仕様書 基本設計 結合テスト報告書 結合テスト設計 結合テスト仕様書 基本設計書 詳細設計 結合テスト C M M レベル 3 に準拠した 車載向けソフトウェア開発プロセスの構築 設計者が担当 単体テスト報告書 単体テスト設計 単体テスト仕様書 詳細設計書 単体テスト 製作者が担当 プログラム 製 作 寺久保 敏・熊 本 博 文・出 川 裕 久 加 櫓 武 Construction of CMM Level 3 Software Development Process for Automotive ECU ─ by Satoshi Terakubo, Hirofumi Kumamoto, Hirohisa Degawa and Takeshi Karo ─ Software for automotive electronic control unit (ECU) has become complicated in recent years along with the spread of automotive LANs and the advancement of their functions. On the other hand, since abnormal operation of software affects the safety of a car and there are many copies of software in the market, quality level required for software is very high. In AutoNetworks Technologies, Ltd. and Sumitomo Wiring Systems, Ltd., in order to build a software development structure which can respond to the increased software development scale and the complication of software while maintaining or raising quality levels, Capability Maturity Model (CMM) is being adopted since 2002 and the software development process has been improved. CMM is an evaluation model developed by Carnegie Mellon University’s Software Engineering Research Institute for measuring the software development capability. It is globally adopted as a de facto standard for software development process improvement model, and attracting wide attention from many car makers and government offices in Japan. In this paper, an outline will be reported about the structure and effect of a software development process which has achieved CMM Level 3 in July 2004. 1. 緒 言 自動車に搭載される電子制御ユニット（ECU ： 中で広くデファクトスタンダードとして採用されているも Electronic Control Unit）のソフトウェアに要求される品質 のである。日本でもカーメーカーや、官庁等で広く注目さ レベルは非常に高い。ソフトウェアの不動作や誤動作が自 れている指標であることから、ソフトウェア開発プロセス 動車の安全性に対して悪影響を与える事も少なくなく、ま の改善モデルとして選定した。 た、数千台／月から数万台／月規模の製品が出荷されてい 本稿では、CMM を指標としたソフトウェア開発プロセ スの改善活動につき、具体例を交えながら紹介する。 るため、量産後の改修や交換は容易ではない。 一方、自動車に求められる快適性や利便性は年々高まっ てきており、これまでに無かった新機能が開発されたり小 型車でも標準的なドアロックやルームランプ等の既存機能 においても進化を続けたりしているため、車載 ECU の数も 2. CMM の概要と改善ポイントの明確化 2−1 CMM の構造と目標レベル CMM はソフト それぞれの ECU に実装されるソフトウェアの規模も飛躍的 ウェアプロセスの主要要素（KPA ： Key Process Area）を に増大している。（図 1）また、近年の自動車内には車載 記述する効果的な枠組みである。未成熟なプロセス（レベ LAN が複数張り巡らされており、搭載される多数の ECU ル 1）から成熟し秩序あるプロセス（レベル 5）への進化す が相互に協調動作できるよう、車載 LAN に対応できる通信 る改善経路が、5 段階の成熟度レベルで示されている。各 機能やゲートウェイ機能を装備することがソフトウェア開 レベルの概要を図 2 に示す。レベル 1 を除いて、各成熟度 発規模のさらなる増大と複雑化の原因になっている。 レベルは複数の KPA で構成されており、各レベルの構成要 ㈱オートネットワーク技術研究所および住友電装㈱（以 下、両者を総称して当社と記す）では、品質レベルを維 素である KPA が全て達成できていると判断されて初めてそ のレベルの達成と認定される。 持・向上しながら上記のソフトウェア開発規模の増大や複 CMM のモデルの定義では、図 3 に示されるように、レ 雑化に対応できるよう、2002 年から CMM（Capability ベル 3 以上から実績の改善が期待できる仕組みとなってい Maturity Model ：ソフトウェア能力成熟度モデル）を採用 る（1）こと、自動車業界ではレベル 3 あれば十分と言われて し、ソフトウェア開発プロセス改善に取り組んできた。 いる（2）ことから当社の改善活動の目標としてはレベル 3 と CMM は、米国カーネギーメロン大学ソフトウェア工学研 し、2002 年 4 月から CMM を明確に意識した改善活動を開 究所が開発したソフトウェア開発能力を測る指標で、世界 始した。改善活動の中核として後述する改善グループを組 2 0 0 5 年 3 月 ・ SE I テクニカルレビュー ・ 第 16 6 号 −（ 45 ）− ’ 90 年 代 ’ 00 年 代 ⇒ UART、単方向通信 車両動向（LAN構成） BEAN、AVC-LAN、GA-NET CAN、LIN ’ 80年代 （マイコン無し） 製品展開 J/B一体型ECU J/B一体型ECU（多重） ボデーECU （非多重） ボデーECU G/W-ECU ボデーECU（多重） センターモジュール G/W-ECU センターモジュール ボデーECU ソフトウェア規模 4k 32k 48k 96k 128k 64k G/W-ECU センターモジュール 32k （ヒーコン16∼48k） 128k CMMをモデルとしたプロセス改善活動 ◆’ 00年末 プロセス改善活動開始 開発プロセス 図1 5 オーネット研 2003年6月 Ａ社 2002年11月 Ｂ社 2001年12月 オーネット研 2002年2月 管理された（レベル4） 測定・制御されたプロセス 定義された（レベル3） 特徴が記述され、よく 理解されたプロセス 反復できる（レベル2） 以前マスターしたタスクが 反復可能なプロセス 初期（レベル1） 予測できず、制御が まずいプロセス 図2 要件管理、プロジェクト計画、 プロジェクト進捗管理、 外注管理、品質保証、構成管理 目標N-z 確 率 レベル5組織では、 継続的に実績が 改善される 時間/コスト/... 最適化する（レベル5） 継続的なプロセス改善 オーネット研 2004年7月 レベル2 レベル3 2004/7/2達成 ボデー系 ECU 開発の変遷 国内の自動車部品メーカーでレベル達成を 公表しているのは3社のみ（2005年1月末時点） レベル3が最高で、当社を含め2社が達成 レベル3 レベル2 2003/6/13達成 欠陥予防、技術変更管理、 プロセス変更管理 4 定量的プロセス管理、 ソフトウェア品質管理 組織プロセス重視、 組織プロセス定義、 トレーニングプログラム、 ソフトウェア統合管理、 ソフトウェアプロダクトエンジニアリング、 グループ間調整、 ピアレビュー CMM の 5 段階レベルの概要 目標N-y 確 率 レベル4組織では、 プロセスと成果物に対する 定量的理解に基づいて、 実績が改善され続ける 時間/コスト/... 3 目標N-x 確 率 レベル3組織では、 整った形で定義された プロセスを持ち、 実績が改善される 時間/コスト/... 2 目標N+a 確 率 レベル2組織では、 過去の実績に基づく計画が より現実的になる 時間/コスト/... 織し、プロセス改善活動で先行する関係会社や社外の専門 家にもアドバイザーとしてご協力いただきながら活動を推 進した結果、2004 年 7 月にレベル 3 の達成を公式に確認す 1 目標N 確 率 る事ができ、日本国内の自動車部品メーカーでは 2 社目の 認定を受けることができた。 時間/コスト/... 次項以降で、当社の取り組みについて述べる。 −（ 46 ）− レベル1組織では、 スケジュールとコストが 目標を上回るのが 典型的である CMM レベル 3 に準拠した車載向けソフトウェア開発プロセスの構築 図3 成熟度レベル毎のプロセス能力（1） 2−2 CMM レベル 3 との差異（GAP）および改善のポイント GAP 分析の結果から、主な改善ポイントは次の 3 つに大 目標とするレベル 3 までと、当時の当社仕組みとの GAP 分 別できる。 析を実施した結果の概略を表 1 に示す。CMM で要求され （1）体制面 ている仕組みや活動の中には当時から既に存在するものも 「品質保証」、「構成管理」、「組織プロセス重視」、「トレ 多数有ったが、明文化されたルールが存在しないものや、 ーニングプログラム」の各 KPA で、これまで明確に置 不十分なものも多数存在した。これは、当時の当社のソフ トウェア開発組織が少人数の組織であり、特に明文化され いていなかった役割の新設が必要。 （2）ルール面と活動面 たルールが不十分でも管理できる状態であったためで、近 開発チームに必要なルールは関係する全ての KPA で 未来の製品種類の増加と開発規模の増大を見越して、組織 不完全ながらも存在し、「組織プロセス重視」以外で 規模の拡大と、不足している仕組みの強化に着手した。 求められている活動も全てベースとなるものが存在し たので、既存のルールをベースとした見直しを中心と 表1 レベル KPA し、補強された新ルールに沿った活動へのスムーズな GAP 分析結果 体制 ルール 活動 検証 改善すべき主な内容 要件管理 ○ ▲ ○ ▲ 要件管理状態のレ ビューと計測 プロジェクト計画 ○ ▲ ▲ ○ 見積もり手順が無い 進捗管理 ○ ▲ ▲ ▲ 管理項目の明確化 と明文化 外注管理 − − − 品質保証 × 構成管理 × 組織プロセス重視 組織プロセス定義 ▲ ▲ × ▲ × × ▲ ▲ × ▲ （3）検証面 検証すべき観点が従来に比べて大幅に増加するが、開 発チームが従来と大差なくこなせる仕組みの構築。 − 当社のルールに基 づいて社員と一体 になった開発のた め適用外 ▲ プロセスの観点か ら品質保証する仕 組みが弱い × 構成管理計画(ベ ースライン監査や リポジトリ定義) と管理状態のレビ ューと計測 2 移行。 次章では、これら改善ポイントに対する具体的な取り組 みについて述べる。 3. CMM 準拠のプロセス構築への主な取り組み 3−1 組織体制の強化 CMM で規定されている組 織的な役割や活動として、次の 4 つがある。 ①ソフトウェアエンジニアリングプロセスグループ（SEPG） ‥‥プロセスの構築、改善、維持および管理 ②ソフトウェア品質保証グループ（SQA） ‥‥プロセス遵守 状況をチェックし、プロセス品質の確保を保証する × ソフトウェアエンジ ニアリングプロセス グループの組織 ③トレーニンググループ‥‥必要な教育の開発と実施 × プロセス資産(標 準・要領書、デー タベース、ライブ ラリ類)の定義と 維持運用 と比較的小規模であり、また対象となるソフトウェアの規 ④構成制御委員会‥‥ソフトウェアベースラインの管理 当社におけるソフトウェア開発の組織規模は数十名程度 模も数千行から数万行程度と小さく、少人数での開発とな トレーニングプログラム × × ▲ × 教育体系の定義 るため、全てを独立した組織として実現することはオーバ ▲ × ▲ × 組織の標準プロセス の定義とテーラリン グガイドの作成 ーヘッドが大きくなりすぎる状態であった。そのため、役 統合管理 ▲ 設計、製作、評価 工程の定義と責任 者の明確化 × ソフト開発チーム 外との関わりの明 確化 3 エンジニアリング グループ間調整 ピアレビュー ○ ▲ ○ ▲ × ○ ▲ ▲ ○ ▲ レビュー計画の立案 割としては明確に独立して定義するが、運用面では可能な 限り複数の機能をキーパーソンが兼任できるよう、組織定 義に工夫を凝らした。今回構築した当社の組織構成の概念 を図 4 に示す。 （1）SEPG の設置 活動の中核として、ソフト開発統括者と製品分野ご との開発責任者および専任のプロセス改善推進者か らなる委員会形式の SEPG を置いた。SEPG のアクテ ○： ほぼ仕組みが存在し、小規模な改善で対応できる ▲： 半分程度の仕組みは存在し、現状の見直しで対応できる ィビティとしては、組織全体に対して約 5 ％に相当す る規模を維持することに留意して運営した。また、 ×： 仕組みが不十分かほとんど無く、大幅な見直しが必要 プロセスの定着状況をチェックする役割を持つ SQA 活動の責任者として、最もプロセスを良く知るプロ 詳細な分析結果や取り組んだ改善活動の細目については セス改善推進者が兼任したが、SEPG と SQA の責任 紙面の制約から割愛するが、基本的には全ての KPA に関し 者をそれぞれ別にすることで、両機能の独立性を確 て改善活動が必要な状態であった。 保した。 2 0 0 5 年 3 月 ・ SE I テクニカルレビュー ・ 第 16 6 号 −（ 47 ）− トの実施結果に対して、レビュータスクを明記しており、設 SQA ソフト開発統括者 計やテストの実施と共に、レビューの実施を明確に規定して （SEPG責任者、教育責任者） 製品a向けチーム リーダ 教育TF 設計者 製作者 構成管理責任者(チーム内部でアサイン) 製品分野Ａ 責任者 製品b向けチーム リーダ 設計者 製作者 構成管理責任者(チーム内部でアサイン) 製品分野B 責任者 いる。さらに、対象製品が自動車のモデルチェンジや派生車 種向けに小変更されることが多いため、ウォーターフォール モデルとしての単純な規定だけではなく、仕様の変化点とそ れが全体に与える影響範囲や内容を十分に検討した上で、変 更が必要な部分のみに絞って適用できるルールとした。 また、今回定義したソフトウェア開発ワークフローでは、 製品c向けチーム リーダ 設計者 製作者 構成管理責任者(チーム内部でアサイン) 製品分野C 責任者 製品d向けチーム リーダ 設計者 製作者 構成管理責任者(チーム内部でアサイン) SEPG ソフトウェア開発チームの役割をリーダ、設計者、製作者 の 3 階層に分類している。それぞれが責任を持って遂行す る業務を、対応する設計とテストの組み合わせを基準に階 層的に定義しており、それぞれの分担部分を一つの標準 （責任範囲や成果物を明確に定義したルール）と従属する 複数の要領書（具体的な手順や雛形を提供）としてとりま プロセス改善推進者 （SQA責任者） とめ、各階層の担当者が参照する標準や要領書が散在しな いように整備した。 図4 組織構成の概要 要求仕様書 ハード･ソフト 協調 （2）SQA 機能の実現 SQA 活動の実務を担当する SQA 担当者に関しては、 開発チームのリーダクラスを個別にアサインし、自ら が開発チームの一員として参加しない別の開発チーム 総合テスト報告書 総合テスト 総合テスト設計 仕様確認書 総合テスト仕様書 要求仕様書（仕様確認書） ソフト ハードウェア仕様書 担当 ソフトウェア外部設計 システムテスト報告書 システムテスト設計 システムテスト リーダが担当 システムテスト仕様書 ソフトウェア外部仕様書 を監査対象とする方式を採用した。この方式はメンバ 結合テスト報告書 基本設計 ーの早期育成とプロセスの早期立ち上げを狙った取り 結合テスト設計 結合テスト 結合テスト仕様書 基本設計書 組みで、他人の管理する開発チームを第三者の立場で 単体テスト報告書 監査する形式を取ることで開発チームと SQA の独立性 詳細設計 を確保しつつ、また、開発チームのメンバーが SQA 担 詳細設計書 当者としても活動することで、プロセス遵守意識の向 設計者が担当 単体テスト設計 単体テスト仕様書 単体テスト 製作者が担当 プログラム 製 作 上と、プロセス運用方法の修得を促進している。 （3）トレーニンググループと構成制御委員会 図5 ソフトウェア開発ワークフロー トレーニンググループに関しては、ソフト開発統括者 と製品分野ごとの開発責任者の中から教育タスクフォ ース（TF）を組織し、活動を開始した。構成メンバー 3−3 開発活動の検証強化 CMM の構成上、全て の全てが SEPG としても活動しているため、SEPG の の KPA に検証（レビュー）の観点が存在し、この部分をど サブグループ的なメンバー構成となったが、運営は のように実現するかが効率化の一つのポイントになる。レ SEPG 活動とは独立させた。 ベル 2 からレベル 3 の範囲にある KPA は 13 と数も多く、効 構成制御委員会に関しては、当社が開発するソフトウ 率的なレビューを実施する仕組みの構築が不可欠である。 ェアの規模が前述の通り小規模であることから、専門 このため、従来から開発活動の進捗管理用に作成していた 組織として設置する必要性は無く開発チーム毎の管理 「プロジェクトレビューレポート」の内容を以下の観点で で十分であり、役割と責任範囲を明確にした上で、開 発チーム内部のメンバーの兼任によって実現した。 3−2 ルールの明文化と活動の定着（ソフトウェア開 発ワークフローの定義） 工程毎の成果物や責任範囲を 拡張し、定義しなおした。 新しいプロジェクトレビューレポートでは、進捗管理の 核となる管理項目は従来から強化して継承し、CMM で要 求されている全ての検証項目を網羅的に取り込んだ。新旧 明確にしやすいウォーターフォールモデルを基本として、 のプロジェクトレビューレポートに記載される主な項目を 当社のソフトウェア開発ワークフローを定義した。エッセ 表 2 に示す。これにより、プロジェクトレビューレポート ンスを抜き出して図示すると、図 5 のような V 字モデルと を見るだけで、ほとんどの KPA に対応した開発活動の検証 して表現することができる。開発者向けの詳細なワークフ が実現できるようになり、漏れのない、効率的なプロジェ ローでは、全てのソフト設計とテスト設計、および各種テス クトレビューが実施可能となった。 −（ 48 ）− CMM レベル 3 に準拠した車載向けソフトウェア開発プロセスの構築 新旧プロジェクトレビューレポート内容比較 CMM対応標準適用前 超 下 70 0以 下 ~7 50 ~5 0以 30 ~3 -1 10 0~ -1 0以 下 下 0以 未 満 満 0未 10 0~ -3 懸案リスト -5 懸案リスト -7 0~ -7 規模進捗（作成ステップ数）規模進捗（追加、削除ステップ数） 0未 満 工数消化グラフ（累積、週間） 満 工数消化グラフ（累積） -3 詳細計画 マイルストーン予実グラフ EVM（アーンド･バリュー･マネジメント） -5 詳細計画 ■（a） 50% 40% 30% 20% 10% 0% 0~ 新 版 0未 従来版 プロジェクト比率 表2 見積との乖離（％） 要件管理状況 コンピュータ資源消費状況 図7 CMM 対応標準適用前 品質指標（レビューメトリクス、テストメトリクス） 管理工数発生状況 CMM対応標準適用後 4. 超 下 70 0以 下 50 ~7 0以 ~5 0以 30 ~3 10 0~ -1 -3 改善効果 下 下 -1 10 0以 未 満 満 0未 0~ -3 0未 -7 0~ -7 -5 0未 満 開発依存関係の状況 満 見積もり根拠要件の変化状況 0~ 構成管理状況 ■（b） 50% 40% 30% 20% 10% 0% -5 プロジェクト比率 SQA 監査受審状況 見積との乖離（％） 当社がレベル 3 の達成を公式に確認したのは 2004 年 7 月 図8 CMM 対応標準適用後 2 日である（図 6）。本稿執筆時点では、レベル 3 達成プロ セスを全適用して完了したプロジェクトが無いため、今回 表3 はレベル 2 達成前後での開発工数の見積もりに対する実績 見積もりに対する実績値比率 （a）レベル 2 達成前 （b）レベル 2 達成後 ジェクトの見積もり工数に対する実績消化工数の乖離度 平 均 1.03 1.31 （％）を、図 8 はレベル 2 達成後の同様の指標をグラフ化し 標準偏差 0.56 0.25 値の乖離度を評価してみた。図 7 はレベル 2 達成前のプロ たものである。 また、見積もりに対する実績値比率の平均値と標準偏差 を表 3 に示す。 しかしながら、管理工数や設計工数が従来に比べて増加 図 7、図 8 と表 3 から、レベル 2 達成前後で標準偏差が （図 9）する事になり、そのため平均値を 3 割近く押し上げ 半減していることがわかる。これは、見積もり方法やプロ ることとなった。ルールに従って過去のプロジェクトの実 ジェクトのワークフローが定義され、ルールに従ったプロ 績（改訂前のルール適用分）ベースから工数見積もりを算 ジェクト管理や設計が遂行されるようになり、プロジェク 出する時、今回強化した管理や設計に対応する工数が控え ト間の諸般の要因差が吸収できる仕組みが構築できたこと めな値になり、それが見積もり超過の原因となっているの を示していると考えられる。 で、現行プロセスを適用したプロジェクト実績が貯まるま での一過性の現象だと考えられる。 全発生工数に占める管理工数比率 20% ◆ 15% ◆ ◆ 10% ◆ ◆ ◆ 5% ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ ◆ 20 01 20 年1 01 ~3 20 年4 月 01 ~6 20 年7 月 01 ~ 年 9 20 10 月 02 ~12 20 年1 月 02 ~3 20 年4 月 02 ~6 20 年7 月 02 ~ 年 9 20 10 月 03 ~12 20 年1 月 03 ~3 20 年4 月 03 ~6 20 年7 月 03 ~ 年 9 20 10 月 04 ~12 20 年1 月 04 ~3 20 年4 月 04 ~6 20 年7 月 04 ~ 年 9月 10 ~1 2月 0% 図6 CMM レベル 3 認定証 図9 管理工数比率の変遷 2 0 0 5 年 3 月 ・ SE I テクニカルレビュー ・ 第 16 6 号 −（ 49 ）− 5. 結 言 本報告では、当社が構築した CMM レベル 3 までに準拠 したソフトウェア開発プロセスの概要とその効果を示す一 例を報告した。車両に搭載される ECU の機能は今後益々増 大する見込みであり、高級車に新規追加された機能は順次、 大衆車・小型車まで幅広く展開されるので、今後開発すべ 参 考 文 献 （1）ソフトウェアエンジニアリング研究所、「能力成熟度モデルのキープ ラクティス 1.1 版」、CMU/SEI-93-TR-25、カーネギーメロン 大学（1993） （2）「ソフトも日々カイゼン信頼性確保のお手本に」、日経エレクトロニ クス、2004 年 3 月 1 日号、pp106-117、日経 BP 社（2004） き車載 ECU 向けソフトウェアの規模や種類は増大を続ける ことは明らかである。今回報告した仕組みもそれに合わせ て絶えず進化させる必要があり、また、変化に応じた進化を 遂げられなければ対応できなくなることは明らかである。 今後、さらなる進化と改善を継続するため、今回構築し たプロセスのメトリクス収集と分析によるフィードバック と、蓄積したプロセスデータを有機的に活用できる仕組み の構築が課題であると考えている。 −（ 50 ）− 執 筆 者 -----------------------------------------------------------------------------------------------------------------寺 久 保 敏：㈱オートネットワーク技術研究所 ソフト開発センター 熊 本 博 文：㈱オートネットワーク技術研究所 ソフト開発センター センター長 出 川 裕 久：㈱オートネットワーク技術研究所 ソフト開発センター 次長 加 櫓 武：住友電装㈱ 電子事業本部 エレクトロニクス設計部 グループ長 --------------------------------------------------------------------------------------------------------------------------------------- CMM レベル 3 に準拠した車載向けソフトウェア開発プロセスの構築