JP2006209660A - ソフトウェア開発支援装置およびソフトウェア開発支援用プログラム - Google Patents

Abstract

【課題】ソフトウェア開発の初期の時点で、開発の優先順位の高い機能を高精度に判定して、ソフトウェアの開発期間の短縮および開発の負荷の軽減を図ることが可能なソフトウェア開発支援装置を提供することを目的とする。
【解決手段】本発明に係るソフトェア開発支援装置１００は、機能設計書の機能の分割に不具合がないか否かを検証する機能分割検証部１１２と、機能設計書の各機能の重要性判断の基準となる機能特性を設定する機能特性設定部１１３と、各機能毎に、機能特性設定部１１３で設定された機能特性に評価点を設定し、各機能毎に設定された機能特性の評価点を合計してその合計点を算出する機能評価部１１４と、機能のならびの一覧を作成し、機能のならび毎に、機能のならびを構成する各機能の合計点に基づいて重要度を演算し、機能のならびの幹枝を判定する幹枝判定部１１５とを備えている。
【選択図】図２

Description

本発明は、ソフトウェア開発支援装置およびソフトウェア開発支援用プログラムに関し、詳細には、ソフトウェア開発の優先順位の高い機能と低い機能を分離することが可能なソフトウェア開発支援装置およびソフトウェア開発支援用プログラムに関する。

ソフトウェアの開発は、一般に、要件定義工程、設計工程（外部設計工程、システム構造設計工程、プログラム設計工程）、製造工程（プログラミング工程、プログラムテスト工程）、テスト工程（結合テスト工程、システムテスト工程、運用テスト工程）からなる。従来、ソフトウェア開発手法としては、例えば、（１）ウォータフォール型、（２）スパイラル型、（３）プロトタイプ型がある。

（１）ウォータフォール型は、最初に全ての仕様を明確にし、全体の作業計画を立ててソフトウェアを開発する手法である。（２）スパイラル型は、最初に依頼者が目で確認できるような大まかな仕様を定めて開発する手法であり、最初の確認での改良事項や、まだ実現していない機能について仕様を定めこれを開発し、依頼者に確認する。以後、これを繰り返し、仕様をまとめていく。（３）プロトタイプ型は、依頼者の要求に見合う事項を擬似的に実現するソフトウェア（以後、これをプロトタイプと呼ぶ）を開発する手法である。これを依頼者と確認し、詳細にわたる仕様を定め開発する。

しかしながら、上記各手法は、以下の如き問題がある。（１）ウォータフォール型は、最初に全ての仕様を明確にする必要があるため、仕様が明確になるまでは開発作業が開始できないという問題がある。また、最後にならないと依頼者が機能等を確認することができないという問題もある。すなわち、依頼者の機能追加や変更が発生すると開発作業の計画見直しが必要で、大きな作業が発生するという問題がある。

（２）スパイラル型は、依頼者に確認を行うたびに仕様が変わることが多く、場合によっては、それまで開発した部分までも修正しなければならなくなるという問題がある。また、確認頻度を上げ、依頼者との合意をこまめに行えば最後になって大きな変更は出にくくなるが、開発者の作業負担が大きくなり、開発効率が下がるという問題がある。

（３）プロトタイプ型は、依頼者の要求事項をおおまかに実現するだけのもの（たとえば、性能やセキュリティの考慮等は含まれない）で、依頼者との確認時には補足説明や別途作成する資料等で依頼者の要求事項を満足することを保証する。このプロトタイプで依頼者と仕様について確認できた時点で、開発計画を立てて開発を行うが、プロトタイプの開発量が大きいと開発者の負担が増大するという問題がある。

以上から、（１）依頼者が早期に動作確認でき、（２）開発者の負担を増やすことなく、（３）依頼者の要求する仕様が最初に明確になっていなくても開発作業を進めることが可能なソフトウェア開発の支援ツールが望まれている。ソフトウェア開発の支援ツールとしては、例えば、特許文献１が公知である。しかしながら、特許文献１の方法では、開発の優先順位の高い機能を高精度に判定することができないという問題がある。

特開平１０−３０７７１８号公報

本発明は、上記に鑑みてなされたものであって、ソフトウェア開発の初期の時点で、開発の優先順位の高い機能を高精度に判定して、ソフトウェアの開発期間の短縮および開発の負荷の軽減を図ることが可能なソフトウェア開発支援装置およびソフトウェア開発支援用プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、開発対象のソフトウェアを各機能に分割し、かつ、機能間の呼び出し関係を記述した機能設計書を作成または入力する機能設計書入力手段と、各機能の重要性判断の基準となる機能特性を設定する機能特性設定手段と、前記機能設計書の各機能毎に前記設定された機能特性の評価点を設定し、当該各機能毎に前記設定された機能特性の評価点を合計して合計点を算出する機能評価手段と、前記機能設計書で記述された機能間の呼び出し関係に応じた機能のならびの一覧を作成し、当該機能のならび毎に、機能のならびを構成する各機能の前記合計点に基づいて、その重要度を算出する判定手段と、を備えたことを特徴とする。

これによれば、各機能の重要性判断の基準となる機能特性を設定し、各機能毎に、設定された機能特性の評価点を設定し、当該各機能毎に機能特性の評価点を合計して合計点を算出し、さらに、機能のならび毎に、機能のならびを構成する各機能の合計点を演算してその重要度を算出しているので、機能のならび毎に重要度を算出でき、高精度に機能の優先順位を判定することができる。

