================================================================================
8/26 8:50〜10:30
チュートリアル１
セッションS2-1-1:「組込みソフトウェアの信頼性を向上させる方法」
講師: 二上 貴夫（SESSAME／東陽テクニカ）
席数 ：約100席
参加者：約80名
================================================================================
プログラム：
本講演では、
１．いろいろな知恵と作戦
２．信頼性を上げるための美学
３．いろいろな信頼性のための考え方
４．信頼性検証
に関して講演を行う。
信頼性：
・まず、ソフトウェアを離れて信頼性とは？
相手を信用したら応えてくれた/裏切られた
・どうしてか？
優れていたから/徳不足だったから
信頼性とは約束したことをやってくれる程度のものである。
約束の確かさとは、一意性、無矛盾性のこと。
では、コンピュータとソフトウェアをどうやって信頼できるものにするか？
”信頼性”のスコープ：
・信頼性は品質特性の一面である。
安全性、信頼性、保守性、可用性など。
・信頼性の崩れは全ての領域で発生する。
実行、コンパイル、プログラム、設計、要求など、ありとあらゆる場面で発生。
完璧な設計したから、完璧なプログラムが出来るというのはほんの一部に過ぎない。
ソフトの信頼性確保に役立つ考え：
・製品ライフサイクルでの信頼性
たくさんの事象から次に起こる事象を考える必要がある。
絶対大丈夫、絶対起こらないというのはない。
・企画／開発中
工学技術からのアプローチで、削っても良いという肉をドンドン削る。
・利用中
答えを多数決で決定する。
failを予測するようなソフトウェアがある。
外部の事象から自分をチェックする。
・支援中
ビジネス講座の世界で考える。
色々な局面、理論的、工学的、ビジネス的にありとあらゆる面で評価してみる。
開発工程での信頼性原理：
・客体視の原理
‐ある工程の信頼度が高ければ、次の工程での障害は小さくなる。
‐ヒューマンエラーは必ず起こる。
ミスは無くせない。ゼロにはならない。
例：失業率（どんなに産業が発展してもゼロにならない）
いいソフトを作ろうと思えば思うほどミスが起こりやすい。
大勢で作ろう、考えようとすると、必ずミスが存在する。（お互いに依存症）
・主体視の原理
‐複雑になるほど信頼度は下がる（ＫＩＳＳの法則）
初めてのものでいいものを作りたい
→モチベーション的には十分だが、構成は複雑になりがちである。
‐工学ルールの適用限界が信頼度を脅かす
ソフト屋は理想化、抽象化する。細かいところに目を奪われずに、
大事な骨子をアブストラクトすることが大切。
客体視からの対策：
・どの工程（プロセス）のどの作業であってもplan/do/seeのサイクルを回す
何をやるにも考え、実行して、検証を行うことが大切。
・ドキュメントやモデル、コードを検証する
reviewを行ったほうが５倍ほど品質（信頼度）が上がる。
特に、少人数でやっているところほどreviewしたほうが良い。
rehearsal, preparationは設計上大切、本格的な活動の前に準備をするべき。
これらの行為は、ソフトウェア開発ではあまり行われていないのが現状。
・いろいろな観点で標準化を推進する
チーム、会社、業界のスタンダードなど、標準化が究極のチェックシートとなる。
主体視からの対策：
・ソフトウェア分析や設計技術によって簡潔な成果物をつくる
ソースコードだけでなく、仕様書のテストのカバレッジ（範囲）を上げるべき。
特に組込みの世界では、専門家が専門のものを作っているのでできるはず。
・テスト技術の適用範囲を拡大して最適なテストを実施する
・ターゲットドメイン知識とソフトウェア知識のブリッジ技術を向上させる
ドメイン知識とソフトウェア知識をブリッジさせる。
今日の参照例題：
・風圧に比例して伸びるバネがある
ｌ（バネの長さ）＝ｃ（係数）Ｘｐ（風圧）＋Ｌ（バネの自然長）
この伸びから風圧を求める装置を作成する。
信頼性のための工程作戦：
・工程
‐ｎバージョン開発、ウォーターフォール
ｎバージョン：ある仕様書から行動に至る開発チームを２つ以上用意する。
隔離して開発し、結果を実行して見比べる→答えが異なったら失敗。
ウォーターフォール：得られる信頼性は一番高いが、コストがかかる。
・検証
‐レビュー、オーディット、インスペクション
実用的にはあまり明文化されていない。
・モデリング
ソフト設計者が孤独を感じるには一番のもの。
‐プロトタイプ
‐シミュレーション
・テスト
信頼性のための分析：
・一般的な文章による仕様について適切なモデリングで信頼性を上げる技術のこと
‐利用 →ユースケースモデル
‐データ加工 →データフローモデル
‐時間的なやり取り →シーケンスモデル
時間の観測の信頼性確保は上手く解決できていない。
‐関係と記憶 →ＥＲモデル
百数十万行以上の携帯のソースのうち、半分以上が関係とデータである。
（処理は３０万行くらい、コメントは２割くらい）
実態と関連のモデル化。
‐手続き →アクティビティモデル
‐機能構造 →ファンクションモデル
‐並列、多体 →クラスモデル
intの平均値を取る関数→floatの平均値→intoとfloatの平均値
言われたままに作るのは面倒…ＯＯＰを利用する。
高信頼性分析 クラス分析：
・バネの長さ獲得と出力のモデルを複数の視点でモデリングする。
測定場所によって、ＣやＬの値が違う→クラス分析の出番。
高信頼性分析 ライフサイクル分析：
離散密度は忘れがちである。
過去の値との相互作用を考えなければならない。
（以前の自分自身に関係して計算をする必要がある場合）
基本設計のミスというよりも欠如だと言える。
信頼性のための設計：
・分析で利用したモデルを設計の立場で再利用する
・新規に設計として呼び出し、参照モデルを加える
・実装環境との整合をとり、テスト設計する
人の生死、特に輸送系に関わる場合によく考えられている。
高信頼設計 パーフェクト型：
・仕様をしっかりと決めれば完璧なはず
・しかし、理念と現実は、普通は一致しない
‐突かれない盾を作れ／絶対貫通できる矛を作れ
‐落ちない飛行機を作れ
理念：ｌ＝ｃＸｐ＋Ｌ
現実：ｐ＝（ｌ−ＬＥＮ）/ｃ
仕様書はある種の理念で書かれている。そこから、差が出ることを心得た上で、
完璧なウォーターフォール設計することは信頼性の獲得に役立つ。
高信頼設計 フェールセーフ型：
・複数の機能主体が働けるようにして単体の崩壊をカバーする
・ただし、全部の保証が飛んでしまえばアウト
完璧であるということはありえない。
高信頼設計 ソフトランディング型：
・01ルール v.s. 0.0-1.0ルール
‐システムの可用度が徐々に下がると…
変化に気づく機会が得られる。
性能犠牲でも結果は出せる。
マージン０の設計では採用できない。
信頼性設計のためには大事。例えば、アルゴリズムの中に
自分自身のＣＲＣチェックを入れるなど、自分自身を診断するという
信頼性設計を行う。
高信頼設計 ハイジーン型：
・衛生学的な考え方で、多くの視点から提案される手段について、
試行と効果測定を繰り返して信頼性を上げる
・ポータビリティ設計、インクルード設計、レイヤーモデル設計などがある
信頼性のための実装：
・言語は信頼性の権化ではない
‐Ｃ言語は、信頼性の多くをコンパイラ実装とアプリ実装に依存している。
・ＡＳＰＥＣＴとしての信頼性を常に意識すること
あるものの見方、信頼性のＡＳＰＥＣＴとして常に意識する。
・可変量・可動性と普遍量・不動性の按配
設計段階でどこが普遍量、どこが可変量かをきちんと設定すること。
ポインタをconstで扱うなど
・柔軟性と信頼性の相克を知ること
柔軟性要求に答えすぎた結果、信頼性を失ってしまった。
良かれと思ってやったら裏目になった例。
ファンクションポインタを使ったコードの信頼性は高いか？
・工程と固める時期のモデル 例外処理
高信頼性実装 testability：
テストデータはConfiguration Managementである。
信頼性を高いものに持っていくには、前のバージョンを使って検証することが大切。
全てのフォルダにはテスト用のmakeが入っていても良いくらいである。
高信頼性実装 domain separation：
飛行船の例（非常に高い信頼性で設計される）
ドメインの分割、設計で分かれてても、実装では一緒になっては意味が無い。
高信頼性実装 domai separation 2：
・ドメインの接続は.hで
tyepdefを使う。
信頼性のためのＰＤＳ：
・いつでも、考え/実行し/振り返ることが大切
要求文書を見直す。一つ見直して安心しない。ＰＤＳは無限に続くものである。
信頼性と安全性：
信頼性と安全性は別のものである。
ソフトウェア信頼性の先に安全性がある！
検証の道具と方法：
・道具を使えば信頼性は上がる
目、耳、口、頭
紙、鉛筆、消しゴム
表、ワープロ、ドローツール
ＩＣＥ、リバース、静的テスト、カバレッジテスト
１つの検証方法：
・ありとあらゆるレビューをおこなって、審査官の判断に任せる方法（陪審員制度など）
→ある意味では合理的