JP2006085668A - ソフトウェア開発支援システム - Google Patents

Abstract

【課題】非正常系に対応するための仕様を正しく効率的に設定でき、開発する組み込みソフトの品質改善が図れるソフトウェア開発支援システムを提供することにある。
【解決手段】ソフトウェア開発支援システムＡはソフトウェアに関連する特徴情報の入力をユーザーから受け付ける入力手段２０ａ及びソフトウェア開発者に情報を提示する出力手段２０ｂを備えたユーザーインターフェース部２０と、特徴情報とこの特徴情報に関連する非正常現象との関連、各非正常現象間の関連、非正常現象に対応した処理内容を含むデータに基づいて構築されたデータベース２１と、ユーザーインターフェース部２０により受け付けた前記特徴のデータに基づいて前記データベース２１に格納している対応データを検索し、当該開発対象ソフトウェアに対して考慮すべき非正常事象を獲得してこれら獲得した事象に基づいた仕様の生成を行う演算処理部２２とから構成される。
【選択図】図１

Description

本発明は機器等に組み込むソフトウェアの作成に用いるソフトウェア開発支援システムに関するものである。

ソフトウェアの障害に関する障害を分析するシステムが従来提供されている（例えば特許文献１）。このシステムはソフトウェアにおいて発生した障害の名称や、障害が発生した環境、症状や対応者が特定した発生原因、登録した日付などを登録し、これら登録した情報を落ちいて、障害の分析やグラフ化などを自動的に実行し、発生原因の割合の分析を行うものである。また商品出荷後でのフィールド稼働後の障害情報の管理を含めてハードウェアの障害を他面的に分析するシステムが提供されている（特許文献２）。
特開２０００−２９３４１１号公報 特開２００３−２３３６８６号公報

上述の特許文献１に示されるシステムはソフトウェアの障害管理を行うシステムであるが、ソフトウェアを作成後における障害分析に使用するものであって、ソフトウェアを作成するに当たって障害等の分析を行い作成しようとするソフトウェアの仕様に盛り込むというものではなかった。また特許文献２に示されるシステムもフィールド稼働後の障害管理を目的とするものであり、特許文献１と同様にソフトウェアを作成するに当たって障害等の分析を行い作成しようとするソフトウェアの仕様に盛り込むというものではなかった。

特に近年、機器に組み込むソフトウェア（以下、組み込みソフトと呼ぶ）の大規模化、複雑化が進む一方で、開発期間の短縮に対する要求が強くなっており、上述の特許文献１、２に示されるシステムではこれら要求に対して対応させるものではなかった。

ところで組み込みソフトでは、仕様設定や設計段階における問題が重要であることを裏付ける統計結果が経済産業省が実施した調査によって下記のように得られている。
・組み込みソフト関係者の約７０％が、課題はソフトウェアの品質向上にあると認識している。
・ソフトウェアの発注時の課題のトップに、要求仕様や設計仕様の伝達の困難さが挙げられている。
・開発中発生した前工程への設計手戻りの原因のうち、要求仕様や仕様書の不備が約半数を占める。

このため、組み込みソフトに対しても効率的な開発手法の整備が急務とされ、様々な手法が提案されている。しかし仕様分析段階においては、組み込みソフト固有の特性から、それらの手法が充分な効果を発揮できていないと思われるのが現状である。

つまり、組み込みソフトには、長期安定動作、ユーザーの監視下にない状況での動作、リアルタイム性、消費電力や発熱への配慮、多少の異常がある状態でも動作を保証するといったユーザーからのニーズと、ハードリソースの制限、開発中のハードリソース変更に対する対応といったメーカーからのニーズがあるという特徴がある。これらのニーズに対応するためには、開発者にハードウェアに対する知識とソフトウェアが利用される環境におけるシステムの障害要因となりうる事象や状態（以下、システムの障害要因となりうる異常事象、例外事象や障害が発生している状態を総称して非正常系と呼ぶ）に対する知識が必要となる。実際、組み込みソフトに関する市場で散見されるトラブルは、その多くが非正常系への対応が不十分であったことに由来するものであった。

本発明は、上述の点に鑑みて為されたものであって、その目的とするところは、上述の非正常系に対応するための仕様を正しく効率的に設定でき、開発するソフトウェアの品質改善が図れるソフトウェア開発支援システムを提供することにある。

上述の目的を達成するために、請求項１の発明では、開発対象のソフトウェアを用いるハードウェア要件と該ソフトウェアの機能仕様と動作環境とを含む前記ソフトウェアの特徴情報を使用者から受け付ける入力手段と使用者に情報を提示する出力手段を備えたユーザーインターフェース部と、前記特徴情報と異常事象との関連、異常事象間の関連、異常事象と異常事象に対する処理内容との関連を含む関連情報に基づいて構築されたデータベースと、前記特徴情報に基づいて前記データベースに格納している前記関連情報を検索し、前記ソフトウェアに対して考慮すべき異常事象を取得して、取得した事象に基づいた仕様の生成を行うとともに、生成した仕様と前記特徴情報とを合成して前記ソフトウェアの仕様として前記出力手段を介して提示する処理部とを備えていることを特徴とする。

請求項１の発明によれば、ユーザーが開発対象のソフトウェアに対応する特徴情報をユーザーインターフェース部の入力手段で入力するだけで、異常事象を折り込んだ当該ソフトウェアの仕様を自動的に作成してユーザーに提示することができ、そのため異常事象に対する知識をユーザーが特に持たなくても、稼働時におけるトラブル発生を回避したソフトウェアの仕様を正しく効率的に設定することが可能となるとともに開発するソフトウェアの品質改善が図れる。

請求項２の発明では、請求項１の発明において、前記処理部は、前記異常事象の要因と事象発生に至るプロセスの分析を行うことにより、状態とイベントとのマトリクスを作成し、該マトリクスを前記出力手段より使用者に提示する分析機能を備えることを特徴とする。

請求項２の発明によれば、ソフトウェアの開発者であるユーザーに対して、組み込み対象のシステムの状態とイベント発生との関係を提示することができ、その結果ソフトウェアの設計につなげる支援が可能となり、ユーザー個人の能力に依存しない組み込みソフトの品質改善が図れる。

