JP2013105439A - 共有ソフトウェアのリポジトリ管理システム - Google Patents

Abstract

【課題】共有ソフトウェアの利用者側から複数の変更提案が来たとき、それらの統合案の作成、合議の支援、合議結果のソフトウェアへの反映の管理工数を削減する。
【解決手段】利用者側からの共有ソフトウェアへの変更提案を溜めておき、それらを同一の関数に対するものに分けて、それらが予め決められた制約（関数のパラメータを変えず、機能追加のみなど）を満たすならば、自動的に統合案を作成し、合議書を作成して、合議を促し、その結果に従って、共有ソフトウェアを更新して、利用者に配信する。
【選択図】 図１

Description

本発明は、共有ソフトウェアのリポジトリ管理システムに係り、特に、複数の開発部署に設けられたそれぞれのコンピュータ端末でソフトウェア開発のために共通に使用されているソフトウェア（共有ソフトウェア）を集中管理する、リポジトリ管理システムに関する。

本発明の共有ソフトウェアのリポジトリ管理システムは、各開発部署からのソフトウェアの更新提案を受け付け、一元的に管理する技術に関するものである。
複数の開発部署において、共有ソフトウェアを使用する場合、運用開始後の各部署の環境に応じてソフトウェアの更新の要求が生ずる。このような個々の更新要求に個別に対応すると共有ソフトウェアとしての意義が失われるので、共有ソフトウェアの利用者側から複数の変更提案があったときは、それらの統合の可能性を検討し、その結果をソフトウェアへ反映しながら一元的に管理することが必要となる。

特許文献１には、複数の作業者により開発された各プログラムモジュールをマージする技術が開示されている。すなわち、特許文献１の「ソフトウェア生成装置ならびにソフトウェア生成方法」は、複数の作業者が分担してソフトウェアの開発を行った場合、各作業者により開発された各プログラムモジュールをマージすることを容易にするため、それらのモジュールの整合性を判断する。特許文献１には、複数のモジュールに変更があったとき、それらが整合性を持つかどうかの判断方法が記載されている。すなわち、整合性の判断方法としては、「同階層のプログラムモジュールについて整合性を判断する」例が記載されており、また、整合性判断内容の例としては、「プロセスの入出力の一致」、「同じ変数が用いられているか」、「共通プロセスの下階層にあるプロセスの起動が記述されているか」かが挙げられている。

特開２００８−２３４３７９号公報

共有ソフトウェアを管理する部門では、複数の開発部署から整合性のない複数の変更、例えば、１つの関数などソフトウェアの同一項目に複数の変更が提案されたとき、それらの整合性の解消方法などを検討し、関連部署を呼んで、変更の合議を行い、確定させる必要がある。このため、共有ソフトウェアの管理工数がかかる。

複数の変更提案がお互いに整合性を満たさないとき、できるだけ少ない管理工数でそれらの不整合を解消するリポジトリ管理システムが求められる。さらに、共有ソフトウェアを管理する部門が、複数の開発部署からの変更提案に対して柔軟に対処できるリポジトリ管理システムが望ましい。

特許文献１に記載されたものは、複数の作業者が分担してソフトウェアの開発を行う場合において、複数のプログラムモジュール間に整合性がないと判断された場合、整合性がない旨を示す結果、バグ情報、バグ情報に該当するプロセス名などを含む整合性判断情報を表示部に表示し、作業者は、整合性判断情報を確認しながら、プログラムモジュール群の修正を編集画面上で行う。すなわち、個々の作業者が、整合性判断情報を確認しながら整合性があるようにプログラムモジュールを修正し、同階層のプログラムモジュール間のマージが行えるようにする。

特許文献１に開示された発明は、ソフトウェアの共同開発を対象としており、整合性の要件は限られた範囲のものである。特許文献１には、広範囲の変更の提案が整合性を満たさないときに、それらを効率良くかつ柔軟に解消するための共有ソフトウェアの管理方法は記載されていない。

本発明は、共有ソフトウェアの変更提案の要求に対して、整合性の解消を合理的かつ柔軟な手法で行い、管理部門の工数を大幅に削減することのできる、共有ソフトウェアのリポジトリ管理システムを提供することを目的としている。

上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、共有ソフトウェアを格納するデータベースとしてのソフトウェア資産管理リポジトリと、該データベースを管理する管理処理部とを備え、前記共有ソフトウェアを利用する複数の利用者端末とネットワークで接続される、共有ソフトウェアのリポジトリ管理システムであって、前記管理処理部は、前記利用者端末から前記共有ソフトウェアに関する複数の変更提案のデータを受け付け、前記複数の変更提案が、統合できる蓋然性の高い所定の制約を満たしているとき、統合変更案を作成し、該統合変更案による統合変更の可否判定の合議を関連部署に依頼する機能と、該合議の結果を受け取って前記共有ソフトウェアに適用する機能とを有することを特徴とする。

本発明によれば、複数の開発部署から同じ共有ソフトウェアに対する異なるが来た場合でも、整合性を合理的かつ柔軟な手法で解消した、共有ソフトウェアの変更統合案を自動作成する。そして、それを合議資料として配布し、合議の結果に従い、修正する。これにより、リポジトリ管理のための工数を大幅に削減することができる。

