HOME»応用情報技術者試験掲示板»問8:CI導入についての解答の吟味
投稿する
問8:CI導入についての解答の吟味 [1352]
中野さん(No.1)
問8CI導入の問4(1)について:
・ITecの解答予想:ア
・その他会社解答予想:エ
解答はアであっていると推測します。
理由については、仮に(エ)が正解であると仮定しましょう。当然(イ)もアドバイスとして適切であることになります。このとき、(イ)では、”一つの要求を細分化して開発する”というアドバイスなので、当然モジュール化された要求に対応する要求に対するソースコードは随時チェックインされることになります。したがって、(ア)のアドバイス”改善要望に対応したソースコードから随時チェックインする”ことは(イ)に矛盾します。以上が、私の見解です。不可解な点がございましたら、返答お願いします。また、その場合、解答の根拠を明確に説明して頂けると幸いです。よろしくお願いします。
・ITecの解答予想:ア
・その他会社解答予想:エ
解答はアであっていると推測します。
理由については、仮に(エ)が正解であると仮定しましょう。当然(イ)もアドバイスとして適切であることになります。このとき、(イ)では、”一つの要求を細分化して開発する”というアドバイスなので、当然モジュール化された要求に対応する要求に対するソースコードは随時チェックインされることになります。したがって、(ア)のアドバイス”改善要望に対応したソースコードから随時チェックインする”ことは(イ)に矛盾します。以上が、私の見解です。不可解な点がございましたら、返答お願いします。また、その場合、解答の根拠を明確に説明して頂けると幸いです。よろしくお願いします。
2018.10.25 22:18
中野さん(No.2)
内容の訂正;
・要求に対するが二重に記述されている点
・問8の設問4(1)です。
よろしくお願いします。
・要求に対するが二重に記述されている点
・問8の設問4(1)です。
よろしくお願いします。
2018.10.25 22:22
あああさん(No.3)
別に選択したもの以外の3つを同時にアドバイスするとは言っていないので、仮にアとイのアドバイスの行動が矛盾していようが関係ないのでは?
また、問題の作成ミスで、アもエもアドバイスとして誤りであるという可能性はありませんか。
また、問題の作成ミスで、アもエもアドバイスとして誤りであるという可能性はありませんか。
2018.10.25 23:03
aaaさん(No.4)
難しいとこですよね。仮にエが正しいと仮定すると、変更要求に対応した順から随時チェックインするというアドバイスが正しくなってしまいます。それでは、継続的インテグレーション(CI)を導入する効果のうち、バグを削減するという効果が意味をなしません。
2018.10.26 08:13
aaaさん(No.5)
追記:要求に対応したソースコードは、ものによっては規模がでかいため、CIツールを使って頻繁にワークフローを実施する必要があります。したがって、変更中のものでもチェックインすることでリグレッションテストを細かいレベルで実施し、他の既存機能への影響を与えないようにすることができます。
2018.10.26 08:51
Na2Ge2さん(No.6)
指摘3でXでビルドエラーが発生しているため、他のアプリの単体テストが意味をなさないと上がっていて、指摘1へのアドバイスで変更中のソースコードでもチェックインするが良しとする場合ですけど、
・変更中のソース=ビルドが通らないソース。という事ではない。
・設問4(3)で指摘3の対応として「アプリケーション毎にビルドとテストを行う(仮)」を行うのでビルドが通らなかったとしても他のアプリには影響を及ぼさない。
という事になりますか。
自分はエと回答しましたが、多分この2点の思い込みがあったせいだと思われます。
・変更中のソース=ビルドが通らないソース。という事ではない。
・設問4(3)で指摘3の対応として「アプリケーション毎にビルドとテストを行う(仮)」を行うのでビルドが通らなかったとしても他のアプリには影響を及ぼさない。
という事になりますか。
自分はエと回答しましたが、多分この2点の思い込みがあったせいだと思われます。
2018.10.26 09:20
M6さん(No.7)
Both of the two choices seem to be correct for me, the majority of people selected (エ)as their answers. Is there anyone who convince me logically for this equation? I'd appreciate your help.
2018.10.26 10:17
Nasuさん(No.8)
私は「エ」と回答しました。
抑えておきたい点として、はじめに2点挙げておきます。
----------------------------------------------
・サービス部のヒアリング内容
「改善要望をまとめて大規模に機能追加する開発方法から、短いサイクルで段階的に機能追加する開発方法に変更してほしい。」
・指摘1から考えられること
ワークフローの実施間隔を「2時間ごと」から「1週間に1度」に変更する。
----------------------------------------------
以上を前提として、各選択肢を見ていきます。
【ア:改善要望に対応したソースコードから随時チェックインする】
サービス部のヒアリング内容を考えると、「改善要望をこまめにチェックインしてほしい」というこのアドバイスは適切であると言えます。
【イ:一つの要求を細かな要求に細分化して開発する】
ワークフローの実施間隔が長くなるということは、ビルドとテストの頻度が減るということになり、その分だけ開発に時間をかけることが出来るようになります。よって、「一つの要求に時間をかけて吟味しながら開発してほしい」というこのアドバイスは適切であると言えます。
【ウ:プログラムを小さな機能単位に分割して開発する】
サービス部のヒアリング内容を考えると、「機能単位で分割して開発してほしい」というこのアドバイスは適切であると言えます。
【エ:変更中のソースコードでもよいので随時チェックインする】
指摘1から、ワークフローの間隔が長くなることを考慮すると、変更中のソースコードを随時チェックインする必要性が感じられません。また、変更中ということは、ソースコードを編集中ということなので、そのようなファイルをチェックインしてしまうと、ビルドエラーが発生する可能性が高くなると考えられます。
したがって、このアドバイスは不適切であると言えます。
----------------------------------------------
以上が私が解釈した内容ですが、間違っている可能性もあります(^▽^;)
よろしくお願いします。
抑えておきたい点として、はじめに2点挙げておきます。
----------------------------------------------
・サービス部のヒアリング内容
「改善要望をまとめて大規模に機能追加する開発方法から、短いサイクルで段階的に機能追加する開発方法に変更してほしい。」
・指摘1から考えられること
ワークフローの実施間隔を「2時間ごと」から「1週間に1度」に変更する。
----------------------------------------------
以上を前提として、各選択肢を見ていきます。
【ア:改善要望に対応したソースコードから随時チェックインする】
サービス部のヒアリング内容を考えると、「改善要望をこまめにチェックインしてほしい」というこのアドバイスは適切であると言えます。
【イ:一つの要求を細かな要求に細分化して開発する】
ワークフローの実施間隔が長くなるということは、ビルドとテストの頻度が減るということになり、その分だけ開発に時間をかけることが出来るようになります。よって、「一つの要求に時間をかけて吟味しながら開発してほしい」というこのアドバイスは適切であると言えます。
【ウ:プログラムを小さな機能単位に分割して開発する】
サービス部のヒアリング内容を考えると、「機能単位で分割して開発してほしい」というこのアドバイスは適切であると言えます。
【エ:変更中のソースコードでもよいので随時チェックインする】
指摘1から、ワークフローの間隔が長くなることを考慮すると、変更中のソースコードを随時チェックインする必要性が感じられません。また、変更中ということは、ソースコードを編集中ということなので、そのようなファイルをチェックインしてしまうと、ビルドエラーが発生する可能性が高くなると考えられます。
したがって、このアドバイスは不適切であると言えます。
----------------------------------------------
以上が私が解釈した内容ですが、間違っている可能性もあります(^▽^;)
よろしくお願いします。
2018.10.26 10:43
中野の知り合いさん(No.9)
確実ではないですが、(ア)ではないでしょうか?答えが(エ)が解答であると答えている方の考えは以下のフローにしたがっていると思います。(他の投稿を見る限り)
・変更中のコードをリポジトリにチェックインすると、CIツールにおいてビルドが通らないために指摘3の影響を悪化させる。したがって、解答としてのアドバイスとして正しくない。
しかしながら、Na2Ge2がおしゃっていました通り、指摘3に対しては、改善策を実施するため、アプリケーション間が独立させることができますし、細分された期間で、CIツールの効果(バグの早期発見、品質向上)が得られると思います。
(ア)のアドバイスでは導入目的である、テストの効率化を向上することはできません。
・変更中のコードをリポジトリにチェックインすると、CIツールにおいてビルドが通らないために指摘3の影響を悪化させる。したがって、解答としてのアドバイスとして正しくない。
しかしながら、Na2Ge2がおしゃっていました通り、指摘3に対しては、改善策を実施するため、アプリケーション間が独立させることができますし、細分された期間で、CIツールの効果(バグの早期発見、品質向上)が得られると思います。
(ア)のアドバイスでは導入目的である、テストの効率化を向上することはできません。
2018.10.26 10:47
中野の知り合いさん(No.10)
I translate what i mentioned into english for M6 just in case, which follows;
I anticipate (ア)as the answer, even though the majority of people chose (エ)as their answers like you said. I'd say the people think like this;
"if an related-engineer does the check-in activity with his/her incomplete code in repository, it may make the finding3 pointed out worse as it's not probably built. "
However, the finding3 must be addressed by changing the current workflow with no "folk" between built activity and unit-test activity.
Through the reason above, I support my answer.
I anticipate (ア)as the answer, even though the majority of people chose (エ)as their answers like you said. I'd say the people think like this;
"if an related-engineer does the check-in activity with his/her incomplete code in repository, it may make the finding3 pointed out worse as it's not probably built. "
However, the finding3 must be addressed by changing the current workflow with no "folk" between built activity and unit-test activity.
Through the reason above, I support my answer.
2018.10.26 11:12
中野の知り合いさん(No.11)
ワークフロー頻度を減らしてしまったら、CI導入効果がなくなってしまうと思います。
cIのベストプラクティスから逸脱してしまうのではないでしょうか....
私もそこまでの経験と知識がないので、なんとも言えませんが。
cIのベストプラクティスから逸脱してしまうのではないでしょうか....
私もそこまでの経験と知識がないので、なんとも言えませんが。
2018.10.26 11:25
Na2Ge2さん(No.12)
指摘3の対応は設問4(3)の解答によるもので、その解答が正しいかどうかはわからないので、指摘3の対策により「ビルドが通らないチェックインが問題ない」とするのは前後関係に矛盾が生じませんか?
それと一つのアプリを複数人で開発した場合、やっぱりCIが意味をなさなくなるのではないですか?
そう思い、先の書き込みには「変更中のソース=ビルドが通らないソース」という自分の思い込みがあったのでは?と書きました。
それと一つのアプリを複数人で開発した場合、やっぱりCIが意味をなさなくなるのではないですか?
そう思い、先の書き込みには「変更中のソース=ビルドが通らないソース」という自分の思い込みがあったのでは?と書きました。
2018.10.26 11:52
Na2Ge2さん(No.13)
ちょっと周りくどい書き方をしましたが、聞きたいのは
「変更中のソース=ビルドが通らないソース」ですか?という事です。
「変更中のソース=ビルドが通らないソース」ですか?という事です。
2018.10.26 12:01
中野の知り合いさん(No.14)
確かに、前後関係は逆になってしまいますね。そこがネックとなっているのですが、変更が多岐にわたるということから、バグの特定をするためチェックインの頻度は現在のワークフローの2時間くらいがベストだと思います。
2018.10.26 12:17
ギリギリ間に合ったさん(No.15)
私もアとエで迷い、最終的にエにしました。しかし、自信をもってエとは言えません。
理由は「改善要望」と「要求」がどう対応するのか?(開発期間の大小関係が問題文中から読み取れなかったから)が不明だったためです。
改善要望-機能の関係ならサービス部の記述より、改善要望 = {機能追加1, 機能追加2, ... 機能追加n}ということが読み取れます。しかし、改善要望-要求の関係は?
改善要望の開発期間の最大値は6か月と記載されています。しかし最小値は記載されていません。
要求という文言はいきなり出てきて「チェックインに1週間」と記載されています。
修正中のソースコードが「エラーがないか」「エラーがあるか」が明確に判断ができないのと同じで、改善要望>要求、改善要望<要求が明確に判断できません。
最終的にはどちらが開発に影響があるかを考え「エ」を選択しました。
出題ミスであればいいと思っています。
理由は「改善要望」と「要求」がどう対応するのか?(開発期間の大小関係が問題文中から読み取れなかったから)が不明だったためです。
改善要望-機能の関係ならサービス部の記述より、改善要望 = {機能追加1, 機能追加2, ... 機能追加n}ということが読み取れます。しかし、改善要望-要求の関係は?
改善要望の開発期間の最大値は6か月と記載されています。しかし最小値は記載されていません。
要求という文言はいきなり出てきて「チェックインに1週間」と記載されています。
修正中のソースコードが「エラーがないか」「エラーがあるか」が明確に判断ができないのと同じで、改善要望>要求、改善要望<要求が明確に判断できません。
最終的にはどちらが開発に影響があるかを考え「エ」を選択しました。
出題ミスであればいいと思っています。
2018.10.26 12:45
Rさん(No.16)
エクストリームプログラミングではテスト駆動開発によるフィードバックを利用します。
確かに変更中≠ビルドが通らないですが、変更中の単体テストに意味があるとは思えません。
それにビルドが通らないプログラムをアップされても困ります。
確かに変更中≠ビルドが通らないですが、変更中の単体テストに意味があるとは思えません。
それにビルドが通らないプログラムをアップされても困ります。
2018.10.26 12:56
Aさん(No.17)
テスト駆動開発では、改善要望単位で単体テストを行うのではなく、もっと細かいモジュール単位で単体テストを行うので、(ア)のアドバイスではまずい気がします。改善要望が単純な機能追加とは限りません。
2018.10.26 13:20
Nasuさん(No.18)
スレッドの内容とは少し逸れてしまいますが、今回のように受験者の解釈によって解答が分かれてしまう問題は過去にも出題されており、その度に掲示板で議論が起こっています。
【30年春試験 セキュリティの問題に関する議論】
https://www.ap-siken.com/bbs/1130.html
【29年秋試験 セキュリティの問題に関する議論】
https://www.ap-siken.com/bbs/0898.html
解釈が分かれてしまうような設問を試験問題として出題するのは
IPAさんの出題ミスだと思いますし、良いこととは思いませんが、
それをきっかけにして、受験者同士がお互いの考えを主張して議論し合うことは、
その分野に関して、より知識が深まっていくことに繋がるのでは?
・・・と、プラス思考で考えるようにしています(^O^)
【30年春試験 セキュリティの問題に関する議論】
https://www.ap-siken.com/bbs/1130.html
【29年秋試験 セキュリティの問題に関する議論】
https://www.ap-siken.com/bbs/0898.html
解釈が分かれてしまうような設問を試験問題として出題するのは
IPAさんの出題ミスだと思いますし、良いこととは思いませんが、
それをきっかけにして、受験者同士がお互いの考えを主張して議論し合うことは、
その分野に関して、より知識が深まっていくことに繋がるのでは?
・・・と、プラス思考で考えるようにしています(^O^)
2018.10.26 21:51
ささにしきさん(No.19)
私はエだと思います。
『変更中のソースコード』ということは誤ったソースコードとも受け取れるからです。
『変更中のソースコード』ということは誤ったソースコードとも受け取れるからです。
2018.10.29 10:45