(57)【要約】【課題】ソフトウェア開発システムにおいて、ソフトウェアの一部を修正した場合にその修正の影響が広い範囲に及ぶのを防ぐこと。その修正が他に影響を及ぼす範囲を細かく抽出すること。【解決手段】ドキュメント等にセルフキーとアッパーキーを付与し、セルフキーに基づいて自工程内のドキュメント等を記憶し、アッパーキーに基づいて、自工程内のドキュメント等に対する修正の影響が及ぶ上位工程のドキュメント等を記憶する。各工程内のドキュメント等を工程別に記憶する工程定義ファイルを作成し、工程定義ファイルにより、各工程内のドキュメント等とその下位に位置する工程内のドキュメント等の関係を定義する。いずれかの工程内のドキュメント等が修正されたとき、そのドキュメント等のアッパーキーに基づいて上位工程内のドキュメント等を検索し、工程定義ファイルに基づいて下位工程内のドキュメント等を検索し、修正の影響が及ぶ範囲を抽出する。【選択図】図２
2010039751.tif 000002
【特許請求の範囲】
【請求項１】
階層化された複数の工程を経てソフトウェアを開発するソフトウェア開発システムであって、
各工程内のドキュメントまたはソースコードに付与された第１のキーワードに基づいて自工程内のドキュメントまたはソースコードを記憶する第１の記憶手段と、
各工程内のドキュメントまたはソースコードに付与された第２のキーワードに基づいて自工程内のドキュメントまたはソースコードに対する修正の影響が及ぶ上位工程のドキュメントまたはソースコードを記憶する第２の記憶手段と、
各工程内のドキュメントまたはソースコードと該工程の下位工程内のドキュメントまたはソースコードの関係を定義する工程定義手段と、
いずれかの工程内のドキュメントまたはソースコードに対する修正の影響が及ぶドキュメントまたはソースコードを、前記上位工程内のドキュメントまたはソースコードについては前記第２のキーワードに基づいて検索し、前記下位工程内のドキュメントまたはソースコードについては前記工程定義手段に基づいて検索する検索手段と、
を備えることを特徴とするソフトウェア開発システム。
【請求項２】
各工程内のドキュメントまたはソースコードに付与され、前記ドキュメントまたはソースコードが修正されるたびに更新される第１の版数と、
前記第１のキーワードに付与され、前記ドキュメントまたはソースコードに対する修正の影響が及ぶ全てのドキュメントまたはソースコードの修正が終了すると更新される第２の版数と、
をさらに備え、
前記検索手段は、前記第１の版数と前記第２の版数が異なることをトリガーとして前記検索処理を行うことを特徴とする請求項１に記載のソフトウェア開発システム。
【請求項３】
各工程がさらに複数の小工程からなり、各小工程内のドキュメントまたはソースコードに付与され、小工程を識別する工程識別子、
をさらに備え、
前記第１の記憶手段は、前記工程識別子に基づいて自工程内の各小工程内のドキュメントまたはソースコードを記憶し、
前記検索手段は、いずれかの工程内のドキュメントまたはソースコードに対する修正の影響が及ぶドキュメントまたはソースコードを、前記自工程内の各小工程のドキュメントまたはソースコードについては前記工程識別子に基づいて検索することを特徴とする請求項１または２に記載のソフトウェア開発システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ソフトウェア開発システムに関する。
【背景技術】
【０００２】
ソフトウェアの開発を支援するシステムが知られている。例えば、ソフトウェアの要求を記述した要求記述文書、該要求記述文書から作成される設計モデル、および、該設計モデルから作成されるプログラムコードである成果物の開発を支援する開発支援装置が提案されている。この開発支援装置は、成果物および成果物間の対応情報を格納する記憶部と、修正する成果物の入力を受け付ける修正受付部と、前記修正受付部により受け付けた成果物を起点として、前記記憶部に格納された成果物間の対応情報を辿ることにより、修正する成果物が影響する他の成果物を追跡する修正追跡部と、前記修正追跡部により追跡された成果物を通知する修正通知部と、を有することを特徴とする（例えば、特許文献１参照。）。
【０００３】
また、ソフトウェア開発における設計書作成を支援するソフトウェア開発支援装置が提案されている。この開発支援装置で、設計書は開発フェーズの１つに帰属し前記設計書を構成する少なくとも１つの設計要素を有し、設計要素は各要素を実現する実現要素と各要素に依存する依存要素を含み、前記実現要素および依存要素の情報を含む設計要素情報が記録された記憶手段と、設計変更時に前記記憶手段に記録された前記実現要素と前記依存要素の情報を検索し、設計変更が生じたときに変更の要求を実現する実現要素と、その変更が波及する依存要素とを抽出する検索手段と、前記検索手段によって検索した実現要素と依存要素を基に、変更が必要な設計要素を取得して表示する可視化装置とを具備したことを特徴とする（例えば、特許文献２参照。）。
【０００４】
また、上流から下流へ段階的に設計情報を詳細化しながらソフトウェア成果物を作成する場合に、上流の設計情報と下流の設計情報とそれらの間の関連情報を登録する設計情報管理システムが提案されている。この設計情報管理システムは、ソフトウェア成果物の記述ルールに基づいて、ソフトウェア成果物を格納する成果物格納部と、設計情報や設計情報間の関連情報を記憶する設計情報格納部と、ソフトウェア成果物から設計情報識別ＩＤ及び設計情報と、上流ソフトウェア成果物との関連を表す設計情報識別ＩＤを抽出する機能を有し、ソフトウェア成果物内の設計情報を設計情報識別ＩＤ単位に格納し、かつソフトウェア成果物内の設計情報識別ＩＤ間の関連を格納する設計情報解析手段を持つことを特徴とする（例えば、特許文献３参照。）。
【０００５】
【特許文献１】特開２００７−１２２１３５号公報
【特許文献２】特開２００７−１８３３４号公報
【特許文献３】特開２００７−１９９７５５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、前記特許文献１に開示された開発支援装置は、要求記述文書が修正されると、要求記述文書からリンクのある設計モデルを追跡し、その設計モデルからリンクのあるプログラムコードを追跡し、さらに再帰的に、そのプログラムコードからリンクのある設計モデルを追跡し、その設計モデルからリンクのある要求記述文書を追跡する。最初にプログラムコードを修正した場合や、最初に設計モデルを修正した場合も同様である。このように再帰的に追跡を行うため、最初の修正の影響が広い範囲に及ぶおそれがある、という問題点がある。
【０００７】
前記特許文献２に開示されたソフトウェア開発支援装置では、開発フェーズに属する設計書単位で管理しているため、ある開発フェーズに属する設計書の一部が修正されても、その設計書と関連のある全ての設計書にその修正の影響が及んでしまう。つまり、設計書の一部の修正が他に影響を及ぼす範囲を、設計書単位ではなく、修正部分ごとに細かく抽出することができない、という問題点がある。
【０００８】
前記特許文献３に開示された設計情報管理システムでは、一つの上流の設計情報に複数の下流の設計情報が関連する場合を考慮していないため、上流の設計情報を修正した場合に、その修正の影響が広い範囲に及ぶおそれがある、という問題点がある。また、関連情報としてＩＤを用いているため、上流の設計情報と下流の設計情報の関連が固定的であり、下流側で上流への関連付けを変更するのは困難である、という問題点がある。
【０００９】
この発明は、上述した従来技術による問題点を解消するため、ソフトウェアの一部を修正した場合にその修正の影響が広い範囲に及ぶのを防ぐことができるソフトウェア開発システムを提供することを目的とする。また、この発明は、ソフトウェアの一部を修正した場合にその修正が他に影響を及ぼす範囲を細かく抽出することができるソフトウェア開発システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
このソフトウェア開発システムは、階層化された複数の工程を経てソフトウェアを開発するにあたって、各工程内のドキュメントまたはソースコードに第１のキーワードと第２のキーワードを付与し、第１のキーワードに基づいて自工程内のドキュメントまたはソースコードを記憶し、第２のキーワードに基づいて自工程内のドキュメントまたはソースコードに対する修正の影響が及ぶ上位工程のドキュメントまたはソースコードを記憶する。また、このソフトウェア開発システムは、各工程内のドキュメントまたはソースコードを工程別に記憶し、各工程内のドキュメントまたはソースコードと該工程の下位工程内のドキュメントまたはソースコードの関係を定義する工程定義手段を備える。
【００１１】
さらに、このソフトウェア開発システムは、いずれかの工程内のドキュメントまたはソースコードが修正されたときに、そのドキュメントまたはソースコードに付与された第２のキーワードに基づいて上位工程内のドキュメントまたはソースコードを検索する検索手段を備える。この検索手段は、いずれかの工程内のドキュメントまたはソースコードが修正されたときに、工程定義手段に基づいてそのドキュメントまたはソースコードの下位工程内のドキュメントまたはソースコードを検索する。
【００１２】
このソフトウェア開発システムは、各工程がさらに複数の小工程からなる場合、各小工程内のドキュメントまたはソースコードに工程識別子を付与し、工程識別子に基づいて各小工程内のドキュメントまたはソースコードを記憶する。そして、前記検索手段は、いずれかの工程内のドキュメントまたはソースコードが修正されたときに、工程識別子に基づいてその修正の影響が及ぶ自工程内の各小工程のドキュメントまたはソースコードを検索する。
【００１３】
このソフトウェア開発システムによれば、いずれかの工程内のドキュメントまたはソースコードが修正されたときに、上位工程、自工程および下位工程の中から、その修正の影響が及ぶドキュメントまたはソースコードが検索される。上位工程、自工程または下位工程がさらに複数の小工程からなる場合には、修正の影響が及ぶドキュメントまたはソースコードが小工程の単位で検索される。
【発明の効果】
【００１４】
このソフトウェア開発システムによれば、ソフトウェアの一部を修正した場合にその修正の影響が広い範囲に及ぶのを防ぐことができるという効果を奏する。また、ソフトウェアの一部を修正した場合にその修正が他に影響を及ぼす範囲を細かく抽出することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１５】
以下に添付図面を参照して、このソフトウェア開発システムの好適な実施の形態を詳細に説明する。
【００１６】
（ソフトウェア開発システムのハードウェア構成）
図１は、実施の形態にかかるソフトウェア開発システムのハードウェア構成を示す説明図である。図１に示すように、ソフトウェア開発システム１は、ＣＰＵ１０１と、ＲＯＭ１０２と、ＲＡＭ１０３と、ＨＤＤ（ハードディスクドライブ）１０４と、ＨＤ（ハードディスク）１０５と、ＦＤＤ（フレキシブルディスクドライブ）１０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）１０７と、ディスプレイ１０８と、Ｉ／Ｆ（インターフェース）１０９と、キーボード１１０と、マウス１１１と、スキャナ１１２と、プリンタ１１３と、を備えている。また、各構成部は、バス１００によってそれぞれ接続されている。
【００１７】
ここで、ＣＰＵ１０１は、ソフトウェア開発システム１の全体の制御を司る。ＲＯＭ１０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ１０３は、ＣＰＵ１０１のワークエリアとして使用される。ＨＤＤ１０４は、ＣＰＵ１０１の制御に従ってＨＤ１０５に対するデータのリード／ライトを制御する。ＨＤ１０５は、ＨＤＤ１０４の制御で書き込まれたデータを記憶する。ＦＤＤ１０６は、ＣＰＵ１０１の制御に従ってＦＤ１０７に対するデータのリード／ライトを制御する。ＦＤ１０７は、ＦＤＤ１０６の制御で書き込まれたデータを記憶する。
【００１８】
また、着脱可能な記録媒体として、ＦＤ１０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）、メモリーカードなどであってもよい。ディスプレイ１０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ１０８は、例えば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
【００１９】
Ｉ／Ｆ１０９は、通信回線を通じてインターネットやローカルエリアネットワークなどのネットワーク１１４に接続され、このネットワーク１１４を介して他の装置に接続される。そして、Ｉ／Ｆ１０９は、ネットワーク１１４と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ１０９には、例えばモデムやＬＡＮアダプタなどを採用することができる。
【００２０】
キーボード１１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス１１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。スキャナ１１２は、画像を光学的に読み取り、ソフトウェア開発システム１内に画像データを取り込む。なお、スキャナ１１２は、ＯＣＲ機能を持たせてもよい。また、プリンタ１１３は、画像データや文書データを印刷する。プリンタ１１３には、例えば、レーザプリンタやインクジェットプリンタを採用することができる。
【００２１】
（ソフトウェア開発システムの機能的構成）
図２は、ソフトウェア開発システムの機能的構成を示すブロック図である。図２に示すように、ソフトウェア開発システム１は、ドキュメント依存関係処理部２、ドキュメント保存部３、主処理部４およびオブジェクト生成部５を備えている。ドキュメント依存関係処理部２は、工程定義ファイル６、工程定義記憶部７、修正処理フラグ記憶部８およびドキュメント版数チェック部９を備えている。
【００２２】
ドキュメント保存部３は、ドキュメントまたはソースコード（以下、ドキュメント等とする）を保存する。ドキュメント等は、ヘッダー部とドキュメント本体からなる。ドキュメント本体は、ドキュメントの本文またはソースコードのソース部である。ヘッダー部は、自ドキュメント等を識別する第１のキーワードとしてのセルフキー（Ｓｅｌｆ  Ｋｅｙ）、自ドキュメント等に対して上位に位置するドキュメント等（以下、上位ドキュメント等とする）を識別する第２のキーワードとしてのアッパーキー（Ｕｐｐｅｒ  ｋｅｙ）、自ドキュメント等が生成される工程を識別するための工程識別子、並びに自ドキュメント等の各種状態を示す第１、第２および第３の３つのフラグを備えている。
【００２３】
セルフキーは、自ドキュメント等を他のドキュメント等から区別することができれば、機械的な名称など、いかなるキーワードであってもよいが、好ましくは、ドキュメント等の内容を表す意味や内容のキーワードであるのがよい。セルフキーは、一ドキュメント等内にいくつ存在してもよいが、同一工程内では上位のドキュメント等の数とそのすぐ下位のドキュメント等の数が１：Ｎの関係になっている場合を除いて、一意である必要がある。
【００２４】
また、セルフキーは、ドキュメント本体にも記載される。このドキュメント本体に記載されるセルフキーには、第１の版数が付与されている。この第１の版数は、ユーザによって更新される。ヘッダー部のセルフキーには、第２の版数が付与されている。この第２の版数は、システム側、例えばドキュメント保存部３により更新される。第１の版数および第２の版数は、例えば０から始まる整数であり、１ずつインクリメントされ、９の次に０に戻る。
【００２５】
アッパーキーは、上位ドキュメント等に登録されている上位ドキュメント等のセルフキーである。自ドキュメント等において、上位ドキュメント等のセルフキーをアッパーキーとして登録することによって、自ドキュメント等がつながる上位ドキュメント等を特定することができる。
【００２６】
第１のフラグは、自ドキュメント等に対して自発的な修正を行う場合にオンになる。第１のフラグは、自ドキュメント等の修正を発端として修正が必要な全てのドキュメント等の修正が終了した時点でオフとなる。以下、この一連の修正処理において最初に自発的に修正が行われるドキュメント等を基点ドキュメント等とする。第２のフラグは、他のドキュメント等が修正されたことによる影響が及んで、自ドキュメント等を修正したり、チェックする必要がある場合にオンになる。第３のフラグは、自ドキュメント等の修正が完了したときにオンになる。
【００２７】
工程定義ファイル６は、工程別にドキュメント等を記憶するとともに、自ドキュメント等と、自ドキュメント等に対して下位に位置するドキュメント等（以下、下位ドキュメント等とする）の依存関係を記憶する。工程定義記憶部７は、工程定義ファイル６を記憶する。
【００２８】
修正処理フラグ記憶部８は、アッパーキーに基づいて上位ドキュメント等を検索し、工程定義ファイル６に基づいて下位ドキュメント等を検索する。また、修正処理フラグ記憶部８は、工程定義ファイル６に基づいて、同一レベルの工程において同一セルフキーが設定されているドキュメント等を検索する。修正処理フラグ記憶部８は、それらの検索結果に基づいて、該当するドキュメント等の第１、第２および第３の各フラグの状態を記憶する。
【００２９】
ドキュメント版数チェック部９は、ドキュメント本体内のセルフキーの版数（第１の版数）とヘッダー部のセルフキーの版数（第２の版数）を比較する。比較の結果、版数に違いがあれば、ドキュメント版数チェック部９は、そのドキュメント本体が変更されたと判断する。版数が同じである場合には、ドキュメント版数チェック部９は、ドキュメント本体に記載されたセルフキーの版数が変更されていないと判断する。
【００３０】
主処理部４は、ドキュメント版数チェック部９によりドキュメント本体内のセルフキーの版数が変更されていないと判断された場合、ディスプレイ１０８に、ユーザに対して版数の更新を促すメッセージを表示する。主処理部４は、ディスプレイ１０８に、第１のフラグまたは第２のフラグがオンになっているドキュメント等を表示し、ユーザにそのドキュメント等の修正を促す。
【００３１】
オブジェクト生成部５は、コンパイラを備えている。オブジェクト生成部５は、修正処理フラグ記憶部８を介して各ドキュメント等の第１、第２および第３のフラグをチェックする。その結果、第１のフラグおよび第２のフラグがオフである場合、オブジェクト生成部５は、オブジェクトの生成を許可し、オブジェクトを生成する。第１のフラグまたは第２のフラグがオンである場合には、オブジェクト生成部５は、オブジェクトの生成を許可しない。
【００３２】
（具体例の説明）
図３は、工程定義の概念の一例を示す説明図である。例えば図３に示すように、ソフトウェアの開発工程が、機能仕様書を生成するＢＩ工程、基本設計書を生成するＢＤ工程、機能設計書を生成するＦＤ工程およびソース（コメント）を生成するＭＫ工程からなるとする。例えば、ＢＩ工程では、全体画面に関する「Ａ１全体画面」ドキュメント等が生成されるとする。ＢＤ工程では、「Ａ１全体画面」ドキュメント等の下位ドキュメント等として、「Ｂ１全体レイアウト」ドキュメント等が生成されるとする。さらに、ＢＤ工程は、複数の小工程からなり、「Ｂ１全体レイアウト」ドキュメント等として、各小工程において「Ｂ１１名前」、「Ｂ１２出発」、「Ｂ１３到着」、「Ｂ１４ルート表示」および「Ｂ２１実行」の各ドキュメント等が生成されるとする。
【００３３】
ＦＤ工程では、「Ｂ１全体レイアウト」ドキュメント等の下位ドキュメント等として、「Ｃ１位置」ドキュメント等が生成されるとする。また、「Ｂ１１名前」、「Ｂ１２出発」、「Ｂ１３到着」および「Ｂ１４ルート表示」の各ドキュメント等の下位ドキュメント等として、「Ｃ２フォント」ドキュメント等が生成され、「Ｂ２１実行」ドキュメント等の下位ドキュメント等として、「Ｃ３表示する」ドキュメント等が生成されるとする。ＭＫ工程では、「Ｃ１位置」、「Ｃ２フォント」および「Ｃ３表示する」の各ドキュメント等の下位ドキュメント等として、それぞれ、「Ｄ１位置」、「Ｄ２フォント」および「Ｄ３表示する」の各ドキュメント等が生成されるとする。図３に示す工程定義の概念図において、横一列が一構成単位に該当する。
【００３４】
図４、図５、図６および図７は、それぞれ、「Ａ１全体画面」、「Ｂ１全体レイアウト」、「Ｂ１１名前」および「Ｃ１位置」の各ドキュメント等の構成の一例を示す説明図である。図４に示すように、「Ａ１全体画面」ドキュメント等１１のヘッダー部には、セルフキーとして「全体画面（＊）」が設定される。セルフキーの後には、第２の版数を表す数字＊（＊＝０、１、・・・、９）が括弧で括られて付される。「Ａ１全体画面」ドキュメント等１１は、工程定義において最上位にあたるドキュメント等であるので、アッパーキーは設定されない。工程識別子として、後述する工程グループコード「Ａ１」が設定される。ドキュメント本体には、「全体画面（＊）」のセルフキーが第１の版数付きで記載される。
【００３５】
図５に示すように、「Ｂ１全体レイアウト」ドキュメント等１２においては、ヘッダー部にセルフキー、アッパーキーおよび工程識別子として、それぞれ、第２の版数付きの「全体レイアウト（＊）」、「全体画面」および工程グループコード「Ｂ１」が設定される。ドキュメント本体には、第１の版数付きの「全体レイアウト（＊）」が記載される。
【００３６】
図６に示すように、「Ｂ１１名前」ドキュメント等１３においては、ヘッダー部にセルフキー、アッパーキーおよび工程識別子として、それぞれ、「名前（＊）、入力（）、漢字（）」、「全体レイアウト、入力、漢字」および後述するサブ工程識別子「Ｂ：Ｂ１１」が設定される。図３に示す例では、「Ｂ１１名前」ドキュメント等１３には、「名前」以外にも「入力」と「漢字」のセルフキーがあるので、ヘッダー部にはこれらのセルフキーが羅列される。ただし、「名前」のセルフキーには、第２の版数を表す数字＊が括弧で括られて付されるが、同一工程内のセルフキーは版数の対照外であるため、「入力」と「漢字」のセルフキーには、第２の版数を表す数字のない括弧だけが付される。ドキュメント本体には、第１の版数付きの「名前（＊）」が記載される。
【００３７】
図７に示すように、「Ｃ１位置」ドキュメント等１４においては、ヘッダー部にセルフキー、アッパーキーおよび工程識別子として、それぞれ、第２の版数付きの「位置（＊）」、「全体レイアウト」および工程グループコード「Ｃ１」が設定される。ドキュメント本体には、第１の版数付きの「位置（＊）」が記載される。その他のドキュメント等の構成も同様であるので、省略する。
【００３８】
図８は、工程定義ファイルのデータベース構造の一例を示す説明図である。図８に示すように、工程定義ファイル６は、基準データベース２１と拡張データベース２２により構成されている。基準データベース２１のレコードは、例えば「フォワードポインタ」、「工程識別子」、「サブ工程識別子」、「キー名称」、「工程グループコード」、「サイドポインタ」、「ネクストポインタ」および「キーポインタ」の各フィールドを有する。拡張データベース２２のレコードは、例えば「フォワードキーポインタ」、「キー名称」および「ネクストキーポインタ」の各フィールドを有する。
【００３９】
「フォワードポインタ」フィールドには、工程間において前工程へのリンクを示すポインタが格納される。「工程識別子」フィールドには、ＢＩやＢＤなどの工程分類を示すデータが格納される。「サブ工程識別子」フィールドには、同一セルフキー内における詳細工程分類を示すデータが格納される。詳細工程分類は、Ｂ１１やＢ１２などである。「キー名称」フィールドには、セルフキーの名称を示すデータが格納される。「工程グループコード」フィールドには、同一工程内のキーであることを示すコードが格納される。「サイドポインタ」フィールドには、同一工程内のリンクまたは同一セルフキー内のリンクを示すポインタが格納される。「ネクストポインタ」フィールドには、工程間において後（次）工程へのリンクを示すポインタが格納される。「キーポインタ」フィールドには、同一セルフキー内にあるキー名称へのポインタが格納される。「フォワードキーポインタ」フィールドには、同一セルフキー内にあるキー名称へのリンク元を示すポインタが格納される。「ネクストキーポインタ」フィールドには、同一セルフキー内にあるキー名称への次のリンクを示すポインタが格納される。
【００４０】
図９は、工程定義ファイルの一例を示す説明図である。この例は、図３に示す工程定義に図８に示すデータベース構造を適用したものである。図９に示すように、最初のポインタ「０」のレコード３１では、キー名称として、ＢＩ工程でのセルフキーである「全体画面」が登録される。次のポインタ「１００」のレコード３２では、キー名称として、ＢＤ工程でのセルフキーである「全体レイアウト」が登録される。ポインタ「０」のレコード３１では、ネクストポインタとして「１００」が登録される。ポインタ「１００」のレコード３２では、フォワードポインタとして「０」が登録される。
【００４１】
ＢＤ工程には、さらに工程内セルフキーが存在するので、「名前」、「出発」、「到着」、「ルート表示」および「実行」の工程内セルフキーが、それぞれキー名称として、ポインタ「１０１」、「１０２」、「１０３」、「１０４」および「１０５」のレコード３３，３４，３５，３６，３７に登録される。これらは、ＢＤ工程の同一セルフキー内のレコードであるので、それぞれにサブ工程識別子、工程グループコードおよびサイドポインタが登録され、横ならびのリンクとされる。また、これらＢＤ工程の同一セルフキー内のレコードは、同一レベルであるので、いずれも、フォワードポインタとして「１００」が登録され、ネクストポインタとして「２００」が登録される。さらに、これらのレコードには、同一セルフキー内にセルフキーがあるので、それぞれに拡張情報として「１００００」〜「１０００８」のキーポインタが登録される。ポインタ「１００００」〜「１０００８」のレコード４１，４２，４３，４４，４５，４６，４７，４８，４９は、拡張データベースのレコードである。
【００４２】
ポインタ「２００」のレコード３８では、キー名称として、ＦＤ工程でのセルフキーである「位置」が登録される。ポインタ「２００」のレコード３８では、フォワードポインタとして「１００」が登録され、ネクストポインタとして、ソースへのリンクである「３００」が登録される。また、ＦＤ工程に関しては、ポインタ「２１０」のレコード３９に、キー名称として「フォント、桁数」が登録され、ポインタ「２２０」のレコード４０に、キー名称として「表示する」が登録される。ポインタ「２１０」のレコード３９では、フォワードポインタとして「１００」が登録され、ネクストポインタとして、ソースへのリンクである「３１０」が登録される。ポインタ「２２０」のレコード４０では、フォワードポインタとして「１００」が登録され、ネクストポインタとして、ソースへのリンクである「３２０」が登録される。
【００４３】
ＦＤ工程は、ＢＤ工程のような同一セルフキーのリンクではないので、ＦＤ工程の各レコードでは、サブ工程識別子が登録されていない。また、ＦＤ工程の各レコードでは、工程グループコードが異なる。ポインタ「３００」以降のレコードについては、図示省略する。図１０に、図９に示す工程定義ファイルにより定義されるリンクを概念的に示す。図１０において、「０」や「１００」などの数字は、図９に示す各レコードのポインタである。矢印は、依存関係を示す。
【００４４】
図１１は、ドキュメント等の依存関係をまとめた機能マトリクスの一例を示す説明図である。上述した例では、ＢＤ工程において、上位のドキュメント等の数とそのすぐ下位のドキュメント等の数が１：Ｎの関係となる。このような関係の場合、図１１に示す機能マトリクス５１を用意し、この機能マトリクス５１に基づいて第２のフラグをオンにする下位ドキュメント等を決定するようにしてもよい。図１１に示す機能マトリクス５１において、「１」はドキュメント等にマトリクス左端の関連項目（「入力」など）を含み、「０」は含まないことを表す。「Ｂ１１名前」ドキュメント等の「入力」関連項目が修正された場合、「Ｂ１２出発」および「Ｂ１３到着」の各ドキュメント等に対しても修正が必要となるので、これら２つのドキュメント等の第２のフラグがオンになる。それに対して、「Ｂ１４ルート表示」および「Ｂ２１実行」の各ドキュメント等は、「入力」関連項目を含まないので、これらのドキュメント等を修正する必要がない。
【００４５】
上述した機能マトリクス５１は、例えば工程定義ファイル６に基づいて工程定義記憶部７により生成される。例えば図９に示す構成の場合、工程定義記憶部７は、基準データベース２１から工程グループコードをリストアップし、その中から複数のレコードに登録されているコードを探し出す。図９に示す例では、「Ｂ１」が該当する。次いで、工程定義記憶部７は、工程グループコードとして「Ｂ１」が登録されている複数のレコードの中から、サブ工程識別子が登録されているレコードを取り出す。図９に示す例では、「Ｂ１１」〜「Ｂ１２」が登録されているレコードが該当する。次いで、工程定義記憶部７は、「Ｂ１１」〜「Ｂ１２」のサブ工程識別子が登録されている各レコードのキーポインタに基づいて拡張データベース２２を参照し、拡張データベース２２に登録されているキー名称を取り出す。そして、工程定義記憶部７は、取り出したキー名称が機能マトリクス５１にない名称であれば、マトリクスの左端にその名称を追加し、機能マトリクス５１に既にある名称であれば、該当するサブ工程識別子の欄に「１」を格納する。これを繰り返すことによって、機能マトリクス５１ができあがる。
【００４６】
図１２は、主処理部により表示される画面の一例を示す説明図である。図１２に示すように、ディスプレイ１０８の画面には、ユーザに処理の選択を促す処理選択部６１、ドキュメント等の関連情報（リンク情報）を表示するドキュメント関連表示部６２、関連するドキュメント等のフラグの情報を表示する関連ドキュメントフラグ表示部６３、自ドキュメント等のヘッダー部の情報を表示するドキュメント情報表示部６４、および自ドキュメント等のドキュメント本体を表示するドキュメント加工処理部６５が表示される。
【００４７】
上述した機能的構成において、ドキュメント保存部３は、第１の記憶手段および第２の記憶手段としての機能を有する。工程定義ファイル６および工程定義記憶部７は、工程定義手段としての機能を有する。修正処理フラグ記憶部８は、検索手段および記憶手段としての機能を有する。主処理部４は、処理手段としての機能を有する。また、図１に示すハードウェア構成において、ドキュメント保存部３は、ＨＤ１０５などの２次記憶装置により構成される。工程定義ファイル６は、ＨＤ１０５などの２次記憶装置に記憶される。主処理部４、オブジェクト生成部５、工程定義記憶部７、修正処理フラグ記憶部８およびドキュメント版数チェック部９は、ＲＯＭ１０２やＨＤ１０５などの記憶部に記憶された各機能に関するプログラムをＣＰＵ１０１に実行させることにより、実現される。あるいは、各種ドキュメント等や工程定義ファイル６や機能マトリクス５１をネットワーク１１４上の記憶装置に格納しておき、これらをＩ／Ｆ１０９を介してネットワーク１１４からダウンロードして使用するようにしてもよい。また、主処理部４、オブジェクト生成部５、工程定義記憶部７、修正処理フラグ記憶部８およびドキュメント版数チェック部９の各機能を実現するプログラムも、Ｉ／Ｆ１０９を介してネットワーク１１４からダウンロードして使用するようにしてもよい。
【００４８】
（ソフトウェア開発システムにおけるドキュメント処理手順）
図１３〜図１５は、ソフトウェア開発システムにおけるドキュメント等の作成または修正処理手順を示すフローチャートである。図１３に示すように、まず、ドキュメント作成処理が開始されると、ドキュメント等の新規作成であるか否かを判断する（ステップＳ１）。新規作成であるので（ステップＳ１：Ｙｅｓ）、ユーザは、工程定義ファイル６を作成し、ＢＩ工程のドキュメント内容を示すセルフキーを設定する（ステップＳ２）。作成終了であるか否かを判断し（ステップＳ３）、終了であれば（ステップＳ３：Ｙｅｓ）、処理を終了する。
【００４９】
作成終了でなければ（ステップＳ３：Ｎｏ）、ユーザは、各ドキュメント本体に版数付きでセルフキーを記載するとともに、ヘッダー部を作成する（ステップＳ４）。ユーザは、ヘッダー部に、版数付きでセルフキーを登録し、工程識別子として工程グループコードを登録し、第１、第２および第３のフラグ（フローチャートにおいては、それぞれフラグ１、フラグ２およびフラグ３と表記する）を設定する。ＢＩ工程のドキュメント等を作成する場合には、最上位のドキュメント等であるので、ユーザは、ヘッダー部にアッパーキーを登録しなくてよい。次いで、ユーザは、工程定義ファイル６にセルフキーを登録し（ステップＳ５）、処理を終了する。
【００５０】
ドキュメント等を追加する場合には、ドキュメント等の新規作成ではないので（ステップＳ１：Ｎｏ）、ドキュメント等の追加であるか否かを判断する（ステップＳ６）。追加であるので（ステップＳ６：Ｙｅｓ）、ユーザは、追加するドキュメント等についてステップＳ２〜ステップＳ５の処理を行う。ただし、ドキュメント等の追加処理では、工程定義ファイル６が既に作成されているので、ステップＳ２で新たに工程定義ファイル６を作成する必要はない。また、ドキュメント等の追加処理においてはＢＤ工程、ＦＤ工程またはＭＫ工程のドキュメント等を作成するので、ユーザは、ステップＳ４でヘッダー部にアッパーキーを登録し、工程識別子として工程グループコードまたはサブ工程識別子を登録する。また、ユーザは、工程定義ファイル６の各フィールドに格納されているデータを、追加したドキュメント等に応じて適宜、修正する必要がある。
【００５１】
ユーザは、ステップＳ１、ステップＳ６およびステップＳ２〜ステップＳ５の追加処理を繰り返すことにより、ＢＤ工程、ＦＤ工程またはＭＫ工程のドキュメント等を追加する。ドキュメント等を作成または追加する際には、工程定義ファイル６で一括りにされたセルフキー単位でドキュメント等を作成するのがよい。
【００５２】
ドキュメント等を修正する場合には、ドキュメント等の追加ではないので（ステップＳ６：Ｎｏ）、ユーザは、基点ドキュメント等として、修正対象のドキュメント等を開く（ステップＳ７）。次いで、工程定義記憶部７は、工程定義ファイル６の基点ドキュメント等の要修正フラグと基点フラグをオンにする（ステップＳ８）。なお、図８および図９に示す工程定義ファイル６のデータベース構造および具体例では、要修正フラグおよび基点フラグの各フィールドが省略されている。
【００５３】
次いで、ユーザは、開いた基点ドキュメント等のドキュメント本体を修正し、修正完了後、ドキュメント本体に記載されているセルフキーの版数を更新して、基点ドキュメント等を保存する（ステップＳ９）。その保存をトリガーとして、ドキュメント版数チェック部９は、保存された基点ドキュメント等について、ドキュメント本体内のセルフキーの版数とヘッダー部のセルフキーの版数が異なっているか否かを判断する（ステップＳ１０）。その結果、版数が異なっていれば（ステップＳ１０：Ｙｅｓ）、修正処理フラグ記憶部８は、基点ドキュメント等が修正されたと判断し、基点ドキュメント等の第１のフラグと第３のフラグをオンにする。また、工程定義記憶部７は、工程定義ファイル６の基点ドキュメント等の要修正フラグをオフにする（ステップＳ１１）。
【００５４】
次いで、修正処理フラグ記憶部８は、修正された基点ドキュメント等のヘッダー部のアッパーキーに基づいて、関連する上位ドキュメント等を検索し、該当する上位ドキュメント等のヘッダー部の第２のフラグをオンにする。また、工程定義記憶部７は、工程定義ファイル６の該当する上位ドキュメント等の要修正フラグをオンにする（ステップＳ１２）。該当する全ての上位ドキュメント等のフラグ操作が終了したか否か判断し（ステップＳ１３）、終了していない場合には（ステップＳ１３：Ｎｏ）、終了するまで、上位ドキュメント等の検索およびフラグ操作を繰り返す。
【００５５】
上位ドキュメント等に対するフラグ処理が終了したら（ステップＳ１３：Ｙｅｓ）、図１４に示すように、修正処理フラグ記憶部８は、工程定義ファイル６を参照し、基点ドキュメント等と同レベルの工程にあるドキュメント等（以下、同位ドキュメント等とする）の中から、同一セルフキーが登録されているドキュメント等を検索し、該当する同位ドキュメント等のヘッダー部の第２のフラグをオンにする。また、工程定義記憶部７は、工程定義ファイル６の該当する同位ドキュメント等の要修正フラグをオンにする。
【００５６】
そして、同位ドキュメント等に対するフラグ処理が終了したら、修正処理フラグ記憶部８は、工程定義ファイル６を参照し、基点ドキュメント等に関連する下位ドキュメント等を検索し、該当する下位ドキュメント等のヘッダー部の第２のフラグをオンにする。また、工程定義記憶部７は、工程定義ファイル６の該当する下位ドキュメント等の要修正フラグをオンにする（ステップＳ１４）。該当する全ての下位ドキュメント等のフラグ操作が終了したか否か判断し（ステップＳ１５）、終了していない場合には（ステップＳ１５：Ｎｏ）、終了するまで、下位ドキュメント等の検索およびフラグ操作を繰り返す。
【００５７】
下位ドキュメント等に対するフラグ処理が終了したら（ステップＳ１５：Ｙｅｓ）、主処理部４は、ディスプレイ１０８に、第２のフラグがオンになっているドキュメント等を表示し、ユーザに修正を促す。ユーザは、第２のフラグがオンになっている上位ドキュメント等を順次修正し、それぞれのドキュメント本体に記載されているセルフキーの版数を更新して、保存する。修正処理フラグ記憶部８は、保存された上位ドキュメント等の第２のフラグをオフにし、第３のフラグをオンにする。また、工程定義記憶部７は、工程定義ファイル６の修正済みの上位ドキュメント等の要修正フラグをオフにする（ステップＳ１６）。修正対象の上位ドキュメント等の修正が終了したか否かを判断する（ステップＳ１７）。終了していない場合には（ステップＳ１７：Ｎｏ）、終了するまで、上位ドキュメント等の修正処理を繰り返す。
【００５８】
上位ドキュメント等の修正処理が終了したら（ステップＳ１７：Ｙｅｓ）、ユーザは、同位ドキュメント等および下位ドキュメント等について、同様に、修正を行い、ドキュメント本体のセルフキーの版数を更新し、保存する。それに伴って、修正処理フラグ記憶部８は、保存された同位ドキュメント等および下位ドキュメント等の第２のフラグをオフにし、第３のフラグをオンにする。また、工程定義記憶部７は、工程定義ファイル６の修正済みの同位ドキュメント等および下位ドキュメント等の要修正フラグをオフにする（ステップＳ１８）。修正対象の同位ドキュメント等および下位ドキュメント等の修正が終了したか否かを判断し（ステップＳ１９）、終了していない場合には（ステップＳ１９：Ｎｏ）、終了するまで、同位ドキュメント等および下位ドキュメント等の修正処理を繰り返す。
【００５９】
同位ドキュメント等および下位ドキュメント等の修正処理が終了したら（ステップＳ１９：Ｙｅｓ）、修正処理フラグ記憶部８は、基点ドキュメント等の第１のフラグをオフにする。また、工程定義記憶部７は、工程定義ファイル６の基点ドキュメント等の基点フラグをオフにし（ステップＳ２０）、ドキュメント等の修正処理を終了する。同位ドキュメント等に対する処理は、例えば「Ｂ１１名前」ドキュメント等を基点ドキュメント等として修正処理を行う場合に実行される。
【００６０】
一方、基点ドキュメント等の修正が終了して、ドキュメント本体内のセルフキーの版数とヘッダー部のセルフキーの版数を比較した結果、版数が同じである場合には（ステップＳ１０：Ｎｏ）、図１５に示すように、主処理部４は、ディスプレイ１０８に、ドキュメント本体内のセルフキーの版数が変更されていないことを表示し、ユーザに対して版数の更新を促す（ステップＳ２１）。ユーザがドキュメント本体内のセルフキーの版数を更新しない場合（ステップＳ２２：Ｙｅｓ）、自ドキュメント等の修正内容が自ドキュメント等内で完結し、他のドキュメント等に影響を及ぼさないと判断する。そして、工程定義記憶部７は、工程定義ファイル６の基点ドキュメント等の要修正フラグと基点フラグをオフにし（ステップＳ２３）、ドキュメント等の修正処理を終了する。ユーザに対して版数の更新を促した結果、ユーザがドキュメント本体内のセルフキーの版数を更新する場合には（ステップＳ２２：Ｎｏ）、ステップＳ９へ戻り、セルフキーの版数を更新した後、上述した関連するドキュメント等の修正処理を行う。
【００６１】
図１６は、ソフトウェア開発システムにおけるオブジェクト生成処理手順を示すフローチャートである。図１６に示すように、オブジェクト生成処理が開始されると、オブジェクト生成部５は、修正処理フラグ記憶部８を経由して各種ドキュメント等内のヘッダー部のフラグをチェックする。コンパイルの対象となる全てのドキュメント等について、第１、第２および第３のフラグが全てオフであるか、または第３のフラグのみがオンであれば（ステップＳ３１：Ｙｅｓ）、オブジェクト生成部５は、オブジェクトの生成を許可する。その結果、オブジェクト生成部５は、コンパイルおよびリンケージ処理を行い（ステップＳ３２）、オブジェクト生成処理を終了する。フラグをチェックした結果、コンパイル対象のいずれかのドキュメント等において、第１のフラグまたは第２のフラグがオンである場合には（ステップＳ３１：Ｎｏ）、オブジェクト生成部５は、オブジェクトの生成を許可しない。この場合には、ステップＳ１へ戻る。
【００６２】
以上説明したように、本実施の形態によれば、同一レベルの工程において同一セルフキーが設定されているドキュメント等を検索することができるので、修正の影響が及ぶドキュメント等を細かく抽出することができる。また、上位のドキュメント等の数とそのすぐ下位のドキュメント等の数が１：Ｎの関係となる場合に機能マトリクスを用いることによって、一ドキュメント等に対する修正の影響が広い範囲に及ぶのを防ぐことができる。また、他のドキュメント等に影響のない修正を行った場合には、他のドキュメント等の検索が行われないので、無用なドキュメント検索処理を行わずに済む。また、アッパーキーにより上位ドキュメント等との依存関係を特定し、下位ドキュメント等については工程定義ファイルにより依存関係を特定するので、設計の初期段階において下位ドキュメント等や作成するフェーズが未定である場合でも、作成が終了したドキュメント等をすぐに記憶することができる。
【００６３】
また、いずれかのドキュメント等が修正されたときに、上位ドキュメント等、同位ドキュメント等および下位ドキュメント等の中から、その修正の影響が及ぶドキュメント等を検索し、基点ドキュメント等に対する修正内容を反映させることができる。従って、依存関係のある複数のドキュメント等の間に不整合が生じるのを防ぐことができる。また、ソフトウェア開発における設計ドキュメントからソースコードまでの内容について、特別な作業を追加することなく、一意性を保証することができる。
【００６４】
以上において本発明は、上述した実施の形態に限らず、種々変更可能である。例えば、ドキュメント等は各工程内で生成される設計書であるが、各ドキュメント等は各工程設計書全体でもよいし、機能ごとの単位としてドキュメント等を作成し記憶するようにしてもよい。その際、各ドキュメント等内にキーワードを挿入しておき、このキーワードをセルフキーとしてそのドキュメント等を代表するものとして利用すればよい。また、セルフキーの版数を０〜９に限らず、１０以上の数値に拡張し、本来の改版履歴を表す版数として用いてもよい。
【００６５】
上述した実施の形態に関し、さらに以下の付記を開示する。
【００６６】
（付記１）階層化された複数の工程を経てソフトウェアを開発するソフトウェア開発システムであって、各工程内のドキュメントまたはソースコードに付与された第１のキーワードに基づいて自工程内のドキュメントまたはソースコードを記憶する第１の記憶手段と、各工程内のドキュメントまたはソースコードに付与された第２のキーワードに基づいて自工程内のドキュメントまたはソースコードに対する修正の影響が及ぶ上位工程のドキュメントまたはソースコードを記憶する第２の記憶手段と、各工程内のドキュメントまたはソースコードと該工程の下位工程内のドキュメントまたはソースコードの関係を定義する工程定義手段と、いずれかの工程内のドキュメントまたはソースコードに対する修正の影響が及ぶドキュメントまたはソースコードを、前記上位工程内のドキュメントまたはソースコードについては前記第２のキーワードに基づいて検索し、前記下位工程内のドキュメントまたはソースコードについては前記工程定義手段に基づいて検索する検索手段と、を備えることを特徴とするソフトウェア開発システム。
【００６７】
（付記２）各工程内のドキュメントまたはソースコードに付与され、前記ドキュメントまたはソースコードが修正されるたびに更新される第１の版数と、前記第１のキーワードに付与され、前記ドキュメントまたはソースコードに対する修正の影響が及ぶ全てのドキュメントまたはソースコードの修正が終了すると更新される第２の版数と、をさらに備え、前記検索手段は、前記第１の版数と前記第２の版数が異なることをトリガーとして前記検索処理を行うことを特徴とする付記１に記載のソフトウェア開発システム。
【００６８】
（付記３）各工程がさらに複数の小工程からなり、各小工程内のドキュメントまたはソースコードに付与され、小工程を識別する工程識別子、をさらに備え、前記第１の記憶手段は、前記工程識別子に基づいて自工程内の各小工程内のドキュメントまたはソースコードを記憶し、前記検索手段は、いずれかの工程内のドキュメントまたはソースコードに対する修正の影響が及ぶドキュメントまたはソースコードを、前記自工程内の各小工程のドキュメントまたはソースコードについては前記工程識別子に基づいて検索することを特徴とする付記１または２に記載のソフトウェア開発システム。
【００６９】
（付記４）前記第１のキーワードは、上位工程のドキュメントまたはソースコードに付与された前記第２のキーワードであることを特徴とする付記１〜３のいずれか一つに記載のソフトウェア開発システム。
【００７０】
（付記５）各工程内のドキュメントまたはソースコードに付与され、他のドキュメントまたはソースコードから独立して自発的に修正を行うことを示す第１のフラグと、各工程内のドキュメントまたはソースコードに付与され、他のドキュメントまたはソースコードに依存して修正を行うことを示す第２のフラグと、各工程内のドキュメントまたはソースコードに付与され、修正が完了したことを示す第３のフラグと、いずれかの工程内のドキュメントまたはソースコードが修正されるときに、前記各フラグの状態を記憶する記憶手段と、をさらに備えることを特徴とする付記１〜４のいずれか一つに記載のソフトウェア開発システム。
【００７１】
（付記６）前記第１のフラグまたは前記第２のフラグがオンにされているドキュメントまたはソースコードの修正を促す処理手段、をさらに備えることを特徴とする付記５に記載のソフトウェア開発システム。
【図面の簡単な説明】
【００７２】
【図１】実施の形態にかかるソフトウェア開発システムのハードウェア構成を示す説明図である。
【図２】実施の形態にかかるソフトウェア開発システムの機能的構成を示すブロック図である。
【図３】工程定義の概念の一例を示す説明図である。
【図４】ドキュメント等の構成の一例を示す説明図である。
【図５】ドキュメント等の構成の一例を示す説明図である。
【図６】ドキュメント等の構成の一例を示す説明図である。
【図７】ドキュメント等の構成の一例を示す説明図である。
【図８】工程定義ファイルのデータベース構造の一例を示す説明図である。
【図９】工程定義ファイルの一例を示す説明図である。
【図１０】図９に示す工程定義ファイルにより定義されるリンクを概念的に示す説明図である。
【図１１】ドキュメント等の依存関係をまとめた機能マトリクスの一例を示す説明図である。
【図１２】表示画面の一例を示す説明図である。
【図１３】実施の形態にかかるソフトウェア開発システムにおけるドキュメントの作成または修正処理手順を示すフローチャートである。
【図１４】図１３の続きを示すフローチャートである。
【図１５】図１３の続きを示すフローチャートである。
【図１６】実施の形態にかかるソフトウェア開発システムにおけるオブジェクト生成処理手順を示すフローチャートである。
【符号の説明】
【００７３】
１  ソフトウェア開発システム
３  第１の記憶手段、第２の記憶手段
４  処理手段
６，７  工程定義手段
８  検索手段、記憶手段
【図１】
2010039751.tif 000003
【図２】
2010039751.tif 000004
【図３】
2010039751.tif 000005
【図４】
2010039751.tif 000006
【図５】
2010039751.tif 000007
【図６】
2010039751.tif 000008
【図７】
2010039751.tif 000009
【図８】
2010039751.tif 000010
【図９】
2010039751.tif 000011
【図１０】
2010039751.tif 000012
【図１１】
2010039751.tif 000013
【図１２】
2010039751.tif 000014
【図１３】
2010039751.tif 000015
【図１４】
2010039751.tif 000016
【図１５】
2010039751.tif 000017
【図１６】
2010039751.tif 000018