JPH0916392A - ソフトウェア開発支援方式 - Google Patents

Abstract

(57)【要約】 【目的】 任意の成果物を修正する際に、その修正内容
に応じて関連する成果物の情報を提示するソフトウェア
開発支援方式を得ることを目的とする。 【構成】 要求分析、システム設計、機能設計、詳細設
計、ソースコード生成生成、オブジェクトコード生成、
システム結合、単体試験、結合試験、総合試験、運用試
験の各開発フェーズで得られる全ての成果物に関する情
報を格納する定型資料データベース１１０と、成果物の
相互の関連付け情報を格納する関連付けデータベース１
１２とを設ける。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、計算機システムの構
築の効率を向上し作業を容易にするためのソフトウェア
開発支援方式に関するものである。

【０００２】

【従来の技術】図２７は計算機システムを開発するため
の従来のソフトウェア開発支援方式の代表的な例である
ＣＡＳＥ（Computer Aided Software Environment ）ツ
ールにおけるソフトウェアプロセスモデルの一例である
Ｖカーブモデルの開発の流れを示す図である。

【０００３】次に動作について説明する。かかるソフト
ウェア開発支援方式では、ソフトウェアの開発は、要求
分析（問題の解説）、システム（概要）設計、機能（基
本）設計、詳細（モジュール）設計、ソースコード生
成、オブジェクトコード生成、システム結合、単体試
験、結合試験、総合試験、運用試験の各開発フェーズを
順に進行する。各開発フェーズでは、各種の仕様書や、
ソースプログラム、試験データ等が成果物として生成さ
れる。それらの成果物は、開発対象となる計算機システ
ムにより異なる。また、ある開発フェーズで不具合が生
じた場合には、すぐ上流の開発フェーズに戻るようにし
てソフトウェア開発は進められる。

【０００４】従来のソフトウェア開発支援方式を用いた
ＣＡＳＥツールは上記した開発フェーズを支援するため
に、構造化手法、オブジェクト指向分析と言った方法論
に基づいてソフトウェア開発の作法を規定し、またこれ
ら方法論で採用されているドキュメントの記法を用いて
仕様書を作成するためのエディタを提供している。例え
ば構造化手法を採用するものは、データフローダイアグ
ラム（以下ＤＦＤと略記する）等を描画するためのエデ
ィタを持ち、オブジェクト指向分析を採用するものはク
ラス階層図等のエディタを持っている等である。これら
は単に描画のみではなく、描画された内容が各設計手法
の枠組に添っているかの検査を行う機能を持つ。例え
ば、ＤＦＤではデータの流れが完結しているか等の検
査、クラス階層図では継承関係がループしていないかど
うか等の検査を行う等である。また、上記したように、
これらの設計内容に応じて部分的又は完全なソースコー
ドの生成を行う機能を有している。さらに、生成された
ソースコードに対して異常動作が起きるかどうかの検査
項目を生成する機能を有している。

【０００５】さらに、従来のソフトウェア開発支援方式
を用いたＣＡＳＥツールは、上記した個々の開発フェー
ズ間の成果物の整合性のチェック機能と、連続した開発
フェーズの間での成果物の変換のための機能とを有して
いる。整合性のチェックは各開発フェーズ毎に成果物の
構成要素が全てそろった時点で可能になる。一般に、開
発フェーズのうち、分析や設計、製作に関するものの間
では、下流工程後のものほどより詳細かつ具体的な記述
が行われる。ＣＡＳＥツールの中には、作成中の計算機
システムに要求される機能、性能が満たされているかの
評価機能を備えているものがあるが、これについても全
ての構成要素に関する詳細な記述が完了している必要が
ある。特に、性能に関する評価は詳細設計が終了するま
ではできない。さらに、各開発フェーズで生成される成
果物は個別システム毎に管理されており、連続して複数
のシステムを作成するような場合でも、システム間での
統合的な管理は行われることはない。

【０００６】

【発明が解決しようとする課題】従来のソフトウェア開
発支援方式は以上のように構成されているので、全ての
成果物のモジュール等の設計の詳細化が完了してから機
能、性能の評価を行い、機能が不十分な成果物のモジュ
ールの修正に加えてその影響を吸収するために他の成果
物のモジュール等の修正を行って全体の整合を取らなけ
ればならず、その関連ある成果物のモジュール等を探し
出すために多大な手間がかかってしまうという問題点が
あった。

【０００７】また、連続して複数のシステムを作成する
際に以前に開発したシステムに類似の機能があったとし
ても、それを後から開発するシステムに流用して開発を
効率的に行うことができないという問題点があった。

【０００８】さらに、システム開発中又は保守にあたり
システムの機能を変更する際には、その機能を直接実現
しているモジュールを改造するだけではなく、関連する
モジュールについても前者のモジュールの変更内容の吸
収するための改造が必要になる事があるが、このような
場合、従来のソフトウェア開発支援方式では仕様変更の
工数の見積りが困難であり、また、仕様変更に対する適
切な判断材料を提示できないなどの問題点があった。

【０００９】この発明は上記のような問題点を解消する
ためになされたもので、任意の成果物を修正する際に、
その修正内容に応じて関連する成果物の修正を容易に達
成するために、関連する成果物の情報を提示するソフト
ウェア開発支援方式を得ることを目的とする。

【００１０】またこの発明は、類似したシステムの成果
物等をテンプレートとして提供して開発効率を向上させ
得るソフトウェア開発支援方式を得ることを目的とす
る。

【００１１】さらにこの発明は、成果物の変更に伴って
改造が必要な影響範囲を見積り、仕様変更に伴う改造の
工数を見積ることにより、仕様変更に対する適切な判断
材料を提供できるソフトウェア開発支援方式を得ること
を目的とする。

【００１２】

【課題を解決するための手段】請求項１の発明に係るソ
フトウェア開発支援方式は、各開発フェーズで得られる
全ての成果物を相互に関連付ける関連付け情報を格納す
る統合データベースを設けたものである。

【００１３】請求項２の発明に係るソフトウェア開発支
援方式は、少なくとも機能設計及び詳細設計の開発フェ
ーズにおいて、既定値を含むテンプレートを用いて開発
を行うものである。

【００１４】請求項３の発明に係るソフトウェア開発支
援方式は、各開発フェーズの直接の成果物以外の資料
と、各開発フェーズにおいて生成される成果物とを相互
に関連付ける関連付け情報を統合データベースにおいて
管理するものである。

【００１５】請求項４の発明に係るソフトウェア開発支
援方式は、サブシステム、モジュールの各々についての
版とそれらを組み合わせた全体の版との管理を行い、且
つ、関連付け情報の改訂履歴を含めた版管理を行うもの
である。

【００１６】請求項５の発明に係るソフトウェア開発支
援方式は、既定値を含むテンプレートを用いて、ソフト
ウェア開発の各開発フェーズ毎にソフトウェアの機能、
性能の検証を行うものである。

【００１７】請求項６の発明に係るソフトウェア開発支
援方式は、ソフトウェア開発の各開発フェーズ毎に、テ
ンプレートの既定値が設計値で置き換わった割合により
システムを構成する要件が全てそろっているか否かを判
定するものである。

【００１８】請求項７の発明に係るソフトウェア開発支
援方式は、利用者が利用を開始するときに入力する情報
に基づいて、統合データベースから利用者の担当する成
果物を呼び出すものである。

【００１９】請求項８の発明に係るソフトウェア開発支
援方式は、システムの成果物の間のシステム構成上の関
係に基づいて、開発中または開発済みのシステムの一部
又は全部の機能変更に直接関与する部分の改造が影響す
る範囲を見積るものである。

【００２０】請求項９の発明に係るソフトウェア開発支
援方式は、影響範囲の見積とソフトウェア開発の各利用
者の担当部分の情報とから、改造の部分の担当者を検索
し提示するものである。

【００２１】請求項１０の発明に係るソフトウェア開発
支援方式は、影響範囲の見積と各成果物の工数とに基づ
き、改造の工数の見積を行うものである。

【００２２】請求項１１の発明に係るソフトウェア開発
支援方式は、利用者が入力する開発対象のシステムの特
徴に基づいて、過去の開発事例から開発対象のシステム
と関連の深い開発事例を選択し該開発事例の成果物をテ
ンプレートとして使用するものである。

【００２３】請求項１２の発明に係るソフトウェア開発
支援方式は、過去の開発事例について非定型資料関連付
けステップにおいて管理される開発事例の関連付け情報
を参照することにより、開発事例に関連する情報を提示
するものである。

【００２４】

