JP4883700B2

JP4883700B2 - レポジトリサーバ管理システム

Info

Publication number: JP4883700B2
Application number: JP2007066762A
Authority: JP
Inventors: 剛川尻; 嘉之河村
Original assignee: Hitachi Solutions Ltd
Current assignee: Hitachi Solutions Ltd
Priority date: 2007-03-15
Filing date: 2007-03-15
Publication date: 2012-02-22
Anticipated expiration: 2027-03-15
Also published as: JP2008226122A

Description

本発明は、アプリケーション開発におけるレポジトリサーバの管理に関するものであり、特にレポジトリの更新の可否を、投票と開発者の過去の実績に従って決定するシステムに関するものである。

近年、アプリケーションの規模の拡大に伴い、多数の開発者が関わるアプリケーションの開発が増えてきている。このような開発プロジェクトにおいては、開発者間で開発状況を共有するために、レポジトリサーバと呼ばれる保管場所でソースコードを管理することが一般的になってきた。
レポジトリサーバを利用した開発システムにおいては、更新された内容がアプリケーション全体に影響して深刻な不具合を引き起こすことが良くある。そこで、ソースコードをレポジトリに格納する前に、更新した内容をチーム内で精読し、問題点を洗い出して修正することがよく行われている。このような精読作業はソースコードレビューと呼ばれている。

図２１は、レポジトリサーバを利用した開発システムの構成を示す図であり、本システムは開発ＰＣ２１０１と、課題データベース２１０２と、スケジュールデータベース２１０３と、レポジトリサーバ２１０４から構成されており、開発ＰＣ２１０１と、課題データベース２１０２、スケジュールデータベース２１０３、レポジトリサーバ２１０４はネットワークで接続されている。

開発ＰＣ２１０１にはソースコードを記述するアプリケーションと、レポジトリサーバ２１０４のクライアントアプリケーションが搭載されており、それらを操作するためのマウス２１０５とキーボード２１０６が設けられている。
課題データベース２１０２には、アプリケーションの開発中に発覚した不具合や、要望の内容が格納されている。
スケジュールデータベース２１０３は、開発者ごとに予定の開始時刻や終了時刻が格納されている。
レポジトリサーバ２１０４は、開発者が登録したソースコードが格納されており、ファイルごとに更新履歴を記憶する手段を備えている。

このような開発システムにおいては、開発者は課題データベース２１０２の内容（課題や要望）に従って開発ＰＣ２１０１でソースコードを記述し、スケジュールデータベース２１０３に登録された開発プロジェクト内の開発者のスケジュールを調整した上でソースコードレビューを実施する。
ソースコードレビューで妥当であると承認された場合はクライアントアプリケーションで更新内容をレポジトリサーバ２１０４に反映する。
このように、レポジトリサーバ２１０４にソースコードの更新内容を反映させることを、一般にコミットと呼ぶ。
コミット後にソースコードに不具合が発覚した場合は、その内容を課題データベース２１０２に登録した上で、レポジトリサーバ２１０４から対象のソースコードを取得し、修正を加えて再度コミットする。
本発明に関連する公知技術文献としては下記特許文献１があげられる。

特開２００６−１８７３５号

ソースコードレビューはアプリケーションの品質を高める点で有力であるが、多くの場合、会議形式で実施するので各開発者のスケジュールを調整した上で実施する必要があった。
これは、開発者ごとにスケジュールの空きを予約した上で、その時間に更新する内容の妥当性に対して投票を実施し、その投票結果に従ってレポジトリサーバに反映させるかどうか決定するシステムを構築することで解決できる。
しかし、開発の規模が大きくなると、ソースコードの量が膨大となるため、全ての開発者の更新内容を確認することは現実的ではない。多くの開発の現場では効率的にソースコードレビューを実施するために、不具合の発生率といった開発者の過去の実績からソースコードレビューを実施するか決定しているので、同様に過去の実績に基づいて投票を実施することが望ましい。
また、ソースコードレビューに必要となる時間は開発者ごとに異なるので、一律に同じ時間を割り当てるのは非効率と言える。過去の遅延時間に基づいて投票時間を決定することが望ましい。

本発明の目的は、コミットした開発者の過去の実績を基にコミットの可否を判定し、不可の場合は、過去の投票の遅延時間から投票時間を算出し、その投票結果に従って、レポジトリサーバに反映させるかを決定することにより効率的にソースコードレビューを実施することができるレポジトリサーバ管理システムを提供することにある。

