> ## Content Index
> Fetch the complete content index at: https://www.geekjp.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 【基本情報処理技術者試験】最新問題のテクノロジ系をまったり解く　問４６～問５０　【令和元年度秋試験】
- URL: https://www.geekjp.com/2019-11-18-142904/
- Published: 2019-11-18T05:29:04.000Z
- Updated: 2019-11-18T05:29:04.000Z
- Description: R01 基本情報技術者試験 秋期試験に挑戦 基本情報技術者試験 （ＦＥ）の問題をまったり解いていきます。 ＩＰＡの資格試験は、過去問からの出題率が高く、確実に合格するためにはどの区分の試験を受けるにしても過去問学習は大事です。 また、独学でも受験可能ですが、用語が多く初めは戸惑うと思います。が、過去問を十分に学習することで合格点に届くラインまでは問題を解けるようになるとおもいます。今は、オンラインやＷＥＢでもたくさんの解説ページがありますが、Ｗｅｂの情報はどこまでうのみにしていいのかわからない部分もありますので、一応書籍を１～３冊ほど買っておくと確実だと思います。 以下に、私のおすすめ書籍を…
- Author: 工学じじい
- Tags: コンピュータサイエンス, 技術, 情報処理技術者試験, #Import 2026-07-19 20:21, #Import 2026-07-19 20:24

## R01基本情報技術者試験 秋期試験に挑戦

基本情報技術者試験（ＦＥ）の問題をまったり解いていきます。  
ＩＰＡの資格試験は、過去問からの出題率が高く、確実に合格するためにはどの区分の試験を受けるにしても過去問学習は大事です。  
また、独学でも受験可能ですが、用語が多く初めは戸惑うと思います。が、過去問を十分に学習することで合格点に届くラインまでは問題を解けるようになるとおもいます。今は、オンラインやＷＥＢでもたくさんの解説ページがありますが、Ｗｅｂの情報はどこまでうのみにしていいのかわからない部分もありますので、一応書籍を１～３冊ほど買っておくと確実だと思います。

以下に、私のおすすめ書籍を挙げておきますので、よかったら参考にしてください。

|  |
|  |
|  |
  
  
キタミ式イラストIT塾 基本情報技術者 平成31/01年 (情報処理技術者試験)  
  
最近話題のキタミ式です。解説に漫画や、図表が多く、ビジュアルで訴えてくれるので、繰り返し見ているうちに頭に残りやすいです。  
ただ、Amazon等のレビューにもありますが、解説ってよりは用語の羅列とか辞書のような、書き方になっているので、大事なところがわかりづらいという意見も多いです。  
  
  
|  |
|  |
|  |

  
平成31/01年 イメージ&クレバー方式でよくわかる 栢木先生の基本情報技術者教室  

こちらも有名な、栢木先生シリーズです。イメージはキタミ式と似ていて、図表を多く取り入れており、少し勉強したことがある人なら、頭に書いていることが残りやすいかもしれません。ただ、全くの初学者にとっては、謎の文字と図の羅列に見えてしまうことがありそうです。  
現在新版の予約受付中のようです。  

|  |
|  |
|  |

  
平成31年【春期】/01年【秋期】基本情報技術者 合格教本  
  
後は、これを一冊リファレンスとして持っておけば大丈夫かと思います。  
これ3冊そろえたら、たいてい合格できるんじゃない？って三兄弟です。  
kindle版もありますので、ぜひ通勤途中や、通学途中にお気に入りの音楽でも聴きながら見てみてください！

それでは、今回も問題解いていきまーす。

### 令和元年度 基本情報技術者試験 午前問題 問４６～問５０

#### 令和元年度 基本情報技術者試験 午前問題 問４６

モジュール結合度が最も弱くなるものはどれか。

| ア | 一つモジュールで、できるだけ多くの機能を実現する                     |
| - | -------------------------------------------- |
| イ | 二つのモジュール間で必要なデータ項目だけを引数として渡す                 |
| ウ | ほかのモジュールとデータ項目を共有するためにグローバルな領域を使用する。         |
| エ | ほかのモジュールを呼び出すときに、呼び出したモジュールの論理を制御するための引数を渡す。 |

