パズル:人とライオン

形式手法の特徴と活用という解説を組込みシステム技術協会に寄稿した。その際に、例題として人とライオンのパズルを使った。このパズルを少し分析してみたい。

まず、パズルの内容であるが、次のようになる。人が3人、ライオンが3頭、ある川の前にいて、船で渡ろうとしている。船は1艘で、定員は2。人もライオンも船を操縦できる。どういう手順で渡ればよいか。ただし、両岸、船の中で人がライオンより少なくなると、食べられてしまう。

状態遷移系を使って解を求めてみる。まず、船の乗り方は5種類しかない。人2、ライオン2、人1、ライオン1、人1ライオン1。船の中はすべて安全である。

ある岸における人とライオンの数の組合わせは、4通りかける4通りで、16通りがあり得る。その中で安全な組合わせは10通りしかない。船の位置は2通りなので、ある岸における人の数、ライオンの数、船の位置で状態を表すとして、高々20通りと言うことになる。

初期状態は、人3、ライオン3、船はこちら側。終了状態は、人0、ライオン0、船は向こう側。最初の移動による状態を考えてみると、5通りの船の乗り方の中で、安全状態は次のいずれかしかない:

人3ライオン2、人3ライオン1、人2ライオン2

最初の状態の次は初期状態しかなく、残りの状態の次は、後戻りを避けると、次の状態だけである:

人3ライオン2

その後も、次の安全な状態は1又は2通りしかない。意外と正解の数は少ない。図で表現するとこのようになる。

値引きと割引きの違い

見積明細を書いているとき、これは値引きと書くのか、割引きと書くのか迷った。今まで、出精値引きという表現は使っているが、このときには何とか値引きじゃおかしいと感じた。

類似語辞典で調べてみた。値引きは物の値段に関して使われているだけで、割引きの方が使用範囲は広い。たとえば、携帯電話料金には割引きが使われている。人の能力や考えを割引くとも言うし、将来の企業価値を割引く、手形を割引く、というように使われている。

対応する英語は、和英辞書によれば、discountとなるようだ。逆に数えるという語源を持ち、ほぼ、割引くと同じ意味で、同じように使われている。割引きの語源はわからないが、discountの訳語にぴったりだ。

物やサービスの料金、人や企業などの価値には割引きを使い、物の値段を割引くときだけ、値引きとしてもよい。

車の機能安全

先週、ISO26262の解説を聞く機会を得た。安全要求は、安全機能と安全度に関する要求から構成されると理解しているものには、ちょっと物足りなさを感じた。車では、安全度しか取扱っていないと感じたから。

安全を実現するためにどういう機能を実装しなければならないかは、既に実績済みであり、差別化事項であり、規格で規定することではないと言うことかもしれない。

ということで、ソフトウェア開発に関しては、バグを作り込まない、バグを封じ込めるための開発手法だけが話題。後者は、アーキテクチャ設計に関係するが、基本的には、開発プロセスの改善が課題。車の分野では、開発プロセスのアセスメントにAutomotiveSPICEが広く使われているので、この拡張で対応しようという意志があるかもしれない。

先日の報道によれば、NECは、ISO26262の支援サービスを提供する。規格の内容の研修、開発プロセスの診断、改善の実施支援から構成される。通常のプロセス改善サービスと同じだ。

消費税課税事業者

来月から5期目の事業年度に入る。2年前の売上が1000万円を超えたので、今期から消費税を納付しなければならない。届出が必要だと記憶していたので、国税庁のホームページで確認した。

事由が生じたら速やかに届け出ると記載されているが、よく読むと、今ではなく、2年前、売上が1000万円を超えたときに届けなければならないと気づいた。速やかではないけど、手遅れではなさそうなので、e-Taxを使って申請書類を送付した。

会計帳簿は税抜きで記載し、期末に税額を確定させて、納付することになるらしい。

形式仕様記述では何ができる

モデル検査ではシステムの動作仕様をまねるモデルを作って、そのモデルを動作させて特定の条件を検査する。他方、形式仕様記述では、システムの仕様そのものを正確に記述する。曖昧さを排除するため、その記法に数学的手段を用いるが、次の効果が生まれる:

1)特定条件の成立を、実行させることなく、数学的手段によって証明できる。

2)仕様詳細化が可能な場合には、詳細化後も1)の特定条件が成立することを証明できる。

つまり、仕様作成の段階でテストができると言うことであり、テスト済みの仕様からテスト不要なコードを生成できると言うことである。

しかし、限界はある。その一つが、要求を設計仕様と同じように形式仕様記述できるかである。仕様が、そしてコードが、要求を満たしていることの確認は、人手によらざる得ない。

