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            
無料ブログはココログ

« 2009年1月 | トップページ | 2009年3月 »

2009年2月

2009年2月26日 (木)

【ソフトウェア信頼度成長モデルを考える②】現場における様々な言い方、使われ方(2)

1.対象となるテスト期間

(1)特定テスト内でのモデル
   例えばシステムテストの最初から最後までを対象とするという考え方
   結合テストとシステムテストと2つのテストを合わせて実施するのもこちらに入れておく。

(2)テスト全体を通じたモデル
   例えばモジュールテスト(単体テスト、ユニットテスト)からユーザ受け入れテストまでのおよそテストと名の付く工程全てを対象とするという考え方  

モジュールテスト、結合テスト、システムテストは、それぞれ異なる視点でテストするものであるから、それら全てを通じて、統計的に有意な形でグラフ化されるということは考えづらいので、(1)の使い方が良いであろうし、一般的であろう。

2009年2月24日 (火)

【ソフトウェア信頼度成長モデルを考える①】現場における様々な言い方、使われ方(1)

ソフトウェアテストにおける発見されたバグの傾向をみる手法として、「ソフトウェア信頼度成長モデル」「ソフトウェア信頼度成長曲線」「バグ成長曲線」等と呼ばれる考え方がある。
これらは、意識的にどれかを選んでもしくは使い分けている人もいれば、同じものを指しているのに場面場面で違う名称で呼んでいたりする人もいる。

つまり「ソフトウェア信頼度成長曲線」「バグ成長曲線」を使い分けている人もいれば同じであると思っている人もいるので、話がかみ合わないこともある。

名称が違うだけなら、まだ良い。
その内容自体が人によって違っていたりする。

これは、学問的な定義がどうのということもあるが、信頼度成長モデルが、直感的視覚的には理解しやすいので手を出しやすく、開発現場で活用されているが、実際の運営においては前提条件や過程において難しい点が多いモデルであることから来るものでもあろう。

次からは、とりあえず「ソフトウェア信頼度成長モデル」と呼ぶことにするが、これが開発の現場でどのような意味で使用されているか考えたい。

2009年2月 6日 (金)

【定量的品質管理あれこれ③】ソフトウェア品質の定量的管理ができる条件とは

ソフトウェアは人が作成するものであるから、計測する定量データにバラツキが生じるのは避けられない。
また、そもそも毎回同じ仕様のものを作るわけではないから、それぞれの成果物のバラツキ(規模、難易度等)が本来的に内包されている。

これらも考慮した上で、定量的管理ができる開発とはどのようなものであるか考えてみる。

要は、定量管理する測定項目が開発毎にばらつかない、もしくはバラツキが小さければ良い訳である。

そのようなな開発はあるのか。

開発自体のフレームワーク化、部品化を高度に進めて、ほとんど人手によるコーディングという作業を行わずしてプログラムが書けるような開発であれば、バラツキをより小さくすることが可能であろう。
また逆に、開発サポートツールやプログラムの自動生成の仕掛けがほとんど無い、昔ながらの手で一行一行書いていく開発野場合に、開発標準・規約をガチガチに定めれば、可能かもしれない。

そうではなく、ツールを使えるところはツールで、ツールが無い部分は手作業で、といった開発では、開発量(FPにしろSLOCにしろ)を分母にした定量管理はバラツキが多くなるであろう。

既に書いた通り、開発とは名ばかりで、実際は既にある部品の組み合わせと、それらに与えるパラメータとテストケースを考えるだけで、実際ほとんどコーディングをしないような開発・・・、この場合は定量的管理が出きるのではないかと考える。

部品毎に、考えるべきパラメータ数とその難易度、テストケースパターン数等の定量的管理項目が予測でき、部品の組み合わせは、各々の部品の定量的管理項目の何らかの組み合わせで評価できるであろうから。

この次元に至っていない開発の場合は、人手によるバラツキとの格闘は避けられないのではないかと考える。

2009年2月 5日 (木)

【定量的品質管理あれこれ②】定量的管理におけるデータのばらつきに目をつぶるな

システム開発において定量的管理を難しくするデータのばらつきについて考える。
データのばらつきはどのようなときに生じるのであろうか。

個別のデータ項目によらないばらつき要因としては、
  ・作業者の能力レベルの違い(プログラマの生産性は10倍以上と言われる等)
  ・プロジェクト毎、要件毎の要求レベルの違い
  ・開発支援ツールの活用度合い
等が挙げられる。

これら要因によるばらつきは無視できないと考えるべきである。
定量的管理を行う際に最も注意すべきは「出てきた数字を盲信しない」ということである。
ばらつきを考慮した上で数字を取り扱わねばならない。

