課題解決、品質向上、技術向上のセミナーならTH企画セミナーセンター

ソフトウェアの設計漏れ防止のための

業務アプリケーションの構築における“設計漏れ”を防ぐ要件定義のプロセスとテクニック

ソフトウェアの設計漏れ防止のプロセスとノウハウを解説する特別セミナー!!

講師

ウルシステムズ株式会社 コンサルティング第1事業部 シニア・コンサルタント 植田 昌司先生

日時
会場

連合会館 (東京・お茶の水)

会場案内

Googlemapでの表示はこちら

受講料
(消費税等込み)1名:47,250円 同時複数人数申込みの場合 1名:42,000円
テキスト

受講概要

予備知識

  以下のいずれかの経験をお持ちの方を前提としております。
 1)2~3年以上の業務アプリケーションの構築経験
 2)業務アプリケーションの上流工程実施経験
 3)業務アプリケーションの構築時に「設計漏れ」を味わった経験

習得知識

 1)業務アプリケーションの要件定義のプロセスへの理解
 2)業務フロー、システムユースケース記述の記述方法
 3)要件定義で注意すべきポイント

講師の言葉

 業務アプリケーションの構築で、リリース直前に「設計漏れ」が発覚し、多大な苦労をすることがあります。
 では、なぜ「設計漏れ」が発生するのでしょうか?
 私は「設計漏れ」の多くは、要件定義(いわゆる上流工程)時に発生すると考えています。 そこで漏れなく
要件定義するため、つまり「設計漏れ」を防ぐための“一つの解決策”として、体系だった要件定義手法である
「プロセス」について皆様と意見交換させていただき、皆様のお役に立つことが出来れば幸いと思っております。

プログラム

Ⅰ.「設計漏れ」の定義
 1.コンピュータシステムの役割
  a.業務のツール
  b.ミスの防止装置
 2.「設計漏れ」とは
  a.業務を停止させてしまう「漏れ」
  b.処理の正確性が失われてしまう「漏れ」
  c.処理の迅速さ・耐久性が失われてしまう「漏れ」
Ⅱ.「設計漏れ」を防ぐ要件抽出プロセス
 1.業務要件定義
  a.現行業務の分析
   1)ビジネスユースケース図(As-Is)
   2)業務フロー(As-Is)
   3)ビジネスルール(As-Is)
   4)帳票一覧(As-Is)
   5)業務コスト表(As-Is)
   6)課題表

  b.業務要件定義
   1)ビジネスユースケース図(To-Be)
   2)業務フロー(To-Be)
   3)ビジネスルール(To-Be)
   4)帳票一覧(To-Be)
   5)業務コスト表(To-Be)
   6)課題解決表

  c.演習
   ・業務フローの書き方
 2.システム要件定義
  a.現行システム分析
   1)全体システム構成図(As-Is)
   2)機能一覧(As-Is)
   3)論理ER図(As-Is)
   4)課題表

  b.システム要件定義
   1)システムユースケース一覧(To-Be)
   2)概念モデル図(To-Be)
   3)システムユースケース記述(To-Be)
   4)ビジネスルール(To-Be)
   5)状態遷移図(To-Be)
   6)全体システム構成図(To-Be)
   7)課題解決表

  c.演習
   ・システムユースケース記述の書き方

講師紹介

 <略歴>
 1996~2005:大手SIerにてOpen系システム開発の要件定義から
       導入・運用サポートまでの範囲で、主にPM・PLとして
       携わる。
 2005~  :ウルシステムズ(現職)にて、発注者側に立って、
       要件定義・PMの支援に携わっている。