2016/12/03

システムアーキテクト 午後2 平成28年問3 「組込みシステムにおけるオープンソースソフトウェアの導入について」

こんばんは。Cobbyこと小林 健了です。

システムアーキテクト 午後2 平成28年問3 「組込みシステムにおけるオープンソースソフトウェアの導入について」についてコメント致します。

類題は平成23年問3「組込みシステムの開発におけるプラットフォームの導入について」になります。
これまで、開発手法、信頼性設計、モジュール設計が2年連続で問われている中では、変化はあるものの
準備は必要と思われるテーマです。
この問題の特徴としては、後述しますが「関連部署との協議」がキーになります。
なぜなら、組込みシステムの過去問題ではこの視点で問われたことがないからです。
初学者には厳しい要求だったかもしれません。

設問アでは、「組込みシステムの概要、オープンソースソフトウェア (以下、OSSという) 導入の是非を検討するに至った経緯、
OSSの導入目的」が問われています。
組込みシステムの概要はノーヒントになりますが、専門化、高度化された機能、短い開発期間、ライフサイクルであることを主張できるとよいでしょう。そのための製品選定も重要です。同時に、のちの記述のための、製品性能と独自ハードウェアについて記述しておきましょう。
OSS導入の是非を検討するに至った経緯は、製品の機能に対応するために社内で保有しない技術があること、
標準技術を採用する必要があること、他方、そのためのコストや期間が限定されていることを挙げることになります。
OSS導入の目的としては2種類考えられます。
・顧客からOSSの導入を要求される場合。
・自発的にOSSを導入する場合は、無償→コスト低減、開発の利便性→開発期間の短縮
とつなげると良いでしょう。開発成果やデファクトスタンダードのくだりについては、それぞれをOSS導入の是非を検討するに至った経緯や
組込みシステムの概要に関連付けられればなおよいでしょう。

設問イでは、「関連部署との協議内容、OSS及び市販品と自社開発ソフトウェアとの組み合わせに関する考慮点」が
問われています。
問題文を参考にしながら関連部署との協議内容の一例を示します。
・OSS導入による保証及びサポート体制の構築→保証体制は品質保証部門と、サポート体制はサポート部門、運用部門、保守部門と協議。方法論も併せて。
・自社開発部分の外部への開示→開示の要否と開示が必要な場合の開示判断を、ソフトウェア開発部門と製品企画部門と協議。
・性能要件の達成や独自ハードウェアの制御に関するOSS部分の修正と自社開発ソフトウェアの組み合わせの調整→ソフトウェア開発部門と協議。
更に、OSS及び市販品と自社開発ソフトウェアの組み合わせについては、考慮点も必要です。
考慮点は、利点と注意点で構成します。以下は、私が想定する考慮点です。
・利点→OSSのソースコードが公開されているので、ソースコードレベルでの製品機能や製品性能の最適化を図れる
・注意点→自社での最適化した組み合わせの保証やサポートがなく問い合わせも困難、OSS自体も保障されているわけではない、開示が必要なモジュールの採否判断が求められることがある、など。

設問ウでは、「開発段階で発生した課題、目的の達成度、これを踏まえたOSS導入の是非に対する判断の妥当性、今後の対応」が問われています。
開発段階で発生した課題については、本文中に記載した懸念点は考慮した、しかし実際にはある懸念点の影響は予想以上に大きく課題となった、という方向になるでしょう。
例えば、標準的なデバイスドライバの品質が予想外に低くそのサポートが得られない、という課題が考えられます。
ただ、単に課題として放置するだけでなく、例えば「外部専門家の知見とソースが公開されていることを活用し、
品質が低下する部分に関する暫定プログラムを作成、適用した」と課題を解決した方法を提示しておきましょう。
判断の妥当性については、論文の性質上、「いくつかの課題は発生したが、それら課題をすべて所定のコスト及び機関で解決できたので、判断は妥当であった」と結論することになるでしょう。
今後の課題としては、先述の例では、
・品質が低下する部分に関する暫定プログラムをOSSとして公開しOSSコミュニティの品質向上に寄与する
・逆に標準的なデバイスドライバの修正が行われるかどうかを定期監視し修正版を製品に組み込む仕組みを構築する
・活用された外部専門家の知見を組織内に取り込み教育する
・開発時に発生した課題に類似した課題が運用段階で発生することを見越したサポート体制や方法論の強化指示
といったところが挙げられます。

