Comments
Description
Transcript
組込みソフトウェアの開発力向上に向けた 施策と提言(第2部)
組込みソフトウェアの開発力向上に向けた 施策と提言(第２部) 平成１６年６月 経済産業省 組込みソフトウェア開発力強化推進委員会準備会 組込みソフトウェアエンジニアリング部会 注意 当報告書に現れる商標は全て、それぞれの所有者に属するものであり、国内および海外 において一定の権利を保有する場合があります。 第 2 部-目次 1.組込みソフトウェア開発における現状と課題 １.1 概論 1.2 組込みソフトウェア開発のエンジニアリングの現状・課題 ２ 組込みソフトウェアエンジニアリング部会の検討の経緯（詳細） 2.1 組込みエンジニアリング部会における検討の流れ 2.2 組込みソフトウェア開発における課題 2.3 組込みソフトウェア開発における課題解決策 報告書第２部は,部会での検討過程で用いた詳細な情報を掲載する. 1. 組込みソフトウェア開発における現状と課題 1.1 概論 1.2 組込みソフトウェア開発のエンジニアリングの現状・課題 1.2.1 開発技術 1.2.2 コンポーネント 1.2.3 手法・ツール 1.2.4 プロセス 1.3 個別ドメインの現状 -1- 1.1 概論 我々の身の回りの様々な製品で組込みソフトウェアが利用されるようになりつつある.これに 伴い組込みソフトウェアは従来にも増して規模が増大し,より複雑なものとなってきている.そし て,この結果,組込みソフトウェアの開発現場は様々な課題を抱えている. 本章では,組込みソフトウェアエンジニアリング部会での検討の背景にある組込みソフトウェ ア開発の現状と課題を整理した. 整理はソフトウェア工学から見たエンジニアリングとしての 現状と課題,および,個別ドメインの現状と課題という２つの視点で整理した. ソフトウェア工学による様々な成果はこれまで主としてビ 組込みソフトウェア開発の エンジニアリングの現状と課 ジネスアプリケーション領域のソフトウェアで活用されてき た.しかしながら,近年急激に拡大している組込みソフトウェ 題 アの領域ではこうしたこれまでのソフトウェア工学の成果が 必ずしも十分には活かされていない. 組込みソフトウェアではソフトウェア単独の世界ではなく, 周辺のハードウェアデバイスやプラットフォームの多様性な ど様々な要因をその開発の中で考慮することが求められ る.また様々な機器制御などを司るシステムではリアルタイ ム性を始めとする性能ファクターも重視される.これらが従 来のビジネスアプリケーションソフトウェアにはない様々な 制約となって組込みソフトウェアの開発を難しくしている. また近年の組込みソフトウェアはより多機能化が進み, 制御的な側面と情報処理的な側面を併せ持つものも増加 しており, 従来のような一人の専門家ではカバーしきれな いほどにその裾野が拡大しており,これもまた新たな課題と して浮上してきている. 組込みソフトウェア開発のための技術という観点からは,こ のような制約をいかに適切にハンドリングしていくかが重要 であり,これらに対する適切な解決策（技術）が求められて いる. 解決策の候補としては既にビジネス領域で活用され だしている様々な設計技術-例えばオブジェクト指向やＭＤ Ａ(Model Driven Architecture),あるいはコンポーネントを利 用した開発などが考えられる. また,設計資産を将来におい て有効に活用していくためのプロダクトラインなども候補と してあげることができる. また組込みソフトウェアの品質という観点からは,より高度 な検証技術の導入や,様々なツールの導入による属人性の 排除を進めていく必要がある. こうしたツールやコンポーネ ントあるいはそのベースにある手法などは誰もが共通に利 用できることが求められ標準化なども重要な検討事項とな る. 個別ドメインの現状・課題 本章では個別ドメインとして,自動車用ソフトウェア,情報家 電ソフトウェア,携帯電話ソフトウェアと産業機器向けソフト ウェアを取り上げた. 各ドメインの詳細については 1.3 節を 参照いただきたい. これらのドメインを並べて評価すると, -2- いずれのドメインも「規模・複雑さの増加」「短期間での開 発」が進行している.さらに既に指摘したが,様々な機能の融 合による「制御」と「情報処理」の混在がこれらの課題に拍 車をかける形となっている. こうした中でエンジニアリングの側面からは,前述のエンジ ニアリング側面の課題が存在すると同時に,より効率的な 再利用を実現するためのフレームワークなどへの期待が 大きい.また,実際の組込みソフトウェアの開発ではハードウ ェアやマーケットなどの影響で仕様変更が数多く入り要求 フェーズが混乱するといったケースも多発しており,要求フェ ーズの課題解決の期待が大きい. 一方,上記のような複雑系となりつつある組込みソフトウェ アの開発では,従来以上の高いマネージメント能力が必要 とされている. しかしながら,多くの組込みソフトウェア開発 はこれまでハードウェアの付帯物として扱われてきた経緯 から,適切なマネージメント手法が導入されず,また,スキルを もったマネージャも配置されないなどの課題がある.さらに 組込みソフトウェア開発のもつ様々な制約事項を加味した マネージメント手法なども未整備であるといった課題が存 在する. 組込みソフトウェア開発にお 個別ドメインの現状や課題をみても明らかなように,組込み ソフトウェアを開発している現場では,様々な課題が存在し, けるプロセス評価/改善 それらに対する適切な解決策を待ち望んでいる. こうした様々な課題を解決する上で重要となるのは,「それ ぞれの開発現場で何が問題で,どのような解決策を取るか」 を適切にナビゲートしていく技術である. ビジネスアプリケ ーション領域では CMM(Capability Maturity Model)や CMMI などが先行して利用されているが,組込みソフトウェア開発 に適した同種の手法の確立も解決すべき課題としてあげる ことができる. -3- 1.2 組込みソフトウェア開発のエンジニアリングの現状、 課題 1.2.1 開発技術 組込みソフトウェアは，家庭電気製品，自動車，携帯端末，各種制御機器などの心臓部に組 み込まれ，その機能や品質はこれら製品や機器の価値を決める最も重要な要素である．した がって，組込みソフトウェアの開発技術を高く保つことは，わが国製造業の競争力の維持にと って極めて重要である． 〔I〕 背景 オブジェクト指向技術 従来，組込みソフトウェアはそのサイズが余り大きくなか ったこと，また，比較的単純な機能の実現を行えば良かっ た事などもあって，その開発には最新のソフトウェアテクノ ロジーが用いられてこなかった．しかし，高度なユーザーイ ンタフェースやネットワーク機能など製品に要求される機能 が高級化すると同時に，利用可能なＣＰＵやメモリーなどの ハードウェア資源が高性能化したことなどによって，組み込 まれるソフトウェアが大規模化・複雑化したことにより，これ までのソフトウェア開発手法が十分に機能しなくなりつつあ る．こうした背景から，最新のソフトウェア開発技術を組込 みソフトウェアの開発に投入，あるいはそのための技術開 発を行うことが強く求められている．このような動きは欧米 では特に顕著であり，わが国もこれまで保ってきた組込み ソフトウェアでの優位性を維持するために，この分野に技 術開発を傾注することが必要である． 以下では，オブジェクト指向技術，プロダクトライン開発， ＭＤＡ，検証技術など，今後の組込みソフトウェアの開発に 必要となるソフトウェア技術について述べるとともに，それ を組み込みソフトウェア開発に有効に活用するための留意 点について触れる． 組込みソフトウェアには，高信頼性，実時間性，再利用性， ハードウェアとの協調などが要求されるが，その規模や複雑さ の増大に対処するには，オブジェクト指向技術の導入を進め なければならない．オブジェクト指向技術は，ビジネスシステ ムにおいては標準的技術として考えられているが，これまで の組込みシステムではハードウェア資源の制約などから，オ ブジェクト指向技術が十分には使われていない．しかしなが ら，コンポーネント技術による複雑システムへの対応，再利用 性，あるいは変更容易性などオブジェク技術のもつ技術的利 点を考えると，今後の組込みソフトウェアには必須の技術とな ると考えられる．最近のＵＭＬ記法や開発ツールの普及，クラ スライブラリーやコンポーネントの流通などによって，オブジェ クト技術はますます標準的な技術となっており，組込みシステ ムにこれを採用する動きは世界的な流れである．現在のオブ ジェクト指向技術は，実時間性要求をもった組込みソフトウェ -4- アの開発には不十分であるとされてきたが，実時間オブジェク ト指向技術の研究開発も活発であることから，実時間要求の 厳しい特殊なものを除いては，組込みシステムの開発にオブ ジェクト指向技術が利用されることが標準的になると予想され る． プロダクトライン開発 多数の類似製品に組み込まれるソフトウェアの開発にとっ ては，再利用技術は極めて重要である．プロダクトライン開発 は，基幹プロダクトとそれからの派生としてソフトウェアを捉え ることにより，一連のソフトウェア製品の開発のコストを低減さ せる技術である．これまでに開発した類似プロダクト群のプロ ダクトライン資産としての管理，それらからの基幹プロダクトの 抽出，差分開発による新プロダクトの構築，これらのプロセス や製品群の記述や管理などに関して技術開発が進んでいる． このような開発方法は現在でも多くの開発現場で実質的には 行われているが，プロダクトライン開発として，その定義やプロ セスを明確化し，ツール，環境及び組織を整備することに大き な意義がある．また，新しい製品群の開発では，最初からプロ ダクトラインを意識した設計やアーキテクチャの採用などを行 うことが重要である． モデル駆動型開発 プロダクトライン開発とならんで注目を集めている再利用技 術は，モデル駆動開発（ＭＤＡ）である．プロダクトライン開発 が機能の追加や増強のための技術であるのに対して，モデル 駆動開発では，アプリケーションのロジックから実装プラットフ ォームを分離することにより，アプリケーションの再利用を図ろ うとする技術である．従来，組込みシステムの開発では，性能 やハードウェア資源の問題などで，アプリケーションのロジック とデバイスやＣＰＵの制御などが絡み合ってプログラムされて いた．ＭＤＡの採用によりこれらを分離すれば，組込みソフトウ ェアの移植性を上げるうえで，大きな効果があると期待され る．ＭＤＡ技術の採用に向けて，組込みシステム用のプラット フォームの技術開発や，実時問性に関する性能上の問題の 解決などを図る必要がある．ＭＤＡは従来のコードのみに重点 を置いた開発ではなく，抽象度の高いアプリケーションやプラ ットフォームのモデルに視点をおいた開発を行おうとするもの であり，モデルの検証やコードの自動生成などによって，信頼 性の向上とコスト削減をもたらすことが期待される． 検証技術 組込みソフトウェアにとって，その信頼性は最も重要な特性 である．ソフトウェア品質の低さはそれの組み込まれた製品の 価値を下げ，リコールなどに経済的損失をもたらすのみでな く，人命などへの重大な危険をもたらす可能性がある．この点 では単なるビジネスソフトウェアとは大きな違いがある．従来， 膨大なテストによって保たれてきた組込みソフトウェアの信頼 性も，ヒューマンインタフェースやネットワーク機能などの高度 の機能の導入やサイズの増大によって従来の方法だけでは その保証を行うことが困難になりつつあり，テストと同時にプロ グラムの検証技術を積極的に導入すべき時期に来ている． 検証技術には定理証明技術などを利用して機能の正しさな -5- どを検証する方法が古くから研究開発されてきたが，検証コス トの高さなどから，現在ではより簡便なモデル検査技術に注 目が集まり，組込みシステムなどへの適用が試みられてい る．この技術は，有限状態システムの可到達性テストに帰着さ れ，従来ハードウェアの検証に用いることをターゲットして発 達してきた技術であり，例えば，インテル社などは強力なモデ ル検査スタッフを抱えている．ハードウェアに比べ状態空間の 大きいソフトェアにモデル検査を適用するには，解決すべき問 題も多いが，世界中の先進的研究開発機関でソフトウェアへ の適用に関する技術開発が行われており，その実用化も時間 の問題であると考えられる． 〔II〕 技術適用の際の留意点 ソフトウェアテクノロジーの観点から，今後の期待される重 要な技術について概観したが，最後にこれらを組み込みソ フトウェア開発に適用する際の留意点について触れたい． パソコンやワークステーションの世界でのソフトウェアテ クノロジーの進展は，世界標準仕様のハードウェアやプラッ トフォーム上で，類似性を持ったビジネスソフトウェアが数 多く開発されていることによって支えられてきた．一方組み 込みソフトウェアは本質的に個別のハードウェアへの依存 性が高く，プラットフォームや開発技術の標準化もパソコン やワークステーション上と比較して困難である．また開発さ れるソフトウェアは製品に依存して多様であり，その開発の 絶対量 (コピー数ではなく設計量)ははるかに少ない．従っ て，相対的に小さなセグメントが多く存在し，それらを中規 模チームによって開発しているという実情に即した手法や ツールの整備が必須となる．例えば手法やツールのカスタ マイズの考え方ひとつをとっても，そのアプローチは異なっ てくる．一方リアルタイム性や資源制約など，組込みソフト ウェアならではの特性に対する配慮も必要となる． 組込みソフトウェアの規模や機能が増大し，またそれを 支える CPU パワーなどが強力になるにつれ，前述したよう なパソコンやワークステーション上でのソフトウェア開発の 技術が取り入れられてくることは必然であると考えられる． その際には，パソコンやワークステーション上のソフトウェア やソフトウェア開発との類似性と，組込みソフトウェアの特 殊性とを十分に踏まえ，開発の実情に即した技術の具現化 と導入形態の検討が重要であろう． -6- 1.2.2 コンポーネント 近年のソフトウェア開発では,コンポーネントを活用して,より効率的に高品質のソフトウェア を開発する方式が定着しつつある. 組込みソフトウェアの開発においても,この傾向は同様で あり,カーネル,TCP/IP 通信,ファイルシステムなどをはじめとする各種の部品パッケージ・コン ポーネントが流通するようになってきている. 〔I〕 現状と課題 組込みソフトウェア分野でのコンポーネントに関する現状 の課題としては, ① コンポーネントの汎用性の問題 ② コンポーネントに求められる機能の高度化の問題 ③ ビジネスのマーケットの問題 ④ 技術伝承としてのコンポーネントの問題 ⑤ コンポーネント間の組み合わせの問題 などを考えることができる. コンポーネントの汎用性 /独立性の問題 ソフトウェアコンポーネントを考える場合,最も重大な問題はそ の汎用性と独立性のレベルである. 充実した機能やサービスをコンポーネントによって提供しよう とする場合,概して特定のアプリケーション,ソフトウェアやプラッ トフォームなどとの依存性が高くなりがちである.このようなコン ポーネントは高い機能やサービスを提供できる代わりに利用 に際して様々な制約を併せ持つことなり汎用性の面から課題 を抱えることとなる. 一方,コンポーネントの汎用性を追及する場合には,どのような プラットフォームでも動作し,特定のアプリケーションやソフトウ ェアの依存性をなくすために,結果的に機能面で様々な制約を 受けるといったことも発生する. コンポーネントの高機能 化の問題 近年の組込みソフトウェアは様々な機能を実装し,規模的にも 大きく複雑なものとなる傾向がある.これに対応してコンポーネ ントも多様化し,高機能が要求されるようになってきている.例え ば,最近の組込み機器の多くには通信機能が搭載されており, そのアプリケーションの実現するためにインタネットサービス やデータベースなどビジネスアプリケーション分野での技術や 知識を組込みソフトウェア向けにパッケージ化することなどが 求められるようになってきている.さらにソフトウェアコンポーネ ントに対し,ユーザから様々なニーズや要望が寄せられるよう になってきており,これらの要求や要望を満足しようとするとコ ンポーネントの規模や複雑さが膨らみ,その開発は困難を極め るといった問題も発生している.またこうした傾向はコンポーネ ントの汎用性を低下させるといった側面も併せ持っている. コンポーネントのビジネ スとしての問題 ソフトウェアコンポーネントがどの程度汎用性を持っているか, そして,どの程度のサービスや機能を提供するかで,マーケット におけるソフトウェアコンポーネントの位置づけは大きく変わ り,ソフトウェアコンポーネント・ビジネスへの影響が顕著にな る. 組込みソフトウェアに利用されるコンポーネントでは,特に -7- コストやロイヤリティなども側面も重要な要素となっている. さ らに,近年ではソフトウェア・コンポーネントに関して品質保証 が求められることも少なくない.これらを踏まえてコンポーネント 事業をどのようなビジネスモデルに乗せていくかが今後の組 込みソフトウェア産業の中でも大きな課題になると考えられる. 技術伝承としてのコンポ ーネントの問題 組込みソフトウェアにおけるソフトウェアコンポーネントは制御 系を始めとする特殊（専門的）技術のパッケージ化という側面 を持っており,これは技術の伝承という観点と深い関係をもつ. 特殊性や専門性をもつシステムやミドルウェアの部分部分は 多くの場合,個人スキルに依存しており,これらをコンポーネント として如何に体系化し,整理していくかがコンポーネント化を進 めていく上での大きな課題となっている. コンポーネントの組み合 わせの問題 現在の組込みソフトウェア開発では,単一の組織、企業内に閉 じた開発プロジェクトは少なくなりつつあり,よりオープンな開発 スタイルが主流となってきている.このような状況下では,複数 のコンポーネントベンダーが提供する複数のコンポーネントを 組み合わせて一つの製品をくみ上げるといった形が想定され るが,このようなコンポーネントの組み合わせの際にそれらの 整合性などで問題が発生する. また,そのような状況を適切に 捌くことのできるハイレベルなプロジェクトマネージャの不足 や,開発終盤でのコンポーネントに起因する不具合情報刷り合 わせなども課題となってくる. 〔II〕 コンポーネントビジネス 組込みソフトウェア分野でのコンポーネントビジネスを考え における日本の優位性 た場合,日本は下記のような点で優位性をもっていると考え られる. ① 世界的に見て日本はコンシューマ向け組込み製品 が最も進歩している国の一つである.このため,組込 みソフトウェアに対するニーズの大半は、わが国か ら発生する. 即ち、わが国は組込みパッケージの大 きな市場となっており,市場ニーズの把握、動向調 査、ビジネスチャンスなどにおいて、わが国の組込 みソフト開発者は大きな地理的優位性をもっている. ② 組込みパッケージは,多様なハードウェアプラットフ ォームに対応できるようカスタマイズが必要である. この点で間近なサポートを可能とする①の地理的 優位性は大きなものがある。 ③ わが国の製品メーカの多数は、海外にも開発拠点 をもっていたり、国際的な標準化活動を展開したり している。それを経由して国内で製作した組込みソ フトウェアを世界に頒布できる可能性がある。 しかし,現実に上記のような優位性を有しているにもかかわ らず,国内の組込みソフトウェアメーカやコンポーネントベン ダーが,これらの優位性の恩恵を必ずしも享受していない. 今後の日本における組込みソフトウェア産業の育成・強化 を考えた場合,如何にしてこれらの恩恵を享受し,競争力を もった産業に育てていくかが大きな課題となる. -8- 〔III〕 次世代のイメージ 様々なデバイス技術,通信要素技術などの進化によりユビ キタス社会の入り口が見えようとしており,今後,数年の間に 本格的なユビキタス社会が到来することが予想される.こう したユビキタス社会を支えるものの一つが組込み製品であ り,そこに使われる組込みソフトウェアであろうことは容易に 想像ができる. ユビキタスに対応したコ ンポーネントの進化 ユビキタス時代の組込みソフトウェアは現在以上に高機能化 が求められ, OS やプラットフォームの進化と通信と融合した機 能の多様化が想定できる. この中でソフトウェアコンポーネン トも現在以上の進化が予想される. 組込みソフトウェアで利用 されるコンポーネントは,情報処理機能を中心としたものと,リア ルタイム処理/制御を中心としたものに２極化していく. 前者は より汎用性が高いレベルでのコンポーネント化が進み,それに よって組込みソフトウェアの品質や生産性向上に寄与すること が予想される.一方,後者は組込みソフトウェアのプラットフォー ムの多様性など特殊性のある技術や課題が影響するため,も う一段階のブレークスルーが必要とされる可能性が高く,欧米 を始めとする諸外国との技術競争の場となる可能性がある. 組込みシステムの複合 化への対応 ユビキタス時代の組込みシステムは家電製品,通信機器など 様々なシステムが相互に連動して動作するようになると考えら れる.これに伴いシステム的には更なる複雑さが加わる一方で 開発期間はより短期開発が志向されると思われる.このような 状況下ではドメイン毎のプラットフォームなど粒度の大きなコ ンポーネントなども今後必要となってくる,こうしたテーマについ ては単独の企業での推進よりは業界団体や標準化団体,政府 機関などを含めた議論が必要となる. -9- 1.2.3 手法・ツール ソフトウェアの進化はその開発手法や開発ツールの進化とともに進んできた. 特に近年の 組込みソフトウェアのように大規模・複雑化が進んでくると,如何に適切な開発手法や開発ツ ールを利用するかがビジネス面での成否にも大きくかかわってくる. 〔I〕 背景 メインフレームの時代 メインフレーム時代は日の丸コンピュータを御旗に,設計表記 法 PAD1,自動コード生成,リバースエンジニアリングなど様々な 手法やツールが開発された。またメインフレーム時代はマシン 使用時間の制約から,机上検査やドキュメンテーションに充分 な時間を費やされていた. パソコンの時代 パソコン時代になると米国 OS ベンダーから提供されるワープ ロ、ドローイングツールを利用し設計が行われるようになった. そしてメインフレーム用の国産ツールの多くはパソコン用に移 植されることなく消え失せた。 またパソコン時代にはコンパイル、テスト、デバックの自由度 が増し,机上検証は軽視される一方で,コード中心の開発（コー ドが動けば OK 的文化）に急激に傾斜していった. ユビキタスの時代 現在,多くのソフトウェア技術者は海外製ツールを習得（学習） して米国 OS や DB ベンダーの認定(書)を受けて仕事をしてい る.この結果,新しい手法・ツールを創造するよりは、新しい手 法・ツールを学ぶことが重視され、問題発見・解決能力は極め て心許無い状況になってきている. 日本の電子立国を継引してきた家電や自動車が,これからの ユビキタス時代に引き続き世界をリードし,わが国が組込みソ フトウェア立国となるためには,オリジナルな手法・ツールを検 討していく必要がある。 〔II〕 手法・ツールの現状 1 1960 年代以降,情報の世界の主役はメインフレーム,パソコ ンと移り変わってきた.そして 21 世紀,ユビキタス時代が到来 しようとしている。ユビキタス時代にはデジタル家電,自動車 といった組込み製品が主役になると考えられる。 従来とこれからの組込みソフトウェアの違いは何か？従来 の組込みソフトウェアのドメインが制御型領域であったのに 対し、これからの組込みソフトウェアは制御型領域と情報 処理型領域、そしてこの 2 つの領域を結びつけるプラットフ ォームという 3 種類のドメインから構成される点である。 Problem Analysis Diagram（日立製作所考案） - 10 - 制御型ドメイン 従来からある制御ドメインは、大雑把に言えば、機械的、アナ ログ的にハードウェアで制御していたものを、電子的、デジタ ル的にソフトウェアでの制御に置き換えることであった。電子 化、マイコン化に置き換えるためのツールや手法が必要とさ れ、コンパイラやデバッガ、RTOS2が「IT:実装技術」として整備 されてきた。これからの組込みソフトウェアでも「IT:実装技術」 の重要性は変わらない。 複合ドメイン 制御・情報・プラットフォームの複合ドメインでは、消費者（利 害関係者）に満足されるサービス（要求）を「獲得」「表記」そし て「検証」する新たな手法やツールを求めている。 このようなドメインでは従来提供されていたものをいかに効率 良いものに代替するかではなく、ユビキタス時代により機器同 士が接続されて、従来無かったサービスを創造する。このた め、要求仕様が決まらず、要求変更が発生する。しかしながら 現在は要求獲得技術が必ずしも体系化されておらず、個々の 技術者の経験や性格に依存している。「RE:要求獲得＆要求 定義」における問題解決が大きな課題としてクローズアップさ れる.このため要求を「獲得」「記述」「検証」するための手法・ツ ールを整備することが、複合ドメインを扱うこれからの組込み ソフトウェアに対して急務であるといえる. 〔III〕 手法・ツールの課題 要求の「獲得」、「記述」、「検証」は相互に関連しているが、 その軸は「記述」、つまり表記法(Notation)となる。システム 開発（商品開発）として、プロジェクト推進中に、利害関係者 を含めて関係者間で情報を共有し認識する記述手法が必 要となる. 事例-SDL 「RE:要求獲得＆要求定義」の表記法はドメインを限定する といくつかの成功例は見て取れる。例えば、ドメインを OSI3基 本参照モデル通信仕様と限定すれば、ITU4勧告で規定される SDL5が採用されている。表記法は ITU の WG で 4 年に 1 度く らいの割合で改訂される。ちなみに SDL を支援するツールとし ては北欧企業の１社がほぼ独占状態を占めている。画面制御 仕様をドメインとすると状態遷移図をベースにした表記法（通 称スゴロクチャート）が主に採用されているが、それぞれ支援 するツールごとに方言があり、ツール間のデータ互換性はな い。連続系制御をドメインとして、数式モデルをブロック図と状 態図で記述する。この分野のツールは米国企業 1 社に寡占さ れている。 事例-UML OMG6から UML7がオブジェクト指向モデリングのための統 一言語として登場した。UML はドメインを限定しない。UML を 支援するツールは商用、フリーも合わせると世界中に 100 以 2 Real Time Operating System 3 Open System Interconnection International Telecommunication Union Specification and Description Language 4 5 - 11 - 上も存在する。ちなみにその中でデファクト的な位置にあるの は、UML 表記法の元になった表記法を提唱した３人のエンジ ニアを集めた米国企業のツールである。UML では、組込みシ ステムに重要な非機能要求への取組みが貧弱である。UML で記述した機能モデルと、UML 以外の表記法で記述された非 機能要求を合わせて「検証」できないことが、UML が本格的に 組込みソフトウェア開発現場に浸透していない理由の１つであ ろう。 6 7 手法・ツールの課題 複合ドメインを対象とした手法・ツールの課題は次の 2 点であ ろう。 ・ 機能要求モデルと非機能要求モデルを混在するため の手法の確立 ・ 既存資産を上手く活用できるツールの整備 手法の標準化への対応 また、技術論ではないが、手法・ツールに関して、次のようなこ とが気がかりである。RE の軸である「表記法」を海外で運営さ れる団体で規格化され、その規格に対応するツールが規格と ほぼ同時に市場に出る。日本は規格、ツールを習得するのに 時間をとられ、やっと理解したところで次の規格、ツールが出 てくる。規格、ツールに振り回され、何故その規格になるの か、次はどのような規格にするかといった思考を停止される。 このため国内で問題を産業界側で提示し、解決案を大学で提 案するといった産学連携がない状況になりがちである。大学 側も企業側なりのスポンサーがないため、海外の成果をひた すら咀嚼するだけになりかねない。組込みで成功している ITRON は日本の土俵で規格化し、そのメンバーがカーネル、 ツールを開発したことが成功の要因の１つである。 Object Management Group Unified Modeling Language - 12 - カバーするプロセス の範囲 上流 開発方法論 マネジメント プロセス 開発環境 支援プロセス 開発手法 要求定義 設計 開発ツール コーディング 構造化プログラミング 下流 1960 1970 図 1. 1 〔IV〕 手法・ツールの将来 1980 1990 2000 時期 ツールの変遷 3 年後くらいを目処とした次世代の手法・ツールとして期待 できるものは次の３つであろうか。 (1) ドメイン毎に用意された要求定義手法とそれを支援す るツール (2) 上流工程から下流工程までのトレーサビリティが証明 された開発手法とそれを支援するツール (3) モデルを最新のデバイス上で実行可能とするモデルコ ンパイラ 要求定義手法 次世代組込みのドメインが明確に定義されることで、要求工 学、表記法、自動検証といった分野のソフトウェア工学が次世 代組込みソフトウェア開発の現場に適用される。 上流から下流までのト レーサビリティ 「RE:要求獲得＆要求定義」の１つの要求定義項目をクリック すると、その要求定義に適用された「DM:設計技術」、「IT:実装 技術」、「VV:検証及び妥当性確認」が表示され、それぞれの 項目をクリックするとより詳細な情報を得ることが出来る。 RE,DM,IT,VV 間のトレーサビリティは形式仕様記述により証明 され、RE レベルでテストされたことは、DM,IT,VV で再度確認の ために行う必要は無い。RE-DM-IT 間のトレーサビリティは数 学的に証明されており、従来膨大なテスト工数は大幅に削減 されることになる。 モデルベースの開発 DM(設計技術)では RE（要求獲得&要求定義）を実現する ための最適な命令や並列性を持たせた IT（リコンフィグラブ - 13 - ルチップ）へとモデルをマッピングする。従来職人的なエン ジニアの個人の経験と勘で行われていたアーキテクチャ設 計は、アーキテクチャパターンとして資産化される。 〔V〕 優位性 ユビキタス時代を牽引する家電や自動車、さらにそれを支 える半導体を保有する我国は、それだけで海外に比べると 優位性があると思われる。これから必要とされる「RE:要求 獲得＆要求定義」には、徹底したドメインの分析が必要不 可欠に思える。ドメイン特化開発は再利用を促進するプロ セスモデルとなる。知識工学では対象とする分野を調査 し、エキスパートシステムやニューラルネットワークの構築 の鍵となる要素を抽出する。ドメイン特化開発では、同一ド メインにおいて再利用できるオブジェクトやアーキテクチャ パターンが抽出される。 - 14 - １.2.4 プロセス 組込みシステム開発は我が国の産業の牽引役となる重要な産業の一つである.しかしながら,こ れまでは技術者個々人の能力に依存する形態が主流となっていた.近年の組込みシステム開発 では大規模化,複雑化,短納期化が進んでおり,個人の能力に頼る開発形態は限界にさしかかって いる.このような状況を打開する上でソフトウェアプロセスに着目したアプローチは極めて重要と考 えられる. . 〔I〕 組込みソフトウェア開発 近年の組込みソフトウェアは大規模複雑化が進み、限られた CPU 能力とメモリ資源の中で,効率的に高品質なソフトウェア のプロセスの現状 を開発する技術が重要視されている。このような状況で開発 現場から見た組込みソフトウェアの開発プロセスの現状を整 理すると以下のとおりである場合が多い. 作業標準の欠如 組込みソフトウェアの開発では,開発工程や作業内容に関して 核となる標準化が図られていない. この結果プロジェクトごとに開発方法が異なり成果物（ソフトウ ェアのアーキテクチャやドキュメント）の体系がバラバラになる といった状況が発生している. 個人スキル依存の開発 実際の開発では、個人レベルで要求を分析、設計、実装、テ ストする基本パターンがあり、同じ人であれば開発手順やソフ トウェア構造はある程度安定している。組込みソフトウェア開 発の多くは個人のスキルに依存した開発形態であり,結果とし てソフトウェアの信頼性や生産性も個人スキルに依存せざる を得ない. このような個人依存の開発プロセスのままでは,産業としての 組込みソフトウェアの信頼性は十分に保証できない. プロセスに基づくコント ロールの欠如 組込みソフトウェア開発では核となる作業標準などが十分整 備されず,個人スキルに依存した開発形態が続いている.この 結果,ソフトウェアプロセスという概念に基づいた開発の適切な コントロールもままならない状況にある. 結果として,開発の途 中で課題が発生してもプロセスとしての歯止めをかけることが 難しいなど多くの課題が繰り返し発生している. また,プロセスの確立が安定したソフトウェア開発をもたらすと いう意識の欠如は,プロセス評価に基づく適切なプロセス改善 をも難しくしている. 〔IＩ〕 プロセスを取り巻く現状 プロセス関連の手法・標 準の開発 上述のような組込みソフトウェア開発におけるプロセスに関 する現状を打開すべく,近年,CMM や CMMI などソフトウェア プロセスに関する注目が集まっている.プロセスを取り巻く 状況は,手法・標準の開発・制定という側面とこれらの運用 という二つの側面を考える必要がある. ソフトウェア開発のためのプロセス定義については ISO/IEC12207 として標準的なプロセスの考え方が提示されて おり, 国内でもこれをもとに共通フレームなどが制定されてい る.また,こうした標準的なプロセスに対して,実際の各開発組織 - 15 - でどの程度そのプロセスが整備され実施されているかを評価 し改善を促す技術として CMM や CMMI に代表されるプロセス 評価改善手法が提案されている.これについても国際標準とし て ISO/IEC15504 が制定され,これを参考に国内でも JISA や日 科技連などでモデル化を進めている. これらのモデルの多くは,ビジネスアプリケーションあるいは組 込みソフトウェアといった分野を特定していない.このためこれ らの手法を組込みソフトウェア開発に適用しようとする場合に は,組込みソフトウェア特有の制約事項などを考慮してモデル を適切に解釈する必要があると考えられる. プロセス関連手法の運 用 プロセス評価改善については米国 CMU/SEI などがプロセスモ デルの維持、アセスメント（評価）方法の開発・維持、トレーニ ングの提供、アセッサの認定、プロセス評価改善データやノウ ハウの収集・分析・公開などの支援業務を展開している. プロ セス評価改善に関しては,第３者による評価やレベルの認証な ど運用面での課題も少なくない. 〔IＩI〕 プロセスを取り巻く課題 ソフトウェアプロセスに関して,これまでは主としてビジネス アプリケーション分野のソフトウェアを対象に技術が育てら れてきた経緯があり,組込みソフトウェア分野におけるソフト ウェアプロセスの取り組みは始まったばかりである. ソフトウェアプロセスによるアプローチを考えた場合,ＰＤＣＡ (Plan/Do/Check/Action)サイクルに対応して, ① プロセスの定義と実行 ② プロセスの実施状況の確認(プロセス評価) ③ プロセスの改善 といった３つのメタな活動としてとらえることができるが,それ ぞれに関して次のような課題を考えることができる. 組込みソフトウェアにお けるプロセスの定義/標 準化の課題 組込みソフトウェアのプロセス定義を考えた場合,最も大きな 課題は, ① ハードウェアの存在とプラットフォームの多様性 ② 開発のコンカレント性と分散開発の進行 をどのようにプロセスに反映していくかがポイントとなる.このた めには,組込みソフトウェア開発特有の課題を洗い出して課題 の対応のための作業項目を定義することにより組込みソフト ウェアに特化した開発プロセスが定義できると考えられる. 組込みソフトウェアにお けるプロセス評価の課 題 プロセス評価に関しては,近年の組込みソフトウェア開発は開 発期間が極めて短くなる傾向にあり,その中で如何に効果的に プロセス上の課題を発見できるかがカギとなっている. また,プロセス定義とも関係するが,組込みソフトウェア開発特 有の事情や制約をどのように捉え,それをどのようにプロセス 評価の判断にマッピングしていくかもまた重要な課題である. 組込みソフトウェアにお けるプロセス改善の課 題 組込みソフトウェア開発では個人スキルに依存する部分が多 く属人性が高い. プロセス改善の第一歩はこうした属人性の 排除であり,それを円滑に進めるための改善手法が必要とされ る. - 16 - 〔IV〕 管理プロセスの問題 ソフトウェア開発を進めためのプロセスとして は,ISO/IEC12207 に規定されているように様々なプロセス が必要となる.近年の組込みソフトウェア開発は規模の増 大や短期開発などが急激に進み,様々な制約条件が発生 し開発に様々な影響を及ぼしている. このため,数多くある プロセスの中でも特に管理プロセスを充実させることが組 込みソフトウェア開発の進化には必要と考えられる. 分散開発への対応 近年の組込みソフトウェア開発は数多くのユニットに分けた分 散開発が主流となっている.こうした分散開発では従来以上の マネージメント能力が必要とされ,また,システム全体の構造や 設計を理解した技術面・管理面とも強いリーダが必須である. 規模拡大への対応 一方で組込みソフトウェアの規模拡大は管理対象の拡大を意 味しているが,こうした規模の大きな組込みソフトウェアの開発 に適した管理プロセスを整備していく必要がある. 期間短縮への対応 また,開発期間の短縮化に関しては、仕様の早期凍結や流用 などのエンジニアリング面でのアプローチが必要であるが、精 度の高い見積りを行うとともに、如何に管理のオーバーヘッド を減らすか、品質向上により失敗コストを如何に減らすかが重 要な課題となる. この意味では管理プロセス自身のコスト評価 や適切なスケジューリングなども課題となる. 〔V〕 支援プロセスの問題 近年の組込みソフトウェア開発は多人数・分散開発の形態 をとることも多く,こうした場合,ドキュメンテーションや情報共 有など支援プロセスの適否が大きな影響を与える. しかし ながら,組込みソフトウェア開発では概して支援プロセスは 軽視されがちであり,様々な課題をもっている. ドキュメンテーションに 関する課題 組込みソフトウェア開発では ・ ドキュメントが標準化されていない ・ ドキュメントを作成する習慣がない ・ 未だにコード中心の開発から抜け出せない などの課題があり,文書化やそれに基づくレビューの充実や支 援システムによるサポートなどが必須要件となっている. 情報共有/伝達に関す る課題 また多人数・分散環境下ではドキュメントなども含めて様々な 情報を共有しながら開発を進める必要がある. 〔VI〕マネージメントスキルの ソフトウェアプロセスを円滑に機能させようとした場合,プロ ジェクトマネージャや開発リーダが重要な役割を担う.しかし 問題 ながら,組込みソフトウェア分野ではこのプロジェクトマネー ジメントに必要なスキルが十分に備わっていないなど以下 のような課題も散見される. ・ 適切なマネージメントスキルを持ったマネージャが不 - 17 - 足している,あるいはマネージャの育成が進んでいな い. ・ システム全体の設計に関する深い知識を持ったリダが不足している. ・ 設計現場の力が強く、プロセス改善スタッフが思うよ うな活動を推進できない. - 18 - 2. 組込みソフトエンジニアリング部会の検討の経緯(詳細) 2.1 組込みソフトウェアエンジニアリング部会における 検討の流れ 2.2 組込みソフトウェア開発における課題 2.2.1 課題の抽出 2.2.2 課題の連関 2.2.3 課題及び解決策領域設定 2.2.4 各領域における課題の連関 2.3 組込みソフトウェア開発における課題解決策 2.3.1 課題に対する解決策の検討 - 19 - 2.1 組込みソフトウェアエンジニアリング部会における検 討の流れ 組込みソフトウェアエンジニアリング部会では、組込みソフトウェア開発の現場においてどのよう なことが課題となっているかを明らかにし、その課題の解決策を見出すための検討を行った。 全体の流れは、基本的に事務局で検討したものについて各委員に部会前に確認を求めアンケ ートを行い、その結果をまとめ部会で討議、さらに検討を進めるということを繰り返した。 検討の主な流れは、以下に示すとおりである。（図 2. 1） ① 課題抽出のための領域設定 組込みソフトウェア開発における課題の抽出に際し、検討を容易にするため、組込みの 種類やその開発における領域を設定した。 ② アンケートによる課題の抽出 ①で定めた領域ごとにどのような課題が存在するかを各委員に対してアンケート調査を 行うことで明らかにした。 ③ 課題の連関図作成 ②において明らかになった各課題がどのような関係にあるのかを調べるため、課題の連 関図を作成した。連関図を作成することで中心となる課題が見えてきた。 ④ 再度、課題の領域を設定 ③より中心的な課題が明らかになったので、新たに課題の領域を設定し直すこととした。 ⑤ 領域ごとの課題連関の検討 新たに設定された領域のもとで課題の連関について再度検討を行った。 ⑥ 領域ごとの課題解決策アンケート実施 新たに設定された領域のもとで、各領域での課題の解決策、「今現在どのような解決策を とっているか」、また「どのような解決策が必要とされるのか。」について各委員に対してア ンケート調査を行った。 ⑦ 課題とその解決策との対応を検討 アンケートによって得られた解決策が、既に得られている課題との対応づけを行った。（ど の解決策がどの課題を解決するのかについての検討） ⑧ 解決策優先順位アンケート実施 課題解決策の優先順位（必要とされている順番、ただし順位が低いものが不要というわ けではない。）について各委員にアンケートを行った。 以上により、課題解決策の優先順位を明確にしていった。さらにこれら解決策の実現性なども考 慮に入れた上で、開発すべき課題解決策について検討を進めていく。（５章以降に詳細を示す。） - 20 - 課題抽出のための領域設定 課題の抽出（委員アンケート） 課題の連関図作成 再度領域の設定 領域ごとの課題連関の検討 領域ごとの解決策抽出（委員アンケート） 課題とその解決策との対応を検討 解決策優先順位の検討（委員アンケート） 図 2. 1 事務局での検討 委員へのアンケート 組込みエンジニアリング部会での検討の流れ - 21 - 2.2 組込みソフトウェア開発における課題 2.2.1 課題の抽出 組込みソフトウェア開発における課題を抽出するために、組込みソフトウェア開発の領域を情報 処理型、制御型、およびそのインタフェースに分けて検討を行い、課題を洗い出した結果をまとめ る。 具体的には、次のような観点から行った課題の抽出（課題抽出アンケート結果参照）及び議論 （部会）の結果を整理したものである。 ・ エンジニアリングプロセスにおける課題 ・ 管理プロセスにおける課題 ・ 支援プロセスにおける課題 ・ 開発環境、教育における課題 ・ 組込み、ドメイン特有の課題 システムコールやAPIを利用するソフトウェアをイメージ 例：携帯電話のアプリケーションなど 情報処理型 大きく二つに分類 インターフェース 制御型（従来型組込み） 割り込みを利用して開発するイメージ 例：自動車のエンジン制御など （注）人材のスキルは別出し →ＩＴＳＳ 図 2. 2 組込みソフトウェアの領域と課題 この領域を踏まえた上で、次のような観点から意見を集約した。 (1)どのような開発であるか。 組込みソフトウェア開発における自らの役割、開発規模、プロジェクト規模、開発形態、 開発期間 (2)開発工程のどの部分でどのような課題があったか。 エンジニアリングプロセスと呼ばれる要求獲得/設計/実装/テストなどの作業に関わる 課題、管理プロセスにおける課題（例えば計画立案、プロジェクトマネージメントなど）、ド - 22 - キュメンテーションやレビュー、品質保証などエンジニアリングプロセスを支える支援プロ セスに関わる課題、開発環境や教育など組織的取組に関わる課題 (3)組込み故に困っている特徴的なところ、製品ドメインの特徴や制約によって発生する 課題があったか。 (4)既存手法や技術が利用されていない主たる障害あるいはどのような手法が役に立っ ているか。 - 23 - 2.2.2 課題の連関 抽出された課題の中で、中心となる課題を明らかにするため、課題の連関を分析した結 果をまとめる。具体的には連関図を作成し分析することにより、以下のような課題の存在 を確認した。 特に連関が集中する課題（共通の課題となると考えられる） ・要件が決まらない。 ・時間がない。 ・教育が不十分。 ・SW 開発に標準がない。 ・HW 連携による問題（コスト、リソース） 末端の課題（他の課題の根本的な要因となると考えられる） ・要件変更が多い。 ・要件の獲得技術がない。 ・ドメインごとにアプローチが違う。 ・開発規模が小さい。 ・絶え間ない開発 ・商品開発責任者、ビジネス責任者の理解不足 ・品質保証部の索引力が弱い。 ・量産・設計現場の力が強く改善活動が進まない。 ・外注管理の難しさ ・分散開発 ・開発の巨大化 ・知識習得に要する時間膨大 ・良い見本に触れる機会が少ない。 ・ノウハウの伝達が OJT ・商品分野ごとに HW が異なる。 ・要求仕様が高度で理解が難しい。 ・構造設計が悪い。 ・明確なテスト完了基準の不足 ・製品に対する要求の変化が激しい。（市場の変化） また、集約した意見をもとに作成した課題の連関図を、図 2. 3、図 2. 4 に示す。 - 24 - 図 2. 3 課題の連関図(その１) - 25 - 図 2. 4 課題の連関図(その 2) - 26 - 2.2.3 課題及び解決策の領域設定 2.2.2 項における課題の連関について検討を行い、改めて各課題を次のようにカテゴライズした。 RE:要件に関する課題 MT:マネジメントに関する課題 DM:設計に関する課題 IT:実装に関する課題 VV:検証妥当性に関する課題 QM:品質可視化に関する課題 この領域の具体的な内容は、表 2 1 に示すとおりである。 表21 課題領域 ＲＥ：Requirement Engineering for embedded software ＤＭ： Design Method for embedded system 開発初期のシステム要求獲得＆分析手法の整備 要求変更管理手法の確立 フォーマルメソッドとの連携 Ｓ/Ｖ分離によるコアアセット設計手法 ＵＭＬ2をベースにした形式手法の組込み領域での 実用化 Ｐｒｏｄｕｃｔ Line的開発アプローチの実用化 Ｃｏｄｅｓｉｇｎ技術とのシームレスな連携 ＩＴ：Ｉｍｐｌｅｍｅｎｔ Technique embedded system ＶＶ： Validation and verification for embedded system 組込みソフトウェア向けコンポーネントウェア フレームワーク技術/モデルベース開発との連動 リファクタリング ＸＰ的なアプローチ ペアプログラミング＆ピアレビュー テストファースト テスト自動化技術 形式検証 ＭＴ： Management Technique for embedded system ＱＭ： Quality Measurement for embedded system ＥＶＭＳの実用化 組込み用ＦＰ（Ｆｕｎｃｔｉｏｎ Point)の実用化 組込み向けリスクマネージメント手法の確立 組込みシステムの品質評価手法確立 メトリックス標準化＆評価基準値 評価結果フィードバック手法の確立 システム性能評価手法 27 2.2.4 各領域における課題の連関 本項では 2.2.3 項において示したような課題の領域に基づき、領域ごとに課題の因果関係につい て考察した結果をまとめる。最初に下図の因果関係の整理・分析の考え方を記す。 例えば、 ・ 要求定義が不十分 ・ 設計が最適化されていない ・ 検証・テストが不十分 ・ 開発管理が機能していない ・ 品質レベルが把握できない という事項がどのような因果関係にあるのかについて検討を行った。以上の課題の外に組込みソ フトウェア開発自身の制約やビジネス要因という課題が存在するが、これらの課題は組込みソフト ウェア開発における制約条件となり、この課題については、受け入れざるを得ない（解決策が存在 しない）ものと考えられる。 因果関係の整理・分析 要求定義が不十分 組込みソフトウェアの制約 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに起因する制約 設計が最適化されていない 検証・テストが不十分 ビジネス要因 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 開発管理が機能していない 品質レベルが把握できない 図 2. 5 課題領域の因果関係 28 ①「RE：要求獲得＆要求定義」における課題の因果関係 課題領域「RE:要求獲得&要求定義」での課題の因果関係は以下のとおりである。 2.2.2 項の課題の連関図において、RE の領域での課題は、「要件変更が多い」、「要件が決まら ない」、「レビューができない」、「要件の獲得技術がない」などがあげられたが、これら課題のさら に周辺にある課題とその連関図 2. 6 に示すとおりである。 「要件変更が決まらない」のは、その原因を考えると HW 仕様が決まらないためであり、これは 組込みソフトウェア開発における一つの特徴（組込みソフトウェアの制約）である。 「要件の獲得技術がない」という課題は、ビジネス要因である「市場ニーズが把握しきれない」、 「製品に対する要求の変化が激しい」といった課題と連関し、さらには、「要求が煩雑に変更され る」、「要求仕様の検証・レビューが不十分」といった課題へとつながっていく。 多様な周辺技術が 関係する HW仕様がなかなか 決まらない 多様なプラットフォーム による実現が可能 制御方式が複雑 HW仕様が決まらないと ソフトの仕様を決めにくい 組込みソフトウェアの制約 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに起因する制約 HW誤りを ソフトでリカバー 要求の獲得技術 がない 非機能的な要求の 変動幅が大きい ビジネス要因 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 市場ニーズが 把握しきれない 製品に対する要求の 変化が激しい 外注依存度が高く 既存システムがブラック ボックス化 要求が頻繁に 変更される 過去のシステムの要求 の再利用が難しい 要件が決まらない 要求仕様の検証・ レビューが不十分 要求仕様が ドキュメント化されない 過去システムの仕様や ノウハウが読み取れない 要求仕様書の記述内容 が標準化されていない メカニズムとして 要求から設計への変換が 自動化されていない 図 2. 6「要求獲得&要求定義」における課題の因果関係 29 要求定義が不十分 ②「DM：設計技術」における課題の因果関係 課題領域「DM:設計技術」での課題の因果関係は以下のとおりである。 4.2.2 項の課題の連関図において、DM の領域での課題は、「要求仕様が高度で理解しがたい」、 「SW,HW 両方の知識を持つ人材の不足」、「設計手法・品質に個人差がある」などがあげられたが、 これら課題のさらに周辺にある課題とその連関について図 2. 7 に示すとおりである。 DM における課題、例えば「要求を元に適切な機能分割・モデリングが出来ていない」、「製品戦 略を考慮して設計されていない」は、RE における課題の「要求獲得・定義が不十分」と関連がある。 また RE と同様、HW における設計の影響を受ける。 「設計の個人差が大きい」ために、「信頼性が低い」、「保守しにくい」、「拡張性が低い」、「再利 用性が低い」といった課題が発生することが考えられる。 HWの多様性 CPU/デバイスなどの 影響受けやすい タイミングなどの 制約がきつい 共通のプラット フォームがない 排他制御などの 制約が存在 設計検証/レビュー が不十分 ハード/ソフトの切り 分けが難しい 組込みソフトウェアの制約 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに 起因する制約 信頼性が低い ハードウェア設計との 関連付けが難しい 組込みに適した 標準的な設計手法が ない 設計の個人差が 大きい 設計情報の表現方法が 標準化されていない 要求獲得・定義が不十分 ビジネス要因 zソフトウェアカバー範囲 の拡大 z短期開発 z高品質・信頼性の要求拡大 保守しにくい 拡張性が低い 再利用性が 低い 設計環境（ツール） が不十分 過去の設計資産が 利用できていない 要求を元に 適切な機能分割・モデリングが 出来ていない 製品戦略を考慮して 設計されていない Hot/Frozen Spotの 切り分けが不十分 モジュール化/部品化 が不十分 図 2. 7「設計技術」における課題の因果関係 30 開発ボリューム が膨大 設計が最適化 されていない ③「IT：実装技術」における課題の因果関係 課題領域「IT:実装技術」での課題の因果関係は以下のとおりである。 2.2.2 項の課題の連関図において、IT の領域での課題は、「モジュール化、部品化ができていな い」、「再利用が難しい」、「既存資産の活用が浸透していない」、「リアルタイム性と高度情報処理 の両立」などがあげられたが、これら課題のさらに周辺にある課題とその連関について図 2. 8 に 示すとおりである。 「モジュール間依存性が高い実装」であるため、「パッケージ化（部品化）を考慮した実装ができ ない」、「コンポーネントとしての利用が難しい」ということになる。「モジュール間依存性が高い」の は、「HW に依存する複雑な処理」があるためであり、これは組込みソフトウェアであるが故の課題 である。 また、ビジネス要因で「ソフトウェア規模の増大」が課題としてあげられ、そのため「外注依存の 開発・実装」、「経験の浅いメンバーの投入」、「混成プロジェクト」であることが問題になってくると 考えられる。 パッケージ化（部品化）を 考慮した実装ができていない ベテランに依存した 実装 コンポーネントとしての 利用が難しい 高度な専門処理 モジュール間依存性が 高い実装 組込みソフトウェアの制約 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに 起因する制約 HWに依存する 複雑な処理 HWに依存した コンポーネントの利用 コンポーネント利用の 拡大 ビジネス要因 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 ソフトウェア規模の 急増 プログラム（構造）が 見えない 複雑な ソースコード プログラムの理解性低下 利用したコンポーネントの 使い勝手/信頼性/特性が 把握できない 外注依存の開発・実装 経験の浅いメンバーの 投入 コンポーネント利用部に 関するトラブル コーディング規約に 基づくレビューが 不十分 混成プロジェクト コーディング規約の 未整備 図 2. 8「実装技術」における課題の因果関係 31 部分部分によって コーディングスタイルが まちまち ④「VV：検証及び妥当性確認」における課題の因果関係 課題領域「VV:検証及び妥当性確認」での課題の因果関係は以下のとおりである。 2.2.2 項の課題の連関図において、VV の領域での課題は、「明確なテスト完了基準の不足」、 「テスト項目が多い」、「検証確認漏れ」、「排他制御の不十分さ」などがあげられたが、これら課題 のさらに周辺にある課題とその連関図 2. 9 に示すとおりである。 VV における課題のいくつかは、RE の課題「要求獲得・定義が不十分」、DM の課題「設計が不 十分」などが原因となっている。 テストにおける課題は、 ・ 短いテスト期間 ・ テスト項目が膨大 ・ 全てのテスト項目を洗い出せない ・ 単体テストが不十分 ・ 分散開発時の統合テストが難しい（HW との問題がある） などがあげられる。 HW/SW両方の 知識が必要 テスト環境がドメインに依存 テスト環境が貧弱（シミュレーション環境） 実機の完成度が低い場合がある 微妙なタイミングの テストが難しい HWに依存する テスト項目がある 組込みソフトウェアの制約 システムをテストする テストデータが用意できない テスト担当者の 経験・勘に依存 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに起因する制約 要求獲得・定義が不十分 分散開発時の 統合テストが難しい -HW+SW -SW+SW 実質的には テスト項目を選択 テスト期間内に 必要なテスト項目を 消化しきれない ビジネス要因 テスト項目が 膨大 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 テストは手間 が掛かる 短い テスト期間 テストの抜けが 発生する 不具合検出効率の 高いテスト項目が 特定できない 全てのテスト項目を 洗い出せない 設計が不十分 不具合発生時の 動作再現が難しい テストすべき状態を 作り出せない テスト十分性の 判断が難しい テストケース/データの 再利用が出来ていない 単体テストが 不十分 単体/結合/総合の ３レベルのテストを 実施する余裕がない 総合テストに依存した ビッグバン形式になっ ている 設計表現が形式化されていない リグレッション テストが大変 リグレッション テストが不十分 静的検証技術などが 活用されていない 図 2. 9「検証及び妥当性確認」における課題の因果関係 32 検証・テストが 不十分 ⑤「MT：開発管理」における課題の因果関係 課題領域「MT:開発管理」での課題の因果関係は以下のとおりである。 2.2.2 項の課題の連関図において、MT 領域での課題は、「開発規模が小さくて管理時間がな い」、「支援体制が組みにくい」、「プロジェクトマネージャ不足」、「外注管理の難しさ」、「分散開発」、 「組織マネージャがついていけない」などがあげられたが、これら課題のさらに周辺にある課題と その連関図 2. 10 に示すとおりである。 「ソフト開発を熟知した管理者が不在」であるために「リスク管理」ができないという問題、また見 積に関わる課題「見積もり時の不確定要素が多い」、「初期見積もりの甘さ」、「組込みの制約事項 を考慮した見積もり手法がない」といった課題も重要である。 マネージメント機能が適切にはたらいていないと、「開発/納期遅れ」、「コスト超過」、「品質低 下」といった問題を招く。 組込みの制約事項を考慮した 開発管理手法がない 管理標準（基準）が決まっていない 開発管理ルーチンが不明瞭 指標を測る仕組み （ツールなど）が不十分 管理指標（メトリクス）が決まっていない 外注依存度 が高い ソフト/ハードの 分散開発 開発プロセスの 未整備 開発状況の 可視化が出来ていない 不明瞭な開発 マイルストーン 効果的な対策が 適切なタイミングで 実施されない 組込みソフトウェアの制約 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに 起因する制約 ソフト開発を熟知した 管理者の不在 リスク意識 の欠落 開発期間が短く 管理に充当する 余裕がない リスクが 読みきれない 開発/納期遅れ コスト超過 適切なリスク管理が 実施されていない 品質低下 技術的に未成熟 領域の開発 ビジネス要因 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 新規要素技術 開発の不透明さ 開発管理が 機能していない 当初から無理な 計画でスタート 見積もり時の 不確定要因が多い 初期見積もり （期間,コスト）の甘さ 組込みの制約事項を 考慮した見積り手法 がない 開発者のスキル/生産性が 把握できていない 図 2. 10「開発管理」における課題の因果関係 33 ⑥「QM：品質可視化」における課題の因果関係 課題領域「QM:品質可視化」での課題の因果関係は以下のとおりである。 QM については、4.2.2 項の課題の連関図においては考察されていなかったが、改めて QM にお ける課題の連関についてまとめたものを図 2. 11 に示す。 修正が難しい場合の 後工程（テストなど） での十分な検証方法が 確立していない 品質計測結果を 適切に利用する 方法が見えていない 品質計測/定量評価の 習慣がついていない 組込みソフトウェアの制約 品質計測/可視化に 手間がかかる HW依存部分の 特殊性 zプラットフォームに起因 する制約 zHWに起因する制約 z実世界とのインタラクションに 起因する制約 適切なツールが ない 基本的にユニットごとの 並行開発 品質データをもとにした レビューが出来ていない 評価メトリクスが 決まっていない ソフトウェアの弱点などが 開発途中で十分に評価で きていない 品質メトリクスの基準値が 決まっていない ビジネス要因 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 開発途中で 各部分の出来栄えや 状況を把握できない 設計ドキュメントが 標準化されていない 開発途中での修正作業などが 必要なタイミングで実施できない コーディングスタイルが 標準化されていない 複雑な依存関係 一部を修正すると 他のところにも影響する 修正作業に適した 手法が確立していない 図 2. 11「品質可視化」における課題の因果関係 34 2.3 組込みソフトウェア開発における課題解決策 2.3.1 課題に対する解決策の検討 本項では、以上検討してきた組込みソフトウェア開発における課題に対して、これらを解決する ためには、どのような手法・技法が必要かについて検討を行った結果を記す。具体的には、各委 員に対してアンケートを行い、挙げていただいた課題の解決策の具体例に基づいて、議論・整理 した内容をまとめた。 なお、解決策について、2.2.3 項で示した領域ごと（RE,DM,IT,VV,MT,QM）に次のような観点から アンケート調査を行った。 １．現状でどのような工夫がなされているか。 ２．新たにどのような手法・技法があればこれらの課題が解決すると考えられるか。 また、特に課題解決のための手法・技法については、次の意見を集約した。 １．作るべきもの（実現可能性が高い） ２．あればいい（実現可能性は問わない） 35 ①「RE：要求獲得＆要求定義」の課題と解決策の対応 制約条件については、解決策が存在しないと考えられる課題であるが、それ以外の課題につい ては、次のような解決策が考えられる。 (1)要求を獲得する技術 ・機能要求/非機能要求および HW 要求の獲得のための技術 ・ビジネス戦略の要求への反映 (2)要求を記述整理する技術、要求仕様を利用する技術 ・組込みソフト向け要求仕様記述フレーム ・要求仕様のパッケージ化と再利用技術 ・設計情報とのリンク技術 ・変更を前提とした要求の構成管理手法 (3)要求を検証する技術 ・要求のプライオリティ付けと SV 分離技術 ・組込みソフト要求分析技術 多様な周辺技術が 関係する 制約条件-1 多様なプラットフォーム による実現が可能 HW仕様がなかなか 決まらない 制御方式が複雑 HW仕様が決まらないと ソフトの仕様を決めにくい 組込みソフトウェアの制約 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに起因する制約 要求を獲得する技術 ビジネス要因 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 制約条件-2 HW誤りを ソフトでリカバー 要求の獲得技術 がない 非機能的な要求の 変動幅が大きい 市場ニーズが 把握しきれない 製品に対する要求の 変化が激しい 外注依存度が高く 既存システムがブラック ボックス化 要求が頻繁に 変更される 要件が決まらない 要求仕様の検証・ レビューが不十分 要求を 検証する技術 要求定義が不十分 過去のシステムの要求 の再利用が難しい 要求仕様が ドキュメント化されない 過去システムの仕様や ノウハウが読み取れない 要求仕様書の記述内容 が標準化されていない メカニズムとして 要求から設計への変換が 自動化されていない 図 2. 12「要求獲得&要求定義」における課題と解決策 36 ②「DM：設計技術」の課題と解決策の対応 制約条件については、解決策が存在しないと考えられる課題であるが、それ以外の課題につい ては、次のような解決策が考えられる。 (1)設計可視化、検証技術 ・マルチビューからの設計可視化技術 ・HW を考慮した Model Checking の実用化 ・HW 要素を考慮した、Model Checking、静的／動的検証手法 (2)再利用技術 ・組込み向けプロダクトライン技術の整備 (3)モデリング技術 ・組込み向けアーキテクチャ、設計パターン ・ドメインモデリング手法 (4)コデザインとの連携 ・ソフト主導のコデザイン技術 制約条件-1 HWの多様性 設計可視化 検証技術 CPU/デバイスなどの 影響受けやすい タイミングなどの 制約がきつい ハード/ソフトの切り 分けが難しい 組込みソフトウェアの制約 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに 起因する制約 共通のプラット フォームがない 排他制御などの 制約が存在 設計検証/レビュー が不十分 コデザインとの 連携 ハードウェア設計との 関連付けが難しい 組込みに適した 標準的な設計手法が ない zソフトウェアカバー範囲 の拡大 z短期開発 z高品質・信頼性の要求拡大 モデリング技術 設計環境（ツール） が不十分 制約条件-2 要求を元に 適切な機能分割・モデリングが 出来ていない 製品戦略を考慮して 設計されていない 拡張性が低い 再利用性が 低い 短い設計期間 ビジネス要因 保守しにくい 設計の個人差が 大きい 設計情報の表現方法が 標準化されていない 要求獲得・定義が不十分 信頼性が低い Hot/Frozen Spotの 切り分けが不十分 過去の設計資産が 利用できていない 再利用技術 モジュール化/部品化 が不十分 図 2. 13「設計技術」における課題と解決策 37 開発ボリューム が膨大 設計が最適化 されていない ③「IT：実装技術」に関する課題と解決策の対応 制約条件については、解決策が存在しないと考えられる課題であるが、それ以外の課題につい ては、次のような解決策が考えられる。 (1)コーディング規約の整備 ・わかりやすく保守しやすい組込ソフトウェアに適したコーディングスタイルを実現するためのル ール決めやツールによる支援 (2)プログラム部品化技術 ・プログラム/設計/仕様を一体化したパッケージ化支援技術や HW 非依存のコンポーネント抽 出技術 (3)プログラム可視化技術 ・プログラム構造の可視化 ・スライシングをベースにしたプログラム内関連の可視化や HW との関連の可視化 (4)コンポーネント評価技術 ・COTS などの使い勝手/再利用性/信頼性評価手法やサイズ面/性能面からの評価技術 (5)コード自動生成技術 ・設計からコードへの変換技術 プログラム 部品化技術 制約条件-1 パッケージ化（部品化）を 考慮した実装ができていない ベテランに依存した 実装 高度な専門処理 モジュール間依存性が 高い実装 組込みソフトウェアの制約 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに 起因する制約 HWに依存する 複雑な処理 コンポーネント利用の 拡大 プログラム 可視化技術 プログラム（構造）が 見えない 複雑な ソースコード HWに依存した コンポーネントの利用 コンポーネントとしての 利用が難しい プログラムの理解性低下 利用したコンポーネントの 使い勝手/信頼性/特性が 把握できない コンポーネント利用部に 関するトラブル コンポーネント 評価技術 ビジネス要因 ソフトウェア規模の 急増 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 外注依存の開発・実装 経験の浅いメンバーの 投入 コーディング規約に 基づくレビューが 不十分 混成プロジェクト 制約条件-2 コーディング規約の 未整備 コーディング規約の整備 図 2. 14「実装技術」における課題と解決策 38 部分部分によって コーディングスタイルが まちまち ④「VV：検証及び妥当性確認」に関する課題と解決策の関係 制約条件については、解決策が存在しないと考えられる課題であるが、それ以外の課題につい ては、次のような解決策が考えられる。 (1)テスト項目/データの作成 ・仕様情報/設計情報からテスト項目を自動生成、HW 依存のテスト項目/データ生成、テスト項 目の優先度付けと選択 (2)テスト自動化 ・テストデータの生成、テストシナリオに従ったデータの自動投入 ・テスト項目／データの再利用によるリグレッションテスト自動化 (3)（静的）検証技術 ・ 設計/実装品質データに基づいたレビュー範囲の絞り込みや組込み特有項目に関する静的 検証手法（ツール） ・コード／設計トレースによる確認技術 ・Model Checking (4)汎用テスト環境 ・ドメイン HW に依存しない準汎用テスト環境構築メカニズム 設計が不十分 汎用テスト環境 設計表現が形式化されていない HW/SW両方の 知識が必要 テスト環境がドメインに依存 静的検証技術などが 活用されていない テスト環境が貧弱（シミュレーション環境） 実機の完成度が低い場合がある 微妙なタイミングの テストが難しい 制約条件 -1 HWに依存する テスト項目がある 組込みソフトウェアの制約 要求獲得・定義が不十分 全てのテスト項目を 洗い出せない ビジネス要因 テスト項目が 膨大 テスト自動化 テストは手間 が掛かる 短い テスト期間 テストの抜けが 発生する 不具合検出効率の 高いテスト項目が 特定できない テスト期間内に 必要なテスト項目を 消化しきれない 制約条件 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 実質的には テスト項目を選択 テスト項目/ データの作成 分散開発時の 統合テストが難しい -HW+SW -SW+SW -2 （静的） 検証技術 システムをテストする テストデータが用意できない テスト担当者の 経験・勘に依存 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに起因する制約 不具合発生時の 動作再現が難しい テストすべき状態を 作り出せない テスト十分性の 判断が難しい テストケース/データの 再利用が出来ていない 単体テストが 不十分 単体/結合/総合の ３レベルのテストを 実施する余裕がない 総合テストに依存した ビッグバン形式になっ ている リグレッション テストが大変 図 2. 15「検証及び妥当性確認」における課題と解決策 39 リグレッション テストが不十分 検証・テストが 不十分 ⑤「MT：開発管理」に関する課題と解決策の関係 制約条件については、解決策が存在しないと考えられる課題であるが、それ以外の課題につい ては、次のような解決策が考えられる。 (1)見積手法/計画立案技術 ・HW/SW 相互依存を考慮したコスト・工数/期間見積手法、HW 要因を加味したソフトリスク評価 手法の確立 ・組込みソフト開発プロセス設計技術 (2)開発管理手法/状況の可視化と制御 ・開発状況可視化メトリクスの設定と定量評価による開発制御 ・PMBOK の組込み向けカスタマイズ ・開発リスク音モニタリング方式と削減手法 ・変更影響を吸収する開発制御技術 (3)情報共有化 ・Web などによる開発ドキュメント（直接/間接）の共有化のための仕組み（パッケージ）作り ・HW 部門なども含めた情報共有化のためのコミュニケーション／意思決定手法 開発管理手法 状況の可視化と制御 組込みの制約事項を考慮した 開発管理手法がない 管理標準（基準）が決まっていない 制約条件-1 開発管理ルーチンが不明瞭 指標を測る仕組み （ツールなど）が不十分 管理指標（メトリクス）が決まっていない 外注依存度 が高い ソフト/ハードの 分散開発 開発プロセスの 未整備 組込みソフトウェアの制約 zプラットフォームに起因する制約 zHWに起因する制約 z実世界とのインタラクションに 起因する制約 制約条件-2 ビジネス要因 zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 要求定義が不十分 開発状況の 可視化が出来ていない 不明瞭な開発 マイルストーン 効果的な対策が 適切なタイミングで 実施されない ソフト開発を熟知した 管理者の不在 リスク意識 の欠落 開発管理が 機能していない 開発期間が短く 管理に充当する 余裕がない リスクが 読みきれない 開発/納期遅れ 適切なリスク管理が 実施されていない 技術的に未成熟 領域の開発 新規要素技術 開発の不透明さ 見積もり手法 計画立案技術 当初から無理な 計画でスタート コスト超過 情報 共有化 品質低下 過去のデータ・経験が 蓄積されていない 見積もり時の 不確定要因が多い 初期見積もり （期間,コスト）の甘さ 組込みの制約事項を 考慮した見積り手法 がない 過去のデータ・経験が 活されていない 開発者のスキル/生産性が 把握できていない 図 2. 16「開発管理」における課題と解決策 40 ⑥「QM：品質可視化の課題解決策」に関する課題と解決策の関係 制約条件については、解決策が存在しないと考えられる課題であるが、それ以外の課題につい ては、次のような解決策が考えられる。 (1)レビュー・インスペクション支援技術 ・重点レビュー箇所の選択 ・計測結果からの事前指摘 ・レビュー結果フォロー ・HW 依存箇所のチェック手法 (2)品質（自動）計測可視化技術 ・評価レビュー＆メトリクスの設定 ・評価基準値の設定 ・自動計測/自動診断メカニズムの開発 ・計測結果統計処理及び表示方法 (3)重点テスト技術 ・重点的にテストすべき箇所を特定する手法（量的な削減を目指す） ・テスト完了指標と判断方式 (4)リファクタリング技術 ・HW 制約を加味した上で保守性向上を目的とした設計構造の見直し、修正 (5)情報共有 ・Web などによるプロセス及びプロダクトの状況の共有化のための仕組み（パッケージ）作り 41 重点テスト技術 品質(自動) 計測可視化技術 組込みソフトウェアの制約 品質計測/可視化に 手間がかかる zプラットフォームに起因 する制約 zHWに起因する制約 z実世界とのインタラクションに 起因する制約 制約条件 品質計測結果を 適切に利用する 方法が見えていない 品質計測/定量評価の 習慣がついていない HW依存部分の 特殊性 適切なツールが ない 基本的にユニットごとの 並行開発 品質データをもとにした レビューが出来ていない 評価メトリクスが 決まっていない zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 開発途中で 各部分の出来栄えや 状況を把握できない レビュー インスペクション技術 ソフトウェアの弱点などが 開発途中で十分に評価で きていない 品質メトリクスの基準値が 決まっていない ビジネス要因 修正が難しい場合の 後工程（テストなど） での十分な検証方法が 確立していない 設計ドキュメントが 標準化されていない 開発途中での修正作業などが 必要なタイミングで実施できない コーディングスタイルが 標準化されていない 複雑な依存関係 一部を修正すると 他のところにも影響する 修正作業に適した 手法が確立していない リファクタリング技術 図 2. 17「品質可視化」における課題と解決策 42 ⑦「ESPA：組込み向けソフトウェアプロセスアセスメント」に関する課題と 解決策 制約条件については、解決策が存在しないと考えられる課題であるが、それ以外の課題につい ては、次のような解決策が考えられる。 (1)組込みソフトの制約を考慮したプロセス評価手法の整備 ・最大 2.5 日程度の短期アセスメント手法 ・改善プロセスの特定手法 (2)プロセス定義/設計 ・組込みソフト開発に適した標準プロセス策定およびプロセス設計手法 (3)プロセス改善手法の整備 ・改善箇所だけでなく、改善の HOW に関する技術のナビゲート ・ツール／手法の導入指針 (4)運用の仕組み（制度化） ・改善実施効果の評価メカニズムの整備 プロセス 定義/設計 HW部門も含めた 改善を行わないと意味がない HWを意識した 開発プロセスが 決まっていない 品質監査/受託資格制度などと リンクしていない 組込みソフトウェア開発を熟知した アセッサーがいない 既存のプロセス評価の手法が 組込みソフトウェア開発 に向いていない 組込みソフトウェアの制約 zプラットフォームに起因 する制約 zHWに起因する制約 z実世界とのインタラクションに 起因する制約 プロセス改善 手法の整備 組込みソフトの制約 を考慮した プロセス 評価手法の整備 ビジネス要因 運用の仕組み （制度化） 適切な改善ソリューションへの 誘導が出来ていない プロセス改善を推進する仕組み （組織）設置が難しい 既存手法は 時間/手間がかかる zソフトウェアカバー範囲の拡大 z短期開発 z高品質・信頼性の要求拡大 プロセスの評価は出来ても 改善が具体的に進まない 開発が絶え間なく プロセス評価改善を 行う余裕がない プロセスアセスメントのための 教育/資格取得など準備が大変 手間の割りに効果が 見えない 制約条件 SEIなどによる指導が 欠かせない 図 2. 18「ESPA」における課題と解決策 43 既存手法は 形式的で形骸化する場合が多い プロセス評価＆改善が 機能していない