本発明は、ユーザーが開発対象ソフトウェアに対応する特徴をユーザーインターフェース部の入力手段で入力するだけで、当該開発対象ソフトウエアの異常事象や例外事象を折り込んだ仕様を自動的に作成してユーザーに提示することができ、そのため異常事象や例外事象に対する知識をユーザーが特に持たなくても、稼働時におけるトラブル発生を回避したソフトウェアの仕様を正しく効率的に設定でき、結果作成を可能とし、開発するソフトウェアの品質改善が図れるという効果がある。

まず、本発明者らは上述した非正常系仕様の記述のもととなるモデル構築を目的として、非正常系仕様の設定において考慮すべき事項について事例分析を行い、この分析に基づいてソフトウェア開発支援システムを発明するに至った。そこで実施形態の説明の前に、この非正常系仕様の分析について事例を挙げて説明する。

ここで各事項を通じた具体例として、以下のような単純な架空商品を想定する。この商品は図６（ａ）に示すように屋外に設置される照明器具１であって、図６（ｂ）に示すようにセンサ部２に入る光が一定以上の光量を持つ場合に所定電圧の電圧信号を出力する昼光センサ３と、辺りを照らす照明器具１及びその照明器具１を電気的にオン／オフ制御するためのリレーを含む照明回路４、これらを統括制御するＣＰＵ部５と、クロックを制御するタイマ６と、これらに電源を供給する電源回路（図示せず）から構成される。本システムに対する当初の要求仕様は「昼間は消灯しており、夜間は点灯して、周囲を明るく照らす」である。

次に分析の結果得られた事項について述べる。
１）パッケージ系ソフトと組み込みソフトでは、非正常現象発生の主要なトリガが異なる。
非正常現象の概念自体は組み込みソフト固有の概念ではないが、組み込みソフトにおいては、パッケージ系ソフトではあまり考慮されない利用環境からの影響が重要な位置を占めるのが特徴である。

屋外で稼動することによる汚れ、風雨などの影響は言うに及ばず、システム利用者でない人間が意図せずシステムの動作を妨害することなども考慮しなければならない。例えば、昼光センサ付照明システムにおいては、先の風雨などの天候のほか、夜間にヘッドライトを点灯した自動車が通りかかった場合や子供のいたずらの可能性も考慮しなければならない。

また、部品の故障や機能の劣化へもある程度対応しなければ可用性の高いシステムとして市場に受け入れられない。更に、ハード的な設計によっては、夜間にシステム自身が照明を点灯したことでセンサはこれを昼間の明るさと判断してしまう可能性もある。これらはモデリングに際してシステムのアクタを決定する場合、一般的なイメージであるアクタはシステムの外部にあるもの、との考えを改める必要性を意味している。即ち組み込みソフトでは周辺環境もシステムと同時にモデリングする必要がある。
２）実装技術によって発生する非正常系が決まる
システムにおいて発生しうる非正常現象（異常事象や例外事象）の種類は、そのシステムにおける実装技術に依存して決定する。例えば昼光センサ付照明システムでは、夜間にヘッドライトを点灯させた自動車が通過するといったケースを想定する必要が生じる。一方、システムクロック（タイマ６）を採用したシステムにおいてはこのケースを想定する必要はなく、代わりに実際の時刻とシステムクロックの時刻の不一致を考慮する必要がある。

このことは、組み込み系においてはハードウェア／ソフトウェアの設計が、仕様に影響を及ぼすことを意味している。このことから、システムの実装技術を決定することで、それに伴う非正常現象が形式的に導出できることが期待される。
３）非正常現象が別の非正常現象の原因となる
システム内で発生した現象が、別の非正常現象の原因となることがある。例えば、事例の昼光センサ付照明システムにおいて、システムが夜と判断して照明を点灯した結果、その光をセンサが検知して昼と判断する、といった異常や、明け方や夕方など、明るさが安定しない状況下では昼光センサ３からの電圧信号が頻繁にオン／オフ変化することが予想されるが、それがＣＰＵ部５の電圧信号検知の割り込み処理の頻発につながるといったことが挙げられる。このことは、システムの動的側面を考慮して分析を行う必要があることを表している。このような現象の伝播は組み込みソフト分野に限った現象ではないが、組み込みソフト分野においてはハードウェアやＯＳ（オペレーティングシステム）、ミドルウェアといった階層も仕様分析段階で考慮に入れる必要があるため、分析が困難となる一因となっている。
４）ハードウェアの非正常発生の検知をソフトの機能として求められることが要求される
コスト要求の厳しい組み込みシステムにおいては、ハードウェアの非正常検知を行うために高価な部品を用いたり、非正常検知用の回路を設けることを最低限に留めるために、ソフトウェアによってハードウェアの非正常検知を行うことが要求されることが多い。
５）一つの非正常現象に対して、複数の対応手段が存在する
ある非正常現象を検知した場合、システム、サブシステム或いはコンポーネントは以下のような処理をとることができる。（１）非正常の原因を取り除く、（２）非正常の発生を外部に通知する、（３）時間経過によって非正常から回復するのを待つ、（４）非正常現象発生箇所をシステムから切断し、影響の拡大を防ぐ。また、これらの処理と並行して、事前手段を採用することもできる。例えば事例の昼光センサ付照明システムにおいて、昼光センサ３が故障したために昼光センサ３からの入力信号がめまぐるしく変化して昼夜いずれとも判断し難い場合の対応方法について、前述の種別毎に考えると、（１）はソフトウェアでの実現が困難、（２）は異常通知ＬＥＤなどによってメンテナンス者への注意を促す方法、（３）はある程度時間をおいて、昼光センサ３からの入力信号が再び安定するまで待つ方法、（４）は昼光センサ３を昼夜の判断基準から外す方法、次善手段は例えばタイマ６によって１２時間毎に昼／夜を区別するといった方法がそれに相当する。
６）非正常への対応手段の利用可否は実装技術に依存する
先に、１つの非正常現象に対して複数の対応手段があることについて述べたが、システムの実装技術によっては採用できない対応手段が存在する。事例の昼光センサ付照明システムにおいて、昼光センサ３が故障したケースにおいては、非正常の原因を取り除く対応は例えば昼光センサ３を自動的に交換する機能をシステムに設けることに相当するが、その対応は現実的ではない。また、コスト削減のために異常検知ＬＥＤを実装しないとすれば、外部への通知を行うという対応についても別の方法によるか、外部への通知を行わないとする仕様に変更する必要がある。
７）非正常への対応手段は、要求仕様における優先順位付けによって決定される
１つの非正常現象に対して複数の対応手段が取りえる場合、各手段のうちいずれを選択するべきかの判断基準は、システムの要求仕様における優先順位に委ねられる。昼光センサ付照明システムの場合、昼光センサ３の故障時に照明をどのように制御するかの仕様は、もしそのシステムが安全性を重視したものであればオン制御することが、もしそのシステムが省エネルギー性を重視したものであればオフ制御することが望ましいと判断される可能性がある。