上記目的を達成するために、本発明のレポジトリサーバ管理システムは、開発プロジェクトに属する複数の開発者が各自の開発者用コンピュータを使用してそれぞれ開発したプログラムをレポジトリサーバに保管するのを管理するシステムであって、
開発者用コンピュータからのプログラム保管申請を受け、そのプログラム保管申請を送付した開発者について過去の実績を含めた評価値を第１のデータベースから取得し、保管申請を受けたプログラムを前記レポジトリサーバに保管するか否かを前記評価値に基づいて判定し、前記評価値が予め設定された設定値を満たしていない場合には保管申請されたプログラムを第２のデータベースに退避格納し、設定値を満たしていた場合には前記レポジトリサーバに保管する第１の手段と、
前記第２のデータベースに退避格納したプログラムについて同一開発プロジェクトに属する他の開発者の承認投票により前記レポジトリサーバに保管するか否かを決定するために各開発者のスケジュールを第３のデータベースから取得し、各開発者が承認投票を行うためのスケジュールを決定し、各開発者に通知する第２の手段と、
各開発者の開発者用コンピュータから前記第２のデータベースに退避格納したプログラムについてレポジトリサーバに保管するか否かを記述した承認可否通知を受け付けて集計し、承認率が予め設定された設定値を満たしていた場合には前記退避格納したプログラムを前記レポジトリサーバに保管し、設定値を満たしていなかった場合に前記退避格納したプログラムを破棄する第３の手段と
を備えることを特徴とする。

本発明のレポジトリサーバ管理システムによれば、次のような効果がある。
ソースコードレビューを、開発者の過去の実績に基づいて実施でき、アプリケーションの品質を上げることができる。また、開発者の時間を有効活用することができるなど、効率的にソースコードレビューを実施することができる。

以下、本発明を適用したレポジトリサーバ管理システムの一実施の形態について説明する。
図１は、本発明の実施の形態の一例を示すレポジトリサーバ管理システムのシステム構成図である。
本実施形態のシステムは、共通システム１０１と、ｎ個の開発システム１０２から構成されており、共通システム１０１と、開発システム１０２はネットワークによって接続されている。
なお、ｎ個の開発システムを例示しているが、１つの場合であっても適用可能である。
共通システム１０１は、開発プロジェクト間で共有する情報を管理するものであり、開発プロジェクトの定義情報を保持するプロジェクトデータベース１０３と、開発者ごとに、参加した開発プロジェクトの履歴や評価、実績を格納する開発者データベース１０４と、開発者のスケジュールを格納するスケジュールデータベース１０５が設けられている。
プロジェクトデータベース１０３及び開発者データベース１０４には、プロジェクト履歴を更新するプロジェクト入力部１０６が設けられている。
スケジュールデータベース１０５には、スケジュールを更新するスケジュール入力部１０７が設けられている。プロジェクト入力部１０６及びスケジュール入力部１０７の内容は、Ｗｅｂサーバ１０８によってブラウザに表示される。開発者はブラウザでＷｅｂサーバ１０８にアクセスすることで、共通システム１０１が管理する情報を更新する。

開発システム１０２は、開発プロジェクトごとに設けられるものであり、ソースコードを記述する環境である開発ＰＣ１０９と、開発者を評価して投票を実施する投票システム１１０と、作成したソースコードを格納するレポジトリサーバ１１１から構成される。
開発ＰＣ１０９は、投票システム１１０を経由してレポジトリサーバ１１１にネットワークで接続されている。
開発ＰＣ１０９は、開発者ごとに設けられるものであり、ソースコードを編集するアプリケーションと、レポジトリサーバ１１１のクライアントアプリケーションが備わっている。また、それらを操作するためのマウス１１２とキーボード１１３が設けられている。レポジトリサーバのクライアントアプリケーションは、ソースコードの取得やコミットといった、レポジトリサーバ１１１を操作するための基本的な機能が備わっている。
通常、クライアントアプリケーションの接続先はレポジトリサーバ１１１に設定するが、本システムでは投票システム１１０に設定する。以降では、投票システム１１０に対するコミットを特に、コミット申請と呼び、投票システム１１０がレポジトリ１１１を更新することをコミットと呼ぶ。なお、クライアントアプリケーションの動作については公知であるので説明を省略する。

投票システム１１０は、投票システム１１０の設定情報を保持するシステム設定データベース１１４と、コミット申請した開発者の評価を取得して、レポジトリサーバ１１１に反映させるか判断するコミット可否判定部１１５と、コミット申請された内容を保留する保留データベース１１６と、保留された内容に対して投票結果を格納する投票データベース１１７と、開発者ごとに投票予定日時を決定してスケジュールを予約するスケジュール調整部１１８と、決定した投票予定日と保留内容を、メールで投票者に伝達するメールサーバ１１９と、投票者から投票を受け付ける投票入力部１２０が設けられている。また、開発者から要望や不具合を受け付ける課題入力部１２１と、入力された内容を記憶する課題データベース１２２が設けられている。

ここで要望とは、開発するアプリケーションが実装する必要がある個々の機能を指し、要望を全て満たすとアプリケーションは完成となる。また、不具合とはプログラムの実装ミスといった問題点を指す。以降では要望と不具合をあわせて課題と呼ぶ。
また、投票システム１１０は、投票入力部１１９と課題入力部１２０の内容をブラウザに表示するＷｅｂサーバ１２３が設けられている。また、コミット可否判定部１１５の判定結果と、課題データベース１２２と、投票データベース１１７の内容を基に、開発者の評価を算出して開発者データベース１０４に格納する評価格納部１２４が設けられている。

