JP2015152979A - 製品設計支援プログラム、製品設計支援方法および製品設計支援装置 - Google Patents

Abstract

【課題】製品に必要な要件を実現する難易度を定量的に算出することで、製品の設計の支援を行うことを目的とする。
【解決手段】製品設計支援装置は、データベース３と演算部６とを備える。データベース３は、要件を定義した第１の書類と、第１の書類から関連付けられ要件の機能を定義した第２の書類と、第２の書類に関連付けられたテスト書類と、テスト書類に対応付けられたテスト結果と、を記憶する。演算部６は、第１の書類に関連付けられた全ての第２の書類についてのテスト書類に含まれるテスト項目の数とテスト項目のテスト結果とに基づいて、要件を実現する際の難易度を算出する。
【選択図】図１

Description

本発明は、製品設計支援プログラム、製品設計支援方法および製品設計支援装置に関する。

ソフトウェアが制御する製品の開発を行うときに、各種のテストが行われる。各種のテストの一例として、ソフトウェア単体のテストがある。また、各種のテストの一例として、ソフトウェアと電子回路とを組み合わせたシステムテストや制御される部品を実装した製品を対象とした実機テスト等もある。

関連する技術として、設計書のレビューを行ったときのレビュー結果、およびプログラムコードのテスト結果を関連付けて記憶する技術が提案されている。また、各業務の総試験項目数を、設定したウェイトに従って割り振り、サブシステムごとの目標値を算出する技術が提案されている。また、ソフトウェア開発の過程でうみだされる各工程の成果物の評価方法であって、ソフトウェア開発における複数の工程の成果物同士の間の依存関係の状態を評価する技術が提案されている（例えば、特許文献１〜３参照）。

特開２００７−２４１３４７号公報 特開２００１−３３７８４６号公報 特開２０１３−０１５９５８号公報

ソフトウェアが制御する製品の開発を行うときには、開発対象の製品が満たす条件が定義された要件定義が行われる。要件定義は、例えば要件定義書等の書類に記述される。要件定義は、抽象的な定義であり、要件を詳細化または具体化することにより、各種の機能が定義される。機能は、設計書等の書類に記述される。

要件や機能には、実現するための難易度がある。例えば、要件や機能が要求する条件が複雑な場合には、難易度が高くなる。要件を具体化または詳細化した機能のレベルでは、機能のテストを行ったテスト結果に基づいて、機能を実現する難易度を定量的に導き出すことは難しくない。

一方、上述したように、要件は、開発対象の製品が満たす条件が抽象的に定義されたものであり、要件を実現する難易度を定量的に導き出すことは難しい。開発対象の製品を設計する上で、設計者は要件の実現性の難易度を定量的に評価できることが好ましい。

１つの側面では、本発明は、製品に必要な要件を実現する難易度を定量的に算出することで、製品の設計の支援を行うことを目的とする。

１つの案として、開発対象の製品が満たす条件が定義された要件の難易度を算出する製品設計支援装置は、記憶部と演算部とを備える。前記記憶部は、前記要件を定義した第１の書類と、当該第１の書類から関連付けられ前記要件の機能を定義した第２の書類と、当該第２の書類に関連付けられたテスト書類と、当該テスト書類に対応付けられたテスト結果と、を記憶する。前記演算部は、前記第１の書類に関連付けられた全ての前記第２の書類についてのテスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果とに基づいて、前記要件を実現する際の難易度を算出する。

製品に必要な要件を実現する難易度を定量的に算出することで、製品の設計の支援を行うことができる。

製品設計支援装置の一例を示すブロック図である。 製品設計支援装置のハードウェア構成の一例を示す図である。 各書類のリレーションの一例を示す図（その１）である。 各書類のリレーションの一例を示す図（その２）である。 実施形態の処理の一例を示すフローチャートである。 実施形態における要件ごとの難易度を示す表の一例である。 実施形態における要件ごとの難易度を示すグラフの一例である。 応用例における処理の一例を示すフローチャートである。 図８の要件ごとの難易度の演算処理の一例を示すフローチャートである。 応用例における要件ごとの難易度を示す表の一例である。

＜製品設計支援装置の一例＞
以下、図面を参照して、実施形態について説明する。図１は、実施形態の製品設計支援装置の一例を示している。図１において、難易度算出部１は、表示部２およびデータベース３に接続されている。表示部２は、難易度算出部１が出力する画面を表示する。例えば、表示部２にはディスプレイを適用することができる。データベース３は、記憶部の一例である。

データベース３は、種々の書類を電子データで記憶している。以下、書類の電子データを書類データと称する。データベース３は、機能要件書と概要機能設計書と詳細機能設計書とソースコードとを記憶している。また、データベース３は、実機テスト仕様書とシステムテスト仕様書とユニットテスト仕様書とプログラムテスト仕様書とを記憶している。

実機テスト仕様書、システムテスト仕様書、ユニットテスト仕様書およびプログラムテスト仕様書は、それぞれテスト結果と対応付けられて、データベース３に記憶されている。テスト結果は、対応するテスト仕様書に基づくテストの結果である。テスト仕様書は、テスト書類の一例である。

図１に示した一例では、各書類データを１つのデータベース３に記憶しているが、各書類データは異なるデータベースに記憶されていてもよい。また、各書類データのうち、対応付けられているテスト仕様書とテスト結果とは同一のデータベースに記憶され、その他の書類データは異なるデータベースに記憶されてもよい。

また、図１に示した一例では、データベース３には機能要件書が複数記憶されている。要件が１つの場合、データベース３に記憶される機能要件書は１つであってもよい。他の書類データも同様であり、同種の書類データについて、複数の書類データがデータベース３に記憶されてもよいし、１つの書類データがデータベース３に記憶されてもよい。