上述したように、非正常現象は様々な情報と関連を持つが、そのうち非正常系仕様の検討に先立って与えられることが多い情報として、システムでの実装技術（特にハードウェア）が挙げられる。このことから、システムでの実装技術とそれに伴って生じる可能性のある非正常現象との関連を中心に知識体系を構築し、その知識体系に開発対象システム（組み込みシステム）の採用手段を入力として与えることで、開発対象システム（組み込みシステム）で発生しうる非正常現象とその対応方法を出力とするようなソフトウェア開発支援システムを構築できることが分かった。

更に本発明者らは上述の分析結果に基づいて非正常系仕様抽出のための組み込みシステムの概念モデリングを行った。つまり、組み込みシステムは環境との関係が非常に深い。それはパッケージ系ソフトは利用される環境における人間が占める比率が高いため、人間の判断によってシステムへの影響をコントロールすることができるが、組み込みシステムでは利用される環境における人間の占める比率が低く、ときには無人環境での動作を要求されるためである。このような理由から、組み込みシステムの概念モデリングにおいては、組み込みシステムが置かれる環境も含めたモデリングが必要である。

例として、上述の昼光センサ付照明システムにおいて、システムは「昼／夜」と判断するための情報をどのように得ているかについて考察した。

この場合、昼光センサ付照明システムは昼光センサ３が受光する光の量によって昼夜の区別を行っている。この光は発光する物体から直接、若しくは光を反射する物体を経由して、空間の中を通過してくる。また、光の量という情報の運び手によって運ばれた「昼／夜」の情報は、昼光センサ３にて銅線（信号線）の中を通過する電気信号によってＣＰＵ部５まで運ばれるようになる。このことから、昼光センサ３は情報の運び手を光の量から電圧信号に変換させる役割を担っていると言える。

以上の考察から、組み込みシステム及びそれを取り巻く環境について、以下のように定義した。
・組み込みシステムに関連する情報の運び手をキャリアと呼ぶ。例えば、上述の昼光センサ付照明システムでは昼光センサ３に対して「昼／夜」の情報をもたらす光の量がキャリアである。
・ここでキャリアの送信元を情報発信者と呼ぶ。
・キャリアの経路を情報フローパスと呼ぶ。例えば、上述の昼光センサ付照明システムでは電圧信号の経路である銅線（信号線）は情報フローパスである。
・キャリアを変換する物を情報変換ポイント（若しくは情報受信者）と呼ぶ。例えば、上述の昼光センサ付照明システムの昼光センサ３はそれまで光の量というキャリアが運んできた「昼／夜」という情報を、電圧信号に運ばせるようにするため、情報変換ポイントとして扱う。また、情報変換ポイントは、変換後のキャリアの受信側から見れば情報発信者と言える。これらの概念を、上述の昼光センサ付照明システムに当てはめると、太陽という情報発信者から光の量というキャリアを用いて昼光センサ３に昼という情報が伝達されることになる。

さて、上述した定義に基づいて組み込みシステムに情報がもたらされる仕組みをモデリングした場合、非正常現象の発生は情報発信者、情報フローパス、情報変換ポイントにて発生するものとすることができる。ここで情報発信者において発生する非正常現象を「なりすまし」と呼ぶ。つまりこのなりすましとは、情報変換ポイントが受信する情報を、本来発すべき情報発信者以外の発信源が発信している現象を表す。例えば、上述した昼光センサ付照明システムの昼光センサ３は、昼光センサ３が捉える光の量によって昼或いは夜という情報を得るが、夜間にヘッドライトを点灯した自動車が昼光センサ３の近隣を通過することによって、昼光センサ３は昼に相当するだけの光を受信する。この場合、昼という情報を、本来の情報発信者である太陽ではなく、自動車のヘッドライトが太陽になりすまして発信していると言える。また、情報フローパスにおいて発生する非正常現象を、ここでは情報フローパス妨害と呼ぶ。情報フローパス妨害は、情報のキャリアが通る情報フローパスに情報のキャリアの通過を妨げるものが現れる現象を表す。例えば、昼間であっても、昼光センサ３の前に光を遮る障害物が置かれた場合、昼光センサ３に入る光の量が減少してセンサは夜という情報を得てしまう。

次に、情報変換ポイントにて発生する非正常現象を、ここでは情報変換ポイント例外と呼ぶ。情報変換ポイント例外は、情報変換ポイントの特性が変化した結果、変換前と変換後の持つ情報が変化する現象を表す。例えば、上述した昼光センサ付照明システムの昼光センサ３の受光回路が経年劣化などで当初より多い量の光を受光しないと昼と判断できないようになってしまった場合、この昼光センサ３にて情報変換が行われる前と後で、昼という情報が夜という情報に変わってしまうことがある。
このように、システム及びそれを取り巻く環境で発生する非正常現象は、情報フローパス・ダイアグラムの概念の上では、以上の３種類に分類することができる。

図７は上述した情報伝達の基本的モデルと非正常現象の発生を反映した非正常系概念モデルを示しており、同図では、情報発信者１０と情報受信者１１が情報フローパス１２と隣接しており、その情報はやはり情報フローパス１２と隣接している情報変換ポイントで変換されることが表されている。情報は、情報発信者１０からキャリアに載せて発信される。キャリアはフローパス１２の中を伝達し、途中で何度か情報変換ポイント１３によって変換され、最終的に情報受信者１１に到達する。

