ICONIXプロセス × FileMaker シリーズのVol.8は、「ロバストネス分析」について解説します。
ロバストネス分析は、ICONIXプロセスの中でも最も特徴的であり、且つ、これがなければICONIXプロセスを採用する価値がないとさえ言い切ってしまえる中心的なアクティビティですね。
このロバストネス分析・・・
既に登場から20年以上経過している分析手法なのですが、なぜかシステム開発現場で実際に使用されているのをあまり見かけることはありません。
恐らくロバストネス分析自体がUMLの正式なダイヤグラムとして定義されていないのが最も大きな原因と思いますが、この分析手法は極めて強力なので、ぜひ使ってみてください。
この分析手法を実際のプロジェクトに導入することで、以下の様な「こまった」状態を改善する事ができます。
目次
困った1:設計・実装の段階で、システム化要件の漏れが見つかる。
これはW/Fモデルではもはや「おなじみ」と言ってもいいほど発生する問題です。
しかし、この問題を効率的に解消するのはなかなか難しく、「古くて新しい問題」の典型的なものですね。
実際、失敗したシステム開発プロジェクトの失敗の原因の70〜80%は、この要件定義の漏れに原因があると言われています。
ロバストネス分析、及びICONIXプロセス、はこの問題をかなり効率的に解決することができます。
実際弊社では、ロバストネス分析を導入することで、この要件定義フェーズ(要件分析フェーズ)で必ず発生する「要件取り漏れ問題」を大きく改善することができました。
なぜ改善できるかについては・・・ぜひ動画を御覧ください。
困った2:要件定義書の粒度が担当によってバラバラ。
チーム開発となると、必ず設計書の粒度に関する問題が発生します。
特に要件分析・要件定義フェーズといった抽象度の高い情報を扱うフェーズであればあるほど、この問題が顕著に現れます。
弊社ではロバストネス分析とユースケース分析をイテレーティブに反復することにより、この粒度に関する問題もある程度解決することができました。
現在では、ドキュメントの粒度に関して、過度に敏感になることはありません。
なぜなら、要件分析フェーズと予備設計フェーズをイテレーティブに反復することによって、何度もドキュメントにレビューが入ること、及びロバストネス分析のサニティチェック機能によって、自ずとドキュメントの粒度が統一化されるからです。
困った3.要件定義書の粒度が粗すぎて、設計作業へムーズに入ることができない。
ロバストネス分析は、要件分析と詳細設計の橋渡し役を担います。
ご存知の通りユースケース記述は、非技術者でも理解できる言語表現で記述されています。
この総述的なドキュメントから、いきなり、コンピュータの内部の振る舞いを記述する設計に入るには、あまりに大きなギャップがあり、作業がスムーズに進まない場合が多々ありますよね。
ロバストネス図は、ユースケース記述ほど曖昧ではなく、またシーケンス図等コンピュータの内部の振る舞いをより詳細に記述できるダイヤグラム程詳細でもありません。
この程よい抽象度(≒粒度)で記述できることが、要件分析と詳細設計の橋渡しに大きく貢献してくれます。
ICONIXプロセス × FileMaker にアジャスト
弊社の場合、ICONIXプロセスでいう「詳細設計フェーズ」は省略して、実装フェーズにはいります。
っというのも、実装にはFileMakerプラットフォームを用いますし、そのFileMakerプラットフォームの良さを最大限に引き出すため、予備設計フェーズ以降は完全にアジャイルアプローチを取るからです。
よって、弊社のプロジェクトでは、要件分析と詳細設計間のギャップではなく、要件分析と実装のギャップを埋めるためにロバストネス分析を用いるという位置づけになります。
それでは動画の解説をご覧ください。
どうぞ!