本発明の第１の実施例に係る、共有ソフトウェアのリポジトリ管理システムの全体の構成例を示す図。 第１の実施例による、共有ソフトウェアのリポジトリ管理の処理概要を示す図。 第１の実施例における、統合できる蓋然性の高い所定の「制約Ｐ」の例を示す図。 第１の実施例における、共有ソフトウェアのリポジトリ管理システムを実現するコンピュータシステムの例を示す図。 第１の実施例における、統合変更案作成部の処理フロー図。 第１の実施例における、共有プログラムに対する複数開発部署からの変更提案に基づく統合の例を示す図。 第１の実施例における、変更提案書の例を示す図。 第１の実施例における、変更提案書で指示される共有プログラムの変更部分を示す図。 第１の実施例における、変更の合議書の例を示す図。 第１の実施例における、ソフトウェア変更部の処理フロー図。 本発明の第２の実施例に係る、変更案統合機能を追加可能にした、共有ソフトウェアのリポジトリ管理システムの全体の構成例を示す図。 第２の実施例における、変更案統合機能を複数利用可能な変更案作成部の処理フロー図。 第２の実施例における、統合できる蓋然性の高い所定の「制約Ｑ」の共有プログラムの変更部分の例を示す図。 図１３の共有プログラムの変更に対応する、制約Ｑの変更提案書の例を示す図。 第２の実施例における、統合できる蓋然性の高い所定の「制約Ｒ」の共有プログラムの変更部分の例を示す図。 図１5の共有プログラムの変更に対応する、制約Ｒの変更提案書の例を示す図。 本発明の第３の実施例に係る、変更管理をカスタマイズ可能にした、共有ソフトウェアのリポジトリ管理システムの構成例を示す図。 第３の実施例における、共有ソフトウェア更新ルール実行部の処理フロー図。

本発明の代表的な実施例によれば、共有ソフトウェアのリポジトリ管理システムは、共有ソフトウェアを格納するデータベースを持ち、該データベースを管理する管理処理部と該データベースに格納されているソフトウェアを利用するための複数の端末とがネットワークで接続され、該管理処理部は、端末からの共有ソフトウェアの変更提案データを受け付ける変更受付部と、送られてきた変更提案データを蓄えておく変更提案ストックと、複数の変更提案から統合された変更提案を作成する統合変更案作成部と、作成された統合変更提案を関連部署に送りって部署間の合議を依頼する合議実行部と、合議結果を受け取ってその内容を共有ソフトウェアに適用する共有ソフトウェア変更部と、変更結果を利用者に配信するソフトウェア配信部からなり、該統合変更案作成部は、共有ソフトウェアの同一項目に対する変更を纏め、それらが全て予め決められた制約を満たす場合、統合変更案を作成して、該合議実行部に該当号変更案で合議実施を依頼するように指示し、その結果をソフトウェア変更部に送って共有ソフトウェアを変更させ、変更結果の共有ソフトウェアをソフトウェア配信部に指示し、利用している端末に配信する。

これにより、ソ複数の開発部署から同じ共有ソフトウェアに対する異なる変更提案が来た場合でも、それらの変更提案が、統合できる蓋然性の高い所定の「制約」を満たしているときは、自動的に共有ソフトウェアの変更統合案を作成する。そして、合議により、一部の付加情報の付加のみで変更提案の統合ができるか否かの良否判定を行う。このような合議結果に基づき、共有ソフトウェアの信頼性を確保しつつニーズに応じた柔軟な修正をすることができる。また、リポジトリ管理のための工数を大幅に削減することができる。

本発明の他の実施例の共有ソフトウェアのリポジトリ管理システムによれば、予め決められた制約を守った変更提案の統合方法が複数ある場合に、次々にそのような方法を登録して行く。これにより、整合性を満たす所定の「制約」について、タイプの異なる複数の「制約」を登録することで、より広い範囲の不整合を合理的な手法で柔軟に解決することができるようになる。

さらに、本発明の他の実施例の共有ソフトウェアのリポジトリ管理システムによれば、変更統合や合議のタイミングをルールで決めたり、また、条件によっては合議をしないで直接共有ソフトウェアを変更し、関連部署に配信するなど、多様な共有ソフトウェア管理を行う。すなわち、合議を開いたり、直接共有ソフトウェアを変更して通知したり、管理する部門の運用方法を変更することができるようにし、より柔軟な運用が可能となる。
以下、図面を用いて実施例を説明する。

本発明の第１の実施例の共有ソフトウェアのリポジトリ管理システムでは、予め決めた制約を満たす変更提案が複数の開発部署から送られてきたとき、類似した複数の変更提案が、統合できる蓋然性の高い所定の「制約」を満たしているとき、それらを統合した変更案を作成して、関連部署に合議を案内する。その合議結果により、共有ソフトウェアを更新する。

図１を使って、第１の実施例の構成を説明する。図１は、第１の実施例に係る、共有ソフトウェアのリポジトリ管理システムの構成例を示す図である。本実施例の共有ソフトウェアのリポジトリ管理システムは、まず、複数の利用者にソフトウェアを配信する基本的な構成として、共有ソフトウェアの管理を行う管理処理部1002と、複数の利用者側の端末1006 (1006a， 1006b， -， 1006n)がネットワーク1015で接続された形態になっている。また、管理処理部1002には、共有ソフトウェア1003(103a， 103b， -， 103n)を蓄積するソフトウェア資産管理リポジトリ1001がある。端末1006を使っている利用者は、管理処理部1002から共有ソフトウェア1003を配信してもらい、自分たちが開発する利用側ソフトウェアからそれらの共有ソフトウェア1003を呼び出すことにより、利用する。