ここで、情報発信者１０、情報受信者１１、情報変換ポイント１３がそれぞれｎ−ｎの関連になっている点に着目し、これらの間の関連は同じキャリア１４を利用することを条件として成立するため、各々が意図しない相手との間で情報の送受信が行われる可能性がある。また、情報発信者１０自身が意図していないキャリア１４によって情報発信をするケースもある。例えば上述の昼光センサ付照明システムの場合には太陽が光を発信するが、同時に熱も発している。このことは例えば、昼光センサ付照明システムに人体検知などを目的とした熱センサを付加した場合、太陽光の影響で人体を誤認識する可能性があるなどのように、システム設計者が意図していない情報伝達が行われる可能性があることと、それによって組み込みシステムの設計が困難なものになっている事実を表している。ここで情報発信者１０、情報受信者１１、情報フローパス１２が夫々物理的な存在であるため、夫々が持つ記号１４或いは１４’、シンタクス１５或いは１５’やセマンティクス１６或いは１６’というオブジェクトが存在することになる。

さて上述した概念モデルは非正常系仕様の設定において考慮すべき事項が直観的に記述できる必要があるが、上述した１）〜７）の事項の内４）〜７）については非正常現象を検知する、或いは除去や代替手段などの処理に対する事項であるため、概念モデルの記述範囲には含まれないものの、１）〜３）の事項については、以下のように捉えることで記述できる。
１）パッケージ系ソフトと組み込みソフトでは、非正常現象発生の主要なトリガが異なる
図７の概念モデルは周辺環境を含めたモデルになっているため、情報発信者１０や情報フローパス妨害者１８として周辺環境に存在するインスタンスを選択することで記述可能である。
２）実装技術によって発生する非正常系が決まる
情報発信者１０や情報受信者１１、情報変換ポイント１３における実装技術は、それらが情報フローパス１２上で用いるキャリア１４の種類や性質を決定する。これらをキーとして以下のように記述することができる。

なりすましの情報発信者は、本来の情報発信者と同じキャリア１４を用い、同じ情報フローパス１２と関連を持つ別の情報発信者である
情報フローパス妨害者１８は、情報発信者と同じキャリア１４に対して妨害を行うことができ、同じ情報フローパス１２と関連を持つ存在である。

情報変換ポイント１３の例外は、情報変換ポイント１３がシステム上で用いるキャリア１４について、その解釈を変化させうる可能性のあるものを例外要因１９とすることで記述可能である。

ここで図８に上記モデルを用いて太陽から発信された光が昼光センサ３を通じてソフトウェア内で昼と解釈されるまでの情報伝達過程に関するインスタンス図を、また図９には上述した３種類の非正常現象に対応したインスタンス図を記述した例を示す。

図８では光量、電圧、０／１がキャリアを、空間、導線（後述する銅線）、論理過程が情報フローパスとなり、太陽が昼光センサ３に対する情報発信者、昼光センサ３がＣＰＵ部５に対する情報変換ポイント、ＣＰＵ部５がソフトウェア３０に対する情報変換ポイントとなり、最終的にソフトウェア３０が情報受信者となり、太陽、昼光センサ３，ＣＰＵ部５，ソフトウェア３０の縦方向の要素が上から、記号、シンタクス、セマンティクスに対応する。

図９（ａ）〜（ｄ）は事例の昼光センサ付照明システムにおいて太陽から発信された光が昼光センサ３を通じて組み込みソフト内で昼と解釈されるまでの情報伝達過程に関するインスタンス図を示す。

図９（ａ）及び図９（ｄ）は上述したなりすましの記述例を示しており、光量がキャリア１４に、ヘッドライトが情報発信者１０に、空間が情報フローパス１２に、昼光センサ３が情報受信者１１に相当し、ヘッドライトがなりすましの情報発信者１０に夫々相当し、ヘッドライトの光量は多いので、昼光センサ３では閾値より多い光量を受光することになり、この閾値より多い光量に基づいて明るいと判断される。つまり太陽が出ていない夜間において昼間と判断されてしまうという非正常現象である。また、図９（ｄ）においてはシステム自身の出力である照明の光が原因の場合を示し、太陽が出てない夜間において自身の出力が昼光センサ３の閾値より多い光量の場合、昼光センサ３では閾値より多い光量を受光することになり、この閾値より多い光量に基づいて明るいと判断される。つまり太陽が出ていない夜の環境では昼光センサ３の受光する光量は閾値より少なく、この閾値より少ない光量に基づいて暗いと判断されるべきところ、自身の出力である照明の光が出ていない夜間において昼間と判断されてしまうという非正常現象である。

図９（ｂ）は情報フローパス１２での妨害の記述例を示しており、光量がキャリア１４に、木の葉が図７の情報フローパス妨害者１５に、太陽が情報発信者１０に、空間が情報フローパス１２に、昼光センサ３が情報受信者１１に夫々相当し、この場合空間に木の葉が存在することで、昼光センサ３が太陽から受光する光量が減少し、閾値より少ない光量となり、この閾値より少ない光量に基づいて暗いと判断される。つまり昼間において夜間と判断されてしまうという非正常現象となる。

図９（ｃ）は情報フローパス１２での妨害の記述例を示しており、光量がキャリア１４に、太陽が情報発信者１０に、空間が情報フローパス１２に、昼光センサ３が情報変換ポイント１３に、経年変化が図７の例外要因１９に夫々相当し、この場合昼光センサ３が太陽から受光する光量が経年劣化により閾値より少ない光量となり、この閾値より少ない光量に基づいて暗いと判断される。つまり昼間において夜間と判断されてしまうという非正常現象となる。
３）非正常現象が別の非正常現象の原因となる
非正常現象の発生箇所を情報発信者、または情報変換ポイントとみなし、非正常現象の結果発生した情報がキャリアによって次の非正常現象発生箇所である情報変換ポイント、または情報受信者に到達するもの、とみなすことで記述可能である。

以上のように、図７で示した非正常系概念モデルは、非正常系仕様の記述において考慮すべき項目のうち非正常現象に直接関与する項目について記述が可能である。

このような概念モデルに基づいて実現したのが本発明のソフトウェア開発支援システムであり、このソフトウェア開発支援システムを実施形態により説明する。

（実施形態１）
図１は本実施形態のハードウェア構成を示しており、図示するソフトウェア開発支援システムＡは開発対象ソフトウェアを用いるハードウェア要件、機能仕様、動作環境を含む開発対象のソフトウェアに関連する特徴情報の入力をユーザーから受け付ける入力手段２０ａ及びソフトウェア開発者であるユーザーに情報を提示する出力手段２０ｂを備えたユーザーインターフェース部２０と、特徴情報とこの特徴情報に関連する異常事象（上述した例外要因となる事象を含む）たる非正常現象との関連、各非正常現象間の関連、非正常現象に対応した処理内容を含むデータに基づいて構築された記憶装置内のデータベース２１と、ユーザーインターフェース部２０により受け付けた前記特徴のデータに基づいて前記データベース２１に格納している対応データを検索し、当該開発対象ソフトウェアに対して考慮すべき非正常事象を獲得してこれら獲得した事象に基づいた仕様の生成を行うとともに、生成した仕様と前記ユーザーインターフェース部２０で受け付けた前記特徴が示す仕様とを合成してソフトウェアの仕様を得、前記ユーザーインターフェース部の出力手段２０ｂを介して提示する演算処理部２２とから構成される。