また、本発明の好ましい態様によれば、前記機能設計書の機能毎に、他の機能との呼び出し関係、前記機能特性の評価点、および当該機能特性の評価点を合計した合計点が格納されるデータ構造体を記憶する記憶手段を備え、前記機能設計書入力手段は、前記機能設計書で記述される機能間の呼び出し関係に基づいて、前記データ構造体に、前記機能毎に、前記他の機能との呼び出し関係を格納し、前記機能評価手段は、前記データ構造体に、各機能毎に前記機能特性の評価点を格納するとともに、当該機能毎に、格納された機能特性の評価点を合計した合計点を格納し、前記判定手段は、前記データ構造体を参照して、前記機能のならびの一覧を作成するとともに、当該機能のならび毎に、機能のならびを構成する各機能の前記合計点を演算してその重要度を算出することが望ましい。これによれば、簡単な方法で高精度に機能の優先順位を判定することができる。

また、本発明の好ましい態様によれば、前記判定手段は、前記機能のならびの重要度が基準値以上の場合には、幹と判定し、基準値未満の場合には、枝と判定することが望ましい。これによれば、機能を「幹」と「枝」に分離して、ソフトウェア開発を行うことができる。

また、本発明の好ましい態様によれば、前記機能設計書に記述された機能の分割に不具合がないか否かを検証する機能分割検証手段と、を備えたこととしたので、機能の分割の仕方に不具合がある場合には、機能の分割を修正することができる。

また、本発明の好ましい態様によれば、前記機能分割検証手段は、前記機能設計書に記述された機能の関係を階層構造で記述し、第ｎ階層にある各機能の分割数が所定範囲内に有るか否かを判定し、前記分割数が前記所定範囲外にある機能に関して、その旨を表示手段に表示することが望ましい。これによれば、設計者は、不具合のある機能を容易に識別することができる。

本発明によれば、重要性判断の基準となる機能特性を複数設定し、分割した各機能毎に設定された機能特性の評価点を設定し、当該各機能毎に機能特性の評価点を合計して合計点を算出し、さらに、機能のならび毎に、機能のならびを構成する各機能の合計点を演算してその重要度を算出しているので、機能のならび毎に重要度を算出して、高精度に機能の優先順位を判定することができ、ソフトウェア開発の期間の短縮および負荷の軽減を図ることが可能なソフトウェア開発支援装置およびソフトウェア開発支援用プログラムを提供することが可能になるという効果を奏する。

以下に添付図面を参照して、この発明にかかるソフトウェア開発支援装置およびソフトウェア開発支援用プログラムの最良な実施の形態を詳細に説明する。この実施の形態によりこの発明が限定されるものではない。また、下記実施の形態における構成要素には、当業者が容易に想定できるものまたは実質的に同一のものが含まれる。

（実施の形態）
［用語の定義］
本明細書で使用する「用語」について説明する。（１）「依頼者」とは、ソフトウェアの開発を企画し、開発を依頼（発注）する者をいう。（２）ソフトウェアの開発は、要件定義・設計・製造・テストの作業を経て完成する。「工程」とは、この作業の区切りをいい、各工程は更に細分化した工程で構成されることもある。

（３）「機能」とは、依頼者が企画した内容を実現するためのソフトウェアを、データの処理内容から複数に分解し、その１つ１つを機能という。分解の仕方により１つのソフトウェアであっても機能の数が異なることもあるが、本明細書ではどのような分解であってもよい。（４）「機能のならび」とは、各機能の関係を示すものをいう。機能は単独で存在するのではなく、他の機能から呼び出される、または、他の機能を呼び出す。機能間の呼び出しをつなげると「機能のならび」ができる。例えば、機能Ａが機能Ｂと機能Ｃを呼び出し、機能Ｂが機能Ｄを呼び出すとする。このとき、機能のならびとしては機能Ａ−機能Ｂ−機能Ｄと機能Ａ−機能Ｃがある。（５）「機能特性」とは、機能の持つ重要度を測るために設定する測定可能な事項をいう。（６）「幹」とは、ソフトウェア開発の優先順位の高い主要部分をいい、「枝」とは、ソフトウェア開発の優先順位が低い周辺部分をいう。

［ソフトウェア開発の概略］
図１は、本実施の形態に係るソフトウェア開発の概略説明図である。図１において、まず、依頼者との商談で全体業務構想の要件定義について契約を行う（契約１工程Ｓ１）。つぎに、業務仕様について概略設計を行った後、開発の優先順位の高い「幹」と優先順位の低い「枝」の切り分けを行う（要件定義工程Ｓ２）。そして、依頼者との商談で「幹」と「枝」についての契約を行う（契約２工程Ｓ３）。この後、「幹」の開発（ＥＤ（Ｅｘｔｅｎｔ Ｄｅｓｉｇｎ：外部設計）〜ＯＴ（Ｏｐｅｒａｔｉｏｎａｌ Ｔｅｓｔ）を行う（幹の開発工程Ｓ４）。「幹」の開発後、「幹」の部分の稼働を行い（本稼働１工程Ｓ５）、「幹」の検証と「枝」の見直しを行う（評価工程Ｓ６）。その後、「枝」の開発（ＥＤ〜ＯＴ）を行う（枝の開発工程Ｓ７）。「枝」の開発終了後、「幹」と「枝」を統合してソフトウェア全体の稼働を行う（本稼働２工程Ｓ８）。

以上のように、ソフトウェア開発の初期の時点で、開発の優先順位の高い「幹」と優先順位の低い「枝」の切り分けを行い、「幹」の開発を行った後に、「枝」の開発を行っているので、上流工程で基幹機能の確定と絞り込みを行ってこれら機能の早期確認を行うことが可能となると共に、各工程で各機能の確認／修正を実現して開発期間の短縮と開発の負荷を低減することが可能となる。

