JPH05298077A - カスタマイズ開発手順支援方法 - Google Patents

Abstract

(57)【要約】 【目的】 多人数でソフトウエアを開発する際に、各開
発部署が各自の開発手順を定義可能とし各開発手順に基
づいたソフトウエア開発を支援する。 【構成】 適用手順を定義、記憶する適用手順決定部１
０１、適用手順部１０３、起動するツールが開発手順に
適するかどうかを判定しユーザを誘導するツール整合部
１０７で構成する。 【効果】 適用手順を定義するだけで適用手順に応じた
設計を誘導できソフトウエア開発支援システム構築の省
力化が可能であること、および適用手順を誘導すること
で設計ドキュメント間での設計内容の整合性を維持でき
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は多人数によってソフトウ
エアを開発する際に仕様書を対話的に編集する設計支援
システムにおいて特に複数の開発部署が各々の開発手順
に基づいてソフトウエア開発を行うための支援システム
に好適な開発手順を定義する方法に関する。

【０００２】

【従来の技術】大規模なソフトウエアを開発する場合、
多数のドキュメント及びプログラムを多人数で分担し設
計を行う。多人数による分担開発を行う際、開発者によ
ってドキュメント内容が異なったり品質にばらつきが生
じないように、従来は開発方法を標準化し各開発者へ遵
守させてきており、計算機でソフトウエアの開発を支援
するシステムにおいても、標準開発手順を保持し開発者
へ遵守させるように設計の手順を誘導する必要がある。

【０００３】従来の技術では、特願平２−７３３１８
「設計支援方法」の発明において開発手順を記憶し開発
者へ手順を提示し設計を誘導する方法の記述がある。該
発明は記憶する開発手順に対して開発者が誤った手順で
開発しようとするとその旨を提示し設計を誘導する技術
である。

【０００４】

【発明が解決しようとする課題】実際に分担開発を行う
場合は、まず開発部署単位で複数人数の開発者のチーム
を構成し、開発部署毎で開発対象を分担する。また各開
発部署内においてさらに各開発者へ分担し、ソフトウエ
アを複数開発部署において並行開発するのが現状であ
る。この場合、標準開発手順を全ての開発部署の全ての
開発者が遵守して行うことは少なく、実状は開発納期等
にあわせて標準開発手順で規定するドキュメント開発順
序を変更したり、あるドキュメントに関しては設計しな
い等、各開発部署で独自の開発手順に基づいて設計を行
っている。

【０００５】ところが上記従来技術では複数の開発部署
が各々ソフトウエア開発を行う際に既に規定する標準開
発手順を各自の開発手順に置き換えて遂行する点に関し
て配慮されておらず、ソフトウエア開発を支援するシス
テムは各開発手順に応じて再構築させなければならなか
った。また各開発部署が各自の開発手順を定義して開発
を遂行するためある時期においては複数の開発手順が存
在することとなり、多数の設計者が同時期に各々の開発
手順に基づいてソフトウエア開発を遂行する点に関して
従来の技術では配慮されていない。またソフトウエアの
開発手順は標準を規定して各開発者へ遵守させるように
提示している。しかし現状では例えば開発の納期が短い
ために標準開発手順を遵守して開発すると納期に間に合
わないことがあり、開発者は標準開発手順の一部を変更
して開発している。また開発部署によって各々の特徴が
あり、例えばある開発部署は完成は早いが品質が悪いと
か、逆に完成は遅いが品質は良いなどの性格をもってい
る。各開発部署は品質劣化や納期遅延を防止しするため
に開発手順を各自で定義して開発のやり方を工夫してい
る。

【０００６】本発明の目的は、各開発部署が各自の開発
手順を定義してソフトウエアの開発を遂行する際に、各
開発手順に基づいたソフトウエア開発支援システムの再
構築を省力化すること、および各開発部署が定義する開
発手順を他部署においても再利用可能とする事である。

【０００７】

【課題を解決するための手段】上記目的を達成するため
に、本発明では各開発部署が各自の開発手順を定義可能
とし、また各々の開発手順に基づいてソフトウエア開発
支援システムで提供する開発ツールの有効性を決定し、
ユーザを誘導することでユーザのソフトウエア開発を支
援したものである。またある開発部署が定義し適用した
開発手順を他部署においても再利用可能とした。

【０００８】

【作用】多人数でソフトウエアを開発する際に対話的に
仕様書を編集するソフトウエア設計支援システムにおい
て、ユーザの定義する開発手順を記憶するステップとド
キュメント種別の一覧を保持するステップと該記憶する
開発手順及びドキュメント種別の一覧より開発手順に適
したドキュメント編集用ツールを判定するステップと該
判定結果を記憶するステップを設けた。またユーザの定
義した開発手順に基づいて開発を誘導するために、ユー
ザがドキュメントを設計するために開発ツールを起動す
る際に、先にツールの有効性を判定した結果に基づい
て、適する場合はツールを起動し適さない場合はその旨
を表示するステップを加えた。これにより各開発部署で
定義した開発手順にもとづいてソフトウエアの設計を支
援する。

【０００９】

【実施例】まず、第１の実施例について説明する。図１
は第１の実施例を実現するための機能構成図である。

【００１０】１０１はユーザ（特に開発部署の取り纏
め）が所属する部署でのソフトウエア開発において適用
する開発手順（開発ドキュメントと開発順序）を決定す
る適用手順決定部である。１０２はユーザがどの開発部
署に所属するか、また該ユーザが取り纏めか開発設計者
かを記憶する部署ユーザ対応部である。適用手順決定部
１０１はまず部署ユーザ対応部１０２で記憶されている
内容を読みとり、適用しようとするユーザの所属部署及
び取り纏めか設計者かを特定する。特定した結果、ユー
ザが取り纏めである場合には手順の適用ができるよう
し、ユーザが開発設計者であった場合には手順の適用は
できないように制限する。これはある部署に所属する各
ユーザが自分の開発手順を定義して開発することによっ
て、部署内での開発ドキュメントの管理を複雑にするこ
とを防止するためである。１０３は適用部署、および適
用した開発手順を記憶する適用手順部である。本適用手
順部１０３は、開発の開始時点で適用手順決定部１０１
において決定し、開発の終了時点で棄却する。適用手順
部１０３は、開発部署の取り纏めユーザが決定し開発部
署での開発を開始させると、開発終了時点までの期間に
おける内容の変更は基本的には認めない。開発の途中の
段階で手順を変更することで設計者に混乱を招くことが
合ってはならないからである。しかし開発途中では様々
な外的要因が発生し手順を変更せざるを得ない場合も生
じる。例えば適用した手順がある程度まで進んでいる状
態で、急きょ開発納期が短縮したなどのの要因で手順を
変更せざるを得ない場合は、現開発段階以降のまだ部署
内では未着手の開発手順に関して変更可能とする。適用
手順決定部１０１の詳細機能構成図を図３、部署ユーザ
対応部１０２の詳細な内容を図４、適用手順部１０３の
詳細な内容を図９で後述する。１０４はユーザが対話的
に仕様を設計するための仕様データ編集部である。仕様
データ編集部はユーザの入力した仕様内容を仕様データ
部１０５へ登録する。また仕様データ編集部は既に設計
した仕様内容を仕様データ部１０５から参照し、ユーザ
の修正、変更を受付け、再度仕様データ部１０５へ登録
する。仕様データ編集部はソフトウエア開発で必要な複
数ドキュメントを編集する。複数ドキュメントとは、例
えばソフトウエアのある開発単位を表すモジュールの詳
細を定義する「モジュール仕様書」であるとか、モジュ
ール間での呼び出し関係を定義する「呼び出し関連図」
などである。従って、仕様データ部１０５は文書や図面
で表現したデータを記憶する。１０６はユーザがあるド
キュメントから別のドキュメントを生成する仕様データ
生成部である。例えば「呼び出し関連図」ドキュメント
から「モジュール仕様書」ドキュメントを生成する。仕
様データ生成部は上述の例以外にも複数の生成手段を有
している。１０７は１０３の適用手順を読み込み、ユー
ザが実行しようとする仕様データ編集部１０４または仕
様データ生成部１０６が適用手順に従っているかどうか
を判定し、従っていない場合にその旨をユーザに提示す
るツール整合部である。ツール整合部１０７の詳細は図
１０で後述する。

