タグ

2010年10月4日のブックマーク (3件)

  • 鈴村さんが指南する業務フロー図の上手な書き方

    まずは,業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが(図1)である。スイムレーンに役割を書き,上から下(または左から右)に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し,矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り,業務とは複雑なものである。厳密に書こうとすると,業務フローも複雑になりがちである。しかし,分かりやすさを重視するなら,一つの業務フローに登場するアクティビティはせいぜい10~15程度にとどめるべきだ。 複雑なフローを表現したければ,一部の業務フローを別に切り出して,サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が,サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」

    鈴村さんが指南する業務フロー図の上手な書き方
  • Part1 業務分析の知識体系、BABOKを理解する

    20年以上にわたりシステム構築の現場で仕事をしてきた筆者の経験では、プロジェクトの失敗を探ると要件定義までの上流工程の問題に行き着くことが多い。定義した要求に過不足がある、要求の内容が誤解を生む表現になっている、整理が不十分なまま要求が個条書きされており整合が取れていない──。こうした事態が、みなさんの現場でも起こっていないだろうか。 利用部門などから要求を引き出して分析し、それを基にソリューションを立案してその妥当性を検証する。さらに、要求の変更を管理していく。ソリューション企画から要件定義までの上流工程を中心に、こうした要求にかかわる一連の作業をいかに行うかが、プロジェクト成功の大きなカギを握る。 しかし多くの現場には、要件定義までの上流工程について標準的な方法が存在せず、ITエンジニアの属人的スキルに頼っているのが実情だろう。スキルの高いITエンジニアが要件定義までの工程を担当するか

    Part1 業務分析の知識体系、BABOKを理解する
  • j1nn.com - このウェブサイトは販売用です! - j1nn リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

    hersey
    hersey 2010/10/04