JPH06332911A

JPH06332911A - プロジェクト進捗管理方式

Info

Publication number: JPH06332911A
Application number: JP11995493A
Authority: JP
Inventors: Yoshiyasu Sasage; 佳保捧; Masamitsu Fukusako; 正光福迫
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1993-05-21
Filing date: 1993-05-21
Publication date: 1994-12-02

Abstract

(57)【要約】【構成】計画設定手段１０は工程計画値（作業着手
日、作業完了日等）及び品質目標値（ＤＲ件数、ＣＲ件
数、試験項目数、誤り検出件数等）を設定する。基準設
定手段３０は工程評価基準（遅れ度合い等）及び品質評
価基準（目標達成度合い等）を設定する。実績収集手段
２０は作業実績（着手日／完了日、作業実績量、デザイ
ンレビュ件数、コードレビュ件数、試験項目数、誤り検
出件数等）を収集する。比較部４０は計画値（または目
標値）と作業進捗時に収集された作業実績値との比較結
果を得る。評価部５０は比較結果を各基準値（工程／品
質）に照らして評価結果を得る。また、目標を達成する
ためのガイド値を自動算出し出力する。評価結果は定量
的数値とメッシュの濃淡（または色）で自動出力する。【効果】工程と品質の両方の目標／実績対比評価が容
易に行える。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は例えばソフトウェアシ
ステム開発プロジェクトにおいて、ソフトウェア工程進
捗管理における目標／実績対比評価装置に関するもので
ある。

【０００２】

【従来の技術】

従来例１．図２２は特開平４−１４１７６７号公報に示
された従来のプロジェクト進捗管理方式を示す図であ
る。図２２においては、プロジェクト開発の進捗管理を
行うために、プロジェクトリーダ及び開発要員がプロジ
ェクトに関するデータを入力するための端末１，２と、
その進捗管理の処理を行うためのホストコンピュータ３
とを有するプロジェクト進捗管理方式において、プロジ
ェクトに関するデータを入力する前記端末上のデータ入
力手段４，７と、前記ホストコンピュータ及び前記端末
間のデータの送信及び受信を行う前記端末上のデータ送
受信手段５，８と、プロジェクトの進捗状況を表示する
前記端末上のデータ表示手段６，９と、前記端末からプ
ロジェクトに関するデータを受信する前記ホストコンピ
ュータ上のデータ受信手段１０と、進捗率算出用の基礎
データを記憶する前記ホストコンピュータ上の進捗率算
出データ記憶手段１１と、前記データ受信手段で受信し
たプロジェクトに関するデータを、進捗率算出用基礎デ
ータとして編集し、前記進捗率算出データ記憶手段に書
き込む前記ホストコンピュータ上の進捗率算出データ編
集・書込手段１２と、各開発工程の工程比率を保持する
前記ホストコンピュータ上の工程比率記憶手段１３と、
前記進捗率算出データ記憶手段上の進捗量に関する情報
及び前記工程比率記憶手段上の工程比率の情報をもと
に、プロジェクトの進捗率を算出する前記ホストコンピ
ュータ上のプロジェクト進捗率算出手段１４と、前記プ
ロジェクト進捗率算出手段により、得られた進捗データ
を記憶する前記ホストコンピュータ上の進捗データ記憶
手段１５と、前記進捗データ記憶手段上の進捗の予定及
び実績並びに所要工数の予定及び実績に関する情報を参
照して比較することにより現在のプロジェクト進捗状況
を判定し、必要によりアラーム情報を付加する前記ホス
トコンピュータ上の進捗状況アラーム判定手段１６と、
前記進捗データ記憶手段上の進捗状況の情報を参照し
て、前記端末にグラフ形式で出力するデータの生成を行
う前記ホストコンピュータ上のグラフ生成手段１７と、
前記グラフ生成手段による生成結果のデータを、前記端
末側へ送信する前記ホストコンピュータ上のデータ送信
手段１８とを有することを特徴とするプロジェクト進捗
管理方式を示している。このプロジェクト管理方式はプ
ロジェクトリーダ及び開発要員が端末からプロジェクト
に関するデータを入力するだけで正確なプロジェクトの
進捗状況がグラフ形式でタイムリーに把握でき、しかも
プロジェクトの進捗状況によっては注意を要すると思わ
れるプロジェクトについて自動的に注意を促すことがで
きる。

【０００３】従来例２．次に図２３は特開平２−２０８
７４５号公報に示されたソフトウェアシステム開発障害
管理方式を示す図である。このソフトウェアシステム開
発障害管理方式は、ソフトウェアシステム開発の総合試
験段階において、障害発生日付、発生モジュール名、障
害識別等を含む障害発生情報ファイル１と、試験実施計
画／実績の日付や件数、試験対象機能区分等を含む試験
実施情報ファイル２と、モジュール構成、新規／流用ス
テップ数等を含む試験対象ソフトウェア情報ファイル３
とを用いることを特徴とするソフトウェアシステム開発
障害管理方式である。障害発生情報ファイル１には発生
した障害毎に少なくとも受付番号、障害発生日付、発生
機種名、障害件名、障害処置日付、障害処置区分、誤り
発生モジュール名、誤り発生段階、誤り発生区分、誤り
見逃し理由、処置確認日付を格納し、試験実施情報ファ
イル２には試験実施計画日付毎に少なくとも試験対象機
能区分、試験実施計画件数、試験実施実績件数を格納
し、試験対象ソフトウェア情報ファイル３には対象ソフ
トウェアの構成モジュール毎に少なくとも新規作成ステ
ップ数、流用ステップ数、呼び出しモジュール名を格納
する。障害分析手続きプログラム４では、障害発生情報
ファイル１の発生機種名、障害発生日付、障害処置日付
と、試験実施情報ファイル２の試験実施計画日付、試験
実施計画件数、試験実施実績件数から、試験計画に対す
る実施実績の進捗状況と障害処置進捗状況、障害処置確
認進捗状況が得られる。また、障害発生情報ファイル１
の発生機種名、誤り発生モジュール名と、試験対象ソフ
トウェア情報ファイル３の構成モジュール名、新規作成
ステップ数、流用ステップ数、呼び出しモジュール名か
ら、モジュール別誤り頻度や誤り波及予測分析ができ
る。更にまた、試験実施情報ファイル２の試験実施実績
件数、試験対象機種区分と、試験対象ソフトウェア情報
ファイル３の新規／流用ステップ数、呼び出しモジュー
ル名から、モジュール別試験密度分析や未試験モジュー
ル分析ができる。

