システムアーキテクト試験 2009年 午後1 問03

模範解答

解説

解答の論理構成

1. (a) の導出
   • 表1「システム全体の機能について、業務が確実に遂行できることを確認する。」
   • 同表「カスタマイズを行っていない機能については(a)を含めて確認する。」
   • 既定の機能はパッケージ標準仕様どおりに動くかどうかが確認対象になるため、「パッケージの仕様どおりに動作すること」と断定できます。
2. (b) の導出
   • 表2「進捗管理」欄に「障害は対応期限を明確にして管理」と明記。
   • 夕会では「当日対応期限になっている障害」が未解決なら対応を指示すると記載。
   • 朝会ではその前段階として障害管理票から“期限到来の障害が片付いているか”をチェックする流れとなるため、「対応期限が到来している障害が解決していること」が適切。

誤りやすいポイント

• (a) を「業務フローが正しいこと」と一般化し過ぎる。カスタマイズしていない機能に限定する点を見落とすと減点対象です。
• (b) を「障害が解決していること」とだけ書くと、期限の概念が抜けて不十分となります。
• 朝会・夕会の役割を混同し、朝会で“作業開始可否”を判断する根拠を読み飛ばすケースも多いです。

FAQ

模範解答

解説

解答の論理構成

1. 表2の引用

   “その後、原因、対応の要否、対応の内容、予定工数、優先度、(c)、(d) を追記する。”

2. ここまでで記入済みの項目は
   • 対応内容や予定工数・優先度＝「何をどれだけやるか」
3. 残る情報ギャップは
   • “いつまでに”＝期限
   • “誰が”＝担当者
4. テスト工程では
   • 期限のないタスクは未達リスクを生む
   • 担当者のないタスクは責任所在が不明
5. よって (c)＝「対応期限」、(d)＝「対応担当者」と導けます。

誤りやすいポイント

• 「進捗率」や「障害番号」を入れたくなるが、既に別管理表・票に存在するため重複します。
• “対応方針” を (c) に入れる誤答が多いですが、既に “対応の内容” が列挙済みです。
• “優先度” と “期限” を混同しがちですが、優先度は相対順位、期限は具体的な日付です。

FAQ

模範解答

解説

解答の論理構成

1. 【問題文】方式1の説明
   「F社が現在の業務で使用している取引先データ及び契約データを…使用する」
   → 現行データは“実際に存在する契約のみ”で構成される。
2. 網羅性の不足
   実データだけでは、異常系・境界値・将来想定ケースなどテストで必要な全パターンが含まれない。
3. 表4の評価軸
   「機能の確認は十分にできるか」で方式1は「X」、方式2は「〇」。
   したがって方式1が×になる理由(e)は、機能確認に必要なデータが不足する点に帰着。
4. 文脈に合う字句
   「テストケースを網羅するデータがない可能性がある」が欠落理由として最適。

誤りやすいポイント

• 方式1を「現行データだから品質が高い」と誤解し、網羅性問題を見落とす。
• 方式2を「入力データ作成が大変だから×」と短絡的に判断し、評価軸の優先度を混同する。
• (e)を「データ量が多すぎる」など量的課題と勘違いしてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 長期イベント未発生の問題
   • リース期間は【問題文】「リース期間は、4年又は5年」と規定。
   • システム日付は表1で「最初の1週間は…その後は…翌年度4月に行う年次集計処理まで」と１年強しか進めない。
   • さらに「方式2」では契約をテスト中に登録するため、登録から４年以上経過する契約が存在しない。
   • 再リース機能は【問題文】「翌々月にリース期間満了となる契約について…満了通知兼再リース契約申請書を…」と満了契約が前提。
   • よって再リース機能・満了通知・物件処分など長期イベントを確認できない。
2. 障害即時共有欠如の問題
   • 障害対応は表2「機能検証チームのリーダが障害管理票を起票し、チーム内で管理する」と記載。
   • 管理チームが障害状況を把握するタイミングは同表「朝会」「夕会」の報告時。
   • 重大障害が日中に発生しても、他チームや実行チームは朝夕会まで情報を得られず、依存プログラムを使い続ける恐れがある。
   • その結果、障害波及や無駄なテスト実行など運営停滞が発生しうる。

誤りやすいポイント

• 「翌々月にリース期間満了」を１年テストで確認できると誤解しやすい。期間設定と方式2を同時に考慮する必要があります。
• 障害管理票の起票＝共有完了と思い込むと、連絡タイミングの遅延を見落とします。
• 問題点を単なる労力や工数の増減と捉え、機能検証漏れ・品質リスクに結び付けないミスが散見されます。

FAQ

模範解答

解説

解答の論理構成

1. 【問題文引用】表3には
   • 「予定累計」が「（ウ）」
   • 「実績累計」が「（オ）」
     と示されている。
2. システムテストでは、ある時点までに確認できたテストケース総数（実績累計）が計画総数（予定累計）を下回ると遅延、上回ると前倒し、等しいと計画どおりと判断するのが一般的。
3. よって判断に必須の数値は「（ウ）予定累計」と「（オ）実績累計」。
4. 判断基準は 実績累計 ≥ 予定累計、すなわち「オがウ以上」。

誤りやすいポイント

• 「（イ）予定」や「（エ）実績」の単日値を比較してしまい、前日繰り越しを見落とす。
• 障害件数（カ〜ケ）と混同し、進捗ではなく品質指標で遅延を判断してしまう。
• 「オがウ以下」と誤記し、判断基準を逆にしてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 完了条件の定義を確認
   【問題文】表1「テストの完了」に「当日実施予定のすべてのテストケースについて、正しい結果が得られたことが確認できた場合、当日のテストが完了」とあります。システム全体では “総テストケースがすべて確認済み” になることが最終完了条件です。
2. 必要な数値を抽出
   ・総テストケース数 → 表3の「ア」
   ・確認済みの実績累計 → 表3の「オ」
   他の数値は未完了かどうかの直接判定に不要です。
3. 大小関係の整理
   $ア=オ$ になった瞬間、残件は 0 となりサイクルテストが完了したと判断できます。
4. したがって
   判断を行うのに最も必要なのは「ア」と「オ」、大小関係は「アとオが等しいとき」です。

誤りやすいポイント

• 予定累計（ウ）と比較してしまう
  予定は計画達成度を見る指標であり、完了判定には不適切です。
• 障害解決件数（ケ）が総障害件数（キ）と一致するまで待つと誤解する
  障害が解決されない限りテストケースは確認完了にカウントされません。確認完了実績累計にすでに反映されているため、改めて見る必要はありません。
• 日別実績（エ）を積み上げ計算してしまう
  表では累計（オ）が既に用意されているので再集計は不要です。

FAQ