【作用】請求項１の発明におけるソフトウェア開発支援
方式は、要求分析、システム設計、機能設計、詳細設
計、ソースコード生成、オブジェクトコード生成、シス
テム結合、単体試験、結合試験、総合試験、運用試験の
各開発フェーズで得られる全ての成果物の間での関連づ
けを行うことで、開発するソフトウェアの例えばあるモ
ジュールを変更する際に関連するモジュールを検出し提
示することが可能になる。関連づけは利用者が関連づけ
られたモジュールを確認するために呼び出すためにも使
用できる。

【００２５】請求項２の発明におけるソフトウェア開発
支援方式は、少なくとも機能設計及び詳細設計の開発フ
ェーズにおいて、既定値を持つテンプレートを使用して
ソフトウェア開発を進める。これにより、システムの設
計の際の指針を利用者に与えることができ、設計の効率
を向上させ得る。また、テンプレートの利用は設計時の
漏れも防ぐことができる。

【００２６】請求項３の発明におけるソフトウェア開発
支援方式は、打合せ議事録、打合せ資料、及び参考文献
を少なくとも含む、各開発フェーズの直接の成果物以外
の資料と、各開発フェーズにおいて生成される成果物と
を相互に関連付ける関連付け情報を統合データベースに
おいて管理する。このように、関連づけが打合せ議事録
等にも及ぶことで、設計内容の背景の確認が容易にな
り、設計方針の誤った解釈によるミスを減少させること
ができる。

【００２７】請求項４の発明におけるソフトウェア開発
支援方式は、ソフトウェアを少なくともサブシステム、
モジュールに細分化して、その各々についての版とそれ
らを組み合わせた全体の版との管理を行い、且つ、関連
付け情報の改訂履歴を含めた版管理を行う。最小単位毎
に版管理を行うことで、関連付けの単位と版管理の単位
が一致することになり、関連付けを版毎に管理すること
が可能になる。関連付け情報を実体と分離して管理する
ことで、柔軟な関連付けの管理が行え、外部から取り込
まれたデータに対しても関連付けが行える。

【００２８】請求項５の発明におけるソフトウェア開発
支援方式は、既定値を含むテンプレートを用いて、ソフ
トウェア開発の各開発フェーズ毎にソフトウェアの機
能、性能の検証を行う。既定値の埋め込まれたテンプレ
ートを使用することで、個別のモジュールの内容を検討
するにあたって、そのモジュールについては新たに設計
した内容を用いて、残りのモジュールについては既定値
を用いて動作の模擬を行うことが可能になる。テンプレ
ート上で機能、設計の見積を行うことにより、部分的な
設計がシステム全体の要求に合致しているかを確認でき
る。

【００２９】請求項６の発明におけるソフトウェア開発
支援方式は、ソフトウェア開発の各開発フェーズ毎に、
テンプレートの既定値が設計値で置き換わった割合によ
りシステムを構成する要件が全てそろっているか否かを
判定する。より具体的には、各モジュールに付けられた
設計が済であるか否かのマークを集計することで、シス
テム開発の進捗を把握するための指標を提示することが
可能になる。

【００３０】請求項７の発明におけるソフトウェア開発
支援方式は、利用者の参加するプロジェクト、プロジェ
クト内のチーム、及び利用者が担当する部分に関する情
報を少なくとも管理し、利用者が利用を開始するときに
入力する情報に基づいて、統合データベースから利用者
の担当する成果物を呼び出す。従って、利用者がシステ
ムの使用開始時に入力する情報をプロジェクト、利用者
の属性と照合し、当該作業に必要な情報を検索、収集し
て提示することが可能になる。

【００３１】請求項８の発明におけるソフトウェア開発
支援方式は、開発中または開発済みのシステムの一部又
は全部の機能を変更する際に、システムの成果物の間の
システム構成上の関係に基づいて、変更に直接関与する
部分の改造が影響する範囲を見積る。従って、特定モジ
ュールの変更のシステム全体への影響の度合いを見積
り、仕様変更に対する評価基準を提示することができ
る。

【００３２】請求項９の発明におけるソフトウェア開発
支援方式は、影響範囲の見積とソフトウェア開発の各利
用者の担当部分の情報とから、改造の部分の担当者を検
索し提示する。即ち、例えばモジュール間のシステム構
成上の関係を辿り影響範囲を求め、モジュール毎の担当
部門、担当者を上記の統合データベースから検索するこ
とで、設計時の変更、問題点の解消のための連絡先、即
ち改造が必要な部分の担当者を提示することが可能にな
る。

【００３３】請求項１０の発明におけるソフトウェア開
発支援方式は、影響範囲の見積と各成果物の工数とに基
づき、改造の工数の見積を行う。工数の予測を行うこと
で、改造の規模を把握するための情報が提供でき、改造
の方式が複数考えられるような場合に、それらを比較検
討するための指標として使用できる。

【００３４】請求項１１の発明におけるソフトウェア開
発支援方式は、利用者が入力する開発対象のシステムの
特徴に基づいて、過去の開発事例から開発対象のシステ
ムと関連の深い開発事例を選択し該開発事例の成果物を
テンプレートとして使用する。システム、より細かくは
モジュールの特徴、即ち機能、性能を検索することで、
過去に開発した類似システム、モジュールを提示するこ
とが可能になる。予め用意されたテンプレートだけでは
なく、よく似た事例を検索する機能を用いることによ
り、新規設計時にも設計の方針を得やすくなる。

【００３５】請求項１２の発明におけるソフトウェア開
発支援方式は、過去の開発事例について非定型資料関連
付けステップにおいて管理される開発事例の関連付け情
報を参照することにより、開発事例に関連する情報を提
示する。開発事例を検索した際には、関連付け情報を辿
りその開発事例の設計の根拠を知ることで、新規設計で
変更すべき点をより良く把握できる。

【００３６】

【実施例】

実施例１．以下、この発明の一実施例を図について説明
する。図１はこの発明の一実施例によるソフトウェア開
発支援方式の構成を示すブロック図であり、図におい
て、１０１はデータベースインタフェイス、１０８はプ
ロジェクト属性を格納するプロジェクト属性データベー
ス（統合データ、ベース）、１０９は利用者属性を格納
する利用者属性データベース（統合データ、ベース）、
１１０は定型資料を格納する定型資料データベース（統
合データ、ベース）、１１１は事例情報を格納する事例
データベース（統合データ、ベース）、１１２は関連付
け情報を格納する関連付けデータベース（統合データ、
ベース）、１１３は非定型資料を格納する非定型資料デ
ータベース（統合データ、ベース）である。データベー
スインタフェイス１０１は、表示制御部１０２、属性決
定部１０３、リポジトリ検索部１０４、事例検索部１０
５、関連決定部１０６、外部アクセス部１０７からな
る。

【００３７】次に動作について説明する。データベース
インタフェイス１０１は、利用者と各データベースの間
のインタフェイスをつかさどる。データベースインタフ
ェイス１０１に含まれる各サブシステム、表示制御部１
０２、属性決定部１０３、リポジトリ検索部１０４、事
例検索部１０５、関連決定部１０６、外部アクセス部１
０７は、互いに交信しながら各データベースにアクセス
し、利用者の要求するデータの呼び出し、更新を行う。

【００３８】プロジェクト属性データベース１０８は、
ソフトウェア開発の支援の対象となるソフトウェア開発
プロジェクトに関する、開発体制、開発内容等の情報を
格納している。具体的には、プロジェクトの名称、プロ
ジェクト責任者、担当者、担当者のチーム分け、チーム
毎の担当内容、プロジェクトの開発対象システムの情報
が格納される。図２はプロジェクト属性データベース１
０８内に格納されるプロジェクト属性情報の形式を示す
図であり、図において、２０１はプロジェクト番号、２
０２はプロジェクト名称、２０３は責任者の利用者番
号、２０４は担当者の複数の利用者番号、２０５は複数
のチーム情報、２０６はソフトウェアシステムのシステ
ム番号である。プロジェクト番号２０１、利用者番号２
０３，２０４、システム番号２０６は、それぞれプロジ
ェクト、利用者、ソフトウェアシステムを識別するため
のものであり、この発明によるソフトウェア開発支援方
式によるソフトウェアシステムに登録されるプロジェク
ト、システム、利用者それぞれの通し番号である。尚、
プロジェクト属性データベース１０８は、プロジェクト
番号２０１又はプロジェクト名称２０２をキーとして検
索される。

