11-01　ア
　エラーの発見が遅れると、そこまで行ってきた作業が無駄になり
　やり直しになるのでコストがかかる


11-02　エ
　バーコードには価格は含まれない
　国コード、メーカコード、商品アイテムコード、チェックディジットの順


11-03　イ
　モジュールなので単体テスト
　内部構造を考慮しないのでブラックボックステスト


11-04　ウ
　ISBNは本に割り振られた番号
　ITFは物流分野で用いる段ボールに印字する一次元バーコード
　全銀協コードは各銀行に割り振られた銀行コードを定めたもの


11-05　ウ
　後で見た時にわかりやすくすることが目的なので、ウ以外は該当しない


11-06　イ
　Numeric＝数字なので、数字が入力されているかどうかチェックすること
　ア　チェックディジットチェック
　ウ　バランスチェック
　エ　重複チェック


11-07　ア
　計算すればOK
　7+6+27+16=56　56/11=5あまり1
　11-1=10　よって1の位は0


11-08　イ
　慣れている人にとっては速く操作ができ、慣れていない人には確実に
　操作ができるようなインタフェースが良いので
　マウスとキーボードの併用が良い
　他の選択肢は操作に時間がかかるか、入力原票との対応関係がわかりにくい


11-09　ア
　チェックディジットは読み取り間違いや入力間違いの検出に使用する


11-10　ア
　一意＝重複していないという意味
　よって重複を調べる重複チェックを実施


11-11　イ
　ア　いちいち強制終了されると困る
　イ　適切（あまりごちゃごちゃしていると見づらい）
　ウ　プログラムでの処理順ではなく、ユーザが使いやすい順番とする
　　　ここでは入力原票の順が良い
　エ　入力の確認を省くと入力間違いが生じやすくなる
　　　入力確認のプロセスを設置しても見ない可能性はあるが、手続きを省略
　　　すると確認しない行為が助長される


11-12　ウ
　コードを取り扱うのはユーザ部門なので、ユーザ部門にとって分かりやすい
　ことが重要。よってア、イは間違い
　エは、追加や廃止はプログラムに機能として盛り込むのでテスト段階で決める
　のでは遅すぎる。


11-13　エ
　1000項目から該当商品を選びだすのは困難なので
　ユーザ（取引先）がメニューをカスタマイズできると良い。
　アイウはいずれも取引先にとって使いやすさの向上につながらない


11-14　イ
　ア　外部設計では画面構成を決める。プログラムの分割は内部設計で実施
　ウ　外部設計→内部設計の順番は固定
　エ　外部設計はユーザから見たシステム設計


11-15　イ
　ア　数字と文字をまとめるのではなく、意味の観点から分割するべき
　イ　見やすくするための工夫であり、正解
　ウ　数字は右づめ、文字は左詰め（エクセルと同じ）
　エ　プログラムのわかりやすさではなくユーザのわかりやすさを重視すべき


11-16　エ
　26×26×26×1000＝17576000


11-17　イ
　ア　値を越えないのではなく値が一致することを確認する
　イ　正解
　ウ　値の型を調べるのがフォーマットチェック
　エ　リミットチェックは最少、最大値を調べるのではなく、最少、最大値が
　　　上限や下限を越えていないことを調べる


11-18　ア
　未消化テスト項目が減っておらず、解決していないバグや検出バグにも変化が
　見られないということは、解決できないバグがありテストが進まないというこ
と
　イ　テストの消化実績が上がっているなら未消化テスト項目数が減るはず
　ウ　バグが多発しているなら検出バグ数が増えるはず
　エ　バグ発生とテスト項目消化の比率が一致しても未解決バグがないことは意
味しない


11-19　ウ
　国コード→商品メーカコード→商品アイテムコード→チェックディジットの順


11-20　ア
　外部設計はユーザインタフェースの設計なので、
　画面や出力する帳票のレイアウトを決める


