KAOS (55) 要求の優先度付け (3.4-2)

01/10/2014 – 7:52 AM

AHPが他のモデルと異なる特徴を整理すると次の4点になります 1．

人間の持っている主観や勘が反映されるようにモデルが作られていること

多くの目的を同時に考慮できるようなモデルであること

曖昧な環境を明確に説明できるようなモデルであること

意思決定者が，容易にこのモデルを使えること

前回は，効果的な優先度付けの制約について考えた．この制約を満足する手法として，AHP（Analytic Hierarchy Process, 階層分析法）がある．AHPになじみがない人のために，何回かに分けて説明したい．

先ずは，きわめて単純な（階層を持たない）例から．

今，代替案が3つあるとする．この3つに対して優先度を付加することを考える．AHPでは，ペア比較（Pairwize Comparison，一対比較という訳語もある）を行う．必ずペアで比較する．これが，特徴のひとつである．もちろん，3つくらいであれば「えいやっ」法が使えるのであるが，多数に対する発展性に乏しい．

簡単なペア比較表
代替案A 代替案B 代替案C
代替案A 1 9 5
代替案B 1/9 1 1/4
代替案C 1/5 4 1

縦軸・横軸ともに，同じ3つの代替策が並ぶ．決定しないといけないのは，上の表で青色背景色の部分である．ペアでの比較で，2つの代替案のみを比較する．通常は，１〜９の数値で表現する．１は「同じくらい」．9は，「きわめて重要」という場合である．上記1行2列で，9となっているのは，代替案Aが代替案Bよりも「きわめて重要」ということである．

一般には，1,3,5,7,9かその逆数を用いる．まれに偶数も用いる（上記）．或いは，単に1,4,9とする場合もある．

行毎に考えていく．1行・1列目は，同じものの比較であり，当然1になる．この右下がりの対角線は常に１である．次に，代替案Aと代替案Bを比較する．代替案AはBと比べて「きわめて重要」なので，ここでは9を与えている（逆に考えないよう注意，ここでは，代替案Aが重要である）．次に，代替案AとCの比較で，代替案Aは「かなり重要」で，5としている．

あくまで相対的な比較と云うことである．これは前回の条件bに相当している．

次は2行目．代替案Bから見て，代替案Aは逆の関係にあるので，先に入力した9の逆数がそのまま入る．2行・2列目は，同一比較なので１になる．3行・3列目は，代替案Bから代替案Cを見た場合である．Cの方がBよりも（4倍程度?）重要だとすると，ここには逆数が入る．

3行目は，もう比較済みなので，それぞれ逆数が入る．下三角行列は，常に入力不要である．

表を見て，2行目がそもそも要るのかと思ってはいけない．ここは，ポイントである．表にしてしまうと，つい，5/9を入力してしまいたくなるが，あくまでペアでの比較として考える．

計算のときは，表を埋めることになる．しかし，利害関係者に表を記入してもらうわけではなく，アンケートやインタービューを通して，データを集める．従って，アンケート用紙の作り方やインタビューの方法に考慮が必要である．

enquete

最近よく見かけるペア比較タイプのアンケート

（この項つづく）

 (nil)

Notes:

  1. 木下栄蔵，入門AHP 決断と合意形成のテクニック，pp. 2-3, 日科技連，2000 ↩
By nil | Posted in KAOS, 要求, 要求工学 | Tagged | KAOS (55) 要求の優先度付け (3.4-2) はコメントを受け付けていません

KAOS (54) 要求の優先度付け (3.4-1)

30/09/2014 – 8:06 AM

要求の優先度が役立つ場面には次がある．

  • 利害関係者が望む全ての特性を開発するには，用意した予算・人員・納期では，制約があるとき
  • （例えば，スパイラル型の開発において）次のサイクルやリリースを計画する，或いは不測の事態（開発の遅れ・予算の制限・人員不足・納期短縮の圧力）のために再計画を行うとき．
  • 優先度の低い要求を後回しにする，或いはあきらめることによって，衝突回避が可能になるとき

