平成27年秋期試験午後問題　問8

問8　情報システム開発

⇱問題PDF
ソフトウェアパッケージの利用に関する次の記述を読んで，設問1～3に答えよ。
広告
　K社は，現行の購買システムの再構築のために，短期間で導入できる購買業務用ソフトウェアパッケージ(以下，購買パッケージという)の利用を検討している。現行業務を分析し改善要望を整理した結果を基に，業務機能を定義し，新業務フローを作成した。その上で，購買パッケージとのフィット＆ギャップ分析を行い，ギャップ部分についてはできるだけ購買パッケージに合わせることとし，重要度が高いギャップだけ，追加プログラムの開発を行う方針とした。
  • 改善要望の整理
    　現行業務を分析し，改善要望を整理した。
    • 現在の見積りの業務では，現場担当者が仕入先に対して見積りを依頼している。仕入額の削減や発注遅延の防止を目的として，購買部から仕入先に対して見積りを依頼するようにしたい。
    • 仕入先とのやり取りの業務では，仕入先から受領した情報をシステムに入力する手間や，データの入力ミスが問題となっている。特に入力量が多い見積回答データや請求データについては，仕入先に直接入力させたい。
  • 業務機能の定義
    　改善要望を整理した結果から，表1に示す業務機能を定義した。
    pm08_1.png
  • 新業務フローの作成
    　業務機能を定義した結果から，図1に示す新業務フローを作成した。
    pm08_2.png
〔購買パッケージの機能〕
　導入を検討している購買パッケージの標準機能を表2に示す。
pm08_3.png
〔フィット＆ギャップ分析〕
　業務機能と購買パッケージの標準機能とのフィット＆ギャップ分析を行ったところ，表3の結果が得られた。
pm08_4.png
〔追加プログラムの外部設計〕
　フィット＆ギャップ分析によってギャップと判定された業務機能のうち，見積回答と，請求については，購買パッケージに合わせて，仕入先から受領した情報をK社の社員がシステムに入力する運用を継続することにした。見積取得依頼については，現場担当者からの依頼に基づいて，購買部が仕入先から見積りを取得するという改善要望を優先することとし，購買パッケージに対して，K社独自の機能を追加プログラムとして開発することにした。
　追加プログラムとして開発が必要な，現場担当者が入力する見積取得依頼の画面設計の一部を図2に，見積取得依頼のクラス図を図3に示す。追加プログラムは，購買パッケージが提供しているテーブル(パッケージテーブル)を直接参照せず，購買パッケージが提供しているプログラム(パッケージプログラム)を使用してパッケージテーブルにアクセスする。追加プログラムが必要とするデータでパッケージテーブルに存在しないデータは，K社独自のテーブルとして新たに作成する。
pm08_5.png
　見積取得依頼画面のボタンとその機能を次に示す。
  • 品目名を入力する際，又は希望する仕入先があり希望仕入先名を入力する際は，品目ボタン又は仕入先ボタンを押すことによって，それぞれの入力補助画面へ遷移する。遷移先の入力補助画面でマスタ検索を行い，出力される品目又は仕入先をラジオボタンで選択し，確定ボタンを押すことによって，見積取得依頼画面の明細に，品目名又は希望仕入先名を指定する。
  • 明細追加ボタンを押すことによって，品目名，数量などを入力するための新たな明細行が追加される。
  • 選択欄のチェックボックスにチェックを入力した後，明細削除ボタンを押すことによって，選択した明細行が削除される。
  • 見積取得依頼画面で案件名及び明細行を入力し登録ボタンを押すことによって，見積取得依頼及びその明細が登録される。