11-21　ウ
　結合テストであるため上半期と下半期を結合している必要がある
　ア、イはそれぞれのワークシートで完結している
　ウは両者を結合している
　エは手計算をしているので関係なし


11-22　ア
　リミットを越えていないかどうかを調べるのがリミットチェック


11-23　エ
　誰でも情報にアクセスできること
　住民基本台帳やデータベースなどの個別の情報ではなく全般的な話
　ウはトレーサビリティ


11-24　エ
　情報が入手できないことによる社会的、経済的格差のこと
　単に情報が入手できないということではない


11-25　ア
　候補一覧から選択＝プルダウンメニュー
　項目数が少ない場合に有効


11-26　エ
　完成したソフトウェアを受け入れる際は、取得をする側が
　問題がないかどうかチェックする。
　必要に応じて開発者が支援をする。


11-27　エ
　ア　内部構造：ホワイトボックス、外部構造：ブラックボックス
　イ　両者には関係あり、検出エラー数が多い＝残存エラー数が少ない
　ウ　エラーは全て検出できない。エラーをできる限り多く出すことで
　　　エラーがほとんど残されていないことを確認する程度


11-28　イ
　修正がほかの部分に影響していないことを確認するのは退行テスト
　（レグレッションテスト）


11-29　イ
　3個の位置検出パターンがあり、どの方向からでも読み取り可能
　ア　ASCIIコード（半角英数字）のみでなく日本語でも組み込み可能
　ウ　そんなに小さくはできない（最少は21×21）
　エ　ITFの説明


11-30　イ
　コード化対象を選定し、データがどれくらいあるかわからないと
　コードの桁数が定まらない。
　よって、イが最初で次にエとなる。


11-31　イ
　運用部門が行うのは、日常的な業務を行った際にトラブルが発生しない
　ことを確認すること


11-32　イ
　ア　ソフトウェア方式設計
　ウ　ソフトウェア詳細設計
　エ　プログラム作成後のテスト工程


11-33　イ
　ア　プログラムの分割を行うのはソフトウェア方式設計
　ウ　順番は固定
　エ　外部設計は利用者側、内部設計はコンピュータ側


11-34　ア
　信頼度成長曲線はS字曲線を描くので該当する者はないが
　強いていうなら、アが最も近い


11-35　ア
　ア　正解
　イ　ヨーロッパでも通用する
　ウ　価格を示すコード部は存在しない
　エ　最後の1ケタがチェックディジット


11-36　イ
　ITFです。


11-37　エ
　デフォルトの値は頻繁に選択される値を使用すべきです。


11-38　ウ
　不十分だったのはリグレッションテストであるため、
　リグレッションテストの説明をしているウが正解


11-39　ア
　ア　正解
　イ　英数字は4296文字、漢字はその半分
　ウ　画像などのバイナリ形式のデータも保存できます。
　エ　プログラムではありません。データを格納しているだけです。


11-40　ア
　イ　同じ情報量なら2次元バーコードの方が狭いスペースで表現可能
　ウ　画像や音楽も保存可能
　エ　スタック型ではなくマトリクス型
　　　スタック型は従来の1次元バーコードを重ねたもの
　　　マトリクス型は縦横の2次元方向にデータを保存したもの


11-41　ア
　製造日や流通経路、ロット番号はJANコードには含まれない。
　ロット番号：製品を管理する際の最小単位。ロットごとに検査を行い
　異常値が検出された場合は、そのロットを出荷停止にするなどの
　対応がとられる。


11-42　エ
　トップダウンテスト：スタブ
　ボトムアップテスト：ドライバ


11-43　イ
　ホワイトボックステストは内部構造に基づいてテストデータを決める。
　ア、ウ、エはいずれも内部構造を意識していないのでブラックボックステスト


11-44　イ
　本社内のLAN環境でテストを行っているので、全国の事業所からインター
　ネットを経由して送られてきたデータを処理して戻すまでの時間はわからない。
　他はLAN内でもテスト可能。