#### 解説

ソフトウェアを設計するときのモジュール分割の問題です。  
学生の時、ソフトウェア設計演習の先生に、C言語でモジュールを作るとか言われて、このおっさん何言ってんだ？って思ってましたが、このような設計の概念はオブジェクト指向言語が普及して結構理解しやすくなったのではないかなと思います。C言語では、厳密には違うのかもしれないですがモジュール＝関数と思ってもまぁまぁ間違いではないと思います。

まず用語についてまとめてみたいと思います。  
モジュールと似たような意味で使われる言葉に以下のようなものがあります。

| モジュール | コンポーネント |
| ----- | ------- |
| ライブラリ | パッケージ   |
| プラグイン | セグメント   |

  
なんとなくぼんやり、文脈に従って使っていましたが、まじめに意味を調べてまとめてみます。

| モジュール   | １つの機能単位で分割されたプログラムを指す。入出力のインターフェースが規格化されていて、同規格において容易に追加や削除、交換ができる。C言語でいえば単独でコンパイルできる単位になる。 |
| ------- | ------------------------------------------------------------------------------------------- |
| コンポーネント | 何らかの機能を持ったプログラムの部品。単独では意味をなさず、ほかのプログラムと組み合わせて使う。                                            |
| ライブラリ   | 様々なモジュールを集めて一つにまとめたもの。                                                                      |
| パッケージ   | 様々なライブラリを集めて一つにまとめたもの。                                                                      |
| プラグイン   | ある機能への拡張機能を提供するためのプログラムやモジュール                                                               |

まとめてもいまいちわからないw  
とりあえずモジュールは、一つの機能をもって分割されたプログラムの部品＝C言語では入出力を規定された関数と思っておけばいいかなと思いました。

次に、モジュール結合度ですが、モジュール分割を行う際に設計したモジュール同士の関係性の評価として以下のようなことが言われています。

|           | 良い設計例                                                | 悪い設計例                            |
| --------- | ---------------------------------------------------- | -------------------------------- |
| モジュール分割   | モジュール分割技法を使って、適切にモジュールを分割する。・STS分割・トランザクション分割・共通機能分割 | モジュール分割を行わない。または、個人的なモジュール分割を行う。 |
| モジュールの凝集度 | 高い（機能的凝集／情報的凝集）                                      | 低い（論理的凝集）                        |
| モジュール結合度  | 弱い（データ結合／スタンプ結合）                                     | 強い（共通結合／外部結合／制御結合）               |

問題となっているモジュール結合度は、モジュール間の関連性の強さを示す尺度です。モジュール結合度が弱いほど、モジュールの独立性は高くなります。

| 内容結合   | 外部宣言していないデータを他のモジュールが直接に参照・更新           |
| ------ | --------------------------------------- |
| 共通結合   | 複数のモジュールが共通領域のデータ構造を共有して参照・更新           |
| 外部結合   | 外部宣言されたデータを複数のモジュールで共有。必要なデータのみを外部宣言する。 |
| 制御結合   | 機能コードを受け渡し、呼ばれたモジュールの実行を制御する。           |
| スタンプ結合 | データの構造体を受け渡す。呼ばれたモジュールは構造体の一部を使用する。     |
| データ結合  | 処理に必要なデータのみを受け渡す。モジュール間での機能的な関係はない。     |

これを知らなくても、内容から考えてモジュール同士の独立性が高くなりそうなのを選べばいいんですけど、全部見ていきます。

| ア | 一つモジュールで、できるだけ多くの機能を実現する |
| - | ------------------------ |

上で出てきた、モジュールの凝集度の話でモジュール間の結合性の話ではないので×  
  
| イ | 二つのモジュール間で必要なデータ項目だけを引数として渡す |
| - | ---------------------------- |

データ結合の説明に合致します。一番結合度の低い設計です。  
  
