KAOS (25) 良い要求工学を実践する上での障害 (1.3)

喫煙者は,タバコを吸うことが身体に悪いと知っていながら,タバコを吸い続ける.今のやり方では拙いと分かっていながら,要求分析の方法を変えない実践者に似ている(p.52)

少なくとも人間が習慣を変えることを嫌う生き物であることには,同意する(喫煙は比喩として不適切だが).ここでは,要求工学の様々な技術を適用する上で,障害となることを述べている.なかなか興味深い.前回までに見たように,要求工学は重要であるにも関わらず,なぜ余り実践されないかという「障害」である.

費用回収の見込み

一般的に,要求の分析は,プロジェクトの契約前に実施する(提案するためには分析が必要).このとき,契約を結べるかどうかは分からないため,十分な費用を掛けることができない.

余裕のなさ

厳しいスケジュール・短期費用・最新技術へのキャッチアップに対する懸念と圧力がある

「経済学 1

要求工学における「経済学」の研究は,ほとんどなされてこなかった.また,要求工学の技術を適用することによる利点と,費用面での有利さに関して,量的な研究も行われてこなかった.測定は難しい.大規模なエンピリカル研究からは,十分な証拠を得ることはできなかった.

取り残される要求文書

実践者は,時に要求文書が巨大で複雑だと感じる.そうした場合,プロジェクトの進化に合わせたメンテナンスがなされることはなく,古くなった要求文書は,誰からも見向きもされなくなる.

要求文書では動かない

要求文書は,最終顧客がお金を払う実行可能なソフトウェアから(ライフサイクル上)遠い位置にいる.実際,要求の品質は,最終製品の品質がどうかを,示していない.

取り組みの遅れ

授業や教科書,そしてパイロット研究を通じた効果的な要求工学技術の応用は, 他のソフトウェア工学の分野よりも遅れている.

(nil)

Notes:

  1. 当然ここでの経済学は,BohemのSoftware Engineering Economics を下敷きにしている.従って,括弧付きの経済学である.それでも,経済学的視点は必要だと考えている.特にソフトウェアプロセスの選択はトレードオフであり,マクロ的視点は必要だと考えている(とりあえず,お金の話は関係ない)

KAOS (24) 要求工学の役割とその危険 (1.2.2)

高品質の要求を「エンジニアリング」することは,きわめて重要なことである.要求・前提・ドメインプロパティ中に誤りがあると,場合によっては,多数の人に影響し,長く続き,非常にコストがかかる.そして,危険な状況を引き起こす.(p.51)

ここでは,要求工学の重要性について,負の側面から見ている.重要だから間違いがあっては困るというのは当然だが,改めて箇条書きになると気が引き締まるに違いない.

技術面

  • 受け入れテストデータの導出
  • ソフトウェアアーキテクチャ設計とコンポーネント/コネクタ識別
  • 品質保証チェックリスト定義
  • 設計文書およびユーザマニュアル作成
  • ソフトウェア進化のための対応

コミュニケーション面

要求文書は,ソフトウェアプロジェクトに関係する人たちが,ソフトウェアに対して意思疎通を図るときに,もっとも参照するものである

プロジェクト管理面

要求文書は,プロジェクトコスト・必要なリソース・開発ステップ・マイルストーン・レビューポイント・スケジュールを決めるための基礎文書である

法的面

要求文書は,ソフトウエアを提供する組織・顧客(・再委託先)契約において,コアとなる文書である

認証面

法規によって,品質基準を強制することが増えつつある.特に,医療・輸送・航空・原子力といった分野が相当する

経済面

多数の人に影響し・長く続き・非常にコストのかかる要求文書の誤りは,経済的に大きな影響を与える

社会面

十分にユーザ中心に考えられていないと,要求工学プロセスは,重要な必要性や制約を見過ごすかもしれない.結果として,(システムを使用した)活動に悪影響及ぼす.システムは,部分的に利用する・間違って利用するか全く使われないまで,様々な反応を引き起こす.結果として,そのシステムの利用を前提とした人間系を含む社会システムに大きな影響を与える.