本発明ではこの基本的な構成に加え、管理処理部1002が、利用者側からの変更提案1005を受け付ける変更提案受付部1007、受け取った変更提案(1005a， -， 1005n)を蓄積しておく変更提案ストック用データベース1004、蓄積された変更提案1005を纏めなおし、統合的な変更案を作成する統合変更案作成部1008、統合変更案作成部が作成した統合変更案を元に関連部署に合議を促し、結果を受け取る合議実行部1012、合議結果に従って共有ソフトウェア1003を実際に変更するソフトウェア変更部1013、その結果の共有ソフトウェアを利用者に配信するソフトウェア配信部1014からなる。管理処理部1002は、さらに、入出力装置の一部として、リポジトリ管理システムを管理する部門の担当者のための、GUI機能付き管理者用ディスプレイ1020も備えている。統合変更案作成部1008は、複数の変更を統合し合議を開催するために、類似した複数の変更提案を纏める変更提案纏め機能1009、類似した複数の変更提案を予め与えられたルールに従って１つに纏めるための統合変更案（若しくは統合変更検討案）の自動生成機能1010、及び、合議開催指示機能1011の3つの機能を備えている。なお、統合変更案には、複数の変更提案が類似しているものの所定のルールでは１つに統合する具体的な統合変更案を示せない場合にそれを合議の対象とする案件も含まれる。

次に、図２、図３により、本実施例による共有ソフトウェアのリポジトリ管理の処理の概要を説明する。

管理処理部1002は、利用者側からの変更提案1005を受け付け、変更提案ストック用データベース1004に蓄積する（S201）。利用者の端末から送られてくる変更提案1005には、変更されるファイル名称、それが予め決められた制約（ここでは「制約Ｐ」とする）を満たすのかどうか、変更される対象の関数、変更の内容3000（本例では追加）等が記述されている。

統合変更案作成部1008では、変更提案纏め機能1009により、所定期間、例えば1週間毎に、あるいは所定件数、例えば１０件乃至２０件毎に、同一項目に対する、換言すると類似した、複数の変更提案を纏める（S202）。すなわち、変更提案ストック1004にある変更提案を調べ、同じソフトウェアの項目（関数など）に対する変更どうしを纏める。次に、統合変更案の自動生成機能1010により、変更提案の全てが、統合できる蓋然性の高い所定の「制約」を満たす場合に、統合変更案を自動生成する（S202）。

変更提案を統合できる蓋然性が高い所定の「制約」の例として、関数のパラメータを変えず、新たな機能を追加するのみで、複数の変更提案を統合する場合がある。ここでは、この「制約」をより明確に定義した「制約Ｐ」300の例を、図３に示す。すなわち、「制約Ｐ」300に該当する例とは、次の条件（１）〜（５）を全て満たす場合である。

（１）関数のパラメータには変更がなく、
（２）第１パラメータは機能番号を表し、
（３）この変更では機能追加のみを行い、
（４）従来プログラムへのコード変更も追加のみ、
（５）変数への代入は予め決められた変数の集合、あるいは、追加した変数のみ。
なお、「制約Ｐ」の具体的な条件は、上記例に限定されるものでは無い。

統合変更案の自動生成機能1010は、それぞれの同じ項目に対する変更提案が上記制約Ｐを全て満たしているかを調べ、もし、満たしていれば、それらの変更提案を統合した統合変更案を作成する（S203）。
なお、複数の変更提案が上記「制約Ｐ」を全て満たしている場合に、これらを、合議無しに、リポジトリ管理システムで自動的に統合変更して１つの「共有ソフトウェア」を自動変更することも考えられる。しかし、予め決めた「制約Ｐ」による文言の定義の上では上記条件（１）〜（５）を満たしていても、この定義を、全ての状態を想定した完全なものにすることは困難であり、一部の事例については実態に合わない事態が発生する可能性がある。例えば、送られてきた追加機能の中には既にあるものと重複するものがあるかもしれない。あるいは、定義された文言上では類似しており統合可能に見える関数、文字列、顧客名等が、実際には明確に区別すべきものであったりすることも考えられる。すべて自動処理するとこれらの事態を排除できず、「共有ソフトウェア」の信頼性を低下させる要因となる。一方で、上記条件（１）〜（５）を満たす変更提案については、人間が若干の情報を与えるだけでより統合の可否の正確な判定が可能になり、「共有ソフトウェア」の信頼性を維持することができる。

これを実現するために、統合変更案作成部が作成した統合変更案を元に関連部署に合議を促し、一部の付加情報（合議）による、統合変更案の良否判定を行う（S204）。すなわち、合議実行部1012において、関連部署に合議をはかり、統合変更案の承認、あるいは、修正して承認することを依頼してもらう。合議の結果、例えば、似たコードや説明の機能を統合するかどうかが、付加情報として与えられる。