ここで出力手段２０ｂはモニタ装置等の表示装置（及び印字装置）が用いられ、入力手段２０ａは表示装置での表示画面を用いたＧＵＩ（ポインティングデバイスの利用）やキーボードから構成される。

またデータベース２１には上述した分析や概念モデルに基づいて作成した利用キャリア対応テーブル（図２（ａ）参照）、情報受信者例外種別テーブル（図２（ｂ）参照）、情報フローパス妨害例テーブル（図２（ｃ）参照）を格納している。利用キャリア対応テーブルは上述した情報受信者、情報発信者、情報フローパスを伝達者種別とし、夫々の名称と、キャリアとを関連付けて記述している。また受信者例外種別テーブルは、情報受信者の種別毎に例外要因の種別と、影響を受けるキャリアと、影響内容を関連付けて記述している。更に情報フローパス妨害例テーブルは、情報フローパスの種別毎に妨害例、影響を受けるキャリア、影響内容を関連付けて記述している。図２で示す各テーブル例は上述した昼光センサ付照明システムの事例に対応させたものであるが、勿論各種組み込みシステムを考慮して当該テーブルが作成されるのは言うまでもない。

次に本実施形態の使用について図３の処理の流れを示す概念的システム図を用いて説明する。

まずソフトウェア開発者であるユーザーはユーザーインターフェース部２０の入力手段２０ａを用いて開発対象となるソフトウェアを用いるハードウェア要件、ソフトウェアの機能仕様、動作環境を含むソフトウェアの特徴情報（正常仕様）を入力する。

具体的には次の情報を入力する。
１）使用ハード：
ソフトウェアを用いるシステムで使用するハードウェアを記述する。
２）利用環境：
ソフトウェアを用いるシステムがどのような場所で利用されるかを記述する。つまりそのシステムが環境から受けうる影響を検索するための情報である。
３）入力：
ソフトウェアを用いるシステムに対して、どのハードウェアを経由して入力がなされるか、入力をどのように区別しているかを記述する。つまりシステムが想定している入力を、想定外の入力（誤操作・ノイズなど）と区別するための情報である。
４）出力：
ソフトウェアを用いるシステムが、どのハードウェアを経由して出力を行うか、出力はどのように区別されるかを記述する。つまりシステムが想定している出力を、想定外の出力（騒音・異常データ等）と区別するための情報である。
５）構成：
使用ハードがどのように接続されているか、またそれらの間はどのようなキャリア（情報を伝える媒体）で結び付けられているか。記述順としては左側が情報発信者で、真中がその間の情報フローパス、右側が 情報受信者で、最後にかっこ書き内にキャリアを表す。

ここで図６に示す昼光センサ付照明システムに組み込むソフトウェアについて本実施形態を用いて仕様決定の支援を受ける場合を例とすると、ユーザーたるソフトウェア開発者は開発対象となるソフトウェアの特徴情報を上述の１）〜５）の項目に対応する情報を次のように入力する。

１）使用ハード：昼光センサ、照明回路制御、タイマ、ＣＰＵ部
２）利用環境 ：一般屋外
３）入力：昼光センサ（光量：大／小）、タイマ（時間経過：パルス）
４）出力：照明回路（光量：点灯／消灯）
５）構成：昼光センサ→銅線→ＣＰＵ部（電圧）
タイマ→銅線→ＣＰＵ部（電圧）
ＣＰＵ部→銅線→タイマ（電圧）
＜※これはタイマリセットの場合を示す＞
ＣＰＵ部→銅線→照明回路（電圧）
昼夜一般屋外→昼光センサ（光量）
＊→＊タイマ（時間経過）
＜＊は特定の情報発信者やキャリアを特に持たない場合を示す。＞
照明回路→一般屋外→人間（光量）
このようにして入力手段２０ａを用いて情報入力を終了すると、ユーザーは演算処理部２１に入力確定の指示を入力手段２０ａから与えると、演算処理部２１は、上述した非正常仕様導出処理Ｓ２を開始する。つまり非正常現象についてデータベース２２のテーブルから検索する処理を開始する。

ここで演算処理部２１は「構成」の記述中、昼夜一般屋外→光センサ（光量）の記述に着目し、まず「なりすまし」の検出を行う。この場合、入力特徴情報「構成」に記述した各レコードに対して、キャリア（入力例では光量）をキーとし、伝達者種別が「発信者」であるようなレコードを、データベース２２に格納されている図２（ａ）に示す利用キャリア対応テーブルから検索する。ここでは、「太陽」、「ヘッドライト」、「懐中電灯」、「ネオンサイン」が検索されることになる。これら検索されたレコードはシステムに対して本来の昼夜情報とは違う情報を与える可能性のある情報発信者に対応する。

更に演算処理部２１は、「出力」の照明回路（光量）の記述に着目し、これを伝達者種別が「発信者」であるようなデータベース２２に格納されているキャリア対応テーブル内のレコードと同様に「なりすまし」検出の対象として扱う。その場合、システムの出力コードの内容において、情報伝達者種別は「情報発信者」、名称は「自身の出力」、キャリアは入力特徴情報「出力」に記載された「光量」として扱う。

次に、「情報フローパス妨害」の検出を行う。この場合入力特徴情報の「構成」に記述された各レコードに対して、情報フローパス（入力例では一般屋外）とキャリアをキーとして、データベース２２に格納されている図２（ｂ）に示すフローパス妨害例テーブルを検索する。

ここでは、「光を遮る障害物」が検索される。この「光を遮る障害物」がシステムに対して与えられるべき情報を妨害する可能性のあるものである。

