HOME | products | LDRA | TBreq_RTM

Cut the cost of code development with traceability tools

Shan Bhattacharya, LDRA Ltd.  12/7/2011 2:19 PM EST

要件トレーサビリティで開発費用を削減

 
要件駆動型開発のスローガン、およびそれに関連する全ては、より良いアプリケーションのより高い信頼性を求めて20年近くにわたって考察されてきた。そして要件駆動型開発の実現を理想とするソフトウェアプロセス、認証機関、業界標準の潜在的なモチベーションとなっている。 
 
ただこれら取り組みにもかかわらず、組込みソフトウエアの欠陥の大半は、依然として要件に関係している。この問題の主要な原因の一つは、製品のスコープ変更に起因する要件の継続的な変更である。このような絶え間ない変更によってさらされるリスクから身を守るには、組織は、要件への変更と、結果として生じる製品ライフサイクルの実装段階を管理することを学ぶ必要がある。
 
優れた要求管理の実践には、システムレベルからよく考え抜かれて分類、分割された要件が求められる。このような分割が上手く管理され、その成果物が構成管理され、様々なエンジニアリング上の規範が上手く伴うなら、開発ライフサイクルの全段階で、絶え間ない要件の変更に対処できる。 
 
開発チームによっては要件トレーサビリティマトリックス(RTM)を製品リリース時に作成するけれど、もし開発プロセスの中心的駆動力としてRTMを実践すれば、多くのエラーを回避できる。本資料では開発における避けようのない課題である、RTMを作成し開発プロジェクトのプロセスを通じて維持する方法を紹介する。
 

The need for traceability tools

 
大規模プロジェクトでは、数百万行のコードに複数のサブシステムとインタフェースが含まれる。そして一般にこのようなプログラムは、複数階層からなる顧客による大規模な仕様のもと、複数の組織で開発される。
 
通常これらのプロジェクトは、システムに想定される振る舞いと、その他の要件を説明する、運用コンセプトとシステムレベルのドキュメントから開始される。そしてシステムレベルの要件はサブシステムに分割され、ソフトウエアなどに変換されると、それらは各専門担当者(SME:subject matter experts)によって検証され、承諾される。このような業務は、通常は、IBM Rational DOORSなどの要件管理ツールや、IBM Rational SynergyとClearCaseのような変更管理ツールや構成管理ツールによって管理される。 
 
要件が検証されプロジェクトが詳細設計フェーズに入ると、成果物の数は急速に増加する。この時点で変更があると、無数の未解決の問題を導入することになる。この複雑なレベルのRTMの実践には、優れたトレーサビリティ•ツールを必要とする。
 
要件トレーサビリティは、要件・実装・検証など成果物間で、プロジェクトのライフサイクルを通じてバイディレクショナル(双方向)に追跡すること。バイディレクショナルな要件トレーサビリティにより、コードから要件に戻って追跡し、テストや検証作業に進むことができる。要件は設計で実現され、コードとして実装され、テストされるので、その正しい実装を確保するために、各段階の成果物間がリンクされる必要がある。成果物は、テキスト、グラフィカルなモデル、コード、様々な形式のテストデータ など色々なフォーマットで存在する。効果的な変更管理には、異なる開発フェーズから関連するコンポーネントを識別して、データの照会が単一の環境から行える必要がある。この作業を手動で実行することは困難で多くの工数を伴う。そこでトレーサビリティ•ツールは、より効率的なやり方を提供する。 
 
トレーサビリティ•ツールは、様々な成果物を伴う異なった媒体の橋渡しとして、開発活動の全範囲にわたって、要件に対して成果物をリンクする。また効果的なトレーサビリティ•ツールは上流と下流へのインパクト解析のレポートや、変更の影響をより良く理解するためにトレーサビリティ情報を活用できるマトリクスを生成する。
 

Managing an RTM

 
一つのトレーサビリティ•マトリックスは、互いに連携する成果物間にのみ構築される。 そしてRTMに紐付される成果物とその活動は、構成管理される必要がある。様々なタイプの要件があり、例えばシステムのモードや各状態の要件は、電力管理やセキュリティシステムの要件と組み合わされ、ソフトウエアに実装される。そして、これらの取り組みに関与する成果物は、PowerPointのスライドや技術面等の特定課題の詳細から、状態遷移図やコードのリポジトリにまで及ぶ。これらすべての成果物は、個々に継続的に変更されている。しかしそのスナップショットはバージョン管理され、任意の時点で存在するシステムの全体像を提示しなければならない。バージョン管理は、RTMを駆動するコンテンツを管理する包括的な変更管理ワークフローの重要な役割を果たす。
 
