システム開発技術の用語
全188語。
推測・協調・学習のライフサイクルを繰り返すアジャイル手法。
⚠ 「推測・協調・学習」の3語が出たらASD。
開発モデルの種類とアジャイル
コスト・品質・スピードを大きく改善するため、業務の流れを根本から設計し直すこと。
⚠ 「プロセスをデザインし直す」は BPR。SOA はシステムの作り方。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
業務の中でデータがどこから来て、どこで加工され、どこへ行くかを4つの記号で描く図。
⚠ 流れ図（フローチャート）は処理の順番と分岐を描く。DFDは順番を描かない。
DFD・E-R図・決定表とコード設計
業務で扱うデータの構造に注目して設計し、データを共有資源として一元管理する考え方。
⚠ プロセス中心は業務手順に合わせてデータを作る。オブジェクト指向はデータと手続をまとめる。
DFD・E-R図・決定表とコード設計
管理対象を実体（エンティティ）、実体どうしのつながりを関連（リレーションシップ）として描く、データの関係の図。
⚠ データの流れならDFD、状態の変化なら状態遷移図。「実体と関連」があればE-R図。
DFD・E-R図・決定表とコード設計
組織全体の業務とシステムを、業務・データ・適用処理・技術の4つの体系で整理して最適化する枠組み。
⚠ 「4つの体系」が出たら EA で、SOA ではない。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
全体モデルを作り、優先度付きのフィーチャ（機能）リストを作って、フィーチャ単位で計画・設計・構築を繰り返すアジャイル手法。
⚠ 「フィーチャ」が出たらFDD。
開発モデルの種類とアジャイル
サーバなどのインフラの構成・設定をコードとして書き、ツールで自動的に適用する手法。
⚠ データ移行や機器廃棄の効率化ではない。「同一構成の多数のサーバに一括適用」が効果。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
少人数のチームが開発ツールを活用し、期限を区切って短期間でシステムを作り上げる開発手法。
⚠ アジャイルも短期間だが、RADの決め手は「開発ツールの活用」と「短期間での完成」。
開発モデルの種類とアジャイル
営業活動に IT を使って、営業の効率と品質を高める仕組み。
⚠ SOA と略語が似ている。「営業」が出たら SFA。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
サービスの内容・範囲・品質の要求水準を、提供者と顧客があらかじめ合意しておく取り決め。
⚠ 「要求水準を明確にして合意」は SLA。システムの作り方ではなく契約。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
業務機能を「サービス」という部品とみなし、それを組み合わせてシステムを構築する考え方。
⚠ SOAP（Web サービスの通信手順）や SLA（品質の合意）と名前が似ている。「組み合わせて構築する考え方」なら SOA。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
Web サービス同士が XML でメッセージをやり取りするための通信手順。
⚠ WSDL（窓口の定義）とともに「インタフェースやプロトコルを規定」と出る。SOA そのものではない。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
インターネット上の Web サービスを XML で登録・検索できる仕組み。
⚠ 「Web サービスを検索」と出たら UDDI。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
ソフトウェアの設計を図で表すための、世界共通の表記ルール。
UML の図の種類と読み方
Web 経由で他のプログラムから機能やデータを呼び出せるようにした窓口。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
5つの価値を基礎に、テスト駆動開発・ペアプログラミング・リファクタリングなどの実践を推奨するアジャイル手法。
⚠ 「5つの価値」「ペアプログラミング」があればXP。役割・イベントの話ならスクラム。
開発モデルの種類とアジャイル
システムを利用する人や外部システムなど、システムの外側にいる登場人物。
UML の図の種類と読み方
ある処理から次の処理への制御の流れや分岐を表す図で、業務のワークフローにも使う。
⚠ シーケンス図は「誰と誰が」時間順にやり取りするかを表す。順序と分岐ならアクティビティ図。
UML の図の種類と読み方
ある時点で成り立つべき条件を論理式としてプログラムに埋め込み、実行中に正しさを確かめる手法。
⚠ 「論理式を埋め込む」とあればこれ。網羅率を測るのはカバレージ分析。
デバッグ・テスト支援ツールと品質の測り方
短い期間ごとに動くソフトウェアを作って確認することを繰り返し、要求の変化に素早く対応する開発の考え方。
⚠ スパイラルも繰り返すが、アジャイルは「短い反復で動くものを出す」考え方の総称で、スクラムやXPを含む。
開発モデルの種類とアジャイル
稼働中のアプリケーションの不具合修正や機能変更を、承認・テスト・記録の手順に沿って行う作業。
⚠ 担当者のテストが終わった時点では完了ではない。承認を経て本番に反映し、完了を記録して初めて完了。
システム移行と保守
アジャイル開発で繰り返す1〜4週間程度の開発期間の単位。
⚠ スクラムでは同じものを「スプリント」と呼ぶ。
開発モデルの種類とアジャイル
システムを部分ごとに一通りの工程で完成させ、それを繰り返して段階的に全体を仕上げるモデル。
⚠ プロトタイピングの選択肢で罠として出る。「部分的に機能を完成させて繰り返す」はこちら。
開発モデルの種類とアジャイル
クラスの定義に基づいて作られた、具体的な1個の実体。
⚠ クラスと逆に覚えやすい。「代々木公園」のような固有の1個がインスタンス。
オブジェクト指向の基本（クラス・継承・多相性）
モデレータが進行し、参加者が役割を分担してチェックリストに沿って指摘し、正式な記録を残す公式なレビュー。
⚠ 「作成者が説明して参加者が質問」だけならウォークスルー。モデレータが出たらインスペクション。
レビューの種類（ウォークスルー・インスペクション）
異なるシステムや製品同士がデータをやり取りして一緒に動ける性質。
⚠ トレーサビリティ（追跡できること）と名前の響きが似ているので注意。
要件定義から外部設計・内部設計へ
モジュール同士がデータや呼出しをやり取りするときの約束事（引数・戻り値の形など）。
テスト工程の流れ（単体・結合・システム・運用）
作成者が成果物を説明し、開発者同士で質問・指摘をして誤りの検出に専念するレビュー。
⚠ インスペクションとの違いは、モデレータ・チェックリスト・正式記録が無いこと。解決策はその場で検討しない。
レビューの種類（ウォークスルー・インスペクション）
要件定義からテストまでの工程を順番に進め、前の工程が完了してからその成果物を使って次の工程に進む開発モデル。
⚠ スパイラルやアジャイルは「繰り返す」。ウォータフォールは原則戻らず1回で流す。
開発モデルの種類とアジャイル
別のコンピュータや装置の動作をソフトウェアなどでまねて再現する仕組み。
⚠ 結合テストで未完成モジュールの代わりをするスタブ・ドライバとは別物で、誤答の選択肢として出る。
テスト工程の流れ（単体・結合・システム・運用）
システムで管理する対象のことで、物だけでなく注文のような出来事も含み、特性を表す属性をもつ。
⚠ インスタンスはエンティティの具体的な1件で、1つのエンティティに多数ある（1対1ではない）。
DFD・E-R図・決定表とコード設計
スーパクラスで定義されたメソッドを、サブクラスで同じ名前のまま再定義すること。
⚠ オーバロードは同じクラス内に引数違いの同名メソッドを並べること。「再定義」ならオーバライド。
オブジェクト指向の基本（クラス・継承・多相性）
同じクラスの中に、名前が同じで引数の型・個数・並び順が違うメソッドを複数定義すること。
⚠ オーバライドはサブクラスでの再定義。キーワードは「引数が異なる」。
オブジェクト指向の基本（クラス・継承・多相性）
データと、そのデータを扱う手続をひとまとめにした部品。
⚠ クラスから作られた実体を指すときはインスタンスと同じ意味。
オブジェクト指向の基本（クラス・継承・多相性）
ある時点に存在する具体的なオブジェクトと、そのつながりを表す図。
⚠ クラス図は型（設計図）を、オブジェクト図は実体を表す。
UML の図の種類と読み方
ホワイトボックステストで、命令・分岐・条件をどこまで実行したかを測る基準。
テスト技法とカバレッジ（網羅基準）
データと手続を一つのオブジェクトにまとめ、内部の詳細を外部から隠すこと。
⚠ 抽象化（共通部分を取り出す）や継承（引き継ぐ）と混同しやすい。キーワードは「隠蔽」。
オブジェクト指向の基本（クラス・継承・多相性）
同じ性質をもつオブジェクトに共通する属性と操作を定めた、ひな形となる定義。
⚠ インスタンスはクラスから作られた実体。クラスは1つ、インスタンスは複数作れる。
オブジェクト指向の基本（クラス・継承・多相性）
クラスとクラス間の関係を表して、システムの静的な構造を示す図。
⚠ オブジェクト図はある瞬間の実体を表す。クラス図は設計図どうしの関係を表す。
UML の図の種類と読み方
変数名の付け方や書式など、プログラムの書き方を統一するために決めておくルール。
⚠ セキュアプログラミングは安全なコードを書くための手法で、書き方の統一が目的ではない。
モジュールの分け方（強度と結合度）
オブジェクト間のメッセージのやり取りを、オブジェクト同士のつながりを中心に表す図。
⚠ シーケンス図とはメッセージを表す点が共通。時間軸を前面に出すのがシーケンス図。
UML の図の種類と読み方
アプリとその実行環境をひとまとめにし、1つの OS 上で軽く速く動かす仮想化技術。
⚠ マイクロサービスの選択肢で混ぜられる。「高速に起動」「オーバーヘッドが少ない」はコンテナ。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
ソフトウェアを構成する部品と、その依存関係を表す図。
UML の図の種類と読み方
部品が全体と一体で扱われる、結びつきの強い全体と部分の関係。
⚠ 多相性や継承の選択肢に紛れて出る。部品の組合せなので、継承とは別。
オブジェクト指向の基本（クラス・継承・多相性）
全体と部分の関係のうち、全体が消えると部分も消える強い結び付きで、全体側に黒い菱形を付ける。
⚠ 集約は白い菱形。黒が強い結び付きと覚える。
UML の図の種類と読み方
継承関係で、上位クラスの性質を引き継ぐ下位クラス。
⚠ 上位の「部品」はサブクラスではない。「〜の一種」と言えるものだけがサブクラス。
オブジェクト指向の基本（クラス・継承・多相性）
対象に1から順番に番号を付けるコード体系。
DFD・E-R図・決定表とコード設計
オブジェクト間の相互作用（メッセージのやり取り）を時系列で表す図。
⚠ アクティビティ図は処理の流れを表す。「時系列」「相互作用」とあればシーケンス図。
UML の図の種類と読み方
完成したシステム全体が、機能・性能・負荷などの要件を満たすかを確かめるテスト。
⚠ 運用テストと混同しやすい。仕様・要件の視点ならシステム、利用者の業務手順の視点なら運用。
テスト工程の流れ（単体・結合・システム・運用）
共通フレームでのシステムテストの呼び名で、システムが要件を満たすかを実際の業務データや例外データで確かめるテスト。
⚠ 全分岐・全命令を通すデータは単体テスト用、ユニット間のエラーを見るデータは結合テスト用。
テスト工程の流れ（単体・結合・システム・運用）
継承関係で、性質を引き継がせる側の上位クラス。
⚠ サブクラス（派生クラス）は引き継ぐ側。呼び名が複数あるだけで、同じものを指す。
オブジェクト指向の基本（クラス・継承・多相性）
役割（プロダクトオーナーなど）・イベント（スプリントレビューなど）・作成物（プロダクトバックログなど）・ルールから成るアジャイル開発の枠組み。
⚠ XPは5つの価値と開発プラクティス、ASDは推測・協調・学習、FDDはフィーチャ単位。
開発モデルの種類とアジャイル
テスト対象から呼び出される下位モジュールの代わりに、仮の結果を返すテスト用モジュール。
⚠ ドライバは逆に呼ぶ側（上位）の代役。「呼び出される」ならスタブ、「呼び出す」ならドライバ。
テスト工程の流れ（単体・結合・システム・運用）
レコードなどのデータ構造を丸ごと引数で渡し、受け取った側がその一部だけを使う結合。
⚠ データ結合より1段強い。不要な項目まで渡していればスタンプ結合。
モジュールの分け方（強度と結合度）
1つのオブジェクトの状態が、イベントの発生や時間の経過でどう変わるかを表す図。
⚠ アクティビティ図は処理の流れを表す。「状態」「イベント」「遷移」ならステートマシン図。
UML の図の種類と読み方
要求される処理能力の限界、つまり高負荷の状態でシステムがどう動くかを確かめるテスト。
⚠ 使いやすさの評価（ユーザビリティ評価）、他機との性能比較（ベンチマーク）、修正の影響確認（回帰テスト）と区別する。
テスト工程の流れ（単体・結合・システム・運用）
プログラムの指定した命令を実行するたびに、指定したメモリの内容を書き出すこと。
⚠ メモリダンプはエラーで止まったときに出す。実行の履歴を出すのはトレーサ。
デバッグ・テスト支援ツールと品質の測り方
要求分析から実装までの工程を繰り返し、毎回リスクを評価しながらシステムを成長させていくモデル。
⚠ インクリメンタルモデル（部分を完成させて足していく）とも似る。スパイラルの決め手は「リスク評価」。
開発モデルの種類とアジャイル
ソフトウェアを構成する、ひとまとまりの機能を持った部品。
要件定義から外部設計・内部設計へ
作成したコンポーネントを組み合わせ、正しく連携するかをテストするプロセス。
⚠ 結合テストの暫定的な要求事項を定義するのは、前の工程である方式設計。
要件定義から外部設計・内部設計へ
各コンポーネントの中身を、コーディングできる細かさまで決めるプロセス。
⚠ 方式設計は全体の構造と部品分けまで。詳細設計はその部品の内部を決める。
要件定義から外部設計・内部設計へ
ソフトウェア要件を最上位の構造に変換し、構成要素（コンポーネント）とそのインタフェースを決めるプロセス。
⚠ 要件定義は仕様を決める工程、詳細設計は1行単位まで詳しくする工程。「最上位レベル」とあれば方式設計。
要件定義から外部設計・内部設計へ
コードの値から計算した数字を末尾に付け、入力されたコード値の誤りを見つける仕組み。
⚠ チェックポイントはDBの障害回復の用語。桁数・範囲・数値チェックは別の入力チェック。
DFD・E-R図・決定表とコード設計
確認すべき項目をあらかじめ一覧にしたもので、インスペクションで漏れなく指摘するために使う。
レビューの種類（ウォークスルー・インスペクション）
利用者マニュアルのうち、基本的な考え方と操作手順を例題を使って一通り説明する章。
⚠ リファレンス（機能を詳細に整理した辞書的な章）と取り違えやすい。「例題で一通り」ならチュートリアル。
システム移行と保守
DFDで平行な二本線で表す、データをためておくファイルやデータベース。
⚠ 「同期」の記号ではない。円（プロセス）と取り違えさせる選択肢に注意。
DFD・E-R図・決定表とコード設計
DFDで矢印で表すデータの流れで、流れるデータの名前を付ける。
⚠ 流れ図の矢印は制御（処理の順番）の流れで、意味が違う。
DFD・E-R図・決定表とコード設計
必要なデータ項目だけを引数で渡す、最も弱い（望ましい）結合。
⚠ スタンプ結合はデータ構造を丸ごと渡す。必要な項目だけならデータ結合。
モジュールの分け方（強度と結合度）
設計書を関係者で確認して、仕様の不備や設計の誤りを早い段階で見つけ、手戻りを減らす活動。
⚠ スケジュールの見直しや見積り精度の向上が目的ではない。ねらいは「早期発見・手戻り削減」。
レビューの種類（ウォークスルー・インスペクション）
0〜9の10区分を繰り返して分類を細かくしていくコード体系で、図書分類が典型。
DFD・E-R図・決定表とコード設計
テストでコードのどれだけの部分が実行されたかを、網羅率として測る道具。
⚠ 静的コード解析は実行しない。「割合」「網羅率」とあればカバレージ分析。
デバッグ・テスト支援ツールと品質の測り方
何を、どんな入力と期待結果で確かめるかを決めたテストの1単位。
⚠ テストデータ。先にテストケースを決め、それに沿ってテストデータを準備する。
テスト技法とカバレッジ（網羅基準）
先にテストケースを作り、それに合格するようにプログラムを書く開発方法。
⚠ 「テストケースを先に設定」と書かれていればこちら。リファクタリングではない。
モジュールの分け方（強度と結合度）
計画したテスト項目のうち、実施を終えた件数で、テストの進捗管理に使う。
⚠ テストデータの作成量やプログラムの修正量は、進捗の指標ではない。
デバッグ・テスト支援ツールと品質の測り方
上位のモジュールから下位へ順に結合していく結合テストの方式で、未完成の下位の代わりにスタブを使う。
⚠ ボトムアップテストは逆に下位から結合し、ドライバを使う。
テスト工程の流れ（単体・結合・システム・運用）
上位モジュールの代わりに、引数を渡してテスト対象モジュールを呼び出すテスト用モジュール。
⚠ スタブは呼ばれる側（下位）の代役。ボトムアップで必要なのがドライバ。
テスト工程の流れ（単体・結合・システム・運用）
単体テストで、まだ無い呼び出し元の代役がドライバ、呼び出し先の代役がスタブ。
⚠ これらを生成する道具は、テストの準備を支援するもので、静的解析ではない。
デバッグ・テスト支援ツールと品質の測り方
命令が実行された順序と実行結果の履歴を出力するデバッグ用の道具。
⚠ ダンプは「ある時点のメモリやファイルの中身」を出すもの。順序の「履歴」を出すのがトレーサ。
デバッグ・テスト支援ツールと品質の測り方
要件や変更要求が設計・実装・テストにどう反映されたかを、後からたどれる性質。
⚠ インターオペラビリティは相互運用性、ユーザビリティは使いやすさ。「経過を追える」はトレーサビリティ。
要件定義から外部設計・内部設計へ
一部の部門や拠点で先に新システムを導入し、問題がないことを確認してから全体に広げる方式。
⚠ 段階移行との違いは、最初の一部が「試行」の役割を持つ点。
システム移行と保守
テスト項目の消化件数に対して累積バグ件数を描いたグラフで、頭打ちになれば品質が安定してきたと判断する。
⚠ 目標件数に届いたかではなく、曲線が水平に近づいたかで判断する。
デバッグ・テスト支援ツールと品質の測り方
会議を開かずに成果物を複数のレビュアへ配布・回覧し、各自がコメントを返すレビュー。
⚠ 「配布又は回覧」がキーワード。会議形式のウォークスルーとは違う。
レビューの種類（ウォークスルー・インスペクション）
プログラムの中身を見ずに、機能仕様どおりの入力と出力になるかを確かめるテスト。
⚠ ホワイトボックステスト。選択肢に「網羅率・内部構造・分岐」があればホワイト、「機能仕様・同値クラス・限界値」があればブラック。
テスト技法とカバレッジ（網羅基準）
各イテレーションの最後に、チームが進め方を見直して次の改善策を決める活動。
⚠ 毎日行う朝会（進捗共有）とは別。ふりかえりはイテレーションの区切りで行う。
開発モデルの種類とアジャイル
複数のサービスから得た情報や機能を、画面上に並べたり重ねたりして見せるマッシュアップ。
⚠ 地図の埋め込みや取得データのグラフ化はこちら。出力を次の入力に使っていればロジック。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
分割された各プログラムの内部構造（モジュールの分け方など）を決める工程。
⚠ 内部設計より後、コーディングより前。
開発モデルの種類とアジャイル
プログラムの内部構造や処理手順を、コーディングできる粒度まで決める工程。
⚠ 外部設計の作業ではない。流れ図はこの工程の成果物。
要件定義から外部設計・内部設計へ
DFDで円（○）で表す、データを加工する処理。
⚠ データストア（二本線）は加工せずにためるだけ。
DFD・E-R図・決定表とコード設計
スクラムで、作るものの優先順位（プロダクトバックログ）に責任を持つ役割。
開発モデルの種類とアジャイル
スクラムで、作るべき機能や改善を優先順位順に並べた一覧。
開発モデルの種類とアジャイル
番号の範囲ごとに分類を割り当てるコード体系。
⚠ 桁別コードは範囲ではなく桁の位置で分類を表す。
DFD・E-R図・決定表とコード設計
試作品を早い段階で作り、利用者から意見をもらいながら開発を進める方法。
⚠ 「試作品」「フィードバック」と書かれていればこちら。
モジュールの分け方（強度と結合度）
開発の初期に試作品を作って利用者に確認してもらい、UIや性能の要求を早めに確定させて後の手戻りを減らすモデル。
⚠ スパイラルの「繰り返しながらリスク評価」と混同しやすい。キーワード「試作」があればプロトタイピング。
開発モデルの種類とアジャイル
モジュールの呼び出し回数や実行時間など、動いているときの特性を測る道具。
⚠ 網羅率を測るのはカバレージ分析ツール。時間や回数を測るのがプロファイラ。
デバッグ・テスト支援ツールと品質の測り方
2人のプログラマーが組んで、1つのプログラムを一緒に書く開発方法。
⚠ リファクタリングの選択肢と並べて出る。「2人」と書かれていればこちら。
モジュールの分け方（強度と結合度）
下位のモジュールから上位へ順に結合していく結合テストの方式で、未完成の上位の代わりにドライバを使う。
⚠ 「個々をテストしてから一気に全部結合」はビッグバンテストで別物。スタブが必要なのはトップダウン。
テスト工程の流れ（単体・結合・システム・運用）
プログラムの内部構造（命令や分岐）に着目し、必要な部分が実行されたかを網羅率で確かめるテスト。
⚠ ブラックボックステスト。分岐やモジュールが増えるとテストデータが急増するのはホワイト側の特徴。
テスト技法とカバレッジ（網羅基準）
プログラムの内部の構造（命令や分岐）を見ながら、それが正しく通るかを確かめるテスト。
⚠ ブラックボックステストは、中身を見ずに入力と出力だけで確かめる。
デバッグ・テスト支援ツールと品質の測り方
ソフトウェアを独立した小さな単一機能のサービスに分け、連携させて全体を実現する構成。
⚠ モノリシックは全機能が一体で変更時に全体を作り直す。コンテナは実行環境をまとめる技術で、構成の考え方ではない。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
公開されている複数のサービスや Web API を組み合わせて、新しいサービスを提供すること。
⚠ 自社の既存プログラムを部品化して再利用するのはコンポーネント再利用。「公開されている」「他のサービス」が決め手。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
オブジェクトがもつ手続（操作）で、メッセージを受けると実行される。
⚠ メッセージは実行を頼む側の働きかけ、メソッドは頼まれて実行される中身。
オブジェクト指向の基本（クラス・継承・多相性）
他のオブジェクトにメソッドの実行を依頼し、動作を起こさせるもの。
⚠ オブジェクト内部のデータ（属性）や、オブジェクトを生成するひな形（クラス）とは別。
オブジェクト指向の基本（クラス・継承・多相性）
エラーでプログラムが止まったときに、メモリの内容を書き出すこと。
⚠ スナップショットダンプは、エラーとは関係なく、指定した命令を実行するたびに書き出す。
デバッグ・テスト支援ツールと品質の測り方
1つのモジュールの中にある機能が、どれだけ1つの目的にまとまっているかを表す尺度で、強いほど良い。
⚠ モジュール結合度は部品どうしのつながりを表し、弱いほど良い。望ましい向きが逆。
モジュールの分け方（強度と結合度）
モジュールどうしがどれだけ依存し合っているかを表す尺度で、弱いほど良い。
⚠ モジュール強度（中のまとまり）と取り違えない。こちらは部品と部品の間の話。
モジュールの分け方（強度と結合度）
インスペクションでレビューを主導し、参加者にそれぞれの役割を果たさせる進行役。
⚠ 記録するのは書記、欠陥を直すのは作成者、資料を説明するのは作成者（説明者）。
レビューの種類（ウォークスルー・インスペクション）
全機能を1つのソフトウェアとしてまとめた構成で、一部の変更でも全体の作り直しが必要になる。
⚠ マイクロサービスの反対。「変更が他に影響しない」と書いてあればマイクロサービス。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
利用者が目的を、迷わず効率よく満足して達成できる使いやすさ。
⚠ トレーサビリティとは無関係の品質特性。
要件定義から外部設計・内部設計へ
システムが外部に提供する機能と、それを使うアクタとの関係を表す図。
⚠ DFDはデータの流れを表す。「アクタ」「外部に提供する機能」ならユースケース図。
UML の図の種類と読み方
参加者が順番に司会者とレビュアを交代しながら進めるレビュー。
⚠ 「順番に司会者」がキーワード。進行役が固定されるインスペクションとは別。
レビューの種類（ウォークスルー・インスペクション）
プログラムを修正したあと、修正していない部分に悪い影響が出ていないかを確かめるテスト。
⚠ リファクタリングのあとに行うテストであり、リファクタリングそのものではない。
モジュールの分け方（強度と結合度）
既存のソースコードなどを解析して、設計書や仕様を作り直すこと。
⚠ リファクタリングはコードそのものを書き直す。設計書を作るならリバースエンジニアリング。
モジュールの分け方（強度と結合度）
外から見た振る舞い（外部仕様）は変えずに、プログラムの内部構造を整理して保守性を高める活動。
⚠ リバースエンジニアリング（コードから設計書を作り直す）、リグレッションテスト（修正の影響を確かめる）と区別する。
モジュールの分け方（強度と結合度）
利用者マニュアルのうち、機能を詳細に説明し、知りたい箇所を見つけやすいように整理した章。
⚠ チュートリアルは学ぶための章、リファレンスは調べるための章。
システム移行と保守
エンティティどうしの関係で、1対多などの数の対応を表す。
⚠ 業務の手順や状態遷移を表すものではない。
DFD・E-R図・決定表とコード設計
あるサービスの出力を別のサービスの入力に渡し、処理を連結して新しいサービスを作るマッシュアップ。
⚠ プレゼンテーションマッシュアップは表示を並べるだけ。サービス同士がデータを受け渡しているかで見分ける。
サービスを組み合わせる設計（SOA・マイクロサービス・IaC）
関係のない機能がたまたま1つのモジュールに入っている、最も弱い強度。
モジュールの分け方（強度と結合度）
一方のクラスが他方を一時的に使い、相手の変更の影響を受ける関係で、破線の開いた矢印で表す。
⚠ 汎化は実線の白抜き三角矢印。破線なら依存。
UML の図の種類と読み方
受けた操作を自分で処理せず、内部で他のオブジェクトに依頼するしくみ。
⚠ 継承（上位から引き継ぐ）や集約（部品を組み合わせて一つにする）と混同させられる。
オブジェクト指向の基本（クラス・継承・多相性）
旧システムから新システムへの切替え手順と、切替えに伴う問題点を本番前に確認するテスト。
⚠ 性能テスト（処理性能）、結合テスト（インタフェースの整合性）、受入れテスト（要求機能を満たすか）と区別する。キーワードは「切替え」。
システム移行と保守
移行の方式・手順・日程・体制や、失敗時の切戻しの判断基準をまとめた計画。
システム移行と保守
別のアーキテクチャのコンピュータなど、異なる環境でも動くようにしやすい度合い。
⚠ 相互運用性は他システムとつながりやすいこと。変更性（保守性の一部）は直しやすいこと。
デバッグ・テスト支援ツールと品質の測り方
ある時点で旧システムの全てを一度に新システムへ切り替える方式で、短期間・低コストだがトラブルの影響が大きい。
⚠ 並行運用と混同しやすい。新旧を同時に動かすなら並行運用、一度に全部切り替えるなら一斉移行。
システム移行と保守
本稼働の前に、利用者に提供する視点で、業務手順どおりにシステムが使えるかを確かめるテスト。
⚠ 利用者が見るのは「業務手順」、運用者が見るのは「運用手順」。仕様どおりかの確認はシステムテスト。
テスト工程の流れ（単体・結合・システム・運用）
画面上の項目の配置や表示内容を決めたもので、利用者が確認できる代表的な成果物。
⚠ 物理データベース仕様は内部設計の成果物で、顧客の承認対象ではない。
要件定義から外部設計・内部設計へ
プログラムを修正・変更したことで、変更していない部分に想定外の悪影響が出ていないかを確かめるテスト。
⚠ 新規モジュールの誤り検出は単体テスト。3つの呼び名がすべて同じものだと覚える。
テスト工程の流れ（単体・結合・システム・運用）
製品化した後の保守に備えて、開発に使ったツールや機材を使用頻度に関係なく定期的に動作確認して保持すること。
⚠ 「最新版に更新し続ける」は誤り。当時の製品を再現できる状態を保つことが目的。
システム移行と保守
DFDで四角で表す、システムの外にいるデータの出どころ・行き先となる人や組織。
⚠ 入力画面や帳票を表す記号ではない。
DFD・E-R図・決定表とコード設計
外部宣言した個々のデータ項目を、複数のモジュールで共有する結合。
⚠ 共通結合はデータ構造（共通域）全体を共有する。個々の項目の外部宣言なら外部結合。
モジュールの分け方（強度と結合度）
画面・帳票の様式や入出力など、ユーザから見えるシステムのふるまいを決めたもの。
⚠ 帳票・画面の様式は外部仕様。内部仕様と取り違えない。
レビューの種類（ウォークスルー・インスペクション）
要求仕様を基に、利用者から見えるシステムの機能や画面などを決める工程。
⚠ 内部設計と取り違えやすい。「機能を定義」が外部、「プログラムに分割」が内部。
開発モデルの種類とアジャイル
画面・帳票・コード・論理データ構造など、利用者から見える仕様を決める設計工程。
⚠ 内部設計はコンピュータ側の視点。顧客の承認を受けるのは外部設計の成果物。
要件定義から外部設計・内部設計へ
クラス同士に何らかの関係があることを、実線で表す関係。
⚠ 関連名は線の上に書き、四角形の中には書かない。
UML の図の種類と読み方
1人でプログラムを読み、頭の中で動かして誤りを探す個人作業。
⚠ 複数の関係者で行うウォークスルーとは違い、個人で行う。
レビューの種類（ウォークスルー・インスペクション）
1つのモジュールが単一の機能だけを実行する、最も強い（望ましい）強度。
⚠ 情報的強度は複数の機能を持つ（機能ごとに入口点がある）点が違う。
モジュールの分け方（強度と結合度）
画面・帳票・処理内容など、システムが何をできるかを定めた要件。
⚠ 非機能要件は性能や信頼性などの品質面。災害対応策や移行手順はこちら。
要件定義から外部設計・内部設計へ
グローバルな共通域にあるデータ構造を、複数のモジュールで共有する結合。
⚠ 内容結合の次に強い。「グローバル」「共通域」と書かれていたら強い結合だと判断する。
モジュールの分け方（強度と結合度）
同値クラスの切れ目にある値とそのすぐ外の値をテストデータにして、境目の誤りを見つける方法。
⚠ 同値分割。≧と＞の取り違えのような境界の誤りを見つけるのは限界値分析。
テスト技法とカバレッジ（網羅基準）
上位クラスの属性や操作を、下位クラスがそのまま引き継いで使えるしくみ。
⚠ 委譲は他のオブジェクトに処理を頼むしくみで、引き継ぎではない。
オブジェクト指向の基本（クラス・継承・多相性）
条件の組合せと、それぞれに対する動作を表の形で整理したもの。
⚠ 実体を長方形で結ぶのはE-R図、制御の流れを矢印で描くのは流れ図。
DFD・E-R図・決定表とコード設計
モジュール同士やサブシステム同士をつないで、インタフェース（データの受け渡し）が正しいかを確かめるテスト。
⚠ システムテストと混同しやすい。「インタフェース」が出たら結合、「機能・性能・負荷」が出たらシステム。
テスト工程の流れ（単体・結合・システム・運用）
システムの要素とそのつながりを、時間の流れ抜きで表すUMLの図の系統。
⚠ 振る舞い図は時間の流れや変化を表す。「静的」とあれば構造図。
UML の図の種類と読み方
利用者が理解しやすく、覚えやすく、使いやすい度合い。
⚠ 連携先を増やすのは相互運用性、機能を増やすのは機能適合性、データを分散配置するのは信頼性の施策。
デバッグ・テスト支援ツールと品質の測り方
初期処理のように、同じタイミングで実行する処理をまとめたモジュールの強度。
⚠ 「特定の時点で必要な作業をすべて含む」と書かれていたら時間的強度。機能的強度ではない。
モジュールの分け方（強度と結合度）
実行の順番に関係がある機能をまとめた強度で、扱うデータどうしには関係がない。
⚠ 連絡的強度との違いは、同じデータを扱うかどうか。
モジュールの分け方（強度と結合度）
後の工程で問題が見つかり、前の工程に戻って作業をやり直すこと。
開発モデルの種類とアジャイル
後の工程で誤りが見つかり、前の工程まで戻って作り直すこと。
レビューの種類（ウォークスルー・インスペクション）
複数のオブジェクトを部品として組み合わせ、全体と部分（part-of）の関係を作ること。
⚠ 継承（is-a）とは別の関係。集約では全体が部品の属性や操作を共有するわけではない。
オブジェクト指向の基本（クラス・継承・多相性）
全体と部分の関係のうち、部分が単独でも存在できるもので、全体側に白い菱形を付ける。
⚠ コンポジションは黒い菱形で、部分は全体と運命を共にする。
UML の図の種類と読み方
仕様上の結果に影響しない、余分で不要な処理。
⚠ ブラックボックステストでは結果が正しく見えるため検出できない。
テスト技法とカバレッジ（網羅基準）
同じデータを扱う複数の機能をまとめ、機能ごとに入口点を設けたモジュールの強度。
⚠ 論理的強度は入口が1つで、引数で機能を選ぶ。入口点が機能ごとにあれば情報的強度。
モジュールの分け方（強度と結合度）
判定の中の個々の条件が、それぞれ真と偽の両方を1回以上取るようにする基準。
⚠ 判定条件網羅。条件網羅を満たしても判定全体が片方の結果しか出ないことがあり、分岐網羅を満たすとは限らない。
テスト技法とカバレッジ（網羅基準）
設計で決めたイベントと状態の組合せどおりに、システムの状態が変わるかを確認するテスト手法。
⚠ 決定表（ディシジョンテーブル）を使う手法。状態遷移テストは状態遷移図・状態遷移表を使い、状態が変わるシステムに向く。
テスト技法とカバレッジ（網羅基準）
システムの状態、状態を変えるきっかけ（イベント）、そのとき実行する動作を描く図。
⚠ 機能の階層構造はHIPOなど、段階的な詳細化は機能分解、データの流れはDFD。制御系システムに向く。
DFD・E-R図・決定表とコード設計
処理の順序、やり取り、状態の変化など、システムの動きを表すUMLの図の系統。
⚠ 構造図は止まった状態の作りを表す。「動的」とあれば振る舞い図。
UML の図の種類と読み方
呼び出し先の処理の流れを決めるフラグや処理コードを引数で渡す結合。
⚠ 引数で渡しているのでデータ結合と思いやすいが、渡す値が処理の流れを決めるなら制御結合。
モジュールの分け方（強度と結合度）
プログラムを動かさずに調べるのが静的テスト、実際に動かして調べるのが動的テスト。
⚠ 選択肢の文に「実行」「計測」が入っていたら動的と見る。
デバッグ・テスト支援ツールと品質の測り方
プログラムを実行せずにソースコードを読み、文法の誤りや使われない変数などの論理的な問題を見つける道具。
⚠ テストカバレージ分析やプロファイラは実行してから測る動的な道具。「実行時間」「実行された」とあれば静的ではない。
デバッグ・テスト支援ツールと品質の測り方
移行作業が失敗したときに、新システムの利用をやめて旧システムに戻すこと。
⚠ 判断基準は当日ではなく、事前に移行計画書へ書いておく。
システム移行と保守
他のシステムと情報をやり取りして連携しやすい度合い。
⚠ 別の環境に持っていくのは移植性。
デバッグ・テスト支援ツールと品質の測り方
オブジェクト同士がメッセージを送り合う様子を表す図の総称で、シーケンス図とコミュニケーション図を含む。
UML の図の種類と読み方
エンティティがもつ特性で、顧客なら氏名や住所。
DFD・E-R図・決定表とコード設計
オブジェクトが内部にもつデータ（性質の値）。
⚠ 属性はデータ、メソッドは手続。製造番号や住所は属性であってサブクラスではない。
オブジェクト指向の基本（クラス・継承・多相性）
一つのサブクラスが、複数のスーパクラスから性質を引き継ぐこと。
⚠ 多相性に「特有のもの」ではない。多相性に特有なのはオーバライド。
オブジェクト指向の基本（クラス・継承・多相性）
関連の両端に書いて、相手のクラスがいくつ対応するかを示す数（1、* など）。
UML の図の種類と読み方
同じ指示（インタフェース）で操作しても、相手のクラスに応じて異なる動作をする性質。
⚠ 多相性は「性質」、オーバライドはそれを実現する「手段」。
オブジェクト指向の基本（クラス・継承・多相性）
1つのモジュールについて、内部のロジックが仕様どおり動くかを確かめるテスト。
⚠ 結合テストと混同しやすい。「モジュール内部」「全分岐・全命令」なら単体、「モジュール間」なら結合。
テスト工程の流れ（単体・結合・システム・運用）
機能や拠点ごとに少しずつ新システムへ切り替える方式で、移行途中は新旧が混在する。
⚠ パイロット移行と似ている。段階移行は全体を順番に移す方式、パイロット移行は一部で試してから全体に広げる方式。「新旧間を接続するアプリケーションが必要」は段階移行の特徴。
システム移行と保守
細かい違いを捨てて、共通する本質的な性質だけを取り出すこと。
⚠ 「隠蔽」が出たらカプセル化。抽象化は「共通の性質を取り出して整理する」。
オブジェクト指向の基本（クラス・継承・多相性）
請求書や一覧表など、出力する書類の項目と書式を決める外部設計の作業。
⚠ 物理データ設計・プログラム設計は内部設計の作業。
要件定義から外部設計・内部設計へ
毎日短時間で、チームの進捗や困りごとを共有する打ち合わせ。
⚠ ふりかえりの時期を問う問題で罠の選択肢になる。
開発モデルの種類とアジャイル
入力を同じ扱いをされるグループ（同値クラス）に分け、各グループから代表値を選んでテストする方法。
⚠ 境界値分析。同値分割は「代表値」、境界値分析は「切れ目の値」を選ぶ。
テスト技法とカバレッジ（網羅基準）
上位クラスをもとに、性質を追加した特殊な下位クラスを作ること。
⚠ 汎化の逆向き。
オブジェクト指向の基本（クラス・継承・多相性）
モジュールの分け方や制御の流れなど、プログラム内部の作りを決めたもの。
⚠ 外部仕様をもとに作るので外部仕様とつながっている。レビューでは外部仕様との不整合と内部の矛盾を見る。
レビューの種類（ウォークスルー・インスペクション）
外部設計で決めた機能を、プログラム単位に分割して処理の流れを決める工程。
⚠ プログラム設計は「1本のプログラムの中身」。内部設計は「どのプログラムに分けるか」。
開発モデルの種類とアジャイル
外部設計の内容をどう実現するかを、プログラム分割・物理データ構造・処理方式などの形で決める工程。
⚠ 外部設計と視点が逆。「プログラムに分割」はこちらの作業。
要件定義から外部設計・内部設計へ
他のモジュールの内部のデータや処理を直接参照・変更する、最も強い（最悪の）結合。
モジュールの分け方（強度と結合度）
各判定の結果が真になる場合と偽になる場合の両方を1回以上通す基準。
⚠ 条件網羅。分岐網羅は判定全体の真偽、条件網羅は中の個々の条件の真偽を見る。満たせば命令網羅も満たす。
テスト技法とカバレッジ（網羅基準）
複数のクラスに共通する性質をまとめて、上位クラスを作ること。
⚠ 逆向き（上位から特殊な下位クラスを作る）が特化。どちらも is-a の関係で、部品関係（集約）とは違う。
オブジェクト指向の基本（クラス・継承・多相性）
「子は親の一種」という継承の関係で、子から親へ向かう白抜き三角の矢印で表す。
⚠ 依存は破線の開いた矢印。三角の矢印の先が親クラス。
UML の図の種類と読み方
応答時間・稼働率・セキュリティ・運用・移行など、機能以外の品質を定めた要件。
⚠ 機能要件は「何ができるか」。画面レイアウトは機能要件の成果物。
要件定義から外部設計・内部設計へ
コードの値から対象の内容が連想できるコード体系。
⚠ シーケンス（連番）・ブロック（区分）・デシマル（十進分類）は内容を連想できない。
DFD・E-R図・決定表とコード設計
判定の中の個々の条件について、真偽の全ての組合せを試す基準。
⚠ 条件網羅。条件が2つなら、条件網羅は各条件の真偽がそろえばよいが、複数条件網羅は4通り全部が必要。
テスト技法とカバレッジ（網羅基準）
データを記憶装置にどう格納し、どうアクセスするかまで決めた構造。
⚠ 論理データ構造（外部設計）と取り違えない。物理は内部設計。
要件定義から外部設計・内部設計へ
新旧システムを一定期間同時に動かし、結果を比べて問題がないことを確かめてから新システムへ移る方式。
⚠ 安全性は最も高いが、二重運用の運用コストがかかる。「費用が下がる」は誤り。
システム移行と保守
修正や変更がしやすい度合いで、平均修正時間（修正時間の合計÷修正件数）などで測る。
⚠ 誤り件数÷成果物の量は信頼性の指標。変更行数÷移植行数は移植性の指標。
デバッグ・テスト支援ツールと品質の測り方
本番環境で実際に使われるプログラムを保管する場所。
⚠ 変更が簡単でも直接更新してはいけない。テストと承認を経てから登録する。
システム移行と保守
仕様上、エラーとして扱われるべき入力値のグループ（範囲外の値など）。
⚠ 有効同値クラス。無効側の境界値（範囲のすぐ外の値）の数え落としが典型ミス。
テスト技法とカバレッジ（網羅基準）
プログラム中の全ての命令を1回以上実行させる基準。
⚠ 判定条件網羅。命令網羅は「何もしない側」の分岐を通らなくても満たせるので、一番弱い。
テスト技法とカバレッジ（網羅基準）
テストで実行された命令や分岐が、全体の何％にあたるかを表す数値。
デバッグ・テスト支援ツールと品質の測り方
仕様上、正しく処理されるべき入力値のグループ。
⚠ 無効同値クラス（エラーになるべきグループ）。個数問題では無効側も数える。
テスト技法とカバレッジ（網羅基準）
インタビューなどで利用者の要望や課題を集め、整理する作業。
要件定義から外部設計・内部設計へ
現状の問題点を調査・分析し、新しいシステムに求めることを明確にする最初の工程。
開発モデルの種類とアジャイル
システムで何を実現するかを、利用者と合意して文書にまとめる工程。
⚠ 外部設計は、決まった要件を画面や帳票などの見える形に落とし込む次の工程。
要件定義から外部設計・内部設計へ
同じデータを受け渡しながら、複数の機能を順番に実行するモジュールの強度。
⚠ 手順的強度も順番に実行するが、扱うデータは別々。同じデータを扱えば連絡的強度。
モジュールの分け方（強度と結合度）
どんなデータ項目をどのような関係で持つかを、格納方法を考えずに表した構造。
⚠ 物理データ構造は実際の格納方法。論理は外部設計、物理は内部設計で決める。
要件定義から外部設計・内部設計へ
似た機能をまとめ、処理コードなどの引数で1つを選んで実行するモジュールの強度。
⚠ 情報的強度（機能ごとの入口点）と区別する。引数による選択は制御結合を生みやすい。
モジュールの分け方（強度と結合度）