次に「情報受信者例外」の検出を行う。つまり、情報受信者が受け取ったキャリアの解釈の仕方を誤ってしまうことによって、情報を誤解するタイプの異常事象（例外事象）を検出する。この場合入力特徴情報の「構成」に記述された各レコードに対して、受信者（上の例では昼光センサ３）とキャリアをキーとして、データベース２２に格納されている図２（ｃ）に示す情報受信者例外種別テーブルを検索する。ここでは、「受光感度変化」が検索される。この「受光感度変化」が情報受信者である昼光センサ３において、情報を誤解してしまう可能性として考慮すべき事項である。

このようにして３つの非正常現象についての関連情報を検索して当該ソフトウェアに対して考慮すべき非正常現象（異常事象）を取得した演算処理部２１では、この取得した非正常現象に基づいた非正常仕様を生成し（Ｓ２）、この生成した非正常仕様とユーザーが入力した特徴情報に含まれている正常仕様とを合成する処理を行い（Ｓ３）、この合成よって得られた開発対象のソフトウェア（システム）の全体仕様内容をユーザーインターフェース部２０の出力手段２０ｂを通じてユーザーに提示する（Ｓ４）。ユーザーはこの提示された仕様を開発しようとするソフトウェアの作成に反映させることで、ユーザーが特に様々な非正常現象について知らなくても、トラブルを起こさないソフトウェアを作成することができることになる。

尚図３は上記処理の流れを概念的に示したシステム構成図であり、この図に示すように演算処理部２０は正常仕様を特徴情報として入力手段２０ａから受け取ると、データベース２１の各テーブルの検索により非正常仕様の導出処理Ｓ１を行い、この導出処理Ｓ１から非正常仕様作成Ｓ２、正常仕様と非正常仕様による仕様合成処理Ｓ３を経て出力手段２０ｂによる全体仕様提示Ｓ４の処理を順次行うのである。
（実施形態２）
上記実施形態１では非正常現象を反映させた全体仕様をソフトウェア開発者に提示するものであったが、本実施形態では演算処理部２１に非正常現象の要因と現象発生に至るプロセスの分析を行うことにより、状態とイベントとのマトリクスを作成し、該マトリクスをユーザーインターフェース部２０の出力手段２０ｂよりソフトウェア開発者に提示する分析機能をも備えている点に特徴がある。

次に本実施形態の分析機能を実現するに至るまでに、本発明者らが上述したような非正常現象を引き起こす要因等について考察した結果を簡単に説明する。

まず非正常現象を引き起こす要因は、外部或いは内部の発生事象であり、直接のシステムだけでなく、システムを取り巻く環境も考える必要がある。これらの挙動を分析することにより、非正常現象の特性が把握でき、それによる障害影響を最小にすることができる。そのためには、まず外部に起因する非正常系の一次要因の抽出を抜け漏れなく行うことが必要であり、そのための仕組みを作る必要がある。一次要因の一例として、環境、機構、機構、回路、施工、運用、処理等の項目がある。一方過去の経験がない新たなシステムの非正常系の要因を抽出するためには、抽象化した視点からの分析が必要であり、非正常系の要因から発生する現象を、ソフトウェア処理視点から見た非正常系の要因としては、情報の意味、情報の量、情報の時間、情報の構成、情報の対象、情報の状態等がある。

また状態の組み合わせによる非正常現象の発生もある。例えば携帯電話が鳴ること、車を運転していることはそれぞれ問題ではないが、前の車が急停車するという非正常な状態で、たまたま運転中であり、かつ携帯電話が鳴りだした場合にのみ、気を携帯電話にそらしてしまい、ブレーキへの対応が遅れ事故が発生する。このように、非正常系が要因となるが、他の特殊な状態と組み合わさった場合のみ障害が発生する。このため、組み合わせを充分配慮しないと検討もれが発生する。発生する状況としては、通常の状態で、非正常イベント発生時に非正常事象が生じる場合、非正常状態で、通常のイベント発生時に非正常事象が生じる場合、非正常状態で、非正常イベント発生時に非正常事象が生じる３つの場合があるため、非正常系の分析には、正常なイベント、正常な状態、非正常なイベント、非正常な状態を組み合わせて分析する必要がある。

更に非正常現象は、上述したような一次要因から連鎖的に生じることもあるが、このプロセスを分析することにより抜けのない非正常現系の抽出が可能になる。

また非正常現象の分析としてタイミングによる問題も重要な課題として取り上げなければならない。タイミングに関して、障害要因を分類すると、競合や衝突、リソース不足、状態等の遷移中や処理中による不安定期間に分類できる。

そして非正常現象への対応は、一次的な非正常系で対応できれば連鎖を考える必要がないが、連鎖したプロセスの過程でしか対応できない場合も多い。例えば、煙感知器による火災判断の場合、火災の煙以外にタバコの煙による誤作動の可能性がある。煙センサからの入力としてはフィルタリングできないが、アプリケーションレベルでは、例えば、部屋の人感センサが煙発生以前から点灯している、部屋の電気鍵が開けられている、部屋の照明が点灯している、火災の熱検知器は作動していないといったことから煙による火災検知の誤報をフィルタリングできる。このため、非正常系の最も効率が高くかつ確実に対応するためには、非正常系の障害へのプロセスを分析し、全体的な視点から対策を施すことが重要となってくる。

さて組み込みシステムでの障害（非正常現象）の分析は、前述したように一次非正常要因、組み合わせ、連鎖といった非正常系から障害へのプロセス分析を必要とする。

このような結果から、状態とイベントによりシステムの動きを網羅的にとらえることで、ソフトウェアの挙動を設計していくことができる分かった。そこで非正常現象（障害）の分析としての非正常系分析手法として、状態遷移表を分析段階に拡張し、イベントと状態のマトリクスよる分析が可能であると考えて実現したのが本実施形態の演算処理部２１での分析機能である。

まず分析機能は、分析段階で概念的な抽象状態（正常系）と抽象イベント（正常系）をその対象とし抽出する機能と、システムの環境や構成要因から、外部の非正常要因を検討することにより、一次的な非正常イベントを抽出する機能を備えており、これにより、状態とイベント（正常、一次非正常）の表を作成する。

次にこの表のマトリクス部分に注目していくことにより、組み合わせにより連鎖的に発生する非正常系を抽出する機能を備えている。ここでの非正常系は、回避処理により影響を受けないようにできる場合とできない場合があるが、できない場合は、分析機能は、二次的非正常系の状態やイベントとして新たに追加し、これをマトリクス部分の状態やイベントの項目に追加してマトリクスを拡張する処理を行う。これを続けていった場合、ある障害可能性に対し、回避処理により防ぐことができるか、障害を受け入れざるを得ない状態になり、それ以上新たな非正常系がなくなった時点で非正常系の抽出が完了する。