コミット可否判定部１１５は、開発者の評価を、プロジェクトデータベース１０３と開発者データベース１０４から取得して、コミット申請された内容をレポジトリサーバ１１１に反映させるか判定する。
本システムにおいて、評価は不具合の発生といった項目ごとに重要度に応じて数値で表現され、評価の合計を統合評価と呼ぶ。統合評価は、経過日数や開発プロジェクトの経験実績も考慮されて算出される。統合評価がシステム設定データベース１１４に格納されている閾値に満たない場合、コミット可否判定部１１５は、コミット申請された内容を保留データベースに退避する。保留された内容は、投票によって承認された場合にレポジトリサーバ１１１に反映される。しかし、投票によって却下となった場合、保留された内容は破棄される。また、統合評価が閾値より高い場合は投票を実施せず、即時にレポジトリサーバに反映する。
なお、コミット可否判定部１１５は、クライアントアプリケーションのソースコードの取得や、更新履歴の取得といったコミット申請以外の要求をレポジトリサーバ１１１に伝え、結果を返す手段を備える。

スケジュール調整部１１８は、投票データベース１１７に記録された、過去の投票における遅延時間を基に、開発者ごとに投票時間を算出し、スケジュールデータベース１０５に記録された開発者の空き時間に投票予定日時を予約する。
ここで、遅延時間とは、予約した投票予定日時に対して開発者が実際に投票するまでの遅れ時間のことである。
レポジトリサーバ１１１は、登録されたソースコードごとに変更履歴を管理し、クライアントアプリケーションの指示に従ってソースコードを更新したり、ある時点でのソースコードの内容を開発者ＰＣ１０９に送信したりする。なお、レポジトリサーバ１１１の内部動作については公知であるので説明を省略する。

図２は、プロジェクトデータベース１０３のデータ構造を示す図であり、プロジェクトデータベース１０３は、プロジェクトを一意に特定するプロジェクトＩＤ２０１と、プロジェクト名を指定するプロジェクト名２０２と、プロジェクトの特徴を指定する属性２０３から構成される。
プロジェクトＩＤ２０１は開発プロジェクト間で重複しない値がプロジェクト入力部１０６によって設定される。また、プロジェクト名２０２は、開発者が入力した、プロジェクトを解かりやすく区別する名前が格納される。属性２０３は、開発プロジェクトのキーワードを指定するものであり、一つのプロジェクトにつき任意のものを複数指定することができる。属性２０３の内容は、統合評価の算出に使用される。

図３は、開発者データベース１０４のデータ構造を示す図であり、開発者データベース１０４は、開発者を一意に特定する開発者ＩＤ３０１と、プロジェクト履歴３０２から構成される。開発者ＩＤは、開発者ごとに重複しない値が設定されている。プロジェクト履歴は、開発者ＩＤ３０１で指定された開発者が、これまでに参加してきたプロジェクトと、その評価の記録であり、プロジェクトＩＤ３０３と、参加日３０４と、終了日３０５と、種別３０６と、評価３０７から構成される。
プロジェクトＩＤ３０３には図２のプロジェクトＩＤ２０１で定義されたものが入力される。参加日３０４と終了日３０５は、それぞれプロジェクトに参加した日と終了した日が格納されるものであり、現在参加中のプロジェクトには終了日が入力されない。
種別３０６と評価３０７は、評価格納部１２４が格納するものであり、参加したプロジェクトにおいて評価が算出するたびに格納される。
評価種別３０６は評価の種類を表し、要望が満たされたことを示す要望解決と、不具合を修正したことを示す不具合解決と、投票の結果コミット申請が承認されたことを示す申請承認と、申請が却下されたことを示す申請却下と、投票を行ったことを示す投票の５種類がある。評価３０７は評価種別に応じて評価格納部１２１が算出した評価の値であり、その値はシステム設定データベース１１４の設定値に応じて変動する。

図４は、スケジュールデータベース１０５のデータ構造を示す図であり、スケジュールデータベース１０５は、開発者ＩＤ４０１と、スケジュール４０２から構成される。
開発者ＩＤ４０１は、図３の開発者ＩＤ３０１で定義されたものが格納される。
スケジュールは開発者ごとに複数登録され、開始日時４０３と、終了日時４０４と、内容４０５から構成される。これらの内容は開発者がスケジュール入力部１０７から入力したり、スケジュール調整部１１８が入力したりして格納される。

図５は、システム設定データベース１１４のデータ構造を示す図であり、システム設定データベース１１４は、設定の名称である設定名５０１と、設定される値を示す設定値５０２と、該当する設定値を示す範囲５０２から構成される。
設定名には１２の種類があり、統合評価閾値はコミット可否判定部１１５がコミット申請した開発者に対して投票が必要かどうか判定する統合評価の閾値である。
平均閲覧時間は行単位を単位とした閲覧に必要な平均時間である。
承認率閾値は、投票結果において、レポジトリサーバ１１１に反映させるかどうか判定する、承認率の閾値である。
プロジェクト経過補正値は統合評価の算出において過去の開発プロジェクトにおける評価を経過日数に応じて変化させるための補正値であり、経過日数に応じて変化する。
遅延評価値は、投票に対する評価値であり、遅延日数に応じて変化する。
承認評価値は承認された開発者に対して与える評価の値である。
却下評価値は却下された開発者に対して与える評価の値である。
重要度評価値は、課題を解決した場合に与える評価値であり、重要度に応じて変化する。
遅延補正値は、課題を解決した場合に与える評価値の補正値であり、課題解決の遅延時間に応じて変化する。
不具合解決補正値は、解決した課題が不具合であった場合に与える評価の補正値である。
要望解決補正値は、解決した課題が要望であった場合に与える評価の補正値である。
不具合発生補正値は、不具合を発生させた場合に与える評価の補正値である。

