JP5179207B2 - ソフトウェア開発支援の装置、そのプログラム、及び方法 - Google Patents

Description

本発明は、設計単位毎の設計情報を複数集めて形成されるソフトウェアの開発支援技術に関する。

企業システム開発などの大規模なソフトウェア開発には、多数の人が参加し、またそこで生産される成果物も膨大となる。そのため、人と人、成果物と人、成果物と成果物の関係が非常に複雑になる。この複雑さに取り組むために大規模ソフトウェア開発では、一般的にウォーターフォールと呼ばれる開発手法が用いられる。

ウォーターフォールでは、まず、開発プロセスを工程やステップに分割する。そして、ある工程での設計作業が完了し、精査・承認された後、次の工程へ進む。また、各々の工程の設計作業では、上流工程の設計成果物を用いて設計を行い、出来上がった成果物を下流に引き渡すことでプロジェクトを進める。そうすることで、成果物の流れや担当者を明確化し、進捗の管理を容易に行える。

しかし、実際には、すべての設計情報が揃って次の工程へ進むことはまれであり、また上流工程に手戻りが無いこともまれである。
主だった理由は、下記３点である。
１．上流の設計成果物のすべてが揃ってから、下流の作業が始まるのでは、遅延が大きすぎる。
２．特に企業システムでは、要件が変わることはしばしばあり、要件変更に伴い仕様変更が行われる。
３．誤謬が一切無く設計が行われることは、現実的に考えづらく、どうしてもバグへの対処のための仕様変更が起きる。

先に述べたように、成果物の数が膨大であり複雑なため、１つの成果物に関連する成果物の数が多いので、仕様変更の際に仕様変更に関連する成果物を調査し、変更可能性のある成果物を人手で洗い出すのは非常に困難である。

これをシステム的にサポートする技術としては、例えば、以下の特許文献1，２に記載されている技術がある。

前者の特許文献１に記載の技術では、公開された成果物間の関連を取得・管理し、ある成果物に変更があった場合、関連する他の成果物にフラグ付けをするなどして開発者に通知することで、変更可能性のある成果物情報を提供している。

また、後者の特許文献２に記載の技術では、複数の公開された成果物の共通部分を抽出して一元管理し、ある成果物に変更があった場合、一元管理されている共通部分に対して上書きすることで、自動的に変更を反映し、仕様変更反映の支援を行っている。

特開平５−３５４６０号公報 特開２００６−７９２１２号公報

かかる従来技術では、次のような問題がある。

すなわち、特許文献１，２に記載の技術では、いずれも、仕様変更が発生した際、もし仕様変更の影響を受ける開発者が仕様変更となった設計情報を取得し直していないことが、成果物をリポジトリへ登録した後になってようやく、開発者や管理者に明らかになる点である。リポジトリとは、ソフトウェア開発を行う際に用いられる設計成果物を格納するためのデータベースで、ここに設計成果物を可能することで、他の開発者に設計成果物を公開し、この設計成果物に自由にアクセスできるようになっているものである。

大規模開発では、開発拠点が複数箇所に分散していたり、ネットワークの利用制約があったりといった物理的理由から、リポジトリと開発者の設計ツールとが常に接続されているということは難しい。また、変更がリポジトリから電子メール等で通知された場合でも、開発者は自身が現在取り組んでいる設計を完結させてから、仕様変更対応に取り組みたい、としばしば考える。そのために、通知を受けてもすぐに開発者のツールに変更された成果物を取り込まず、結果そのまま成果物の変更対応を忘れてしまうことがある。またそもそも通知自体を見逃してしまったりするなど、開発者側の理由から、設計ツールが保持している上流の成果物が、公開されている成果物とずれてしまうといった事態が発生する。大規模開発では開発者の数も多いので、こういった事態が発生する確率が高い。

このような場合、特許文献１，２に記載の技術では、前述したように、設計情報の公開後に、つまり設計成果物のリポジトリへの登録後に、設計情報（成果物）間の整合を確認して、初めて、再設計が必要なことが明らかになる。このとき、次のような問題が発生する。（１）開発者が最新の設計情報を参照せずに作業をしていた時間が無駄になる。（２）再設計の影響を受ける他の開発者が作業をしていた時間が無駄になる。特に（２）の問題は、開発が大規模であればあるほど影響範囲も大きく、再設計の必要性が明らかになるのが遅延すればするほど、多大な人月を浪費し、納期遅延の原因となる。

そこで、本発明は、設計情報の再設計等による無駄を削減し開発の効率化を図ることを目的とする。

前記問題点を解決するための発明は、
開発者が開発した複数の設計情報を、それぞれ公開設計情報として、コンピュータの第一の記憶領域に格納し、
開発者が設計情報の設計に利用する前記公開設計情報を前記第一の記憶領域から取得し、該公開設計情報を参照設計情報として該開発者に提供し、
複数の前記公開設計情報のうち、開発者が設計情報の設計に利用する公開設計情報を参照設計情報として、前記コンピュータの第二の記憶領域に格納し、
前記設計情報が前記公開設計情報として前記第一の記憶領域に格納されると、該公開設計情報と、前記第二の格納領域に格納されている前記参照設計情報のうち該公開設計情報を参照元とする参照設計情報との整合状態を確認し、該整合状態を第一の整合状態として、前記コンピュータの第三の記憶領域に格納し、
前記第三の記憶領域に格納されている前記整合状態の情報を含む開発状況情報を外部に通知し、
開発者が開発中の設計情報を受け付けて、開発設計情報として、前記コンピュータの第四の記憶領域に格納し、
前記開発設計情報が前記第四の記憶領域に格納されると、該開発設計情報中の参照設計情報と、前記第二の記憶領域に格納されている前記複数の参照設計情報のうち該開発設計情報の参照設計情報との整合状態を確認し、該整合状態を第二の整合状態として前記第三の記憶領域に格納する、ことを特徴とする。

本発明によれば、ある設計情報が公開設計情報として公開されると、この公開設計情報と、この公開設計情報を参照元とする参照設計情報との整合状態が確認され、この参照設計情報を利用した開発設計情報が公開される前であっても、この整合状態が開発者等に通知されるので、この開発設計情報に関する再設計等による無駄を削減し開発の効率化を図ることができる。

以下、本発明に係るソフトウェア開発支援装置の一実施形態について、図面を用いて説明する。

本実施形態のソフトウェア開発支援装置１００は、図１に示すように、ネットワークを介して、各開発者の開発者端末Ｄと接続されている。

このソフトウェア開発支援装置１００は、コンピュータであり、キーボードやマウス等の入力装置１０１と、ディスプレイやプリンタ等の出力装置１０２と、他の機器との間で通信を行うための通信装置１０３と、これらのインタフェース１０４と、各種演算処理を実行するＣＰＵ１１０と、このＣＰＵ１１０のワークエリアとなるメモリ１０５と、ハードディスクドライブ装置等の記憶装置２００と、これらを相互に接続するバス１０６とを有している。

記憶装置２００には、ソフトウェア開発支援プログラム２０１と、ソフトウェアの開発者が開発時に必要な情報が格納される開発者設計情報格納部２０２と、各種情報の整合状態が格納される整合状態格納部２０３と、開発者が設計した設計情報が一応完成し、これが公開設計情報（成果物）として格納される公開設計情報格納部２６０と、公開設計情報のステータスが格納される設計情報ステータス格納部２７０と、設計情報間の参照についての関連情報が格納される関連情報格納部２８０と、各設計情報の開発状況が格納される開発状況格納部２９０と、を有している。

開発者設計情報格納部２０２には、開発者が設計に利用する参照設計情報２１０と、開発者が実際に設計している開発設計情報２２０と、開発者を特定すると共に開発者が設計担当する工程等を特定する開発者情報２３０と、が格納される。参照設計情報２１０は、公開設計情報格納部２６０に格納されている公開設計情報のうちで、開発者が参照設計情報として利用する公開設計情報に、各種管理情報を付したものである。なお、以上の参照設計情報２１０、開発設計情報２２０、開発者情報２３０は、いずれも開発者毎に存在し、これらについては、後ほど詳細に説明する。

整合状態格納部２０３には、開発者設計情報格納部２０２に格納されている参照設計情報２１０が公開設計情報と整合しているか否かを示す格納参照整合情報２４０と、開発設計情報（公開、未公開を問わない）中の参照設計情報が、参照元の設計情報（公開、未公開を問わない）と整合しているか否かを示す設計情報内参照整合情報２５０とが格納される。なお、これら格納参照整合情報２４０及び設計情報内参照整合情報２５０に付いても、後ほど詳細に説明する。