開発組織はソフトウエアをベースにした製品を、ソフトウエアとその要件、デザイン、検証成果物と、RTM とを合わせて出荷する。そして多くの場合、成果物間のRTM を後回しにして、出荷直前になって慌てることになる。そして潜在的な欠陥となりうる不整合がトレーサビリティ作業の最後の段階で明らかになってしまう。この時点になっての、このような不整合の修正は多くの費用を要し、想定外の遅延と予算超過を招くことになる。
 
しかしながらRTM が開発全サイクルを通じて管理されていれば、出荷のプロセスの苦痛はずいぶんと和らぐことになる。トレーサビリティの課題は、ライフサイクルを通じた運用で功を奏し、結果各成果物は出荷前に十分に検査される。
 

Benefits of traceability

 
良きトレーサビリティの成果を十分に享受するには、開発後工程になって引き起こされる複雑さへの理解が必要となる。要件が確認され詳細設計フェーズに入ると多数の成果物が一気に増殖する。実装と検証のフェーズではコードとテストデータがRTMに加わってくる。多くのエンジニアが総動員されて、製品の複雑さの全容が姿を現し、プロジェクトの非効率とリスクによって開発コストが跳ね上がる。そして欠陥が見つかるたびに深刻なスケジュールの遅延。予算変更、スコープの変更、さらに妥当な改新でさえシステムの変更をあおってしまう。その一方でRTMの完全な状態を維持するには、設計成果物からコード、様々な形式のテストケース、テスト結果などへのトレーサビリティがメンテナンスされる必要がある。
 
このような様々な要因は克服できないかに思えるが、トレーサビリティツールによってプロセスをコントロールできる。トレーサビリティの規範を、専用ツールによって開発プロセスを通じて維持することで、開発プロセスを分断・崩壊させる欠陥を飛躍的に軽減できる。以下に紹介するシナリオではトレーサビリティに関わる解析が行われ、上流にある要件との課題に折り合いをつけ、新しく追加される機能を見積もること、プロジェクトの進捗がより良く観察できるようになる。
 
最初のシナリオは、ソフトウエア要求仕様(software requirements specification (SRS))に振る舞いを実装する担当者が、要件定義内の不一致、あるいはエラーを発見する場合。もしトレーサビリティがメンテナンスされていたならば、担当者は欠陥が上流のシステムレベルの要件へ与えるインパクトの解析を行うことができる。(図1) そして関連する要件や設計成果物の担当者達とコミュニケーションを図ることで、問題をより良く把握・記述して、解決にあたることができる。
 
もしこのような上流へのトレーサビリティが取れないと、担当者は技術的な解を得たとしても要件や設計の修正に至る内容を上流に上手く伝達できない。このような制限があると、開発後半の検証作業までシステムの欠陥が見過ごされてしまうという事態に陥ることになる。
 


 
図1:SRS_0001の上流の要件へのインパクトを視覚化。ソフトウエア要求仕様(software requirements specification (SRS))の上流階層である、主要要求仕様(the Prime Item Development Specification (PIDS))とインターフェイス仕様(the Interface Control Document (ICD))がハイライト表示されている様子
 
システムのスコープに対する要件の変更がプロジェクトとそのRTMに設定されると、その要件変更によるコスト、開発スタッフのやりくり、その他必要になる手配へのインパクトを直ちに検討しなければならない。要件の変更は、追加、修正、削除される要件などスコープの変更に関与する(図2)。より良くメンテナンスされているRTMと下流へのインパクト解析により、ソフトウエアへのインパクトを直ちに評価できる。
 

 
図2:要件列(左側)にあるシステムレベル要件(system-level requirements (PROJ_SYS_0012))が、下流(真ん中)のDownstream列ではソフトウエア要件(PROJ_SRS_0022 と PROJ_SRS_0032)に分解され、右側のMapped Files列で関連するソースファイルとプロトタイプがソフトウエア要件にマップ(紐付)されている様子を確認できる。そしてPROJ_SYS_0012への変更・修正がインパクトを与えるファイルやプロトタイプを確認できる。
 
要件トレーサビリティツールで、管理チームは変更により影響を受けるコード数を把握して実装費用を直ちに見積もることができる。コード変更の影響を受けるソース行、関連する設計、検証コストなどをファクターにして。プロジェクトのリーダーは正確なコストを査定して、十分な証拠をもって、顧客と交渉にあたることができる。開発人員の予測、追加の機能、その他の要因を含めてプロジェクトの計画はより正確に計画され、決断を下すことができる。
 

