拾って落とすエンジニア活動ログ

各種技術や周辺知識のTIPS、振り返り

初級ソフトウェア品質技術者のシラバスから用語まとめ(3章)

初級ソフトウェア品質技術者の資格試験のシラバスVer2.0から第3章分のメモです。

 

第1章はこちらです。

初級ソフトウェア品質技術者のシラバスから用語まとめ(1章) - 拾って落とすエンジニア活動ログ

 

 第2章はこちらです。

初級ソフトウェア品質技術者のシラバスから用語まとめ(2章) - 拾って落とすエンジニア活動ログ

 

SQuBOKを見ていると、この技法は仕事でつかえそうじゃないか?ググるか・・と思う瞬間もありつつ、今週末試験だしメモだけして次行くぞ、やたら分厚い3章に進みます。

 

3ソフトウェア品質技術

<工程に共通なソフトウェア品質技術>

3.1メトリクス
3.1.1測定理論
  • メトリクス:定義された測定方法及び測定量
  • 測定理論:ソフトウェアの品質測定として、種々の国際規格で整理されている測定と評価に関する主要な概念や理論のこと。
  • 定量:測定の結果として値が割り当てられる変数。
  • 基本測定量:単一の属性とそれを定量化するための方法とで定義した測定量
  • 導出測定量:複数の基本測定量の値の関数として定義した測定量
  • 指標:定義された情報ニーズに関するモデルから導出した特定の属性の見積もりまたは評価を示す測定量
  • 尺度:連続的もしくは離散的な値の順序集合または分類の集合で、それに属性を対応付けるもの
  • 名義尺度:順序のない質的変数の測定値を分類するための尺度。OSの種類など
  • 順序尺度:順序のある質的変数の測定値を分類するための尺度。障害の重大度の度合いなど。
  • 間隔尺度:数値間の等間隔性が保証された量的変数の測定値に対応する尺度。加減算を適用できる。気温、テストの点数など
  • 比率尺度:数値間の等間隔性が保証された量的変数で、ゼロという値が属性の量がないことを表す尺度。四則演算が適用できる。身長、体重など
  • 評定水準:順序尺度上の点のことで、測定尺度を分類するために使用される。あるメトリクスを用いて得られた測定値を優良可に分類するなど。
  • 測定プロセス:メトリクスを実際に計測するプロセス。
  • GQM手法:Goal-Question-Metrics手法。ある対象項目に関する任意のメトリクスを、トップダウン方式で決定するための手法。方法(1)組織の方針や戦略に基づき具体的な目標を設定する。(2)目標に対する現在の状況や変化などについて定量的に回答可能な質問を決定する。(3)質問に答えるメトリックを導出する。
3.1.2プロダクトメトリクス
  • プロダクトメトリクス:ソフトウェア製品そのものやソフトウェアの振る舞いなどにおける属性を測定する方法の集合
  • 内部メトリクス:ソフトウェア製品を動作させずにそのものの属性を静的に測定するメトリクス。内部を見て初めてわかる属性のメトリクス。仕様書など製品の中間生産物の測定に利用する。
  • 外部メトリクス:製品を試験実行して振る舞いを測定するメトリクス。テストまたは運用期間中に、実行可能なソフトウェアまたはシステムを実行し、操作し、観察することによって測定する。
  • 利用時の品質メトリクス:特定の利用者が特定の利用状況において、有効性、効率性、リスク回避性および満足性に関して特定の目標を達成するためのニーズを満たすために、製品またはシステムを利用できる度合い。
  • 複雑度のメトリクス:開発・理解・保守がどの程度困難かを数値で示し、品質を予測するメトリクス。規模が大きい、アルゴリズムが複雑、条件分岐が多い、構造が複雑などだと複雑度が上がる。
  • LOC(Lines of Code):ソースコード行数。品質評価に用いる場合は、コメント行を含まない新規に追加した行数+改変した行数を規模として扱う場合が多い。
  • ファンクションポイント:ソフトウェアの機能を点数付けした規模のメトリクス。ファンクションポイントを用いてソフトウェアの規模を測定する方法をファンクションポイント法と呼び、IFPUG法は最も多く使われている。IFPUG法では、ファンクション(機能)として計測する要素ごとに機能を抽出する。外部入力、外部出力、外部照会、内部論理ファイル、外部インターフェースファイルの5種類の機能種別がある。それぞれの機能について複雑さをもとに重みづけを行って合計するとファンクションポイントが出る。