［ソフトウェア開発支援装置およびソフトウェア開発支援用プログラム］
図２は、上記要件定義工程Ｓ２を実施するためのソフトウェア開発支援装置１００の構成を示す図である。ソフトウェア開発支援装置１００は、ＣＰＵなどの制御装置１１０と、キーボード、マウス、およびスキャナなどの入力装置１２０と、ＬＣＤ、有機ＥＬ、ＰＤＰ、およびＣＲＴなどの表示装置１３０と、プリンタなどの印刷装置１４０と、ＲＡＭなどの主記憶装置１５０と、ＨＤＤ、ＣＤドライブ装置などの記憶装置１６０と、を備えており、通常のコンピュータを利用したハードウェア構成となっている。

制御装置１０１は、開発対象のソフトウェアを各機能に分割し、機能間の呼び出し関係を記述した機能設計書を作成・編集・入力する機能設計書作成・編集部１１１（機能設計書入力手段）と、機能設計書の機能の分割に不具合がないか否かを検証する機能分割検証部１１２（機能分割検証手段）と、機能設計書の各機能の重要性判断の基準となる機能特性を設定する機能特性設定部１１３（機能特性設定手段）と、各機能毎に、機能特性設定部１１３で設定された機能特性の評価点を設定し、各機能毎に設定された機能特性の評価点を合計してその合計点を算出する機能評価部１１４（機能評価手段）と、機能のならびの一覧を作成し、機能のならび毎に、機能のならびを構成する各機能の合計点に基づいて重要度を演算し、機能のならびの幹枝を判定する幹枝判定部１１５（判定手段）として機能する。

記憶装置１６０は、各種データを格納するものであり、機能設計書データ１６１、評価表リスト１６２等を格納する。評価表リスト１６２（データ構造体）は、機能のならびの「幹」、「枝」を判定する場合に使用されるものであり、機能設計書の各機能毎に作成される。図３は、評価表リスト１６２のフォーマットの一例を示す図である。評価表リスト１６２は、図３に示すように、機能名、機能説明、呼び出し先アドレス１〜ｋ、読み出し元アドレス１〜ｍ、設定される機能特性１〜ｎの評価点（点数）、および評価点の合計点のデータを格納するエリアを備えている。なお、データ構造体の形態は、リスト形式に限られるものではなく、例えば、表形式としてもよい。

本実施の形態のソフトウェア開発支援装置１００で実行されるソフトウェア開発支援用プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。また、本実施形態のソフトウェア開発支援装置１００で実行されるソフトウェア開発支援用プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態のソフトウェア開発支援装置１００で実行されるソフトウェア開発支援用プログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。また、本実施の形態のソフトウェア開発支援用プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

上記ソフトウェア開発支援装置１００で実行されるソフトウェア開発支援用プログラムは、上述した各部（機能設計書作成・編集部１１１、機能分割検証部１１２、機能特性設定部１１３、機能評価部１１４、幹枝判定部１１５）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体からソフトウェア開発支援用プログラムを読み出して実行することにより上記各部が主記憶装置１５０上にロードされ、機能設計書作成・編集部１１１、機能分割検証部１１２、機能特性設定部１１３、機能評価部１１４、幹枝判定部１１５が主記憶装置１５０上に生成されるようになっている。

図４は、ソフトウェア開発支援装置１００の全体の処理の流れを説明するためのフローである。機能設計書作成・編集部１１１は、開発対象のソフトウェアを各機能に分割し、機能間の呼び出し関係を記述した機能設計書を作成・編集する（機能設計書作成・編集工程Ｓ１１１）。機能分割検証部１１２は、機能設計書の機能の分割に不具合がないか否かを検証する（機能分割検証部工程Ｓ１１２）。ここで、機能の分割に不具合がある場合には、設計者は、機能設計書を修正する。機能特性設定部１１３は、各機能の重要性判断の基準となる機能特性を設定する（機能特性設定工程Ｓ１１３）。機能評価部１１４は、各機能毎に、設定された各機能特性の評価点を設定し、各機能毎に、設定された機能特性の評価点を合計して合計点を算出する（機能評価工程Ｓ１１４）。幹枝判定部１１５は、機能のならびの一覧を作成し、機能のならび毎に、機能のならびを構成する各機能の合計点に基づいて重要度を演算し、機能のならびの幹枝を判定する（幹枝判定工程Ｓ１１５）。上記各工程は、メニュー画面で設計者により選択された場合に実行される。

［機能設計書作成・編集工程］
機能設計書作成・編集部１１１は、開発対象のソフトウェアを各機能に分割し、かつ、分割した各機能の呼び出し関係を記述した機能設計書を作成する。図５は、機能設計書の一例を示す図である。

ソフトウェア開発ではまず開発内容に対して設計を行う。設計では、処理の流れ、データの構造、周辺装置や他アプリケーションソフトウェアとのデータ通信等の観点からそれぞれについて内容が理解し易い形式で記述される。一般に設計書の記述内容および記述形式は、開発するソフトウェアの種類や企業によって異なっているのが現状である。

機能設計書作成・編集部１１１は、表示装置１３０に機能設計書作成画面を表示し、設計者は、この機能設計書作成画面上で入力装置１２０を使用して、開発ソフトウェアの設計書として機能設計書を作成する。機能設計書は、開発ソフトウェアの機能を分割し、各機能の要件定義（その処理内容や扱うデータに関する記述）と、各機能の呼び出し関係を記述するものである。機能設計書作成・編集部１１１は、作成された機能設計書のデータを記憶装置１６０に格納する。図５の機能設計書の一例に示すように、各機能が互いに関連をもって接続されている。これは、一部の例外を除いて、ある処理を実現するために通常は１機能が全ての処理を行うのではなく、処理をいくつかの機能に分割し、互いに補完しあうように呼び出しを行うよう設計するためである。ある機能が他の機能を呼び出すとき、これを「機能の呼び出し」と呼ぶ。