11-45　ア
　国内でPOSシステムで使用するバーコードはJANと呼ぶ。


11-46　ア
　関連する項目をまとめる。
　イ　初心者はマウス操作が良い
　ウ　エラー内容を詳しく表示する
　エ　詳細な使用方法はヘルプ画面で表示


11-47　イ
　他は全てホワイトボックステスト


11-48　エ
　ア　組み合わせているので結合テスト
　イ　単体テストのテスト仕様はソフトウェア詳細設計で作成
　ウ　利用者でなく開発者がテストデータを作成


11-49　エ
　ドライバを使用しているのでボトムアップテスト
　※サンドイッチテスト：折衷ラインより上部はトップダウンテスト、下部は
　　ボトムアップテストを行う。スタブとドライバが必要
　※ビックバンテスト：すべてのモジュールを一気に結合してテスト


11-50　イ
　ア　設計段階で品質を保証していないとテストで解決できないバグが続出
　イ　修正した場合は前回のテストでOKだったものも再テストする
　　　　（リグレッションテスト）
　ウ　エラーを起こさせるのがテストの目的
　エ　本人がテストをしても気づかないことがあるので他人が行うべき


11-51　イ
　アはトラップ


11-52　ウ


11-53　ウ
　利用部門はシステムが組みあがってから参加


11-54　ウ
　外部から見た機能について検証するのはブラックボックステスト


11-55　イ
　単体→結合→システム→運用テスト


11-56　ア
　情報バリアフリーは高齢者や障害者が情報機器を活用して
　情報を入手できるようにすること


11-57　エ
　ア　運用テスト
　イ　単体テスト
　ウ　レビュー（又は単体テスト）


11-58　エ
　変更が他に影響を及ぼしていないかを確認するのはリグレッションテスト


11-59　ウ
　納品された際は、仕様どおりに作られているか確認する


11-60　ウ
  デザインレビューは設計の各工程で、設計が完了したかどうかを確認し
　次の工程に進んでよいかどうか判断をするために行う。
　他の選択肢は特定のプロセスに限定しているので間違い


11-61　ウ
　単体テスト→結合テスト→システムテスト→運用テストの流れ


11-62　ア
　共通フレームでは外部設計や内部設計という用語は使わないので
　混乱を招くよくない問題。
　なお対応付けは以下の通り。
　単体テスト　プログラム開発の担当者
　結合テスト　内部設計の担当者
　システムテスト　外部設計の担当者
　運用テスト　利用部門の担当者
　

11-63　ア
　都道府県コードなし
　標準は13ケタ
　インストアマーキングは小売店が独自に作成するその小売店内でのみ
　有効なバーコード。肉の量り売りの際につけるバーコードなどが該当。
　メーカが製造段階で印刷するのではない。


11-64　エ
　本番稼働可能かどうかは本番と異なる環境では検証できない
　しかし本番環境でテストを行い、失敗すると取り返しがつかないため
　本番環境と同等のテスト環境でテストすべき


11-65　ウ
　ホワイトボックステストの定義を覚えていればOK
　残りの選択肢は全てブラックボックステスト


11-66　エ
　ア　散布図
　イ　フローチャート
　ウ　特性要因図


11-67　ウ
　プログラミングはプログラムを書くこと
　ア　結合テスト
　イ　モジュールに分割しているだけで書いていない
　エ　フローチャートを書いているだけ（プログラミングの前段階）


11-68(1)　エ
　ア　単に網羅的に書いただけでは間違いが起こりそうなケースはわからない
　イ　この表では命令の実行順序はわからない
　ウ　この表では頻度はわからない

　　 (2)　ウ
　地区がA、重さが20なので、サイズに関わらずA地区の一番高い料金

　   (3)  ア
　アは区分1になる。1つ1つ確かめるしかない。 

　　 (4)　イ
　地区がA、サイズはいずれも100までだが重量が10㎏未満と10gを～20kgの場合
　なので、イしかない。