(57)【要約】      （修正有）【課題】レビュー工数とレビュー時期を開発工程毎のスケジュールに自動設定し、レビューの実施状況を判定して管理者に通知することが可能な開発プロセス評価管理システムを提供する。【解決手段】日報処理部１１は、担当者が入力したプロジェクト進捗情報をスケジュール表として処理するとともにプロジェクト進捗情報保持部に格納されたプロジェクト進捗情報とレビュー比率テーブル２を基に開発工程毎の計画すべきレビュー工数とレビュー時期を算出し、評価処理監視部１２は、動作設定テーブル３に設定されたプロジェクトの進捗評価にかかる異常の監視方法に基づいて評価処理監視タスクを実行し、評価処理部１３は、日報処理部１１により処理された情報および評価処理監視部１２で実行される評価処理監視タスクの結果に基づいて評価処理を行ない、異常が認められる場合には、評価処理実行部１４からネットワーク１５を介して関係者に異常判定結果を通知する。【選択図】図１
2011145982.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してクライアント端末及び管理用サーバが接続されている開発プロセス評価管理システムにおいて、
前記管理用サーバは、
開発プロジェクトの進捗情報を格納するプロジェクト進捗情報保持部と、
前記開発プロジェクトの開発工程毎にレビュー比率が格納されているレビュー比率テーブルと、
を備えるとともに、
予め入力された前記開発プロジェクトの計画情報と前記レビュー比率テーブルとを基に開発工程毎にレビュー計画を算出するレビュー計画算出手段と、
を備え、
前記クライアント端末は、
前記プロジェクトの進捗に応じてプロジェクト進捗情報を入力する手段と、
前記プロジェクトの進捗状態を表示する手段と、
を備える
ことを特徴とする開発プロセス評価管理システム。
【請求項２】
請求項１記載の開発プロセス評価管理システムにおいて、
前記管理用サーバの前記レビュー計画算出手段は、開発工程毎に計画した全体工数とレビュー比率テーブルから計画する作り込み工数、レビュー工数を決定し、計画した作業開始日と全体工数の情報より作り込み工数、レビュー工数の順に一日当たりで工数を割り当て、これを上流工程から下流工程まで繰り返すことで、開発工程毎に一日当たりのレビュー工数と時期を決定することを特徴とする開発プロセス評価管理システム。
【請求項３】
請求項１記載の開発プロセス評価管理システムにおいて、
前記管理用サーバの前記レビュー計画算出手段は、開発工程毎に計画した作り込み工数とレビュー比率テーブルから計画するレビュー工数を決定し、計画した作業開始日と作り込み工数の情報より作り込み工数、レビュー工数の順に一日当たりで工数を割り当て、これを上流工程から下流工程まで繰り返すことで、開発工程毎に一日当たりのレビュー工数と時期を決定することを特徴とする開発プロセス評価管理システム。
【請求項４】
請求項２または３記載の開発プロセス評価管理システムにおいて、
前記管理用サーバは、
前記開発プロジェクトの異常を監視する方法を設定する動作設定テーブルと、
異常発生時の連絡先のアドレスが登録されている連絡先登録テーブルと、
を備えるとともに、
前記レビュー計画と前記担当者が入力したレビュー実績を基に動作設定テーブルに設定した監視方法で前記プロジェクトの進捗をチェックし、異常発生時に連絡先登録テーブルを参照して前記連絡先に通知する異常判定通知手段と、
を備える
ことを特徴とする開発プロセス評価管理システム。
【請求項５】
ネットワークを介してクライアント端末及び管理用サーバが接続されている開発プロセス評価管理システムの方法において、
開発プロジェクトにおける開発工程毎に計画した全体工数を求めるステップと、
前記全体工数とレビュー比率から計画するレビュー工数とレビュー時期を算出するステップと、
前記プロジェクトの進捗をチェックし、異常発生時に予め登録されている連絡先に通知するステップとからなる開発プロセス評価管理方法。
【請求項６】
ネットワークを介してクライアント端末及び管理用サーバが接続されている開発プロセス評価管理システムのプログラムにおいて、
開発プロジェクトにおける開発工程毎に計画した全体工数を求めるステップと、
前記全体工数とレビュー比率から計画するレビュー工数とレビュー時期を算出するステップと、
前記プロジェクトの進捗をチェックし、異常発生時に予め登録されている連絡先に通知するステップと、
をコンピュータに実行させることを特徴とする開発プロセス評価管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアの開発工程管理の技術改良に関するもので、レビュー計画の立案とレビュー実施状況の監視を容易にした開発プロセス評価管理システムおよび開発プロセス評価管理方法ならびに開発プロセス評価管理プログラムに関する。
【背景技術】
【０００２】
ソフトウェアの開発工程管理においては、開発工程毎に工数を見積って工程を管理している。作業として例えば、設計工程では、仕様書を作成した後、レビューを行い、その内容をフォローすることが必要とされている。
しかしながら、前記のように開発工程の各作業には、作り込み作業（仕様書作成・プログラム作成・試験など）、レビュー作業、レビュー指摘項目のフォロー作業の３つのステップがあるが、これらの作業をどのように見積るかはスケジュール表を作成する担当者やマネージャーの個人の裁量に委ねられている。
このように、作業見積りは、担当者や管理者の裁量に依存しているために、開発工程毎の作業工数を見積る場合、この３つのステップをまとめて見積っていることが多く、作り込み作業のみ工数で見積り、レビューは工程の最後に行うか、又は、レビューされないことが多い。
このため、レビューが実施されない場合、後工程の作業は、前工程の不具合を内在させて進めていくことになり、問題が発見された時の工程が後になるほど、手戻りの作業量が増大する。
また、作業の質やレビューの指摘内容によって、大幅な設計の見直しや仕様書の変更項目が多くなり、そのフォローに多くの時間を割く場合がある。
【０００３】
そのため、レビュー工数・レビュー後のフォロー工数をスケジュールに確実に盛り込むことが求められている。しかし、本来必要な作業であるにもかかわらず、スケジュール作成において、レビュー日の設定が曖昧で、工程の最終日に行なわれることが多く、レビューやレビュー後のフォローに要する時間がそのまま工程遅延につながっている。また、レビュー実施状況を監視し、問題が拡大する前に対応する必要がある。
このような課題にたいしては、たとえば、以下の特許文献１および特許文献２に開示された技術が知られている。
すなわち、特許文献１には、過去のプロジェクトから類似プロジェクトの情報を取り出し、その中からレビューで利用できる情報を抽出し、チェックリストを作成することが記載されている。これは、レビュー前にチェック項目を予め決めておき、レビュー時のチェック漏れを防止するものであり、レビュー計画（工数や時期）は個人の裁量に委ねられている。
また、特許文献２には、レビュー参加者の情報やプロセス日時情報をレビュー計画ＤＢに格納しておき、関係者にしかるべき時期にレビュー実施内容を通知することが記載されている。これは、あくまでレビュー開始前に事前準備を促す通知方法であり、レビュー実施状況を監視し、異常を通知するものではない。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−２６５５８０号公報
【特許文献２】特開２００８−５２５２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
すなわち、上述の従来技術では、レビュー計画を立てることが前提となっており、レビュー工数やレビュー時期を決めるのは人の裁量に委ねられている。また、レビューの実施状況を監視し、異常を関係者に通知するものではない。このため、レビューを計画してもプロジェクトの進捗状況により担当者の判断でレビューを省略したり、またレビューを実施しても実施時期の大幅な遅れやフォローに予想外の工数が発生する場合がある。
本発明の目的は、人によるスキルや手間をかけずにレビュー工数とレビュー時期を開発工程毎のスケジュールに自動設定し、さらに、自動的にレビューの実施状況を判定して管理者に通知することが可能な開発プロセス評価管理システムおよび開発プロセス評価管理方法ならびに開発プロセス評価管理プログラムを提供することにある。
【課題を解決するための手段】
【０００６】
本発明の第１の観点は、ネットワークを介してクライアント端末及び管理用サーバが接続されている開発プロセス評価管理システムにおいて、前記管理用サーバは、開発プロジェクトの進捗情報を格納するプロジェクト進捗情報保持部と、前記開発プロジェクトの開発工程毎にレビュー比率が格納されているレビュー比率テーブルと、を備えるとともに、予め入力された前記開発プロジェクトの計画情報と前記レビュー比率テーブルとを基に開発工程毎にレビュー計画を算出するレビュー計画算出手段と、を備え、前記クライアント端末は、前記プロジェクトの進捗に応じてプロジェクト進捗情報を入力する手段と、前記プロジェクトの進捗状態を表示する手段と、を備えることを特徴とする開発プロセス評価管理システムを提供する。
本発明の第２の観点は、ネットワークを介してクライアント端末及び管理用サーバが接続されている開発プロセス評価管理システムの方法において、開発プロジェクトにおける開発工程毎に計画した全体工数を求めるステップと、前記全体工数とレビュー比率から計画するレビュー工数とレビュー時期を算出するステップと、前記プロジェクトの進捗をチェックし、異常発生時に予め登録されている連絡先に通知するステップとからなる開発プロセス評価管理方法を提供する。
【０００７】
本発明の第３の観点は、ネットワークを介してクライアント端末及び管理用サーバが接続されている開発プロセス評価管理システムのプログラムにおいて、開発プロジェクトにおける開発工程毎に計画した全体工数を求めるステップと、前記全体工数とレビュー比率から計画するレビュー工数とレビュー時期を算出するステップと、前記プロジェクトの進捗をチェックし、異常発生時に予め登録されている連絡先に通知するステップと、をコンピュータに実行させることを特徴とする開発プロセス評価管理プログラムを提供する。
【発明の効果】
【０００８】
本発明によれば、レビューが確実に管理（計画と実施）されるので、上流工程での問題点が同じ工程内で発見できるようになるため、問題発生時の手戻り工数が減少できる。また、レビュー実施状況が自動的に、関係者に連絡されるので、管理者の負担を軽減することができる。さらに、スケジュールを作成した時に、マイルストーンとしてのレビュー日を決定することができ、レビューアの日程調整も容易となる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施の形態である開発プロセス評価管理システムの構成概要を示す図である。
【図２】本発明の一実施の形態である開発プロセス評価管理システムにおけるスケジュール表の一例を示す図である。
【図３】本発明の一実施の形態である開発プロセス評価管理システムにおける開発工程毎の全体工数入力の一例を示す図である。
【図４】本発明の一実施の形態である開発プロセス評価管理システムにおける図３にレビュー工数を反映させた一例を示す図である。
【図５】本発明の一実施の形態である開発プロセス評価管理システムにおける開発工程毎の作り込み工数入力の一例を示す図である。
【図６】本発明の一実施の形態である開発プロセス評価管理システムにおける図５にレビュー工数を反映させた一例を示す図である。
【図７】本発明の一実施の形態である開発プロセス評価管理システムにおける開発工程別レビュー比率テーブルの構成を示す図である。
【図８】本発明の一実施の形態である開発プロセス評価管理システムにおける動作設定テーブルの構成を示す図である。
【図９】本発明の一実施の形態である開発プロセス評価管理システムにおける連絡先登録テーブルの構成を示す図である。
【図１０】本発明の一実施の形態に係る開発プロセス評価管理システムのレビュー工数算出処理の一例（その１）を示すフローチャートである。
【図１１】本発明の一実施の形態に係る開発プロセス評価管理システムのレビュー工数算出処理の一例（その２）を示すフローチャートである。
【図１２】本発明の一実施の形態に係る開発プロセス評価管理システムの全体的な動作を説明する処理の一例を示すフローチャートである。
【図１３】本発明の一実施の形態に係る開発プロセス評価管理システムの評価処理実行部の評価処理監視部である評価処理起動タスクの処理の一例を示すフローチャートである。
【図１４】本発明の一実施の形態に係る開発プロセス評価管理システムにおけるレビュー実施判定処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本発明の実施の形態について、詳細に説明する。
図１は、本発明の実施形態に係る開発プロセス評価管理システムの構成概要を示す図である。図１において本発明の実施形態に係る開発プロセス評価管理システムは、管理用サーバ１０と、クライアント端末である管理者用端末２０、担当者用端末３０とにより構築され、ネットワーク１５を介して管理用サーバ及びクライアント端末が通信可能に接続されている。なお、ネットワークは、有線、無線を問わず既存の公衆網、ＬＡＮ、ＷＡＮなどを用いることができる。
図１において、管理用サーバ１０は、担当者により入力されたプロジェクトの進捗情報を保持するプロジェクト進捗情報保持部１と、開発工程毎にレビュー比率とフォロー比率を格納するためのレビュー比率テーブル２と、異常の監視方法を設定する動作設定テーブル３と、異常発生時の連絡先のアドレスを格納する連絡先登録テーブル４と、をデータベース５に備えている。プロジェクトの進捗情報とは、計画情報と実績情報を含み、後で説明する図２〜図６に示されている情報が該当する。
また管理用サーバ１０は、プロジェクトに携わる担当者から入力されたプロジェクト進捗情報をスケジュール表として処理するとともにプロジェクト進捗情報保持部に格納されたプロジェクト進捗情報とレビュー比率テーブル２を基に開発工程毎の計画する作業工数（作り込み工数、レビュー工数、レビューの指摘項目のフォロー工数）と時期を算出する日報処理部１１と、動作設定テーブル３に設定されたプロジェクトの進捗評価にかかる異常の監視方法に基づいて評価処理監視タスクを実行する評価処理監視部１２と、日報処理部１１により処理された情報および評価処理監視部１２で実行される評価処理監視タスクの結果に基づいて評価処理を行なう評価処理部１３と、を有し、これらでもって評価処理実行部１４を構成している。
【００１１】
そして評価処理部１３が行なうプロジェクトの進捗評価により、異常の発生が認められた場合には、判定結果に応じて評価処理実行部１４からネットワーク１５を介して関係者に異常の発生を連絡先登録テーブル４に登録されているアドレスを元に自動的に通知する。
なお、図示はしていないが、管理用サーバとしての機能を実現するためのハードウェア資源として、例えば、ＣＰＵ、記憶装置、入出力装置、各種インターフェースなど、を周知の構成として備えており、また当然ながら、上記のごとき機能を実現させるためのプログラムを上記記憶装置内に格納している。データベース５は上述の記憶装置により実現され、また、評価処理実行部１４内の各構成は、上述のＣＰＵ、記憶装置、各種インターフェース等のハードウェア資源と後述する処理フローを実行する各種プログラムにより実現される。
一方、クライアント端末としての管理者用端末２０は、上記した所定のテーブルに情報(プロジェクト初期情報)を入力するための設定画面２１と、プロジェクトの進行に伴う現在までの進捗状態を表示する画面２２を備えており、またクライアント端末としての担当者用端末３０は、プロジェクトの進捗情報を入力するための入力画面３１と、プロジェクトの進行に伴う現在までの進捗状態を表示する画面３２とを備えている。なお、図示はしていないが、クライアント端末としての機能を実現するためのハードウェア資源として、例えば、ＣＰＵ、記憶装置、入出力装置、各種インターフェースなど、を周知の構成として備えており、また上記のごとき機能を実現させるためのプログラムを上記記憶装置内に格納している。
【００１２】
図２は、端末(クライアント端末)からプロジェクトの進捗情報を入力するスケジュール表を示す図である。図２において、計画時には、項目、開発工程、担当者、各開発工程に対応する日毎の作業予定（時間）（例．１０月１日〜３１日における日毎の予定時間）に情報を入力する。また、運用時には、作業実績（時間）とレビュー実績（時間）を1日に１回入力する。次に各項目について説明する。
１．項目４１：開発する機能名称を入力する。
２．開発工程４２：開発する機能名称に対応する開発工程を選択する。
３．担当者４３：開発する機能名称に対応する開発工程の作業を行う担当者名を入力する。
４．残工数４４：計画と実績の工数から、残工数を人日で自動計算する。但し、工程が前倒しになった場合や遅延した場合は、残工数が変わるので、工数の増減が判明した時点で残工数を手入力する。
演算式：
残工数＝（作業予定工数＋レビュー予定工数）―（作業実績工数＋レビュー実績工数）
５．工数４５：作業予定、作業実績、レビュー予定、レビュー実績は、日毎の入力の総和を人日で表示する。ソフトウェアの開発作業としては作り込み作業、レビュー作業、フォロー作業があるがここでは作り込み作業とレビュー指摘項目のフォロー作業を合わせて作業予定及び作業実績としている。
６．進捗率４６：計画に対し、工程の遅れを考慮した進捗率を自動計算で求める。
【００１３】
演算式：
進捗率＝（作業実績工数＋レビュー実績工数）／（残工数＋作業実績工数＋レビュー実績工数
７．作業予定４７：該当する開発工程の作業予定日に作業予定時間を入力する。
８．作業実績４８：該当する開発工程の作業実施日に作業実績時間を入力する。ここで作業実績は、作り込み作業とレビュー指摘項目のフォロー作業の実績時間を入力する。
９．レビュー予定４９：該当する開発工程のレビュー予定日に、レビュー予定時間が表示される。
１０．レビュー実績５０：該当する開発工程のレビュー実施日にレビュー実績時間を入力する。
図７は、図１の管理用サーバ内に設けられたレビュー比率テーブルの構成を示す図である。図７に示すレビュー比率テーブルは、開発工程毎に必要となるレビュー時間、及び、レビュー時の指摘項目をフォローするための時間を求めるための全体工数に対する比率が格納されている。この数値は、過去の類似プロジェクトのプロジェクト進捗情報を参考に比率が求められている。
【００１４】
過去のプロジェクトの進捗情報は、プロジェクト進捗情報保持部１に保存されており、機能名や顧客名などのキーワードでＤＢを検索し、情報を端末（クライアント端末）に表示させることができる。
次に、開発工程毎の全体工数を入力することで各作業の工数と時期を算出する例を図３、図４、図１０から詳細に説明する。
図３は、スケジュール表に開発工程毎の全体工数を入力した例である。全体工数とは、作り込み工数、レビュー工数、レビュー指摘項目のフォロー工数の総和であり、計画時に「作業予定」の該当する予定日に時間を入力する。
図４は、スケジュール表に図１０のフローに従って、図３で入力した全体工数（工数の総和）を基に、作り込み工数（仕様作成・プログラム・試験など）、レビュー工数、レビュー指摘項目のフォロー工数を求めた結果を反映させたものである。ここでは作り込み工数とフォロー工数を合わせた時間が作業予定に反映されている。
図１０に、全体工数から、レビュー工数とレビューの指摘項目のフォロー工数を求めるレビュー計画算出手段（図８で工数入力種別＝０の場合）のフローを示す。スケジュール表にある工程数分以下の処理をする（ステップ５１）。
【００１５】
１）日毎の作業工数から作業予定工数の総和を求める（ステップ５２）。
２）図７より開発工程に対応したレビュー比率、フォロー比率を読み出し（ステップ５３）、下記式に従ってレビュー工数・レビューフォロー工数を求め、最後に作業工数を求める（ステップ５４）。
レビュー工数          ＝  工数の総和  ×  レビュー比率
レビューフォロー工数  ＝  工数の総和  ×  フォロー比率
作り込み工数              ＝  工数の総和  −（レビュー工数  ＋  レビューフォロー工数）
３）レビュー日を求める（ステップ５５）。レビュー日は、工程の開始日と作り込み工数から求められる。但し、レビューが２日間にまたがる場合は、各日の時間を求め、当日、又は、翌日のどちらかが２時間未満の場合は、翌日にレビューを実施する（ステップ５６）。
例えば、当初計画でレビュー日の作り込み作業予定時間が８時間となっている場合、
作り込み作業時間＝６時間、レビュー時間＝３時間となる場合がある。この場合は、作り込み作業終了後の２時間と翌日に持ち越す1時間がレビュー時間とになるので、翌日にまとめてレビューを実施する（ステップ５７）。
【００１６】
レビューは、一度に集中して行うことが望ましいため（１時間分を翌日にするとレビューの効率が下がる）レビュー日を翌日にする（ステップ５８）。また、レビューを翌日にした場合は、作り込み作業時間が６時間となるが２時間はリスク分として空けておく。
４）レビュー当日の作業時間から、レビュー時間を引く（ステップ５９）。
さらに、図３の入力した全体工数から図４のスケジュ−ルを作成する方法について補足しておく。開発工程のＳＡでは、全体工数が５．０人日（４０時間）なので、上記式に当てはめると、レビュー工数２時間、レビューフォロー工数６時間、作り込み工数３２時間となる。
よって、作業予定の１日〜６日に作り込み工数が入り（休日、祝日除く）、レビュー予定の７日にレビュー工数２．０時間が入る。さらに、作業予定の７日にレビューフォロー工数６．０時間が入る。同様に他の工程についても処理する。
次に、開発工程毎の作り込み工数を入力することで各作業の工数と時期を算出する例を図５、図６、図１１から詳細に説明する。
図５は、スケジュール表に開発工程毎の作り込み工数（仕様作成・プログラム・試験など）のみを入力した例である。
【００１７】
図６は、スケジュール表に図１１のフローに従って、図５で入力した作り込み工数を基に、レビュー工数、レビューの指摘項目のフォロー工数を求めた結果を反映させたものである。ここでは作り込み工数とレビューの指摘項目のフォロー工数を合わせた時間が「作業予定」に反映されている。
図１１に、作り込み作業工数から、レビュー工数とレビューの指摘項目のフォロー工数を求めるレビュー計画算出手段（図８で工数入力種別＝１の場合）のフローを示す。スケジュール表にある工程数分以下の処理をする（ステップ６１）。
１）日毎の作業工数から作業予定工数の総和を求める（ステップ６２）。
２）図７より開発工程に対応したレビュー比率、フォロー比率を読み出し（ステップ６３）、下記式に従ってレビュー工数・レビューフォロー工数を求め、最後に作り込み作業工数を求める（ステップ６４）。
工数の総和            ＝  作り込み作業工数    ／  （１−レビュー比率  ―  フォロー比率）
レビュー工数          ＝  工数の総和  ×  レビュー比率
レビューフォロー工数  ＝  工数の総和  ×  フォロー比率
３）レビュー日を求める（ステップ６５）。求め方は、図８の工数入力種別＝０の場合と同じ（ステップ５６〜５９＝ステップ６６〜６９）。
【００１８】
４）レビュー当日の作り込み作業時間にレビューのフォロー工数を追加する（ステップ７１）。
５）追加に伴い工数が増えるので、以降のスケジュールを全て後ろにずらしていく（ステップ７２）。
さらに、図５の入力した全体工数から図６のスケジュ−ルを作成する方法について補足しておく。開発工程のＳＡ工程では、作り込み工数が５．０人日（４０時間）なので、上記式に当てはめると、レビュー工数２．５時間、レビューフォロー工数７．５時間、作り込み工数４０．０時間となり、合計の時間が５０時間なので残工数は６．２５人日（５０時間）になる。
よって、作業予定の１日〜７日に作り込み工数が８時間づつ入り（休日、祝日除く）、レビュー予定の８日にレビュー工数２．５時間が入る。さらに、作業予定の８、９日にレビューフォロー工数がそれぞれ５．５時間と２時間が入る。同様に他の工程についても処理する。
図８は、図１の管理用サーバ内に設けられた動作設定テーブルの構成を示す図である。図８において動作設定テーブルは、図１に示した担当者用端末３０から入力された「プロジェクトの進捗情報」（日報＝スケジュール表）から、管理用サーバ１０におけるプロジェクトを評価する評価処理の実行時間を指定するためのものである。
【００１９】
具体的には、図８に示すように、
１．工数入力種別６１：開発工程毎にプロジェクト進捗情報を入力するとき、開発工程毎の全工数を入力するか、作業工数のみを入力するかを指定する。
２．評価処理起動方法６２として、以下の３種類の指定を設けている。すなわち、
（１）フラグ=０：評価処理を実行しない
（２）フラグ=１：入力完了時に実行
（３）フラグ=２：評価処理実行時刻に実行    １回／１日
３．評価処理実行時刻６３：時間、分  を指定する。そしてこの時間は、日報入力チェックを行なう時間にも使用される。
４．日替わり日指定フラグ６４：評価処理実行時刻の当日をチェック日とするか、前日をチェック日とするかを指定する。フラグ=０は前日、フラグ=１は当日とする。例えば、評価処理実行時刻を、０１：００とした場合は前日(フラグ=０)を指定する。夕方の１８：００にする場合は、当日(フラグ=１)を指定する。
５．日報入力遅延監視日６５：担当者に、入力遅延の連絡の有無と連絡する場合に、何日分遅れたら連絡するかを定義する。
６．日報入力遅延監視日６６：ＰＭ(プロジェクトマネージャ)に、入力遅延の連絡の有無と連絡する場合に、何日分遅れたら連絡するかを定義する。
７．日報入力遅延監視日６７：上級管理者に、入力遅延の連絡の有無と連絡する場合に、何日分遅れたら連絡するかを定義する。
【００２０】
図９は、図１の管理用サーバ内に設けられた連絡先アドレステーブルの構成を示す図である。図９に示す連絡先アドレステーブルには、氏名７１、登録者種別７２、連絡先メールアドレス７３、電話番号７４が項目として設けられている。本連絡先は、異常判定された場合に、異常であることを通知対象者の連絡先として、メールアドレス、電話番号などが登録されている。なお、登録者種別７２としては、本プロジェクト遂行にかかる職制が用いられている。
図１２は、本発明の実施形態に係る開発プロセス評価管理システムの全体的な動作を説明する処理フローを示す図である。図１２に示す処理フローを、図１に示した開発プロセス評価管理システムの構成概要とともに説明する。図１２の処理フローにおいて、左側に示す処理フロー（ａ）は、図１に示す管理者用端末２０を使ったＰＭ（プロジェクトマネージャ）によるプロジェクト初期設定（ステップ２０）を示すもので、ＰＭ（プロジェクトマネージャ）は、プロジェクト開始時に図１に示したサーバ１０内のデータベース５の各種テーブルへの設定を行なう（ステップ２１）。すなわち、担当者により入力されたプロジェクトの進捗情報を保持するプロジェクト進捗情報保持部１と、開発工程毎にレビュー比率ととフォロー比率を格納するためのレビュー比率テーブル２と、異常の監視方法を設定する動作設定テーブル３と、異常発生時の連絡先のアドレスを格納する連絡先登録テーブル４、のそれぞれに対して設定登録を行なう。
【００２１】
次いで図１２の中央及び右側に示す処理フロー（ｂ）、（ｃ）に示すように、サーバ処理（ステップ１０）では、まず、サーバ１０は進捗データ(画面)のクライアント端末(図１に示す担当者用端末３０)への送信を行なう（ステップ１１）。担当者端末処理（ステップ３０）では、担当者は、担当者用端末３０を使って進捗入力画面の呼び出しを行なう（ステップ３１）。これらの処理は、通常のクライアント・サーバシステムにおけるログオン処理に相当する。そして、担当者は、その日における作業を実施した後に、その日の作業に対応する作業時間（日報＝スケジュール表）を入力し、サーバ１０内の評価処理実行部１４に入力データを送信する（ステップ３２）。
これを受けて処理フロー（ｂ）では、評価処理実行部１４内の日報処理部１１で担当者用端末３０から送信された日報の登録を行なう（ステップ１２）。この処理においては、データベース７におけるプロジェクト進捗情報保持部６にデータが登録される。日報の登録がなされたら、評価処理実行部１４内の評価処理監視部１２により、動作設定テーブル３（図８参照）の設定内容を参照して、評価処理を実行してよいかどうかを判定し、図８に示す評価処理の実行方法におけるフラグが「入力完了時実行」の設定の場合には（ステップ１３：Yes）、評価処理実行部１４内の評価処理部１３により、入力されたデータの［評価処理］を実行する（ステップ１４）。
【００２２】
この［評価処理］については後述する。そして［評価処理］の実行の結果、新規に異常が発生した場合（ステップ１５：Yes）は、評価処理実行部１４内の評価処理部１３からネットワーク１５を経てクライアント端末（担当者端末）に異常の通知を行なう（ステップ１６）。この異常の通知についても後述する。一方、処理フロー（ｃ）における担当者端末（クライアント端末）処理では、評価処理実行部１４から評価処理結果が送信された場合には、端末画面に送信結果の表示を行なう（ステップ３３）。
図１３は、評価処理起動タスクの処理フローを示す図である。図１３の左側に示す処理フロー（ａ）は、評価処理起動タスクのメインフローを示すもので、サーバ１０の起動時に起動され、常時、評価処理の起動監視を行なっている。この評価処理起動タスクの処理は、上述したように評価処理実行部１４内の評価処理監視部１２において実施する。すなわち、評価処理監視部１２は、動作設定テーブル５を参照し、評価処理が無効（＝評価しない）以外であれば（ステップ４１：Yes）、評価処理実行時間の時刻になるまで待つ（ステップ４２）。無効（＝評価しない）の場合（ステップ４１：No）は、一定時間処理を停止(スリープ)し、再度定義があるかどうかをチェックする（ステップ４３）。これは、サーバ１０の起動後に、動作設定テーブル３の設定変更がなされても評価処理が実行されるようにするためである。
【００２３】
評価処理実行時間の時刻が到来したら（ステップ４２）、対象となる全ての日報＝スケジュール表（「プロジェクト進捗情報」）の入力が出されているかを、図１３の右側の処理フロー（ｂ）に示す「日報（「プロジェクト進捗情報」）の入力チェック」処理でチェックする。その後、動作設定テーブル３に定義されている「動作設定」が「評価処理実行時間に実行」されたかをチェックし（ステップ４６）、実行が確認された場合（ステップ４６：Yes）には、［評価処理］を呼びだす（ステップ４７）。この［評価処理］については後述する。
図１３の右側の処理フロー（ｂ）に示す「日報（「プロジェクト進捗情報」）の入力チェック」処理は、上級管理者、ＰＭ（プロジェクトマネージャ）、担当者毎に指定されている最終入力の遅延日をチェックし、入力がされていない場合には、未入力通知を下記手順で行なう。すなわち、監視が有効であった場合には、現在日と動作設定テーブル３に定義されている「日替わり日指定フラグ」６４から入力が完了すべき「入力確認日」を決定する（ステップ１０１）。「日替わり日指定フラグ」６４において、
日替わり日指定フラグ＝０（前日指定）：現在日の前日をチェックする「入力確認日」とする（ステップ１０２）
日替わり日指定フラグ＝１（当日指定）：現在日をチェックする「入力確認日」とする（ステップ１０３）
次いで「プロジェクト進捗情報」の入力が完了すべき「入力確認日」から過去に遡って、スケジュール表の当該月の実績時間を入力する欄に実績が入力がされている月日で最終入力日を見つけ（ステップ１０４）、実稼動日（休日を除く、勤務日）を除いた「入力確認日」と「最終入力日」の差分を求める（ステップ１０５）。なお、実稼動日は、「プロジェクトの進捗情報」の日毎の予定時間の入力がない日で判断するか、別途稼動日、非稼動日を設定するテーブルを設けても良い。そしてその差分が、上級管理者、ＰＭ（プロジェクトマネージャ）、担当者毎に指定されている遅延日（図８に示す動作設定テーブルの定義６５〜６７参照）以上であれば、対象者に連絡を行う（ステップ１０６〜ステップ１１４）。
【００２４】
図１４に、動作設定テーブルの条件に従って判定を開始したときの、レビュー実施判定処理フローを示す。スケジュール表にある工程数分以下の処理をする（ステップ８１）。
１）当日がレビュー実施予定日か判定する（ステップ８２）。
２）レビュー実施予定日の場合は、レビュー実績が入力されているか判定する（ステップ８３）。レビュー実績が入力されていないことで、レビューが実施されていないと判断する。
３）レビューが実施されていない場合で、
・進捗率が１００％の場合（ステップ８４）は、レビューが実施されなかったことを通知する（ステップ９１）。
・進捗率がレビューすべき工数より少ない場合（ステップ８７）は、工程遅れを通知する（ステップ８９）。
・進捗率がレビューすべき工数を過ぎている場合（ステップ８７）は、レビュー未実施を通知する（ステップ８８）。
・通知先は、通知先アドレステーブルに登録のある人に対して行う。
４）レビューが実施されていた場合で、レビューの実施時間が予定の５０％以下の場合（ステップ８５）は、レビュー不足の疑いありの通知を送付する（ステップ８６）。
【００２５】
本発明の実施例によれば、開発プロジェクトのスケジュールを計画するとき、開発工程毎の作り込み工数または全体工数をスケジュール表に入力することで、作業工数（作り込み工数、レビュー工数、レビュー指摘項目のフォロー工数）と時期が自動で算出されスケジュール表に反映することができる。
このことにより、個人スキルによる計画精度のムラを防止するとともに確実にレビューを計画することができる。さらにスケジュールの予実管理を自動で行い問題発生時は関係者に通知されることで確実にレビューが実施され、その結果としてプロジェクトの上流工程での問題点が同じ工程内で発見できるようになるため、問題発生時の手戻り工数が減少できる。また、レビュー実施状況が自動的に、関係者に連絡されるので、管理者の負担を軽減することができる。
【符号の説明】
【００２６】
１  プロジェクト進捗情報保持部
２  レビュー比率テーブル
３  動作設定テーブル
４  連絡先登録テーブル
５  データベース
１０  管理用サーバ
１１  日報処理部
１２  評価処理監視部
１３  評価処理部
１４  評価処理実行部
１５  ネットワーク
２０  管理者用端末
２１  設定画面
２２  進捗状態表示画面
３０  担当者用端末
３１  進捗入力画面
３２  進捗状態表示画面
４１  項目
４２  開発工程
４３  担当者
４４  残工数
４５  工数
４６  進捗
４７  作業予定
４８  作業実績
４９  レビュー予定
５０  レビュー実績
６１  工程入力種別
６２  評価処理起動方法
６３  評価処理実行時刻
６４  日指定フラグ
６５  日報入力遅延監視日（担当者）
６６  日報入力遅延監視日（ＰＭ）
６７  日報入力遅延監視日（上級管理者）
７１  氏名
７２  登録者種別
７３  連絡先メールアドレス
７４  電話番号
【図１】
2011145982.tif 000003
【図８】
2011145982.tif 000004
【図９】
2011145982.tif 000005
【図１０】
2011145982.tif 000006
【図１１】
2011145982.tif 000007
【図１２】
2011145982.tif 000008
【図１３】
2011145982.tif 000009
【図１４】
2011145982.tif 000010
【図２】
2011145982.tif 000011
【図３】
2011145982.tif 000012
【図４】
2011145982.tif 000013
【図５】
2011145982.tif 000014
【図６】
2011145982.tif 000015
【図７】
2011145982.tif 000016