同図に示す例では、矢印で「機能の呼び出し」関係を記述しており、矢印の元が呼び出し元、矢印の先が呼び出し先を示している。具体的には、同図に示す例では、機能１は、機能２，機能３，機能４を呼び出し、機能４は、機能５，機能６を呼び出している。この場合、機能１の呼び出し先アドレスは、機能２，３，４となり、機能２，３，４の呼び出し元アドレスは、機能１となる。また、機能４の呼び出し先アドレスは、機能５，６、機能５，６の呼び出し先アドレスは、機能４となる。

機能設計書作成・編集部１１１は、作成された機能設計書に基づいて、各機能の評価表リスト１６２に、機能説明（要件定義）、呼出先アドレス・呼出元アドレスのデータを格納する。なお、ここでは、機能設計書作成・編集部１１１が機能設計書を作成することとしたが、ワードプロセッサーのような開発対象の要件定義を表現できる他のソフトウェアで記述（描画）して、その情報を入力することにしてもよい。

［機能分割検証工程］
機能分割検証部１１２は、機能設計書の機能の分割に不具合がないか否かを検証する。依頼者の要件定義からいくつかの機能に分割する際、依頼者の意図がはっきりしていないと詳しい部分と漠然とした部分が混在することになる。かかる状態で機能分割すると、詳しい部分の機能のならびは長くなり、漠然とした部分の機能のならびは短くなる。その結果、詳しい部分の機能のならびは重要度が高くなり、その優先順位が高くなってしまう。

図６は、機能分割検証工程を説明するためのフローである。図７は、機能の関係を階層構造で記述した場合の一例を示す図である。図８は表示装置１３０に表示される機能分割検証結果の表示例を示す図である。

図６において、機能分割検証部１１２は、各機能の評価表リスト１６２の呼び出し先アドレスを探索して、各機能の関係を階層構造で記述する（ステップＳ２０１）。図７において、最初を第一階層とすると、第一階層の機能から呼び出されている機能は第二階層になる。

機能分割検証部１１２は、第ｎ階層（ｎ≧２）にある各機能の分割数Ｘを調べてその平均値を算出する（ステップＳ２０２）。例えば、図７において、第二階層をみると、「機能２１」は分割数が「４」で、「機能２２」は分割数が「１」である。従って、第二階層での分割数の平均値は「２．５」となる。

つぎに、機能分割検証部１１２は、第ｎ階層にある各機能の分割数が平均値のａ％〜ｂ％の範囲にあるか否かを判断する（ステップＳ２０３）。ここで、ａ，ｂは設計者が指定する値である。この判断の結果、ａ％を下回っている場合には、機能分割検証部１１２は、該当する機能について、”仕様がはっきりしていない可能性がある旨”を表示する（ステップＳ２０４）。

ａ％を下回っている場合は、依頼者との仕様確認が不十分な場合が想定されるためである。図７において、仮に、設計者がａ＝５０と定めたものと仮定すると、第二階層の分割数の平均値は「２．５」となる。「機能２１」の分割数は「４」であるため、第二階層の分割数の平均値「２．５」の５０％である「１．２５」を上回る。これに対して、「機能２２」は分割数が「１」であるため、第二階層の分割数の平均値「２．５」の５０％である「１．２５」を下回る。従って、「機能２２」は仕様確認が不十分であると予測される。

他方、ｂ％を超える場合には、該当する機能について、”仕様が細かすぎる可能性がある旨”を表示する（ステップＳ２０５）。ｂ％を超える場合は他の機能に比して仕様が細かすぎる可能性がある。この場合は、他の機能と同等の数になるよう分割を調整する必要がある。ただし、メニュー画面に代表されるように、ある機能が一度に多数の機能に分割されることがあるので、その場合はｂ％以下にするような調整を行う必要はない。また、ａ％〜ｂ％の範囲内にある場合には、識別表示は行わない（ステップＳ２０６）。

図８は、機能分割検証結果の表示例を示しており、「機能２２」について、”仕様がはっきりしていない可能性がある旨”が表示されている。設計者は、この機能分割検証結果を見て、機能設計書で機能の分割の修正が必要と判断した場合には、機能設計書の機能の分割数を修正する。具体的には、設計者は、機能の分割数が平均値のａ％以下である場合には、機能をさらに細かく分割し、また、機能の分割数が平均値のｂ％以上である場合には、他の機能と同等の数になるように分割数を調整する。

［機能特性設定工程］
機能特性設定部１１３は、各機能の重要性判断の基準となる機能特性を設定する。例えば、機能特性としては、制御系ソフトウェアの開発では、制御信号の種類による特性・処理時間に対する特性・他信号との並行処理に関する特性等があり、事務処理系ソフトウェア開発では、起動時期に関する特性・データアクセスに関する特性・オンライン処理／バッチ処理に関する特性等がある。

図９は、機能特性設定画面の一例を示す図である。機能特性設定部１１３は、表示装置１３０に機能特性設定画面を表示し、設計者は、この機能特性設定画面上で、開発対象のソフトウェアの性質に応じた機能特性を設定する。

機能特性設定画面では、特性一覧サブ画面３０１が表示され、設計者がこの特性一覧サブ画面３０１で、各機能の機能特性を選択することにより、機能特性を設定でき、選択された機能特性は選択サブ画面３０２に表示される。

ここで、各機能特性のうち、選択頻度の高い特性については基本特性とし、それ以外を設計者が選択可能な任意特性としておくのが望ましい。基本特性としては、例えば、（１）その機能から呼び出している他の機能の数、（２）その機能を呼び出している他の機能の数、（３）データベースやファイルを更新する項目数等がある。