3.1.3プロセスメトリクス
  • プロセスメトリクス:開発プロセスの主に品質にかかわる属性を測定する方法の集合。プロセスの効率性や生産性、安定性などはソフトウェア品質に大きな影響を及ぼす。またプロセスメトリクスからプロダクトの品質をある程度予測することができる。
3.2モデル化の技法
3.2.1離散系のモデル化技法
  • UML:ソフトウェアのオブジェクト指向モデリングのための表記法。構造と振る舞いの各側面を目的に応じてかき分けるための複数の図から構成される(構造図(クラス図、パッケージ図、オブジェクト図、コンポジット構造図、配置図、コンポーネント図)、振る舞い図(ユースケース図、アクティビティ図、ステートマシン図、シーケンス図、コミュニケーション図、相互作業概要図、タイミング図)。UMLでモデルを作ることで、コミュニケーションの効率化、レビュー効果の向上、シミュレーション・アニメーションの導入による障害の早期発見の効果がある。
  • SysML:システム全体のモデル化のための表記法であり、要求、構造、振る舞いの各側面について目的に応じてかき分けるための複数の図から構成される。UMLとは異なり、システムをハードウェアやソフトウェアに分割する前の全体的な検討を行うシステムズエンジニアリング領域を対象とする。要求図、構造図(パッケージ図、ブロック定義図、内部ブロック図、パラメトリック図)、振る舞い図(ユースケース図、アクティビティ図、ステートマシン図、シーケンス図)を通じて表現。システムエンジニアリング工程でのコミュニケーション改善、障害の早期発見および手戻りの削減の効果がある。
  • 構造化チャート(PAD):構造化プログラミングの理論に基づいてプログラムのアルゴリズムを構造化するための表記法。プログラムの構造を見えるようにする、製造と検査を系統的にできるようにする、処理するデータの構造をプログラムの構造と同じ記法で表現できるようにする という3つの目的がある。なお、問題分析図ProblemDialogDiagramとは、フローチャートにかわり構造的・階層的な表現ができる構造化チャートのこと。
  • モデル駆動開発(MDD):UMLに基づくモデル化や、モデル変換、あるいはコード生成を実施するツールを利用した開発形態。OMG(Object Management Group)の商標。
  • MBSE(Model-Based System Engineering):要求定義や設計の段階ではSysMLを使い、それ以降の工程ではハード、ソフトの開発領域にあわせた技法を使う。このようなモデルを活用したシステムズエンジニアリングのこと。
3.2.2連続系のモデル化技法
  • MBD(Model-Based Development):対象の振る舞いについて連続的な変化をモデルとして表現し検証やシミュレーション解析を通じて性質を明らかにする、連続系のモデル化およびそれをサポートしたツールを利用した開発形態。
  • MDD(Model-Driven Development):対象の振る舞いを離散的なイベントまたはそれに伴う状態の連なりとしてモデル化する開発形態。
3.2.3ドメイン特化技法
3.3形式手法
  • 形式手法:数理論理学に基づいて仕様記述や検証を行うアプローチ方法の総称。
3.3.1形式仕様記述の技法
  • 形式仕様記述の技法:要求仕様や設計を厳密に記述し、系統的な方法で一定の品質保証を目指す技法。要求仕様や設計を、文法・意味論が厳密に定められた形式言語でモデル化して記述する。形式技法の代表的な技法として、VDM、Event-B、Alloyなどがある。
3.3.2形式検証の技法
  • 形式検証の技法:テストや人手でレビューできないケースに対し、検証すべき性質を与えて検証を行い、高信頼性を保証する技法。特定の状況でのみ顕在化する障害の自動検出や、対象範囲において障害が発生しないことの保証を行う。
  • 不変条件、事前条件、事後条件:システムが状態として保持するデータについて常に成り立つべき条件が不変条件。各関数・操作の実行前に前提として成り立つべき条件が事前条件。実行後に成り立つべき条件が事後条件。

<工程に個別なソフトウェア品質技術>

3.4品質計画の技法
  • 品質計画の技法:品質計画には、品質目標、開発プロセスアーキテクチャ・基準や規約などの計画、レビュー計画・テスト計画・検査計画・監査計画などの個別の計画、評価のための判断基準や収集する指標、それぞれの活動の合否基準、結果として製品が要求事項を満たしていることを実証するために必要な記録を含むとよい。また、潜在的な品質不良のリスクおよびその緩和策について言及するとよい。
  • 費用便益分析:プロジェクトを評価する際に、経済的指標を用いて有形および向けの費用と便益を見積分析する技法。両者のトレードオフを考慮し品質計画を立てる。
  • 品質計画書:品質目標を設定すること、ならびにその品質目標を達成するために必要な運用プロセス及び関連する資源を規定するために作成する計画書。
3.5要求分析の技法
  • 要求分析の技法:要求分析には要求の抽出、分析、仕様化、妥当性確認と評価のそれぞれの活動に技法がある。
  • プロセスパラメータ:使用するプログラミング言語が指定されるなどシステム開発における制約条件のこと。プロセス要求とも呼ばれる。
3.5.1要求抽出
  • 要求抽出:ステークホルダーが意識している要求を獲得して収集するだけでなく、意識していない要求を発見し引き出す活動または技法。
  • ステークホルダー識別:ソフトウェアおよびシステムに関係を持つステークホルダーを識別すること。
  • 要求開発(Openthology):要求は元からクライアントにあるものではなく、一緒に開発するものである を合言葉にうみだされた日本発の体系。
3.5.2要求分析
  • 要求分析:抽出した要求に対して、分類やモデル化を通じてシステムとその外の境界を明確にし、システム要求からソフトウェア要求へと詳細化及び明確化し、要求の妥当性や完全性、一貫性を確認すること。
  • ユーティリティ・ツリー:特定の品質要件を満たすためのサブ要求と管理指標のシナリオをツリー状に階層表記する方法。
  • NFRフレームワーク:品質要求をソフトゴールとその依存関係にあるサブゴールという形で可視化を試み、それら個々の品質要求間の相関関係をSynergyとConflictの関係で表すフレームワーク
  • Planguage:仕様言語。システムの品質特性を明確に評価可能な形で定義するための記述方法を示している。
  • 品質機能展開(Quality Function Deployment):製品に対する品質目標を実現するためにさまざまな変換及び展開を用いる方法論。品質展開、(技術展開、コスト展開、信頼性展開、)業務機能展開の総称。品質の展開とは顧客が要求する品質を明らかにして、その品質を製造する製品に組み入れるために必要な事柄を分析する作業。業務機能の展開とは、必要とされる品質を作り込むために実施される業務を機能別に明らかにする作業。つまり、要求される品質を明らかにして、その品質を満たす製品を作り上げるための業務の仕組を構築するためのツール。
  • 要求可変性分析:共通のコア資産の再利用を通じて多品種の製品群を体系的に導出するプロダクトライン開発において、多品種製品間のシステム要求における可変性を識別する作業。
3.5.3要求仕様化
  • USDM(要求仕様記述法、Universal Specification Describing Manner):要求仕様を記述するための表記法。要求仕様書を、要求とそれを実現するためのいくつかの仕様のセットで書く。要求は、要求と理由と説明のセットで書く。仕様は、要求で表現された振る舞いに対する具体的な制約条件や処理内容、選択肢など。要求の仕様化では、要求の動詞表現に着目して要求を満たす具体的な仕様を抽出する。
3.5.4要求の妥当性確認と評価
  • 要求の妥当性確認と評価:要求やモデルのレビュー、プロトタイピング、受け入れテストの設計などを通じて、ステークホルダーのニーズや上位の要求に照らしてソフトウェア要求が妥当であることを確認し、さらに、要求そのものの記述の品質を評価すること。
3.6設計の技法
  • 設計の技法:ソフトウェア方式設計とソフトウェア詳細設計に適用する技法。
3.6.1方式設計の技法
  • DSM(依存関係マトリクス):大規模で複雑なシステムのシステム要素(タスクやモジュールなど)の依存関係を、容易に明らかにするための2次元の表を用いる設計の技法。システム要素を洗い出し、システム要素が実施される順に上から並べ、同じように列名として記述。行に並べたシステム要素が依存するシステム要素を列名から探して×印を記入。
3.6.2詳細設計の技法
  • コンポーネント:内容を隠ぺいするシステムのモジュール化部品で、その表明は環境内で置き換え可能である。コンポーネントはその振る舞いを提供インターフェース、および要求インターフェースと要求インターフェース(動的、および静的セマンティクスを含む)によって定義する。
  • 設計原則:過去のソフトウェア開発の知見から生まれた、設計の基本思想や作法を示したもの。SWEBOK2004では、設計の推奨技法として、「抽象化」、「相互結合と凝集度」、「分割とモジュール化」、「カプセル化/情報隠蔽」、「インターフェースと実現の分離」、「十分性、完全性、および基本性」の6つの基本思想を取り上げている。
3.7実装の技法
  • リファクタリング:外部から見たときの振る舞いを保ちつつ、理解や習性が簡単になるようにソフトウェアの内部構造を変化させること。
  • 契約による設計(Design by Contract、DbC):ここのモジュールの責務を明確にしてソフトウェアの複雑性を下げ、保守性を向上する技法。
3.8レビューの技法
3.8.1レビュー方法
  • ピアデスクチェック:成果物の作成者に、机上での障害の発見に長けたレビューア1名を加えて実施するレビュー。
  • パスアラウンド:レビュー対象となる開発成果物を複数のレビューアへ配布、または回覧を行うことで障害の指摘を行う形態のレビュー
  • ラウンドロビンレビュー:レビュー参加者全員が順に司会者とレビューアの役を持ち回りでつとめるレビュー。
  • ウォークスルー:仕様書やソースコードなどの成果物に対し、作成者を含め複数人が内容を確認することで実施するレビュー。インスペクションでは参加者の役割が明確で、形式的なチェックリストを用いるが、ウォークスルーにはそれがないのが違い。
3.8.2仕様・コードに基づいた技法
  • パストレース:処理の中のパス(処理の実行経路)と、条件によるそのパスの組み合わせとしてのロジックを確認するレビュー技法。
  • ラン・スルー:要求仕様から想定される具体的な入力データをもとに、レビューアが机上で内部仕様やプログラムを追跡するレビュー技法。パストレース技法の一種。
  • モジュール展開:分割されているモジュールを一つの図などに展開し、モジュール分けの妥当性、インターフェース設定の適切性をレビューする技法。大規模なプログラムでは量が多くなりすぎて全体の見通しが悪くなるため、他の技法を用いるとよい。
3.8.3フォールトに基づいた技法
  • FTA(フォールトの木解析):その製品がフォールトなどの定義された状態に至る、単独または組み合わせの要因を識別して構造化するための技法
  • EMEA(エラーモード故障解析):ヒューマンエラーによる障害の削減のために、考えられる間違いや人的過誤とその影響、および知名度を系統的に分析するために使用する。FMEA(故障モード影響解析、あるアイテムの故障モードに着目し、原因調査、影響評価を行うこと)の適用対象がヒューマンエラーになったもの。
  • CFIA(構成要素障害影響分析):ハードウェア構成の脆弱性を発見し、障害時にとるべきアクションを明確化するためにIBMで開発された技法。
  • PQ(パタン・キュー)デザインレビュー:軽微な一時的障害や一般的に想定されるべき部分的な障害でシステム全体がダウンする、あるいは主機能が使えなくなるようなシステム障害の未然防止のために実施するシステム的なレビューの技法。
3.9テストの技法
3.9.1経験及び直感に基づいた技法
3.9.2仕様に基づいた技法
  • グレーボックステスト:機能に対する入力と出量という外部に見える現象から判断するブラックボックステストに対し、仕様が明示されない(暗黙の仕様など)ものは、機能がプログラムのロジックに依存することがあることや、インターフェース仕様の確認のためには内部状態まで踏み込む必要があることから、場合によりプログラムロジックやメモリーの内容を参照する形で行われるテスト。
  • 同値分割:テスト対象が同じ振る舞いをすると仮定できる入力や出力などの値の集合や範囲を「同値クラス」としてまとめ、同値クラス内の代表値のみをテストすることによりテストの数を削減する技法。
  • デシジョンテーブルによるテスト:テスト対象の仕様をデシジョンテーブルと呼ばれる表にまとめ、これに基づいてテストケースを作成する技法。プログラムへの入力を「条件」実行結果を「動作」として抽出し、表の左端列、条件記述部と動作記述部に記入する。その後、条件指定部と動作指定部に規則を記入する。
  • 原因結果グラフ:プログラムの仕様を入力と出力の論理関係、原因間の関係を原因結果グラフと呼ばれるグラフで表現し、それに基づいてテストケースを作成する技法。
  • モデルベースドテスト:テスト対象システムの振る舞いをモデル化し、そのモデルに基づいてテストケース、テストスイート、テストスクリプトなどを自動生成する技法。
  • 要因分析技法:ソフトウェアの外部市王を要因とその要因がとりえる状態の形式で整理して「要因分析表」を作成し、それに基づいてテストケースを設計する。
  • CFD技法(Cause Flow Diagram):テスト対象の入力(原因)と出力(結果)を同値に分割した同値分割図をもとに原因と結果を流れ線でつないだ原因流れ図(CFD)を作成し、これに基づいてデシジョンテーブルを作成してテストケースを抽出する技法。CFD作成時には実装情報を用いて合理的にテストケース数を削減するグレーボックステストのアプローチがとられている。
3.9.3コードに基づいた技法
3.9.4フォールトに基づいた技法
  • ミューテーションテスト:テスト対象のプログラムを一定の規則に基づいて変更あるは変異させたときに、その変異をテストで検出できるかどうかにより、テストケースの集合であるテストセットの十分性(障害発見能力)を測る技法で、ホワイトボックステストの一つ。
3.9.5利用に基づいた技法
  • 運用プロファイルによるテスト:ソフトウェアが実際に運用される際にどのように利用されるかを確率分布により表現した利用パターン(運用プロファイル)をもとに運用時と同じ条件下でテスト対象を動作させ、ソフトウェアの信頼性を評価する技法。
3.9.6ソフトウェアの形態に基づいた技法
3.9.7組み合わせの技法
3.9.8リスクに基づいた技法
3.9.9テスト技法の選択と組み合わせ
3.9.10テスト自動化技法
  • TABOK:米国ATIが策定した自動テストに関する知識体系。7つの自動化リーダー向けスキルカテゴリと、5つの自動化技術者向けスキルカテゴリが定義され、立場・役割ごとに必要となる知識が体系化されている。
3.10品質分析・評価の技法
3.10.1信頼性予測に関する技法
  • ソフトウェア信頼性モデル:ソフトウェアの信頼性を定量的に評価するための数理モデル。動的モデル(ソフトウェア信頼度成長モデル)と静的モデルに分かれる。動的モデルはソフトウェアを実行した履歴から信頼性を計測・評価する。静的モデルでは開発プロセスの特性要因やソフトウェアの特徴と信頼性との関係を過去の実績などから経験的に関係づけたモデル。
  • フォールト発見数モデル:テスト時間と発見した障害数の関係に着目して構築した数理モデルから総障害数や潜在障害数を予測する。NHPPモデルや統計的データ解析モデルがある。
  • 統計的データ解析モデル:累積障害数データに傾向曲線を当てはめることで飽和状態を予測し、残存障害数を推定するもの。
  • Fault-Prone分析:モジュール集合などの要素集合のうちで、フォールトを含んでいる可能性の高いモジュールを特定する技法。
  • 欠陥除去モデル:開発作業において混入した欠陥数とその除去数からある工程終了時の残存欠陥数を予測するモデル。
3.10.2品質進捗管理に関する技法
  • 異常値管理:目標値や標準値の上限・下限の管理限界を定めて、管理限界を超えたものを異常値として分析して対策を講じる管理手法。
  • 工数・成果モデル:プロセス品質を評価するためのモデルで、工数指標と発見障害などの成果を組み合わせたマトリクスを作成し、座標位置によりプロセス品質を把握する技法。開発プロセスのどの工程に対しても用いることができる。縦軸が工数指標の高低(テスト効率など)、横軸が成果の高低(欠陥率など)の2x2マトリクス。(工数・成果マトリクス。工数が高い効率で、成果(発見欠陥)が低がベスト)
  • コード統合パターン:横軸に出荷までの時間、縦軸に完成予定のコード量をとった計画コード曲線の形状。S字形曲線なら正常な健全パターン。
  • PTR(問題追跡報告Problem Tracking Report)サブモデル:テスト工程で期待できる障害除去数を時系列で展開した曲線。時間軸に沿ってコード統合量に応じた予測PTR率とPTR展開パターンを使用することにより、ある時点のテストの障害率を分析・評価できる。
  • Rayleighモデル:PTRサブモデルと近いが、開発プロセスのすべての工程をカバーしている点が違い。PTRサブモデルはテスト工程のみ。
  • PTR発生およびバックログ予測モデル:開発プロセスの終了時点でPTRの数とバックログの数を予測するモデル。問題追跡報告とは障害報告書を指し、バックログと歯未解決の障害を指す。分析的なモデルではなく、経験的なモデル。
3.10.3障害分析に関する技法
  • ODC(直交欠陥分類):障害の性質をとらえたまま定量的に分析を行うことを目的とする。プロジェクト状態の診断を早期から少ない実施コストで行うことが可能。1)ODC属性による障害の分類 2)蓄積された障害データの分析の2つのステップで構成する。 ODC属性には、報告者にによる視点3つと修正者による6つの視点がある。蓄積して分析することで、どの分類に障害が集中しているか分布を調べることにより開発プロセスのどこで障害が発生しやすいかを分析できる。
  • バグ分析:バグを分析することで傾向を把握し、同一原因のバグの摘出を測るとともに類似バグの混入を防止することで信頼性の向上を図る。分析には2種類の方法がある。1)作り込み原因をなぜなぜ分析などで追及し、根本的原因に対策を立てる。2)バグの属性から分類し統計的に解析することで、解析対象のウィークポイントをつかむ。