図４は本実施形態の演算処理部２１が備えている分析機能により非正常分析のためのマトリクスの作成の概要を示しており、図示する（１）の段階では一次非正常イベントの作成の段階に対応し、この段階では開発しようとするソフトウェアを用いるシステムの構成要件と機能、運用状態を分析し、これにより正常イベントの抽出を行った後、一次非正常イベントの抽出を行う。この場合外部からの一次非正常系イベントの抽出に対して、非正常系の要因から抽出する方法と、システムのＣＰＵ部から見た非正常系の項目と照らし合わせて抽出する方法がある。非正常系の要因としては、上述した非正常系の要因である環境、機構、回路、施工、運用、処理といった要因のリスト（これは図１でのデータベースに格納しているものとする）と、システム構成のマトリクスから一次非正常イベントを抽出する。また、ソフトウェア処理からの要因項目としても、同様にシステム構成要素と要因とのマトリクスから抽出する。

次の（２）の段階は初期の非正常分析マトリクスを作成する段階であって、（１）の段階で得られた正常、一次非正常イベント、正常状態から初期の非正常分析マトリクス表を作成する。また（３）の段階は新たな非正常系の抽出の段階であって、各イベントと状態の交点での挙動を検討し、新たな非正常系の発生可能性を検討する。交点があり得ないもの、新たな非正常系が発生しないものは、マトリクスの当該欄の対して網掛け等の検討済みのマークを行い、処理は記述しない。次の（４）の段階は抽出した非正常系の分析を行う段階であって、非正常系が発生する可能性がある場合、その検出方法と回避方法の検討を行う。そのために新たな処理機能を追加し、その処理機能により新たな状態が発生する場合や発生する可能性のある非正常系を回避できない場合には新たな非正常系状態と非正常系イベントが発生することになり、そのため状態とイベントの交点には発生する非正常系を、また非正常系の回避が可能であって処理することが妥当な場合には、その検出方法を、検出した非正常系の回避方法を記入する処理を行う。（５）の段階は非正常系イベントと状態の展開を行う段階で（４）の段階で抽出できた非正常系に対して、回避処理が行え、外部に影響を全く発生させない場合は、新たな非正常イベントとし、非正常状態は発生しない。また回避処理を行っても非正常の影響を与える場合は、新たな状態或いはイベントとし、マトリクスに追加拡張する。これにより新たに拡張した非正常系の状態とイベントは、正常系や、抽出済みの他の非正常系との相互作用により、更に次の非正常系の可能性について分析する。非正常処理機能を考える場合、その発生方法を理解し、それに応じた対応を取らなければならないため、連鎖している状況をマトリクスから逆にトレースする。そして（５）の段階で展開した状態やイベントに、どのイベントと状態により発生したかを連鎖コードとして、イベント或いは状態項目の欄に記入する。

このようにして最終的に次の段階（６）で非正常分析マトリクスからなる表が完成することになる。この場合すべての交点から新たな非正常系の抽出がない、対応できない、必要がなく運用等でカバーできるといった展開できなくなるまで分析を行う。

そしてこの完成したマトリクスからなる表を出力手段２ｂによりソフトウェア開発者に提示することで、状態とイベント発生の関係が一目で分かることになる。尚マトリクスの表に記述された、非正常系と検出方法、対応方法を表に記述し、非正常系処理要件としてまとめる処理も本実施形態の演算処理部２１の分類機能を備えている。

次に図６に示す昼光センサ付照明システムの事例に基づいて説明する。まず図１のソフトウェア開発支援システムで本実施形態におけるマトリクスを用いる分析機能を働かせるためには、上述した特徴情報以外に予めユーザーインターフェース部２０の入力手段２０ａを用いてソフトウェアを組み込むシステムの状態情報と、イベントの情報を
初期：初期化処理中
昼の処理中（光量＝大）
夜の処理中（光量＝小）
と記述して入力する。

そして入力が終了して分析の指示を与えると演算処理部２１は分析機能を働かせて上述した（１）〜（６）の段階に基づいた処理を行う。

演算処理部２１は昼光センサ３の構成であるケース、センサ回路、処理機能に対して、障害要因と照らし合わせながら、初期状態の一次非正常イベントとして、早朝・夕方、街路樹の陰、汚れ・経年劣化、車のヘッドライト、ノイズ、停電・リセット、昼光センサ３の故障を抽出する。図５のマトリクス表では、状態コードとしてＡ、Ｂ、で表し、イベントコードとして１、２、で表す。またマトリクスの交点を、例えばＡ５のように示す。状態とイベントの各下には連鎖コードとして、どのマトリクスの交点から新たな状態やイベントとして展開したかを記している。各交点には３行あり、上から発生しうる非正常系、検出方法、対策方法として記している。実際には詳しく記すが表の見易さのために簡略化している。

そして図５では状態としてのＡからＥ、イベントとしての１から９のマトリクスの部分が、初期状態の昼光センサ３の処理に関するマトリクスとして作成した部分となる。

そして初期状態のマトリクスを作成した後、マトリクスの展開を行う処理に入る。ここで、Ｂ７の電気的ノイズにより、昼光センサ３のセンサ回路に誤動作を与え、アナログ／デジタル変換ミスにより入力値が一時的に変化してしまう可能性がある。また、Ｄ４の太陽光が街路樹の影になる場合、木の葉の風による揺らぎや枝、幹など遮り方を配慮する必要がある。更にＥ６の車のヘッドライトを受光した場合、センサ入力値が一時的に変化する。昼光センサ３のセンサ回路の故障により昼光センサ３の出力値が発振した場合も考慮する必要があり、それらの要因による照明ちらつき防止のため、平均値処理によるノイズ除去を追加する必要があり、そこでその処理をＦとして付け加える。

