(57)【要約】【課題】製品全体に対する要件とソフトウェア・モジュール等のコンポーネントに対する変更とを確実に対応づけて管理することができるとともに、担当者のコンポーネントに対する作業状況から製品全体の進捗状況を容易に把握すること。【解決手段】本発明に係るプロジェクト管理システムは、コンポーネントの階層的な構造を管理する過程と、その上位のコンポーネントに対して達成すべき要件を割り当てる過程と、その子孫のコンポーネントに対してその達成すべき要件を該上位のコンポーネントに割り当てられた達成すべき要件のうちから割り当てる過程と、該子孫コンポーネントに対して割り当てられた達成すべき要件の達成状況をコンポーネントのリビジョンの更新に伴って更新させる過程と、これらを基に上位のコンポーネントに対する達成すべき要件の達成状況を算出する過程とを有することを特徴とする。【選択図】図１
2006221316.tif 000002
【特許請求の範囲】
【請求項１】
コンポーネントの階層的な構造を管理する過程と、その上位のコンポーネントに対して達成すべき要件を割り当てる過程と、その子孫のコンポーネントに対してその達成すべき要件を該上位のコンポーネントに割り当てられた達成すべき要件のうちから割り当てる過程と、該子孫コンポーネントに対して割り当てられた達成すべき要件の達成状況をコンポーネントのリビジョンの更新に伴って更新させる過程と、これらを基に上位のコンポーネントに対する達成すべき要件の達成状況を算出する過程とを有することを特徴とするプロジェクト管理システム。
【請求項２】
前記コンポーネントに割り当てられた要件の達成状況に不具合が発見された場合、その不具合を新たな要件として他の要件と同様に管理することを特徴とする請求項１記載のプロジェクト管理システム。
【請求項３】
前記コンポーネントに割り当てられた要件の削除や変更が生じた場合、その要件の削除或は要件の変更自体を新たな要件として他の要件と同様に管理することを特徴とする請求項１記載のプロジェクト管理システム。
【請求項４】
コンポーネント・リビジョンの作成時にその基になった複数のコンポーネント・リビジョンを管理し、前記複数の基となったコンポーネント・リビジョンにおける要件の達成状況から作成されたコンポーネント・リビジョンの要件達成状況を推定する過程とを有することを特徴とする請求項１記載のプロジェクト管理システム。
【請求項５】
コンポーネント・リビジョンの実体を管理するファイル管理ツールを有し、これを利用してコンポーネント・リビジョンに対するファイルリビジョンを生成、チェックイン、チェックアウトすることを特徴とする請求項１記載のプロジェクト管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウエア開発等の開発管理を支援するプロジェクト管理システムに関し、特に開発で達成すべき要件や解決すべき不具合の予定と実績を管理するシステムに関する。
【背景技術】
【０００２】
プロジェクト管理では、達成すべき要件や様々なトラブル等の一覧と、それらの達成・解決の予定・実績を管理することが重要であり、このような観点からこれまで多くのプロジェクト管理システムが考案されてきた。
【０００３】
又、近年では顧客要求に柔軟に対応するため、単に１つの製品開発だけを行うプロジェクトだけでなく、それを基にした多くの派生製品を開発することが要求されており、又、それぞれに対してテストや出荷後或は開発途中での不具合修正や要望追加・変更のため、非常に多くのバージョンを開発・出荷することが必要になってきている。
【０００４】
このため、複数製品間でのモジュールの共用を目指した共通部品の開発や、過去の製品の既存モジュールの修正によって新規のバージョンや派生製品を開発する流用開発等が積極的に行われるようになってきている。
【０００５】
このような共用開発・流用開発では、多数の製品、多数のバージョンを多数の共用モジュール、流用モジュールの組合せによって開発するため、これら多数の製品やバージョンにおいて達成すべき要件や解消すべき不具合の予定とその実績、即ち製品全体として予定された要件は達成されたか・不具合は解消されたかと、各モジュールに行われた修正とを正確に管理し、開発者及び関係者に周知徹底することが極めて重要である。
【０００６】
このため、例えばハードウエアの例ではあるが、特許文献１においては、製品を構成する部品に対する技術的な改良に基づく恒久的な変更と、顧客要求に基づく変更を管理し、それらに基づいて様々な製品構成を管理し、行われた変更を追跡可能にしたシステムが提案されている。
【０００７】
【特許文献１】特開平５−１８９４４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、前記特許文献１では変更結果の管理だけであり、結果に至るまでの業務に関しては何も支援を行えない。
【０００９】
特に、どういう製品のどのバージョンにおいてどいう変更を行うかどうかといった予定が管理されておらず、又、予定の作成も支援されていない。
【００１０】
又、このような共用・流用開発では、多数の他の製品や以前のバージョンに対しても修正を行う必要が多く、このような場合にも支援が必要とされている。
【００１１】
又、以前に実現した要件は新規の製品やバージョンでは削除や変更される場合があるが、このような場合には確実に削除・変更されるよう管理されなければならない。
【００１２】
又、このような多くの変更は変更を受ける実体である製品のコンポーネント、例えばソフトウエアの場合には各モジュールのソースコード等の変更と確実に対応づけて管理することが望まれる。
【００１３】
本発明はこのような課題に鑑み、以下を目的とする。
【００１４】
・多数の製品、多数のバージョンにおける達成すべき要件や解消すべき不具合の予定とその実績の管理を支援する。
【００１５】
・  品を構成する多数のコンポーネントの修正の予定・実績を管理し、又、製品全体の達成すべき要件の予定・実績との対応付けを支援する。又、ソースコード等の修正作業との対応付けを支援する。
【００１６】
・不具合が生じた場合に、他の製品や以前のバージョンでの対処の必要性と対処方法の判断を支援する。
【００１７】
・以前に達成済みの要件の変更や削除が要求された場合、これらに対する処置が正確に行われるよう支援する。
【課題を解決するための手段】
【００１８】
本発明に係るプロジェクト管理システムは、コンポーネントの階層的な構造を管理する過程と、その上位のコンポーネントに対して達成すべき要件を割り当てる過程と、その子孫のコンポーネントに対してその達成すべき要件を該上位のコンポーネントに割り当てられた達成すべき要件のうちから割り当てる過程と、該子孫コンポーネントに対して割り当てられた達成すべき要件の達成状況をコンポーネントのリビジョンの更新に伴って更新させる過程と、これらを基に上位のコンポーネントに対する達成すべき要件の達成状況を算出する過程とを有することを特徴とする。
【発明の効果】
【００１９】
本発明によれば、製品全体に対する要件とソフトウェア・モジュール等のコンポーネントに対する変更とを確実に対応づけて管理することができるとともに、担当者のコンポーネントに対する作業状況から製品全体の進捗状況を容易に把握することができるという効果が得られる。
【発明を実施するための最良の形態】
【００２０】
以下に本発明の実施の形態を添付図面に基づいて説明する。
【００２１】
＜実施の形態１＞
図１に本発明の基本構成を示す。
【００２２】
図１において、Ａ−ａ，Ａ−２はクライアントとなるコンピュータ、Ａ−３はサーバーとなるコンピュータであり、互いにネットワークで接続されている。サーバーコンピュータＡ−３は、データを管理するためのデータベースＡ−４を持ち、サーバープログラムが動作する。
【００２３】
本発明におけるサーバープログラムは、例えばＷｅｂアプリケーションとして構築される。即ち、クライアントは、汎用的なＷｅｂブラウザであり、サーバー上で稼動するプログラムとＨＴＴＰプロトコルでやり取りを行う。
【００２４】
又、他の構成としては、サーバーマシンではデータベースを管理する汎用的なデータベース管理システム（ＤＢＭＳ）のみが稼動し、各クライアント上で稼動する本発明におけるクライアントプログラムが直接データベースＡ−４をアクセスする形態でも良い。
【００２５】
図２はデータベースＡ−４に収容されるデータの概念的なデータ構造を示す。尚、図中の矢印は１→多の向きにデータ間が１対多の関係にあることを示す．
Ｂ−１は対象とする製品群に関する要件、Ｂ−２は対象とする製品、Ｂ−３は製品のあるバージョン、Ｂ−５は対象とする製品群に関するコンポーネント、Ｂ−６はコンポーネントのリビジョンを表すデータである。
【００２６】
又、Ｂ−８は或る製品バージョンにおけるコンポーネント・リビジョンの構成を示すコンポーネント構成データである。
【００２７】
以下では製品とそのバージョン、コンポーネントとそのリビジョンが図３及び図４のような関係にあるとして説明する。
【００２８】
図３は製品バージョンの系統の例であり、先ず、製品Ｐ１とＰ２の２つがあり、製品Ｐ１には３つのバージョンｖ１．０，ｖ１．１，ｖ１．２がある。図中の矢印の向きはバージョンの作成順序を示しており、バージョンｖ１．１はｖ１．０を基にして作成され、ｖ１．２はｖ１．１を基に作成されることを示す。
【００２９】
又、製品Ｐ２のｖ１．０は製品Ｐ１のバージョンｖ１．０を基に作成され、ｖ１．１は製品Ｐ２の前バージョンｖ１．０と製品Ｐ１のバージョンｖ１．１の２つを基に、即ち２つの製品バージョンがマージされて作成されることを示している。
【００３０】
尚、矢印の上の＋ＲＸ．Ｘの意味については後述する。
【００３１】
同様に図４は製品を構成するコンポーネントの系統の例であり、先ず、コンポーネントＣ１とＣ２があり、コンポーネントＣ１はｒ１．０，ｒ１．１，ｒ１．２，ｒ１．３の４つのリビジョンを持つ。ここで、矢印の意味は図３と同様であり、例えばｒ１．２はｒ１．１を基に作成されることを示す。コンポーネントＣ２は、この順に作成されたリビジョンｒ１．０，ｒ１．１，ｒ１．２，ｒ１．３とｒ１．０から派生したリビジョンｒ２．１，ｒ２．２，ｒ２．３の２つのリビジョン系列を持ち、特にｒ２．２はｒ１．２からも矢印が入っていて２つのリビジョンｒ２．１とｒ１．２がマージされたことを示している。
【００３２】
図３と同様に矢印の上の＋ＲＸ．Ｘの意味については後述する。
【００３３】
ところで、図２において、要件Ｂ−１は例えば外部的或は内部的な機能や性能の１つ１つであり、開発で実現すべきものである。ここでは、対象とする製品群の全ての要件が管理され、新たな要件が発生するごとに追加される。
【００３４】
図５は要件Ｂ−１の一覧の例を示す。各要件は識別するための要件ＩＤと標題を属性として持つ。その他その詳細や補足のための属性等を持っても良い。
【００３５】
又、要件は非常に多数になるため、その分類のための属性を持って検索等に利用しても良い。
【００３６】
ここでは、階層的に要件を分類・整理するとして、図５ではインデントと要件ＩＤの記号Ｒ１，Ｒ１．１，Ｒ１．１．１…の付け方で階層構造を示している。又、図２で要件Ｂ−１から出てＢ−２に入る矢印はこの階層構造を示す。尚、要件の階層的な分類は必須のものではない。
【００３７】
図２において、製品データＢ−２は製品名と製品の内容等を管理し、新たな製品ごとに追加する。
【００３８】
製品は改良や不具合修正を行ったものが何度か出荷されるが、各々が製品バージョンＢ−３である。
【００３９】
製品バージョンデータＢ−３の例を図６に示す。
【００４０】
製品バージョンデータは製品名とバージョン名をキーとし、その製品バージョンのステータスと、その製品バージョンの基となった親バージョン情報を属性として持つ。
【００４１】
製品バージョンのステータスは、例えば「予定」「開発中」「出荷済み」から１つの値を取る。
【００４２】
尚、これ以外にテスト時等における構成を確定するために出荷済み以外の中間バージョンを設けても良く、この場合には例えばステータスに「テスト」という値を加えても良い。
【００４３】
親バージョン情報は、その製品バージョンの基となった製品バージョンのリスト、即ちそのキー値（製品名、バージョン名）のリストであり、図２におけるＢ−４の矢印で示される関係である。
【００４４】
図６の内容は図３の製品バージョン系統の例に基づいており、例えば製品Ｐ１のバージョンｖ１．１を基にして製品Ｐ１のバージョンｖ１．２の開発が予定されており、製品Ｐ１のバージョンｖ１．０を基にした製品Ｐ２のバージョンｖ１．１が開発中であることを示す。
【００４５】
尚、親バージョン情報が１組の（製品名、バージョン名）でなく、リストである意味は実施の形態３で説明する。
【００４６】
図２において、コンポーネントＢ−５は、対象とする製品群に関する全てのコンポーネントのそれぞれであり、コンポーネント名とその説明等を属性として持ち、新たなコンポーネントの追加ごとにデータが追加される。
【００４７】
ここで、コンポーネントとは、ソフトウエア開発の場合には製品で使用するモジュールであるが、その他機能仕様書やテスト仕様書等の開発に関連する文書等を含んでも良い。
【００４８】
コンポーネントＢ−５は、開発の途上で順次機能追加や不具合修正が行われていくため、それらのリビジョンＢ−６が管理される。
【００４９】
図７にコンポーネント・リビジョンデータＢ−６の例を示す。
【００５０】
図７でコンポーネント・リビジョンは製品バージョンと同様に（コンポーネント名、リビジョン名）をキーとし、リビジョンのステータスと親リビジョン情報等を属性として持つ。
【００５１】
リビジョンのステータスは、例えば「予定」「作成中」「作成済」のうちの１つの値を取る。
【００５２】
ここで、「予定」とは、そのリビジョンが未だ実体としては存在せず、作成作業も始まっていない状態である。「作成中」は作成作業中であることを示し、特に前リビジョンの修正によって新リビジョンを作成する場合には前リビジョンをチェックアウトしている状態である。
【００５３】
「作成済」はそのリビジョンが実際に作成され存在していることを示し、いわゆるチェックイン済みの状態である。
【００５４】
親リビジョン情報は、製品バージョンの親バージョン情報と同様に、そのリビジョンの基となったリビジョン名のリストであり、図２の矢印Ｂ−７で示される関係である。
【００５５】
尚、ここでは他のコンポーネントのリビジョンを基にリビジョンを作成することはないとして、（コンポーネント名、リビジョン名）のリストの代わりにリビジョン名だけのリストとしている。
【００５６】
図７の内容は図４のコンポーネント・リビジョンの系統の例に基づいており、例えばコンポーネントＣ１にはｒ１．０→ｒ１．１→ｒ１．２の順に各リビジョンが作成済みであり、ｒ１．２を基にｒ１．３を作成する予定があることを示す。
【００５７】
尚、製品バージョンの場合と同様に、親リビジョン情報が１つのリビジョン名だけでなく、リストである意味は実施の形態３で説明する。
【００５８】
尚、このコンポーネント・リビジョンデータは、その他例えばそのリビジョンの作成担当者や作成日時、修正内容に関するコメント等の属性を持っても良い。
【００５９】
図２において、Ｂ−８は或る製品バージョンにおけるコンポーネント・リビジョンの構成を示すコンポーネント構成データである。
【００６０】
図８はこのコンポーネント構成データの例であり、製品Ｐ１のバージョンｖ１．０はコンポーネントＣ１のリビジョンｒ１．１とＣ２のリビジョンｒ１．０から成り、製品Ｐ２のバージョンｖ１．１は、コンポーネントＣ１のリビジョンｒ１．３とＣ２のリビジョンｒ２．２から成ることを示している。
【００６１】
この製品バージョンのコンポーネント・リビジョン構成は、製品バージョンのステータスを出荷済みにしたときに確定されるが、ステータスが予定あるいは開発中の場合には各コンポーネントの作成・修正作業に伴うコンポーネント・リビジョンの改訂によって変化する。
【００６２】
図２において、Ｂ−９は各製品バージョンで実現されるべき要件を示す製品バージョン要件データであり、図９にこのデータの例を示す。
【００６３】
製品バージョン要件データは（製品名、バージョン名、要件ＩＤ）をキーとし、その製品バージョンにおけるその要件の対応状況を管理する対応ステータス属性を持つ。
【００６４】
尚、Ｂ−１の要件データが階層的に分類されている場合には、この要件ＩＤは最下層の葉ノードに対してのみ設定する。
【００６５】
対応ステータスは、例えば「予定」「未完」「対応済」「無関係」のうちの１つの値を取る。
【００６６】
ここで、「予定」はこの製品バージョンでこの要件を実現すべきであるが、未だ実現されていないこと、「対応済み」は実現されたこと、「未完」は実現するための処置は実施したが不具合等により完全には実現されていないことを示す。
【００６７】
「無関係」はこの製品バージョンと要件に対する製品バージョン要件データが実際には存在しない場合、或はデータが存在してもこの製品バージョンとこの要件は無関係であることを例えば後から予定を削除した等の場合に明示する等の場合に使用する。
【００６８】
図９では例えば製品Ｐ１のバージョンｖ１．０では２つの要件Ｒ１．１とＲ１．２に対応済みであること示す。又、製品Ｐ１のバージョンｖ１．１では更に２つの要件Ｒ１．３とＲ１．４に対応済みであることを示す。
【００６９】
尚、ここではこの製品バージョン要件データは製品バージョンの親バージョンとの差分で作成されるとしている。即ち、製品Ｐ１のバージョン１．１の親バージョンはバージョンｖ１．０であるので、既に要件Ｒ１．１とＲ１．２には対応済みであり、それに加えてＲ１．３とＲ１．３に対応済みであることを示す。
【００７０】
これらの関係は図３では＋ＲＸ．Ｘにより示されており、製品バージョン間を繋ぐ矢印上の要件が、この間の開発で前のバージョンで実現済みのものに追加して実現されたことを示している。
【００７１】
即ち、親バージョンと比較し、親バージョンにない要件を割り当てる場合、或は親バージョンと同じ要件が割り当てられていてもその属性である対応ステータスが異なる場合にのみ、この製品バージョン要件データが作成される。
【００７２】
尚、新たな要件の追加によって以前対応済みであった要件に不具合が発生する等、いわゆる「退化」が起こる場合があり得るが、このような場合の対応については実施の形態２で後述する。
【００７３】
図２において、Ｂ−１０は各コンポーネント・リビジョンで実現されるべき要件を示すコンポーネント・リビジョン要件データであり、図１０にこのデータの例を示す。
【００７４】
各コンポーネント・リビジョン要件データは（コンポーネント名、リビジョン名、要件ＩＤ）をキーとし、その各コンポーネント・リビジョンでのその要件に対する対応状況を管理する対応ステータス属性を持つ。
【００７５】
対応ステータスは、例えば製品バージョン要件の場合と同様に「予定」「未完」「対応済」「無関係」のうちの１つの値を取る。
【００７６】
又、このデータも製品バージョン要件の場合と同様に、親リビジョンに対する差分で管理される。
【００７７】
図１０では例えばコンポーネントＣ１のリビジョンｒ１．０では要件Ｒ１．１とＲ１．２に対応すべきであったがＲ１．１に対しては「未完」即ち未だ不完全であり，Ｒ１．２に対しては「予定」即ち未だ何も行われておらず、リビジョンｒ１．１でこの２つの要件に対応済になったことを示す。
【００７８】
又、コンポーネントＣ１のリビジョンｒ１．２では更に要件Ｒ１．３，Ｒ１．４への対応が必要になったが、Ｒ１．４に対しては「未完」であり、ｒ１．３で「対応済」になったことを示す。
【００７９】
製品バージョン要件の場合と同様に、このような関係も図４における矢印上の＋ＲＸ．Ｘの要件が、前のリビジョンからの修正作業によってその要件に対する対応ステータスが変化したことを示している。
【００８０】
尚、図１０では例えば要件Ｒ１．２とＲ１．３の実現のためにはコンポーネントＣ１とＣ２の２つと関連するが、このように製品全体に対する要件とそのために対応が必要なコンポーネントとは一般的に多対多の関係になる。
【００８１】
以下にユーザーの操作とシステムにおける処理について説明する。
【００８２】
先ず、「対応ステータスの集計」関数を定義する。これは製品バージョン要件或はコンポーネント・リビジョン要件の対応ステータスの値のリストを取り、その集計結果として対応ステータスの１つの値を返す。
【００８３】
これは例えば対応ステータスの値を「予定」「未完」「対応済」「無関係」の順に大きくなる大小関係を持つと見なし、リストから最小の値を求めれば良い。又、リストが空なら「無関係」とする。
【００８４】
次に、「製品バージョン要件の対応ステータス獲得」関数を定義する。
【００８５】
図１１にそのフローを示す。この関数は（製品名、バージョン名、要件ＩＤ）を引数とし、この製品バージョンにおける要件ＩＤの要件の対応ステータスを求め、（定義製品名、定義バージョン名、対応ステータス）の組を返す。
【００８６】
前述のように製品バージョン要件データは差分のみを保持しているため、この製品バージョンに対して要件データがなければ、祖先の製品バージョンを辿って製品バージョン要件データが定義されている最も近い祖先の値を返す。
【００８７】
これは図１１のようにこの関数の再帰呼び出しにより得られる。
【００８８】
全く同様にコンポーネント・リビジョンに対しては「コンポーネント・リビジョン要件の対応ステータス獲得」関数が定義できる。
【００８９】
以下では或る製品のあるバージョンを出荷し、これを基に機能拡張等の新規要件を加えて次のバージョン、或は動作するプラットフォームや対象ユーザーが異なる別系統の製品の最初のバージョンを開発するとする。
【００９０】
この場合、本発明におけるプロジェクト管理システムを利用して開発担当者及び開発管理者は以下の手順で作業を行う。
【００９１】
Ｓ１：新規製品の場合は製品データを追加させる。
【００９２】
Ｓ２：開発する製品バージョンを追加させる。
【００９３】
このためにはシステムは製品名を一覧表示し選択させ、バージョン名を入力させる。
【００９４】
バージョン名に重複がないかをチェックし、新たな製品バージョンデータをデータベースに追加する。
【００９５】
このデータの親バージョンは指定した製品バージョン、ステータスは「予定」とする。
【００９６】
Ｓ３：追加したステータス「予定」の製品バージョンで実現すべき要件を入力する。
【００９７】
システムは図１１の「製品バージョン要件の対応ステータス獲得」関数を使用し、要件データからこの製品バージョンで対応済みでない要件の一覧を表示し、複数選択させる。要件データがなければ追加させる。
【００９８】
選択された各要件に対し、システムは、製品バージョン要件データをその対応ステータス＝「予定」で追加する。
【００９９】
Ｓ４：この新たな製品バージョンの初期状態となるコンポーネント・リビジョン構成を作成させる。
【０１００】
このためにはシステムは、親の製品バージョンのコンポーネント・リビジョン構成を基に、例えば各コンポーネントのブランチリビジョンをステータス＝「予定」で作成し、コンポーネント・リビジョンデータに追加する。
【０１０１】
又、合わせてこの製品バージョンに対するコンポーネント構成の初期データとして、これらのコンポーネント・リビジョンを登録する。
【０１０２】
尚、この過程において各コンポーネントの初期リビジョンをどうするかは全体の検討の結果に基づいて決定することが必要である。
【０１０３】
例えば、或るコンポーネントは親の製品バージョンと同一のリビジョンを使用した方が良い場合もあるし、他の製品におけるリビジョンからブランチリビジョンを作成した方が良い場合もある。
【０１０４】
このような場合には、ユーザーに各コンポーネントのリビジョンを修正させる。
【０１０５】
又、コンポーネントの情報として、あるものは親の製品バージョンに関わらず常にその時点での全体での最新のリビジョンを使用する等と定めておき、それに従って初期リビジョンを設定しても良い。
【０１０６】
Ｓ５：次に、各コンポーネントに対するコンポーネント・リビジョン要件を入力させる。
【０１０７】
これは例えば各コンポーネントの担当者が行う。コンポーネントの担当者は新規に追加された製品バージョン要件から各コンポーネントに関連しコンポーネントの修正を行わなければならないコンポーネントと要件の組合せを検討し決定しなければならない。システムは、このために図１２のような「コンポーネント要件状況画面」を表示する。
【０１０８】
図１２では各行にこの製品バージョンにおける現在のコンポーネント・リビジョンの一覧を表示し、各コンポーネント・リビジョンに対して設定されている要件とその対応状況を表示する。
【０１０９】
図の要件及び対応ステータス欄は、この製品バージョンにおける製品バージョン要件の各々要件ＩＤに対し、このコンポーネント・リビジョンにおける対応ステータスを前記「コンポーネント・リビジョン要件の対応ステータス獲得」関数により獲得し、値が「無関係」以外のものの要件ＩＤ、要件名と獲得した対応ステータス値を表示する。
【０１１０】
図の集計対応ステータスは、各コンポーネント・リビジョンにおける個々の要件によらない対応状況であり、要件ごとの対応ステータスから「対応ステータスの集計」関数で得た値である。
【０１１１】
最初は何もコンポーネント・リビジョン要件が登録されていないので、各行の集計対応ステータス列は「無関係」が表示され、要件列には＜追加＞ボタンのみが表示される。＜追加＞ボタンを選択すると、この製品バージョンにおける製品バージョン要件一覧を表示し、このコンポーネントに関連する要件を複数選択させ、その要件ＩＤに対しコンポーネント・リビジョン要件データを対応ステータス＝「予定」で登録する。
【０１１２】
Ｓ６：以上のように製品バージョン要件と、その実現のために修正が必要なコンポーネント・リビジョンの対応付けが終わると、この製品バージョンデータのバージョン状態＝「開発中」として開発をスタートさせる。
【０１１３】
各コンポーネント担当者は、コンポーネントの修正作業を実施し、何度かリビジョンを改訂していく。
【０１１４】
リビジョン改訂時には担当者は図１２の画面を表示し、コンポーネントに割り当てられた各要件に対する対応ステータスを例えば「未完」「対応済」等に変更する。
【０１１５】
各要件ごとの対応ステータスが変更されれば、上述のように集計対応ステータス列の値を再集計して表示を更新する。
【０１１６】
Ｓ７：管理担当者は開発中の製品バージョンの状態を、例えば図１３のような「製品バージョン要件状況画面」を表示する。
【０１１７】
ここでは、製品バージョン要件データとＢ−１の要件データの階層構造とを突き合わせ、この製品バージョンに関連する要件を階層的に各行に表示する。
【０１１８】
又、この製品バージョンにおける現在のコンポーネント・リビジョン構成とコンポーネント・リビジョン要件データから、要件ごとに関連するコンポーネント、リビジョンとその対応ステータスを表示する。
【０１１９】
図の集計対応ステータス欄は各要件に対して、関連コンポーネントの対応ステータスの集計値であり、前述の「対応ステータスの集計」関数により得られる。
【０１２０】
又、階層構造上の親要件に対しては、その子要件の集計対応ステータスの集計値をその集計対応ステータスとして表示する。
【０１２１】
Ｓ８：図１３の製品バージョン要件状況画面で、全ての要件の集計対応ステータスが「対応済」になればこの製品バージョンの完成である。
【０１２２】
管理者はシステムを使用してこの製品バージョンの状態を「出荷済」とすることによりこのバージョンのコンポーネント・リビジョン構成を確定する。
【０１２３】
尚、上述の説明では、図２の製品バージョン要件Ｂ−９、コンポーネント・リビジョン要件Ｂ−１０は差分管理するとしたが、勿論、差分管理でなくても良い。
【０１２４】
この場合には、例えば或るコンポーネント・リビジョンに割り当てられたコンポーネント・リビジョン要件データがあれば、このコンポーネントの次のリビジョンでも要件データが同じ対応ステータスで作成される。この方法ではデータ量は大幅に増加するが、処理は単純なため処理速度は向上する。
【０１２５】
又、部分的に差分管理を行う方法もある。例えば、製品バージョンの出荷時点におけるコンポーネント・リビジョンに、それまでに関連したコンポーネント・リビジョン要件をコピーし、以後、このリビジョンを基に次のリビジョンが作成される場合には、次のリビジョンに対して割り当てられた要件のみを差分管理していく等である。
【０１２６】
又、上述の説明では製品が複数のコンポーネントから直接構成されるとして説明したが、勿論、「製品−ユニット−部品」のような階層構造として管理しても良い。このような場合には、図２の代わりに図１４のようなデータ構造を使用する。
【０１２７】
図１４において、要件データＢ−１は、図２と同様、コンポーネント・リビジョンデータＢ−１１は階層を含めた全てのコンポーネント、即ち製品、ユニット、部品等のそれぞれのコンポーネント名とリビジョン名を管理する。その内容は図７と同様である。
【０１２８】
コンポーネント構成Ｂ−１２は、コンポーネント・リビジョンの親子関係、例えば製品１のリビジョン１．１は、ユニット１のリビジョン１．１とユニット２のリビジョン１．２から成り、ユニット１のリビジョン１．１は、部品１のリビジョン１．３とから成るといった関係を保持するデータである。尚、例えば部品１のリビジョン１．１は、製品２のユニット１のリビジョン１．５にも使用する等、共有される場合があるので、コンポーネント構成Ｂ−１２は、コンポーネント・リビジョンＢ−１１同士を多対他に関連づけるリレーションとなる。
【０１２９】
図１４の例においても、基本的には最下層のコンポーネントである部品に実現すべき要件を割当て、その対応ステータスを管理していくことになるが、やはり先ずは最上位の製品に対して開発する次のリビジョンの要件の予定を割当て、更にその要件の中から順次下位のコンポーネントに要件の予定を割り当てていくことが望ましい。
【０１３０】
このようにして各コンポーネントに対して実現すべき要件を割り当てた後、開発をスタートし、以後は前述のように担当者は最下層のコンポーネントのリビジョンアップと要件の対応ステータスを入力していく。
【０１３１】
尚、操作上、例えば中位のコンポーネントに割り当てられた要件を「対応済み」にすることにより、下層のコンポーネント全てに対しその要件の対応ステータスを「対応済み」に変更するようにすることもできる。
【０１３２】
上位コンポーネントの要件の対応状況は前述のように子孫のコンポーネントの対応状況の集計結果が自動的に反映される。
【０１３３】
又、例えば図１２のコンポーネント要件状況画面で、担当者が各要件に対する対応ステータスの予定や実績を入力する際、その対応作業のための期間や開発工数の予定・実績等も合わせて入力させれば、製品バージョンでの要件ごとの期間や開発工数、或は製品バージョン全体での期間や開発工数等も自動集計可能である。
【０１３４】
又、対応ステータスの代わりに実績としては進捗率のような数値で入力させても良い。
【０１３５】
又、開発作業には「会議」等のコンポーネントの作成・修正以外の作業もあるが、そのような場合には例えば会議の議事録等をダミーのコンポーネントとして作成し、同様に管理することができる。
【０１３６】
又、或る製品の複数のバージョン、或は複数の製品の次バージョンを同時に開発するような場合もあり得る。
【０１３７】
このような場合には、例えば図１２及び図１３で特定の製品バージョンにおけるコンポーネント・リビジョン要件対応状況、製品バージョン要件対応状況を表示するだけでなく、現在開発中の全ての製品バージョンに対する要件対応状況を同時に表示するような画面を設けると有用である。
【０１３８】
＜実施の形態２＞
次に、例えば出荷した製品バージョンに不具合が発生した場合について説明する。
【０１３９】
不具合の解析の結果、２つのコンポーネントに問題があり、このため２つの要件に対する対応が不完全であったことが分ったとする。実際には、この問題は製品バージョンにおけるコンポーネント・リビジョンで持ち込まれたものでなく、それ以前のリビジョンで既にあった問題である場合も多い。
【０１４０】
更に、これらのコンポーネントは他の製品でも使用されており、他の製品も同様に修正しなければならない場合もある。
【０１４１】
何れにせよ担当者は問題のあったコンポーネントのどのリビジョンまで遡って修正するかを決定しなければならない。このために対応ステータスの選択肢として「不具合」を追加し、「不具合」「予定」「未完」「対応済」「無関係」の順に大きくなる大小関係とし、前述の対応ステータスの集計関数ではこれらの最小値を求めるものとする。
【０１４２】
修正を行うリビジョンが決定されれば、システムは、そのリビジョンのリビジョン要件データの対応ステータス値を例えば「不具合」に変更する。このとき、システムは、このリビジョンの子孫の全てのリビジョンを辿り、もし同じ要件に対するリビジョン要件データがあればその対応ステータスも「不具合」に変更していく。
【０１４３】
上述のように、製品バージョン要件データのステータス値は、コンポーネント・リビジョン要件データの対応ステータス値の集計値が反映されるので、結果として関連した製品バージョンの対応ステータスが「不具合」となる。
【０１４４】
尚、この方法では、要件データの対応ステータス値が変更されてしまい、以前の値が分からなくなってしまう問題がある。この対処のためには、製品バージョン要件データ、コンポーネント・リビジョン要件データの前の対応ステータス値を保存するようにしておく。又、不具合も解決すべき課題であるから要件と同様と考える方法もある。即ち、発生した不具合の情報を図２のＢ−１の要件データとして追加する。
【０１４５】
次に、原因となったコンポーネント・リビジョンに対し、この不具合要件に対する要件データを対応ステータス＝「不具合」で追加する。
【０１４６】
システムは、このリビジョンの子孫およびそれを使用している製品バージョンを追跡することによって、この不具合が存在する可能性のあるものを指摘できる。
【０１４７】
次に、修正する製品バージョンの派生バージョンを作る。
【０１４８】
前述のように、各コンポーネント・リビジョンのブランチリビジョンが作成されるが、原因となったコンポーネントに対しては対応ステータス＝「不具合」となっているので、これがブランチリビジョンに引き継がれる。
【０１４９】
以後はこの不具合を修正し、修正したリビジョンで対応ステータス＝「対応済み」とすれば良い。
【０１５０】
尚、この不具合要件データを不具合の生じた要件データの子データとして追加するようにするか、或は不具合要件データ中に不具合の生じた要件ＩＤを持たせることによりどの要件に対して不具合が生じたのかを追跡することが可能になる。
【０１５１】
＜実施の形態３＞
複数の別系列のリビジョンから新たなリビジョンを作るいわゆる「マージ」を支援する場合について説明する。
【０１５２】
この場合、図６の製品バージョンにおける親バージョン情報、図７のコンポーネント・リビジョンにおける親リビジョン情報は複数の親を持つためリストになる場合がある。従って、図１１における「製品バージョン要件の対応ステータス獲得」関数Ｆ−１は、図１５のＦ−１’よりのフローに変更される。即ち、ステップＦ−７に代わるＦ−７’おいて複数の親バージョンに対して要件の対応ステータスを獲得し、その集計値を結果として返す。「コンポーネント・リビジョン要件の対応ステータス獲得」関数も同様に変更される。
【０１５３】
或るコンポーネントのリビジョンを他の２つの親リビジョンのマージで作成した場合、このリビジョンは２つの親リビジョンで対応済みの全ての要件に対し、対応済みであることになる。
【０１５４】
但し、これらの対応ステータス値が正しいかどうか、即ち、実際に２つの親リビジョンで対応済みの要件には対応済みかどうかは問題であり、基本的には担当者が検討を行い決定しなければならないが、例えば以下のような方法で初期値を設定しても良い。
（１）２つの親リビジョンの共通の祖先となるリビジョンを求め、その共通祖先リビジョンでの対応済み要件は対応済みとし、共通祖先から２つの親リビジョン間で対応された要件に対しては「予定」或は「未完」とする。
（２）２つの親リビジョンそれぞれでの対応済みの要件の集合に対し、その共通集合である要件に対しては「対応済」、残りの要件に炊いては「未完」とする。
【０１５５】
何れにせよ担当者はコンポーネントの詳細を検討し、マージ後の要件の各々について新たな修正が必要か、以前のままで問題ないかを判断し、対応ステータス値を適した値に設定しなければならない。
【０１５６】
＜実施の形態４＞
次に、要件自体の削除や変更があった場合の対応方法について説明する。
【０１５７】
例えば、古い機能が必要なくなった場合には、以後のバージョンではこの機能が確実に削除されていなければ問題を起こす可能性が高い。
【０１５８】
又、要件の内容が変更された場合、例えばこれまで５桁であったユーザーコードが６桁に変更されたような場合、以降のバージョンではこの変更が確実に対応されていることが必要である。即ち、要件の削除や変更は、それ自体が新たな要件となる。このためには、図２の要件データＢ−１の内容は図５のものから図１６のものに変更される。
【０１５９】
図１６では、各要件に対し、要件種別、対象要件ＩＤ、変更回数の３つの属性が追加されている。
【０１６０】
要件種別は「通常」「変更」「削除」の３つの値を取り、「通常」は通常の要件、「変更」は対象要件ＩＤで示される要件の変更であること、「削除」は対象要件ＩＤで示される要件の削除であることを示す。
【０１６１】
変更回数属性は、要件の変更は何度か行われる可能性があるため、その識別のために使用し、同一の対象要件ＩＤを持つ種別が「変更」或は「削除」である要件に対して、１より順次増加させるとする。即ち、この番号の一番大きなものが対象要件ＩＤで示される要件に対して現在有効な変更或は削除である。
【０１６２】
図１６では、Ｒ１．１のＸＸ表示要件に対し、２度変更が行われており、現在有効なのはＲ１．１１であってＲ１．１とＲ１．９は有効でないことを灰色で示している。
【０１６３】
又、Ｒ１．１０はＲ１．２の要件を廃止するという要件であり、Ｒ１．２は現在有効でないことを灰色で示している。
【０１６４】
このような種別が「変更」「削除」である要件も、上述の説明のように通常の要件と全く同様に扱うことができる。
【０１６５】
＜実施の形態５＞
次に、コンポーネント・リビジョンの実体と本発明におけるシステムを連動させる例を説明する。
【０１６６】
コンポーネントが例えばソースファイルや文書ファイルである場合には、その実体の管理には汎用的ないわゆるファイルのバージョン管理ツールが有用である。このようなツールには、例えばＧＮＵのＣＶＳ等が利用できる。
【０１６７】
図１７にこのようなファイルのバージョン管理ツールをバックエンドとして、コンポーネントの実体管理に利用する場合の構成を示す。
【０１６８】
図１７では、図１に対してファイルのバージョン管理ツールのサーバーが動作するファイル管理サーバーマシンＡ−５と、このツールが使用するファイルリポジトリＡ−６が追加されている。
【０１６９】
各クライアントマシンＡ−１，Ａ−２には、このファイル管理ツールのクライアントプログラムがインストールされており、各ユーザーは、自分のクライアントマシンから直接このファイル管理ツールを使用することが可能である。
【０１７０】
又、システムのサーバーマシンＡ−３にもこのファイル管理ツールのクライアントプログラムがインストールされており、サーバープログラムは、これを利用してファイル管理ツールに実行を指示したり、情報を読み出したりできる。
【０１７１】
勿論、サーバーＡ−３，Ａ−５は、同一マシンであっても構わず、ファイル管理サーバー或はファイルリポジトリが複数あっても構わない。
【０１７２】
連携のためには、例えばシステムはコンポーネントデータＢ−５の属性として、このコンポーネントのファイルリポジトリＡ−５における識別子、例えばリポジトリ名とファイルのパス名を記憶する。
【０１７３】
コンポーネントのリビジョン名としては、ファイルのバージョン管理ツールが使用するリビジョン名と同じ値を使用しても良く、リビジョン名の対応表を作成・管理しても良い。
【０１７４】
システムの操作手順は基本的に前述のＳ１〜Ｓ８と同様であるが、ファイルのバージョン管理ツールと特に関連するのはＳ４及びＳ６である。
【０１７５】
Ｓ４で新たな製品バージョンの初期状態となるコンポーネント・リビジョン構成を作成させるときには、前述と同様に先ずシステムのデータベースにこの製品バージョンで使用する初期コンポーネント・リビジョンを登録する。
【０１７６】
ユーザーは、必要によっては他のリビジョンを使用する等、このデータを変更しても良い。
【０１７７】
各コンポーネントの初期リビジョンが或る程度確定すれば、担当者或は管理者の指示により、システムは、ファイル管理ツールを使用して、各コンポーネントに対して必要となるファイルリビジョンを一括して生成する。
【０１７８】
例えば、派生リビジョンの作成が必要な場合には、親リビジョン名を指定してブランチを作るようファイル管理ツールに指示する。
【０１７９】
２つのリビジョンをマージしたリビジョンの作成が必要な場合には、２つの親リビジョン名を指定してマージしたファイルリビジョンを作成させる。
【０１８０】
又、Ｓ６では、以下のようにして担当者が行うコンポーネントに割り当てられた各要件に対する対応ステータスの入力とファイル管理ツールを使用したファイルの修正作業を連動させる。
【０１８１】
担当者は、ファイル管理ツールのクライアントプログラムを使用して、先ず、修正を行うファイルリビジョンをチェックアウトするようファイル管理サーバーＡ−５に要求する。この要求は実行される前に先ずそのクライアントマシンで動作するシステムのプログラムに通知される。このプログラムは、必要ならチェックアウトするリビジョンの情報等をファイル管理サーバーＡ−５から獲得し、システムサーバーから対応するコンポーネント・リビジョンの情報を得て、このコンポーネント・リビジョンの情報を表示するＵＲＬを作成してＷｅｂブラウザを起動してこのＵＲＬを表示させる。
【０１８２】
担当者は、この画面で、このチェックアウトで新たに対応する要件があれば、これをこの新リビジョンに対して割り当て、システムのデータベースを更新する。或は、一度対応済みとした要件だが問題が見つかった場合には、対応ステータスを「未完」に変更して更新する。
【０１８３】
この操作の終了は再びシステムのクライアントプログラムに通知され、この通知によってシステムのクライアントプログラムはファイル管理サーバーに対して実際にチェックアウト処理を実行するよう指示する。これによってファイル管理サーバーからファイルがチェックアウトされ、クライアントマシンにファイルが転送されてくる。
【０１８４】
続いて、担当者は、ファイルの修正を行い、修正が終わればそのファイルをチェックインするようサーバーＡ−５に要求する。この場合も同様に、システムのクライアントプログラムがこの要求をトラップし、同様にコンポーネント・リビジョンの情報を表示するＵＲＬを作成し、Ｗｅｂブラウザを起動して表示させる。
【０１８５】
担当者は、この画面で，チェックインしようとしたリビジョンに対して割り当てられている要件を確認し，その対応ステータスを例えば「未完」から「対応済」に変更する．
この操作の終了も同様に再びシステムのクライアントプログラムに通知され，この通知によってシステムのクライアントプログラムはファイル管理サーバーに対して実際にファイルのチェックインを実行するよう指示する。これによってクライアントマシン上のファイルがファイル管理サーバーに転送され、ファイルリポジトリ上に新たなリビジョンとして保管されることになる。
【０１８６】
尚、クライアントマシンからファイル管理ツールへの要求をシステムがトラップする方法としては、各クライアント上のファイル管理ツールのクライアントプログラムを置き換える方法がある。
【０１８７】
又、他の方法としては、例えばＧＮＵ，ＣＶＳではファイル管理サーバーＡ−５で動作するファイル管理ツールのサーバーに、チェックインやチェックアウトを実行する前後に指定したプログラムを実行するよう設定できる機能がある。このような場合には、ファイル管理サーバーにシステムのプログラムを設定すれば良い。
【図面の簡単な説明】
【０１８８】
【図１】本発明の基本構成を説明する図である。
【図２】本発明の概念的なデータ構造を説明する図である。
【図３】例として説明するための製品バージョン及びコンポーネント・リビジョンの系統図である。
【図４】例として説明するための製品バージョン及びコンポーネント・リビジョンの系統図である。
【図５】本発明における各データの内容を説明する図である。
【図６】本発明における各データの内容を説明する図である。
【図７】本発明における各データの内容を説明する図である。
【図８】本発明における各データの内容を説明する図である。
【図９】本発明における各データの内容を説明する図である。
【図１０】本発明における各データの内容を説明する図である。
【図１１】本発明における製品バージョン要件の対応ステータス獲得関数のフロー図である。
【図１２】本発明の画面例を説明する図である。
【図１３】本発明の画面例を説明する図である。
【図１４】本発明における概念的なデータ構造の他の例を説明する図である。
【図１５】本発明における製品バージョン要件の対応ステータス獲得関数の拡張されたフロー図である。
【図１６】本発明における拡張された要件データを説明する図である。
【図１７】本発明の拡張された構成を説明する図である。
【符号の説明】
【０１８９】
Ａ−１  クライアント
Ａ−２  クライアント
Ａ−３  サーバー
Ａ−４  データベース（ＤＢ）
Ａ−５  ファイル管理サーバー
Ａ−６  ファイルリポジトリ
【図１】
2006221316.tif 000003
【図２】
2006221316.tif 000004
【図３】
2006221316.tif 000005
【図４】
2006221316.tif 000006
【図５】
2006221316.tif 000007
【図６】
2006221316.tif 000008
【図７】
2006221316.tif 000009
【図８】
2006221316.tif 000010
【図９】
2006221316.tif 000011
【図１０】
2006221316.tif 000012
【図１１】
2006221316.tif 000013
【図１２】
2006221316.tif 000014
【図１３】
2006221316.tif 000015
【図１４】
2006221316.tif 000016
【図１５】
2006221316.tif 000017
【図１６】
2006221316.tif 000018
【図１７】
2006221316.tif 000019