FE GLOSSARY CATEGORY

システム開発技術の用語

この分野の用語を一覧化しました。まず重要語を確認し、その後に一覧から苦手語をつぶしていきましょう。

白猫のやさしい一言

最初から全部覚えようとしなくて大丈夫だよ。問題で出会った用語を戻って確認する流れが、結局いちばん早いから。……「全部読んだ」より「3つ説明できる」のほうが、本番では強いよ。

黒猫の闇の刻印

クッ……「見たことある」程度の認識では、選択肢の闇に呑まれる。似た用語との違いまで自らの言葉で語れて初めて、その術は身についたと言える。……ちゃんとノートに2つ並べて書け、それでいいから。

この分野の重要語

アルゴリズム アルゴリズムは、ある問題を解くための明確な処理手順です。 正規化 正規化は、リレーショナルデータベースでデータの重複や更新時の不整合を減らすために表を整理することです。 API APIは、プログラム同士が機能やデータを利用し合うために定められた呼出し口です。 HIPO（Hierarchy plus Input Process Output） HIPOは、機能を階層構造で分解し、各機能の入力・処理・出力を整理する設計手法です。 IoT IoTは、センサや機器をネットワークにつなぎ、状態取得や制御を行う仕組みです。 NoSQL データベース NoSQLデータベースは、リレーショナルデータベース以外の柔軟なデータモデルを持つデータベースの総称です。 UML UMLは、ソフトウェアの構造や振る舞いを図で表すための標準的なモデリング記法です。 教育訓練システム（e-Learning，Web Based Training） 教育訓練システムは、利用者や運用担当者に業務手順やシステム操作を学ばせるためのe-LearningやWBTの仕組みです。 複数条件網羅（multiple condition coverage） 複数条件網羅は、判定条件を構成する個々の条件の真偽の組合せをすべて少なくとも1回実行するテスト網羅基準です。 双方向の追跡可能性（双方向のトレーサビリティ） 双方向の追跡可能性は、要件から成果物へも、成果物から要件へも両方向にたどれる性質です。 レビュー参加者 レビュー参加者は、成果物レビューで作成者・レビューア・モデレータなどの役割を担う人たちです。 DFD DFD（データフロー図）は、データがどこから来てどう処理され、どこへ流れるかを図で表す手法です。

用語一覧