もう一つの限界は、記述対象があらかじめモデル化されていて、それから外れれば、記述できないことである。そのモデルとしては、内部状態を持ち、操作によってその状態を変える機械、データ構造を定義し、その操作を提供する抽象データ型が代表的である。

システム開発の一部にしか適用できないことになるが、だからといって形式手法が役立たないと言うことにはならない。仕様段階で検証できることの効果は大きい。

モデル検査で何ができる

形式手法は、実用的に分類すると、形式的仕様記述とモデル検査に分けられる。このモデル検査では、検証対象の設計仕様をモデル化し、そのモデルを実行させて、特定の要求仕様の成立を検証する。

ここで、モデルに状態遷移系を使うので、検証できる仕様は、システムの動作仕様にほぼ限られる。したがって、モデル検査の手順は次のように記述できる:

1)システムの動作仕様を記述する。

2)状態遷移系としてモデルを記述する。

3)検証したい要求仕様を記述する。

4)モデルを実行させ、要求仕様の成立を調べる。

検査することは、動作仕様が要求仕様を満たすかどうかである。そのために、モデルが特定の条件を満たすかを調べるが、本来の目的を忘れてはならない。

電子証明書を更新

住民基本台帳カードに記録している電子証明書は、3年で有効期限が切れる。次の有効期間は、更新日から3年間と言うことなので、期限直前に市役所に行った。

写真付台帳カードなので、このカードだけ持参すればすむが、手続きでパスワードが必要になる。これには2種類有り、カードの暗証番号と、電子証明書のパスワードを要求される。このことは、市役所からの案内書には書いてない。幸い、PCを鞄に入れていたので、出直さずにすんだ。

案内書も不備だが、窓口も手慣れていないように感じた。利用者は少ないかもしれない。

安全機能の分類

製品やシステムの安全に関するリスクが大きいとき、それを許容できるまで低減させる対策が安全機能である。この安全機能とは何か、その分類を考える。

まず、リスクとは、潜在危険の発生頻度と発生する危害の大きさで決まるから、発生頻度を下げるか、危害の大きさを小さくできれば、それが安全機能となる。

別の観点として、危害発生のメカニズムを考える。稼働しているソフトウェアの中には、開発時に作り込まれたバグという欠陥が潜んでいる。気がつかないが、あらかじめ決められた条件が成立すれば、この欠陥は顕在化する。バグが顕在化すると、所定の機能が実現できなくなり、いわゆる故障が起きる。この故障が、人に危害を加えるという事故を起こす。

この危害発生メカニズムに従えば、安全機能の第1段階は、欠陥検出(ハードウェアも含めば、障害検出)である。障害を検出したら、次にやることはこの障害からの回復である。障害回復できないと、第3段階として危害を抑制することになる。

二つの見方を組み合わせると、たとえば、データベースの不整合という事故を例に取れば、安全機能を次のように整理できる:

1)発生頻度を下げるために、不整合を起こす要因を洗い出し、その発生を検出し、それを訂正するか、あるいは中断させる。

2)データベース不整合を常に監視し、それを検出したら、不整合のない状態に戻す。

テストのためのバグの分類

ソフトウェアテストの目的は、バグを検出することにある。効果的にテストを行うためには、バグに関する考察が役に立つ。

バグがどこに潜んでいるかを考えるために、ソフトウェア構造をモデル化する。まず、ソフトウェアはユニットの集合であると考える。それぞれのユニットには要求仕様が対応し、その要求仕様を実現しようとして作成される。各ユニットは、関連するユニットと協調し、システム環境の中で動作する。

このモデルに従えば、まず、要求仕様に関連するバグを予想できる。要求仕様は完全でないかもしれないし、矛盾を含んでいるかもしれない。仕様に問題がなくても、それを正確には理解できないかもしれないし、誤った機能として実現するかもしれない。

設計やコーディングの段階でも、ユニットの中にバグが入り込む。制御フローやアルゴリズムにミスがあるかもしれない。データ定義や操作がすべて正しく行われるとは限らない。もっと単純に、タイプミスも避けられない。

完璧にユニットを作成できたとしても、単独で動作するのでなければ、協調動作するユニットとの間で、役割分担や連絡手順などに勘違いがあるかもしれない。それも問題ないとしても、システム内部で資源を取り合う他のユニット群と争いを起こし、動作不良に陥るかもしれない。

このように考えて、バグを次のように分類してみた:

1)仕様ミス:　要求仕様の不完全性、矛盾
2)機能バグ:　要求仕様の理解不足、機能実現ミス
3)構造バグ:　制御フローやアルゴリズムの誤り
4)データバグ:　データ構造や操作の誤り
5)コーディングミス:　規約違反や単純ミス
6)インタフェースバグ:　ユニット間の機能分担や手順の誤り
7)システムバグ:　資源や、負荷、タイミングに関するバグ

テストの種類には単体テスト、結合テスト、システムテストがあるが、1から5までのバグは、単体テストの対象であり、単体で取り除くことができる。これらを結合テストとシステムテストで取り除こうとすることは、実に効果的でなく、効率的でもない。

視覚的理解のために、バグの分類図をここに掲載する。

マニフェストは要求仕様書

今週、政権が交代し、新内閣が発足した。新任大臣の発言をきいていて、今までとは違うと感じることは多い。その一つとして、各大臣の発言内容が非常に整合している。目指す方向がばらばらじゃない。その要因は何か？　今までの内閣と何が違うのか？

それはマニフェストの存在だと思う。マニフェストは、新内閣がやるべきことを記述した、いわゆる、要求仕様書である。その内容が全大臣で共有されている。

今回の新内閣には十分な準備期間があった。要求仕様書を作成することができ、その内容を共有することができた。多くのソフトウェア開発プロジェクトでは、この準備期間が短く、要求が明確にされないまま始まり、十分な要求仕様書を作成することなく、多くの開発チームを作って開発を進める。その結果は、多くのプロジェクトでは悲惨である。

政権公約を明確にしていない内閣の姿は、ここ数年、何度も見ている。マニフェストを掲げた内閣が、足並み良く、効率的に進捗すれば、その姿は、ソフト開発でも手本となりうる。

マニフェストを実現できるスキルが必要だが、このマニフェスト政権の成り行きに目を離せない。

池袋からJR抜きで上野へ行くには

最近、電車事故が多い。実際、遭遇することも多い。そのときに的確に判断できるように、以前、迂回ルートを確かめておく必要性を書いたが、先日、それが役に立った。

池袋に着き、上野へ行くため9時25分頃発の山手線に乗換えようとした。15分頃に事故があり、電車が止まっていることを改札を通ってから知らされた。10時に上野を出発する電車に乗らないといけない。隣ホームの埼京線で赤羽に出て、そこから宇都宮線で上野へ行くのが早いか。さあ、どうする？　ここで、以前、迂回ルートを考えていたことを思い出し、iPod touchを取出し、そのメモを確認した。

まずJRの改札を出て、地下鉄丸ノ内線に直行。後楽園で降り、いくつもエスカレータを乗り継いで、大江戸線春日へ。次は、上野御徒町で降り、銀座線上野広小路に乗り換え。ここでの乗り換えは難しくて、最後尾車両に乗っておかなければならない。上野は後一駅先。これで、5分前には乗車できた。

幸い、なじみのある駅ばかりだったので間に合ったが、初体験だと、乗り換えに時間がかかり、こうはうまくいかないことも確かだ。

政治家は上流設計できるか？

組込みソフトの開発においては、上流設計が手薄である。要求分析や基本設計という上流設計を担える人材が少ない。詳細設計をして、具体的にならないと、物事を理解できないし、設計上の決定ができない。特に、ソフト開発の経験の薄い幹部に、その傾向が顕著に見られる。

今回の政権交代では民主党は、脱官僚依存を唱え、政策決定を政治家で行いたいと主張している。政策の詳細設計ができていない段階で、政策の方針や枠組みという上流設計が、およそ政策立案の経験の少ない政治家にできるだろうか？

一つの予想。具体化されないと理解できない政治家が、詳細設計まで踏み込み、官僚に詳細を要求し、細かい議論に明け暮れ、基本設計が時間切れで、内容が薄いままで終了し、政策の具体化、実施の段階で多くの手戻りを起こしてしまう。

もう一つの予想。物作りを知らない政治家が、政策の実施工数やコストを考えず、要望だけで政策の基本設計を終え、無理のある実施を官僚に押しつけ、官僚は政策実施に熱意を失ってしまい、結局は、政策が頓挫する。

もし、政治家が、官僚との分業を理解し、上流設計に押し留まり、上流設計の責務を果たすことができれば、その姿とやり方は、組込みソフト開発にも応用できる。上流設計シフトの参照モデルとなりうる。

今回の政権交代の成否は、組込みソフト開発に光明を投げかけると期待する。

ショルダーかキャリーバッグか

仕事で使うバッグをショルダーからキャリーバッグに変えてみた。2キロを切る新商品が発売され、飛びついてしまった。今までのショルダーが1.5キロ弱だから、500グラム程度しか重くない。