今回の問では、単なる開発者という視点よりは、開発管理や部署のとりまとめといった、少し高めの視点が求められる問題でした。

「情報処理教科書 高度試験午後I記述 春期・秋期」にインタビューを、
「情報処理教科書 高度試験午後II論述 春期・秋期」に体験記を寄稿しておりますので、
秋試験の学習に向けて是非ともお読みくださいませ。



よろしければ、クリックをお願い致します。

2016/11/21

システムアーキテクト 午後2 平成28年問2 「情報システムの移行方法について」

こんばんは。Cobbyこと小林 健了です。

システムアーキテクト 午後2 平成28年問2 「情報システムの移行方法について」についてコメント致します。

設問アでは、「対象業務の概要、現システムの概要、現システムから新システムへの変更の概要」が問われています。
システムアーキテクトでは毎回問われる「情報システムの概要と対象の業務の概要の書き分け」は、今回も必須です。
こちらは、ほぼノーヒントです。
対象業務として関与する組織、データの整合性の必要性、社会的な影響度に触れる、
現システムから新システムへの変更の概要としてデータを比較する際の制約となりそうな事項や移行後の障害となりそうな事項を記載する、
といった対応しか取れないように見えます。
逆にいうと、この問題ではどのような事例にも対応できる、と言えます。

設問イでは、踏まえた制約条件、選択した移行方法、選択した理由が問われています。業務要件を評価した際の手順、そのときの評価項目と重みづけの考え方が問われています。
3種類の例が挙げられていますが、いずれも「理由」「選択した移行方法」という構造となっています。
移行方法としては、一斉移行か段階移行 (部門ごともしくは並行稼働を実施) となっています。
いずれも「対象業務の特性による制約条件」については触れられていないので自らで編み出す必要があります。
システムアーキテクトの講評では業務要件に関する記述が少ないと毎回指摘されているため、
この問題の合否は「対象業務の特性による制約条件」を記述しきれるかどうかにあると言えます。

設問ウでは、移行作業後の業務に支障が出ないようにするための工夫と想定した支障について問われています。
移行作業中、移行作業後に関する工夫点が記載されています。
それぞれ、支障としては以下が考えられるでしょう。
・移行作業中→作業の遅延、障害の発生
・移行作業後→データ不整合の発生

この問題では、移行作業と業務をいかに関連付けるかがキーになると言えます。

「情報処理教科書 高度試験午後I記述 春期・秋期」にインタビューを、
「情報処理教科書 高度試験午後II論述 春期・秋期」に体験記を寄稿しておりますので、
秋試験の学習に向けて是非ともお読みくださいませ。



よろしければ、クリックをお願い致します。

2016/11/20

システムアーキテクト 午後2 平成28年問1 「業務要件の優先順位付けについて」

こんばんは。Cobbyこと小林 健了です。

本日から、システムアーキテクトの論述試験についてコメントします。
システムアーキテクト 午後2 平成28年問1 「業務要件の優先順位付けについて」についてコメントいたします。

設問アでは、「情報システムの概要、情報システムの開発の目的、対象の業務の概要」が問われています。
システムアーキテクトでは毎回問われる「情報システムの概要と対象の業務の概要の書き分け」は、今回も必須です。
一見ノーヒントに見えますが、問題文の交番部分に書かれた事項を考慮して、以下のように考えれば記載の方向性も少しは見えてくるでしょう。
情報システム
→情報システムで適用する技術や他の連携するシステムの存在とその中での対象情報システムの位置づけが書かれているとよいでしょう。
情報システムの開発の目的
→目標の開発コストや開発期間は、業務要件の優先順位付けの根拠としてあったほうがよいでしょう。
　実際の目的としては、業務コスト削減や業務のスピードアップが挙げられます。
対象の業務の概要
→まず、業務特性を記載します。他に、業務を行う組織体制、要員の習熟度もあるとよいでしょう。
各項目を100字程度ずつ準備するだけで、800字目いっぱい論述できます。

