• 戻る（高度午前 - 開発技術）

システム開発技術

個人情報が適切に取り扱われるよう考慮したシステム設計をすること。

• INVEST（インベスト）
  ユーザー・ストーリーの評価の６つの観点

  • Independent（独立している。）
    ユーザー・ストーリーが独立しており、任意の順序で作業できる。
    先行するストーリーが完了してないと始められない、など他の影響を受けない。

  • Negotiable（交渉可能である。）
    ストーリーが具体的なタスクに落ちすぎておらず、
    顧客やプロダクトオーナーとプログラマが協働して実現方法を決められる。

  • Valuable（価値がある。）
    ストーリー単独で顧客にとっての価値があること。

  • Estimatable（見積もり可能である。）
    ストーリーを実現するのにかかる時間が見積もり可能である。
    （他ストーリーとの相対時間は）優先順位を決めるのに役立つ。

  • Sized Right (Small)（適切な大きさである。）
    小さく適正でスコープを把握し易い。

  • Testable（テスト可能である。）
    そのストーリーが完了したかどうかをテストできること。
    受け入れ条件が明確になっていること。

• 高度午前 - システム戦略の該当節を参照。

共通フレーム 2013 JIS X 0160:2012のシステム開発におけるテスト

※ Vモデル的な。

デマルコが提唱したシステム開発プロジェクトのライフサイクル

　　　　　　　　　　←予算・スケジュール┐┌物理的要求→（ハード調査）──ハード───┐
　　　　　　　　　　　　　　　　　　　　↑↑　　　　　　　　│　　　　　　　　　　　　↓
→ユーザの要求→（調査）→フィジスタ→（構造化分析）　　　　　│システム　　　　　（システム開発）→システム
　　　　　　　　　　　　　　　　　　　　↑↓　　　　　　　　↓構成データ　　　　　　　↑
　　　　　　　　　───→ユーザの要求┘└構造化仕様書→（構造化設計）─設計・テスト┘

• トップダウン・アプローチ
  企業の情報戦略に基づきTO-BEを検討しつつ論理データモデル作成

• ボトムアップ・アプローチ
  AS-ISを集めつつ改善を加え論理データモデル作成

• 最終的に、
  業務に必要な属性を備えた正規化された論理データモデル
  が作成されるのは、トップダウンでもボトムアップでも同じ。

• 構造化分析設計読んだ方がイイ。

• 子プロセスは親プロセスと入出力の数が同じである必要がある。

• DFDの書き方は簡単だが、以下の様なプロセスは記法に誤りがある。

  • データの入力が無い
  • データの出力が無い

• UMLを齧っておいた方がイイ。

• クラスの書き方

  • 上から

    • クラス名
    • プロパティ一覧
    • メソッド一覧

  • 一覧の可視性

    • （＋）：Public
    • （－）：Private
    • （＃）：Protected
    • （～）：Package(internal)

• クラス図の書き方
  関係の書き方はER図ライクだが、
  データの関連に留まらず、以下の点が異なる。

  • インスタンスレベルの関係

    • リンク
      オブジェクトのインスタンス間の関係
    • 関連
      オブジェクトの参照
    • 集約
      データの関係で部分を表す。
    • コンポジション
      集約と同じだが、部分の共有が不可能である点が異なる。

  • クラスレベルの関係

    • 汎化・特化
      クラスの継承関係
    • 実現
      抽象クラスやインターフェイスの利用

  • 一般的な関係

    • 依存
      インスタンスへの変更が、他のインスタンスへ影響を与えることを示す。
    • 多重度
      ER図と同じだが、データだけでなく参照の多重度でもある。

• 各種、UML図（UMLのダイアグラム）

  • 構造図

    • クラス図
    • オブジェクト図
    • コンポーネント図
    • パッケージ図
    • 配置図
    • 複合構造図

  • 振る舞い図

    • ユースケース図
    • アクティビティ図（フローチャート
    • ステートマシン図（状態遷移図

  • 相互作用図

    • シーケンス図
    • コミュニケーション図（コラボレーション図）
    • 相互作用概要図
    • タイミング図

• エンティティのライフサイクル分析
• 機能の過不足を確認できる（例えば、削除機能が無いなど）。

• SysML : Systems Modeling Language

• システムズエンジニアリングのためのドメイン固有モデリング言語。

• (UML)のサブセットにUMLのプロファイル機構を使って拡張したもの