Managing change through traceability

 
このような粒度で解析ができなければ、各専門担当者(SME)からの見積もりの収集に頼ることになり多大なエラーの要因となってしまいがち。 たとえそれら各見積もりがある程度正確であっても、見積もりをバックアップする具体的な証拠は無く、また交渉時において十分に準備されることは無いであろう。 システムのスコープに対する要件の変更 によって引き起こされる絶え間ない変更の管理は、納期通りに完成させて出荷するうえで欠かせない重要事項。下流へのインパクト解析を伴ったトレーサビリティの更新によって、管理者は混沌としてリスクの多い取り組みから、不確定な要素を排除できる。
 
そして検証活動はプロジェクト実施中に開始されるので、進捗のモニタは修正作業を適正に実施するうえで欠かせない。 どのトレーサビリティ活動が完了していないか、プロジェクトを納期通りに完成するために必要な検証活動のどれがパスしていて、どれがこけているかを把握すること。トレーサビリティツールは明確な証拠を提供できる。どの要件がマップされていないか?どの要件に検証作業が割り当てられているか?(図3)
 


 
図3:様々な段階のトレーサビリティと検証活動を視覚化して表示できる。要件とソースコードのマップ、検証活動の割り当てなど。
 
そのようなツールなら管理者は検証の進捗をモニタしてスケジュールに対する状況を判断できる。納期通りの完成が危ういなら、それは早期に発見されて対処され、結果としてスタッフの増員も正確に行える。このような可視化によって、プロジェクトのずさんな進捗管理は排除され、また開発チームメンバーごとのタスク完了によりRTMがアップデートされるので彼らのモチベーションにもなる。
 
このようなデータなしでは、管理者チームは毎週のように進捗情報を聞きに回る(あちこちの部署間で)ことになってしまいがち。そして得られるデータは個々の主観的な判断。そして場当たり的なデータの寄せ集めは、本質的に怪しげな進捗レポートとなってしまう。
 
上質なRTMが整って、全てのスコープでトレーサビリティの情報が入手できることで、あらゆるレベルの管理者、顧客、開発担当者は、いつでもプロジェクトの明確な情報を得ることができるようになる。トレーサビリティとそれによる可視化が備われば、開発ゴールへの道筋が全チームメンバーに明らかにできる。混乱は最小限に抑えられ、技術的な解決策はより効果の高いものになる。この開発・管理形態は基準としてふさわしく、この取り組みが今後普及し、プロジェクトや開発組織にとっての常識的な作法となることを願う。
 

Tools and the future

 
要件管理とトレーサビリティをベースにしたシステム開発の効果は、ソフトウエア業界でもいよいよ明らかになってきた。これに対するソリューションの多くはトレーサビリティの課題の一部にのみ向けられ、デザイン、実装、検証への考慮が足りない。これらの段階の成果物はプロジェクト後半になってやっと結集され、製品開発完了を直前にして要件に連携される。結果、RTMは、開発プロセスの駆動に精力的に活用されない。
 
プロジェクトの複雑さは増す一方であり、また開発プロセスや業界スタンダードでのトレーサビリティと透明性への要求は高まる一方であり、開発組織は開発のより早期段階からのトレーサビリティの自動化支援ができるツールのエコシステムとプロセスを確立しなければならない。とりわけ検証作業が開発全体の大部分を占める、安全・安心、ミッションクリティカルなシステムでは重要。
 
この課題がより良く理解されてきたことで、ツールを提供するベンダは開発プロセスの後期になってトレーサビリティを支援するソリューションの提供を始めている。それらの中でALM(アプリケーションライフサイクルマネジメント)などのツールは、RTMの細部も統合した開発プロセスを導入する。このような次世代型のツールは徹底したソリューションを提供し、ミッション、セーフティクリティカルなシステムのソフトウエア開発者の切実な問題を解決することになるであろう。
 
ソフトウエアの複雑さがますます増加するなか、このような解決策を得て要件駆動で取り組むことで、高い信頼性の製品を予算や納期の超過なく提供できるようになる。
 

About the author

 
Shan Bhattacharya is a field application engineer for LDRA Ltd. He graduated from Cameron University and began his career in factory automation and robotics. He continued with various defense contractors including Lockheed Martin, where he served as a lead engineer and finished his time as a deputy IPT lead. Shan has been with LDRA since 2007 and provides consultation for clients in various industries focusing on requirements management, software certifications, and development best practices.