KAOS (1) 準備としての状況設定(1.1-1)

08/08/2014 – 5:09 PM

機能安全については，一区切りつけて，しばらくは，KAOS法について書いてみたいと思う．ただ，概説を書くつもりはなく，Lamsweerde氏の著書 1を吟味しながら，思うところを書いていく．興味のあるところは，先になかなか進まないと思う．ちなみに今回は，最初の2行のみが対象になっている．

ある問題がソフトウェアによって正しく解決する，ということを確実に実施するためには，解くべき問題を最初に正しく理解し定義することが必要である（イタリック箇所が原文，以降も同じ）

これは本当かということから，本書は始まる．

そもそも何が正しい問題かを示すことが難しい．どうしてそれが問題として現れるべきなのか．誰が問題解決に関係すべきなのかを知らなければならない．

ここでは，問いが二重になっている．（具体的な要求の）問題解決は，（要求工学において）何を問題と見なして，どう解決されるべきかという．従って，要求工学というのは，「すべて（all about）」である．誰でも何でもいうことができるけれど，決して，誰も正解には到達しない．然るが故に，安心して好きなことがいえる．

さて，メタで考えてみる．要求工学が解くべき問題とはなんだろうか．いま，要求者が何かをしたいと思った．何故思ったかにはいろいろある．(a) 業務上の面倒な手作業に疲れたかもしれない．或いは，(b) パフォーマンスを上げない限り，ビジネスが成立しないという切実な問題に向き合っているのかもしれない．または，(c) 魅力的な製品のデモを見たなどのきっかけで，本当はこんなことがしたかったんだと自分の欲望に気づいた場合である．

(a)(b)の要求分析は簡単で，(c)が難しそうに見えるかもしれない．しかし，難しさの種類は違っても，全て難しいことに変わりはない．

(a) の場合

手作業をシステム化するということは，オーバーヘッドを伴うことが多々ある．今までは，手書きで好きな場所に記録をとっていたのに，そういう融通がまったく利かないかもしれない．また，対象業務のうち50%が仮に10倍速くなったとしても，残りが変わらないと，全体の効率UPが50%を超えることはないという見落としがちな現実がある．システム化による手間で，その効果も相殺されているかもしれない．今のプロセスをシステム化によって変更した時の新たなプロセスは，想像が難しいというのが，困難さの一番の理由だろうか．体験のみがイメージを作る．

(b) の場合

この場合の切実な例は，天気予報である．明日の天気予報のための計算は，今日中に終わらないといけない．明後日になったのでは意味がなくなる．ただ，極端な話としてはそうなのだが，その天気予報であっても，何らかの妥協がなされるに違いない．例えば，必要な時間に終了できるように，計算アルゴリズムを簡略化するとか，提供する情報を可能な範囲にとどめるといったことである．もちろん一般には，これほどの切実さはないだろう．しかし，どの程度の性能にしておけばよいか，といった非機能に類する要求はやはり定義が難しい問題である．

(c)の場合

ビジネスにおいて，個人的な理由から費用をかけてソフトウェア開発がなされるのか？という疑問を持つかもしれない．しかし，大概はそういうものではないかと想像している．Lazzarato氏がいうように，今やソフトウェアに占める「情動」の割合が大きい以上，ますます個人的動機からスタートする場面も多くなっているに違いない．もちろん，この個人は誰でもよいというわけではなく，プロジェクトをスタートさせるだけの力を持った個人ということになる．また個人的な理由が前面にでることもなく，通常は合理的に見える説明が表に出る．こうなるととてもややこしい．表面上の話には，「こうしたい」というのが現れていないわけだから，普通には分析しようがないということになる．

Lamsweerdeさんが言うように，問題定義は容易ではない．解くべき問題が定義できたときに，問題は解決しているという言葉が，頭をよぎる．

（nil）

Notes:

  1. Lamsweerde, A. v., Requirements engineering : from system goals to UML models to software specifications. John Wiley: Chichester, England ; Hoboken, NJ, 2009; p xxix, 682 p.
    ISBN:0470012706 (pbk.) 9780470012703 (pbk.) ↩
By nil | Posted in KAOS, 要求工学 | KAOS (1) 準備としての状況設定(1.1-1) はコメントを受け付けていません

実験による立証

11/11/2013 – 9:07 PM

安全という言葉は，「危害源（ハザード）がないこと」と定義される以上，「この車は，安全である」という言明は，「この車には，危害源がない」となります．従って，これを示すためには，危害源の不在証明をしなくてはならなくなります．一般に，否定的な言明は，証明することができません．それは，プログラムにおける誤りを示すことができないのと同様の構成になっています．単に構造だけではなく，ソフトウェアの比重が高い以上，実質的に同じといっても良いかもしれません．

