プロジェクトのすすめ vol.3 #TechLunch

プロジェクトのすすめ vol.3
2012/08/01 (水) @ Livesense TechLunch
発表者：島田 喜裕

Transcript

1. プロジェクトのすすめ3 ユースケースについて
2. TDDのFAQ ▪テスト駆動開発 (TDD) を始めたばかりの、次のようなよくある 質問 どれくらい事前設計をするのでしょうか？どうすればいつやめる かわかるのでしょうか？ ↓
3. TDDのFAQ ▪テスト駆動開発 (TDD) を始めたばかりの、次のようなよくある 質問 どれくらい事前設計をするのでしょうか？どうすればいつやめる かわかるのでしょうか？ ↓ 何を構築すべきかわかるまでです。
4. TDDで補えない事 • 良いプログラムは開発できるが、良いシステム を開発できるわけではない • なんらかの開発プロセスは必要 ◦ アジャイルやウォーターフォールなど
5. プログラムの仕様と要件 • システム開発の目的は顧客の要件の実現 ◦ 仕様が要件を満たしていなければ本末転倒 • 要件から「何を構築するか」を設計する
6. 「何を構築するか？」を決める • 顧客の言葉を使ったシステムの使い方 ◦ ユースケース ◦ ユーザストーリー • システムの外部的な振る舞い ◦ 画面モックアップ
7. 方向付けフェーズ ユースケースモデルは、予測されるほとんどのユースケースを リストするが、最初に詳述するのは10%ぐらい。 システムの範囲、目的、リスクをとらえた大まかなビジョンを作 成するために行われる。
8. • 文書資料はさほど多くなくて良い • プロジェクトにとって本当に価値のある成果物だけを作成 し、価値がはっきりしないものは作成しない。 • 完全な仕様を作成することは重要ではない。 ◦ プログラミングやテストから得られた貴重なフィードバッ クをもとに詳細化していく基礎となる、おおまかな文書を 作成。 　多くの場合、成果物やモデルを作成する際に重要なことは文 書や図そのものではなく、考察し、分析し、先を見越した準備を 整えることにあります。 　これは「モデリングの最も重要な価値は、信頼できる仕様をま とめることではなく、理解を深めることである」 とするアジャイル モデリングの考え方そのもの。
10. 戦闘準備に入ると計画は役に立 たぬことを幾度も思い知った。 しかし、計画を立てぬわけにはい かなかった アイゼンハワー
11. 定義 • アクタ：人(役割によって識別される)、コンピュータシステム、 組織。振る舞いを持つ何か。 ◦ 例）レジ係り • シナリオ：アクタと目的のシステムとの間で行われるアクショ ンおよび相互作用の特定シーケンス。システムの使い方の 特定のストーリー。 ユースケース：目標達成のためにシステムを使用するアクタを 記述した、正常なシナリオおよび失敗のシナリオの関連性のあ るまとまり。
12. ユースケースモデル • ユースケースは図ではなくテキスト文書のこと。 • ユースケースモデリングは主に、作図ではなくテ キストを書くという行為を指す。 新米のユースケースモデラはテキストでストーリー を書くという単純だけれども集中力を要する作業よ り、ユースケース図、ユースケース関係、ユース ケースパッケージなど二次的な作業にとらわれる 傾向がある
13. ユースケースを作成する理由 ユースケースはものごとを単純にする優れた方法 であり、問題領域の専門家や要件の提供者が自 分でユースケースを書いたり、書く作業に参加した りできるようになる。 • 単純で分かり易ければ、だれにとっても、特に 顧客にとっても、自分たちの目標を定義したりレ ビューしたりする際に利用しやすい。 • 重要なことを見落とすリスクも小さくなる
14. ユーザの側からみた目標と立場を協調できる。 「こ のシステムを使うのは誰か。彼らの典型的な使い 方のシナリオは何か。目標は何か」を問いかける。 単にシステムフィーチャーの リストを問うのに比べて、よりユーザを重視。 ユースケースの強みは、レベルは詳しさの程度を 高めたり低めたりできるところ。
15. アクタの種類 • 主要アクタ・・・システムを使うことによって達成 されるユーザ目標をもつ。例）レジ係り • 補助アクタ・・・システムに情報を提供する。コン ピュータシステムであることが多いが、人や組織 である場合もある。例）自動化された支払い承 認サービス • 舞台裏アクタ・・・ユースケースの振る舞いに関 心を持つが、主要アクタでも補助アクタでもない アクタ。例）政府税務機関
16. ユースケースの書式 ユースケースは書式や正式さの度合いを変えて書くことができ る • 簡素・・・短い1パラグラフの要約で、通常は主要な正常シナ リオを表す。 • 略装・・・非公式なパラグラフ形式。いくつかのパラグラフに 別れ、様々なシナリオを記述。 • 盛装・・・すべてのステップとバリエーションが詳細に書か れ、事前条件や正常時のような補助的なセクションもある。
17. 盛装のユースケース テンプレートの例
18. 指針 • 簡潔なユースケースを書く • ブラックボックスユースケース・・・システムの内 部動作も、システムのコンポーネントも、設計も 説明しない。「どのように」 を決めずに、システ ムが「何を」行わなければならないかを指定。
19. ユースケース駆動 反復型(イテレーション)開発手法におけるユースケースの扱い • 機能的要件が主としてユースケースに記録される。他の要 件テクニック(機能リストなど)は、使うにしても二次的。 • ユースケースが反復型計画の重要な部分を占める。反復の 作業は、部分的にはユースケースの一部のシナリオまたは ユースケース全体を選ぶことによって定まる。またユース ケースは見積りの重要な材料でもある。 • ユースケース実現化が設計を駆動。 • ユーザにマニュアルの編成にも影響を及ぼす。 • 機能テストまたはシステムテストはユースケースのシナリオ に対応。
20. 最後に はじめから「すべてを正しく」しなければならないと思いつめると 分析麻痺に陥り、行き詰る。 反復しながら進化的に考える。 ユースケースは推敲を経るうちに少しの手間で反復的に進化し ていくイメージ。
21. 次回 プロジェクトのすすめ?