JP2000215038A

JP2000215038A - 情報管理装置および記録媒体

Info

Publication number: JP2000215038A
Application number: JP11173238A
Authority: JP
Inventors: Masahiro Noguchi; 正浩野口; Minoru Kondo; 実近藤; Naoki Kitahara; 直樹北原; Ken Kikata; 憲木方
Original assignee: Nippon Steel Corp
Current assignee: Nippon Steel Corp
Priority date: 1998-11-20
Filing date: 1999-06-18
Publication date: 2000-08-04

Abstract

(57)【要約】【課題】ソフトウェア開発の作業を開発者が意識しな
くても適切に行うことができ、かつプロジェクト情報間
の整合性を正しく維持できるようにする。【解決手段】システム開発の基本的なプロセスを定義
するプロセス定義部１と、記述形式格納部４内のプロセ
ス定義の内容を参照しながら実際のプロジェクトに合わ
せて各種作業を実行し、種々のプロジェクト情報を生成
してプロジェクト情報格納部５に格納する複数の処理実
行部６〜１６とを設けることにより、最初に基本的なプ
ロセス定義を記述しておけば、複数の処理実行部により
そのプロセス定義の内容に沿って正しい手順でプロジェ
クト情報を順次生成していくことができ、生成したプロ
ジェクト情報を各成果物間の関連等も含めて１つの記憶
手段にて一元的に管理することができるようにし、プロ
ジェクト情報間に矛盾が生じないようにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は情報管理装置および
記録媒体に関し、特に、ソフトウェア開発・保守を実施
する一連のプロジェクト上で発生する様々な情報（以
下、プロジェクト情報と称する）を一元的に管理するこ
とによってソフトウェア開発・保守を支援するための装
置に用いて好適なものである。

【０００２】

【従来の技術】一般に、ソフトウェアの開発・保守は、
仕様書の作成、設計書の作成、ソースコードやバイナリ
コードの作成、出来上がったプログラムのテストなどの
各種の作業を通して行われる。そして、これらの作業を
行う際には、仕様書やソースコードなどの成果物の他
に、テストデータ、障害に関する情報、バージョンや進
捗に関する情報など、様々な情報（プロジェクト情報）
が扱われる。

【０００３】通常、これらのプロジェクト情報は、実際
には個々が単に独立したものとして存在するのではな
く、他の情報との関係を持って存在することが多い。例
えば、要求仕様書を参照して詳細設計書が作成され、そ
の作成された詳細設計書を参照してソースコードが作成
されるといったように、成果物どうしには何らかの参照
関係が存在する。

【０００４】したがって、上述の例でソースコードを作
成しようとする場合には、原則的にはその前提として詳
細設計書が作成されていなければならず、更にその詳細
設計書を作成しようとする場合には、原則的にはその前
提として要求仕様書が作成されていなければならないと
いうことになる。また、あるプロジェクト情報を変更し
たり削除した場合には、これに関連する他のプロジェク
ト情報も併せて変更したり削除しなくてはならない場合
が少なからず生じる。

【０００５】

【発明が解決しようとする課題】従来、このようなプロ
ジェクト情報を生成・管理するためのツールがいくつか
提案され、また利用されている。しかしながら、これら
のツールでは、各ツールで作成されたプロジェクト情報
が各ツール毎に散在して管理されており、しかも互いの
関係が管理されることはなかった。

【０００６】そのため、例えば開発者があるプロジェク
ト情報を変更したときに、これに関連して変更すべき他
のプロジェクト情報があるときは、そのことを開発者自
らが判断し、そのためのツールを立ち上げて変更を行う
必要があった。よって、関連するプロジェクト情報の変
更を行うことを忘れてしまい、その結果、プロジェクト
情報間で整合性を欠いてしまうことがあるという問題が
あった。

【０００７】特に、ソフトウェア開発においては、成果
物の変更に伴ってバージョン（版）を順次更新すること
がよく行われる。そのため、開発者は、ある成果物のあ
る版に変更を加えたときに、それに関連して変更すべき
成果物の種類だけでなく、その成果物のどの版を変更す
べきかということまで自分で判断する必要があり、非常
に煩雑であった。

【０００８】また、従来のツールでは、各種プロジェク
ト情報の作成や変更を行う場合、基本的な操作は可能で
あるが、いつ、誰が、どの作業をして、どのような情報
を生成するかという作業手順を管理する手段を備えてい
ない。そのため、例えばあるアプリケーションソフトウ
ェアを作成しようとする場合、どのような作業をどのよ
うな順番で行うかを開発者自身が判断して行う必要があ
った。その結果、必要な作業の抜けが生じたり、適切で
ない順番で作業を行ってしまうことがあるという問題も
あった。

【０００９】さらに、一連のソフトウェア開発で生成さ
れたシステムをリリースするときには、前のバージョン
からの変更点や、対応済あるいは未対応の障害に関する
情報などを記述したリリースノートを作成することが多
い。しかしながら、従来は、このリリースノートは開発
者が記述していたため、必要な情報の記述漏れがあった
り、整合性を欠いてしまうなどの問題があった。

【００１０】本発明は、このような問題を解決するため
に成されたものであり、散逸しがちなプロジェクト情報
を一元管理し、版ごとに管理される各プロジェクト情報
間の整合性を常に正しく維持できるようにするととも
に、ソフトウェア開発で必要な作業を開発者が特に意識
しなくても適切な手順で行うことができるようにするこ
とを目的としている。また、本発明は、リリースノート
作成の効率を上げるとともに、その記述漏れや不整合を
抑制できるようにすることも目的としている。

【００１１】

【課題を解決するための手段】本発明の情報管理装置
は、システム開発・保守を行う上で必要な作業を示すタ
スク名とその順序、各タスクにより生成される成果物
名、各タスクを実行する作業者名、各成果物間の関連、
およびシステムの階層構造の各情報を含み、システム開
発・保守の基本的なプロセスを定義するプロセス定義手
段と、上記プロセス定義手段により記述されたプロセス
定義を格納する第１の記憶手段と、上記システム開発・
保守を実際に行うプロジェクトに合わせて各種作業を実
行し、その際に上記第１の記憶手段に格納されているプ
ロセス定義の内容を解析して種々のプロジェクト情報を
生成する複数の処理実行手段と、上記複数の処理実行手
段により生成されたプロジェクト情報を格納する第２の
記憶手段とを備えたことを特徴とする。ここで、上記プ
ロセス定義での各タスク名の記述順序はタスクの実行順
序と一致するようにしても良い。

【００１２】本発明の他の態様では、上記複数の処理実
行手段は、ある成果物を作成もしくは変更するときに、
上記プロセス定義を参照して、当該成果物に対応するタ
スクを自動的に生成する第１の自動生成手段を含むこと
を特徴とする。ここで、上記第１の自動生成手段は、上
記プロセス定義に記述されている順序に従ってタスクを
生成するようにしても良い。また、上記第１の自動生成
手段は、作成もしくは変更した成果物との関連が上記プ
ロセス定義に記述されている成果物に対して参照関係を
自動的に生成する手段を更に含むようにしても良い。

【００１３】本発明のその他の態様では、上記複数の処
理実行手段は、ある成果物を削除するときに、上記プロ
セス定義を参照して、当該削除した成果物との関連が定
義されている成果物を自動的に削除する第１の自動削除
手段を含むことを特徴とする。

【００１４】本発明のその他の態様では、上記複数の処
理実行手段は、ある成果物を変更するときに、上記プロ
セス定義を参照して、当該変更した成果物との関連が定
義されている成果物を報知する報知手段を含むことを特
徴とする。

【００１５】本発明のその他の態様では、上記複数の処
理実行手段は、ある成果物間の参照関係を作成するとき
に、上記プロセス定義を参照して、当該作成した参照関
係に付随して作成すべき成果物間の参照関係を自動的に
生成する第２の自動生成手段を含むことを特徴とする。
また、上記複数の処理実行手段は、ある成果物間の参照
関係を削除するときに、上記プロセス定義を参照して、
当該削除した参照関係に付随して削除すべき成果物間の
参照関係を自動的に削除する第２の自動削除手段を含む
ことを特徴とする。

【００１６】本発明のその他の態様では、上記複数の処
理実行手段は、成果物あるいは参照関係の作成、変更も
しくは削除を行うときに、上記第１の記憶手段内のプロ
セス定義と上記第２の記憶手段内に既に格納されている
プロジェクト情報とを参照して、その時点で選択可能な
成果物の一覧を作成する一覧作成手段を含むことを特徴
とする。

【００１７】本発明のその他の態様では、上記複数の処
理実行手段は、上記タスクが生成されたときに、そのタ
スクを実行すべき作業者を割り当てる処理を起動する作
業者割り当て手段を含むことを特徴とする。

【００１８】本発明のその他の態様では、システムの開
発・保守を行う際にバージョンアップされる各成果物の
版と、上記システムの版および当該システムに含まれる
成果物の構成とを管理する版・構成管理手段を備え、上
記複数の処理実行手段により生成されるプロジェクト情
報を、上記システムの版ごと、および当該システムの各
版を構成する各成果物の版ごとに管理することを特徴と
する。

【００１９】本発明のその他の態様では、上記成果物あ
るいは参照関係の作成、変更もしくは削除を行うとき
に、上記第１の記憶手段内のプロセス定義と上記第２の
記憶手段内に既に格納されているプロジェクト情報とを
参照して、上記作成、変更もしくは削除を行う成果物の
版と関連のある成果物の版の一覧を作成する一覧作成手
段を備えることを特徴とする。

【００２０】本発明のその他の態様では、上記成果物の
変更を行うときに、変更後の成果物を新たな版に更新す
るか現状の版で対応するかをユーザに選択させる選択手
段を備えることを特徴とする。この場合、上記タスクの
実行工程を管理し、各タスクが計画中、実行中、完了の
何れの段階にあるのかを管理する工程管理手段を備え、
上記選択手段は、上記工程管理手段により管理されてい
るタスクの状態が計画中もしくは実行中のタスクに対応
する成果物についてのみ、上記変更後の成果物を新たな
版に更新するか現状の版で対応するかをユーザに選択さ
せるようにしても良い。

