ログイン 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

Vモデル手法って

  • このトピックは管理者もしくはモデレータによりロックされています
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 .2 | 投稿日時 2007-12-2 2:07
jun  新米   投稿数: 20
よくウォーターフォール型の開発手法としてVモデルという言葉を聞くのですが、どういったものなのでしょうか? またASAPでいうSAP導入方法論とはどう違うのでしょうか?すいませんがご教示ください。
投票数:204 平均点:3.43
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2007-12-4 1:21
emy  半人前   投稿数: 25
Vモデル手法という言葉自体は一般的なものですから
まずは、このページを読んでください

http://ja.wikipedia.org/wiki/V%E3%83%A2%E3%83%87%E3%83%AB

プロジェクトの中では開発者、SE、コンサルタントと大勢役割分担して作業しているため、みながみなそれぞれのやり方で開発、テストしていたら品質面にムラがでてくるどころか、要件違い、バグの山積み大発生となること間違いなし。ここはやはりPJ全体のテストの方法、考え方として定める必要があり、単体テストは詳細設計書に準拠に検証をすすめなさいよ、統合テストまたはシステムテストでは基本設計書ベースにユーザーの目線で求めたいものが正しいか検証していきなさいよ。といったテストの進め方をこのモデルを応用して定めることとなります。
では実際、プロジェクトを進めていくにあたり、当初に書いた基本設計書、業務プロセスフローをもとに統合テストできるかというと、結構要件変更箇所でていて、テストシナリオ書くときにいっしょに業務フロー書き直すなんてよくありませんか? 厳密にこの手法でやっていこうとするとビジネス設計フェーズにえらく時間がかかるでしょうし、エンドユーザーの理解度が追いつかない、現実的にはムリですので「基本的にはVモデルの考え方を基本としてスパイラルに業務プロセス、要求仕様の穴を埋める。詳細化していく」ということがERP導入では主流のような気がします。
SAPの導入方法論ASAP(今はソリューションマネージャ)もこのVモデルを応用した考え方しています。
ERPの導入における要件定義、基本設計ではプロトタイピングでスパイラルに進めていく。のが基本とされていますがこれは要件仕様FIXの仕方でより完成系をイメージできて極力齟齬を防止する方法というだけであってドキュメンテーションはウォータフォール型を崩していません。
またASAPの考え方は
要件定義、基本設計、詳細設計を記述するときはテストする項目、テストシナリオとしても再利用できるつくり方にすればまたテストシナリオ作る必要ないし、基本設計書や要件定義書が過去のものとして放置されずテスト期間中にアップデートするため納品物の品質保持でき、運用面にも利用できるとのこと。一理ありですね。
投票数:189 平均点:5.93
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2008-2-12 0:31
jun  新米   投稿数: 20
emyさんお礼遅くなってすいません。
テストにおける基本的な考え方、理解できました。
統合テストは本来基本設計書を基にした検証。とはいいますが実際は単体テストの延長線、基本設計には明確になっていなかった考慮不足の対応がほとんどです。今後はこれを防ぐに最適な方法考えていきたいと思います。また何か助言のほどよろしくお願いします。ありがとうございました。
投票数:201 平均点:4.68

  条件検索へ


 

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