またＦ４、Ｇ４、Ｆ６、Ｇ６のように回避処理からではすべての昼光センサ３の出力値の読み間違えを回避することは不可能であり、昼光センサ３の出力値の誤入力イベントとして１２を加える。またＤ３、Ｅ３の早朝・夕方では、昼光センサ３が昼と夜の判断付近でセンサオン、オフの判断変化を繰り返し、照明がちらつく可能性があるため、充分照度が低下して昼光センサ３をオフに、充分照度が高くなってからオン処理を行う必要がある。このため、その間の照度での処理をＧに展開する。Ａ５、Ｂ５のケースの汚れやセンサ回路の経年劣化から、センサ入力値が低下していくことになり、非正常系イベントとして１１を付け加える。更にＤ１１では、昼光センサ３が劣化した場合、昼の判断処理が経年的にずれてくるため、一日の最大値と最小値を計算し、それから昼と夜の判定レベルを計算し、動的に変化させることにより劣化や汚れに強いシステムとなるため、この処理をＨに追加する。また、センサ入力値の絶対値が小さくなっており、問題が発生する可能性があるため、この状態をＩに追加する。Ｂ９の昼光センサ３のセンサ回路故障時では、あり得ない値になるか、値が固定になるか、発振する。発振に対する対応は、Ｆ、その他の故障判断処理を追加してＪとし、昼光センサ３の故障判断したというイベントを１３に追加する。また、これらの判断ができない場合は、センサ値を読み間違えるため、１２にも展開する。Ｄ１２、Ｅ１２では、ノイズ等の除去ができなかったセンサ入力エラーのため、誤動作する可能性があるが、最悪でも短時間に照明がちらつくことがないように変化判断後一定時間は判断を変えない処理を付け加え、Ｋに展開する。Ｊ４では、センサ故障判断中に街路樹の木の葉の揺れで太陽光が遮られることが同時に発生した場合を考える必要があり、実験などにより適切なアルゴリズムを考える必要がある。Ｉ４では、昼光センサ３が汚れてセンサの絶対値が低下している状態で、街路樹による太陽光の遮りは全体レベルが低下しているため、通常は問題ないが、受光部が平面でなく突起しているなどむらのある汚れ方をしている場合、その方向によって影響を受けてしまう可能性がある。これについては、受光部がむらのある汚れをしないような構造にしなければならない。Ｈ８の瞬時停電があった場合、前日までの平均値処理がリセットされるため、経年劣化が進んでいる場合、昼夜の判断レベルが一日間行えない。また、Ｇ８の停電リセット状態で、Ｆの昼夜判定レベルの中間にあった場合、判定ができないため、不定とする。Ｃ１３の昼光センサ３の故障認識状態で、初期化処理が発生した場合、故障認識がリセットされ、センサ判断を誤る可能性があるため、初期処理時にセンサ判断処理を加えることにより誤動作を回避する。

以上の処理を演算処理部１２の分析機能が検討し、図５に示す昼光センサ３の非正常分析マトリクスを生成するのである。この生成したマトリクスは出力手段２０ｂを通じて開発者に提示する。

尚図５より昼光センサ３の非正常系仕様要求要件を整理し、
(I)早朝・夕方の照明のちらつきを防止するために、昼光センサ３のオンの判定レベルとオフの判定レベルに充分幅を持たせ、一旦昼と判断した場合、充分暗くならないと夜と判断しないようにする。
(II)街路樹などの陰、電気的ノイズ、ヘッドライト、センサ故障時の発振に、できる限り誤動作しないセンサ平均化処理を組み込む。
(III)センサ受光部の汚れ、センサ回路の経年劣化に対応するため、一日の変化を記録し、昼と夜の判断レベルを変化させる。停電・リセット時にはデータが消えるため、規定値に戻し一日は補正が効かない仕様とする。
(IV）初期化処理時と常時定期的にセンサ故障判定を行う。センサ故障時は、センサ値を不定値として扱う。
(V)平均値処理時には、太陽光の街路樹による遮りが発生するが、判定レベルには問題ないよう配慮する。
(VI)センサ判断は環境により確実ではないため、最悪照明のちらつきが発生しないようにセンサ判断変化後一定時間は再変化させない。
（VII)センサ故障判断処理については、街路樹の陰など、値が連続的に大きく変化する環境もあるため、実験しアルゴリズムを定める。

という内容を記述した非正常要求仕様要件表を作成して出力手段２０ｂを通じて提示する処理も行う。

このようにして作成された図５に示すマトリクスの表を状況説明資料として用いることができるため、きめ細かい処理を行うソフトウェアを作成することが可能となる。また、システム評価段階で、非正常系仕様抽出の資料として、非正常系の試験を抜けなく実施し確認することが可能となるのである。

実施形態１のシステム構成図である。 （ａ）〜（ｃ）は実施形態１のデータベースに格納されているテーブルの構成図である。 実施形態１の概念的なシステム図である。 実施形態２の分析機能の処理段階の説明図である。 実施形態２で生成されるマトリクスの説明図である。 非正常現象の分析に用いた事例の構成を示し、（ａ）は昼光センサ付照明システムの側面図、（ｂ）は回路構成図である。 非正常系概念モデルの説明図である。 昼光センサ付照明システムの事例における情報伝達過程に関するインスタンス図である。 昼光センサ付照明システムの事例における非正常現象発生に対応したモデルにおけるインスタンス図である。

符号の説明

Ａ ソフトウェア開発支援システム
２０ ユーザーインターフェース部
２０ａ 入力手段
２０ｂ 出力手段
２１ 演算処理部
２２ 記憶部

Claims (2)

1. 開発対象のソフトウェアを用いるハードウェア要件と該ソフトウェアの機能仕様と動作環境とを含む前記ソフトウェアの特徴情報を使用者から受け付ける入力手段と使用者に情報を提示する出力手段を備えたユーザーインターフェース部と、前記特徴情報と異常事象との関連、異常事象間の関連、異常事象と異常事象に対する処理内容との関連を含む関連情報に基づいて構築されたデータベースと、前記特徴情報に基づいて前記データベースに格納している前記関連情報を検索し、前記ソフトウェアに対して考慮すべき異常事象を取得して、取得した事象に基づいた仕様の生成を行うとともに、生成した仕様と前記特徴情報とを合成して前記ソフトウェアの仕様として前記出力手段を介して提示する処理部とを備えていることを特徴とするソフトウェア開発支援システム。
2. 前記処理部は、前記異常事象の要因と事象発生に至るプロセスの分析を行うことにより、状態とイベントとのマトリクスを作成し、該マトリクスを前記出力手段より使用者に提示する分析機能を備えることを特徴とする請求項１記載のソフトウェア開発支援システム。
   

Images