任意特性としては、例えば、（１）前提機能の有無（前提機能：その機能が処理を行うためには他の機能が先に実行されている必要がある場合、他の機能を前提機能と呼ぶ。ただし、上記図５に示したような「機能の呼び出し」を指すものではなく、処理として独立している機能を指す。例えば、在庫確認で在庫量が適正水準を下回ったときに生産計画を実行する。生産計画からみると、在庫確認が前提機能となる。）、（２）実行頻度（例：年次処理・月次処理・週次処理・日次処理等）、（３）他ソフトウェアとデータを送受信する機能の有無、（４）他ソフトウェア・機能と同期をとりながら処理を行う等が考えられる。

［機能評価工程］
機能評価部１１４は、各機能毎に、機能特性設定部１１３で設定された各機能特性の評価点を設定する。具体的には、機能評価部１１４は、記憶装置１６０に記憶されている各機能の評価表リスト１６２に基づいて、表示装置１３０に評価表リスト画面を表示する。設計者は、この評価表リスト画面上で、各機能毎に、機能特性の評価点を設定する。機能評価部１１４は、設計者により設定された機能特性の評価点を、評価表リスト１６２に格納する。図１０は、表示装置１３０に表示される評価表リスト画面の表示例を示す図である。

評価点の配分は開発対象のソフトウェアによって変えることにしてもよい。仮に、機能特性１の重要度が高い場合には高い評価点を設定し、機能特性２が高くない場合には、低い評価点を設定する。機能評価部１１４は、各機能毎に、評価表リスト１６２の機能特性の評価点を合計し、その合計点のデータを評価表リスト１６２に格納する。

なお、機能特性によっては、機能評価部１１４で評価点を自動計算できる場合とできない場合がある。例えば、機能特性１として「その機能から呼び出している他の機能の数」を設定した場合には、機能評価部１１４は、各機能の評価表リスト１６２にある「呼び出し先アドレス１」〜「呼び出し先アドレスｋ」までのうち、実際に他機能を呼び出している、すなわち、アドレスが設定されている数をカウントする。また、機能特性１として「前提機能の有無」を設定した場合には、前提機能となる名前を記述しておくと、機能評価部１１４は、各機能の評価表リスト１６２を調べ、前提機能であると指定されている機能を探索する。前提となっている機能は、優先的に開発する必要があるため、高い点数を与える。以上では、機能評価部１１４が、自動的に判断する場合の例について説明した。他方、機能特性１として、「実行頻度（年次・月次等）を設定した場合には、機能評価部１１４が自動的に判断することができない。この場合には、設計者が評価点を設定する必要がある。このように、機能特性の評価点は、機能評価部１１４で自動計算してもよいし、設計者が設定することにしてもよく、本発明はいずれでもよい。

［幹枝判定工程］
幹枝判定部１１５は、各機能の評価表リスト１６２を参照して、機能の呼び出しを調べ、機能のならびの一覧を作成する。図１１は、機能のならびの一覧の一例を示す図である。同図において、例えば、機能１が、機能２と機能４を呼び出し、更に機能２が機能３を呼び出している場合には、機能のならびとしては、機能１−機能２−機能３（機能のならび１）、機能１−機能４（機能のならび３）となる。

幹枝判定部１１５は、機能のならび毎に、各機能の評価表リスト１６２を参照して、機能のならびを構成する各機能の合計点に基づいて、重要度を演算する。例えば、図１１において、「機能１」，「機能２」，「機能３」，「機能４」の合計点をそれぞれ「１０」，「１５」，「２０」，「２５」とした場合には、「機能のならび１」は、機能１−機能２−機能３で構成されるため、ｆ（１０，１５，２０）の演算式で、「機能のならび３」は機能１−機能４で構成されるため、ｆ（１０，２５）の演算式で重要度を算出することができる。例えば、合計点を合計した場合には、「機能のならび１」の重要度は、ｆ（１０，１５，２０）＝１０＋１５＋２０＝４５であり、「機能のならび３」の重要度はｆ（１０，２５）＝１０＋２５＝３５となる。ここでは、単純に合計点を合計した場合について説明したが、重み付け演算等を行うことにしてもよい。ここで、機能のならびの重要度が求められると、機能のならびを重要度の高い順に並べることができる。これが開発の優先順位を表すことになる。

幹枝判定部１１５は、機能のならびの重要度が、基準値以上の場合には、優先順位が高い「幹」と判定し、基準値未満の場合には、優先順位が低い「枝」と判定して、各機能のならびの幹枝の判定結果を表示装置１３０に表示する。ここで、基準値は、設計者が定めるもので、機能のならびの平均値としたり、機能のならびの点数配分状況を統計的な処理を施して決定することができる。図１２は、機能のならびの幹枝の判定結果の表示例を示す図である。同図に示す例では、重要度の高い順に機能のならびが表示されており、また、機能のならびが「幹」，「枝」に分離されている。

（実施例）
図１３〜図１５を参照して、上記ソフトウェア開発支援装置１００を使用して事務処理系ソフトを開発する場合を一例として説明する。図１３は事務処理系ソフトの機能設計書の一例を示す図である。

機能設計書作成・編集部１１１は、設計者の操作に応じて、例えば、図１３に示すような機能設計書を作成する。図１３に示す例では、機能”受注管理、受注情報登録、受注配分計画、生産計画、在庫確認、取引先照会”と、各機能の機能説明および呼び出し関係とが記述されている。機能設計書作成・編集部１１１は、作成された機能設計書に基づいて、評価表リスト１６２に、機能説明、呼出先アドレス、呼出元アドレスのデータを格納する。

