最初に可視化、後で作成

作者 Dave West , 翻訳者 編集部Ｎ 投稿日 2010年7月6日

セクション

エンタープライズ・アーキテクチャ,

プロセス/プラクティス,

設計/アーキテクチャ,

デベロップメント

トピック

Business Process Modeling ,

Artifacts & Tools ,

顧客要求 ,

Business Process Management ,

Visualization ,

SOA ,

ビジネス ,

エンタープライズアーキテクチャ ,

Architecture ,

Agile ,

パフォーマンス&スケーラビリティ

共有 |

原文(投稿日：2010/06/28)へのリンク

iRise は、その名を冠した製品を「最終製品のルック・アンド・フィールと動作を真似る、ビジネス　ソフトウェアの動くプレビュー版を早く作り上げる、エンタープライズ　可視化プラットフォーム」と説明している。これは、最近の Computerworldの記事で、 Esther Sheinが書いた 最初に可視化、後で作成：シュミレーション　ツールの強み とウェビナーによるアナウンス、 要求の可視化ツールを活用する：バイオテクノロジ会社におけるAgileのケース スタディで特集された。ユーザ インタフェースを可視化し、ビジネスプロセスをモデル化し、そしてユーザとのやりとりをシュミレートする自動化ツールを使用することは、もっと一般的ツール例えば、主にテキスト形式で、システムの要求を長いリストにする、表計算ソフトよりもずっと優れている、と考えられる。

Shein 氏は、 Framinghamにある IDC社のアナリストである Melinda-Carol Ballou氏の話を引用し、特に今日の経済状況では、よい要求の重要性は、ますます注目されている。

ビジネスの利害関係者 が、ソフトウェア開発者に自分たちの要求を伝えることの難しさは、今に始まったことではない。しかし、不況 の影響で、この難しさに対処することが、もっと重要な意味を持つようになっている。増々リソースが足りなくなる中で、間違っている余裕などなくなっている。そのため、作るものとビジネスが本当に必要なものとの乖離があると、失敗コストが非常に顕著になる。要求を可視化して、スクリーンで見れば、ユーザは、具体的に見える、すなわち、物理的な言葉で、要求が意味するものを見えるわけである。

Shein氏は、より良く要求を把握することができれば、「難しい」そして「失敗」したプロジェクトの良く知られた問題に対処できると考えている。

Standish Groupの報告では、2006年から2008年の間で、プロジェクトの成功率は、下がっている。2008年では、プロジェクトの約44％が、遅延、予算超過、そして／あるいは要求されたフィーチャや機能[難しい]が欠けていた、そして24%が失敗そして完成か引渡し前にキャンセルされたか、全く使われなかった。2006年では、失敗の割合は、19%だった。

要求の可視化ツールがこの状況を改善できる範囲においては、ツールの価値は、明らかである

iRise は、どんどん競合が増す市場で、戦っている。 Computerworldの記事に載っている競合には:

• Blueprint、CSSフレームワーク
• RavenFlow 英語の文書を解析して要求を構造化するように、設計されたビジアル要件定義ソフトウェアを提供している。
• The Blueprint Requirements Center は、ビジネスプロセス図、ユースケース、UIモックアップを含んだ要求を定義する基盤を提供する。
• Microsoft の Visual Studio 2010 Ultimate には、 Expressionという、反復的に、ユーザインタフェースをプロトタイプする非公式な方法を提供するツールがある。
• IBMは、 Rational Jazzプラットフォームを提供しており、その中に、開発チームがプロジェクトのライフサイクルを通して、要求を効果的に定義、使用するのを助ける Rational Requirements Composer を持っている。

これらのツールは、グラフィカルにユーザインタフェースを表現でき、ビジネスプロセスやロジックをモデル化する方法を提供する。

Shein氏が、述べているように、完全で、正確で、曖昧さのないシステム要求を把握することは、新しい問題ではない。Fred Brooks 氏が、（「銀の弾などない: ソフトウェアエンジニアリングの本質と偶有的事項」の中で） 言っているように、ソフトウェアでは、概念的な構成物（精神的あるいは、ビジアルな表現）が欠けていることが、その本質的な難しさなのである。

要求を把握するために、自動化ツールを使うのにも、同じくらい長い歴史がある。 Dan Bricklin氏（ Visicalcの共同発明者、最初の商用表計算ソフトで、しばしば、デスク コンピュータ革命とApple社の初期の成功の火付け役となり、「キラー　アプリケーション」として名を上げた）は、 Demoという「高速プロトタイピング ツール」を作って、ユーザインタフェースをグラフィカルに表現し、そのインタフェースとの基本的なやりとりをシミュレートした－1970年代である。コミュニケーションの改善とソフトウェア インタフェースに対する顧客満足度の向上のためにそのようなツールを使うことの価値は、はっきりと示され、すぐに Demoをまねた多くの似たような製品が出てきた。その後の数十年は、この種のツールの採用を妨げる２つの問題があった：１つ目、プロトタイピングを危険で、間違いの元になると、あざ笑うソフトウェア　エンジニアリングの支持者によって、プロトタイピングという考えは、非常に異論があった。２つ目、ユーザの期待が間違っていた　－　完璧なプロトタイピングを見て、アプリケーションの開発が本質的には、終わったと考えられがちだった！

要求の可視化ツールの市場は、伸びると見られている：2007年は、1億9400万ドルと報告され、2013年までには、2億9000万ドルと見込まれている。これは、爆発的な成長とは言えない、そして、これまでの製品ができなかったことを今日入手できるもっと洗練された製品が、できるようになるか、どうかはまだ分からない。