JP2005055993A - プロジェクト管理システム - Google Patents

Abstract

【課題】現在、ソフトウェア開発は、作業場所が複数の拠点にわかれ、また作業者も多いため、進捗・品質管理は重要である。しかし、進捗・品質管理はプロジェクト管理者の作業負荷が大きいという問題があった。
【解決手段】開発計画と品質基準をもとに、随時登録されてくる成果物の進捗・品質情報を取得してプロジェクト管理表を作成し、進捗の遅れている案件または品質の悪い案件に対しては、その旨を警告表示あるいはメッセージ送信によって連絡し、その対策案の自動作成を行い、対策案の自動配布を行うプロジェクト管理システム。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、ソフトウェア開発における進捗および品質を管理するプロジェクト管理システムに関する。
【０００２】
【従来の技術】
現在のソフトウェア開発プロジェクトは、開発規模が大きく、成果物の数も多く、開発期間も長期化する傾向にある。従って現在のプロジェクトにおいては、一般に知られるプロジェクト管理技術を用いて定期的に進捗を管理し、早期に遅延を発見して回復の対策を策定することが必要とされている。また、成果物の数が多いため、それらの品質を管理し、品質が悪い場合は改善策を策定する事が求められている。
このようなプロジェクト進捗管理および品質管理を支援するシステムしては、特許文献１に示すような装置が提案されている。この装置では、ソフトウェア開発における計画と成果物を突き合わせることにより完成度合を計測し、進捗の管理支援としている。
【０００３】
【特許文献１】
特開２００１−２０９５３０号公報
【０００４】
【発明が解決しようとする課題】
現在、ソフトウェア開発は、作業場所が複数の拠点にわかれ、また作業者も多いため、個々の進捗を把握する事はそれほど困難ではないが、全体の進捗を正確に把握することは難しく、プロジェクト管理者の負担となっていた。また、多数の成果物の品質を確認することは作業負荷が大きいという問題があった。上記従来の装置は進捗自動計測を可能としているが、これは成果物のみの状況から進捗を計測しており、進捗の遅れを検出することは可能であるが、その原因となった事項は別途調べなければわからないという問題があった。また、上記従来の装置では成果物の品質については判定を行っておらず、従って見かけ上進捗に遅れが無くとも品質が悪いために後で大幅な作業増になるような事態を予測することはできなかった。
【０００５】
本発明の目的は、プロジェクト管理システムにおいて、進捗及び品質を判定するための情報を自動取得し、プロジェクト管理表を自動作成し、進捗の遅れと品質の低下を自動判定し、その原因を推測し対策案の作成を支援することが可能なプロジェクト管理システムを提供することにある。
【０００６】
【課題を解決するための手段】
上記の目的を達成するために、本発明のプロジェクト管理システムは、作業計画と設計書と成果物とテスト情報と障害情報とを格納する手段を備え、前記格納情報から進捗情報及び品質情報を取得してプロジェクト管理情報として格納する手段とプロジェクト管理情報を用いてプロジェクト管理表を作成する手段とを備える。作業計画と設計書はプロジェクト開始時に格納しておく。
【０００７】
さらに本発明のプロジェクト管理システムは、成果物の進捗を評価して評価結果が基準値を外れているプログラムを判定する手段と品質を評価して評価結果が基準値を外れているプログラムを判定する手段とを備える。望ましくはこの両方の手段を備えるが、進捗管理のみの機能で構成する場合もある。上記判定に必要な進捗基準と品質基準は、プロジェクト開始時に格納しておき、随時登録されてくる成果物情報からプロジェクト管理表を作成して進捗を評価する。また同様に登録されてくるテスト情報及び障害情報から品質を評価する。評価結果が前記基準に満たない場合は、それぞれ進捗の遅れた案件または品質の悪い案件に対して、その旨を警告表示あるいはメッセージ送信によって登録元に連絡する。
【０００８】
さらに本発明のプロジェクト管理システムは、進捗の回復のための対策案生成手段と、品質の改善のための対策案生成手段とを備える。進捗管理のみ機能の場合は前者の手段のみを備える。この機能により、進捗の遅れた案件または品質の悪い案件の原因を解析し、対策案を自動作成して前記連絡時に合わせて送信する。
ソフトウェア開発における、成果物またはテスト情報や障害情報の登録と情報取得、判定処理は次のように行う。開発担当者は、成果物を新規作成した場合あるいは修正を行った場合には、当該成果物を開発サーバに格納する。プロジェクト管理サーバは、プロジェクト管理情報を取得する手段により、開発サーバに格納されたファイルから成果物名称、作成者、作成日などの進捗情報を取得し、バグや工数などの品質情報を求める。
【０００９】
さらにプロジェクト管理サーバでは、プロジェクト管理表を作成する手段により、プロジェクト管理表である進捗管理表及び品質管理表を作成し、格納する。進捗管理表・品質管理表は、画面表示、一覧表出力のいずれかで参照可能であり、メール送信も可能である。評価結果が基準値を外れているプログラムを判定する手段により進捗管理表を作業計画と比較し、進捗の遅れている案件を検出し、その案件には、その旨を警告メッセージとして表示し、管理者および担当者にメールを送信する。これにより、管理者が自ら進捗の度合や品質の悪い案件を判断する必要がなく、警告を出す手間も省け、問題点の早期発見ができる。
【００１０】
進捗の遅れている案件に対しては、何らかの対策が必要となる。本発明のプロジェクト管理システムは、進捗の回復のための対策案生成手段により、当該作業の重要度により、作業計画の見直し等の対策を見積もり、管理者に送信する。計画の変更が行われた場合には、新しいバージョンとして管理する。また、品質の悪い案件に対しては、品質の改善のための対策案生成手段により、類似バグの摘出命令等の対策方法を見積もり、管理者および作業者に送信する。対策後の情報は、別バージョンとして管理し、配布履歴も更新する。
【００１１】
【発明の実施の形態】
以下、本発明の実施例を図面により詳細に説明する。本発明のプロジェクト管理システムは、ソフトウェア管理、進捗管理、品質管理、バージョン管理、配布管理など、種々の分野に適用できるが、ここではソフトウェア開発における進捗および品質管理を例に説明する。
【００１２】
図１は、本発明のソフトウェア管理および配布システムを実現するためのシステム構成を示したものである。１１は、作業計画であり、ソフトウェア開発作業の作業名、作業者、作業期間などを記述したファイルである。１２は、設計書であり、ソフトウェア開発作業者がプログラムを作成するために必要な設計書ファイルである。１３は、プログラムソースであり、作成したプログラムファイルである。１４は、テスト情報であり、ソフトウェアのテストの進捗状況を記録したファイルである。１５は、障害情報であり、プログラム作成時のバグ情報やその対策状況を記録している。１６は、作業者端末であり、設計書やプログラムの作成、登録、修正、および情報の参照などの作業を行うために使用するものである。１７は、プロジェクト情報取得・集計手段であり、プログラム作成時の各種設計書やプログラムソースの進捗・品質情報を取得して集計して、プロジェクト管理表を作成する機能を有している。１８は、プロジェクト情報考察・判定手段であり、プログラム作成時の進捗状況や品質状況を考察して、問題点がないかを判定する機能を有している。１９は、プロジェクト情報提案・配布手段であり、進捗が遅れているプログラムや品質の悪いプログラムに対して、回復案や対策案を提案する機能を有している。１１０は、プロジェクト管理ファイルであり、取得した各種の情報から、進捗や品質の情報を記録したファイルである。１１１は、プロジェクト管理表であり、プロジェクト管理ファイルを参照する場合に使用される。１１２は、進捗基準値であり、各案件の進捗が計画通りであるかどうか判定する基準となるファイルである。１１３は、品質基準値であり、各案件の品質が基準値内であるかどうか判定する基準となるファイルである。１１４は、進捗改善対策情報であり、進捗の遅れが基準以上の場合の改善対策を格納するファイルである。１１５は、品質改善対策情報であり、品質が悪い場合の改善対策を格納するファイルである。１１６は、管理者端末であり、管理者がプロジェクト管理情報の参照、修正、承認などの作業を行うために使用するものである。
【００１３】
図２は、プロジェクト管理ファイル１１０のデータ構成例である。管理対象は、作業拠点単位、部署単位、作業者単位、プログラム単位等がありが、ここではプログラムＩＤを扱う。プロジェクト２１は、プログラムＩＤであり、作成するプログラムのＩＤを表す。２２は、完了予定日であり、作成するプログラムの完了予定の日付を表す。２３は、設計書新規登録日であり、設計書を新規登録した日付を表す。２４は、設計書更新日であり、登録した設計書を更新した日付を表す。２５は、プログラム新規登録日であり、プログラムソースを新規登録した日付を表す。２６は、プログラム更新日であり、プログラムを更新した日付を表す。２７は、テストカバレジ情報新規登録日であり、テストカバレジ情報を新規登録した日付を表す。テストカバレジとは、テストの実行状況や、テスト日時、テスト回数を表す。２８は、テストカバレジ情報更新日であり、テストカバレジ情報を更新した日付を表す。２９は、プログラム完了日であり、プログラム作成が完了した日付を表す。２１０は、工数であり、プログラム作成に要した期間を表す。２１１は、状態であり、情報収集時点での作成状態を表す。２１２は、進捗判定であり、プログラム作成の進捗が、計画と比較して進んでいるのか遅れているのかを表す。２１３は、進捗対策状況であり、進捗が遅れているプログラムに対して対策を行ったかどうかを表す。２１４は、チェックリスト密度であり、プログラムテスト時のチェックリストの密度を表す。チェックリストは、プログラムが正常に動作しているかを確認するために使用するテスト項目の一覧である。２１５は、チェックリスト基準値であり、チェックリストの基準となる範囲を表す。２１６は、バグ密度であり、プログラムのテスト時に発生したバグの密度を表す。２１７は、バグ基準値であり、バグの基準となる範囲を表す。２１８は、品質判定であり、バグ密度が基準値から外れているかどうかを表す。２１９は、品質対策状況であり、品質の悪いプログラムに対する対策を行ったかどうかを表す。
【００１４】
図３は、プロジェクト管理情報取得および配布のフローチャートである。処理ブロック３１では、ソフトウェア開発時における成果物の登録を行う。処理ブロック３２では、管理対象のプロジェクトの成果物情報を取得する。処理ブロック３３では、取得した情報から、プロジェクト管理情報を作成する。判断ブロック３４では、進捗情報または品質情報が基準値内かどうかの判断を行う。処理ブロック３５では、進捗または品質が基準値を外れている場合にエラー情報の表示を行う。処理ブロック３６では、プロジェクト管理表の作成を行う。判断ブロック３７では、進捗または品質が基準値を外れている場合に対策を行うかどうかの判断を行う。処理ブロック３８では、進捗・品質を改善する対策案を作成する。
【００１５】
図４は、図３における進捗が遅れているプログラムに対策を施す場合の詳細フローチャートである。処理ブロック４１では、プロジェクト管理ファイルからプログラムの完了予定日および完了日を取得する。判断ブロック４２では、計画表に記載された完了予定日に対して遅れているかどうかを判定する。図２の例では、完了予定日と、完了日を比較すると、プログラムＢは計画に対して完了日が後であるため、プログラムＢを遅れていると判定する。処理ブロック４３では、プログラムの完了日が、完了予定日と比較して遅い場合には、エラー表示を行う。表示方法は、遅れの度合によって、複数のランクを設定可能とする。遅れているプログラムの表示は、文字が大きくなる、色を変えるなど、他と区別して表示・出力される。処理ブロック４４では、進捗が遅れているプログラムの対策案を少なくとも一つ作成する。
【００１６】
対策案は、原因を調査するレビューの実施、有識者の追加、作業時間の延長など、複数案の雛形を用意しておき、どの対策案を優先させるかを設定可能とする。処理ブロック４５では、管理者および作業者に作業指示を発行する。対策を発行した場合には、プロジェクト管理表に履歴を残す。処理ブロック４６では、プロジェクト管理ファイルからプログラム作成時のチェックリスト密度とバグ密度を取得する。判定の基準となる値は、過去に開発されたプロジェクトの成果物から、プログラム作成時のバグ密度やチェックリスト密度の基準を設定しておき、これを品質基準値と呼ぶこととする。判断ブロック４７では、品質基準値のチェックリスト密度と実際のチェックリスト密度を比較し、バグ密度と実際のバグ密度を比較し、品質が基準値を外れているかどうかを判定する。
【００１７】
図２の例では、プログラムＢのバグ密度が基準値を外れているため、品質に問題ありと判定する。処理ブロック４８では、品質の悪いプログラムには、エラー表示を行う。基準を外れている度合は、複数のランクを設定可能とする。処理ブロック４９では、品質が悪いプログラムの対策案を少なくとも一つ作成する。ここでは、類似バグの検出を設定している。対策には、類似バグの検出、チェックリストの追加等、複数案の雛形を用意しておき、どの対策案を優先させるかを選択可能とする。図２の例では、品質が悪いと判定した原因はプログラムＢのバグであるため、類似バグの検出を対策とする。処理ブロック４１０では、管理者および作業者に作業指示を発行する。対策を発行した場合には、プロジェクト管理表に履歴を残す。
【００１８】
【発明の効果】
以上の本発明によれば、進捗の遅れや品質の悪いことで開発作業に支障が出ないように、危険がある箇所を早期に発見し、解決の手助けを行うとともに、複数の拠点に対してどこに命令を出すかを自動的に判定し、対策案も見積もることができるので、タイムラグが生じることが無く、管理作業の負荷を軽減することができる。また、進捗・品質管理作業をフィードバックしていくことにより、システム全体の管理者は、システムの新規構築時からソフトウェアのバージョンアップ時まで、仕様書やプログラム等の成果物および、何らかの対策を施した更新情報を総合的に管理できる。
【図面の簡単な説明】
【図１】本発明の実施例を示す構成図である。
【図２】プロジェクト管理ファイルの例を示す図である。
【図３】プロジェクト管理情報取得および配布のフローチャートである。
【図４】進捗対策および品質対策発行のフローチャートである。
【符号の説明】
１１ 作業計画
１２ 設計書
１３ プログラムソース
１４ テスト情報
１５ 障害情報
１６ 作業者端末
１７ プロジェクト情報取得・集計手段
１８ プロジェクト情報考察・判定手段
１９ プロジェクト情報提案・配布手段
１１０ プロジェクト管理ファイル
１１１ プロジェクト管理表
１１２ 進捗基準値
１１３ 品質基準値
１１４ 進捗改善対策情報
１１５ 品質改善対策情報
１１６ 管理者端末
２１ プログラムＩＤ
２２ 完了予定日
２３ 設計書新規登録日
２４ 設計書更新日
２５ プログラム新規登録日
２６ プログラム更新日
２７ テストカバレジ情報新規登録日
２８ テストカバレジ情報更新日
２９ プログラム完了日

Claims (2)

1. ソフトウェア開発において作業計画と設計書と成果物とテスト情報と障害情報とを格納する手段を設け、前記格納情報から進捗情報及び品質情報を取得してプロジェクト管理情報として格納する手段と、プロジェクト管理情報を用いてプロジェクト管理表を作成する手段とを有し、成果物の進捗を評価して評価結果が基準値を外れているプログラムを判定する手段と品質を評価して評価結果が基準値を外れているプログラムを判定する手段とのうち少なくとも１つを備え、前記判定結果を表示する手段を備えることを特徴とするプロジェクト管理システム。
2. 請求項１に記載のプロジェクト管理システムにおいて、上記成果物の進捗を評価判定する手段を備えた時は進捗の回復のための対策案生成手段を備え、上記成果物品質を評価判定する手段を備えた時は品質の改善のための対策案生成手段を備え、対策案を表示する手段を備えることを特徴とするプロジェクト管理システム。

Images