【０００４】従来例３．図２４は従来のプロジェクト開
発進捗工程を示すための従来の工程進捗管理表を示す図
である。図において横軸は年月を示し、縦軸はこのプロ
ジェクトにより開発されるべき項目として、機能Ａ、機
能Ｂを示している。この従来の工程進捗管理表には計画
時に作成したバーチャート上に個々の作業進捗実績デー
タに基づく進捗度合いを稲妻線として記入する。進捗度
合いが進んでいる場合には稲妻線の凸部は図において右
向きを示し、進捗度合いが遅れている場合には図におい
て稲妻線の凸部が左向きを示して記入される。このよう
な従来の工程進捗管理表はバーチャート上の稲妻線によ
る計画／実績対比のため評価判定に時間を要する。ま
た、作業品質の確保に裏付けられた実質の工程進捗評価
ができていないという問題がある。

【０００５】

【発明が解決しようとする課題】従来例１に示したプロ
ジェクト進捗管理方式は工程面に注目してプロジェクト
の進捗を管理する方式である。また、従来例２に示した
障害管理方式は特に品質面に注目した管理方式である。
プロジェクトを遂行するにあたっては、プロジェクトの
進捗を管理することと、プロジェクトを遂行した結果、
目的となる対象物の品質が一定以上のものであるという
品質を管理することの２つの点が注目されなければなら
ない。それに対して従来のプロジェクト進捗管理方式は
前述したように工程面のみに注目したものあるいは品質
面のみに注目したものが知られているが、その両方の面
からプロジェクトを評価する管理方式というものが存在
していない。即ち、プロジェクトを遂行するにあたり、
工程進捗状況と、各工程から出力されるソフトウェアや
ハードウェアの品質との両方が初期の計画を達成してい
るかどうかが重要なものであり、一方を度外視して他方
を実行し続けることはできない。

【０００６】この発明は上記のような問題点を解決する
ためになされたものであり、工程面と品質面の両面に渡
ってプロジェクトの進捗を管理できるプロジェクト進捗
管理方式を得ることを目的とする。

【０００７】

【課題を解決するための手段】第１の発明に係るプロジ
ェクト進捗管理方式は、計画値（工程／品質）と工程進
捗段階で収集された各実績値（工程／品質）との差異を
基準値に照らして比較評価し、結果を出力するものであ
り、以下の要素を有するものである。（ａ）プロジェクトの工程計画と、各工程が目的とする
対象の品質目標とを設定する計画設定手段、（ｂ）各工
程の作業実績と、その作業実績に基づく対象の品質実績
とを収集する実績収集手段、（ｃ）プロジェクトの各工
程とその対象の品質とを評価する評価基準を設定する基
準設定手段、（ｄ）上記計画設定手段により設定した工
程計画と品質目標と、上記実績収集手段により収集した
作業実績と品質実績とをそれぞれ比較する比較手段、
（ｅ）上記比較手段により比較した結果を、上記基準設
定手段により設定した評価基準により評価しその評価結
果を出力する評価手段。

【０００８】また第２の発明に係るプロジェクト進捗管
理方式は、上記評価手段が評価結果を工程と品質を対に
して出力することを特徴とするものである。

【０００９】また第３の発明に係るプロジェクト進捗管
理方式は、評価結果として定量的数値を出力するととも
にその値に対応するあらかじめ定められたメッシュの濃
淡、あるいはあらかじめ定められた色をその定量的数値
上あるいはその定量的数値の近傍に出力することを特徴
とするものである。

【００１０】また第４の発明に係るプロジェクト進捗管
理方式は、上記評価手段が品質評価の結果品質目標未達
成のものがある場合に各工程毎に品質目標を達成する為
のガイドを出力することを特徴とするものである。

【００１１】

【作用】第１の発明に係るプロジェクト管理方式は、計
画設定手段、実績収集手段、基準設定手段がともにプロ
ジェクトの工程と各工程が対象としている目的物の品質
の両方の計画値、実績値、基準値の各情報を設定あるい
は収集する。比較手段及び評価手段は上記計画設定手
段、実績収集手段、基準設定手段により設定された計画
値、実績値、基準値に基づいて工程と品質の両面につい
て比較評価を行い、その評価結果を出力する。従って、
プロジェクトの進捗を工程と品質の両面に渡って管理す
ることが可能になる。

【００１２】第２の発明におけるプロジェクト進捗管理
方式は、評価手段が工程と品質を対にして表示する。例
えば工程と品質の評価結果を表にすることにより、ある
いは工程と品質の評価結果をグラフにすることにより、
工程と品質を関連させて理解することが可能になる。

【００１３】第３の発明におけるプロジェクト進捗管理
方式は、評価手段による出力方法として定量的数値の他
に視覚的に識別可能な網掛けや色による識別を行えるの
で定量的数値による具体的な値を知ることができると同
時に視覚的に訴えられる識別表示により評価の傾向が即
座に理解することが可能になる。

【００１４】第４の発明におけるプロジェクト進捗管理
方式は、評価手段の品質評価の結果目標未達成がある場
合には、各工程毎に品質目標を達成するためのガイドを
出力するためそのガイドに従って作業を行うだけで品質
の目標を達成することが可能になる。また、どの工程を
重点的にやり直す必要があるかが判断できる。あるい
は、目標達成のための作業負荷量見積りが容易になる。

【００１５】

【実施例】

実施例１．図１はこの発明に係るプロジェクト進捗管理
方式の一実施例を示す図である。この実施例において
は、ソフトウェア開発工程進捗管理における目標／実績
対比評価装置を例にして説明する。図において１１は工
程計画値と品質目標値を入力する計画値入力部である。
１２は計画値入力部から入力した情報を工程計画値１３
及び品質目標値１４として記憶する計画値記憶部であ
る。この計画値入力部１１と計画値記憶値１２により計
画設定手段１０を構成している。２１は作業実績値と品
質実績値を入力する実績値入力部である。２２は実績値
入力部２１が入力した工程実績値２３と品質実績値２４
を記憶する実績値記憶部である。実績値入力部２１と実
績値記憶部２２により実績収集手段２０を構成してい
る。３１は工程評価基準と品質基準を入力する基準値入
力部である。３２は基準値入力部３１が入力した工程評
価基準３３と品質評価基準３４を記憶する基準値記憶部
である。基準値入力部３１と基準値記憶部３２により基
準設定手段３０を構成している。４０は計画値記憶部１
２に記憶された情報と実績値記憶部２２に記憶された情
報を比較する比較部である。５０は比較部４０からの比
較結果と基準値記憶部３２に記憶された評価基準を比較
し、評価結果として目標／実績対比評価表６０を出力す
る評価部である。５１は評価部５０の評価の結果、品質
目標が未達成かどうかを判断する判断部である。品質目
標が未達成の場合、判断部５１は目標達成ガイド７０を
出力する。