たとえば、新人とベテランプログラマの混成チームの人月当たりSLOC量はどうやって定量化するのかという場合に、単純に各人のSLOCの和と労働時間の和を出して割ればよいというわけではないと、分かるであろう。

分かるであろうが、そのように行っている組織があるのは何故か。
それは、ある程度の規模のプロジェクトではそれらが収束するであろうと期待しているからだという理由付けがなされることが多いと思う。

しかし、「人により10倍の差があるものが収束などするのだろうか」という疑問に統計学的に答えることは困難であろう、

にもかかわらず、
  単純に各人のSLOCの和と労働時間の和を出して割る方法
で、生産性が測られることが多いのは何故か。

それは、そこでいう生産性が何のために算出されるのかと言う目的に遡れば理解しやすい。

純粋な意味で自己の開発プロセスを改善するためであれば、ばらつきは厳密に評価されねばならないのではないかと思われる。
しかし、これを出すことで「誰かを説得できる」のであれば話は別である。
ばらつこうが何だろうが、「今回のプロジェクトの生産性はこれこれで、所期のパフォーマンスを出せています」と顧客や上位管理層にアピールするためであれば、個々のデータのばらつきについては「どうでも良い」と言えるかもしれない。

このような使い方は邪道だ、という意見が出ることは理解できる。

しかし、これも定量的データの活用方法として認めるべきであると考えるし、個人的には、これがソフトウェア開発における定量的データの最も有効な使い方であると考える。
あまりにバラツキが多いデータから改善の機会を見つけたり、改善の効果を定量的数字で表すことは、非常に困難なことであると考えるからであるし、劇的な改善の契機は地道な計測からではなく、定性的管理で発見できると考えるからである。

ツールを導入して「導入前対比○○%生産性がアップしました」というのは「顧客や上位管理層にアピールするため」であって、それで更なる改善のきっかけにはならないのではないか。

但し、「顧客や上位管理層にアピール」はしないと、新しい取り組みが許可されないこともあるだろうから、そのために計測することは「あって良い」と考える。

2009年2月 4日 (水)

【定量的品質管理あれこれ①】プロジェクト内で完結する定量的品質管理

ソフトウェア品質の定量的管理の切り口として、同一システムの過去の蓄積データや別システムの類似プロジェクトデータを使用した管理と、同一プロジェクト内データを使用した管理に分ける考え方がある。

過去の蓄積データ・類似プロジェクトデータを使用した管理とは、過去のプロジェクトにおいて計測したデータを元に、今回のプロジェクトにおける当該データの傾向を予測し管理するもので、通常の場合に定量的管理と言えばこちらを指すことが多い。

次に、同一プロジェクト内データを使用した管理とは、例えばパイロット的に一部を開発し、そこで採取されたデータを指標値としてそれ以降の開発を管理していくものである。他の例としては、結合テストやシステムテストの段階で、不具合発生プログラムを追跡し、特定のプログラムもしくはプログラム群に何らかの傾向がないかをみることや、同様の考えから、複数の基本設計書を作成した場合にそこから発展する詳細設計書、プログラムソースの欠陥傾向を分析し、特定の基本設計書が他と対比して異なった傾向を示している場合に何らかの手を打つ等の管理がある。

過去の蓄積データや類似プロジェクトデータは、あくまで今回とは別のプロジェクトのデータであり、蓄積データは、個々のプロジェクト毎の前提条件の違いを無視したものであり、今から取り組むプロジェクトに適用するにあたっては、それら違いに応じた精度で定量的管理を行わねばならない。
例えばSLOCの生産性を3桁4桁の精度で管理することができるか否かは、算数的なことではなく、個々のプロジェクト及び同一プロジェクト内における様々なばらつきを考慮して決めるべきことがらである。

同一プロジェクト内データを使用した管理においては、特定の個人が作成した成果物や特定の機能に不具合が集中するという傾向をつかむことができる。
プロジェクトを走らせながら定量的に見てパイロットデータもしくはその他のデータと歩調が合わないデータを発見するという考えである。

当然のことではあるが、個人を責める材料にこのデータを使用することは厳禁である。しかし、本来的に個人を追い詰める可能性を秘めているデータと言えるので取り扱いには細心の注意が必要である。
そもそも、同一プロジェクト内といえど、成果物間で要件の複雑度や要求される品質レベル等の差があることが多いので、外れ値なのか誤差なのかの判別の難易度は、過去の蓄積データや類似プロジェクトデータ対比では易しい可能性はあるが、それでも難しいことには変わりはない。

2009年2月 3日 (火)

【ソフトウェア品質の定量的管理における想像力④】毎年目標値を改善しても毎年達成できてしまうという表彰すべき組織