この解決策として，形式的なアプローチが主張されます．それは形式科学とでもいうべき，数学や形式論理学での証明を使う．あるいは，天体の運行が形式科学の道具立てを使い，成功しているからということだろうと思います．しかし，経験科学，特に人間系が関わる分野では，必ずしも成功しているわけではないというのは，社会学や経済学の事例を持ち出すまでもなく明らかだろうと思います．

これは何も安全に限った話ではありません．経験科学でかつ人間系が関わるカテゴリに含まれるソフトウェア工学においても同様です．今回は，このソフトウェア工学の分野において，理論があってそれを証明しようとする時，いかなる立証の方法があるかという話になります．

つい最近，勧められた次の本を読みました．

「先進的な実験によって立証するソフトウェア工学の手引き」とでも訳せるタイトルです．「実験によって立証する」というのは，エンピリカルにあてた訳語です．通常は，カタカナをそのまま用いることが多いようです．

ちなみに，このソフトウェア工学におけるこの「実験によって実証する概念」は，Basili先生によって始められ，その端緒たなった論文は，通常「ソフトウェア工学における実験」が参照されています．

さて，上記の手引きが「先進的」かどうかは別にして，まさに「実験によって立証する」のだという精神に満ちています．もちろん，自然科学における実験に相当するものだけがその対象ではありません．以下に示すようなデータ収集手段があります．

  •  コントロール実験（Controlled Experiments）
  •  ケーススタディ（Case Studies）
  •  サーベイ（Survey Research）
  •  エスノグラフィ（Ethnographies）
  •  実地研究（Action Research）

最初のものは，まさに自然科学分野において用いられる方法で，実験群と対照群にわけて比較する方法です．後者になればなるほど，社会学的アプローチに近づきます．

さて，この本でおもしろいのは，11章になります．この章のタイトルは，ソフトウェア工学研究に対する実験によって立証する場合の手法の選び方（Selecting Empirical Methods for Software Engineering Research）です．

かなり辛辣にソフトウェア工学分野での実証主義的「実験」の有効性について述べた後，次の４つの哲学的立場があるとしています．

(1)　実証主義

自然科学にあるように，基本的な事実の観測から論理的な推論を通して結論を持ち引き出す．

(2)　構成主義（解釈主義）

科学上の知識は，人間から離れて存在することはできないと考える．例えば，科学的な理論に用いられる用語の意味は，社会的に構成されている．

(3)　批判理論

何らかの制約を加えられている思考システムから人々を解放することによって，その価値を判断する．実践を目指す

(4)　プラグマティズム

全ての知識は，適当で不完全である．その価値は，どういう方法で入手したかに依存し，役に立つか否かが問題となる．真実は，観察者によって異なる．従ってコンセンサスが重要になる．

学校教育の成果か，一般には(1)が科学全般において用いられる方法と考えます．ただし，科学においてすら妥当な分野は限定されるというのは，カール・ポパーたちの議論から明らかになっています（明らかというのは，言い過ぎかもしれませんが，帰納法が潜在的に持つ限界は明らかで，論理は反証が見つかるまでは棄却できないというのは，一つの立場として認められると思います）．

もう少し，科学の範囲を広くとると先に挙げた（２）〜（４）の立場が現れます．11章の結論は，（１）の適用範囲には限界があり，（２）〜（４）から適切に選ぶべきとなっています．このあたりの構成は，著者たちは言及していませんが，トゥールミンの「理性への回帰」における主張（特に6章の「方法再考」）と類似の議論になっています．

これはこれで良いとして，では実際にはどうするかということもあるだろうと思います．

ソフトウェア工学が扱う範囲で，例えばソフトウェア開発を行うということになると，多くの変項がありますし，人間系の問題ですから，そもそもそこでの理論を立てようがあるのかということになります．証すべき理論がなければ，それを（帰納によって）これこれのデータから示されるとすることはできないはずです．おそらく検証可能性を議論する以前の問題となることが多いように思います．

では，何が残るかと言えば，近代的合理性というよりは，何ごとかについての，筋の通った説明ということになるのではと思います．あるいは，理にかなっている，納得する説明ということでしょうか．もちろん，誰にとっての筋がとった説明かというのはありますから，構成主義者たちがいうように多様性をみとめ，プラグマティストたちがいうようにコンセンサスが重要で，批判理論者が主張するように，それは実践に関わるものでなくてはならないと思います．すくなくとも，実証主義的装いをしたまがいものだけは避けるべきと考えます．

(nil)

By nil | Posted in 社会, 立証・論証 | 実験による立証 はコメントを受け付けていません

勇名轟くヘクトルは，防壁の中へ躍り込む

21/10/2012 – 3:38 PM