【００１１】図２は本実施例を実現するためのハードウ
エア構成図である。

【００１２】２０１は本実施例を実現するプログラムを
処理し、実行するＣＰＵである。２０２はマウス等のユ
ーザが入力するポインティングデバイスである。２０３
はキーボードで、ユーザが仕様データなどを入力するデ
バイスである。２０４はＣＰＵの処理結果等をユーザに
出力するＣＲＴである。２０５は本プログラムや扱うデ
ータなどを記憶する主記憶メモリである。２０６は本プ
ログラムや扱うデータなどを記憶する外部記憶装置であ
る。２０７はＣＰＵの処理結果等をユーザに出力するプ
リンタである。

【００１３】図３は図１の適用手順決定部１０１を詳細
に説明するための機能構成図である。本図内の点線で囲
まれた部分が適用手順決定部１０１である。適用手順決
定部１０１は、まず手順を適用しようとするユーザが所
属する部署および部署取り纏めか開発設計者かを特定す
るために、ユーザ識別部３０１を実行する。ユーザ識別
部３０１は、まず適用しようとするユーザからユーザの
名称もしくは識別子を受け付ける。次に部署ユーザ対応
部１０２で記憶する内容を読みとり、受け付けたユーザ
名称もしくは識別子から該ユーザの所属部署及び部署取
り纏めか開発設計者かを特定する。もしユーザが部署の
取り纏めである場合、開発手順を適用するための手続き
を続けることができるが、開発設計者であった場合は、
「開発手順の適用はできない」などのメッセージを表示
し、適用のための手続きを終了する。

【００１４】図４は部署ユーザ対応部１０２の記憶内容
の例を示す。部署ユーザ対応部１０２は例えば部署名欄
４０１、ユーザ名欄４０２、役職欄４０３で構成する。
図４では「ＦＡＸ開発部」「交換器開発部」の２部署と
各部署に所属するユーザ名称および役職を定義してい
る。従ってユーザの名称が例えば「山田」とすると、ユ
ーザ識別部３０１は、ユーザから受け付けた名称が「山
田」を部署ユーザ対応部１０２のユーザ名欄４０２から
検索し、該当する部署を部署名欄４０１から、また役職
を役職欄４０３から特定する。ユーザ識別部３０１は、
この場合「山田」の所属部署が「ＦＡＸ開発部」で役職
が「取り纏め」という結果を得、「山田」は「取り纏
め」であるがゆえに次の適用手順の手続きを継続実行す
ることができる。またユーザの名称が例えば「田中」で
あった場合、ユーザ識別部３０１は結果として所属部署
が「ＦＡＸ開発部」で役職が「開発設計者」を得る。従
って、「田中」の場合、「開発手順の適用はできませ
ん」などのメッセージを表示して手順適用の手続きを終
了する。上述の例ではユーザを表現するためにユーザの
名称を用いたが、代わりにユーザの識別子であってもよ
い。例えば「User ID: 123456789」である。この場合、
部署ユーザ対応部１０２のユーザ名称欄４０２をユーザ
識別子欄とし、またユーザ識別部３０１がユーザから受
け付ける内容も、ユーザの名称の代わりに識別子とすれ
ば、上述のユーザ識別部３０１は容易に実現可能であ
る。３０２は適用しようとする手順を定義する手順定義
部である。手順定義部３０２はユーザ識別部３０１が
「取り纏め」と判定したユーザに対して実行する。手順
定義部３０２はユーザが対話的に適用手順を定義できる
ように、ユーザに対して図５でしめす手順定義画面を表
示する。

【００１５】図５は手順定義画面のレイアウト例を示
す。３０３は過去に適用した開発手順を記憶する開発手
順部である。開発手順部の記憶する内容を図６で示す。
図６では、過去に適用した２つの開発手順を示してい
る。各々の手順は次の４つの欄で表現する。手順を識別
するための手順Ｎｏ欄６０１、手順の内容を簡単に説明
するための手順内容欄６０２、適用手順として開発の順
序を規定するための開発フェーズ欄６０３、各開発フェ
ーズで開発するドキュメントを定義する開発ドキュメン
ト欄６０４である。まず、手順Ｎｏ．欄６０１が「１」
の手順の場合について説明する。本手順はある「Ａ工
場」で定義した「規格No.H234」という「標準開発手
順」であることを示す。また適用手順として４つの開発
フェーズからなり、各フェーズで開発するドキュメント
を定義している。開発フェーズはこの場合、数値で表現
しており、数値の小さい順に開発を進めていくことを表
す。開発フェーズ「１」の場合、開発ドキュメントとし
て「呼び出し関連図」「モジュール関連図」「状態遷移
表」「テーブル関連図」の４種類を開発する。同一フェ
ーズでは、どのドキュメントから開発を始めてもよい。
ただし、１つの開発フェーズが終了しないと、次の開発
フェーズへはすすめない。４種類のドキュメントの開発
が終了すると、次開発フェーズ「２」へと進み、「モジ
ュール仕様書」「テーブル仕様書」の２種類のドキュメ
ントの開発へとりかかるのである。次に手順Ｎｏ欄６０
１が「２」の手順の場合、「納期重視型開発手順」で、
開発フェーズは３つ、開発ドキュメントは合計６種類で
あることを示している。図３での開発手順部３０３で記
憶する手順は、図６では２種類であるが、他の開発手順
も含め複数記憶可能である。

【００１６】図７は、ユーザが適用手順として手順Ｎ
ｏ．２の手順を定義した例を示す。定義するためのユー
ザ操作として、「開発手順リスト」のプルダウンメニュ
ー７０１より適用手順Ｎｏ．「２」をポインティングデ
バイスであるマウスカーソル７０２で指定する。この場
合、開発手順部３０３で記憶する手順Ｎｏ．２の開発手
順を読み込み、適用手順Ｎｏ欄７０３に手順Ｎｏ．であ
る「２」、適用手順欄７０４に適用手順の内容を表示す
る。適用部署欄７０５はユーザがキーボードより入力す
るか、または先のユーザ識別部３０１で特定した部署を
用いる。

【００１７】７０６で示す「確定」をユーザがマウスカ
ーソル７０２で指定すると、適用手順定義部３０２はユ
ーザが定義した開発手順を開発部署に適用するものとし
て、適用手順部１０３へ登録し、適用の手続きを終了す
る。また７０７の「終了」をユーザがマウスカーソル７
０２で指定すると、定義した手順を棄却して適用の手順
を終了する。７０８で示す「適用事例」をユーザがマウ
スカーソル７０２で指定すると、適用手順定義部３０３
は、適用事例表示部３０４を実行する。適用事例表示部
は手順適用事例部３０５で記憶している過去に適用した
手順の開発履歴を読み込み、ＣＲＴやプリンタ等へ表
示、印刷する。

