システム開発技術の要点とまちがえやすい点（ITパスポート試験 論点テキスト）

このページの論点

マネジメント系｜開発技術｜12論点・要点59本・まちがえやすい点35本・式1本

• システム開発技術
  • 要件定義・外部設計・内部設計の違い
  • 要件追跡・変更管理・フィットギャップ分析
  • V字モデルとテスト工程の対応関係
  • ブラックボックス・ホワイトボックステスト技法
  • カバレッジ基準（命令・分岐・条件網羅）
  • スタブ・ドライバと各種テストの目的
  • ソフトウェアレビューの技法と心得
  • データの流れ・状態を表す設計図表
  • ISO/IEC 25010の品質特性
  • ソフトウェア保守の4分類
  • 新旧システムの移行方式とデータ検証
  • ソフトウェアの見積り手法と工数の単位

システム開発技術

要件定義・外部設計・内部設計の違い

要件定義から外部設計、内部設計へ進む各工程が何を定めるかを扱い、利用者から見える仕様と内部の作りの区別が問われる。

要点

• 要件定義は、利用者の業務上のニーズや要求を整理し、システムが満たすべき機能や制約を開発側と利用者側の共通の理解として明確化する工程である。
• 基本設計以降の工程は、要件定義で確定した内容を前提に画面やデータベース等を具体化する工程であり、要件そのものを定める段階ではない。
• 外部設計（基本設計）は、画面・帳票・入出力など、利用者から見える仕様を定める設計工程である。
• 内部設計（詳細設計）は、外部設計で定めた仕様を実現するために、システム内部のデータ構造や処理の分割、モジュール構成を決める工程である。

まちがえやすい点

• 外部設計は画面や帳票など利用者から見える部分を設計する工程であり、プログラムの内部構造やモジュール分割を決める内部設計とは異なる。
• 要件定義は要求の明確化を行う工程であり、システムの動作を検証するシステムテストや、内部構造を定める内部設計ではない。

要件追跡・変更管理・フィットギャップ分析

要求と成果物の対応付け、変更要求の承認統制、パッケージ標準機能との差分分析という、開発を支える管理活動を扱う。

要点

• トレーサビリティ管理は、要求事項と設計書・プログラム・テストケースなどの成果物との対応関係を追跡可能な形で管理する活動である。
• トレーサビリティ管理は、要求の実装漏れの防止や、変更時の影響範囲の把握に役立つ。
• 変更管理は、変更要求の受付から影響評価、承認判断、実施までを統制するプロセスであり、承認された変更のみを統制された手順で実施させる。
• フィットギャップ分析は、自社の業務要件とパッケージの標準機能を比較し、そのまま使える部分と追加開発や業務変更が必要な差分を洗い出す分析である。

まちがえやすい点

• 変更管理は変更要求の承認統制を行う活動であり、成果物の版を識別・記録する構成管理や、既存機能への影響を確認するリグレッションテストではない。
• トレーサビリティ管理は要求と成果物の対応関係の追跡に主眼を置く活動であり、成果物のバージョンや変更履歴を管理する構成管理とは目的が異なる。
• フィットギャップ分析は標準機能との差分を洗い出す分析であり、他社との比較を行うベンチマーキングや、強み弱みを整理するSWOT分析とは別である。

V字モデルとテスト工程の対応関係

単体・結合・システム・受入の各テストが設計工程のどれに対応し、誰が何を確認するかの区別を扱う。

要点

• 単体テストは、詳細設計の内容がモジュール単位で正しく実装されているかを検証するテストである。
• 結合テストは、基本設計で定めたモジュール間のインタフェースや連携が正しく動作するかを検証する工程である。
• システムテストは、結合を終えたシステム全体を対象に、機能だけでなく性能・負荷・セキュリティ・他システムとの連携が要件を満たすかを開発者側が検証するテストである。
• 受入テストは、発注者（利用者側）が納品前に、要求した機能や業務の流れどおりにシステムが使えるかを自ら確認するテストであり、合格すると検収となる。
• テストは単体、結合、システム、運用（受入れ）の順に、確かめる範囲を広げていく。
• 受入れテストは、完成したシステムが要求どおりに業務で使えるかを、発注者や利用者の立場で確認する、検収前のテスト。

まちがえやすい点

