システムエンジニアのためのモデリング心得 トップ10: その2 欠陥は直すより避けたい

Bruce Douglassによるシステムエンジニアのためのモデリング心得トップ10シリーズの今回の話題では、なぜ欠陥を直すよりそれを避けるべきなのかについて彼が考えを語ります。

Bruce Douglass (Bruce.Douglass@us.ibm.com), Rationalチーフ・エバンジェリスト, システムズ・エンジニアリング, IBM

author photo組込みソフトウェア方法論者。トライアスリート。システムズエンジニア。UMLおよびSysML仕様開発コントリビューター。作家。黒帯。神経科学者。クラッシックギター奏者。高校中退。Bruce Powel DouglassはUSD(サウスダコタ大学)医学部より神経サイバネティックスの博士号を取得し、35年以上にわたる様々なハードリアルタイム環境のセーフティ・クリティカルなリアルタイム・アプリケーションの開発の経験を持っています。彼は5,700ページにおよぶ多くの技術書籍の著者で、Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, Design Patterns for Embedded Systems in Cといった本を書いています。彼は、IBM Rationalのチーフ・エバンジェリストであり、システムズ領域のソート・リーダーでもあります。BruceはIBMの全世界の顧客に対してコンサルテーションや助言を提供しています。Bruceをツイッターでフォローするには@BruceDouglassです。



2014年 1月 18日

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

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

クリックして大きなイメージを見る

図1.典型的な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.要求分析のためのテスト指向開発-高忠実度モデリング・ワークフロー
要求分析のためのテスト指向開発-高忠実度モデリング・ワークフロー

クリックして大きなイメージを見る

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

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

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

訳者について

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

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


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