【００１６】次に動作について説明する。計画値入力部
１１は作業着手日、作業完了日等の工程計画値を入力
し、計画値記憶部１２はこれらを工程計画値１３として
記憶する。また、計画値入力部１１は計画値としてのデ
ザインレビュ件数（ＤＲ件数）、コードレビュ件数（Ｃ
Ｒ件数）、試験項目数、誤り検出件数等の品質目標値を
入力し、計画値記憶部１２はこれらを品質目標値１４と
して記憶する。また実績値入力部２１は着手日及び完了
日、作業実績量を入力し、実績値記憶部２２はこれらを
工程実績値２３として記憶する。また実績値入力部２１
は（実際に発生した）デザインレビュ件数、コードレビ
ュ件数、試験項目数、誤り検出件数等を入力し、実績値
記憶部２２はこれらを品質実績値２４として記憶する。

【００１７】図２、図３、図４は計画値入力部１１及び
実績値入力部２１が入力する情報の一例を示す図であ
る。図２はプロジェクトが機能Ａ，Ｂ，Ｃ，・・・とい
うように複数の機能に分けられてそれぞれ遂行される場
合の機能Ａの設計フェーズの計画値の設定及び実績の収
集に用いられる情報を示している。また、図３は同様に
機能Ａの製作フェーズの計画値の設定及び実績収集に用
いられる情報を示している。更に、図４は同様に機能Ａ
の試験フェーズの計画値の設定及び実績収集に用いられ
る情報を示している。各図とも横軸は年月と週単位の日
付が用いられている。なお、この例では週単位である
が、週単位に限定する必要はない。この単位は日単位で
も２週間単位でもプロジェクトによって変えてよい。一
方、縦軸は機能Ａに含まれるプログラム名Ａ１，Ａ２が
示されている。例えば、プログラムＡ１を例にして説明
すると、プログラムＡ１に対して予定と週実績と合計と
実績の４つの情報を記入する。予定の欄にはプログラム
Ａ１の仕様書のページ枚数が記入される。例えば、図２
に示すように、９２年６月の第１週には１０ページの仕
様書を作成することが予定として記入され、第２週及び
第３週にはそれぞれ２０ページの仕様書が作成される予
定であることが記入される。また合計欄にはこれらの仕
様書の累積ページ数が記入される。従って、第１週に１
０ページ、第２週に３０ページ、第３週に５０ページと
いう仕様書の累積ページ枚数が記入される。計画値入力
部１１はこれらの情報を入力し、工程計画値１３として
入力する。

【００１８】次に、実際にプロジェクトが開始され作業
実績が発生した場合には、週単位にその実績が記入され
る。例えばプログラム名Ａ１に対しては９２年６月の第
１週には８ページの仕様書が完成したことを記入する。
また第２週には２０ページ、第３週には１５ページの仕
様書が完成したことを記入する。また、実績にはその累
積値が記入され、第１週に８ページ、第２週に２８ペー
ジ、第３週に４３ページの仕様書が作成されたことが記
入される。これらの実績値は実績値入力部２１から入力
され、工程実績値２３として記憶される。

【００１９】また、図２の右端に示した実績（見通し）
は作成すべき仕様書のページ枚数を記入する。またＤＲ
の欄には作成された仕様書のレビュを行った結果指摘さ
れた件数（以下、この件数のことをデザインレビュ件
数、あるいはＤＲ件数と呼ぶ）を記入する。また見通し
の欄にはこの仕様書を完成する予定の日付を記入する。
プログラムＡ１の場合は、図２に示すように、仕様書の
ページ枚数が５０であり、デザインレビュ件数が５件で
あり、仕様書を完成すべき日付が６月１９日であるとい
うことが記入されている。このページ枚数５０と見通し
６月１９日は工程計画値１３として計画値入力部１１よ
り入力される。また、デザインレビュ件数５は品質実績
値２４として実績値入力部２１から入力される。

【００２０】次に図３について説明する。前述した設計
フェーズに続く製作フェーズの工程計画値及び工程実績
値及び品質実績値が記入される。例えば、プログラムＡ
１を例にすると、図３に示すように、第１週目に１００
ステップ、第２週目に２００ステップ、第３週目に２０
０ステップのコーディングが行われる予定に対して、実
際の実績としては第１週目に５０ステップ、第２週目に
２５０ステップ、第３週目に２５０ステップのコーディ
ングが行われたことが記入され、合計実績にはそれぞれ
の累積値が記入される。計画値入力部はこれらの計画値
を入力するとともに、実績値入力部はそれぞれの実績が
わかった時点で週単位にその実績を入力する。

【００２１】また、図３の右端における実績（見通し）
の欄にはプログラムＡ１の合計ステップ数と作成された
プログラムのコードをレビュした結果指摘された件数
（この件数をコードレビュ件数、あるいはＣＲ件数とい
う）と、このプログラムＡ１の作成を終える見通しの日
付を記入する。このステップ数及び見通しは計画値入力
部から工程計画値１３として入力される。一方、コード
レビュ件数は実績値入力部から品質実績値２４として入
力される。

【００２２】次に図４は前述した機能ＡのプログラムＡ
１、Ａ２に対する試験フェーズの予定と週実績を示す情
報であるが、その記入方法は前述した図２、図３と同様
であるためここではその説明を省略する。なお、図４の
右端にある実績（見通し）のうち項目とは試験を行うた
めの項目の合計数を示している。また障害検出の欄は試
験を行った結果障害が検出された件数を示している。ま
た見通しは試験を終了する予定日を記入する欄である。
障害検出の数は品質実績値２４として実績値入力部２１
から入力される。

【００２３】次に図５〜図８を用いて品質目標値１４の
具体例について説明する。図５、図６、図７、図８は、
計画値入力部１１から入力され、計画値記憶部１２に記
憶される品質目標値１４の一例を示す図である。

【００２４】図５に示すように、システム生産量として
プログラムの総ライン数、新規に開発する新規量、以前
から存在するコードを流用する流用量及び他のシステム
から移行してくる移行量の各ライン数の計画値を設定す
る。

【００２５】次に図６、図７、図８は生産品質管理項目
とその基準を示す図であり、図６、図７、図８は左から
右に連続してソフトウェア開発工程を示しているもので
ある（ここでは、図面上３つの図に分割して記入してい
る）。生産ステップナンバーは１から１０までふられて
おり、それぞれに対応してソフトウェアが作られる生産
ステップを示している。それぞれの生産ステップに対応
して管理項目及び管理目標値というものを定めている。

【００２６】レビュ実施網羅度としてレビュ実施ドキュ
メント数が全ドキュメント数に占める割合を示してい
る。レビュ実施網羅度は社員でレビュを実施する場合
と、外注先で実施する場合に分かれている。例えば生産
ステップナンバー４のソフトウェア設計についてこのレ
ビュ実施網羅度を見てみると社員で実施する場合が０．
３であるため、目標としては全体の３割を社員でドキュ
メントレビュを行うということを示している。また、同
じく生産ステップナンバー４のソフトウェア設計におい
てレビュ実施網羅度を見ると外注先での実施が１．０と
なっているため、外注先において全てのドキュメントを
レビュすることを目標としている。