最後の例では,ロンドンの救急システムの問題が挙げられている.同じ救急に関しては,最近私が読んだ記事にも類似の例がある.システムのデザイン変更により,同様に救急搬送の問題解決ができた佐賀県の例である 1.システムに誤りがあれば,救えたハズの命も危うくなる.

特定の医療機関への搬送が集中していることが救急隊員にもリアルタイムに確認できるようになり,考えて行動できるようになったことで,搬送先の分散化を実現できた.

(nil)

Notes:

  1. 「ITが救急車・救命士・救命センター連携を変える」 臨床画像 Vol.30 No.9 2014

KAOS (23) どうして要求をエンジニアリングするのか (1.2.1-2)

要求を精緻化するために明示的・暗黙的に用いるドメインプロパティもまた間違っているかもしれない.(p.49)

例として挙げられているのは,LH 2904 便が,ワルシャワ空港で悪天候下着陸しようとして,滑走路上で正常に停止できなかった事故である(1993年).ここでの例は,M. Jackson の本 1からとしている.

ともに,事故そのものについては余り触れていないので,簡単に書いておく.


悪天候の中で,ワルシャワ空港に着陸しようとしていた航空機 A320-200 は,ウィンド・シア(急激な風速・風向きの変更)があるという情報から,規定に従いアプローチの速度を上げた.滑走路に降りたが,速度は速く横風のために,左脚を十分に接地しないままの滑走が続いた.また,停止のための各装置の作動が遅れた.その結果,滑走路をオーバーランしそうになり,障害物を避けるために右に曲がった.左翼が土手とぶつかり,燃料タンクが破損.火災が発生した.死者2名.負傷者68名.

事故調査報告書によると,ブレーキシステムは次の仕様になっていた.

1. グラウンドスポイラ

ONが選択され,次の「地上」条件に適合したときにスポイラが動作する

地上条件:両方の着陸装置のショックアブソーバが,共に6,300kg以上の加重を受けている.或いは,両方の着陸装置の車輪の回転速度が,共に72ノット(約時速133Km)を超えている.

2. 逆推力装置

ONが選択され,地上条件に適合した場合に動作する

3.  車輪制動

ONが選択され,地上条件に適合した場合に作動する

即ち,地上で停止するためには,全て「地上」条件を満足している必要があった.しかし,横風を受けて車輪は片側だけの接地であり,かつ滑走路がぬれていたため,スリップにより車輪回転からは正しい速度を計算できない状態であった.即ち,接地しているにも関わらず,地上にはいないとシステムは判断した.


Lamsweerdeさんの説明は,次になる 2

システム要求

ReverseThrustEnabled ↔ MovingOnRunway

(逆推力装置が可能なのは,滑走路上を移動しており,かつその時に限る)

ソフトウェア要求

reverse = ‘on’ ↔ WheelPulses = ‘on’

(リバース変数をon にセットならば,車輪の回転パルスがオンであり,かつそのときに限る)

仮定

WheelPulses = ‘on’ ↔ WheelsTurning

reverse = ‘on’ ↔ ReverseThrustEnabled

(車輪の回転パルスがオンならば,そのときに限り車輪は回っている)

(リバース変数をonに設定するのは,車輪が回っているときに限る)

ドメインプロパティ

MovingOnRunway ↔ WheelsTurning

(滑走路上を移動しているならば,車輪は回り,かつ車輪が回るのは,滑走路上を移動しているときに限る)

ソフトウェア要求に対して,仮定とドメインプロパティを組み合わせると,システム要求と同じとなることを,辿れると思う.

明らかに,ドメインプロパティが間違えていたということになる 3

(nil)

Notes:

  1. 『ソフトウェア博物誌―世界と機械の記述』(Michael Jackson(原著), 玉井哲雄・酒匂寛(翻訳))、トッパン、267頁、1997年 p.230-231に本事故に関する記述がある
  2.  ↔で示す双条件は日本語にするのが難しい.A ↔ B の場合,AならばBであり,BならばAである.或いは,かつそのときに限る,となります
  3. 実際には,車輪は回転している.車輪から推定する速度が規定速度に達していなかった.従って,車輪が回るというのは,規定速度に対応する回転速度ではなかったと解釈する