• 各種システムやSoSの仕様記述、分析、設計、検証、評価に使う。

• SoS (System of System)
  複数のシステムを組み合わせて全体で一つとして利用者に提供されるシステム

• 特徴

  • パラメトリック図を使用して、
    システムの要素間のパラメタについて、
    その制約条件を数式で表現すると言った事が可能。

  • アクティビティ図を使用して、
    連接、反復、選択の記述パターンで処理の流れを視覚化する。

  • 内部ブロック図を使用して、
    ソフトウェア構造を視覚化する。

JIS X 25010:2013 で定義されており、以下のものがあるが、

• 機能適合性
• 性能効率性
• 使用性
• 信頼性
• 保守性

• コンポーネントベース＆イベント・ドリブン
  １画面１モジュール、複数イベント・ハンドラとカッチリ決まる。

  • コンポーネント

    • View（画面）
    • Codebehind（イベント・ハンドラ）
    • 業務ロジック、データアクセス

  • フレームワーク

    • JSF
    • Web Forms
    • Windows Forms

• MVC
  Controllerをデータに対応させるか、
  画面に対応させるか。自由度が高い。

  • コンポーネント

    • Model
      Model → ViewModel(POJO, POCO)
      業務ロジック、データアクセス、引数・戻り値

    • View

    • Controller

  • フレームワーク

    • Struts
    • Spring MVC
    • ASP.NET MVC

• 分割技法
  業務系は、業務側がSTS分割（縦）＋TR分割（横）、
  基盤側が、共通機能分割みたいな感じで設計してるな...。

  • データの流れに着目

    • STS分割
      Source（入力）、Transform（変換）、Sink（出力）
      と、DFDと親和性の高そうなモジュール分割技法

    • TR分割
      トランザクション単位にモジュール分割する。
      トランザクションごとの処理が異なる場合に適する。

  • データの構造に着目

    • ジャクソン法
      入出力データの構造に着目して機能分割を行う方法の1つ。
      入力データの構造と出力データの構造の関係からプログラムの構造を導き出す。

    • ワーニエ法
      入出力データの構造に着目して機能分割を行う方法の1つ。
      モジュールと言うより、データ処理の制御構造をプログラム構造に反映させる。

• 結合度の評価尺度
  結合度の低い順（結合度は低い程、良い）

  • データ結合（引数）
  • スタンプ結合（構造体引数）
  • 制御結合（制御に関する引数）
  • 外部結合（グローバル変数）
  • 共通結合（グローバル構造体）
  • 内容結合（内部データを参照...言語的にはサポートされていない）

• 強度の評価尺度
  強度の高い順（強度は高い程、良い）

  • 情報的強度（データでまとめたインスタンス・メソッド）
  • 機能的強度（１つの機能を実現するためのクラス、メソッド。）
  • 連絡的強度（逐次的であることは問題、業務、データ、機能に関連している）
  • 手順的強度（手順的であることは問題、業務に関連しているタメ）
  • 時間的強度（時間的であることは何かしら関係がある可能性がある）
  • 論理的強度（類似機能をまとめたスタティック・メソッド的な）
  • 暗号的強度（定義不可なまとまり）

• デザイン・パターン

多くの場合、レビューはインスペクションを指す。

• インスペクション

  • 責任のあるプロジェクトメンバー以外の第三者が参加し、
    評価基準に基づいて仕様書やソースコードなどの成果物に
    潜在的な不具合や問題点がないかを検証する会議。
  • 以下が、他のレビュー手法と比べて特徴的。
    • 責任者としてモデレーターが任命され、インスペクション作業全体を統括する
    • 検出した欠陥をログに保管し、修正が行われたことを追跡調査する

• ウォークスルー

  • レビューを希望する成果物の作成者が、チーム内で、
    必要な数のレビューアを招集し、成果物の内容を説明する。
  • 元来は、プログラムの机上チェックで、これがドキュメントチェックに拡張された。
  • 第三者が参加しない非公式な打ち合わせで、ピアレビューの同義語としても使われる。

• ラウンドロビン・レビュー

  • レビュー会議の参加者が説明や発言を持ち回りで行う方法。
  • 参加者の専門性のレベルが同程度のときに有効とされる。

• プロトタイピング
  レビューを減らすことはできるが、
  観点の異なる専門家を招いたレビューの実施等は必要。

• C言語 > MISRA-C :自動車産業関連

