-
ステークホルダーが意識していない要求も発見し引き出す活動要求抽出
-
システムに対する要求者を漏れなく識別することステークホルダー識別
-
ステークホルダーの種類（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をより便利にご利用いただけます。