pm08_6.png
〔購買パッケージのバージョンアップ対応〕
　購買システムの本番リリース後，購買パッケージのバージョンアップがあり，見積回答機能が強化されて，K社の業務機能(表1のNo.3)に合致するようになった。そこで，購買パッケージのバージョンアップを検討し，追加プログラムへの影響調査を実施した。購買パッケージにおいては，バージョンアップの際に既存のパッケージテーブルに対する変更は一切行われていないことを確認した。また，追加プログラムの開発に当たって，K社ではパッケージプログラムやパッケージテーブルに対する改修を一切行っていない。
　念のため，テスト環境を用意して，購買パッケージのバージョンアップを行い，購買システムの動作検証を実施したところ，①追加プログラムが異常終了した。この原因を調査して追加プログラムの修正を実施し，本番環境のバージョンアップを無事に完了した。
広告

設問1

表3中のa～cに入れる適切な機能内容について，それぞれ20字以内で述べよ。

解答例・解答の要点

a：見積金額をシステムに入力 (12文字)
b：仕入先が見積回答を直接入力 (13文字)
c：仕入先が請求内容を直接入力 (13文字)

解説

本問は既存の購買システムをアップデートするシナリオを通じて、現行業務分析、顧客要求事項のとりまとめ、帳票(画面)設計・クラス設計、システム移行計画と実行まで、一連の開発フローを進めるためのスキルを問う問題です。

設問1で登場する「フィット＆ギャップ分析」は、既存パッケージソフトが顧客の要求に適合している（フィット）部分と、適合しない（ギャップ）部分を抽出整理する分析です。表1の業務機能及び①の新業務フローから、新システムが実現しようとしている機能（＝顧客要求事項）と、表2に記載された購買パッケージの標準機能を比較します。

〔a，bについて〕
表2の「見積回答入力」欄を見ると、「仕入れ先から受領した見積回答書の内容を基に，見積金額を入力する」ことが可能です。ただし、ここで金額を入力するのはシステムの利用者、すなわちK社の担当者が入力する事になります。しかし、本文中の「(1)：改善要望の整理」には「見積回答データや請求データについては，仕入先に直接入力させたい」という記載があるほか、表1の「見積回答」欄には「仕入れ先が，見積回答を直接入力する」という記載があり、購買パッケージの機能と顧客要求に差が生じています。従って[a]には標準機能の範囲で実現できる「見積金額をシステムに入力」が入り、[b]には標準機能にない「仕入先が見積回答を直接入力」が入ります。

∴a＝見積金額をシステムに入力
　b＝仕入先が見積回答を直接入力

〔cについて〕
表1の「請求」欄を見ると、「仕入れ先が，請求内容を直接入力する」とあります。また図1に示されたフローから、仕入れ先による請求内容の入力は商品を出荷した後に「受領・検品」と同時進行で行われ、検品完了後の「請求書照合」で請求情報が必要になることがわかります。しかし、表2の「請求書照合」では「仕入れ先から請求書の請求内容と検収データを照合し」とあり、この購買パッケージの標準機能は仕入れ先からの「請求書」による請求を想定しています。要するに、K社の要求にある仕入先がシステムに請求内容を入力する機能には対応していないということです。

したがって、請求業務において標準機能にないのは「仕入先が請求内容を直接入力」する機能です。

∴c＝仕入先が請求内容を直接入力
広告

設問2

図3について，(1)，(2)に答えよ。
  • d，fに入れる適切な字句を答えよ。
  • eに入れる適切な関連と多重度を答えよ。図3の凡例に倣って解答すること。

解答例・解答の要点

  • d：明細追加()
    f：0..1
  • e：pm08_7.png

