＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
もっといい品質管理手法のアイデアありませんか？
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2005-02-18 08:56
意外な方向に話がのびていってますねー。
私としてはこの話は、
、につきるような気もするのですが．．． バグ摘出件数はそれ単独では品質管理の指標にはなりえないと思います。 通常バグ摘出件数を品質管理の指標として用いる場合は、時系列で累積バグ摘出件数をプロットして「テストが順調に消化されてバグが収束する」のをビジュアル的に見るために用いるケースがほとんどかと思っていました。 うーん、案外デバッグとテストの違いがわからない人って多いのかも。 | ||||
|
投稿日時: 2005-02-18 09:35
ちょろっと考えました。
そもそも品質管理って何なんでしょうね？ 管理対象って何だと思いますか？ 製造業の場合、『（Ｂ）工程・製造機器 → （Ａ）製品』の関係なので （Ａ）の品質は（Ｂ）に影響され、（Ｂ）の精度を高める事により（Ａ）の品質が上がります （Ｂ）は流動性が低い為、（Ｂ）への品質向上の行為は効果的に蓄積されます。 つまり（Ｂ）が管理対象です。 それに対しシステム開発では、 『（Ｃ）工程・人・開発ツール → （Ｂ）システム → （Ａ）データ・サービス』の関係なので （Ａ）の品質は（Ｂ）に影響され、（Ｂ）の品質は（Ｃ）に影響されます。また （Ｂ）の精度を高める事により（Ａ）の品質が上がり、 （Ｃ）の精度を高める事により（Ｂ）の品質が上がります。 （Ｂ）は１プロジェクト内では流動性がやや低い為、 （Ｂ）への品質向上の行為は御客としては効果的に蓄積されますが、 システム開発側の効果として蓄積するには（Ｃ）を対象としなければいけません。 しかし、それが直接（Ａ）の品質向上に繋がる訳では無い事に注意が必要です。 上記の関係構成で考えると、 システム開発では、製造業の品質管理における一連の作業を短期間に行う考えが必要になり。 また品質における管理対象とはなるのは（Ｃ）では無いでしょうか？ これは製造業の（Ａ）（Ｂ）関係で云うと（Ａ）（Ｂ）を管理している その人をさらに管理する概念が発生する訳です。 もし品質における管理対象を（Ｃ）とした場合、巷でいわれる大半の品質管理は （Ｂ）を対象とした概念ですから的外れの様に感じます。 _________________ OFF企画中ご意見募集 [ メッセージ編集済み 編集者: はにまる 編集日時 2005-02-18 09:39 ] | ||||
|
投稿日時: 2005-02-18 10:46
何か「バグ摘出件数目標値」を勘違いされているような気がします。
ここで言う「バグ摘出件数」というのは、品質管理の指標でも何でも無くて （無関係では無いですが）テスト作業のバロメータです。 品質管理的に指標となるのは、バグ（トラブル）発生件数であって、摘出件数 じゃ無いです。 つまり工業製品で言い換えると、５００個ごとの抜き取り検査で不良品が２個 見つかったとすれば、「統計的にその製品ではもっと不良があるはずだ」という ことになれば、その製品の品質がどうのこうのではなく、「抜き取り検査」を「全 数検査」に変えると言う検査精度のバロメータに過ぎないわけです。 ですから、目標摘出数に満たない場合には、まずテストケース、テスト方法が 適切だったのかを検証するべきですね。 | ||||
|
投稿日時: 2005-03-04 18:26
ちょっと飛び入りさせてください
バグ摘出件数に目標を定める方法そのものについて余り議論が行っていないようですね 一般に、工程ごとに、バグ摘出件数の上下限値を決めて、その間に入れば まあＯＫというような管理方法です。 この管理方法が使える、根本の考え方は、 ”人間は間違いをする” ということがベースだと思っています。 ソフトウェア開発の方法は、殆どが人間ワークです ＰＣの上で仕事をしますが、業務設計、プログラミングは 人間が頭の中でやります。また、ある工程から次の工程に行くとき ドキュメントは引き継げますが、成果物はそのまま使えるません。 各工程でつながりがないから（できないから）、人間ワークが必要になるのです。 また、この管理方法が使える条件は、 （１）チームとしての、仕事の仕方が比較的安定している場合でしょう 初めてのチーム 初めての業務 お客様もはじめての業務 経験不足の人がたくさん といった仕事の仕方が不安定な場合には、自分たちのチームの目標値に変える必要があります。パッケージソフトなどのバージョンアップでは使えます どなたかも指摘されていますが、自分たちのチームはどんな力か ということを知っていないと目標値が決められません （２）試験項目が十分 使い方 上限下限値の範囲に入っていればＯＫ 上限を超えた 再レビュー 下限値を超えない 試験項目の見直し または ＯＫ 下限値以下で 試験も十分な場合 誰が作ったかを見ること 最後は人の顔を見て下さい | ||||
|
投稿日時: 2005-03-05 17:36
私も飛び入り(^^)
品質管理を機械的にやっているところは、指標を「決まり」として扱いますから数値をごまかさざる得ない事があるのは仕方ない事です。 バグ摘出件数はそもそも指標のはずですから、スコーピオンさんのおっしゃるとおり開発条件によって上下します。 逆にいえば、指標がどういう条件での数値なのかを提示してもらい、その差異で補正するのは当然の行為だと思います。（それが力関係で出来るかどうかは別ですが） 補正できなかったら、本当に根拠の無い品質管理になるでしょう。 それはともかくとして、品質管理をテスト（バグ摘出）に絞って論ずるのは如何なものかと思いますね。 ここの議論は関係無いかもしれませんが、テストはあくまでも最後の砦です。 外注任せで「まともな設計」と「まともな実装」が出来ない企業が、テストにこだわるのだと最近思うようになりました(笑 （最近外れプロジェクトばかりだぁ(ToT)） | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.