『Patterns for Effective Use Cases』から、パターンの要約をメモっておく。
■■■ Team のパターン
★ SmallWritingTeam
各成果物をレビューして仕上げる担当者数は２，３人に抑える事。大人数を動員するときは TwoTierReview パターンを使う事。
★ ParticipatingAudience
顧客や内部のステークホルダに、なるべく積極的にユースケース作成プロセスに参加してもらう事。
★ BalancedTeam
異なる専門分野の人をチーム構成に含めて、ステークホルダの利益を開発プロセスの中で擁護していく事。特に設計者とエンドユーザは確実にチームに含める事。
■■■ Process のパターン
★ BreadthBeforeDepth
まず最初に概観レベルのユースケースを作っておいてから、関連するユースケース群を横断しつつ、詳細レベルの記述を段々と追加するような作業の流れに従う事で、労力の無駄な消耗を防ぐ事。
★ SpiralDevelopment
イテレーションを繰り返す中で、ユースケースの精度と正確性がだんだんと増加していくように、反復的かつ「広さ優先」の作法でユースケースを開発していく事。
★ MultipleForms
プロジェクトに関連するリスクと、関係者の好みを汲み取りつつ、ユースケースの書式を選択する事。
★ TwoTierReview
２つのタイプのレビューを催す事：第一にチームの内輪だけで数回行う小さなレビュー。第二に完全なグループで、一回だけ行うレビュー。
★ QuittingTime
ユースケースが出来上がってステークホルダや開発者など聴衆のニーズを満たした時点で、そのユースケース開発はとっとと止めてしまう事。
★ WritersLicense
書き方の小さな違いに無駄にこだわらない事。一たび QuittingTime の条件を通ったユースケースについては、ライタが小さな様式の違いに関する"ライセンス"を得る事ができるようにする事。
■■■ Use Case Set のパターン
★ SharedClearVision
システムの目的を明確化し、組織のミッションを支援するような声明を準備して、プロジェクトに関係する全員が読めるように公開する事。
★ VisibleBoundary
システムと対話する人間と設備の両方を列挙して、システムとその環境との境界を可視化する事。
★ ClearCastOfCharacters
システムと対話するものであるアクタと、システムに対して果たすべきものであるロールを識別し、それぞれについて明確に説明する事。
★ UserValuedTransactions
アクターのビジネス上の目的を満たすためにシステムが提供する、価値のあるサービスを識別する事。
★ EverUnfoldingStory
展開して詳細を見たり、畳み込んで全体的な文脈を重点的に示したりできるような、階層的なストーリとしてユースケース・セットを組み立てる事。
■■■ Use Case のパターン
★ CompleteSingleGoal
よく定義された完全な一個のゴールを示すように、各ユースケースを書く事。（そのゴールは、EveryUnfoldingStory における任意のレベルでもある。）
★ VerbPhraseName
プライマリ・アクターのゴールを表現するような、能動態の動詞句でユースケースを名づける事。
★ ScenarioPlusFragments
失敗を考慮しない単純なシナリオでサクセス・ストーリーラインを書き、その下に代替事象の発生を示すストーリの断片を記述する事。
★ ExhaustiveAlternatives
処理すべき全ての代替および失敗を、ユースケースにおいて漏れなく捕捉しておく事。
★ Adornments
ユースケース・テンプレートのシナリオ・テキストの外に、ユースケースの関連付けに役立つ補足情報を保持するための追加フィールドを作成する事
★ PreciseAndReadable
ステークホルダが読んで評価する気になるレベルの読み易さで、尚且つ、自分達が何を構築しているのか開発者が理解できるレベルの正確さで、ユースケースを書く事。
■■■ Scenarios and Steps のパターン
★ DetectableConditions
検出可能な条件のみを含める事。システムに与える正味の効果が同じである条件はマージする事。
★ LeveledSteps
シナリオの長さは、３ステップから９ステップにする事。
★ ActorIntentAccomplished
各ステップを記述する際、どのアクターがアクションを実行し、それにより何をアクターが得る事になるのか明確に示す事。
★ ForwardProgress
アクターを前に進めないステップは排除するかマージする事。読者がシナリオの進行に付いて来れなくなる様なややこしい経路は簡略化する事。
★ TechnologyNeutral
各ステップを書く際、IT技術に中立となるよう留意する事。
■■■ Use Case 間の関連のパターン
★ CommonSubBehavior
「包含」される下位レベルのユースケースを用いて、共有されるアクションのコースを表現する事。
★ InterruptsAsExtensions
シナリオの多くのステップに代替コースが割り込んで来る場合、拡張ユースケースを作る事。
★ PromotedAlternative
ユースケースに過度に影響する複雑な代替は、分離したユースケースへの移動を考慮する事。
★ CapturedAbstraction
汎化した抽象ユースケースの作成を考慮する事。その抽象ユースケースを特化する具象的・個別的なシナリオは、それ自身の具象ユースケースに置く事。
■■■ 既存 Use Cases の編集のパターン
★ RedistributeTheWealth
長くて扱いにくい経路や、複雑すぎる拡張は、それ自身のユースケースを別途作って移動する事。
★ MergeDroplets
関連する小さなユースケースやユースケースの断片は、同じゴールに関連するものをマージして、別途ユースケースを作成する事。
★ CleanHouse
システムに価値をもたらさなかったり、既にアクティブ･リストにないユースケースは取り除いてしまう事。
2010年7月11日日曜日
2010年6月28日月曜日
主語 ← ユースケースの最初の一歩
最近入った開発部隊で、ユースケースらしきものが作られていたが、どうにも酷すぎる。
最初のページにスティックマンを書いたら、残りのページのシナリオに何を書こうがOKなんて思ってるんだろうか・・・
ユースケースを知らないライタが命ぜられるまま書いて、それと同じくらいユースケースを知らないレビュアーが検定して、「どう役に立つか知らないけど、とりあえず何となく意味が通じない事もない気がする。スティックマンと楕円が、何となくユースケースっぽさをかもし出しているし。」みたいなレベルなのが見え見え。
これではいけないので、チェックリストを作って、ライタがレビュー前にそれを使って、ユースケースとしての最低レベルに自力で持って行けるようにしたい。レビュアーも自分が本来意識を向けるべきところにのみ集中できるはず。
という訳で、いつものとおり「まずは必ず他人の成果を利用する事から始める」ポリシーに従って、手持ちの本とかWebでみた資料をいろいろ思い浮かべる。で、Cockburn のユースケース本 に何かあったのを思い出し、実物を開いて裏表紙に載っている「Pass/Fail Tests for Use Cases Fields」 というリストを確認。
以下のような内容。
◆ Use Case Title
1. Is it an active-verb goal phrase that names the goal of the primary actor?
2. Can the system deliver that goal?
◆ Scope and Level
3. Are the fields filled in?
◆ Scope
4. Does the usecase treat the system mentioned in Scope as a black box?
5. If the system in Scope is the system to be designed, do the designers have to design everything in it and nothing outside it?
◆ Level
6. Does the use case content match the stated goal level?
7. Is the goal really at the stated goal level?
◆ Primary Actor
8. Does he/she/it have behavior?
9. Does he/she/it have a goal against the SuD that is a service promise of the SuD?
◆ Preconditions
10. Are they mandatory, and can they be set in place by the SuD?
11. Is it true that they are never checked in the use case?
◆ Main Success Scenario
15. Does it have 3-9 steps?
16. Does it run from trigger to delivery of the success guarantee?
17. Does it permit the right variations in sequencing?
◆ Each Step in Any Scenario
18. Is it phrased as a goal that succeeds?
19. Does the process move distinctly forward after its successful completion?
20. Is it clear which actor is operating the goal--who is "kicking the ball"?
21. Is the intent of the actor clear?
22. Is the goal level of the step lower than the goal level of the overall use case? Is it, preferably, just a bit below the use case goal level?
23. Are you sure the step does not describe the user interface design of the system?
24. Is it clear what information is being passed in the step?
25. Does it "validate" as opposed to "check" a condition?
◆ Extension Condition
26. Can and must the system both detect and handle it?
27. Is it what the system actually needs?
◆ Overall Use Case Content
29. To the sponsors and users: "Is this what you want?"
30. To the sponsors and users: "Will you be able to tell, upon delivery, whether you got this?"
31. To the developers: "Can you implement this?"
ユースケースを書く上での重要なエッセンスだけ抽出した、非常に濃いチェックリストなんだけど、うーん・・・
これは、すでにある程度の経験を積んだ人か、少なくともこの本をじっくり読了した人になら有用だけど、未経験者にはほとんど意味が通じない予感（日本語に訳したとしても）。もうちょい機械的というか事務的に作業できるのを作る必要があるなあ。
まあ、それは後で何とかするとして、ユースケースに余り自信のない人は、とりあえず各ステップの主語をちゃんと書く事から始めるのがお勧め。ただし主語といっても、定義が若干あいまいな日本語文法のそれというより、英語のような動詞に対するものとしての主語。もう少し言うと、状態動詞ではなくて動作動詞で、さらに能動態の主語。
動作の主体、ボールをキックするその人、動きが生じて状況が前進する瞬間の主役を主語として、ステップを記述する。そうすると、ユースケースにまつわる他の事も分かってくる。つうかそれが駄目だと、ユースケース全体の他のすべての項目も多分駄目。
つうわけで、主語だけはしっかりと書くべし。まずはそこからだ。
・・・なんて、上から目線で言ってみる。
最初のページにスティックマンを書いたら、残りのページのシナリオに何を書こうがOKなんて思ってるんだろうか・・・
ユースケースを知らないライタが命ぜられるまま書いて、それと同じくらいユースケースを知らないレビュアーが検定して、「どう役に立つか知らないけど、とりあえず何となく意味が通じない事もない気がする。スティックマンと楕円が、何となくユースケースっぽさをかもし出しているし。」みたいなレベルなのが見え見え。
これではいけないので、チェックリストを作って、ライタがレビュー前にそれを使って、ユースケースとしての最低レベルに自力で持って行けるようにしたい。レビュアーも自分が本来意識を向けるべきところにのみ集中できるはず。
という訳で、いつものとおり「まずは必ず他人の成果を利用する事から始める」ポリシーに従って、手持ちの本とかWebでみた資料をいろいろ思い浮かべる。で、Cockburn のユースケース本 に何かあったのを思い出し、実物を開いて裏表紙に載っている「Pass/Fail Tests for Use Cases Fields」 というリストを確認。
以下のような内容。
◆ Use Case Title
1. Is it an active-verb goal phrase that names the goal of the primary actor?
2. Can the system deliver that goal?
◆ Scope and Level
3. Are the fields filled in?
◆ Scope
4. Does the usecase treat the system mentioned in Scope as a black box?
5. If the system in Scope is the system to be designed, do the designers have to design everything in it and nothing outside it?
◆ Level
6. Does the use case content match the stated goal level?
7. Is the goal really at the stated goal level?
◆ Primary Actor
8. Does he/she/it have behavior?
9. Does he/she/it have a goal against the SuD that is a service promise of the SuD?
◆ Preconditions
10. Are they mandatory, and can they be set in place by the SuD?
11. Is it true that they are never checked in the use case?
◆ Main Success Scenario
15. Does it have 3-9 steps?
16. Does it run from trigger to delivery of the success guarantee?
17. Does it permit the right variations in sequencing?
◆ Each Step in Any Scenario
18. Is it phrased as a goal that succeeds?
19. Does the process move distinctly forward after its successful completion?
20. Is it clear which actor is operating the goal--who is "kicking the ball"?
21. Is the intent of the actor clear?
22. Is the goal level of the step lower than the goal level of the overall use case? Is it, preferably, just a bit below the use case goal level?
23. Are you sure the step does not describe the user interface design of the system?
24. Is it clear what information is being passed in the step?
25. Does it "validate" as opposed to "check" a condition?
◆ Extension Condition
26. Can and must the system both detect and handle it?
27. Is it what the system actually needs?
◆ Overall Use Case Content
29. To the sponsors and users: "Is this what you want?"
30. To the sponsors and users: "Will you be able to tell, upon delivery, whether you got this?"
31. To the developers: "Can you implement this?"
ユースケースを書く上での重要なエッセンスだけ抽出した、非常に濃いチェックリストなんだけど、うーん・・・
これは、すでにある程度の経験を積んだ人か、少なくともこの本をじっくり読了した人になら有用だけど、未経験者にはほとんど意味が通じない予感（日本語に訳したとしても）。もうちょい機械的というか事務的に作業できるのを作る必要があるなあ。
まあ、それは後で何とかするとして、ユースケースに余り自信のない人は、とりあえず各ステップの主語をちゃんと書く事から始めるのがお勧め。ただし主語といっても、定義が若干あいまいな日本語文法のそれというより、英語のような動詞に対するものとしての主語。もう少し言うと、状態動詞ではなくて動作動詞で、さらに能動態の主語。
動作の主体、ボールをキックするその人、動きが生じて状況が前進する瞬間の主役を主語として、ステップを記述する。そうすると、ユースケースにまつわる他の事も分かってくる。つうかそれが駄目だと、ユースケース全体の他のすべての項目も多分駄目。
つうわけで、主語だけはしっかりと書くべし。まずはそこからだ。
・・・なんて、上から目線で言ってみる。
2010年6月3日木曜日
usecase の本
久しぶりに仕事でユースケース書く事になりそうなので、以下に手持ちのユースケースの資料を整理。
Writing Effective Use Cases
言わずと知れたユースケースライターのバイブル。読めば読むほどユースケースを書く作業が面白くなってくる。書いているうちに沸いてくる疑問や迷いについても大抵答えが提示されている。
実用的には、とりあえずこの一冊があれば十分じゃないだろうか。チームで作業するときも、この本から要点を抜き出してガイドラインにして配布するようにすればいい効果が期待できる。
Patterns for Effective Use Cases
内容は『Writing Effective Usecases』に載っている事がほとんどだけど、パターンカタログの体裁をとっているので、そういうスタイルが好きな人には良い本。
Applying Use Case Driven Object Modeling with UML
タイトルからは分かりにくいけど、ほぼ ICONIX というアジャイルプロセスの解説書。
ICONIX では ユースケース が重要視されていて、他の成果物やタスクとも絡んだプロセス全体の中での活かし方とか位置づけとか、結構参考になる。他に、Domain Model や Robustness 分析についても上手に解説されていて、なかなかの良書。
ユースケースによるアスペクト指向ソフトウェア開発
ユースケースの開発者のヤコブソンが、アスペクト指向をとりこんで発展させたもの。
アスペクトって、ログとかトランザクションとか実装レベルかつ非機能要件の領域で語られる事が多いけど、もっと高い抽象度でドメインよりの話題としても語られても良いのではなかろうかと思ってるときに見つけた本。
と言っても実は、正直まだよく理解できていなかったりする。上の3冊はサクサク読めて現場でもすぐに役立てられる本だけど、この本はある程度時間をかけてじっくり読む必要がありそう。
＝＝＝＝
他にも何冊か UML の参考書があって、中でユースケースにも触れられているけど割愛。なんかユースケース図のスティックマンのおかげで、ユースケース本来の重要性が見失われ続けている気がしないでもない。
Writing Effective Use Cases
言わずと知れたユースケースライターのバイブル。読めば読むほどユースケースを書く作業が面白くなってくる。書いているうちに沸いてくる疑問や迷いについても大抵答えが提示されている。
実用的には、とりあえずこの一冊があれば十分じゃないだろうか。チームで作業するときも、この本から要点を抜き出してガイドラインにして配布するようにすればいい効果が期待できる。
Patterns for Effective Use Cases
内容は『Writing Effective Usecases』に載っている事がほとんどだけど、パターンカタログの体裁をとっているので、そういうスタイルが好きな人には良い本。
Applying Use Case Driven Object Modeling with UML
タイトルからは分かりにくいけど、ほぼ ICONIX というアジャイルプロセスの解説書。
ICONIX では ユースケース が重要視されていて、他の成果物やタスクとも絡んだプロセス全体の中での活かし方とか位置づけとか、結構参考になる。他に、Domain Model や Robustness 分析についても上手に解説されていて、なかなかの良書。
ユースケースによるアスペクト指向ソフトウェア開発
ユースケースの開発者のヤコブソンが、アスペクト指向をとりこんで発展させたもの。
アスペクトって、ログとかトランザクションとか実装レベルかつ非機能要件の領域で語られる事が多いけど、もっと高い抽象度でドメインよりの話題としても語られても良いのではなかろうかと思ってるときに見つけた本。
と言っても実は、正直まだよく理解できていなかったりする。上の3冊はサクサク読めて現場でもすぐに役立てられる本だけど、この本はある程度時間をかけてじっくり読む必要がありそう。
＝＝＝＝
他にも何冊か UML の参考書があって、中でユースケースにも触れられているけど割愛。なんかユースケース図のスティックマンのおかげで、ユースケース本来の重要性が見失われ続けている気がしないでもない。