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

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

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

E60aa4f80303f3f386898546ddb3686a?s=128

Livesense Inc.

April 21, 2014
Tweet

Transcript

  1. プロジェクトのすすめ3 ユースケースについて

  2. TDDのFAQ ▪テスト駆動開発 (TDD) を始めたばかりの、次のようなよくある 質問 どれくらい事前設計をするのでしょうか?どうすればいつやめる かわかるのでしょうか? ↓

  3. TDDのFAQ ▪テスト駆動開発 (TDD) を始めたばかりの、次のようなよくある 質問 どれくらい事前設計をするのでしょうか?どうすればいつやめる かわかるのでしょうか? ↓ 何を構築すべきかわかるまでです。

  4. TDDで補えない事 • 良いプログラムは開発できるが、良いシステム を開発できるわけではない • なんらかの開発プロセスは必要 ◦ アジャイルやウォーターフォールなど

  5. プログラムの仕様と要件 • システム開発の目的は顧客の要件の実現 ◦ 仕様が要件を満たしていなければ本末転倒 • 要件から「何を構築するか」を設計する

  6. 「何を構築するか?」を決める • 顧客の言葉を使ったシステムの使い方 ◦ ユースケース ◦ ユーザストーリー • システムの外部的な振る舞い ◦

    画面モックアップ
  7. 方向付けフェーズ ユースケースモデルは、予測されるほとんどのユースケースを リストするが、最初に詳述するのは10%ぐらい。 システムの範囲、目的、リスクをとらえた大まかなビジョンを作 成するために行われる。

  8. • 文書資料はさほど多くなくて良い • プロジェクトにとって本当に価値のある成果物だけを作成 し、価値がはっきりしないものは作成しない。 • 完全な仕様を作成することは重要ではない。 ◦ プログラミングやテストから得られた貴重なフィードバッ クをもとに詳細化していく基礎となる、おおまかな文書を

    作成。  多くの場合、成果物やモデルを作成する際に重要なことは文 書や図そのものではなく、考察し、分析し、先を見越した準備を 整えることにあります。  これは「モデリングの最も重要な価値は、信頼できる仕様をま とめることではなく、理解を深めることである」 とするアジャイル モデリングの考え方そのもの。
  9. None
  10. 戦闘準備に入ると計画は役に立 たぬことを幾度も思い知った。 しかし、計画を立てぬわけにはい かなかった アイゼンハワー

  11. 定義 • アクタ:人(役割によって識別される)、コンピュータシステム、 組織。振る舞いを持つ何か。 ◦ 例)レジ係り • シナリオ:アクタと目的のシステムとの間で行われるアクショ ンおよび相互作用の特定シーケンス。システムの使い方の 特定のストーリー。

    ユースケース:目標達成のためにシステムを使用するアクタを 記述した、正常なシナリオおよび失敗のシナリオの関連性のあ るまとまり。
  12. ユースケースモデル • ユースケースは図ではなくテキスト文書のこと。 • ユースケースモデリングは主に、作図ではなくテ キストを書くという行為を指す。 新米のユースケースモデラはテキストでストーリー を書くという単純だけれども集中力を要する作業よ り、ユースケース図、ユースケース関係、ユース ケースパッケージなど二次的な作業にとらわれる

    傾向がある
  13. ユースケースを作成する理由 ユースケースはものごとを単純にする優れた方法 であり、問題領域の専門家や要件の提供者が自 分でユースケースを書いたり、書く作業に参加した りできるようになる。 • 単純で分かり易ければ、だれにとっても、特に 顧客にとっても、自分たちの目標を定義したりレ ビューしたりする際に利用しやすい。 •

    重要なことを見落とすリスクも小さくなる
  14. ユーザの側からみた目標と立場を協調できる。 「こ のシステムを使うのは誰か。彼らの典型的な使い 方のシナリオは何か。目標は何か」を問いかける。 単にシステムフィーチャーの リストを問うのに比べて、よりユーザを重視。 ユースケースの強みは、レベルは詳しさの程度を 高めたり低めたりできるところ。

  15. アクタの種類 • 主要アクタ・・・システムを使うことによって達成 されるユーザ目標をもつ。例)レジ係り • 補助アクタ・・・システムに情報を提供する。コン ピュータシステムであることが多いが、人や組織 である場合もある。例)自動化された支払い承 認サービス •

    舞台裏アクタ・・・ユースケースの振る舞いに関 心を持つが、主要アクタでも補助アクタでもない アクタ。例)政府税務機関
  16. ユースケースの書式 ユースケースは書式や正式さの度合いを変えて書くことができ る • 簡素・・・短い1パラグラフの要約で、通常は主要な正常シナ リオを表す。 • 略装・・・非公式なパラグラフ形式。いくつかのパラグラフに 別れ、様々なシナリオを記述。 •

    盛装・・・すべてのステップとバリエーションが詳細に書か れ、事前条件や正常時のような補助的なセクションもある。
  17. 盛装のユースケース テンプレートの例

  18. 指針 • 簡潔なユースケースを書く • ブラックボックスユースケース・・・システムの内 部動作も、システムのコンポーネントも、設計も 説明しない。「どのように」 を決めずに、システ ムが「何を」行わなければならないかを指定。

  19. ユースケース駆動 反復型(イテレーション)開発手法におけるユースケースの扱い • 機能的要件が主としてユースケースに記録される。他の要 件テクニック(機能リストなど)は、使うにしても二次的。 • ユースケースが反復型計画の重要な部分を占める。反復の 作業は、部分的にはユースケースの一部のシナリオまたは ユースケース全体を選ぶことによって定まる。またユース ケースは見積りの重要な材料でもある。

    • ユースケース実現化が設計を駆動。 • ユーザにマニュアルの編成にも影響を及ぼす。 • 機能テストまたはシステムテストはユースケースのシナリオ に対応。
  20. 最後に はじめから「すべてを正しく」しなければならないと思いつめると 分析麻痺に陥り、行き詰る。 反復しながら進化的に考える。 ユースケースは推敲を経るうちに少しの手間で反復的に進化し ていくイメージ。

  21. 次回 プロジェクトのすすめ?