ソフトウェア開発管理技術の用語
全70語。
ソフトウェア開発組織やプロジェクトのプロセスの成熟度を、段階で評価するためのモデル。
⚠ 開発の進め方の型（プロセスモデル）や、取引のための共通フレームと取り違えやすい。CMMI は「評価する」モデル。
品質管理とバグ・修正コストの見積り
開発規模（行数）が分かっていることを前提に、式で工数と工期を見積もる方法。
⚠ FP法は規模を求める方法、COCOMOは規模を入力にして工数・工期を求める方法。
開発規模と工数の見積り
Java のバイトコード（中間コード）を実行する仕組みで、これがあれば Java アプリケーションが動く。
⚠ サーブレットの説明問題で「インタプリタ」「バイトコードを実行」とあれば Java VM の説明。
成果物の管理・解析とコード設計
Java VM さえあれば、Web ブラウザも Web サーバも使わずに単体で動く Java プログラム。
⚠ アプレット（ブラウザが必要）、サーブレット（Web サーバが必要）との違いは「VM だけで動く」こと。
成果物の管理・解析とコード設計
サーバからダウンロードして、クライアント側の Web ブラウザ上で実行される Java プログラム。
⚠ サーブレットと名前が似ている。「ダウンロードしてクライアントで実行」ならアプレット。
成果物の管理・解析とコード設計
クライアントの要求に応じて、Web（アプリケーション）サーバ上で実行される Java プログラム。
⚠ アプレット（ダウンロードしてブラウザで実行）と混同しやすい。過去問の選択肢（JavaScript・アプレット・サーブレット・VBScript）の中で「Web サーバ上だけで動く」のはサーブレット。ただし一般論としてサーバ側の技術がサーブレットだけというわけではない。
成果物の管理・解析とコード設計
Java のプログラムをアプリケーションの部品として扱うための規約。
⚠ サーブレットの説明問題で「部品として取り扱う規約」とあれば JavaBeans。
成果物の管理・解析とコード設計
続けること・問題だったこと・次に試すことの 3 つで振り返る手法。
⚠ タイムライン・チームレーダー・ドット投票も振り返りの手法だが、この 3 区分を使うのは KPT。
アジャイル開発（XP とスクラム）
プロジェクトの作業を階層的に細かく分解した一覧。
⚠ WBS の完了数は進捗の指標で、品質の指標ではない。
品質管理とバグ・修正コストの見積り
ペアプログラミングやテスト駆動開発など、プログラマの作業習慣を軸にしたアジャイル手法。
⚠ スクラムはチームの進め方（役割・イベント・バックログ）が軸。「プラクティス」という語はアジャイル全般で使うので決め手にならない。問題文に XP と明示されているか、選択肢がペアプロ・TDD・CI・計画ゲームなら XP、スプリント・プロダクトオーナ・イベントならスクラムと判断する。
アジャイル開発（XP とスクラム）
短い期間で動くものを作って見せ、反応を見て計画を直すことを繰り返す開発の進め方の総称。
⚠ ウォータフォール：工程を順に一度だけ進める。工程を各スプリントに割り当てる選択肢はウォータフォール的な考え方で誤り。
アジャイル開発（XP とスクラム）
プロジェクトの開始時に、目的や方針をチームと関係者で共有するための資料。
⚠ テスト完了の確認には使わない。
アジャイル開発（XP とスクラム）
既知のエラーをわざと埋め込んでテストし、その発見率と本物のエラーの発見率が等しいとみなして、残存エラー数を推定する方法。
⚠ 推定で出るのはまず本物のエラーの総数。残存数は総数から発見済みの数を引いて求める。
品質管理とバグ・修正コストの見積り
設計・製造などの工程を並行して進めて、開発期間を短くする手法。
⚠ 名前が似ているだけで、解析とは関係ない。キーワードは「並行」。
成果物の管理・解析とコード設計
固定長のスプリントを繰り返し、3 つの役割と決まったイベントでチームを回すアジャイル手法。
⚠ XP（作業習慣が軸）と混同しない。
アジャイル開発（XP とスクラム）
チームの進捗を妨げる問題を取り除き、自律的に動けるよう支援する役割。
⚠ バックログの並び順を決めるのはプロダクトオーナ。
アジャイル開発（XP とスクラム）
1 か月以内の固定長の開発期間で、毎回リリース判断できるインクリメントを作る単位。
⚠ 生産量の尺度はベロシティ。スプリントは期間。
アジャイル開発（XP とスクラム）
そのスプリントで達成する目標で、リリース判断できるインクリメントを作るために設定する。
アジャイル開発（XP とスクラム）
スプリントの最後に、チームの進め方を振り返って改善策を決めるイベント。
⚠ 成果物を確認するのはスプリントレビュー。
アジャイル開発（XP とスクラム）
スプリントの終わりに、作った成果物を関係者に見せて確認するイベント。
⚠ レトロスペクティブは「やり方」の振り返りで、レビューの後に行う。
アジャイル開発（XP とスクラム）
人の油断や心理の隙を突いて、パスワードなどの情報を盗み出す攻撃手口。
⚠ 開発手法ではなくセキュリティの用語。
成果物の管理・解析とコード設計
コードの入力ミスを見つけるために、各桁から計算して末尾に付ける1桁の数字。
成果物の管理・解析とコード設計
開発者が毎日同じ時間と場所で短く集まり、進捗・今日の予定・障害を共有するイベント。
⚠ プランニング・レビュー・レトロスペクティブはスプリントごとに 1 回で、毎日は行わない。
アジャイル開発（XP とスクラム）
先にテストを書いて失敗させ、通す最小限のコードを書き、リファクタリングする手順を繰り返す開発方法。
⚠ コードを書いた後でテストケースを作るのは TDD ではない。
アジャイル開発（XP とスクラム）
縦軸に残作業量、横軸に時間を取り、残作業が 0 に向かって減っていく様子で進捗を見るグラフ。
⚠ 右上がりのバーンアップチャート、バスタブ曲線、信頼度成長曲線と軸と形で見分ける。
アジャイル開発（XP とスクラム）
利用者から見た機能（入出力・照会・ファイル）の数と複雑さから点数を出し、補正してソフトウェアの規模を見積もる方法。
⚠ 類推見積法（過去の類似実績）、標準タスク法（作業分解して積算）、COCOMO（規模を前提に工数と工期を出す）と区別する。FP法が出すのは規模。
開発規模と工数の見積り
設計情報からソースコードなどを生成する、通常の向きの開発手法。
⚠ リバースエンジニアリングと向きが逆。「設計情報から自動生成」ならフォワード。
成果物の管理・解析とコード設計
メンバーが見積りの数字が書かれたカードを同時に出し合い、作業規模を見積もる手法。
⚠ TDD の手順ではない。
アジャイル開発（XP とスクラム）
作るプログラムの行数（ステップ数）を積算して開発規模を見積もる方法。
⚠ 選択肢で「ステップ数を積算」とあればこれ。FP法は行数ではなく機能の数で測る。
開発規模と工数の見積り
プロダクトバックログアイテムを作り、内容と優先順位（並び順）を決める役割。
⚠ スクラムマスタは障害の除去やチーム・バックログ管理の「支援」をする。「決める」のがプロダクトオーナ。
アジャイル開発（XP とスクラム）
プロダクトに必要な機能や改善を優先順位付きで並べた一覧で、プロダクトに 1 つ置き、継続的に更新する。
⚠ 最初に全部確定させる、チームごとに作る、プロダクトゴールを含めない、はいずれも誤り。
アジャイル開発（XP とスクラム）
2 人で 1 つのプログラムを書き、役割を交替しながらその場で相談・チェックし合う方法。
⚠ 2 人でメインとサブを分担する分業や、プログラマと利用者で試作を見るプロトタイピングとは違う。
アジャイル開発（XP とスクラム）
チームが 1 スプリントで終えた作業量を、ストーリーポイントなどで相対的に表した尺度。
⚠ スプリント（期間）、バックログ（作業一覧）、レトロスペクティブ（振り返り）と混同しない。
アジャイル開発（XP とスクラム）
既存のソフトウェアを分析・理解したうえで、全体を新しく作り直すこと。
⚠ リバースは解析だけ、リエンジニアリングは作り直しまで行う。
成果物の管理・解析とコード設計
プログラムの構造を整理し直すこと（再構造化）。
⚠ 仕様や設計を取り出す手法ではないので、リバースエンジニアリングとは違う。
成果物の管理・解析とコード設計
既存のソフトウェアやDB定義を解析して、仕様や設計の情報を取り出す手法。
⚠ フォワードエンジニアリングは逆向き（設計情報 → コード）。リエンジニアリングは解析したうえで作り直すところまで含む。
成果物の管理・解析とコード設計
外部から見た振る舞いを変えずに、プログラムの内部構造を改善すること。
⚠ リバースエンジニアリングと混同しやすい。「振る舞いを変えずに」が出てきたらリファクタリング。
成果物の管理・解析とコード設計
プログラムの動きを変えずに、内部の構造を読みやすく保守しやすく整えること。
⚠ 機能追加やバグ修正とは別物。「次のイテレーションまでしない」は誤り。
アジャイル開発（XP とスクラム）
各工程の成果物を一元管理する場所で、作業効率を上げ、用語の統一にも役立つ。
⚠ 不良管理・手順定義・進捗管理のツールと混同しやすい。キーワードは「成果物の一元管理」。
成果物の管理・解析とコード設計
設計書やプログラムなどの成果物を人が読み、誤りや問題点を見つける作業。
⚠ テストはプログラムを動かして確かめる作業。レビューは動かさずに読んで確かめる。
品質管理とバグ・修正コストの見積り
WBS で分解した作業のうち、最も下の単位で、担当や見積りを割り当てる単位。
品質管理とバグ・修正コストの見積り
実際の業務に近い環境と手順で、システムが運用に耐えるかを確かめる最終段階のテスト。
品質管理とバグ・修正コストの見積り
成果物を修正して新しい版にするときに通す、決められた承認と記録の手順。
成果物の管理・解析とコード設計
作るソフトウェアの大きさで、FP値・行数・画面数などで表す。
⚠ 工数とは別物。規模を生産性で割ると工数になる。
開発規模と工数の見積り
他のシステムが管理していて、対象システムは参照だけするデータのまとまり。
⚠ 自分で更新するなら内部論理ファイル。
開発規模と工数の見積り
計算や加工をした結果を、帳票や画面としてシステムの外へ出す機能。
⚠ 外部照会は加工せずにそのまま返す。加工があれば外部出力。
開発規模と工数の見積り
入力をきっかけに、保存データを加工せずに取り出して返す機能。
⚠ 外部出力との違いは、計算などの加工をするかどうか。
開発規模と工数の見積り
画面・帳票・操作など、利用者から見えるシステムの振る舞いを決める設計。
⚠ 内部設計はプログラム内部の構造を決める設計。外部設計の誤りはマニュアルにも波及するので、修復コストがより高い。
品質管理とバグ・修正コストの見積り
システムの外からデータを受け取って処理する機能。
⚠ 外部照会は入力に応じて検索結果を加工せずに返す機能。
開発規模と工数の見積り
チェックディジットの計算で、合計を割るときに使う数（例：11、10）。
⚠ 基数で割った「余り」と「基数 − 余り」を取り違えないこと。問題文の手順に従う。
成果物の管理・解析とコード設計
起こりうる値を、その起こりやすさで重み付けした平均的な見込み値。
品質管理とバグ・修正コストの見積り
システム開発や取引にかかわる作業内容や用語を共通化し、発注側と受注側が同じ言葉で話せるようにした枠組み。
⚠ CMMI の説明の誤り選択肢として出る。成熟度の評価は CMMI。
品質管理とバグ・修正コストの見積り
各自のコードを頻繁に結合し、そのたびにテストを繰り返すこと。
アジャイル開発（XP とスクラム）
XP で、顧客と開発者が次に作る機能と見積りを話し合って決めるプラクティス。
⚠ 相互チェックで品質を上げるのはペアプログラミング。
アジャイル開発（XP とスクラム）
仕事の量を「人数×期間」で表したもので、人月や人日で数える。
⚠ 期間（何か月かかるか）と混同しやすい。工数＝要員数×期間で、10人月は「10人で1か月」でも「2人で5か月」でもよい。
開発規模と工数の見積り
プログラムや文書のバージョンと、その組み合わせを管理し、どの版がどれかを分かるようにする活動。
⚠ 品質管理と並べて出る。バージョンは構成管理の対象であり、品質の指標ではない。
品質管理とバグ・修正コストの見積り
成果物の版とその対応関係、変更の手続を管理して、どれが最新で、どれとどれが対応しているかを常に分かるようにすること。
⚠ 進捗管理・品質管理と混同しやすい。対象が「成果物の版」なら構成管理、作業の進み具合やバグ・レビュー結果なら別の管理。
成果物の管理・解析とコード設計
構成管理の対象になる個々の成果物（プログラム・仕様書・設計書など）。
成果物の管理・解析とコード設計
チェックディジットの計算で、データの各桁に掛ける決められた数。
成果物の管理・解析とコード設計
要求定義や設計など、開発の前半にあたる工程。
⚠ 下流工程（プログラミング・テスト）と比べ、上流で入った誤りほど後で直すコストが高い。
品質管理とバグ・修正コストの見積り
1人が1か月働いたときの作業量の単位。
⚠ 人日は1人が1日働く量。問題ごとにどちらの単位か確かめる。
開発規模と工数の見積り
1人が単位期間あたりにこなせる規模で、例えば「1人月あたり10FP」のように表す。
⚠ 規模から工数を出すのに必要なのは生産性。開発期間・要員数・工程配分比率は工数を出したあとに使う。
開発規模と工数の見積り
プログラムに含まれているが、まだ見つかっていない不良。
品質管理とバグ・修正コストの見積り
プログラム規模当たりに含まれる潜在不良の件数で、0.04件/kステップのように表す。
⚠ 年間発見率（その年に見つかる割合）とは別物。件数を出すのが潜在不良率、その年の分を出すのが年間発見率。
品質管理とバグ・修正コストの見積り
見積り対象のシステム自身が持ち、更新するデータのまとまり。
⚠ 外部インタフェースファイルは他システムが持ち、参照だけするデータ。
開発規模と工数の見積り
成果物の版（バージョン）を記録し、仕様書・設計書・プログラムの版の対応を取れるようにすること。
成果物の管理・解析とコード設計
作業を単位作業まで分解し、それぞれに基準の工数を当てて積み上げる見積り方法。
⚠ 「単位作業項目まで分解」「基準値の積算」とあればこれ。画面数×1画面あたり工数の計算もこの考え方。
開発規模と工数の見積り
成果物ごとのレビュー時間やバグ数・バグ密度など、成果物の品質を数字で把握するための目安。
⚠ ワークパッケージの完了数（進捗）、個人の生産性、プログラムのバージョン（構成管理）は品質指標ではない。
品質管理とバグ・修正コストの見積り
成果物が求められた品質を満たしているかを、計画・測定・改善する活動で、機能・性能・ドキュメントなどすべての成果物を対象にする。
⚠ 進捗管理（どこまで終わったか）や構成管理（どの版か）と混同しやすい。品質管理は「出来の良さ」を扱う。
品質管理とバグ・修正コストの見積り
システム全体の複雑さや特性に応じて未調整FPに掛ける調整用の倍率。
⚠ 重み付け係数は機能1個ごとの点数、補正係数は最後に全体へ掛ける倍率。
開発規模と工数の見積り
機能ごとの個数×重み付け係数を合計した、補正前のFP値。
⚠ 最終的なFP値はこれに補正係数を掛けた値。掛け忘れが定番のひっかけ。
開発規模と工数の見積り
過去の似たシステムの実績を基に、違う部分を調整して規模や工数を見積もる方法。
⚠ 選択肢で「過去の類似」「相違点」とあればこれ。FP法ではない。
開発規模と工数の見積り