• システムテストは開発側が本番同等環境で全体を検証する工程であり、発注者・利用部門が実際の業務条件で最終確認を行う受け入れテストとは実施主体と目的が異なる。
• 結合テストは基本設計に対応してモジュール間の連携を検証するテストであり、詳細設計に対応する単体テストや要件定義に対応するシステムテストとは対応する工程が異なる。
• 運用テストは実際の業務での利用に耐えるかを検証するテストであり、詳細設計の内容を検証する単体テストとは対応する上流工程が異なる。
• システムテストは全体を通して要件を満たすかを確かめる段階であり、部品どうしのやり取りを確かめる結合テストとは扱う範囲が異なる。

ブラックボックス・ホワイトボックステスト技法

内部構造に着目する手法と入出力に着目する手法の違い、同値分割・限界値分析・決定表といった技法の着眼点を扱う。

要点

• ホワイトボックステストは、プログラム内部のロジックや処理経路に着目し、条件分岐などが仕様どおりに網羅されているかを確認する手法である。
• ブラックボックステストは、内部構造を意識せず入出力に着目する手法であり、同値分割法や限界値分析はその具体的な技法である。
• 限界値分析は、有効範囲・無効範囲の境界値付近を重点的に検査し、境界条件の誤りを見つけやすくする技法である。
• 同値分割は、入力を仕様上同じ動作をするグループ（同値クラス）に分け、各グループから代表値を1つずつ選んでテストケースとし、テスト件数を効率化する技法である。
• デシジョンテーブル（決定表）は、複数の条件の組み合わせとそれに対応する動作を表形式で整理し、組み合わせ漏れを防ぎながらテストケースを設計する技法である。

まちがえやすい点

• 同値分割は各グループから代表値を選ぶ技法で境界値には着目せず、境界値付近を重点的に検査する限界値分析とは異なる。
• 判定条件網羅はホワイトボックスの網羅基準であり、入力をグループに分けて代表値を選ぶブラックボックスの同値分割ではない。
• リグレッションテストは修正や機能追加によって既存の機能が壊れていないかを確認するテストであり、新機能が仕様どおり動くことだけを確認するものではない。

カバレッジ基準（命令・分岐・条件網羅）

ホワイトボックステストの網羅基準について、命令網羅・分岐網羅・複数条件網羅の厳しさの順序と定義を扱う。

要点

• 命令網羅（ステートメントカバレッジ）は、プログラム中のすべての命令を少なくとも1回実行することを基準とする、最も基本的で緩やかな網羅基準である。
• 分岐網羅（デシジョンカバレッジ）は、各条件分岐について真・偽の両方の経路を少なくとも1回通過することを基準とし、命令網羅より厳密に分岐経路を検証できる。
• 複数条件網羅は、判定を構成する各条件式の真偽の全組合せを実行する、最も厳しい網羅基準である。

まちがえやすい点

• 命令網羅は分岐の真偽を区別せず命令の実行有無のみに着目する緩やかな基準であり、真偽両方の経路を通る分岐網羅ではない。
• 条件網羅は各条件の真偽を1回ずつ実行する基準であり、条件の全組合せまで実行する複数条件網羅とは別である。

スタブ・ドライバと各種テストの目的

結合テストの代用モジュール、回帰テスト、負荷テスト、信頼度成長曲線、静的解析など、目的別のテストと分析手法を扱う。

要点

• スタブは、トップダウンテストで未結合の下位モジュールの代わりに用いる、呼び出され応答するだけの簡易な代用モジュールである。
• ドライバは、ボトムアップテストで未結合の上位モジュールの代わりにテスト対象を呼び出し、結果を検証する代用モジュールである。
• 回帰テスト（リグレッションテスト）は、修正・改修によって既存の正常だった機能に悪影響が生じていないかを、既存のテストケースを再実行して確認するテストである。
• 負荷テスト（性能テスト）は、実運用を想定した高い負荷をシステムにかけ、応答時間や処理件数などの性能要件を満たすかを検証するテストである。
• 信頼度成長曲線は、累積バグ検出数の推移をプロットし、曲線が横ばいに近づくことでバグの摘出が収束し品質が安定したと判断する目安となる。
• 静的解析は、プログラムを実行せずソースコードを解析し、コーディング規約違反や潜在的な誤りなどを検出する手法である。

まちがえやすい点

