(57)【特許請求の範囲】
【請求項１】
キーボード等の入力操作部と、メモリ等の情報格納部と、入力あるいは格納されている情報を検索し抽出する演算部と、前記演算部によって抽出された情報を表示画面とを有するコンピュータを利用して、設計対象ソフトウェアのアーキテクチャの設計を支援するソフトウェア設計要件抽出支援方法において、
ソフトウェア設計を行う上で考慮すべき品質特性を前記情報格納部内に予め格納しておく品質特性格納ステップと、
前記コンピュータの入力操作部を介して、設計者から記設計対象ソフトウェアの機能要求項目および非機能要求項目の入力を受け付けて、これらをコンピュータの情報格納部内に記録する要求項目受付ステップと、
前記演算部が、前記情報格納部内に記録された各機能要求項目について、予め情報格納部内に格納されている品質特性とを個別に対比させ、その対比結果をコンピュータの表示画面上に表示する機能項目−品質特性表示ステップと、
前記表示画面上に表示された対比結果に基づいて設計者が判断した各機能要求項目の実現に影響するリスクを、設計者から前記入力操作部を介して受け付けるリスク受付ステップと、
前記演算部が、前記入力操作部を介して受け付けた各リスクを、前記情報格納部内に格納されていた非機能要求項目と個別に対比させ、その対比結果をコンピュータの表示画面上に表示するリスク−非機能要求項目表示ステップと、を含むことを特徴とするソフトウェア設計要件抽出支援方法。
【請求項２】
前記情報格納部内に過去のデータに基づいて予め用意した機能要求項目の候補および非機能要求項目の候補を格納しておき、前記要求項目受付ステップに先立ち、前記演算部が、情報格納部内に格納された機能要求項目と非機能要求項目を表示画面に表示するステップを含む、ことを特徴とする請求項１に記載のソフトウェア設計要件抽出支援方法。
【請求項３】
前記リスク受付ステップが、各リスクについて機能要求項目の実現に対する影響度を受け付けるものであり、前記リスク−非機能表示ステップが、予め設定された基準値以上のリスクを抽出するものである、ことを特徴とする請求項１または請求項２に記載のソフトウェア設計要件抽出支援方法。
【請求項４】
前記要求項目受付ステップが、各非機能要求項目についてその満足度を受け付けるものであり、前記リスク−非機能要求項目表示ステップが、予め設定された基準値以上の非機能要求項目を抽出して表示するものである、ことを特徴とする請求項１乃至請求項３のいずれかに記載のソフトウェア設計要件抽出支援方法。
【請求項５】
キーボード等の入力操作部と、メモリ等の情報格納部と、入力あるいは格納されている情報を検索し抽出する演算部と、前記演算部によって抽出された情報を表示画面とを有するコンピュータを利用して、設計対象ソフトウェアの機能要求項目および非機能要求項目に基づいて得られた複数の対応策の分類整理、およびそれに基づく採用すべき１つ以上の対応策の決定を支援するソフトウェア設計要件決定支援方法において、
ソフトウェア設計を行う上で考慮すべき品質特性を前記情報格納部内に予め格納しておく品質特性格納ステップと、
前記コンピュータの入力操作部を介して、設計者から記設計対象ソフトウェアの機能要求項目および非機能要求項目の入力を受け付けて、これらをコンピュータの情報格納部内に記録する要求項目受付ステップと、
前記演算部が、前記情報格納部内に記録された各機能要求項目について、予め情報格納部内に格納されている品質特性とを個別に対比させ、その対比結果をコンピュータの表示画面上に表示する機能項目−品質特性表示ステップと、
前記表示画面上に表示された対比結果に基づいて設計者が判断した各機能要求項目の実現に影響するリスクを、設計者から前記入力操作部を介して受け付けるリスク受付ステップと、
前記演算部が、前記入力操作部を介して受け付けた各リスクを、前記情報格納部内に格納されていた非機能要求項目と個別に対比させ、その対比結果をコンピュータの表示画面上に表示するリスク−非機能要求項目表示ステップと、
前記リスク−非機能表示ステップにおいて表示画面に表示されたリスク−非機能要求項目に基づいて設計者が用意した対策案を、前記コンピュータの入力操作部を介して受け付けて、これを前記情報格納部内に格納する対策案受付ステップと、
前記情報格納部内の各対策案を表示画面に表示した状態で、設計者から各対策案と重要度を前記入力操作部を介して受け付け、これらを情報格納部に格納する分類受付ステップと、
前記演算部が、前記分類受付ステップで受け付けた各対策案をその重要度に応じて分類整理して表示画面に表示する重要度表示ステップと、
前記重要度表示ステップで表示された重要度の高い各対策案について、設計者からその対策案と関連する他の対策案との関係についての情報を受け付けて情報格納部に格納する関係受付ステップと、
前記演算部が、前記情報格納部に格納されている各対策案を、所定の関係を有する対策案ごとに分類整理して表示画面に表示し、設計者から各グループごとに設計要件の取捨選択情報を受け付けて、前記情報格納部に格納する取捨選択情報受付ステップと、を含むことを特徴とするソフトウェア設計要件決定支援方法。
【請求項６】
前記関係受付ステップは、１つの対応策を採用すると別の対応策の採用が困難になるような相反の関係を受け付けるものであり、前記取捨選択情報受付ステップは、設計者から相反の関係をなくすための対応策を削除するという取捨選択情報を受け付けるものである、ことを特徴とする請求項５に記載のソフトウェア設計要件決定支援方法。
【請求項７】
前記関係受付ステップは、１つの対応策を採用すると別の対応策を採用したのと同様になるような類似および／または依存の関係を受け付けるものであり、前記取捨選択情報受付ステップは、設計者から、設計者が指定した対応策に対して類似および依存の関係にある他の対応策を削除するという取捨選択情報を受け付けるものである、ことを特徴とする請求項５または請求項６に記載のソフトウェア設計要件決定支援方法。
【請求項８】
前記重要度表示ステップは、各対応策の現時点での重要度が予め設定された所定の基準値以上の対応策を表示するものである、ことを特徴とする請求項５乃至請求項７のいずれかに記載のソフトウェア設計要件決定支援方法。
【請求項９】
設計対象ソフトウェアのアーキテクチャの設計を支援するソフトウェア設計要件抽出支援プログラムであって、
前記キーボード等の入力操作部と、メモリ等の情報格納部と、入力あるいは格納されている情報を検索し抽出する演算部と、前記演算部によって抽出された情報を表示画面とを有するコンピュータに対して、
ソフトウェア設計を行う上で考慮すべき品質特性を前記情報格納部内に予め格納しておく品質特性格納機能と、
前記コンピュータの入力操作部を介して、設計者から記設計対象ソフトウェアの機能要求項目および非機能要求項目の入力を受け付けて、これらをコンピュータの情報格納部内に記録する要求項目受付機能と、
前記演算部が、前記情報格納部内に記録された各機能要求項目について、予め情報格納部内に格納されている品質特性とを個別に対比させ、その対比結果をコンピュータの表示画面上に表示する機能項目−品質特性表示機能と、
前記表示画面上に表示された対比結果に基づいて設計者が判断した各機能要求項目の実現に影響するリスクを、設計者から前記入力操作部を介して受け付けるリスク受付機能と、
前記演算部が、前記入力操作部を介して受け付けた各リスクを、前記情報格納部内に格納されていた非機能要求項目と個別に対比させ、その対比結果をコンピュータの表示画面上に表示するリスク−非機能要求項目表示機能と、を実現させることを特徴とするソフトウェア設計要件抽出支援プログラム。
【請求項１０】
設計対象ソフトウェアの機能要求項目および非機能要求項目に基づいて得られた複数の対応策の分類整理、およびそれに基づく採用すべき１つ以上の対応策の決定を支援するソフトウェア設計要件決定支援プログラムであって、
キーボード等の入力操作部と、メモリ等の情報格納部と、入力あるいは格納されている情報を検索し抽出する演算部と、前記演算部によって抽出された情報を表示画面とを有するコンピュータに対して、
ソフトウェア設計を行う上で考慮すべき品質特性を前記情報格納部内に予め格納しておく品質特性格納機能と、
前記コンピュータの入力操作部を介して、設計者から記設計対象ソフトウェアの機能要求項目および非機能要求項目の入力を受け付けて、これらをコンピュータの情報格納部内に記録する要求項目受付機能と、
前記演算部が、前記情報格納部内に記録された各機能要求項目について、予め情報格納部内に格納されている品質特性とを個別に対比させ、その対比結果をコンピュータの表示画面上に表示する機能項目−品質特性表示機能と、
前記表示画面上に表示された対比結果に基づいて設計者が判断した各機能要求項目の実現に影響するリスクを、設計者から前記入力操作部を介して受け付けるリスク受付機能と、
前記演算部が、前記入力操作部を介して受け付けた各リスクを、前記情報格納部内に格納されていた非機能要求項目と個別に対比させ、その対比結果をコンピュータの表示画面上に表示するリスク−非機能要求項目表示機能と、
前記リスク−非機能表示機能において表示画面に表示されたリスク−非機能要求項目に基づいて設計者が用意した対策案を、前記コンピュータの入力操作部を介して受け付けて、これを前記情報格納部内に格納する対策案受付機能と、
前記情報格納部内の各対策案を表示画面に表示した状態で、設計者から各対策案と重要度を前記入力操作部を介して受け付け、前記演算部が、これらを情報格納部に格納する分類受付機能と、
前記演算部が、前記分類受付機能で受け付けた各対策案をその重要度に応じて分類整理して表示画面に表示する重要度表示機能と、
前記重要度表示機能で表示された重要度の高い各対策案について、設計者からその対策案と関連する他の対策案との関係についての情報を受け付けて情報格納部に格納する関係受付機能と、
前記演算部が、前記情報格納部に格納されている各対策案を、所定の関係を有する対策案ごとに分類整理して表示画面に表示し、設計者から各グループごとに設計要件の取捨選択情報を受け付けて、前記情報格納部に格納する取捨選択情報受付機能と、をコンピュータに実現させることを特徴とするソフトウェア設計要件抽出支援プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ソフトウェアのアーキテクチャ設計を行う場合に、機能要求だけでなく、非機能要求も反映させるための手法に関するものである。
【０００２】
【従来の技術】
ソフトウェアのアーキテクチャの設計を行う際、従来は、機能要求に焦点が当てられ、拡張性を高くするなどの非機能要求は、それらをどこまで考慮するかが設計者のスキルに依存することが多く、必ずしも設計に反映されるわけではなかった。ソフトウェアアーキテクチャ設計時に、非機能要求をも反映させなければ、例えば、仕様変更やプラットフォーム変更などの外的変動が発生した場合に、対応するのが困難なことが多い。
【０００３】
また、ＯＭＴ法（Ｊ．ランボー他著、羽生田栄一監訳、オブジェクト指向方法論ＯＭＴモデル化と設計、1992.7 ISBN4-8101-8527-3）などの、オブジェクト指向分析／設計技法も、クラスの抽出、クラス間の関連の抽出などの、マクロなレベルでの作業項目を明示している。しかしながら、従来のオブジェクト指向分析／設計技法は、将来の外的変動が発生したときに対応しやすい構成とするための作業項目を明示するものではないので、顧客の要求等が変動した場合には、要求を満足するソフトウェアを開発するコストが高くなる。
【０００４】
【発明が解決しようとする課題】
現在の高度に複雑化したシステムでは、単に顧客の要求する機能だけを実現すればよいわけではない。その上、顧客の要求自体も曖昧で、開発が進むにつれて、要求仕様が次第に明らかになるというケースも多い。このような、要求の変更などの外的変動に対応できるようにするためには、発生した要因が、ソフトウェアのどこの部分に影響を与えるか、どのように修正すべきかを、明確に追跡できるようにする必要がある。
【０００５】
そのためには、現状の設計が、「なぜそのようになっているか」を明確に説明できる必要がある。なぜなら、仕様変更に強くするには、予め仕様変更を想定し、それを反映した設計でなければならず、このことが、「なぜそのような設計になっているか」という理由になるからである。したがって、ソフトウェアの設計に当たっては、様々な変動に対応できるように予め作り込むことが必要であり、このことが、設計の根拠を重要視しなければならない理由である。
【０００６】
本発明は、以上のような従来技術の課題を解決するために提案されたものであり、その目的は、外的変動が発生した場合に、どの部分が影響するか、どのように直すべきかを明確化できるようにして、ソフトウェア開発のトータルコストを下げ、また、顧客満足度の高いソフトウェアを開発できるようにするための優れた方法を提供することである。
【０００７】
すなわち、本発明の第１の目的は、設計対象ソフトウェアの構成と仕組みに関して作り込むべき設計要件として、機能要求だけでなく非機能要求をも反映させた設計要件を効率的に抽出可能とすることにより、多様な非機能要求を設計の根拠として設計に反映可能なソフトウェア設計要件抽出支援方法を提供することである。
【０００８】
また、本発明の第２の目的は、機能要求および非機能要求を反映させた設計要件を分類整理して重要な設計要件のみに限定し、採用すべき設計要件を効率的に決定可能なソフトウェア設計要件決定支援方法を提供することである。また、本発明の第３の目的は、機能要求および非機能要求を反映させた設計要件に基づいて、多様な外的変動に対応可能なソフトウェアアーキテクチャを効率的に設計可能なソフトウェア設計支援方法を提供することである。
【０００９】
【課題を解決するための手段】
上記目的を達成するために、本発明は、各機能要求項目についてソフトウェア設計上で考慮すべき特性を個別に対比させることで機能要求項目の実現に影響する事象を抽出し、各事象について非機能要求項目を個別に対比させることで、機能要求だけでなく非機能要求をも反映させた設計要件を効率的に抽出できるようにしたものである。
【００１０】
なお、本発明において重要な用語の定義は次の通りである。
「設計要件」は、設計対象ソフトウェアの構成と仕組みに関して作り込むべき具体的な要件であり、それを実現するために、設計対象ソフトウェアの具体的な構成と仕組みが決定付けられるような具体的な内容を表現する情報である。例えば、処理Ａを行える仕組みを設ける、情報Ｂを保持できる構成にする、部分Ｃを変更可能な構成にする、等の情報であるが、情報の表現形式は何ら限定されない。
【００１１】
「機能要求」は、設計されるソフトウェアに要求される具体的な機能を意味しており、ソフトウェアエンジニアリングの分野で一般的に使用されている用語である。
「非機能要求」は、設計されるソフトウェアに要求される具体的な機能以外の各種の要求を意味しており、例えば、性能要求、搭載対象の制約、再利用性、拡張性、保守性、セキュリティ、使いやすさ、等の各種の制約や条件を含む広い概念である。この「非機能要求」もまた、ソフトウェアエンジニアリングの分野で一般的に使用されている用語である。
【００１２】
「ソフトウェア設計を行う上で考慮すべき特性」は、ソフトウェア設計一般において考慮すべき各種の特性を意味しており、例えば、ソフトウェアエンジニアリングの分野で一般に定義されている、品質評価のための特性である「品質特性」をもとに再構成した、「アーキテクチャ特性」などを利用できる。アーキテクチャ特性には、「仕様の安定性」などのアーキテクチャ特性項目が多数含まれているが、それぞれに、機能要求項目の実現に影響する事象を誘発させるための質問を定義している。「ソフトウェア設計を行う上で考慮すべき特性」は、「アーキテクチャ特性項目」に限らず、定義済みの他の各種の特性項目、あるいは開発者等が事前に定義した特性項目なども含む広い概念である。
【００１３】
「機能要求項目の実現に影響する事象」は、対象としている機能要求項目の実現方法に影響を与えるか、あるいは実現を困難にするような、何らかの事象を意味しており、一般的にリスクと称される事象を含むが、それ以外の各種の事象を含む広い概念である。
「ソフトウェアアーキテクチャ」は、ソフトウェアの全体構造とそれぞれの部分を構成する構成要素間の関係を表現する情報であり、ソフトウェア全体の設計方針となるものである。この「ソフトウェアアーキテクチャ」もまた、ソフトウェアエンジニアリングの分野で一般的に使用されている用語である。
【００１４】
請求項１の発明は、キーボード等の入力操作部と、メモリ等の情報格納部と、入力あるいは格納されている情報を検索し抽出する演算部と、前記演算部によって抽出された情報を表示画面とを有するコンピュータを利用して、設計対象ソフトウェアのアーキテクチャの設計を支援するソフトウェア設計要件抽出支援方法において、
ソフトウェア設計を行う上で考慮すべき品質特性を前記情報格納部内に予め格納しておく品質特性格納ステップと、
前記コンピュータの入力操作部を介して、設計者から記設計対象ソフトウェアの機能要求項目および非機能要求項目の入力を受け付けて、これらをコンピュータの情報格納部内に記録する要求項目受付ステップと、
前記演算部が、前記情報格納部内に記録された各機能要求項目について、予め情報格納部内に格納されている品質特性とを個別に対比させ、その対比結果をコンピュータの表示画面上に表示する機能項目−品質特性表示ステップと、
前記表示画面上に表示された対比結果に基づいて設計者が判断した各機能要求項目の実現に影響するリスクを、設計者から前記入力操作部を介して受け付けるリスク受付ステップと、
前記演算部が、前記入力操作部を介して受け付けた各リスクを、前記情報格納部内に格納されていた非機能要求項目と個別に対比させ、その対比結果をコンピュータの表示画面上に表示するリスク−非機能要求項目表示ステップと、を含むことを特徴とする。
【００１５】
この方法によれば、各機能要求項目についてソフトウェア設計上で考慮すべき特性を個別に対比させることにより、その対比結果に基づいて機能要求項目の実現に影響する事象を抽出することができる。そして、抽出された各事象について非機能要求項目を個別に対比させることにより、その対比結果に基づいて機能要求だけでなく非機能要求をも反映させた設計要件を効率的に抽出することができる。したがって、この方法によって得られた設計要件を採用することにより、多様な非機能要求を設計の根拠として設計に反映させることができる。
【００１６】
請求項２の発明は、前記情報格納部内に過去のデータに基づいて予め用意した機能要求項目の候補および非機能要求項目の候補を格納しておき、前記要求項目受付ステップに先立ち、前記演算部が、情報格納部内に格納された機能要求項目と非機能要求項目を表示画面に表示するステップを含む、ことを特徴とする。
この方法によれば、過去のデータに基づいて予め用意した候補の中で該当するものがあればそれを選択するだけで機能要求項目および非機能要求項目を入力できるため、候補が存在しない要求項目のみを作成するだけで、必要な全ての要求項目を効率的に入力することができる。
【００１７】
請求項３の発明は、前記リスク受付ステップが、各リスクについて機能要求項目の実現に対する影響度を受け付けるものであり、前記リスク−非機能表示ステップが、予め設定された基準値以上のリスクを抽出するものである、ことを特徴とする。
この方法によれば、候補として得られる事象の中から影響度が基準値以上の事象のみを機械的に抽出し、影響度の低い事象を除去することにより、抽出する事象の数を自動的に少なくできるため、事象の抽出効率を高めると共に、後続作業の効率を高めることができる。
【００１８】
請求項４の発明は、前記要求項目受付ステップが、各非機能要求項目についてその満足度を受け付けるものであり、前記リスク−非機能要求項目表示ステップが、予め設定された基準値以上の非機能要求項目を抽出して表示するものである、ことを特徴とする。
この方法によれば、候補として得られる設計要件の中から非機能要求項目の満足度が基準値以上の設計要件のみを機械的に抽出し、満足度の低い設計要件を除去することにより、抽出する設計要件の数を自動的に少なくできるため、設計要件の抽出効率を高めると共に、後続作業の効率を高めることができる。
【００１９】
請求項５の発明は、前記請求項１の発明に加え、
前記リスク−非機能表示ステップにおいて表示画面に表示されたリスク−非機能要求項目に基づいて設計者が用意した対策案を、前記コンピュータの入力操作部を介して受け付けて、これを前記情報格納部内に格納する対策案受付ステップと、
前記情報格納部内の各対策案を表示画面に表示した状態で、設計者から各対策案と重要度を前記入力操作部を介して受け付け、前記演算部が、これらを情報格納部に格納する分類受付ステップと、
前記演算部が、前記分類受付ステップで受け付けた各対策案をその重要度に応じて分類整理して表示画面に表示する重要度表示ステップと、
前記重要度表示ステップで表示された重要度の高い各対策案について、設計者からその対策案と関連する他の対策案との関係についての情報を受け付けて情報格納部に格納する関係受付ステップと、
前記演算部が、前記情報格納部に格納されている各対策案を、所定の関係を有する対策案ごとに分類整理して表示画面に表示し、設計者から各グループごとに設計要件の取捨選択情報を受け付けて、前記情報格納部に格納する取捨選択情報受付ステップと、を含むことを特徴とする。
【００２１】
この方法によれば、機能要求および非機能要求を反映させた複数の設計要件を分類整理して、相関の高い複数の設計要件を上位の設計要件に統合する等の作業を行い、機能要求項目群や現在の作業範囲、作業フェーズ等の詳細度、具体度等によって決定される現時点での重要性の高い設計要件を抽出することにより、設計要件をより少ない数の重要な設計要件のみに限定することができる。そして、そのように限定された重要な設計要件について、所定の関係を有する設計要件のグループごとに設計要件の取捨選択を順次行うことにより、設計要件の数を効率的に絞り込むことができる。したがって、この方法によれば、機能要求および非機能要求を反映させた設計要件を分類整理して重要な設計要件のみに限定し、限定した設計要件を設計要件間の関係に基づいてさらに効率的に絞り込むことができるため、採用すべき設計要件を効率的に決定することができる。
【００２２】
請求項６の発明は、前記関係受付ステップは、１つの対応策を採用すると別の対応策の採用が困難になるような相反の関係を受け付けるものであり、前記取捨選択情報受付ステップは、設計者から相反の関係をなくすための対応策を削除するという取捨選択情報を受け付けるものである、ことを特徴とする。
【００２３】
請求項７の発明は、前記関係受付ステップは、１つの対応策を採用すると別の対応策を採用したのと同様になるような類似および／または依存の関係を受け付けるものであり、前記取捨選択情報受付ステップは、設計者から、設計者が指定した対応策に対して類似および依存の関係にある他の対応策を削除するという取捨選択情報を受け付けるものである、ことを特徴とする。
【００２４】
これらの方法によれば、複数の設計要件が相反の関係にある場合には、相反の関係をなくすような取捨選択を行い、複数の設計要件が類似の関係にある場合には数を少なくするような取捨選択を行うことができる。したがって、重要な設計要件として抽出された設計要件について、設計要件間の関係と現時点での重要性に応じて適切な取捨選択を順次行うことにより、設計要件の数を適切かつ効率的に絞り込むことができるため、より少ない数の最も重要な設計要件のみを、採用すべき設計要件として容易に決定することができる。
【００２５】
請求項８の発明は、前記重要度表示ステップは、各対応策の現時点での重要度が予め設定された所定の基準値以上の対応策を表示するものである、ことを特徴とする。
この方法によれば、機能要求および非機能要求に基づいて得られた設計要件を分類整理した上で、現時点での重要度が基準値以上の設計要件のみを機械的に抽出し、重要度が比較的低い設計要件を除去することにより、抽出する設計要件の数を自動的に少なくできるため、設計要件の抽出効率を高めると共に、後続作業の効率を高めることができる。
【００２８】
なお、請求項９または１０の発明は、請求項１または５の発明の方法をそれぞれプログラムの観点から把握したものであり、各プログラムによれば、対応する各方法について上述した作用と同様の作用が得られる。
【００２９】
【発明の実施の形態】
以下には、本発明の実施形態を図面に沿って具体的に説明する。ただし、ここで記載する実施形態は、本発明を何ら限定するものではなく、本発明の一態様を例示するものにすぎない。
【００３０】
本発明は、典型的には、コンピュータをソフトウェアで制御することにより実現される。この場合のソフトウェアは、コンピュータのハードウェアを物理的に活用することで本発明の作用効果を実現するものであり、また、従来技術を適用可能な部分には好適な従来技術が適用される。さらに、本発明を実現するハードウェアやソフトウェアの具体的な種類や構成、ソフトウェアで処理する範囲などは自由に変更可能であり、例えば、本発明を実現するプログラムは本発明の一態様である。
【００３１】
［１．ソフトウェア設計支援方法］
図１は、本発明を適用したソフトウェア設計支援方法の概要をデータの流れと共に示すフローチャートである。この図１に示すように、顧客、経営者、プロジェクトマネージャ等のステークホルダからの要求は、設計者により、機能要求項目Ｄ１１と非機能要求項目Ｄ１２とに分類して入力され、記録される（Ｓ１１０）。
【００３２】
次に、リスク項目とそれに対する対策案の抽出を行う（Ｓ１２０）。すなわち、記録された各機能要求項目Ｄ１１について、予め用意されたアーキテクチャ特性項目Ｄａを順次組み合わせて（Ｓ１２１）、各組み合わせについてリスク項目Ｄ２１を抽出、記録し（Ｓ１２２）、各リスク項目Ｄ２１について、全ての非機能要求項目Ｄ１２を個別に対比させ、可能性Ｄ２２、許容度Ｄ２３、対策案Ｄ２４を抽出、記録する（Ｓ１２３）。
【００３３】
ここで、「アーキテクチャ特性項目」とは、ソフトウェアアーキテクチャ設計を行う上で考慮すべき特性として一般に定義されている「品質特性」をもとに再構成したもので、ソフトウェアアーキテクチャ設計を行う上で考慮すべき特性項目を表している。また、「リスク」とは、本発明における「機能要求項目の実現に影響する事象」に含まれる概念であり、そのような事象の中でも、特に、対象としている機能要求項目の実現に、大きな影響を与えるか、あるいは実現を困難にすると思われるような、より限定された何らかの事象を意味している。
【００３４】
また、「可能性」は、そのリスクが発生するのはどのような場合かについての情報であり、「許容度」は、そのリスクをどこまで考慮すべきかについての情報である。また、「対策案」は、本発明における「設計要件」に含まれる概念であり、ここでは、そのリスクが発生した場合の対応を容易にするために、どのような構成、仕組み等を設ければよいかについての情報である。そして、機能要求項目Ｄ１１とアーキテクチャ特性項目Ｄａの全ての組み合わせについてステップＳ１２１〜Ｓ１２３を行った時点で次のステップＳ１３０に進む。
【００３５】
ステップＳ１３０においては、記録された対策案Ｄ２４を分類整理して、現時点で重要な対策案Ｄ３１と現時点で重要でない対策案Ｄ３２を抽出、記録する。次に、記録された「重要な対策案」Ｄ３１について、相反、類似、依存、独立、等の各種の関係のうち、少なくとも、相反、類似、依存、等の、ある対策案を講ずることが別の対策案を講ずることに何らかの影響を与える関係を「重要な対策案の関係」Ｄ４として抽出、記録する（Ｓ１４０）。
【００３６】
ここで、「相反」は、ある対策案を講ずると、別の対策案を講ずるのが困難あるいは不可能になる、という関係である。また、「類似」は、ある対策案を講ずると、別の対策案をも講じたことになる、という関係である。また、「依存」は、ある対策案を講ずるためには、別の対策案を講ずることが条件となる、という関係である。そしてまた、「独立」は、ある対策案を講じても、別の対策案を講ずることに何ら影響を与えない、という関係である。
【００３７】
続いて、記録された「重要な対策案の関係」Ｄ４に基づいて、所定の関係を有する各グループごとに対策案の取捨選択を行い、ソフトウェアアーキテクチャ設計に採用すべき１つ以上の対策案を決定する（Ｓ１５０）。そして、記録された「採用すべき対策案」Ｄ５に基づいて、各対策案を実現するための構成と動作原理を順次抽出し、統合することにより、ソフトウェアアーキテクチャＤ６を構築し、記録する（Ｓ１６０）。
【００３８】
なお、ステップＳ１６０で記録されたソフトウェアアーキテクチャＤ６の構成要素群が、実装環境に依存せずに、その詳細を検討できると判断された場合（Ｓ１７０）には、それぞれの構成要素群を対象に、上記ステップＳ１１０〜Ｓ１６０を繰り返す。
以下には、図１を参照しながら、ソフトウェア設計支援方法における個々のステップの詳細について順次説明する。
【００３９】
［１−１．機能要求項目と非機能要求項目の入力ステップ］
機能要求項目と非機能要求項目の入力ステップＳ１１０においては、設計者が、顧客、経営者、プロジェクトマネージャ等のステークホルダから与えられた要求の中から機能的な要求に属するものを抽出、整理して機能要求項目とすると共に、それ以外のものを非機能要求項目として分類し、キーボード等の入力操作部により入力操作を行うことにより、それらの機能要求項目Ｄ１１および非機能要求項目Ｄ１２に関する情報は、コンピュータに入力され、メモリ等の格納部に記録される。
【００４０】
［１−２．リスク項目とそれに対する対策案等の抽出ステップ］
図２は、リスク項目とそれに対する対策案等の抽出ステップＳ１２０（ステップＳ１２１〜Ｓ１２４）の詳細をデータの流れと共に示すフローチャートである。この図２に示すように、まず、入力ステップＳ１１０で記録された機能要求項目Ｄ１１と予め用意されたアーキテクチャ特性項目Ｄａから、１つの機能要求項目Ｄ１１と１つのアーキテクチャ特性項目Ｄａからなる組み合わせを取り出す（Ｓ２０１）。このステップＳ２０１は、図１のステップＳ１２１に相当する。
【００４１】
そして、機能要求項目Ｄ１１とアーキテクチャ特性項目Ｄａの組み合わせを、類似リスク検索の支援表示と共に設計者に順次提示してリスク項目の入力支援を行う（Ｓ２０２）。なお、本実施形態における各種の入力支援は、基本的に、設計者に対して情報を画面表示することで行われ、これに音声出力等が適宜組み合わせられるようになっている。設計者が検索要求の入力操作を行うことで、類似リスクの検索要求が入力された場合（Ｓ２０３のＹＥＳ）には、過去の作業データＤｂから類似したリスクを検索、提示する（Ｓ２０４）。
【００４２】
設計者が、提示された機能要求項目Ｄ１１とアーキテクチャ特性項目Ｄａの組み合わせや過去の類似データＤｂ等を参照しながら、リスクの検討を行ってリスク項目の作成やその確認等の入力操作を行った場合（Ｓ２０５のＹＥＳ）には、そのリスク項目Ｄ２１に関する情報は、コンピュータに入力され、メモリ等の格納部に記録される（Ｓ２０６）。なお、これらのステップＳ２０２〜Ｓ２０６は、図１のステップＳ１２２に相当する。
【００４３】
続いて、記録されたリスク項目Ｄ２１を設計者に提示して可能性、許容度、対策案の入力支援を行う（Ｓ２０７）。この入力支援にあたってはまた、記録された非機能要求項目を満足させる「対策案」を得るために、設計者に対して、全ての非機能要求項目Ｄ１２を示すリストが各リスク項目Ｄ２１と同時に提示される。設計者が、提示されたリスク項目Ｄ２１と非機能要求項目Ｄ１２を参照しながら、リスク項目Ｄ２１に対する可能性Ｄ２２、許容度Ｄ２３、対策案Ｄ２４の検討を行ってそれらの情報の作成やその確認等の入力操作を行った場合（Ｓ２０８のＹＥＳ）には、それらの情報は、コンピュータに入力され、メモリ等の格納部に記録される（Ｓ２０９）。なお、これらのステップＳ２０７〜Ｓ２０９は、図１のステップＳ１２３に相当する。
【００４４】
そして、機能要求項目Ｄ１１とアーキテクチャ特性項目Ｄａの各組み合わせを順次取り出し、各組み合わせについてステップＳ２０２〜Ｓ２０９を繰り返す。最終的に、全ての組み合わせについて上記のステップＳ２０１〜Ｓ２０９を行った（Ｓ１２４のＮＯ、Ｓ２１０のＮＯ）時点で、次のステップＳ１３０に進む。なお、このようなリスク項目Ｄ２１とそれに対する対策案Ｄ２４等の抽出ステップは、記録された非機能要求項目Ｄ１２をブレイクダウンすることと、潜在的な非機能的な要求を漏れなく抽出するために行うものであるため、対策案Ｄ２４は、その詳細度、粒度にはあまり左右されることなく、広い視野で漏れなく抽出することが望ましい。
【００４５】
［１−３．対策案の分類整理、重要な対策案の抽出ステップ］
図３は、対策案の分類整理、重要な対策案の抽出ステップＳ１３０の詳細をデータの流れと共に示すフローチャートである。この図３に示すように、まず、ステップＳ１２０で記録された全ての対策案Ｄ２４のリストを設計者に提示して入力支援を行う（Ｓ３０１）。設計者が、相関の高い複数の対策案の選択やその確認等の入力操作を行うことで、統合の対象となる複数の対策案Ｄ２４が指定された場合（Ｓ３０２のＹＥＳ）には、それらの複数の対策案Ｄ２４を統合対象グループとして並べて提示し、対策案の記述を修正させるための入力支援を行う（Ｓ３０３）。
【００４６】
設計者が、提示された複数の対策案Ｄ２４を参照しながら、統合対象グループに含まれる対策案の全てを包括するような上位の対策案に統合する形で、対策案の記述の修正やその確認等の入力操作を行った場合（Ｓ３０４のＹＥＳ）には、元となったグループの複数の対策案がリスト中で削除され、それらを包括する上位の対策案に置き換えられる（Ｓ３０５）。
【００４７】
相関の高い対策案Ｄ２４の統合が終了するかあるいはそのような統合の対象となる複数の対策案Ｄ２４が存在せず、統合が不要である場合（Ｓ３０６のＹＥＳ）には、設計者は、対象の機能要求項目群の具体度、現在の作業範囲、作業フェーズ等の詳細度や具体度に適合する対策案の検討のみを行う。このような検討に基づき、設計者が、現在のフェーズで考慮すべき対策案としての選択やその確認等の入力操作を行った場合（Ｓ３０７のＹＥＳ）には、設計者の選択結果に応じて、設計者によって選択された対策案Ｄ２４は現時点で「重要な対策案」Ｄ３１として、また、選択されなかった対策案Ｄ２４は現時点で「重要でない対策案」Ｄ３２として、メモリ等の格納部にそれぞれ記録される（Ｓ３０８）。
【００４８】
すなわち、設計者によって現在のフェーズで考慮すべき対策案として選択されなかった対策案については、実装する環境に依存した対策案、あるいは、対象の機能要求項目群の具体度、現在の作業範囲、作業フェーズ等の詳細度、具体度等と比べて、詳細度や具体度が高い対策案、等については、現在のフェーズで考慮すべきではない対策案である。したがって、これらの対策案については、現時点で「重要でない対策案」Ｄ３２としてグルーピングしておき、その対策案を考慮すべき時点で抽出すればよい。
【００４９】
［１−４．重要な対策案の関係抽出ステップ］
図４は、重要な対策案の関係抽出ステップＳ１４０の詳細をデータの流れと共に示すフローチャートである。この図４に示すように、まず、ステップＳ１３０で記録された現時点で重要な対策案Ｄ３１の全てを示すリストと共に、相反、類似、依存、等の関係を示すシンボル等を示す選択画面を設計者に提示して入力支援を行う（Ｓ４０１）。設計者が、相反の関係を有する複数の対策案とその関係の選択やその確認等の入力操作を行うことで、相反の関係を有する複数の対策案Ｄ３１が指定された場合（Ｓ４０２のＹＥＳ）には、それらの複数の対策案Ｄ３１を、相反の関係を有する対策案のグループとして提示して次の入力操作に備える（Ｓ４０３）。
【００５０】
同様に、類似の関係を有する複数の対策案Ｄ３１が指定された場合（Ｓ４０４のＹＥＳ）には、それらの複数の対策案Ｄ３１を、類似の関係を有する対策案のグループとして提示して次の入力操作に備える（Ｓ４０５）。そしてまた、依存の関係を有する複数の対策案Ｄ３１が、依存する側と依存される側を示す依存方向と共に指定された場合（Ｓ４０６のＹＥＳ）には、それらの複数の対策案Ｄ３１を、依存の関係を有する対策案のグループとして依存方向と共に提示して次の入力操作に備える（Ｓ４０７）。
【００５１】
そして、全ての対策案について、関係の明確化が終了した時点（Ｓ４０８のＹＥＳ）で、相反、類似、依存等の、重要な対策案の関係に関する情報は、「重要な対策案の関係」Ｄ４として、メモリ等の格納部に記録される（Ｓ４０９）。なお、このステップＳ１４０は、ソフトウェアアーキテクチャ設計に、どのような対策を講じていけばよいかを検討しやすくするために行うものであるため、その観点から必要となる各種の関係を抽出、記録する。
【００５２】
［１−５．採用すべき対策案の決定ステップ］
図５は、採用すべき対策案の決定ステップＳ１５０の詳細をデータの流れと共に示すフローチャートである。この図５に示すように、まず、ステップＳ１４０で記録された「重要な対策案の関係」Ｄ４に基づいて、相反の関係を有する「重要な対策案」Ｄ３１の各グループを設計者に順次提示して入力支援を行う（Ｓ５０１）。
【００５３】
設計者が、提示された対策案の各グループについて、相反の関係を解消させるために採用しない対策案の選択やその確認等の入力操作を行うことで、各グループについて採用しない対策案Ｄ３１ａが指定された場合（Ｓ５０２のＹＥＳ）には、その指定された対策案Ｄ３１ａに基づいて、採用しない対策案を決定し、重要な対策案Ｄ３１から削除する（Ｓ５０３）。
【００５４】
すなわち、指定された対策案Ｄ３１ａを採用しない対策案として決定すると共に、その指定された対策案Ｄ３１ａと類似の関係を有する別の単数または複数の対策案Ｄ３１ｂ、および指定された対策案に依存する別の単数または複数の対策案Ｄ３１ｃについても採用しないものと決定し、これらの採用しない対策案Ｄ３１ａ，Ｄ３１ｂ，Ｄ３１ｃを、重要な対策案Ｄ３１から削除する。
【００５５】
次に、削除されずに残った「重要な対策案」Ｄ３１の中から、類似の関係を有する「重要な対策案」Ｄ３１の各グループを設計者に順次提示して入力支援を行う（Ｓ５０４）。設計者が、提示された対策案の各グループについて、最も重要な対策案の選択やその確認等の入力操作を行うことで、各グループで最も重要な対策案Ｄ３１ｄが指定された場合（Ｓ５０５のＹＥＳ）には、その指定された対策案Ｄ３１ｄを採用する対策案として決定し、各グループの別の単数または複数の対策案Ｄ３１ｅを、重要な対策案から削除する（Ｓ５０６）。
【００５６】
続いて、削除されずに残った「重要な対策案」Ｄ３１の中から、依存の関係を有する「重要な対策案」Ｄ３１の各グループを設計者に順次提示して入力支援を行う（Ｓ５０７）。設計者が、提示された対策案の各グループについて、採用する対策案の選択やその確認等の入力操作を行うことで、各グループについて採用する対策案Ｄ３１ｆが指定された場合（Ｓ５０８のＹＥＳ）には、その指定された対策案Ｄ３１ｆに基づいて、採用しない対策案を決定し、重要な対策案Ｄ３１から削除する（Ｓ５０９）。
【００５７】
すなわち、グループ内に指定された対策案Ｄ３１ｆが依存する別の対策案Ｄ３１ｇがある場合には、最終的な依存先となる対策案まで辿る形で、対策案Ｄ３１ｆが依存する全ての対策案Ｄ３１ｇを採用する対策案として決定し、指定された対策案Ｄ３１ｆにさらに依存するような別の対策案Ｄ３１ｈについては、重要な対策案から削除する。
【００５８】
最後に、削除されずに残った「重要な対策案」Ｄ３１の中から、上記のような、相反、類似、依存の関係を持たず、他の対策案から完全に独立している対策案については、個々の対策案を設計者に個別に順次提示して入力支援を行う（Ｓ５１０）。設計者が、提示された個々の対策案について、採用の有無やその確認等の入力操作を行うことで、採用すると指定された対策案Ｄ３１ｉについては（Ｓ５１１１のＹＥＳ）には、その指定された対策案Ｄ３１ｉを採用する対策案として決定し、採用しないと指定された対策案Ｄ３１ｊについては、その対策案Ｄ３１ｊを、重要な対策案から削除する（Ｓ５１２）。
【００５９】
そして、以上のような、相反、類似、依存、独立の関係に基づく対策案の取捨選択が終了した時点（Ｓ５１３のＹＥＳ）で、削除されずに残った「重要な対策案」Ｄ３１は、「採用すべき対策案」Ｄ５として、メモリ等の格納部に記録される（Ｓ５１４）。
【００６０】
［１−６．対策案を実現する構成と動作原理の抽出、統合ステップ］
図６は、対策案を実現する構成と動作原理の抽出、統合ステップＳ１６０の詳細をデータの流れと共に示すフローチャートである。この図６に示すように、まず、ステップＳ１５０で記録された「採用すべき対策案」Ｄ５に基づいて、全ての「採用すべき対策案」Ｄ５のリストを設計者に提示して、優先順位を付けさせるための入力支援を行う（Ｓ６０１）。なお、ここでは、「採用すべき対策案」Ｄ５として、ｎ個の対策案Ｄ５１〜Ｄ５ｎが存在するものとする。
【００６１】
設計者が、提示されたｎ個の対策案Ｄ５１〜Ｄ５ｎについて、優先順の選択やその確認等の入力操作を行うことで、ｎ個の対策案Ｄ５１〜Ｄ５ｎの優先順位が指定された場合（Ｓ６０２のＹＥＳ）には、既存のパターンや過去の作業データ等に対する情報検索の支援表示と共に、その指定された優先順位に基づいて、対策案Ｄ５１〜Ｄ５ｎを順次提示して、それを実現する構成、動作原理を入力するための入力支援を行う（Ｓ６０３）。設計者が、検索要求の入力操作を行うことで、既存のパターンや過去の作業データの検索要求が入力された場合（Ｓ６０４のＹＥＳ）には、既存のアーキテクチャパターンやデザインパターンＤｃ、過去の作業データＤｂ等の情報を検索、提示する（Ｓ６０５）。
【００６２】
設計者が、提示された第１の対策案Ｄ５１や、既存のパターンＤｃや過去の作業データＤｂ等の情報を参照しながら、その対策案Ｄ５１を実現する構成、動作原理を検討し、それらに関する情報の入力操作を行った場合（Ｓ６０６のＹＥＳ）には、その構成、動作原理Ｄ６１に関する情報が明確性を有するか否かが判定される（Ｓ６０７）。
【００６３】
すなわち、構成、動作原理に関する情報において、各構成要素は、役割、責任範囲を明確に定義している必要があるため、そのような明確性を判定して不明確な場合（Ｓ６０７のＮＯ）には、再入力操作を促すこと等が行われる。明確性を有する場合（Ｓ６０７のＹＥＳ）には、その構成、動作原理Ｄ６１に関する情報は、コンピュータに入力され、メモリ等の格納部に記録される（Ｓ６０８）。なお、構成、動作原理に関する情報は、ブロック構造図程度（マクロなレベル）でもよく、対象が狭い場合には、プログラム言語で設計者が経験に基づいて作成してもよい。
【００６４】
続いて、次の対策案Ｄ５２がある場合（Ｓ６０９のＹＥＳ）には、その対策案Ｄ５２と情報検索の支援表示を行うと共に、取得済みの構成、動作原理Ｄ６１に関する情報を設計者に提示して入力支援を行い（Ｓ６０３）、Ｓ６０４〜Ｓ６０７によって、その対策案Ｄ５２を実現するための構成、動作原理Ｄ６２を取得し、既存の構成、動作原理Ｄ６１に統合する（Ｓ６０８）。このようにして、優先順位が最下位である第ｎ番目の対策案Ｄ５ｎまで、同様の作業を行い、構成、動作原理を統合していく。なお、統合が困難な場合には、その対策案に対して別の構成、動作原理を抽出するか、最初の対策案に戻って別の構成、動作原理を抽出するか、あるいは任意の別のステップに戻ってやり直す等の作業が行われる。
【００６５】
そして、抽出、統合された構成、動作原理が、全ての「採用すべき対策案」を反映した構成、動作原理になった時点（Ｓ６１０のＹＥＳ）で、顧客の要求等に応じて動作シナリオを導出し、その動作シナリオを、現時点の構成、動作原理上で、各構成要素の責任、責任範囲から逸脱せず、動作原理から逸脱せずに、動作させることができるか否かを検証する（Ｓ６１１）。この結果、問題があると判断された場合（Ｓ６１１のＹＥＳ）に、これを回避する非機能要求項目を抽出できる場合にはそれを加え、任意のステップからやり直す。そして、最終的に問題がないことが検証できた場合（Ｓ６１１のＮＯ）には、現時点の構成、動作原理をソフトウェアアーキテクチャＤ６として記録する（Ｓ６１２）。
【００６６】
［１−７．構成要素群に対する繰り返しステップの補足説明］
以下には、ステップＳ１６０で記録されたソフトウェアアーキテクチャの構成要素群を対象とした上記ステップＳ１１０〜Ｓ１６０の繰り返しステップについて補足説明する。まず、ステップＳ１１０の機能要求項目Ｄ１１は、ステップＳ１６０で構築したソフトウェアアーキテクチャＤ６上で、対象の構成要素群と関連する構成要素群に対して提供する機能要求項目となる。これらは、対象の構成要素群の役割、責任範囲や、ステップＳ１２０で抽出した対策案Ｄ２４から、抽出する。
【００６７】
また、この繰り返し作業において、ステップＳ１２０については、以前の繰り返し作業中の同じステップＳ１２０で抽出した対策案Ｄ２４や、ステップＳ１３０において「現時点で重要でない対策案」としてグルーピングされた対策案Ｄ３２を参考にする。そしてまた、ステップＳ１６０については、以前の繰り返し作業の同じステップＳ１６０で構築したソフトウェアアーキテクチャＤ６に統合していく。
【００６８】
［２．ソフトウェア設計の具体例］
以下には、上記のような本実施形態によるソフトウェア設計支援方法を、会議室予約システムのソフトウェアアーキテクチャ設計に適用した具体例について説明する。
【００６９】
［２−１．機能要求項目と非機能要求項目の入力ステップ］
ここでは、顧客からの要求として、次のような要求１〜要求６が与えられたものとする。
【００７０】
【表１】
（要求１）：オンラインで会議室の予約を行うためのシステム。利用者は、端末にログインして会議室の予約、キャンセル、閲覧を行える。
（要求２）：予約する場合、利用者は、日付、時間帯、会議室を指定する。端末には、予約できたか否かを表示する。
（要求３）：キャンセルする場合、利用者は、その利用者の予約を指定する。キャンセルは、予約を行った利用者でなければ、キャンセルできないものとする。端末には、キャンセルできたか否かを表示する。
（要求４）：閲覧を行う場合、利用者は、会議室を指定する。端末には、指定された会議室について、操作を行った日から１ヶ月後までの予約状況を表示する。
（要求５）：端末の画面構成、操作仕様は任意であるが、直感的でわかりやすいユーザインタフェースとする。
（要求６）：複数の利用者が同時に、同じ時間、同じ会議室の予約を行おうとしても、先着順で予約可、予約不可が決まる。
【００７１】
これらの要求１〜要求６に基づいて、機能的な要求と非機能的な要求を抽出し、機能的な要求について、設計者がユースケース分析を行うことにより、機能要求項目および非機能要求項目として、以下の各項目を抽出し、入力操作する。その結果、これらの情報は、コンピュータに入力され、メモリ等にデータとして記録される（Ｓ１１０）。
【００７２】
【表２】
（機能要求項目１）：予約を閲覧する
（機能要求項目２）：予約する
（機能要求項目３）：予約をキャンセルする
（非機能要求項目１）：端末からの操作性
（非機能要求項目２）：同時利用の配慮
（非機能要求項目３）：拡張性を重視
【００７３】
［２−２．リスク項目とそれに対する対策案等の抽出ステップ］
ここでは、一例として、機能要求項目１「予約を閲覧する」と、アーキテクチャ特性項目「仕様の安定性」の組み合わせで、リスク項目とそれに対する対策案等を抽出する場合について説明する。
【００７４】
まず、機能要求項目１「予約を閲覧する」とアーキテクチャ特性項目「仕様の安定性」に定義されている質問であるところの、「機能拡張する可能性があるか」、「動作環境が変更される可能性はあるか」、といったリスクを伴う個々の状況との組み合わせが設計者に対して画面表示される（Ｓ２０２）。この場合、類似リスク検索の支援表示も行われる。これにより、設計者は、必要に応じて類似リスクの検索要求を行い（Ｓ２０３）、過去の作業データから類似したリスクを検索、表示させる（Ｓ２０４）こともできるため、項目の組み合わせやその類似リスク等の画面表示を同時に参照しながら、リスクの検討を容易に行うことができる。
【００７５】
この場合、会議室によっては備えている備品もあり、それらの情報も表示できるようにするかもしれない。あるいは、利用者の指示に応じて、表示する項目数を加減することも考えられる。このような検討に基づき、設計者は、例えば、次のリスク項目を抽出し、その入力操作を行う（Ｓ２０５）。その結果、これらの情報は、コンピュータに入力され、メモリ等にデータとして記録される（Ｓ２０６）。
【表３】
（リスク項目１）：備品等、会議室に応じて表示する情報が異なる
（リスク項目２）：表示する情報が、利用者の希望に応じて異なる
【００７６】
続いて、記録されたリスク項目１、リスク項目２が、前述した非機能要求項目１〜非機能要求項目３と共に設計者に対して画面表示され、リスク項目に対する可能性、許容度、対策案の入力操作の支援が行われる（Ｓ２０７）。そのため、設計者は、リスク項目と非機能要求項目を同時に参照しながら、可能性、許容度、対策案の検討を容易に行うことができ、非機能要求項目を反映させた対策案を効率的に抽出することができる。
【００７７】
例えば、リスク項目１「備品など、会議室に応じて表示する情報が異なる」について可能性を検討すると、会議室に備えられている備品が異なることが一般的と考えられるので、将来的に仕様変更が発生する可能性が高い。また、許容度を検討すると、非機能要求項目１「端末からの操作性」を考慮し、同様の仕様変更が発生したときに、なるべく柔軟に対応できるように作り込んでおくことが望ましいと考えられる。そしてまた、対策案としては、会議室という概念クラスを設け、会議室に関する情報や操作を隠蔽し、他から透過なアクセスができるようにする構成が有効であると考えられる。
【００７８】
設計者は、以上のようなリスク項目の抽出、およびそれに対する対策案等の検討を、機能要求項目１〜機能要求項目３の各々と、各アーキテクチャ特性項目との全ての組み合わせについて行うことにより、各リスク項目に対する可能性、許容度、対策案を抽出し、その入力操作を行う（Ｓ２０８）。その結果、これらの情報は、コンピュータに入力され、メモリ等にデータとして記録される（Ｓ２０９）。この例において、対策案としては、例えば次のような対策案１〜対策案１５が記録される。
【００７９】
【表４】
（対策案１）：「会議室」という概念クラスを設け、透過なアクセスができる構成にする
（対策案２）：「処理依頼」という共通の処理を行える仕組みを設ける
（対策案３）：利用者の操作に関する部分を、他の部分と完全に分離した構成にする
（対策案４）：予約情報をＤＢＭＳで保持してもよいように、データの記録処理を抽象化する構成にする
（対策案５）：ＯＳに依存する部分を分離する
（対策案６）：予約情報等のデータをｅｘｐｏｒｔ可能な仕組みを設ける
（対策案７）：予約情報を多重化して保持できる構成にする
（対策案８）：検索アルゴリズム等を交換可能な構成にする
（対策案９）：従業員ＤＢ等の他のシステムとの連携を考慮する
（対策案１０）：複数の利用者が同時に予約しても整合性が取れる仕組みを設ける
（対策案１１）：データ保持部分をｐｌｕｇ−ｉｎのように変更可能な構成にする
（対策案１２）：会議室や利用者情報を、ｉｍｐｏｒｔできるような仕組みを設ける
（対策案１３）：予約や取り消しの仕方を、利用者が定義できるような仕組みを設ける
（対策案１４）：データ検索部分やデータ保持部分を交換可能な構成を設ける
（対策案１５）：様々なユーザインタフェースを定義できるようにし、予約処理を透過に扱える構成にする
【００８０】
［２−３．対策案の分類整理、重要な対策案の抽出ステップ］
ここでは、上記のように記録された対策案１〜対策案１５を、ＫＪ法等の手法を用いて分類整理する。すなわち、まず、対策案１〜対策案１５のリストが設計者に対して画面表示される（Ｓ３０１）ため、設計者は、現在の作業フェーズで重要な対策案と重要でない対策案を容易に選択することができる（Ｓ３０７）。また、重要な対策案のうち、現在のフェーズで重要な対策案と重要でな相関の高い複数の対策案がある場合には、それらを容易に選択することができる。設計者により統合のそれらの対策案が指定される（Ｓ３０２）と、指定された対策案は、統合対象グループとして並べて画面表示される（Ｓ３０３）ため、設計者は、複数の対策案を同時に参照しながらそれらを包括するような上位の対策案を容易に作成することができる。
【００８１】
設計者によって上位の対策案が作成され、それを元の対策案の代わりとすることが確認される（Ｓ３０４）と、元の対策案は削除され、上位の対策案に置き換えられる（Ｓ３０５）。このような統合作業によって、対策案の数を少なくすることにより、後続の作業を容易にすることができる。なお、この例において対象としている作業範囲は、システム全体に関わる部分であるので、粒度の細かい対策案は現在のフェーズでは考慮すべきでない、すなわち重要でない対策案としてグルーピングし、それ以外の対策案を、重要な対策案としてグルーピングすることになる。例えば、次のような「重要な対策案１」〜「重要な対策案６」が記録される（Ｓ３０８）。
【００８２】
【表５】
（重要な対策案１）：ユーザインタフェースを予約情報処理部分と分離する構成にする
（重要な対策案２）：各プラットフォームで、ユーザインタフェースだけを書き直せばよいようにする
（重要な対策案３）：予約や取り消し、閲覧の方法が変更されてもよいように、「処理依頼」という共通の処理の枠組みを作る
（重要な対策案４）：複数の利用者が同時に処理を依頼しても整合性が取れる仕組みを作る
（重要な対策案５）：予約情報を多重化して保持しておく
（重要な対策案６）：システム内部で、データに対する処理を抽象化する構成にする
【００８３】
［２−４．重要な対策案の関係抽出ステップ］
ここでは、上記のように記録された「重要な対策案１」〜「重要な対策案６」の間の関係を抽出する。すなわち、これらの重要な対策案のリストと関係を表現するシンボルを含む選択画面を設計者に対して画面表示する（Ｓ４０１）ことにより、設計者は、相反、類似、依存、独立、等の観点で対策案間の関係を容易に検討して指定することができる（Ｓ４０２、Ｓ４０４、Ｓ４０６）。設計者によって指定された対策案とその関係は、図７に示すように、画面上でグラフィック画像として表現させる（Ｓ４０３、Ｓ４０５、Ｓ４０７）ことにより、設計者は自らが指定した対策案間の関係を容易に把握、確認することができる。グラフィック画像で表現された関係は、設計者によってその内容が確認された後、「重要な対策案の関係」として記録される（Ｓ４０９）。
【００８４】
なお、図７においては、一例として、重要な対策案を表示するボックスと関係を示すシンボルとしての接続線からなるグラフィック画像表現を示している。すなわち、ボックス間を接続する双方向矢印付きの直線は、各ボックスによって表現される対策案間に相反の関係があることを示しており、ボックス間を接続する矢印のない直線は、各ボックスによって表現される対策案間に類似の関係があることを示している。また、ボックス間を接続する線がない場合には、各ボックスによって表現される対策案が互いに独立の関係であることを示している。なお、ここでは、依存の関係は存在していないため、図示していないが、例えば、依存先に向けた単方向矢印付きの直線で表現すること等が可能である。
【００８５】
［２−５．採用すべき対策案の決定ステップ］
ここでは、記録された「重要な対策案の関係」に基づいて、「重要な対策案１」〜「重要な対策案６」の中から、採用すべき対策案を決定する。すなわち、図７に示すようなグラフィック画像で所定の関係にある対策案を画面表示する（Ｓ５０１、Ｓ５０４、Ｓ５０７、Ｓ５１０）ことにより、設計者は、対象となる関係を有する対策案を容易に対比することができるため、採用する対策案または採用しない対策案を容易に指定する（Ｓ５０２、Ｓ５０５、Ｓ５０８、Ｓ５１１）ことができる。
【００８６】
図７の例においては、相反の関係を有する対策案グループとして、まず、「複数の利用者が同時に処理を依頼しても整合性が取れる仕組みを作る」と、「予約情報を多重化して保持しておく」とを示す各ボックスとその間を接続する双方向矢印付きの直線を表示する（Ｓ５０１）ことにより、設計者は、両方のボックスを比較して、採用しない対策案を容易に指定することができる（Ｓ５０２）。この場合、例えば、コストと重要度の観点から、「予約情報を多重化して保持しておく」を採用しない対策案として指定されたものとする。その結果、この対策案は重要な対策案のリストから削除される（Ｓ５０３）。
【００８７】
次に、類似の関係を有する対策案グループとして、図７に示す他の２組のボックスとその間を接続する直線をそれぞれ表示する（Ｓ５０４）ことにより、設計者は、線で接続された各グループのボックスを比較して、各グループで最も重要な対策案を容易に指定することができる（Ｓ５０５）。この場合、例えば、「システム内部で、データに対する処理を抽象化する構成にする」と「予約や取り消し、閲覧の方法が変更されてもよいように、「処理依頼」という共通の処理の枠組みを作る」のグループについては、後者が指定され、また、「各プラットフォームで、ユーザインタフェースだけを書き直せばよいようにする」と「ユーザインタフェースを予約情報処理部分と分離する構成にする」についてもまた、後者が指定されたものとする。その結果、指定されなかった対策案は重要な対策案のリストから削除される（Ｓ５０６）。
【００８８】
この例では、以上の作業だけで対策案の取捨選択が終了する（Ｓ５１３）ため、削除されずに残った３つの対策案が、次のように、「採用すべき対策案１」〜「採用すべき対策案３」として記録される（Ｓ５１４）。
【表６】
（採用すべき対策案１）：複数の利用者が同時に処理を依頼しても整合性が取れる仕組みを作る
（採用すべき対策案２）：予約や取り消し、閲覧の方法が変更されてもよいように、「処理依頼」という共通の処理の枠組みを作る
（採用すべき対策案３）：ユーザインタフェースを予約情報処理部分と分離する構成にする
【００８９】
［２−６．対策案を実現する構成と動作原理の抽出、統合ステップ］
ここでは、記録された「採用すべき対策案」に基づいて、その対策案の全てを実現する構成と動作原理を抽出し、統合することにより、ソフトウェアアーキテクチャを構築する。すなわち、まず、記録された「採用すべき対策案１」〜「採用すべき対策案３」のリストを画面表示する（Ｓ６０１）ことにより、設計者は、対象となる対策案を容易に対比することができるため、優先順位を容易に指定する（Ｓ６０２）ことができる。この例では、例えば、次のような優先順位が付けられる。
【００９０】
【表７】
（採用すべき第１の対策案）：予約や取り消し、閲覧の方法が変更されてもよいように、「処理依頼」という共通の処理の枠組みを作る
（採用すべき第２の対策案）：ユーザインタフェースを予約情報処理部分と分離する構成にする
（採用すべき第３の対策案）：複数の利用者が同時に処理を依頼しても整合性が取れる仕組みを作る
【００９１】
このように優先順位が指定されると、設計者に対して、その優先順位に応じて対策案が順次表示されると共に、既存のパターンや過去の作業データ等に対する情報検索の支援表示も行われる（Ｓ６０３）。これにより、設計者は、必要に応じて既存のパターンや過去の作業データの検索要求を行い（Ｓ６０４）、それらの情報を検索、表示させる（Ｓ６０５）こともできるため、各対策案と既存のパターンや過去の作業データ等を同時に参照しながら、その対策案を実現する構成や動作原理を容易に検討することができる。この例では、各対策案について、例えば、次のような検討が行われる。
【００９２】
「採用すべき第１の対策案」については、デザインパターンのＶｉｓｉｔｏｒパターン（Ｅ．ガンマ 他著、本位田真一 他監訳、オブジェクト指向における再利用のためのデザインパターン改訂版、1999.11,ISBN4-7973-1112-6）を適用することが有効と思われる。依頼処理をＶｉｓｉｔｏｒとし、これがあらゆる依頼を表現し、依頼に対する処理を隠蔽することで、利用者からのあらゆる依頼を、共通に扱えるようにできる。また、これをオブジェクトとすることで、ネットワークを介した予約処理も、透過に扱うことができる。
【００９３】
「採用すべき第２の対策案」については、ユーザインタフェースを司る部分を設け、これが上記依頼処理に処理を委譲するという構成にすることで、実現することができる。
「採用すべき第３の対策案」については、複数の依頼処理が発生しても、実際に処理を開始できる権限を与える部分が、システム全体で１つだけ存在する構成にすることで対応できると考えられる。全ての予約情報という１つのブロックを設け、これに依頼処理が処理を開始する権限を与えられるようにすれば、十分である。
【００９４】
設計者が、このような各対策案についての検討結果を統合した構成、動作原理の入力操作を行うことにより、これらの構成、動作原理は、ソフトウェアアーキテクチャを構築する情報として、メモリ等に記録される（Ｓ６０３〜Ｓ６１０）。この例では、構築されたソフトウェアアーキテクチャをＵＭＬで記述すると、図８に示すようになる。また、ソフトウェアアーキテクチャの構成要素である各クラスの役割の定義は、次のようになる。
【００９５】
【表８】
（画面）：利用者からの操作を受け付け、その結果を利用者に提示する役割がある。利用者の操作を反映した処理依頼オブジェクトを生成し、処理を処理依頼オブジェクトに委譲し、依頼結果を、画面を通して利用者に提示する。
（処理依頼）：利用者の操作に応じた要求を保持し、その要求に応じて、予約情報を操作する。
（予約情報）：会議室や利用者、予約等の情報を保持する。処理依頼オブジェクトだけが操作でき、また、処理依頼オブジェクトへ操作の権利を与えることができる。
【００９６】
このソフトウェアアーキテクチャで、前述した機能要求項目や非機能要求項目を実現できることを確認できるため、これを構築したソフトウェアアーキテクチャとして記録する（Ｓ６１１、Ｓ６１２）。なお、この例では、３つの比較的シンプルな対策案だけを示しているため、構成、動作原理の統合も一度に可能であるが、実際には、多数の対策案が存在する場合がほとんどであり、各対策案について、構成や動作原理の抽出や統合が順次行われる。
【００９７】
［２−７．本手法で構築されたソフトウェアアーキテクチャ］
上記のステップで記録されたソフトウェアアーキテクチャは、３つの構成要素から構成されており、それぞれの構成要素について詳細化可能である（Ｓ１７０）ため、各構成要素を対象に、ステップＳ１１０〜Ｓ１６０を繰り返す。２回目の繰り返しステップにおいて、機能要求項目は、上記のステップＳ１６０で定義した役割を元に、改めて詳細を検討することになる。この例では、各構成要素について各ステップを繰り返し、ソフトウェアアーキテクチャを統合することにより、最終的に、図９に示すソフトウェアアーキテクチャが得られる。このソフトウェアアーキテクチャの構成要素である各クラスの役割の定義は、次のようになる。
【００９８】
【表９】
（会議室）：会議室固有の情報を保持する。会議室固有の情報とは、１つの会議室の、名前、場所、収容人数、設備等である。
（利用者）：利用者固有の情報を保持する。利用者固有の情報とは、名前、所属、役職等である。
（予約）：予約情報を保持する。予約情報とは、予約した会議室（会議室オブジェクト）と、予約者（利用者オブジェクト）、予約日時である。
（日時）：日時情報を保持する。日時情報とは、特定の日の特定の時間帯、毎週水曜日の特定の時間帯、等、日時に関するあらゆる表現を可能とする。必ず、新たな予約が発生すると共に、日時オブジェクトが作られる。このオブジェクトによって、予約の、日時に関する情報を表現する。
（依頼窓口）：依頼オブジェクトを受け付け、予約、会議室、利用者、の各オブジェクトに対する操作権を決定する。依頼窓口オブジェクトは、１システムに１つだけ存在する。分散環境のための、代理窓口という役割も持つ。依頼窓口オブジェクトが、予約オブジェクトを生成したり、操作したりすることはない。
（依頼）：利用者からの依頼内容と、それに応じた処理を表現するための抽象クラスである。依頼内容とは、会議室の予約や取り消しに関する情報である。処理とは、予約、会議室、利用者、の各オブジェクトの生成、変更、削除、検索等である。この派生クラスに、具体的な依頼とその処理手順を示したクラス群が存在する。
（依頼結果）：依頼によって行われた処理の結果を表現するための抽象クラスである。結果とは、依頼の成功、失敗や、その詳細等である。依頼結果オブジェクトは、それが利用者にどのように提示されるかは知らない。この派生クラスに、具体的な依頼結果を表現したクラス群が存在する。
（画面）：利用者からの操作を受け付け、その結果を利用者に提示する。利用者の操作に応じて、適切な依頼オブジェクトを生成し、これを依頼窓口オブジェクトに渡す。依頼結果オブジェクトを受け取り、その内容を利用者に画面を通して提示する。
【００９９】
この本手法により構築されたソフトウェアアーキテクチャ上で、典型的な処理の流れは、次のようになる。
（１）画面オブジェクトは、利用者の要求を受け付け、その内容に見合った依頼オブジェクトを生成し、これを依頼窓口オブジェクトに渡す。
（２）依頼窓口オブジェクトは、受け取った依頼オブジェクトに、予約、会議室、利用者、の各オブジェクトに対するアクセス権を与えると共に、これらのオブジェクトへの操作を委譲する。
（３）依頼オブジェクトは、自身が保持する依頼内容にしたがって、予約、会議室、利用者、の各オブジェクトを操作し、その結果として、適切な依頼結果オブジェクトを生成する。
（４）依頼結果オブジェクトは、依頼窓口オブジェクトを経由して、画面オブジェクトに渡し、画面オブジェクトは、依頼結果オブジェクトが保持する情報にしたがって、利用者に結果を提示する。
【０１００】
［２−８．従来手法で構築されたソフトウェアアーキテクチャ］
ここでは、本手法と比較するために、顧客からの上記の要求１〜要求６に対して、従来手法でソフトウェアアーキテクチャを構築した場合について、説明する。
まず、予約については、日時、時間帯、会議室を指定して行う仕様となっており、また、閲覧は、会議室を指定して行う仕様となっている。したがって、「特定の会議室」に、「予約した利用者」と、「日付と時間帯」に関する情報を付加して記録すれば十分である。
【０１０１】
キャンセルは、利用者の予約を指定する仕様なので、上記の情報が特定できれば十分である。
また、実際の依頼処理は、予約、キャンセル、閲覧で、それぞれが具体的に行う処理を仕様として定めることができる。
したがって、従来手法によれば、図１０に示すようなソフトウェアアーキテクチャで、顧客要求を満足することができる。この従来手法で構築されたソフトウェアアーキテクチャの各クラスの定義は、次のようになる。
【０１０２】
【表１０】
（会議室）：会議室固有の情報を保持する。会議室固有の情報とは、１つの会議室の、名前、場所、収容人数、設備等である。この会議室に対する予約リストを保持する。
（利用者）：利用者固有の情報を保持する。利用者固有の情報とは、名前、所属、役職等である。
（予約）：予約情報を保持する。予約情報とは、予約した会議室（会議室オブジェクト）と、予約者（利用者オブジェクト）、予約日時である。
（依頼窓口）：依頼内容を受け付け、予約、会議室、利用者、の各オブジェクトに対する操作を行う。操作とは、予約、会議室、利用者、の各オブジェクトの生成、変更、削除、検索等である。依頼窓口オブジェクトは、１システムに１つだけ存在する。分散環境のための、代理窓口という役割も持つ。
（画面）：利用者からの操作を受け付け、その結果を利用者に提示する。利用者の操作に応じて、その内容を依頼窓口オブジェクトに渡す。依頼結果の内容を受け取り、その内容を画面を通して利用者に提示する。
【０１０３】
この従来手法により構築されたソフトウェアアーキテクチャ上で、典型的な処理の流れは、次のようになる。
（１）画面オブジェクトは、利用者の操作を受け付け、その内容を依頼窓口オブジェクトに渡す。
（２）依頼窓口オブジェクトは、予約、会議室、利用者、の各オブジェクトに対するアクセス権を調整し、受け取った内容にしたがって、これらのオブジェクトを操作する。
（３）依頼窓口オブジェクトは、依頼結果の内容を画面オブジェクトに渡し、画面オブジェクトは、受け取った依頼結果の内容にしたがって、利用者に結果を提示する。
【０１０４】
［２−９．本手法と従来手法で構築されたソフトウェアアーキテクチャの比較］以下には、本手法によって構築された図９のソフトウェアアーキテクチャと、従来手法によって構築された図１０のソフトウェアアーキテクチャにおいて、仕様変更が発生した場合の対応について具体的に比較する。
ここでは、一例として、「この先３ヶ月間、毎週水曜日の１３時〜１５時、場所はどこでもよいから予約する」等の、複雑な処理を行えるようにする仕様変更が発生した場合を想定する。
【０１０５】
まず、本手法で構築したソフトウェアアーキテクチャの場合、次のように容易に対応することができる。
（１）依頼の仕方が追加、変更されるのであるから、それを表現するクラス、つまり、依頼、依頼結果の抽象クラスの派生クラスの追加、変更を行えばよいことが、容易に導き出される。
（２）実際の追加、変更も、日時オブジェクトを予約ごとに作っているので、必要に応じて日時クラスの変更、あるいは派生クラスの追加、を行うことで、依頼クラスの追加、変更にも容易に対応できる。
（３）各クラスの変更は、他のクラスに影響を与えない。
（４）画面クラスの変更は、依頼処理と分離してあるので、他との影響を考慮することなく、独立して修正することができる。
【０１０６】
これに対して、従来手法で構築したソフトウェアアーキテクチャの場合、次のように、仕様変更への対応が困難である。
（１）依頼に関する操作を、依頼窓口クラスが単独で全て担っているので、依頼窓口クラスの内部を大幅に変更する必要がある。
（２）仕様変更の大きさにより、依頼窓口クラスの変更が大がかりになったり、依頼窓口のインタフェースにも影響を与えることが考えられる。したがって、画面クラスにも大きな変更を行う必要性が生じる。
（３）日時を、予約クラスの内部属性としているので、場合によっては予約クラスにも影響が及ぶことになる。
【０１０７】
［３．実施形態の効果］
以上のように、本実施形態の手法によって構築したソフトウェアアーキテクチャは、仕様変更に対応しやすいだけでなく、潜在的な顧客の要求も引き出した上でソフトウェアアーキテクチャを構築することができるので、ソフトウェア開発のトータルコストを下げ、顧客満足度の高いソフトウェアを開発できるようにすることができる。また、本手法における特徴的な各ステップの効果は次の通りである。
【０１０８】
まず、リスク項目とそれに対する対策案等の抽出ステップの効果は次の通りである。すなわち、各機能要求項目についてアーキテクチャ特性項目を個別に対比させることにより、その対比結果に基づいて機能要求項目の実現に大きく影響するかあるいは実現を困難にするリスク項目を抽出することができる。特に、過去の作業データ等の検索、提示も行うことにより、過去のデータを利用してリスク項目をより容易に抽出することができる。そして、抽出された各リスク項目について非機能要求項目を個別に対比させることにより、その対比結果に基づいて機能要求だけでなく非機能要求をも反映させた対策案を効率的に抽出することができる。したがって、このステップによって得られた対策案を採用することにより、多様な非機能要求を設計の根拠として設計に反映させることができる。
【０１０９】
次に、対策案の分類整理、重要な対策案の抽出ステップにおいては、機能要求および非機能要求を反映させた複数の対策案を分類整理して、相関の高い複数の対策案を上位の対策案に統合する等の作業を行い、機能要求項目群や現在の作業範囲、作業フェーズ等の詳細度、具体度等によって決定される現時点での重要性の高い対策案を抽出している。したがって、このステップによれば、後続するステップにおいて対象とする対策案を、より少ない数の重要な対策案のみに限定することができる。
【０１１０】
また、重要な対策案の関係抽出ステップによれば、重要な対策案の相反、類似、依存、独立の各関係を順次抽出することができるため、対策案の採用に影響する全ての関係を効率的に抽出することができる。特に、対策案とその関係をグラフィック画像として表示することにより、関係の把握、確認を容易に行うことができ、作業効率をさらに高めることができる。
【０１１１】
そしてまた、採用すべき対策案の決定ステップにおいては、所定の関係を有する対策案のグループごとに対策案の取捨選択を順次行うことにより、対策案の数を効率的に絞り込むことができる。この場合にも、関係抽出ステップと同様に、対策案とその関係をグラフィック画像として表示することにより、対策案の関係の把握やそれに基づく対策案の取捨選択を容易に行うことができる。このステップにおいては、最初に、相反の関係をなくすような取捨選択を行うことにより、相反の関係にある一方の対策案を除去すると共に、その対策案と類似の関係にある対策案や依存する対策案を機械的に削除することができる上、さらに、残った対策案の中から、類似や依存の関係に応じて、適切な取捨選択を行いながら、対策案の数を大幅に少なくすることができる。したがって、採用すべき対策案の決定効率を高めると共に、後続作業の効率を高めることができる。
【０１１２】
また、対策案を実現する構成と動作原理の抽出、統合ステップにおいては、機能要求および非機能要求を反映させた、絞り込まれた数の「採用すべき対策案」を、その優先順に提示することにより、効率的に構成と動作原理を抽出、統合して、効率的にソフトウェアアーキテクチャを構築することができる。特に、既存のパターンや過去の作業データ等の検索、提示も行うことにより、それらの情報を利用して、構成と動作原理の抽出をより容易に行うことができる。
【０１１３】
さらに、構築したソフトウェアアーキテクチャの構成要素が、実装環境に依存せずにその詳細を検討できるような場合には、各構成要素を対象に、一連のステップを繰り返すことにより、詳細度をより高めたソフトウェアアーキテクチャを効率的に構築することができる。
【０１１４】
［４．他の実施形態］
なお、本発明は、前述した実施形態に限定されるものではなく、本発明の範囲内で他にも多種多様な形態が実施可能である。
【０１１５】
［４−１．既存のデータの自動提示、候補としての利用］
例えば、前記実施形態において、リスク項目を抽出する際には、検索要求に応じて過去の作業データから類似したリスクを検索し、提示するようにしたが、検索要求なしに自動的に提示したり、あるいは、提示した既存のリスク項目を候補としてリスク項目を選択させたりすること等も可能である。この場合には、設計者は、既存のリスク項目にないリスク項目のみを作成すればよいため、リスク項目の抽出効率を大幅に向上することができる。
【０１１６】
また、対策案を実現する構成と動作原理の抽出の際における既存のパターンや過去の作業データについても同様にそれらの情報を自動提示したり、候補として選択させたりすることにより、構成と動作原理の抽出効率を大幅に向上することができる。さらに、このような、既存のデータの自動提示やそれを候補として選択させる等の支援表示を行う手法は、リスク項目に対する対策案を抽出する際にも同様に適用可能であり、同様の効果が得られるものである。
【０１１７】
そしてまた、機能要求項目や非機能要求項目を入力する際にも、過去のデータに基づいて予め用意した機能要求項目の候補や非機能要求項目の候補を提示して、設計者に選択させることも可能である。この場合にも、候補が存在しない要求項目を作成するだけで、顧客等の要求に応じた全ての要求項目を効率的に入力することができる。
【０１１８】
［４−２．予め用意した基準値による数の削減］
一方、前記実施形態においては、設計者が作成した全てのリスク項目をそのまま記録して、各リスク項目に対する対策案等を抽出するようにしたが、過去の作業データ等を利用して、リスク項目による機能要求項目の実現に対する影響度に関する基準値を予め設定し、その基準値以上のリスク項目を抽出すること等も可能である。
【０１１９】
例えば、候補として得られたリスク項目の影響度に応じて、影響度が極めて高いものを「影響度Ａ」、それ以外のものを「影響度Ｂ」として、影響度Ａのリスク項目のみを機械的に抽出し、影響度Ｂのリスク項目を除去することにより、記録するリスク項目の数を自動的に少なくできる。その結果、リスク項目の抽出効率を高めると共に、後続作業の効率を高めることができる。また、変形例として、「影響度Ｂ」のリスク項目については、自動的に削除せずに、そのリストを一旦設計者に提示して残すリスク項目を選択させるようにしてもよい。
【０１２０】
同様に、対策案についても、過去の作業データ等を利用して、非機能要求項目の満足度に関する基準値を予め設定し、その基準値以上の対策案を抽出すること等が可能である。この場合には、候補として得られた対策案の中から、非機能要求項目の満足度が基準値以上の対策案のみを機械的に抽出し、満足度の低い対策案を除去することにより、抽出する対策案の数を自動的に少なくできる。その結果、対策案の抽出効率を高めると共に、後続作業の効率を高めることができる。また、変形例として、満足度の低い対策案については、自動的に削除せずに、そのリストを一旦設計者に提示して残す対策案を選択させるようにしてもよい。
【０１２１】
また、抽出された対策案の中から、現時点で重要な対策案を決定する際にも、同様に、過去の作業データ等を利用して、対策案の現時点での重要度に関する基準値を作業フェーズ等に応じて予め設定し、その基準値以上の対策案を重要な対策案として抽出すること等が可能である。この場合には、機能要求および非機能要求に基づいて得られた対策案の中から、現時点での重要度が基準値以上の対策案のみを機械的に抽出し、重要度が比較的低い対策案を除去することにより、抽出する重要な対策案の数を自動的に少なくできる。
【０１２２】
この場合、特に、相反や類似等の所定の関係を有する対策案の各グループごとにグループ内の各対策案の現時点での重要度を比較し、重要度の高低に応じて取捨選択を行うことにより、設計要件の数を自動的にさらに少なくできる。その結果、重要な対策案の抽出効率を高めると共に、後続作業の効率を高めることができる。また、変形例として、重要度が比較的対策案については、自動的に削除せずに、そのリストを一旦設計者に提示し、重要な対策案として残す対策案を選択させるようにしてもよい。
【０１２３】
［４−３．自動化の推進］
なお、上述したような各種の基準値による評価対象となる「リスク項目による機能要求項目の実現に対する影響度」、「対策案による非機能要求項目の満足度」、「現時点での対策案の重要度」、等は、リスク項目や対策案の作成時に設計者によって段階評価値等を与えることが考えられる。あるいはまた、過去の作業データ等に基づいて、それらの影響度、満足度、影響度等を表現する値を算出するためのアルゴリズムを作成して、自動的に求めること等も考えられる。
【０１２４】
同様に、前記実施形態において、設計者による検討対象として記載した各部分は、関連する各種のデータと、各種の統計手法や解析手法等とを有機的に組み合わせることにより、コンピュータによる対象の自動判定や自動抽出を行うことが可能である。そのような自動化を進めることにより、機能要求項目と非機能要求項目の自動的な分類、入力、リスク項目等の事象とそれに対する対策案等の設計要件の自動抽出、重要な対策案の自動選択とその関係の自動抽出、採用すべき対策案の自動決定、採用すべき対策案を満足するソフトウェアアーキテクチャの自動構築、等が可能となる。したがって、本発明の手法は、最終的には、顧客等からの要求を入力しただけで、機能要求および非機能要求を反映させた設計要件を自動的に抽出し、そのような設計要件を満足するソフトウェアアーキテクチャを自動的に構築できるようにするものである。
【０１２５】
【発明の効果】
以上説明したように、本発明によれば、各機能要求項目についてソフトウェア設計上で考慮すべき特性を個別に対比させることで機能要求項目の実現に影響する事象を抽出し、各事象について非機能要求項目を個別に対比させることで、機能要求だけでなく非機能要求をも反映させた設計要件を効率的に抽出できるようにしたことにより、多様な非機能要求を設計の根拠として設計に反映可能なソフトウェア設計要件抽出支援方法を提供することができる。
【０１２６】
また、本発明によれば、機能要求および非機能要求を反映させた設計要件を分類整理して重要な設計要件のみに限定し、採用すべき設計要件を効率的に決定可能なソフトウェア設計要件決定支援方法、および、機能要求および非機能要求を反映させた設計要件に基づいて、多様な外的変動に対応可能なソフトウェアアーキテクチャを効率的に設計可能なソフトウェア設計支援方法、を提供することができる。
【図面の簡単な説明】
【図１】本発明を適用したソフトウェア設計支援方法の概要をデータの流れと共に示すフローチャート。
【図２】図１に示す方法において、リスク項目とそれに対する対策案等の抽出ステップの詳細をデータの流れと共に示すフローチャート。
【図３】図１に示す方法において、対策案の分類整理、重要な対策案の抽出ステップの詳細をデータの流れと共に示すフローチャート。
【図４】図１に示す方法において、重要な対策案の関係抽出ステップの詳細をデータの流れと共に示すフローチャート。
【図５】図１に示す方法において、採用すべき対策案の決定ステップの詳細をデータの流れと共に示すフローチャート。
【図６】図１に示す方法において、対策案を実現する構成と動作原理の抽出、統合ステップの詳細をデータの流れと共に示すフローチャート。
【図７】図１に示す方法によって抽出された重要な対策案の関係の一例を示すデータ表示図。
【図８】図１に示す方法によって構築されたソフトウェアアーキテクチャの一例を示す構造図。
【図９】図８に示すソフトウェアアーキテクチャの詳細度をさらに高めたソフトウェアアーキテクチャの一例を示す構造図。
【図１０】従来手法によって構築されたソフトウェアアーキテクチャの一例を示す構造図。
【図１】
0003887571.tif 000002
【図２】
0003887571.tif 000003
【図３】
0003887571.tif 000004
【図４】
0003887571.tif 000005
【図５】
0003887571.tif 000006
【図６】
0003887571.tif 000007
【図７】
0003887571.tif 000008
【図８】
0003887571.tif 000009
【図９】
0003887571.tif 000010
【図１０】
0003887571.tif 000011