鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
IPA、経営層に「非機能要件」をわかりやすく伝える読本を公開
情報処理推進機構（IPA）のソフトウェア・エンジニアリング・センター（SEC）は2011年4月27日、「経営に活かすIT投資の最適化」と題した無償の読本をホームページ上で公開した。システム要件のうち機能要件以外の要件すべてを指す、性能や信頼性といった「非機能要件」の重要性をユーザー企業にわかりやすく伝えることを狙った。 読本ではまず、自動車の購入者とディーラーの会話を通して、非機能要件のイメージをつかませる。その後ネットサービス企業のトラブル事例から非機能要件を決めることの重要性を伝えている。その後、非機能要件を六つのカテゴリに分けて解説。非機能要件の検討時には「事業コンセプトに一致させる」「トレードオフを見極める」「定期的に見直す」の三つが欠かせないといったコラムも掲載する。 この読本を作成したのはSECの「非機能要求グレードWG（ワーキンググループ）」である。同WGは昨年4月、システム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