• 参考

  • 各プログラミング言語のコーディング規約まとめ - Qiita
    https://qiita.com/moaible/items/134329123074337913fb

• スレッドのスタック

• マイコンのデバッグ
  どうも基板上に乗せるマイコン・コンポーネントの
  デバッグ（電子回路の検査）を行うコンテキストらしい。
  マイコンのデバッグはオシロスコープやロジックアナライザといった
  「針(プローブ)」の測定器を使うことで回路上の信号を測定して行う。

  • ICE（インサーキット・エミュレータ）

    • これまではICEが広く用いられてきた。
    • ICEはマイコン（MPU）のエミュレータ
    • ICEを基板上に乗せて回路上の信号を測定。

  • バウンダリスキャンテスト（BST）

    • マイコン（MPU）の小型化・集積化で回路上の信号を測定が難しくなってきた。

    • ICの端子に埋め込まれた「テスト用回路」を使って、ICの端子の状態を調べたり、
      入出力する値を変更するBS技術が開発され、これがテストに応用され始めた（BST）。

    • 日本では、ディジタルのI/Oしか検査しかできなかったため流行らなかったとされる。
      海外では、エンドユーザ主導で、効率良くBSTできるソリューションが提供されている。

• 静的テスト / 動的テスト

• ホワイトボックス・テスト
  カバレッジ(網羅率)分析

• ブラックボックス・テスト
  限界値（境界値）分析、同値分割

• ボトムアップ・テスト

• トップダウン・テスト

• ドライバ / スタブ、
  検査/ 被検査モジュール（テスト対象）

• 図表を用いたテスト

  • 決定表（ディシジョン・テーブル）
  • 状態遷移図

• 経験ベースのテスト技法

  • 概要

    • テストの効果がテスト担当者のスキルや経験に大きく依存

    • 仕様ベース・構造ベースの体系的なテスト技法でテストケースを設計し、
      その後、それを補うために経験ベースのテスト技法を用いるのが有効。

  • エラー推測テスト技法

    • ホワイトボックスを想定し攻めるので
      限界値（境界値）以上の欠陥を発見できる。
    • ゼロ除算、ヌルポ、うるう年など。

  • 探索的テスト技法

    • システムの動作をみて、臨機応変にテストをおこなう高レベルなテスト
    • 探索的にエラー発生の可能性の高いテストを設計　→　実行　→　記録して行く。

• ISO 26262（自動車分野の機能安全規格）で定義されるテスト指標

  • C0（命令網羅）
    通過したステップ

  • C1（分岐網羅）
    通過した分岐

  • C2（条件網羅）
    通過した分岐の組合せ（≒条件）

  • その他

    • 経路網羅
    • 入口/出口網羅

  • RC0（差分 命令網羅）
    修正後、通過したステップ

  • RC1（差分 分岐網羅）
    修正後、通過した分岐

  • RC2（差分 条件網羅）
    修正後、通過した分岐の組合せ（≒条件）

  RC0対応ツールを触った感じ、ステップや分岐を修正すると、
  対応するコード、コード・ブロックのカバレッジがクリアされる感じだった。

• ソート処理のカバレッジ率を上げるテストデータの問題
  挿入個所に、右端 / 中間 / 左端 が登場するデータセットを選択。

少ないテスト回数でより広い範囲をカバーするためのテストケース作成手法

• 限界値（境界値）分析

  • 出力が同じになるような入力をそれぞれグループにまとめ、
    グループが隣接する境界付近の値を入力としてテストを行なう方式。

  • 出力が変化する境界付近では条件式の記述ミスや設計書の解釈の誤り
    などによりバグが頻発するため、その付近の値を重点的に調べる。

• 同値分割
  出力が同値となるグループの中から
  適当に選んだ代表をテストデータとして取り上げる手法。

単体テスト用の検査モジュール

• 被検査モジュール（テスト対象）

• 検査モジュール

  • ドライバ
    下位の被検査モジュール（テスト対象）を呼び出す上位モジュール。

  • スタブ
    上位の被検査モジュール（テスト対象）からを呼び出される下位モジュール。

真面目に計算しないと間違う。

• 100個のバグを埋め込んだ。

• 30個のバグが抽出された。

  • 10/xの潜在バグが抽出された。
  • 20/100の埋込バグが抽出された。