図６は、保留データベース１１６のデータ構造を示す図であり、保留データベース１１６は、保留された内容をプロジェクト内で一意に特定する保留ＩＤ６０１と、コミット申請された日時を格納する申請日時６０２と、コミット申請した開発者を示す申請者６０３と、コミット申請時に指定されたコメントを格納するコメント６０４と、更新ファイルの名前を示すファイル名６０５と、更新対象となるリビジョンを示す６０６と、更新された箇所と内容を示す更新内容６０７から構成される。
保留ＩＤ６０１は、コミット可否判定部１１５が投票を必要と判断した場合に開発プロジェクト内で一意となるものが割り当てられる。
更新日時６０２は、開発ＰＣ１０９のクライアントアプリケーションがコミット申請した時の日時が格納される。
ファイル名６０５は、コミット申請されたファイルの一覧であり、一度のコミット申請で複数のソースコードがクライアントアプリケーションによって指定される。
対象リビジョン６０６は、修正の対象となるリビジョンを指し、クライアントアプリケーションによって指定される。ここでリビジョンとは、レポジトリサーバがファイルごとに割り当てる編集履歴の識別子であり、開発者はソースコードごとにリビジョンを指定して、目的とする時点の内容を取得する。
更新内容６０７は、対象リビジョン６０５の内容と、コミット申請された内容の行単位の差分であり、この内容はクライアントアプリケーションが算出して送信する。
なお、６０２から６０７の内容は、一般のレポジトリサーバ１１１を利用した開発において、クライアントアプリケーションがレポジトリサーバ１１１に送信する内容と同一であり、投票結果が承認となった場合はそのままレポジトリサーバ１１１に反映される。

図７は、投票データベース１１７のデータ構造を示すものであり、投票データベース１１７は、保留ＩＤ７０１と、標準投票時間７０２と、投票結果７０３から構成される。
保留ＩＤ７０１は、図６の６０１で定義されたものであり、投票対象となるコミット申請を指す。
標準投票時間７０２は、各開発者に与える投票時間の基準となる時間であり、この時間に投票遅延時間の平均を開発者ごとに加えたものを投票時間とする。標準投票時間７０２は、６０７で定義された更新内容の量に応じて変化する。
投票結果７０３は、コミット申請された内容に対して個々の開発者が投票した結果であり、投票した開発者を示す投票者７０４と、投票予定日時を示す投票予定日時７０５と、実際に投票された日時を示す投票実施日時７０６と、投票された結果を示す可否７０７と、投票時に指定された指摘事項を示す指摘事項７０８から構成される。
投票者ＩＤは、図３の３０１で定義された開発者ＩＤが格納され、開発プロジェクト中のコミット申請した開発者以外の開発者が格納される。投票者の一覧は、図６の６０３で述べた申請者と、開発者データベース１０４に記憶された開発者３０１と、進行中のプロジェクトのＩＤ３０３から取得できる。なお、進行中のプロジェクトは終了予定日３０５が格納されているかどうかで判定できる。
投票予定日時７０５は、標準投票時間７０２を基にスケジュール調整部１１８が算出した結果が格納される。
投票実施日時７０６は、投票入力部１２０によって実際に投票された日時が格納される。
可否７０３は投票者が指定するものであり、承認と却下の２種類が格納される。
指摘事項７０８は、可否７０３において却下を選択した場合に投票者が入力するものである。

図８は、課題データベース１２２のデータ構造を示す図である。
課題データベース１２２は、開発プロジェクト内で一意に課題を特定する課題ＩＤ８０１と、課題の内容を示す内容８０２と、課題が不具合か要望かを区別する種別８０３と、課題の進捗状態を示す状態８０４と、課題の完了予定日時を示す完了予定日時８０５と、課題の重要度を示す重要度８０６と、不具合を発生した開発者を示す発生者８０７と、課題の解決に割り当てられた開発者を示す対応者８０８と、課題が解決した日時を示す完了日時８０９から構成される。
課題ＩＤ８０１には、開発プロジェクト内で一意となるものが課題入力部１２１によって設定される。
内容８０２は、課題の説明が任意に入力される。
種別８０３は、入力された課題が要望か不具合か選択するものであり、評価の算出などに使用される。
状態８０４は、３つの種類があり、課題が発生した直後の状態を示す調査中と、対応者を割り当てたことを示す割り当て済みと、課題が解決したことを示すクローズのいずれかの値をとる。
なお、全ての課題の状態は、調査中から割り当て済みを経て、クローズに遷移する。
完了予定日時８０５と重要度８０６は、課題の困難さと対応者の能力に応じて入力するものであり、状態８０４が調査中である場合は入力されない。発生者８０７は、調査で判明した不具合の発生者を入力する項目であり、状態８０４を割り当て済みに更新する時に入力する。
なお、種別８０３が要望である場合、発生者８０７は入力されない。
対応者８０８は、課題に対応する開発者を入力するものであり、状態８０４を割り当て済みに更新するときに入力する。なお、発生者８０７と対応者８０８の情報は評価の算出で使用される。完了日時８０９は、状態をクローズに更新した日時を課題入力部が格納する。完了予定日時８０５と完了日時８０９の差は評価の算出に使用される。