設問イでは、業務要件を評価した際の手順、そのときの評価項目と重みづけの考え方が問われています。
3つの事項が問われますが、それぞれ、手順、項目、考え方といった、異なる側面が問われていることには注意が必要です。
手順については、問題文の項番1から4のうち、項番1から3相当の概要を解答します。4項については優先順位付けの内容となるので除外します。
この手順は、システムアーキテクトや開発組織が個別に行うのでなく、利用者とともに行う手順であるとベターです。
評価項目については、業務面の評価項目とシステム面の評価項目の両面を解答します。
業務面の評価項目としては「組織の整備や教育訓練などの準備の負荷、業務コスト削減や業務のスピードアップの度合い」が挙げられます。
システム面の評価項目としては「適用する技術の検証の必要性、影響する他の情報システムの修正を含む開発コスト及び開発期間」が挙げられます。
設問ウの回答に向けて、定量評価項目と定性評価項目という観点で分類してもよいでしょう。
重みづけの考え方は、「業務の特性や情報システムの開発の目的などを踏まえ」とありこの部分がヒントとはなりますが、
問題文に具体的な記述がないので実質的にノーヒントでの解答となります。
設問アの記述をどの程度具体化できたかの勝負になると思われます。
特に、ここでは具体的な重みづけの内容が問われているわけではないことには十分にご注意ください。
(補足的に重みづけの内容を解答することには支障はありません)

設問ウでは、業務要件ごとの評価のやりかた、業務要件の優先順位付けについて問われています。
いくつかの業務要件について問われているので、例として、最高の優先順位と思われる2要件について論述するといった考え方があります。
評価のやりかたとしては、3項に記述があるように、定量的に評価する必要があります。
例えば準備の負荷、業務コスト削減量、開発に要する人件費→工数、準備に要する期間、業務スピードアップの度合い、開発期間→時間など。
定性的な項目についても、定量化することが求められています。
例えば、適用技術としてIoTを挙げる場合、新技術の適用内容として定性項目と考えられます。
この場合は、適用する技術の検証や業務スピードアップの度合い等に評価を反映するだけでなく、加点項目を事前に決めて、その加点項目がいくら増える、といった表現を行うとよいでしょう。
なお、この時点では、まだ重みづけは考慮しません。
次に、業務要件の優先順位付けでは、重みづけを考慮した上で最終的な優先順位付けを解答します。
この決定を、利用者とともに行っていると記述できるとベターです。
設問ウにおいても、
・評価についてはそのやり方が問われていて、評価値は補足に過ぎない
・優先順位付けについては結果が問われている
と、それぞれ何が問われているかを理解することは重要です。

この問題では、「定量的な評価」がキーになると言えます。

「情報処理教科書 高度試験午後I記述 春期・秋期」にインタビューを、
「情報処理教科書 高度試験午後II論述 春期・秋期」に体験記を寄稿しておりますので、
秋試験の学習に向けて是非ともお読みくださいませ。



よろしければ、クリックをお願い致します。

2015/11/19

午後Ⅱ論述試験概説 システムアーキテクト 問3

こんばんは。Cobbyこと小林 健了です。

本日は、平成27年度「システムアーキテクト」の午後Ⅱ論述試験の概説です。

第3回目は、システムアーキテクト 問3 「組込みシステム製品を構築する際のモジュール間
インタフェースの仕様決定について」です。
設問文、問題文から、どのような論述が求められていたかについてみていきましょう。
この問題自体は難しくはないので、愚直に設問イを具体的に書けたかどうかが
キーとなるでしょう。
本問では3ケースが問題文に記載されていますので、それぞれ①②③で示します。

設問ア あなたが携わった組込みシステム製品の概要、特徴、及び要件について、
モジュール間インタフェース仕様で配慮した内容を含めて、800字以内で述べよ。