この1ヶ月ほど、キャリーバッグを引いてみて、まず感じることは、歩道はでこぼこが多くて、引きづらい。音がうるさいので、気を遣ってしまう。

もう一つの不便は、バスに乗ったときの置き場所。電車は、混んでいれば困るが、幸い、ラッシュを避けることができる。混んでいなければ、自立できるので、床に置いておくことができ、ショルダーよりは利点が多い。

もう一つ気を遣うことは、乗り換えの時など、人が混んでいる場所では、後ろに引いてはだめで、前に押すようにする。そうしないと、他の人の足にぶつかることが多い。

利点は、バッグを担がないので、膝や腰の負担が小さいように思う。バッグを床に置いておけるので、バッグを持っての行動範囲を広くできる。容積が増えたので、帰り道、土産物を買おうこともできる。

キャリーバッグを仕事で使う必須条件をあげるとしたら、立てたまま中のものを出し入れできることだ。使えない状況は、満員電車と雨の日。これから上着を着るようになると、ショルダーよりキャリーバッグの方が気に入るように思う。

安全要求定義プロセス

機能安全を作り込んだ組込みソフトウェアを開発するため、現在のソフトウェア開発プロセスモデルを、機能安全規格が規定する安全ライフサイクルに整合するように変更することを考える。

まず、新たに安全要求定義というプロセスを追加する。現在のプロセスモデルでは要求定義、アーキテクチャ設計、詳細設計と続くが、安全要求定義は、アーキテクチャ設計と並行して実施する。理由は、安全要求定義でリスクを分析し、そのリスク低減策をアーキテクチャ設計で考え、そのリスク低減策の評価を安全要求定義で行うという手順になるからだ。

次に、要求定義とアーキテクチャ設計は、システムとソフトウェアに分けて行われるから、安全要求定義もシステムとソフトウェアに分かれる。リスク低減策はソフト単独ではなく、システムとして講じられることになるから、システム安全要求定義が主体であり、重要である。

最後に、安全要求定義での実施内容は、リスクアセスメント、リスク低減のための安全機能の規定、リスク低減度合いに対応する設計技法の選択となる。リスクアセスメントはシステム安全要求定義で行い、機能の規定と技法の選択は、ソフトウェア安全要求定義で行う。

組込みソフト開発では、上流の設計、特にシステム設計が弱いが、機能安全を作り込みためには、より一層、組込みソフト技術者にシステム設計の能力が求められる。

なお、新しい開発プロセスモデルと安全要求定義の実施手順を、具体像を描くことができるように、ここに掲載する。

状態遷移図にHAZOP手法を適用

状態遷移図で表現されたソフトウェアの振る舞いに対して、HAZOP手法を用いてリスク評価することを考える。

状態1において事象Xが発生すると、処理Yを実行して状態2へ遷移するとして、この遷移に関するリスクをHAZOP手法を用いて評価する。HAZOPではリスクの洗い出しにガイドワードを適用するから、状態遷移図に対するガイドワードの意味を決めることから始める。7種類のガイドワードは、次のように解釈する:

No:　事象が発生せず、遷移が起きない。
More:　使用せず
Less:　使用せず
As well as:　事象を誤検出して、遷移を起こしてしまう。
Part of:　処理が実行できず、遷移が未完成。
Reverse:　事象が伝達できず、遷移が起きない。
Other than:　別事象を誤認して、遷移を起こしてしまう。

すべての遷移に対して、このガイドワード解釈を適用してリスクを洗い出し、その原因と影響を考え、安全対策を検討する。リスク洗い出しを網羅的に行えることが特徴である。

具体的な感じがつかめるように、ここに参考例を掲載する(まだ不十分かもしれないが)。

ユースケースを網羅するテスト設計

組込みソフトウェアの開発では要求定義プロセスが確立していないので、製品の要求仕様書がないことは多い。システムテストの目的が要求仕様書を満足しているかの確認であるとすれば、このような状況下では、漏れのないシステムテストは期待できない。

テストのために要求仕様書に代わる資料を作成しなければならないが、製品の使い方がわかれば、ユースケース図とユースケースシナリオがその候補となりうる。

ユースケース図が書けたとして、ここから網羅性の高いテストケースにどう辿り着けばよいか？

製品ではユースケースシナリオは、個々のユースケースの操作手順を記述することになる。いくつかの手順から成り、それぞれの手順はいくつかの選択肢に分かれる。つまり、ユースケースシナリオは制御フローで表現できる。したがって、すべての分岐を網羅するように実際のシナリオを作成すれば、それをもとにして網羅性の高いテストケースを作成することができる。