【００２１】本発明のその他の態様では、上記版・構成
管理手段は、上記成果物の作成、変更もしくは削除を行
うときに、上記システムの新しい版およびそれに含まれ
る各成果物の版の新しい構成を生成することを特徴とす
る。

【００２２】本発明のその他の態様では、上記成果物の
障害を管理する障害管理手段と、上記複数の処理実行手
段により上記成果物あるいは参照関係の作成、変更もし
くは削除を行うときに入力される変更データ、および上
記障害管理手段により障害管理を行うときに入力される
障害データを用いて、更新した版の内容を表すリリース
ノートを自動的に生成する第３の自動生成手段とを備え
たことを特徴とする。

【００２３】また、本発明のコンピュータ読み取り可能
な記録媒体は、システム開発・保守を行う上で必要な作
業を示すタスク名とその順序、各タスクにより生成され
る成果物名、各タスクを実行する作業者名、各成果物間
の関連、およびシステムの階層構造の各情報を含み、シ
ステム開発・保守の基本的なプロセスを定義するプロセ
ス定義手段と、上記システム開発・保守を実際に行うプ
ロジェクトに合わせて各種作業を実行し、その際に上記
プロセス定義手段により記述されたプロセス定義の内容
を解析して種々のプロジェクト情報を生成し、それを記
憶手段に格納する複数の処理実行手段としてコンピュー
タを機能させるためのプログラムを記録したことを特徴
とする。

【００２４】本発明は上記技術手段より成るので、最初
に基本的なプロセス定義を記述しておけば、そのプロセ
ス定義の内容に沿ってプロジェクト情報を正しい手順で
生成していくことができ、しかも１つの基本的なプロセ
ス定義から異なるプロジェクト毎にそれぞれのプロジェ
クト情報を生成することができる。さらに、複数の処理
実行手段により順次生成したプロジェクト情報を各成果
物間の関連等も含めて１つの記憶手段にて一元的に管理
することが可能となる。

【００２５】本発明の他の特徴によれば、ある処理実行
手段により成果物が作成もしくは変更されると、当該成
果物に対応するタスクが自動的に生成されるので、開発
者は当該成果物を作成するための作業を特に意識しなく
ても正しい手順で作業を行うことが可能となる。さら
に、上記作成もしくは変更した成果物との関連が定義さ
れている成果物に対して参照関係が自動的に生成される
ので、成果物間の関連等について開発者が特に意識しな
くても、常に正しい関連が維持される。

【００２６】この参照関係の自動生成は、ある成果物間
の参照関係を作成したときにも、それに付随して作成す
べき参照関係について同様に行われる。また、これとは
逆にある成果物間の参照関係が削除されると、当該削除
された参照関係に付随して削除すべき成果物間の参照関
係が自動的に削除されるので、プロジェクト情報間の関
連が常に正しく維持される。

【００２７】本発明のその他の特徴によれば、ある処理
実行手段により成果物が削除されると、当該削除された
成果物との関連が定義されている成果物が自動的に削除
されるので、付随して削除すべき情報の消し忘れがなく
なり、正しい整合性を維持することが可能となる。ま
た、上述のように参照関係の自動生成によって正しい関
連が維持されているので、自動削除すべき情報の漏れが
ない。

【００２８】本発明のその他の特徴によれば、ある処理
実行手段により成果物が変更されると、当該変更された
成果物との関連が定義されている成果物が開発者に報知
されるので、付随して変更すべき情報の変更し忘れがな
くなり、正しい整合性を維持することが可能となる。ま
た、上述のように参照関係の自動生成によって正しい関
連が維持されているので、報知すべき情報の漏れがな
い。

【００２９】本発明のその他の特徴によれば、ある処理
実行手段により成果物あるいは参照関係の作成、変更も
しくは削除が行われると、その時点で選択可能な成果物
の一覧が作成され、例えば画面表示によって開発者に知
らせられるので、成果物や参照関係を操作できる作業に
制限が設けられ、その時点で有効なもの以外は選択でき
ないようになり、開発者が特に意識しなくても、常に正
しい成果物を参照しながらソフトウェア開発を実施する
ことができるようになる。

【００３０】本発明のその他の特徴によれば、複数の処
理実行手段により生成されるプロジェクト情報が、シス
テムの版ごとおよび当該システムの版を構成する各成果
物の版ごとに管理されるので、成果物間の参照関係がシ
ステムの版および成果物の版ごとに適切に維持されるよ
うになる。

【００３１】本発明のその他の特徴によれば、例えばあ
る成果物のある版に対して作成、変更もしくは削除が行
われると、それと関連のある成果物の版の一覧が作成さ
れ、例えば画面表示によって開発者に知らせられるの
で、開発者は、付随して変更等を行うべき成果物の版を
容易に知ることが可能となる。

【００３２】本発明のその他の特徴によれば、成果物の
作成、変更もしくは削除が行われると、それに対応して
システムの新しい版およびそれに含まれる各成果物の版
の新しい構成が生成されるので、開発者が特に意識しな
くても、各成果物の版の間で常に正しい参照関係等が維
持されるようになる。

【００３３】本発明のその他の特徴によれば、成果物等
の変更の実行過程で得られる変更データ、および障害管
理手段による障害管理の実行過程で得られる障害データ
を用いてリリースノートが自動生成されるので、開発者
がリリースノートを一から作成しなくても済むようにな
る。

【００３４】

【発明の実施の形態】以下、本発明の一実施形態を図面
に基づいて説明する。図１は、本実施形態による情報管
理装置の全体構成を示す機能ブロック図である。

【００３５】図１において、１はプロセス定義部であ
り、ソフトウェア開発・保守を行う上で必要な基本的な
プロセスを定義する。プロセス定義の記述には、システ
ム等を開発するためにはどんな作業が必要であるかの基
本的なタスク名と、各タスクによって生成される成果物
名と、各タスクを誰（どのチーム）が実行するかの役割
を示す概念としてのチーム名と、タスクと成果物との関
係や成果物と役割との関係、さらには各成果物間の参照
関係との記述が少なくとも含まれる（ただし、成果物と
タスクとの関係が１対１であるならば、タスクに関する
内容をプロセス定義で記述しなくても良い）。各タスク
名の記述順序はタスクの実行順序と一致するものとす
る。

【００３６】このプロセス定義では、上述のタスク名や
成果物等を階層構造的に記述する。図２（ａ）は、一例
として成果物名を階層構造的に記述した例を概念的に示
している。この例では、１つのアプリケーションは仕様
書、ソースコード、バイナリ、リリースノートの構造を
持つということが示されている。また、これらの成果物
間の参照関係の記述としては、仕様書を参照してソース
コードが作成され、そのソースコードを参照してバイナ
リが作成されるといったような基本的な参照関係を記述
する。

【００３７】図３〜図５は、プロセス記述の具体的な例
を示す図である。この例の記述中において、unitはシス
テムの構造を表すものであり、階層構造の各階層に置か
れる。ここには、各階層のunitが持つ具体的な構造要素
（component ）が定義されている。unitの構造要素（co
mponent ）としては、タスク名、各タスクによる成果物
名、タスクと成果物との関係や各成果物間の参照関係
（reference ）等が記述される。また、各成果物に対し
て、その成果物を生成するチーム名（role）や、その成
果物を生成する際に事前に生成されていることが必要な
成果物を表す起動条件（trigger ）も記述される。

【００３８】例えば、図３において、「define unit シ
ステム」と記述された部分には、このシステムを生成す
るためのタスクとして、分析設計、サブシステム開発、
テストの３つのタスクがあり、これらのタスクに対応す
る成果物として、仕様書、サブシステム、テストデータ
がこの順番で作られることが示されている。なお、成果
物名の後に記された＜＞内の数字は、その成果物をいく
つ持てるかを表したものである。

【００３９】上記仕様書に関しては、「define product
システム．仕様書」と記述された部分において、その
仕様書は分析設計チームが作成するということが示され
ている。また、上記テストデータに関しては、「define
product システム．テストデータ」と記述された部分
において、そのテストデータは品質保証チームが作成
し、実行コード（バイナリコード）とライブラリとが全
て作られていることが事前条件として必要であることが
示されている。

【００４０】また、上記サブシステムに関しては、「de
fine unit システム．サブシステム」と記述された部分
において、更にこのサブシステムを生成するためのタス
クとして、分析設計、アプリケーション開発、ライブラ
リ開発、テストの４つのタスクがあり、各タスクに対応
する成果物として仕様書、アプリケーション、ライブラ
リ、テストデータがこの順番で作られることが示されて
いる。また、図４の「define unit システム．サブシス
テム．アプリケーション」と記述された部分に示すよう
に、アプリケーションを作成する際にはライブラリを参
照するということも示されている。

【００４１】このように、本実施形態では、ソフトウェ
ア開発で生成される各成果物間の関係だけでなく、その
成果物を誰が作るのか、その成果物を作るためには事前
にどんな成果物が作られていることが必要で、どんな作
業をしなければならないか等の情報を含めて、ソフトウ
ェア開発のプロセスをモデル化し、それを整理して記述
できる仕組みを提供している。

【００４２】上記プロセス定義部１で記述するプロセス
定義は、ソフトウェア開発の具体的なプロジェクトに依
存しない、基本的でかつ概念的なプロセスを定義したも
のであり、プロジェクトにおいては、プロセス定義にお
ける各要素を具現化したものをプロジェクト情報として
管理する。例えば、プロセス定義中の成果物であるアプ
リケーションは、プロジェクトによって、図２（ｂ）の
ような生産管理システムや計画システムといった固有の
情報として具現化される。