難易度算出部１は、必要性記憶部４とデータ処理部５と演算部６と画面生成部７とを備えている。必要性記憶部４は、要件の必要性を記憶する。要件には必要性があり、要件によって、必要性は異なる。

例えば、製品に必須な要件は、必要性が非常に高い。また、製品の商品力向上の要件は、安全上必要な要件よりは必要性が低いが、比較的必要性が高い。また、製品の便利機能の要件は、必要性が低い。必要性記憶部４は、要件ごとに必要性を数値で記憶している。

データ処理部５は、データベース３に記憶されている各書類データを取得して、各種の処理を行う。演算部６は、データ処理部５が取得した情報に基づいて、要件の難易度を得るための種々の演算を行う。画面生成部７は、要件の難易度を含む画面を生成して、表示部２に出力する。表示部２は、入力した画面を表示する。

＜難易度算出装置のハードウェア構成の一例＞
次に、難易度算出装置のハードウェア構成の一例について説明する。図２の一例に示すように、難易度算出装置は、バス２０に対して、プロセッサ２１とＲＡＭ(Random Access Memory)２２とＲＯＭ(Read Only Memory)２３と補助記憶装置２４と周辺機器接続部２５と通信インタフェース２６と可搬型記憶装置接続部２７とが接続されている。

プロセッサ２１はＣＰＵ（Central Processing Unit)のような任意の処理回路である。プロセッサ２１はＲＡＭ２２に展開されたプログラムを実行する。ＲＯＭ２３はＲＡＭ２２に展開されるプログラムを記憶する不揮発性の記憶装置である。

補助記憶装置２４は、種々の情報を記憶する記憶装置であり、例えばハードディスクドライブや半導体メモリ等を補助記憶装置２４に適用することができる。上述したデータベース３は、補助記憶装置２４に記憶されてもよい。周辺機器接続部２５は、ディスプレイ２８および入力デバイス２９を接続する。

通信インタフェース２６は、外部との通信を行うときのインタフェースである。例えば、データベース３はＬＡＮ（Local Area Network)経由で接続される外部の記憶装置に記憶されていてもよい。この場合、プロセッサ２１は、通信インタフェース２６を介して、データベース３を参照してもよい。

可搬型記憶装置接続部２７は、可搬型記憶装置３０と接続可能に設けられている。可搬型記憶装置３０としては、可搬型のメモリや光学式ディスク（例えば、ＣＤ（Compact Disk)やＤＶＤ（Digital Video Disk)等）を適用することができる。実施形態の処理を行うプログラムは、コンピュータ読み取り可能な記録媒体に記録されていてもよい。この場合、記録媒体に可搬型記憶装置３０を適用することができる。

ＲＡＭ２２、ＲＯＭ２３および補助記憶装置２４は、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。

図１で一例として示した難易度算出部１のデータ処理部５と演算部６と画面生成部７とは、例えばプロセッサ２１で実行されるアプリケーションにより実現されてもよい。必要性記憶部４は、ＲＡＭ２２に記憶されてもよい。

＜各書類データの関連の一例＞
図３および図４は、各書類データの関連の一例を示している。機能要件は、例えば、ソフトウェアで制御する製品を開発する上で、製品が満たす条件が定義された要件のうち機能に関する要件を含む。機能要件は、単に要件と称されることもある。

実施形態では、要件は機能要件書で定義される。機能要件書は第１の書類の一例である。図３の一例では、機能要件書Ａと機能要件書Ｂと機能要件書Ｃとを示しているが、機能要件書の数は３つには限定されない。

図１の一例に示したように、データベース３は、実機テスト仕様書、システムテスト仕様書、ユニットテスト仕様書およびプログラムテスト仕様書を記憶している。これらの各テスト仕様書にはそれぞれテスト結果が対応付けられている。

テスト結果は、テスト仕様書のテストに基づいた結果である。テスト仕様書は、１または複数のテスト項目を含んでいる。実施形態では、テスト仕様書は複数のテスト項目を含んでいるものとする。テスト結果はテスト項目に基づくテストの結果であり、正常または障害（不良であってもよい）を含む。テスト仕様書は、他に、テストの内容やテストの実行環境等の情報を含んでもよい。

図３の一例では、実機テスト仕様書は１つを示しているが、実機テスト仕様書は複数であってもよい。実機テスト仕様書は、実際の製品にソフトウェアを実装したときのテストに関する仕様書である。実機テスト仕様書Ａにはテスト結果が対応付けられている。

図３の一例では、６つの概要機能設計書Ａ〜Ｆを示している。概要機能設計書は、機能要件書で定義される機能の概要を示す設計書である。概要機能設計書は、第１の設計書の一例である。概要機能設計書の数は、６つには限定されない。システムテスト仕様書Ａ〜Ｆは、概要機能設計書Ａ〜Ｆに対応している。

概要機能設計書は、上述したように、機能要件書で定義される機能の概要を示す設計書である。概要機能設計書に関連付けられるシステムテスト仕様書は、製品のシステム全体のテストになる。システムテスト仕様書Ａ〜Ｆにはそれぞれテスト結果が対応付けられている。テスト仕様書に含まれるテスト項目の数は１つであってもよく、その場合は、テスト結果も１つになる。

図３および図４の一例では、書類データ間の関連を実線の矢印または破線の矢印で示している。実線の矢印は、第１のリレーションを示している。第１のリレーションは、詳細化・具体化リレーションとも称される。機能要件書には、開発対象の製品が満たす抽象的な条件が記述される。従って、機能要件書に第１のリレーションが設定されている概要機能設計書は、当該機能要件書を詳細化または具体化した設計書になる。