図９は、プロジェクト入力部１０６が表示するプロジェクト管理画面の一例であり、プロジェクト管理画面は、プロジェクトの新規登録欄９０１と、プロジェクトへの参入欄９０２から構成され、プロジェクトの新規登録欄９０１は、プロジェクト名の入力欄９０３と、属性の入力欄９０４と、新規作成ボタン９０５を備える。
また、プロジェクトへの参入欄９０２は、プロジェクトＩＤの入力欄９０６と、開発者ＩＤの入力欄９０７と、参加ボタン９０８と、離脱ボタン９０９を備える。
開発者はブラウザでＷｅｂサーバ１０８にアクセスすることで、これらの情報を入力する。そして、プロジェクト名９０３と属性９０４を入力した上で新規作成ボタンを押すとプロジェクト名の入力欄９０３の内容がプロジェクト名２０２に格納され、属性の入力欄９０４の内容が属性２０３に格納される。なお、属性は複数指定することができる。
また、プロジェクトＩＤ９０６と、開発者ＩＤ９０７を入力した上で参加ボタン９０８を押すと、指定された内容と開発者ＩＤ３０１が一致するプロジェクト履歴３０２に、プロジェクトＩＤ３０３が格納される。また、参加ボタン９０８を押した日が参加日３０４に格納される。
離脱ボタン９０９を押すと、開発者ＩＤ３０１とプロジェクトＩＤ３０３が一致するプロジェクト履歴３０２中の終了日３０５に離脱ボタン９０９を押した日が格納される。

図１０は、スケジュール入力部１０７が表示するスケジュール管理画面の一例であり、スケジュール管理画面は、対象開発者ＩＤの入力欄１００１と、表示ボタン１００２と、スケジュールの表示欄１００３と、スケジュールの登録欄１００４から構成される。
スケジュールの表示欄は指定された開発者のスケジュールの内容を表示するもので、対象開発者ＩＤの入力欄１００１を入力して表示ボタン１００２を押すことで表示され、開始日時４０３の内容を表示する開始日時の表示欄１００５と、終了日時４０４の内容を表示する終了日時の表示欄１００６と、内容４０５の内容を表示する内容の表示欄１００７と、削除ボタン１００８から構成される。
削除ボタン１００８をクリックすると、該当スケジュールをスケジュールデータベースから消去する。
スケジュールの登録欄１００４は、開始日時の入力欄１００９と、終了日時の入力欄１０１０と、内容の入力欄１０１１と、予約ボタン１０１２から構成され、各入力欄の内容を入力した上で予約ボタン１０１２を押すと、入力したスケジュールが登録される。

図１１は、投票入力部１２０が表示する投票画面の一例であり、投票対象の表示欄１１０１と、申請内容の表示欄１１０２と、投票の入力欄１１０３から構成される。
投票対象の表示欄１１０１は、コミット申請者を示す申請者の表示欄１１０４と、申請された日時を示す申請日時の表示欄１１０５と、コミット申請時に入力されたコメントの表示欄１１０６から構成される。
更新内容の表示欄１１０２は、ファイル名１１０７と、更新前の内容を示す更新前欄１１０８と、更新後の内容を示す更新後１１０９から構成される。
投票の入力欄１１０３は、指摘事項の入力欄１１１０と、承認ボタン１１１１と、却下ボタン１１１２から構成される。
投票対象の表示欄１１０１の内容は、保留データベース１１６の内容を基に出力され、申請者６０３の内容が申請者の表示欄１１０４に、申請日時６０２の内容が申請日時の表示欄１１０５に、コメント６０４の内容がコメントの表示欄１１０６に表示される。
なお、本画面はブラウザによって表示され、対象となる保留ＩＤ６０１はＵＲＬで指定されているものとする。

申請内容の表示欄１１０２はファイル名の表示欄１１０７と、更新前の表示欄１１０８と、更新後の表示欄１１０９から構成され、修正ファイル６０５ごとに表示される。
更新前１１０８の内容は、レポジトリサーバ１１１から取得したものであり、更新内容６０７の内容と合わせて更新後の表示欄１１０９の内容を構築する。
なお、更新された行については１１１３のように色を変えて強調表示する。
投票者は更新内容を精読し、指摘事項の入力欄１１１０を入力した上で承認ボタン１１１１か、却下ボタン１１１２を押す。入力された内容は投票結果７０２に反映される。なお、投票者の投票者ＩＤ７０３は、保留ＩＤと同様にＵＲＬで指定されているものとする。