【００４３】また、あるプロジェクトがある基本プロセ
ス定義と合致した開発・保守を行うならば、その基本プ
ロセス定義からプロジェクト情報を生成することができ
る。一方、プロジェクトがどの基本プロセス定義にも合
致しなければ、そのプロジェクトに合致する基本プロセ
スを新たに定義し、追加することになる。したがって、
基本プロセス定義は、複数記述することができる。そし
て、新たな基本プロセス定義からプロセスを生成するこ
とになる。

【００４４】次いで、２はプロセス定義格納部であり、
上記プロセス定義部１で記述された基本的なプロセス定
義を格納する。３はＤＢ初期化部であり、ユーザによっ
て記述されプロセス定義格納部２に格納されたプロセス
定義を読み込み、オブジェクト指向に従ったフォーマッ
トに変換して、その結果を記述形式格納部４に格納す
る。ＤＢ初期化部３はまた、記述されたプロセス定義を
どのプロジェクトに対して使うか、言い換えると、ある
プロジェクトでどのプロセス定義を使うかを指定する指
定情報をプロジェクト情報格納部５に格納する。

【００４５】上記記述形式格納部４は、記述された基本
的なプロセス定義を１つあるいは複数格納するデータベ
ースである。また、上記プロジェクト情報格納部５は、
上記記述形式格納部４内のプロセス定義に基づいてカス
タマイズされる各プロジェクト毎のプロジェクト情報
（以下に述べる各種実行部によって順次生成される実際
のインスタンス）を格納するデータベースである。ただ
し、初期の段階では、実際のインスタンスではなく、上
述した指定情報のみが格納される。

【００４６】後述するように、本実施形態では、成果物
毎に順次バージョンアップされる各版を版・構成管理部
２３により管理しており、プロジェクト情報は各版毎に
プロジェクト情報格納部５に格納される。また、このプ
ロジェクト情報格納部５上では、あるプロジェクトで生
成するシステムが順次バージョンアップされていく場合
に、それぞれのバージョンに含まれる成果物の構造情報
だけでなく、それぞれのリリースがどの成果物のどの版
によって構成されるかまで表した構成情報が版・構成管
理部２３により管理されている。

【００４７】６は選択可能成果物一覧作成部であり、例
えば、ある成果物のある版の追加、削除、変更を行った
り、参照関係の追加や削除を行ったりするときに、その
とき選択可能な成果物の版として何が存在するかを示す
一覧を作成し、その結果を変更管理部１８を介してユー
ザ入力・選択部１７に供給する。ユーザ入力・選択部１
７は、キーボードやマウス等の入力デバイスと、ディス
プレイやプリンタ等の出力デバイスを備えており、上記
作成された一覧は、例えばディスプレイに表示される。

【００４８】一覧を作成するときには、記述形式格納部
４およびプロジェクト情報格納部５の両方の内容を参照
する。すなわち、例えばある階層の成果物のある版に対
して追加や変更がユーザによって指示されると、記述形
式格納部４内のプロセス定義を参照して、その階層の成
果物がどんな記述形式で書かれているか、更にその下の
階層にはどんな成果物が存在するか、さらには成果物間
の参照関係にはどんなものが存在するかを調べる。そし
て、この調べた結果に基づいて、既にプロジェクト情報
格納部５に格納されている成果物の各版の中で現在選択
可能なものを取り出して画面に一覧として表示する。

【００４９】図２（ａ）の例で、例えばユーザによって
「ソースコード」のある版の追加が指示されると、選択
可能成果物一覧作成部６は、そのソースコードの版と参
照関係にあり、しかもソースコードを生成するに当たっ
て前提として必要となる「仕様書」のある版をプロジェ
クト情報格納部５から取り出して一覧を作成する。この
とき、プロジェクト情報格納部５内に仕様書が未だ格納
されていなければ、一覧は表示されない。これによりユ
ーザは、ソースコードを生成する前提として必要な仕様
書が未だ作成されていないことを認識することができ
る。

【００５０】このように、本実施形態では、成果物、参
照関係の作成や編集を行うことができる作業に制限を設
け、その時点で使用可能な成果物のみをツール側で自動
的に探し出してきて、その中からユーザに選ばせるよう
にしている。これにより、ユーザが特に意識しなくて
も、常に正しい手順でソフトウェア開発を実施すること
ができるようになる。

【００５１】次いで、７は成果物追加実行部であり、ユ
ーザ入力・選択部１７から変更管理部１８を介して与え
られる指示に応じて新たな成果物の追加を実行する。こ
のとき、新たな成果物には、版・構成管理部２３によっ
て版番号が付される。また、８は自動生成実行部であ
り、上記成果物追加実行部７の実行時に、その成果物の
作成に必要な作業（タスク）等を自動生成する。すなわ
ち、ある成果物の生成のために行うべきタスクは記述形
式格納部４内のプロセス定義に記述されているので、こ
れを参照して、必要となるタスクを自動生成する。自動
生成実行部８は、タスク自身を自動生成するだけでな
く、どの成果物のためのタスクかという成果物との関係
や、成果物どうしの参照関係、タスクの実行順序も自動
生成する。

【００５２】この成果物追加実行部７および自動生成実
行部８での実行結果は、プロジェクト情報格納部５に格
納される。このプロジェクト情報格納部５に格納された
タスクは、後述する工程管理部１９で管理される。工程
管理部１９は、タスク情報等をユーザ入力・選択部１７
に供給し、その成果物を作るためにはどのような作業を
どのような順序で行うべきかをディスプレイ上にガント
チャートやスケジュール等の形式で表示したり、プリン
トアウトする。このようにすることで、開発者が行うべ
きタスクを確実に認識することができるようになる。

【００５３】９は成果物削除実行部であり、ユーザ入力
・選択部１７から変更管理部１８を介して与えられる指
示に応じて成果物の削除を実行する。また、１０は自動
削除実行部であり、上記成果物削除実行部９の実行時
に、記述形式格納部４内のプロセス定義を参照して、指
示に応じて削除した成果物より下位の階層にある成果物
で、関連のある成果物の版や参照関係にある成果物の版
を自動的に削除する。

【００５４】例えば、ある仕様書を削除する場合、その
仕様書から作られているソースコードやバイナリは、対
応する仕様書が削除された場合には残しておく必要がな
いのであれば、自動削除実行部１０によって上記仕様書
と共に自動的に削除される。あるいは、削除する仕様書
がユーザに提示され、ユーザからの確認後に削除され
る。この成果物削除実行部９および自動削除実行部１０
での実行結果も、プロジェクト情報格納部５に格納され
る。なお、成果物の削除は、変更管理部１８で管理する
データを削除するのであって、ファイル等の成果物の実
体を削除するものではない。

【００５５】このように、本実施形態では、あらかじめ
記述されたプロセス定義の内容に従って、削除が指示さ
れた成果物の版と関連のある成果物の版も自動的に削除
するようにしているので、ユーザによる間違った操作を
防ぐことができる。また、同時に削除すべき成果物の版
を削除し忘れてしまう不都合もなくすことができ、成果
物どうしの整合性を保証することが可能となる。

【００５６】１１は参照関係追加実行部であり、ユーザ
入力・選択部１７から変更管理部１８を介して与えられ
る指示に応じて成果物どうしの参照関係の追加を実行す
る。上述のように、成果物間の参照関係は、記述形式格
納部４内のプロセス定義の内容や、版・構成管理の内容
に従って自動生成実行部８により自動的に生成される
が、プロジェクトを進めていく上で、ある成果物の版間
に参照関係を明示的に引く必要が生じる場合がある。こ
の参照関係追加実行部１１は、ユーザが明示的に参照関
係を引きたい場合に使用する。

【００５７】この参照関係の追加を実行するときも、選
択可能成果物一覧作成部６による一覧表示が利用され
る。すなわち、ある成果物に対して参照関係を引けるの
はどの成果物であるかということが記述形式格納部４内
のプロセス定義にあらかじめ記述されており、また、成
果物の版構成がプロジェクト情報格納部５で管理されて
いるので、参照関係を引く一方の成果物とその版を指定
すると、対象となるもう一方の成果物とその版の一覧が
表示される。ユーザは、この一覧の中から任意の成果物
の版を選択することにより、参照関係を引く一対の成果
物とその版を指定することになる。

【００５８】１２は自動生成実行部であり、上記参照関
係追加実行部１１の実行時に、記述形式格納部４内のプ
ロセス定義を参照して、更に下位の階層の成果物との参
照関係を必要に応じて自動的に生成する。例えば、プロ
セス定義を参照して更に下位の階層の成果物を見た場合
に、指示に応じて参照関係を追加した成果物と対応する
成果物がある場合には、その成果物との参照関係を自動
生成する。この参照関係追加実行部１１および自動生成
実行部１２での実行結果も、プロジェクト情報格納部５
に格納される。

【００５９】１３は参照関係削除実行部であり、ユーザ
入力・選択部１７から変更管理部１８を介して与えられ
る指示に応じて成果物どうしの参照関係の削除を実行す
る。この参照関係削除実行部１３も、ユーザが明示的に
参照関係を削除したい場合に使用するものである。ま
た、１４は自動削除実行部であり、上記参照関係削除実
行部１３の実行時に、記述形式格納部４内のプロセス定
義を参照して、削除された参照関係と関連する参照関係
を全て自動的に削除する。あるいは、ユーザに提示し、
確認してから削除する。この参照関係削除実行部１３お
よび自動削除実行部１４での実行結果も、プロジェクト
情報格納部５に格納される。

【００６０】このように参照関係の自動生成実行部１２
と自動削除実行部１４とを設けることにより、成果物ど
うしの参照関係のメンテナンスに抜けがなくなるように
することができる。これにより、上述した成果物の追加
や削除、あるいは後述する成果物の変更を行ったときの
成果物どうしの整合性を常に正しく維持することが保証
される。