解説

  • 〔dについて〕
    見積取得依頼クラスの操作（メソッド）です。図2に示された見積取得依頼の画面と図3のクラス図を照らし合わせると、図2の「見積取得依頼画面」の内容が見積取得依頼クラスに相当し、同画面下部の「明細」に並んだ各行が見積取得依頼明細クラスに対応していることがわかります。すなわち、1つの見積取得依頼に対して複数の見積取得依頼明細が紐づく前提となっています。

    見積取得依頼画面には明細追加ボタンがあり、このボタンを押すと「新たな明細行が追加される」と書かれています。しかし、見積取得依頼明細を削除する操作はあるのに「明細を追加する」機能が図2のクラス図に定義されていません。

    この操作は空の依頼明細（見積取得依頼明細のインスタンス）を1つ作成して、当該見積取得依頼インスタンスに紐づければ良いので、引数は不要です。したがって[d]には「明細追加()」が入ります。

    ∴d＝明細追加()

    〔fについて〕
    見積取得依頼明細クラスから見た仕入先クラスの多重度です。仕入先クラスは、見積取得依頼明細に紐づけられた仕入れ先情報を表しますが、本文に「希望する仕入先があり希望仕入先名を入力する際は(中略)見積取得依頼画面の明細に，品目名又は希望仕入先名を指定する」とあります。この記述より、仕入先の指定は必須ではない（多重度0があり得る）ことがわかります。また仕入先の入力は「出力される品目又は仕入先をラジオボタンで選択し」とあります。ラジオボタンは「複数の選択肢のなかから、ただ一つを選択する」際に使用されるユーザインタフェースであるため、希望仕入先名に指定される仕入先はただ1つです。これらを踏まえると[f]は「0..1」となります。

    ∴f＝0..1

  • 〔eについて〕
    見積取得依頼クラスと見積取得依頼明細クラスの関連を表します。前述した通り、1つの見積取得依頼（クラス）には複数の見積取得依頼明細（クラス）が紐づけられ、「集約」の関係性があることが伺えます。さらに、見積取得情報が消えれば、それに紐づいている見積取得明細情報は存在意味を失うので、両クラスの生存期間が同じである強い分解－集約関係、すなわち「コンポジション」の関係が適切です。
    pm08_8.png
    多重度については、1つの見積取得依頼について複数の明細を追加登録できるため、見積取得依頼クラス側の多重度が1に対し、見積取得依頼明細クラス側の上限はなし（多重度*)です。見積取得依頼明細クラス側の下限については、本文中に「案件名及び明細行を入力し登録ボタンを押すことによって，見積取得依頼及びその明細が登録される」とあり、明細のない見積取得依頼は登録できない（存在しない）と考えられるので1となります。したがって、見積取得依頼明細クラス側の多重度は1以上（1..*）が適切です。

    ∴e＝pm08_7.png
広告

設問3

本文中の下線①の異常終了を予見できなかったのは，バージョンアップの影響調査において何が不足していたからか。調査が必要であった内容について40字以内で述べよ。

解答例・解答の要点

追加プログラムが使用するパッケージプログラムの変更内容 (27文字)

解説

購買パッケージのバージョンアップに伴うレグレッションテスト（別名、「退行テスト」など）の問題です。既存システムをカスタマイズしたり、システム間に依存性のある状況では、システムの改修やバージョンアップなどで変更を加えると、思わぬところに影響が飛び火することがあります。

テスト前の確認では、「購買パッケージにおいては，バージョンアップの際に既存のパッケージテーブルに対する変更は一切行われていない」「K社ではパッケージプログラムやパッケージテーブルに対する改修を一切行っていない」と、購買パッケージ単体での動作確認に終始しており、パッケージプログラムの変更による影響を考慮していません。

本文中に「追加プログラムは，…パッケージが提供しているプログラム(パッケージプログラム)を使用してパッケージテーブルにアクセスする」とあるように、異常終了した追加プログラムはパッケージプログラムに依存しています。パッケージがバージョンアップされれば、当然にパッケージプログラムのインタフェースや動作が変わる可能性があるので、変更箇所があるか、どのように変更されたのか、その変更が追加プログラムの動作に影響しないかどうかなどを十分に調査しておく必要があります。

∴追加プログラムが使用するパッケージプログラムの変更内容
広告
模範解答
広告

前の問題次の問題

▲
Pagetop