|
|
- 《 品質管理編 》
要件定義の品質確保。
要件定義工程などの上流工程の品質証明は、
試験工程のそれも後半に示されます。
やっかいなもので、結論は実際に業務に乗せてみない事には
答えが出ないのです。
要件定義の詳細部分は基本設計で洗い出されていきます。
しかし、それは要件定義が正しいものとした前提で
設計が進んでいくのです。
そこで見つかる故障とは、
・詳細設計へ進むにつれて明らかになる他のシステムとの矛盾
・局所的にみたユーザーインターフェースや業務処理手順の誤り
・既存処理との整合性誤り
あくまでも局所的な誤りしか出来ないのです。
しかし、本当の要件定義の誤りは、システムの総合試験や運用試験に
ならなければ見つかりません。
ベンダーにおいては、長年ユーザーと要件定義や基本設計から
かかわっているプロジェクトリーダーが少なくなっています。
それは、ユーザーにとっても同じことです。
長年業務システムにかかわっていても、
企業戦略と全社システムを統一した要件定義となると
なかなか見つけることが出来ません。
それに要員不足が加わっているのです。
さらに
システムが複雑化しすぎて、
トータルで最初考えることが難しくなっています。
故に最初から要件定義が修正なくして、
本番を迎えるなどありえないのではないでしょうか。
むしろ修正はあるものと考えて
要件定義を作成するべきではとも考えております。
３０年ぐらい前の開発では、故障は悪という考え方でしたが、
次第に故障はあるものと考えるようになりました。
故障はあるものの前提に立ち、
・故障を作りこまない作業手順
・故障を早く検出する作業手順
を確立し、それでも故障は潜むという考え方に変っています。
要件定義工程も、
・故障や矛盾を作りこまない作業手順
・故障を早く検出する作業手順
の確立が急がれるのですが、なかなかできない現状があります。
なぜなら、上流工程を担当できる要員が少なく
検討する人が少ないのです。
後半の試験工程になるほど、要件定義の誤りによる仕様変更は、
高くつきますし、仕様変更による影響も大きくなります。
これについては、残念ながら私もいい回答はありません。
要件定義の故障が存在するという前提に基づいて予算組みを
予め行っておく。。。う～ん回答になっていませんが。
|