【００６１】１５は変更／チーム割り当て実行部であ
り、ユーザ入力・選択部１７から変更管理部１８を介し
て与えられる指示に応じて変更の割り当ておよびチーム
の割り当てを行う。ここで、変更の割り当てとは、要求
に応じて各種成果物の変更を実際に実施することを言
う。また、チームの割り当てとは、成果物の変更の作業
を誰（どのチーム）が実施するかを決定することを言
う。成果物の変更を行うときにはチームの割り当ても必
ず行う必要があるので、本実施形態では１つの実行部に
これらの機能を持たせた。

【００６２】すなわち、上記選択可能成果物一覧作成部
６によりどの成果物のどの版を変更可能かを一覧として
表示し、任意の成果物とその版をユーザに選ばせる。ユ
ーザが変更したい成果物の版を選択すると、変更／チー
ム割り当て実行部１５は、成果物の変更内容を解析し、
その変更によって影響を受ける他の成果物とその版の特
定を行う。さらに、記述形式格納部４内のプロセス定義
を参照して、その変更作業をどのチームに割り当てるか
の決定も行う。

【００６３】１６は自動生成実行部であり、上記変更／
チーム割り当て実行部１５により特定された内容に従っ
てプロジェクト情報を自動的に生成し、その結果をプロ
ジェクト情報格納部５に格納する。また、記述形式格納
部４内のプロセス定義やプロジェクト情報格納部５内の
版・構成管理情報を参照して、変更された成果物の版と
参照関係にある他の成果物の版を調べ、それを変更管理
部１８を介してユーザ入力・選択部１７に供給する。ユ
ーザ入力・選択部１７では、供給された成果物とその版
をディスプレイなどに表示することにより、関連して変
更すべき成果物をユーザに知らせる。これにより、１つ
の成果物の変更に伴って他の変更すべき成果物をユーザ
が見落としてしまうことがなくなる。

【００６４】上記変更管理部１８は、ソフトウェア開発
における各種成果物の追加や削除、あるいは成果物の変
更等を行う際に、ユーザ入力・選択部１７からの指示に
応じて上述した各ブロック６〜１６を制御するととも
に、各ブロック６〜１６からの情報をユーザ入力・選択
部１７を介してユーザに提示する処理を行う。

【００６５】また、上記工程管理部１９は、プロセス定
義に基づき上述の各実行部により生成された一連のタス
クの実行工程を管理する。図６は、この工程管理部１９
により管理される工程の画面表示例を示す図である。図
６において、白抜きのバー３１のそれぞれがタスクを示
している。各バー３１の横には、記述形式格納部４内の
プロセス定義に基づいて、そのタスクをどのチームが実
行するのかも併せて示している。また、タスク間に引か
れている矢印３２は、上記プロセス定義に記述されてい
る起動条件（trigger ）を示している。

【００６６】また、上記バー３１の中の帯状の線は、そ
のタスクの進捗を示している。すなわち、バー３１の中
に帯状の線が何も描かれていないタスクは「計画中」、
途中まで描かれているタスクは「実行中」、最後まで描
かれているタスクは「完了」であることを示す。工程管
理部１９は、それぞれのタスクが現在、計画中、実行
中、完了のどの段階に当たるのかを管理し、その結果を
プロジェクト情報格納部５に格納する。

【００６７】タスクが新たに登録された時点では、その
タスクには「計画中」のステータスが自動的に付けられ
る。その後、そのタスクに基づく作業を開始すると、
「実行中」のステータスに遷移させられる。そして、作
業が完全に終わった段階で「完了」のステータスが付け
られる。ステータスの切り替えは、入力される作業の実
績に応じて工程管理部１９が自動的に行っても良いし、
ユーザが明示的に指示することによって行っても良い。

【００６８】２０は障害管理部であり、一連のソフトウ
ェア開発の中で生成される各種成果物の障害を管理す
る。システム開発の際に発生するプログラム上のバグ
や、仕様書上の間違い等に関する障害は、原因調査、対
策、テスト等の各段階を経て最終的に除去される。障害
管理部２０は、発生した障害が登録されると、その登録
された障害が現在、原因調査中、対策中、テスト中等ど
の段階に当たるのかを管理し、各段階の作業などを確実
にフォローしていく。その際、障害管理部２０は、登録
された障害の件名、各段階で行った原因調査の内容やそ
の結果、対応策などのユーザから入力された情報をプロ
ジェクト情報格納部５に格納する。

【００６９】また、点線で示すブロック２１，２２はそ
れぞれ、上記変更管理部１８に対して設けられているブ
ロック６〜１４と同様の構成を備えるものであり、ここ
ではその詳細な構成については図示を省略している。た
だし、工程管理部１９に対するブロック２１内には、成
果物や成果物間の参照関係に関する追加や削除を行う構
成ではなく、タスクやタスク間の起動関係に関する追加
や削除を行う構成が備えられる。また、障害管理部２０
に対するブロック２２内には、成果物の障害や障害間の
参照関係に関する追加や削除を行う構成が備えられる。

【００７０】また、上記版・構成管理部２３は、成果物
毎に順次バージョンアップされる各版を成果物毎に管理
するとともに、各成果物のどの版を組み合わせてシステ
ム全体の版を構成するかを表す「成果物の構成」を管理
する。このある時間に作成を完了し、公開する計画がさ
れている個々の成果物の版と、その組み合わせで括られ
る一まとまりを「リリース」と呼ぶ。これに対して、シ
ステムがどの成果物の組み合わせから成るかを単に表し
たものを「成果物の構造」と呼ぶ。

【００７１】図７は、この版・構成管理部２３により管
理されるあるシステムのあるリリース、つまり各成果物
の版と、その組み合わせである成果物の構成の例を示す
図である。この例では、システム全体のリリース番号は
「alpha1.2.1」であり、このシステムは、図７のツリー
構造中でそれより下の階層に含まれる各成果物の版を含
んで構成される。図７において、「計画中」と示された
成果物は、先に説明した工程管理部１９で「計画中」と
示されたタスクと紐付いている。つまり、まだ成果物は
実体としてないが、将来は成果物として存在すべきもの
まで明示され、管理されている。

【００７２】２４はリリースノート作成部であり、生成
されたリリースに関するバージョンアップ情報等を作成
する。リリースノートに載せる情報としては、そのリリ
ースに含まれる成果物の構成とそのバージョン、前のバ
ージョンから変更された点や未対応の点、あるいは次バ
ージョンで対応予定の点に関する情報、障害に関する情
報などがある。これについての詳細は後述する。

【００７３】次に、上記のように構成した本実施形態の
情報管理装置の動作を、以下に簡単に説明する。本実施
形態の情報管理装置を使用する前提として、ユーザはま
ず最初に、プロセス定義部１により基本的なプロセス定
義を記述し、ＤＢ初期化部３を介して記述形式格納部４
に格納する。また、あるプロジェクトでどのプロセス定
義を使うかを指定する指定情報をプロジェクト情報格納
部５に格納する。

【００７４】このように、様々なプロジェクトに共通し
て利用可能なプロセス定義を記述形式格納部４に格納す
るとともに、プロジェクト情報格納部５にプロジェクト
情報の初期状態を設定することによって初めて、本実施
形態の情報管理装置を利用可能な状態となる。したがっ
て、ここまでの処理は、変更管理部１８、工程管理部１
９、障害管理部２０のそれぞれに対する各実行部６〜１
６，２１，２２の実行前にオフラインで実施することが
可能である。

【００７５】このようにして準備が完了すると、ユーザ
からの指示に応じて、上述した各実行部６〜１６，２
１，２２により具体的なプロジェクト情報の生成が順次
行われる。その際、自動実行を達成するための基本的な
関係は全て記述形式格納部４内のプロセス定義に記述さ
れており、各実行部はそのプロセス定義に記述されてい
る関係を解析して処理を行う。

【００７６】このとき、例えば、ある成果物の追加を行
うときには、成果物の作成に必要なタスクがその実行順
序等も含めて自動生成され、そのタスクを誰が行うべき
かも提示されるので、どのような作業をどのような順番
で誰が行うかをユーザ自身が判断する必要がなくなる。
また、ある成果物の追加、削除、変更を行ったり、参照
関係の追加、削除を行ったりするときは、そのとき選択
可能な成果物のみが一覧として表示されるので、ユーザ
が特に意識しなくても、常に正しい手順でソフトウェア
開発を実施することができ、必要な作業の抜けが生じた
り、適切でない順番で作業を行ってしまうことがなくな
る。

【００７７】また、ある成果物を削除すると、その削除
した成果物と関連のある成果物が自動的に削除されるの
で、同時に削除すべき成果物を消し忘れてしまう不都合
をなくすことができる。また、ある成果物の変更を実施
すると、その成果物と参照関係のある他の成果物が調べ
られ、それがディスプレイなどに表示されるので、１つ
の成果物の変更に伴って他の変更すべき成果物をユーザ
が見落としてしまうことがなくなる。これにより、成果
物どうしの整合性を正しく維持することができる。そし
て、このような成果物の整合性は、参照関係の自動生成
や自動削除機能によって、常に正しくなることが保証さ
れる。

【００７８】このようにして、それぞれの実行部６〜１
６，２１，２２での処理が行われる毎に、その処理結果
がプロジェクト情報格納部５に格納されていき、そのプ
ロジェクトに特有のプロセスが順次生成されていく。こ
のように、本実施形態では、それぞれの実行部６〜１
６，２１，２２での処理結果を全てプロジェクト情報格
納部５に格納することにより、プロジェクト情報を一元
的に管理することができる。

【００７９】また、成果物の追加、削除、変更等が行わ
れると、それに応じてバージョンアップされる各成果物
の版が版・構成管理部２３により管理されるとともに、
システム全体のリリースに含まれる成果物の構成も版・
構成管理部２３により管理される。また、成果物の追
加、削除、変更等を行った原因となった障害の管理が障
害管理部２０により実行され、それらの実行結果がプロ
ジェクト情報格納部５に格納される。さらに、このプロ
ジェクト情報格納部５に格納された情報に基づいて、リ
リースノート管理部２４によりリリースノートが自動的
に生成される。

