システムエンジニアのためのモデリング心得 トップ10: その1 品質を保証する唯一の効果的な方法は継続的検証である

Bruce Douglassが継続的検証の重要性を説明します。これは欠陥を避けるだけでなく、品質を向上させプロジェクトにおけるやり直しを大幅に削減するのに役立ちます。

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月 24日

私は、次に上げるような条件を満たしているとき、またそのときに限り、要求が「良好な状態」にあると考えます。

要求の集合が、内部的な設計判断については規定することなく、システムの全ての条件、環境、そして操作的な利用状況に対して、入力→出力の間の制御およびデータの変換対応を適切に表現している。

システムエンジニアは、下流のエンジニアリング活動に仕様を引渡します。下流のエンジニアリングは、要求の実現を適切に設計し実装していきます。もし要求がその引渡しの前にこの「良好さ」の条件を満たしていれば、(秘訣その2で述べたように)欠陥を後で直すより避けることが可能になります。

どうやって良好さの条件を満たせばよいか

心得その2で説明した衛生的な設計が、良好さの条件を満たす鍵になります。病気(欠陥)を避けるための原則、実践論、ツール、方法論を使うことが必須です。いろいろな証拠が示すように、唯一最良の方法は、衛生管理(すなわち検証)の技法を、作業成果物を作成している間ずっと継続的に、または、少なくともそれに近い形で適用することです。

これを理解するには、検証を明確に定義する必要があります。検証に関して構文的と意味的という2つの基本的なカテゴリーがあります。構文的検証とは、作業成果物が整形式(well-formed)であり、形式として適切であることを検証します。例えば、あるプロジェクトでは要求に関して以下のような標準を決めているかもしれません。

  • 全ての要求は一意に番号付けされる。
  • それぞれの機能要求は「することになる(shall)」という言葉を用いて記述の規範的な部分を示す。
  • 全ての機能要求は少なくとも1つのサービス品質要求で修飾される
  • その他

これは、「適正なものとは」について語るような要求とは異なります。それは単になされた記述が形式の適正さのルールに沿っていることを意味するのみです。構文的な適正さの検証は、通常品質保証チームが行い、人手によるか、または自動的に実施されます。

「意味的」検証は、記述がその内容において適正で、一貫性があり、正確であることを検証します。意味的な適正さを保証することが、このあまり限定されていない「検証」という言葉がより普通に意味するところでしょう。特定領域の専門家、数学者、あるいは検証者は、この意味的適正さを相手にします。

システムの作業成果物の意味的検証の方法としては、以下の3つがあります。

  • レビュー
  • 形式的(数学的)分析
  • テスト実行

意味的レビュー

意味的レビューは、意味的検証の中では最も非力です。作業成果物は、欠陥や内部・外部両方での矛盾を探す、1人もしくは何人かの同僚もしくは領域専門家によりレビューされます。人の認知能力は、狭い範囲での分析では見事に効果的ですが、作業成果物が広範囲か複雑、あるいはその両方といった場合には鈍ってきます。そうなると、知的活動の話が注意力の話に変わってしまいます。複雑なシステムの細かく入り組んだ詳細を、何十何百時間と検査する間中注意力を維持するのは困難なことです。レビューのもうひとつの問題はコストです。1つの作業成果物をレビューするのに何人もの人を部屋の中に拘束するということは、レビュー時間がエンジニアリングにおける大きなオーバーヘッドになっていることを意味します。1ダースかもっと多くの人が1回のレビューに巻き込まれるというのも珍しいことではありません。ということは、他の検証方法にかかるであろう時間の12倍ものコストをかけることになります。

最もうまくやれた場合でも、意味的レビューは他の検証方法よりも非力です。このやり方は、補助的な価値を添えるものと考えたほうがよいです。私から見て、多くの企業で見られる問題は、このやり方がシステムエンジニアリングのほとんどの作業成果物に適用される唯一の検証の手段であるということです。


形式的分析

形式的分析は、個人的な意見を排除し、安全性、信頼性、頑強性といったシステムの側面からの厳密な分析を同時に提供できるという利点があります。形式的手法は、とあるシステムの全ての状態が有限時間で到達可能であることを形式的定理証明により決定する(例えば、「あるエレベーターはリクエストに対して1分以内に到着する」)といったことから、様々なレベルで適用することができます。形式的手法の強みの一つは、実行経路とは関係なく条件を検証できることです。それは、あり得る全ての状況における帰結を、それがテスト実行では原理的に不可能なものであっても検証できます。形式的手法の適用の主な困難さは、正にこの手法の価値である数学的厳密さの程度がほとんどのエンジニアには使いこなせないようなレベルのものであることです。さらに、他の全ての分析と同様、結果に対しては単に公理的前提条件やクラスの不変量(仮定)の下での妥当性が言えるだけです。もしあなたの周りに形式的手法の博士号を持ったスタッフがいなければ、もう少し軽い形式的手法で折り合いをつけることになるでしょう。

