コース概要

ソフトウェア開発プロセスとモデリングの概要

  • 方法論と、Business アナリストの作業に対するその影響
  • ウォーターフォールのステップ 分析、設計、実装、テスト、メンテナンス
  • Agile 経営分析の考え方
  • Business アナリストとは誰ですか?
  • BA の役割に関する視点
  • 動的 (行動) モデル
  • 静的 (構造) モデル
  • 構造化分析

オブジェクト指向に関する BA の視点

  • オブジェクト指向 Programming とそのモデリングへの影響
  • UML スタンダード
  • 認知心理学とOO?
  • オブジェクト
  • 属性と操作
  • 操作と方法
  • カプセル化
  • クラス
  • 人間関係
  • 一般化
  • 協会
  • 集計
  • 構成
  • ポリモーフィズム
  • Use Case とシナリオ
  • Business とシステム Use Case

Business オブジェクト指向モデリング (BOOM) の概要

  • BOOM と SDLC
  • ブームのステップ
  • ステップの順序付け
  • 属性と操作のどちらを最初に定義しますか?

エンドツーエンド Business プロセスの分析

  • 開始、分析、テスト段階でのインタビュー
  • ステップ 1: 開始
  • Business 要件文書テンプレート
  • ステップ 1a: モデル Business Use Case
  • ステップ 1a i: Business Use Case を特定する (Business ユースケース図)
  • 理論を実践する
  • Rational Rose ユーザーへの注意事項
  • ケーススタディ D1: Business ユースケース図
  • ステップ 1a ii: スコープ Business Use Case (アクティビティ図)
  • ケーススタディ D2: Business パーティションを使用したユースケース アクティビティ図

システム Use Case による IT プロジェクトの範囲設定

  • ステップ 1b: システム Use Case のモデル化
  • ケーススタディ E1: 役割マップ
  • ステップ 1b ii: システム ユースケース パッケージを特定する (システム ユースケース図)
  • ケーススタディ E2: システムのユースケース パッケージ
  • ステップ 1b iii: システム Use Case を特定する (システム ユースケース図)
  • ケーススタディ E3: システムのユースケース図
  • ステップ 1c: 静的モデルの開始 (主要な Business クラスのクラス図)
  • ステップ 1d: 分析のベースラインを設定する (BRD/開始)

ユーザーエクスペリエンスのストーリーボード化

  • ステップ 2: 分析
  • ユースケース説明テンプレート
  • 基本的なフローの文書化
  • ユースケース作成ガイドライン
  • 基本的な流れ例:CPP制度検討事例報告
  • 代替フローの文書化
  • 例外フローの文書化
  • システム使用例のインタビューを実施するためのガイドライン
  • システム Use Case のアクティビティ図
  • 関連アーティファクト
  • デシジョンテーブル
  • ケーススタディ F1: デシジョンテーブル
  • ディシジョン ツリー
  • ケーススタディ F2: デシジョン ツリー
  • 条件/応答テーブル
  • Business ルール
  • 高度なユースケース機能
  • ケーススタディ F3: 高度なユースケース機能

主要な Business オブジェクトのライフサイクル要件

  • ステートマシン図とは何ですか?
  • ステップ 2a ii: 1. 重大なオブジェクトの状態を特定する
  • ケーススタディ G1: 州
  • ステップ 2a ii: 2. 状態遷移を特定する
  • ケーススタディ G2: 移行
  • ステップ 2a ii: 3. 状態 Activiti を特定する
  • ケーススタディ G3: 状態 Activities
  • ステップ 2a ii: 4. 複合状態を特定する
  • ケーススタディ G4: 複合状態
  • ステップ 2a ii: 5. 同時状態を特定する

クラス図を使用した全体的なルールの収集

  • ステップ 2b: 静的解析
  • ステップ 2b i: エンティティ クラスを特定する
  • ケーススタディ H1: エンティティ クラス
  • ステップ 2b ii: モデルの一般化
  • ケーススタディ H2: 一般化
  • ステップ 2b iii: 一時的な役割のモデル化
  • ケーススタディ H3: 一時的な役割
  • ステップ 2b iv: 全体と部分の関係をモデル化する
  • 複合構造図
  • ケーススタディ H4: 全体と部分の関係
  • ステップ 2b v: 関連を分析する
  • ケーススタディ H5: 協会
  • ステップ 2b vi: 多重度の分析
  • ケーススタディ H6: 多重度

要件の一貫性と再利用の最適化 Documentation

  • ステップ 2b vii: システム Use Case を静的モデルにリンクする
  • ケーススタディ I1: システム Use Case を静的モデルにリンクする
  • ケーススタディ I1: 結果
  • ステップ 2b viii: 属性の追加
  • メタ属性
  • ケーススタディ I2: 属性の追加
  • ステップ 2b ix: ルックアップ テーブルを追加する
  • ケーススタディ I5: ルックアップ テーブルの分析
  • ステップ 2b x: 操作の追加
  • ケーススタディ I7: 分散オペレーション
  • ステップ 2b xi: クラス構造の修正
  • ケーススタディ I8: 構造の見直し

テストケースの設計とプロジェクトの完了

  • ステップ 2c: テストの指定
  • 構造化されたウォークスルー
  • テスト用のデシジョンテーブル
  • ケーススタディ J1: デシジョンテーブルからのテストケースの導出
  • 境界値分析
  • ケーススタディ J2: 境界値分析を使用したテスト データの選択
  • システムテスト
  • システムテストを超えて
  • ステップ 2d: 実装計画の指定
  • ステップ 2e: 開発のベースラインを設定する

要件に対して開発者が行うこと

  • オブジェクト指向 Design Patterns
  • 可視性
  • コントロールクラス
  • 境界クラス
  • シーケンス図
  • Communication 図表
  • その他の図
  • 階層化されたアーキテクチャ
  • インターフェース
  • ミックスイン
  • OO 言語を使用した OO の実装
  • プロシージャルを使用した OOA の実装 Languages
  • RDBMS を使用した OOA からの Database の実装

要求

なし

 21 時間

参加者の人数



Price per participant

お客様の声 (5)

関連コース

Design Patterns

14 時間

Efficient Requirement Management using Agile Methods and Agile UML Modeling

21 時間

関連カテゴリー