NTTグループのソリューションガイド

ICTソリューション総合誌 月刊ビジネスコミュニケーション

ビジネスコミュニケーション
第98回 アーキテクチャと要求国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授 山本修一郎

国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授
(前NTTデータ フェロー システム科学研究所長)山本 修一郎

本稿では、アーキテクチャに影響を与える要求について紹介する。要求に対するアーキテクチャの妥当性を議論することは、アーキテクチャに影響を与える要求と、影響しない要求を区別することでもある。また、要求に基づいてアーキテクチャを評価する手法についても解説する。

アーキテクチャ有意要求の必要性

システム開発が失敗する理由の最初の2つが、要求とアーキテクチャの欠陥である。アーキテクチャに影響する非機能要求のことをアーキテクチャ有意要求(Architecturally Significant Requirements, ASR)という。ASRを正しく定義するのは困難である。この理由は、機能要求はアーキテクチャの要素としてのコンポーネントに割り当てることが容易にできるのに対して、システム全体の振舞いに影響を与えるASRは、特定のコンポーネントに対応しないためである。大規模システム開発では、アーキテクチャが決まらないと、プロジェクトの組織体制を決めることができない。したがって下流工程の設計、実装、統合、テスト、展開にも影響する。

典型的なアーキテクチャ有意要求には以下の要素が含まれる。

(1)指定された品質特性を満足すべき程度としての品質要求

(2)アーキテクチャ制約

(3)アーキテクチャが実現する機能要求

このようなアーキテクチャ有意要求の必要性を、品質モデルの観点から見れば、次のように考えることができる。

システム品質は、システムアーキテクチャ品質によって決定される。

システムアーキテクチャ品質は、アーキテクチャ有意要求によって決定される。

したがって、アーキテクチャがシステムにとって必要であると同時に、アーキテクチャ有意要求も必要になる。換言すれば、ASRとそれに基づくアーキテクチャ判断が、システム全体の品質、開発計画、開発維持経費、保守性、拡張性、受容性、使用性に影響することになる。したがって、ASRとアーキテクチャの妥当性とともに、それらのリスクを分析することが重要になる。要求リスクとアーキテクチャリスクを分析するためには、要求とアーキテクチャを可視化することが重要になる。これによって、発注者の要求に対する、要求とアーキテクチャの準拠性ならびに、アーキテクチャに対するシステムとコンポーネント要求の準拠性を確認することができる。

品質とは

【定義】

必要とされる特性に対して、開発生産物が示す程度のことを品質という。

したがって、品質を測定するためには品質特性を定義するとともに、測定尺度を定義する必要がある。このため、次のような品質モデルが必要になる。

◆品質モデル

開発生産物の品質は、品質特性(Quality Characteristics)、品質属性(Quality Attributes)、品質計測単位(Quality Measurement Scales)からなる品質モデルで定義される。品質モデルの構成要素の例を表1に示す。

品質特性には、開発時に測定される開発指向の品質特性と、システム運用時に測定される運用指向の品質特性がある。開発指向品質特性の代表的な例は、バグ数に基づくソフトウェア品質である。運用指向品質特性には、ディペンダビリティ、効率性、相互接続性、持続可能性、使用性、性能、容量、構成可能性などがある。ディペンダビリティは、健全性と防御性(defensibility)がある。防御性は、耐故障性、安全性、セキュリティ、回復性がある。健全性には、可用性、正当性、予測可能性、信頼性などがある。なお、このような品質特性の階層分類の仕方には多様なものがあるので、ここで示したのはQUASAR[1]に基づく分類例である。

表1 品質モデルの構成要素例

表1 品質モデルの構成要素例

◆品質要求の記述例

【記述形式】

条件Xの下で、システムが指定された品質基準Yに対する閾値Zに一致するか越えている。

この記述形式に従うと、「システムは高信頼で、耐故障性があり、安全でセキュアである必要がある」というような品質要求の記述は、定量的ではないので、よくないことが分かる。

これに対して、以下のような記述はよい品質要求の例である。

「通常運用条件の下で、基幹系機能に対して、システムの平均故障時間間隔が少なくとも5000時間である必要がある。」

品質ケース

開発生産物が十分な品質を持つことを示すために、主張(Claim)、議論(Argument)、証拠(Evidence)を用いた一貫性のある説明を品質ケース(Quality Case)という。

ここで「ケース」というのは、もともと、法廷用語で、有罪か無罪かを立証するために法廷での弁論のやり取りをToulmin[2]が定式化した論証手法に由来する。システム安全性やディペンダビリティを確認するための手法として、安全性ケース、ディペンダビリティケース、アシュアランスケースなどが考案されている。安全性ケースやディペンダビリティケースは、それぞれ、安全性やディペンダビリティについてのアシュアランスケースである。アシュアランスケースは保証ケースともいう。

Firesmithは、品質ケースによって品質の評価とシステムが要求品質を持つことの認証を容易化できるとしている。この意味では、アシュアランスケースを適用して品質ケースが開発されているのだから、アシュアランスケースを用いてアーキテクチャ要求品質を保証できるともいえる。

◆Toulmin構造

これらの基礎になったToulimin構造を図1の例で説明しておく。まず、「あること」が成立するというためには、それを「主張」として記述する必要がある。その上で、主張の根拠となる事実を「データ」として提示する必要がある。さらに、主張をデータが立証するというためには、この因果関係が妥当であることを「保証」する必要がある。このような保証に対する根拠としてのデータや証拠となる事実を「支援」という。

図1 Toulminの論証構造

図1 Toulminの論証構造

続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。

第59回以前は要求工学目次をご覧下さい。


会社概要 NTT ソリューション 広告募集 ページ先頭へ
Copyright:(C) 2000-2017 BUSINESS COMMUNICATION All Rights Reserved. ※本サイトの掲載記事、コンテンツ等の無断転載を禁じます。