ログイン Up dated!
ユーザー名:

パスワード:


パスワード紛失

新規登録

SAP勉強会開催中!

運 営

メインメニュー

運営者及び問合先

当サイトに対する問い合わせは erp.expert.jp@gmail.comまでお願いします。または
SUNTEC WEST お問合せまで。
なおこのサイトからのメールが迷惑メールに振り分けられてしまう場合があります。


フォーラムの説明
フォーラムは階層構造になっており「カテゴリ」の下に「フォーラム」があります。その下にQ&Aのやりとりの題名があり、それを「トピック」と呼びます。例にあげると「SAP ERP」というカテゴリがあって「Financials」というフォーラムがあります。その下でメンバーが自由に「原価センタグループの移送方法ありますか」とかいうQ&Aの「トピック」を立ててやりとりします。 このフォーラム機能は通知機能があります。興味のある「カテゴリ」「フォーラム」「トピック」と各レベルごとに誰かが投稿したら「メール」で知らせること機能でフォーラム内各ページの下にある「イベントの選択」で自由に通知方法を選択してください。なおその前に「ホーム」→「アカウント編集」でイベント更新通知メッセージの受取方法は「メール」、イベント通知のタイミングは「・・・通知する」となっていることを確認してください。「フォーラム」とその親となる「カテゴリ」に また「トピック」とその親となる「フォーラム」に通知チェックを入れたりするとどちらかがキャンセルされるか二度通知いくようなことが発生しますので親側にチェックいれたらその子には通知チェックはずしておいてください。複雑になってしまったら「ホーム」→「イベント通知機能」で整理するといいでしょう。

投稿数ランキング
1 chira3903 51
2 ttabuchi 43
3 emy 25
4 jun 20
5 chong 20
6 hiro888 15
7 mkouso 11
8 sarjan 11
9 saku_saperp 11
10 ishikawa 10

見積精度の上げ方

  • このトピックは管理者もしくはモデレータによりロックされています
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 .2 .3 .4 | 投稿日時 2008-2-4 1:02
ゲスト    投稿数: 0
現在、SAPプロジェクトでFIT&GAPを終え、GAP部分の追加見積をはじきだしていますが、ブレを少なくするために皆様どのような工夫、観点で行っていますでしょうか?
投票数:219 平均点:4.34
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2008-2-10 16:35
hiro888  新米   投稿数: 15
私の方法ですが、(スクラッチのときですけど)
GAP部分の要件をもう少し具体的にイメージしてみて、どのような機能が必要なのか、例えばI/Fならばオンラインにつなぐ必要性は? 夜間バッチでOK?、画面はDynpro? パラメーターズ? 更新ビューでOK?、プログラムなら複雑度、帳票?、何か計算やロジックが入ってる?などその機能と難易度を洗い出してみます。そこで難易度によって開発技術者のランクに応じて見積工数当てはめていきます。当然期待どおりの技術者が入ってくるということはないので以下のように加重します。
ランクA(経験4年以上) 8人月  係数1.5
ランクB(経験2年以上) 10人月 係数1.0
ランクC(経験1年程度) 10人月 係数0.8
それぞれ係数を乗じた和が総合工数とするやり方をしてます。
投票数:223 平均点:4.30
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2008-2-11 13:05
ゲスト    投稿数: 0
ありかどうございます。係数重み付けは客先に説明する際、納得していただけるものと思います。
投票数:220 平均点:5.27
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2008-2-11 20:11
emy  半人前   投稿数: 25
ステップ数、機能数(FP)などによる見積もり手法がありますけど、私はどちらかというと人によってブレが多いといわれるけどKKD法(経験、勘、度胸)派です。勘は経験からピンとくるものであるし、自信がある経験だから度胸につながります。さまざまな要因を頭に入れて過去事例から相対的、総合的にはじきだす工数は以外にいいところついているものです。そこでプロジェクトマネージメント手法である「リスクマネージメント」を取り入れ、この見積もりにどのようなリスクが潜んでいるかを洗い出していきます。たとえば「ユーザーの参画度」これだって現状、客先の窓口が情報システム部門だけであれば「今後経理部門ユーザーがでてきてくつがえすようなことだって考えられる」これもひとつのリスク。基本設計書承認の遅れ、会議にいつも参加メンバーが異なりいつも同じことの説明し要件FIXの進捗が悪いとか、これもリスク。プロジェクトコントロールのよしわるしで開発工数のブレは広がります。いくら優れたPMであっても最悪のシナリオで、基本設計がどのくらい考慮深く書いているのか、もしジュニアの開発者だったらどの程度手戻りがあるか?なども含め見積時に考慮します。しかし客先にはこんな要因全部正直に説明するわけにはいきませんから、はじきだした工数を逆算でステップ数に落としたり選択条件パターン、チェックロジックの複雑さによるテスト工数として説明しております(まんざらうそじゃない)。hiro888さんの開発者レベルによる係数もいい説明の材料ですしいい見積もり手法です(希望どおりの開発者がアサインされればブレも少ないんでしょうけど・・)
投票数:228 平均点:5.04
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2008-2-12 2:31
ゲスト    投稿数: 0
emyさん、ありがとうございます。「ユーザーの参画度」確かにブレる要素ですよね。自動車の運転と同じようにタクシーの運転手は飛ばすときはハデにとばすけど危なそうと感じればグッと徐行しますよね。経験が総合的に判断でき見通しも確かなのでしょう。リスク分析するというポイントも大変参考になりました。
投票数:223 平均点:4.22

  条件検索へ


 

Powered by XOOPS Cube 2.1.8© 2010 ERP EXPERT Project  |  COPYLIGHT (C) 2007 Suntec-BS rights reserved.