図３の一例では、機能要件書Ａと概要機能設計書Ａおよび概要機能設計書Ｃとの間に第１のリレーションが設定されている。また、機能要件書Ｂと概要機能設計書Ｂおよび概要機能設計書Ｅとの間に第１のリレーションが設定されている。また、機能要件書Ｃと概要機能設計書Ｄおよび概要機能設計書Ｆとの間に第１のリレーションが設定されている。

また、図３の一例において、破線で示す矢印は第２のリレーションである。第２のリレーションは検証リレーションとも称される。第２のリレーションは、テスト仕様書に設定されるリレーションである。第２のリレーションは、テスト仕様書によりテストされる対象となる書類データとの関連を示している。

図３の一例では、概要機能設計書Ａ〜Ｆとシステムテスト仕様書Ａ〜Ｆとの間に第２のリレーションが設定されている。また、機能要件書Ｃと実機テスト仕様書Ａとの間にも第２のリレーションが設定されている。

第１のリレーションおよび第２のリレーションは、書類データの間に予め設定されているものである。第１のリレーションおよび第２のリレーションは、任意の手法で設定されてよい。例えば、機能要件書および概要機能設計書が共通するファイル名を有していれば、両者の間に第１のリレーションを設定することができる。また、機能要件書に含まれるデータと概要機能設計書に含まれるデータとの間に共通性があれば、両者の間に第１のリレーションを設定することができる。

以上のように、第１のリレーションおよび第２のリレーションは予め設定することができる。予め設定された第１のリレーションおよび第２のリレーションは、例えば、ＲＡＭ２２や補助記憶装置２４等に記憶されてもよい。

図３および図４の一例で示すように、概要機能設計書Ｆと詳細機能設計書Ａ〜Ｆとの間には第１のリレーションが設定されている。実施形態の概要機能設計書は、製品のシステム全体の概要の設計書である。概要機能設計書とシステムテスト仕様書との間に第２のリレーションが設定される。

実施形態の詳細機能設計書は、概要機能設計書を詳細化または具体化した設計書である。詳細機能設計書は、第２の設計書の一例である。詳細機能設計書は、個々の部品やモジュール等の条件を定義している。図３および図４に示した一例では、概要機能設計書Ｆを詳細化または具体化した設計書が詳細機能設計書Ａ〜Ｆになる。

概要機能設計書Ｆは複数の設計書に詳細化または具体化することができる。一例として、概要機能設計書Ｆは詳細機能設計書Ａ〜Ｆに詳細化または具体化されるものとする。従って、概要機能設計書Ｆと詳細機能設計書Ａ〜Ｆとの間に第１のリレーションが設定される。

上述したように、１つの概要機能設計書は複数の詳細機能設計書と第１のリレーションが設定されてもよいし、１つの概要機能設計書は１つの詳細機能設計書と第１のリレーションが設定されてもよい。また、概要機能設計書Ａ〜Ｅについても、それぞれ１または複数の詳細機能設計書と第１のリレーションが設定されていてもよい。

詳細機能設計書Ａ〜Ｆは、ユニットテスト仕様書Ａ〜Ｆとの間に第２のリレーションが設定されている。ユニットテスト仕様書は、個々の部品やモジュール等（以下、ユニットと称する）のテストの内容を定義した仕様書である。ユニットテスト仕様書Ａ〜Ｆは、それぞれユニットテスト仕様書のテストを行ったテスト結果と対応付けられている。

図４の一例で示すように、詳細機能設計書ＦとソースコードＡ〜Ｃとの間に第１のリレーションが設定されている。実施形態のソースコードは、詳細機能設計書で定義される条件をソースコードレベルまで具体化または詳細化したものである。ソースコードとプログラムテスト仕様書との間に第２のリレーションが設定される。

詳細機能設計書Ｆは複数のソースコードに具体化または詳細化することができる。一例として、詳細機能設計書ＦはソースコードＡ〜Ｃに具体化または詳細化されるものとする。従って、詳細機能設計書ＦとソースコードＡ〜Ｃとの間に第１のリレーションが設定される。

上述したように、１つの詳細機能設計書は複数のソースコードと第１のリレーションが設定されてもよいし、１つの詳細機能設計書は１つのソースコードと第１のリレーションが設定されてもよい。また、概要機能設計書Ａ〜Ｅについても、それぞれ１または複数のソースコードと第１のリレーションが設定されていてもよい。

ソースコードＡ〜Ｃは、プログラムテスト仕様書Ａ〜Ｃと第２のリレーションが設定されている。プログラムテスト仕様書は、ソースコードのテストの内容を定義した仕様書である。プログラムテスト仕様書Ａ〜Ｃは、それぞれプログラムテスト仕様書のテストを行ったテスト結果と関連付けられている。テスト結果は、例えば、正常または障害として示される。

概要機能設計書、詳細機能設計書およびソースコードは、第２の書類の一例である。第２の書類は、第１の書類で定義される要件の機能を定義する書類である。従って、第２の書類は、要件の機能を定義する書類であれば、概要機能設計書、詳細機能設計書およびソースコードには限定されない。

＜実施形態の処理の一例＞
次に、実施形態の処理の一例について説明する。最初に、データ処理部５は、データベース３から難易度の演算を行う要件についての第１の書類を取得し、第１の書類をリストＬ１にセットする（ステップＳ１）。実施形態では、第１の書類は、機能要件書であるため、リストＬ１には、取得された機能要件書がセットされる。

