システムエンジニアのためのモデリング心得 トップ10

その2 欠陥は直すより避けたい

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: システムエンジニアのためのモデリング心得 トップ10

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:システムエンジニアのためのモデリング心得 トップ10

このシリーズの続きに乞うご期待。

伝統的なウォーターフォール型、もしくは、Vサイクル型の開発プロジェクトは、段階を踏みながら一連の活動を進めていきます。それは、それぞれの段階を完了したときには、せいぜい2、3程度のマイナーな欠陥しか残っていないという基本的な前提に基づいています。少なくとも、理論的にはそう考えます。

図1.典型的なVサイクル・プロセス
典型的なVサイクル・プロセス
典型的なVサイクル・プロセス

しかし、いろいろなプロジェクトの証拠に基づけば、単純にこれは真実でないとわかります。万が一真実だとすれば、システム検証・妥当性(V&V)テストは、全くの最初から、そしてほとんどの場合に合格してしまうでしょう。欠陥を取り除く作業は、たまたま必要な場合もあるという程度となるでしょう。そして、作業やコストが深刻な超過になることもほとんどないでしょう。しかし、そうであるとは考えられず、3分の1のプロジェクトはコスト超過、時間超過に陥っています。かなりの数のプロジェクトが予算超過により完了前にキャンセルされています。

「最後に検証する」というやり方は、問題の欠陥をプロジェクトの最後の時点で特定することになります。プロジェクトの最後の時点というのは、プロジェクトを完了することを期待されている時点です。2つの理由によりそのコストは高くなります。1つは、完全に構築済みのシステムにおいて欠陥を特定して分離しなければならないということです。しかし、その理由の大部分と言えるのは、作業成果物(要求、アーキテクチャ、設計、プログラムコード、テストケース、その他)のかなりの部分を無駄にすることによる大きなコストです。このやり直しのコストこそが、プロジェクトに致命的な打撃を与える真犯人なわけです。

私は、欠陥を早い時期に入れてしまって後になって直すよりも、一番初めの時点で「避ける」ほうがよいと信じています。避けるにはどうすればよいのかというのが本当の問題です。そのためのプラクティス(実践法)が沢山あります。

  • 高忠実モデリングを使うテスト駆動開発(TDD-HFM)
  • 継続的統合
  • インクリメンタルな検証と妥当性確認(V&V)
  • 継続的な品質保証(QA)
  • 継続的なディペンダビリティ・アセスメント

ここでは、この中でTDD-HFMを特に見てみることにします。上記のものは全て重要であり、システム設計に欠陥が埋め込まれてしまう前に取り除くのに役立ちます。しかし、私はTDD-HFMには特別な価値があると思っています。テスト駆動開発は、アジャイルソフトウェア開発の文脈において欠陥を回避する手段として開発されました。この考え方によれば、テストケースは、ソースコードを開発するのと同時に開発され適用されます。このことは(Harmonyプロセスではナノサイクルと呼ぶ)20分から60分のとても小さなサイクルの中で起こります。目標とすべきは、この短い時間の中で自分がこれまでに作成したものが実際に正しいことを必ず一度は検証することです。つまり、検証をプロセスの最後のところから移動させて、数時間で行っている普段の作業の流れの一部分にしてしまうのです。

テストを最後にだけ行うというのは、「さて今年も時期が来たか」と言って大晦日にたった一回歯を磨く程度の意味しかありません。我々は、いつも(少なくとも日に一度)衛生管理することで歯に問題が起こらないようにします。TDDは、システムエンジニアリングにおける作業成果物の衛生管理をするということ、それ以上でもそれ以下でもありません。衛生管理は、Merriam Websterによれば「特に清潔で衛生的であることにより健康維持や病気予防につながるもの」と定義されています。私は、この定義はエンジニアリング作業成果物の開発にとって特に適切なものだと思っています。我々は、システムエンジニアとして、作業成果物を検証と結びつけた形で作成しなければなりません。秘訣その7(「要求モデルによって高くつく欠陥を早期に回避し易くなる」)のところでも、このことについては既に少しお話しました。これは、ほとんどのシステムエンジニアリング作業成果物に応用できます。要求を良いもの(完全で、一貫していて、的確で、正確)にしたければ、「検証可能」な要求モデルを作成しましょう。良い(そして最適な)アーキテクチャを構築したければ、検証可能なアーキテクチャ・モデルを作りましょう。

これは解答の大きな部分ではあるのですが、それだけでは不十分です。「検証可能」というだけでは十分ではないのです。完全に検証されているということが必須です。検証されている作業成果物を構築する最善の方法は、開発される中で継続的に検証するということです。このテスト駆動開発のアプローチは、さもなければ開発チームやテストチーム、最悪の場合は顧客への驚きと共に顕在化してしまうような欠陥の大部分を取り除くことができます。

ここで、欠陥のない要求を構築するという問題を考えてみましょう。図2のワークフローは、どうやってこれを進めるかを示しています。このワークフローを効果的に実行するための鍵となるのは、これらのサイクルを短く、そして焦点を絞ったものすることです。通常は、1つのサイクルは20分から1時間程度になります。図の内側の要求モデリングのループでは、それは以下のユースケースに沿って少数ずつ要求が生成されることを意味します。

  • 実行コンテキストを更新する
  • そのシナリオと機能フローの中でその要求を明確にする
  • 状態マシンをインクリメンタルに更新する
  • その更新を検証する

もし顧客に聞くべき質問があったり、顧客にデモをしたい機能があったりすれば、そのモデルを(シミュレーションとして)評価や検討のためにいつでも顧客の前に差し出すことができます。

図2.要求分析のためのテスト指向開発-高忠実度モデリング・ワークフロー
要求分析のためのテスト指向開発-高忠実度モデリング・ワークフロー
要求分析のためのテスト指向開発-高忠実度モデリング・ワークフロー

さて、次はいよいよシステム開発のための心得その1です。

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。この記事の著者のBruce Douglassを含む、ラショナル・グローバル・チームのメンバーと共に、ラショナル・ソリューションの普及とお客様へ提供する価値の向上に日々取り組んでいます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=960236
ArticleTitle=システムエンジニアのためのモデリング心得 トップ10: その2 欠陥は直すより避けたい
publish-date=01182014