【００３９】図３はプロジェクト属性情報から参照され
るチーム情報２０５の形式を示す図であり、図におい
て、３０１はチーム番号、３０２はチーム名称、３０３
はチームの責任者の利用者番号、３０４は所属する担当
者の複数の利用者番号、３０５〜３０７は担当する複数
の製作単位の番号であり、チーム情報２０５はこれらの
情報から成る。チーム番号３０１はプロジェクト内での
チーム分けを識別するためのものであり、プロジェクト
内での通し番号である。製作単位の番号は、プロジェク
ト内での成果物を識別するためのものであるが、製作単
位は適用する開発手法により変化する。例えば、オブジ
ェクト指向分析／設計を適用する場合プログラムは、サ
ブシステム、モジュール、クラスの順に細分化されるの
で、製作単位の番号の並びは、これらの番号の並びとな
る。クラス単位での指定をするためには、図３に示すよ
うに、それの属するサブシステム番号３０５、サブシス
テム内でのモジュール番号３０６、モジュール内でのク
ラス番号３０７の組合せで指定する。モジュール単位で
の指定をする場合には、それが属するサブシステム番号
３０５、サブシステム内でのモジュール番号３０６とモ
ジュール自身であることを示す識別子で指定する。モジ
ュール自身であることの識別子は、例えばクラスの裁番
を１から行い０がモジュール自身を差すことにすれば実
現できる。

【００４０】利用者属性データベース１０９は、個々の
利用者の担当内容等の情報を格納している。具体的に
は、利用者の名称、参加するプロジェクト、参加プロジ
ェクト内での所属チーム、担当する製作単位の情報を格
納する。図４は利用者属性データベース１０９における
利用者属性データの形式を示す図であり、図において、
４０１は利用者番号、４０２は利用者名称、４０３は複
数の参加プロジェクト情報である。また、図５は利用者
属性データベース１０９の利用者属性データから参照さ
れる参加プロジェクト情報の並び４０３の形式を示す図
であり、図において、５０１はプロジェクト番号、５０
２は担当情報の並びである。また、図６は参加プロジェ
クト情報の並び４０３から参照される担当情報の並び５
０２の形式を示す図であり、図において、６０１はチー
ム番号、６０２〜６０４は利用者の担当する複数の製作
単位の番号、即ちサブシステム番号、モジュール番号、
クラス番号である。尚、利用者属性データベース１０９
で使用される利用者番号４０１、プロジェクト番号５０
１、チーム番号６０１、製作単位の番号、即ちサブシス
テム番号６０２、モジュール番号６０３、クラス番号６
０４はプロジェクト属性データベース１０８で使用され
るものと共通である。尚、利用者属性データベース１０
９は利用者番号４０１又は利用者名称４０２をキーとし
て検索される。

【００４１】定型資料データベース１１０は、ソフトウ
ェアのシステム開発の各開発フェーズで作成されるシス
テム構成図、データフローチャート等の定型的な成果物
を格納している。具体的には、システム構成、機能設
計、詳細設計、ソースコード、オブジェクトコード、実
行形式、単体試験仕様、単体試験結果、組合せ試験仕
様、組合せ試験結果、総合試験仕様、総合試験結果等テ
ンプレート作成の対象となるシステム開発の各開発フェ
ーズでの成果物全てが定型資料データベース１１０に格
納される。

【００４２】例えば、オブジェクト指向分析／設計を行
う場合は、サブシステム間の関係を表現するサブシステ
ム交信モデル、オブジェクト間の関係を表現するオブジ
ェクト交信モデル、オブジェクトの状態遷移を表現する
オブジェクト状態モデル、オブジェクトの動作とデータ
のやり取りを表現するアクションデータフローダイアグ
ラム（以下ＡＤＦＤと略記する）、全体の動作の制御を
表現する制御スレッド図等多数の成果物を作成すること
が定められている。図７はオブジェクト状態モデルの一
例を示す説明図、図８はＡＤＦＤの一例を示す説明図、
図９に制御スレッド図の一例を示す説明図である。これ
らの図は本位田真一／伊藤潔監訳「続・オブジェクト指
向システム分析」啓学出版（エス スレーラ、ジェイ
メラー著、プレンティスーホール）より引用（状態モデ
ルは４１頁、制御スレッド図は１０２頁、ＡＤＦＤは１
２２頁に記載されている）した。

【００４３】定型資料データベース１１０に格納される
定型資料情報にはその改訂履歴を管理するための版情報
と、テキスト、ダイアグラム、ブロック図と言った情報
の内容に応じて表示方式を決定するための表示制御情報
が付加される。図１０は定型資料データベース１１０の
定型資料情報の形式を示す図であり、図において、１０
０１はシステム番号、１００２はシステム名称、１００
３は成果物情報の並びである。図１１は図１０に示す定
型資料情報から参照される成果物情報の並び１００３の
形式を示す図であり、図において、１１０１は成果物番
号、１１０２は成果物名称、１１０３は開発フェーズ番
号、１１０４は製作単位番号、１１０５は工数、１１０
６は表示識別番号、１１０７は複数の成果物実体情報、
１１０８は未編集リストである。開発フェーズ番号１１
０３は、開発フェーズ名との対応表において定義され
る。開発フェーズの分け方は適用するＶカーブモデル、
スパイラルモデル等の開発手法に応じて定められる。成
果物実体情報の並び１１０７は、成果物の版毎の改訂履
歴を示す。工数１１０５には設計完了前は見積、完了後
は実績が入る。未編集リスト１１０８は当該成果物のテ
ンプレートの既定値が設計値で置き換えられていないも
ののリストである。これは成果物実体情報の形式により
異なる。

【００４４】例えば、図９に示した制御スレッド図の場
合、各プロセスの処理時間が設計対象であるから、未編
集リスト１１０８の初期値はプロセス名が列挙されたも
のである。設計の進展に伴って、つまり設計値で既定値
が置き換えられる毎に未編集リスト１１０８から当該の
ものが除かれる。設計が完了した時点では、未編集リス
ト１１０８は空になる。尚、定型資料データベース１１
０は、システム番号１００１又はシステム名称１００２
をキーとして検索される。

【００４５】図１２は図１１の成果物実体情報の並び１
１０７を示す図であり、図において、１２０１は成果物
実体番号、１２０２は版番号、１２０３は利用者番号、
１２０４はチーム番号、１２０５は実体呼び出し番号、
１２０６はエントリ情報の並である。また、図１３は図
１２のエントリ情報の並び１２０６を示す図であり、図
において、１３０１はエントリ番号、１３０２は位置情
報、１３０３は関係付け番号である。

【００４６】図１１に示す表示識別番号１１０６は、フ
ロック図、アローダイアグラム、テキスト等、用いられ
る情報の表示形式に応じて番号付けされたものである。
また、図１３に示す位置情報１３０２は表示形式により
指定の方法が異なる。ブロック図のようにブロック単位
で意味を持つものはブロック番号を内容とし、アローダ
イアグラムのようにノードとアークそれぞれが意味を持
つものは、ノードとアークの種別とその番号を内容とす
る。図１２の実体呼び出し番号１２０５は資料の実体の
呼び出しのための識別子として用いられる。成果物とし
てのソースコードやオブジェクトコード、実行形式等は
通常のファイルシステムのファイルとして格納されても
よいし、特定のＣＡＳＥツールのリポジトリに加えられ
てもよい。

【００４７】事例データベース１１１は過去の開発事例
を新たに開発するシステムのひな形として使用するため
の検索情報を格納している。具体的には、過去に開発さ
れたシステムの名称とそれらの機能、性能の特徴に関す
る情報を格納する。即ち、システム、モジュール毎にそ
の機能、性能をもとにして特徴付けを行い、それらをキ
ーとして過去の開発事例を検索することを目的として、
それらの機能、性能が事例データベース１１１に登録さ
れている。機能、性能は、それらを表現する項目を予め
設定しておき、例えば項目毎に数値化して評価すること
で表現する。図１４は事例データベース１１１における
事例データの形式を示しており、図において、１４０１
は事例番号、１４０２はシステム番号、１４０３は機能
評価値（又は機能特性）の並び、１４０４は性能評価値
（又は性能特性）の並びである。システム番号１４０２
は事例となるシステムを識別するためのものであり、プ
ロジェクト属性データベース１０８で使用するものと共
通である。

