2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2012年2月 | トップページ | 2012年4月 »

2012年3月

2012年3月29日 (木)

【続定量的品質予測のススメ】 tool is all i need

P88「表5.2-3 対策3:設計プロセス・品質プロセスを見直す」において、「分析内容が表面的」「データ分析工数が大きい」というデータ上の現象例に対する対策として「データ分析ツールを導入する」とある。

まあ、現象例の後者についてはそれでも良いだろう。
しかし、「分析内容が表面的」なのは、ツールを導入すれば解決するのであろうか。

例えば信頼度成長曲線のフィッティングツールで万能感あふれるまま実測値に合う曲線が見つかったらそれは表面的ではない実態に即した深い分析なのだろうか。

ツールを導入して本気で色々試すことは良いことであるというのは否定はできない。
しかし、ツールを導入すれば何も考えなくとも様々なレポートが出力できるから厚みのある分析ができると思うのならばツールを入れる前にすることがあると思われる。

そんなの当たり前だろと言われそうだが、実際のところ、ツールに使われている者が多いのではないだろうか。

2012年3月26日 (月)

【続定量的品質予測のススメ】 魔法のプロセス、方法論

P88「表5.2-3 対策3:設計プロセス・品質プロセスを見直す」において、「定量的品質管理上の問題が頻発している」というデータ上の現象例が挙げられている。

かなり抽象的な記述である。
そしてこれに対する対策を取る理由の例として「明文化された品質保証プロセス、方法論がない」とある。

明文化された品質保証プロセス、方法論があれば定量的品質管理上の問題が頻発しないのかというと全くそうは言えないと思う。

あくまでこれは例だからということかもしれないが、それを言うならばもう少し現象を具体的に書けば良いと思う。

「定量的品質管理上の問題が頻発している」という本現象の前の減少はすべて定量的品質管理上の問題と言え、こえらが頻発すればそれは明文化された品質保証プロセス、方法論がないからですと言うのは少々乱暴だと思われる。

まあ、これは少々揚げ足取りで、わざわざ書くこともないとも思うが、しかし、何かあると明文化された品質保証プロセス、方法論がないからだみたいなことを声高に言う人もいるので、念のため明文化しておいた。

2012年3月22日 (木)

【続定量的品質予測のススメ】 プロジェクトが異常なのに定量データが管理限界内

P86「表5.2-3 対策3:設計プロセス・品質プロセスを見直す」において、「定量データが管理限界を超えていても、プロジェクトが正常な状態にある」と「プロジェクトが異常な状態であるにもかかわらず、定量データが管理限界内にある」というデータ上の現象例に対する対策として次の3つの対策が書かれている。

・管理指標を見直す
・プロジェクト特性に依存する場合:プロジェクト固有の読み替えを行う
・プロジェクト特性に基かない場合:管理値の方を適切に見直す

とある。

書かれていることが少しわからない。
定量データが管理限界内にあるのに、どうしてプロジェクトが異常な状態であるとわかるのであろうか。

それは、異常な状態であるという判断が管理限界内を判断するメトリクスとは別なところでなされているからではないのか。

良くないたとえかもしれないけれど、制動能力のメトリクスが不芳なのに、どうして車の加速性能のメトリクスは正常なのだろうと言っているようなものではないだろうか。
当該メトリクスでは判断できないのだから状態を言い当てられなくて当たり前なのだ。

そもそも、ある種のメトリクスによる管理限界か否かの判定が妥当でない何らかの評価基準があるのであれば、そのようなメトリクスを使用せず、その何らかの評価基準で判断すれば良いだけのことである。

何故精度調整の難しいメトリクスを使用しなければならないのかが分からない。

 

2012年3月19日 (月)

【続定量的品質予測のススメ】 チェックリストの呪縛

P86「表5.2-3 対策3:設計プロセス・品質プロセスを見直す」において、「指摘が不十分である」と「指摘項目が偏っている」というデータ上の現象例に対する対策として「チェックリストを増補改訂する」とある。

まあ、そうである。特にこのような現象においてはチェックリストは強力な武器である。
しかし、何かの対策をすぐにチェックリストに頼るのはあまりよくないと考える。

チェックリストは何かの存在を形式的に気づかせてくれるだけである。
本質的な理解・把握・行動に結びつく対策も合わせて考えるべきである。

レビュー内容の不十分性ならば、レビュー内容を充実させることを考えるべきである、
バックグラウンドに偏りのないレビューア体制をとる等の方法もあろう。

