HOME»応用情報技術者試験掲示板»令和2年秋期試験 午後問9【プロジェクトマネジメント】
投稿する
機能をまたがる整合性の確認に使ったのは、基本設計での成果物（設計書等）だと思ったので、自分は原因工程を選びました。
基本設計書を見れば、各システムがどういうパラメータの受け渡しをしているかなどの、インターフェース部分（＝機能をまたがる部分）の整合性を確認できると思います。
また、基本設計での障害件数も180と高く、これが機能をまたがる部分で整合していない部分なのかなと。
なので、R氏の考えの流れとしては、
①原因工程別の分析表を見た
②基本設計工程の障害件数が高いことに着目
③基本設計書（成果物）を確認してみる
④機能をまたがる整合性に問題があった
というストーリーを想像しています。
ちなみに、障害動作別だと、障害動作がどういうものであったかの「障害内容」はわかりますが、「障害の原因」までは成果物として纏めていないと想像しました。というか、その障害の原因を分析してまとめたのが原因工程別の分析表と思うので、いずれにせよ原因工程別に行き着く気がします。
もちろん、基本設計の障害件数が多いというのもありますが、一般論として、結合テストは基本設計と対応します。すなわち、結合テストで生じた障害原因は基本設計にあると考えるのが一般的です。
この問題では、結合テストで障害が多数発見されているので、基本設計での作りこみが甘かったと推察できます。例えば、モジュール同士のパラメータの受け渡し方がまずかったとか、インターフェース部分をよく考えず設計した想定のストーリーなのかなと。
そうすると必然的に基本設計からやり直す必要があります。
ちなみに、仕様変更、すなわち要件定義からやり直すんじゃないの？という疑問を持たれているのかと理解しました。一般的に、要件定義に対応するのはシステム適格性確認テストなので、要件定義からやり直すのであれば、システム適格性テストで障害が発見されるという問題上の設定が必要になります。
IPAとしても、そういった一般論から外れて「結合テストでの障害対応として要件定義からやり直す」という解答にはしないのではと思います。
そういった観点も踏まえると、基本設計からやり直す必要があると思います。
»[2288] 令和2年秋期試験 午後問11【システム監査】 投稿数:42
»[2287] 令和2年秋期試験【受験前】 投稿数:1
令和2年秋期試験 午後問9【プロジェクトマネジメント】 [2290]
管理人(No.1)
午後問9(プロジェクトマネジメント)についての投稿を受け付けるスレッドです。
2020.10.18 00:03
もえさん(No.2)
試験お疲れ様ですー！
皆様どのようにご回答しましたかー？
皆様どのようにご回答しましたかー？
2020.10.18 15:45
はせさん(No.3)
たたき台置いておきます
原因種別、基本設計
イ
リベートサブシステムの初回稼働は12月1日で期間がある
116、95
実際のデータを使用して、算出金額一致を確認する
障害の解消件数と実作業工数を監視
原因種別、基本設計
イ
リベートサブシステムの初回稼働は12月1日で期間がある
116、95
実際のデータを使用して、算出金額一致を確認する
障害の解消件数と実作業工数を監視
2020.10.18 16:33
あさん(No.4)
設問2はウのマスタースケジュールにしました…
2020.10.18 16:42
kuroさん(No.5)
私の回答は以下の感じです。間違えの指摘をお願い致します。
原因工程、基本設計
イ
次のリベート実施タイミングが12月と6月30日の稼働からかなり期間が空くから
116、95
実務で使用しているデータを使用して、算出金額の正しさを確認する
テスト密度やテスト検出不具合密度などの指標の実績値
原因工程、基本設計
イ
次のリベート実施タイミングが12月と6月30日の稼働からかなり期間が空くから
116、95
実務で使用しているデータを使用して、算出金額の正しさを確認する
テスト密度やテスト検出不具合密度などの指標の実績値
2020.10.18 16:45
ケントさん(No.6)
116と95の算出方法を教えて頂けませんか？？
2020.10.18 18:14
かかかさん(No.7)
原因工程、基本設計
ウ
116、95
経理システムが全ての処理パターンを正しく実行できること
最後は何て書いたか忘れました
ウ
116、95
経理システムが全ての処理パターンを正しく実行できること
最後は何て書いたか忘れました
2020.10.18 18:16
はるさん(No.8)
116→再実施行程各システムごとに計算
販売は20×15 その他は×10
計620人月(１０人でやるので、62日)
解消→120件で一件当たり2人月
240人月(24日)
30日
62+24+30=116
95も同様の計算かと
販売は20×15 その他は×10
計620人月(１０人でやるので、62日)
解消→120件で一件当たり2人月
240人月(24日)
30日
62+24+30=116
95も同様の計算かと
2020.10.18 18:24
はるさん(No.9)
原因行程を選んだ理由はあります？
機能をまたがる～とあったので、画面表示や値不正などの障害動作を選んだのですが
機能をまたがる～とあったので、画面表示や値不正などの障害動作を選んだのですが
2020.10.18 18:26
はせさん(No.10)
原因工程を選んだのは、「〇〇の観点の分析から成果物」とあったからです。異常終了の成果物はないんじゃないかなーといった感じです
2020.10.18 19:58
apさん(No.11)
設問4は
販売システムと基本設計工程の障害件数
にしました
根拠としては、品質評価のボトルネックになっているのが
・サブシステム別の観点→販売システム
・原因工程別の観点→基本設計工程
であると二つ問題文に明記されていることが挙げられると思います。虫食い部分にはなっていますが。
テスト密度と検出不具合なんたらはひっかけじゃないですかね。
名前からしてもともと指標値が定まっていそうな値ですし、そもそも再計画前のテスト時から監視されています。
なので、再テストの際にあえて監視を強化するポイントではないかと。
販売システムと基本設計工程の障害件数
にしました
根拠としては、品質評価のボトルネックになっているのが
・サブシステム別の観点→販売システム
・原因工程別の観点→基本設計工程
であると二つ問題文に明記されていることが挙げられると思います。虫食い部分にはなっていますが。
テスト密度と検出不具合なんたらはひっかけじゃないですかね。
名前からしてもともと指標値が定まっていそうな値ですし、そもそも再計画前のテスト時から監視されています。
なので、再テストの際にあえて監視を強化するポイントではないかと。
2020.10.18 20:01
TOさん(No.12)
問1 障害動作 基本設計
問2
(1) イ
(2) リベートシステムの次回実行が12/1のため、6/30に稼働させる必要がない
(3) 116 95
問3 経理サブシステムの新旧アウトプットに差異がないこと
問4 作業対象の障害件数と障害の解消にかかる作業工数
116日と95日のところは深読みしすぎて、
「ソフトウェア適格性確認テスト・受入テスト」の30日を
30日＊8人＝240人日
240人日/10人＝24日 と要員8人→10人と再計算して、
合計110日と、89.8日って書きかけました。
ここをみると116日と95日が多数派のようで安心しました。
問2
(1) イ
(2) リベートシステムの次回実行が12/1のため、6/30に稼働させる必要がない
(3) 116 95
問3 経理サブシステムの新旧アウトプットに差異がないこと
問4 作業対象の障害件数と障害の解消にかかる作業工数
116日と95日のところは深読みしすぎて、
「ソフトウェア適格性確認テスト・受入テスト」の30日を
30日＊8人＝240人日
240人日/10人＝24日 と要員8人→10人と再計算して、
合計110日と、89.8日って書きかけました。
ここをみると116日と95日が多数派のようで安心しました。
2020.10.18 20:17
まーじさん(No.13)
＞原因行程を選んだ理由はあります？
機能をまたがる整合性の確認に使ったのは、基本設計での成果物（設計書等）だと思ったので、自分は原因工程を選びました。
基本設計書を見れば、各システムがどういうパラメータの受け渡しをしているかなどの、インターフェース部分（＝機能をまたがる部分）の整合性を確認できると思います。
また、基本設計での障害件数も180と高く、これが機能をまたがる部分で整合していない部分なのかなと。
なので、R氏の考えの流れとしては、
①原因工程別の分析表を見た
②基本設計工程の障害件数が高いことに着目
③基本設計書（成果物）を確認してみる
④機能をまたがる整合性に問題があった
というストーリーを想像しています。
ちなみに、障害動作別だと、障害動作がどういうものであったかの「障害内容」はわかりますが、「障害の原因」までは成果物として纏めていないと想像しました。というか、その障害の原因を分析してまとめたのが原因工程別の分析表と思うので、いずれにせよ原因工程別に行き着く気がします。
2020.10.18 20:36
ひまひまさん(No.14)
設問1 (a) 原因工程 (b) 基本設計
設問2 (1)ウ (2) 他のサブシステムへの影響がないから (3)(c)116 (d)95
設問3 販売部門のデータを使った経理処理に誤りがないか
設問4 テスト検出不具合密度と障害の解消の作業工程
他の人のを見る限り、設問2(1)(2)と設問4は間違ってそうですね
設問2 (1)ウ (2) 他のサブシステムへの影響がないから (3)(c)116 (d)95
設問3 販売部門のデータを使った経理処理に誤りがないか
設問4 テスト検出不具合密度と障害の解消の作業工程
他の人のを見る限り、設問2(1)(2)と設問4は間違ってそうですね
2020.10.19 05:36
ルンバサンバさん(No.15)
基本設計からを選んだ人が多いのって原因工程別だと基本設計が大きいから？
基本設計からのやり直すのって、本文中の「プロジェクト計画の変更」と既に合って無くないか・・・
それは基本設計のやり直しでなくて仕様変更だと思うんだけど・・・
基本設計からのやり直すのって、本文中の「プロジェクト計画の変更」と既に合って無くないか・・・
それは基本設計のやり直しでなくて仕様変更だと思うんだけど・・・
2020.10.19 18:08
まーじさん(No.16)
>基本設計からを選んだ人が多いのって原因工程別だと基本設計が大きいから？
>基本設計からのやり直すのって、本文中の「プロジェクト計画の変更」と既に合って無くないか・・・
>それは基本設計のやり直しでなくて仕様変更だと思うんだけど・・・
もちろん、基本設計の障害件数が多いというのもありますが、一般論として、結合テストは基本設計と対応します。すなわち、結合テストで生じた障害原因は基本設計にあると考えるのが一般的です。
この問題では、結合テストで障害が多数発見されているので、基本設計での作りこみが甘かったと推察できます。例えば、モジュール同士のパラメータの受け渡し方がまずかったとか、インターフェース部分をよく考えず設計した想定のストーリーなのかなと。
そうすると必然的に基本設計からやり直す必要があります。
ちなみに、仕様変更、すなわち要件定義からやり直すんじゃないの？という疑問を持たれているのかと理解しました。一般的に、要件定義に対応するのはシステム適格性確認テストなので、要件定義からやり直すのであれば、システム適格性テストで障害が発見されるという問題上の設定が必要になります。
IPAとしても、そういった一般論から外れて「結合テストでの障害対応として要件定義からやり直す」という解答にはしないのではと思います。
そういった観点も踏まえると、基本設計からやり直す必要があると思います。
2020.10.20 02:03
ルンバサンバさん(No.17)
自分が勉強した時の（10年前位）V字モデルは
基本設計→総合試験
機能設計→結合試験
だったはず。最近変わったか自分の覚え間違い？？今調べたら確かに
基本設計→結合試験
になってる
ちなみに要件定義を変える＝仕様変更でなく、
基本設計を変える＝仕様変更だという認識です。
ケースにも寄ると思うけど、今回要件レベルの変更は変わっていないと思うので。
今回のパターンだと基本設計の是正処置をした上で（本文に、「是正処置を講じた上でb工程から作業を再実施～」とあるから）製造工程からの修正になると思ってました・・・
基本設計→総合試験
機能設計→結合試験
だったはず。最近変わったか自分の覚え間違い？？今調べたら確かに
基本設計→結合試験
になってる
ちなみに要件定義を変える＝仕様変更でなく、
基本設計を変える＝仕様変更だという認識です。
ケースにも寄ると思うけど、今回要件レベルの変更は変わっていないと思うので。
今回のパターンだと基本設計の是正処置をした上で（本文に、「是正処置を講じた上でb工程から作業を再実施～」とあるから）製造工程からの修正になると思ってました・・・
2020.10.20 16:36
その他のスレッド
»[2289] 令和2年秋期試験 午後問10【サービスマネジメント】 投稿数:24»[2288] 令和2年秋期試験 午後問11【システム監査】 投稿数:42
»[2287] 令和2年秋期試験【受験前】 投稿数:1