1.1 組込みシステム製品の概要、特徴
問題文にはヒントはありませんが、相応の見識があれば書けるでしょう。
ただし、①「開発着手後の仕様変更や追加が想定される」②「少ないハードウェアで
大きなパフォーマンスが要求される」③「長期間使用されることが求められる」ことに
つながっている必要はあります。

1.2. 組込みシステム製品の要件
問題文から、
②「少ないハードウェアで大きなパフォーマンスが要求される」ことを数値で表現します。
③「長期間使用されることが求められる」ことを数値で表現します。
問題文にはありませんが
①「開発着手後の仕様、追加が想定される」ことから、トレンド的な要求が例として
IoT対応、センサネットワークの通信プロトコル対応等が挙げられます。

1.3 モジュール間インタフェース仕様で配慮したこと
問題文から、
①「開発着手後の仕様の変更、追加が想定される」ことを記述します。
③「将来、保守、リプレースなどでモジュールの交換が発生することがある」ことを記述します。
問題文にはありませんが、
②モジュール間の通信量が多くなることを表現します。

設問イ 設問アで述べた組込みシステム製品に求められる要件に適切に対応するために
考慮したモジュール間インタフェースについて、将来発生しうると想定した事態の内容、
及びその事態に対してどのように配慮したかを、800字以内1,600字以内で具体的に述べよ。

2.1. 将来発生しうると想定した事態
問題文から、
③「組込み製品を構成するモジュールの陳腐化、生産中止などの理由から新たなモジュールに
置き換えなければならなくなる」ことを記述します。
問題文にはありませんが、
①「仕様の変更、追加」により影響を受ける範囲が大きくなり、修正対応工数が増大する、
等と記述します。
②モジュール間の通信が多すぎて所定のパフォーマンスを出せないことを記述します。

2.2 その事態への配慮
問題文から、
①「他のモジュールに影響しないようにインタフェースの仕様を決定し、柔軟性を持たせる。
そのためには、もj-る間を祖結合とし (モジュールの結合度) 、機能を極力独立させるような
インタフェースにする (最適なモジュール分割)」と記述します。
②「全体を見つけ都合としたインタフェースにする」と記述します。
問題文にはありませんが、
②モジュール分割については、組込みシステムによりますが過度のモジュール分割を避ける旨の
配慮があってもよいでしょう。
③保守単位に沿ったモジュール分割、交換により別モジュールを接続できるよう、
標準化されたインタフェース (装置内イーサネット接続等) を採用する、が考えられます。

設問ウ 設問イで述べたモジュール間インタフェースの仕様決定が、組込みシステムに製品の
開発にどのように影響し、組み込みシステム製品の納入後に、どのように評価されたかを、
600字以上1,200字以内で具体的に述べよ。

3.1 製品開発時の影響
問題文にはヒントはありませんが、
①「開発着手後の仕様変更や追加が多く発生したが、疎結合化、機能ごとのモジュール化により
仕様変更や追加で生じた追加工数を最小化できた」
②「想定したパフォーマンスを確保できた」
③「保守、リプレースのケースを多く想定し、多様な交換に対する互換性を確保した」等の
記述を行います。

3.2. 製品納入後の評価
問題文にはヒントはありませんが、
③「実際に対象モジュールが陳腐化してしまったが、インタフェースが標準化されたもので
あったためすぐに字バージョンのモジュールを接続して稼働を確保できた」等の記述を行います。


ここまでお読みくださいまして、ありがとうございます。
「情報処理教科書 高度試験午後II論述 春期・秋期」に体験記を寄稿しておりますので、
是非ともお読みくださいませ。


よろしければ、クリックをお願い致します。

2015/11/04

午後Ⅱ論述試験概説 システムアーキテクト 問2

こんばんは。Cobbyこと小林 健了です。

本日も、平成27年度「システムアーキテクト」の午後Ⅱ論述試験の概説です。

