 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| SOA時代にむけて、品質の定義は変わった | ||||||||||||
|
皆さんは品質という言葉を耳にした時に何が思い浮かびますか。大体は表2にあげるようなことではないでしょうか。
表2：品質といえば
と、いきなり総論から入っていますが、品質という局面が語られる場合、多くは開発という作業の成果物に焦点が当てられます。「同意された仕様を実現するのが開発」という暗黙の了解のもとで、障害とは「同意された仕様が実現されていない」ということを意味します。 コーディングのミスというミクロなところから、所定の入力に対して出力が不適切という「仕様」そのものまで、あらゆる粒度の不適切さが「同意された仕様からはずれた障害」として識別されます。 実は同意された仕様そのものが、よく変わるものということも事実です。要求変更は、当初予定されていたコスト／スケジュール／体制までも変えうる可能性があります。故に、これを管理するということが大変重要です（とはいうものの、要求定義と要求管理の違いがわからないプロジェクトが多いのも事実です）。 さらにもう1つ、昔からいわれ続けて、なお今になっても再評価されている品質とは、「そもそも仕様が適切なのか？」「システム自身の説明責任が果たせるか？」ということです。同意した仕様自体が変わるという現実が多くのプロジェクトを悩ませています。ですが、仕様通りにできれば問題は解決するのでしょうか。冒頭のことから明らかなのは、ITシステムとビジネスとの連携の度合いは深まる一方だということです。 SOA（Service Oriented Architecture）では、ビジネスプロセスを分解するトップダウンアプローチで、ITシステムのサービスを定義します。では、どの辺りをどのくらいの粒度でサービスとして構築すれば、効果が期待できるのでしょうか。今、問題を解決するために構築されたシステムが、その問題をきちんと解決するという品質が問われつつあるといえるでしょう。  図1：SOAの概念 |
||||||||||||
| SOA時代をにらんで変わるベストプラクティス | ||||||||||||
|
IBM Rationalでは、過去の経験則からより高品質のシステムを実現するための「ソフトウェア開発のベストプラクティス」を提唱しています。そのプラクティスも、ITシステムのビジネス上での位置づけの変更を受けて改訂されることになりました。いわば「SOA時代のベストプラクティス」といえます。 詳細を説明する前に、「SOA時代のソフトウェア開発は何が変わるのでしょうか。また、その中で品質向上のポイントや取り組みはどう変わるべきなのでしょうか」ということについて考えてみましょう。 |
||||||||||||
| 様々なタイプのプロジェクト形態が、企業（グループ）内で混在する | ||||||||||||
|
SOAに限った話ではありませんが、開発プロジェクトの形態が多岐にわたり、かつ普遍化されています。
表3：開発プロジェクトの形態
これまでのシステムの構造は、俗に「マスター」と称されるデータベースを土台に、個々のシステムが独立して構築される"ストーブパイプ"型が中心でした。SOAでは、これらのシステム自体が外部にサービスを公開する「協調型」になります。これまで以上に、連携方法を含めたプロジェクト間の情報の共有が重要になってきます。  図2：既存の開発スタイルからSOA型へ |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