3.10.4データ解析・表現に関する技法
  • QC七つ道具:数値データを整理解析し、現象を定量的に分析するために用いる技法。視覚的に表現することで問題点がわかりやすくなる。特性要因図(フィッシュボーン)、パレート図、チェックシート、ヒストグラム、散布図、管理図、層別。層別とは、ばらつきの原因になる要因ごとにデータを分けて考えること。
  • 新QC七つ道具:言語データを品質管理に生かす技法。言語データを整理して図で表現する。親和図法、連関図法、系統図法、マトリクス図法、アロー・ダイアグラム法(日程計画図)、PDPC法、マトリクス・データ解析法。
  • EDA(探索的データ解析)手法:モデルを前提の解析するのではなく、データの示唆する情報を多面的にとらえて解析する手法。
  • p管理図・u管理図:工程が安定した状態にあるか管理する。p管理図は障害の確率、u管理図は単位当たりの障害数を管理する。
3.11運用の技法
  • ソフトウェア若化:経年劣化による稼働中システムの性能低下、異常停止やハングアップなどの障害を未然防止するための保全技法。予防的な再起動など。プロアクティブな技法。
3.12保守の技法

<専門的品質特性のソフトウェア品質技術>

3.13使用性の技法
  • ユーザビリティテスト:ユーザーに使ってもらい、その際の行動や発話から製品・サービスの使用性の問題点を発見する技法。
  • CIF(Common Industory Format for Usability):人間中心設計活動からの成果物の表現形式を規定している。
  • ヒューリスティック法:使用性に関する知見を集めたガイドライン(チェックリスト)に基づいて評価するインスペクション法の一種。