【００１８】図８は手順適用事例部３０５で記憶する内
容を示す。手順適用事例部は例えば次の６種類の欄で構
成する。手順Ｎｏ欄８０１は過去に適用した手順のＮｏ
を表す。適用部署欄８０２は適用先である部署の名称を
表す。適用製品欄８０３は手順を適用して開発した製品
の名称を表す。開発期間欄８０４は手順を適用して製品
を開発した期間を表す。開発規模欄８０５は開発製品の
ステップ数を表す。開発人員欄８０６は開発に投じた人
員を表す。手順適用事例部３０５のこれらの内容を手順
定義時にユーザへ表示することで、過去と同じ状況、例
えば開発期間が半年以内であるとか、開発人員が１０人
未満、推定開発規模２０キロステップ以下であるといっ
た条件より過去の適用手順を調べることで、自分がこれ
から適用しようとする最適な手順は何かを判断しやすい
ようにすることを目的としている。ユーザが「確定」と
した手順は適用手順部１０３へ登録する。

【００１９】図９は適用手順部１０３の内容例を示す。
図９は適用部署（欄９０１）が「ＦＡＸ開発部」、開発
手順ＮＯ．（適用手順Ｎｏ欄９０２）が「２」、適用手
順として９０３欄、９０４欄の内容であることを示す。
適用手順部１０３で記憶する内容は、開発が終了するま
で保持する。手順登録部３０６は開発終了後に、適用し
た手順の内容を適用製品、開発期間、開発人員などの情
報と対応づけて手順適用事例部３０５へ登録する。さら
に、適用手順が開発手順部３０３で記憶する手順とは別
の新規の手順である場合には適用手順部３０３へ該適用
手順を登録する。登録の全ての手続きが終了した時点
で、適用手順部１０３内に記憶する開発部署の適用手順
を棄却する。

【００２０】図１０は図１で示したツール整合部１０７
の内容を詳細に表す機能構成図である。図中の点線で囲
んだ部分がツール整合部１０７である。ツール整合部１
０７は設計者に対して適用開発手順に基づく仕様データ
の編集及び仕様データの生成を支援する。開発手順を適
用すると、ツール整合部１０７はまず１００１である支
援ツール有効判定部を起動する。支援ツール有効判定部
１００１は適用手順部１０３で記憶する適用手順と、ド
キュメントエディタ一覧部１００２、ドキュメント間生
成ツール一覧部１００３を読み込む。ドキュメントエデ
ィタ一覧部１００２は仕様データ編集部１０４でサポー
トするドキュメントの編集機能の一覧を保持している。
ドキュメントエディタ一覧部１００２の内容を図１１で
示す。ドキュメントエディタ一覧部はドキュメントのＮ
ｏ欄、ドキュメント名称欄およびドキュメントを編集す
るプログラムの名称、即ちツール名欄からなる。図１０
の仕様データ編集部１０４は、ドキュメントエディタ一
覧部１００３のツール名欄で定義するプログラムの集合
である。

【００２１】図１１で記述する例では、１２種類のドキ
ュメントを定義している。また、ドキュメント間生成ツ
ール一覧部１００３は仕様データ生成部でサポートする
生成機能の一覧を保持している。図１２はドキュメント
間生成ツール一覧部１００３の内容を示す。Ｎｏ欄、生
成ツール名称欄、生成元となるドキュメントの名称欄、
および生成するドキュメントの名称欄からなる。生成元
ドキュメントとは生成ツールにとって入力となるドキュ
メントで、生成先ドキュメントとは生成ツールにとって
出力となるドキュメントである。さらに生成ツール欄で
定義するプログラムの集合が、図１０の仕様データ生成
部１０６である。図１２では２０種類の生成ツールを定
義している。

【００２２】図１３は図１１のドキュメントと図１２の
ドキュメント生成ツールとの関係を図で表現したもので
ある。本図の方形がドキュメントを表し、丸形が生成ツ
ールを表している。

【００２３】図１４は図６でしめす手順Ｎｏ１の開発手
順が適用された場合、ドキュメントおよび生成ツールと
開発フェーズとの関係を表している。図１４では適用開
発手順に適するドキュメントと生成ツールを示す。本図
中の例では全てのドキュメントは開発手順に適している
が、生成ツールは一部適さないものがあることを示して
いる。開発手順に適さないとは、開発フェーズの順序に
従って設計されるべきドキュメントが後フェーズで開発
されたドキュメントから生成される、ことを意味する。
つまり開発フェーズの順序に逆らった生成ツールが開発
手順に適さないのである。

【００２４】図１５は図９で示す開発手順を適用した場
合のドキュメントおよび生成ツールと開発フェーズとの
関係を表している。本図の例で示す開発手順に適するド
キュメントが６種類、生成ツールが４種類である。従っ
て開発手順に適さないという意味は、前述の内容の他に
適用開発手順では設計しないドキュメントをもさすので
ある。本図の場合、適用手順に適さないドキュメントは
６種類、生成ツールは１６種類に及ぶ。

【００２５】図１０で示す支援ツール有効判定部１００
１は、適用手順に適するドキュメント及び生成ツールを
特定する機能を有する。適するか適さないかの判断を行
うための材料として、適用手順部１０３（内容は図
９）、ドキュメントエディタ一覧部１００２（内容は図
１１）、ドキュメント間生成ツール一覧（内容は図１
２）を用いる。支援ツール判定部１００１の判定結果を
判定結果部１００４へ記憶する。

【００２６】図１６は判定結果部１００４の内容例を示
す。図１６では、判定結果部の内容を次の４欄で構成す
る。手順Ｎｏ欄１４０１は適用中の開発手順のＮｏを表
す。適用部署欄１４０２は適用中の開発部署を表す。エ
ディタ欄１４０３は仕様データ編集部１０４の保持する
ドキュメントのＮｏと各々のドキュメントが適用中の開
発手順に適するかどうかの判定結果を有している。生成
ツール欄１４０４は仕様データ生成部１０６の保持する
生成ツールのＮｏと各ツールが適用中の開発手順に適す
るかどうかの判定結果を有している。エディタ欄１４０
３と生成ツール欄１４０４中の「○」が適用中の開発手
順に適することを表しており、「×」が適さないことを
表している。支援ツール判定部１００１の判定アルゴリ
ズムを図１８で後述する。

【００２７】図１０で示すように、ある開発設計者が設
計に着手しようとする場合、ユーザ識別部１００５がユ
ーザの所属する開発部署を識別する。ユーザ識別部は図
３で示すユーザ識別部３０１と同様の機能を有する。仕
様データ編集制御部１００６は、ユーザが仕様データ編
集部１０４をもちいてあるドキュメントを設計しようと
すると、ユーザ識別部１００５で特定したユーザの所属
開発部署から判定結果部１００４で記憶する適用開発手
順の判定結果を読みとり、ユーザが設計しようとするド
キュメントが開発手順に適するものかどうかを判定結果
から検索し、適するものであればドキュメントのエディ
タを起動し、適さないものであればその旨をユーザに表
示する機能を有する。仕様データ生成制御部１００７
は、仕様データ編集制御部１００６と同様、あるユーザ
がドキュメントから別のドキュメントを生成するために
仕様データ生成部１０６の生成ツールを起動しようとす
ると、その生成ツールが開発手順に適するかどうかを先
述の通り調べ、適する場合は生成ツールを起動し、適さ
ない場合はその旨をユーザに表示するものである。図１
７はユーザが設計しようとしたときに仕様データ編集制
御部１００６および仕様データ生成制御部１００７が表
示する内容を表す。

【００２８】図１８（ａ）（ｂ）は図１の適用手順決定
部１０１を実現するアルゴリズムを表すフローチャート
である。まず図１８(a)から説明する。

