« 豪華な施設で打合せをしたの巻 | トップページ | カンカン照りの今日は久しぶりに「神保町」に行くの巻 »

2011年8月 3日 (水)

要件開発&要件管理&構成管理を最大限効果的にするために!

よく効果的な要件開発や要件管理および構成管理の作業について聞かれるが、これらは単独で効率を求める改善活動をしても限界がある。

ISOやCMMIでしきりに作業プロセスやテンプレートばかり整備することを指導してるコンサルタントがいるが、おそらく開発技法に乏しく自らが優れた開発手法や開発・検証環境で作業を経験していないから、指導できないのだろう。

開発手法や開発・検証環境と要件開発や要件管理および構成管理の作業の関連性でいえば、たとえば、要件定義を例にとれば、単に要件定義の作業だけを意識していても成果は薄いのである。

要件定義の中心的な成果物にユースケースがあるが、ユースケースが現在の開発で大変重視されるは、これは単に機能や非機能をユースケースのシナリオで運用フローを明確にするだけではないからである。

実際、多くの組織では十分な運用フローを定義できていない、あるいはその手法を知らないので、真の妥当性確認のレビューを要件定義に実施出来ていない。

このような組織がほとんどであるから、ユースケースのシナリオで運用フローを明確するだけでも大きな効果はある。
#CMMIでレベル3以上に到達している組織でも、技術的な視点から見て、かなり稚拙な要件定義書が多いのが現状である。

しかし、ユースケースドリブンの本当の効果は、要件定義と設計・実装作業は密接に関連するからこそ発揮できるであり、ユースケースドリブンというアプローチをとることで、アーキテクチャ設計の根拠としてサブシステム分割、レイヤー構成の設計、サブシステム間インターフェース設計およびパフォーマンス設計が根拠を持つ設計とすることができる。

並行開発作業を行う場合や優れた構成管理活動に欠かせない理想的な構成単位においてもサブシステム分割の結果は大きな意味をもつ。

サブシステム分割が不適切であると、要件変更などで多くの成果物に変更がおよびやすくなり極めて非効率になるのである。

テスト作業もモジュール試験をおこなうのに、多くのサブシステムを必要としてしまうのでは作業効果が悪い、こうなるのはサブシステム間の独立性(凝集度や連結度が著しく悪いからである)が悪からである。

その結果、要件管理作業も煩雑になり、成果物間のトレーサービリティと内容の整合性の維持が大変になる。

逆に言えば、効果的なサブシステム分割とアーキテクチャ設計さらに保守性や再利用性を考慮した設計を行えば構成管理や要件管理は非常に楽になるのだ。

必要に応じて、さらに独立性を高めるために「依存関係逆転原理」「抽象依存の原理」「リスコフ置換原理」などに代表される設計原則を適用して、構成管理や要件管理に負荷をさらに最小化することだって可能だ。

どのようにすればユースケースドリブンやOOAD、DOADそしてデザインパターンやMDAを使うかは詳細な解説がいるので、ここでは書けないが、要件定義、要件管理、設計・実装、構成管理の作業のプロセスは密接に関連しているので、分離して考えることは本来は不可能であることを理解するのが大切だ。

CMMIのプロセス領域「技術解(TS)」でも固有プラクティス2.2に「技術データーパッケージを確立する」とあるが、この技術データーパッケージはサブシステム毎に関連する設計情報をまとめることである。

CMMI(ISOも他の国際標準規格も)はソフトウエア工学、品質工学が土台になっているので、本当の意味でCMMIを理解活用するには、ソフトウエア工学、品質工学の十分な理解が求められる。

どのようにすれば効果的な技術データーパッケージが確立できるは、CMMIでは言及されていないので、各企業が優れた設計・実装技法を用いて自身で検討することになる。

この際、効果的なアプローチがOOADやユースケースドリブンアプローチおよび他の先端技法である。

大きな組織改革や改善活動には、最新技術テクノロジーとユースケースドリブンを効果的に組み合わせることにより可能であるが、それを指導できるISO監査官やCMMIの資格保持者が少ない。

そのために通り一辺倒な改善活動しか指導できないコンサルタントが多いのが現状である。

最新の技術テクノロジーの知識や経験があるかをまず確認した上でコンサルタントを雇おう。

そうでなければ、まともな改善活動など不可能になるリスクがある。

また逆にきちんとISOやCMMIの資格を保持しているコンサルタントであることも大切である。

正式な資格がないのにコンサルティングを実施している企業が多いのである。

話を本線に戻すと、要件開発や要件管理および構成管理活動を効果的な設計手法を抜きに検討してる組織は非常に問題がある。

多少の成果はあっても、大きな飛躍は望めない。

洋書であるが良い本があるので1つ紹介しておこう。

Ivar Jacobsonが書した「Software Resuse」である。

IvarはUMLの定義者として有名だが、ユースケースドリブン・アプローチの提唱者でもある。

Softwarereuse

Ivarとは過去に一緒に仕事をしたことがり、そのとき同じ会社の優秀なスタッフとも仕事をした。

日本国内の数社の企業に一緒に行った事がある。

「Software Resuse」は簡単に読み飛ばすことができるような書籍ではないが、要件定義がからどのように保守性・拡張性が高いソフトウエア設計と実装ができるかの方法が見てとれるだろう。

保守性・拡張性が高いソフトウエア設計と実装は、構成管理や要件管理も非常に単純化できるのだが、それは構成管理対象(構成管理アイテム)が、効果的に「仕様」と「実装」が分離されているからである。

「仕様」と「実装」を実現するためには要件定義の際に、明確に運用フローを抽出しておくことが大切なのだが、《include》《extend》などのユースケースの定義法や可変性の定義および可変性を一か所に封じ込める技法を読み取ってもらいたい。
#単にソースコードについてのみ当てはまるのではなく、文書など成果物全般に適用できることに注意せよ。このときも技術データーパッケージの確立技法を意識する。

さらにこのアプローチをは発展させたもに、ユースケースによる要件定義から横断的な関心の分離を実現するアスペクト指向のアプローチを導入することが出来る。

まずは、基礎となる部分を確実に理解することが大切だが、それと同時に要件開発や要件管理および構成管理の作業プロセスが最大限に効率化できるのである。

|

« 豪華な施設で打合せをしたの巻 | トップページ | カンカン照りの今日は久しぶりに「神保町」に行くの巻 »

「パソコン・インターネット」カテゴリの記事