• スタブは上位から結合するトップダウンテストで用いる代用モジュールであり、ボトムアップテストで用いるドライバとは役割も名称も異なる。
• 回帰テストは既存機能への悪影響の確認を目的とし、高負荷時の性能を見る負荷テストや、利用者による最終確認である受け入れテストとは目的が異なる。
• 静的解析はプログラムを実行しない点で、実際に実行して確認する動的テストや、高負荷のストレステスト、回帰テストとは別である。
• 負荷テストは高負荷時の性能を検証するテストであり、個々のモジュール単位を検証する単体テストや、内部構造に着目するホワイトボックステストとは目的の観点が異なる。

ソフトウェアレビューの技法と心得

インスペクションとウォークスルーの形式性の違い、およびレビューを行う時期と対象の考え方を扱う。

要点

• インスペクションは、事前準備・役割分担・公式記録を伴う最も形式的なレビュー技法であり、作成者以外の視点を交えて客観的に欠陥を検出する。
• ウォークスルーは、成果物の作成者が主体となって進行するカジュアルなレビューで、正式な議事録を必須としない。
• レビューは、動くものができる前の設計書や仕様書の段階でも行われ、早い段階で欠陥を見つけるほど修正の費用は小さくて済む。
• レビューの対象は成果物であって人ではなく、レビューの場では作成者の人格を責めない。
• コードレビューは、プログラムのソースコードを作成者以外の開発者が読み、誤りや規約違反、改善点を見つけて指摘する活動。

まちがえやすい点

• ウォークスルーは作成者が主体で公式記録を必須としない簡易な形式であり、第三者を交えた形式的なレビューであるインスペクションとは異なる。
• インスペクションは最も形式的なレビューであり、参加者が持ち回りで主導するラウンドロビン・レビューとは形式性の高さが異なる。
• レビューは担当者の評価を下げる場ではなく、評価を下げる場にすると欠陥を隠す動機が生まれ、レビューの目的そのものが損なわれる。

データの流れ・状態を表す設計図表

DFD、状態遷移図、状態遷移表が何を表現するかを扱い、他の図表との着目点の違いが問われる。

要点

• DFD（データフローダイアグラム）は、データの発生源・処理（プロセス）・データストアなどを記号で表し、データの流れに着目してシステムを図式化する手法である。
• 状態遷移図は、対象が取り得る状態と、イベントの発生に伴う状態間の遷移を、状態と矢印を用いて表現する図である。
• 状態遷移表は、状態とイベントの組合せに対して遷移先や処理を格子状の表にまとめ、状態遷移の定義漏れや矛盾を確認しやすくした表現方法である。

まちがえやすい点

• 状態遷移図は状態の変化を表す図であり、データの流れを表すDFDや、データの実体間の関連を表すE-R図、作業のスケジュールを表すガントチャートとは目的が異なる。
• DFDはデータの流れに着目する図であり、データの実体と関連を表すE-R図や、作業の順序関係を表すアローダイアグラムとは着目点が異なる。
• 状態遷移表は状態とイベントの組合せを格子状に整理するものであり、条件の組合せと動作の対応を示す決定表ではない。

ISO/IEC 25010の品質特性

機能適合性・性能効率性・使用性・信頼性・保守性・移植性・セキュリティなど、品質特性それぞれの意味の区別を扱う。

要点

• 機能適合性は、ソフトウェアが明示的・暗示的なニーズを満たす機能をどの程度提供できているかを表す品質特性である。
• 性能効率性は、与えられた資源量のもとで、応答時間・処理量・資源使用量など求められる性能を発揮できるかを表す品質特性である。
• 使用性は、利用者が製品を理解・習得し、目的の達成のために容易に操作できる度合いを表す品質特性である。
• 信頼性は、定められた条件・期間で、要求された機能を安定して実行し続ける度合いを表す品質特性である。
• 保守性は、不具合の修正や機能追加などの変更を効果的・効率的に行える度合いを表す品質特性である。
• 移植性は、ソフトウェアをある実行環境から別の実行環境へ移し替える際の容易さを表す品質特性である。
• セキュリティは、認可された者だけがアクセスでき、不正使用や改ざんから守る度合いを表す品質特性である。

まちがえやすい点

• 保守性は変更のしやすさを表す特性であり、別の実行環境へ移し替える際の容易さを表す移植性とは別である。
• 信頼性は安定稼働の度合いを表す特性であり、操作のしやすさを表す使用性や、資源に対する性能を表す性能効率性とは異なる。
• 互換性は他製品や環境との共存・情報交換のしやすさを表す特性であり、利用者にとっての使いやすさを表す使用性ではない。

ソフトウェア保守の4分類

是正保守・適応保守・完全化保守・予防保守がそれぞれ何を契機・目的とする保守かの区別を扱う。