この合議実施の結果に基づき、ソフトウェア変更部1013がソフトウェア資産管理リポジトリ1001の共有ソフトウェア1003を変更する（S205）。この共有ソフトウェア1003の変更は、例えば、管理者が管理者用ディスプレイ1020のＧＵＩ機能を使用しながら実行する。そして、変更結果のソフトウェアを、ソフトウェア配信部1014から利用者端末に配信する（S206）。

上記「制約Ｐ」を採用することにより、共有ソフトウェアの全く自由な編集は制限されるが、複数の追加変更の間にほとんど干渉がない、信頼性の高いソフトウェア構造を、人から一部（若干）の付加情報を合議で得るのみで、換言するとほぼ自動的に、作ることが可能になる。また、合議の対象になるのは、変更提案を統合できる蓋然性が高い統合変更案のみに限られるので、合議に要する時間も短くて良く、共有ソフトウェアの統合変更処理を効率的に行うことができる。

図４は、本発明の装置を実現するコンピュータシステムの例である。本システムの構成要素である図１の管理処理部1002の各機能をコンピュータに実現させるためのプログラムを図４の補助記憶装置404に記憶しておき、またそれぞれの利用者の端末1006の情報をそれぞれ実行時に別のコンピュータシステムの記憶装置403に読み込み、それぞれのコンピュータのＣＰＵ402で実行し、キーボード、マウスなどの入力装置404やディスプレイ(1020)、スピーカなどの出力装置405を用いてソフトウェア部品のパラメータ設定やそのテスト結果の登録を行うことで本発明の装置を実現することができる。また、図１の構成や機能をコンピュータに実現させるためのプログラムを全て記憶装置403に読み込み、ネットワークに接続された形態ではなく、スタンドアローンの形態で利用者が1人だけの場合でも、従来の利用におけるテスト結果データを活用しながら部品の利用を行うことができる。また、別の実装の方法としては、図１の各部を直接ハードウェアで実現することもできる。

次に、図５を使って、統合変更案作成部1008の処理フローを詳細に説明する。まず、処理S5001で、変更提案ストックの中で同じ関数に対する変更提案を纏める(Proposal[1]，…，Proposal[N]とする。)。そして、処理S5002で、I＝1 to Nの間、処理S5003以下で各Proposal[I]に対して統合変更案を作成する処理を繰り返す。条件判定処理S5003で、Proposal[I]の変更提案は全て「制約P」に収まっているかを調べ、この条件が成立するときは、処理S5004以下の一連の処理で統合変更案作成を行なう。

まず、処理S5004で、全ての変更提案で追加される（機能名、説明、構文要素への操作列）を
(FN[j]， EXPLANATION[j]， MOD_SEQ[j])
とする。次に、処理S5005で、FN[j]に重複があれば、名前を変更して解消する。次に、処理S5006で、複数のFN[j]間のEXPLANATION[j]やMOD_SEQ[j]を比較して、文字列の一致度などで類似度が高いものがあれば、同一の機能の可能性があることを記録する。最後に、処理S5007で、変更統合の合議書を
・変更対象の関数の記述
・提案部署のリスト
・関連部署として、利用している部署と管理部門
・追加される機能名、説明、変更内容、類似しているもの
を作成し、合議実行部に依頼して合議を開く。判定処理S5003で条件が成立しないときには、処理S5008で、別の方法で合議する。別の合議の例としては、全ての変更提案を束ねて、関連部署に配り、対面の会議を行うなどである。

図６は、複数の開発部署での共有ソフトウェアを統合した例を示している。この例では、開発部署1からの変更提案1005aでは部分2001のように変更したいという提案が来ており、開発部署2からの変更提案1005bでは部分2002のように変更したいという提案が来ている。これらの変更は関数の型を変えていない。この例では、最初のパラメータfn にはこの関数で実行してもらいたい機能の番号が送られるとする。開発部署1からの変更提案1005aでは新しい機能の番号NEW_FN1とその実装「処理1」、開発部署2からの変更提案1005bでは「では同じく、新しい機能番号NEW_FN2とその実装「処理2」が追加されている。「処理1」と「処理2」の間に干渉がなければ、これらは、変更提案を統合できる蓋然性が高い所定の「制約」を満たす案件として、統合変更案作成部で統合変更案を作成し、この案を元に関連部署に合議を促し、一部の付加情報（合議）による、統合変更案の良否判定を行う。統合変更案が採用されると、新しい共有ソフトウェア1050のように２つの変更提案部分2003、2004を取り入れて、開発部署1と開発部署2の両方で利用できる共有ソフトウェアにすることができる。ここで、２つの実装の間に干渉がないというのは、例えば、
（１）２つの処理で同じ変数に対して代入していない場合
（２）結果を返すなどの予め許された変数に対しては両方で代入しているが、それ以外では同じ変数に代入していない
などである。

図６の例は、合議を省略しても良いようなごく簡単な例である。実際には、このように２つ以上の部署から別々の機能追加の提案が来たとしても、これらが別々の機能であるとは限らない。たまたま、複数の開発部署で同じ、あるいは、片方での変更がより一般的で、それをもう一方の開発部署が使うことができる場合もある。もともと、共有ソフトウェアを複数の開発で利用する目的は、開発量を減らすことなので、このような場合は１つに纏める必要がある。通常、このような機能仕様の決定のためには共有ソフトウェアの管理部署が関係者を集めて合議する必要があり、時間がかかる。本発明はこのような合議を効率化することも目的としており、合議の際の資料として、これらを纏めるかどうかの項目を有する統合変更案を生成する。

