ウォーターフォル開発の見積り手法については昔から議論されてきました、COCOMOのようなステップ数による見積りから始まり、外部入出力から見積りを行うファンクションポイント法(FP法)、ユースケース図から見積りを行うユースケースポイント法等さまざまな工数見積の手法が提案されてきました。しかし私がたどり着いた最善な見積り方法は KKD法＋積み上げ法 という至って原始的な方法です。 KKD法とは、感(K)と経験(K)と度胸(D)で見積りを行う方法で、熟年経験者の完全なる感に頼るというヒューマンスキルに依存した見積り手法です。 積み上げ法とは、実施する作業を出来るだけ細分化して個々のタスクについて見積りを行った後、それをすべて合計する事で全体の工数とする見積り手法です。 私も昔、だれでも見積りを行える見積り手法というものを目指して様々な方法を模索してきました。その模索の中でわかったことはそもそもF

ウォターフォール開発には工数に見合った適切な開発期間というものがあります。100人月の作業が100人いたら1ヶ月で終わるかといったらそんなことはありません。100人月かかる作業にはそれに合わせた開発期間が必要です。ではどうやって開発期間を求めれば良いでしょうか。 開発期間を見積るにはCOCOMOの指標が役に立ちます。COCOMOとはソフトウェア開発の工数・期間の見積もり手法です。COCOMOではシステム開発にかかる期間を工数をxとした場合 小規模 2.5*x^0.38 中規模 2.5*x^0.35 大規模 2.5*x^0.32 と定義されています。この指標は古いものですが統計情報を元に算出されているためなかなか優秀でJUASが2007年に調査した値でも近い値となっています。 しかしこの値には、 小規模、中規模、大規模の境目が難しい 計算式が覚えにくい 1人月で計算すると2.5ヶ月かかるとい

結局皆さんテスト密度等の実際の数字が気になるところですよね。今まで出てきた数字をまとめてみます。指標の数字は実施している手順やテストケースの書き方等に大きく影響されるので一概にこれが正しいという数字はありません。しかしなにも手がかりや実績も無いという人もいらっしゃるかと思いますのでそのような場合は以下のような設定をおいてみるのも良いかもしれません。ちなみにKLOCはJavaがベースです。 開発期間 開発期間＝工数^0.5 開発期間は平方根で求めます。たとえば9人月の作業は3人で3ヶ月です。 最大期間短縮率 最短開発期間＝工数^0.5*0.75 短縮率は最大75%。これ以下の開発期間はデスマ高し。 工数割合 設計:実装・テスト　3:7 設計終了段階で既に4割くらい使ってしまっているとかなりデスマ率は高いと思うので機能を減らす等早めに手を打った方が得策かもしれません。 ケース数 単体：150ケ

指標に使うステップ数はどのようにカウントすれば良いでしょうか。 ステップ数をカウントするツールはいっぱいありますが、どのツールでも大抵全ステップ数以外に実行ステップ数、コメント行、空白行を分けてカウントしてくれると思います。この中で基本的に指標として使用する数値は「実行ステップ数」です。何故ならステップ数をカウントする一番の目的はテストケース数が妥当かを確認するためです。コメント行や空白行に対してテストは実施しないのでテスト指標として利用する場合は取り除くべきです。 ではXMLやプロパティファイル、HTMLなどの微妙なファイルのステップ数はどうすれば良いでしょうか。基本の考え方は上記と一緒です。そのファイルに対してテストを実施するのかどうかで判断します。例えば単純な設定値を記載するようなXMLでテストが不要なものはカウントとしては含まないですが、XSLTのようなXMLと言いつつ実際はプログ