ＣＰＵ１１０は、機能的に、開発者からの各種要求を受け付ける要求入力部１１１と、設計情報を受け付ける設計情報入力部１１２と、設計情報を出力する設計情報出力部１１３と、設計情報相互間の関連情報を取得する設計情報関連取得部１１４と、公開情報格納部２６０に格納されている複数の公開情報のうちの一部を参照設計情報２１０として開発者設計情報格納部２０２に格納する参照設計情報記録部１１５と、設計情報入力部１１２が受け付けた設計情報のうち公開要求のあったものを公開設計情報として公開設計情報格納部２６０に格納する設計情報公開部１１６と、公開情報格納部２６０に格納されている公開設計情報のステータスを管理するステータス管理部１１７と、開発者設計情報格納部２０２に格納されている参照設計情報２１０が公開設計情報と整合しているか否か確認する格納参照整合確認部１１８ａと、開発設計情報（公開、未公開を問わない）中の参照設計情報が、参照元の設計情報（公開、未公開を問わない）と整合しているか否かを示す設計情報内参照整合確認部１１８ｂと、開発状況情報を生成する開発状況生成部１１９ａと、開発状況情報を要求者に通知する開発状況通知部１１９ｂと、を有している。なお、これらの各機能部１１１〜１１９ｂは、いずれも、ソフトウェア開発支援プログラム２０１をＣＰＵ１１０が実行することで機能する。

次に、図２４に示す概念図を用いて、本実施形態におけるソフトウェア開発支援方法の概要を説明する。

ここでは、“インタフェース定義”の工程を担当する“satoh”は、公開設計情報格納部２６０内の“yamada”の公開設計情報“CostomerNo”２６１ａを参照設計情報として利用して、インタフェース定義“getCustomerInfoListByName”を設計するとする。さらに、“イメージビュー定義”の工程を担当する“kimura”は、公開設計情報格納部２６０内の“satoh”の公開設計情報“getCustomerInfoListByName”２６１ｂを参照設計情報として利用して、イメージビュー定義“CustomerInfoImageView”を設計するとする。すなわち、ここでは、“yamada”の設計情報“CostomerNo”が最上流の設計情報で、“satoh”の設計情報“getCustomerInfoListByName”がその下流の設計情報で、“kimura”の設計情報“CustomerInfoImageView”が最下流の設計情報であるとする。

ソフトウェア開発支援装置１００は、まず、開発者“satoh”からの要求に応じて、インタフェース定義“getCustomerInfoListByName”の設計に利用する公開設計情報格納部２６０内の“yamada”の公開設計情報“CostomerNo”２６１ａを参照設計情報として、開発者“satoh”に提供する。さらに、公開設計情報“CostomerNo”２６１ａを開発者設計情報格納部２０２に、参照設計情報２１０として格納する（Ｓ５）。

開発者“satoh”は、ソフトウェア開発支援装置１００から提供された参照設計情報“CostomerNo”を用いて、インタフェース定義“getCustomerInfoListByName”を設計する。ソフトウェア開発支援装置１００は、この開発者“satoh”からインタフェース定義“getCustomerInfoListByName”の保存要求を受けると、これを開発者設計情報格納部２０２に開発設計情報２２０として保存する（Ｓ１１）。

その後、ソフトウェア開発支援装置１００は、この開発者“satoh”からインタフェース定義“getCustomerInfoListByName”の公開要求を受けると、整合状態格納部２０３に格納されている整合情報を確認し（Ｓ１６）、この整合情報が“整合”であれば、この設計情報を公開設計情報２６１ｂとして公開する（Ｓ１７）。すなわち、インタフェース定義“getCustomerInfoListByName”を他の開発者も利用できるように、公開設計情報格納部２６０に公開設計情報２６１ｂとして格納する。

開発者“kimura”がイメージビュー定義“CustomerInfoImageView”を設計する場合も、以上と同様に、ソフトウェア開発支援装置１００は、公開設計情報“getCustomerInfoListByName”２６１ｂを開発者設計情報格納部２０２に、参照設計情報２１０として格納し（Ｓ５）、これを利用して設計されたイメージビュー定義“CustomerInfoImageView”を開発者設計情報格納部２０２に開発設計情報２２０として保存する（Ｓ１１）。さらに、ソフトウェア開発支援装置１００は、開発者“kimura”からイメージビュー定義“CustomerInfoImageView”の公開要求を受けると、整合情報を確認した後（Ｓ１６）、この設計情報を公開設計情報２６１ｃとして公開する（Ｓ１７）。

ところで、ソフトウェアの実際の開発では、開発者“satoh”からインタフェース定義“getCustomerInfoListByName”を公開する前に、さらには公開した後に、参照していた“yamada”の公開設計情報“CostomerNo”２６１ａが、“CostomerID”に変更されることが度々ある。この最上流の設計情報“CostomerNo”の変更は、その下流の“satoh”の設計情報“getCustomerInfoListByName”に影響を与えるのみならず、さらにその下流の“kimura”の設計情報“CustomerInfoImageView”にも影響を与える。

「背景技術」の欄で述べたように、ネットワークの制約や開発者自身の本題等により、開発者端末が保持している参照設計情報が公開設計情報格納部２６０に格納されている公開設計情報とズレてしまうといった事態が発生し得る。その場合、特許文献１，２の技術では、設計情報を公開した後に、初めて、この設計情報に不整合があり、再設計が必要となることが明らかになる。このため、再設計の必要性が明らかになるのが遅延すする等の問題が生じる。

そこで、本実施形態では、開発者“kimura”が参照する設計情報“getCustomerInfoListByName”をこの開発者に提供するのみならず、これを参照設計情報２１０として開発者設計情報格納部２０２に格納しておき、この参照設計情報を利用した開発設計情報“CustomerInfoImageView”が公開されなくても、この開発設計情報の上流の開発設計情報、つまり参照設計情報の元になっている開発設計情報“getCustomerInfoListByName”が公開設計情報２１６ｂとして公開されたときに（Ｓ１７）、この公開設計情報２１６ｂとこれを参照する開発設計情報の参照設計情報“getCustomerInfoListByName”２１０との整合状態を確認し（Ｓ１９）、この整合状態を開発者“kimura”等に通知するようにしている。

さらに、本実施形態では、設計情報“getCustomerInfoListByName”が開発設計情報２２０として開発者設計情報格納部２０２に保存されたとき（Ｓ１１）、この開発設計情報“getCustomerInfoListByName”中の参照設計情報“CostomerNo”と、開発者設計情格納部２０２に参照設計情報２１０として格納されている“CostomerNo”との整合状態を確認し（Ｓ１３）、この整合状態も開発者等に通知するようにしている。また、本実施形態では、開発設計情報“getCustomerInfoListByName”が、修正後に再び公開設計情報２１６ｂとして公開されたとき（Ｓ１７）、この公開設計情報２１６ｂを参照している設計情報“CustomerInfoImageView”２６１ｃが公開されていれば、新たに公開された公開設計情報“getCustomerInfoListByName”２１６ｂと、既に公開されている下流側の公開設計情報“CustomerInfoImageView”２６１ｃ中の参照設計情報“getCustomerInfoListByName”との整合状態を確認し（Ｓ２１）、この整合状態も開発者等に通知するようにしている。

次に、図１６〜図２１に示すフローチャートを用いて、本実施形態のソフトウェア開発支援装置１００の動作について説明する。

図１６に示すように、ステップ１は、ソフトウェア開発が続いている間、ソフトウェア開発支援装置１００が動作することを示すループである。開発者、もしくは管理者の要求の待ち状態である。もし開発終了になったのであればループを抜け、開発終了となる。開発者もしくは管理者から開発に関する要求があった場合、すなわち開発が続行していれば、ステップ２へ進む。

ステップ２は、要求入力部１１１が、開発者、もしく管理者からの要求が、設計情報の取得要求か否かを判定する処理である。もし設計情報の取得要求であれば、ステップ３へ進み、要求が設計情報の取得要求でなければ、ステップ１０（図１７）へ進む。

以下、ステップ３からステップ９は、設計情報取得要求に関する処理であり、図２に示す各機能部１１１，１１３，１１５，１１７，１１８aにより実行される。

ステップ３は、要求入力部１１１が設計情報の取得要求種別を判定する処理である。もし設計情報の取得要求種別が、設計の際に参照する参照設計情報の取得要求であれば、ステップ４へ進む。もし設計情報の取得要求種別がこれから着手しようとする開発設計情報の取得要求であればステップ７へ進む。

以下ステップ４からステップ６は、参照設計情報取得要求に関する処理である。

ステップ４は、設計情報出力部１１３が参照設計情報を開発者に提供する処理である。設計情報出力部１１３は、開発者情報２３０に基づき、開発者が参照する公開設計情報の一覧を公開設計情報格納部２６０から取り出し、この公開設計情報を参照設計情報として、通信装置１０３を介して開発者端末Ｄへ、若しくは出力装置１０２へ出力する。