ノルウェイの博士課程の学生さんが書かれた「安全性 vs. セキュリティ」という文章があります 1．この文章によると，ノルウェイ語では両者は区別されずに‘sikkerhet’と呼ぶそうです．これは，両者とも基本的には安全で代表するが，場面によって「セキュリティ」を区別のために外来語として扱う日本と似ている気がします．以前に見たとおり，「セキュリティ」は，一般的には「安全」を確保する手段と考えることができます．この学生さんの文章では，「安全性」と「セキュリティ」を幾つかの特性を用いて区別しているのですが，それとは別の方法で，ここでは考えてみたいと思います．

ここでは区別のために次のようなルールを考えます．

二項があったときに，いま関心を持っている側が人の場合には「安全性」を使う．逆に，人ではない場合には，「セキュリティ」を使う．

例えば，私と石の二項を考えます．私に石が飛んでくるとします．いま主たる関心が私（S）にあれば，「安全性」について語ることになります．一方で，その石が貴重なもので私がそれを盗むということを考えてみます．この場合は，今度は石がSとなり，人ではないので，「セキュリティ」の議論となります．もちろん私以外にも石に関心を持っている人がいるでしょう．この場合は三項になります．例えば，私（S）に，ある人（O1）が石（O2）を投げる場合を考えます．この場合は，私にとっては石が飛んでくるのですから，「安全性」の問題ですが，ある人（O1）に視点を移すと，こちらが主体化されます（Sとなる）．私を排除しようことに何らかの意図があるわけですから，私自身は代替可能なモノ的なわけです（Oになる）．排除によって最終的に土地や金品などの財産を奪うのだとしたら，こちらは「セキュリティ」の問題と云うことになります．このように，安全性とセキュリティの間には，どの側面から議論するかで変わる場合があります．

***

さきに，「排除」によって，土地や金品を奪うという話をしました．逆に言えば，誰も「排除」することなく自由に取得できるのであれば，そこにセキュリティの問題は存在しないことになります．

この「排除」に着目して，別の側面から考えてみます．こちらは，情報セキュリティに限定していることに注意をしてください．限定的な「セキュリティ」という用語の使い方になります．また，ここでは安全性ではなく，ディペンダビリティとセキュリティを対比させています．安全性は，ディペンダビリティの一要素というとらえ方です．

ここで，機密性（confidentiality）がセキュリティのみに関係するのは良いだろうと思います．この機密性を確保するためには，「権限付きアクション」が必要になります．また，一般には，可用性に示されるようにシステムが常に利用可能であることが大事ですが，セキュリティの場合は誰でもアクセスできることは望ましくないわけですから，そこにも「権限付きアクション」というフィルタが入ることになります．完全性（integrity）も，セキュリティの側からみると不用意にデータが更新されることはないということを意図します．この場合は，ただ先の可用性とは異なり完全性の喪失において陽に権限付きアクションが関わるわけではありません．正当な変更は，完全性を失いませんから．しかし，「権限付きアクション」でない場合は，ある蓋然性を持って完全性が損なわれると考えて良さそうです．

以前は，SQuaRE（Systems and software Quality Requirements and Evalution）という新しい品質モデルで比較しましたが，視点が異なるとその構造（関連する特性との関係）も変わってきます．以下に念のために再掲しておきます．

【安全性を含む場所】(4.1, Table 3)
定義場所：利用時の品質
特性　　：リスク緩和性
副特性　：経済的リスク緩和，健康及び安全リスク緩和，環境リスク緩和
【セキュリティを含む場所】(3.3, Figure 4)
定義場所：システム／ソフトウェア製品品質
特性　　：保障性（security）
副特性　：機密性，完全性，行為証明性(non-repudiation)，行為追跡性（accountability），真正性

注意すべきは，どちらも安全性が一次要素になっていないことです．上記ですと副特性として定義されています．これは以前に議論したとおり，システムの特性としてはみなせない．あくまで環境を含んだ系として考えるべきことがらである，ということに依拠しているからだと思います．

「排除」に対応した防御は，「セキュリティ」のみならず，「安全性」においてももちろん重要です．情報セキュリティの場合は，その防御が主としてシステムの要素となっているのに対して，安全性の場合はその防御がおおむねシステム外にあるというところが，どこまでの系を考えるかというときの違いとなる，ということだろうと思います．

***

表題は，イリアス XII から 2．

（nil）

Notes:

  1. http://www.iot.ntnu.no/users/albrecht/rapporter/notat%20safety%20v%20security.pdf ↩
  2. ホメロス イリアス 松平千秋訳 岩波文庫 1992 ↩
By nil | Posted in セキュリティ, 安全 | 勇名轟くヘクトルは，防壁の中へ躍り込む はコメントを受け付けていません