データベース３には、複数の機能要件書が記憶されている。データ処理部５は、データベース３に記憶されている複数の機能要件書から対象となる一部または全部の機能要件書を取得する。データ処理部５は、取得した機能要件書をリストＬ１にセットする。リストＬ１はＲＡＭ２２により実現されてもよい。この場合、データ処理部５は、取得した機能要件書をＲＡＭ２２に記憶する。

次に、データ処理部５は、リストＬ１にセットした第１の書類の数の分、ループ処理を開始する（ステップＳ２）。データ処理部５は、リストＬ１から１つの第１の書類を取得し、取得した第１の書類に設定されている第１のリレーションを再帰的に辿る（ステップＳ３）。

そして、データ処理部５は、第１のリレーションを辿ったときに得られる第２の書類をリストＬ２にセットする（ステップＳ４）。実施形態では、第２の書類は、概要機能要件書、詳細機能要件書またはソースコードである。データ処理部５は、第１のリレーションを辿り、リストＬ２にこれらの第２の書類をセットする。リストＬ２は、ＲＡＭ２２に記憶されてもよい。

実施形態では、概要機能設計書は、１または複数の詳細機能設計書との間に第１のリレーションが設定されている。データ処理部５は、リストＬ２にセットされた全ての概要機能設計書について、第１のリレーションが設定されている詳細機能設計書を取得する。データ処理部５は、取得した詳細機能設計書をリストＬ２にセットする。

実施形態では、詳細機能設計書は、１または複数のソースコードとの間に第１のリレーションが設定されている。データ処理部５は、リストＬ２にセットされた全ての詳細機能設計書について、第１のリレーションが設定されているソースコードを取得する。データ処理部５は、取得したソースコードをリストＬ２にセットする。

以上により、データ処理部５は、リストＬ１から取得した第１の書類を起点として第１のリレーションが設定されている全ての第２の書類をリストＬ２にセットする。実施形態では、リストＬ１には機能要件書がセットされる。また、リストＬ２には、概要機能設計書と詳細機能設計書とソースコードとのうち何れか１つまたは全部がセットされる。

次に、データ処理部５は、リストＬ２にセットされている第２の書類の数の分、ループ処理を開始する（ステップＳ５）。概要機能設計書は、システムテスト仕様書との間に第２のリレーションが設定されている。詳細機能設計書は、ユニットテスト仕様書との間に第２のリレーションが設定されている。ソースコードは、プログラムテスト仕様書との間に第２のリレーションが設定されている。

データ処理部５は、リストＬ２にセットされている第２の書類を１つ取得する。そして、データ処理部５は、第２の書類に設定されている第２のリレーションを辿ることにより、テスト仕様書に含まれるテスト項目を取得する（ステップＳ６）。実施形態では、データ処理部５は、システムテスト仕様書、ユニットテスト仕様書およびプログラムテスト仕様書のそれぞれのテスト仕様書に含まれる全てのテスト項目を取得する。

データ処理部５は、第２の書類との間に第２のリレーションが設定されているテスト仕様書にテスト項目が含まれているか否かを判定する（ステップＳ７）。テスト仕様書にテスト項目が含まれていなければ（ステップＳ７でＮＯ）、ステップＳ８およびステップＳ９の処理は行われない。

一方、テスト仕様書にテスト項目が含まれていれば（ステップＳ７でＹＥＳ）、データ処理部５は、テスト項目数と障害数とを取得する（ステップＳ８）。システムテスト仕様書、ユニットテスト仕様書およびプログラムテスト仕様書には、それぞれテスト結果が対応付けられている。

テスト結果は、テスト項目数と障害数とを含む。テスト項目数は、テスト仕様書に含まれるテスト項目の数であり、障害数はテスト項目のテストを行った結果、障害が発生した数である。

演算部６は、第２の書類に関連付けられているテスト結果のテスト項目数および障害数を要件ごとに加算する（ステップＳ９）。実施形態では、演算部６は、機能要件書ごとに、テスト項目数および障害数を要件ごとに加算する。テスト項目数および障害数の初期値はゼロである。

データ処理部５および演算部６は、リストＬ２から取得した第２の書類についてステップＳ６〜ステップＳ９の処理を終了すると、リストＬ２にセットされている次の第２の書類について、ステップＳ６〜ステップＳ９の処理を開始する。

従って、演算部６は、リストＬ２にセットされている全ての第２の書類について、テスト項目があれば、テスト項目数および障害数を順次加算する。よって、１つの第１の書類から第１のリレーションで関連付けられている全ての第２の書類について、テスト項目数の合計値および障害数の合計値が得られる。つまり、１つの要件についての、テスト項目数の合計値および障害数の合計値が得られる。演算部６は、障害数の合計値をテスト項目数の合計値で除算することで、難易度の演算を行う（ステップＳ１１）。

テスト項目数の合計値に対する障害数の合計値の割合が大きければ、要件に対する障害が大きいことになる。従って、要件を実現する難易度は高くなる。一方、テスト項目数の合計値に対する障害数の割合が小さければ、要件に対する障害が小さいことになる。従って、要件を実現する難易度は低くなる。

ステップＳ３〜ステップＳ１１の処理は、１つの要件についての処理である。ステップＳ１の処理で、データ処理部５は１つの第１の書類を取得している。リストＬ１に他の第１の書類があれば、データ処理部５および演算部６は、当該第１の書類について、ステップＳ３〜ステップＳ１１の処理を行う。

従って、リストＬ１にセットされている全ての第１の書類について、ステップＳ３〜ステップＳ１１の処理を行うことで、演算部６は、全ての第１の書類についての難易度を演算することができる。リストＬ１にセットされている全ての第１の書類について、ステップＳ３〜ステップＳ１１の処理が終了したときに、ステップＳ２〜ステップＳ１２のループ処理は終了する。