ここで、開発者情報２３０は、図６に示すように、当該開発者を示す開発者識別子２３１と、当該開発者が担当している工程を示す担当工程種別２３２と、担当工程内の担当設計情報を示す担当設計情報識別子２３３と、当該開発者が設計のために用いる参照設計情報を設計する工程を示す参照工程種別２３４と、参照工程内の参照設計情報を示す参照設計情報識別子２３５とを含む情報である。なお、ここでの担当設計情報識別子２３３及び参照設計情報識別子２３５は、参照設計情報そのものを示すものではなく、あくまでもワイルドカードである。また、この開発者情報２３０は、開発するソフトウェアの計画段階で定められる情報で、実際に、このソフトウェア開発支援装置１００により、開発支援が行われる以前に設定される情報である。

公開設計情報格納部２６０は、開発者が設計した設計情報が一応完成し、これが公開設計情報（成果物）として格納されるデータベース、すなわち、リポジトリである。ここに格納される公開設計情報２６１ａ，２６１ｂは、図４及び図５に示すように、設計本体情報２６２ａ，２６２ｂと、この設計本体情報２６２ａ，２６２ｂの管理情報２６５とを含む情報である。設計本体情報２６２ａ，２６２ｂは、設計情報の識別子（データ項目識別子、インタフェース識別子）２６３ａ，２６３ｂと、設計情報名（データ項目名、インタフェース名）２６４ａ，２６４ｂと、各種データとを含んでいる。また、管理情報２６５は、設計本体情報２６２ａ，２６２ｂが更新された日時を示す更新日時２６６と、設計本体情報２６２ａ，２６２ｂが登録されてから何回更新されたかを示す更新回数２６７とを含んでいる。なお、図４では、設計工程がデータ項目定義である場合の公開設計情報２６１ａを示し、図５では、設計工程がインタフェース定義である場合の公開設計情報２６１ｂを示しており、これらの図から理解できるように、設計本体情報２６２ａ，２６２ｂ中の各種データは、設計の対象になっている工程等が異なれば、データ種の内容、データ種の数も異なる。

また、本実施形態において、設計情報とは、これ以上細分化すると、設計情報として意味をなさなくなる最小の設計単位で、図４及び図５における１レコード分の情報のことである。言い換えると、図４及び図５における１レコード中の各項目データをまとめた情報である。

例えば、このステップ４において、“satoh”という識別子を持つ開発者が、参照設計情報の取得を要求したとすると、設計情報出力部１１３は、開発者情報２３０（図６）を参照して、開発者識別子２３１が“satoh”のレコードから、参照工程種別“データ項目定義”２３４、参照設計情報識別子“Ｄ”２３５を把握し、これに対応する全公開設計情報（図４中のデータ項目識別子がＤである全て）を公開設計情報格納部２６０から取得する。そして、設計情報出力部１１３は、これら全公開設計情報のそれぞれを参照設計情報として、開発者に提供する。

ステップ５は、参照設計情報記録部１１５が参照設計情報を開発者設計情報格納部２０２に格納する処理である。参照設計情報記録部１１５は、ステップ４で、設計情報出力部１１３が開発者に提供した公開設計情報を取得し、これを当該開発者の参照設計情報２１０として、開発者設計情報格納部２０２に格納する。

参照設計情報２１０は、図７に示すように、設計本体情報２１６と、この設計本体情報２１６の管理情報２１１とを含んでいる。この設計本体情報２１６は、ステップ４で、設計情報出力部１１３が開発者に参照設計情報として提供した公開設計情報２６１ａ中の設計本体情報２６２ａである。また、管理情報２１１は、参照設計情報識別子２１２と、ステップ４で参照設計情報を取得した開発者の識別子である取得者識別子２１３と、参照設計情報を提供した日時である取得日時２１４と、この参照設計情報を取得した際の更新回数である取得時更新回数２１５と、を含む。なお、取得時更新回数２１５は、開発者が公開設計情報を参照設計情報として取得した際、この公開設計情報２６１ａ中の更新回数２６７（図４）である。

例えば、前述したように、ステップ４で、“satoh”という識別子を持つ開発者による参照設計情報の取得要求に対して、この開発者に参照設計情報として公開設計情報２６１ａ（図４）を提供した場合、開発者設計情報格納部２０２には、図７に示すように、取得者識別子２１３が“satoh”である全レコードのそれぞれが参照設計情報２１０として格納される。

ステップ６は、格納参照整合確認部１１８ａが、ステップ５で格納した参照設計情報の整合状態を記録する処理である。ここでは、開発者に対して最新の参照設計情報を提供したばかりで、この参照設計情報の元になった公開設計情報に対する、この参照設計情報の整合状態として“整合”を記録する。

参照設計情報の提供を受けた開発者の格納参照整合情報２４０は、図９に示すように、この格納参照整合情報２４０を一意に特定する識別子である参照整合情報識別子２４１と、開発者が取得した参照設計情報の識別子である参照設計情報識別子２４２と、この参照設計情報を取得した開発者の識別子である取得者識別子２４３と、この参照設計情報の識別子である設計情報（データ項目）識別子２４４と、公開設計情報に対するこの参照設計情報の整合状態２４５と、この整合状態が始まった日時である状態開始日時２４６とを含む。このステップ６では、例えば、取得者識別子２４３が“satoh”で、この“satoh”がステップ４で取得した全参照設計情報の整合状態２４５は、全て“整合”として記録される。

以上で、参照設計情報の取得に関する処理は終了し、ステップ１へ戻る。

本実施形態においては、ステップ３で開発者に提供した参照設計情報を、ステップ５で保持しておくことにより、この開発者がこの参照設計情報を用いた設計情報を公開する以前に、この参照設計情報や、この参照設計情報を用いた設計情報に不整合が起きている可能性があることを早期に検知することができる。その結果、開発者や管理者に最新の整合状態を、設計情報の公開前に通知できるようになり、また、開発者の進捗状況についても詳細に提供することができるようになる。なお、整合状態の通知方法の詳細については、後ほど詳細に説明する。

前述したように、ステップ３において、設計情報の取得要求種別が開発設計情報の取得要求であると判断されれば、ステップ７へ進む。以下、ステップ７〜ステップ９は、開発設計情報の取得要求に関する処理である。

ステップ７は、ステータス管理部１１７が、設計情報ステータス格納部２７０を参照して、開発設計情報のステータスを確認する処理である。開発設計情報のステータスは、図２３に示すように、開発設計情報の編集が一応終了し、公開設計情報として公開されているチェックイン状態と、開発者により開発設計情報が編集中であるチェックアウト状態とがある。チェックアウト状態は、開発設計情報の編集が排他状態であり、この開発設計情報がチェックイン状態になるまでの間、他の開発者は編集することができない。もし、開発設計情報のステータスが既にチェックアウト状態（編集中）であれば、開発設計情報の取得ができないので、開発設計情報の取得要求を却下し、ステップ１へ戻る。また、開発設計情報のステータスがチェックイン状態（公開中）であれば、ステップ８へ進む。

ステップ８は、設計情報出力部１１３が開発（公開）設計情報を提供する処理である。設計情報出力部１１３は、開発者が要求する設計情報を公開設計情報格納部２６０から取り出し、この公開設計情報を開発設計情報として、通信装置１０３を介して開発者端末Ｄへ、若しくは出力装置１０２へ出力する。この際、開発者情報２３０に基づき、担当工程以外の設計情報について開発設計情報の取得をしようとしていないか確認してもよい。

ステップ９は、ステータス管理部１１７が公開設計情報のステータスを更新する処理である。テータス管理部１１７は、ステップ８で公開設計情報を開発設計情報として開発者に提供したことにより、この公開設計情報を編集中扱いにするために、この公開設計情報に関してチェックアウト状態になったことを設計情報ステータス格納部２７０に書き込む。

このステップ９により、開発設計情報の取得要求に関する処理は終了し、ステップ１へ戻る。

前述したように、ステップ２において、開発者もしくは管理者からの要求が設計情報の取得要求ではないと判断された場合には、ステップ１０（図１７）に進む。

以下、図１７のフローチャート中のステップ１０からステップ２２は、開発設計情報の保存要求に関する処理であり、図３に示す各機能部１１１，１１２，１１４，１１６，１１７，１１８a，１１８ｂにより実行される。

ステップ１０は、要求入力部１１１が、開発者もしくは管理者の要求が開発設計情報の保存要求かどうかを判定する処理である。もし、開発設計情報の保存要求であれば、ステップ１１へ進み、開発設計情報の保存要求でなければ、ステップ１５へ進む。

以下、ステップ１１からステップ１４は、開発設計情報の保存要求に対する処理である。

ステップ１１は、設計情報入力部１１２が、開発者等からの開発設計情報を保存する処理である。設計情報入力部１１２は、開発者端末Ｄからの開発設計情報を通信装置１０３及び要求入力部１１１を介して受け付け、これを開発者設計情報格納部２０２に当該開発者の開発設計情報２２０として保存する。なお、開発者等からの開発設計情報の受付は、入力装置１０１から受け付ける場合もある。