見積もりを誤ったため実際の工数が計画対比オーバーして失敗したという事例が多い組織は、逆に、見積もりを誤ったため実際の工数が計画対比アンダーして失敗したという事例も多くてよさそうなはずである。
もし、工数オーバーの事例のみしかないのであれば、慢性的に見積もりを適正値より低く行っているか、実績対比見積もり工数が多いときは、なんとなく消化してしまっているのであろう。計画通りと言うことで、だれも文句を言わないのだからそれで良いという考えもあろう。
しかし、工数オーバーの場合はそうはいかない。誰かがその工数を負担しなければならないし、誰かが責任を取らなくてはならなくなる。

ここで指標値に戻って考えると、工数オーバーの場合は工数・成果物量ともに実際の数が計上されるだろうが、工数アンダーの場合は、どうだろう。

実際は、見積もり対比小さな工数で開発が出来たはずが、見積もり通りの工数が計上されていたら、生産性は小さくなろう。
計画対比かなり早く出来そうであれば、ゆっくりとやろう、早く帰ろうという気にならないか。

このあたりに生産性の指標値における作為の可能性が潜む。
定められた生産性を達成するため、最低限のバーは超えねばならないが、あるプロジェクトで見積もりを誤ったのか生産性が劇的に向上する見込みとなったからと言って、そのまま報告されると期待してよいのだろうか。
なぜずば抜けて良い結果になったかわからない値を素直に報告して、指標値見なおしにあたって上方修正されるのでは、開発者としては積極的に報告する気にはなれないのではないか。

一度数値が設定されたら、それが色々な意味で開発のベースになる。
数字を設定された値に近づけようというモチベーションが働くことを止めるのは難しい。

最初に実際の開発能力対比低すぎる値を設定してしまったら、それは本来得られるべきパフォーマンスを低下される方向に働くという可能性があることを意識するべきである。

ゆえに、3つや4つの計測データを採って、それを元に仮指標を作成して、以後はデータが増えるたびにその結果を取り込んで数字を精緻化していけばよいという考えは、仮に採用するのであれば、取得するデータが恣意的要素が入り込む余地の無いものに限った方がよいであろう。

さもないと、毎年目標値を改善しても毎年達成できてしまうという表彰すべき組織を、希望すればいつでも作れてしまうことになろう。

2009年2月 2日 (月)

【ソフトウェア品質の定量的管理における想像力③】想像力について始めに立ち戻って再考

実際に、ある項目について定量管理を行う場合、

①計測項目もしくはそれらを組み合わせて導出された数字が、知りたい情報を定量的に表しているという合理的理由はあるか
②①で定量的に表すと結論できたとして、管理限界の範囲は、管理する上で有効な幅に収まるか

の2つについては、必ず検討しなければならない。

①は、普通行うだろう。
工数と生産量や生産量とテストケース数など、何らかの関係が想像された上で組み合わせが定められるはずだ。

しかし、②はどうだろうか。
生産性の管理図を作成してみて、上限と下限の値が1.5倍以上になったりしていないだろうか。
1.5倍の範囲なら収束しているよと言える組織であればよいが、それは予算のぶれが中心値対比そRRぞれ25%ぶれても構わないということに近い。
本当にそれでよいのだろうか。

計測開始して、いくつかのデータが採れたら、それを元に仮指標を定めて管理を始めればよいという考え方もある。
そのように定量的管理を始めることがまったくナンセンスであるとは言えないが、留意すべきことはある。

最も意識すべきは、そのデータの使い方である。
生産性であれば、始めに測定したデータはそのシステムに対する担当者の経験が浅い段階での測定値であるので、開発が進むにつれて生産性が上がっていくことが見こまれる。

当然、品質管理担当者もそれは知っているので、データの集まり具合を見て生産性指標値を上位補正することを考えるであろうが、開発側からすれば、少しでも楽をしたい、儲けたいという自己の利益のためだけではなく、いざと言うときの予備工数を取っておきたいと言うプロジェクトを成功させたいという意識からの心理も働き、意図的に生産性を調整することが可能な計測方法の場合、集められた数字が恣意的なデータになるリスクがある。

これは、別に指標値をデータ収集の初期段階で始めた場合に限らないが、最初に定められる目標値、もしくは上下限値の設定は最も重要である。

指標値の多くは、人による作業の一面に着目して計測される。
生産性なら。成果物量と工数が真に正比例の関係にあれば計測を正しく行う限りごまかしようが無いが、実際には、成果物量に対しては難易度が、工数においては個人の能力差が、真摯に開発に取り組んで計測を正しく行ってもデータのバラツキ要因となるし、工数に関しては、上手く言っているときや開発の初期には、たとえ見積もりが実際に必要であった工数対比過大であっても、それに合わせた開発をするために工数はちゃんと消化されるであろう。

« 2009年1月 | トップページ | 2009年3月 »