• 検索結果がありません。

4. アジャイルソフトウェア開発のための Tips

4.4 Tips一覧

4.4.2 モデリング

ふせんモデリング

【目的】

開発の初期段階において、クラス名などがまだ固まっていないときに、複数名で、対象領域 の概念およびその関係を明らかにするため。

【詳細】

ふせんを追加したり削除したりしながら対象領域の概念を明らかにして、ふせんをクラスや オブジェクトに見立てて、それらの関係を明らかにします。ふせんは動かすことが可能なため、

常にふせんの位置関係を変化させながら、あるべきモデルを検討することが容易にできます。

ふせんは模造紙やホワイトボード上に配置します。模造紙で行った場合はそのまま保存す ることができます。ホワイトボードの場合は、デジカメで結果を残します。

ファシリテイターが参加者の意見をまとめつつ、参加者はそれぞれ、ふせんをはっていきま す。それにより全員参加で議論ができます。

29

30

ユーザーストーリーから半径1mのモデリング

【目的】

対象の要件に関係するモデル要素だけを集めたモデル図(ビュー)を使用することで関係者 の理解を深めるため。

【詳細】

対象の要件に直接関係しないモデル要素を含むすべてを表示した大きくて複雑なモデルを 使ってしまうと、理解が困難な場合があります。そのため、関係者が容易に理解できるように、

対象を絞り込んだモデル要素を集めたモデル図(ビュー)を使うようにします。

31

ポンチ絵のようなモデル

【目的】

ラフなモデルを使って、実装する対象の構造や振る舞いを複数人で共有する。

【詳細】

モデルを通してシステムの構造を明らかにし、コードでは表現しきれない意図や考えを伝え ていくことができます。

また、どこまで理解できているのか、どこに分からないことがあるのか、そういったことを把 握するためにモデルを利用することができます。「分かっている」と思っていることであっても、

改めて描き出すことで、理解できていない部分や曖昧な部分が明確になることがあります。こ の段階では、モデルの完全性は必ずしも重要ではありません。

32

合意形成モデリング

【目的】

メンバー全員で、モデリング対象の共通理解を持つため。

【詳細】

プロジェクト初期にモデリング能力が高い個人が一人だけでモデルをつくりがちですが、そ の場合、モデリング対象の見方が偏っていたり、他の人の理解が不十分だったりします。

たたき台のモデルに対して議論をすると当初のモデルの影響を受けやすいので、必要なメ ンバー全員※1で、その場で共通理解を持つために、全員で議論しながらモデルを一からつくり あげるのが有効です。その際ホワイトボードを利用したり、モデリングツールの入ったパソコン の画面をプロジェクターで映したりします。

※1 開発者に加え、製品に対する責任を負う人なども含みます。

33

外部文書とモデルのトレーサビリティを確立する

【目的】

モデルだけでは表せない要求の詳細や別途検討した設計の詳細またはテスト手順とモデ ルを関連付けてモデルの確かさを高めるため。

【詳細】

UML のモデルが表す構造や処理内容は対象ソフトウェアのある側面を表したにすぎません。

要求項目や処理の流れはユースケース図やアクティビティ図で表すことができますが、それら を要求管理ツールやテスト管理ツールといった専用ツールで管理した方が適切に管理できる でしょう。また、処理の検討結果は技術文書としてまとめられ、管理されることもあるでしょう。

これらツールや技術文書を個別に管理するよりモデルを中心としてそれぞれを関連付ける ことで要求からテストまでを一貫して管理することができます。

具体的には、各要求を《requirement》としてモデル要素に表し、ユースケースやクラス、アク ティビティ図のアクションに関連付けることでモデルとのトレーサビリティを確立することができ ます。更に、モデリングツールの機能を使ってユースケースやクラスの下に外部ファイルへの リンクや外部システムの URL をインポートすることで技術文書やテスト管理ツールとモデルと のトレーサビリティを確立することができます。

この様にトレーサビリティを確立すると要求がソフトウェアのどこでどの様に実現されるか、

またどの様にテストされるか見える化することができ全体の品質向上に繋げられます。

<<requirement>>

text = 処理結果を ログファイルに 出力できること Id = 1.1.

ログ出力

TextFileDAO

<<satisfy>>

Logger

<<satisfy>>

<<interface>>

IOutputter

要求文書にある要求の各 項目を《requirement として表す

クラスが要求を満足して いることを表す。これに より、矢印の元となって いるクラスが要求を満た していることが保証され る。

34

関連したドキュメント