開発者設計情報格納部２０２に保存された開発設計情報２２０は、図８に示すように、開発設計本体情報２２２と、その管理情報２２５とを含んでいる。この開発設計情報２２０に関する固定種別がインタフェース定義である場合、開発設計本体情報２２２は、設計情報の識別子であるインタフェース識別子２２３と、設計情報名であるインタフェース名２２４と、各種データとを含んでいる。また、管理情報２２５は、当該開発設計情報２２０が保存された日時２２６と、当該開発設計情報２２０の保存者の識別子２２７とを含んでいる。設計情報入力部１１２は、開発設計情報を受け付けた際、設計情報の識別子であるインタフェース識別子２２３が未設定である場合には、これを設定する。なお、図８は、開発者“satoh”が新たにインターフェイス定義“getCustomerInfoListByName”を設計し、これを保存した場合の例である。

ステップ１２は、設計情報関連取得部１１４が関連情報を取得する処理である。設計情報入力部１１２は、ステップ１１で開発設計情報２２０を保存すると、設計情報関連取得部１１４を呼び出す。設計情報関連取得部１１４は、ステップ１１で保存された開発設計情報２２０中の各項目データと、この開発設計情報２２０の参照設計情報との関連を取得し、これを関連情報格納部２８０に書き込む。つまり、設計関連情報取得部１１４は、開発設計情報２２０中のどこに、どのような参照設計情報が用いられているかを把握し、これを関連情報格納部２８０に書き込む。

関連情報格納部２８０に書き込まれた関連情報２８１には、図１２に示すように、関連情報識別子２８２と、対象となる開発設計情報の項目識別子２８５と、この項目のデータ名２８６と、この項目で参照している参照設計情報の識別子２８３と、この参照設計情報の名２８４と、を含んでいる。

例えば、図１２の関連情報２８１中で、最上部のレコードに示されている関連情報識別子２８２が“REL-00235”の関連情報２８１は、図８に示す開発設計情報２２０中で、インタフェース出力項目識別子“IFOUT-0104（項目識別子２８５）”及びインタフェース情報項目名“CostomerNo（項目データ名２８６）”で特定される項目に関して、図７中の参照設計情報２１０中で、最上部のレコードに示されている参照設計情報識別子２１２が“REF-000001（２８２）”で、データ項目識別子が“D-0001（２８３）”で、データ項目名が“CostomerNo（２８４）”で特定される参照設計情報を用いていることを示している。

ステップ１３は、情報内参照整合確認部１１８ｂが、開発設計情報中の参照設計情報が参照元の設計情報と整合しているか否かを確認する処理である。すなわち、ここでは、ステップ１１で保存した開発設計情報中の参照設計情報が、この開発設計情報の編集中に変更されて、この参照設計情報の新しいものと整合しているか否かを確認する。情報内参照整合確認部１１８ｂは、ステップ１２で関連情報格納部２８０に書き込まれた関連情報２８１を参照して、図２４に示すように、この関連情報２８１が示す参照設計情報を開発者設計情報格納部２０２から取得し、この参照設計情報と、この関連情報２８１が示す開発設計情報中の項目データ（参照設計情報）とを比較し、両者の整合状態を確認する。

ステップ１４は、情報内参照整合確認部１１８ｂがステップ１３に確認した情報内参照整合の状態を、整合状態格納部２０３に記録する処理である。

整合状態格納部２０３に記録された情報内参照整合情報２５０は、図１１に示すように、整合情報識別子２５１と、関連情報識別子２５２と、参照設計情報識別子２５３と、参照設計情報名２５４と、開発設計情報の項目識別子２５５と、開発設計情報の項目データ名２５６と、整合状態２５７と、この整合状態が始まった日時である状態開始日時２５８とを含んでいる。これらのデータのうち、関連情報識別子２５２と参照設計情報識別子２５３と参照設計情報名２５４と開発設計情報の項目識別子２５５は、対応する関連情報２８０の対応データで同じである。

以上で、開発設計情報の保存要求に対する処理が終了し、ステップ１へ戻る。

前述したように、ステップ１０において、開発者もしくは管理者からの要求が開発設計情報の保存要求ではないと判断された場合には、ステップ１５に進む。

ステップ１５は、要求入力部１１１が、開発者もしくは管理者の要求が開発設計情報の公開要求かどうかを判定する処理である。もし開発設計情報の公開要求であれば、ステップ１６へ進む。公開要求でなければ、ステップ２３（図１８）へ進む。

以下、ステップ１６からステップ２２は、開発設計情報の公開要求に対する処理である。

ステップ１６は、この開発設計情報に関する格納参照整合情報２４０及び情報内参照整合情報２５０を確認をする処理である。

格納参照整合確認部１１８ａは、関連情報格納部２８０に格納されている関連情報２８１を参照して、開発者が公開要求している開発設計情報に用いている参照設計情報の識別子を取得し、この識別子の参照設計情報の格納参照整合情報２４０を確認する。例えば、公開要求の対象が図８に示すインターフェイス定義“getCustomerInfoListByName”である場合、格納参照整合確認部１１８aは、関連情報格納部２８０に格納されている関連情報２８１（図１２）を参照して、この開発設計情報“getCustomerInfoListByName”の項目識別子“IFOUT−0104”，“IFOUT−0105”，…の参照設計情報識別子“D−0001”，“D−0002”，…を取得し、この識別子“D−0001”，“D−0002”，…の全格納参照整合情報２４０（図９）を確認する。この場合、図９中の取得者識別子が“satoh”の全格納参照整合情報２４０の整合状態２４５が全て“整合”であるか否かを確認し、全てが“整合”であれば、この開発設計情報“getCustomerInfoListByName”の格納参照整合状態は“整合”であるとする。

情報内参照整合確認部１１８ｂは、開発者が公開要求している開発設計情報から、この開発設計情報に用いている参照設計情報の識別子、つまり項目識別子を取得し、この識別子の参照設計情報の情報内参照整合情報２５０を確認する。例えば、情報対参照整合確認部１１８ｂは、開発設計情報“getCustomerInfoListByName”の項目識別子“IFOUT−0104”，“IFOUT−0105”，…を取得し、この識別子“IFOUT−0104”，“IFOUT−0105”，…の全情報内参照整合情報２５０（図１１）を確認する。この場合、図１１中の全情報対参照整合情報２５０の整合状態２５７が全て“整合”であるか否かを確認し、全てが“整合”であれば、この開発設計情報“getCustomerInfoListByName”の情報内参照整合状態は“整合”であるとする。

開発設計情報に関する全格納参照整合情報２４０が“整合”を示し且つ全情報内参照整合情報２５０が“整合”を示していれば、ステップ１７の公開処理に進み、そうでなければ、この開発設計情報の公開は却下される。

ステップ１７は、設計情報公開部１１６がこの開発設計情報を公開する、言い換えると、この開発設計情報を公開設計情報として、公開設計情報格納部２６０に格納する処理である。例えば、図２４に示すように、開発設計情報“getCustomerInfoListByName”が公開設計情報２１６ｂとして、公開設計格納部２６０に格納される。

ステップ１８は、ステータス管理部１１７がこの開発設計情報のステータスを更新する処理である。設計情報公開部１１６は、この開発設計情報が公開設計情報として公開設計情報格納部２６０に格納されたことで、この公開設計情報がチェックイン状態になった旨を設計情報ステータス格納部２７０に書き込む。

ステップ１９は、格納参照整合確認部１１８ａが、図２４に示すように、この公開設計情報と、この公開設計情報を参照元の情報としている他の開発者の参照設計情報との格納参照整合状態を確認する処理である。この処理によって、公開された設計情報を参照している他の開発者の開発設計情報が、古い情報を参照しているか否かが明らかになる。その結果、例えば、公開された設計情報を参照している開発者が、もし、一定期間以上、当該設計情報を更新しない場合は、この開発者の開発設計情報が公開されていなくても、当該開発者にフォローできるようになる。

ここで、格納参照整合確認部１１８ａによるステップ１９の詳細処理について、図１９及び図２０に示すフローチャートを用いて説明する。

ステップ３１は、公開した開発設計情報の公開種別を確認する処理である。公開種別が開発設計情報の追加であれば、ステップ３２に進み、公開種別が開発設計情報の更新であれば、ステップ３５に進み、公開種別が開発設計情報の削除であれば、ステップ４１（図２０）に進む。なお、格納参照整合確認部１１８ａは、図４に示すように、変更前の公開設計情報と変更後の公開設計情報とを比較することで、公開種別が、追加、更新、削除のいずれかであることを確認する。

ステップ３２は、公開種別が追加の開発設計情報を参照している開発者を抽出する処理である。格納参照整合確認部１１８ａは、開発者情報２３０（図６）を参照して、この開発設計情報を開発する工程種別を参照工程種別２３４としている開発者識別子２３１を抽出する。