優先度があることは意義深いことだとして，どうしたら効果的に優先度を付加することができるか．以下が条件としている．

  1. レベル分けされていた方が良い．レベル内では，各要求は同一の優先度を持つ．容易に優先度付けできるように，レベルを示す数値は，小さい方が良い
  2. レベルは，量的というよりは質的な区分の方が良い．また，絶対的レベルというよりは，相対的なレベル分けが良い（例：「高い」ではなく，「〜より高い」）
  3. 要求は，比較可能であること．そのためには，粒度や抽象度が同じくらいであること．
  4. 比較される要求は，他から独立であること．少なくとも，相互に依存していないこと．相互依存があると，ある要求をあきらめたときに，残るべき要求も成立しなくなる
  5. 優先度レベルによる要求のクラス分けは，同意のために利害関係者同士で調整済みである必要がある

前回の寄与度と同様に，優先度を如何に体系立てて付加するかが，ここでの議論である．対象が単純であれば，えいやっと優先度をつけて，合意をとるのも容易かもしれない．しかし，レベル分けが必要なほど複雑になってくると，合意をとるのはなかなか難しくなる．

一般的な合意形成の手法として有名なAHPを，次回扱う．上記のうち，a-dは，ヴァリエーションが多くあるAHP（Analytic Hierarchy Process）のうち，最も基本的なAHPの条件でもある．

ソフトウエアを作る側は，常に合理性を求められるが，要求者はどうか．共に，体系立てて合理的に考えることは，（特に二者間取引においては）重要である．

（nil）

By nil | Posted in KAOS, リスク, 要求, 要求工学 | KAOS (54) 要求の優先度付け (3.4-1) はコメントを受け付けていません

KAOS (53) 代替策の評価 (3.3-1)

29/09/2014 – 7:20 AM

（…）様々な貢献型がある．”マイナス”の貢献をするものからプラスの大きな貢献をするものまで．プラスから順番に並べると次のようになる．実現する（MAKE,++），助けになる（HELP,+），不明(UNKNOWN,?），邪魔をする（HURT,-），阻害する（BREAK,–）．(NFR本 1，p. 63)

ここでは，代替手段の選択に関する評価を取りあげている．代替手段の利点は，そもそも何か．

  • 副目的・機能・前提に関する代替となる組合せの中に，適切なものがあれば，目的を達成できる可能性がある
  • システムコンポーネントとソフトウェア−環境の境界との間で，代替となる責任を割当できる可能性がある
  • 代替となる解決策によって，要求文の間の衝突を解消できる可能性がある
  • 代替となる対抗手段の組合せによって，リスクを減らすことができるかもしれない

KAOS的用語が使われているので，少し説明が必要かもしれない．

2番目は，KAOSにおいて，仕様ノードには，操作とエンティティが割り当てられることを思い出す（思い出すといっても，この議論は，第二部に入ってからである．まだ説明がない）．或いは，仕様は「誰か」が実行する必要がある．人が実行する場合もあるし，システム化の目的からは，システムの構成品である何かのコンポーネント（即ちソフトウェア）である．もし，ソフトウェアが受け持つ範囲が変化すれば（即ち，境界が変わるので），対応するコンポーネントが新たに必要になる，不要になる，或いは変更が必要になるということである．

もし，不要になれば，（例えば開発労力が減り）プロジェクト視点での要求を充足できるかもしれない．

上記は，当たり前のことのようにも思う．しかし，KAOSを初めとする要求分析手法のメリットは，体系的に実施することにある．体系立てることによって，間違いを減らす．思い込みに基づく争いを防ぐことが可能となる（これは，ひとつの信念かもしれない）．

 冒頭のように，これまで何度も登場している NFR本では，プラスやマイナスの記号を用いて，代替手段の貢献を示すことができる．以下は，単純な例である．

NFRにおける貢献度の図的記述法の例

NFRにおける貢献度の図的記述法の例

この図の例では，正確さに対して，柔軟なユーザインターフェイスというソフトゴールは，マイナスである．即ち，目的達成の邪魔をしている．優先度の付加はプラスの効果である．正しいかの「確認」を行うことは，まさに正確さの実現ということになる（NFRの図式の説明は，いずれ行いたい．！は，重要なソフトゴールであることを示している）．

質的な代替手段の評価においては，KAOSでもこの方式を勧めている．

(nil)

Notes:

  1. Chung, L., Non-functional requirements in software engineering. Kluwer Academic: Boston, 1999. ↩
By nil | Posted in KAOS, リスク, 未分類, 要求, 要求工学 | KAOS (53) 代替策の評価 (3.3-1) はコメントを受け付けていません