第2回目は、システムアーキテクト 問2 「業務の課題に対応するための業務機能の変更又は
追加について」です。
こちらは、開発経験者向けの問題といえるでしょう。それでも、システムアーキテクトと
その他のスペシャリスト系を決定的に分ける業務への理解が必要であることは変わりありません。
なぜなら、システムアーキテクトは、開発すること自体がミッションではなく、業務の必要性に
応じて情報システムにより課題を解決する立場にあるからです。
問題文については1業務の事例しか紹介されていませんが、同様の事象を経験している方が
多いと考えられることから、難易度は普通と判断します。
それでは、設問文、問題文から、どのような論述が求められていたかについてみていきましょう。

設問ア あなたが携わった情報システムにおいて、業務機能の変更又は追加を必要とするような
業務の課題はどのようなものであったか。対象となった情報システムの概要、及び業務の
概要とともに800字以内で述べよ。

1.1 業務の概要
まず前提として、システムアーキテクトの論述では「業務」と「情報システム」を明確に
書き分けてください。この書き分けが、システムアーキテクトとその他のスペシャリスト系を
決定的に分けるポイントと考えます。
業務の概要については、各自で準備します。問題文の例を活用すると、
・通信販売業
・出荷指示、作業計画、作業指示、ピッキング→物流業務も行っている
と言えます。

1.2 情報システムの概要及び特徴
ここでも、「業務」と「情報システム」を混同しないように留意します。
情報システムの概要については、各自で準備します。情報システムの特徴については、
問題文内の例を活用すると
・受注内容の変更を受け付けられる→受注システム
・出荷指示、作業計画、作業指示、ピッキング→物流システム、作業管理システム等
と言えます。更に、「受注内容の変更が翌日以降分だけ可能である」等、設問イにつながる
制約を記述できるとよいでしょう。
注意が必要な点としては、本問では「業務機能の変更又は追加」が問われているので、
すでに存在して稼働している情報システムである必要があります。

1.3 業務の課題
当然ですが、既存の情報システムの業務機能の変更または追加を伴う程度の課題である必要が
あります。ここでは、「受注量や納品場所などの変更を出荷指示直前まで受け付け、受注当日中に
出荷したい」といったものになります。留意点は、
・業務に関する事項であること。システムに関する事項ではない。
・「～したい」という表現とする
となります。

設問イ 設問アで述べた業務の課題に対応するために、どのような業務機能の変更又は追加が
必要となったか。業務の課題に対応できると考えた理由とともに、800字以上1,600字以内で
具体的に述べよ。

2.1 必要となった業務機能の変更又は追加
ここでは、必要となった業務機能の変更又は追加について記述します。
問題文の例示が充実しているので、これに従えると楽に対応できます。
・翌日以降分が可能であった受注内容の変更を、出荷指示直前まで受け付け、変更内容を
　作業計画や作業指示に反映する。そのため、受注から出荷指示までの既存の各業務機能を、
　日時起動方式から随時起動方式に変更する (変更の例)。
・出荷作業時間を短縮するために、既存の出荷指示機能に、出荷作業者の倉庫内の移動距離が
　最短となるピッキング順序を指示する機能を追加する (追加の例)。

2.2 業務の課題に対応できると考えた理由
ここには対応する問題文の記述がないため、設問アの内容等を基に記述します。

設問ウ 設問イで述べた業務機能の変更又は追加の際、既存機能の活用や既存の情報システムへの
影響の最小化のために、どのような工夫をしたか、600字以上1,200字以内で具体的に述べよ。

3.1 既存機能の活用のための工夫
問題文の例示が充実しているので、これに従えると楽に対応できます。
・既存の出荷指示のロジック部分をそのまま利用し、処理方式を随時起動方式に変更することで、
　受注内容が変更されウ都度、出荷指示内容に反映できるようにする。

3.2 既存の情報システムへの影響の最小化のための工夫
問題文の例示が充実しているので、これに従えると楽に対応できます。
・出荷機能に影響を与えないよう、ピッキング順序を最適化する機能を新たに開発し、既存の
　情報システムから起動する方式にする。

ここまでお読みくださいまして、ありがとうございます。
「情報処理教科書 高度試験午後II論述 春期・秋期」に体験記を寄稿しておりますので、
是非ともお読みくださいませ。


よろしければ、クリックをお願い致します。