ステップ３３は、ステップ３２で抽出した開発者の参照設計情報は“追加物未参照不整合”であるとする処理である。公開種別が追加の開発設計情報を参照している開発者は、未だこの開発設計情報を取得していない。取得忘れがあると、新規公開又は追加された開発設計情報に関する設計・開発の抜け漏れの原因となる。そこで、当該設計情報について追加物未参照不整合とする。

例えば、データ項目開発者“yamada”が、このデータ項目の公開設計情報一覧を取得し、図４に示す変更後の公開設計情報一覧のように、データ項目“ItemPrice”を追加して、これを公開設計情報として公開した場合、この公開設計情報を開発するする工程は「データ項目定義」である。そこで、格納参照整合確認部１１８ａは、前述のステップ３２で、開発者情報２３０（図６）を参照して、「データ項目定義」を参照工程種別２３４としている開発者識別子２３１を抽出する。例えば、図６においては開発者“satoh”を抽出する。そして、開発者“satoh”は、データ項目“ItemPrice”について追加物未参照不整合とする。

ステップ３４は、ステップ３２による抽出処理で未抽出の開発者が存在するか否かを判断する処理である。未抽出の開発者が存在するならば、ステップ３２に戻って開発者の抽出処理を行い、未抽出の開発者が存在しなければ、本処理を終了する。

前述したように、ステップ３１で、開発設計情報の公開種別が更新であると判断した場合には、ステップ３５に進む。

ステップ３５は、参照設計情報一覧から、識別子が当該開発設計情報と一致する参照設計情報を抽出する処理である。格納参照整合確認部１１８ａは、開発者設計情報格納部２０２から参照設計情報一覧を取得し、公開された当該設計開発情報の識別子と一致する識別子の参照設計情報を抽出する。

ステップ３６は、公開された開発設計情報の管理情報と、抽出された参照設計情報の管理情報とが一致するかどうかを判定する処理である。もし、管理情報が一致すれば、ステップ３９へ進む。もし管理情報が一致しなければ、ステップ３７へ進む。

ステップ３７は、公開された開発設計情報の開発設計本体情報と、抽出された参照設計情報の参照設計本体情報とが一致するかどうかを判定する処理である。もし、両設計本体情報の各項目データが一致すれば、ステップ３９へ進む。もし、両設計本体情報の各項目データのいずれかが一致しなければ、ステップ３８へ進む。

ステップ３８は、ステップ３５で抽出した開発者の参照設計情報は“更新物参照不整合”であるとする処理である。また、ステップ３９は、ステップ３５で抽出した開発者の参照設計情報は“整合”であるとする処理である。これらステップ３８，３９の処理が終了すると、ステップ４０に進む。

例えば、データ項目開発者“yamada”が、図４に示す変更前の公開設計情報一覧を取得し、この一覧中のデータ項目“CustomerNo”を、同図に示す変更後の公開設計情報一覧に示すように、“CustomerID”へ更新して、公開設計情報として公開したとする。格納参照整合確認部１１８ａは、このデータ項目“CustomerID”のデータ項目識別子“D-001”を取得し、ステップ３６で、図７に示す参照設計情報２１０が示すこのデータ項目識別子“D-001”の取得時更新回数“2”と、図４に示す変更後の公開設計情報一覧中のデータ項目識別子“D-001”の更新回数“3”とを比較する。この例では、更新回数が異なるので、ステップ３７で、開発設計本体情報“CustomerID”と参照設計本体情報“CustomerNo”とを比較する。ここでは、設計本体情報が不一致であるため、ステップ３８で、この参照設計情報は“更新物参照不整合”であるとする。

ステップ４０は、未抽出の参照設計情報が存在するか否かを判断する処理である。未抽出の参照設計情報が存在すれば、ステップ３５に戻って、さらに、参照設計情報を抽出する。また、未抽出の参照設計情報がなければ、本処理は終了する。

前述したように、ステップ３１で、開発設計情報の公開種別が削除であると判断した場合には、ステップ４１（図２０）に進む。

ステップ４１は、参照設計情報一覧から、当該開発設計情報と一致する参照設計情報を抽出する処理である。格納参照整合確認部１１８aは、開発者設計情報格納部２０２から参照設計情報一覧を取得し、削除結果が公開された当該開発設計情報の識別子と一致する識別子の参照設計情報を抽出する。

ステップ４２は、当該参照設計情報は、“削除物参照不整合”であるとする処理である。削除された公開設計情報を、開発者が参照し続けていた場合、削除された情報を誤って開発設計情報に埋め込んでしまい、設計の品質を下げる要因となる可能性がある。よって、当該参照設計情報を“削除物参照不整合”であるとする。

ステップ４３は、未抽出の参照設計情報が存在するか否かを判断する処理である。未抽出の参照設計情報が存在すれば、ステップ４１に戻って、さらに、参照設計情報を抽出する。また、未抽出の参照設計情報がなければ、本処理は終了する。

例えば、データ項目開発者“yamada”が、図４に示す変更前の公開設計情報一覧を取得し、この一覧中の“CustomerAge”を、同図に示す変更後の公開設計情報一覧に示すように、削除して、公開したとする。なお、ここでの削除は、開発者が削除した公開設計情報を取得できなくことを意味し、公開設計情報一覧の中から当該公開設計情報自体が削除されることを意味しない。格納参照整合確認部１１８ａは、このデータ項目“CustomerAge”のデータ項目識別子“D-006”を取得し、このデータ項目識別子“D-006”の参照設計情報（図７）を抽出して、この参照設計情報を“削除物参照不整合”とする。

以上、ステップ３１〜４３の処理で、図１７のフローチャート中の他の開発者の格納参照設計情報との整合確認処理（ステップ１９）が終了し、ステップ２０に進む。なお、以上では、データ項目開発者“yamada”が開発設計情報としてのデータ項目“CustomerNo”等を公開したときの格納参照整合確認（Ｓ１９）の詳細例について説明したが、図２４は、インタフェース開発者“satoh”が、開発設計情報としてのインタフェース“getCustomerInfoListByName”を公開したときの格納参照整合確認（Ｓ１９）の例を示している。

ステップ２０は、格納参照整合確認部１１８ａがステップ１９の整合確認処理での確認結果に基づき、整合状態格納部２０３内の格納参照整合情報２４０を更新する処理である。

図４を用いて前述したように、データ項目開発者“yamada”が、公開設計情報一覧のうち、公開設計情報の一つであるデータ項目“CustomerNo”（データ項目識別子“D-0001”）を“CustomerID”に更新し、公開設計情報の他の一つであるデータ項目“CustomerAge” （データ項目識別子“D-0005”）を削除し、公開設計情報のさらに他の一つであるデータ項目“ItemPrice” （データ項目識別子“D-0184”）を追加し、これらを公開したとする。この場合、この公開設計情報一覧を参照する開発者“satoh”に関する整合状態格納部２０３内の格納参照整合情報２４０は、図９の内容から図１０の内容に更新される。すなわち、参照設計情報としてのデータ項目“CustomerNo” （データ項目識別子“D-0001”）の整合状態２４５は、“更新物参照不整合”となり、参照設計情報としてのデータ項目“CustomerAge” （データ項目識別子“D-0005”）の整合状態２４５は、“削除物参照不整合”となり、参照設計情報としての“ItemPrice” （データ項目識別子“D-0184”）の整合状態２４５は、“追加物未参照不整合”となる。

ステップ２１は、図２４に示すように、情報内参照整合確認部１１８ｂが、他の開発者の公開設計情報との情報内参照整合を確認する処理である。情報内参照整合確認部１１８ｂは、まず、関連情報格納部２８０（図１２）から、新たに公開された開発設計情報の識別子を参照設計情報識別子２８３とする関連情報２８１を抽出する。そして、この関連情報２８１の開発設計情報の項目識別子２８５の項目データを含む公開設計情報を抽出し、この公開設計情報中の項目データ（参照設計情報）と、新たに公開された開発設計情報との情報内参照整合を確認する。

例えば、インタフェース開発者“satoh”が、開発設計情報としてのインタフェース“getCustomerInfoListByName”（識別子“IF-0014”）を公開したとする。この場合、情報内参照整合確認部１１８ｂは、まず、関連情報格納部２８０（図１２）から、新たに公開された開発設計情報の識別子“IF-0014”を参照設計情報識別子２８３とする関連情報２８１を抽出する。そして、図２４に示すように、この関連情報２８１における開発設計情報の項目識別子“VOUT-0024”２８５の項目データ“getCustomerInfoListByName”を含む公開設計情報（識別子“V-0011”）を抽出し、この公開設計情報中の項目データ（参照設計情報）と、新たに公開された開発設計情報との情報内参照整合を確認する。

ステップ２２は、情報内参照整合確認部１１８ｂがステップ２１の整合確認処理での確認結果に基づき、整合状態格納部２０３内の情報内参照整合情報２５０を更新する処理である。

以上、ステップ１５〜ステップ２２の処理で、開発設計情報の公開要求に対する処理は終了し、ステップ１へ戻る。

