新人向け理解度テスト
実施方法
- 問題数：10問
- 満点：100点
- 合格目安：70点
- 制限時間：30分
- 教材を見ずに回答する
- 記述は文章または箇条書きでよい
問題
問1 開発プロセス全体【10点】
システム開発は、要件定義から突然始まるわけではありません。
要件定義より前に行われる活動を二つ以上挙げ、それらが必要な理由を説明してください。
問2 V字モデル【10点】
V字モデルにおいて、単体テスト・内部結合テスト・外部結合テストは、それぞれどの設計工程と対応関係しているでしょうか？なお、工程名称はプロジェクトによって異なることがあります。
問3 要件定義【10点】
要件定義の目的を説明してください。
また、BOMシステムの要件定義で整理すべき内容を二つ以上挙げてください。
問4 外部設計と内部設計【10点】
外部設計と内部設計の違いを、次の観点を含めて説明してください。
- 誰が読む設計書か
- 何を決める工程か
- どの程度まで具体化するか
問5 内部設計の本質【10点】
次の記述が適切であれば「○」、適切でなければ「×」を記入し、理由を説明してください。
外部設計書に書かれた論理名を物理名へ置き換え、SQLの論理名を物理名へ変更すれば、内部設計は完了したといえる。
回答：
理由：
問6 実装工程【10点】
実装工程で、プロジェクトメンバーがそれぞれ独自の判断でプログラムを作ると、どのような問題が発生しますか。また、その問題を防ぐために必要なことを説明してください。
問7 テスト設計とブラックボックステスト【10点】
ブラックボックステストとは、どのような考え方でテストケースを作成する方法ですか。
次の言葉を使って説明してください。
- 仕様書
- 期待結果
- 実装の中身
問8 テスト実施と証跡【10点】
テスト証跡は、どのような状態で残す必要がありますか。
また、画面からデータを登録する機能をテストする場合に、必要になる証跡の例を二つ以上挙げてください。
問9 内部結合テストと外部結合テスト【10点】
内部結合テストと外部結合テストの違いを説明してください。
問10 受入テストから本番稼働【10点】
受入テストで、現場担当者から次の意見が出ました。
「このシステムでは実際の業務を行えません。必要な機能が足りていません」
この問題を防ぐため、要件定義や外部設計ではどのような対応が必要でしょうか。
解答・採点基準
問1 解答例
要件定義より前には、業務設計、業務課題の整理、システム化範囲の検討、PoC、製品やベンダーの選定などが行われる。
業務の目的や課題が整理されていなければ、何をシステム化するべきか決められない。また、技術的に実現可能か、どの製品やベンダーが適しているかを確認する必要がある。
採点基準
- 活動を二つ以上挙げている：5点
- 業務を整理する必要性を説明：5点
問2 解答例
要件定義→外部結合テスト
外部設計→内部結合テスト
内部設計→単体テスト
採点基準
- 外部結合テストと対応する設計工程の記載：3点
- 内部結合テストと対応する設計工程の記載：3点
- 単体テストと対応する設計工程の記載：4
問3 解答例
要件定義の目的は、何をシステム化し、システムで何を実現するかを明確にすることである。
BOMシステムでは、次のような内容も整理する。
- BOMにどのようなバリエーションがあるか
- 製品/部品/工程の特徴
- 設計BOMと製造BOMの違い
- 品番変更や構成変更の管理方法（差分を登録 or 変更後の構成を登録）
採点基準
- 要件定義の目的：5点
- BOMシステムの要件定義で整理する内容を二つ以上：5点
問4 解答例
外部設計は、顧客の業務担当者が読んで、業務が実現できるかを確認するための設計である。画面、帳票、機能の動きなどを、業務上理解できる言葉で記載する。
内部設計は、開発者が実装できるレベルまで仕様を具体化する設計である。クラス構成、物理テーブル、処理フロー、データ構造、例外処理などを決める。
採点基準
- 外部設計の読者：3点
- 外部設計の目的・内容：2点
- 内部設計の読者：3点
- 内部設計の目的・内容：2点
問5 解答例
回答：×
内部設計の目的は、名前を論理名から物理名へ変更することではない。
外部設計で決めた仕様について、処理の順番、データの持ち方、クラスやメソッド、例外処理、トランザクションなどを、実装者が迷わないレベルまで具体化する必要がある。
採点基準
- 「×」を選択：5点
- 本来決める内容を説明：5点
問6 解答例
各担当者が独自の方法で実装すると、命名、クラス構成、エラー処理、ログ、SQLなどが統一されず、品質や保守性がばらつく。
品質をそろえるためには、コーディング規約、命名規則、共通部品、エラー処理などのルールを決め、迷った場合にはチームで認識を合わせる必要がある。
採点基準
- 品質がばらつくことを説明：3点
- ルールの共有を説明：3点
- チームでの認識合わせを説明：2点
問7 解答例
ブラックボックステストは、プログラムの中身や実装方法を見ずに、仕様書をもとにテストケースを作る方法である。
ある入力を行ったときに、仕様書で定められた期待結果になるかを確認する。
採点基準
- 仕様書をもとにする：3点
- 入力と期待結果の関係を説明：4点
- プログラムの中身を前提にしない：3点
問8 解答例
テストを実施していない第三者が見ても、何を操作し、どのような結果になり、なぜOKと判断したのかが分かる状態で証跡を残す。
証跡の例は次のとおり。
- 登録前後の画面
- 入力内容
- 完了メッセージ
- 登録前後のデータベース
- 出力された帳票やファイル
- ログ
採点基準
- 第三者が判断できることを説明：5点
- 適切な証跡を二つ以上：5点
問9 解答例
内部結合テストでは、１つのシステムの中で複数の機能を業務の流れとしてつなぎ、正しく処理できるかを確認する。
外部結合テストでは、複数のシステムが連携して、業務を処理できるかを確認する。
採点基準
- 外部結合テストを説明：5点
- 内部結合テストを説明：5点
問10 解答例
要件定義や外部設計では、特定の担当者だけでなく、関係する部署や実際にシステムを利用する現場担当者にも確認する必要がある。
業務フローや画面設計を使って、実際の業務を行えるか確認し、打ち合わせの決定事項や合意内容を議事録として残す。
本番稼働リハーサルや並行稼働では、実際の業務手順やデータを使い、システムだけでなく、業務、運用、担当者の動きまで問題なく成立するかを確認する。
システムの利用頻度や業務サイクルに応じて、1日のリハーサルや数週間の並行稼働を行い、その後に旧システムから新システムへ切り替えるカットオーバーを行う。
採点基準
- 現場担当者を含めて確認する：10点