レビューなのでチェックリストの充実は正しい対策の一つだと思うので本書の記述が間違っているとは思わない。
ここでは、安易なチェックリスト依存を避けるためにあえて記述したものである。

2012年3月15日 (木)

【続定量的品質予測のススメ】 指標の定義の精緻化

定量的品質管理における精緻化というもの。

P85「対策3:設計プロセス・品質管理プロセスを見直す」に、「指標の定義があいまいな場合は、定量的品質管理を行っても有意なデータが集まらないので、問題があれば定義の精緻化を検討すべきである」と書かれている。

これは、多くの場合正しいと思う。
しかし、精緻な方向にばかり目が行くのは危険だと思う。

そもそも、考えている品質モデルが、想定している品質水準を満たすことが可能であると検証しているのであろうか。

モデル上可能な精度以上を求めて何かを精緻化することは、”多くの場合”間違っている(と思うのだが・・・違うかもしれない)。

「指標の定義があいまいな場合は、定量的品質管理を行っても有意なデータが集まらないので、問題があれば指標のモデルが想定する精度とのアンマッチがないか、もしくは定義の精緻化を検討すべきである」程度の記述の方が良いのではないだろうか。

精緻精緻と言って沼に陥らないために。

2012年3月12日 (月)

【続定量的品質予測のススメ】 発注者のレビューへの協力

P85「表5.2-2 対策2:一過性の作業を追加する」において、データ上の現象例として、「要件に関する指摘が極端に少ない」と「発注者の確認を受けていない」があり、その場合の対策として「発注者にレビューへの協力を仰ぐ」と書かれている。

この対策は、「発注者の確認を受けていない」の対策にはなるが、「要件に関する指摘が極端に少ない」の対策にはならないのでないか。
確かに、広義の「協力を仰ぐ」には今以上の協力も含まれるであろうから、対策と言えなくもない。しかし、今、現に発注者のレビューが不十分であるというのであれば、本来は、それに合った対策を取るべきであり、協力をお願いするだけでは、一時的には良くなってもまた戻る可能性が残る。

発注者は大抵の場合お客様なので、優越する地位を持っていることは事実かもしれないが、対策がお願いすることでは十分とは言えまい。

2012年3月 8日 (木)

【続定量的品質予測のススメ】 一定水準以上のシステムの品質

P81「5.2 対策の実施」において、「・・・漫然と行う定量的品質管理は、『管理のための管理』に陥りやすい。システムの品質が一定水準以上になるように迅速に決断し、実行するまでが、定量的品質管理なのである」とある。

論理としては間違ってはいないと思う。
問題は、「システムの品質が一定水準以上になる」という状態をどう判断するかだ。

一定水準以前に、システムの品質とは、何なのだろうか。
本書にその定義はあっただろうか。

それともシステムの品質と言えば誰もが「ああ、あれのことね」というものがあるのだろうか。

レビュー密度が基準を満たせば一定水準以上であると判断するのはまさに「管理のための管理」であろうし・・・。

2012年3月 5日 (月)

【続定量的品質予測のススメ】 基準値からの乖離

P80「設計品質評価の技法」において「過去の経験から得られた基準値とは異なる値になった場合、どの程度の乖離ならば問題とみなすのかもあらかじめ設定しておく。そうでないと、後で問題かそうでないか、恣意的に判断してしまうことになりかねない」とある。

ここでいう基準値は幅を持たないのであろうか。

持たないのであれば、ソフトウェア開発において基準値通りにぴったりに合った設計品質が確保できるということになるが、そうなのだろうか。
一方、幅を持つのであれば、その幅の外延に更に問題とみなすか否かの乖離範囲を設定しろというのであろうか。

単純に問題とみなすか否かの乖離範囲の上下限を基準値とするのでは問題があるのであろうか。

2012年3月 1日 (木)

【続定量的品質予測のススメ】 明らかな異常値も有用な定量的データです

P79「定量分析の準備」において「定量データは、分析前に異常値やプロジェクトの規定フォーマット・ガイドラインに適合していないデータを除外するなどして内容を整え、適切な分析を行うことが望ましい」とある。
また「明らかな異常値を排除してデータ分析を行った方が、適切な問題発見や将来予測につながる」とも書かれている。

その通りだと思う。
一方で、明らかな異常値については、それにつき個別に詳細な分析をすべきではあろう。
そもそも想定しているモデルが間違っているかもしれないのだから。
分析においては、異常値はポイ捨てされて顧みられないこともあると思うが、こちらにも定量的に有意な情報があると考えるべきであり、これはP80「設計品質評価の技法」に書かれている。

« 2012年2月 | トップページ | 2012年4月 »