設計者は、例えば、以下の観点で、機能特性を設定することができる。（１）他の機能を呼び出す場合、その機能は「幹」になりえる。（２）複数の機能から呼び出される機能は「幹」になりえる。（３）他の機能の状況によって動作する機能がある場合、他の機能を前提機能と呼ぶ（例：在庫確認で在庫量が適正水準を下回ったときに生産計画を実行する。）。（４）実行頻度が高い機能は「幹」になりえる。（５）業務の主となるデータ（例えば、給与計算システムでは勤務時間・給与等のデータ）を処理する機能は「幹」になりえる。（６）ＤＢに対しインデックスの付いているフィールドを処理する機能は「幹」になりえる。（７）ＤＢに対しキーとなるフィールドを処理する機能は幹になりえる。（８）他ソフトウェアとデータを送受信する機能は「幹」になりえる。（９）他ソフトウェア・機能と同期をとる機能は「幹」になりえる。

機能特性設定部１１３は、設計者の操作に応じて、これらの（１）呼出先／呼出元、（２）複数の呼出元、（３）前提機能、（４）実行頻度、（５）主たるデータの扱い、（６）インデクス付き、（７）キー、（８）送受信、（９）同期を機能特性として設定する。図１４は、評価表リスト１６２の一例を示す図である。図１４に示す例では、評価表リスト１６２は、（１）呼出先／呼出元、（２）複数の呼出元、（３）前提機能、（４）実行頻度、（５）主たるデータの扱い、（６）インデクス付き、（７）キー、（８）送受信、（９）同期の各機能特性の評価点を格納するエリアと、（１０）合計点を格納するエリアを備えている。

機能評価部１１４は、例えば、以下のようにして、機能特性の評価点を設定することができる。

（１）他の機能を呼び出している、または、他の機能から呼び出されている場合に、それぞれにつき２点を配分し、評価表リスト１６２中の呼び出し元、および、呼び出し先にアドレスが入っている場合、その数を数え、２点を乗じ、その結果を評価表リスト１６２の（１）のエリアに格納する。

（２）複数の他機能から呼び出される数に２点を乗じて配分する。評価表リスト１６２の呼び出し元アドレスを調べ、アドレスが複数（２以上）格納されていれば呼出元の数に２点を乗じた結果を評価表リスト１６２の（２）のエリアに格納する。

（３）他の機能の前提機能になっている場合には１０点を配分する。例えば、図１３に示す例では、生産計画の機能は在庫確認の機能で適正在庫水準を下回ったときにおこなうとすると、在庫確認は生産計画の前提機能となる。評価表リスト１６２の呼出先アドレスを探索し、全ての機能説明部を読み、他の機能の前提機能になっているか否かを調べる。他の機能の前提機能になっている場合には、評価表リスト１６２の（３）のエリアに１０点を格納する。

（４）年次＝１点、月次＝２点、週次＝３点、日次＝４点と配分する。機能説明部からその機能が実行される時期（年次／月次等）のデータを取り出し、それぞれ定められた点数を、評価表リスト１６２の（４）のエリアに格納する。

（５）１０点を配分し、業務の主たるデータとしては、データ項目名として一覧表を用意することにする。機能説明部に出現する用語を抽出し、これを一覧表と照合することでその機能が主たるデータを扱っているか否かを判断できる。照合の結果、一覧表に記載されている用語が使用されていればその機能の評価表リスト１６２の（５）のエリアに１０点を格納する。

（６）ＤＢ名から既存ＤＢを探し、ＤＢ構造を表す定義体を読み込む。この定義体からどのデータ項目にインデクスがついているか判別できるので、機能説明部のデータ項目名と照合することでインデクスのついているデータ項目か否か判別できる。インデクスが付いている場合、その機能の評価表リスト１６２の（６）のエリアに５点を格納する。

（７）ＤＢ名から既存ＤＢを探し、ＤＢ構造を表す定義体を読み込む。この定義体からどのデータ項目がキーであるか判別できるので、機能説明部のデータ項目名と照合することでキーであるデータ項目か否か判別できる。キーであるデータ項目の場合、その機能の評価表リスト１６２の（７）のエリアに５点を格納する。

（８）機能説明部から他ソフトウェアとデータを送受信するか否かを判断し、送受信がある場合は、評価表リスト１６２の（８）のエリアに５点を格納する。

（９）機能説明部から他ソフトウェア・機能と同期をとるか否かを判断し、同期をとっている場合は、評価表リスト１６２の（９）のエリアに５点を格納する。

このように配分する点数が定まると、各機能が上記（１）〜（９）に該当するか否かを判定し、各機能の評価表リスト１６２の（１）〜（９）のエリアに評価点を格納することができる。なお、該当しない場合は０点を格納する。ここで、機能評価部１１４が、自動判定できない機能特性については設計者が判断する。機能評価部１１４は、評価表リスト１６２の（１）〜（９）のエリアに格納された評価点を合計して、その合計点を（１０）のエリアに格納する。

ここで、図１３に示す各機能の合計点を、仮に、受注管理＝１０点、受注情報登録＝２１点、受注配分計画＝１０点、取引先照会＝２１点、在庫確認＝３１点、生産計画＝１１点とする。幹枝判定部１１５は、評価表リスト１６２を参照して、機能のならびの一覧を作成する。具体的には、評価表リスト１６２の呼出先アドレスを探索し、機能の呼び出しを並べることで機能のならびを作成することができる。

図１３に示す例では、「受注管理−生産計画」、「受注管理−受注情報登録」、「受注管理−受注配分計画」、「受注管理−受注配分計画−在庫確認」の４つの機能のならびがある。

