|
||||||||||
|
前のページ 1 2 3 |
||||||||||
| 工期計算式の基準 | ||||||||||
|
プロジェクト全体工数と全体工期がともに記入されている105件のプロジェクトについて、工期の3乗根と工期の関係をグラフ化して回帰直線を引いた結果、工期は次の式のようになった。
工期 = 2.67 × (投入人月の立方根) + 0.1
切片を除いた近似式は次のような式となり、COCOMO法とほぼ同じ結果が出た。日本の工期は諸外国に比べてもっと短いと当初は予測していたが、諸外国並みの結果となっている。 工期 = 2.7 × (投入人月の立方根) |
||||||||||
|
COCOMOII法 JBoss工期(月) = 2.7 × (人月)0.33+0.2×Σwi ΣWi : 規模変動要因 規模変動要因は(1)開発の先例性、(2)開発の柔軟性、(3)アーキテクチャ/リスクの理解度、(4)チームの凝集度、(5)プロセスの成熟度(CMM)の5個の構成で、それぞれの要因を六レベル(「非常に低い」から「極めて高い」まで最大5%の高低差)に分類している。また一般に、基本値0.33に対して大きな値にはならない。 |
||||||||||
|
|
||||||||||
| 「貴社に工期計算標準はありますか」と質問した場合、多くの企業のプロジェクトマネージャーは「お客あるいは利用者が希望した納期までの期間が工期です」と答えるのが普通である。そこで、「そうですか。その工期までの開発負荷は非常にきびしいのか?徹夜徹夜の繰り返しになるのか?多少のゆとりはあるのか?その程度をどのように測っておられますか?」と再度確認すると、大半は返事がない。 そのようなプロジェクトマネージャーに1つの目安として使用してもらうのが、上記式の目的である。開発対象プロジェクトの投入人月が予測できたならば、上記式で標準工期を計算する。 次に顧客から要請されている工期と標準工期の比率(工期過不足率)を求める。
工期過不足率 = 1 − (顧客からの要請工期 ÷ 標準工期)
この過不足率をもとに対策を考える。プロジェクトの標準工期に対する過不足率と対策の関係、工期過不足率と品質の関係、プロジェクト終了時のユーザ満足度の関係などを蓄積しておけば、各企業でのプロジェクト失敗は少なくなる。次の工期短縮率対策の例を参考にしていただきたい。 |
||||||||||
![]() 図1:評価尺度と対策 (画像をクリックすると別ウィンドウに拡大表示します) |
||||||||||
| 基本設計、構築、テストの工期比率 | ||||||||||
|
規模別工期比率については、設計工期:実装工期:テスト工期 = 3:3:4 となり、テスト比率が高い結果となった。長いテスト工期を短縮する方法は3つある。 1つ目は、「システム設計の最初から本番への切り替え方法を検討すること」であり、切り替え方法を踏まえてのテスト手法を検討しておくことである。 2つ目は「ユーザビリティを基本設計で検証し、単体テスト完了時に微調整を行う開発手法を確立すること」である(図3、図4)。つまり総合テスト時に使い勝手や運用の容易性の修正作業をしないように、前工程で準備完了しておくことが肝心である。 3つ目は、「単体テストで発見すべき欠陥は確実に単体テストで取り除いておくこと」である。旧システムから新システムへの切り替えをするために準備するコンバージョンシステムを単体テストの開始時期までに、早めに作成してコンバージョンされたデータも活用すると、単体テスト結果はよい品質のものになると同時に総合テスト期間も短縮できる。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||