【００４８】機能評価値（又は機能特性）１４０３、性
能評価値（又は性能特性）１４０４はプロジェクトの終
了毎に各システムを機能、性能で特徴付けるために利用
者が評価して定めるものである。機能評価値（又は機能
特性）１４０３はシステムの機能を数値化して表現する
ものである。例えば、リアルタイム性、汎用度等の項目
化を行い各々に対して評価値を与える。また、機能評価
値（又は機能特性）１４０３として適用分野を用いても
よく、アプリケーションの種別による分類を行いその番
号を指定することもできる。例えば、データベース検索
システムの中でも、検索対象が銀行の口座であるか、資
材の在庫であるか、保険の顧客名簿であるか等の分類が
できる。あるいは、ＰＡＴＬＩＳのキーワード検索のよ
うな方式を取ることも可能である。性能評価値（又は性
能特性）１４０４は機能評価値（又は機能特性）１４０
３と同様に、システムを機能面から特徴付ける項目をあ
らかじめ設定しておき、それらに評価値を与える。例え
ば、応答性、モジュールサイズ等の項目を設定した場合
はベンチマークによる定量データを使用できる。また、
性能評価値又は性能特性１４０４として、変更の容易性
を示す保守性等利用者の主観による評価のほかに、試験
結果を不具合の改修の程度をしめすシステムの安定性等
も使用できる。尚、事例データベース１１１は、機能評
価値（又は機能特性）１４０３又は性能評価値（又は性
能特性）１４０４に基づく評価関数で検索される。

【００４９】関連付けデータベース１１２は、設計内容
の裏付けを得たり、過去の開発事例の設計からその試験
結果を調べる等、関連情報の検索に使用する関連付けに
ついての情報を格納される。具体的には、定型資料デー
タベース１１０と、以下で詳細に説明する非定型資料デ
ータベース１１３とに格納される全てのデータの間の関
連付けの情報が関連付けデータベース１１２に格納され
る。図１５は関連付けデータベース１１２における関連
付け情報の構成を示す図であり、図において、１５０１
は関連付け番号、１５０２は関連付けの重み付けの値、
１５０３，１５０７はシステム番号、１５０４，１５０
８は成果物番号、１５０５，１５０９は版番号、１５０
６，１５１０はエントリ番号である。このように、１つ
の関連づけ情報には１つの関連づけ番号１５０１が付与
され、１対の関連付けられた成果物のシステム番号、成
果物番号、版番号、及びエントリ番号から構成される。

【００５０】関連付けの重み付けの値は関連づけられる
資料の双方が定型資料であるときにのみ与えられる。関
連付け先が非定型資料の場合は、システム番号１５０３
又は１５０７は非定型資料で有ることを示すマークとな
り、成果物番号１５０８は非定型資料番号となる。関連
付け番号１５０１は、関連付け情報を識別するための番
号であり、全ての関連付けを通して裁番される。システ
ム番号１５０３，１５０７、成果物番号１５０４，１５
０８、版番号１５０５，１５０９、エントリ番号１５０
６，１５１０、非定型資料番号（関連付け先が非定型資
料の場合）は、プロジェクト属性データベース１０８、
定型資料データベース１１０、非定型資料データベース
１１３等のものと共通である。非定型資料であることを
示すマークは、例えばシステム番号１５０３又は１５０
７を１から裁番し、０を非定型資料のマークとすること
で実現できる。尚、関連付けデータベース１１２は、関
連付け番号１５０１で検索される。

【００５１】非定型資料データベース１１３は定型資料
データベース１１０に蓄えられる成果物の裏付け資料と
して参照される外部資料を格納している。具体的には、
議事録、打合せ資料等、定型資料データベース１１０に
格納される以外の情報が格納される。非定型資料には、
表示制御情報が付加される。図１６は非定型資料データ
ベース１１３における非定型資料の形式を示す図であ
り、図において、１６０１は非定型資料番号、１６０２
は非定型資料名称、１６０４は表示識別番号、１６０５
は実体呼び出し番号である。非定型資料香号１６０１
は、定型資料との関連付けられた非定型資料を検索する
ための識別子であり、それらの非定型資料の通し番号で
ある。実体呼び出し番号１６０５は、定型資料と同様に
実体へのアクセスに使用する。表示識別番号１６０４も
定型資料と同様に、非定型資料の表示形式の識別に用い
られる。尚、非定型資料データベース１１３は非定型資
料番号１６０１又は非定型資料名称１６０２で検索され
る。

【００５２】次にデータベースインタフェース１０１の
各部における動作について説明する。表示制御部１０２
は、定型資料データベース１１０及び非定型資料データ
ベース１１３に格納されている定型資料及び非定型資料
の情報の属性に応じて、ＣＲＴ等の表示装置への適切な
表示の制御を行う。表示の形式は表示識別子である表示
識別番号１１０６，１６０４により決定される。

【００５３】属性決定部１０３は、利用者が使用開始時
に入力する利用者名称（図４の利用者名称４０２に対
応）、プロジェクト名称（図２のプロジェクト名称２０
２に対応）、チーム名称（図３のチーム名称３０２に対
応）から、図２に示す形式を有するプロジェクト属性デ
ータベース１０８、及び図４に示す形式を有する利用者
属性データベース１０９を検索して、当該利用者の担当
するシステム番号２０６、製作単位番号等のリストを得
る。チーム名称を入力するのは、複数のチームに重複し
て所属することに対応するためである。成果物の版は最
新を仮定するが、特に指定されたときは、指定された版
の値を使用する。

【００５４】リポジトリ検索部１０４は、属性決定部１
０３が得たシステム番号２０６、モジュール番号３０
６、版番号１２０２から、定型資料データベース１１０
を検索し、利用者が行う作業の対象となる成果物実体番
号１２０１を得る。

【００５５】事例検索部１０５は、利用者が入力するシ
ステムの機能、性能の情報から、事例情報データベース
１１１を検索し、それらのパラメータがもっとも近いシ
ステム番号１４０２を得る。パラメータのマッチングに
は任意の方法を用いてよい。例えば、あらかじめ入力さ
れたパラメータと事例情報データベース１１１内のパラ
メータを用いた評価式をいくつか用意しておき、検索時
にそれらからの選択を許したり、検索時に評価式を自由
に作成させる等の方法がある。いずれの場合も、評価式
の最大化又は最小化を行い、上位のいくつかを結果とし
て出力する。

【００５６】関連決定部１０６は、利用者が定型又は非
定型資料の表示上で選択する関連呼び出し情報から、関
連付けデータベース１１２を検索し、関連付けの他方の
成果物番号１５０４又は１５０８、即ち定型又は非定型
資料番号を得る。外部アクセス部１０７は、定型又は非
定型資料のうち、実体が外部のデータベースに蓄えられ
たものについて、それが蓄えられたデータベースにアク
セスし、当該データを呼び出す。

【００５７】次にこの実施例のソフトウェア開発支援方
式によるソフトウェア開発の動作について説明する。ソ
フトウェアシステムの開発に先立ち、各開発フェーズに
おいて生成すべき成果物のガイドラインをテンプレート
により定めておく。テンプレートは、過去に開発した類
似システムの平均的なシステム構成と、それに含まれる
個々のモジュールの機能、性能とを含む。クラス、モジ
ュール間でのデータのやり取り、関数，ロジックの呼び
出し等の論理的な関係はシステム構成に含まれる。各開
発フェーズ内では、システムのモジュール構成等の情報
に基づき、成果物は相互に関連づけられ、その関連付け
情報が上記した関連付けデータベース１１２に格納され
ている。これ以外に、設計者が着目する成果物の間の関
連づけを自由に行えるように、全ての開発フェーズをま
たがり成果物間の関連付け情報が関連付けデータベース
１１２に格納され得る。関連づけはシステム開発中に生
成される全ての書類を対象とする。仕様を決定するため
の会議の打合議事録、開発チームの間での通信記録等も
関連付けデータベース１１２に取り込み、関連づけの対
象とする。モジュール間の関連づけには相互の関連の強
さによる重み付けを行う。関連付け情報は、モジュール
間の関数の呼び出し等論理的な構造により決定される
が、重み付けを得るためのそれらの客観的な指標が得ら
れないときには、利用者により決定される。重み付けは
成果物の間に限られる。外部資料との関連付けには重み
付けは行わない。

【００５８】図１７、図１８、及び図１９はそれぞれ関
連付けデータベース１１２の関連付け情報を得る処理の
流れを示すフローチャートである。成果物間の関連付け
にはモジュール間の関数等の呼び出し関係等論理的に定
まるものと、利用者が自由に設定するものとの２通りが
ある。前者は、市販のＣＡＳＥツールに含まれるモジュ
ール構成エディタ等でシステム設計を行う過程でその関
連付け情報は自動的にＣＡＳＥツールのデータベースに
登録されるので、その関連付け情報から自動的に生成し
て関連付けデータベース１１２に格納することができ
る。重み付けについては関数間呼び出し等に基づく依存
関係から自動的に定めることができるが、利用者による
上書きを行うことも可能である。

