 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 分析方法 | ||||||||||
|
分析方法には、図2の3つの考え方があり、順を追って説明する。  図2：3つの分析方法 |
||||||||||
| その1：特性基準値の精度向上を目指す方法 | ||||||||||
|
これは A ＝ b×cx など仮説式を立てて係数を求める方法である。仮説を立ててデータを解析し、特性を解明する。例えば、工期A ＝ 2.7×（人月）0.318 の0.318は適しているのか、それとも0.351の方が適しているのかということをデータの分散分析に基づき追求する。工期と投入工数の関係においてはこういった式が一般に使用されている。 ソフトウェア工学でもこの手法がよく採用されているが、特定の集団の定められたメンバーが開発を実施する場合ならば問題はない。しかし、そのつど集められたメンバーが特別な目標も与えられず、常に新しいテーマを毎回異なる仕様に基づき開発する場合はそうではない。開発しているデータを詳細に分析すればするほど、混乱し悩みが深くなり、泥沼に陥（おちい）る可能性がある。 このプロセスは必要ではあるが、的を絞らずに一般から広くデータを集め解析する場合には、大まかな特性分析をする程度でよい。よって、企業別に分野を絞り、特定の集団の実績分析を行うならば精度向上の意味が出てくる。 ソフトウェア開発の品質と生産性におよぼす要因は非常に多く、それが個々に目標値もなく作業した結果は「ばらつく」のが当然であり、このようなデータをもとに上記係数の精度向上を検討するよりは、大まかな特性をとらえてその活用法を柔軟に求めて行くことが肝心である。 |
||||||||||
| その2：わかりやすい特性基準値をもとに、その活用方法を柔軟に求める方法 | ||||||||||
|
これはその1で求められた何らかの分析結果を基準におき、各プロジェクトではその基準との差を意識して利用する方法である。「基準がないよりは、何かあれば1つの目安になる」との見解で基準を利用する方法である。 その結果、前出の式は次のようになる。
工期A ＝ 2 × （人月）1/3
式を変更した結果、「標準工期は投入工数の立方根の2倍」と覚えやすくなり、計算しやすくなる。単純に「1000人月のプロジェクトは10の3乗であるから、10 × 2 ＝ 20ヶ月 を標準とする」という要領で計算すればよい。 ユーザ企業にアピールするには、こういった柔軟なセンスが必要となる。システム開発の工期とは、「いつまでに開発してほしい」との顧客の要望に基づいて決定される。「標準式で計算すればシステム開発の工期は20ヶ月必要となるが、お客の要望が15ヶ月であるならば、25%工期が足りない。前回プロジェクトを20%短縮して開発したことがあるが、その時の対策よりもう少し何か対策を増やさないと上手く行かない」というように、ある基準と比較して対策を強化するという1つの目安として活用できる。 このJUASが提唱している上記の立方根の法則はBoemのCOCOMO法から借用したものである。べき乗の精度を求めず、むしろこの標準からの差で難易度を判断すれば、COCOMO法は使いやすいものになる。「COCOMO法は当社のプロジェクトには適してない」と判断する前に、このように使いこなして欲しい。 |
||||||||||
| その3：特性を活用する方法（Factベース） | ||||||||||
|
これは因果関係を統計解析して原因と対策の関係を追求するだけでなく、基本的特性を見抜き、その結果を利用する方法である。 既述の例でいえば、「当社では標準工期よりも50%短いプロジェクトは破綻するので、そのようなプロジェクトは実施しない」ということとなり、数値解析ではなく、大まかなデータ分析からでもこのような事実を発見できる。 「ベンダー側のプロジェクトマネージャーが未経験な場合はシステム品質が悪い」「ユーザ側プロジェクトマネージャーの経験度はシステム品質に影響しない」などの事実を正しく認識して広く役立てればよい。このように、「数値解析にのみ頼らず知見を見つけ出し、そのノウハウを活用する」ことも有効な対策の1つである。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
人気記事ランキング
-
-
連載