図１２は、課題入力部１２１が出力する課題管理画面の一例を示す図であり、課題管理画面は課題を新規に登録する新規登録欄１２０１と、登録済みの課題を更新する更新欄１２０２から構成される。
新規登録欄１２０１は、内容を入力する内容入力欄１２０３と、種別を指定する種別選択欄１２０４と、登録ボタン１２０５から構成される。
内容入力欄１２０３と種別選択欄１２０４で指定された内容は登録ボタン１２０５を押すことで、課題データベースの内容８０２と種別８０３に反映される。また、登録ボタン１２０５を押して登録した直後は状態８０４に調査中が格納される。
更新欄１２０２は、課題ＩＤ８０１の内容を表示する課題ＩＤの表示欄１２０６と、内容８０２を表示する内容の表示欄１２０７と、種別８０３の内容を表示する種別の表示欄１２０８と、状態８０４の内容を表示する状態の選択欄１２０９と、発生者８０７の内容を入力する発生者の入力欄１２１０と、対応者８０８の内容を入力する対応者の入力欄１２１１と、重要度８０６の内容を選択する重要度の選択欄１２１２と、完了予定日時８０５の内容を入力する完了予定日時１２１３と、入力した内容を反映させる更新ボタン１２１４から構成される。

更新欄１２０２には、状態８０４がクローズ以外となっている課題が全て表示され、未入力の項目は入力して更新ボタン１２１４を押すことで課題データベースに反映することができる。ただし、状態の選択欄１２０９を調査中から割り当て済みに変更する場合は、発生者の入力欄１２１０と、対応者の入力欄１２１１と、重要度１２１２と、完了予定日１２１３が入力されている必要がある。
なお、種別１２０８が要望である場合は発生者の入力欄１２１０は表示されない。また、状態の選択欄１２０９は、割り当て済みの場合のみクローズに更新することができ、クローズを選択して更新ボタン１２１４を押すと、その日時が完了日時８０９に格納される。

図１３は、スケジュール調整部１１８がメールサーバ１１９を使用して投票者に送信する投票依頼メールの内容を表す図であり、投票者の開発ＩＤ１３０１と、コミット申請者の開発者ＩＤ１３０２と、申請日時１３０３と、コメントの内容１３０４と、投票スケジュール日時１３０５と、投票画面のＵＲＬ１３０６から構成される。
投票者の開発ＩＤは、投票データベース１１７の投票者７０３から取得される。
コミット申請者の開発者ＩＤ１３０２と、申請日時１３０３と、コメント１３０４は、保留ＩＤ７０１が一致する申請者６０３と、申請日時６０２と、コメント６０４から取得される。
投票スケジュール日時１３０５は、スケジュール調整部が決定した投票日時から取得される。
投票ＵＲＬ１３０６は、投票者の開発者ＩＤと保留ＩＤをパラメーターとして含み、投票入力部１２０は、この内容を基に対象の保留ＩＤと投票者を判断する。

図１４は、投票の結果、却下となった場合に申請者に送信する却下告知メールの内容を示す図であり、却下告知メールは、コミット申請者の開発者ＩＤ１４０１と、申請日時１４０２と、コメント１４０３と、指摘事項１４０４から構成される。
１４０１から１４０３の内容は、保留データベース１１６の内容から取得され、それぞれ申請者６０３と、申請日時６０２と、コメント６０４の内容が反映される。
指摘事項１４０４の内容は、指摘事項７０８の内容が反映される。
なお、本システムは開発者のメールアドレスが開発者ＩＤから類推できることを想定しているが、できない場合は開発者データベース１０４に、開発者ＩＤごとにメールアドレスが定義されている必要があることは言うまでもない。

図１５は、本システムを利用したアプリケーション開発の全体フローをフローチャートである。
開発者はプロジェクト入力部１０６が出力するプロジェクト管理画面で、プロジェクトＩＤ９０６と開発者ＩＤ９０７を指定して開発者プロジェクトに参加する（ステップ１５０１）。
次に開発者は課題データベース１２２において割り当てられた課題を把握し、解決するために開発ＰＣ１０９でソースコードを記述する（ステップ１５０２、１５０３）。
ソースコードが完成したら、レポジトリサーバ１１１のクライアントアプリケーションを操作して、ソースコードを投票システム１１０にコミット申請する（ステップ１５０４）。

コミット申請を受けるとコミット可否判定部１１５は、開発者データベース１０４とプロジェクトデータベース１０３から開発者の統合評価を取得する（ステップ１５０５）。
次に、コミット可否判定部１１５は、取得した統合評価とシステム設定データベース１１４に設定された統合評価閾値と比較する（ステップ１５０６）。
統合評価が統合評価閾値以下の場合は、コミット申請された内容を保留データベース１１６に退避した上で、投票データベース１１７に投票結果を格納する領域を作成し、スケジュール調整部１１８で投票スケジュールを算出する（ステップ１５０７）。

投票者はメールサーバ１１９から図１３に示した投票依頼メールを受け取り、それに記載されたＵＲＬ１３０６で投票入力部１２０にアクセスし、更新内容を確認した上で投票結果を入力する（ステップ１５０８）。
投票者７０３が全て投票を実施したら、コミット可否判定部１１５は可否７０７から全投票数の承認の割合を算出し、システム設定データベース１１４に記憶された承認率閾値と比較する（ステップ１５０９）。
承認率が承認率閾値を越えた場合は、保留ＩＤ１１６に退避したコミット申請の内容を、レポジトリサーバ１１１に反映させる（ステップ１５１０）。
次に開発者は課題入力１２１が出力する課題更新画面を操作して課題の状態１２０９をクローズに更新する（ステップ１５１１）。

