例による仕様

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

例による仕様SBE )は、抽象的なステートメントの代わりに現実的な例を使用して要件をキャプチャして説明することに基づいて、ソフトウェア製品の要件とビジネス指向の機能テストを定義するための共同アプローチです。これは、アジャイルソフトウェア開発手法、特にビヘイビア駆動開発のコンテキストで適用されますこのアプローチは、ドメインと組織が非常に複雑な大規模プロジェクトの要件と機能テストを管理する場合に特に効果的です。[1]

例による仕様は、例駆動開発、実行可能要件、受け入れテスト駆動開発(ATDD [2]またはA-TDD [3])、アジャイル受け入れテスト、[4]テスト駆動要件(TDR)とも呼ばれます。

利点

非常に抽象的または斬新な新しい概念は、具体的な例がなければ理解するのが難しい場合があります。[要出典]例による仕様は、正確な理解を構築することを目的としており、ソフトウェア開発におけるフィードバックループを大幅に削減し、やり直しの削減、製品品質の向上、ソフトウェア変更の所要時間の短縮、ソフトウェアに関連するさまざまな役割のアクティビティの調整の向上につながります。テスター、アナリスト、開発者などの開発。[1]

信頼できる唯一の情報源としての例

例による仕様の重要な側面は、すべての観点から必要な変更に関する信頼できる唯一の情報源を作成することです。ビジネスアナリストが独自のドキュメントで作業する場合、ソフトウェア開発者は独自のドキュメントを維持し、テスターは個別の機能テスト、ソフトウェア配信のセットを維持しますこれらの異なるバージョンの真実を絶えず調整および同期する必要があるため、有効性は大幅に低下します。反復サイクルが短い場合、このような調整は週単位または隔週単位で必要になることがよくあります。例による仕様では、さまざまな役割が、すべての人の理解を捉える信頼できる唯一の情報源の作成に参加します。例は、明確さと正確さを提供するために使用されているため、同じ情報を仕様として使用できます。そしてビジネス指向の機能テスト。機能のギャップの明確化、要件の欠落または不完全、追加のテストなど、開発または配信中に発見された追加情報は、この信頼できる唯一の情報源に追加されます。機能に関する信頼できる唯一の情報源があるため、配信サイクル内で知識を調整、翻訳、および解釈する必要はありません。

必要な変更に適用される場合、洗練された一連の例は、事実上、ソフトウェア機能を受け入れるための仕様およびビジネス指向のテストです。変更が実装されると、例を含む仕様が既存の機能を説明するドキュメントになります。このようなドキュメントの検証は自動化されているため、頻繁に検証される場合、このようなドキュメントは、基盤となるソフトウェアのビジネス機能に関する信頼できる情報源になります。そのようなドキュメントと、すぐに古くなる典型的な印刷されたドキュメントを区別するために[4]、例を含む仕様の完全なセットは、LivingDocumentationと呼ばれます。[1]

キープラクティス

例によって仕様を適用するチームは、通常、次のプロセスパターンを正常に適用します。[1]

  • 目標からスコープを導き出す
  • チーム全体の仕様ワークショップ、小規模な会議、電話会議のレビューを通じて、共同で指定する
  • 例を使用して要件を説明する
  • 精製仕様
  • 例に基づくテストの自動化
  • テストを使用して基盤となるソフトウェアを頻繁に検証する
  • 将来の開発をサポートするために、例を含む仕様からドキュメントシステムを進化させる

スクラムフレームワーク内で例によって仕様を適用するソフトウェアチームは、通常、共同で指定すること、例を使用して要件を説明すること、例を改善することなど、製品バックログの改善に5%〜10%の時間を費やします。[3]

マッピング例

マッピングの例は、会話を操作し、受け入れ基準を短時間で導き出すことができる単純な手法です。このプロセスは、ストーリーを例ごとに仕様の形で文書化されたルールと例に分割し、BDDの分野で広く使用されている手法です。[5]

適用性

例による仕様は、ビジネスドメインの観点から要件を理解または伝達する際に問題を引き起こすのに十分な組織およびドメインの複雑さを持つプロジェクトに適用されます。純粋に技術的な問題や、知識の理解や伝達に重要な複雑さがない場合には適用されません。投資銀行、金融取引、保険、航空券の予約、オンラインゲーム、価格比較などの分野で、このアプローチの使用法が文書化されています。[1]同様のアプローチは、原子力発電所のシミュレーションプロジェクトでも文書化されています。[3]