【００２７】次に、客先承認網羅度は全仕様書数のうち
客先から承認を得なければならない仕様書数を示してお
り、生産ステップナンバー３のシステム設計については
作成した仕様書を全て客先から承認を得なければならな
いことが目標値として定められている。

【００２８】次に、レビュでの指摘率が管理項目として
あげられている。このレビュでの指摘率とは２種類の指
摘率があり、図中＊１で示されるものはこのシステムで
生産される１キロラインあたりのレビュ指摘件数を示し
ており、図中＊２で示される値は新規に開発される１キ
ロラインあたりのレビュ指摘件数を示している。前述し
た図２に示す設計フェーズにおいては仕様書のページ枚
数を単位としていたが、仕様書のページ枚数と図３に示
したように総ステップ数がわかっているため、図２に示
したデザインレビュ件数は１キロラインあたりのデザイ
ンレビュ件数に変換することが可能である。

【００２９】このようにして図２、図３、図４に示した
デザインレビュ件数、コードレビュ件数は１キロライン
あたりのレビュ指摘件数に変換して用いることが可能で
ある。従って、図６、図７、図８に示す品質の目標値に
は１キロラインあたりのレビュ指摘件数を用いることが
可能になる。例えば生産ステップナンバー３のシステム
設計においては、レビュでの指摘率が５と記入されてい
るため１キロラインあたりのデザインレビュ件数は５件
であることを目標としている。同様に生産ステップナン
バー４のソフトウェア設計を行う場合にはレビュでの指
摘率が１０と記入されているため１キロラインあたりの
デザインレビュ件数は１０件であることを示している。

【００３０】なお、図中＊１あるいは＊２に示したよう
にシステム全体のコードから判断する指摘率と、新たに
作成するコードのみから算出する指摘率を用いるのはシ
ステム全体を考えた場合には新規作成する以外に流用す
る場合あるいは移行してくる場合があるため新規にプロ
グラムを開発する場合と比べて異なる目標値を掲げるこ
とが妥当である場合のことを考慮しているからである。
各生産ステップにおいて何れか適当と思われる方を選択
して用いることができる。例えばシステム設計、ソフト
ウェア設計においてはシステム全体のものから計算され
たレビュ指摘件数を用いるのに対してプログラム設計の
場合には新規にコーディングされたものから計算された
レビュ指摘件数を用いている。

【００３１】次に試験網羅度は試験すべき項目としてあ
げた件数を記入する。例えば、システム試験設計におい
ては試験網羅度を１０としており、ソフトウェア試験設
計においては試験網羅度を３０としておりプログラム試
験設定においては試験網羅度を６０としている。これら
はシステム試験あるいはソフトウェア試験あるいはプロ
グラム試験を行う場合には１キロラインあたり１０項目
または３０項目または６０項目の試験を行うべきことを
示している。なお、この試験網羅度に対してもシステム
全体から計算された試験網羅度と、新規コーディングさ
れたものから計算された試験網羅度の２種類のもの（＊
１、＊２）がある。

【００３２】次に試験での誤り検出率が管理目標値とし
て記入される。図４に示した障害検出の件数は図３に示
したように総ステップ数がわかっているため、１キロラ
インあたりの障害検出数を計算することが可能である。
この試験での誤り検出率は実際にプログラム試験、ソフ
トウェア試験、システム試験を行った結果、１キロライ
ンあたりに発見される誤り件数（図４の障害検出の件数
に相当）の目標値を記入するものである。前述した試験
網羅度は１キロラインあたりに試験をすべき件数の目標
値を定めているのに対して、この試験での誤り検出率は
１キロラインあたりに検出すべき誤りの件数の目標値を
掲げているものである。例えばシステム試験設計におい
て試験網羅度は１０と記入されており、システム試験に
おいて試験での誤り検出率が１と記入されているのは、
システム試験において１０項目の試験を行うことを目標
としており、その結果、誤り件数を１件見つけるという
ことを目標にしているものである。同様にプログラム試
験設計において試験網羅度が６０と記入されており、プ
ログラム試験において試験での誤り検出率が１０と記入
されているのは６０項目の試験を行い、そのうち１０件
の項目について誤りを検出することを目標としているも
のである。以上説明したように図５、図６、図７、図８
に示した目標値は計画値入力部１１から品質目標値１４
として入力され計画値記憶部１２に記憶される。

【００３３】次に基準値入力部３１が入力する工程評価
基準３３と品質評価基準３４の具体例について図９を用
いて説明する。図９（１）は工程評価基準を示す図であ
る。工程評価基準は「工程遅れなし」、「１週間以内の
遅れ」、「１週間から２週間以内の遅れ」、「２週間以
上の遅れ」というような４つの基準を設けている。そし
てこの例では、工程の遅れが大きくなるに従ってそれぞ
れの基準に対して視覚的にその遅れが認識できるような
表示としてメッシュに濃淡をつけて表示する。例えば
「工程遅れなし」においてはメッシュをなしにする。
「１週間以内の遅れ」に対しては薄いメッシュを用い
る。「１週間から２週間以内の遅れ」対しては普通のメ
ッシュを用いる。「２週間以上の遅れ」に対しては濃い
メッシュを用いる。

【００３４】次に図９（２）は品質評価基準の一例を示
している。品質評価基準は目標達成率で表されている。
目標達成率が８０％から１２０％の場合には品質が基準
以内であるとする。また目標達成率が６０％から８０％
または目標達成率が１２０％から１４０％の場合には目
標が少しずれていると判断する。このように目標達成率
は８０％を下回ってもいけないし、あるいは１２０％を
上回ってもいけないと設定される。同様に目標達成率が
しだいに目標達成率の８０％、１２０％から離れるに従
って品質評価基準としてしだいに悪くなる基準を設けて
いる。また、前述したように目標達成率が８０％から１
２０％の場合には表示する場合にメッシュを何も表示せ
ず目標達成率がしだいに悪くなるに従って薄いメッシュ
から濃いメッシュを用いて表示する。

【００３５】次に図９（３）は対策の必要性の評価基準
を示している。工程が２週間以上遅れている場合または
品質の目標達成率が０％から２０％または１８０％以上
の場合にはなんらかの対策が必要であるという基準を設
ける。また工程が２週間以内の遅れであり、あるいは品
質の目標達成率が２０％から８０％の場合または１２０
％から１８０％の場合には対策が必要であろうという評
価基準を設ける。更に工程の遅れがない場合、あるいは
品質の目標達成率が８０％から１２０％の場合には対策
の必要がないという評価基準を設ける。それぞれの評価
基準に対応して対策が必須の場合には○の記号を用いて
表示する。また対策が要と判断されたものには△の記号
を用いて表す。対策が不要と判断された場合には何も表
示しない。以上図９に示した各基準は基準値入力部３１
から入力され、基準値記憶部３２においてそれぞれ工程
評価基準３３及び品質評価基準３４として記憶される。

