大規模なアプリケーションのすべての機能を追跡する方法
タイトルが示すように、アプリケーションが大きくなるにつれて機能を追跡する方法は？
私の会社では、アプリケーションが「ユースケース」と呼ばれるチャンクに分割されているWordドキュメントを使用しています。これは、サイズと複雑さが異なります。問題は、「ハッピーパス」とEdgeケースの間をスキャンしなければならないため、それらのいくつかがすぐに大きくなって読みにくくなることです。
最近、アプリケーションのライフサイクル全体でVisual Studio Team Servicesの使用を開始しました。VSTSやその他のシステムで、Word文書よりも優れた方法があるのではないかと思います。
組織とアプリケーションでこの問題をどのように処理しますか？ （VSTSを使用している場合-課題に取り組むためにVSTSの機能を使用していますか？）
回答とコメントへのフィードバック
Bart van Ingen Schenau楽しい答え。その方法でアプリケーションに関連付けたいのですが、文書化する必要のあるアプリケーションはたくさんあります。これはその1つです。
クリストフ包括的な回答ありがとうございます。その内容から、これは多様なテーマであり、簡単に答えられるものではないことがわかります。他のコメントからも多くの意見があることを実感しています。私はあなたのリンクとあなたが言及した用語に感謝します。私はすでにBPMNとユースケース2.0について読み始めています。
Ewan誰かがあなたの意見に沿って何か答えてくれることを願っています。テスト駆動開発（TDD）と同じ方法で、自動化されたテストとドキュメントを（同時に）作成する標準的な方法があることを望みました。私が達成したいと思っているのは、変更が、いわば、何が起こるかについての既存の契約を壊すときをすぐに確認することです。
クリストフへのフィードバック
このアプリ/システムのドキュメントには、約400のユースケースが含まれています。私たちはあなたがするよりも多かれ少なかれドキュメントを各ユースケースに入れているかもしれません。もっと疑う。
ほとんどのドキュメントをエンドツーエンドのテストに変換したいのですが。現在、エンドツーエンドまたはUIテストはありません。ただし、ユニットテストはたくさんあります。次のことを想像してみてください。
X.0の使用例は非常に単純ですが、x.1の使用例はかなりあります-ハッピーパスからの逸脱と呼ばれるもの。私たちの製品で400のユースケースを数えるとき、私はすべての偏差を含めませんでした。
ドキュメントがテストになる方法を見たいのですが。おそらく私は ガーキン構文 のようなものを使うことができますか？
Feature: Disallow modifying Product Number when Product is in use
The user cannot modify the Product Number when the Product is in use.
Background:
Given a product with Product Number 123
Scenario: A user attempts to modify a Product Number when the product is in use
Given the product being associated with an Order Line
When I try to change the Product Number to 456
Then I should see "You cannot change the Product Number, as the Product is already being used"
Scenario: A user attempts to modify a Product Number when the product is not in use
Given the product not being associated with any other entity
When I try to change the Product Number to 456
Then I should see "Changes saved"
ドキュメントが必要ですか？
大規模なソフトウェアシステムでは、構造化された方法で機能を追跡する必要があります。
- 私は、システムの機能を文書化するのに確かな（統合または受け入れ）テストスイートで十分である可能性がある、小さなチームによって開発されたシステムについては話していません。必要に応じて、開発者は、新しい利害関係者と進化について話し合う前に、テストケースから機能をいつでも再発見/リバースエンジニアリングできます。
- 私はむしろ、ERP 400を超えるユースケースと数千のユーザーを表す60の異なる役割を持つ、より大きなシステムを考えています。誰もすべての詳細を知ることも覚えることもできません。また、さまざまな利害関係者がシステムが何をするか、または何をするかについての異なる理解。
- 場合によっては、ドキュメントを維持する義務を負うこともあります（ SOX規制 ファイナンスの場合、 [〜＃〜] gmp [〜＃〜] 医薬品製造の要件）
機能の文書化には、主に2つの側面があります。システムが利害関係者のために行うことと、システムの実装方法です。 3つ目は、最新の状態に保つ方法です。
1.システムは利害関係者のために何をしますか？
問題1：概要を保持する
ビジネスの利害関係者が、UCの画面またはフローアクションの変更を要求するとします。通常、UCの大規模なフラットリストを確認します。あなたはICを見つけるでしょう。おそらく、同様に影響を受ける可能性のある密接に関連するものもいくつか識別します。しかし、彼らのタイトルの背後にあるものを理解していない場合、いくつかのあまり明白でない接続とビジネスの副作用を見逃す可能性があります。
解決：
- スコープ内の主要なビジネスプロセスの概要を含むドキュメントを作成します（アクティビティのドメインごとに編成された大企業の場合、複数のドキュメントになる場合があります）。それらの分解を主要なステップに文書化します（通常、いくつかの高レベルの [〜＃〜] bpmn [〜＃〜] 図を使用します）。
- ユースケースとプロセスステップをリンクする通信テーブルを作成します。
次に、大規模なナビゲーションから適切なユースケースまで掘り下げ、逆に、任意のUCから開始して、ビジネスプロセス（および同じプロセス内の他のすべての潜在的に関連するユースケース）を見つけます。
問題2：判読できない複雑な使用例
あなたが説明したように、リスクは、UCが適切な詳細レベルにないため、または単にバリアントや例外が多すぎるために、非常に複雑になる可能性があることです。
ソリューション：
- 効果的なユースケースの作成 、 Alistair Cockburn （Agile Manifestoの作成者の1人）では、マルチレベルの使用方法を説明しています複雑なUCをいくつかのより単純で理解しやすいものに分解する場合。例がたくさんある本です。
- ユースケース2.0（無料の電子ブック） 、 Ivar Jacobson （ユースケースコンセプトの発明者および共著者of UML）は、ユースケーススライスでユースケースをカットする非常に効果的なアプローチを提案しています。バリアントフローは別のスライスにあるため、読みやすくなります。このアプローチは、Jeff Pattonの ユーザーストーリーマッピング と似ていますが、機能主導のアプローチではなく、目標主導のアプローチです。
2.機能はどのように実装されていますか？
技術文書の領域では、すぐに同期がとれておらず、時代遅れになっている役に立たない散文を過剰に文書化して書くリスクが高くなります。したがって、非常に注意して、可能であれば包括的なドキュメントを避ける必要があります。
推奨事項（ 古いもの from Grady Booch 、OO UMLのパイオニアおよび共同開発者））は、以下の情報に焦点を当てることです。コードで簡単に読み取ることができないため、アイデアは次のとおりです。
- 設計の主な駆動原理を説明するために、
- 関連する主要コンポーネントの概要を簡単に説明する
- 次に、単一のコンポーネントがすべての詳細でどのように機能するか（コードによって既に文書化されています）ではなく、コンポーネント間の意図と主要な相互作用を説明することに重点を置きます。
それを最新に保つ？
複雑な生活システムの優れたドキュメントがある場合、6か月後には古くなります。最新の状態に保つ唯一の方法は、このプロセスを開発プロセスの不可欠な部分として扱うことです。これは、doneの定義の一部である必要があります。
技術文書のアドバイスに従えば、まれな場合にのみ更新する必要があります（新しいコンポーネント、相互作用の大きな変更）。
UCにとって、それはもちろん、主要なユーザーと口頭で話し合う単純な会議に比べてオーバーヘッドです。しかし、複雑なシステムの場合、そのようなUCは一般に、他の利害関係者によって検証/確認される必要があります。したがって、大規模な組織では、ユースケースのこのリアルタイムのドキュメントは、コミュニケーションをより効果的にするのに役立つ可能性があります。
自動テスト。理想的には、人間が読める形式の説明、おそらくBDDスタイルです。
実際の危険性は、以前の機能を誤って壊す新しい機能を追加することなので、これらはドキュメントよりもはるかに優れています。
ドキュメントを使用して、すべてを読み、アプリケーションを手動でテストする必要がありますが、ドキュメントどおりに機能します。
テストを使用すると、すべてのテストを実行して、それらが緑色であることがわかります。