3.14セーフティの技法
  • フォールト・アボイダンス:リスク低減の設計技法のひとつ。高信頼性部品を使用したり、故障の生じにくい設計や構造を採用することで危険事象の発生を回避しようとする考え方。
  • フェイルソフト:リスク低減の方法のひとつ。故障個所を切り離すなど、縮退を許してもシステムを完全には停止させず処理を続行する。
  • フェイルオーバー:切り替え。
  • パッシブセーフティ:人体の被害の影響を最小限に抑える技法。エアバッグなど。
  • アクティブセーフティ:危険事象を未然に防ぐ技法。危険事象の前兆を監視し、正常状態への回復または危険事象の回避を行う。アンチロックブレーキシステム等。
  • セーフティ・クリティカルシステムのテスト:信頼性保証のテストあるいは、危害を発生させないことを保証するテストのこと。OK/NGだけで判定するべきではなく、システムの安全性に対してどのように悪影響を及ぼしているのかという点を念頭に置いて評価し、安全度水準に沿って判定するべき。
  • ハザードに対するシナリオテスト:ハザードの推測と列挙、ハザードから危険事象へのパスの道程、安全機能の動作評価の大きく3つに分けられる。ソフトウェアに対するハザードの推測は、機能府動作、仕様の穴、設計・実装障害、非定常入力の4つの観点から行う。
