情報処理試験のメモ2010/10/18 00:28

情報処理試験は終了した。。。
あまり勉強もしなかったので合格できる気はしていないが、わずかばかり勉強する中でも仕事に応用できそうな事項があったのでメモする。


■業務フローの表記方法
業務フローはシステム構築の要件定義段階で良く書くが、表記方法を標準化したい場合に何に従うべきか?

→情報処理の予想問題の中で出てきたキーワード「BPMN」
@ITの特集記事リンク
http://www.atmarkit.co.jp/farc/rensai/bpmn01/bpmn01.html

UMLのアクティビティ図でも同種の事ができるが、BPMNの方が表現しやすいという評価が上記でされている。
他には、内部統制関連の資料でもフローが描かれるが、あれも統一できないものだろうか・・・ 
基幹システムの世界ではSOAの流れになっているが、この記述も「ビジネスプロセスに紐付くサービス」という形で表現頂けるとありがたい気がする。


■システム要件定義
機能要件 / 非機能要件 を意識した要件定義が必要。特にアプリ側の担当者としては非機能要件を疎かにしがちな気がする。


■システム関連図
システム間でどのようなデータのやり取りをするのか図に表わす事は良くあるし、それぞれその時の目的に合わせて必要な部分にフォーカスを当てた図となる。いきなりファイル単位での連携図になってしまう事もある。
→DFDをレベル0(全社レベル)から順に詳細化して作成すれば、わかりやすい気がしたが、「図をドリルダウンする」という文化というか表現手法が追いついていない気がする。PPTで描こうとすると自分でページ切りしてやらないといけない。FLASHならカッコよく作れる気もするが、そんな事に時間を費やせる余裕も無い。そうなるとせいぜい2段階位で図を作る感じになる。


■モジュール分割の良否判定
システム保守をしていると、不具合対応だとか仕様変更だとかいった場面で、手を入れようとする機能の変更がどこまで影響を与えるかを調べる必要が出て、それが意外な所に影響を与える事がわかってしまったりする事がある。こう考えると、その機能の変更はタイヘン!という事になるが、そもそも元の機能の設計がダメだという事が言えないか。いや、言えるはず。
モジュールの結合度を、設計レビュー時にきちんと評価すれば、それがダメな設計か良い設計か(レビュー者が経験が浅かったとしても)判断できるのではないか。あまりそうした指標での評価ができていない気がする。機能を満たす事に主眼が置かれていて、あとはバグが無ければ良しとされてしまう。運用性というのは見えづらい部分なので仕方ないかもしれないが…

情報処理試験の勉強中のつぶやき2010/06/11 23:05

まずは午前の勉強。すこしやってみて感じた所。
・逆ポーランド表記法は仕事で一度もお目にかかった事が無いが、要るのか…?
・1600×1200画素24bitのデジカメでは、8Mのメモリに何枚入るか→答え:1枚。
 ちょっとリアリティに欠ける問題かも。。。

など、個人的に不思議に思う点があるが、問題として出る以上しかたない。午前と午後Iは、論文添削をするに値しない人達を除外するためのフルイに過ぎないのかも…と思う。

情報処理試験をめざす2010/06/08 23:13

秋の情報処理試験を目指す事にした。
マイコンいじってる事も勉強にならないわけではないが、目指す所は仕事の関係上からシステムアーキテクト試験(SA)であって、エンベデッドシステムスペシャリスト試験(ES)じゃないので、あまり試験には寄与しなさそうだ。ESもマジメに勉強して取ったら、マイコン素人からは卒業できるのだろうか。システム開発という言葉上はSAもESも同じだが、ESの方は技術的、SAは業務的な領域の高度知識が必要になるし、システム開発にあたっての勘所も変わってくるのだと思う。

ESは春試験だし、午前は同じ領域だから、午後一をちょっと触ってみても面白いかもしれない。
シラバスを見ても、ESはガチでハードな感じ。ハードウェアベンダーさんだったら、きっと取らないといけないのだろうか…? いろいろな所の資格保有者数を見ても、受験者数を見ても、イマイチ人気のない試験のようだが。。

■情報処理推進機構:情報処理技術者試験センター:情報処理技術者試験制度:制度の概要
 http://www.jitec.jp/1_11seido/seido_gaiyo.html