共有された例に基づくテストは、ビジネスの観点からソフトウェアを提供しながらチームをサポートするように設計されたテストのカテゴリに最適です(アジャイルテスト象限[6]を参照)-適切な製品が構築されていることを確認します。これらは、純粋に技術的な観点からソフトウェアシステムを調べるテスト(単体テスト、コンポーネントテスト、技術統合テストなど、製品が正しい方法で構築されているかどうかを評価するテスト)や、開発後に製品を評価するテストに代わるものではありません。 (セキュリティ侵入テストなど)。

歴史

ソフトウェアプロジェクトでの信頼できる唯一の情報源、要件、および自動テストとしての現実的な例の最初の文書化された使用法は、1996年の論文A Pattern Language of Competitive Development [7] [8]WardCunninghamによって説明されたWyCash +プロジェクトです。名前の例による仕様は、2004年にMartinFowlerによって作成されました。 [9]

例による仕様は、 1997年頃に提案されたエクストリームプログラミングのカスタマーテスト[10]プラクティスと、2004年のドメイン駆動設計からのユビキタス言語[11]のアイデアを発展させたものであり、WeinbergとGauseによって記述された要件としてブラックボックステストのアイデアを使用しています。[12] 1989年。

自動化

大規模プロジェクトでの例による仕様の適用を成功させるには、多数の例(テスト)に対してソフトウェア機能を頻繁に検証する必要があります。実際には、これには例に基づくテストを自動化する必要があります。一般的なアプローチは、テストを自動化することですが、非技術チームおよび技術チームのメンバーが読みやすくアクセスできる形式で例を保持し、信頼できる唯一の情報源として例を保持します。このプロセスは、仕様と自動化レイヤーの2つの側面に分割されたテストを処理するテスト自動化ツールのクラスによってサポートされます。多くの場合プレーンテキストまたはHTML形式であり、例と補助的な説明が含まれているテストの仕様。自動化レイヤーは、サンプルをテスト対象のソフトウェアシステムに接続します。このようなツールの例は次のとおりです。

参考文献

  1. ^ a b c d e Adzic、Gojko(2011)。例による仕様:成功したチームが適切なソフトウェアを提供する方法マニング。ISBN 9781617290084
  2. ^ ピュー、ケン(2011)。リーンアジャイル受け入れテスト駆動開発:コラボレーションによるより優れたソフトウェア:リーンアジャイル受け入れテスト駆動開発の物語アディソンウェスリー。ISBN 978-0-321-71408-4
  3. ^ a b c ラーマン、クレイグ; Vodde、Bas(2010)。リーンおよびアジャイル開発のスケーリングの実践:大規模スクラムを使用した大規模、マルチサイト、およびオフショア製品開発ピアソン。ISBN 978-0-321-63640-9
  4. ^ a b Adzic、Gojko(2009)。コミュニケーションギャップの橋渡し:例による仕様とアジャイル受け入れテストネウロイ。ISBN 0-9556836-1-0
  5. ^ Wynne、Matt(2015年12月8日)。「マッピング例の紹介」きゅうりブログ2021年5月10日取得
  6. ^ クリスピン、リサ; グレゴリー、ジャネット(2008)。アジャイルテスト:テスターとアジャイルチームのための実用ガイドアディソンウェスリー。ISBN 978-0-321-53446-0
  7. ^ プログラム設計のパターン言語2アディソン-ウェスリー。1996. ISBN 978-0-201-89527-8
  8. ^ ウォードカニンガム。「エピソード:競争力のある開発のパターン言語パートI」C2.com 2014年1月8日取得
  9. ^ マーティンファウラー2004年3月18日(2004-03-18)。「SpecificationByExample」Martinfowler.com 2014年1月8日取得
  10. ^ ベック、K。(1999)。極端なプログラミングの説明:変化を受け入れる。アディソン-ウェスリー。ISBN 978-0-321-27865-4
  11. ^ Evans、Eric(2004)。ドメイン駆動設計:ソフトウェアの中心にある複雑さへの取り組みアディソン-ウェスリー。ISBN 0-321-12521-5
  12. ^ ワインバーグ、ジェラルド; ガウス、ドナルド(1989)。要件の調査:設計前の品質ドーセットハウス。ISBN 0-932633-13-7

外部リンク