【００２９】ユーザ識別ステップ１６０１はユーザの開
発部署および役職を判別する。役職が開発部署取り纏め
であった場合次のステップを実行するが、役職が開発設
計者であった場合は処理を終了する。コマンド入力ステ
ップ１６０２はユーザからキーボード２０３またはマウ
ス２０２よりコマンドを入力する。コマンド判定ステッ
プ１６０３はステップ１６０２でユーザより受け付けた
コマンドを解析しコマンドの内容に応じて次の実行すべ
きステップを決定する。ユーザからの入力が「開発手順
Ｎｏ」を表す数値であった場合ステップ１６０４を実行
する。「手順適用事例表示」コマンドであればステップ
１６０６、「手順定義」コマンドであればステップ１６
０８、「確定」コマンドであればステップ１６１０、
「終了」コマンドであれば終了へと次の処理を実行す
る。ステップ１６０４はユーザの入力した手順Ｎｏの開
発手順を開発手順部３０３で記憶する内容から読み込む
ステップである。ステップ１６０５はステップ１６０４
の読み込んだ開発手順および手順ＮｏをＣＲＴ２０４へ
出力しユーザへ提示する。処理はその後ステップ１６０
２へ戻る。ステップ１６０６はユーザが手順適用事例表
示のコマンドを入力した場合適用手順事例部３０５より
読み込む。ステップ１６０７はステップ１６０６の読み
込んだ手順適用事例をＣＲＴ２０４へ出力する。処理は
その後ステップ１６０２へ戻る。ステップ１６０８はユ
ーザが手順定義のコマンドを入力した場合開発フェーズ
を入力するステップである。ステップ１６０９はステッ
プ１６０８で入力した開発フェーズに対応する開発ドキ
ュメントを入力する。処理はその後ステップ１６０２へ
戻る。ステップ１６１０はユーザが「確定」コマンドを
入力した場合、適用する手順を定義しているかどうか判
別するステップである。ユーザが適用手順を定義してい
た場合は、ステップ１６１１において適用手順を適用手
順部１０３へ登録する。ユーザが適用手順を定義してい
なかった場合は、「適用手順を定義してから確定してく
ださい」のメッセージを表示し処理をステップ１６０２
へ戻す。ステップ１６１１で適用手順を登録した後は本
アルゴリズムを終了する。ステップ１６０２においてユ
ーザが終了コマンドを入力した場合は本アルゴリズムを
終了する。本アルゴリズムの例のように手順適用事例の
表示と適用手順の定義とを同時に実行させることで、ユ
ーザは適用する手順を定義する際過去に適用した手順や
適用先の開発製品、開発期間、人員等を参照しながら自
開発部署の特徴と類似した過去の例を参照しながら、適
した開発手順を定義することができる。

【００３０】図１９は図１０で示す支援ツール有効判定
部１００１の機能を実現するためのアルゴリズムの一部
を表しており、ドキュメントエディタに対する有効性の
判定を行う。ステップ１７０１はドキュメントエディタ
一覧部１００２に記憶されている全てのドキュメントを
読み込む。ステップ１７０２は先に読み込んだ全てのド
キュメントの判定結果を「無効」（本アルゴリズムでは
「×」印）と初期化する。ステップ１７０３はユーザの
定義した適用手順部１０３に記憶する開発手順から１つ
の開発ドキュメントの名称を読み込む。ステップ１７０
４はステップ１７０３において読み込もうとした開発ド
キュメントが存在するかどうかを判定する。つまり適用
手順部１０３に記憶する開発ドキュメントを全て読み込
んだかどうかを判定する。まだ読み込んでいないドキュ
メントがある場合はステップ１７０５へと進み判定処理
を続ける。全て読み込んでいた場合はステップ１７０６
へと進み最後の処理を行う。ステップ１７０５は読み込
んだドキュメントを「有効」（本アルゴリズムでは
「○」印）と定義する。処理はステップ１７０３へと移
行し、次の開発ドキュメントの読み込みステップ１７０
３へと続く。ステップ１７０６は全てのドキュメントの
判定結果を判定結果部１００４へ登録する。登録する判
定結果の内容は図１６エディタ欄１４０３で既に示し
た。ステップ１７０６の実行後、本アルゴリズムを終了
する。

【００３１】図２０は図１０で示す支援ツール有効判定
部１００１の機能を実現するためのアルゴリズムの一部
を表しており、ドキュメントの生成ツールに対する有効
性の判定を行う。ステップ１８０１は図１０で示すドキ
ュメント間生成ツール一覧部１００３で記憶する全ての
生成ツールの名称を読み込む。ステップ１８０２は先に
読み込んだ全ての生成ツールの判定結果を「無効」（本
アルゴリズムでは「×」印）と定義し初期化する。ステ
ップ１８０３は同一開発フェーズとして定義した開発ド
キュメント間での生成ツールにおける判定を実行する。
詳細は図２１で示す。ステップ１８０４は異なる開発フ
ェーズ間でのドキュメント間での生成ツールにおける判
定を実行する。詳細は図２２で示す。ステップ１８０５
は全ての生成ツールの判定結果を図１０で示す判定結果
部１００４へ登録する。

【００３２】図２１は図２０で示すステップ１８０３の
詳細アルゴリズムである。同一フェーズで開発するドキ
ュメント間の生成ツールの判定とは、例えば図１５でに
おいては、開発フェーズ１で開発する「モジュール仕様
書」「テーブル仕様書」ドキュメント間の生成ツール
「Ｎｏ８」における有効性の判定を行うことである。ス
テップ１９０１は判定対象とする開発フェーズの値を保
持する「（開発フェーズ）」変数を定義し値「１」を代
入して初期化する。ステップ１９０２は（開発フェー
ズ）変数の値と適用手順で定義する開発フェーズの最大
値との代償関係を判定しする。（開発フェーズ）変数値
が最大値以下である場合、即ち「（変数値）≦（最大
値）」と判定した場合はステップ１９０３へ進み、処理
を継続する。変数値が最大値より大きい場合、即ち
「（変数値）＞（最大値）」と判定した場合は本アルゴ
リズムを終了する。ステップ１９０３は（開発フェー
ズ）変数の値で示す開発フェーズに対応する全ての開発
ドキュメントの名称を読み込む。ステップ１９０４は先
に読み込んだ開発ドキュメントの数が１つかまたは２つ
以上かを判定する。読み込んだ開発ドキュメントが１つ
の場合はステップ１９０９へ進み、次の開発フェーズの
判定処理に移行するため、（開発フェーズ）の値を
「１」増分させる。複数合った場合は次のステップ１９
０５を実行する。ステップ１９０５は先に読み込んだ全
てのドキュメントから２つ選択する。ステップ１９０６
は先の２つのドキュメントの組み合わせが全て選択され
たかどうかを判定する。全ての組み合わせを選択してい
た場合はステップ１９０９へ進み、次の開発フェーズの
判定処理に移行する。全ての組み合わせを選択していな
かった場合は、次のステップ１９０７へ進む。ステップ
１９０７は先に選択した２つのドキュメント間で生成ツ
ールが定義されているかどうかを図１０で示すドキュメ
ント間生成ツール一覧部１００３で記憶する内容を検索
し判定する。生成ツールが定義されている場合は、次の
ステップ１９０８においてその生成ツールを「有効」
（本アルゴリズムでは「○」印）と定義する。２つのド
キュメント間で生成ツールが定義されていなかった場合
は、処理１９０５へ移行し次の２つのドキュメントの組
み合わせを調べる。