【００３６】次に比較部４０の動作について説明する。
比較部４０は前述したような工程計画値と品質目標値を
それぞれ工程実績値と品質実績値と比較する。例えば、
図２に示したプログラムＡに対する工程目標値が１０，
２０，２０と定められているのに対して週実績が８，２
０，１５と入力され記憶されている場合、これらの値を
比較してその達成具合あるいは遅れを算出する。

【００３７】また、図２のデザインレビュ件数が５と入
力して実績入力部から品質実績値２４として入力されて
おり、図７に示したプログラム設計のレビュでの指摘率
が２０と設定されていることから、比較部４０は図２に
示したデザインレビュ件数を１キロラインあたりのデザ
インレビュ件数に変換した後、図７のプログラム設計の
目標値として定められたレビュでの指摘率２０との比較
を行う。また図３に示す製作フェーズにおいてはプログ
ラムＡ１に対して目標値が第１週に１００ステップ、第
２週に２００ステップ、第３週に２００ステップと計画
値が入力されているのに対して、実績が５０，２００，
２５０と入力される場合比較部４０はこれらの値を比較
して工程の遅れ度合いを比較算出する。また、図３のコ
ードレビュ件数を１キロラインあたりに換算しなおして
図７のコーディングに示すレビュでの指摘率に示された
値２０と比較する。このように比較部４０は図２、図
３、図４に示したデザインレビュ件数及びコードレビュ
件数及び障害検出件数を品質実績値２４として入力し、
図６、図７、図８に示す管理目標値と比較することによ
り品質の目標達成率を計算する。

【００３８】次に、評価部５０の動作について説明す
る。評価部５０は比較部４０からの比較結果と基準値記
憶部３２に記憶された工程評価基準３３と品質評価基準
３４を用いて評価結果を出力する。図１０から図１６は
評価部５０が評価の結果、出力する目標／実績対比評価
表６０のいくつかの例を示す図である。

【００３９】図１０はソフトウェア試験工程進捗評価表
を示している。図において縦軸はソフトウェアの機能数
を１００とした場合の達成率を示している。また図にお
いて横軸は各月と各週を表している。各週に記載された
数字は、各週の着手予定の数と着手した実績数である。
また、各週の完了予定数及び完了実績数である。グラフ
は着手したものの累積値を示している。このグラフは要
領書作成着手と完了について示している。またその試験
に対する着手と完了を示している。

【００４０】次に図１１は機能Ａとその機能を構成して
いる５つのプログラムＡ１からＡ５に対する工程進捗状
況と品質状況を示している。機能Ａ全体に対しては機能
毎の品質状況が表示される。機能毎の品質状況には、デザインレビュ指摘率コードレビュ指摘率試験密度誤り率ヒット率の各状況が矢印あるいは＊で表示されている。図１１の
ＤＲ指摘率は図６に示したレビュでの指摘率のうちのデ
ザインレビュに相当するものである。また図１１のＣＲ
指摘率は図６に示したレビュでの指摘率のコードレビュ
に相当するものである。また図１１の試験密度は図６に
示した試験網羅度に相当するものである。更に図１１の
誤り率は図６に示した試験での誤り率検出率に相当する
ものである。次に図１１のヒット率は試験密度に対する
誤り率の比率を示すものである。例えば試験密度が１キ
ロラインあたり１０項目あり、その誤り率が１キロライ
ンあたり５項目あった場合にはヒット率は５０％とな
り、ヒット率が評価基準よりも上回っている場合にはヒ
ット率が目標値よりも上回っているということが表示さ
れる。

【００４１】各表示には矢印が用いられるが矢印が上向
きにある場合には目標の範囲を超えた方向で目標が達成
されていないということを示しており、矢印が下を向い
ている場合には目標未達成であるということを示してい
る。また＊は目標を達成していることを（即ち８０％か
ら１２０％であることを）示している。また機能毎の品
質状況の下に記入された７１２件という値は残りの誤り
件数を示している。この残りの誤り件数は以下のような
計算式で求めることができる。残りの誤り件数＝（総ステップ数／１０００）×誤り率
−現在までの誤り件数誤り率を１キロラインあたり３５件とし、総ステップ数
を８２３９９とし、現在までにわかっている誤り件数を
２１７２とすると、残りの誤り件数即ち今後発見される
であろう誤り件数は、（８３２９９／１０００）×３５−２１７２＝７１２となり、今後発見されるであろう残りの誤り件数を算出
することが可能である。

【００４２】また、図１１は各プログラムＡ１からＡ５
に対応してそれぞれの工程進捗状況を示している。プロ
グラムの設計、プログラムの作成、プログラムの試験そ
れぞれについて開始、進捗、完了という項目を設け、そ
れぞれの工程に対して完了した場合には○印を記入して
いる。またそれぞれが完了した場合においてどのような
遅れ具合で完了したかメッシュの濃淡により表示してい
る。例えばプログラムＡ１について見てみるとプログラ
ム設計、プログラム製作は予定通り完了しており、プロ
グラムの試験の開始は予定通り開始できたが進捗状態か
ら遅れ完了も２週間以上遅れたということがこの進捗状
況から把握することができる。

【００４３】また、図１１はプログラムＡ１からＡ５の
品質状況についても表示している。プログラムの設計、
プログラムの製作、プログラムの試験について項目を分
けて品質を管理する。プログラム設計については設計仕
様書のページ数と１キロラインあたりのページ数とデザ
インレビュ件数と１ページあたりのデザインレビュ件数
を表示する。またプログラム製作については、プログラ
ムのステップ数とコードレビュ件数と１キロラインあた
りのコードレビュ件数を表示する。更にプログラム試験
については試験項目数と１キロラインあたりの項目数を
表示するとともにその試験の結果発見された誤り件数と
１キロラインあたりの誤り件数を表示する。また、これ
らの表示を定量的数値で表示するとともに品質評価の結
果、目標未達成のもの及び許容範囲以外のものをメッシ
ュを用いて視覚的に一目できるように表示している。

【００４４】また、開発が終了していないものに対して
は日付を記入したり試験中という状態を記入している。
図においてはプログラムＡ５のプログラム試験が未完了
であり、その予定日として９月７日という日付が記入さ
れている。またプログラム試験の品質状況においては試
験中という状況が表示されている。

【００４５】この図１１で特徴となる点は工程進捗状況
と品質状況を１つの表に表示している点である。またそ
の表示方法として評価基準とのズレを示すため視覚的に
判別が容易に可能なメッシュを用いて表示している点で
ある。