【００８０】図８は、成果物に変更を割り当てる際にユ
ーザ入力・選択部１７によりユーザに提示される表示画
面の例を示す図である。図８の上欄に示すように、成果
物の変更を実行するときは、まず変更名、変更内容、変
更理由、障害ＩＤを入力する。ここに入力される内容
は、リリースノート作成部２４によるリリースノート作
成の際に利用される。なお、障害ＩＤの欄には、障害管
理部２０に登録された障害に起因して成果物の変更を行
うときに、その変更の原因となった障害の番号等を入力
する。一方、障害が原因ではなく、顧客からの要求に応
じて成果物の変更を行うときなどには、そのことを表す
チェックボックス４５をクリックする。

【００８１】また、図８の画面の下欄には、ユーザによ
り選択された所望のリリースに含まれる成果物の構成要
素が全て表示される。このとき、工程管理部１９により
管理されている、それぞれの成果物を生成するためのタ
スクが現在、計画中、実行中、完了のどの状態にあるの
かの情報もプロジェクト情報格納部５より得て、その情
報が各成果物名と共に表示される。

【００８２】さらに、それぞれの成果物名の横には、ど
の成果物に対して変更を行うかを選択するためのチェッ
クボックス４１が表示される。所望のチェックボックス
４１をマウス等の入力デバイスを用いてクリックするこ
とにより、所望の成果物を選択することが可能である。
図８の例では、共通ライブラリの「GRD alpha1.2.1」に
含まれる「ソースコード alpha1.2.1 」を変更する成果
物として選択した状態が示されている。

【００８３】所望の成果物に対するチェックボックス４
１をクリックすると、更にその横に現在の版で対応する
かどうかを選択するためのチェックボックス４２が表示
される。ただし、このチェックボックス４２が表示され
るのは、対応するタスクのステータスが計画中あるいは
実行中となっている成果物を選択したときのみであり、
ステータスが完了となっている成果物を選択したときに
は表示されない。これは、既に作業が完了してしまって
いる成果物に対しては更に変更を加えることはできない
ので、このような成果物が選択された場合には自動的に
次の版を作るようにするためである。

【００８４】計画中あるいは実行中の成果物が選択され
た場合において、その成果物の変更を行ってもバージョ
ンアップはせず、現在の版のままで対応する場合には、
上記チェックボックス４２をクリックすれば良い。一
方、変更後に成果物のバージョンを上げる場合は（例え
ば、alpha1.2.2とするなど）、このチェックボックス４
２はクリックせずにそのままの状態としておく。

【００８５】次に、ある成果物を選択した状態で、「変
更割り当ての計算」と書かれたボタン４４をクリックす
ると、図１の変更／チーム割り当て実行部１５は、記述
形式格納部４に格納されているプロセス定義の内容やプ
ロジェクト情報格納部５内容の版・構成管理情報を参照
して、選択されている成果物に関連のある他の成果物を
調べる。すなわち、選択されている成果物に関して“re
ference ”や“trigger ”で記述されている関連のある
他の成果物がないかどうかを調べる。

【００８６】そして、そのような成果物が存在する場合
には、そのことをユーザに知らせるためのマーク４３
（図８の例では“！”）を該当する成果物名の横に表示
する。ユーザは、この表示を見ることにより、１つの成
果物の変更に伴って他の変更すべき成果物の候補を確認
することができる。これにより、変更すべき他の成果物
をユーザが見落としてしまうことを防ぐことができる。
必要であれば、マーク４３が表示された成果物について
も変更を割り当てることになる。

【００８７】図９は、上記版・構成管理部２３により実
行される版および成果物の構成管理の例を示す図であ
る。ここでは、説明の簡略化のために、図９（ａ）に示
すように、あるリリース1.1.1 が３つの成果物Ａ，Ｂ，
Ｃ（版は皆1.1.1 ）より構成され、成果物Ａは成果物Ｂ
を参照し、成果物Ｂは成果物Ｃを参照する関係（成果物
Ｂは成果物Ａから参照され、成果物Ｃは成果物Ｂから参
照される関係）にあるものとする。

【００８８】この状態において、例えば、成果物Ｂを変
更してその版を1.1.2 に上げ、新しいリリース1.1.2 を
作ったとする。このとき版・構成管理部２３は、図９
（ｂ）に示すように、成果物Ｂが変更される前の版1.1.
1 に張られていた参照・被参照関係を見て、そこで参照
・被参照関係にあった成果物Ａの版1.1.1 および成果物
Ｃの版1.1.1 との間に相互参照を張り、それを新たなリ
リース1.1.2 とする。

【００８９】さらに、図９（ｂ）に示す状態において、
成果物Ａを変更してその版を1.1.2に上げ、その変更を
リリース1.1.2 に割り当てたとする。このとき版・構成
管理部２３は、図９（ｃ）に示すように、成果物Ａの版
1.1.1 と成果物Ｂの版1.1.2との間に張られていた参照
・被参照関係を、変更後の成果物Ａの版1.1.2 と成果物
Ｂの版1.1.2 との間の参照・被参照関係に切り替える。
つまり、ここでは、変更前の成果物Ａの版1.1.1 と参照
・被参照関係にあって、変更後のリリース1.1.2 に含ま
れるものがあるかどうかを調べ、あればそちらとの間で
関係を結ぶ。

【００９０】一方、上記図９（ｂ）に示す状態におい
て、成果物Ａを変更してその版を1.1.2 に上げ、図９
（ｄ）に示すようにその変更を新たなリリース1.1.3 に
割り当てたとする（例えば、その変更がリリース1.1.2
を出すまでに間に合わないような場合）。この場合は、
成果物Ａの版1.1.2 と成果物Ｃの版1.1.1 がリリース1.
1.3 に含まれるのは確実であるが、成果物Ｂに関して
は、版1.1.1 と版1.1.2 のどちらがリリース1.1.3 に含
まれるのかは、どのような流れで各リリースを生成して
いるのかによる。

【００９１】例えば、リリース1.1.1 →リリース1.1.2
→リリース1.1.3 のように各リリースをシーケンシャル
に生成しているような場合には、最新のものが常に正で
あるという考えに基づいて、成果物Ｂに関しては、最新
の版1.1.2 の方にリリース1.1.3 の参照・被参照関係を
張る。また、リリース1.1.1 をもとにリリース1.1.2と
リリース1.1.3 とを生成しているような場合には、リリ
ース1.1.3 を作る元となったリリース1.1.1 に含まれる
版1.1.1 の方にリリース1.1.3 の参照・被参照関係を張
る。成果物Ｂに関して何れの版に参照・被参照関係を張
るかは、版・構成管理部２３が自動的に判断して決めて
も良いし、ユーザが指定することによって決めても良
い。

【００９２】このように、本実施形態では、ある成果物
を変更してバージョンアップしたときに、版の概念も含
めて成果物間の依存関係が自動的に更新される。そのた
め、各成果物の各版どうしの整合性を常に正しく維持す
ることができる。これにより、例えば図８の画面で！マ
ーク４３を表示する際にも、選択された成果物の版と関
連のある成果物の版が常に正しく提示されるようにな
る。

【００９３】次に、各部の動作を以下に示すフローチャ
ートに従って詳しく説明する。図１０は、本実施形態の
情報管理装置を利用できるようにするまでの準備段階の
処理の流れ、つまりプロセス定義の記述からその登録ま
での流れを示すフローチャートである。

【００９４】図１０において、最初にステップＳ１でユ
ーザは、システムの立案を行う。システムの立案時に
は、開発手順も定めるので、図１のプロセス定義部１で
プロセス定義の記述形式ファイルを作成する。ここで
は、１つあるいは複数のプロセス定義を記述することが
可能である。ここで記述されたプロセス定義は、プロセ
ス定義格納部２を介してＤＢ初期化部３に与えられる。

【００９５】次のステップＳ２では、最初のプロジェク
ト登録か否か、すなわち、過去に本装置を使用して特定
の基本プロセス定義に則ったプロジェクト情報が生成さ
れておらず、今回が初めての登録か否かを判断し（これ
はユーザが明示的に指定しても良いし、ＤＢ初期化部３
が判断しても良い）、そうであればステップＳ３に進
み、そうでなければステップＳ４に進む。

【００９６】すなわち、特定の基本プロセス定義の最初
のプロジェクト登録の場合は、ステップＳ３で記述形式
格納部４を初期化した後、ステップＳ４に進む。一方、
最初のプロジェクト登録でない場合は、既に記述形式格
納部４は初期化されているので、ステップＳ３の処理は
行うことなくステップＳ４に進む。ステップＳ４では、
記述されたプロセス定義を専用のオブジェクト指向形式
に変換して記述形式格納部４に格納する。

【００９７】次に、ステップＳ５では、ソフトウェア開
発におけるプロジェクトに特有のプロセス（プロジェク
ト情報）を作成するための初期状態を設定する。ここで
は、対象とするプロジェクトに合わせてプロセス定義を
使ってプロジェクト情報を作成するための内部構造情報
を生成する。そして、ステップＳ６で、その生成した内
部構造情報をプロジェクト情報格納部５に格納する。

【００９８】図１１は、プロジェクト情報として新たな
成果物を追加する際の処理の流れの一例（システム登
録）を示すフローチャートである。図１１において、ス
テップＳ１１で、ユーザがユーザ入力・選択部１７を用
いて、例えば一番上の階層にある成果物である「システ
ム」の追加登録を行う旨を指示すると、成果物追加実行
部７は、ステップＳ１２で記述形式格納部４からプロセ
ス定義を読み込み、その内容に基づいて、ステップＳ１
３で上記システムに関して作成する成果物があるかどう
かを判断する。