この統合変更案を生成について、図７〜図９を使って説明する。
図７は、本発明での変更提案1005の内容を説明する。変更内容3001には、共有ソフトウェアの構文項目（個別の宣言文、条件文、場合わけの分、繰り返し文）に対する編集操作が書かれている。この例では宣言文DEC001に “int x；”を追加し、場合わけ文 SWITCH001 にCMD05の場合の処理を追加することを表している。構文項目を識別するためのDEC001 やSWITCH001は最初に共有ソフトウェアを作成するとき、全ての文につけておいても良いし、あるいは、変更提案を出す開発部署がその場でつけて、ほかの開発部署がつけたものと指すものが一致するかどうか調べて、複数の開発部署からの変更が同じものにつけられているかどうか調べても良い。

図８は、この変更提案を施すことで変更された共有ソフトウェア1050の例を示している。部分4002がDEC001への追加操作として、部分4003がSWITCH001への追加操作の結果として変更されている。

図９は、複数の変更提案(1005a〜1005c)を纏め、合議に使う合議書5000の例を表している。合議書5000は、変更提案のタイトル、提案部署（変更提案を出してひとつに纏められた部署の集まり）、関連部署（その共有ソフトウェアを利用している部署の集まり）、予め決められた制約「制約Ｐ」内の変更であること、その制約の元に機能拡張として、部分5001に記述されているように、機能名 FNA1， FNA2， FNA3， FNB1， FNB2， FNB3， FNC1， FNC2が追加されている。これらの機能にはそれぞれの提案部署、説明、変更内容（具体的な共有ソフトウェアへの編集操作）が書かれている。また、さらに部分5002は、説明や変更内容が類似なため、同一な変更であったり、あるいはそのうちのいくつかは別の変更の部分として実現できる可能性があったりする部分である。この部分5002は、統合変更案作成部1008が複数の変更提案1005(1005a〜1005c)を処理することにより作り出す。また、合議の際は、これらの類似部分5003をどのように纏めるかをこの合議書の上で纏めて、ソフトウェア変更部1013に渡すことで、合議した内容を、即、共有ソフトウェア1003に反映することができる。ここで合議書の上で纏めるとは、例えば、類似部分5003に関して合議書のまま、全部別々でよければ、そのまま承認して、そのデータをソフトウェア変更部1013に渡し、あるいは、FNB2， FNB3 がFNB1と同一であることを合議すれば、FNB2， FNB3を消してしまい、あるいは、FNB1を拡張することでFNB2とFNB3がカバーできるなら、FNB2， FNB3を消して、FNB1の説明、変更内容を修正して、ソフトウェア変更部1013に渡せばよい。

次に、図１０を使って、ソフトウェア変更部1013の処理フローを詳細に説明する。処理S10001で、合議結果で合議された新機能について、処理S10002以下の一連の処理を繰り返し、変更を共有ソフトウェアに取り入れていく。まず、処理S10002で、その機能の構文要素への操作列を適用し共有ソフトウェアを更新する。そして、処理S10003で、ソフトウェア配信部に指示して、更新したソフトウェアを利用先に配信する。

本実施例によれば、変更提案が統合できる蓋然性の高い所定の「制約」を満たしているときは、自動的に共有ソフトウェアの変更統合案を作成する。そして、合議による一部の付加情報の付加のみで、変更提案の統合ができるか否かの良否判定を行う。このような合議結果に基づき、共有ソフトウェアの信頼性を確保しつつニーズに応じた柔軟な修正をすることができる。また、変更統合案を自動的に作成するので、リポジトリ管理のための工数を大幅に削減することができる。さらに、合議の対象になるのは、変更提案を統合できる蓋然性が高い統合変更案のみであり、この点でも、リポジトリ管理を効率的に行うことができる。

次に、本発明の実施例２に係る共有ソフトウェアのリポジトリ管理システムついて述べる。実施例２は、複数の変更提案を統合できる蓋然性の高い所定の「制約」として、実施例１で述べた「制約Ｐ」のような、予め決められた制約を守った変更提案の統合方法が複数ある場合に、次々にそのような方法を登録して行くことができる共有ソフトウェアのリポジトリ管理システムである。

実施例１で述べた「制約Ｐ」以外に、複数の変更提案を統合できる蓋然性が高い「制約」の例としては、例えば、以下の制約Ｑ、制約Ｒのようなものがある。

制約Ｑ：
・制約Ｐにおいて、関数のパラメータには決まったデータ型のパラメータの追加が許される。

制約Ｑのときの統合変更案作成方法：
・追加されたパラメータの型や説明が類似している場合には、それらを１つにできないか合議を図る資料を生成する。

制約Ｒ：
・元の関数から呼び出している関数を、より性能のよい関数に置き換える範囲内の変更である。

制約Ｒのときの統合案作成方法：
・複数の部署から同じ関数を異なる関数に置き換える提案があった場合は、合議資料を生成しどのように変更するかを決める。そうでなく、全ての置換えが矛盾なく実行できる場合は全て採用する。

また、共有ソフトウェア関連部署内で取り決めを行うことにより、複数の案の統合方法と合議事項を決めることができる場合がある。本実施例では、このような場合に共有ソフトウェアのリポジトリ管理システムにそれらの統合方法を組み込む実施例を説明する。

