ユースケース記述
前回、ユースケース図についてお話ししました。 ユースケース図にアクター、システム領域、ユースケース、関連線として表現されるものについて、ご理解いただけたと思います。 今回は、ユースケース記述についてのお話です。 ユースケース図は、 どんなアクターがいるのかどんなユースケースがあるのかどのアクターがどのユースケースを利用するのかユースケース同士は、どんな関係を持っているのかについて、とてもシンプルでわかりやすく表現できます。 でも、わかりやすい反面、シンプルすぎて、これだけでは細かい情報が欠けています。 図に書けない細かい情報を補足するものが、ユースケース記述です。コンテンツユースケース記述とはユースケース名アクター概要前提条件イベントフロー事後条件まとめオススメユースケース記述とは ユースケース記述とは、一つ一つのユースケースに対する、補足説明です。 でも、UML(2.0)では、実際の書き
誤解しがちなモデリングの技：第5回：ユースケース図にまつわるアレコレ | 豆蔵ソフト工学ラボ
誤解しがちなモデリングの技 第5回：ユースケース図にまつわるアレコレ 印刷 株式会社豆蔵 ES事業部 皆川 誠 2009/07/07 ［モデリング］ 連載第5回のテーマは「ユースケース図」です。ユースケース図を描く際に誤って使われることが多い表記や、{あまり嬉しくない|誤った}ユースケース図の描き方/使い方などをいくつか紹介していきたいと思います。ただし、ユースケース図を描く際にもっとも典型的な失敗である「ユースケース図上で細かく機能分割してしまう」や「《include》と《extend》の使用方法を間違ってしまう」といった例については既に他の記事やホームページなどで多く解説されているので、是非それらの記事をご覧ください。本記事では、その他の少し気付きにくい誤用/誤解の例を紹介します。 その1：アクター⇔ユースケース間の関連線の矢尻 最近はそれほど見かけなくなってきましたが、少し古い本
良いユースケースを書くための発想法
システムの要求仕様を決めるのに、ユースケースを使うことがよくあります。 しかし、ユースケースは上手く書けない、何を書けば良いのか分からない、という人も、少なくありません。 たいていのユースケースは、アクターが１人２人いて、アクターが行える操作がいくつか丸で描かれて、それらが線で結ばれているだけの、とてもシンプルなものです。しかし、シンプルすぎて、何の役に立つのか分からない、という人もいます。 役に立つユースケースを書こうとして、細かいことまで書き込みすぎてしまう人も良く見かけます。しかし、それは誤りです。 ユースケースは何のために書くのでしょうか。ここでは、ユースケースの目的をはっきりさせて、良いユースケースを書くための考え方を紹介します。 開発者は、細かいことまでユースケースに書き込みがち Design Wave Magazine 2007年5月号別冊付録「組み込みシステム開発者＆LSI
機能テストとは何か? - たまゆら雑記
つい最近、機能テストって何だろうと話をしていました。 この機能テストという言葉は非常にやっかいな言葉で、コミュニケーションを取るのが難しい用語の一つです。 難しいということを知っていて、それなりに注意を払って話をしてみても伝わらないものは、なかなか伝わらないものです。 多くの書籍でも同様で、みな 好きなことを喋っている としか思えません。えっ、そう思わないって！ では少しばかりご覧ください。機能テストにまつわるさまざまな記述を。 「ソフトウェア・テストの技法」(Myers) p.118より引用 機能テストは、プログラムと外部仕様との相違点を発見する過程である。外部仕様は、外部世界（たとえばユーザ）からみたプログラムの行動について正確に記述することである。 「ソフトウェアテスト技法」(Beizer) p.9、p21、p422より引用 機能テストでは、プログラムやシステムを１個のブラックボック
今でも簡単に適用できる30年以上前の見積もり技法
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 前回からお届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 シリーズ2回目となる今回は“昔の見積もり技法”を解説します。見積もりを含めたプロジェクト管理は、過去30年以上、ほとんど進歩しておらず、
「やることリスト」に基づく見積もり手法
業務としてソフトウェアを開発するならば、工数の見積もりは避けては通れない。見積もりは、ソフトウェア開発プロセスのはじめの一歩に過ぎないが、その成否はプロジェクト全体の命運を握ることになる。プロジェクトに焦燥と混乱をもたらすことなく、堅実に開発を進めていくためには、正確で具体的な見積もり手法が求められる。 良く知られた見積もり手法の１つに、ファンクションポイント法がある。外部との入出力に着目して、ソフトウェアの機能から工数を見積もるファンクションポイント法は、有効な見積もり手法である。 だが、実際のソフトウェア開発の現場では、ファンクションポイント法で見積もりを行っているケースは多くはない。その原因の１つには、ファンクションポイント法を使うためには、入出力を定めたモデルの作成や、ポイントの計算方法など、専門的な知識と技能が必要なことが挙げられる。 小規模なソフトウェア開発では、見積もりのしや
現実的な見積もりアプローチを考える
思えばここ数年，「ソフトウエア見積もり」というテーマを追い続けてきた。2004年9月，日経ITプロフェッショナル（現在は日経システム構築と統合して日経SYSTEMS）で「本当に使える見積もり技術」という特集記事を担当。多くのユーザー企業やベンダーに取材し，現場の問題意識の高さや見積もりの難しさを知った。日本ファンクションポイント・ユーザ会をはじめ関連団体の会合にも参加し，現場のエンジニアの生の声を聞いた。 その特集が高スコアを得て，気をよくした記者は同タイトルの連載記事を企画（寄稿者は日立製作所の初田賢司氏）。2005年5月から11回にわたって，同連載の編集を担当した（おかげ様でこの連載も大変好評だった）。そしてこの10月2日，同連載をベースに大幅に加筆・修正した単行本を刊行する（要求定義に関する単行本も同時に刊行）。今回の記者の眼では，これまでの取材や編集などを通じて，見積もりについて“
FP法について - Writing Cafe
[Programs] / 最終更新時間：2004年06月24日 23時45分47秒 概要 最近、開発効率をなんとかしたいという思いが強くていろいろ調べている。どの手法を使うとどうなるのかが分からないと判断がつかない。そこで開発効率を測る物差しとしてファンクションポイント(FP)法に注目してみた。 よりよい開発のあり方については、楽しいプロジェクト運営もどうぞ。 目次 概要 目次 参考本 現状 ソフトウェアの規模 注意すること FP法の用語 用語の言い換え データファイル 要素処理 FP値の計測手順 どんなレポートを書くか？ プロジェクト見積もり 1. FPの計測タイプを識別する 2. 計測範囲とアプリケーション境界を識別する 3. すべてのデータファイルと、その複雑度を識別する ファンクションポイント計測一覧表-ファイルをリスト化 ファンクションポイント計測一覧表-ファイルの複雑度を加える
テスト計画の立案
今回は、どのビルドでどのようなテストをすべきかを計画する方法について説明します。ソフトウェア開発プロジェクトでは、いろいろな計画を立てなければいけませんが、テスト計画はその中でも大事なものです。テスト範囲とテスト戦略、QA要員やテストに必要なソフトウェア／ハードウェアなどのリソース調達、そしてスケジュールなどについて、テスト計画書を記述します。また、具体的なテストケースの記述と、この実施についても計画しなければなりません（一般に、テスト計画書の中にはテストケースは含まれません）。一口にテストといっても大変に奥が深く、テストのすべてを包括的に説明しようとすれば分厚い本が書けてしまうほどですが、今回は反復型開発において注意すべき事柄に的を絞って説明したいと思います。 テストの目的 テスト計画を立案・実施する前に、なぜそのテストをするのか、そのテストの目的を明らかにしておきましょう。ソフトウェア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chimaira.org
NESMA、ファンクションポイント法 (FPA)、他のソフトウェア計測法