情報処理試験のメモ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/11/18 12:16

突然のコメントすいません。

このブログをみて感動しました!
今授業でarduinoの勉強をしてるんですが、回路の知識がまったくない状態で、いきなり「グループで好きな物作れ。」と言われえて困惑しています。

もしよろしかったら、すこしarduinoの質問をさせてもらっていいですか?

_ aki ― 2010/11/19 01:11

どうぞ。どうぞ。
わたしも電子工作に触れたのはここ1年程度の素人なので、あまり力になれないかもしれないですけど、わかる範囲でお答えしますよ。…と思ったら連絡先がなかったのでとりあえず作りました。
aki9987@gmail.com

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※なお、送られたコメントはブログの管理者が確認するまで公開されません。

名前:
メールアドレス:
URL:
コメント:

トラックバック

このエントリのトラックバックURL: http://isa.asablo.jp/blog/2010/10/18/5421854/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。