【００３３】図２２は図２０で示すステップ１８０４の
詳細アルゴリズムである。異なるフェーズで開発するド
キュメント間の生成ツールの判定とは、例えば図１５で
においては、フェーズ１で開発する「モジュール仕様
書」ドキュメントとフェーズ３で開発する「呼び出し関
連図」ドキュメント間の生成ツール「Ｎｏ２」における
有効性の判定を行うことである。ステップ２００１は判
定の基準とする開発フェーズの値を保持する「（開発フ
ェーズ）」変数に「０」を代入し初期化する。ステップ
２００２は（開発フェーズ）変数の値を「１」増分させ
る。ステップ２００３は（開発フェーズ）の変数値と適
用手順で定義した開発フェーズの最大値との大小関係を
判定する。変数値が最大値よりも小さい場合、即ち
「（変数値）＜（最大値）」となった場合は処理２００
４へ移行し（変数値）の開発フェーズに基づく判定処理
を継続する。変数値が最大値以上であった場合、即ち
「（変数値）≧（最大値）」と判定した場合は本アルゴ
リズムを終了する。ステップ２００４はユーザの定義し
た適用手順部１０３に記憶する開発手順から（開発フェ
ーズ）で定義する開発ドキュメントの名称を１つ読み込
む（これをドキュメントＡとする）。ステップ２００５
はステップ２００４において読み込もうとした開発ドキ
ュメントが存在するかどうかを判定する。つまり適用手
順部１０３に記憶する開発ドキュメントを全て読み込ん
だかどうかを判定する。まだ読み込んでいないドキュメ
ントがある場合はステップ２００６へと進み処理を続け
る。全て読み込んでいた場合はステップ２００２へと戻
り次の（開発フェーズ）における処理へと移行する。ス
テップ２００６は生成先ドキュメントの開発フェーズを
保持する（生成先開発フェーズ）変数に（開発フェー
ズ）の値を代入し初期化する。本アルゴリズムの場合、
（開発フェーズ）は生成元の開発フェーズを表してい
る。ステップ２００６において（生成先開発フェーズ）
を「１」でなく（開発フェーズ）変数値にした理由は、
（開発フェーズ）＜（生成先開発フェーズ）の関係でド
キュメントを生成するツールが有効であるため、（生成
先開発フェーズ）を「１」から調べる必要がないからで
ある。ステップ２００７は（生成先開発フェーズ）の値
を「１」増分する。ステップ２００８は（生成先開発フ
ェーズ）の変数値と適用手順で定義する開発フェーズの
最大値との大小関係を判定する。「（変数値）≦（最大
値）」と判定した場合、ステップ２００９を実行し
「（変数値）＞（最大値）」と判定した場合は、ステッ
プ２００４へ戻り別の生成元ドキュメントに対する判定
処理を継続する。ステップ２００９は（生成先開発フェ
ーズ）の値に対応する開発フェーズで定義するドキュメ
ントの名称を１つ読み込む（ドキュメントＢとする）。
ステップ２０１０は先の生成先ドキュメントを全て読み
込んだかどうかを判定する。全て読み込んでいない場合
はステップ２０１１へ進み、全て読み込んだ場合はステ
ップ２００７へ戻り次の（生成先開発フェーズ）での判
定処理を継続する。ステップ２０１１は生成元であるド
キュメントＡと生成先であるドキュメントＢとの間に生
成ツールが定義されているかどうかを判定する。生成ツ
ールが定義されている場合はステップ２０１２において
その生成ツールを「有効」（本アルゴリズムでは「○」
印）と定義する。ステップ２０１１で生成ツールが定義
されていない場合はステップ２００９へ戻り次の生成先
ドキュメントに関する判定処理を継続する。以上図２
１、図２２で示した判定アルゴリズムによって、生成ツ
ールの判定結果を得ることができ、図２０で示すステッ
プ１８０５において有効性の判定結果を登録するのであ
る。

【００３４】図２３(a)(b)はそれぞれ図１０で示す仕様
データ編集制御部１００６および仕様データ生成制御部
１００７を実現するアルゴリズムである。まず、仕様デ
ータ編集制御部１００６の実現アルゴリズムを(a)で説
明する。ステップ２１０１は起動しようとするドキュメ
ントに対応する判定結果を読み込む。ステップ２１０２
は読み込んだ判定結果が「有効（本図では”○”印）」
かどうかを判定し、「有効」である場合は、ステップ２
１０３で示すとおりドキュメントエディタを起動する。
「有効」でない場合、ステップ２１０４で示すとおり、
「本ドキュメントは適用手順では無効です」を表示し、
本ドキュメントが適用手順では適していない旨をユーザ
に提示する。次に仕様データ生成制御部１００６の実現
アルゴリズムを(b)で説明する。ステップ２１１１は起
動しようとする生成ツールに対応する判定結果を読み込
む。ステップ２１１２は読み込んだ判定結果が「有効
（本図では”○”印」かどうかを判定する。「有効」で
あった場合、ステップ２１１３で生成ツールを起動し、
「有効」でなかった場合「本生成ツールは適用手順では
無効です」を表示し、本生成ツールが適用手順では適し
ていない旨をユーザに提示する。

【００３５】次に第２の実施例について説明する。第１
の実施例における支援ツール有効判定部１００１の判定
結果では「有効」「無効」の２種類であったのを、第２
の実施例では「有効」「中間」「無効」の３種類に増や
す。第１の実施例と第２の実施例との差分を図１５およ
び図２４を用いて説明する。図１５は手順Ｎｏ２の適用
手順の場合の支援ツール有効判定部１００１の判定結果
を示す。この図によると無効となるドキュメントが６種
類、および生成ツールが１６種類と全ツールの半数以上
が「無効」と判定している。図２４は第２の実施例にお
ける判定結果を示す。図２４では無効となるドキュメン
トを２種類、生成ツールを５種類と第１の実施例での
「無効」と判定するツールの種類を減らす。これにより
適用手順に有効な支援ツールの種類を増やし利用の幅を
広げる。第２の実施例では次のツールを「中間」と判定
する。即ち中間ドキュメントのエディタと中間ドキュメ
ント間の生成ツールである。中間ドキュメントとは例え
ば図２４の場合「ＰＡＤ」「引き数シート」などのドキ
ュメントで、中間生成ツールは「１１」「１２」「１
３」などである。中間ドキュメントは適用手順で定義す
る２つのドキュメントの間をつなげるためのドキュメン
トで、例えば「モジュール仕様書」の記述後、次の開発
フェーズで定義する「ソースリスト」を記述する前に、
生成ツール「９」を用いて生成する「引き数シート」で
ある。中間生成ツールは中間ドキュメントを生成するた
めの生成ツール、および中間ドキュメントから次の開発
フェーズにおいて定義するドキュメントを生成するツー
ルで、例えば先の生成ツール「９」が該当する。「中
間」という判断結果は、適用手順では定義していないが
設計手段としては有効であることを明示する。

【００３６】図２５は手順Ｎｏ２Ｎｏ適用手順における
第２の実施例の判定結果である。「有効（本図では”
○”印）」「中間（本図では”△”印）」「無効（本図
では”×”印）」と各ツールを３種類に判定する。図２
６は図１０で示す支援ツール有効判定部１００１の実施
例２における実現アルゴリズムを表す。ステップ２４０
１は有効ドキュメント判定処理でドキュメントの「有
効」「無効」の２種類を第１の実施例通りに判定する処
理である。詳細なアルゴリズムは図１９で示すとおりで
ある。ステップ２４０２はドキュメントに対して「中
間」を判定するための中間ドキュメント判定処理であ
る。先のステップ２４０１で２種類に判定した結果を用
いて、特に「無効」と判定したドキュメントのうち中間
ドキュメントとして利用可能なドキュメントを「中間」
と判定する。詳細なアルゴリズムを図２７で示す。ステ
ップ２４０３は生成ツールに対して「有効」「無効」
「中間」の３種類の判定を実行する生成ツール判定処理
である。詳細アルゴリズムを図２８、図２９を用いて後
述する。