| ウ | ほかのモジュールとデータ項目を共有するためにグローバルな領域を使用する。 |
| - | ------------------------------------ |

外部結合や共通結合の説明です。外部にデータ構造を持っているときが共通結合、単一データの時が外部結合になります。  
  
| エ | ほかのモジュールを呼び出すときに、呼び出したモジュールの論理を制御するための引数を渡す。 |
| - | -------------------------------------------- |

制御結合の例ですね。

正解は「イ」

ちなみに、かなりいろいろなところで間違えていますが、モジュールの凝集度の説明で**暗号的凝集**と書いているところがかなり多いですが、英語の**Coincidental cohesion**を訳したもので、「暗合的」または、「偶発的」が正しいです。  
凝集度の話は、また今度！  
  
  
#### 令和元年度 基本情報技術者試験 午前問題 問４７

エラー埋め込み法において、埋め込まれたエラー数を S、埋め込まれたエラーのうち発見されたエラー数を ｍ、埋め込まれたエラーを含まないテスト開始前の潜在エラー数を T、 発見されたエラー数をｎとしたとき、S, T, m, n の関係を表す式はどれか。  
  
| ア | \\(\\frac{m}{S} = \\frac{n -m}{T}\\) |
| - | ------------------------------------ |
| イ | \\(\\frac{m}{S} = \\frac{T}{n -m}\\) |
| ウ | \\(\\frac{m}{S} = \\frac{n}{T}\\)    |
| エ | \\(\\frac{m}{S} = \\frac{T}{n}\\)    |

#### 解説

ソフトウェアに潜在するエラー数を推定する方法である、エラー埋め込み法の問題です。プログラムに意図的にエラーを埋め込んだ状態でテストを行い、テストで発見された埋め込みエラー数からまだ発見されていない潜在エラー（真のエラー）数を推測する手法です。

S ＝ 埋め込まれたエラー数  
m ＝ 埋め込まれたエラーのうち発見されたエラー数  
T ＝ 埋め込まれたエラーを含まないテスト開始前の潜在エラー数  
n ＝ 発見されたエラー数

埋め込まれたエラーの発見率と、潜在的に存在するエラーの発見率は同じになるはずです。  
潜在的に存在するエラーのうちテストで発見された数は、全発見エラー数ー埋め込みエラー数のうち発見されたエラー数  
＝n-m

埋め込まれたエラーの発見率は、\\(\\frac{m}{S}\\)  
潜在エラーの発見率は、\\(\\frac{n-m}{T}\\)

したがって、以下が成り立ちます。

\\(\\frac{m}{S} = \\frac{n-m}{T}\\)

#### 令和元年度 基本情報技術者試験 午前問題 問４８

テストで使用するスタブまたはドライバの説明のうち、適切なものはどれか。

| ア | スタブは、テスト対象モジュールからの戻り値の表示・印刷を行う。   |
| - | --------------------------------- |
| イ | スタブは、テスト対象モジュールを呼び出すモジュールである。     |
| ウ | ドライバは、テスト対象モジュールから呼び出されるモジュールである。 |
| エ | ドライバ、引数を渡してテスト対象モジュールを呼び出す。       |

#### 解説

テスト環境におけるダミーの利用に関する問題です。  
複数人での開発現場では、前問のようにモジュール分けをしてモジュールごとの開発を行っていきますが、テスト段階ですべてのモジュールが完成していないと、完全なテストは行えません。そこで、開発済みのモジュール以外は、テスト用の入出力だけを実装したダミーモジュールを使って、開発されたモジュールをテストしていきます。このように、上位と下位のモジュールをつなぎ合わせて繰り返し試験する手法を「結合テスト」と呼びます。

結合テストは大きく分けて２種類あり、

1. テスト対象のモジュールを呼び出すダミーモジュールを作成し、問題がなければ本物の呼び出しモジュールと置き換えて、最上位の呼び出しモジュールまでをテストするボトムアップテスト
2. テスト対象のモジュールに呼び出されるダミーモジュールを作成し、問題がなければ本物の呼び出されるモジュールと置き換えて、最下位の呼び出されるモジュールまでをテストするトップダウンテスト

