平成24年度 秋期に実施されたシステムアーキテクト試験
午後Ⅱの全3問（論述式）です。問題文・設問と，問われていることの整理をそのまま読めます。
問1 業務の変化を見込んだソフトウェア構造の設計について
企業を取り巻く環境の変化に応じて，業務も変化する。情報システムには，業務の変化に対応して容易に機能を変更できるような，ソフトウェア構造の柔軟性が求められる。
このため，システムアーキテクトは，システム要件定義の段階から，業務の変化が起こり得るケースを想定し，変化の方向性やシステムに与える影響を予測する。ソフトウェア構造の設計では，その予測に基づいて，業務が変化してもシステム全体を大きく作り直す必要がないように考慮しなければならない。
例えば，次のようにソフトウェア構造の設計を行う。
- 業務フローの制御部分と業務ロジック部分を分離する。
- 業務ロジックが互いに疎結合となるように分割する。
- データアクセスコンポーネントを共通化する。
その際，そのような設計を行うことによって引換えに生じた課題に対応するための工夫を行うことが重要である。例えば，処理時間が長くならないように複数のプロセスを並行して処理したり，処理同士の整合性を確保するために排他制御の仕組みを用意したりする。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
企業を取り巻く環境の変化に応じて，業務も変化する。情報システムには，業務の変化に対応して容易に機能を変更できるようなソフトウェア構造の柔軟性が求められる。
このため，システムアーキテクトは，システム要件定義の段階から，業務の変化が起こり得るケースを想定し，変化の方向性やシステムに与える影響を予測する。ソフトウェア構造の設計では，その予測に基づいて，業務が変化しても，システム全体を大きく作り直す必要がないように考慮しなければならない。
本問は，業務が変化しても，システム全体を大きく作り直す必要がないように設計したソフトウェア構造の設計内容，その設計を行うことによって引換えに生じた課題に対応するために重要と考えて工夫した内容，及び設計したソフトウェア構造に対するシステムアーキテクトとしての評価について，具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要なソフトウェア構造の設計能力を評価する。
設問と問われていること
設問ア
800字以内
あなたがソフトウェア構造の設計に携わったシステムにおける，対象業務の概要及び特徴について，800字以内で述べよ。
問われていること
- ソフトウェア構造の設計に携わったシステムの対象業務の概要
- 対象業務の特徴
組み立ての注意
問われているのは対象業務の概要及び特徴。採点講評は，“対象業務の概要及び特徴”を問うているにもかかわらず，“プロジェクトの概要”や“システムの概要”を述べている論述を挙げている。
設問イで想定した業務の変化を述べるので，特徴は，どのような変化が起こり得る業務なのかが分かるように書いておくと，後の論述がつながる。
設問イ
800字以上1,600字以内
設問アで述べたシステムについて，どのような業務の変化を想定したか。また，業務が変化してもシステム全体を大きく作り直す必要がないように，どのようなソフトウェア構造を設計したか。800字以上1,600字以内で具体的に述べよ。
問われていること
- 想定した業務の変化
- システム全体を大きく作り直す必要がないように設計したソフトウェア構造
組み立ての注意
ソフトウェア構造は，前文の例（業務フローの制御部分と業務ロジック部分を分離する，業務ロジックが互いに疎結合となるように分割する，データアクセスコンポーネントを共通化する）のように，具体的な構造として書く。
採点講評は，“業務変化によってシステムが受ける影響”，“ソフトウェア構造の面からの設計”，“業務変化に対応できる理由”の三つを関連付けた論述を期待したが少なかったとしている。また，“想定した業務の変化”ではなく，設定値をテーブル化するなどの“汎用化のためのプログラミング方法”や，商品の種類が増加するなどの“当然考慮すべき業務要件やデータ量の変化”に対応する構造を述べた論述，“柔軟性を持った構造にした”などにとどまり具体的な構造に触れていない論述を挙げている。
設問ウ
600字以上1,200字以内
設問イで述べたソフトウェア構造の設計において，生じた課題とそれに対応するために重要と考えて工夫した内容，及び設計したソフトウェア構造に対するシステムアーキテクトとしての評価について，600字以上1,200字以内で具体的に述べよ。
問われていること
- ソフトウェア構造の設計において生じた課題
- 課題に対応するために重要と考えて工夫した内容
- 設計したソフトウェア構造に対するシステムアーキテクトとしての評価
組み立ての注意
課題は，前文のとおり，設問イの設計を行うことによって引換えに生じたものとして書く。工夫は，前文の例（処理時間が長くならないように複数のプロセスを並行して処理する，処理同士の整合性を確保するために排他制御の仕組みを用意する）のように書く。
評価の対象は，設問イで設計したソフトウェア構造。想定した業務の変化に対応できるかという観点とつなげて書く。
採点講評（IPA）
問1（業務の変化を見込んだソフトウェア構造の設計について）では，“業務変化によってシステムが受ける影響”，“ソフトウェア構造の面からの設計”，“業務変化に対応できる理由”，の三つについて，関連付けて論述することを期待したが，そのような論述は少なかった。
多くの受験者が，“想定した業務の変化”に対応するソフトウェア構造ではなく，設定値をテーブル化するなど“汎用化のためのプログラミング方法”や販売管理システムにおいて商品の種類が増加することなど，“当然考慮すべき業務要件やデータ量の変化”に対応するソフトウェア構造について論述していた。また，“どのようなソフトウェア構造を設計したか”と問うているにもかかわらず，“柔軟性を持った構造にした”などの論述にとどまり，具体的なソフトウェア構造に触れていない論述も見られた。
業務の変化が激しくなっている状況において，業務を踏まえてソフトウェア構造を設計する能力は，システムアーキテクトとして特に必要とされるものである。その重要性を理解し，実践してほしい。
全問共通
全問に共通して，具体的で，経験に基づいて記述されていることをうかがわせる論述が多かった。一方で，問題文の引用で文字数を費やし，結果的に期待した内容が書かれていない論述や，問題文に例示した項目と一般論の組合せだけで構成された具体性に欠ける論述も見られた。問題文に記載した項目は事例として挙げたものであり，転記を求めているものではないことを理解してほしい。
また，設問で問うている内容に対応しない論述も散見された。例えば，“対象業務の概要及び特徴”を問うているにもかかわらず，“プロジェクトの概要”や“システムの概要”を述べているような論述が挙げられる。このような論述では，受験者の能力や経験を正しく評価できない場合があるので，実際の経験に基づき設問に沿って具体的に論述してほしい。
出典：平成24年度 秋期 システムアーキテクト試験 午後Ⅱ 問1（表記を一部改変）
問2 障害時にもサービスを継続させる業務ソフトウェアの設計について
業務におけるシステムの重要性の増大に伴い，システムの障害時にもサービスを継続させることが重要になっている。システムアーキテクトは，サービス継続の方針に基づいて，機器の二重化などハードウェア面での対策だけでなく，障害時に継続運用を可能にする業務ソフトウェアを設計する。
例えば，小売業で“来店する顧客が通常どおり商品を購入できること”，金融業で“決済取引を止めないこと”がサービス継続の方針である場合，システムアーキテクトは，次のように障害時にも継続運用を可能にする業務ソフトウェアを設計する。
- 小売業で本部と店舗のシステムが連携してPOS売上処理を行っている場合，本部システムの障害に備え，POS売上処理を店舗システム単独で稼働可能にする。このため，店舗システムにPOS売上データを一時的に保持する機能を用意しておく。
- 金融業で，ネットワークの処理能力が大幅に低下するような障害に備え，障害時に決済取引以外の処理を一時的に停止する機能を用意しておく。
このような，継続運用を可能にする業務ソフトウェアを設計する際，更に次のような継続運用に備えた処理や障害復旧処理における工夫をする。
- 通常時に，本部のマスタを更新する都度，店舗のマスタも同時に更新し，いつでも店舗システム単独での稼働に切り替えられるようにする。また，店舗での欠品を防止するために，復旧後，配送頻度の高い食品などの発注データを優先的に処理する。
- ネットワークの処理能力の回復後，停止させていた業務を再開するとともに，全業務が利用可能であることを利用者の画面上に表示する仕組みを用意する。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
業務におけるシステムの重要性の増大に伴い，システムの障害時にもサービスを継続させることが重要になっている。システムアーキテクトは，サービス継続の方針に基づいて，機器の二重化などハードウェア面での対策だけでなく，障害時に継続運用を可能にする業務ソフトウェアを設計する。
本問は，対象業務と対象システムの概要及び障害時のサービス継続の方針について述べることを求めている。また，その方針に基づいて障害時にもサービスを継続することにした処理と，継続運用を可能にするための業務ソフトウェアの設計を述べ，継続運用に備えた処理や障害復旧処理における工夫について，具体的に論述することを求めている。論述を通じて，システムアーキテクトに必要な，業務の特徴を踏まえた業務ソフトウェアの設計能力を評価する。
設問と問われていること
設問ア
800字以内
あなたが開発に携わった，障害時にも継続運用を可能にするシステムについて，対象業務とシステムの概要，サービス継続の方針について，800字以内で述べよ。
問われていること
組み立ての注意
サービス継続の方針は，前文の例（小売業で“来店する顧客が通常どおり商品を購入できること”，金融業で“決済取引を止めないこと”）のように，業務の側から見て何を止めないのかとして書く。設問イはこの方針に基づいて継続する処理を選ぶので，方針が処理の選び方の根拠になるように書いておく。
設問イ
800字以上1,600字以内
設問アで述べた方針に基づいて，障害時にもサービスを継続することにした処理は何か。また，継続運用を可能にするために業務ソフトウェアをどのように設計したか。800字以上1,600字以内で具体的に述べよ。
問われていること
- 障害時にもサービスを継続することにした処理
- 継続運用を可能にするための業務ソフトウェアの設計
組み立ての注意
設計は，前文の例（POS売上処理を店舗システム単独で稼働可能にしてPOS売上データを一時的に保持する機能を用意する，決済取引以外の処理を一時的に停止する機能を用意する）のように，業務ソフトウェアとしての設計を書く。
採点講評は，問題文で除外しているにもかかわらず，機器やデータベースの二重化など業務ソフトウェア面以外での対策を述べた論述が多かったとしている。前文も「機器の二重化などハードウェア面での対策だけでなく」としている。
設問ウ
600字以上1,200字以内
設問イで述べた業務ソフトウェアの設計で，継続運用に備えた処理や障害復旧処理においてどのような工夫をしたか。600字以上1,200字以内で具体的に述べよ。
問われていること
組み立ての注意
工夫は，前文の例（通常時に本部と店舗のマスタを同時に更新していつでも切り替えられるようにする，復旧後に配送頻度の高い食品などの発注データを優先的に処理する，回復後に停止させていた業務を再開して全業務が利用可能であることを画面上に表示する）のように，障害に備えた通常時の処理や復旧時の処理として書く。
採点講評は，ここで“継続運用を可能にするための設計”に関する工夫を書いた論述を挙げている。それは設問イで述べる内容であり，設問ウで問われているのは継続運用に備えた処理や障害復旧処理における工夫。
採点講評（IPA）
問2（障害時にもサービスを継続させる業務ソフトウェアの設計について）では，サービス継続の方針に基づいて，サービスを継続する処理と，継続運用を可能にするための業務ソフトウェア設計について論述することを期待したが，そのような論述は少なかった。多くの受験者が，問題文で除外しているにもかかわらず，機器やデータベースの二重化など業務ソフトウェア面以外での対策について論述していた。また，“継続運用に備えた処理や障害復旧処理においてどのような工夫をしたか”と問うているにもかかわらず，“継続運用を可能にするための設計”に関する工夫を記載している論述も散見された。
システムは，常に正常に稼働しているとは限らない。システムアーキテクトとして，システム障害時の業務も想定した設計を心掛けてほしい。
全問共通
全問に共通して，具体的で，経験に基づいて記述されていることをうかがわせる論述が多かった。一方で，問題文の引用で文字数を費やし，結果的に期待した内容が書かれていない論述や，問題文に例示した項目と一般論の組合せだけで構成された具体性に欠ける論述も見られた。問題文に記載した項目は事例として挙げたものであり，転記を求めているものではないことを理解してほしい。
また，設問で問うている内容に対応しない論述も散見された。例えば，“対象業務の概要及び特徴”を問うているにもかかわらず，“プロジェクトの概要”や“システムの概要”を述べているような論述が挙げられる。このような論述では，受験者の能力や経験を正しく評価できない場合があるので，実際の経験に基づき設問に沿って具体的に論述してほしい。
出典：平成24年度 秋期 システムアーキテクト試験 午後Ⅱ 問2（表記を一部改変）
問3 組込みシステムの開発プロセスモデルについて
組込みシステムの開発では，システムの要求分析から出荷に至るまでの工程において，システムの品質，開発コスト及び納期のバランスをとるために，適切な開発プロセスモデル（以下，プロセスモデルという）を決定する必要がある。そのために，組込みシステムのシステムアーキテクトは，システム開発における様々なプロセスモデルの特性を理解して，システムに最適なプロセスモデルを選択し，決定する。
例えば，プロジェクトマネジメントの容易さの観点からは，開発工程が明確に分かれているウォータフォールモデルが用いられる。ただし，このプロセスモデルは，開発途中での要求仕様の変更がなく，かつ，各開発工程を手戻りなく実行することが前提になっている。
また，ユーザインタフェースの要求仕様が不明確な状態から開発する場合に用いられる，プロトタイピングモデルがある。このプロセスモデルでは，試作品の作成とその評価を繰り返し，要求仕様を明確にしていくので，工程の時間管理が重要になる。
一方，多くの機能をもつシステムを開発する場合に，システムを独立性が高い幾つかのサブシステムに分割して，サブシステムごとに順次開発し，リリースしていくインクリメンタルモデルもある。その他，スパイラルモデル，オブジェクト指向開発モデルなど多くのプロセスモデルがあり，対象システムの特徴や納期，社内の開発環境などを考慮して最適なプロセスモデルを決定しなくてはならない。
あなたの経験と考えに基づいて，設問ア〜ウに従って論述せよ。
出題趣旨（IPA）
組込みシステムのシステムアーキテクトは，システム開発における様々な開発プロセスモデルの特性を理解して，システムに最適なプロセスモデルを選択し，決定する能力が求められる。
本問は，組込みシステム開発の経験を基に，各種の開発プロセスモデルについての知見とその適用について具体的に論述することを求めている。
本問では，論述を通じて，システムアーキテクトに必要な各種開発プロセスモデルの特徴，欠点に関する知識，及び組込みシステム開発のプロジェクトにおいて組込みシステムの特徴を分析し，適切な開発プロセスモデルを選択して運用する能力を評価する。
設問と問われていること
設問ア
800字以内
あなたが開発に携わった組込みシステムの概要について，開発目標，開発の特徴を含め，800字以内で述べよ。
問われていること
- 開発に携わった組込みシステムの概要
- 開発目標
- 開発の特徴
組み立ての注意
設問ウで，採用したプロセスモデルによって開発目標を達成できたかを問うので，開発目標は評価できる形で書いておく。開発の特徴は，前文の例（要求仕様の変更の有無，ユーザインタフェースの要求仕様が不明確か，多くの機能をもつか）のように，プロセスモデルの選び方に効くものを書く。
採点講評は，対象が組込みシステムではない論述を，出題の趣旨から外れると判断したとしている。
設問イ
800字以上1,600字以内
設問アで述べた組込みシステム開発で，どのような点をプロセスモデルの決定において重要と考えたか。また，その結果，どのようなプロセスモデルを採用したか。採用に至る過程を含め，800字以上1,600字以内で具体的に述べよ。
問われていること
- プロセスモデルの決定において重要と考えた点
- 採用したプロセスモデル
- 採用に至る過程
組み立ての注意
重要と考えた点は，前文のとおり，システムの品質，開発コスト及び納期のバランスや，対象システムの特徴や納期，社内の開発環境などから書く。
前文は，ウォータフォールモデル，プロトタイピングモデル，インクリメンタルモデルについて，それぞれ用いられる場面と前提や注意点を挙げている。採用に至る過程では，こうした特性を比べてどう選んだかを書く。出題趣旨も，各種開発プロセスモデルの特徴，欠点に関する知識を評価するとしている。
設問ウ
600字以上1,200字以内
設問イで述べたプロセスモデルの採用は適切であったか。また，そのプロセスモデルによって開発目標を達成し，システムの品質，開発コスト及び納期の最適化を実現できたか。更に改善する余地があればその事項も含め，600字以上1,200字以内で具体的に述べよ。
問われていること
- プロセスモデルの採用は適切であったか
- 開発目標の達成
- システムの品質，開発コスト及び納期の最適化を実現できたか
- 更に改善する余地がある事項
組み立ての注意
開発目標は，設問アで述べたものに照らして評価する。品質，開発コスト及び納期は，前文が述べるバランスの三つの要素。
出題趣旨は，適切な開発プロセスモデルを選択して運用する能力を評価するとしている。選んだモデルを運用した結果として書く。
採点講評（IPA）
問3（組込みシステムの開発プロセスモデルについて）では，具体的な経験をうかがわせる論述が多かった。論述されたプロセスモデルについては，プロトタイピングモデルでの開発が多く，ユーザインタフェースを重視する具体的な開発状況を読み取れた。また，システム開発時の品質管理を重視する立場から，ウォータフォールモデルを採用した論述も散見された。一部の論述では対象が組込みシステムではないものがあり，これは出題の趣旨から外れると判断した。
全問共通
全問に共通して，具体的で，経験に基づいて記述されていることをうかがわせる論述が多かった。一方で，問題文の引用で文字数を費やし，結果的に期待した内容が書かれていない論述や，問題文に例示した項目と一般論の組合せだけで構成された具体性に欠ける論述も見られた。問題文に記載した項目は事例として挙げたものであり，転記を求めているものではないことを理解してほしい。
また，設問で問うている内容に対応しない論述も散見された。例えば，“対象業務の概要及び特徴”を問うているにもかかわらず，“プロジェクトの概要”や“システムの概要”を述べているような論述が挙げられる。このような論述では，受験者の能力や経験を正しく評価できない場合があるので，実際の経験に基づき設問に沿って具体的に論述してほしい。
出典：平成24年度 秋期 システムアーキテクト試験 午後Ⅱ 問3（表記を一部改変）