図１1は、複数の予め決められた制約が複数ある場合の共有ソフトウェアのリポジトリ管理システムの構成図である。この図１1では、図１のシステムに対して統合方式データベース1060が追加されている。統合方式データベース1060には、制約番号1， 2， …， nとそのときの変更提案の集合を統合する複数の方法(制約)Q，R，-Zの組6000が登録されている。統合変更案作成部1008は、複数の変更を統合し合議を開催するために、同一項目に対する変更提案纏め機能1082、変更提案での制約に共通な統合方式の検索機能1083、登録されている統合方法の実行機能1084、及び、合議開催指示機能(図示略)の各機能を備えている。統合変更案作成部1008の統合方式の検索機能1083はこのデータベース1060を検索することで、同じ関数に対する複数の部署からの変更提案1005が同じ制約番号を守っている場合は、それらの変更提案を纏める方法を取り出し、統合方法の実行機能1084により、取り出された方法(制約)に従って統合変更案を作成し、合議開催指示機能による合議などを行う。利用者の端末から送られてくる変更提案1005には、変更されるファイル名称、それが予め決められた制約（ここでは「制約Ｐ」とする）を満たすのかどうか、変更される対象の関数、変更の内容3002（本例では追加）等が記述されている。

図１2を使って、変更案統合機能を複数利用可能な変更案作成部1008の処理フローを詳細に説明する。まず、処理S11001で、変更提案ストックの中で同じ関数に対する変更提案を纏める(Proposal[1]，…， Proposal[N]とする)。そして、処理S11002で、I＝1 to Nの間、処理S11003を繰り返す。条件判定処理S11003で、Proposal[I]の変更提案が全て同じ制約番号noの制約に収まっているかを調べ、この条件が成立するときは、処理S11004以下の一連の処理を行ない、Proposal[I]ごとの統合変更案を作成する。まず、処理S11004で、統合方式データベースから制約番号noの統合方法を検索し、それをIntegrateMethodsとする。ここで、IntegrateMethods は統合変更案を作成するための手続きの列であるそして、処理S11005で、ここで作成した統合変更案で合議実行部に依頼して合議を行う。判定処理S11003で条件が成立しないときには、処理S11006で、別の方法で合議する。

次に、上記統合方式データベース1060に登録・保持される予め決められた制約Ｑの具体的な例を図１３で説明する。図１３の共有ソフトウェア1051では、図８の共有ソフトウェア1050に加え、関数 f のパラメータに4004の char＊arg2 の部分が追加されている。ここでは、制約Ｐにおいて決まったデータ型として文字列 char ＊ が定められているとして、記述している。

図１３の制約Ｑを満たす変更提案書1005の例を、図１４に示す。ここでは、「追加されたパラメータの型や説明が類似している場合には、それらを１つにできないか合議を図る資料を生成する。」という統合変更案作成方法に基づき、説明文の中に新たなパラメータ4004が追加されることが示され、また変更内容3003の１行目に関数 FUNC001に引数が追加するという内容が書かれている。

さらに、上記統合方式データベース1060に登録・保持される予め決められた制約Ｒの具体的な例を図１5で説明する。図１5の共有ソフトウェア1052では、制約Ｒを満たすパラメータ4010，4011，4012の変更の例を表している。すなわち、「元の関数から呼び出している関数を、より性能のよい関数に置き換える範囲内の変更」である。

図１5の制約Ｒを満たす変更提案書1005の例を、図１6に示す。こでは説明文の中に、速度の問題から呼んでいる関数を高速なものに置き換えるという説明があり、変更内容3004の１行目に２行目にそれぞれ、関数ComputeXCoordinate()と ComputeYCoordinate()を置き換えることが指示されている。統合案作成方法に基づき、「複数の部署から同じ関数が異なる関数に置き換える提案があった場合は、合議資料を生成し」どのように変更するかを決める。このとき、複数の部署からの変更提案において、速度の問題で置き換える関数に重複がなければ、全ての置換えが矛盾なく実行できるので、それら全てを置き換えればよいが、例えば、部署1と部署2から同じ関数 ComputeXCoordinate()を、部署1ではFastComputeXCoordinate()に、部署2ではQuickComputeXCoordinate()に置き換えることを提案された場合は、どちらを採用するか合議が必要である。

このように、本実施例では、整合性を満たす所定の「制約」について、Ｐ，Ｑ，Ｒ，…のようにタイプの異なる複数の「制約」を統合方式データベース1060に登録し、これらを変更提案の作成、統合変更案の作成、及び合議実行、ひいては共有ソフトウェアの変更に利用することで、ソフトウェアの信頼性を確保しつつ、より広い範囲の不整合を柔軟に解決することができるようになる。

実施例３では、実施例１や実施例２をベースにして、さらに、変更統合や合議のタイミングをルールで決めたり、また、条件によっては合議をしないで直接共有ソフトウェアを変更し、関連部署に配信するなど、より柔軟な共有ソフトウェア管理を行うことができる、共有ソフトウェアのリポジトリ管理システムの例を説明する。

