JCSQE(工程に個別なソフトウェア品質技術)

s_bma.99 2024年09月03日 カード126 いいね2

テスト

ビューア設定

[Enter]で回答、[Shift + Enter]で改行します。テスト結果は全て回答すると保存されます。キーボードショートカットテストビューア設定

JCSQE(工程に個別なソフトウェア品質技術)
  • ステークホルダーが意識していない要求も発見し引き出す活動
    要求抽出
  • システムに対する要求者を漏れなく識別すること
    ステークホルダー識別
  • ステークホルダーの種類(2つ)
    一次ステークホルダー(直接かかわる)、二次ステークホルダー(直接かかわらない)
  • 「本当に役に立つ」システムを開発するための日本発のIT戦略策定であり、要求は一緒に開発するものであることが前提となる
    要求開発
  • ビジネスオーナーと業務担当者、システム開発者が一緒に要求を育てるモデル
    「コタツ」モデル
  • 要求から詳細なソフトウェア要求を明確にし、要求の妥当性を確認する
    要求分析
  • 状態遷移モデルなど、問題領域における主要な概念をモデル化したもの
    概念モデル
  • 想定される環境下で対象システムが果たすべきことに関する要求を分析し、詳細化する技法
    機能要求分析
  • ソフトウェア開発や維持のコストに大きく関わる機能面以外の要求
    非機能要求
  • 製品に対する品質目標を実現するために、さまざまな変換および展開を用いる方法論
    品質機能展開(QFD)
  • QFDで用いる品質要求と品質を有する技術を作るための技術特性の関係の解析に用いる
    品質表
  • 品質を実現するための情報収集に必要な展開(2つ)
    ①要求品質展開②製品特性展開
  • 共通のコア資産の再利用をする多品種製品開発のシステム要求における可変性を識別する(それぞれの製品同士、どこがどのように異なっているかを分析)
    要求可変性分析
  • システム運用上の要求とソフトウェアの要求を仕様書として文書化すること
    要求仕様化
  • ソフトウェアに対する要求を仕様化して文書化したもので、ソフトウェア設計工程で用いる
    ソフトウェア要求仕様
  • 要求仕様を記述するための表記法
    USDM(要求仕様記述法)
  • USDMの構成(3つ)
    「要求」「理由」「説明」
  • ソフトウェアアーキテクチャの設計のことを言い、ソフトウェアシステムの品質特性を実現させるためのもの
    ソフトウェア方式設計
  • 過去のソフトウェアアーキテクチャ設計における経験を抽象化したもの
    アーキテクチャパターン
  • 機能を部品としてソフトウェアを構築する技法
    構造化設計
  • 機能とデータをカプセル化したオブジェクトを部品化する技法
    オブジェクト指向設計
  • インターフェース集合を部品化しコンポーネント間の結合を行う技法
    コンポーネントベース設計
  • エンドユーザが利用する機能を構成単位とする技法
    サービス指向設計
  • 品質特性シナリオを作り上げるワークショップ形式の評価技法
    QAW(Quality Attribute Workshop)
  • 品質特性シナリオに基づいてアーキテクチャを設計する品質駆動型の評価技法
    ADD(Attribute Driven Design)
  • アーキテクチャが品質要求をどのように満たすかを分析してアーキテクチャを評価する技法
    ATAM(Architecture Trade-Odd Analysis Method)
  • アーキテクチャを経済的な側面から評価する技法
    CBAM(Cost Benefit Analysin Method)
  • システム同士の依存関係を二次元表に表して設計する技法
    DSM(依存関係マトリクス)
  • 各ソフトウェアのインターフェースの設計
    ソフトウェア詳細設計
  • TDD(テスト駆動開発)の目的(2つ)
    保守性、開発者の支援
  • ソフトウェア設計の特定の文脈上で起こる問題と解法、結果をまとめた設計ノウハウ
    デザインパターン
  • デザインパターンの1つであるGoFパターンが使用するカテゴリ(3つ)
    生成、構造、振る舞い
  • ソフトウェア開発の知見から生まれた設計の基本思想や作法
    設計原則
  • 個々のモジュールの責務を明確にして保守性を上げる設計
    契約による設計
  • 提供側メソッドの責務であり、クラスなどのオブジェクトが常に真になることを証明すること
    不変表明
  • 契約による設計でルーチン(処理)の事前条件、事後条件、不変表明を満たせない場合どうするか
    例外を発生させる
  • レビューアがどのように対象物を読むかを示すもの
    リーディング技法
  • 机上レビューの公式的な呼び方
    ピアデスクチェック
  • 専用ツールやSNS利用を前提としたコードレビュー
    モダンコードレビュー
  • 処理中のパスと条件によるパスの組み合わせのロジックを確認する。入力データと期待出力を想定する。
    パストレース
  • FMEAに加えて故障発生確率を考慮する技法
    FMECA
  • FMEAをヒューマンエラーに対して適用した技法
    EMEA
  • システム構成要素間の相互作用によるアクシデントモデル
    STAMP
  • 障害時にとるべきアクションを明確化するための技法
    CFIA
  • システムがダウンする障害の未然防止のために実施するレビュー
    PQデザインレビュー
  • 障害が混入しやすい箇所の情報を含むシナリオレビュー
    ディフェクトベースドレビュー(DBR)
  • 利用者の手順と照らし合わせながら読むレビュー
    ユーセージベースドリーディング(UBR)
  • プログラムのロジックを参考にして仕様を得ながら行うテスト
    グレーボックステスト
  • 相互作用のある複数の変数の共感条件に対してテストケースを作成する
    ドメイン分析
  • テスト対象の原因と結果を「流れ線」でつないだ図を作成してデシジョンテーブルを作成するテスト
    CFD技法
  • 分岐網羅と条件網羅の違い
    分岐網羅は行き先すべて、条件網羅は行き先が同じでも条件全てをテストする
  • 制御フローとは
    IF~ELESE等のロジック
  • プログラム変更による変異をテストで検出できるかを確認し、テストセットの十分性を測る技法
    ミューテーションテスト 
  • 表を作成して、組み合わせを網羅するテストケースを設計する手法
    直交表テスト
  • 2つの因子間の組み合わせを網羅し、すべての水準の組み合わせが1つ以上存在するとしたテスト
    ペアワイズテスト
  • 因子と水準を分類木とよばれる図に表し組み合わせを網羅するテストケースを設計する技法
    クラシフィケーションツリー
  • 直行表を用いた組み合わせ作成を中心としたテスト設計プロセスを定義したもの
    HAYST法
  • 信頼性の予測および評価に関する技法
    信頼性予測
  • ソフトウェア品質をサンプリングテストで予測する日立の技法
    探針
  • ソフトウェア実行履歴から信頼性を計測し、評価するモデル
    動的モデル
  • 動的モデルは信頼度が成長する過程を記述するため○○と呼ばれる
    ソフトウェア信頼度成長モデル
  • 開発プロセスの特性要因とソフトウェアの特徴と信頼性の関係を経験的に関係づけたモデル
    静的モデル
  • フォールト(障害)を含んでいる可能性の高いモジュールを特定する技法
    Fault-Prone分析
  • 品質計画の進捗状況を管理することで早期に必要な対応を行う
    品質進捗管理
  • ソフトウェア開発プロセスの障害率を表したモデル
    Rayleighモデル
  • テスト工程で期待する障害除去率を時系列で分析したモデル
    PTR(問題追跡報告)サブモデル
  • サービス等を価値として捉え、分析することで価値の改善を進める方法論
    VE(VA)
  • バグを負債として、負債が0になった時点で出荷する管理方法
    品質会計(NEC)
  • 障害分析の目的(2つ)
    予防、似た障害の発見(水平展開)
  • 障害の含有要素を分類し、分析することで障害混入要員をプロセス改善に結びつける技法
    ODC(直交欠陥分類)
  • ODCを行うことで障害の顕在化を○○することが出来る
    抑制
  • ODC属性による障害の4象限
    種類・動機・個所・影響
  • 品質管理において、データを解析し、分析するために用いる7つの技法の総称
    QC七つ道具
  • QC七つ道具①因果関係を魚の骨のようにあらわした図
    特性要因図
  • QC七つ道具②重点項目の絞り込みや項目ごとの重要度把握に用いる図
    パレート図
  • QC七つ道具③集計用紙や記録用紙
    チェックシート
  • QC七つ道具④データの度数分布表を表示した柱状図
    ヒストグラム
  • QC七つ道具⑤相関性などをプロットした図
    散布図
  • QC七つ道具⑥工程管理に用いる郡内変動を表した折れ線グラフ
    管理図
  • QC七つ道具⑦データを視覚的に把握するために用いる
    グラフ
  • QC七つ道具⑧ばらつきの原因になる要因ごとにデータを分けて考える
    層別(考え方のため、7つ道具と分けている)
  • 新QC七つ道具①未経験の話題を言語データとしてあらわし、親和性をグループ化して現状を可視化する
    親和図法(KJ法)
  • 新QC七つ道具②原因と結果などが複雑に絡み合う場合に関係性を論理的につないで課題を解明する。
    連関図法
  • 新QC七つ道具③目標に到達するための手段を系統的に展開して解決する技法
    系統図法
  • 新QC七つ道具④PERTで使用する日程計画図であり、ネットワークの形を利用してプロジェクト推進に必要な課題解決の計画と管理をする
    アロー・ダイアグラム法
  • 新QC七つ道具⑤計画開始時から結果までの経過に従って矢印で結合した図する技法
    POPC法(過程決定計画表)
  • 新QC七つ道具⑥二次元の配置で問題を整理して全体構成を把握する技法
    マトリクス図法
  • 新QC七つ道具⑦多数のデータを少数の代表的な総合指標にまとめて分析する
    主成分分析
  • 新QC七つ道具道具の特徴
    言語データを主に使用する(主成分分析以外)
  • それぞれの水準の行×列の組み合わせを集計して表にまとめる
    クロス集計表/カイ二乗検定
  • 成功・失敗のどちらかが得られる試行に対し、「成功」回数をまとめた分析
    二項分布
  • 発生確率の小さい事象のランダムな発生回数に従う分析
    ポアソン分布
  • 言語データのキーワードをネットワーク状に表したもの
    共起ネットワーク分析
  • メモリリーク等によるソフトウェアの経年劣化
    ソフトウェア若化
  • 「訂正」を行う保守(2種類)
    是正保守・予防保守
  • 「改良」を行う保守(2種類)
    適応保守・完全化保守
  • ソースコード間の依存関係や構成、目的を解明する。システム保守のためのドキュメント整備
    リバースエンジニアリング
  • システムを再構築するための調査や改造プロセス
    リエンジニアリング
  • ソースコードに同じロジックがないか抽出する技法
    コードクローン分析
  • 使用するプログラミング言語が指定される開発における制約条件
    プロセスパラメーター
  • 要求は一緒に開発するものという、言葉を元に設立されたアライアンス
    要求開発アライアンス
  • 品質要求間の相互関係を正方向の作用と負方向の作用の関係で表すフレームワーク
    NFRフレームワーク
  • サブ要求と管理指標のシナリオをツリー上に階層表記する方法
    ユーティリティツリー
  • 仕様言語とプロセス記述からなる技法
    Planguage
  • 業務機能に関する要求以外を非機能要求と定義しているもの
    非機能要求グレード
  • 検証必要項目と指標、検証段階を提示して検討対象システムごとに必要な項目を抽出することを推奨するもの
    非機能要求定義ガイドライン
  • システムに必要な機能
    フィーチャー
  • フィーチャーを識別する技法(2つ)
    フィーチャーツリー、フィーチャーマトリクス
  • 運用概念のこと
    ConOps
  • 実装技法に依存しないアーキテクチャパターン(4つ)
    POSA、Black board、Layers、Pipes and Filters
  • 構造化設計に使うデータフロー図
    DFD
  • 扱う実装技法に特化したアーキテクチャパターン
    PofEAA
  • 規約を設定して重複を防ぐフレームワーク
    Ruby
  • 自動テストコードを記述しながら開発を行う
    TDD(テスト駆動開発)
  • ここのモジュールの責務を明確にして保守性を向上する設計
    DoC
  • C言語のソフトウェア開発標準規格
    MISRA-C
  • ソフトウェア開発に必要なツールを一つにまとめたもの
    統合開発環境(IDE)
  • レビュー対象を複数のレビューアへ配布して内覧を行う手法
    パスアラウンド
  • レビュー参加者が役を持ち回りで務める方法
    ラウンドロビンレビュー
  • ペアプロの代表者手法
    XP(エクストリームプログラミング)
  • 複雑度のメトリクスに着目して保守の困難性を評価する
    複雑度分析
  • 災害復旧計画
    DRP
  • 2つの因子間の組み合わせを網羅したテストケースを設計するペアワイズ法の別名
    All-pair法
  • エラーが起きた時に存在するシステムの欠陥を推測すること
    エラー推測
  • 工程管理図の種類(2つ)
    p管理図・u管理図
  • STAMPをベースにしてハザードの要因を分析する技法
    STPA
よく頑張りました
テストスタート
読み込み中
ログイン
オンライン単語帳

このページを利用するにはログインする必要があります。ログインするとAnkilotをより便利にご利用いただけます。