欠陥追跡アプリのアーキテクチャ

アプリの構造

このFunctional Exampleは、Tulipライブラリ内の1つのアプリケーションですが、さまざまなユーザーの役割やニーズをサポートする専用アプリを構築できる場合、Tulipアプリの価値の多くは、Tulipアプリで生まれます。

レガシーな欠陥追跡ソリューションは、よくてもバグが多く、単発のポイントソリューションであり、最悪の場合、何十枚ものランダムなExcelシートや紙のフォーム、手作業でのデータ入力に多くの時間を費やしていました。

欠陥追跡は少しユニークな問題です。なぜなら、最高の欠陥追跡ソリューションは、インコンテキスト（欠陥が発見されるプロセス内）に存在するからです。したがって、最高の欠陥追跡ソリューションは、欠陥が発見される可能性のあるすべてのプロセスアプリケーションで使用可能でなければなりません。アプリのトランジションを使用して、ユーザーを任意のプロセスアプリから中央の欠陥追跡アプリに移動させたり、欠陥レポート機能をすべてのアプリケーションにコピーしたりすることができます。

1つの中央欠陥追跡アプリ

長所

• 欠陥管理プロセスの変更はシンプルで、変更点は1つ。
• プロセスアプリとは別のチームがアプリのバージョンを管理できる。

短所：

• 欠陥が別のアプリで入力されるため、ユーザーエクスペリエンスがバラバラになる。
• 複数のアプリで変数を管理するため、トリガーが集中する可能性がある。

すべてのアプリで欠陥レポート

長所

• ユーザーエクスペリエンスがよりシームレスになる。
• 欠陥の種類が異なるプロセスでは、標準的な欠陥をよりよくサポートするために、異なる UI を使用できます。
• アプリの変数管理がよりシンプルになる。

短所：

• プロセス変更が発生した場合の変更点が多い。これらの変更は、各アプリに単発で適用する必要がある。
• プロセスアプリを管理する同じチームが、それぞれのアプリの欠陥追跡を所有することになる。

アプリの内訳

不具合追跡のFunctional Exampleは、不具合追跡に必要なコア機能として機能する：

• 不具合の報告
• 欠陥レポートの編集
• (オプション）隔離用の欠陥ラベルの印刷
• 不具合の表示
• 次のステップとステータスの更新
• 不具合履歴の表示
• アナリティクスで欠陥に関する洞察を深める

機能例が示すように、すべての機能を1つのアプリにまとめることも、コア機能のいずれかをよりセグメント化されたアプリケーションに活用することもできます。

いずれのアプローチ（上記）であっても、チューリップは、欠陥の編集と処理機能を、特別な権限を持つユーザーだけがアクセスできる別のアプリケーションに移すことを推奨します。これにより、品質上重要なデータを編集できるユーザーをより厳密に管理できるようになります。