前述したように、ステップ１５（図１７）で、開発者又は管理者からの要求が開発設計情報の公開要求ではないと判断されると、ステップ２３（図１８）に進む。

ステップ２３は、要求入力部１１１が、開発者もしくは管理者からの要求がレポート要求か否かの判定する処理である。もしレポート要求であれば、ステップ２４へ進む。レポート要求でなければ、ステップ１へ戻る。以下、ステップ２４からステップ２６は、レポート要求に対する処理である。

ステップ２４は、要求入力部１１１が、レポート要求者の種別を判定する処理である。もし、レポート要求者が管理者であれば、ステップ２５へ進み、開発者であれば、ステップ２６へ進む。

ステップ２５は、開発状況レポートを提供する処理である。開発状況生成部１１９ａは、開発状況情報を生成し、これを開発状況格納部１３０に書き込んでから、開発状況通知部１１９ｂを呼び出す。開発状況通知部１１９ｂは、開発状況生成部１１９ａが生成した開発状況情報を開発状況格納部１３０から取得し、これを要求元の管理者へ通知する。なお、ここでは、開発状況生成部１１９ａは、開発状況の要求があったときに開発状況情報を生成しているが、開発状況の要求の有無に関わらず、定期的に開発状況情報を生成するようにしてもよい。

開発状況情報としては、格納参照整合情報２４０を開発者別に集計した開発者別の参照整合情報と、格納参照整合情報２４０を開発工程別に集計した開発工程別の参照整合情報と、開発工程別の推定進捗状況情報とがある。これらの整合情報は、いずれのテーブル形式である。開発状況通知部１１９ｂは、以上の三種類の情報のうち、管理者からの要求のあった一種類の情報のみを管理者に通知するようにしてもよいし、三種類の情報全てを管理者に通知するようにしてもよい。

図１３に示すように、開発者別の参照整合情報２９０ａを示すテーブルは、開発者識別子が格納される開発者識別子欄２９１aと、この開発者の参照工程種別が格納される参照工程種別欄２９２ａと、参照工程種別での参照設計情報総数が格納される参照設計情報総数欄２９３ａと、参照設計情報のうちで整合している参照設計情報の数が格納される整合設計情報数欄２９４ａと、参照設計情報のうちで不整合な参照設計情報の数が格納される不整合設計情報数欄２９５aと、不整合な参照設計情報の内訳が格納される不整合内訳欄とがある。不整合内訳欄には、追加物未参照不整合の数が格納される追加物未参照不整合欄２９６ａと、更新物参照不整合の数が格納される更新物参照不整合欄２９７ａと、削除物参照不整合が格納される削除物参照不整合欄２９８ａと、を有している。

開発者別の参照整合情報２９０ａには、以上の他、設計情報毎の不整合の種類等を明示した不整合設計情報明細２９９ａもある。

開発状況生成部１１９ａは、整合状態格納部２０３に格納されている格納参照整合情報２４０（図１０）と、開発者設計情報格納部２０２に格納されている開発者情報２３０（図６）とを参照して、開発者別の参照整合情報２９０ａを生成する。開発状況通知部１１９ｂは、前述したように、開発状況生成部１１９ａが生成した開発者別の参照整合状況情報２９０ａを開発状況格納部１３０から取得し、これを要求元の管理者へ通知する。

管理者は、この開発者別の参照整合状況情報２９０ａにより、参照不整合となっている開発者を把握し、また最新情報取得を促す。もし、不整合となっている参照設計情報を詳細に知りたい場合は、不整合設計情報明細２９９ａを要求して、これを閲覧する。

図１４に示すように、開発工程別の参照整合情報２９０ｂを示すテーブルは、開発工程名が格納される開発工程名欄２９１ｂと、この開発工程中の全設計情報の総数が格納される総数欄２９２ｂと、この開発工程中の各設計情報の名が格納される設計情報名欄２９３ｂと、各設計情報のステータスが格納される設計情報ステータス欄２９４ｂと、各設計情報の開発担当者（最終登録者）の名が格納される担当者欄２９５ｂと、各設計情報の格納参照整合状況が格納される参照整合状況欄２９６ｂと、を有している。

開発状況生成部１１９ａは、前述の開発者別の参照整合情報２９０ａの生成に用いる、整合状態格納部２０３に格納されている格納参照整合情報２４０（図１０）と、開発者設計情報格納部２０２に格納されている開発者情報２３０（図６）との他、設計情報ステータス格納部２７０に格納されているステータスを参照して、開発工程別の参照整合情報２９０ｂを生成する。

設計情報ステータス格納部２７０に格納されているステータスは、図２３を用いて説明したように、チェックインとチェックアウトとのいずれかであるが、設計情報ステータス欄２９４ｂには、チェックイン又はチェックアウトの代わりに、チェックインを意味する“公開済み”又はチュックアウトを意味する“作業中”が格納される。

開発状況通知部１１９ｂは、前述したように、開発状況生成部１１９ａが生成した開発工程別の参照整合状況情報２９０ｂを開発状況格納部１３０から取得し、これを要求元の管理者へ通知する。

管理者は、この開発工程別の参照整合状況情報２９０ｂにより、各設計情報が作業中又は公開済であるか、担当の開発者は誰なのか、現在作業中であれば開発者の参照設計情報が整合しているか否かについて、知ることができる。

図１５に示すように、開発工程別の推定進捗状況２９０ｃを示すテーブルは、開発工程名が格納される開発工程名欄２９１ｃと、この開発工程中の全設計情報の総数が格納される総数欄２９２ｃと、この開発工程中の各設計情報の名が格納される設計情報名欄２９３ｃと、各設計情報のステータスが格納される設計情報ステータス欄２９４ｃと、各設計情報の開発担当者（最終登録者）の名が格納される担当者欄２９５ｃと、各設計情報の推定進捗状況が格納される推定進捗状況欄２９６ｃと、を有している。すなわち、この開発工程別の推定進捗状況２９０ｃを示すテーブルは、図１４を用いて前述した開発工程別の参照整合情報２９０ｂを示すテーブル中の参照整合状況欄２９６ｂを、推定進捗状況欄２９６ｃに替えたものである。

このため、開発状況生成部１１９ａは、この開発工程別の推定進捗状況２９０ｃを生成するにあたり、前述の開発工程別の参照整合情報２９０ｂの生成に用いる、格納参照整合情報２４０（図１０）と開発者情報２３０（図６）と設計情報ステータス格納部２７０に格納されているステータスと参照すると共に、推定進捗状況を求めるために、情報内参照整合情報２５０（図１１）も参照する。

この推定進捗状況欄２９６ｃには、“変更対応中”“変更対応済み”“変更要対応”“変更未着手”等が格納される。管理者には、このように、各設計情報の推定進捗状況が通知されるため、管理者は、より正確な開発の進捗状況を把握することができる。

ここで、各設計情報の推定進捗状況の求め方について説明する。

開発状況生成部１１９ａは、まず、各設計情報毎の格納参照整合情報２４０（図１０）と情報内参照整合情報２５０（図１１）とを取得する。次に、図２２に示す対応状況設定ルールを参照して、設計情報に利用される参照設計情報に関する格納参照整合状態及び情報内参照整合状態に対応する対応状況を定める。この対応状況設定ルールでは、格納参照整合状態及び情報内参照整合状態がいずれも“整合”であれば、参照設計情報の変更に関して“対応済み”とする。格納参照整合状態が“参照”で情報内参照整合情報が“不整合”であれば、開発者設計情報格納部２０２に格納されている参照設計情報２１０は、新しい参照設計情報に更新されているものの、開発者設計情報格納部２０２の開発者設計情報２２０には、新しい参照設計情報が用いられていないので、参照設計情報の変更に関して“旧版参照”とする。また、格納参照整合状態が“不整合”の場合には、基本的に、参照設計情報の変更に関して“変更未対応”とする。但し、情報内参照整合状態も“不整合”の場合には、“要注意”とする。

開発状況生成部１１９ａは、各設計情報に関して、設計情報内の項目データ（参照設計情報）毎の対応状況を求めると、図２１に示すフローに従って、各設計情報の推定進捗状況を求める。

具体的に、開発状況生成部１１９ａは、当該設計情報に関するステータスを確認し（Ｓ５１）、当該設計情報のステータスが“チェックイン”の場合にはステップ５２に進み、当該設計情報のステータスが“チェックアウト”の場合にはステップ５５に進む。ステップ５５では、当該設計情報中のデータ項目に不整合のデータ項目があるか否かを判断し、不整合のデータ項目があれば、ステップ５３で、この設計情報に関して変更の必要性がある旨を示す“要変更”とする。また、不整合のデータ項目がなければ、ステップ５４で、この設計情報に関して変更の必要性がない旨を示す“変更不要”とする。