【００９９】ここで、作成する成果物がない場合にはそ
のまま処理を終了するが、ある場合にはステップＳ１４
に進む。このステップＳ１４で自動生成実行部８は、上
記読み込んだプロセス定義に記述されている成果物名に
対応するタスクを１つ自動生成する。このとき、タスク
の生成は、プロセス定義に記述されている順番に従って
行われる。

【０１００】さらに、ステップＳ１５では、そのときタ
スクを生成した成果物に対して関連を引ける他の成果物
があるかどうかを、上記読み込んだプロセス定義に記述
されている成果物の参照関係（reference ）や起動条件
（trigger ）等を参照することによって判断する。そし
て、そのような成果物が存在する場合には、自動生成実
行部８は、ステップＳ１６で当該成果物への関連を引
く。

【０１０１】そして、ステップＳ１７で、上述のように
して自動生成したタスクや成果物間の関連（参照関係
等）を、成果物追加実行部７で作成した成果物と共にプ
ロジェクト情報としてプロジェクト情報格納部５に格納
する。その後、ステップＳ１３に戻り、作成する成果物
がまだ残っているかどうかを判断し、残っていればステ
ップＳ１４〜Ｓ１７の処理を同様に行う。このように、
プロセス定義として記述されている分だけ繰り返した
後、処理を終了する。

【０１０２】図１２は、プロジェクト情報として新たな
成果物を追加する際の処理の流れの他の例（サブシステ
ム登録）を示すフローチャートである。図１２におい
て、ステップＳ２１で、ユーザがユーザ入力・選択部１
７を用いて、例えば一番上の階層にある成果物である
「システム」を選択すると、成果物追加実行部７は、ス
テップＳ２２で記述形式格納部４からプロセス定義を読
み込み、その内容に基づいて、ステップＳ２３で上記シ
ステムの下の階層にサブシステムの成果物を登録可能か
どうかを判断する。

【０１０３】ここで、サブシステムの登録が可能でない
場合はそのまま処理を終了するが、登録可能な場合には
ステップＳ２４に進み、ユーザはサブシステム登録の指
示を行う。すると、成果物追加実行部７は、ステップＳ
２５で記述形式格納部４からそのサブシステムに関する
プロセス定義を読み込み、その内容に基づいて、ステッ
プＳ２６で上記サブシステムに関して作成する成果物が
あるかどうかを判断する。

【０１０４】そして、作成する成果物がない場合にはそ
のまま処理を終了するが、ある場合にはステップＳ２７
に進む。このステップＳ２７で自動生成実行部８は、上
記読み込んだサブシステムのプロセス定義に記述されて
いる成果物とその成果物に対応するタスクを１つ自動生
成する。このとき、タスクの生成は、プロセス定義に記
述されている順番に従って行われる。

【０１０５】さらに、ステップＳ２８では、そのときタ
スクを生成した成果物に対して関連を引ける他の成果物
があるかどうかを、上記読み込んだプロセス定義に記述
されている成果物の参照関係（reference ）や起動条件
（trigger ）等を参照することによって判断する。そし
て、そのような成果物が存在する場合には、自動生成実
行部８は、ステップＳ２９で当該成果物への関連を引
く。

【０１０６】そして、ステップＳ３０で、上述のように
して自動生成したタスクや成果物間の関連（参照関係
等）を、成果物追加実行部７で作成した成果物と共にプ
ロジェクト情報としてプロジェクト情報格納部５に格納
する。その後、ステップＳ２６に戻り、作成する成果物
がまだ残っているかどうかを判断し、残っていればステ
ップＳ２７〜Ｓ３０の処理を同様に行う。このように、
プロセス定義として記述されている分だけ繰り返した
後、処理を終了する。

【０１０７】図１３は、ユーザが明示的に参照関係を設
定する際の処理の流れを示すフローチャートである。図
１３において、ステップＳ３１でユーザが、参照関係を
引きたい成果物やタスク等のシステム構成要素を選択す
ると、選択可能成果物一覧作成部６は、ステップＳ３２
で記述形式格納部４からプロセス定義を読み込み、ステ
ップＳ３３で、その内容に基づいて、上記選択したシス
テム構成要素と参照関係を引くことが可能な他のシステ
ム構成要素があるかどうかを判断する。

【０１０８】参照可能なシステム構成要素がある場合
は、ステップＳ３４に進み、当該参照可能なシステム構
成要素に対応するプロジェクト情報をプロジェクト情報
格納部５から取り出してきて、候補の一覧を作成する。
この候補の作成は、参照可能なシステム構成要素がなく
なるまで繰り返し行われる。一方、参照可能なシステム
構成要素がない場合またはなくなった場合は、ステップ
Ｓ３５に進み、参照関係を引くための候補があるかどう
かを判断する。ここで、候補がない場合はそのまま処理
を終了するが、ある場合にはステップＳ３６に進む。

【０１０９】ステップＳ３６では、ユーザは、候補の一
覧の中から、上記ステップＳ３１で選択したシステム構
成要素と参照関係を結びたいシステム構成要素を選択す
る。すると、参照関係追加実行部１１は、当該選択した
システム構成要素の階層レベルで参照関係を作成する。
次に、ステップＳ３８で参照関係追加実行部１１は、記
述形式格納部４からプロセス定義を読み込み、ステップ
Ｓ３９で、上記参照関係を作成した階層より下の階層に
おいて関連を引ける成果物があるかどうかを判断する。

【０１１０】そのような成果物が存在する場合には、自
動生成実行部１２は、ステップＳ４０で当該成果物への
関連を引く。そして、ステップＳ４１で、上述のように
して生成した成果物間の参照関係をプロジェクト情報と
してプロジェクト情報格納部５に格納する。その後、ス
テップＳ３９に戻り、関連を引ける成果物がまだ残って
いるかどうかを判断し、残っていればステップＳ４０〜
Ｓ４１の処理を同様に行う。

【０１１１】図１４および図１５は、変更／チーム割り
当てを実行する際の処理の流れを示すフローチャートで
ある。図１４において、ステップＳ５１でユーザが変更
の割り当てを実行するリリースを選択すると、図８に示
した画面が表示される。ここで、ステップＳ５２でその
リリースの中から所望の成果物とその版をチェックボッ
クス４１のクリックにより選択すると、選択可能成果物
一覧作成部６は、ステップＳ５３でプロジェクト情報格
納部５に現在格納されているプロジェクト情報を読み込
むとともに、ステップＳ５４で記述形式格納部４からプ
ロセス定義を読み込む。

【０１１２】そして、ステップＳ５５で、変更割り当て
の計算ボタン４４が押されると、読み込んだプロセス定
義等に基づいて、上記選択された成果物と参照関係にあ
る成果物をチェックし、ステップＳ５６で上記チェック
した成果物とその版を！マーク４３によりディスプレイ
画面に表示する。このように、ある成果物のある版を変
更しようとするときは、プロセス定義の内容等に基づい
て、そのときのプロジェクトの状態に合わせて関連して
変更すべき成果物とその版をチェックし、それをユーザ
に知らせることにより、変更漏れを防いで常に正しい成
果物の関係を維持することができる。

【０１１３】次に、ステップＳ５７でユーザは、上記ス
テップＳ５６にて表示された！マーク４３をもとにどの
成果物のどの版を変更するかを選択する。上述したよう
に、基本的には参照関係のある一方の成果物が変更され
ると他方の成果物も変更する必要が生じるが（例えば、
仕様書を変更した場合には、それに対応してソースコー
ドも変更する必要が生じる）、微細な変更等のために関
連する成果物が影響を受けない場合もある。そのため、
関連して変更する成果物をユーザが選べるように構成し
ている。ここでは、１つあるいは複数の成果物を選択す
ることが可能である。

【０１１４】次に、ステップＳ５８で、上記ステップＳ
５７で選択された成果物の版に対応するタスクが完了以
外の開始状態にあるかどうか、すなわち、計画中または
実行中であるかどうかを判断する。ここで、選択された
成果物の版の変更処理が現在計画中または実行中の場合
はステップＳ５９に進む。ステップＳ５９でユーザは、
選択された成果物について、その変更後も変更前と同じ
版で対応するかどうかをチェックボックス４２のクリッ
クにより選択する。一方、選択された成果物の版につい
て変更処理が既に完了している場合は、必ず新しい版で
対応するため、ステップＳ５９の処理は行わずにステッ
プＳ６０にジャンプする。

【０１１５】上記ステップＳ５９で、ユーザが変更後の
成果物について版を更新しないことを選択した場合はス
テップＳ６７にジャンプし、版を更新することを選択し
た場合はステップＳ６０に進む。ステップＳ６０では、
成果物の変更に対応した新たなリリースを作成したかど
うかを判断し、作成していない場合はステップＳ６１で
新たなリリース（以下に述べる新しい版の成果物や参照
関係などの情報を格納する枠組み）を作成する。一方、
変更に対応した新たなリリースが作成済の場合は、上記
ステップＳ６１の処理は行わずにステップＳ６２に進
む。

【０１１６】ステップＳ６２では、上記ステップＳ５７
で選択された成果物の版の１つに対して変更を施すこと
によって、新しい成果物の版を作成する。次に、ステッ
プＳ６３で、上記変更に伴う版の更新によって新たに作
成すべき成果物があるかどうかを判断して、そのように
作成する成果物がある場合には、プロセス定義の内容に
従って、当該作成する成果物に対応するタスクを自動生
成する。

【０１１７】さらに、ステップＳ６４では、図１５を用
いて後述するように、新たに作成する成果物の版に対し
て、どのチームがその成果物を作成するのかの役割を設
定する。つまり、ある成果物の変更を実施した場合に
は、その変更に伴って新たな成果物が追加（複製）さ
れ、これに対応するタスクが自動的に生成される。この
ようにタスクが新たに生成されるので、それらのタスク
をどのチームが担当するかを決める必要が生じ、チーム
の割り当てが実行される。