【００３７】図２７は図２６のステップ２４０２の中間
ドキュメント判定処理の詳細アルゴリズムである。ステ
ップ２５０１は、判定結果が「有効」でかつ異なる開発
フェーズで設計する２つのドキュメントを選択する。２
つのドキュメントの内先の開発フェーズで設計するドキ
ュメントを「ドキュメントＡ」、後の開発フェーズで設
計するドキュメントを「ドキュメントＢ」とする。ステ
ップ２５０２は選択する２つのドキュメントの組み合わ
せが全て終了したかどうかを判定する。全ての組み合わ
せを終了していない場合はステップ２５０３へ続き、終
了した場合は本アルゴリズムを終了する。ステップ２５
０３は「ドキュメントＡ」を生成元とする生成ツールを
検索する。説明上検索した生成ツールを「生成ツール
Ｐ」とする。ステップ２５０４は「生成ツールＰ」があ
るかどうかを判定する。「生成ツールＰ」がある場合は
ステップ２５０５を実行し、ない場合はステップ２５０
９を実行する。ステップ２５０５は「生成ツールＰ」の
生成先ドキュメントの名称を読み込む（「ドキュメント
Ｃ」と呼ぶ）。ステップ２５０６は「ドキュメントＣ」
を生成元、「ドキュメントＢ」を生成先とする生成ツー
ルを検索する（「生成ツールＱ」とする）。ステップ２
５０７は「生成ツールＱ」が存在するかどうかを判定す
る。存在する場合はステップ２５０８を実行し、存在し
ない場合はステップ２５０３へ戻り次の生成ツールを検
索する。ステップ２５０８はドキュメントＣの判定結果
を読み込む。ステップ２５０９はドキュメントＣの判定
結果が「無効」かどうかを判定する。「無効」である場
合はステップ２５１０を実行し「ドキュメントＣ」の判
定結果を「中間」とし、ステップ２５０３へ戻る。「無
効」でなかった場合は、即ち「有効」であるので判定結
果を変えずにステップ２５０３へ戻る。ステップ２５１
１はドキュメントＢを生成先とする生成ツールを検索す
る（「生成ツールＱ」とする）。ステップ２５１２は生
成ツールが存在するかどうかを判定する。存在する場合
はステップ２５１３を実行し、存在しない場合はステッ
プ２５０１へ戻り次の２つのドキュメントを選択する。
ステップ２５１３は生成ツールＱの生成元ドキュメント
の判定結果を読み込む。ステップ２５１４は判定結果が
無効かどうかを判定する。無効である場合はステップ２
５１３を実行し、ドキュメントＤの判定結果を「中間」
と変更し、ステップ２５０１へ戻る。無効でなかった場
合は即ち「有効」であるので判定結果を変更せずにステ
ップ２５０１へ戻る。

【００３８】図２８は図２６ステップ２４０３の生成ツ
ール判定処理の詳細アルゴリズムを示す。ステップ２６
０１は生成ツールを１つ読み込む。ステップ２６０２は
生成ツールを全て読み込んだかどうかを判定する。全て
読み込んだ場合は本アルゴリズムを終了する。ステップ
２６０３は読み込んだ生成ツールでの生成元ドキュメン
トにおける判定結果を読み込む。ステップ２６０４は読
み込んだ生成ツールでの生成先ドキュメントにおける判
定結果を読み込む。ステップ２６０５は生成元および生
成先のドキュメントの判定結果の組み合わせから、図２
９で示す判定表を用いて生成ツールの判定を行う。ステ
ップ２６０５の終了後はステップ２６０１へ戻り、次の
生成ツールに対する判定処理を実行する。

【００３９】図２９は図２８ステップ２６０５の生成ツ
ールの判定を行う際の生成元ドキュメント及び生成先ド
キュメントの判定結果の組み合わせと生成ツールの判定
結果との対応を表す。生成元ドキュメントの判定結果は
図２８ステップ２６０３での実行結果である。生成先ド
キュメントはステップ２６０４の実行結果と対応してい
る。生成元および生成先のドキュメントの判定結果はそ
れぞれ３種類あり、本図で示すとおりそれぞれを組み合
わせた９通りについて判定結果を記述する。本図の通り
生成ツールの判定結果で「有効」と判定する場合は１通
りのみで、これは生成元及び生成先のドキュメントの判
定結果がどちらも「有効」である場合のみである。また
生成ツールの判定結果で「無効」と判定する場合は４通
りで、これは生成元および生成先ドキュメントの判定結
果のどちらか一方、または両方が「無効」と判定してい
る場合である。「中間」と判定する場合は残り４通り
で、これは生成元および生成先ドキュメントの判定結果
が「有効」かまたは「中間」のどちらかである場合であ
る。

【００４０】図３０は図１０で示す仕様データ編集制御
部の第２の実施例における実現アルゴリズムである。ス
テップ２８０１は起動しようとするドキュメントの判定
結果を読み込む。ステップ２８０２は判定結果が有効、
中間、無効によって次の実行処理を決定する。有効であ
る場合はステップ２８０３で対応するエディタを起動す
る。判定結果が中間である場合はステップ２８０４で
「本ドキュメントは中間ドキュメントです」を表示しユ
ーザに起動しようとするドキュメントが適用手順外では
あるが中間ドキュメントとして有効である旨を表示す
る。表示後はステップ２８０３でドキュメントに対応す
るエディタを起動する。ステップ２８０２で無効で合っ
た場合はステップ２８０５で「本ドキュメントは適用手
順では適してはいません」を表示し、本ドキュメントが
適用手順では無効である旨を表示する。ステップ２８０
６はユーザに無効であることを承知で設計するのかどう
かを尋ねるために「編集しますか（Ｙ／Ｎ）」を表示す
る。ステップ２８０７はステップ２８０６に対するユー
ザの応答を受け付ける。ステップ２８０８はステップ２
８０７で入力したユーザの応答が「Ｙ」であるかどうか
を判定する。「Ｙ」であるばあいはステップ２８０３で
対応するエディタを起動する。「Ｎ」である場合は処理
を終了する。本アルゴリズムでは「無効」と判定したド
キュメントもユーザの自分自身の了解の上でエディタを
起動している。また図１０で示す仕様データ生成制御部
１００７の第２の実施例における実現アルゴリズムは図
３０ステップ２８０１のドキュメントに対する判定結果
の読み込みを生成ツールに対する判定結果の読み込みと
し、ステップ２８０３のエディタの起動を生成ツールの
起動に変更すれば図３０で示す他のアルゴリズムを変更
せずして容易に実現できる。

【００４１】次に第３の実施例に付いて説明する。第２
の実施例では「中間」と判定して利用可能なツールを増
やし、さらに図３０で示すとおり「無効」と判定したド
キュメント、及び生成ツールにおいてもユーザの承諾の
上で利用可能とした。ところがこの実施例によると本来
「無効」と判定したドキュメントから「有効」ドキュメ
ントを生成することも可能となり、信頼性のない設計元
情報から別の情報を生成する等の情報の信頼性に問題が
生じる。また「有効」と判定したドキュメントから「有
効」な生成手段で「有効」と判定したドキュメントを生
成する際においても、生成先で情報を変更される可能性
があり、生成元との仕様書との整合性において問題が生
じる。

【００４２】これらの問題を解決するために第３の実施
例では第２の実施例にさらに編集履歴を記憶する手段を
加え、編集履歴と有効性の判定結果から仕様データ編集
部及び仕様データ生成部の制御を行う。図３１は実施例
３を実現するための機能構成図である。図３１は図１０
の機能構成図に編集履歴を記憶する編集履歴部２９０１
を加える。編集履歴部２９０１の内容を仕様データ編集
制御部１００６および仕様データ生成制御部１００７が
読みとり起動しようとするドキュメント及び生成ツール
の制御を行う。