ステップ１５０６において、統合評価が統合評価閾値を越える場合は、投票を実施せずにステップ１５１０とステップ１５１１を実施する。
また、ステップ１５０９において承認率が設定値以下の場合は、ステップ１５０３に戻り、承認されるまで修正を繰り返す。
以上のように解決した要望に対して、テストなどで不具合が発覚した場合は（ステップ１５１２）、その不具合を課題データベース１２２に登録してステップ１５０３に戻る。
問題が無ければ残りの要望を解決し、要望が全て解決された場合はプロジェクト管理画面で離脱ボタン９０９を押して開発プロジェクトから離脱する（ステップ１５０２，１５１３）。

図１６は、ステップ１５０５で述べた統合評価を取得する手順を示すフローチャートである。
本システムにおいて統合評価は、開発プロジェクトの属性や経過日数を考慮して計算し、まず統合評価Ｒを０で初期化する（ステップ１６０１）。
次に申請者６０３と開発者ＩＤが一致するプロジェクト履歴３０２を一つ取得する（ステップ１６０２）。
次に、そのプロジェクト履歴に記憶された評価を合計し、一時変数Ｐに格納する（ステップ１６０３）。なお、評価の値によってはＰの値は負数である場合がある。
次にプロジェクト履歴の終了日３０５を参照して、取得したプロジェクトが終了したものかどうか判定する（ステップ１６０４）。
終了したプロジェクトであれば、属性２０３を取得する（ステップ１６０５）。

次に終了日３０５が格納されていない現在進行中のプロジェクトの属性２０３を取得し、ステップ１６０５で取得した属性と一致するものがあるか判定する（ステップ１６０６）。
一致するものがある場合は、現在進行中のプロジェクトの属性中の、一致した割合を変数αに格納する（ステップ１６０７）。
次に、取得したプロジェクトの終了日３０５から現在までの経過日数を取得し（ステップ１６０８）、経過した日数に応じたプロジェクト経過補正値をシステム設定データベース１１４から取得して一時変数βに格納する（ステップ１６０９）。そして総合評価Ｒに一プロジェクト中の合計値であるＰと、αと、βを掛け合せた結果を加算する（ステップ１６１０）。
ステップ１６０４において、取得したプロジェクトが現在進行中のプロジェクトである場合は、αに１を代入し（ステップ１６１１）、βに１を代入した上で（ステップ１６１２）、ステップ１６１０を実行する。
以上の操作を全てのプロジェクト履歴に対して実施する（ステップ１６１３）。
これにより総合評価値は、評価が一定であっても、進行中のプロジェクトの属性や経過日数に従って変動することになる。

図１７から図１９は、評価格納部１２４が開発者の評価を算出するフローチャートであり、本システムにおいて評価が決定するタイミングは投票する時と、投票結果を判定する時と、課題を更新した時の３つがある。
図１７は、投票時の評価算出の手順を示すフローチャートであり、まず投票者の投票予定日時を投票予定日時７０５から取得する（ステップ１７０１）。
次に実際に投票された投票実施日時を７０６から取得して、ステップ１７０１とあわせて遅延時間を取得する（ステップ１７０２）。
次に、遅延時間とシステム設定データベース１１４の遅延評価値から該当する評価を取得する（ステップ１７０３）。
最後に投票者７０４と開発者ＩＤ３０１が一致する開発者データベースの評価３０７に、評価値を格納し、属性３０６に、投票と格納して終了する（ステップ１７０４）。

図１８は、投票結果判定時の評価算出の手順を示すフローチャートであり、可否７０７から、保留データ中の全投票結果における承認数の割合を取得する（ステップ１８０１）。
次にシステム設定データベース１１４の承認率閾値と比較して承認するかどうか判定する（ステップ１８０２）。
承認となった場合は、承認数の割合を、システム設定データベース１１４の承認評価値とかけた結果を評価値とする（ステップ１８０３）。
却下となった場合は、却下数の割合を、システム設定１１４の却下評価値とかけた結果を評価値とする（ステップ１８０４）。
最後に申請者６０３と開発者ＩＤ３０１が一致する開発者データベース１０４の評価３０７に、評価値を格納し、属性３０６に、承認結果に応じて申請承認または申請却下と格納して終了する（ステップ１７０５）。

図１９は、課題更新時の評価算出の手順を示すフローチャートであり、課題が更新されると、評価格納部１２４は更新後の状態８０４を取得する（ステップ１９０１）。
状態がクローズに更新された場合は（ステップ１９０２）、評価対象者に対応者８０８を指定する（ステップ１９０３）。
次に、システム設定１１４から重要度を基に該当する重要度評価値を取得する（ステップ１９０４）。
次に完了予定日時８０５と、完了日時８０９の差から遅延した日数を取得し、システム設定１１４から該当する遅延補正値を取得する（ステップ１９０５）。
次に一時変数αにステップ１９０４で取得した重要度評価値と、ステップ１９０５で取得した遅延補正値をかけあわせた結果を格納する（ステップ１９０６）。
次に種別８０３の内容を判断し、不具合である場合はステップ１９０６で算出したαとシステム設定１１４で定義された不具合解決補正値をかけあわせた結果を評価値とする（ステップ１９０７，ステップ１９０８、ステップ１９０９）。

