先ほどIPAより、午前(Ⅰ・Ⅱ)試験の解答例が発表された。
自己採点の結果、
20/25(正答率:80%)
であった。
まずは、1次予選通過である。
午後Ⅰ試験は、どこかが解答速報を出すであろうから、
そこで確認したいと思う。
あと、午後Ⅱ試験の再現論文(骨子レベル)は、以下の通り。
---------------------------------------------------------------------
1-1.データ交換を利用する目的
受発注システムを題材に、受注データと発注データのデータ交換を自動化する
ことで、業務運用の効率化を図ることを中心に論述。
1-2.対象業務及び対象情報システムの概要
受注データを夜間に受信して取り込み、エラーがあればそのリストを出力。翌朝
担当者がエラーリストを確認して、訂正処理を行う。受注データにエラーが無くなっ
たら、食品メーカ向けに発注データを作成し、送信する。
受発注システムの概要は、バッチサーバとオンラインサーバで構成。バッチサーバ
には通信制御ミドルとジョブ管理ミドルを搭載。ジョブ管理ミドルは、同時実行可能数
を10に設定しているが、最大で12まで設定することが可能であることを論述。
2-1.制約事項
発注データを定時迄に送信しなければ、発注が翌日扱いとなり、欠品が発生する
ことを損失額を含めて論述。要件定義時は要求レベルの話だったため、それを更に
詳細にヒアリングし、どの商品が欠品になると損失額が大きくなるのかを具体化。
また、ヒアリング時に、食品メーカの数も把握することも記載。
2-2.情報システムの設計
制約事項を踏まえ、食品メーカ毎に発注データ作成と送信処理を行えるように
設計したことを論述。その時の同時実行数は10とし、なぜ同時実行数10で
運用時間帯の制約を満たすことが出来るのかを以下の観点から論述。
①1多重で処理できるトランザクションの指標値(ベンダより事前に収集)が
1食品メーカ当りの発注データ量を上回り、処理時間内に完了すること
②食品メーカ毎に処理を分けることで、問題のある受注データに引きずられず、
受注データに問題のない食品メーカから処理が可能になること
③発注データ作成と送信処理を同時実行可能とすることで、並列に処理が行え、
万が一特定の食品メーカ向けの発注処理が遅れても影響を局所化できること
3-1.データ交換で想定する異常
催事開催時期に受注量が増加し、それに伴い発注データ件数が増大することを
論述。これを担当者にヒアリングして、その通りであることを裏付けすると共に、
増大時のデータ件数と発注データ件数が大きくなる食品メーカが存在することを
具体的に論述。
3-2.受発注システムでの対応方法
催事開催時期だけ、ジョブ管理ミドルの同時実行可能数を12に設定することと、
発注データ件数が大きくなる食品メーカの発注データ作成と送信処理を2分割して
処理できるようにしたことを論述。2分割に分けた根拠は、2-2.の①で処理できる
件数を超えることを数字を交えて論述。
この対応方法を行わない場合、通常時でさえ多額の損失額が出るのに、受注量
の多くなる催事開催時期は更に損失額が多くなることを定量的に説明。
----------------------------------------------------------------------------
といった形で締めくくった。論文内では、もっと細かく具体的に論述しているが、
そこまで書くのはしんどかったのでやめる。
ひとつ前の記事でも投稿したが、あとは採点官がどのように評価するかであるため、
合格発表まで待つことにする。
ちなみに、合格発表日は、「12/19(金)正午」とのこと。
※コメント投稿者のブログIDはブログ作成者のみに通知されます