【００５９】他方、後者の場合は、図１７に示すよう
に、ステップＳＴ１において、まず利用者は関連付けを
行いたい２つの資料を選び、各々の任意の位置を指定す
ることによりエントリを設定し両者を関連付ける。ステ
ップＳＴ２において、両方（又は両端）のエントリを設
定したか否かを判定し、まだ両方のエントリを設定して
いないならばステップＳＴ１に戻る。次に、ステップＳ
Ｔ３において、関連付けの両方が定型資料か否か調べ、
関連付けの両方が定型資料である場合は、ステップＳＴ
４において、関連付けの重み付けの値が利用者により設
定される。そして、ステップＳＴ５において、作成した
関連付け情報を登録して終了する。

【００６０】図１７におけるステップＳＴ１のエントリ
設定は図１８のフローチャートに従って実行される。ま
ず、ステップＳＴ１１において、利用者は関連付けを行
いたい２つの資料における各々の任意のエントリ位置を
設定する。自動生成による関連付けと利用者による関連
付けのいずれの場合も、ステップＳＴ１２において、指
定された位置にエントリがあるか否かを判定し、エント
リがないときはステップＳＴ１３及びＳＴ１４において
新たにエントリを作成し登録する。また、図１８のステ
ップＳＴ１１におけるエントリ位置設定は図１９に示す
フローチャートに従って実行される。エントリの位置指
定は、まず、ステップＳＴ２１において、関連づけられ
る資料の任意の部分がブロック図のような構造データか
否かを判定し、ブロック図のような構造データの場合
は、ステップＳＴ２２においてブロック等の要素を指定
し、テキストデータのような非構造データの場合は、ス
テップＳＴ２３において文頭からの位置等座標で指定す
る。

【００６１】関連付けデータベース１１２は、打合せ議
事録、打合せ資料、参考文献等ソフトウェア開発支援方
式が直接関与しない非定型資料と、ソフトウェア開発支
援方式を経由して生成される定型資料である成果物との
間の関連付け情報を管理できるようにしてもよい。この
場合、図１９に示すエントリの位置指定をグラフィック
イメージ等に対応するように修正した、図２０に示すエ
ントリ位置設定のフローチャートで実現される。打合せ
議事録、打合せ資料、参考文献等ソフトウェア開発支援
方式が直接関与しない非定型資料は、写真やＦＡＸの出
力等のイメージを含むために、２次元での位置指定が必
要になる。まず、ステップＳＴ３１において、関連づけ
られる資料の一方が定型資料であるか否かを判定し、定
型資料でないならば、ステップＳＴ３２において、関連
づける情報の位置を２次元で指定する。定型資料である
場合の処理（ステップＳＴ３３〜ＳＴ３５）は、図１９
に示すとおりであるので重複説明は省略する。

【００６２】以上述べたように、全ての成果物を統合デ
ータベースに格納する際に、他の製作単位や他の開発フ
ェーズとの関連付け情報が関連付けデータベース１１２
に記録される。関連付け情報にはシステムの構成により
定まるものと、利用者が自由に設定するものとの２種類
あり、全ての成果物は前者の第１のタイプにより相互に
関連付けられて保存されている。成果物のいずれかを修
正する場合は、その修正内容に応じて関連する成果物を
修正し全体の整合を取る必要があるが、関連付けデータ
ベース１１２に格納された関連付け情報がその助けにな
る。即ち、成果物の間での関連付けを行うことで、ある
モジュールを変更する際に関連するモジュールを検出し
提示することが可能になる。この際、後者の第２のタイ
プの利用者が設定した関連付け情報を辿り背景となる設
計の根拠を知ることで、より正確な判断が下せる。ま
た、関連付け情報は、利用者が関連付けられたモジュー
ルを確認するために呼び出すためにも使用できる。さら
に、関連付けが議事録等の非定型資料にも及ぶことで、
設計内容の背景の確認が容易になり、設計方針の誤った
解釈によるミスを減少させることができる。

【００６３】次に各開発フェーズにおいて生成すべき成
果物のガイドラインを定めるテンプレートについて説明
する。機能設計開発フェーズのテンプレートは各モジュ
ールの機能の記述を含み、詳細設計開発フェーズのテン
プレートは各モジュールの性能の記述を含む。個々のモ
ジュールの機能、性能は、従来のシステムの平均的な内
容を既定値として設定する。ソフトウェアシステムの開
発は、テンプレートに埋め込まれた既定値を、新たに設
計した内容で置き換える方式で行う。テンプレートの例
としては、図７や図８や図９の様な定型資料についての
典型的な構成と内容を持つものである。これらに含まれ
る内容は規定値として用いられる。新たな設計内容で規
定値を置き換えることで、ソフトウェアシステムの設計
を行うことになる。

【００６４】ソフトウェア開発の各開発フェーズ毎にソ
フトウェアの機能、性能の検証を行うにあたり、上記し
たテンプレートの既定値を用いて模擬動作を実行し、部
分的な設計内容がシステム全体に要求される機能、性能
に合致するかどうかを検証する。各開発フェーズでは、
当該開発モジュール毎に記述された機能、性能の内容に
従って動作の模擬を行う。機能設計開発フェーズでは、
システムの動作内容の模擬を行い、詳細設計レベルで
は、応答性等性能に関する模擬を行う。かかる機能、性
能の検証は、図７、図８、図９に示した様な定型資料の
テンプレートを使用して行う。部分的に設計の行われた
成果物は一部の設計内容で既定値が置き換えられている
状態である。

【００６５】図８に示したようなＡＤＦＤには、データ
のやり取りにどのような変換が行われるかが記述され
る。ＡＤＦＤはシステム外部との入出力も記述されるの
で、ＡＤＦＤ上でシステム外部からの入力からシステム
外部への出力までの全てのパスを検証することで、シス
テムが正しくデータを加工しているかどうかを判定でき
る。これによりシステムの機能の検証が行える。この機
能の検証はデータの流れをトレースすることで行うた
め、検証の対象となるモジュールについて全てのデータ
の授受が記述されている必要がある。

【００６６】性能の検証は、図９に示した制御スレッド
図のように、プロセス毎の動作制御を記述した図を用い
て行われる。ここで言うプロセスとはデータの書き換え
や式の計算等、意味のある処理の単位である。制御スレ
ッド図の各プロセスにその処理に必要な時間が添えられ
ている。各プロセスはそれに先行する全てのプロセスが
完了するまで処理を開始できない。制御スレッド図を上
から下にたどりながら、所要時間を集計することで対象
モジュールの応答性能が評価できる。制御スレッド図も
ＡＤＦＤと同様、すべてのプロセスについての処理時
間、前後関係が記述されている必要がある。

【００６７】前述のように設計途上のシステムについて
は、テンプレートの未設計の部分については既定値が埋
め込まれている。設計が完了していない部分については
既定値を用いてトレースすることで、設計が途中のモジ
ュールについても機能、性能の検証が行える。テンプレ
ートの規定値を用いてソフトウェア開発の各開発フェー
ズ毎に、システムを構成する要件が全てそろっているか
どうかを判定することができる。設計作業はテンプレー
ト上の既定値を新たな設計値で置き換えるか、新たな要
素を追加することで行われる。テンプレートの呼び出し
時に各定型資料の要素すべてを、図１１に示す成果物情
報１００３に含まれる未編集リスト１１０８に登録す
る。既定値の置き換え毎に当該要素を未編集リス１１０
８から取り除く。未編集リスト１１０８に要素が残って
いるかどうかが、システム設計完了の判定になる。より
明確に言うと、ソフトウェア開発の進捗を既定値が設計
値ないし設計内容で置き換えられた比率で把握する。既
定値を設計値で置き換える動作を行ったときに、そのモ
ジュールの設計が済であることのマーク付けを行う。モ
ジュールによっては既定値をそのまま使用する場合もあ
るが、この場合も設計が済であることを示すマーク付け
を行う。各モジュールに付けられた設計が済であるか否
かのマークを集計することで、システム開発の進捗を把
握するための指標を提示することが可能になる。

