設計漏れを防ぐための
ソフトウェア開発における設計漏れ防止のノウハウと仕様書の書き方
～業務アプリケーションにおける設計漏れ防止のプロセスとノウハウ～
ソフトウェアの設計漏れを防ぐためのプロセスとノウハウを解説する特別セミナー！！
- 講師
ウルシステムズ株式会社 コンサルティング第1事業部 シニアコンサルタント 植田 昌司先生
- 日時
- 会場
- 受講料
- 1名：47,250円 同時複数人数お申込みの場合1名：42,000円
- テキスト
受講概要
受講に当たっての必要な予備知識
以下のいずれかの経験をお持ちの方を前提としております （１）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.業務要件定義（To-Be）
(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.システム要件定義（To-Be）
(1)システムユースケース一覧（To-Be）
(2)概念モデル図（To-Be）
(3)システムユースケース記述（To-Be）
(4)ビジネスルール（To-Be）
(5)状態遷移図（To-Be）
(6)全体システム構成図（To-Be）
(7)課題解決表
c.演習
システムユースケース記述の書き方