【００４６】次に図１２は各機能毎の目標／実績対比評
価表の一例を示す図である。図１２は機能Ａから機能Ｅ
までの目標達成率と対策の必要性を示す図である。目標
達成率には工程と品質の両方が表示されている。図中、
メッシュの濃淡を用いて工程の進捗度合い及び品質の達
成度合いが示されている。このメッシュは図９に示した
各工程評価基準及び品質評価基準に割り当てられたメッ
シュの濃淡を用いて表示されている。まだ図中−が記入
されている項目はまだ結果がわかっていないものであ
り、今後この−が記入されている項目に順次結果が記入
されていくことを示している。また図中、矢印は目標達
成率を超過した場合に上向きの矢印が記入されており、
目標未達成の場合には下向きの矢印が記入されている。
また図１２は各機能に対して対策の必要性が表示されて
いる。この対策の必要性も工程と品質に分けられて表示
されている。この対策の必要性に用いられている記号は
図９（３）に示した各対策の必要性評価基準に割りふり
られた記号○、△を用いている。また−の項目は今後結
果がわかりしだい記入される項目を示している。

【００４７】次に図１３は図１２に示した目標／実績対
比評価表の改良例を示した図である。目標達成率に関し
ては図１２に示したものと同様のものでありここではそ
の説明を省略する。図１２と図１３が異なる点は、対策
の必要性の部分を記号で表示するのではなく数値で表示
している点である。この数値は悪さ加減を示す評価点で
あり数値が大きいほど工程の遅れがあることあるいは品
質が目標を達成していないということを示している。図
１２のように対策の必要性を記号で表すことにより視覚
的に各機能の対策の必要性を把握することができる。そ
れに対して図１３のように各機能毎に悪さ加減を評価点
で示すことにより具体的な悪さ加減を定量的に把握する
ことが可能となる。

【００４８】次に図１４は目標／実績対比評価表の他の
例を示す図である。この評価表は評価結果総括及び工程
進捗状況及び工程遅延と品質の悪さ加減の関係を示すグ
ラフから構成されている。評価結果総括は工程面及び品
質面の両面に渡って評価結果の総括が文章により出力さ
れる。また工程進捗状況は工程を大きく設計、製作、試
験に分類し、どの時点まで工程が進んでいるかをメッシ
ュにより表示する。次に工程遅延と品質の悪さ加減を示
すグラフは図１３に示した評価点を用いて作成される。
例えば機能Ａを例にして説明すると、図１３に示すよう
に機能Ａの試験工程は２週間遅れており、その品質の悪
さ加減は平均値が３．５であることを示している。図１
４に示すグラフは横軸を工程の遅延度とし縦軸を品質の
悪さ加減としている。従って機能Ａの状態は工程が２週
間遅れであり、品質の悪さ加減が３．５である交点で表
示される。また図１３に示す機能Ｂを例にして説明する
と、製作工程において２週間の遅れが発生し品質の平均
値が０．０を示しているため、図１４のグラフにおいて
は工程の遅れが２週間であり品質の悪さ加減が０である
点に機能Ｂを表示することができる。更に機能Ｃを例に
すると図１３においては製作工程が１週間の遅れであ
り、品質の悪さ加減が１．０であるため図１４において
は工程の遅れが１週間であり、品質の悪さ加減が１であ
る交点に機能Ｃを表示することができる。

【００４９】以上説明したことからわかるように、グラ
フ上に表示された点がＸ軸とＹ軸から離れれば離れるほ
ど工程の遅延及び品質の悪さが存在していることを示し
ている。もし交点が（０，０）にあれば工程も守られて
おり品質も目標を達成しているということを示してい
る。このように、各機能の工程と品質を縦軸と横軸にし
てグラフ化することによりプロジェクトが管理する工程
と品質の状況を即座に判定することができる。

【００５０】図１５は目標／実績対比評価表の他の例を
示す図である。図１５は機能ＡのプログラムＡ１からＡ
５に対する品質の評価結果を示している。プログラムの
設計、プログラムの製作、プログラムの試験という３つ
の工程それぞれについて品質の値が表示される。例え
ば、プログラム設計については仕様書の製作密度として
１キロラインあたりのページ数が表示されるとともにデ
ザインレビュ指摘率が表示される。またプログラム製作
に関してはコードレビュ指摘率が表示される。さらに、
プログラム試験に関しては試験密度として１キロライン
あたりの試験項目数を表示している。また、誤り密度を
表示している。また、図１５には具体的な数値は記載さ
れていないがヒット率も表示することが可能である。図
１５においても、具体的な定量的数字を掲げるとともに
その数字に対してメッシュ等の濃淡により目標の達成、
未達成を表示している。

【００５１】図１６は図１５に示した品質評価結果をグ
ラフにしたものである。グラフの縦軸は、製作密度Ａデザインレビュ指摘率Ｂコードレビュ指摘率Ｃ試験密度Ｄ誤り密度Ｅヒット率Ｆという６つの品質項目である。また、グラフの横軸は各
プログラムである。グラフの縦軸の中心は各項目の目標
値がとられる。例えば、デザインレビュ指摘率は１ペー
ジあたり０．５件を目標としているため０．５がグラフ
の中心となる。またコードレビュ指摘率は１キロライン
あたり１５件を目標値としているため１５がグラフの中
心となる。同様に試験密度は１キロラインあたり１００
項目を目標値としているため１００がグラフの中心とな
る。更に、誤り密度は１キロラインあたり１５を目標値
としているため１５がグラフの中心となる。製作密度と
ヒット率に関しては特に目標値が定められていないた
め、とり得る範囲の中心がそのままグラフの中心とな
る。製作密度は０〜１００％をとり得るため５０がグラ
フの中心となる。ヒット率は０〜１．０をとり得るため
０．５がグラフの中心となる。またデザインレビュ指摘
率の０．５から０．７５は許容範囲を示している。また
コードレビュ指摘率の１５から３０は同じく許容範囲を
示している。さらに試験密度の７０から１４０は許容範
囲を示している。誤り密度１２から１８は許容範囲を示
している。

【００５２】このように縦軸に各品質項目とその目標値
及び許容範囲等が表示されているのに対して、横軸には
実際に製作されたプログラムが掲げられそれぞれのプロ
グラムの設計、製作、試験の各工程において得られた品
質実績値に基づいてグラフが作成される。例えばプログ
ラムＡ１に関しては、図１５に示すように、製作密度が
１キロラインあたり１２１ページであるため、Ａの値が
１２１となり、製作密度１００を超えた部分に定められ
る。またデザインレビュ指摘率は１ページあたり１．３
９件であるため同様にグラフの上方に定められる。この
ようにしてＡからＦまでの点がプロットされることによ
りプログラムＡ１に関する６つの品質項目の点がプロッ
トされる。プログラムＡ２からＡ５に関しても同様にす
でに実績値として入力されたものに関してそれぞれの点
がプロットされる。それぞれの点がプロットされた後、
点Ｂ，Ｃ，Ｄ，Ｅのうち最大のものと最小のものの範囲
で矢印が引かれる。この例では製作密度Ａ及びヒット率
Ｆに関しては目標値及び許容範囲が定められていないた
めに矢印を引く場合には考慮されない。この矢印を引く
ことにより目標値及び許容範囲が定められている品質項
目に関してそれぞれのプログラムがどのような傾向にあ
るかを判定することが可能となる。