【００６８】以上述べたように、既定値を持つテンプレ
ートを使用することで、システム設計の際の指針を利用
者に与えることができ、設計の効率を向上させることが
できる。また、テンプレートには設計時の漏れを防ぐ効
果もある。さらに、既定値の埋め込まれたテンプレート
を使用することで、個別モジュールの内容を検討するに
際にそのモジュールについては新たに設計した内容を用
いて、残りのモジュールについては既定値を用いて動作
の模擬を行うことにより、設計途上のシステムのための
テンプレート上での機能、性能の検証を行うことがで
き、部分的な設計がシステム全体の要求に合致している
かを確認できる。従って、全体の設計が終わってから機
能性能を見積るのに比べて早い時期での修正が行うこと
ができ、設計上の効率を増すことができる。

【００６９】次に版管理について説明する。ソフトウェ
アをサブシステム、モジュール等に細分化するとき、そ
の各々についての版とそれらを組み合わせた全体の版管
理を行うとともに、関連付けの改訂履歴を含めた版管理
を行う。図１２の定型資料データベース１１０の成果物
実体情報１１０７の構造に示したように成果物実体と版
番号１２０２とを組にして管理することで行う。成果物
実体が修正されて新たな版として登録されたときは、当
該成果物実体を指定された版番号１２０２と組合せて新
たな定型資料として登録する。関連付けが変更されたと
きも新たな版として登録する。関連付けの変更による版
更新は、図１７に示した関連付け登録のフローチャート
に図２１に示したように版更新の処理を追加することで
実現される。図２１に示すように、ステップＳＴ４１に
おいて、まず利用者は関連付けを行いたい２つの資料を
選び、各々の任意の位置を指定することによりエントリ
を設定し両者を関連付ける。ステップＳＴ４２におい
て、両方（又は両端）のエントリを設定したか否かを判
定し、まだ両方のエントリを設定していないならばステ
ップＳＴ４１に戻る。次に、ステップＳＴ４３におい
て、作成した関連付け情報を登録し、ステップＳＴ４４
において、その関連付け情報に関連する成果物等の版を
更新して終了する。版の呼び出しは、プロジェクト属性
データベース１０８、利用者属性データベース１０９及
び定型資料データベース１１０を検索して成果物一覧を
引き出し、各成果物の最新の版を呼び出すことで行う。
特定の版の呼び出しの場合は、指定された版より少ない
値で最大の版番号を持つ版を呼び出す。

【００７０】このように、最小単位毎に版管理を行うこ
とで、関連付けの単位と版管理の単位とが一致すること
になり、関連付けを版毎に管理することが可能になる。
即ち、版情報を実体と分離して管理することで、最小の
製作単位毎の柔軟な版管理が実現でき、外部から取り込
まれた非定型資料等のデータに対しても関連付けが行え
るようになる。

【００７１】次に、図２２に示す利用者の関連情報の呼
び出し処理のフローチャートを参照しながら、利用者が
利用を開始するときに入力する情報に基づいて利用者属
性データベース１０９を含む統合データベースから必要
な情報を呼び出す動作について説明する。既に述べたよ
うに、利用者属性データベース１０９は利用者の参加す
るプロジェクト、プロジェクト内のチーム、担当する部
分等に関する情報を管理している。図２２に示すよう
に、ステップＳＴ５１において、利用者名が入力される
と、ステップＳＴ５２において、属性決定部１０３が、
図４に示す利用者属性データベース１０９の利用者情報
から当該利用者の参加するプロジェクトの情報を得てプ
ロジェクトリストを作成し、ステップＳＴ５３におい
て、そのプロジェクトリストをＣＲＴディスプレイ等の
表示装置に表示する。次に、ステップＳＴ５４におい
て、利用者がそのプロジェクトリストの中から特定のプ
ロジェクトを選択すると、ステップＳＴ５５において、
当該担当者の担当する担当内容を決定し制作単位の成果
物実体を呼び出す。

【００７２】従って、利用者が当該ソフトウェア開発支
援方式の使用開始時に入力する情報をプロジェクト、利
用者の属性と照合し、当該作業に必要な情報を検索、収
集して利用者に提示することが可能になる。次に、開発
中または開発済みのシステムの一部又は全部の機能を変
更するにあたって、システムの成果物の間のシステム構
成上の関係に基づいて、変更内容に直接関与する部分の
改造が影響を及ぼす範囲の見積処理について説明する。
図２３は影響範囲の見積処理の流れを示すフローチャー
トであり、以下この図を参照しながら説明する。まず、
ステップＳＴ６１において利用者が変更対象を選択し改
造対象が決定すると、ステップＳＴ６２において、シス
テム構成上の成果物間の関連付け情報を関連付けデータ
ベース１１２から検索し改造による影響を受ける可能性
のある制作単位を求める。そして、ステップＳＴ６３に
おいて、製作単位毎に改造の及ぼす影響度を計算して、
ステップＳＴ６４において、算出した影響度から影響範
囲を決定する。

【００７３】システム構成上の関連付け情報の表現方式
はシステム設計の方式、実装言語によって違うが、ここ
ではオブジェクト指向分析／設計に基づき、Ｃ＋＋等の
オブジェクト指向言語による実装を行う場合について説
明する。Ｃ＋＋の場合、実装の最小単位はクラスであ
る。クラスの間の関連付け情報は、関数呼び出し、デー
タメンバのアクセス、継承関係である。これらの関連付
け情報は、クラスをノードとし、関数呼び出し、データ
メンバのアクセス、継承関係をアークとする有向グラフ
で表現できる。前述のように、関連付け情報には、論理
構造から定まるか又は利用者により決定される依存関係
の強さの重み付けの値が付加される。アークにはこの重
み付けの値がラベリングされる。以下この有向グラフを
用いてオブジェクト指向言語における影響度の計算につ
いて説明する。

【００７４】改造にあたり直接修正の対象となるクラス
群に対応するノードの集合を原始集合とする。アークの
向きを考慮して有向グラフを探索し、原始集合のノード
から辿れるノードが影響の及ぶ範囲である。ただし、単
純にシステム構成を現す有向グラフ上でこのような探索
を行うと、システム内の要素は互いになんらかの関連を
持つので、全てのノードが影響範囲に含まれる可能性が
高くなる。そこで、各ノードが影響範囲内にあるかどう
かを、原始集合からの経路の長さと、原始集合からの経
路の数を元にして判定する。判定には次の式で表現され
る評価関数を用いる。

【００７５】

【数１】

【００７６】ここで、Ｖはノードの集合、Ｅはアークの
集合である。ｔは継承であるか、参照であるかといった
関連付けタイプ、ｆはタイプによる重み付けの関数であ
る。Ｐはｖとｕの関係に基づいて決まる影響の波及度で
ある。この値は、先に述べた利用者により設定される依
存関係の強さである。この評価関数は原始集合からアー
クをたどりながら再帰的に計算される。各ノードの評価
関数がしきい値より小さくなったときは、そのノードの
評価関数の値を０とする。これにより、０以外の評価関
数の値を持つノードが、影響を受けると予測されるノー
ド群になる。

【００７７】以上の方法で決定されたノードの集合に対
応する成果物単位の集合が、改造の結果影響を受ける可
能性が高いものであると決定される。影響を受けると予
測されるクラス、モジュールが決定されると、影響を受
けるモジュールの担当者、担当チームが検索でき、改造
の内容を連絡すべき相手先として利用者に提示できる。
図２４はかかる担当者の検索処理の流れを示すフローチ
ャートである。このフローチャートは図２３の改造の影
響範囲の見積処理の流れを示すフローチャートに担当者
検索を追加したものである。この図２４に示すように、
上記した図２３のステップＳＴ６１〜ＳＴ６４と同一な
ステップＳＴ７１〜ＳＴ７４で改造の影響範囲が決定さ
れると、ステップＳＴ７５において、求めた改造の影響
範囲に含まれる成果物単位毎に、図１２に示す定型資料
データベース１１０の成果物実体情報から担当の利用者
の情報を検索して獲得する。

【００７８】以上述べたように、システム構成による関
連情報をたどるだけでは、全ての成果物が修正の対象に
なる可能生が高いが、関連付けの強さを反映する評価関
数に基づき影響の度合いを評価することで、特定モジュ
ールの変更のシステム全体への影響の度合いを見積るた
めの評価基準を提示することができる。これにより、個
々の成果物についての修正の必要の有無の指針が得ら
れ、個別に判定するよりも効率良くまた漏れなく修正対
象を決定できる。また、モジュール間の関連付けを辿
り、モジュール毎の担当部門、担当者を定型資料データ
ベース１１０から検索することで、設計時の変更、問題
点の解消のための連絡先又は交渉先を提示することが可
能になる。

