指針：EBPユースケース ElementaryBusinessProcess：基本ビジネスプロセスビジネスイベントに反応して、1度に１つの場所で1人によって実行されるタスク。 観察可能なビジネスの価値をふかし、データの一貫性を維持する。 （=ユーザー目標レベル）※主要アクタ…

-

技術的に制約があったりする場合に記録する場所

非機能的要求，品質属性，制約がユースケースに明確に関係している場合には、一緒に記録。 ふつうは、補助仕様書にまとめた方がなにかと便利

拡張シナリオは、ハッピーシナリオと対峙してるので、3.に対しては3a，3bとふる ほとんどのステップで起こりうる拡張の条件の場合は、*a，*bのようなラベルをつける

前置き部分 正常シナリオの前に読むべき要素だけを書く 利害者関係と関心のリスト システムが何をしなければならないかを提案し、「境界」を示す 事前条件と事後条件(成功保証） 「必ず真でなければならないこと」を宣言する 多くの場合、すでに終了している…

Cockburnはブリーフ、ジーンズ、スーツって言ってた気がする [brief]簡素 [casual]略装 [fullyDressed]正装

ようやくユースケースにたどりついた。Cockburn様はやっぱりスゴイ システム要件を捕捉する方法 「単純でわかりやすいこと」⇒ 目標を定義したり評価したりしやすいし、リスクも小さくなる ユースケース＝要件 システムの使い方のストーリを記述することによ…

【FURPS＋】モデルの種類⇒要件が必要な範囲をカバーしているかどうかのチェックリスト F Functional(機能的)−機能,能力,セキュリティ U Usability(使いやすさ)−使い勝手,HELP,文書資料 R Reliability(信頼性)−障害の頻度,回復可能性,予見性 P Peformance(パ…

要件とは システムが、プロジェクトが、従わなければならない能力と状態のこと

アーキテクチャを定義してしまう。（推敲フェーズで反復的にやるもの） 詳細に書いたユースケースが1つもない（10〜20%は詳細に書くべき）

成果物はオンラインで記録すること 迅速に行うこと どのプロジェクトでも同じ名前をつけて体系づけること UPの成果物として正式に命名されているもの [Vision]ビジョン文書、[BusinessCase]ビジネス文書 [Use-CaseModel]ユースケースモデル [Supplementary S…

方向付けフェーズとは 製品の範囲、ビジョン、ビジネスの構想をたてること 方向付けフェーズでは 利害関係者が、ビジョンに基本的に合意していることを確認する、 この先の調査に本当に投資する必要があるかどうかを見極める。

XPとUPの違い UPがユースケースと非機能的要件の文書を増幅的に記述することを推奨。⇒XPでは推奨していない UPはPGの前に、設計のより視覚的な図の作成を半日〜1日行うことを推奨。⇒XPでは30分程度

方向付けフェーズ=要件定義、推敲フェーズ=設計、組立フェーズ=実装であると考えてしまう。

成功するソフトウエアに共通する4つの要因 反復型開発であること 新しいコードを少なくとも日に1度は、その時点での構築済みシステムに組み込み、設計の変更に対するフィードバックを（テストを介して）迅速に得ること 本番稼動システムの納品を何度か経験し…

UPではあらゆる成果物がオプション（必須ではない）である。 実用的な価値を確認できる成果物を重視する

ディシプリン =１つの作業分野のこと UPディシプリン の例 ビジネスモデリング 要件 設計 実装 テスト 配置 構成&変更管理 プロジェクト管理 環境 ワークフロー=特定のプロジェクトにおける、アクティビティの特定の順序のこと

inception（方向づけ） elaboration（推敲） construction（組立） transition（移行）

期限を間に合わせることの方が、完了日を遅らせるより望ましい

進行の様子を早期から目で確認できる 複雑さを制御しやすい

さ。がんばって読むぞ。読めるのか？忙しいのに(>_ 読書日記は、おっと思ったとこと、知らない語句などを中心に羅列予定。 実践ＵＭＬ―パターンによる統一プロセスガイド [原書名：Applying UML and patterns : an introduction to object-oriented analysis…