ラン

品質保証に関する提言(終り:変化する要求)

最後になりますが、

システムは、「契約時の曖昧性」、「その後の変動性」、「その結果としての膨張性」という三大特性がある。

そして、厳しいシステムの損益は、見積り/契約条件(即ち契約内容)で5-8割が決まり、プロジェクトが開始してシステム仕様が固まるまでに8-9割、システム開発で残りの1-2割が決まるとまで言われている。

「始めが肝心」であり、見積り/契約の重要性はいくら強調してもしすぎることはない。

このようなシステムに対して、要求が、開発に着手する前にどれだけ合意に達するかは、プロジェクトを成功に導く大きなポイントである。

通常は、80~90%が合意点に達していることが目標である。

それでも、要求は変わる。

要求の内容を正確に把握するのが難しいだけでなく、要求そのものが変化しやすいものであることから、長期の開発プロジェクトを成功させることが難しくなるわけである。

プロジェクトの期間は長くても1年である。

このため2年という期間が設定されたプロジェクトは、最初から成功させる意図が存在しないものということもできる。

成功の目算はあるのかと言われると、明確に答えることは出来ない。

実際には、要求は変化させないとか、リスクが存在しないとか、非現実的な制限を付けないと、成立しない計画になる。

このような状況に対して、
「ウオーターフォールモデル」、
非ウォーターフォール・モデル(「スパイラルモデル」や「プロトタイピング」)、
繰り返し型開発モデル(「インクリメンタル開発」や「イテレーティブ開発」)、
「アジャイルソフトウエア開発」、
オープンソースにおける開発方法「伽藍(がらん)方式」や「バザール方式」等、
といった開発方法やモデルが提案されております。

最後になりますが提言としては、
第一に、第三者に品質保証作業を委託する仕組みを作る必要がある。
第二に、品質の質の向上という点で、プロセスの改善が必要である。
第三として、詳細な作業の工数見積りは困難を喫すが計画を立て挑戦し開発にあった手法やモデルを適用する必要がある。


終わり。
名前:
コメント:

※文字化け等の原因になりますので顔文字の投稿はお控えください。

コメント利用規約に同意の上コメント投稿を行ってください。

 

最近の「品質保証活動のあり方」カテゴリーもっと見る

最近の記事
バックナンバー
人気記事