【００７９】次に、改造の影響見積と各成果物の工数と
に基づく改造の工数の見積処理について説明する。改造
による工数の見積は、図２３に示した影響範囲の見積処
理と、各成果物毎の工数の見積又は実績とを用いて行わ
れる。図２５はかかる工数計算処理の流れを示すフロー
チャートである。図２５に示すように、上記した図２３
のステップＳＴ６１〜ＳＴ６４と同一なステップＳＴ８
１〜ＳＴ８４で改造の影響範囲が決定されると、ステッ
プＳＴ８５において、求めた改造の影響範囲に含まれる
成果物単位毎に改造の工数を求める。ある変更に伴う改
造の工数は各クラスの工数ｃ（ｖ）を用いて

【数２】 と表現できる。Ｕ（ｖ）は式（１）で求めたクラス毎の
評価関数、即ち影響波及度である。改造の工数の見積は
複数の改造案に対する評価の指標として利用者に提示さ
れる。

【００８０】上記の改造の影響範囲の決定処理等におい
ては、クラスを対象として記述したが、モジュールが対
象であってもよく、モジュールを中心に考えるときは、
モジュールとクラスとの包含関係をもとにして、クラス
間の関連に基づく有向グラフを縮約して得られる有向グ
ラフを用いて同様のことが行える。

【００８１】以上述べたように、改造の工数の予測を行
うことで、仕様変更に対して適切な判断を行い改造の規
模を把握するための情報を提供でき、改造の方式が複数
考えられるような場合に、それらを比較検討するための
指標として使用できる。

【００８２】次に、ユーザが入力するシステムの特徴に
基づいて、統合データベースに蓄えられた過去の開発事
例から、関連の深い事例を選択し提示して、新規開発の
ためのテンプレートとして使用することを可能にする機
能について説明する。図２６はかかる過去の開発事例か
ら類似システムを得る処理の流れを示すフローチャート
である。図２６に示すように、まずステップＳＴ９１に
おいて、利用者がシステムの特徴パラメータを入力する
と、ステップＳＴ９２において、事例検索部１０５が、
図１４の事例データベース１１１に格納された過去の事
例にはそのシステムの機能、性能の評価のパラメータと
して付加された機能評価値１４０３及び性能評価値１４
０４を用い、ユーザの入力した特徴パラメータとこれら
のパラメータとの相関を評価関数により計算する。評価
関数は用途に応じて任意のものを用いてよく、例えば項
目毎の差の二乗の総和で評価する最小２乗誤差等を用い
れば平均的な類似度を評価できる。特定の性質を重視し
たいときは、パラメータ毎に荷重係数をかける等して調
整できる。そして、ステップＳＴ９３において、評価関
数がある閾値より大きいか否かをもって類似システムを
決定する。

【００８３】以上述べたように、テンプレートだけでは
なく、システム、モジュールの機能、性能の評価のパラ
メータを用いて良く似た過去の開発事例を検索して、過
去に開発した類似システム、モジュールを提示でき、利
用者は新規設計時にも設計の方針を得やすくなる。過去
の開発事例に対して設計根拠を提示する機能を有する。
過去の開発事例の根拠の提示は、検索した過去の事例か
らそれに関連づけられている非定型資料を呼び出すこと
で実現できる。これは、関連決定部１０６が関連付けデ
ータベース１１２を検索し関連づけられた過去の事例の
非定型資料番号を得、この非定型資料を加工することな
く、例えば外部アクセス部１０７が現在編集途上の成果
物と同じ形式で呼び出すことにより可能になる。したが
って、過去の事例に関連づけられている非定型資料の呼
び出しは、過去の事例の情報をすべてコピーし、図１１
に示した成果物情報に含まれる編集の進展を示す未編集
リスト１１０８にすべての編集対象をリストアップする
ことにより実行される。

【００８４】以上述べたように、開発事例を検索したと
きに、利用者が自由に設定した成果物間の関連付けをた
どりその過去の開発事例の設計の根拠を知ることで、新
規設計で変更すべき点をより良く把握できる。

【００８５】

【発明の効果】以上のように、請求項１の発明によれ
ば、各開発フェーズで得られる全ての成果物を相互に関
連付ける関連付け情報を格納する統合データベースを設
けたものであるように構成したので、関連づけは利用者
が関連づけられたモジュールを確認するために呼び出す
ためにも使用できる効果がある。

【００８６】請求項２の発明によれば、少なくとも機能
設計及び詳細設計の開発フェーズにおいて、既定値を含
むテンプレートを用いて開発を行うものであるように構
成したので、これにより、システムの設計の際の指針を
利用者に与えることができ、設計の効率を向上させ得
る。また、テンプレートの利用は設計時の漏れも防ぐこ
とができる効果がある。

【００８７】請求項３の発明によれば、各開発フェーズ
の直接の成果物以外の資料と、各開発フェーズにおいて
生成される成果物とを相互に関連付ける関連付け情報を
統合データベースにおいて管理するものであるように構
成したので、このように、関連づけが打合せ議事録等に
も及ぶことで、設計内容の背景の確認が容易になり、設
計方針の誤った解釈によるミスを減少させることができ
る効果がある。

【００８８】請求項４の発明によれば、サブシステム、
モジュールの各々についての版とそれらを組み合わせた
全体の版との管理を行い、且つ、関連付け情報の改訂履
歴を含めた版管理を行うものであるように構成したの
で、最小単位毎に版管理を行うことで、関連付けの単位
と版管理の単位が一致することになり、関連付けを版毎
に管理することが可能になる。関連付け情報を実体と分
離して管理することで、柔軟な関連付けの管理が行え、
外部から取り込まれたデータに対しても関連付けが行え
る効果がある。

【００８９】請求項５の発明によれば、既定値を含むテ
ンプレートを用いて、ソフトウェア開発の各開発フェー
ズ毎にソフトウェアの機能、性能の検証を行うものであ
るように構成したので、既定値の埋め込まれたテンプレ
ートを使用することで、個別のモジュールの内容を検討
するにあたって、そのモジュールについては新たに設計
した内容を用いて、残りのモジュールについては既定値
を用いて動作の模擬を行う可能になる。テンプレート上
で機能、設計の見積を行うことにより、部分的な設計が
システム全体の要求に合致しているかを確認できる効果
がある。

【００９０】請求項６の発明によれば、ソフトウェア開
発の各開発フェーズ毎に、テンプレートの既定値が設計
値で置き換わった割合によりシステムを構成する要件が
全てそろっているか否かを判定するものであるように構
成したので、より具体的には、各モジュールに付けられ
た設計が済であるか否かのマークを集計することで、シ
ステム開発の進捗を把握するための指標を提示すること
ができる効果がある。

【００９１】請求項７の発明によれば、利用者が利用を
開始するときに入力する情報に基づいて、統合データベ
ースから利用者の担当する成果物を呼び出すものである
ように構成したので、従って、利用者がシステムの使用
開始時に入力する情報をプロジェクト、利用者の属性と
照合し、当該作業に必要な情報を検索、収集して提示で
きる効果がある。

【００９２】請求項８の発明によれば、システムの成果
物の間のシステム構成上の関係に基づいて、開発中また
は開発済みのシステムの一部又は全部の機能変更に直接
関与する部分の改造が影響する範囲の見積るものである
ように構成したので、従って、特定モジュールの変更の
システム全体への影響の度合いを見積り、仕様変更に対
する評価基準を提示することができる効果がある。

【００９３】請求項９の発明によれば、影響範囲の見積
とソフトウェア開発の各利用者の担当部分の情報とか
ら、改造の部分の担当者を検索し提示するものであるよ
うに構成したので、即ち、例えばモジュール間のシステ
ム構成上の関係を辿り影響範囲を求め、モジュール毎の
担当部門、担当者を上記の統合データベースから検索す
ることで、設計時の変更、問題点の解消のための連絡
先、即ち改造が必要な部分の担当者を提示することがで
きる効果がある。

【００９４】請求項１０の発明によれば、影響範囲の見
積と各成果物の工数とに基づき、改造の工数の見積を行
うものであるように構成したので、工数の予測を行うこ
とで、改造の規模を把握するための情報が提供でき、改
造の方式が複数考えられるような場合に、それらを比較
検討するための指標として使用できる効果がある。

【００９５】請求項１１の発明によれば、利用者が入力
する開発対象のシステムの特徴に基づいて、過去の開発
事例から開発対象のシステムと関連の深い開発事例を選
択し該開発事例の成果物をテンプレートとして使用する
ものであるように構成したので、システム、より細かく
はモジュールの特徴、即ち機能、性能を検索すること
で、過去に開発した類似システム、モジュールを提示す
ることが可能になる。予め用意されたテンプレートだけ
ではなく、良く似た事例を検索する機能を用いることに
より、新規設計時にも設計の方針を得やすくなる効果が
ある。