以上の処理により、演算部６は、第１の書類ごと、つまり要件ごとに難易度を演算する。これにより、抽象的な概念を定義している第１の書類の要件について実現の難易度を定量的な数値を用いて評価することができる。

図６は、要件ごとの難易度を定量的に表示する表の一例を示している。図６において、要件Ａおよび要件Ｂの難易度を数値で示している。従って、図５のステップＳ１でリストＬ１にセットされる第１の書類は要件Ａおよび要件Ｂの書類データである。

また、機能１、機能２、機能３および機能５は、第２の書類で定義される機能の一例である。図６の一例では、要件Ａは、機能１、機能３および機能５との間で第１のリレーションが設定されている。また、要件Ｂは、機能１、機能２および機能５との間で第１のリレーションが設定されている。

従って、データ処理部５は、要件Ａについて、第１のリレーションを再帰的に辿ることにより、機能１、機能３および機能５のテスト結果からテスト項目数および障害数を得る。図６の一例では、機能１は、テスト項目数が「２０」であり、障害数が「２」である。機能３は、テスト項目数が「３５」であり、障害数が「１０」である。機能５は、テスト項目数が「４８」であり、障害数が「３」である。

演算部６は、図５のフローに示されるように、テスト項目数および障害数を加算していく。これにより、要件Ａを実現する機能１、機能３および機能５のテスト項目数の合計値および障害数の合計値が得られる。図６に示す一例の場合、要件Ａのテスト項目数の合計値は「１０３（＝２０＋３５＋４８）」になる。

一方、障害数の合計値は「１５（＝２＋１０＋３）」になる。演算部６は、要件Ａの障害数の合計値をテスト項目数の合計値で除算する。これにより、演算部６は「０．１４６（＝１５／１０３）」という数値を得る。なお、以下において、各数値は、小数点４桁を四捨五入した例を示している。

図５のフローで説明したように、要件Ａと要件Ｂとは別個に難易度の演算が行われる。データ処理部５は、要件Ｂについて、第１のリレーションを再帰的に辿ることにより、機能１、機能２および機能５のテスト結果からテスト項目数および障害数を得る。図６の一例では、機能１および機能５は、上述した値である。機能２は、テスト項目数が「４０」であり、障害数が「４」である。

図６に示す一例の場合、要件Ｂのテスト項目数の合計値は「１０８（＝２０＋４０＋４８）」になる。一方、障害数の合計値は「９（＝２＋４＋３）」になる。よって、演算部６は、要件Ｂの障害数の合計値をテスト項目数の合計値で除算して「０．０８３（＝９／１０８）」を得る。

要件Ａを実現するための難易度「０．１４６」および要件Ｂを実現するための難易度「０．０８３」は定量的な数値である。難易度の数値が高いほど、要件を実現することが困難になり、難易度の数値が低いほど、要件を実現することが容易になる。従って、画面生成部７は、図６に示すような画面を表示部２に出力する。

これにより、表示部２を視認する者（以下、設計者とする）は、要件ごとの難易度を定量的に評価することができる。設計者は、定量的に表示されている難易度に基づいて、要件を実現するか否かを評価することができる。このため、製品の設計を支援することができるようになる。

図６の画面例は、必要性の項目を有している。上述したように、製品の要件には必要性のレベルに差がある。例えば、上述した、製品に必須な要件と商品力向上の要件と便利機能の要件とはそれぞれ必要性のレベルに差異がある。

そこで、各要件の必要性が数値化されて必要性記憶部４に記憶されている。必要性記憶部４は、要件ごとに数値化された必要性を記憶している。この必要性の値は、要件が開発対象の製品にどの程度必要であるかの度合いを示している。例えば、ある要件についての必要性の統計に基づいて、必要性の値が決定されてもよい。図６の画面例では、要件Ａの必要性は「０．１５」であり、要件Ｂの必要性は「０．０５」である。従って、必要性は、要件Ｂより要件Ａの方が高い。

表示部２に、要件ごとの難易度を表示することで、設計者は定量的に難易度を認識することができる。このとき、難易度と必要性とを比較できることが好ましい。これにより、設計者は、必要性に対する難易度を、要件を製品に実装するか否かを評価するときの指標とすることができる。

図６の画面例では、要件Ａの難易度は「０．１４６」であり、必要性は「０．１５」である。よって、設計者は、要件Ａが必要性に見合った難易度を有していることを認識することができる。一方、図６の画面例において、要件Ｂの難易度は「０．０８３」であり、必要性は「０．０５」である。よって、設計者は、要件Ｂが必要性に対して高い難易度を有していることを認識できる。

図６の画面例において、難易度の箇所に別の数値を表示している。この数値は、難易度を必要性で除算した値である。つまり、この数値は、難易度に対する必要性の割合を示している。要件Ａの場合は「０．９７１（＝０．１４５６／０．１５）」であり、要件Ｂの場合は「１．６６７（＝０．０８３３／０．０５）」である。

図６の画面例では、難易度に対する必要性の割合を示している。例えば、要件Ａの数値は「０．９７１」になっており、その数値は「１」以下になっている。これにより、設計者は、括弧内の数値を視認することで、難易度と必要性とが見合っていることを認識できる。

一方、要件Ｂの数値は「１．６６７」になっており、その数値は「１」に対して比較的高い。設計者は、括弧内の数値を視認することで、必要性よりも難易度が比較的高いことを認識することができる。つまり、設計者は、括弧内の１つの数値に基づいて、難易度と必要性との関係を認識することができる。