用語	小分類	要点
API	システム要件定義・ソフトウェア要件定義	APIは、プログラム同士が機能やデータを利用し合うために定められた呼出し口です。
DFD	システム要件定義・ソフトウェア要件定義	DFD（データフロー図）は、データがどこから来てどう処理され、どこへ流れるかを図で表す手法です。
E-R 図	システム要件定義・ソフトウェア要件定義	E-R図は、データを「実体（エンティティ）」と「関連（リレーションシップ）」で表し、データ同士のつながりを図にする手法です。
GUI	システム要件定義・ソフトウェア要件定義	GUI（Graphical User Interface）は、アイコンやボタンなどを画面で見ながらマウスやタッチで操作する方式です。
HIPO（Hierarchy plus Input Process Output）	設計	HIPOは、機能を階層構造で分解し、各機能の入力・処理・出力を整理する設計手法です。
ISO 9000	設計	組織の品質マネジメントシステム（QMS）に関する国際規格群で、製品ではなく「品質を保つ仕組み」そのものを認証対象とする。
IoT	システム要件定義・ソフトウェア要件定義	IoTは、センサや機器をネットワークにつなぎ、状態取得や制御を行う仕組みです。
JIS X 25010	設計	ソフトウェア製品の品質を機能適合性・性能効率性・使用性など複数の品質特性で体系化した規格（ISO/IEC 25010の国内版）。
MVC モデル	設計	アプリケーションをModel（データと処理）・View（表示）・Controller（入力制御）の3つの役割に分けて設計するアーキテクチャパターン。
NS（Nassi-Shneiderman：ナッシシュナイダマン）図	設計	NS図は、プログラムの処理の流れを、矢印を使わず四角を入れ子にして表す図です。
NoSQL データベース	設計	NoSQLデータベースは、リレーショナルデータベース以外の柔軟なデータモデルを持つデータベースの総称です。
STS（Source Transform Sink）分割	設計	データの流れを「入力（Source）→変換（Transform）→出力（Sink）」の3つに着目してモジュール分割する構造化設計の技法。
SysML	システム要件定義・ソフトウェア要件定義	SysMLは、システム全体の構造や振る舞いを図で表すための、システム設計向けの表記法です。
TR（Transaction：トランザクション）分割	設計	入力された処理要求（トランザクション）の種類ごとに処理経路を振り分ける形でモジュールを分割する構造化設計の技法。
UML	システム要件定義・ソフトウェア要件定義	UMLは、ソフトウェアの構造や振る舞いを図で表すための標準的なモデリング記法です。
UX デザイン	システム要件定義・ソフトウェア要件定義	UXデザインは、利用者が製品やサービスを使うときの体験全体を、心地よく価値あるものに設計する取り組みです。
Web システム	設計	WebブラウザをクライアントとしHTTPで通信する、3層構造（プレゼンテーション・アプリケーション・データ）が代表的なシステム形態。
アクター	システム要件定義・ソフトウェア要件定義	アクターは、システムを利用したり、システムとやり取りする人や外部システムです。
アクティビティ	システム要件定義・ソフトウェア要件定義	アクティビティは、システムや業務における、一連の処理や作業の流れを表すものです。
アサーション	実装・構築	プログラムのある時点で「成り立っているはず」の条件を記述し、満たさなければ異常を検出する仕組み。
アルゴリズム	実装・構築	アルゴリズムは、ある問題を解くための明確な処理手順です。
アーキテクチャ	設計	アーキテクチャは、システムやソフトウェアの全体的な構造・設計方針のことです。
インスタンス	設計	クラス（設計図）をもとに実際にメモリ上に生成された個々の実体（オブジェクト）のこと。
インストール計画の作成	導入・受入れ支援	完成したソフトウェアを本番環境へ導入（インストール）するための、手順・日程・体制を定める計画作り。
インスペクション	設計	あらかじめ役割を決めた参加者が、定められた手順で文書やコードの欠陥を公式に検出するレビュー技法。
インタフェースファイル	システム要件定義・ソフトウェア要件定義	インタフェースファイルは、システム間でデータを受け渡すために使うファイルです。
インタフェース仕様	設計	モジュールや機器同士が情報をやり取りする際の、データの形式・項目・手順などを取り決めた仕様。
インタフェース設計	システム要件定義・ソフトウェア要件定義	インタフェース設計は、システムの各部分や外部との接点（やり取りの仕方）を設計することです。
インタフェース設計基準	設計	画面・帳票・通信などのインタフェースを設計するときに守るべき、統一的なルールや指針。
インデンテーション	実装・構築	プログラムの行頭に字下げ（インデント）を入れ、ブロックの入れ子構造を見やすく示すこと。
ウォークスルー	設計	ウォークスルーは、作成者が成果物を説明しながら、参加者で誤りを検討する非公式なレビュー方式です。
エピック	システム要件定義・ソフトウェア要件定義	エピックは、アジャイル開発で、大きなまとまりの要求を表す単位です。
エラー埋込法	実装・構築	わざと既知の誤りを仕込み、テストでそのうち何件発見できたかから、残存する未知の誤りの数を推定する手法。
エラー除去	実装・構築	テストやレビューで発見した誤り（バグ）を取り除き、品質を高めていく活動。
オンサイト保守	保守・廃棄	オンサイト保守は、保守員が現地に出向いて行う保守です。
オートインデント	実装・構築	コードを入力すると、構文に応じて自動で字下げ（インデント）を整える開発ツールの機能。
カプセル化	設計	データ（属性）とそれを操作する手続き（メソッド）を1つにまとめ、内部を外部から隠してアクセスを制限すること。
クライアントサーバシステム	設計	サービスを要求するクライアントと、それに応えるサーバに役割を分け、ネットワーク経由で処理を分担する方式。
クラス	設計	オブジェクトの共通の属性（データ）と操作（メソッド）をまとめて定義した設計図にあたるもの。
クリーンアーキテクチャ	設計	業務ルール（ドメイン）を中心に置き、UIやDBなどの技術的詳細を外側へ追い出して依存方向を内向きに統一する設計思想。
コンポーネントウェア	設計	部品化された再利用可能なソフトウェア（コンポーネント）を組み合わせてシステムを構築する考え方・技術。
コーディング	実装・構築	設計に基づき、プログラム言語を使って実際のソースコードを記述する実装作業。
コーディング方法及び作業標準の適切性	実装・構築	コーディングの手順や規約（作業標準）が、品質確保のために適切に定められ守られているかという観点。
コードインスペクション	実装・構築	ソースコードを対象に、役割と手順を定めて公式に欠陥を検出するインスペクション。
コードオーディター	実装・構築	ソースコードを自動で点検し、規約違反や品質上の問題を指摘する静的解析ツール。
コードレビュー	設計	作成されたソースコードを他者が読み、欠陥や規約違反、改善点を検出する品質確保の活動。
コード補完	実装・構築	入力中の文字から候補を予測して提示し、コーディングを効率化する開発環境の機能。
サイクロマティック複雑度	実装・構築	プログラムの分岐の多さから論理の複雑さを測る指標。値が大きいほど複雑でバグが入りやすい。
サブクラス	設計	上位のスーパークラスの属性・操作を継承し、独自の機能を追加・変更して作られる下位のクラス。
サーバレスアーキテクチャ	設計	サーバの管理を意識せず、イベント発生時に必要な処理だけを実行させるクラウド上の構築方式。
サービス	システム要件定義・ソフトウェア要件定義	サービスは、利用者に価値を提供する一連の機能や活動のまとまりを指します。
サービスの定義	システム要件定義・ソフトウェア要件定義	サービスの定義は、システムが提供するサービスの内容や範囲を明確に定めることです。
サービス記述	設計	Webサービスなどが提供する機能・呼び出し方法・データ形式を、利用者が使えるよう定めた仕様の記述。
システム利用文書	導入・受入れ支援	システムの操作方法や機能を利用者が理解できるよう記した、操作手引きなどの文書。
システム機能仕様	システム要件定義・ソフトウェア要件定義	システム機能仕様は、システムが備えるべき機能を具体的に定めた仕様です。
システム要件	統合・テスト	システム要件は、システムが満たすべき条件や、備えるべき内容を定めたものです。
システム運用部門	導入・受入れ支援	本番稼働後のシステムの運用・監視・障害対応などを担当する部門。
シナリオ	システム要件定義・ソフトウェア要件定義	シナリオは、利用者がシステムをどう使うかを、具体的な筋書きとして表したものです。
シンタックスハイライト	実装・構築	コードの予約語・文字列・コメントなどを色分け表示し、読みやすくする開発環境の機能。
ジャクソン法	設計	ジャクソン法は、入力データと出力データの構造に着目してプログラムを設計する技法です。
スタブ	実装・構築	スタブは、テストのときに、まだできていない下位のモジュールの代わりをする仮の部品です。
ストーリーポイント	システム要件定義・ソフトウェア要件定義	ストーリーポイントは、アジャイル開発で、作業の規模や難しさを相対的に表す見積りの単位です。
セキュリティ	設計	情報資産を機密性・完全性・可用性の観点から脅威から守る、システム品質特性の一つ。
セキュリティ実現方式	システム要件定義・ソフトウェア要件定義	セキュリティ実現方式は、セキュリティ要件を、どんな技術や仕組みで実現するかの方式です。
セキュリティ要件	システム要件定義・ソフトウェア要件定義	セキュリティ要件は、システムが守るべき安全性に関する条件を定めたものです。
ソフトウェアの試行利用	導入・受入れ支援	本格運用の前に、限られた範囲や期間で実際に使ってみて問題がないか確かめること。
ソフトウェアシステム要素	設計	ソフトウェアを構成する、まとまった機能を持つ部分（サブシステムやコンポーネント）のこと。
ソフトウェアユニット	設計	個別にテストや実装ができる、ソフトウェア構成の最小単位（モジュールや関数に相当）。
ソフトウェアユニット分割	設計	ソフトウェアの設計対象を、実装・テスト可能な最小単位（ユニット）へ分けていく作業。
ソフトウェアユニット機能仕様決定	設計	分割した各ユニットが何を入力し、どう処理し、何を出力するかという機能の仕様を確定する設計作業。
ソフトウェアユニット間インタフェース	設計	分割した各ソフトウェアユニットが互いにデータや制御を受け渡す際の接続部分の取り決め。
ソフトウェア利用文書	導入・受入れ支援	ソフトウェアの使い方や機能を説明した、利用者向けのマニュアル・ヘルプなどの文書。
ソフトウェア構成品目	システム要件定義・ソフトウェア要件定義	ソフトウェア構成品目は、構成管理の対象として識別・管理するソフトウェアの単位（プログラム・文書など）です。
ソフトウェア統合テスト仕様	設計	複数のユニットを結合して動かす統合（結合）テストで、何を・どの手順・どの基準で確認するかを定めた仕様。
ソフトウェア統合テスト報告書	統合・テスト	結合（統合）テストの実施結果・検出した欠陥・合否判定をまとめ、次工程へ引き継ぐための文書。
ソフトウェア統合及びテストの実現可能性	実装・構築	計画した結合（統合）とそのテストが、与えられた条件で実際に実施できるかを見極める観点。
ソフトウェア要件	統合・テスト	ソフトウェア要件は、ソフトウェアが満たすべき機能や条件を定めたものです。
ソフトウェア要素	設計	ソフトウェア要素は、ソフトウェアを構成する個々の部品（モジュールやコンポーネント）のことです。
ソフトウェア設計原則（SOLID）	設計	オブジェクト指向設計で保守性・拡張性を高めるための5つの原則の頭文字をまとめた指針。
チェックリスト	設計	チェックリストは、レビューやテストで確認漏れを防ぐために、確認項目を一覧化したものです。
テストの種類（機能テスト，非機能要件テスト，性能テスト，負荷テスト，セキュリティテスト，回帰テスト（リグレッションテスト）など）	統合・テスト	確認する観点ごとに分類したテストの総称。機能・性能・負荷・セキュリティ・回帰など目的別に使い分ける。
テストの種類（機能テスト，非機能要件テスト，性能テスト，負荷テスト，セキュリティテスト，回帰テスト（リグレッションテスト），探索的テストなど）	統合・テスト	目的別に分類したテストの総称。機能・性能・負荷・セキュリティ・回帰に加え、探索的テストも含む。
テストケース	実装・構築	テスト対象に与える入力と、それに対して期待される結果の組み合わせを定めた個々のテスト項目。
テストデータジェネレーター	実装・構築	テストに使うデータを、条件に従って自動的に大量生成するツール。
テスト実施者	実装・構築	定められた手順とケースに従って実際にテストを行い、結果を記録・報告する担当者。
テスト手順	統合・テスト	テストを実施する際の、準備・実行・結果確認・記録までの一連の進め方を定めたもの。
テスト方法論	実装・構築	テストをどんな考え方・進め方で体系的に行うかを定めた、テスト全体の方針や枠組み。
テスト準備（テスト環境，テストデータなど）	実装・構築	テスト準備は、テストを実施する前に環境やデータなど必要なものを整える作業です。
テスト範囲	実装・構築	今回のテストでどこまでを対象とし、何を対象外とするかを定めた範囲。
テスト網羅性	実装・構築	テストが対象の機能・命令・分岐などをどれだけ覆っているかを示す度合い（カバレッジ）。
テスト要件	システム要件定義・ソフトウェア要件定義	テスト要件は、何をどこまで・どんな条件でテストするかを定めた取り決めです。
テスト要求事項	設計	テストで何を・どこまで・どの基準で確認すべきかを定めた、テスト設計のもととなる要件。
テスト計画	統合・テスト	テスト計画は、テストを始める前に、目的・範囲・方法・体制・スケジュールなどを定めることです。
テスト設計と管理手法	実装・構築	効果的なテストケースを作る設計技法と、テストの進捗・品質を管理する手法の総称。
デザインレビュー	設計	設計工程の成果物（設計書）を関係者で点検し、欠陥や問題点を早期に発見・是正するレビュー。
デバッガ	実装・構築	プログラムの実行を制御しながら、不具合の原因箇所を調べるためのツール。
デバッグ環境	実装・構築	プログラムの不具合を調査・修正するために、デバッガやテストデータなどを整えた作業環境。
データストア	システム要件定義・ソフトウェア要件定義	データストアは、データフロー図で、データが蓄えられる保管場所を表すものです。
データフロー	システム要件定義・ソフトウェア要件定義	データフローは、データがどこからどこへ、どう流れていくかの流れを表すものです。
データベース	実装・構築	データベースは、業務データを一定の構造で蓄積し、検索・更新・共有しやすくする仕組みです。
データベース要件	システム要件定義・ソフトウェア要件定義	データベース要件は、データベースが満たすべき条件を定めたものです。
データモデリング	システム要件定義・ソフトウェア要件定義	データモデリングは、扱うデータの構造や関係を整理し、モデルとして表す作業です。
データモデル	設計	システムで扱うデータの構造・項目・データ間の関係を図や規則で表現したもの。
データ処理	実装・構築	入力したデータを、目的に応じて加工・集計・変換して出力する一連の処理。
トップダウンテスト	統合・テスト	上位モジュールから順に結合してテストする方式。未完成の下位の代わりにスタブを使う。
トレーサビリティマトリクス	システム要件定義・ソフトウェア要件定義	トレーサビリティマトリクスは、要件と成果物の対応関係を表にして追跡できるようにしたものです。
ドメインモデル	設計	対象業務（ドメイン）に登場する概念とその関係を、業務の言葉で表現したモデル。
ドメインロジック	設計	システムの中心となる、業務固有の判断・計算・ルールを担う処理部分のこと。
ドライバ	実装・構築	ドライバは、テストのときに、まだできていない上位のモジュールの代わりに下位を呼び出す仮の部品です。
ネスト	実装・構築	制御構造（if・ループなど）の中に、さらに別の制御構造を入れた入れ子の構造。
ハードウェア保守	保守・廃棄	ハードウェア保守は、機器（ハードウェア）の点検・修理・交換を行う保守です。
ハードウェア構成品目	設計	ハードウェア構成品目は、構成管理の対象として識別・管理するハードウェアの単位です。
ハードウェア要素	設計	システムを構成するうち、CPU・記憶装置・通信機器などの物理的な構成部分のこと。
バグ曲線	実装・構築	テスト期間中に累積で検出したバグ件数の推移を表したグラフ。品質の収束度を判断する。
バグ管理図	実装・構築	検出したバグの件数や、未解決・解決済みの推移を管理・可視化するための図表。
パッケージ	設計	関連するクラスやモジュールをまとめて整理する、論理的なグループ化の単位。
ヒアリング計画	システム要件定義・ソフトウェア要件定義	ヒアリング計画は、要件を聞き取る際の、対象・項目・進め方を事前に定めた計画です。
ヒアリング議事録	システム要件定義・ソフトウェア要件定義	ヒアリング議事録は、聞き取りで得た内容を記録し、共有・確認するための文書です。
ピアコードレビュー	実装・構築	同じ立場の開発者同士が、互いのソースコードを点検し合うレビュー。
ピアレビュー	設計	同じ立場の同僚（peer）同士が成果物を相互に点検し、欠陥や改善点を指摘し合うレビュー。
ファイルの分割	設計	処理効率や保守性を高めるため、1つのファイルを目的別・項目別などに複数へ分ける設計上の手法。
ファイルの統合	設計	複数のファイルに分散したデータを1つのファイルにまとめ、管理や処理を効率化する設計手法。
ファジング	統合・テスト	意図的に大量の不正・想定外データを入力し、異常な挙動や脆弱性を見つけるテスト手法。
ブラックボックステスト	設計	内部構造を見ず、仕様にもとづいて入力に対する出力が正しいかを確認するテスト技法。
ブレークポイント	実装・構築	デバッグ時に、プログラムの実行を一時停止させるためコードに設定する地点。
プログラム言語	実装・構築	コンピュータに処理手順を指示するための、文法を持った人工言語。
プロダクトバックログ	システム要件定義・ソフトウェア要件定義	プロダクトバックログは、開発する機能や要望を優先度順に並べた一覧です。
プロトタイプ	設計	完成前に動く試作品を作り、利用者に確認してもらって要件のずれを早期に正す開発手法・成果物。
プロトタイプ版評価	システム要件定義・ソフトウェア要件定義	プロトタイプ版評価は、試作品を利用者に評価してもらい、要件や設計を確認することです。
ホワイトボックステスト	設計	プログラムの内部構造・論理経路に着目し、命令や分岐を網羅するように確認するテスト技法。
ボトムアップテスト	統合・テスト	下位モジュールから順に結合してテストする方式。未完成の上位の代わりにドライバを使う。
マイクロサービスアーキテクチャ	設計	システムを、独立して開発・配置できる小さなサービスの集まりとして構成し、それらをAPIで連携させる設計様式。
メソッド	設計	オブジェクト（クラス）が持つ操作・振る舞いを定義した手続きのこと。
メトリクス計測	実装・構築	メトリクス計測は、ソフトウェアや開発の状態を数値（指標）で測ることです。
モジュールの制御領域	設計	あるモジュールから直接・間接に呼び出して制御できる下位モジュールの範囲。
モジュールの影響領域	設計	あるモジュール内の判定（条件分岐）の結果によって、処理が左右されるモジュールの範囲。
モジュール仕様	実装・構築	個々のモジュールが担う機能・入出力・処理内容を定めた、実装の根拠となる仕様。
モジュール再分割	設計	一度分割したモジュールの粒度や責務が適切でないとき、さらに分け直して構造を改善すること。
モデレーター	設計	インスペクションなどの公式レビューで、進行・調整・記録を取り仕切る進行役。
ユニットテスト	実装・構築	モジュールや関数といった最小単位（ユニット）を個別に検証する単体テスト。
ユビキタス言語	設計	開発者と業務担当者が共通して使う、業務領域（ドメイン）の用語をそろえた共通言語。
ユーザーインタフェース	設計	利用者とシステムが情報をやり取りする接点となる、画面・操作・表示などの仕組み。
ユーザーストーリー	システム要件定義・ソフトウェア要件定義	ユーザーストーリーは、利用者の視点で「誰が・何のために・何をしたいか」を短い文で表した要件です。
ユースケース	システム要件定義・ソフトウェア要件定義	ユースケースは、利用者がシステムを使って何を達成するか、その使い方のまとまりを表したものです。
ユースケース図	システム要件定義・ソフトウェア要件定義	ユースケース図は、利用者（アクター）がシステムをどう使うか、その機能の一覧と関係を表すUMLの図です。
ライフサイクルの評価	保守・廃棄	ライフサイクルの評価は、システムの企画から廃棄までの全体を通して評価することです。
リスク回避性	設計	利用時の品質モデルで、システムの利用が経済・健康・環境などへの危険を抑えられている度合い。
リバースエンジニアリング	保守・廃棄	リバースエンジニアリングは、完成したものを分析し、その構造や仕組みを解き明かすことです。
リファクタリング	保守・廃棄	リファクタリングは、プログラムの外から見た動作を変えずに、内部の構造を整理して分かりやすくすることです。
レコード処理	設計	ファイルやデータベースのデータを、1件分のまとまり（レコード）単位で読み書き・加工する処理。
レスポンスタイム	システム要件定義・ソフトウェア要件定義	処理を要求してから、最初の応答が返ってくるまでにかかる時間（応答時間）。
レビュー参加者	システム要件定義・ソフトウェア要件定義	レビュー参加者は、成果物レビューで作成者・レビューア・モデレータなどの役割を担う人たちです。
レビュー方式	システム要件定義・ソフトウェア要件定義	レビュー方式は、成果物の誤りを早期に見つけるために、関係者で内容を検討する進め方の種類です。
ワーニエ法	設計	ワーニエ法は、データの構造を出発点に、処理を段階的に分解してプログラムを設計する技法です。
一事実一箇所	設計	1つの事実（データ）はシステム内のただ1箇所にだけ持たせる、という設計・正規化の原則。
不具合の根本原因	導入・受入れ支援	表面化した不具合を生み出している、真の原因。これを除かないと再発を防げない。
予防保守	保守・廃棄	予防保守は、障害が起きる前に、未然に防ぐために行う保守です。
互換性	設計	互換性は、異なる環境・製品・バージョンの間でも、問題なく使えたり置き換えられたりする性質です。
仮想環境	導入・受入れ支援	1台の物理マシン上に、ソフトウェアで複数の独立したコンピュータ環境を作り出した環境。
伝票設計	システム要件定義・ソフトウェア要件定義	伝票設計は、業務で扱う伝票（注文書・納品書など）の様式や記入項目を決める設計作業です。
使用性	設計	JIS X 25010の品質特性の一つで、利用者が目的を達するためにどれだけ使いやすいかを表す。
使用性テスト	導入・受入れ支援	実際の利用者に操作してもらい、使いやすさ（使用性）に問題がないかを確かめるテスト。
保守のための文書作成	保守・廃棄	保守のための文書作成は、保守をしやすくするための文書を整備することです。
保守の実現可能性	保守・廃棄	保守の実現可能性は、開発するシステムを、稼働後に保守できるかどうかの見通しです。
保守テスト	保守・廃棄	保守テストは、保守による修正が正しく行われ、悪影響がないかを確認するテストです。
保守体制	保守・廃棄	保守体制は、システムの保守を行うための、担当者や役割分担の仕組みです。
保守契約	保守・廃棄	保守契約は、システムの保守について、提供する内容や条件を定めた契約です。
保守性	設計	保守性は、システムの修正や機能変更、障害対応をどれだけ容易に行えるかを表す品質特性です。
保守手順	保守・廃棄	保守手順は、保守作業を、どんな順序・方法で行うかを定めた手順です。
保守要件	システム要件定義・ソフトウェア要件定義	保守要件は、システムを稼働後に保守しやすくするための条件を定めたものです。
保守要件の定義	保守・廃棄	保守要件の定義は、稼働後の保守に必要な条件を、開発の早い段階で明確にすることです。
修正するシステム及び/又はソフトウェアや関連文書の決定	保守・廃棄	修正対象の決定は、問題に対し、どのシステム・ソフト・文書を直すかを定めることです。
修正実施の選択肢の用意	保守・廃棄	修正実施の選択肢の用意は、問題への対応方法の候補を複数挙げて検討できるようにすることです。
入出力設計	設計	システムが扱う入力（画面・帳票・データ）と出力の形式・項目・流れを決める設計作業。
入出力詳細設計	設計	入出力設計で決めた方針を、項目の桁数・データ型・編集規則などの実装可能な細部まで詰める設計。
共同レビュー	設計	発注者と受注者など立場の異なる関係者が共同で成果物を確認し、合意を取りながら欠陥や認識違いを正すレビュー。
共通機能分割	設計	複数の処理で重複して使われる機能を共通モジュールとしてくくり出し、独立させる分割手法。
内部一貫性	実装・構築	一つの成果物の中で、用語・記述・データなどが互いに矛盾していない状態。
再利用	設計	再利用は、一度作ったプログラムや部品を、別の開発でも繰り返し活用することです。
再利用性	設計	保守性の副特性の一つで、ソフトウェア部品を他の用途やシステムでどれだけ再び使えるかの度合い。
処理の周期	設計	バッチ処理などを、どのくらいの間隔（日次・週次・月次など）で繰り返し実行するかという時間的な単位。
処理能力	設計	一定時間内にシステムが処理できる仕事量を表す指標（スループットなど）。
分かりやすさ	設計	利用者がシステムの内容や操作方法を理解しやすい度合いで、使用性に関わる品質。
分割量	設計	1つのモジュールやファイルをどれくらいの大きさ・数に分けるかという分割の度合い。
分散処理	設計	処理を複数のコンピュータに分けて並行して行い、負荷分散や可用性向上を図る処理方式。
分解	設計	大きく複雑な対象を、扱いやすい小さな部分へ段階的に分けていく設計の基本手法。
判定条件網羅（decision coverage）	実装・構築	プログラム中の各判定（分岐）の真と偽の両方を、少なくとも1回ずつ通すテストの網羅基準。
利用の状況	システム要件定義・ソフトウェア要件定義	利用の状況は、システムが、どんな利用者にどんな状況で使われるかという文脈です。
利用状況網羅性	設計	利用時の品質モデルの特性で、想定した利用状況だけでなく多様な状況でも目標を達成できる度合い。
利用者作業範囲	設計	利用者作業範囲は、システムの利用において、利用者が担当する作業の範囲です。
利用者用文書類（ウィザード，学習書（チュートリアル），オンラインヘルプ）	導入・受入れ支援	利用者の習熟を助ける各種文書・案内。順を追って導くウィザード、学習用のチュートリアル、画面内ヘルプなど。
利用部門	導入・受入れ支援	システムを実際に使って業務を行う、利用者側の部門。
効率性	設計	利用時の品質モデルで、利用者が目標達成に使った資源（時間・労力など）に対する成果の割合。
動的テスト	実装・構築	プログラムを実際に実行して、入力に対する動作・結果を確認するテスト。
原因結果グラフ法	実装・構築	入力条件（原因）と出力（結果）の論理関係を図に表し、そこから効率的なテストケースを導く技法。
双方向の追跡可能性（双方向のトレーサビリティ）	システム要件定義・ソフトウェア要件定義	双方向の追跡可能性は、要件から成果物へも、成果物から要件へも両方向にたどれる性質です。
受入れテスト	導入・受入れ支援	受入れテストは、発注した利用者側が、納品されたシステムを受け入れてよいか確認する最終テストです。
受入れ体制	導入・受入れ支援	発注側が納品物を受け入れて確認・検収するために整える、担当者・役割・手順の枠組み。
受入れ基準	導入・受入れ支援	納品されたシステムを受け入れて良いと判断するための、合否のものさし（条件）。
受入れ手順	導入・受入れ支援	納品物を受け入れる際に、確認・テスト・判定・検収をどう進めるかを定めた手順。
各妥当性確認テストを実施するための環境条件	導入・受入れ支援	妥当性確認テスト（要件を満たすかの確認）を行うために必要な、ハード・ソフト・データなどの環境条件。
同値分析法	実装・構築	入力を、同じ結果になるグループ（同値クラス）に分け、各グループから代表値を選んでテストする技法。
周辺インタフェース要件	システム要件定義・ソフトウェア要件定義	周辺インタフェース要件は、外部システムや機器との接続に関して満たすべき条件です。
命令網羅	実装・構築	プログラム中のすべての命令（文）を、少なくとも1回は実行するテストの網羅基準。
品質特性	システム要件定義・ソフトウェア要件定義	品質特性は、ソフトウェアの品質を評価するための観点（性質）を分類したものです。
品質要件	システム要件定義・ソフトウェア要件定義	品質要件は、システムが備えるべき品質の水準を定めた条件です。
問題の再現又は検証	保守・廃棄	問題の再現・検証は、報告された問題を実際に再現させ、原因を確かめることです。
問題の是正	保守・廃棄	問題の是正は、特定した問題の原因を取り除き、正しく動くように修正することです。
問題報告又は修正依頼の分析	保守・廃棄	問題報告の分析は、報告された問題や修正依頼の内容を調べ、対応方針を判断することです。
問題管理手続の確立	保守・廃棄	問題管理手続の確立は、問題への対応の進め方を、あらかじめ手順として定めることです。
回帰テスト戦略	統合・テスト	回帰テスト戦略は、変更後にどの既存テストを再実行するかを決める考え方です。
回帰テスト（リグレッションテスト）	保守・廃棄	回帰テストは、修正によって、これまで正常だった部分に不具合が出ていないか確認するテストです。
外部一貫性	実装・構築	ある成果物が、関連する他の成果物や上流の要求と矛盾していない状態。
多相性	設計	同じメッセージ（操作呼び出し）に対し、オブジェクトの種類ごとに異なる振る舞いをさせられる性質。
妥当性確認テストの目的	導入・受入れ支援	完成したシステムが、利用者の本来の要求や業務目的を満たしているかを確認すること。
学んだ教訓の記録	導入・受入れ支援	プロジェクトや導入で得た成功・失敗の経験を記録し、今後の活動に生かすこと。
完全化保守	保守・廃棄	完全化保守は、性能や保守性を高めるなど、システムをより良くするための保守です。
実体	設計	データモデルで、管理対象となる人・物・事柄などのまとまり（エンティティ）。
実行環境要件	システム要件定義・ソフトウェア要件定義	実行環境要件は、システムを動かすために必要な環境の条件を定めたものです。
実装制約条件	システム要件定義・ソフトウェア要件定義	実装制約条件は、システムを作る際に守らなければならない制約や前提です。
実験計画法	実装・構築	少ない試行で複数の要因の影響を効率よく調べるための、統計にもとづく実験の組み方。
導入体制	導入・受入れ支援	システムを本番環境へ導入する作業を進めるために整える、担当者・役割・連携の枠組み。
導入作業	導入・受入れ支援	完成したシステムを本番環境へ設置し、稼働できる状態にするための一連の作業。
導入可否判断基準	導入・受入れ支援	システムを本番へ導入してよいかどうかを判断するための、満たすべき条件。
導入手順	導入・受入れ支援	システムを本番環境へ導入する作業を、どんな順序で進めるかを定めた手順。
導入要件	導入・受入れ支援	システムを本番に導入するうえで満たすべき、環境・条件・前提などの要求事項。
帳票設計	システム要件定義・ソフトウェア要件定義	帳票設計は、システムから出力する帳票（請求書・一覧表など）の様式を決める設計作業です。
廃棄計画などの利用者への通知	保守・廃棄	廃棄計画の通知は、システムを廃止する予定や内容を、利用者に知らせることです。
廃棄計画の立案	保守・廃棄	廃棄計画の立案は、システムを廃止する際の手順や対応を、計画として定めることです。
廃棄関連データの保持とアクセス可能性の確保	保守・廃棄	廃棄時のデータ保持は、システム廃止後も必要なデータを残し、使える状態に保つことです。
従属	設計	ある実体やデータが、他の実体の存在を前提として初めて意味を持つ関係（依存関係）。
性能効率性	設計	JIS X 25010の製品品質特性の一つで、使用する資源量に対してどれだけ性能を発揮できるかの度合い。
性能改良	保守・廃棄	性能改良は、システムの処理速度や効率などの性能を高める改善です。
成功基準（期待される結果）	導入・受入れ支援	導入やプロジェクトが成功したと判断するために、あらかじめ定めておく到達目標。
手作業	設計	手作業は、システムによる自動処理に対して、人が手で行う処理のことです。
手順	設計	処理や作業を、定められた順序で段階的に進めるための一連のステップ。
擬似コード	設計	実際のプログラム言語に依存せず、処理の流れを自然言語に近い簡潔な記述で表したもの。
改善作業	導入・受入れ支援	運用や導入で見つかった問題点を分析し、よりよい状態にするために手を加える作業。
改良保守	保守・廃棄	改良保守は、システムの機能や性能を改善・向上させるために行う保守です。
教育	システム要件定義・ソフトウェア要件定義	システムの利用者や運用者に、必要な知識・操作方法を身につけさせるための活動。
教育訓練システム（e-Learning，Web Based Training）	導入・受入れ支援	教育訓練システムは、利用者や運用担当者に業務手順やシステム操作を学ばせるためのe-LearningやWBTの仕組みです。
教育訓練資料	導入・受入れ支援	利用者や運用者への教育・訓練に用いる、手引きやテキストなどの資料。
文書化手法	設計	設計内容や処理の流れを、図や記法を使って分かりやすく記録・伝達するための手法。
新旧環境の並行運用と利用者の教育訓練	保守・廃棄	新旧を並行運用する移行期間中に、利用者へ新システムの操作教育・訓練を行う移行時の活動。
新旧環境の並行運用と旧環境の停止	保守・廃棄	新システムを旧システムと一定期間並行稼働させ、安定を確認してから旧環境を止める移行方式。
日常点検	保守・廃棄	日常点検は、システムが正常に動いているかを、日々確認する保守活動です。
旧環境関連データの保持と安全性確保	保守・廃棄	旧環境データの保持は、移行後も旧システムのデータを安全に残しておくことです。
是正保守	保守・廃棄	是正保守は、見つかった不具合（バグ）を取り除くために行う保守です。
是正処置	導入・受入れ支援	是正処置は、見つかった不具合や問題の「原因」を取り除き、再発を防ぐための対応です。
有効性	設計	有効性は、目的をどれだけ達成できたか、成果が出ているかの度合いです。
条件網羅	実装・構築	判定文に含まれる個々の条件について、真と偽の両方を少なくとも1回ずつ満たすテストの網羅基準。
検収	導入・受入れ支援	発注側が納品物を確認し、要件を満たしていると認めて正式に受け入れること。
検収基準	導入・受入れ支援	納品物を正式に受け取って良いと判断するための、検収時の合否のものさし。
業務モデリング	システム要件定義・ソフトウェア要件定義	業務モデリングは、業務の流れや構造を整理し、モデルとして表す作業です。
構造化	設計	処理を順次・選択・繰返しの基本制御構造だけで組み立て、分かりやすく保守しやすくする考え方。
構造化プログラミング	実装・構築	順次・選択・繰返しの3つの基本制御構造だけでプログラムを構成する設計・実装の考え方。
機能要件	システム要件定義・ソフトウェア要件定義	機能要件は、システムが「何をするか」、提供すべき機能を定めた要件です。
機能追加	保守・廃棄	機能追加は、稼働中のシステムに、新しい機能を加える改善です。
機能適合性	設計	JIS X 25010の品質特性の一つで、必要な機能が過不足なく正しく備わっているかの度合い。
欠陥	実装・構築	仕様や期待と異なる結果を生む原因となる、プログラムや成果物の誤り（バグ）。
欠陥修正	導入・受入れ支援	テストや運用で発見された欠陥（バグ）の原因を取り除き、正しく動くよう直す作業。
正規化	設計	正規化は、リレーショナルデータベースでデータの重複や更新時の不整合を減らすために表を整理することです。
段階的詳細化	設計	段階的詳細化は、大まかな処理から始め、少しずつ細かく分解していく設計の進め方です。
決定表（デシジョンテーブル）	システム要件定義・ソフトウェア要件定義	決定表（デシジョンテーブル）は、条件の組合せと、それに対応する処理を表の形で整理したものです。
流れ図	設計	処理の手順を、定められた記号と矢印を使って図で表したもの（フローチャート）。
満足性	設計	利用時の品質モデルの特性で、利用者がシステムを使ったときに得られる満足の度合い。
特化	設計	上位の一般的なクラスから、より具体的・限定的な下位クラスを派生させること（特殊化）。
画面設計	システム要件定義・ソフトウェア要件定義	画面設計は、利用者が操作する画面のレイアウトや入力項目、操作の流れを決める設計作業です。
監査	統合・テスト	開発の活動や成果物が、定めた基準・手順・規程に従って行われているかを独立した立場で検証すること。
移植性	設計	JIS X 25010の品質特性の一つで、別の環境（OS・ハード）へどれだけ移しやすいかの度合い。
移行結果の検証	保守・廃棄	旧システムから新システムへデータや処理を移した後、正しく移行できたかを確認する作業。
移行要件	システム要件定義・ソフトウェア要件定義	移行要件は、古いシステムから新しいシステムへ切り替える際に満たすべき条件を定めた要件です。
移行計画の文書化と検証	保守・廃棄	移行の手順・体制・スケジュール・切り戻し策などを文書にまとめ、内容の妥当性を事前に確認すること。
移行評価	保守・廃棄	移行評価は、システムの移行がうまくいったかどうかを確認・判定することです。
納品	導入・受入れ支援	完成した成果物（システムや文書）を、発注側に引き渡すこと。
組織の運用の完整性（integrity）	保守・廃棄	移行などの変更を経ても、組織の業務運用が一貫して正しく保たれている状態。
統合する順序	統合・テスト	統合する順序は、モジュールを組み合わせてテストしていく際の進め方（順番）のことです。
継承（インヘリタンス）	設計	上位クラス（スーパークラス）の属性や操作を、下位クラス（サブクラス）が受け継ぐ仕組み。
繰返し	設計	条件が成り立つ間、同じ処理を何度も実行する基本制御構造（ループ）。
複数条件網羅（multiple condition coverage）	実装・構築	複数条件網羅は、判定条件を構成する個々の条件の真偽の組合せをすべて少なくとも1回実行するテスト網羅基準です。
計画及び手続の作成	保守・廃棄	移行や導入を確実に行うため、実施計画と具体的な作業手続きをあらかじめ作成すること。
訓練	システム要件定義・ソフトウェア要件定義	利用者や運用者が、実際にシステムを操作して使いこなせるよう練習させる活動。
費用	システム要件定義・ソフトウェア要件定義	費用は、システムの開発や運用にかかるコストのことです。
追跡可能性	実装・構築	追跡可能性は、要件から成果物まで、つながりをたどって確認できる性質です。
運用シナリオ	システム要件定義・ソフトウェア要件定義	運用シナリオは、システムを実際にどう運用するかを、具体的な流れとして表したものです。
運用及び保守の実現可能性	実装・構築	開発するシステムを、実際に運用し保守し続けられるかを、設計・実装段階で見極める観点。
運用性	設計	システムを安定して運用・操作し続けやすい度合い。保守性や使用性に関わる品質の側面。
運用要件	システム要件定義・ソフトウェア要件定義	運用要件は、システムを稼働後に運用していくために満たすべき条件です。
運用規程	導入・受入れ支援	システムを安定して運用するために、運用作業の手順・ルール・責任を定めた規程。
遠隔保守	保守・廃棄	遠隔保守は、保守員が現地に行かず、ネットワーク経由で行う保守です。
適応保守	保守・廃棄	適応保守は、環境の変化に合わせて、システムを対応させるための保守です。
適用する妥当性確認テストの技法	導入・受入れ支援	妥当性確認テストを行う際に、目的に応じて選ぶテストの手法・進め方。
選択	設計	選択は、未整列部分から最小値または最大値を選び、先頭側へ移していく整列法です。
部品	設計	再利用を前提に、独立した機能のまとまりとして作られたソフトウェアの構成単位（コンポーネント）。
部品化	設計	部品化は、ソフトウェアを独立した部品（モジュール）に分けて作ることです。
開発の生産性	設計	一定の工数・期間でどれだけの開発成果を生み出せるかという効率の度合い。
開発プロセスからの保守に必要な成果物の引継ぎ	保守・廃棄	成果物の引継ぎは、開発で作った文書などを、保守担当へ確実に引き渡すことです。
関係者全員への廃棄の通知	保守・廃棄	廃棄の通知は、システムを廃止することを、関係者全員に確実に知らせることです。
関係者全員への移行の通知	保守・廃棄	関係者全員への移行の通知は、システム移行の日時・影響・変更点を、利用者や関係部門へ漏れなく事前周知する活動です。
関係者全員への移行計画などの通知	保守・廃棄	移行の計画やスケジュール・影響内容を、関係者全員へ事前に共有・周知すること。
関連	設計	関連は、データモデルなどで、ものとものとの間のつながり・関係を表す概念です。
限界値分析法	実装・構築	有効な範囲と無効な範囲の境目（境界値）に着目してテストケースを選ぶブラックボックス技法。
階層	設計	システムやモジュールを役割の上下関係で段階的に積み重ねて整理した構造。
障害	実装・構築	欠陥が実行された結果、システムが本来の機能を果たせなくなる、表に現れた不具合（故障）。
障害分析	実装・構築	障害分析は、発生した障害の原因や影響を詳しく調べることです。
障害対応	システム要件定義・ソフトウェア要件定義	障害対応は、システムに発生した障害に対処し、復旧させる一連の活動です。
集中処理	設計	1台のコンピュータに処理を集めて一括で行う方式。分散処理と対比される。
集約	設計	オブジェクト指向で、全体と部分の「持っている」関係（全体を構成する部分の集まり）を表す関連。
静的解析	実装・構築	プログラムを実行せず、ソースコードを解析して規約違反や潜在的欠陥を検出する手法。
非機能要件	システム要件定義・ソフトウェア要件定義	非機能要件は、システムが「どの程度の品質・条件で動くか」を定めた要件です。
順次	設計	処理を書かれた順に上から下へ1つずつ実行する、構造化の基本制御構造。

科目Aの問題演習に戻る科目Bの問題演習に戻る基本情報用語集トップ基本情報トップ