図１７を使ってこの場合の実施例３の構成を説明する。本実施例では、図１に対して管理処理部1002に共有ソフトウェア更新ルールデータベース1070と共有ソフトウェア更新ルール実行部7003とが追加されている。共有ソフトウェア更新ルールデータベース1070は条件部と統合方法の組の集合（ルール）7000を保持している。本実施例では変更提案を統合するタイミングもルールで決定できるように時間を計り、通知するタイマー7002も追加してある。共有ソフトウェア更新ルール実行部7003は、変更提案受付部1007やタイマー7002から変更提案受信や一定の時間経過などのイベントを受け取り、それにより起動され、共有ソフトウェア更新ルールデータベース1070のルール（7000）を調べ、共有ソフトウェアの更新を次に示すように実施する。

変更ストック1004に蓄積されている変更提案1005の数や内容、共有ソフトウェア1003を利用している部署の数によっては、合議を行うかどうか、あるいは合議を行う範囲などを柔軟に決めたいことがある。

例えば、変更内容としてインタフェース変更を含まず、性能を悪化させない変更で、統合変更案が１つなら、合議を行わず変更を実施して、その通知のみ利用者の端末に送ればよい場合もある。

また、利用している部署が多く、かつ、変更提案が少数でかつ、それらを自動的に統合できない場合は、共有としていたものをコピーして、それら少数の変更提案元の関数として別に配布してしまう場合も考えられる。

本実施例の共有ソフトウェアのリポジトリ管理システムでは、これらの変更提案に関する統合を管理部門が柔軟に行うため、共有ソフトウェア更新ルール7000を設定することで運用を柔軟に行うことができる。

上記の運用例はルールとして書けば以下のようになる。
If 項目 f に対する変更提案の集合をProposalsとする、かつ
Proposalsの個数が１つである、かつ
Proposalsの変更提案はインタフェースを変更しない、かつ
Proposalsの変更提案は性能の悪化がないと記載されている。
Then
Proposals の変更提案を実施する。
変更された共有ソフトウェアの利用者の端末に通知する。

上記の２つ目の例は以下のように記述される。
If 項目 f に対する変更提案の集合をProposalsとする、かつ
F の利用者数 > 10、かつ
Proposalsの変更提案を統合する方法がない。
Then
f をコピーしてProposals の変更提案を実施する。

図１８を使って、共有ソフトウェア更新ルール実行部7003の処理フローを詳細に説明する。本手続きは時間経過、変更提案受信などのイベントごとに呼び出される。まず、処理Ｓ12001で、管理処理部1002が受信したイベントをEとする。そして、処理Ｓ12002で、共有ソフト更新ルール7000が動かなくなるまでの間、処理Ｓ12003を繰り返す。処理Ｓ12003で、全てのルールRについて、処理Ｓ12004を繰り返す。条件判定処理Ｓ12004で、ルールRの条件部がイベントEに関連し、かつ、成立するかを調べ、この条件が成立するときは、処理Ｓ12005で、ルールRの帰結部を実行する。

本実施例によれば、共有ソフトウェア更新ルール実行部7003の機能により、合議を開いたり、直接共有ソフトウェアを変更して通知したり、管理する部門の運用方法を変更することができるようにし、より柔軟で効率の良い運用が可能な共有ソフトウェアのリポジトリ管理システムを提供できる。

1001 ソフトウェア資産リポジトリ
1002 管理処理部
1003 共有ソフトウェア
1004 変更提案ストック用データベース
1005 利用者からの共有ソフトウェアへの変更提案
1006 利用者の端末
1007 変更提案受付部
1008 統合変更案作成部
1012 合議実行部
1013 ソフトウェア変更部
1014 ソフトウェア配信部
1015 ネットワーク
1050 共有ソフトウェア
3000 変更の内容
4002 部分
5001 変更の合議書の例。

Claims (15)

1. 共有ソフトウェアを格納するデータベースとしてのソフトウェア資産管理リポジトリと、
   該データベースを管理する管理処理部とを備え、
   前記共有ソフトウェアを利用する複数の利用者端末とネットワークで接続される、共有ソフトウェアのリポジトリ管理システムであって、
   前記管理処理部は、
   前記利用者端末から前記共有ソフトウェアに関する複数の変更提案のデータを受け付け、
   前記複数の変更提案が、統合できる蓋然性の高い所定の制約を満たしているとき、統合変更案を作成し、該統合変更案による統合変更の可否判定の合議を関連部署に依頼する機能と、
   該合議の結果を受け取って前記共有ソフトウェアに適用する機能とを有する
   ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
2. 請求項１において、
   前記統合できる蓋然性の高い所定の制約とは、該所定の制約と一部の付加情報のみで、前記複数の変更提案から前記統合変更案を自動生成できるものであり、
   該一部の付加情報は前記合議において与えられるものである
   ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
3. 請求項２において、
   前記所定の制約を全て満たすとは、次の条件（１）〜（５）を全て満たす場合である
   （１）関数のパラメータには変更がなく、
   （２）第1パラメータは機能番号を表し、
   （３）この変更では機能追加のみを行い、
   （４）従来プログラムへのコード変更も追加のみ、
   （５）変数への代入は予め決められた変数の集合、あるいは、追加した変数のみ
   ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
4. 請求項３において、
   前記所定の制約とは、前記複数の変更提案が前記条件（１）〜（５）を満たし、かつ、前記関数のパラメータには決まったデータ型のパラメータの追加が許されるものである
   ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