【００４３】図３２は図３１の編集履歴部２９０１の内
容を表す。本実施例では次の６欄より構成する。欄３０
０１はドキュメントに対応する適用手順のＮｏを保持す
る。欄３００２および３００３はドキュメントの種別と
名称を保持する。欄３００４は起動しようとするドキュ
メントに対して最後に行った操作内容を保持する。値は
本実施例の場合「編集」「生成」の２種類である。欄３
００５は欄３００４で示す最後の操作が「有効」だった
ものかどうか判定結果を保持する。値は本実施例の場合
「有効」「中間」「無効」の３種類である。欄３００６
は最後の操作を行った日時を保持する。

【００４４】図３２の編集履歴部の１行目に記述する
「呼び出し関連図」「Ａ」のドキュメントに関して詳細
に説明する。本ドキュメントは欄３００１で示す「手順
Ｎｏ１」の適用手順のもとで、欄３００６で示す「H03/
12/19,11:33:20」の日時において欄３００４で示す「編
集」操作を最後に行ったことを示している。欄３００１
で示す手順Ｎｏ「１」の適用手順において「呼び出し関
連図」が「有効」と判断されているので「編集」操作は
「有効」な手段であることを表す。従って「呼び出し関
連図」「Ａ」は「有効」な「編集」操作で生成したこと
を意味する。

【００４５】図３３(a)(b)は図３１の仕様データ編集制
御部１００６および仕様データ生成制御部１００７の実
施例３におけるアルゴリズムを表す。図３３(a)より説
明する。ステップ３１０１は起動しようとするドキュメ
ントの判定結果を読み込む。ステップ３１０２は起動し
ようとするドキュメントに対応する編集履歴を読み込
む。ステップ３１０３はステップ３１０１の読み込んだ
判定結果とステップ３１０２で読み込んだ編集履歴とか
ら制御内容を決定し実行する。判定結果および編集履歴
と制御内容との対応は図３４で示すステップ３１０４は
ステップ３１０３での判定の結果、最終的にツールを起
動したかどうかを判定する。

【００４６】図３３(a)(b)は図３１の仕様データ編集制
御部１００６および仕様データ生成制御部１００７の実
施例３におけるアルゴリズムを表す。図３３(a)より説
明する。ステップ３１０１は起動しようとするドキュメ
ントの判定結果を読み込む。ステップ３１０２は起動し
ようとするドキュメントに対応する編集履歴を読み込
む。ステップ３１０３はステップ３１０１の読み込んだ
判定結果とステップ３１０２で読み込んだ編集履歴とか
ら制御内容を決定し実行する。判定結果および編集履歴
と制御内容との対応は図３４で示すステップ３１０４は
ステップ３１０３での判定の結果、最終的にツールを起
動したかどうかを判定する。

【００４７】起動していた場合はステップ３１０５にお
いて起動内容を編集履歴として編集履歴部へ更新する。
起動していなかった場合は登録せずに処理を終了する。
次に図３３(b)を説明する。ステップ３１１１は起動し
ようとする生成ツールの判定結果を読み込む。ステップ
３１１２は生成元のドキュメントの編集履歴を読み込
む。ステップ３１１３は判定結果及び編集履歴から制御
内容を決定、実行する。詳細な内容は図３４で示す。ス
テップ３１１４は生成ツールを起動したかどうかを判定
する。起動していた場合はステップ３１１５で生成先ド
キュメントの編集履歴として編集履歴部を更新し処理を
終了する。起動していなかった場合は処理を終了する。
図３４は図３３(a)(b)でしめすステップ３１０３及び３
１１３の判定処理の内容を表す。また図３３におけるお
ステップ３１０５及び３１１５の編集履歴の登録内容も
示す。編集履歴部の内容と判定結果部の内容との組み合
わせから起動内容を図３４で示すように変えることが可
能である。特に編集履歴部の内容が「生成・有効」でか
つ判定結果部の内容が「編集・有効」である場合、編集
しようとするドキュメントは適用手順に適しており、か
つ「有効」な手段で「生成」されたドキュメントである
ことを意味し、判定処理は「エディタ起動」とともに
「生成部分の書き込みロック」となる。編集履歴の内容
を加味することでドキュメントに記述する情報の定義も
とを明確化できる。

【００４８】次に第４の実施例について説明する。前述
までの実施例では支援ツールとして仕様データ編集部お
よび仕様データ生成部の２種類を用いていた。第４の実
施例では仕様データ生成部の代わりに仕様書間の関係デ
ータを保持する仕様書間関連データ部を用いる。図３５
は第４の実施例を実現するための機能構成図である。第
１の実施例との差異は、図１の仕様データ生成部１０６
および図１０の仕様データ生成制御部１００７、ドキュ
メント間生成ツール一覧部１００３の代わりに、仕様書
間関係データ部３３０４、仕様書間関係データ登録／参
照部３３０３、ドキュメント間関係データ対応部３３０
１および仕様書間関係データ制御部３３０２を加える点
である。仕様書間関係データ部３３０４はドキュメント
に記述する項目から特に他のドキュメントと関係のある
設計データを保持する。仕様書間関係データ登録／参照
部３３０３は仕様データ編集部１０４における設計デー
タから仕様書間の関係データを抽出し、仕様書間関係デ
ータ部へ登録したり、または設計のための関係データを
仕様書間関係データ部から参照するための手段である。
ドキュメント間関係データ対応部３３０１は仕様データ
編集部１０４から仕様書間関係データ登録／参照部へ授
受する関係データとドキュメントとの対応関係を保持す
る。仕様書関係データ制御部３３０２は判定結果部１０
０４の内容から仕様書間関係データ登録／参照部３３０
３の実行を制御する。

【００４９】図３６はドキュメント間関係データ対応部
３３０１の内容を表す。仕様データ編集部１０４で支援
する１２種類のドキュメント、および仕様書間関係デー
タ部３３０４で保持する８種類の関係データを示し、ド
キュメントと関係データとの対応関係を本図○印で表
す。本図で示す「呼び出し関連図」と「モジュール」と
の○印の対応関係は、「呼び出し関連図」ドキュメント
から「モジュール」データを抽出し関係データとして仕
様書間関係データ対応部へ登録することを意味する。

【００５０】図３８は第４の実施例における判定結果部
の内容を表す。本図はＮｏ１（図６で示す）の適用手順
における判定結果を表す。判定結果には２種類あり、仕
様データ編集制御部に用いるものと仕様書間関係データ
制御部に用いるものとである。仕様書データ編集制御部
で用いる判定結果にはドキュメントを設計する「開発フ
ェーズ」を加えた他は第１の実施例と変わりはない。仕
様書間関係データ制御部で用いる判定結果は次の２種類
存在する。本図で○印で示す関係データの登録／参照可
能なレベルと△印で示す参照のみ可能なレベルである。
例えば「呼び出し関係」の関係データの場合、開発フェ
ーズの早い「呼び出し関連図」からの登録・参照を可能
とし、後の開発フェーズでの「モジュール仕様書」は参
照のみ可能とする。このように関係データを開発フェー
ズの早いドキュメントから登録し、開発フェーズの遅い
ドキュメントへ参照させることで、開発フェーズの遅い
ドキュメントからの登録を防止する。これは先に設計し
たドキュメントの内容と後で設計したドキュメントの内
容との不整合を防ぐとともに、適用手順をユーザに遵守
する等の効果がある。図３８は図９で示す適用手順にお
ける判定結果である。図３８では「呼び出し関係」の関
係データを開発フェーズの早い「モジュール仕様書」か
ら登録し、開発フェーズの遅い「呼び出し関連図」では
参照のみ可能とする。このようにユーザが定義した様々
な適用開発手順においても、仕様書編集や関係データベ
ース等の支援ツールを手順に応じて制御可能となる。

