なみひらブログ

学んだことを日々記録する。~ since 2012/06/24 ~

「第14回クリティカルソフトウェアワークショップ (14thWOCS2)」に行ってきました(1日目)

最近品質評価あたりを担当していて、勤め先から参加の勧めがあったので参加してきました。
http://www.ipa.go.jp/sec/events/20161212.html

開催概要

セッションメモ

Challenges of Safety Critical Software Development

  • 以前ボーイングの働いていた人。戦闘機の開発経験。
  • 今は信頼性向上などのコンサル業。
  • 安全なソフトウェアをどうつくるかという話。
  • 安全なソフトウェアとは、以下。
    • 意図した機能を満たしながらも、人命や設備機能、大きな経済損失がないことを保証するソフトウェア。
    • 意図しない機能がないソフトウェア。
  • 複雑と付き合うか。
    • マルチコアのCPUの利用範囲が増えてきた。
  • リスク管理の最終的な目標は、コストとスケジュールの節約に対してどのレベルまでのリスクを許容できるかを判断すること
  • 航空機の開発とかでも、アジャイル的な開発が行われ始めている。
  • 所感
    • 内容的には一般的なソフトウェア品質の話に近くて、"Safe(安全)"感が少し弱かった(;´Д`)
    • 内容が抽象度が高めで、「実際どう開発すればいいの?(´・ω・`)」となった。

自動運転を想定した自動車の安全度水準と電子制御の課題

  • 自動車の自動運転実現に向けて、安全の保証・冗長化について。
  • ISO 26262で自動車向けの機能安全規格を定義している。
  • 共通原因故障
    • 1つのバグで、冗長システムを含め、システムを故障になる事象。
  • 対策の思想
    • 異種冗長
    • 同種冗長
  • 対策
    • 多様化設計
    • 分離設計
  • 障害の共通原因故障の比率によっては、大きくシステム稼働率が下がることがある。
  • マイクロソフトは、AIなどのシステムの位置づけを、人間のシステム置き換えではなく、拡張という方針を言っているらしい。
  • あとで調べる
    • βファクタ法
  • 所感
    • 自動運転を導入としていたが、システムの冗長性に関する話で視点が広がった。
      • これまでは、冗長性というと同種冗長しか意識していなかった(;´Д`)

安全性評価に基づくE/Eアーキテクチャ評価手法

  • アーキテクチャの安全性評価のコスト削減の研究。
    • SBAE(Safety-based architecture evaluation method)
  • アーキテクチャの比較評価を定量的にできるようになった。
    • これまでは定性的なものだった。
    • 他の案がでてきたときなど。
  • 論理設計、物理設計に対して評価を行う。
    • 処理を続行できるか。シナリオ上の単一障害点がないか?
  • 安全性評価OKだったアーキテクチャだけ定量評価をする。
  • 安全性評価の観点は以下。
    • 配置性妥当性
    • 独立性
    • 機能連携性
  • アーキテクチャを書く際に使ったツール
  • 所感

ソフトウェアの受け入れテストに対するゴール構造化表記法を用いた効率化の取り組み

  • 受け入れテストに関する課題
    • 表現力、妥当性
  • フローチャート(+観点、知識や知見)から、ゴール構造化記法(GSN)を自動生成する仕組みツール。astahベース。
  • 今後Cucumberと連携してテスト実行を連携する仕組みを検討する予定。
  • 所感
    • 身の回りだとastahを使っている人が多いので、astahがGNS関連の機能拡張をやってもらうと展開が楽になりそう。

お客様利用環境シミュレーションテストによる信頼性向上

  • ゼロックスでの複合機の評価をやっている人。
  • 複合機でのお客様視点(お客様環境)を重視したテスト手法の紹介。
  • お客様同等の環境・使い方
  • 環境は、最も利用されている形態を製品DBから参照。
  • 使い方は、各機器の状態遷移でマトリクスを作って、重み付けを行って高いものを抽出して実施対象にしている。
  • 環境には、他社機も想定して構築している。
  • 所感
    • いろいろな環境を考慮すると結構費用がかかりそう。自動化されたテスト実行のフレームワークが存在しそう。

データセンターにおけるITオペレーションの業務品質向上を達成した改善事例

  • 手作業の管理の限界、運用品質低下。
  • ドキュメントバラバラ→ドキュメント標準
  • 誰かがやっている→責任・作業者の明確化。
  • みんながみるポータルを作った。改善案もそこに投稿できるようにして、効果があった。
  • 所感
    • 現状業務がいっぱいいっぱいの状態で、改善サイクルを回せるようになったのがすごい。良い「仕組み」と「文化」が形成できるかが鍵。

JAXAの事例にみる実施価値に基づくソフトウェア保証手法:VBSA

  • VBSA : Value Based Software Architecture
    • 既存の標準があったときに、それを暗黙的に採用するのではなく、プロジェクト特性にあった必要分だけ(コストの最適化)取捨選択しするための論理フレームワーク
    • Value Chain Model(今回はこっちだけ)
    • Decision Model
  • 効果
    • 価値に基づく指摘・提案
    • 標準の見直し。
    • 教育。属人性の排除。
  • モデルに当てはめる前に、考えをまとめる必要がある。
  • 所感
    • 一つ一つのプロセスについて懐疑的にやるのも大変なので、最初はスコープを絞ったほうがよさそう。

所感

  • 品質保証関係の勉強会(ワークショップ)は初めてだったので新鮮でした。
  • 実践例もあったが、ツール・実作業などの詳細までは出てこなかったので実際の適用作業のイメージがつかなかった(;´Д`)
  • プロダクト評価にかぎらず、何か(評価、プロセスなどなど)を評価してその結果には論理的な説明が必要。業界全体としてそのフレームワークの確立を目指している感じ。

まとめ

ロジカルシンキング苦手(;´Д`;)