3.15セキュリティの技法
  • KAOS:FTAを応用して、脅威と対策を関連付けながら、脅威分析と対策決定をサポートする分析技法。
  • ミスユースケース法:通常のユースケースに加え、攻撃者となるミスユーザー、脅威を表すミスユースケース、その脅威への対策を表すセキュリティユースケースの3つの要素を追加している。
  • SDL(セキュリティ開発ライフサイクル)マイクロソフトの提案した技法。設計段階の技法として、データフローに基づく脅威の分析技法が提案されている。DFDをもとに脆弱性を分析する。典型的な脅威として、なりすまし、かいざん、否認、情報漏洩、DoS、権限昇格の6つ(STRIDE)に分類。
  • フォレンジック(デジタル鑑識):サイバー攻撃など犯罪が発生した際、科学捜査のための証拠の収集方法を明記したもの。
  • ペネトレーションテスト(侵入テスト):情報システムに対して実際に侵入を試みるテスト。
  • ファジング:ツールを活用した機械的脆弱性発見の技法のひとつ。極端に長い文字列など問題を起こしそうなデータを送り込んでソフトウェアの動作状態から脆弱性を発見する技法。
  • アタックツリー分析:セキュリティ要求分析の技法のひとつ。攻撃や脅威が顕在化する状況の分析のため、木構造のゴールツリーを使って分析する。

 

  

 

3章は、、知ってたことを省略したというのもありますが、時間切れにて随分手を抜いてしまいました。

次は合格したかもわからないですが、受験の所感でも投稿の予定です。