【００５３】実施例２．上記実施例１においては、図２
から図９に示す情報を計画値、実績値、基準値として入
力する場合について説明したが、図２から図９に示した
これらの情報は一例であり、その他の形式によりこれら
の情報を入力するようにしても構わない。

【００５４】実施例３．また、上記実施例１において
は、図１０から図１６に示すような目標／実績対比評価
表を用いて説明したが目標／実績対比評価表はその他の
形式で評価され、出力されるような場合でも構わない。

【００５５】実施例４．上記実施例１においては、目標
／実績対比評価表を出力する場合に、定量的数値に対し
て矢印やメッシュの濃淡を用いて目標の達成度合い視覚
的に表示する場合について説明したが定量的数値ととも
に視覚的に表示されるものは、メッシュである場合に限
らず網掛けを用いる場合あるいは色を用いる場合でも構
わない。また定量的数値そのものにオーバラップさせて
メッシュや網掛けや色を示す場合に限らず定量的数値の
わきにこれらの視覚的に識別可能なものを表示するよう
にしても構わない。

【００５６】実施例５．上記実施例１においては、目標
／実績対比評価表６０を出力する場合について説明した
が、この実施例ではさらに品質目標が未達成の場合に目
標を達成するためのガイド表を出力する場合について説
明する。図１７及び図１８は目標品質未達成を判断する
判断部５１が用いる品質目標達成度評価表及び品質目標
未達成を判断する判断部５１が出力する目標達成ガイド
の一例を示す図である。図に示す目標実績対比評価とし
て目標未達成率と管理限界超過率を計算する。目標未達
成率は目標値まで達成しない場合の範囲がどのぐらいで
あるかを示している。例えば、デザインレビュ件数の目
標値として１０５件があげられている場合に４１件以下
のデザインレビュ件数しかあげられない場合には目標未
達成となり、図の目標未達成率４０％の範囲に含まれて
しまうことを意味している。また、管理限界超過率は上
限許容範囲外率と下減許容範囲外率の２つの値を有して
いる。これらの率は管理限界の上限を超えた率及び下限
を超えた率を示している。例えば、この例では上限許容
範囲外率として３０％、下限許容範囲外率として４０％
の範囲が存在しており、合わせて管理限界超過率として
７０％の範囲が存在することを示している。このように
図１７に示すような品質目標達成度評価表を作成してお
くことにより、実際に実績値が収集されて品質実績が計
算された場合にこの品質目標達成度評価表と比較するこ
とにより、対策の必要性と品質目標を達成するためのガ
イド値を計算することが可能である。

【００５７】図１８は対策の必要性と品質目標を達成す
るためのガイド値の一例を示す図である。図においては
機能Ａから機能Ｇまでの各機能について対策の必要性と
品質目標を達成するためのガイド値が示されている。対
策の必要性に示された記号は図９（３）に示した対策の
必要性評価基準にしたがって記入された記号である。ま
た、品質目標を達成するためのガイド値は品質を許容範
囲まで高めるために今後行わなければならない作業件数
や項目件数を示している。例えば機能Ａに対してはデザ
インレビュ指摘件数として２３５件、コードレビュ指摘
件数として１３６件あげなければ品質を目標値にできな
いということを示している。また、機能Ｆについてはプ
ログラム試験において試験項目を５３２件行いその中か
ら誤り検出件数として６１件あげなければならないこと
を示している。このように目標達成ガイドを出力するこ
とにより品質を目標値に近づけるためにはどの工程の作
業を見直さなければならないかということが容易に判明
する。

【００５８】実施例６．次に図１９から図２１を用いて
ガイド表を出力する他の実施例について説明する。目標
達成ガイド出力の基本的な考え方は、プロジェクトの目
的を達成するため、生産段階（設計／製作／試験）の各
段階で収集される定量的なプロジェクト管理情報を複合
（例えば、品質と工程の相関等）することで、効率良く
かつ効果的に問題を洗いだし対策に結びつけることであ
る。

【００５９】図１９は、品質と工程の相関を示す品質／
工程相関グラフである。この品質／工程相関グラフは、
図１４に示したものに対して更に評価点５として実績が
把握されていない場合を追加したものである。この実施
例では、図１９に示した品質／工程相関グラフに基づい
て目標達成ガイドを出力する場合について説明する。図
２０及び図２１は、図１９に示した品質／工程相関グラ
フに基づいて目標達成ガイドを出力した場合の一例を示
す図である。

【００６０】図１９において横軸は工程の遅れを示して
おり、縦軸は品質の目標差を示している。横軸と縦軸の
メモリはそれぞれ評価点が用いられている。横軸と縦軸
の単位で囲まれた領域をそれぞれａ０〜ａ３，ｂ０〜ｂ
３，ｃ０〜ｃ３，ｄ０〜ｄ３とし、ａ０〜ａ３をＡと
し、ｂ０〜ｂ３をＢとし、ｃ０〜ｃ３をＣとし、ｄ０〜
ｄ３をＤと呼ぶことにする。領域Ａは品質、工程ともさ
ほど問題はない状態を示しているのに対し、領域Ｂは品
質面ではさほど問題はないが、工程が大幅に遅れている
ということを示している。同様に、領域Ｃは工程はさほ
ど問題にはならないが、品質が悪い状態を示している。
領域Ｄは品質、工程ともに非常に問題である場合を示し
ている。

【００６１】生産段階（設計／製作／試験）により作業
が異なるため、目標を達成するために実施すべき対策内
容は異なる。ここでは、一例として、設計段階における
目標を達成するためのガイド出力の一例を図２０、図２
１に示す（なお、図１９に示すように本来ａ０〜ａ３，
ｂ０〜ｂ３，ｃ０〜ｃ３，ｄ０〜ｄ３の各々のマトリク
スに対応してガイド出力されるものであるが、ここで
は、便宜上Ａ，Ｂ，Ｃ，Ｄに集約して記述する）。

【００６２】図２０及び図２１は、試験段階におけるガ
イド出力の一例を示す図であり、縦軸に品質及び工程が
設けられており、横軸に図１９で述べた領域Ａ，Ｂ，
Ｃ，Ｄ及び実績が把握されていない領域の５つの項目が
設けられている。前述したように、領域Ａは品質、工程
ともさほど問題にはならない状態である。従って領域Ａ
に対するガイド出力は、障害検出能力と誤り検出能力に
対してそれまでの実績及び今後完成させるまでの推定値
が出力される。また、誤りの作り込み原因として、例え
ば、仕様、レビュ、試験洩れ、の３つの項目にわたり各
値が出力される。また、領域Ａの工程に対しては、例え
ば、試験消化能力、障害処置能力、障害処置時間、設備
の４つの項目にわたりそれぞれ実績と今後完成までに必
要とされる推定値が出力される。