幹枝判定部１１５は、機能のならび毎に、各機能の評価表リスト１６２を参照して、機能のならびを構成する各機能の機能特性の合計点に基づいて、重要度を演算する。ここでは、合計点を合計して重要度を演算する場合について説明する。「受注管理−生産計画」＝１０＋１１＝２１（重要度）、「受注管理−受注情報登録」＝１０＋２１＝３１（重要度）、「受注管理−受注配分計画−取引先照会」＝１０＋１０＋２１＝４１（重要度）、「受注管理−受注配分計画−在庫確認」＝１０＋１０＋３１＝５１（重要度）

幹枝判定部１１５は、機能のならびの重要度が、基準値以上の場合には、優先順位が高い「幹」と判定し、基準値未満の場合には、優先順位が低い「枝」と判定して、各機能のならびの幹枝の判定結果を表示装置１３０に表示する。

基準値は、上述したように設計者が定めるものであるが、ここでは、重要度の平均値を基準値とする。各機能のならびの重要度は、「２１」，「３１」，「４１」，「５１」であるので、重要度の平均値は「３６」となる。従って、「受注管理−受注配分計画−取引先照会」と「受注管理−受注配分計画−在庫確認」が「幹」となり、「受注管理−生産計画」と「受注管理−受注情報登録」は「枝」となる。

また、「幹」、「枝」のように区分するのではなく、優先順位の高い機能から低い機能までを並べ、順に開発することも考えられる。この場合、優先的に開発するのは、「受注管理−受注配分計画−在庫確認」であり、つぎに、「取引先照会」、「受注情報登録」、「生産計画」の順に開発する。

図１５は、機能のならびの幹枝の判定結果の表示例を示す図である。同図に示す例では、重要度の高い順に機能のならびが表示されており、また、機能のならびが「幹」，「枝」に分離されている。この表示例によれば、幹・枝に分離して開発を行う場合、および、重要度の高い順から開発する場合のいずれにも対応することが可能となる。

なお、互いに独立した機能（サブシステムと呼ぶ）がある場合、どのサブシステムを幹とするかを判断する必要がある。この場合、それぞれについて機能分割を行いながら機能に点数をつける。そして、サブシステム内の全機能の点数を合計すると、サブシステムの点数が求まり、これを比較することで「幹」，「枝」を判定することができる。

以上説明したように、本実施の形態によれば、機能設計書作成・編集部１１１は、開発対象のソフトウェアを各機能に分割し、かつ、機能間の呼び出し関係を記述した機能設計書を作成または入力し、機能特性設定部１１３は、重要性判断の基準となる機能特性を複数設定し、機能評価部１１４は、機能設計書の各機能毎に設定された機能特性の評価点を設定し、当該各機能毎に設定された機能特性の評価点を合計して合計点を算出し、幹枝判定部１１５は、機能設計書で記述された機能間の呼び出し関係に応じた機能のならびの一覧を作成し、当該機能のならび毎に、機能のならびを構成する各機能の合計点を演算してその重要度を算出することとしたので、機能のならび毎に重要度を算出して、高精度に機能の優先順位を判定することができ、ソフトウェア開発の期間の短縮および負荷の軽減を図ることが可能となる。すなわち、（１）依頼者が早期に動作確認でき、（２）開発者の負担を増やすことなく、（３）依頼者の要求する仕様が最初に明確になっていなくても開発作業を進めることが可能となる。また、付言すると、ソフトウェア開発の初期の時点で、依頼者の考えがはっきり定まっていない時点でも、また、開発途中での機能追加や仕様変更について、開発の優先順位を決定することができ、早い時期に開発計画を立てることができる。また、機能のならびは、特定のデータ処理について完結しているので、その部分だけを起動することで依頼者に部分的な動作確認を提供することができる。

また、本実施の形態によれば、機能設計書作成・編集部１１１は、機能設計書で記述される機能間の呼び出し関係に基づいて、評価表リスト１６２に、機能毎に他の機能との呼び出し関係を格納し、機能評価部１１４は、評価表リスト１６２に、各機能毎に機能特性の評価点を格納するとともに、当該機能毎に、格納された機能特性の評価点を合計した合計点を格納し、幹枝判定部１１５は、評価表リスト１６２を参照して、機能のならびの一覧を作成するとともに、当該機能のならび毎に、機能のならびを構成する各機能の合計点を演算してその重要度を算出することとしたので、簡単な方法で高精度に機能の優先順位を判定することができる。

また、本実施の形態によれば、幹枝判定部１１５は、機能のならびの重要度が基準値以上の場合には、幹と判定し、基準値未満の場合には、枝と判定することとしたので、機能を「幹」と「枝」に分離して、ソフトウェア開発を行うことができる。

また、本実施の形態によれば、機能分割検証部１１２は、機能設計書に記述された機能の分割に不具合がないか否かを検証することとしたので、設計者は、機能の分割の仕方に不具合がある場合には、機能の分割を修正することができる。

また、本実施の形態によれば、機能分割検証部１１２は、機能設計書に記述された機能の関係を階層構造で記述し、第ｎ階層にある各機能の分割数が所定範囲内に有るか否かを判定し、分割数が所定範囲外にある機能に関して、その旨を表示することとしたので、設計者は、分割に不具合のある機能を容易に識別することができる。

本発明に係るソフトウェア開発支援装置およびソフトウェア開発支援用プログラムは、事務処理系ソフトウェアや制御系ソフトウェア等の各種ソフトウェアを開発する場合に、その開発時間を短縮する場合に有用であ。