ステップ５１で、当該設計情報のステータスが“チェックアウト”と判断して、ステップ５５に進むと、当該設計情報の全データ項目は、“対応済み”であるか否かを判断する。当該設計情報の全データ項目が“対応済み”であるあれば、ステップ５６で、この設計情報に関しての変更は済んでいる旨を示す“変更対応済み”とする。また、当該設計情報の全データ項目が“対応済み”でなければ、ステップ５７に進む。

ステップ５７では、当該設計情報の全項目データは“変更未対応”のみであるか否かを判断する。当該設計情報の全項目データが“変更未対応”のみであれば、ステップ５８で、この設計情報に関する変更が未着手である旨を示す“変更未着手”とする。また、当該設計情報の全項目データが“変更未対応”のみでなければ、ステップ５９に進む。

ステップ５９では、当該設計情報の全項目データに関して、“対応済み”の項目データと“変更未対応”の項目データとを含むか否かを判断する。“対応済み”の項目データと“変更未対応”の項目データとを含むのであれば、ステップ６０で、“変更対応中”とする。また、“対応済み”の項目データと“変更未対応”の項目データとを含まなければ、ステップ６１に進む。

ステップ６１では、当該設計情報の全項目データのうち“要注意”の項目データがあるか否かを判断する。“要注意”の項目データがあれば、ステップ６２で、開発者による変更が全く行われていないので、この開発者に関しては注意が必要である旨を示す“開発者要注意”とする。また、“要注意”の項目データがなければ、当該設計情報に関して“旧版参照”であるとして、ステップ６３で、“参照情報要更新”とする。

開発状況生成部１１９ａは、以上のステップ５３，５４，５６，５８，６０，６２，６３での状況判断結果を、開発工程別の推定進捗状況２９０ｃの推定進捗状況欄２９６ｃに格納する。

以上で、各設計情報の推定進捗状況の推定処理が終了する。

なお、ここでは、推定進捗状況として、開発工程毎の推定進捗状況を求めているが、開発者毎の推定進捗状況を求め、これを管理者に提供するようにしてもよい。

前述したように、ステップ２４（図１８）で、レポート要求者が開発者であると判断されるとステップ２６に進む。

ステップ２６は、レポート要求した開発者が担当する工程に含まれる全設計情報に関して、整合状況レポートを提供する処理である。整合状況レポートは、開発状況生成部１１９ａにより生成され、開発状況通知部１１７により要求元の開発者に通知される。

この整合状況レポートは、格納参照整合情報２４０及び情報内参照整合情報２５０を参照して、レポート要求した開発者が担当する工程に含まれる全設計情報に関して、格納参照整合状態及び情報内参照整合状態を示すものである。

この整合状況レポートの表示の方法としては、例えば、（１）不整合が生じていることをダイアログで画面に表示する、（２）不整合が生じている設計情報の一覧を画面に表示する、（３）設計画面において不整合が生じている設計情報の色を変えて表示する、（４）設計画面において不整合が生じている設計情報にハイパーリンクやボタンなどを付加し、その情報をクリック等すると不整合の詳細な内容や、変更の候補を表示する等が考えられる。

以上、ステップ２３〜ステップ２６の処理で、レポート要求に対する処理は終了し、ステップ１へ戻る。

以上、本実施形態では、ソフトウェア開発者が最新成果物を参照せずに設計している際、ソフトウェア開発者が公開設計情報格納部２６０に対して設計情報を公開する以前の、設計を行っている段階で、既に公開済みの成果物間での不整合による問題が生じる可能性を明らかにし、開発者等にこれを通知することができる。また、本実施形態では、開発者の設計情報中のデータ項目単位で、参照不整合を検知でき、開発者の更新忘れや改造による不適当な設計情報の公開を拒絶することができる。以上の結果、本発明によれば、設計情報の再設計等による無駄を削減し開発の効率化を図ることできる。

また、本実施形態によれば、新規に公開や修正された設計情報を、どの程度の数の開発者が取得し、どの程度の数の開発者が対応したかの進捗情報を、管理者に通知することもできる。このため、管理者によるソフトウェア開発の工程管理が容易になる。

本発明に係る一実施形態におけるソフトウェア開発支援装置の構成図である。 本発明に係る一実施形態におけるソフトウェア開発支援装置の設計情報取得要求に対する処理に関する機能ブロック図である。 本発明に係る一実施形態におけるソフトウェア開発支援装置の設計情報格納要求に対する処理に関する機能ブロック図である。 本発明に係る一実施形態におけるデータ項目定義の公開設計情報のデータ構成を示す説明図である。 本発明に係る一実施形態におけるインタフェース定義の公開設計情報のデータ構成を示す説明図である。 本発明に係る一実施形態における開発者設計情報のデータ構成を示す説明図である。 本発明に係る一実施形態における参照設計情報のデータ構成を示す説明図である。 本発明に係る一実施形態における開発設計情報のデータ構成を示す説明図である。 本発明に係る一実施形態における格納参照整合情報（更新前）のデータ構成を示す説明図である。 本発明に係る一実施形態における格納参照整合情報（更新後）のデータ構成を示す説明図である。 本発明に係る一実施形態における情報内参照整合情報のデータ構成を示す説明図である。 本発明に係る一実施形態における関連情報のデータ構成を示す説明図である。 本発明に係る一実施形態における開発者別の参照整合情報のデータ構成を示す説明図である。 本発明に係る一実施形態における開発工程別の参照整合情報のデータ構成を示す説明図である。 本発明に係る一実施形態における開発工程別の推定開発進捗状況のデータ構成を示す説明図である。 本発明に係る一実施形態におけるソフトウェア開発支援装置の動作を示すフローチャート（その１）である。 本発明に係る一実施形態におけるソフトウェア開発支援装置の動作を示すフローチャート（その２）である。 本発明に係る一実施形態におけるソフトウェア開発支援装置の動作を示すフローチャート（その３）である。 図１７に示すフローチャート中のステップ１９の詳細処理を示すフローチャート（その１）である。 図１７に示すフローチャート中のステップ１９の詳細処理を示すフローチャート（その２）である。 図１８に示すフローチャート中のステップ２５で、推定開発状況を求めるための詳細処理を示すフローチャートである。 本発明に係る一実施形態における推定開発進捗状況を求める際に用いるルールを示す説明図である。 本発明に係る一実施形態におけるチェックイン状態及びチェックアウト状態を概念的に示す説明図である。 本発明に係る一実施形態におけるソフトウェア支援装置の主要な処理内容を概念的に示す説明図である。

符号の説明

１００…ソフトウェア開発支援装置、１０１…入力装置、１０２…出力装置、１０３…通信装置、１０４…インタフェース、１０５…メモリ、１０６…バス、１１０…ＣＰＵ、１１１…要求入力部、１１２…設計情報入力部、１１３…設計情報出力部、１１４…設計情報関連取得部、１１５…参照設計情報記録部、１１６…設計情報公開部、１１７…ステータス管理部、１１８ａ…格納参照整合確認部、１１８ｂ…情報内参照整合確認部、１１９ａ…開発状況生成部、１１９ｂ…開発状況通知部、２００…記憶装置、２０１…ソフトウェア開発支援プログラム、２０２…開発者設計情報格納部、２０３…整合状態格納部、２１０…参照設計情報、２２０…開発設計情報、２３０…開発者情報、２４０…格納参照整合情報、２５０…情報内参照整合情報、２６０…公開設計情報格納部、２７０…設計情報ステータス格納部、２８０…関連情報格納部、２９０…開発状況格納部

Claims (9)

1. 設計単位毎の設計情報を複数集めて形成されるソフトウェアの開発支援装置において、
   複数の公開設計情報が格納される公開設計情報格納領域と、
   開発者が開発した設計情報を、前記公開設計情報として前記公開設計情報格納領域に格納する設計情報公開部と、
   開発者が設計情報の設計に利用する前記公開設計情報を前記公開設計情報格納領域から取得し、該公開設計情報を参照設計情報として該開発者に提供する設計情報出力部と、
   複数の参照設計情報が格納される参照設計情報格納領域と、
   前記複数の公開設計情報のうち、開発者が設計情報の設計に利用する公開設計情報を前記参照設計情報として、前記参照設計情報格納領域に格納する参照設計情報格納部と、
   前記設計情報公開部により前記公開設計情報が前記公開設計情報格納領域に格納されると、該公開設計情報と、前記参照設計情報格納領域に格納されている前記複数の参照設計情報のうち該公開設計情報を参照元とする参照設計情報との整合状態を確認する参照整合確認部と、
   前記参照整合確認部で確認された整合状態を第一の整合状態として、該参照整合確認部により格納される整合状態格納領域と、
   前記整合状態格納領域に格納されている前記整合状態を外部に通知する開発状況通知部と、
   開発設計情報が格納される開発設計情報格納領域と、
   開発者が開発中の設計情報を受け付けて、前記開発設計情報として前記開発設計情報格納領域に格納する設計情報入力部と、を備え、
   前記参照整合確認部は、前記設計情報入力部により前記開発設計情報が前記開発設計情報格納領域に格納されると、該開発設計情報中の参照設計情報と、前記参照設計情報格納領域に格納されている前記複数の参照設計情報のうち該開発設計情報の参照設計情報との整合状態を確認し、該整合状態を第二の整合状態として前記整合状態格納領域に格納する、
   ことを特徴とするソフトウェア開発支援装置。