【０１１８】そして、ステップＳ６５で版・構成管理部
２３は、更新される前の元の版の成果物について参照・
被参照関係が設定されている成果物の版をリストアップ
し、ステップＳ６６で、そのリストアップした成果物の
版と、新しい成果物の版との間に参照・被参照関係を張
る。すなわち、図９（ｂ）〜（ｄ）に示した何れの状態
に該当するかによって、成果物間に相互参照関係を構築
する。

【０１１９】上記ステップＳ５７で複数の成果物とその
版が選択されている場合、そのうちの最初の成果物につ
いて処理しているときは、図９（ｂ）のケースに該当す
ることが多い。この場合は、上記ステップＳ６５では、
成果物Ｂが更新される前の元の版に参照・被参照関係が
張られていた成果物Ａの版1.1.1 と成果物Ｃの版1.1.1
とをリストアップし、ステップＳ６６では、そのリスト
アップした成果物Ａ，Ｃの版1.1.1 と新しい成果物Ｂの
版1.1.2 との間に相互参照を張る。また、２番目以降の
成果物について処理しているときは、図９（ｃ）あるい
は（ｄ）のケースに該当することが多く、これらの場合
はそれぞれのケースに従って上述したように相互参照を
張る。

【０１２０】次に、ステップＳ６７で、上述のように変
更して作成した新たな成果物の版、新たなリリース、自
動生成したタスクや成果物間の参照関係、更には変更内
容や変更理由等の情報を、プロジェクト情報としてプロ
ジェクト情報格納部５に格納する。その後、ステップＳ
６８で、上記ステップＳ５７で選択された成果物の版を
全て処理したかどうを判断し、まだ残りがあればステッ
プＳ５８に戻り、同様の処理を繰り返す。

【０１２１】図１５は、上記図１４のステップＳ６４に
おけるチーム割り当て処理の流れを示すフローチャート
である。図１５において、ステップＳ７１で、上記図１
４のステップＳ６３で自動生成された複数のタスクの中
からユーザが任意のタスクを選択すると、図１の変更／
チーム割り当て実行部１５は、ステップＳ７２で、その
選択されたタスクに対応する成果物が持つ役割（プロセ
ス定義に記述されている上述した分析設計チーム、実装
チーム、品質保証チームなどの概念としてチーム名）を
記述形式格納部４内のプロセス定義から獲得する。

【０１２２】そして、ステップＳ７３で、上記獲得した
仮想上のチームと、プロジェクト上の実際のチーム（例
えば第１チーム、第２チームなどの具体的なチーム名）
とを照合し、選択されたタスクを担当すべき実際のチー
ムを把握する。次のステップＳ７４では、この照合結果
に基づいてチームの候補を作成し、例えばユーザ入力・
選択部１７に供給して画面表示する。

【０１２３】次のステップＳ７５でユーザは、表示され
た候補の中から任意のチームを選択する。これに対応し
て変更／チーム割り当て実行部１５は、ステップＳ７６
で、選択されたチームとタスクとを関係付け、その結果
を次のステップＳ７７でプロジェクト情報格納部５に格
納する。

【０１２４】以上が成果物の変更割り当てとチーム割り
当ての一連の処理内容であるが、チーム割り当ては、新
たなタスクが作られたときに必ず行われるものである。
したがって、図１５の処理は、図１１や図１２の処理に
よってタスクが追加された場合にも同様に実行される。

【０１２５】図１６は、リリースノート作成部２４によ
りリリースノートを作成する際の処理の流れを示すフロ
ーチャートである。図１６において、ステップＳ８１で
ユーザがリリースするバージョンを選択すると、ステッ
プＳ８２でリリースノート作成部２４は、その選択され
たリリースに対応したシステムの成果物構成のデータ
（そのリリースがどの成果物のどの版により構成される
かを表したデータ）をプロジェクト情報格納部５内から
取得する。

【０１２６】さらに、ステップＳ８３でリリースノート
作成部２４は、プロジェクト情報格納部５内から変更デ
ータを取得する。この変更データは、例えば図８の画面
から入力された変更内容や変更理由に関するデータ、変
更管理部１８を用いて実際に成果物の変更処理を行って
いる際に入力された顧客からの要求等に対する対応策の
データ、機能追加を説明したデータ等を含む。次に、ス
テップＳ８４では、変更に含まれる障害があるかどう
か、すなわち、何らかの障害に対応するために行われた
成果物の変更があるかどうかを判断する。

【０１２７】ここで、変更に含まれる障害がある場合
は、ステップＳ８５でその障害に関する障害データをプ
ロジェクト情報格納部５内から取得して、ステップＳ８
４に戻る。この障害データは、障害管理部２０を用いて
実際に障害対策を行っている際に入力される障害の件
名、障害に対する対応策のデータ等を含む。一方、変更
に含まれる障害がない場合は、ステップＳ８６に進み、
全ての変更を調査したかどうかを判断する。そして、未
調査の変更がある場合はステップＳ８３に戻り、その未
調査の変更に対して同様の処理を行う。

【０１２８】一方、全ての変更を調査した場合は、ステ
ップＳ８７に進み、現在選択しているリリースでは未対
応の変更や障害、つまり先のリリースで対応予定のもの
が登録されているかどうかを判断する。そして、現在の
リリースで未対応の変更や障害が登録されている場合
は、ステップＳ８８に進み、未来のリリースで対応予定
の仕様や不具合を記述したデータとして、上述の変更デ
ータおよび障害データをプロジェクト情報格納部５内か
ら取得する。そして、ステップＳ８９で、今までの各ス
テップの処理で取得した変更データおよび障害データを
リリースノートとして出力する。

【０１２９】このように、本実施形態では、成果物の変
更を行う際に入力される変更内容や変更理由、あるいは
障害対策を行う際に入力される障害対応策などのデータ
を保存しておき、それらのデータをそのまま出力する
（多少のフォーマット変換は行っても良い）ことによっ
てリリースノートを自動生成するようにしている。した
がって、リリースノートを始めから記述していく手間が
省け、しかも記述漏れを防ぐことができるというメリッ
トを有する。

【０１３０】なお、以上に説明した本実施形態の情報管
理装置は、コンピュータのＣＰＵあるいはＭＰＵ、ＲＡ
Ｍ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯ
Ｍに記憶されたプログラムが動作することによって実現
できる。したがって、コンピュータが上記機能を果たす
ように動作させるプログラムを、例えばＣＤ−ＲＯＭの
ような記録媒体に記録し、コンピュータに読み込ませる
ことによって実現できるものである。記録媒体として
は、ＣＤ−ＲＯＭ以外に、例えばフロッピーディスク、
ハードディスク、磁気テープ、光ディスク、光磁気ディ
スク、ＣＤ−Ｉ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ、ｚｉ
ｐ、不揮発性メモリカード等を用いることができる。

【０１３１】

【発明の効果】本発明は上述したように、システム開発
・保守を行う上で基本的なプロセスを定義するプロセス
定義手段と、プロジェクトに合わせて各種作業を実行
し、その際にプロセス定義の内容を解析して種々のプロ
ジェクト情報を生成して第２の記憶手段に格納する複数
の処理実行手段とを設け、１つのプロセス定義を複数の
処理実行手段で実際のプロジェクトに合わせてカスタマ
イズすることによってプロジェクト情報を生成するよう
にしたので、最初に基本的なプロセス定義を記述してお
けば、複数の処理実行手段によりそのプロセス定義の内
容に沿ってプロジェクト情報を正しい手順で順次生成し
ていくことができ、しかも生成したプロジェクト情報を
各成果物間の関連等も含めて１つの記憶手段にて一元的
に管理し、プロジェクト情報間に矛盾が生じないように
することができる。しかも、本発明によれば、様々なプ
ロジェクトに合わせた基本プロセスを定義することがで
きるので、本発明の情報管理装置が陳腐化することがな
い。

【０１３２】また、ある成果物を作成もしくは変更した
ときにその成果物に対応するタスクや当該成果物との関
連が定義されている成果物に対する参照関係等を自動的
に生成する手段や、ある成果物間の参照関係を作成ある
いは削除したときにそれに付随して作成あるいは削除す
べき成果物間の参照関係を自動的に作成あるいは削除す
る手段を設けたので、開発者は当該成果物を作成するた
めの作業や成果物間の関連等について特に意識しなくて
も正しい作業を行うことが可能となる。

【０１３３】また、ある成果物が削除されたときに当該
削除された成果物との関連が定義されている成果物を自
動的に削除する手段や、ある成果物が変更されたときに
当該変更された成果物との関連が定義されている成果物
を開発者に報知する手段を設けたので、付随して削除す
べき情報の消し忘れや付随して変更すべき情報の変更し
忘れがなくなり、プロジェクト情報間の正しい整合性を
維持することが可能となる。

【０１３４】また、ある成果物あるいは参照関係の作
成、変更もしくは削除が行われたときにその時点で選択
可能な成果物の一覧を作成する手段を設けたので、開発
者がある作業を実行しようとするときにその時点で有効
な成果物以外は選択できないようになり、開発者が特に
意識しなくても、常に正しい手順でソフトウェア開発を
実施することができるようになる。

【０１３５】また、複数の処理実行手段により生成され
るプロジェクト情報を、システムの版ごとおよび当該シ
ステムの各版を構成する各成果物の版ごとに管理するよ
うにしたので、成果物間の参照関係をシステムの版およ
び成果物の版ごとに適切に維持することができ、システ
ム開発・保守を行う際に版がバージョンアップされてい
くような場合にも対応することができる。

【０１３６】また、成果物あるいは参照関係の作成、変
更もしくは削除を行うときに、その対象となる成果物の
版と関連のある成果物の版の一覧を作成する手段を設け
たので、開発者は、付随して変更等を行うべき成果物の
版を容易に知ることができ、変更すべき成果物の版の変
更し忘れ等がなくなり、プロジェクト情報間の正しい整
合性を維持することが可能となる。

