JPH09265392A - ソフトウェアの品質分析評価方法およびシステム - Google Patents
ソフトウェアの品質分析評価方法およびシステムInfo
- Publication number
- JPH09265392A JPH09265392A JP8074105A JP7410596A JPH09265392A JP H09265392 A JPH09265392 A JP H09265392A JP 8074105 A JP8074105 A JP 8074105A JP 7410596 A JP7410596 A JP 7410596A JP H09265392 A JPH09265392 A JP H09265392A
- Authority
- JP
- Japan
- Prior art keywords
- evaluation
- quality
- score
- software
- quality evaluation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
(57)【要約】
【課題】 品質評価の経験がなくても品質を容易に判断
可能にし、さらには品質の推移を容易に把握可能にする
こと。 【解決手段】 ソフトウェア開発工程の初期段階から最
終段階までの全ての工程において、工程毎、または工程
の初期・中期・終期に対し、品質評価に必要とされる基
本品質評価因子のデータを収集した後、そのデータを各
品質評価観点毎に分析し、各品質評価観点毎の客観的な
数値に対し評価基準に従って評点を付ける。また、その
評点の推移を編集して出力する。
可能にし、さらには品質の推移を容易に把握可能にする
こと。 【解決手段】 ソフトウェア開発工程の初期段階から最
終段階までの全ての工程において、工程毎、または工程
の初期・中期・終期に対し、品質評価に必要とされる基
本品質評価因子のデータを収集した後、そのデータを各
品質評価観点毎に分析し、各品質評価観点毎の客観的な
数値に対し評価基準に従って評点を付ける。また、その
評点の推移を編集して出力する。
Description
【０００１】
【発明の属する技術分野】本発明は、コンピュータソフ
トウエアの品質を管理するための品質分析評価方法およ
びシステムに係り、特に、複数工程にわたる品質の推移
を容易に把握できるようにしたソフトウェアの品質分析
評価方法およびシステムに関するものである。
トウエアの品質を管理するための品質分析評価方法およ
びシステムに係り、特に、複数工程にわたる品質の推移
を容易に把握できるようにしたソフトウェアの品質分析
評価方法およびシステムに関するものである。
【０００２】
【従来の技術】コンピュータで使用するソフトウエア品
質分析評価方法は、品質を静的に評価する方法と、動的
に評価する方法に分類される。
質分析評価方法は、品質を静的に評価する方法と、動的
に評価する方法に分類される。
【０００３】静的評価方法とは、仕様書、プログラム
（モジュール）などの成果物に対して任意の観点（分岐
命令の数など）で評価する方法であり、例えば、開発工
程のある時点でソースコードをデータとして読み込み、
構文解析を行い、ソフトウエアの複雑度・難易度等を計
算して品質を評価するものである。
（モジュール）などの成果物に対して任意の観点（分岐
命令の数など）で評価する方法であり、例えば、開発工
程のある時点でソースコードをデータとして読み込み、
構文解析を行い、ソフトウエアの複雑度・難易度等を計
算して品質を評価するものである。
【０００４】一方、動的評価方法とは、ソフトウエアを
設計・製造・テストする各工程の作業中に、作業、作業
中の条件、ある時点での成果物の状態などに対して任意
の評価観点（プログラムの規模、摘出不良件数など）で
品質を評価するものである。例えば、プログラム中存在
した不良と規模の要因、テスト時に使われるチェックリ
ストの件数と規模の要因等、品質評価観点をプログラム
毎に個々の要因分析評価を実施してプログラム品質を評
価するものである。
設計・製造・テストする各工程の作業中に、作業、作業
中の条件、ある時点での成果物の状態などに対して任意
の評価観点（プログラムの規模、摘出不良件数など）で
品質を評価するものである。例えば、プログラム中存在
した不良と規模の要因、テスト時に使われるチェックリ
ストの件数と規模の要因等、品質評価観点をプログラム
毎に個々の要因分析評価を実施してプログラム品質を評
価するものである。
【０００５】
【発明が解決しようとする課題】ところで、ソフトウェ
アは、その性質上、実際に動作させてみないと判明しな
い不良や、動作させても一定の条件が成立した時に不良
となるものもある。さらに、単体では正常に動作して
も、他のプログラムまたはモジュールと組み合わせると
不正な動作を行うなど、工程が進行しないと発見されな
い不良がある。
アは、その性質上、実際に動作させてみないと判明しな
い不良や、動作させても一定の条件が成立した時に不良
となるものもある。さらに、単体では正常に動作して
も、他のプログラムまたはモジュールと組み合わせると
不正な動作を行うなど、工程が進行しないと発見されな
い不良がある。
【０００６】しかしながら、従来の静的評価方法にあっ
ては、その評価原理上、仕様書やプログラム等の成果物
が完成していることを前提としているため、プログラム
等のコーディング完了時点で評価内容がほぼ決定され、
テスト工程で始めて発見されるような不良があったとし
ても評価内容に反映されない。また、テスト工程におい
ては、テスト工程独自の観点で評価する。
ては、その評価原理上、仕様書やプログラム等の成果物
が完成していることを前提としているため、プログラム
等のコーディング完了時点で評価内容がほぼ決定され、
テスト工程で始めて発見されるような不良があったとし
ても評価内容に反映されない。また、テスト工程におい
ては、テスト工程独自の観点で評価する。
【０００７】従って、前工程の品質評価が次工程に反映
されず、現工程における不良原因がどの様な経過で作り
込まれたかが明確にならず、全部の工程を通じた一貫し
た評価ができないという問題がある。
されず、現工程における不良原因がどの様な経過で作り
込まれたかが明確にならず、全部の工程を通じた一貫し
た評価ができないという問題がある。
【０００８】一方、従来の動的評価方法にあっては、完
成した成果物がなくても評価が可能である反面、品質評
価の経験がないと、評価観点毎に出された客観的な数値
から品質を判断することが難しいという問題がある。
成した成果物がなくても評価が可能である反面、品質評
価の経験がないと、評価観点毎に出された客観的な数値
から品質を判断することが難しいという問題がある。
【０００９】また、工程毎に評価観点が異なるため、特
定のプログラムまたはモジュールについて、ある工程と
別の工程での品質を比較することが難しく、さらに同様
の理由から品質の推移を把握することができないという
問題がある。
定のプログラムまたはモジュールについて、ある工程と
別の工程での品質を比較することが難しく、さらに同様
の理由から品質の推移を把握することができないという
問題がある。
【００１０】本発明の第１の目的は、品質評価の経験が
なくても評価観点毎に出された客観的な数値から品質を
容易に判断することができるソフトウェアの品質分析評
価方法およびシステムを提供することである。
なくても評価観点毎に出された客観的な数値から品質を
容易に判断することができるソフトウェアの品質分析評
価方法およびシステムを提供することである。
【００１１】本発明の第２の目的は、全部の工程を通じ
て一貫した品質評価を行い、品質の推移を容易に把握す
ることができるソフトウェアの品質分析評価方法および
システムを提供することである。
て一貫した品質評価を行い、品質の推移を容易に把握す
ることができるソフトウェアの品質分析評価方法および
システムを提供することである。
【００１２】
【課題を解決するための手段】上記第１の目的を達成す
るために、本発明は、ソフトウェア開発工程の初期段階
から最終段階までの全ての工程において、工程毎、また
は工程の初期・中期・終期に対し、品質評価に必要とさ
れる基本品質評価因子のデータを収集した後、そのデー
タを各品質評価観点毎に分析し、各品質評価観点毎の客
観的な数値に対し評価基準に従って評点を付けるように
したことを特徴とする。
るために、本発明は、ソフトウェア開発工程の初期段階
から最終段階までの全ての工程において、工程毎、また
は工程の初期・中期・終期に対し、品質評価に必要とさ
れる基本品質評価因子のデータを収集した後、そのデー
タを各品質評価観点毎に分析し、各品質評価観点毎の客
観的な数値に対し評価基準に従って評点を付けるように
したことを特徴とする。
【００１３】上記第２の目的を達成するために、本発明
は、ソフトウェア開発工程の初期段階から最終段階まで
の全ての工程において、工程毎、または工程の初期・中
期・終期に対し、品質評価に必要とされる基本品質評価
因子のデータを収集した後、そのデータを各品質評価観
点毎に分析し、各品質評価観点毎の客観的な数値に対し
評価基準に従って評点を付け、その評点を工程の推移に
従って表示するようにしたことを特徴とする。
は、ソフトウェア開発工程の初期段階から最終段階まで
の全ての工程において、工程毎、または工程の初期・中
期・終期に対し、品質評価に必要とされる基本品質評価
因子のデータを収集した後、そのデータを各品質評価観
点毎に分析し、各品質評価観点毎の客観的な数値に対し
評価基準に従って評点を付け、その評点を工程の推移に
従って表示するようにしたことを特徴とする。
【００１４】さらに、各評点に対する合格基準点を設定
し、評点が合格基準点に満たない場合は、次の工程の合
格基準点を上げることにより、前工程の評価結果を次工
程に反映させるようにしたことを特徴とする。
し、評点が合格基準点に満たない場合は、次の工程の合
格基準点を上げることにより、前工程の評価結果を次工
程に反映させるようにしたことを特徴とする。
【００１５】
【発明の実施の形態】以下、本発明の実施の形態を図面
を用いて具体的に説明する。
を用いて具体的に説明する。
【００１６】図１は、本発明を適用したモジュールごと
の品質分析評価処理の実施の形態を示すフローチャート
である。
の品質分析評価処理の実施の形態を示すフローチャート
である。
【００１７】この品質分析評価処理は、キーボードなど
の入力装置、表示装置、メモリ、プリンタなどの周辺機
器を備えたコンピュータシステムによって実行されるも
のである。
の入力装置、表示装置、メモリ、プリンタなどの周辺機
器を備えたコンピュータシステムによって実行されるも
のである。
【００１８】この実施形態における品質分析評価処理で
は、まず、工程ごとに設定された品質評価因子をモジュ
ール単位で収集する（ステップ１０１）。
は、まず、工程ごとに設定された品質評価因子をモジュ
ール単位で収集する（ステップ１０１）。
【００１９】なお、収集する単位は、必要に応じて自由
に設定可能である。
に設定可能である。
【００２０】次に、収集した品質評価因子を基に、各品
質評価観点を、それぞれの計算式により、算出する（ス
テップ１０２）。
質評価観点を、それぞれの計算式により、算出する（ス
テップ１０２）。
【００２１】次に、各評価観点別に設定された評価基準
に従い、例えば５段階評価として評点を付ける（ステッ
プ１０３）。
に従い、例えば５段階評価として評点を付ける（ステッ
プ１０３）。
【００２２】次に、各評価観点の合格基準点と比較し
（ステップ１０４）、基準点に達していないモジュール
については、次工程の合格基準点を所定値上げる（ステ
ップ１０５）。
（ステップ１０４）、基準点に達していないモジュール
については、次工程の合格基準点を所定値上げる（ステ
ップ１０５）。
【００２３】この処理により、モジュールごとの各工程
の品質評価結果を次工程の品質評価に反映させることが
できる。
の品質評価結果を次工程の品質評価に反映させることが
できる。
【００２４】これらの処理を全モジュールについて行
う。
う。
【００２５】更に、これを全ての工程が終了するまで繰
り返す。
り返す。
【００２６】また、必要に応じて前工程と現工程の評点
の差を算出し、評点の推移を集計あるいは編集して表示
装置に表示する。あるいは、プリンタで印刷出力する。
の差を算出し、評点の推移を集計あるいは編集して表示
装置に表示する。あるいは、プリンタで印刷出力する。
【００２７】図２は、製造工程における基本品質評価因
子２０をモジュール別に集計した結果の例を示す図であ
る。
子２０をモジュール別に集計した結果の例を示す図であ
る。
【００２８】基本品質評価因子とは、図２に示すよう
に、例えば、プログラムの規模Ａｎ、コンパイル回数Ｂ
ｎ、修正ステップ数Ｃｎ、不良件数Ｄｎ、重要不良件数
Ｅｎ、チェックリスト件数Ｆｎ等を指し、各品質評価観
点の計算因子となる。
に、例えば、プログラムの規模Ａｎ、コンパイル回数Ｂ
ｎ、修正ステップ数Ｃｎ、不良件数Ｄｎ、重要不良件数
Ｅｎ、チェックリスト件数Ｆｎ等を指し、各品質評価観
点の計算因子となる。
【００２９】図３は、整合工程における品質評価因子の
収集結果を基に計算した評価観点３０をモジュール別に
集計した結果の例を示したものであり、例えば、不良密
度Ａ’ｎ、チェックリスト密度Ｂ’ｎ、重要不良比率は
Ｃ’ｎは、以下の式によって算出される。
収集結果を基に計算した評価観点３０をモジュール別に
集計した結果の例を示したものであり、例えば、不良密
度Ａ’ｎ、チェックリスト密度Ｂ’ｎ、重要不良比率は
Ｃ’ｎは、以下の式によって算出される。
【００３０】不良密度Ａ’ｎ ＝不良件数／プ
ログラムの規模（ステップ数） チェックリスト密度Ｂ’ｎ＝チェックリスト件数／プロ
グラムの規模（ステップ数） 重要不良比率Ｃ’ｎ ＝重要不良件数／不良件数 図４は、所定の評価基準によりつけられた評点４０の一
例を示したものであり、例えば、重要不良比率（ｘとす
る）の評価基準は下記のように設定されている。
ログラムの規模（ステップ数） チェックリスト密度Ｂ’ｎ＝チェックリスト件数／プロ
グラムの規模（ステップ数） 重要不良比率Ｃ’ｎ ＝重要不良件数／不良件数 図４は、所定の評価基準によりつけられた評点４０の一
例を示したものであり、例えば、重要不良比率（ｘとす
る）の評価基準は下記のように設定されている。
【００３１】 これにより、工程別、評価因子別の各モジュールの品質
が５段階評価のどの段階であるかがわかる。
が５段階評価のどの段階であるかがわかる。
【００３２】重要不良比率ｘが「０．１」以下であれ
ば、最高評点である「５」が付けられる。これによっ
て、品質評価に未経験のものであっても、容易に品質の
程度を把握することができる。
ば、最高評点である「５」が付けられる。これによっ
て、品質評価に未経験のものであっても、容易に品質の
程度を把握することができる。
【００３３】図５は、工程Ａ〜Ｄにおけるモジュール１
〜３の評点の推移の一例を表示した図である。なお、縦
軸は、評点である。
〜３の評点の推移の一例を表示した図である。なお、縦
軸は、評点である。
【００３４】図から明らかなように、各モジュール１〜
３の各開発段階の品質の推移が直感的に理解でき、注意
を要するモジュールのピックアップが容易になるなどの
効果がある。
３の各開発段階の品質の推移が直感的に理解でき、注意
を要するモジュールのピックアップが容易になるなどの
効果がある。
【００３５】例えば、モジュール１では、評点が工程Ａ
から工程Ｂの２回目の評価に移るに従って良くなってい
ることから品質が安定してきていることが言える。
から工程Ｂの２回目の評価に移るに従って良くなってい
ることから品質が安定してきていることが言える。
【００３６】逆に、モジュール３は、工程Ｄに移行する
に従って評点が低下し、品質が低下していることが分か
る。
に従って評点が低下し、品質が低下していることが分か
る。
【００３７】評点の推移パターンとしては、図６に示す
ようなものがある。
ようなものがある。
【００３８】図６（ａ）に示す推移パターンは、評点が
工程の進行に伴って上がっているパターンであり、品質
としては「良い」という評価ができる。
工程の進行に伴って上がっているパターンであり、品質
としては「良い」という評価ができる。
【００３９】図６（ｂ）に示す推移パターンは、評点が
高い水準で推移しているので、品質としては「良い」と
いう評価ができる。但し、評点が高すぎるため、収集し
た因子データを確認した方が良いという評価も可能であ
る。
高い水準で推移しているので、品質としては「良い」と
いう評価ができる。但し、評点が高すぎるため、収集し
た因子データを確認した方が良いという評価も可能であ
る。
【００４０】図６（ｃ）に示す推移パターンは、評点が
工程の進行に伴って下がっているパターンであり、品質
としては「悪い」という評価ができる。但し、評点が低
下した観点を再確認し、見直しを行う必要があるという
評価も可能である。
工程の進行に伴って下がっているパターンであり、品質
としては「悪い」という評価ができる。但し、評点が低
下した観点を再確認し、見直しを行う必要があるという
評価も可能である。
【００４１】図６（ｄ）に示す推移パターンは、評点が
低い水準で推移しているので、品質としては「悪い」と
いう評価ができる。但し、評点が低すぎるため、収集し
た因子データや観点を再確認し、見直しを行う必要があ
るという評価も可能である。
低い水準で推移しているので、品質としては「悪い」と
いう評価ができる。但し、評点が低すぎるため、収集し
た因子データや観点を再確認し、見直しを行う必要があ
るという評価も可能である。
【００４２】図６（ｅ）に示す推移パターンは、評点が
工程の進行に伴って僅かに上がっているパターンであ
り、品質としては「やや良い」という評価ができる。
工程の進行に伴って僅かに上がっているパターンであ
り、品質としては「やや良い」という評価ができる。
【００４３】図６（ｆ）に示す推移パターンは、評点が
中程度で維持されているパターンであり、品質としては
「やや良い」という評価ができる。
中程度で維持されているパターンであり、品質としては
「やや良い」という評価ができる。
【００４４】図６（ｇ）に示す推移パターンは、評点が
中程度から工程の進行に伴って下がっているパターンで
あり、品質としては「やや悪い」という評価ができる。
但し、評点が低下した観点を再確認し、見直しを行う必
要があるという評価も可能である。
中程度から工程の進行に伴って下がっているパターンで
あり、品質としては「やや悪い」という評価ができる。
但し、評点が低下した観点を再確認し、見直しを行う必
要があるという評価も可能である。
【００４５】このように、工程の進行に伴う評点の推移
をグラフ表示することによって、品質の推移を容易に把
握することができる。しかも、どの工程から変化してい
るかが判明するため、品質を向上させるための対策の立
案が容易になる。
をグラフ表示することによって、品質の推移を容易に把
握することができる。しかも、どの工程から変化してい
るかが判明するため、品質を向上させるための対策の立
案が容易になる。
【００４６】さらに、推移パターンから品質評価基準自
体の欠陥や不具合も発見できることもあるので、品質評
価基準の見直しによって評価システム自体の信頼性を向
上させることができる。
体の欠陥や不具合も発見できることもあるので、品質評
価基準の見直しによって評価システム自体の信頼性を向
上させることができる。
【００４７】図７は、開発の終了段階において、各工程
別に全モジュールの評点の達成割合を算出することによ
り、開発したシステム全体の品質推移をビジュアルに表
現した例であり、斜線部分が多いほど達成度合いが高い
ことを示している。
別に全モジュールの評点の達成割合を算出することによ
り、開発したシステム全体の品質推移をビジュアルに表
現した例であり、斜線部分が多いほど達成度合いが高い
ことを示している。
【００４８】このように、評点の達成割合を表示するこ
とにより、品質評価に不慣れな者であっても、直感的に
どの工程に品質向上対策を施せばよいかが分かる。
とにより、品質評価に不慣れな者であっても、直感的に
どの工程に品質向上対策を施せばよいかが分かる。
【００４９】なお、図５および図７の表示方法に限ら
ず、その他の表示方法を用いても良い。
ず、その他の表示方法を用いても良い。
【００５０】
【発明の効果】以上に説明したように、本発明によれ
ば、品質の評価内容が異なる品質評価観点に評点を付け
ることにより、品質評価の経験がないものであっても、
品質の良し悪しを容易に判定し、評価することができ
る。
ば、品質の評価内容が異なる品質評価観点に評点を付け
ることにより、品質評価の経験がないものであっても、
品質の良し悪しを容易に判定し、評価することができ
る。
【００５１】また、評点を工程進捗順にグラフ等で表示
出力することにより、ソフトウェアの品質の変化の推移
を容易に把握することができる。
出力することにより、ソフトウェアの品質の変化の推移
を容易に把握することができる。
【００５２】さらに、前工程の品質評価よって次工程の
評価基準を変更することで、品質評価を工程別にこま切
れにすることなく、前工程の評価を次工程に反映させる
ことができる。
評価基準を変更することで、品質評価を工程別にこま切
れにすることなく、前工程の評価を次工程に反映させる
ことができる。
【図１】本発明を適用した品質分析評価処理の実施形態
を示すフローチャートである。
を示すフローチャートである。
【図２】基本品質評価因子をモジュール別に集計した例
を示す図である。
を示す図である。
【図３】基本品質評価因子から品質評価観点別に計算し
た例を示す図である。
た例を示す図である。
【図４】品質評価観点から評点を求めた例を示す図であ
る。
る。
【図５】各モジュールの評点の推移の一例を示した図で
ある。
ある。
【図６】各モジュールの評点の推移パターンの例を示し
た図である。
た図である。
【図７】全体の品質達成度合いを表示した例を示す図で
ある。
ある。
２０…各モジュール別の品質評価因子、３０…各モジュ
ール別の評価観点、４０…各モジュール別の評点。
ール別の評価観点、４０…各モジュール別の評点。
Claims (6)
- 【請求項１】 ソフトウェア開発工程の複数の工程にわ
たって、工程毎に、品質評価に必要とされる基本品質評
価因子のデータを収集した後、そのデータを各品質評価
観点毎に分析し、各品質評価観点毎の客観的な数値に対
し評価基準に従って評点を付け、その評点によってソフ
トウェアの品質を評価することを特徴とするソフトウェ
アの品質分析評価方法。 - 【請求項２】 前記評点を工程の推移に従って表示する
ようにしたことを特徴とする請求項１記載のソフトウェ
アの品質分析評価方法。 - 【請求項３】 前記各工程の評点に対する合格基準点を
設定し、評点が合格基準点に満たない場合は、次の工程
の合格基準点を上げ、前工程の評価結果を次工程に反映
させるようにしたことを特徴とする請求項１または２記
載のソフトウェアの品質分析評価方法。 - 【請求項４】 ソフトウェア開発工程の複数の工程にわ
たって、工程毎に、品質評価に必要とされる基本品質評
価因子のデータを収集する手段と、収集されたデータを
各品質評価観点毎に分析し、各品質評価観点毎の客観的
な数値に対し評価基準に従って評点を付ける手段と、そ
の評点を出力する手段とを備えることを特徴とするソフ
トウェアの品質分析評価システム。 - 【請求項５】 前記評点を工程の推移に従って編集し出
力する手段を備えることを特徴とする請求項４記載のソ
フトウェアの品質分析評価システム。 - 【請求項６】 前記各工程の評点に対する合格基準点を
設定する手段と、前記評点が合格基準点に満たない場合
は、次の工程の合格基準点を上げ、前工程の評価結果を
次工程に反映させる手段を備えることを特徴とする請求
項４または５記載のソフトウェアの品質分析評価システ
ム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8074105A JPH09265392A (ja) | 1996-03-28 | 1996-03-28 | ソフトウェアの品質分析評価方法およびシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8074105A JPH09265392A (ja) | 1996-03-28 | 1996-03-28 | ソフトウェアの品質分析評価方法およびシステム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH09265392A true JPH09265392A (ja) | 1997-10-07 |
Family
ID=13537585
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP8074105A Pending JPH09265392A (ja) | 1996-03-28 | 1996-03-28 | ソフトウェアの品質分析評価方法およびシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH09265392A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003345918A (ja) * | 2002-05-27 | 2003-12-05 | Nec Corp | ソフトウェア品質管理システムおよびソフトウェア品質管理方法 |
| JP2008165491A (ja) * | 2006-12-28 | 2008-07-17 | Hitachi Ltd | ソフトウェア品質評価装置及び方法 |
-
1996
- 1996-03-28 JP JP8074105A patent/JPH09265392A/ja active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003345918A (ja) * | 2002-05-27 | 2003-12-05 | Nec Corp | ソフトウェア品質管理システムおよびソフトウェア品質管理方法 |
| JP2008165491A (ja) * | 2006-12-28 | 2008-07-17 | Hitachi Ltd | ソフトウェア品質評価装置及び方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6711514B1 (en) | Method, apparatus and product for evaluating test data | |
| JP3406739B2 (ja) | ハンディ式現場機器点検装置 | |
| JP2005222108A (ja) | バグ分析方法および装置 | |
| CN101673233B (zh) | 测试项目的排程方法及其排程系统 | |
| JPH09167152A (ja) | 対話的モデル作成方法 | |
| JP3703064B2 (ja) | ソフトウェア品質評価装置および品質評価方法 | |
| JP3550105B2 (ja) | ウエハの故障サイン自動検出、分類方法 | |
| JPH09265392A (ja) | ソフトウェアの品質分析評価方法およびシステム | |
| EP0441547A2 (en) | Simulation of human performance of a process operation procedure | |
| JP6371981B2 (ja) | 業務支援システム、業務支援システムを実行するプログラム及びそれを記録した媒体 | |
| JPH1164235A (ja) | 実装部品自動検査システムおよび実装部品検査基準設定装置および実装部品検査基準設定方法 | |
| JP2000237937A (ja) | 生産システムの設計支援方法 | |
| JPH05290020A (ja) | 再検査指示方式 | |
| KR102562935B1 (ko) | 기술역량 평가장치 | |
| JPH10269076A (ja) | 進捗管理方式および記録媒体 | |
| JPH03222639A (ja) | 巡視点検方式 | |
| US20060047627A1 (en) | Method, system and program for testing accessibility in data processing system programs | |
| JP2004326279A (ja) | 工程進捗度管理システム | |
| JP2001265917A (ja) | 見積評価支援システム | |
| CN116227425A (zh) | 针对芯片设计中算法实现的评估方法 | |
| Baskarada et al. | Constructing a Staged Capability Maturity Model for Information Quality Management: Applying the Delphi Method for Consensus Building within an Information Quality Expert Panel | |
| JP2002091763A (ja) | 開発承認支援システム及び記憶媒体 | |
| JPH0652251A (ja) | 機能設計装置 | |
| JPH05282178A (ja) | ソフトウェア品質評価方式 | |
| JPH04315255A (ja) | データ処理システム用ワークベンチ／ツールボックスインターフェース |