本実施の形態に係るソフトウェア開発の概略説明図である。 本実施の形態に係るソフトウェア開発支援装置の構成例を示す図である。 評価表リスト１６２のフォーマットの一例を示す図である。 ソフトウェア開発支援装置の全体の処理の流れを説明するためのフローである。 機能設計書の一例を示す図である。 機能分割検証工程を説明するためのフローである。 機能の関係を階層構造で記述した場合の一例を示す図である。 機能分割検証結果の表示例を示す図である。 機能特性設定画面の一例を示す図である。 評価表リスト画面の表示例を示す図である。 機能のならびの一覧の一例を示す図である。 機能のならびの幹枝の判定結果の表示例を示す図である。 事務処理系ソフトの機能設計書の一例を示す図である。 評価表リストのフォーマットの一例を示す図である。 機能のならびの幹枝の判定結果の表示例を示す図である。

符号の説明

１００ ソフトウェア開発支援装置
１１０ 制御装置
１１１ 機能設計書作成・編集部
１１２ 機能分割検証部
１１３ 機能特性設定部
１１４ 機能評価部
１１５ 幹枝判定部
１２０ 入力装置
１３０ 表示装置
１４０ 印刷装置
１５０ 主記憶装置
１６０ 記憶装置

Claims (10)

1. 開発対象のソフトウェアを各機能に分割し、かつ、機能間の呼び出し関係を記述した機能設計書を作成または入力する機能設計書入力手段と、
   前記各機能の重要性判断の基準となる機能特性を設定する機能特性設定手段と、
   前記各機能毎に、前記設定された機能特性の評価点を設定し、当該各機能毎に、前記設定された機能特性の評価点を合計して合計点を算出する機能評価手段と、
   前記機能設計書で記述された機能間の呼び出し関係に応じた機能のならびの一覧を作成し、当該機能のならび毎に、機能のならびを構成する各機能の前記合計点に基づいて、その重要度を算出する判定手段と、
   を備えたことを特徴とするソフトウェア開発支援装置。
2. 前記機能設計書の機能毎に、他の機能との呼び出し関係、前記機能特性の評価点、および当該機能特性の評価点を合計した合計点が格納されるデータ構造体を記憶する記憶手段を備え、
   前記機能設計書入力手段は、前記機能設計書で記述される機能間の呼び出し関係に基づいて、前記データ構造体に、前記機能毎に、前記他の機能との呼び出し関係を格納し、
   前記機能評価手段は、前記データ構造体に、各機能毎に前記機能特性の評価点を格納するとともに、当該機能毎に、格納された機能特性の評価点を合計した合計点を格納し、
   前記判定手段は、前記データ構造体を参照して、前記機能のならびの一覧を作成するとともに、当該機能のならび毎に、機能のならびを構成する各機能の前記合計点を演算してその重要度を算出することを特徴とする請求項１に記載のソフトウェア開発支援装置。
3. 前記判定手段は、前記機能のならびの重要度が基準値以上の場合には、幹と判定し、基準値未満の場合には、枝と判定することを特徴とする請求項１または請求項２に記載のソフトウェア開発支援装置。
4. 前記機能設計書に記述された機能の分割に不具合がないか否かを検証する機能分割検証手段を備えたことを特徴とする請求項１〜請求項３のいずれか１つに記載のソフトウェア開発支援装置。
5. 前記機能分割検証手段は、
   前記機能設計書に記述された機能の関係を階層構造で記述し、
   第ｎ階層にある各機能の分割数が所定範囲内に有るか否かを判定し、
   前記分割数が前記所定範囲外にある機能に関して、その旨を表示手段に表示することを特徴とする請求項４に記載のソフトウェア開発支援装置。
6. 開発対象のソフトウェアを各機能に分割し、かつ、機能間の呼び出し関係を記述した機能設計書を作成または入力する機能設計書入力ステップと、
   前記各機能の重要性判断の基準となる機能特性を設定する機能特性設定ステップと、
   前記機能毎に前記設定された機能特性の評価点を設定し、当該各機能毎に前記設定された機能特性の評価点を合計して合計点を算出する機能評価ステップと、
   前記機能設計書で記述された機能間の呼び出し関係に応じた機能のならびの一覧を作成し、当該機能のならび毎に、機能のならびを構成する各機能の前記合計点に基づいてその重要度を算出する判定ステップと、
   をコンピュータに実行させることを特徴とするソフトウェア開発支援用プログラム。
7. 前記機能設計書入力ステップでは、前記機能設計書で記述される機能間の呼び出し関係に基づいて、データ構造体に、前記機能毎に、前記他の機能との呼び出し関係を格納し、
   前記機能評価ステップでは、前記データ構造体に、各機能毎に前記機能特性の評価点を格納するとともに、当該機能毎に、格納された機能特性の評価点を合計した合計点を格納し、
   前記判定ステップでは、前記データ構造体を参照して、前記機能のならびの一覧を作成するとともに、当該機能のならび毎に、機能のならびを構成する各機能の前記合計点を演算してその重要度を算出することを特徴とする請求項６に記載のソフトウェア開発支援用プログラム。
8. 前記判定ステップでは、前記機能のならびの重要度が基準値以上の場合には、幹と判定し、基準値未満の場合には、枝と判定することを特徴とする請求項６または請求項７に記載のソフトウェア開発支援用プログラム。
9. 前記機能設計書に記述された機能の分割に不具合がないか否かを検証する機能分割検証ステップを、コンピュータに実行させることを特徴とする請求項６〜請求項８のいずれか１つに記載のソフトウェア開発支援用プログラム。
10. 前記機能分割検証ステップでは、
    前記機能設計書に記述された機能の関係を階層構造で記述し、
    第ｎ階層にある各機能の分割数が所定範囲内に有るか否かを判定し、
    前記分割数が前記所定範囲外にある機能に関して、その旨を表示手段に表示することを特徴とする請求項９に記載のソフトウェア開発支援用プログラム。
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

Images