5. 請求項３において、
   前記管理処理部は、
   前記複数の変更提案が複数の類似する機能を含む場合に、前記複数の類似する機能を拡張した機能で前記複数の類似する機能を統合する案を生成する
   ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
6. 請求項４において、
   前記管理処理部は、
   追加された前記パラメータの型や説明が類似している場合に、それらを１つにできないか前記合議を図る資料を生成する
   ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
7. 請求項２において、
   前記統合できる蓋然性の高い所定の制約とは、前記複数の変更提案が、元の関数から呼び出している関数を、より性能のよい関数に置き換える範囲内の変更である
   ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
8. 請求項７において、
   前記管理処理部は、
   前記複数の部署から同じ関数が異なる関数に置き換える提案があった場合は、どのように変更するかを決める合議資料を生成し、全ての置換えが矛盾なく実行できる場合は全て採用する合議資料を生成する
   ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
9. 請求項２において、
   前記利用者端末から受け付ける前記変更提案のデータには、変更されるファイル名称、それが前記予め決められた制約を満たすのかどうか、変更される対象の関数、及び、変更の内容が記述されている
   ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
10. 請求項２において、
    前記管理処理部は、
    前記端末からの前記共有ソフトウェアの変更提案データを受け付ける変更受付部と、
    送られてきた前記変更提案データを蓄えておく変更提案ストック用データベースと、
    前記複数の変更提案データから統合変更提案を作成する統合変更案作成部と、
    作成された前記統合変更提案を前記関連部署の端末に送りって、該関連部署間の合議を依頼する合議実行部と、
    前記関連部署間の合議結果を受け取って変更結果として前記共有ソフトウェアに適用する共有ソフトウェア変更部と、
    前記変更結果を前記利用者に配信するソフトウェア配信部とからなり、
    前記統合変更案作成部は、前記変更提案データから前記共有ソフトウェアの同一項目に対する変更を纏め、それらが全て前記予め決められた制約を満たす場合、前記統合変更案を作成して、前記合議実行部に該統合変更案で前記合議の実施を依頼するように指示し、その結果を前記ソフトウェア変更部に送って前記共有ソフトウェアを変更させ、該変更されたソフトウェアを前記ソフトウェア配信部に指示し、前記利用者の各端末に配信する
    ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
11. 共有ソフトウェアを格納するデータベースとしてのソフトウェア資産管理リポジトリと、
    制約番号と統合方式の対の集まりからなる統合方式データベースと、
    更提案データを蓄えておく変更提案ストック用データベースと、
    管理処理部とを備え、
    前記共有ソフトウェアを利用する複数の利用者端末とネットワークで接続される、共有ソフトウェアのリポジトリ管理システムであって、
    前記管理処理部は、
    前記利用者端末から前記共有ソフトウェアに関する複数の変更提案データを受け付ける機能と、
    同一項目に対する前記変更提案が、予め決められた制約を満たすか調べる際に、それらの変更提案が前記統合方式データベースの同一の制約番号を満たすかを調べる機能と、
    前記複数の変更提案が、統合できる蓋然性の高い所定の制約を満たしているとき、前記制約番号に登録されている統合方式を実行することにより作成された統合変更案による統合変更の可否判定の合議を関連部署に依頼する機能と、
    該合議の結果を受け取って前記共有ソフトウェアに適用する機能とを備える
    ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
12. 請求項１１において、
    前記統合できる蓋然性の高い所定の制約とは、該所定の制約と一部の付加情報のみで、前記複数の変更提案から前記統合変更案を自動生成できるものであり、
    該一部の付加情報は前記合議において与えられるものである
    ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
13. 請求項１２において、
    前記利用者の端末から送られてくる前記変更提案データには、変更されるファイル名称、それが予め決められた前記制約を満たすのかどうか、変更される対象の関数、変更の内容が記述されている
    ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
14. 共有ソフトウェアを格納するデータベースとしてのソフトウェア資産管理リポジトリと、共有ソフトウェア更新ルールデータベースと、
    変更提案データを蓄えておく変更提案ストック用データベースと、
    管理処理部とを備え、
    前記共有ソフトウェアを利用する複数の利用者端末とネットワークで接続される、共有ソフトウェアのリポジトリ管理システムであって、
    前記共有ソフトウェア更新ルールデータベースは、前記変更提案ストックの統合や変更の前記共有ソフトウェアへの適用を行う条件を記述した条件部と、その方法を記述した統合方法の組からなるルールを格納しており、
    前記管理処理部は、
    時間や変更提案データを受け付けたイベントにより、前記共有ソフトウェア更新ルールデータベースのルールを実行する機能と、
    前記複数の変更提案が、統合できる蓋然性の高い所定の制約を満たしているとき、前記ルールを実行することで、統合変更案を作成し、該統合変更案による統合変更の可否判定の合議を関連部署に依頼する機能と、
    該合議の結果を受け取って前記共有ソフトウェアに適用する機能とを有する
    ことを特徴とする共有ソフトウェアのリポジトリ管理システム。
15. 請求項１４において、
    前記統合できる蓋然性の高い所定の制約とは、該所定の制約と一部の付加情報のみで、前記複数の変更提案から前記統合変更案を自動生成できるものであり、
    該一部の付加情報は前記合議において与えられるものである
    ことを特徴とする共有ソフトウェアのリポジトリ管理システム。

Images