・自社開発部分の外部への開示→開示の要否と開示が必要な場合の開示判断を、ソフトウェア開発部門と製品企画部門と協議。・性能要件の達成や独自ハードウェアの制御に関するOSS部分の修正と自社開発ソフトウェアの組み合わせの調整→ソフトウェア開発部門と協議。OSS及び市販品と自社開発ソフトウェアの組み合わせについては、考慮点も必要です。考慮点は、利点と注意点で構成します。以下は、私が想定する考慮点です。・利点→OSSのソースコードが公開されているので、ソースコードレベルでの製品機能や製品性能の最適化を図れる・注意点→自社での最適化した組み合わせの保証やサポートがなく問い合わせも困難、OSS自体も保障されているわけではない、開示が必要なモジュールの採否判断が求められることがある、など。設問ウでは、「開発段階で発生した課題、目的の達成度、これを踏まえたOSS導入の是非に対する判断の妥当性、今後の対応」が問われています。開発段階で発生した課題については、本文中に記載した懸念点は考慮した、しかし実際にはある懸念点の影響は予想以上に大きく課題となった、という方向になるでしょう。標準的なデバイスドライバの品質が予想外に低くそのサポートが得られない、という課題が考えられます。品質が低下する部分に関する暫定プログラムを作成、適用した」と課題を解決した方法を提示しておきましょう。判断の妥当性については、論文の性質上、「いくつかの課題は発生したが、それら課題をすべて所定のコスト及び機関で解決できたので、判断は妥当であった」と結論することになるでしょう。・品質が低下する部分に関する暫定プログラムをOSSとして公開しOSSコミュニティの品質向上に寄与する・逆に標準的なデバイスドライバの修正が行われるかどうかを定期監視し修正版を製品に組み込む仕組みを構築する・活用された外部専門家の知見を組織内に取り込み教育する・開発時に発生した課題に類似した課題が運用段階で発生することを見越したサポート体制や方法論の強化指示といったところが挙げられます。秋試験の学習に向けて是非ともお読みくださいませ。よろしければ、クリックをお願い致します。「情報システムの移行方法について」こんばんは。「情報システムの移行方法について」についてコメント致します。設問アでは、「対象業務の概要、現システムの概要、現システムから新システムへの変更の概要」が問われています。システムアーキテクトでは毎回問われる「情報システムの概要と対象の業務の概要の書き分け」は、今回も必須です。こちらは、ほぼノーヒントです。現システムから新システムへの変更の概要としてデータを比較する際の制約となりそうな事項や移行後の障害となりそうな事項を記載する、といった対応しか取れないように見えます。逆にいうと、この問題ではどのような事例にも対応できる、と言えます。設問イでは、踏まえた制約条件、選択した移行方法、選択した理由が問われています。業務要件を評価した際の手順、そのときの評価項目と重みづけの考え方が問われています。3種類の例が挙げられていますが、いずれも「理由」「選択した移行方法」という構造となっています。いずれも「対象業務の特性による制約条件」については触れられていないので自らで編み出す必要があります。システムアーキテクトの講評では業務要件に関する記述が少ないと毎回指摘されているため、この問題の合否は「対象業務の特性による制約条件」を記述しきれるかどうかにあると言えます。関する工夫点が記載されています。秋試験の学習に向けて是非ともお読みくださいませ。よろしければ、クリックをお願い致します。「業務要件の優先順位付けについて」こんばんは。本日から、システムアーキテクトの論述試験についてコメントします。「業務要件の優先順位付けについて」についてコメントいたします。設問アでは、「情報システムの概要、情報システムの開発の目的、対象の業務の概要」が問われています。システムアーキテクトでは毎回問われる「情報システムの概要と対象の業務の概要の書き分け」は、今回も必須です。ノーヒントに見えますが、問題文の交番部分に書かれた事項を考慮して、以下のように考えれば記載の方向性も少しは見えてくるでしょう。情報システム→情報システムで適用する技術や他の連携するシステムの存在とその中での対象情報システムの位置づけが書かれているとよいでしょう。→目標の開発コストや開発期間は、業務要件の優先順位付けの根拠としてあったほうがよいでしょう。実際の目的としては、業務コスト削減や業務のスピードアップが挙げられます。→まず、業務特性を記載します。他に、業務を行う組織体制、要員の習熟度もあるとよいでしょう。各項目を100字程度ずつ準備するだけで、800字目いっぱい論述できます。設問イでは、業務要件を評価した際の手順、そのときの評価項目と重みづけの考え方が問われています。3つの事項が問われますが、それぞれ、手順、項目、考え方といった、異なる側面が問われていることには注意が必要です。手順については、問題文の項番1から4のうち、項番1から3相当の概要を解答します。4項については優先順位付けの内容となるので除外します。この手順は、システムアーキテクトや開発組織が個別に行うのでなく、利用者とともに行う手順であるとベターです。評価項目については、業務面の評価項目とシステム面の評価項目の両面を解答します。業務面の評価項目としては「組織の整備や教育訓練などの準備の負荷、業務コスト削減や業務のスピードアップの度合い」が挙げられます。システム面の評価項目としては「適用する技術の検証の必要性、影響する他の情報システムの修正を含む開発コスト及び開発期間」が挙げられます。設問ウの回答に向けて、定量評価項目と定性評価項目という観点で分類してもよいでしょう。問題文に具体的な記述がないので実質的にノーヒントでの解答となります。設問アの記述をどの程度具体化できたかの勝負になると思われます。ここでは具体的な重みづけの内容が問われているわけではないことには十分にご注意ください。(補足的に重みづけの内容を解答することには支障はありません)設問ウでは、業務要件ごとの評価のやりかた、業務要件の優先順位付けについて問われています。いくつかの業務要件について問われているので、例として、最高の優先順位と思われる2要件について論述するといった考え方があります。評価のやりかたとしては、3項に記述があるように、定量的に評価する必要があります。要する期間、業務スピードアップの度合い、開発期間→時間など。定性的な項目についても、定量化することが求められています。適用技術としてIoTを挙げる場合、新技術の適用内容として定性項目と考えられます。この場合は、適用する技術の検証や業務スピードアップの度合い等に評価を反映するだけでなく、加点項目を事前に決めて、その加点項目がいくら増える、といった表現を行うとよいでしょう。この時点では、まだ重みづけは考慮しません。次に、業務要件の優先順位付けでは、重みづけを考慮した上で最終的な優先順位付けを解答します。この決定を、利用者とともに行っていると記述できるとベターです。・評価についてはそのやり方が問われていて、評価値は補足に過ぎない・優先順位付けについては結果が問われていると、それぞれ何が問われているかを理解することは重要です。秋試験の学習に向けて是非ともお読みくださいませ。よろしければ、クリックをお願い致します。