要点

• 是正保守は、稼働中のソフトウェアで発見された不具合（バグ）を修正する保守である。
• 適応保守は、OSのバージョンアップや関連法制度の改正など、外部環境の変化に合わせてソフトウェアを変更する保守である。
• 完全化保守は、性能の向上や保守のしやすさの改善など、機能や品質を積極的に高めるために行う保守である。
• 予防保守は、まだ障害として顕在化していないが将来不具合につながるおそれのある箇所を、問題が発生する前に検出して修正する保守である。

まちがえやすい点

• 是正保守は顕在化した不具合の修正を行う保守であり、将来の障害を未然に防ぐ予防保守とは契機が異なる。
• 適応保守は外部環境の変化への対応を目的とし、発見した不具合を修正する是正保守や、性能や保守性を改善する完全化保守とは目的が異なる。

新旧システムの移行方式とデータ検証

一斉移行方式と並行運用方式の特徴・負担の違い、および移行したデータの突合による検証を扱う。

要点

• 一斉移行方式は、定めた期日に旧システムを停止し新システムへ全面的に切り替える方式で、移行期間が短く済む一方、新システムに不具合があった場合の業務への影響が大きい。
• 並行運用方式は、新旧システムを一定期間並行稼働させ、処理結果を比較しながら新システムの信頼性を確認したうえで旧システムを廃止する方式である。
• 並行運用方式は移行のリスクを抑えられる一方、二重運用による人的・費用的負担が大きい。
• データ移行検証は、新システムへ移行したデータが旧システムのデータと件数や内容の面で過不足なく一致しているかを突き合わせて確認する作業である。

まちがえやすい点

• 一斉移行方式は旧システムを即座に停止する方式であり、新旧を並行稼働させる並行運用方式ではない。
• データクレンジングはデータの誤り・重複・表記ゆれを整備する作業であり、移行したデータを旧システムと突き合わせて確認するデータ移行検証とは目的が異なる。

ソフトウェアの見積り手法と工数の単位

ファンクションポイント法・類推見積法・COCOMO・デルファイ法の着眼点の違いと、人月という工数の単位を扱う。

要点

• ファンクションポイント法は、入力・出力・内部論理ファイル・外部インタフェース等の機能の数と複雑さを点数化し、その合計値をもとに開発の規模や工数を見積もる手法である。
• ファンクションポイント法は、プログラミング言語やコーディングスタイルに左右されにくく、要件定義等の早い段階から見積りに利用しやすい。
• 類推見積法は、過去に実施した類似プロジェクトの実績データ（規模・工数・コスト等）を参考に、新たなプロジェクトの規模や工数を推定する手法である。
• 類推見積法は、プロジェクトの初期段階など詳細な情報が少ない時点でも、比較的簡便に見積りができる。
• COCOMOは、プログラムの推定規模（ソースコード行数）を基本パラメータとし、複雑さなどの補正係数を用いて工数や期間を数式で算出する見積りモデルである。
• 人月は、1人が1か月間作業した場合の量を基準単位とし、要員数と作業期間（月数）の積で工数全体を表す単位である。
• デルファイ法は、複数の専門家に匿名で意見を求め、集約結果のフィードバックと再質問を繰り返して意見を収束させる手法である。
• 相対見積は、作業の大きさを人日などの絶対値でなく、基準とする作業と比べた相対的な大きさで見積もる方法。

まちがえやすい点

• ステップ数はプログラムの行数を表す規模の単位であり、要員数と期間の積で表す工数の単位である人月とは別である。
• ファンクションポイント法は機能の数と難易度を点数化する手法であり、プログラムの規模を基にするCOCOMOとは着目する指標が異なる。
• 類推見積法は過去の類似実績を基準にする手法であり、機能の数と難易度を点数化するファンクションポイント法とは根拠とするデータが異なる。
• 見積りは要件が具体化するほど精度が上がるため、工程の節目で見直すのが通常であり、初期の見積りを固定したまま進めるものではない。

式

• 工数（人月）要員数×作業期間（月数）1人が1か月間働いた作業量が1人月

ほかのページ

出典と作り方

この読み物は、IPA「ITパスポート試験 シラバス Ver.6.5」の中分類の順に、アプリ「ITウカール」の収録問題の解説をもとにアプリ製薬が作成したものです。公式の文章の転載ではありません。問題文・選択肢は載せていません。

• ITパスポート試験 シラバス Ver.6.5（IPA）