【００９６】請求項１２の発明によれば、過去の開発事
例について非定型資料関連付けステップにおいて管理さ
れる開発事例の関連付け情報を参照することにより、開
発事例に関連する情報を提示するものであるように構成
したので、開発事例を検索した際には、関連付け情報を
辿りその開発事例の設計の根拠を知ることで、新規設計
で変更すべき点をより良く把握できる効果がある。

【図面の簡単な説明】

【図１】 この発明の一実施例によるソフトウェア開発
支援方式の構成を示すブロック図である。

【図２】 上記実施例におけるプロジェクト属性データ
ベース１０８に格納されるプロジェクト属性情報のデー
タ構造を示す図である。

【図３】 図２に示すプロジェクト属性情報のうちのチ
ーム情報部分のデータ構造を示す図である。

【図４】 上記実施例における利用者属性データベース
１０９に格納される利用者情報のデータ構造を示す図で
ある。

【図５】 図４の利用者属性情報の参加プロジェクト情
報部分のデータ構造を示す図である。

【図６】 図５の参加プロジェクト情報の担当情報部分
のデータ構造を示す図である。

【図７】 オブジェクト指向設計によるソフトウェア開
発を行う場合の成果物の一例である、オブジェクトの状
態変化を記述したオブジェクト状態モデルの一例を示す
図である。

【図８】 オブジェクト指向設計によるソフトウェア開
発を行う場合の成果物の一例である、プロセス毎の処理
内容とデータの受渡とを記述したアクションデータフロ
ーダイアグラムの一例を示す図である。

【図９】 オブジェクト指向設計によるソフトウェア開
発を行う場合の成果物の一例である、プロセス毎の処理
の制御を記述した制御スレッド図である。

【図１０】 上記実施例における定型資料データベース
１１０に格納される定型資料情報のデータ構造を示す図
である。

【図１１】 図１０の定型情報データベース１１０の成
果物情報１００３のデータ構造を示す図である。

【図１２】 図１１の成果物の実体情報１１０７のデー
タ構造を示す図である。

【図１３】 図１２の成果物の実体情報のうちのエント
リ情報１２０６のデータ構造を示す図である。

【図１４】 事例データベース１１１に格納される事例
データのデータ構造を示す図である。

【図１５】 関連付けデータベース１１２に格納される
関連付けデータのデータ構造を示す図である。

【図１６】 非定型資料データベース１１３に格納され
る非定型資料データのデータ構造を示す図である。

【図１７】 関連付けデータベース１１２に格納する成
果物間の関連付け情報の作成処理の流れを示すフローチ
ャートである。

【図１８】 図１７に示すフローチャートにおけるエン
トリ設定処理の流れを示すフローチャートである。

【図１９】 図１８に示すフローチャートにおけるエン
トリ位置設定処理の流れを示すフローチャートである。

【図２０】 ソフトウェア開発支援方式が直接関与しな
い資料への関連付け処理におけるエントリ位置設定処理
の流れを示すフローチャートである。

【図２１】 関連付けデータベース１１２に格納する成
果物間の関連付け情報の作成処理に伴う版管理の流れを
示すフローチャートである。

【図２２】 利用者の必要とする情報を呼び出す利用者
関連情報呼び出し処理の流れを示すフローチャートであ
る。

【図２３】 ソフトウェア変更時の改造の影響範囲を見
積る影響範囲見積処理の流れを示すフローチャートであ
る。

【図２４】 改造の際に改造部分の担当者を検索する担
当者連絡処理の流れを示すフローチャートである。

【図２５】 改造のための工数の見積を行う工数見積処
理の流れを示すフローチャートである。

【図２６】 ソフトウェア開発の際に関連する過去の開
発事例を呼び出す事例利用開発処理の流れを示すフロー
チャートである。

【図２７】 従来のソフトウェア開発支援方式における
ソフトウェアプロセスモデルの一例であるＶカーブモデ
ルの開発の流れを示す図である。

【符号の説明】

１０８ プロジェクト属性データベース（統合データベ
ース）、１０９ 利用者属性データベース（統合データ
ベース）、１１０ 定型資料データベース（統合データ
ベース）、１１１ 事例データベース（統合データベー
ス）、１１２関連付けデータベース（統合データベー
ス）、１１３ 非定型資料データベース（統合データベ
ース）。

Claims (12)

【特許請求の範囲】
1. 【請求項１】 要求分析、システム設計、機能設計、詳
   細設計、ソースコード生成、オブジェクトコード生成、
   システム結合、単体試験、結合試験、総合試験、運用試
   験の各開発フェーズで得られる全ての成果物に関する情
   報と、前記成果物を相互に関連付ける関連付け情報とを
   共に格納する統合データベースを設けたソフトウェア開
   発支援方式。
2. 【請求項２】 少なくとも前記機能設計及び前記詳細設
   計の開発フェーズにおいて、既定値を含むテンプレート
   を用いて開発を行うテンプレート利用開発ステップを含
   むことを特徴とする請求項１記載のソフトウェア開発支
   援方式。
3. 【請求項３】 打合せ議事録、打合せ資料、及び参考文
   献を少なくとも含む、各前記開発フェーズの直接の成果
   物以外の資料と、各前記開発フェーズにおいて生成され
   る成果物とを相互に関連付ける関連付け情報を前記統合
   データベースにおいて管理する非定型資料関連付けステ
   ップを含むことを特徴とする請求項１記載のソフトウェ
   ア開発支援方式。
4. 【請求項４】 ソフトウェアを少なくともサブシステ
   ム、モジュールに細分化して、その各々についての版と
   それらを組み合わせた全体の版との管理を行い、且つ、
   前記関連付け情報の改訂履歴を含めた版管理を行う版管
   理ステップを含む請求項１から請求項３のうちのいずれ
   か一項記載のソフトウェア開発支援方式。
5. 【請求項５】 既定値を含む前記テンプレートを用い
   て、ソフトウェア開発の各開発フェーズ毎にソフトウェ
   アの機能、性能の検証を行う検証ステップを含むことを
   特徴とする請求項２記載のソフトウェア開発支援方式。
6. 【請求項６】 ソフトウェア開発の前記各開発フェーズ
   毎に、前記テンプレートの既定値が設計値で置き換わっ
   た割合によりシステムを構成する要件が全てそろってい
   るか否かを判定する開発進捗判定ステップを含むことを
   特徴とする請求項２記載のソフトウェア開発支援方式。
7. 【請求項７】 利用者の参加するプロジェクト、プロジ
   ェクト内のチーム、及び前記利用者が担当する部分に関
   する情報を少なくとも管理し、前記利用者が利用を開始
   するときに入力する情報に基づいて、前記統合データベ
   ースから前記利用者の担当する成果物を呼び出す利用者
   関連情報呼び出しステップを含むことを特徴とする請求
   項１記載のソフトウェア開発支援方式。
8. 【請求項８】 開発中または開発済みのシステムの一部
   又は全部の機能を変更する際に、システムの成果物の間
   のシステム構成上の関係に基づいて、前記変更に直接関
   与する部分の改造が影響する範囲の見積る影響範囲見積
   ステップを含むことを特徴とする請求項１記載のソフト
   ウェア開発支援方式。
9. 【請求項９】 前記影響範囲の見積とソフトウェア開発
   の各利用者の担当部分の情報とから、前記改造の部分の
   担当者を検索し提示する担当者検索ステップを含むこと
   を特徴とする請求項８記載のソフトウェア開発支援方
   式。
10. 【請求項１０】 前記影響範囲の見積と各成果物の工数
    とに基づき、前記改造の工数の見積を行う改造工数見積
    ステップを含むことを特徴とする請求項８記載のソフト
    ウェア開発支援方式。
11. 【請求項１１】 利用者が入力する開発対象のシステム
    の特徴に基づいて、過去の開発事例から前記開発対象の
    システムと関連の深い開発事例を選択し該開発事例の成
    果物をテンプレートとして使用する事例利用ステップを
    含むことを特徴とする請求項１記載のソフトウェア開発
    支援方式。
12. 【請求項１２】 過去の開発事例について前記非定型資
    料関連付けステップにおいて管理される前記開発事例の
    関連付け情報を参照することにより、前記開発事例に関
    連する情報を提示する開発事例設計根拠提示ステップを
    含むことを特徴とする請求項３記載のソフトウェア開発
    支援方式。