T.MURACHIの日記: ユースケースお勉強ちう 4
日記 by
T.MURACHI
とりあえず、こいつの第1部までは読み終わったので、ここまでの雑感を。。。
現場で作成されていたユースケース定義書 (以下、UC 定義書と記述) の書きぶりや運用に対して疑問を抱いたことを動機として学習を開始したのですが、どうやら大方の疑念は的中してしまったように思います。
現場での運用については様々な経緯も混交している為、恐らく見積もり (のための根拠作り) を主目的として記述を開始した協力会社の側としても納得の行かない部分は多かったんではなかろうかと思うのですが (っていうかおいらがそう思いたいだけなんですが ^_^;)、運用のフローとしては大体以下のようになっていて、
- 本社側の人間がユーザーと折衝して要求仕様を作成し、協力会社へ提示。
- 協力会社は UC 定義書を機能単位で作成し、開発の見積もりを立てる。
- 開発者は UC 定義書を外部仕様書として参照し、内部設計および実装を行う。
- テスターは UC 定義書を外部仕様書として参照し、総合テスト仕様を作成、テストを実施する。
- リリース。
各文書の特徴や関連性について言及するとこんな感じになっていました。
- 要求仕様は要件を元に外部仕様のドラフトとして記述されるもので、UI に関する詳細 (メニュー項目や作成するダイアログ、ダイアログ内のコントロール、操作手順例等) についてもある程度踏み込んで記述されている。
- UC 定義書は外部仕様として参照されるため、要求仕様に記述されているすべての情報を含む必要があった。すなわち、UI に関する詳細についてもこの中に明記されていた。
- 総合テスト仕様は、ユースケースとしてまとめられている一通りのシナリオを辿り、その結末が期待通りの動作であることを確認するものとして作成されていた。ちなみに、システムの内部動作に関しては別途モジュール単位でのテストが行われていたが (本社側で実施)、GUI のテストとして行われていたのは実質この総合テストだけであった (協力会社側で実施)。
その為、以下のような問題が発生していました。
- UC 定義書は以下の理由により、ユースケースとしては非常に読みにくい文書になってしまった。
- UI に関する詳細に踏み込んで記述されたため(「ユーザーは、エディットボックスにニックネームを入力し、ダイアログの [OK] ボタンを押す」など)、アクターの目的が把握しにくくなった (そこでやろうとしていることを目的を主眼に記述するなら、「ユーザーは、ニックネームを入力する」で十分である)
- シナリオとして吸収できない事柄を多く記述する必要があったため、巻末に設けた「備考」欄が膨大に膨れ上がった。最終的には記述に割ける工数が間に合わなくなり、要求仕様の記述が丸々「備考」欄にコピペされたりした。
- 目的単位ではなく機能単位で記述されたため、複数の機能を組み合わせて使用するようなケースについて、別途 UC 定義書を作成するということを行わなかった。その為、このようなシナリオがどの UC 定義書に記述されているのかが見つけづらくなってしまった。
- UC 定義書が読みにくいため、本社側の開発者は外部仕様として要求仕様を参照するようになってしまった。UC 定義書のレビューはそれなりに行われていたが、内容に若干の食い違いがあることもあり、そのことが開発に影響することも少なくなかった。
- GUI の細かい動作 (共通の動作、コントロールのフォーカス、等) に関するテストが不十分であった。また、こうした部分のバグの誘発により、深刻な不具合が潜在的に残ってしまうことも幾度かあった。
今回の学習を通じて、現場で感じていた違和感をここまで説明できるようになったのはありがたいことです。
更に言えば、ユースケースの作成には、潜在的な要求の洗い出しという側面があるのですが、これについてはまったく行われていませんでした。開発者の立場として言わせてもらえば、重大な設計ミスに直面するたびに、「一体何のために UC 定義書なんてものを作っていたんだろう?」という思いでいっぱいになっていたわけです。。。(;_;)/
むむむ (スコア:1)
UML 記述の実例として、非常に参考になりました。んー、自分のところのプロジェクトも、UML の記述ルールを見直したほうがいいのかなぁ...。
Re:むむむ (スコア:1)
どもです。ご参考いただけたようで何よりです :) 。
現場ではユースケース図が使われていたのかどうかは知らないのですが (少なくとも本社向けの設計資料としては提示されていなかったようです。。。GUI 部分の内部設計としてクラス図などは作っていたようですが)、ユースケース図は各ユースケースの関係を図示するためのものかと思われますので、どこまで詳細に踏み込むべきかを見計らうのが結構キモなんじゃないかと思います。うまく使えれば、各ユースケースの目的レベルの分析やグルーピング、クリッカブルマップ的な目次作りなどとして利用できそうですが。。。
ちなみに、現場の本社側の開発チームはプレーンテキスト崇拝者が多くて grep 使えないと話にならないという人がほとんどなので (おいら含むw)、UML 使って設計しましょうとか言うだけで嫌な顔されるのはほぼ確実なのですが (^_^; 。今回の件だって、UC 定義書が MS-Word で書かれているからダメなんだよって思っている人がほとんどだし。そういう問題じゃないんだってば~ (((/;^^)/ 。
むらちより/あい/をこめて。
合理化になるのかな~ (スコア:1)
3.開発者は UC 定義書を外部仕様書として参照し、内部設計および実装を行う。
この文だけでは判断できないのですけど,UC 定義書以外に外部設計レベルの書面はなかったのでしょうか.UC 定義書だけでは,内部設計できないでしょうしね・・・・.なんだろう.UC 定義書にいろいろ詰めて“合理化”なぁ~んて,そんな感じなんだろうか?『これだけ見ればいいよ』という,魔法のドキュメントがUC 定義書だったのかもしれない.おおっ!みんな魔法にかかって混乱しているぞ~.わくわく.
o(^_^)o
シナリオとして吸収できない事柄を多く記述する必要があったため、巻末に設けた「備考」欄が膨大に膨れ上がった。最終的には記述に割ける工数が間に合わなくなり、要求仕様の記述が丸々「備考」欄にコピペされたりした。
“いかにも”ありそうな現象ですね~.やはり生の声は貴重ですね.勉強になりました.
m(_ _)m
Re:合理化になるのかな~ (スコア:1)
どもです (^_^) 。大体おっさられる通りで、少なくとも本社側の人間は確実にメダパニ喰らって効果テキメンでした (x_x)/ 。
ユースケースについて学ぶ前までは、おいら自信はユースケースをどういった目的で定義するものなのかを知らなかったので、仕事振りを見る限りでは、下請けをお願いした協力会社がその会社の流儀に則って仕事を進める上で必要だというだけのもの (つまり、形式的なもの、いわゆる「儀式」) でしかないように見えました。
結論としては、この予測は大方当たっていたのですが (^_^; 、それでも要求を分析する上でユースケースという手段が有用であることを理解することはできたので、「ユースケース」と聞いただけで吐き気を催すような精神的アレルギーにならずに済んだのはありがたいことですw。そして、要求を収集する方法と、ソフトウェアを設計する方法は、大分違うプロセスを辿るものであるということを知ることができたのもかなりありがたいです (要求の収集は機能分解で行うとうまく行き、それと同時に、ソフトウェア設計はデータと振る舞いを合わせてコンポーネント化することでうまく行く … 同書 17.3 節より)。よーするに、ユースケースを設計文書としてそのまま扱ってはいけないってことやね。要求は要求、設計は設計として分けて考えなくちゃいけない。
今回のケースで、我々「本社側の人間」は既に開発フェーズに入っているという立場で作業を行っており、「要求仕様」というやつについても、(ドラフトレベルであるとはいえ) かなり開発者よりの情報としてまとめられたものでした。それをユースケースに書きなおすというのはまさに逆方向のプロセスであり、少なくとも GUI という「部分」の開発をお願いされている協力会社側の人間が行うべき作業だったのかというと、激しく疑問が残るわけです。もっとも、より詳細な設計を行う上で、高レベルの設計を参照する要求を分析し、その要求を元に低レベルな設計を構築するというプロセスはアリなのかもしれませんが。でも要求分析ってのもあんまり真面目に行われていなかったみたいだしなぁ。。。特に異常系 (-_-; 。
むらちより/あい/をこめて。