【００５１】

【発明の効果】本発明により、適用手順を定義するだけ
で手順に応じた設計を誘導できソフトウエア開発支援シ
ステム構築の省力化が可能である。複数の開発部署が各
自の適用手順を定義し開発を遂行する際でも、部署とユ
ーザとの対応関係および部署と開発手順との対応関係を
有しているので、同時期に複数の開発手順が存在してい
ても支援可能である。また各設計手順に基づいてユーザ
へ設計の誘導を行うことができるので、設計ドキュメン
ト間での設計内容の不整合を防ぐことが可能である。ま
たある部署で適用する開発手順を他部署でも再利用可能
とすることで例えば品質の劣る開発を行っていた開発部
署へ品質向上のための開発手順を適用させることも可能
で、ソフトウエア開発での効率の良い開発手順を多数の
部署へ伝承することができる。

【図面の簡単な説明】

【図１】第１の実施例を示す機能構成図。

【図２】第１の実施例を実現するためのハードウエア構
成図。

【図３】図１の適用手順決定部１０１を詳細に示す機能
構成図。

【図４】図１の部署ユーザ対応部１０２の記憶内容の例
を示す。

【図５】開発手順定義用の画面レイアウト図

【図６】図３の開発手順部３０３の記憶内容の例を示
す。

【図７】開発手順定義画面上である手順を定義する場合
の画面出力例を示す。

【図８】図３の手順適用事例部３０５の記憶内容の例を
示す。

【図９】図３の適用手順部１０３の記憶内容の例を示
す。

【図１０】図１のツール整合部１０７を詳細に示す機能
構成図である。

【図１１】図１０のドキュメントエディタ一覧部１００
２の記憶内容の例を示す。

【図１２】図１０のドキュメント間生成ツール一覧部１
００３の記憶内容の例を示す。

【図１３】第１の実施例におけるドキュメントと生成ツ
ールとの関係を説明するための図である。

【図１４】図１０の支援ツール有効判定部１００１を説
明するための図

【図１５】図１０の支援ツール有効判定部１００１を説
明するための図

【図１６】図１０の判定結果部１００４の記憶内容の例
を示す。

【図１７】図１０の仕様データ編集制御部１００６、仕
様データ生成制御部１００７での実行結果を画面出力す
る場合の例を示す。

【図１８】図１の適用手順決定部１０１を実現するため
のフローチャートである。

【図１９】図１０の支援ツール有効判定部１００１にお
いてドキュメントに対して判定処理を実行するためのフ
ローチャートである。

【図２０】図１０の支援ツール有効判定部１００１にお
いてドキュメント生成ツールに対して判定処理を実行す
るためのフローチャートである。

【図２１】図２０のステップ１８０３の実行を詳細に示
すフローチャートである。

【図２２】図２０のステップ１８０４の実行を詳細に示
すフローチャートである。

【図２３】図１０の仕様データ編集制御部および仕様デ
ータ生成制御部の実行内容を示すフローチャートであ
る。

【図２４】第２の実施例における支援ツールの有効性判
定結果を説明するための図である。

【図２５】第２の実施例における判定結果部の記憶内容
を示す。

【図２６】第２の実施例を実現するためのフローチャー
トである。

【図２７】図２６のステップ２４０２を詳細に示すフロ
ーチャートである。

【図２８】図２６のステップ２４０３を詳細に示すフロ
ーチャートである。

【図２９】図２８のステップ２６０５での判定内容を説
明するための図である。

【図３０】第２の実施例における仕様データ編集制御部
の実行内容を示すフローチャートである。

【図３１】第３の実施例におけるツール制御部の詳細な
機能構成図である。

【図３２】図３１の編集履歴部２９０１の記憶内容を示
す説明図である。

【図３３】第３の実施例における仕様データ編集制御部
および仕様データ生成制御部を実行するためのフローチ
ャートである。

【図３４】第３の実施例における支援ツール有効判定部
の判定内容を説明するための図である。

【図３５】第４の実施例におけるツール整合部の詳細な
機能構成図である。

【図３６】第４の実施例においてドキュメントと関係デ
ータとの関係を説明するための図である。

【図３７】第４の実施例における判定結果の記憶内容を
示す図である。

【図３８】第４の実施例における判定結果の記憶内容を
示す図である。

【符号の説明】

１０１…適用手順決定部、１０２…部署ユーザ対応部、
１０３…適用手順部、１０４…仕様データ編集部、１０
５…仕様データ部、１０６…仕様データ生成部、１０７
…ツール整合部

Claims (7)

【特許請求の範囲】
1. 【請求項１】多人数でソフトウエアを開発する際に対話
   的に仕様書を編集するソフトウエア設計支援システムに
   おいて、各部署毎に開発手順（開発ドキュメントと開発
   順序を規定）を記憶するステップを設け、該記憶する開
   発手順を他部署の開発に利用可能としたことを特徴とす
   るカスタマイズ開発手順支援方法。
2. 【請求項２】多人数でソフトウエアを開発する際に対話
   的に仕様書を編集するソフトウエア設計支援システムに
   おいて、ユーザの定義する開発手順を記憶するステップ
   とドキュメント種別の一覧を保持するステップと該記憶
   する開発手順及びドキュメント種別の一覧より開発手順
   に適したドキュメント編集用ツールを判定するステップ
   と該判定結果を記憶するステップを設け、ユーザの定義
   した開発手順に基づいて開発を誘導することを特徴とす
   るカスタマイズ開発手順支援方法。
3. 【請求項３】請求項２記載のソフトウエア設計支援シス
   テムにおいて、ユーザがドキュメントを設計するために
   ドキュメントの編集用ツールを起動する際に該判定結果
   に基づいて開発手順に適するかどうかを判別し、適する
   場合はツールを起動し適さない場合はその旨を表示する
   ステップを加えることで、ユーザの定義した開発手順に
   基づいて開発を誘導することを特徴とするカスタマイズ
   開発手順支援方法。
4. 【請求項４】請求項３記載のソフトウエア設計支援シス
   テムにおいて、ユーザを特定する識別子と開発部署を特
   定する識別子との対応関係を保持するステップと、ユー
   ザの定義する開発手順を特定する識別子と開発部署を特
   定する識別子との対応関係を記憶するステップを設け、
   ユーザがドキュメントを設計する際にユーザの所属する
   開発部署を特定しさらに該開発部署で適用している開発
   手順を特定するステップを設けることで、複数開発部署
   においても開発の誘導を可能としたことを特徴とするカ
   スタマイズ開発手順支援方法。
5. 【請求項５】請求項３記載のソフトウエア設計支援シス
   テムにおいて、さらにユーザが実行した設計内容の履歴
   を記憶するステップを加えて、該ユーザが仕様データの
   編集の際に該設計履歴を加味して判定を行うようにする
   ことを特徴とするカスタマイズ開発手順支援方法。
6. 【請求項６】請求項１記載のソフトウエア設計支援シス
   テムにおいて、あるドキュメントから別のドキュメント
   へ生成する支援ツールに対しても適用するために、生成
   元ドキュメント種別と生成先ドキュメント種別との対応
   関係を保持するステップと、ユーザが生成ツールを使用
   する際に開発手順に適するかどうかを判定し、適する場
   合はツールを起動し適さない場合はその旨を表示するス
   テップを加え、ユーザへ定義した開発手順に基づいて設
   計を誘導することを特徴とするカスタマイズ開発手順支
   援方法。
7. 【請求項７】請求項６記載の仕様データの編集及び生成
   に関する方法を、仕様データの編集および仕様書間の関
   係データの登録および参照に関する設計支援システムに
   適用したカスタマイズ開発手順支援方法。