ユースケースモデルの作成 rew-.ppt

ユースケースモデルの作成 GOAL シナリオが与えられたとき、人に伝わるユースケースモデルが書けるようになる。 Objective ユースケースモデルを使う利点を説明できるようになる。 シナリオが与えられたとき、適切にユースケースを抽出できるようになる。 シナリオが与えられたとき、適切にアクタを抽出できるようになる。 「サービスを明らかにする」について議論することができるようになる。 人を幸せにするシステム ソフトウエアには、「人を幸せにするサービスを提供する」という使命がある。 ワープロであれば、文書を書いて、印刷するというサービスを提供します。 表計算システムでは、ある行の数字を全部足して、合計を出したり、並び替えを行ったりするサービスを提供します。 人を幸せにするサービス 「そんなの簡単ジャン！」 意外に難しい。 皆さんも、多かれ少なかれ、「使いにくいソフトウエア」に不満をもったことがあるでしょう。 ケーススタディー (HTS)HyperTransactionSystemの失敗 ケーススタディー(概要) ① 開発チームの作成したものは、××さん（クライアント）の想像していたものとは、異なっていた。 ② どこが異なるかというと、××さん（クライアント）が思っていた「あってしかるべき機能がなかった」ことであった。 ③ しかし、開発チームは、４月時点での仕様書に書かれていない機能は実装しなかった。 ④ ソフトウエアができ、実際に使うときになって問題が発覚した。 ⑤ ××さん（クライアント）は、「性能が悪い」といって激怒した。 ⑥ 開発チームは、作り直しを求められたが、仕様書に書かれていないと反論した。 ⑦ １ヶ月間、水掛け論が続き、ユーザはその間使いづらいソフトウエアを使わされ、そのソフトウエアの評価が落ちた。 ケーススタディー(原因) ① 仕様書は、４月に作成されたが、開発チームが作ったものであり、実証実験チームは、その意味がわからなかった。 ② 実証実験チームは、８月にソフトウエアができるまで、プロジェクトに参加しなかった。（実証実験だけやればいいと思っていた。） ③ 開発チームは、仕様書の機能を満たし、試験にパスすれば、良いソフトウエアができると信じていた。 失敗の本質 ソフトウエアを作り始める段階で、「これから作るものを明らかにする」ことをしなかった。 完成イメージが人それぞれ違っていた。 この問題は、人間が言葉を使って、暗黙の了解を続けている間は、避けられない問題です。 「時計」システムを作ってください。 「ワープロ」システムを作ってください。 「時計」システム あなたの考える「時計」システムを考えてください。 それは、腕時計ですか？置時計ですか？ それは、デジタルですか？アナログですか？ 24時間表示ですか？12時間表示ですか？ アラームはついてますか？ 現在時刻を再設定できますか？それは、どのように行いますか？ ユースケースモデル ユースケースモデルを書く目的は、「作るシステムを明らかにする」ことです。 「明らか」とはどういう意味ですか？ 「明らか」になると、どのようないいことがありますか？ 発注者（クライアント）と開発者の思っていることの食い違いを防げる。 「作るものと、作らないもの」の意見の食い違いを防げる。 開発者の間での思っていることの食い違いを防げる。 自分で作るものがはっきりする。 作るものが、本当に必要かどうか、議論できる。 ユースケース 「ユーザ」がどのように使うのかを考える。 システムの「機能」ではなく、ユーザが受ける「サービス」で考える。 システムの「機能」をユーザが何のために利用するのかを考える。 Ex)「自動販売機」システムの場合 機能 在庫管理機能 販売商品表示機能 サービス 商品を買う（在庫が適切に管理されているかは、関係ない） 商品を選ぶ（表示されているかは関係ないかもしれない。希望商品があるかどうか問い合わせる方法もある。） アクタ サービスを受ける人のこと。 システムに対する「役割」で考える Ex）名簿システム 本名簿システムは、Aさん、Bさん、Cさん、が利用します。 3名とも、システムに対する役割は一緒なので、「ユーザ」アクタとして同じに取り扱う。 システムから見て、同じに役割に見える人は、同じアクタとして扱う。 しかし、管理する人がいる場合は、違う役割を持っているので、「管理者」アクタを追加する。 システムから見て、ユーザにはできないことができるから、役割が違う。 Aさんが、管理者を兼ねても良い ケーススタディー 自動販売機システム シナリオ 近くにある、ジュースの自動販売機を想像した。 山田くんは、まず500円玉を投入した。商品ディスプレイのサンプルを見て、値段が安かっ