• 潜在 / 残存バグの推定

  • x = 潜在バグ

    x = 10 * 100/20 = 50個
    

  • y = 残存バグ = 潜在バグ - 抽出された潜在バグ

    y = x - 10 = 40個
    

• 設問
  500個の出荷に対して全数検査を行った場合。

  • 全数検査しない場合の故障品発生率：3%

  • 全数検査した場合の、

    • 検査時の故障発生率：2%
    • 出荷後の故障発生率：1%

  • 各種コスト

    • 検査コスト：1万/個
    • 出荷前の修理費：50万/個
    • 出荷後の修理費：200万/個

• 計算

  • 全数検査しない場合

    200万/個 * (500 * 0.03) = 3000万
    

  • 全数検査した場合

    1000 + 500 + 500 = 2000万
    

    • 全数検査費用

      1 * 500 = 500 万
      

    • 出荷前の修理費

      50万/個 * (500 * 0.02) = 500万
      

    • 出荷後の修理費

      200万/個 * (500 * 0.01) = 1000万
      

カークパトリックモデルの四段階評価

• レベル1：Reaction（反応）
  受講直後のアンケート調査などによる
  学習者の研修に対する満足度の評価

• レベル2：Learning（学習）
  筆記試験やレポート等による
  学習者の学習到達度の評価

• レベル3：Behavior（行動）
  学習者自身へのインタビューや
  他者評価による行動変容の評価

• レベル4：Results（業績）
  研修受講による学習者や職場の
  業績向上度合いの評価

• 国際電気標準会議（IEC）の国際規格。

  • FTA (Fault Tree Analysis)

    • フォルトツリー解析、故障木解析
    • 故障・事故のトップダウン分析手法
    • 発生頻度の分析のために、原因の潜在的な危険を論理的にたどり、
      それぞれの発生確率を加算し、基本的な事象が起こりうる確率を算出。

  • FMEA (Failure Mode and Effect Analysis)

    • 故障モードとその影響の解析
    • 故障・不具合の防止を目的とし、設計の不完全や潜在的な欠点を見出すために
      構成要素の故障モードとその上位アイテムへの影響を解析するボトムアップ手法

  • HAZOP（Hazard and Operability Study）

    • 化学工業，原子力，製鉄などのプラントで，事故などの原因が，
      原料，材料，燃料などの気体・液体の流量の調整との関係で，電磁バルブの所で
      分析すると効率がよいという経験則から一般化した方式として用いるようになった。
    • セーフテイ・アセスメントのプロセス安全性評価(第4段階)において、
      ・第3段階の危険度ランクが I : FTA、FMEA、HAZOP手法等により、
      ・第3段階の危険度ランクが II : What-if手法
      （PMP：計画 - 時間の該当節を参照）等により、
      潜在危険の洗い出しを行い、妥当な安全対策を決定する。

  • デザインレビュー
    ...。

• その他

  • 5W1H（PMP：計画 - リスクの該当節を参照）
  • パレート図（統計解析の該当節を参照）

移行メモ

• INVEST の「Negotiatable」→「Negotiable」に正した。
• 「全数検査の問題」で「出荷前の修理費：50万/個」と 「出荷前の修理費：200万/個」が同名になっていたが、 前提の「出荷後の故障発生率：1%」と計算式の対応から、 後者を「出荷後の修理費：200万/個」に正した（計算の見出しも同様）。
• 元 Wiki の結合セル（>）を含む表は、GitHub Wiki では再現できないため、 セルの内容を展開して平坦な表にした（システム開発におけるテストの 6 行目）。
• 元 Wiki の行頭空白による図・式は、フェンス付きコードブロックにした （デマルコのライフサイクル図、エラー埋め込み法・全数検査の計算）。
• &color(red){...}; による強調は太字にした。
• 元 Wiki で見出しそのものが他ページへのリンクになっていた箇所 （「機能・非機能、利用者要件」「デザイン・パターン」「スタック関連」）は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
• マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への URL リンクは、移行済みの デザイン・パターン / スレッドのスタック に張り替えた。
• PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
• 未移行のページはファイル名を予約し、TODO.md に記録した。

Tags: 移行, 資格, 高度午前, 開発技術, システム開発技術, INVEST, Vモデル, DFD, UML, SysML, 品質特性, MVC, モジュール分割, 結合度, 強度, レビュー, カバレッジ, 境界値分析, ドライバ, スタブ, FTA, FMEA, HAZOP