![f:id:gomta777:20191118113647p:plain](https://www.geekjp.com/content/files/images/import/hatena/2019/11/20191118113647.png "f:id:gomta777:20191118113647p:plain")

図 結合テスト

これらを踏まえて選択肢を見ていきます。

| ア | スタブは、テスト対象モジュールからの戻り値の表示・印刷を行う。 |
| - | ------------------------------- |

スタブはテスト対象から呼び出されるダミーモジュールですので、これはなんか違います。

| イ | スタブは、テスト対象モジュールを呼び出すモジュールである。 |
| - | ----------------------------- |

スタブはテスト対象から呼び出されるダミーモジュールです。ドライバなら正解ですね。

| ウ | ドライバは、テスト対象モジュールから呼び出されるモジュールである。 |
| - | --------------------------------- |

逆にドライバはテストモジュールを呼び出すためのダミーモジュールです。スタブなら正解ですね。

| エ | ドライバ、引数を渡してテスト対象モジュールを呼び出す。 |
| - | --------------------------- |

ドライバは、テストモジュールを呼び出して結合テストを行いますので、これが正解です。

以上から、正解は「エ」です。  
  
  
#### 令和元年度 基本情報技術者試験 午前問題 問４９

単一の入り口を持ち、入力項目を用いた複数の判断を含むプログラムのテストケースを設計する。命令網羅と条件判定網羅の関係のうち、適切なものはどれか。

| ア | 判定条件網羅を満足しても、命令網羅を満足しない場合がある。  |
| - | ------------------------------ |
| イ | 判定条件網羅を満足するならば、命令網羅も満足する。      |
| ウ | 命令網羅を満足しなくても、判定条件網羅を満足する場合がある。 |
| エ | 命令網羅を満足するならば、判定条件網羅も満足する。      |

#### 解説

前問に続き、単体（ユニット）テスト関連の出題です。  
単体テストは、モジュールの仕様のどの部分に注目してテストするかによって以下の２つに分類されます。

| ホワイトボックステスト | プログラムの内部構造に注目し、論理を実現するために使われている命令や、分岐が正しく動作するか、といった部分についてチェックをする。      |
| ----------- | ---------------------------------------------------------------------- |
| ブラックボックステスト | モジュールの外から見た機能（入出力）に着目し、入力データと出力データの結果だけに着眼し、それが仕様書どおりに正しく処理されているかを調べる。 |

問題文を読むと、内部の処理構造に注目しているのでホワイトボックステストについての出題であることがわかります。

- 関数・メソッド中のすべての命令を実行する命令網羅（ステートメントカバレッジ）
- 分岐条件の全てで真/偽の両方の分岐を通るようにする判定条件網羅（デシジョンカバレッジ、または分岐網羅、ブランチカバレッジ）

などを行うので、条件や、命令を網羅するための値の抽出が必要で、抽出した条件から、どの程度の条件を満たしたかという網羅率（カバレッジ）の解析を行ったりします。

プログラムの中で、処理の通り道が切り替わるのは条件分岐の処理のみです。  
したがって、テストの時にすべてのパターンを網羅しない可能性があるのは、分岐の全パターンを網羅していない時です。  
逆に言うと、すべての処理パターンを網羅していても、すべての分岐パターンは網羅できません。

言葉で書くと、ちょっとわかりづらいですね(笑)  
図で見てみます、色のついた矩形が「処理」を表しています。

![f:id:gomta777:20191118130854p:plain](https://www.geekjp.com/content/files/images/import/hatena/2019/11/20191118130854.png "f:id:gomta777:20191118130854p:plain")

図 処理の分岐

条件網羅でのテストを考えてみます。  
存在するすべての条件分岐に対して、Yes、No全てを通るようにテストするので、以下のようになります。

![f:id:gomta777:20191118131301p:plain](https://www.geekjp.com/content/files/images/import/hatena/2019/11/20191118131301.png "f:id:gomta777:20191118131301p:plain")

図 条件網羅

次に、命令網羅でのテストを考えてみます。

![f:id:gomta777:20191118130843p:plain](https://www.geekjp.com/content/files/images/import/hatena/2019/11/20191118130843.png "f:id:gomta777:20191118130843p:plain")

図 命令網羅

命令網羅では、命令がすべて実行されるようにテストを行いますが、分岐に関しては、命令が実行されるほうのみテストされますので、左図のように条件をすべてテストするわけではないのがわかります。

これを踏まえて、選択肢を見ていきます。

| ア | 判定条件網羅を満足しても、命令網羅を満足しない場合がある。 |
| - | ----------------------------- |

条件判定網羅をしているとすべての分岐を通るようにテストしますので、命令網羅は必ず満たされます。ので×です。

| イ | 判定条件網羅を満足するならば、命令網羅も満足する。 |
| - | ------------------------- |

これは、合ってそうですね。

| ウ | 命令網羅を満足しなくても、判定条件網羅を満足する場合がある。 |
| - | ------------------------------ |

命令を網羅を満足していなくても、判定条件網羅を満足する場合は、ないですよね。判定条件網羅ではすべての分岐を通っていますので、命令はすべて網羅されます。が、逆はないですよね。

| エ | 命令網羅を満足するならば、判定条件網羅も満足する。 |
| - | ------------------------- |

これも、ウと同じ理由で×ですね。

答えは「イ」です。なんかほとんど国語の問題。。。

#### 令和元年度 基本情報技術者試験 午前問題 問５０（テクノロジ系最終問題）

XP（eXtreme Programming)において、プラクティスとして提唱されているものはどれか。  
  
  
| ア | インスペクション  | イ | 構造化設計     |
| - | --------- | - | --------- |
| ウ | ペアプログラミング | エ | ユースケースの活用 |

#### 解説

XP（eXtreme Programming)は、アジャイル開発手法の代表格です。  
従来行われてきたウォーターフォール型などの、要件定義から段階的に上流工程から下流工程へ進む手法では、前の工程への変更や修正に対して融通が利かないという弱点がありました。  
これらを、開発工程を小さな部分に分け、小さな開発サイクルを繰り返して開発を進めるという手法です。

その中で、４つの価値、１４の原則、１９のプラクティス

４（５）つの価値

- コミュニケーション
- 単純さ
- フィードバック
- 勇気
- (リスペクト）

１４の原則

| 人間性 | 経済性   | 相互利益     | 自己相似性   | 改善  |
| --- | ----- | -------- | ------- | --- |
| 多様性 | ふりかえり | 流れ       | 機会      | 冗長性 |
| 失敗  | 品質    | ベイビーステップ | 責任の引き受け |     |

１９のプラクティス

- 共同のプラクティス
1. イテレーション
2. 共通の用語
3. オープンなワークスペース
4. ふりかえり
- 開発のプラクティス
1. テスト駆動開発
2. ペアプログラミング
3. リファクタリング
4. ソースコードの共同利用
5. 継続的インテグレーション
6. YAGNI(You ain't gonna need it)
- 管理者のプラクティス
1. 責任の受け入れ
2. 援護
3. 四半期ごとの見直し
4. ミラー
5. 最適なペース
- 顧客のプラクティス
1. ストーリー
2. リリース計画
3. 受入テスト
4. 短期リリース

これを、如実に実行できる現場は少ないと思いますが、アジャイル開発では著名な開発手法です。

答えは「ウ」ペアプログラミングです。

ペアプログラミングでは、支援者と作業差に分かれて１台の端末を共有しながら開発を進めます。  
ペアは、或る程度の時間で入れ替えや交代を行うのが良いとされています。  
  
  
### 次回予告

今回で、テクノロジ系の問題全問解説しました。  
次は、どこに向かおうか迷っています(笑)

  
良かったら、押してください！↓↓↓  
  
にほんブログ村