(57)【要約】  本発明は、ソフトウェア開発の要件漏れを抑制する開発進捗管理装置又は開発進捗管理方法の提供を目的とする。本発明の開発進捗管理装置は、開発すべきソフトウェアの要求を取得する要求取得部と、要求の開発工程における前後の開発工程の成果物間の対応関係を示すトレーサビリティマトリクスを取得し、その取得状況に基づき開発工程の移行可否を判定する工程移行可否判定部と、を備える。トレーサビリティマトリクスは、本来機能要件に関する第１トレーサビリティマトリクスと、第１トレーサビリティマトリクスよりも粒度が細かく安全機能要件に関する第２トレーサビリティマトリクスと、を含む。機能安全要求に対する工程移行可否判定部３２の移行可の判定条件は、工程移行可否判定部３２が現工程についての第１トレーサビリティマトリクス及び第２トレーサビリティマトリクスを取得することを含む。
2017122285.tif 000002
【特許請求の範囲】
【請求項１】
開発すべきソフトウェアの要求を取得する要求取得部と、
前記要求の開発工程における前後の開発工程の成果物間の対応関係を示すトレーサビリティマトリクスを取得し、その取得状況に基づき前記開発工程の移行可否を判定する工程移行可否判定部と、を備え、
前記要求は、機能安全に関わる機能安全要求と、機能安全に関わらない通常要求とを含み、
前記機能安全要求は、機能安全に関わる安全機能要件と前記安全機能要件以外の本来機能要件とを含み、
前記通常要求は、前記本来機能要件のみを含み、
前記トレーサビリティマトリクスは、前記本来機能要件に関する第１トレーサビリティマトリクスと、前記第１トレーサビリティマトリクスよりも粒度が細かく前記安全機能要件に関する第２トレーサビリティマトリクスと、を含み、
前記機能安全要求に対する前記工程移行可否判定部の移行可の判定条件は、前記工程移行可否判定部が現工程についての前記第１トレーサビリティマトリクス及び前記第２トレーサビリティマトリクスを取得すること、を含む、
開発進捗管理装置。
【請求項２】
前記ソフトウェアの要求が前記通常要求か前記機能安全要求かに応じて、異なる開発工程を設定する開発工程設定部をさらに備える、
請求項１に記載の開発進捗管理装置。
【請求項３】
前記工程移行可否判定部は、前記通常要求に対し前記機能安全要求より緩い条件で工程移行可否を判定する、
請求項１に記載の開発進捗管理装置。
【請求項４】
前記通常要求に対する前記工程移行可否判定部の移行可の判定条件は、前記工程移行可否判定部が現工程についての前記第１トレーサビリティマトリクスを取得すること、を含む、
請求項３に記載の開発進捗管理装置。
【請求項５】
開発すべきソフトウェアの要求を取得し、
前記要求の開発工程における前後の開発工程の成果物間の対応関係を示すトレーサビリティマトリクスを取得し、
前記開発工程の移行可否を判定し、
前記要求は、機能安全に関わる機能安全要求と、機能安全に関わらない通常要求とを含み、
前記機能安全要求は、機能安全に関わる安全機能要件と前記安全機能要件以外の本来機能要件とを含み、
前記通常要求は、本来機能要件のみを含み、
前記トレーサビリティマトリクスは、前記本来機能要件に関する第１トレーサビリティマトリクスと、前記安全機能要件に関し前記第１トレーサビリティマトリクスよりも粒度が細かい第２トレーサビリティマトリクスと、を含み、
前記機能安全要求に対する工程移行可の判定条件は、現工程についての前記第１トレーサビリティマトリクス及び前記第２トレーサビリティマトリクスを取得することを含む、
開発進捗管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア開発の進捗を管理する技術に関する。
【背景技術】
【０００２】
ソフトウェアの開発においては、要求ごとに機能設計、方式設計、詳細設計といった各設計工程が実施される。これら各設計工程で漏れなく設計を行うためには、各設計書間のトレーサビリティを確立することが望ましい。【０００３】
しかし、従来こうしたトレーサビリティの確立状況とソフトウェア開発工程の進捗状況とは同期がとれていないため、本来ある工程で作成すべき成果物が作成されずに工程が進められることがあった。その結果、必要な機能の実装漏れが生じる場合があった。【０００４】
また、機能安全規格（ＩＥＣ６１５０８、ＩＳＯ２６２６２など）では、機能安全要件の確実なトレーサビリティの確保が求められている。従って、ソフトウェアの開発においては、トレーサビリティの確保とそれに基づく進捗管理を行う必要がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２０１４−５３４５３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
この点、特許文献１には、Ｖ字のトレーサビリティが確立しているかを計測し、確立していない場合にユーザに警告するシステムを提案している。しかし、より一層トレーサビリティを確保し、要件漏れの無い開発進捗管理が求められている。【０００７】
本発明は上述の問題点に鑑み、ソフトウェア開発の要件漏れを抑制する開発進捗管理装置又は開発進捗管理方法の提供を目的とする。
【課題を解決するための手段】
【０００８】
本発明の開発進捗管理装置は、開発すべきソフトウェアの要求を取得する要求取得部と、要求の開発工程における前後の開発工程の成果物間の対応関係を示すトレーサビリティマトリクスを取得し、その取得状況に基づき開発工程の移行可否を判定する工程移行可否判定部と、を備え、要求は、機能安全に関わる機能安全要求と、機能安全に関わらない通常要求とを含み、機能安全要求は、機能安全に関わる安全機能要件と安全機能要件以外の本来機能要件とを含み、通常要求は、本来機能要件のみを含み、トレーサビリティマトリクスは、本来機能要件に関する第１トレーサビリティマトリクスと、第１トレーサビリティマトリクスよりも粒度が細かく安全機能要件に関する第２トレーサビリティマトリクスと、を含み、機能安全要求に対する工程移行可否判定部の移行可の判定条件は、工程移行可否判定部が現工程についての第１トレーサビリティマトリクス及び第２トレーサビリティマトリクスを取得すること、を含む。【０００９】
本発明の開発進捗管理方法は、開発すべきソフトウェアの要求を取得し、要求の開発工程における前後の開発工程の成果物間の対応関係を示すトレーサビリティマトリクスを取得し、開発工程の移行可否を判定する。開発すべきソフトウェアの要求は、機能安全に関わる機能安全要求と、機能安全に関わらない通常要求とを含む。機能安全要求は、機能安全に関わる安全機能要件と安全機能要件以外の本来機能要件とを含み、通常要求は、本来機能要件のみを含む。トレーサビリティマトリクスは、本来機能要件に関する第１トレーサビリティマトリクスと、安全機能要件に関し第１トレーサビリティマトリクスよりも粒度が細かい第２トレーサビリティマトリクスと、を含む。機能安全要求に対する工程移行可の判定条件は、現工程についての第１トレーサビリティマトリクス及び第２トレーサビリティマトリクスを取得することを含む。
【発明の効果】
【００１０】
本発明の開発進捗管理装置は、開発すべきソフトウェアの要求を取得する要求取得部と、要求の開発工程における前後の開発工程の成果物間の対応関係を示すトレーサビリティマトリクスを取得し、その取得状況に基づき開発工程の移行可否を判定する工程移行可否判定部と、を備え、要求は、機能安全に関わる機能安全要求と、機能安全に関わらない通常要求とを含み、機能安全要求は、機能安全に関わる安全機能要件と安全機能要件以外の本来機能要件とを含み、通常要求は、本来機能要件のみを含み、トレーサビリティマトリクスは、本来機能要件に関する第１トレーサビリティマトリクスと、第１トレーサビリティマトリクスよりも粒度が細かく安全機能要件に関する第２トレーサビリティマトリクスと、を含み、機能安全要求に対する工程移行可否判定部の移行可の判定条件は、工程移行可否判定部が現工程についての第１トレーサビリティマトリクス及び第２トレーサビリティマトリクスを取得すること、を含む。粒度の異なる複数のトレーサビリティマトリクスの取得を次工程への移行条件とすることにより、要件のトレーサビリティが確保されるため、要件漏れの少ない高品質なソフトウェアを開発することが出来る。【００１１】
本発明の開発進捗管理方法は、開発すべきソフトウェアの要求を取得し、要求の開発工程における前後の開発工程の成果物間の対応関係を示すトレーサビリティマトリクスを取得し、開発工程の移行可否を判定する。開発すべきソフトウェアの要求は、機能安全に関わる機能安全要求と、機能安全に関わらない通常要求とを含む。機能安全要求は、機能安全に関わる安全機能要件と安全機能要件以外の本来機能要件とを含み、通常要求は、本来機能要件のみを含む。トレーサビリティマトリクスは、本来機能要件に関する第１トレーサビリティマトリクスと、安全機能要件に関し第１トレーサビリティマトリクスよりも粒度が細かい第２トレーサビリティマトリクスと、を含む。機能安全要求に対する工程移行可の判定条件は、現工程についての第１トレーサビリティマトリクス及び第２トレーサビリティマトリクスを取得することを含む。粒度の異なる複数のトレーサビリティマトリクスの取得を次工程への移行条件とすることにより、要件のトレーサビリティが確保されるため、要件漏れの少ない高品質なソフトウェアを開発することが出来る。【００１２】
本発明の目的、特徴、態様、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係る開発進捗管理装置の構成を示す概略図である。
【図２】機能安全要求の開発工程を示す図である。
【図３】通常要求の開発工程を示す図である。
【図４】開発進捗管理部の内部構成を示す図である。
【図５】開発工程設定部の動作を示すフローチャートである。
【図６】プロセス定義データを示す図である。
【図７】ワークフロー管理データを示す図である。
【図８】プロセスワークフロー管理部の動作を示すフローチャートである。
【図９】工程移行可否判定部の動作を示すフローチャートである。
【図１０】工程移行条件定義データを示す図である。
【図１１】機能安全要求のトレーサビリティマトリクスを示す図である。
【図１２】通常要求のトレーサビリティマトリクスを示す図である。
【図１３】開発進捗管理装置のハードウェア構成を示す図である。
【図１４】ワークフロー管理データを示す図である。
【図１５】ワークフロー管理データを示す図である。
【発明を実施するための形態】
【００１４】
＜Ａ．実施の形態１＞
図１は、実施の形態１に係る開発進捗管理装置１０１の構成を示す概略図である。開発進捗管理装置１０１は、顧客からのソフトウェア要求仕様書を取得し、それに従って要求ごとに開発工程の進捗管理を行う。
【００１５】
開発進捗管理装置１０１は、要求入力部１、要求格納部２、開発進捗管理部３、開発成果物格納部４、トレーサビリティマトリクス（Ｔｒａｃｅａｂｉｌｉｔｙ  ｍａｔｒｉｘ：ＴＭ）格納部５及び定義格納部６を備えて構成される。
【００１６】
要求入力部１は、顧客からのソフトウェア要求仕様書を取得する。ソフトウェア要求仕様書には、顧客が希望するソフトウェアの要求が複数記載されている。要求とは、機能又は非機能として実現を期待されているもので、顧客又は上位設計から与えられる仕様を意味する。要求のうち、機能安全に関わる要求を機能安全要求といい、それ以外の要求を通常要求という。要求がそのいずれに該当するかは、予め要求仕様書に記載されている。要求入力部１が取得したソフトウェア要求仕様書は、要求格納部２に格納される。
【００１７】
開発進捗管理部３は、要求格納部２からソフトウェア要求仕様書を取得し、これに記載された要求ごとに工程移行条件を設定する。また、要求を実現するために、要求をソフトウェア開発レベルで具体的にした要件ごとに、開発工程を設定する。一般に、１つの要求は複数の要件で実現されるが、１つの要件で実現される場合もある。
【００１８】
開発成果物格納部４には、開発作業の結果として作成された方式設計書などの開発成果物が格納される。ここに格納される開発成果物には、本来機能開発成果物４Ａと安全機能開発成果物４Ｂとがある。
【００１９】
ＴＭ格納部５には、本来機能要件の開発において作成されるＴＭ（本来機能ＴＭ５Ａ）と、安全機能要件の開発において作成されるＴＭ（安全機能ＴＭ５Ｂ）とが格納される。
【００２０】
定義格納部６には、機能安全要求と通常要求の夫々について工程移行条件と開発工程とを定義したデータが格納されている。開発進捗管理部３はこのデータを参照して、上記の設定を行う。
【００２１】
図２に、機能安全要求の開発工程を示す。機能安全要求の開発は、安全要件定義、要求分析、機能設計（安全分析）、方式設計（安全分析）、詳細設計（安全分析）、コーディング（安全分析）、単体試験（安全分析）、統合試験（安全分析）、ＳＷ試験（安全分析）、システム試験、安全要件検証の順に行われる。
【００２２】
要求分析工程では、要求を分析して開発すべき１又は複数の要件を導出する。要件のうち、機能安全に関わる要件を安全機能要件といい、それ以外の要件を本来機能要件という。例えば、「車のディスプレイでＤＶＤを再生する」を機能安全要求とすると、「走行中のＤＶＤ画面表示を禁止する」を安全機能要件、「ＤＶＤを再生する」を本来機能要件と考える事が出来る。機能安全要求は少なくとも一つの安全機能要件を含んでおり、全ての要求は少なくとも一つの本来機能要件を含んでいる。
【００２３】
要求分析工程では、成果物として要求分析書が作成される他、要求分析書の内容と要求との対応関係を示すトレーサビリティマトリクス（ＴＭ）が作成される。ＴＭとは、異なる工程間で成果物の対応関係を示す情報であり、これにより、漏れなく開発が行われているかを追跡することが出来る。これらの成果物及びＴＭは、本来機能要件と安全機能要件とに分けて作成される。上述の例で言えば、「車のディスプレイでＤＶＤを再生する」という機能安全要求と「走行中のＤＶＤ画面表示を禁止する」という安全機能要件との対応関係を示すＴＭが安全機能ＴＭ５Ｂであり、当該機能安全要求と「ＤＶＤを再生する」という本来機能要件との対応関係を示すＴＭが本来機能ＴＭ５Ａである。なお、ここでは本来機能要件と安全機能要件との間で、成果物及びＴＭを異なる文書として作成することについて説明しているが、両者を識別することが出来るならば、これらの成果物及びＴＭは同じ文書上に記載されていても良い。
【００２４】
要求分析工程は、安全機能要件を定義する工程でもある。従って、安全機能要件に対して本工程は安全要件定義工程ともいう。
【００２５】
機能設計工程では、要件を実現するためのソフトウェアのコンポーネントの構造設計、コンポーネント間のインタフェースの設計、動的振る舞いの設計、リソース管理の設計等を実施する。なお、コンポーネントとは、ＳＷ（ソフトウェア）システムをナビ、電話、オーディオといった機能レベルに分解したものをいう。機能設計工程では、成果物として機能設計書が作成され、さらにトレーサビリティマトリクス（ＴＭ）が作成される。これらは、安全機能要件と本来機能要件のそれぞれについて作成される。ここで作成されるＴＭは、要求分析書の内容と機能設計書の内容との対応関係を示す情報であり、具体的には、要求分析書に記載された要件の機能設計内容が、機能設計書のどこに記載されているかを示す情報である。なお、図２には機能設計（安全分析）と示しているが、これは、安全機能要件に対しては、通常の機能設計に加えて安全分析を行うことを意味している。安全分析では、製品に潜む危険の抽出や製品が万一故障したときに発生する可能性のある危険事象を抽出して、それらの対策を施す設計を行う。後述する方式設計及び詳細設計についても、安全機能要件に対しては機能分析と同様に、通常の設計に加えて安全分析を行う。その他、安全分析に加えて従属故障分析を行うこともある。
【００２６】
方式設計工程では、要件を実現するためのコンポーネントのサブコンポーネントの構造設計、サブコンポーネント間のインタフェースの設計、動的振る舞いの設計、リソース管理の設計等を実施する。なお、サブコンポーネントとはコンポーネントを更に分解したものであり、ソフトウェアの大きさによりサブコンポーネントは複数にレベル分けされる場合がある。方式設計工程では、成果物として方式設計書が作成され、さらにトレーサビリティマトリクス（ＴＭ）が作成される。これらは、安全機能要件と本来機能要件のそれぞれについて作成される。ここで作成されるＴＭは、機能設計書の内容と方式設計書の内容の対応関係を示す情報であり、具体的には、機能設計書に記載された設計内容に対応する方式設計内容が方式設計書のどこに記載されているかを示す情報である。
【００２７】
詳細設計工程では、ユニット（関数、クラスレベル）単位でそのロジックやインタフェースが設計される。ユニットとは、サブコンポーネントを関数（クラス）レベルに分解したもので、ソフトウェアを構成する最小単位である。この工程では、成果物として詳細設計書が作成され、さらにトレーサビリティマトリクス（ＴＭ）が作成される。これらは、安全機能要件と本来機能要件のそれぞれについて作成される。ここで作成されるＴＭは、このトレーサビリティマトリクスは、方式設計書の内容と詳細設計書の内容の対応関係を示す情報であり、具体的には、方式設計書に記載された設計内容に対応する詳細設計内容が詳細設計書のどこに記載されているかを示す情報である。
【００２８】
コーディング工程では、詳細設計に従いコンピュータのプログラム（コード）を製作する。この工程では、成果物としてソースコードとトレーサビリティマトリクス（ＴＭ）が作成される。このトレーサビリティマトリクス（ＴＭ）は、詳細設計の各設計項目とコードとの対応関係を示すものである。なお、図２にはコーディング（安全分析）と示しているが、これは、安全機能要件に対しては、通常のコーディングに加えて、機能安全要求の開発にあたって達成すべきコーディング条件が守られていることを確認することを意味している。
【００２９】
単体試験工程では、関数又はクラスレベルでプログラム（コード）が詳細設計通りに動作するかを検証する。ここでは成果物として単体試験成績書が作成され、さらにトレーサビリティマトリクス（ＴＭ）が作成される。ここで作成されるＴＭは、詳細設計書と単体試験成績書との対応関係を示すものである。具体的には、詳細設計の設計項目の試験成績が単体試験成績書のどの部分に記載されているかを示している。
【００３０】
統合試験工程では、各ユニット間、サブコンポーネント間のインタフェースが方式設計書通りに動作するかを検証する。ここでは成果物として、統合試験成績書が作成され、さらにトレーサビリティマトリクス（ＴＭ）が作成される。ここで作成されるＴＭは、方式設計書と統合試験成績書との対応関係を示している。具体的には、方式設計の設計項目の試験成績が統合試験成績書のどの部分に記載されているかを示している。
【００３１】
ソフトウェア（ＳＷ）試験工程では、コンポーネントとして機能設計通りのソフトウェアになっているかを検証する。ここでは成果物として、ソフトウェア試験成績書が作成され、さらにトレーサビリティマトリクス（ＴＭ）が作成される。ここで作成されるＴＭは、機能設計書とソフトウェア試験成績書との対応関係を示している。具体的には、機能設計の設計項目の試験成績がソフトウェア試験成績書のどの部分に記載されているかを示している。
【００３２】
システム試験工程では、ソフトウェアシステム全体として、要件通りのソフトウェアとなっているかを検証する。なお、この工程は、安全機能要件の開発では、安全機能要件通りのソフトウェアとなっているかを検証するため、安全要件検証工程と呼ばれる。この工程では、成果物として、システム試験成績書とトレーサビリティマトリクス（ＴＭ）が作成される。このトレーサビリティマトリクスは、要求分析書とシステム試験成績書との対応関係を示している。具体的には、要求分析書に記載された各要件の試験成績がシステム成績書のどの部分に記載されているかを示している。
【００３３】
図２の例では、機能安全要求は本来機能要件と安全機能要件とを含んでおり、両要件のそれぞれについて各工程でトレーサビリティマトリクスが作成される。これらのトレーサビリティマトリクスは、開発成果物格納部４に格納される。ここで、本来機能要件について作成されるものを第１トレーサビリティマトリクス、安全機能要件について作成されるものを第２トレーサビリティマトリクスとも呼ぶ。第２トレーサビリティマトリクスは、第１トレーサビリティマトリクスよりも細かい粒度で作成される。トレーサビリティマトリクスの粒度には、文書レベル、章・節レベル、要件レベル等が有り、後者になる程工数がかかる。一般に、安全機能要件の設計開発には要件レベルの粒度のトレーサビリティマトリクスを要求する。但し、第１トレーサビリティマトリクスが最も詳細な粒度で作成されていれば、第２トレーサビリティマトリクスと同じ粒度となる場合がある。
【００３４】
開発進捗管理装置１０１は、機能安全要求については、第１トレーサビリティマトリクスと第２トレーサビリティマトリクスの双方が作成されることを条件に、次工程への移行を許可する。例えば、現在の工程が方式設計であるならば、現工程で第１トレーサビリティマトリクスと第２トレーサビリティマトリクスが作成されたことをもって、詳細設計工程への移行を許可する。従って、安全機能要件を一つでも含む機能安全要求の開発においては、安全機能要件と本来機能要件の双方についてトレーサビリティマトリクスを作成しなければ次工程へ移行することが出来ないため、より確実にトレーサビリティが確立され、漏れなく設計開発を行うことが出来る。
【００３５】
次に、通常要求の開発工程を図３に沿って説明する。通常要求は本来機能要件のみを含むため、通常要求に対して設定される開発工程には安全分析が含まれない。また、安全要件定義及び安全要件検証はない。また、通常要求の開発においては本来機能要件について、成果物として要求分析書等とトレーサビリティマトリクス（ＴＭ）が作成される。すなわち、通常要求の開発工程では本来機能要件に関する第１トレーサビリティマトリクスのみが作成される。
【００３６】
そして、開発進捗管理装置１０１は、通常要求については、第１トレーサビリティマトリクスが作成されることを条件に、次工程への移行を許可する。例えば、現在の工程が方式設計であるならば、現工程で第１トレーサビリティマトリクスが作成されたことをもって、詳細設計工程への移行を許可する。このように、通常要求については粒度の粗い第１トレーサビリティマトリクスの作成をもって次工程へ進むことが出来るため、効率良く設計開発を行うことが出来る。
【００３７】
また、このように、機能安全要求と通常要求に対して異なるプロセスを設定することにより、重要な要求である機能安全要求の開発は、その重要さに見合ったプロセスで実施し、通常要求の開発は、標準のプロセスで実施することにより、効率的な開発が出来る。
【００３８】
図４は、開発進捗管理部３の内部構成を示すブロック図である。開発進捗管理部３は、プロセスワークフロー管理部３１、工程移行可否判定部３２及び開発工程設定部３３を備えている。開発工程設定部３３は、開発すべき要件が本来機能要件か安全機能要件かに応じて、異なるワークフローを設定する。以下、その動作を図５のフローチャートに沿って説明する。
【００３９】
まず、開発工程設定部３３は要求格納部２から要求Ｒを取り出し（ステップＳ１）、要求Ｒが機能安全要求か否かを判断する（ステップＳ２）。機能安全要求か否かは、例えば要求Ｒ自体に記載されている。要求Ｒを機能安全要求と判断した場合、開発工程設定部３３は定義格納部６を参照し、機能安全要求のプロセス定義データを取り出す（ステップＳ３）。あるいは、要求Ｒを機能安全要求ではないと判断した場合、すなわち要求Ｒを通常要求と判断した場合、開発工程設定部３３は定義格納部６を参照し、通常要求のプロセス定義データを取り出す（ステップＳ４）。
【００４０】
図６に、要求格納部２で管理するプロセス定義データを示す。図６（ａ）が通常機能要件のプロセス定義データであり、図６（ｂ）が機能安全要求のプロセス定義データである。開発工程設定部３３は、これらのプロセス定義データに従って、要求Ｒのワークフローを設定する（ステップＳ５）。
【００４１】
次に、要求格納部２に格納されている全ての要求Ｒについてワークフローの設定が終了していなければ（ステップＳ６：Ｎｏ）、ステップＳ１に戻り、終了していればワークフロー設定処理を終了する。
【００４２】
プロセスワークフロー管理部３１は、図７に示すワークフロー管理データを保持しており、当該データを用いてワークフローの管理を行う。図７に例示するワークフロー管理データは、要求ＩＤ、要求が機能安全か否かを示す情報、要件ＩＤ、要件が機能安全か否かを示すマーク、要件記述、現在のプロセス、現在のプロセスのステータス、各工程の成果物（設計書等及びトレーサビリティマトリクス）のＩＤを含んでいる。図７に示す要求（パーキングアシスト機能、警告表示機能、音楽再生機能）のうち、パーキングアシスト機能及び警告表示機能は、１以上の機能安全要件を含むことから機能安全要求に該当する。これらの情報は、設計開発者等により作成され、プロセスワークフロー管理部３１で管理される。
【００４３】
以下、図８のフローチャートに沿ってプロセスワークフロー管理部３１によるワークフローの管理処理を説明する。まず、プロセスワークフロー管理部３１は、ワークフロー管理データを参照して現在のプロセスを取得する（ステップＳ１１）。図７の例によれば、現在のプロセスは方式設計である。次に、プロセスワークフロー管理部３１は工程移行可否判定部３２による工程移行可否の判定結果を取得する（ステップＳ１２）。その判定結果が工程移行不可であれば（ステップＳ１３：Ｎｏ）、ステップＳ１１に戻る。ステップＳ１２で取得した判定結果が工程移行可であれば（ステップＳ１３：Ｙｅｓ）、全プロセスの開発が終了したかを判断する（ステップＳ１４）。例えば現プロセスがシステム試験（安全要件検証）であれば、全プロセスの開発が終了したと判断し、開発を完了する。現プロセスがそれ以外のプロセスであれば、次の開発プロセスに移行し（ステップＳ１５）、ステップＳ１１に戻る。
【００４４】
次に、工程移行可否判定部３２による工程移行可否の判定処理について、図９のフローチャートに沿って説明する。工程移行可否判定部３２は、プロセスワークフロー管理部３１の求めに応じ、工程移行可否判定処理を行う。まず、定義格納部６を参照して、工程移行条件定義データを取得する（ステップＳ２１）。
【００４５】
図１０は、ステップＳ２１で取得する工程移行条件定義データを示す図である。図１０（ａ）が通常要求の工程移行条件定義データ、図１０（ｂ）が機能安全要求の工程移行条件定義データを示している。機能安全要求の工程移行条件定義データには、「トレーサビリティマトリクス（本来機能要件）が作成されていること」と、「トレーサビリティマトリクス（安全機能要件）が作成されていること」が含まれている。これは、機能安全要求においては、これら二つのトレーサビリティマトリクスが作成されなければ、工程移行を可と判定出来ないことを示している。一方、通常要求の工程移行条件定義データは空欄となっており、特に工程移行の条件が無いことを示している。
【００４６】
工程移行可否判定部３２は、要求格納部２から要求仕様を、開発成果物格納部４から開発成果物及びＴＭを夫々取得し（ステップＳ２２）、開発プロセス移行条件を満たしているかを判断する（ステップＳ２３）。通常要求については特に工程移行の条件がないため、ステップＳ２３ではＹｅｓとなり移行可の判定結果をプロセスワークフロー管理部３１に出力する（ステップＳ２４）。機能安全要求については、プロセス移行条件定義データに記載された全ての条件を満たしている場合に、移行可の判定結果を（ステップＳ２４）、それ以外の場合に移行不可の判定結果を（ステップＳ２５）、プロセスワークフロー管理部３１に出力する。
【００４７】
図１１に、機能安全要求のトレーサビリティマトリクスを例示している。この機能安全要求は、「走行中にＤＶＤ再生画面が表示されない事」というものである。これに対して、要求分析工程で分析される安全機能要件には、「車両速度、サイドブレーキ状態を監視し、走行中はＤＶＤ表示禁止画面を表示する」がある。また、この安全機能要件に対する機能設計項目には「車両速度をＣＡＮでエンジンＥＣＵより取得」、「サイドブレーキ状態をＣＡＮでエンジンＥＣＵより取得」、「ＤＶＤ再生状態をナビ／ＡＶユニット内で監視」、「ＤＶＤ画面表示可否判定ブロックをナビ／ＡＶユニット上に配置」などがある。このように、トレーサビリティマトリクスは、各工程間の設計成果物の対応関係を示している。
【００４８】
図１２に、通常要求のトレーサビリティマトリクスを例示している。この通常要求は、「ＤＶＤ再生」であり、これに対しても図１１と同様、要求分析、機能設計、方式設計、詳細設計との対応関係を示している。
【００４９】
図１３は、開発進捗管理装置１０１のハードウェア構成を示す図である。開発進捗管理装置１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）等のプロセッサ４１、メモリ４２、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）又はＳＤ等の記憶媒体４３、入出力インタフェース４４により実現される。要求入力部１は入出力インタフェース（Ｉ／Ｆ）４４により実現される。要求格納部２、開発成果物格納部４、ＴＭ格納部５及び定義格納部６は、記憶媒体４３により実現される。開発進捗管理部３は、プロセッサ４１がＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等のメモリ４２に格納されたプログラムを実行することにより、プロセッサ４１の機能として実現される。ただし、これらは、例えば複数のプロセッサ４１が連携して実現されても良い。
【００５０】
＜Ｂ．変形例＞
図１において開発成果物格納部４は、開発進捗管理装置１０１の構成として説明したが、外部サーバ等、開発進捗管理装置１０１の外部構成であっても良い。
【００５１】
以上の説明では、開発進捗管理部３は図１３のプロセッサ４１がメモリ４２等に記憶されたソフトウェアプログラムに従って動作することにより実現された。しかしこれに代えて、開発進捗管理部３は、当該動作をハードウェアの電気回路で実現する信号処理回路により実現されても良い。ソフトウェアの開発進捗管理部３とハードウェアの開発進捗管理部３とを合わせた概念として、「部」という語に代えて「処理回路」という語を用いることも出来る。
【００５２】
上記の説明では、機能安全要件か本来機能要件かに応じて要件単位で異なるプロセスを設定した。しかし、要求単位で異なるプロセスを設定しても良い。すなわち、機能安全要求か通常要求かに応じて異なるプロセスを設定し、機能安全要求を構成する本来機能要件には、安全分析工程を含む安全機能要件と同一のプロセスを設定しても良い。この場合、プロセスワークフロー管理部３１が管理するワークフロー管理データは図１４，図１５に示すもののようになる。大規模なシステム開発では、要件の数が膨大になるため、要求単位ごとにプロセスを選択することによって、システム開発の効率を上げ、コストを抑制することが出来る。
【００５３】
＜Ｃ．効果＞
実施の形態１に係る開発進捗管理装置１０１は、開発すべきソフトウェアの要求を取得する要求入力部１（要求取得部）と、要求の開発工程における前後の開発工程の成果物間の対応関係を示すトレーサビリティマトリクスを取得し、その取得状況に基づき開発工程の移行可否を判定する工程移行可否判定部３２と、を備える。開発すべきソフトウェアの要求は、機能安全に関わる機能安全要求と、機能安全に関わらない通常要求とを含む。機能安全要求は、機能安全に関わる安全機能要件と安全器の要件以外の本来機能要件とを含み、通常要求は、本来機能要件のみを含む。トレーサビリティマトリクスは、本来機能要件に関する第１トレーサビリティマトリクスと、第１トレーサビリティマトリクスよりも粒度が細かく安全機能要件に関する第２トレーサビリティマトリクスと、を含む。機能安全要求に対する工程移行可否判定部３２の移行可の判定条件は、工程移行可否判定部３２が現工程についての第１トレーサビリティマトリクス及び第２トレーサビリティマトリクスを取得すること、を含む。従って、粒度の異なる複数のトレーサビリティマトリクスの取得を次工程への移行条件とすることにより、要件のトレーサビリティが確保されるため、要件漏れの少ない高品質なソフトウェアを開発することが出来る。
【００５４】
また、開発進捗管理装置１０１は、ソフトウェアの要求が通常要求か機能安全要求かに応じて、異なる開発工程を設定する開発工程設定部３３をさらに備える。従って、例えば機能安全要求にはその重要性に応じた安全分析等の工程を設定し、通常要求には安全分析を省略した工程を設定することにより、安全性と効率性を両立させた開発を行うことが出来る。
【００５５】
また、工程移行可否判定部３２は、通常要求に対し機能安全要求より緩い条件で工程移行可否を判定するため、通常要求の設計開発の効率を高めることが出来る。
【００５６】
また、通常要求に対する工程移行可否判定部３２の移行可の判定条件は、工程移行可否判定部３２が現工程についての第１トレーサビリティマトリクスを取得することを含む。従って、第１トレーサビリティマトリクスは第２トレーサビリティマトリクスよりも粒度が粗いため、第１トレーサビリティマトリクスと第２トレーサビリティマトリクスの双方の取得が工程移行条件となる機能安全要求よりも緩い条件で工程を移行することが出来る。従って、効率よく通常要求の設計開発を行うことが出来る。
【００５７】
また、実施の形態１に係る開発進捗管理方法は、開発すべきソフトウェアの要求を取得し、要求の開発工程における前後の開発工程の成果物間の対応関係を示すトレーサビリティマトリクスを取得し、開発工程の移行可否を判定し、要求は、機能安全に関わる機能安全要求と、機能安全に関わらない通常要求とを含み、機能安全要求は、機能安全に関わる安全機能要件と安全機能要件以外の本来機能要件とを含み、通常要求は、本来機能要件のみを含む、トレーサビリティマトリクスは、本来機能要件に関する第１トレーサビリティマトリクスと、安全機能要件に関し第１トレーサビリティマトリクスよりも粒度が細かい第２トレーサビリティマトリクスと、を含み、機能安全要求に対する工程移行可の判定条件は、現工程についての第１トレーサビリティマトリクス及び第２トレーサビリティマトリクスを取得することを含む。従って、粒度の異なる複数のトレーサビリティマトリクスの取得を次工程への移行条件とすることにより、要件のトレーサビリティが確保されるため、要件漏れの少ない高品質なソフトウェアを開発することが出来る。
【００５８】
なお、本発明は、その発明の範囲内において、実施の形態を適宜、変形、省略することが可能である。
【００５９】
この発明は詳細に説明されたが、上記した説明は、すべての態様において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。
【符号の説明】
【００６０】
１  要求入力部、２  要求格納部、３  開発進捗管理部、４  開発成果物格納部、５  ＴＭ格納部、６  定義格納部、３１  プロセスワークフロー管理部、３２  工程移行可否判定部、３３  開発工程設定部、４１  プロセッサ、４２  メモリ、４３  記憶媒体、４４  入出力インタフェース、１０１  開発進捗管理装置。
【図１】
2017122285.tif 000003
【図２】
2017122285.tif 000004
【図３】
2017122285.tif 000005
【図４】
2017122285.tif 000006
【図５】
2017122285.tif 000007
【図６】
2017122285.tif 000008
【図７】
2017122285.tif 000009
【図８】
2017122285.tif 000010
【図９】
2017122285.tif 000011
【図１０】
2017122285.tif 000012
【図１１】
2017122285.tif 000013
【図１２】
2017122285.tif 000014
【図１３】
2017122285.tif 000015
【図１４】
2017122285.tif 000016
【図１５】
2017122285.tif 000017
【国際調査報告】
2017122285.tif 000018
2017122285.tif 000019