« 2005年11月 | トップページ | 2006年1月 »

見積もり手法「KKD法」

これまでの見積もり手法 紹介の続きです。('08/3/4修正)

・見積もり手法「KKD法」

もっとも広く(?)普及している見積もり手法です。というか、こんなもの手法ではありません。「エンジニアの経験と勘に頼った見積もりのことを KKDと呼ぶ」というのが正しいです。

KKDとは、K(勘)、K(経験)、D(度胸)のそれぞれの頭文字をとっています。根性(K)根性(K)ど根性(D)の略でもないし、火事場(K)のくそ(K)力(D)の略でもありませんのであしからず。

KKDの長所は 短時間で算出できること。いわゆる「エイヤー」でだす見積もりですので そりゃまぁ算出は早いです。
また、熟練した技術者のだした見積もりはKKDであっても、説得力があるというのも長所です。(これが実際に当たるかどうかは また別問題ですが...)

欠点は 見積もり結果そのものが 見積もり担当者の主観とスキルに依存するため、精度が人によってまちまちになることです。ようするに 信頼性が低く、よく外れます。

また、主観に依存した見積もりなので、「いったい何に基づいて算出されたのか」という 見積もりの根拠が非常に薄いことも欠点です。見積もりが外れた場合に、その失敗を 次回に生かしたくても、そもそもの見積もり根拠が薄いため 生かしようがありません。このため、失敗を次回に生かすという、改善を行いにくいという欠点も持っています。

ということで、個人的には 非常にまずい手法だと思うんですが、残念ながら世間では 一番信頼されている見積もり手法です。

| | コメント (0) | トラックバック (0)

見積もり手法「FP法(Function Point)」

昨日の続きで5つ目の見積もり手法です。

・見積もり手法「FP法(Function Point)」
ユーザ視点からの機能を 定量化をすることを目的にしていて、システムの機能量を計算する見積もり手法です。
LOCと同じく客観性を重視しています。LOCとの対比で特徴をまとめると、
・LOCは開発言語に依存してしまうため 異なる開発言語間では使えません。しかし、FP法は開発言語に依存しません。
・実際に開発した量ではなく、開発する機能の量を測るため、ユーザの立場から値をとらえやすくなります。

FP法で計測された規模はファンクションポイント(FP)と呼ばれて、コード数や工数などに換算されて利用されることが多いようです。

FP法にはいくつかの計測手法があり、中でも一番普及しているのが、IFPUG法と呼ばれる計測方法です。これは GUI系アプリケーションに適していると言われていますが、組み込みにはあまり向いていません。

ちなみに組み込み用FP法としては、COSMIC-FFP法という計測方法が存在しています。

欠点ですが、FP法の算出は、要求仕様書から行います。つまり、要求仕様書が確定する以前には算出できません。また他の手法に比べると見積もりに時間がかかりますし、見積もり手法の習得にも時間が必要です。

本気でファンクションポイント法を理解しようとするとそれだけで本がまるまる一冊かけてしまいますし、それだけ敷居が高いのが大きな欠点です。

ただ、他の見積もり方法が持っていない 信頼性の置ける客観性を持った数少ない見積もり手法です。欠点を補うだけの長所を持っている手法だと思っています。

| | コメント (2) | トラックバック (0)

見積もり手法「COCOMO/COCOMO II 」

昨日の続きで4つ目の見積もり手法です。

・見積もり手法「COCOMO/COCOMO II (COnstructive COst Model)」
昨日までに紹介した類推法、LOC法、WBS法は手法というほどたいしたものではありませんでしたが、これは「手法」と呼んでよいと思います。
開発するソフトウェアの行数を把握し、その行数に補正係数を掛け合わせて開発工数に換算する手法です。

次の式から算出します。(実際はもうちょい ややこしいですが)
  式:P = a×(K^b)

(P:開発作業量、K:キロステップ、a, b :要員の技量や組織特性に基づいて推定されるパラメータ)
プログラムステップ数とその開発作業量(工数)の間に一定の関係式があるという統計的推論に基づいてます。

さらにCOCOMOにFP法(Function Point)の要素を取り入れたものがCOCOMOⅡです。

欠点ですが、まだ開発していないソフトウェアの行数をどのように把握するのかという問題があります。
また、実際にはパラメータ(a, b)の推定が困難です。
というわけで、式は美しいんですが、結局LOC法における試行錯誤の一種と言えます。

…紹介しておいてなんですが、使ったことがありませんので どの程度使い物になるのかよくわかりません。

| | コメント (0) | トラックバック (1)

見積もり手法「積算法、WBS法」

昨日の続きで3つ目の見積もり手法です。

・見積もり手法「積算法、WBS法(Work Breakdown Structure)」
WBS等によって 細分化されたタスク毎に工数(作業時間)を求めて それらの推定した工数を積上げることにより 見積もりを行う手法です。
細分化の程度の差はあれ、どこでもやっている見積もり方法だと思います。手法というほどたいそうなものではありません。

この方法の欠点は 積上げによる見積もりであるため、項目の抽出漏れや想定外作業により、結果的に現実離れした見積もり結果になるという可能性が高いことです。
要するに 想定外の作業が発生するとアウトということです。
私の経験上、ほとんど場合過少見積もりとなって 結果にあらわれています。

逆に時々 積み上げ型の見積もりは 同じ作業内容を重複してカウントすることがあるため 実際よりも工数が多くなるはず…という人もいます。
言わんとすることはわかりますが、私の経験上 過少見積りになったことはあっても 過大見積りになったことは一度もありません。
また、重複する項目は工程のレビューを行えば たいてい排除されますし、積算法が過大見積りになりやすいというのは説得力が低いと考えています。

| | コメント (0) | トラックバック (0)

見積もり手法「プログラムステップ法、LOC法(Lines Of Code)」

間隔が空いてしまいましたが、前回の続きで見積もり方法です。(2008/3/2修正)

・見積もり手法「LOC法(Lines Of Code)」

プログラムステップ数(LOC)に生産性を掛け合わせておこなう見積もりです。
要求仕様から開発するプログラムのコード数を推定し、そのコード数と1コード当りの生産性から全体の工数見積りをします。
過去の類似システムにおける実績値(LOC)から推定することになるため、その意味では本質的には類推法と変わりません。

長所は 工数見積もりの根拠を数字で出せるため、一見説得力があること。
LOCの算出そのものは容易であることです。

短所は、要求仕様からLOCを推定する確実な方法は存在しない点と、根拠とするLOCそのものの信頼性が低い点 です。
要するにあんまりあてになりません。

使いどころはある程度限定されていて、開発の際の流用元のソースコードの記述内容(レベル)が ある程度安定していて、かつ 過去のLOCが残っている場合のみ、それなりに役立ちます。
実際にはLOC法を単独で使用することはあまりなく、類推法と積算法を組み合わせることが大半になります。
なお、完全な新規開発の場合は過去のソースがありませんので、当然LOCは使用できません。
だから、LOC法を完全な新規開発で使用するのは非常に困難です。

・LOCについて
LOCそのものはプログラムの規模を表す指標の一つで、ソースコードの行数のことです。
呼んで字のごとくコードの行数。プログラムの規模を計る指標のひとつです。

「いまさらライン数」と思いつつも、ほかにいい指標もなく、比較的よく使われる指標です。

よく使われる割に信頼性が低いという致命的な欠点があります。
理由は少し考えればわかることですが、ざっとピックアップするだけでも これだけあります。

・同じ機能のプログラムでもプログラマの力量や選択するアルゴリズムなどによって記述量が全然違う
・同じ機能でも冗長な書き方をしたほうが規模が大きいと判定されてしまう。
・現在利用されているプログラミング言語の多くはソースコードの改行に関して制約が少ないため、プログラマによって改行を挿入する「流儀」が異なる
・同じライン数でも、新規に開発するライン数 と 既存部分を改修するライン数は難易度が全然違う。

さらに、使用可能な環境も限定されます。
採用する言語が違えば 比較の対象には使えません。
そもそも GUIの開発なんかだと 言語がないため 算出が不可能です。

結局のところ 計測が簡単である以外 特にメリットはありません。

| | コメント (0) | トラックバック (0)

見積もり手法「類推法」

  ようやく仕事が落ち着いてきました。
  …と思ったら次のプロジェクトがもう動きはじめています。

  んで、どの程度の作業量になるのか見積もりしないといけないわけなんですが、やっぱり見積もりは難しく、とにかく苦しんでます。
 
  というわけで、何か言い方法が無いか色々と調べてみました。
  いくつか方法が見つかったんで、各方法を私なりの解釈を加えつつ ざっとまとめてみます。
 
類推法
プログラムステップ法、LOC法(Lines Of Code)"
積算法、WBS法(Work Breakdown Structure)"
COCOMO/COCOMO II(COnstructive COst Model)
FP法(Function Point)"
KKD法

 
・見積もり手法「類推法」

経験値による見積もりであり、過去の類似の開発事例から開発規模を類推する手法です。
「手法」と言うほどたいそうなものではありませんが、過去の数字を使えるため あてずっぽうの見積もりに比べれば有効です。

ただし、欠点もあります。
過去のプロジェクトのデータを役に立つほど蓄積できるところとなると、ある程度大手の開発業者に限られてしまうため、なかなか過去のデータを入手できません。
また、開発手法の変化があったとか、過去に類似の開発事例がないと使えないとか、過去のデータが役に立たない場合も多いです。

とは言うものの、過去の実績が使える環境にあるならば 積極的に用いたい手法です。

続きはまた次回に…

| | コメント (0) | トラックバック (0)

テストエンジニアにはサドが向いている

ここしばらくバグの山に埋もれていましたが、ようやく一段落してきました。
まだ油断はできませんが ようやく一息つけそうです。

そんな大量のバグの山に埋もれながら ふと感じたことがあります。

いろんな方がバグの報告をしてくれるわけなんですが、中には本当に申し訳なさそうにバグを報告してくる人がいます。

バグの指摘は 我々 開発側の人間、実装者に作業負荷をかけるのは確かですし、こちらのことを心配してくれること自体はありがたいです。
ですが、テストエンジニアはバグを見つけるために試験しているわけですし、そこで「いい人」になる必要はないでしょう。テストエンジニアがバグを見つけて申し訳ないと思ってしまうことは、テストエンジニアの仕事を自己否定しているように感じてしまいます。

そんな人を見ているとテストエンジニアにはやっぱ性格的な適正があると思うんですが、実際のところはどうなんでしょうか?

人の不具合を嬉々として指摘できるぐらいの方がテストエンジニアには向いていて、いわゆるサド(S)、マゾ(M)でいうならサドが試験者向きだと私は思うんですが...

| | コメント (0) | トラックバック (0)

人を見る目

恐れていたとおりこの週末は出勤するはめになってしまいました。
ある程度 バグがでることは予想していましたが、とんでもなく大量のバグが発生して、まさに想定外の状況です。

ぶっちゃけた話し、安い外注を使ったつけを思いっきり 食らっています。
今回のバグ改修に使った費用を考えれば、もうちょっとマシなところに発注するだけのお金があったのにもったいない限りです。

このごろ思うんですが、外注に払う金額とその能力はある程度の相関関係があるとみたいです。あくまでも私の経験上ですが、やっぱり高いところは それなりにしっかりと仕事をしてくれます。

前職で使っていた外注と今使っている外注のお値段を考えると 今のほうが格段に安いんですが その分 役に立たない人がくる確率も高いです。昔 値段の高い外注を使っていたころは、役に立たないからクビを切るなんてことは稀だったんですが、今では首切りなんぞ しょっちゅう やっててめずらしくありません。

派遣会社の営業が結構てきとーな事もあり、スキルミスマッチな人が来てしまうんですが、
このような場合 雇う側にとってはお金と期間をドブに捨ててしまうようなものですし、雇われる人にとっても精神的に苦痛でしょうし 双方にとってメリットがありません。(派遣会社的にはお金が入るのでおいしいのかもしれませんが…)

人を見る目ってのは重要ですが、なかなか難しいところです。

| | コメント (0) | トラックバック (0)

クソース フォー!!!

  害虫…もとい 外注から引き継いだソースがバグでまくりで、どうしようもありません。
  総合試験がもう3順目に突入しているにもかかわらず、新しいバグがバカスカでる始末です。

  おんなじ試験を繰り返しているというのに、何で毎回新しいバグが発生するのやら 正直信じられません。
  一応外注内で試験を行ったうえで 納品したと言って来ているんですが、あまりにも品質が低く とても試験してから納品されたとは思えません。

 
  あまりにも酷いので どのように納品されたのかちょっと調べてみたんですが、ここで とんでもない事実がわかりました。

  確かに、単体試験書は納品されていて、全部OKとはなっていました。

  OKとなってはいたんですが…
  明らかに動いていないところが OKになっています。
 
  …どうやら NGがあるくせに全部OKと偽造していたみたいです。
 
  正直、ソースコードがどうとか SEとしてどうとか それ以前の問題で論外です。
  というか、詐欺だと思うんですが!?

  ったく…
  オノレは姉歯建築設計事務所デスカーーー????

  はぁぁ、とんでもないものを引き継いでしまいました…

| | コメント (0) | トラックバック (1)

« 2005年11月 | トップページ | 2006年1月 »