種別８０３が要望である場合は、ステップ１９０６で算出したαとシステム設定１１４で定義された要望解決補正値をかけあわせた結果を評価値とする（ステップ１９０７，ステップ１９１０、ステップ１９１１）。
状態８０３が割り当て済みに更新された場合は、評価対象者に発生者８０７を指定する（ステップ１９１２）。
次に、ステップ１９０３と同様に重要度８０６から重要度評価値を取得する（ステップ１９１４）。
次にステップ１９１４で取得した重要度評価値と、システム設定１１４から取得した不具合発生補正値をかけあわせた結果を評価値とする（ステップ１９１３）。
以上の通り算出した評価値を評価対象者の評価３０７に格納して終了する（ステップ１９１６）。
なお、更新後の状態が調査中である場合は何もせず終了する（ステップ１９１７）。

図２０は、スケジュール調整部１１８が、申請された更新内容を基に開発者ごとの投票時間を決定する手順を示すフローチャートである。
最初に、更新内容６０７の文字数を取得する（ステップ２００１）。
次にシステム設定１１４で定義された平均閲覧時間と、ステップ２１０１で取得した文字数をかけあわせて、結果を標準投票時間７０２に格納する（ステップ２００２）。
次に一人の投票者７０３を取得する（ステップ２００３）。その投票者の投票データベース１１７に記録された投票予定日時７０５と投票実施日時７０６の差から遅延時間を取得し、開発プロジェクト中の遅延時間の平均であるプロジェクト平均遅延時間を算出する（ステップ２００４，ステップ２００５）。そして平均遅延時間を、ステップ２００２で算出した標準投票時間と加算して、その開発者の投票時間とする（ステップ２００６）。
以上の処理を開発者ごとに行う（ステップ２００７）。
投票予定日時７０５は、開発者ごとにスケジュールデータベース１０５に記憶された空き時間と、図２０で算出した投票時間から、開発プロジェクトとして最適な投票時間を基に算出される。この最適化アルゴリズムについては公知であるので説明を省略する。

本発明の実施の形態を示すシステム構成図である。プロジェクトデータベースのデータ構造を示す図である。開発者データベースのデータ構造を示す図である。スケジュールデータベースのデータ構造を示す図である。システム設定のデータ構造を示す図である。保留データベースのデータ構造を示す図である。投票データベースのデータ構造を示す図である。課題データベースのデータ構造を示す図である。プロジェクト管理画面の一例を示す図である。スケジュール管理画面の一例を示す図である。投票画面の一例を示す図である。課題管理画面の一例である。投票依頼メールの一例を示す図である。却下告知メールの一例である。システム全体の処理を示すフローチャートである。統合評価取得処理を示すフローチャートである。投票時における評価算出処理を示すフローチャートである。投票結果判定時における評価算出処理を示すフローチャートである。課題更新時における評価算出処理を示すフローチャートである。投票時間算出処理を示すフローチャートである。従来システムの全体構成図である。

符号の説明

１０１共通システム
１０２開発システム
１０３プロジェクトデータベース
１０４開発者データベース
１０５スケジュールデータベース
１０９開発者ＰＣ
１１０投票システム
１１１レポジトリサーバ
１１４システム設定データベース
１１５コミット可否判定部
１１６保留データベース
１１７投票データベース
１１８スケジュール調整部
１２０投票入力部

Claims

開発プロジェクトに属する複数の開発者が各自の開発者用コンピュータを使用してそれぞれ開発したプログラムをレポジトリサーバに保管するのを管理するシステムであって、
開発者用コンピュータからのプログラム保管申請を受け、そのプログラム保管申請を送付した開発者について過去の実績を含めた評価値を第１のデータベースから取得し、保管申請を受けたプログラムを前記レポジトリサーバに保管するか否かを前記評価値に基づいて判定し、前記評価値が予め設定された設定値を満たしていない場合には保管申請されたプログラムを第２のデータベースに退避格納し、設定値を満たしていた場合には前記レポジトリサーバに保管する第１の手段と、
前記第２のデータベースに退避格納したプログラムについて同一開発プロジェクトに属する他の開発者の承認投票により前記レポジトリサーバに保管するか否かを決定するために各開発者のスケジュールを第３のデータベースから取得し、各開発者が承認投票を行うためのスケジュールを決定し、各開発者に通知する第２の手段と、
各開発者の開発者用コンピュータから前記第２のデータベースに退避格納したプログラムについてレポジトリサーバに保管するか否かを記述した承認可否通知を受け付けて集計し、承認率が予め設定された設定値を満たしていた場合には前記退避格納したプログラムを前記レポジトリサーバに保管し、設定値を満たしていなかった場合に前記退避格納したプログラムを破棄する第３の手段と
を備えることを特徴とするレポジトリサーバ管理システム。