図７の画面例は、グラフ形式で難易度を示している。上述したように、要件ごとの難易度は定量的な数値で得られている。従って、画面生成部７は、難易度をグラフ表示することができる。図７の画面例では、横軸を必要性とし、縦軸を難易度として、要件Ｒ１〜要件Ｒ４の難易度を示している。要件Ｒ１は必要性が低く、且つ難易度も低い。従って、設計者は、要件Ｒ１は、開発対象の製品に要件Ｒ１を実装しても、必要性に対して難易度が見合うことを認識することができる。

一方、要件Ｒ２は必要性が低く、且つ難易度が非常に高い。従って、設計者は、要件Ｒ２については、必要性に対して難易度が見合わないことを認識することができる。これにより、設計者は、開発対象の製品から要件Ｒ２を除外することを検討する手がかりを得ることができる。

要件Ｒ３は、必要性が高く、且つ難易度も高い。従って、設計者は、要件Ｒ３は、開発対象の製品に要件Ｒ３を実装しても、必要性に対して難易度が見合うことを認識することができる。

一方、要件Ｒ４は、必要性が高く、且つ難易度が非常に高い。従って、設計者は、要件Ｒ４について、必要性に対して難易度が高いことを認識できる。ここで、必要性が高い要件は、開発対象の製品に実装が要求される要件である場合が多い。例えば、製品に必須の要件は難易度にかかわらず、要件を実現することが要求される。

そこで、設計者は、要件Ｒ４の必要性が高いことから、要件Ｒ４について、必要性に対して難易度が見合わなくても、要件Ｒ４を開発対象の製品に実装することを判断することができる。

図７の画面例では、画面生成部７は、定量的な数値として得られた難易度に基づいて、グラフ表示をする画面を生成し、表示部２にグラフを表示している。よって、設計者は、要件ごとの難易度を視覚的に認識することができる。また、設計者は、必要性によっては、難易度にかかわらず、開発対象の製品に実装することを認識することができる。

＜応用例の処理の一例＞
次に、応用例について説明する。応用例では、演算部６は、開発量を加味した難易度の演算を行っている。図８のフローは、応用例の処理の一例を示している。図８のフローは、図５のフローに対してステップＳ８およびステップＳ１１が変更されている。その他のステップは、図５のフローと同じである。

開発量は、第２の書類の機能を実現するために要する工数であり、一例として、開発量は、ソースコードのステップの総数とする。第２の書類が概要機能設計書または詳細機能設計書の場合は、これらの設計書を起点として第１のリレーションが設定されている１または複数のソースコードのステップの総数が開発量になる。

図５のステップＳ８と同様に、データ処理部５は、テスト項目数と障害数とを取得する。また、データ処理部５は、テスト項目を含むテスト仕様書がプログラムテスト仕様書の場合は、当該プログラムテスト仕様書と第２のリレーションが設定されているソースコードのステップ総数を取得する（ステップＳ２１）。

データ処理部５は、テスト項目を含むテスト仕様書が概要機能設計書または詳細機能設計書の場合は、第１のリレーションを辿って、１または複数のソースコードを取得する。そして、データ処理部５は、取得した１または複数のソースコードのステップ総数を取得する。

ステップＳ５〜ステップＳ１０のループ処理が終了すると、要件ごとの難易度の演算処理が行われる（ステップＳ２２）。図９は、ステップＳ２２の要件ごとの難易度の演算処理の一例を示している。また、図１０は、要件ごとの難易度の表の一例を示している。なお、図１０の表には、開発量の項目が追加されている。

図９のフローチャートに示されるように、演算部６は、機能ごとに障害率を演算する（ステップＳ３１）。演算部６は、要件Ａおよび要件Ｂに含まれる機能１、機能２、機能３および機能５の障害率を演算する。応用例では、障害率は、障害数をテスト項目数で除算した値になる。

従って、機能１の障害率は「０．１（＝２／２０）」になる。機能２の障害率は「０．１（＝４／４０）」になる。機能３の障害率は「０．２８６（＝１０／３５）」になる。機能５の障害率は「０．０６２５（＝３／４８）」になる。

機能１および機能５は、要件Ａと要件Ｂとで重複している。この場合、要件ごとに機能１および機能５を演算してもよいが、重複した演算を行うことになる。従って、要件Ａで演算した機能１および機能５の障害率は、要件Ｂでは演算を行わず、その結果を利用してもよい。

次に、演算部６は、機能ごとの障害率に開発量を乗算する（ステップＳ３２）。図１０に示す一例では、各機能はいずれもキロステップとして示している。また、機能１の開発量は「１」、機能２の開発量は「１．８」、機能３の開発量は「１．５」および機能５の開発量は「２」である。

機能１の障害率に開発量を乗算した値は「０．１（＝０．１×１）」になる。機能２の障害率に開発量を乗算した値は「０．１８（＝０．１×１．８）」になる。機能３の障害率に開発量を乗算した値は「０．４２９（＝０．２８６×１．５）」になる。機能５の障害率に開発量を乗算した値は「０．１２５（＝０．０６２５×２）」になる。

次に、演算部６は、各機能の障害率を合算する（ステップＳ３３）。要件Ａは機能１、機能３および機能５との間に第１のリレーションが設定されている。演算部６は、機能１、機能３および機能５についての上述した値（障害率に開発量を乗算した値）を合算する。

従って、演算部６は、「０．１＋０．４２９＋０．１２５」の演算を行い、「０．６５４」の合算値を得る。この合算値は要件Ａについて障害率を合算した値になる。演算部６は、要件Ｂについての合算も行う。演算部６は、「０．１＋０．１８＋０．１２５」の演算を行い、「０．４０５」の合算値を得る。この合算値は要件Ｂについて障害率を合算した値になる。