それらを踏まえ、形式的手法の応用をサポートする自動化ツールを挙げてみましょう。例えば、IBM Rational RhapsodyのAutomatic Test Generator (ATG)ツールは、ある状態マシンの全ての可能な状態へ到達するための、もしくはある状態には到達しないことを特定できるようなテストベクタを生成することができます。

形式的手法が意味的検証の大半を扱えるものと期待するのは現実的ではありません。レビューのときと同様、他の検証手段の有用な補足といえるでしょう。


テスト実行

テスト実行は、仕様、設計、実装、そして結果としてのシステムなどの作業成果物の意味的検証としては最も現実的なものです。テスト実行は、一連のテストケースを定義することによって行います。それぞれのテストケースは、一連のイベントと特定のデータ値から構成されます。それらのイベントは特定の順序とタイミングで起こり、「正解としての」結果を伴います。

テストを多くすればカバレッジが上がりますが、有限個のテスト集合で全ての可能性をカバーすることはできません。

テスト実行の原理的な問題は、それがテストケースのもつ特定の経路とデータのみを検証するということです。他のイベント系列や他のデータ値は検証されません。インテリジェントなシステムというのは、本質的に無限のデータ値と本質的に無限の状態をとるので、システムをテスト実行で網羅的に検証することはできません。

ソフトウェアのテストカバレッジの最小限のレベルに関してたくさんの基準が提唱されています。その幾つかは、以下のようなものです。

構造カバレッジ
コードの全ての行がテスト集合で試されている
 
分岐カバレッジ
全ての条件判定分岐が真偽両方の組合せ条件においてカバーされている
 
Modified condition/decision coverage (MCDC)
全ての判定点において全てのブール句がそれぞれ独立に真偽の値を取らなければならないことを仮定する
 
データの等価集合によるカバレッジ(Data equivalency set coverage)
データは、その集合の中ではどの値をとってもシステムの振舞いにおいては質的に同等となるような等価なグループに分類され、テスト集合は全ての等価集合からのデータを含んでいる
 

意味的検証のためのベストな方法は、この3つ全ての組合せです。主にはテスト実行に頼れますが、レビューや形式的手法によってテスト実行を補強すべきです。


継続的検証

この記事で提案した衛生的アプローチは、検証技法を作業成果物が開発されるにつれ継続的に適用するというものでした。図1は、要求モデルの開発を表しています。図1では、検証を行う時点がわかるかと思います。その内側のループ(ユースケースのシステムコンテキストの定義 [Define the Use Case System Context] から機能要求の検証と妥当性確認 [Verify and Validate the Functional Requirements ]そして戻る)がナノサイクルであり、20分から60分ごとに回っていることに注意してください。そこでは、小さな幾つかの要求を対象に、それをモデル中で実現し、実行検証して、それを繰り返しています。これは、ユースケースに結び付けられている全ての要求がモデルの中に表現され検証されるまで続きます。

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

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

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

modeling diagram

この要求分析のナノサイクルを実行する中で、テスト検証をこの非常に短いループの最後のステップ(機能要求の検証と妥当性確認 [Verify and Validate the Functional Requirements])として適用します。そこでは、ユースケースモデルの中に表現される状態空間をカバーしていることを保証するためのテストケースを、形式手法を使って作成することもあるでしょう。更に、システムの不変量に関する定理を定義し、数学的解析を適用してその定理を検証するかもしれません。また、これらのサイクルの中でときどき、要求の理解と表現がカスタマーの要望と合致したシステムへとつながっていることを保証するために、作成された、もしくは変更された要求に沿って(要求の更新と保守 [Update and Maintain Requirements] タスク)、モデル実行のデモをカスタマーに対して行いモデルの妥当性確認を行います。ユースケースを定義するこの(比較的小さな)作業の最後には、レビューのステップ(レビュー遂行[Perform Review] タスク)があり、そこでは安定化され検証されたユースケースの仕様と文章で記述された要求が、意味的そして構文的レビュープロセスを使って検証されます。

これらの検証方法が開発活動の適切な場所で適用されるので、厳密な検査の中でのみ明らかにできるような欠陥を、その大部分において回避することができるようになります。これにより、品質を向上させ、検証をプロセスの最後のほうで行うようなシステムエンジニアリング環境では良く起こるやり直しを大幅に減少させることができます。


まとめ

さあ、これで 私のモデルベースシステムエンジニアリングのための心得トップ10がそろいました。もちろん、これがシステムエンジニアリングを遂行する上での網羅的なリストになっているわけではありません。ではありますが、いくらかは役に立つものと願っています。業界として活用していきましょう。

訳者について

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

参考文献

学ぶために

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

  • こちらのオンラインツアー Rational Rhapsody with an online trial (US) もしくは30日間無料のRational Rhapsody の試用版をダウンロードしてください。 Evaluate (US)
  • Evaluate IBM software (US) から目的に応じて試用ダウンロード、オンラインでの試行、クラウド環境での利用をお試しください。

議論するために

コメント

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=960659
ArticleTitle=システムエンジニアのためのモデリング心得 トップ10: その1 品質を保証する唯一の効果的な方法は継続的検証である
publish-date=01242014