PR
図 「Obbligato III R3.1」の画面。ソフトの修正についての「チケット」管理機能を持つ。
図 「Obbligato III R3.1」の画面。ソフトの修正についての「チケット」管理機能を持つ。
[画像のクリックで拡大表示]

 NECは2015年5月26日に発表したPLMツール「Obbligato III R3.1」(関連記事)に関して、組み込みソフト開発プロセスを管理する機能の実現方法を明らかにした。ポイントは3つあり、[1]これまで機械系ハードウエアの管理機能が主だったObbligato IIIのデータベースにソフトを表現するオブジェクトを定義したこと、[2]そのオブジェクトに持たせる情報は要求仕様、ソフトの構成情報、変更管理情報などであり、組み込みソフトそのものは外部ツールで管理すること、[3]ソフトの開発プロセスにより適合した形で問題発見と修正を支援し、機械系ハードの変更管理機能と連携させること、である。これらにより、「ソフトの比重が増えている自動車部品、電気製品などで、ハードとソフト両方の開発プロセスを統合的に管理しやすくなる」(NEC)としている。

ソフト開発プロセスに関門を設ける

 [1]は、ハードとソフトの統合管理の基本的考え方であり、既存のハード関連の開発プロセスの管理機能に、ソフト関連の管理機能を同居させる方法を採っている。その際[2]のように、ソフトのソースコードそのものをObbligato IIIのデータベースで管理するわけではなく、ソースコードの修正やバージョン管理は「Apache Subversion」などの専用ツールを用い、部署間などで共有すべき情報のみをObbligato IIIで保持する。「実は3D-CADでも、Obbligato IIIでは3D-CADデータ自体を管理せず、専用管理ツールから部署間などで共有すべき情報を抽出している。これと同じ仕組み」(NEC)という。

 専用ツールに加えてObbligato IIIを使う必要が生じるのは、ソフトのリリース管理の難しさによる。「ソフトは柔軟であり、さらに今後IoTなどで全てのものがネットワークにつながるようになると、ソフトの更新はいつでも可能になる。逆に、自由度がありすぎて管理が難しくなる」(NEC)。そこで、開発プロセスにあるタイミングでの関門(ゲート)を設けて、そこを通ったら正式リリースとする(コンパイルしてビルドする)、といった決め事が必要になる。この決め事に応じた管理をObbligato IIIが担うわけだ。

 さらに[3]によって、ソフトの変更管理とハードの変更管理を連携させる。これが必要なのは、最近の製品ではある機能をハードとソフトの両方が分担して実現することが珍しくなく、このような場合にソフトの変更がハードの変更を引き起こす可能性があるためだ。何かの問題への対策の状況を記録する際、互いに関係のあるソフトの変更履歴とハードの変更履歴は、互いに参照可能な形で記録しておかなければならない。

 ハードに変更を加える状況とは、例えばDR(デザインレビュー)において問題を洗い出し、それを解決するための担当者や期日を決めて対策を実行することに相当する。出図後の場合には設計変更要求書、同指示書などを発行して対策状況を管理することになる。Obbligato IIIにも従来版から、このようなプロセスを支援する変更管理機能がある。

 ソフトでは、もっとひんぱんに問題の発見と対策の活動が生じるため、「チケット」を発行して管理する。問題を発見した際に「障害チケット」を発行し、これに対応する方法が決まった段階で「変更チケット」になり、対策が終わったら変更チケットを回収する、といった管理である。ハードの場合に設計変更要求書などが出るのは出図後だが、ソフト開発の場合はいわゆるV字開発プロセス全体にわたって問題の発見があるため、チケットの発行もプロセス全体で必要になる。このような違いがあるため、変更管理に必要な機能自体はハードとソフトで異なる。Obbligato IIIでも両方の機能を備えた上で、ハード側の変更管理機能からソフトの変更履歴を参照できるようにして、実質的にハードとソフトを連携した変更管理を可能にする。