次に、演算部６は、合算した障害率を開発量の合計値で除算する（ステップＳ３４）。要件Ａの開発量の合計値は「４．５（＝１＋１．５＋２）」になる。よって、演算部６は要件Ａについて、「０．６５４／４．５」の演算を行い、「０．１４５」の値を得る。

また、要件Ｂの開発量の合計値は「４．８（＝１＋１．８＋２）」になる。よって、演算部６は、要件Ｂについて、「０．４０５／４．８」の演算を行い、「０．０８４」の値を得る。

ステップＳ３４で演算部６が演算した値は、要件ごとの難易度となる。従って、演算部６は、要件Ａについては難易度が「０．１４６」、要件Ｂについては難易度が「０．０８４」を得る（ステップＳ３５）。

要件の定量的な難易度は、図５のフローに示したように、テスト項目数および障害数から得ることができる。応用例では、演算部６は、テスト項目数および障害数に、開発量のファクターを加えて、要件の定量的な難易度の演算を行っている。これにより、より詳細な要件の難易度を得ることができる。

図６は、テスト項目数と障害数とに基づいて演算される難易度の一例を示している。図６の一例に示されるように、要件Ａの難易度は「０．１４５」である。一方、図１０に一例として示す難易度は「０．１４６」になっている。この難易度は、テスト項目数と障害数と開発量とに基づいて演算される値である。よって、両者は値が異なる。

図６の一例に示されるように、要件Ｂの難易度は「０．０８４」である。一方、図１０に一例として示す難易度は「０．０８３」である。要件Ｂについても、開発量を加味して難易度の演算を行っているか否かで、演算される値が異なる。従って、開発量を加味した演算を行うことにより、より詳細な要件の難易度を出力することができる。

応用例においても、表示部２は、図１０のように難易度と必要性とを表により表示するだけでなく、図７のように難易度と必要性との関係をグラフ表示するようにしてもよい。これにより、設計者は、開発量を加味した難易度と必要性との関係を認識することができる。

実施形態と応用例とでは、演算部６の演算方法は異なる。ただし、第１の書類に関連付けられた全ての第２の書類についてのテスト書類に含まれるテスト項目の数と、当該テスト項目のテスト結果とに基づいて、要件の難易度を演算している点では同じである。これにより、設計者は、要件を実現する難易度を定量的に認識することが可能になる。

実施形態および応用例において、難易度算出部１は、データベース３の各書類データを参照できればよい。従って、難易度算出部１は、データベース３から各書類データを取得した後に、取得した書類データを参照してもよいし、データベース３に記憶されている各書類データの内容を検索するようにしてもよい。

また、実施形態および応用例において、演算部６は、テスト結果の障害数を用いて、要件の難易度を演算していたが、テスト結果の正常数を用いて、要件の難易度の演算を行ってもよい。正常数と障害数との合計がテスト項目数になるため、演算部６は、テスト結果の正常数を用いて、要件の難易度の演算を行うこともできる。

開示の実施形態とその利点について詳しく説明したが、当業者は、特許請求の範囲に明確に記載した本発明の範囲から逸脱することなく、様々な変更、追加、省略をすることができるであろう。

以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
開発対象の製品が満たす条件が定義された要件の難易度を算出する製品設計支援プログラムであって、
前記要件を定義した第１の書類と、当該第１の書類から関連付けられ前記要件の機能を定義した第２の書類と、当該第２の書類に関連付けられたテスト書類と、当該テスト書類に対応付けられたテスト結果と、を記憶する記憶部を参照し、
前記第１の書類に関連付けられた全ての前記第２の書類についてのテスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果とに基づいて、前記要件を実現する際の難易度を算出する、
処理をコンピュータに実行させる製品設計支援プログラム。
（付記２）
前記要件を複数含み、前記要件ごとに前記難易度を算出する、
処理を前記コンピュータに実行させる付記１記載の製品設計支援プログラム。
（付記３）
前記第２の書類は、前記要件を具体化または詳細化した第１の設計書と、当該第１の設計書を具体化または詳細化した第２の設計書と、当該第２の設計書を具体化または詳細化したソースコードと、を含み、
処理を前記コンピュータに実行させる付記１記載の製品設計支援プログラム。
（付記４）
前記要件の必要性を前記難易度と共に表示する、
処理を前記コンピュータに実行させる付記１記載の製品設計支援プログラム。
（付記５）
前記難易度を前記必要性で除算した値を表示する、
処理を前記コンピュータに実行させる付記４記載の製品設計支援プログラム。
（付記６）
前記難易度と前記必要性との関係をグラフ表示する、
処理を前記コンピュータに実行させる付記４記載の製品設計支援プログラム。
（付記７）
前記テスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果と前記テスト書類に関連付けられる第２の書類の機能を実現する開発量とに基づいて、前記難易度を算出する、
処理を前記コンピュータに実行させる付記１記載の製品設計支援プログラム。
（付記８）
前記第２の書類ごとに、各第２の書類に関連付けられたテスト書類に含まれるテスト項目のテスト結果の障害数を前記テスト書類に含まれるテスト項目の数で除算して、前記第２の書類ごとの障害率を演算し、
前記第２の書類ごとに、前記第２の書類の機能を実現するソースコードのステップ数を前記障害率に乗算し、
前記第２の書類ごとに乗算された前記障害率を合算し、
合算した前記障害率を全ての前記ソースコードのステップ数の合計値で除算して、前記難易度を演算する、
処理を前記コンピュータに実行させる付記７記載の製品設計支援プログラム。
（付記９）
前記テスト書類に含まれる前記テスト項目の数を合算した合計値と前記テスト結果に含まれる障害の合計値とに基づいて、前記難易度を算出する、
処理を前記コンピュータに実行させる付記１記載の製品設計支援プログラム。
（付記１０）
開発対象の製品が満たす条件が定義された要件の難易度を算出する製品設計支援方法であって、
前記要件を定義した第１の書類と、当該第１の書類から関連付けられ前記要件の機能を定義した第２の書類と、当該第２の書類に関連付けられたテスト書類と、当該テスト書類に対応付けられたテスト結果と、を記憶する記憶部を参照し、
前記第１の書類に関連付けられた全ての前記第２の書類についてのテスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果とに基づいて、前記要件を実現する際の難易度を算出する、
処理をコンピュータが行う製品設計支援方法。
（付記１１）
開発対象の製品が満たす条件が定義された要件の難易度を算出する製品設計支援装置であって、
前記要件を定義した第１の書類と、当該第１の書類から関連付けられ前記要件の機能を定義した第２の書類と、当該第２の書類に関連付けられたテスト書類と、当該テスト書類に対応付けられたテスト結果と、を記憶する記憶部と、
前記第１の書類に関連付けられた全ての前記第２の書類についてのテスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果とに基づいて、前記要件を実現する際の難易度を算出する演算部と、
を備える製品設計支援装置。
（付記１２）
開発対象の製品が満たす条件が定義された要件の難易度を算出する製品設計支援装置であって、
前記製品設計支援装置は、プロセッサを備え、
前記プロセッサは、
前記要件を定義した第１の書類と、当該第１の書類から関連付けられ前記要件の機能を定義した第２の書類と、当該第２の書類に関連付けられたテスト書類と、当該テスト書類に対応付けられたテスト結果と、を記憶するデータベースを参照し、
前記第１の書類に関連付けられた全ての前記第２の書類についてのテスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果とに基づいて、前記要件を実現する際の難易度を算出する、
処理を行う製品設計支援装置。

