概要
今回は試験と要求の関係について考えてみよう。
米国のJet Propulsion研究所では、Safety Critical ソフトウェアに関する試験結果に基づいて要求を発見する方法を提案している[1]。この論文が興味深いのは、普通は試験といえば、要求されたことが正しいことを確認することだとしか考えないのに、試験で摘出されたことには、それ以上の意味があることを指摘していることだ。どういうことかと言えば、私も経験があるが試験では、試験で発見された欠陥が実はすべてソフトウェアの誤りではないということだ。ソフトウェアの誤りではない試験結果についてどう考えるかということである。以下では、この問題について前述の論文に基づいて説明しよう。
要求と試験の関係
要求と試験の関係を図1に示した。試験結果には2つの場合がある。
図1 要求と試験
(1)要求どおりの結果になった。つまり、要求が正しく実装されていることを確認した。
(2)要求どおりの結果にならなかった。つまり、要求が正しく実装されていないことを確認した。
ところで、試験結果が正しいかどうかを誰が確認するのだろうか?普通は試験担当が誤りかどうかをまず判断するわけだ。ここで解釈の取り違えが発生する可能性が出てくる。
試験担当は誤りだと指摘するが、実際には誤りではないことがある。逆に、試験担当は誤りではないと指摘しなかったが、実は要求範囲外であって、誤りであった可能性もある。
この関係を整理すると図1のようになるだろう。
要求の範囲内について、試験結果が正しいか(◎)そうでないか(×)
要求の範囲外について、試験結果が正しいか(△)そうでないか(○)
要求の範囲内について実装しているにもかかわらず、試験担当に誤りとして指摘された×の場合には、ソフトウェアを修正する必要はない。
しかし、要求範囲外の実装になっていないということで誤りがあるとして指摘されたとしても、ソフトウェアを訂正する必要はないと考えるだろう。
また要求されていない動作をソフトウェアがしているにもかかわらず、試験担当が正しい動作だと見逃すこともある。
要求発見
試験結果によって発見できる要求を表1に示した。この表では、要求発見の分類と変更対象の関係と主な原因を示している。
要求発見 | 変更範囲 | 原因の例 |
---|---|---|
要件漏れ | ソフトウェア |
インターフェイス漏れ |
想定外の相互作用 | 運用手順 |
振る舞いや事前条件の抜け |
取違い | 文書 |
要求の説明不足 |
要件漏れ
要件漏れを発見している可能性がある。たとえばインタフェース漏れなどである。
想定外の相互作用
複数の要求間の相互作用によって、あってはならない結果にいたる場合がある。要求の振る舞いや事前条件、事後条件の抜けなどが考えられる。
運用手順を見直すことで対処することもできる。
取違え
要求が意味することを試験担当が理解できないために、誤りを指摘する場合がある。文書を修正して意味が伝わるようにする必要がある。
問題票の構成
次に、要求を発見するための問題票を構造化した例を表2に示そう。
関係 | 内容 | 担当者 | |
---|---|---|---|
問題 | 発見工程 |
□結合試験 □総合試験 |
試験担当 |
発見契機 |
□単一 □複合 |
||
理由 |
|||
調査 | 分析担当 |
||
対処 | 対象サブシステム |
開発担当 |
|
修正対象 |
□ソフトウェア □運用手順 □文書 | ||
修正種別 |
□代入/初期化 □機能/アルゴリズム □インタフェース □タイミング |
||
修正内容 |
問題
試験工程で検出した問題に関する記述では、発見工程、発見契機、発見内容を記述する。発見工程では、結合試験や総合試験などの試験工程なのかを選択する。発見契機では、単一コマンドや機能を試験しているときなのか、ある一連のコマンド操作などを試験しているときに検出した問題なのかを選択する。問題理由には、なぜ誤りだと判断したかを具体的に記述する。
試験担当が問題内容を記述する。
調査
調査内容では、指摘された問題内容が正しいかどうかを要求と比較して判断した結果を記述する。
分析担当が調査内容を記述する。
対処
対処内容として対象サブシステム、修正種別、修正内容を開発担当が記述する。修正対象にはソフトウェア修正、運用手順修正、文書修正がある。修正種別では、何を修正したかという誤り分類を記述する。
これについては、次に述べよう。
誤り箇所の分類例
JPLの例では要求誤りを次の4種に分類している。
- 代入と初期化
- 機能とアルゴリズム
- インタフェース
- タイミング
たとえば火星探査車のソフトウェアの例では、300K行のソフトウェアに対して400個の要求があり171件の問題票を分析したと報告している。この結果、統合試験と総合試験では代入・初期化がそれぞれ17件と6件で、機能アルゴリズムがそれぞれ15件と8件でいずれも誤りが多い。これに対して、インタフェースがそれぞれ6件と1件で、タイミングもそれぞれ5件と2件であり、ともに少なかったようである。
取違えの具体例
火星探査車の問題票の事例では、次のような取違えがあったとしている。
【取違え1】
遠隔装置がオフのとき、コマンドを発行したところリジェクトできず、遠隔装置をリブートしたら処理を完了した。要求どおりの振る舞いであったが、こういう事態があることを補足説明することも考えられる。
【取違え2】
分散コンポーネント間で相手から例外応答を受信した。タイムアウトなどの場合には例外ではなく通常応答である。
【取違え3】
ダウンロード回線がカウンタの値を出力すると誤解したため、カウンタをリセットしても値がそのままになっていた。実際にはそれまでのカウンタ値の最大値を出力していたのである。
このように、問題票で見つかる取違えには重要な視点の違いが含まれているので、次のような要求発見ガイドラインが提案されている。
要求発見ガイドライン[1]
問題票が次の条件を満足するとき、問題票の内容を再検討して要求を発見できる可能性がある。
【条件1】
同じ状況が運用で再現する可能性がある。
【条件2】
相互作用に関する取違えがある。
問題票をソフトウェアの欠陥を発見する手段として見るだけでなく、要求発見や運用上のミスを防ぐための価値を求める視点でも重要だと思われる。このような観点から問題票をこれまで見ていなかったことが多いのではないだろうか?問題票には重要な知識が含まれているということを示した良いアプローチだと感心する。
筆者の経験でも指摘項目のうちで約半分くらいは「指摘誤り」や「再現性なし」ということで、それ以上の問題票の分析をすることなくそのまま放置していた。実は、このような指摘誤りの中に重要な要求の漏れがあったということになる。たとえば、試験環境では再現しないが現地の環境では動作しないという場合もあった。このときは、現地のハードウェア資源の不足やソフトウェアのバージョンの差異などということで要求外としていたことも多い。しかし、運用環境の資源に対する現状を考慮した要求にすべきではなかったかと反省する。開発側の仮説に現場の運用を合わせるのではなく、最初に運用環境の状況を前提にした仮説を設定すべきであろう。
運用に対する考慮点
誤りではないが誤りであると報告された問題票を擬陽性(false positive)という。擬陽性の問題票を識別することができれば、どこかに試験担当の取違えが含まれているから、この取違えに気づくことで運用における取違えを予防できることになる。
取違えとしては、操作インタフェースの誤解と操作説明の不足が多いということである。このような取違えは、安全性が要求されるソフトウェアでなくても起きることではないだろうか?筆者の経験でも問題票はソフトウェアの信頼性を向上させるためにあり、バグを修正するためだけに使っていた。この場合、バグの修正に使われない問題票は価値がないと思いがちである。しかし、バグ修正につながらない問題票には価値がないどころか、運用操作の信頼性向上に使える重要な知識が含まれている可能性があるのである。
システムと人による操作の相互作用
筆者も航空機の自動発券機の前でうろうろして、結局は人のいる発券カウンターに並んでしまうことがある。先日も成田空港でそうだった。このときは担当者がいて、発券カウンターの横にある自動発券機を使って、私のパスポートを自動発券機にかざして搭乗券を発行してくれた。自動発券機の操作はなかなか難しいものである。電車の自動発券機の前で、お年寄りがおろおろしている光景もときどき見ることがある。いずれもシステムの機能としては正しいに違いないが、一般客には操作が難しくて正しく利用できる可能性が低いということであろう。システムと人による操作の相互作用について要求抽出の段階から検討する必要がある。
ソフトウェアの信頼性と安全性
図2にソフトウェアと運用との関係を示した。ソフトウェアに誤りがあるかどうかは、ソフトウェアが要求を実現しているかどうかを試験することで確認できる。ところがソフトウェアが安全かどうかは、ソフトウェアを運用するときにどのような危険を運用側にもたらすか、もたらさないかで判断される。したがってソフトウェアに誤りがあっても安全な場合もあれば、逆にソフトウェアが正しくても安全ではない場合がある。
図2 ITの外を見ないと安全性は分からない
本稿で紹介した手法の基本的な着想は、試験担当がソフトウェアを試験する時と、ソフトウェアを運用担当が運用する時の類似性に基づいて、試験担当による取違えに由来する指摘誤りが、実は運用担当による操作誤りを推定できるだろうということである。
まとめ
本稿では試験工程で発見できる要求について紹介した。さらに試験工程で作成される問題票の構成を示した。このような問題票で、問題発見契機、修正対象、修正種別を分析することにより、試験担当と開発担当との解釈の取違えという考えに基づき、たとえソフトウェアが修正されない場合であっても、運用時における操作誤りを予防できる知識を獲得できることを説明した。問題票の知識を活用することにより、ソフトウェアの安全性を運用段階で向上できる可能性がある。
今後の課題としては、問題票からこのような運用知識を獲得するための手法を確立することであろう。また、試験段階でなくても、要求レビュや設計段階でソフトウェアの運用者の視点に立つことで要求の抜けや取違えを発見できる可能性もある。
■参考文献
- [1] Robyn R. Lutz, Ines Carmen Mikulski, "Requirements Discovery during the Testing of Safety-Critical Software," icse,pp.578, 25th International Conference on Software Engineering (ICSE'03), 2003
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要