2. 請求項１に記載のソフトウェア開発支援装置において、
   前記設計情報入力部により前記開発設計情報が前記開発設計情報格納領域に格納されると、該開発設計情報を構成する中の複数の項目データと、前記参照設計情報格納領域に格納されている参照設計情報のうちの該開発設計情報の参照設計情報とを比較し、該開発設計情報中の複数の項目データのうちのいずれの項目データに該参照設計情報が用いられているかを把握し、該参照設計情報が用いられている該項目データと該参照設計情報との関連を取得する設計情報関連取得部と、
   前記設計情報関連取得部により取得された前記関連の情報が格納される関連情報格納領域と、
   を備え、
   前記参照整合確認部は、前記設計情報入力部により前記開発設計情報が前記開発設計情報格納領域に格納されると、前記関連情報格納領域に格納されている前記関連の情報を参照して、該開発設計情報中で参照設計情報が用いられている項目データと、前記参照設計情報格納領域に格納されている前記複数の参照設計情報のうち該開発設計情報の参照設計情報との整合状態を確認する、
   ことを特徴とするソフトウェア開発支援装置。
3. 請求項１又は２に記載のソフトウェア開発支援装置において、
   前記参照整合確認部は、前記開発設計情報格納領域に格納されている前記開発設計情報の公開要求を受け付けると、前記整合状態格納領域を参照して、該開発設計情報に利用された前記参照設計情報の前記第一の整合状態、及び該開発設計情報の前記第二の整合状態を確認し、いずれの整合状態も整合を示しているか否かを判断し、
   前記設計情報公開部は、公開要求のあった前記開発設計情報に関して、前記参照整合確認部により前記第一の整合状態及び前記第二の整合状態のいずれの整合状態も整合であると判断されると、前記開発設計格納領域内の該開発設計情報を前記公開設計情報格納領域に、前記公開設計情報として格納する、
   ことを特徴とするソフトウェア開発支援装置。
4. 請求項１から３のいずれか一項に記載のソフトウェア開発支援装置において、
   前記参照整合確認部は、前記設計情報公開部により前記開発設計情報が新たな公開設計情報として前記公開設計情報格納領域に格納されると、該新たな公開設計情報と、該公開設計情報格納領域に既に格納されている公開設計情報のうち、該新たな公開設計情報を参照設計情報としている公開設計情報中の参照設計情報との整合状態を確認し、該整合状態を第三の整合状態として前記整合状態格納領域に格納する、
   ことを特徴とするソフトウェア開発支援装置。
5. 請求項１から４のいずれか一項に記載のソフトウェア開発支援装置において、
   前記整合状態格納領域に格納されている設計情報に関する前記第一の整合状態及び前記第二の整合状態と、予め定められているルールとを用いて、前記第一の整合状態が示す整合又は不整合と、前記第二の整合状態が示す整合又は不整合との組合せに応じて、該設計情報の参照元の公開設計情報の変更に伴う対応状況を定め、該対応状況を用いて該設計情報の開発状況情報を生成する開発状況生成部を備え、
   前記開発状況通知部は、前記開発状況情報を外部へ通知する、
   ことを特徴とするソフトウェア開発支援装置。
6. 請求項１から４のいずれか一項に記載のソフトウェア開発支援装置において、
   予め定められた工程を担当する開発者毎の開発者別参照整合情報、及び/又は工程毎の工程別参照整合情報を生成する開発状況生成部を備え、
   前記開発状況生成部は、
   前記開発者別参照整合情報を生成する場合には、前記整合状態格納領域を参照して、開発者毎に、該開発者が担当する工程中の１以上の設計情報の前記第一の整合状態が示す整合又は不整合の数を集計し、該工程中の整合の数及び不整合の数を求めて、該工程中の整合の数及び不整合の数を該工程を担当する開発者の該開発者別参照整合情報とし、
   前記工程別参照整合情報を生成する場合には、前記整合状態格納領域から、工程毎に、該工程中の１以上の設計情報の前記第一の整合状態を取得し、該工程中の１以上の設計情報毎に、該設計情報と該第一の整合状態とを関連付けた情報を該工程別参照設計情報とし、
   前記開発状況通知部は、前記開発者別参照整合情報及び/又は工程別参照整合情報を外部へ通知する、
   ことを特徴とするソフトウェア開発支援装置。
7. 設計単位毎の設計情報を複数集めて形成されるソフトウェアの開発支援プログラムにおいて、
   開発者が開発した複数の設計情報を、それぞれ公開設計情報として、コンピュータの第一の記憶領域に格納する設計情報公開ステップと、
   開発者が設計情報の設計に利用する前記公開設計情報を前記第一の記憶領域から取得し、該公開設計情報を参照設計情報として該開発者に提供する設計情報出力ステップと、
   複数の前記公開設計情報のうち、開発者が設計情報の設計に利用する公開設計情報を参照設計情報として、前記コンピュータの第二の記憶領域に格納する参照設計情報格納ステップと、
   前記設計情報公開ステップで前記公開設計情報が前記第一の記憶領域に格納されると、該公開設計情報と、前記第二の格納領域に格納されている前記参照設計情報のうち該公開設計情報を参照元とする参照設計情報との整合状態を確認し、該整合状態を第一の整合状態として、前記コンピュータの第三の記憶領域に格納する参照整合確認ステップと、
   前記第三の記憶領域に格納されている前記整合状態の情報を含む開発状況情報を外部に通知する開発状況通知ステップと、
   開発者が開発中の設計情報を受け付けて、開発設計情報として、前記コンピュータの第四の記憶領域に格納する設計情報入力ステップとを、前記コンピュータに実行させ、
   前記参照整合確認ステップでは、前記設計情報入力ステップで前記開発設計情報が前記第四の記憶領域に格納されると、該開発設計情報中の参照設計情報と、前記第二の記憶領域に格納されている前記複数の参照設計情報のうち該開発設計情報の参照設計情報との整合状態を確認し、該整合状態を第二の整合状態として前記第三の記憶領域に格納する、
   ことを特徴とするソフトウェア開発支援プログラム。
8. 請求項７に記載のソフトウェア開発支援プログラムにおいて、
   前記参照整合確認ステップでは、前記第四の記憶領域に格納されている前記開発設計情報の公開要求を受け付けると、前記第三の記憶領域を参照して、該開発設計情報に利用された前記参照設計情報の前記第一の整合状態、及び該開発設計情報の前記第二の整合状態を確認し、いずれの整合状態も整合を示しているか否かを判断し、
   前記設計情報公開ステップでは、公開要求のあった前記開発設計情報に関して、前記参照整合確認ステップで、前記第一の整合状態及び前記第二の整合状態のいずれの整合状態も整合であると判断されると、前記第四の記憶領域内の該開発設計情報を前記第一の記憶領域に、前記公開設計情報として格納する、
   ことを特徴とするソフトウェア開発支援プログラム。
9. 設計単位毎の設計情報を複数集めて形成されるソフトウェアの開発支援方法において、
   開発者が開発した複数の設計情報を、それぞれ公開設計情報として、コンピュータの第一の記憶領域に格納する設計情報公開ステップと、
   開発者が設計情報の設計に利用する前記公開設計情報を前記第一の記憶領域から取得し、該公開設計情報を参照設計情報として該開発者に提供する設計情報出力ステップと、
   複数の前記公開設計情報のうち、開発者が設計情報の設計に利用する公開設計情報を参照設計情報として、前記コンピュータの第二の記憶領域に格納する参照設計情報格納ステップと、
   前記設計情報公開ステップで前記公開設計情報が前記第一の記憶領域に格納されると、該公開設計情報と、前記第二の格納領域に格納されている前記参照設計情報のうち該公開設計情報を参照元とする参照設計情報との整合状態を確認し、該整合状態を第一の整合状態として、前記コンピュータの第三の記憶領域に格納する参照整合確認ステップと、
   前記第三の記憶領域に格納されている前記整合状態の情報を含む開発状況情報を外部に通知する開発状況通知ステップと、
   開発者が開発中の設計情報を受け付けて、開発設計情報として、前記コンピュータの第四の記憶領域に格納する設計情報入力ステップとを、前記コンピュータが実行し、
   前記参照整合確認ステップでは、前記設計情報入力ステップで前記開発設計情報が前記第四の記憶領域に格納されると、該開発設計情報中の参照設計情報と、前記第二の記憶領域に格納されている前記複数の参照設計情報のうち該開発設計情報の参照設計情報との整合状態を確認し、該整合状態を第二の整合状態として前記第三の記憶領域に格納する、
   ことを特徴とするソフトウェア開発支援方法。

Images