１ 難易度算出部
２ 表示部
３ データベース
４ 必要性記憶部
５ データ処理部
６ 演算部
７ 画面生成部
２１ プロセッサ
２２ ＲＡＭ
２３ ＲＯＭ
２４ 補助記憶装置
３０ 可搬型記憶装置

Claims (8)

1. 開発対象の製品が満たす条件が定義された要件の難易度を算出する製品設計支援プログラムであって、
   前記要件を定義した第１の書類と、当該第１の書類から関連付けられ前記要件の機能を定義した第２の書類と、当該第２の書類に関連付けられたテスト書類と、当該テスト書類に対応付けられたテスト結果と、を記憶する記憶部を参照し、
   前記第１の書類に関連付けられた全ての前記第２の書類についてのテスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果とに基づいて、前記要件を実現する際の難易度を算出する、
   処理をコンピュータに実行させる製品設計支援プログラム。
2. 前記要件を複数含み、前記要件ごとに前記難易度を算出する、
   処理を前記コンピュータに実行させる請求項１記載の製品設計支援プログラム。
3. 前記第２の書類は、前記要件を具体化または詳細化した第１の設計書と、当該第１の設計書を具体化または詳細化した第２の設計書と、当該第２の設計書を具体化または詳細化したソースコードと、を含み、
   前記第２の書類に基づいて、前記難易度を算出する、
   処理を前記コンピュータに実行させる請求項１または２記載の製品設計支援プログラム。
4. 前記テスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果と前記テスト書類に関連付けられる第２の書類の機能を実現する開発量とに基づいて、前記難易度を算出する、
   処理を前記コンピュータに実行させる請求項１乃至３のうち何れか１項に記載の製品設計支援プログラム。
5. 前記第２の書類ごとに、各第２の書類に関連付けられたテスト書類に含まれるテスト項目のテスト結果の障害数を前記テスト書類に含まれるテスト項目の数で除算して、前記第２の書類ごとの障害率を演算し、
   前記第２の書類ごとに、前記第２の書類の機能を実現するソースコードのステップ数を前記障害率に乗算し、
   前記第２の書類ごとに乗算された前記障害率を合算し、
   合算した前記障害率を全ての前記ソースコードのステップ数の合計値で除算して、前記難易度を演算する、
   処理を前記コンピュータに実行させる請求項４記載の製品設計支援プログラム。
6. 前記テスト書類に含まれる前記テスト項目の数を合算した合計値と前記テスト結果に含まれる障害の合計値とに基づいて、前記難易度を算出する、
   処理を前記コンピュータに実行させる請求項１乃至３のうち何れか１項に記載の製品設計支援プログラム。
7. 開発対象の製品が満たす条件が定義された要件の難易度を算出する製品設計支援方法であって、
   前記要件を定義した第１の書類と、当該第１の書類から関連付けられ前記要件の機能を定義した第２の書類と、当該第２の書類に関連付けられたテスト書類と、当該テスト書類に対応付けられたテスト結果と、を記憶する記憶部を参照し、
   前記第１の書類に関連付けられた全ての前記第２の書類についてのテスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果とに基づいて、前記要件を実現する際の難易度を算出する、
   製品設計支援方法。
8. 開発対象の製品が満たす条件が定義された要件の難易度を算出する製品設計支援装置であって、
   前記要件を定義した第１の書類と、当該第１の書類から関連付けられ前記要件の機能を定義した第２の書類と、当該第２の書類に関連付けられたテスト書類と、当該テスト書類に対応付けられたテスト結果と、を記憶する記憶部と、
   前記第１の書類に関連付けられた全ての前記第２の書類についてのテスト書類に含まれるテスト項目の数と当該テスト項目のテスト結果とに基づいて、前記要件を実現する際の難易度を算出する演算部と、
   を備える製品設計支援装置。

Images