【０１３７】また、成果物の作成、変更もしくは削除が
行われたときに、それに対応してシステムの新しい版お
よびそれに含まれる各成果物の版の新しい構成を生成す
るようにしたので、開発者が特に意識しなくても、各成
果物の版の間で常に正しい参照関係等を維持することが
できる。

【０１３８】また、複数の処理実行手段による実行過程
で得られる変更データ、および障害管理手段による障害
管理の実行過程で得られる障害データを用いてリリース
ノートを自動生成するようにしたので、開発者がリリー
スノートを一から作成する手間を省くことができるとと
もに、必要な記述漏れを防ぐことができ、リリースノー
ト作成の効率および品質を向上させることができる。

【図面の簡単な説明】

【図１】本発明の一実施形態による情報管理装置の全体
構成を示す機能ブロック図である。

【図２】図１の記述形式格納部およびプロセス定義格納
部内の情報の例を概念的に示す図である。

【図３】プロセス記述の具体的な例を示す図である。

【図４】プロセス記述の具体的な例（図３の続き）を示
す図である。

【図５】プロセス記述の具体的な例（図４の続き）を示
す図である。

【図６】工程管理部により管理される工程の一例を示す
図である。

【図７】版・構成管理部により管理される各成果物の版
およびリリース内の成果物の構成の例を示す図である。

【図８】成果物に変更を割り当てる際にユーザに提示さ
れる表示画面の例を示す図である。

【図９】版・構成管理部により実行される版および成果
物の構成管理の例を示す図である。

【図１０】本実施形態の情報管理装置を利用できるよう
にするまでの準備段階の処理の流れ、つまりプロセス定
義の記述からその登録までの流れを示すフローチャート
である。

【図１１】プロジェクト情報として新たな成果物を追加
する際の処理の流れの一例（システム登録）を示すフロ
ーチャートである。

【図１２】プロジェクト情報として新たな成果物を追加
する際の処理の流れの他の例（サブシステム登録）を示
すフローチャートである。

【図１３】ユーザが明示的に参照関係を設定する際の処
理の流れを示すフローチャートである。

【図１４】成果物の変更およびチーム割り当てを実行す
る際の処理の流れを示すフローチャートである。

【図１５】チーム割り当てを実行する際の処理の流れを
示すフローチャートである。

【図１６】リリースノートを作成する際の処理の流れを
示すフローチャートである。

【符号の説明】

１プロセス定義部２プロセス定義格納部３ＤＢ初期化部４記述形式格納部５プロジェクト情報格納部６選択可能成果物一覧作成部７成果物追加実行部８自動生成実行部９成果物削除実行部１０自動削除実行部１１参照関係追加実行部１２自動生成実行部１３参照関係削除実行部１４自動削除実行部１５変更／チーム割り当て実行部１６自動生成実行部１７ユーザ入力・選択部１８変更管理部１９工程管理部２０障害管理部２３版・構成管理部２４リリースノート作成部

───────────────────────────────────────────────────── フロントページの続き (72)発明者北原直樹東京都千代田区大手町２−６−３新日本製鐵株式会社内 (72)発明者木方憲東京都千代田区大手町２−６−３新日本製鐵株式会社内Ｆターム(参考） 5B076 AB10 DD02 EC09

Claims

【特許請求の範囲】

【請求項１】システム開発・保守を行う上で必要な作
業を示すタスク名とその順序、各タスクにより生成され
る成果物名、各タスクを実行する作業者名、各成果物間
の関連、およびシステムの階層構造の各情報を含み、シ
ステム開発・保守の基本的なプロセスを定義するプロセ
ス定義手段と、上記プロセス定義手段により記述されたプロセス定義を
格納する第１の記憶手段と、上記システム開発・保守を実際に行うプロジェクトに合
わせて各種作業を実行し、その際に上記第１の記憶手段
に格納されているプロセス定義の内容を解析して種々の
プロジェクト情報を生成する複数の処理実行手段と、上記複数の処理実行手段により生成されたプロジェクト
情報を格納する第２の記憶手段とを備えたことを特徴と
する情報管理装置。
【請求項２】上記プロセス定義での各タスク名の記述
順序はタスクの実行順序と一致することを特徴とする請
求項１に記載の情報管理装置。
【請求項３】上記複数の処理実行手段は、ある成果物
を作成もしくは変更するときに、上記プロセス定義を参
照して、当該成果物に対応するタスクを自動的に生成す
る第１の自動生成手段を含むことを特徴とする請求項１
または２に記載の情報管理装置。
【請求項４】上記第１の自動生成手段は、上記プロセ
ス定義に記述されている順序に従ってタスクを生成する
ことを特徴とする請求項３に記載の情報管理装置。
【請求項５】上記第１の自動生成手段は、作成もしく
は変更した成果物との関連が上記プロセス定義に記述さ
れている成果物に対して参照関係を自動的に生成する手
段を更に含むことを特徴とする請求項３または４に記載
の情報管理装置。
【請求項６】上記複数の処理実行手段は、ある成果物
を削除するときに、上記プロセス定義を参照して、当該
削除した成果物との関連が定義されている成果物を自動
的に削除する第１の自動削除手段を含むことを特徴とす
る請求項１〜５の何れか１項に記載の情報管理装置。
【請求項７】上記複数の処理実行手段は、ある成果物
を変更するときに、上記プロセス定義を参照して、当該
変更した成果物との関連が定義されている成果物を報知
する報知手段を含むことを特徴とする請求項１〜６の何
れか１項に記載の情報管理装置。
【請求項８】上記複数の処理実行手段は、ある成果物
間の参照関係を作成するときに、上記プロセス定義を参
照して、当該作成した参照関係に付随して作成すべき成
果物間の参照関係を自動的に生成する第２の自動生成手
段を含むことを特徴とする請求項１〜７の何れか１項に
記載の情報管理装置。
【請求項９】上記複数の処理実行手段は、ある成果物
間の参照関係を削除するときに、上記プロセス定義を参
照して、当該削除した参照関係に付随して削除すべき成
果物間の参照関係を自動的に削除する第２の自動削除手
段を含むことを特徴とする請求項１〜８の何れか１項に
記載の情報管理装置。
【請求項１０】上記成果物あるいは参照関係の作成、
変更もしくは削除を行うときに、上記第１の記憶手段内
のプロセス定義と上記第２の記憶手段内に既に格納され
ているプロジェクト情報とを参照して、その時点で選択
可能な成果物の一覧を作成する一覧作成手段を備えるこ
とを特徴とする請求項１〜９の何れか１項に記載の情報
管理装置。
【請求項１１】上記複数の処理実行手段は、上記タス
クが生成されたときに、そのタスクを実行すべき作業者
を割り当てる処理を起動する作業者割り当て手段を含む
ことを特徴とする請求項１〜１０の何れか１項に記載の
情報管理装置。
【請求項１２】システムの開発・保守を行う際にバー
ジョンアップされる各成果物の版と、上記システムの版
および当該システムに含まれる成果物の構成とを管理す
る版・構成管理手段を備え、上記複数の処理実行手段に
より生成されるプロジェクト情報を、上記システムの版
ごと、および当該システムの各版を構成する各成果物の
版ごとに管理することを特徴とする請求項１に記載の情
報管理装置。
【請求項１３】上記成果物あるいは参照関係の作成、
変更もしくは削除を行うときに、上記第１の記憶手段内
のプロセス定義と上記第２の記憶手段内に既に格納され
ているプロジェクト情報とを参照して、上記作成、変更
もしくは削除を行う成果物の版と関連のある成果物の版
の一覧を作成する一覧作成手段を備えることを特徴とす
る請求項１２に記載の情報管理装置。
【請求項１４】上記成果物の変更を行うときに、変更
後の成果物を新たな版に更新するか現状の版で対応する
かをユーザに選択させる選択手段を備えることを特徴と
する請求項１２または１３に記載の情報管理装置。
【請求項１５】上記タスクの実行工程を管理し、各タ
スクが計画中、実行中、完了の何れの段階にあるのかを
管理する工程管理手段を備え、上記選択手段は、上記工程管理手段により管理されてい
るタスクの状態が計画中もしくは実行中のタスクに対応
する成果物についてのみ、上記変更後の成果物を新たな
版に更新するか現状の版で対応するかをユーザに選択さ
せるようにしたことを特徴とする請求項１４に記載の情
報管理装置。
【請求項１６】上記版・構成管理手段は、上記成果物
あるいは参照関係の作成、変更もしくは削除を行うとき
に、上記システムの新しい版およびそれに含まれる各成
果物の版の新しい構成を生成することを特徴とする請求
項１２〜１５の何れか１項に記載の情報管理装置。
【請求項１７】上記成果物の障害を管理する障害管理
手段と、上記複数の処理実行手段により上記成果物あるいは参照
関係の作成、変更もしくは削除を行うときに入力される
変更データ、および上記障害管理手段により障害管理を
行うときに入力される障害データを用いて、上記システ
ムの更新した版の内容を表すリリースノートを自動的に
生成する第３の自動生成手段とを備えたことを特徴とす
る請求項１２〜１６の何れか１項に記載の情報管理装
置。
【請求項１８】システム開発・保守を行う上で必要な
作業を示すタスク名とその順序、各タスクにより生成さ
れる成果物名、各タスクを実行する作業者名、各成果物
間の関連、およびシステムの階層構造の各情報を含み、
システム開発・保守の基本的なプロセスを定義するプロ
セス定義手段と、上記システム開発・保守を実際に行うプロジェクトに合
わせて各種作業を実行し、その際に上記プロセス定義手
段により記述されたプロセス定義の内容を解析して種々
のプロジェクト情報を生成し、それを記憶手段に格納す
る複数の処理実行手段としてコンピュータを機能させる
ためのプログラムを記録したことを特徴とするコンピュ
ータ読み取り可能な記録媒体。