【００６３】一方これら領域Ａの出力に対し領域Ｂの出
力がされる場合は、領域Ａに比べて領域Ｂは工程の遅れ
がはなはだしい場合であるため、試験消化能力が十分で
あるか、障害処置能力が十分であるか、障害処置時間は
十分であるか、設備は十分であるか、等の問題点の提起
がなされる。そしてそれぞれに対して実績と推定が出力
されるとともに、その改善を行なうための値、及びコメ
ントが出力される。

【００６４】次に領域Ｃは品質が悪い場合であるため、
領域Ｃの品質欄には実績及び推定の他に改善値が出力さ
れる。領域Ｄに対しては品質と工程が問題となっている
ため、品質と工程の両方に対して問題提起がなされると
ともにその問題を解決するための改善値がそれぞれ出力
される。なお、把握されていない状態に対しては、評価
不可というガイドが出力される。

【００６５】図２０及び図２１においてＸＸＸＸと記載
されたところは実績値、推定値、改善値等の数値が出力
される。あるいは、日付が出力される場合もある。ある
いは、単語や言葉が出力される場合もある。これら数
値、文字、日付のいずれかが出力されるかは設計段階、
あるいは製作段階、あるいは試験段階においてそれぞれ
作業が異なるため、その作業の実績値や推定値や改善値
を表現するものが選択されて出力される。

【００６６】なお、図２０及び図２１においてはＡ，
Ｂ，Ｃ，Ｄという領域に分けてガイドを出力する場合に
ついて説明したが、ａ０〜ａ３，ｂ０〜ｂ３というよう
な個々のマトリクスそれぞれに対応して図２０及び図２
１に示したようなガイドを出力するようにしても構わな
い。

【００６７】実施例７．上記実施例においてはソフトウ
ェアの開発プロジェクトの例にして説明したが、この発
明はソフトウェアの開発プロジェクトに適用できるばか
りでなく、その他のプロジェクトに関しても適用するこ
とが可能である。例えば家電製品や電子機器等の設計、
製作、試験等にも用いることが可能である。このように
この発明はプロジェクトを遂行するにあたりそのプロジ
ェクトの工程を管理する必要がある場合であり、かつそ
のプロジェクトから生み出される対象物の品質を管理す
る必要がある場合には適用することが可能である。

【００６８】

【発明の効果】以上のようにこの発明によれば、工程と
品質の両面にわたって目標／実績対比評価が行われるの
で、プロジェクトの工程と品質の管理を関連づけて管理
することが可能になる。また、ガイドの出力により、即
座に目標未達成作業に対する積み残し作業量が定量的に
得られる。

【図面の簡単な説明】

【図１】この発明のプロジェクト進捗管理方式の一実施
例を示す図である。

【図２】この発明の一実施例による計画値の設定及び実
績値の収集の情報を示す図である。

【図３】この発明の一実施例による計画値の設定及び実
績値の収集の情報を示す図である。

【図４】この発明の一実施例による計画値の設定及び実
績値の収集の情報を示す図である。

【図５】この発明の一実施例による品質目標値の設定情
報の一例を示す図である。

【図６】この発明の一実施例による品質管理項目とその
基準を示す図である。

【図７】この発明の一実施例による品質管理項目とその
基準を示す図である。

【図８】この発明の一実施例による品質管理項目とその
基準を示す図である。

【図９】この発明の一実施例による評価基準の一例を示
す図である。

【図１０】この発明の一実施例による目標／実績対比評
価表を示す図である。

【図１１】この発明の一実施例による目標／実績対比評
価表を示す図である。

【図１２】この発明の一実施例による目標／実績対比評
価表を示す図である。

【図１３】この発明の一実施例による目標／実績対比評
価表を示す図である。

【図１４】この発明の一実施例による目標／実績対比評
価表を示す図である。

【図１５】この発明の一実施例による目標／実績対比評
価表を示す図である。

【図１６】この発明の一実施例による目標／実績対比評
価表を示す図である。

【図１７】この発明の一実施例による目標達成ガイドの
一例を示す図である。

【図１８】この発明の一実施例による目標達成ガイドの
一例を示す図である。

【図１９】この発明の一実施例による目標達成ガイドの
一例を示す図である。

【図２０】この発明の一実施例による目標達成ガイドの
一例を示す図である。

【図２１】この発明の一実施例による目標達成ガイドの
一例を示す図である。

【図２２】従来のプロジェクト進捗管理方式を示す図で
ある。

【図２３】ソフトウェアシステム開発障害管理方式を示
す図である。

【図２４】従来の工程進捗管理表を示す図である。

【符号の説明】

１０計画設定手段１１計画値入力部１２計画値記憶部１３工程計画値１４品質目標値２０実績収集手段２１実績値入力部２２実績値記憶部２３工程実績値２４品質実績値３０基準設定手段３１基準値入力部３２基準値記憶部３３工程評価基準３４品質評価基準４０比較部５０評価部５１品質目標未達成判断部６０目標／実績対比評価表７０目標達成ガイド

Claims

【特許請求の範囲】

【請求項１】以下の要素を有するプロジェクト進捗管
理方式（ａ）プロジェクトの工程計画と、各工程が目的
とする対象の品質目標とを設定する計画設定手段、
（ｂ）各工程の作業実績と、その作業実績に基づく対象
の品質実績とを収集する実績収集手段、（ｃ）プロジェ
クトの各工程とその対象の品質とを評価する評価基準を
設定する基準設定手段、（ｄ）上記計画設定手段により
設定した工程計画と品質目標と、上記実績収集手段によ
り収集した作業実績と品質実績とをそれぞれ比較する比
較手段、（ｅ）上記比較手段により比較した結果を、上
記基準設定手段により設定した評価基準により評価しそ
の評価結果を出力する評価手段。
【請求項２】上記評価手段は、工程に関する評価結果
と品質に関する評価結果とを対にして、出力することを
特徴とする請求項１記載のプロジェクト進捗管理方式。
【請求項３】上記評価手段は、評価結果として定量的
数値を出力するとともに、その定量的数値に付随してそ
の定量的数値に対応する視覚的に識別可能な識別表示を
出力することを特徴とする請求項１記載のプロジェクト
進捗管理方式。
【請求項４】上記評価手段は、品質評価の結果、品質
目標未達成の場合、各工程毎に品質目標を達成するため
のガイドを出力することを特徴とする請求項１記載のプ
ロジェクト進捗管理方式。