具体的に感じることができるように、ここに簡単な例を載せた。

Webサイトのページ分割

Webサイトに記載される記事は、数ページに分割されていることが多い。見る方にはクリック回数が増え、元に戻る手間を大きくするだけだ。その理由は、転送サイズを大きくしないための配慮と考えていたが、本音は、広告表示回数を大きくしたいだけだろう。

新聞社のサイトでニュースをめくり読みするとき、このページ分割は、特に迷惑である。毎日を例に取ると、ニュースコレクションを開くと、全分野のニュースの見出しを見ることができる(これは便利)。見たいニュースをクリックすると、表示されるのはその記事の一部だけ。もう一度クリックしないと全文を見ることができない。全文を読んでもとのニュースコレクションに戻ろうとしても、一度のクリックでは戻れない。マウスを使っていないときには、一度のショートカットキーで戻れないと、全文を読む気にならなくなる。

毎日ほどではないが、産経も朝日も記事を分割している。分割しない点では、日経と読売が読みやすい。自然と、利用回数はこの2社が多くなる。

一つの記事をページ分割すると、ページビューが増え、広告を読み出す回数は確かに増える。広告掲載単価を上げるには役に立つかもしれない。しかし、そういう小細工は見え見えだ。顧客満足度に目を向けのは、いつのことになるだろう。

ワインセラーの故障

4年間ほど使ったワインセラーが故障した。電源を入れても作動しない。庫内の照明灯がつかない。大型電気製品の故障を経験することが長いことなかったので、どう対処すればいいのか、一瞬、呆然としてしまった。

まず、購入時の書類を探してみた。ない。次に、製品に貼ってある表示を読む。製品コードとともに輸入業者の名前が記載されている。この会社名でネット検索。幸い、購入先と思えるサイトに辿り着くことができた。問い合せ先にメールを出し、修理を相談する。

翌日頃、メールで返事が来て、メーカから連絡させたいというので、住所と電話番号を通知。その後、2度くらいそのメーカから留守電が入り、こちらから折り返し電話を入れて、メーカ担当者とコンタクトできた。引き取り修理になり、その費用は1万円だという。廃棄するとしたら、冷蔵庫と同じようにリサイクル費用がかかるそうだ。

それで、修理の詳細をFaxしてもらい、相手先口座に修理代を振り込む。先方から確認の電話が入り、製品を引き取りに来る日を決める。3日後くらいに宅配業者が取りに来た。2週間くらい待たなければならないそうだ。

購入時には買い得と感じたが、修理の間、放置されるワインと手間を考えると、決して安い買い物じゃなかったなと思わざる得ない。

携帯機種変更の手間

メールにはPCを使っているので、携帯電話にはPCメールを転送している。出先で無線LANが使えないとき、USBケーブルで携帯電話をPCに接続し、メールをチェックする。こんな使い方をしているので、携帯電話を買い換えたとき、同じ環境を再現するために手間がかかる。

まず、通信ドライバをインストールしなければならない。携帯電話会社サイトにアクセスし、ドライバファイルをダウンロードし、最初に、USBケーブルをつないだときに表示されるメッセージにしたがって、このファイルを読ませる。これでモデムが追加されるので、前から使っているダイヤルアップ設定でこのモデムを選択する。Ｖｉｓｔａではこの間の操作は楽になった。

次に、携帯メールに添付ファイルまで転送されるので、この自動受信を止める必要がある。携帯でメールの受信を知れば、メール本体はPCで確認するから、パケット代がかさばる添付ファイルは必要ない。この操作は携帯電話のメール設定で行う。これは忘れなければ、操作そのものは簡単。

携帯電話そのものとしても手間はかかり、PCの買い換え同様、携帯電話の買い換えは敬遠されるようになるか。

パケホーダイは得か？

携帯電話を買い換えたとき、ついつい宣伝に惹かれてパケホーダイを申し込んでしまった。しかし、すぐに解約した。

基本料金に含まれる無料通話がパケット通信に適用されなくなった。今まではパケット通信は無料通話の範囲に収まっていたのに、パケホーダイの従量制が適用され、追加で料金が発生してしまった。

電話もパケットも、無料通話の範囲に収まっていれば、パケホーダイは得にならない。通信料が増えたら、基本料金を増やし、無料通話量を増やす方が得だ。基本料金は長期間使用者には半額になるが、パケホーダイにはこの割引がきかない。

電話会社を乗換え、メールやブラウザをたくさん使う人。この層を対象としているのか。