システム品質ダッシュボード
- システム品質ダッシュボード（原題System Quality Dashboard 原著 Joseph W. Yoder and Rebecca Wirfs-Brock）[2]
「ダッシュボードは、タイムリーにデータを配信する必要があり、その適時性は、ダッシュボードにどのプロセスが表示されるかによって決まる」――Keith Gile（アメリカのマーケットリサーチ会社のアナリスト）
通常、アジャイルソフトウェア開発では、アーキテクチャや重要な品質特性など、他の重要なシステムの側面に注意を払うより前に、まずフィーチャーと機能性に注目します。アジャイルプロジェクトでは、「まず動かし、次に正しく動かし、そして最適化する」といった声を耳にすることがあります。ほとんどのアジャイルプラクティスは、プロダクトオーナーによって概説されている重要な機能要件を開発することを推し進め、それを作業のバックログ上で優先します。システムが進化するにつれて、チームはどのシステム品質特性が重要で、それらをどのようによりよく測定するかを理解しはじめます。システムが進化するにつれて、これらの品質特性を追跡することがますます重要になります。
アジャイルチームは、この情報にアクセスして可視化する手段をどうやって提供できるのでしょうか？
＊＊＊
ツールとダッシュボードの作成には時間がかかり、多くの場合、QAツールの構築に専念するリソースや人は限られています。ツールとダッシュボードは、システムが出荷するのに十分な要件を満たしているかの確認と比較すると、無意味な贅沢のように見えるかもしれません。
どの品質特性の監視が重要であるかを知ることは困難です。システムに組み込まれている品質特性が増えれば増えるほど、監視を継続することが重要だとする品質特性もあれば、一度検証してテスト可能になったことで十分とする品質特性もあります。
セキュリティ、パフォーマンス、信頼性といった特定の品質特性は、定期的に追跡されていないと開発プロセスの後半で改善することは困難になります。元々システムが品質制約を満たしていた場合でも、システムが進化するにつれて、品質特性を監視し、維持しつづけないと品質が低下する可能性があります。
一部の品質特性は、システムの機能が完了するまで正確に測定するのが難しい場合があります。ただし、システムの品質目標を達成できるかどうかを、システムの進化に応じて把握する必要があります。
＊＊＊
したがって、重要な品質特性をテストし、検証するためのダッシュボードを作成します。システムの重要な品質特性が何かが概説され、それがバックログに含まれているので、どの品質特性を監視する必要があるのか、そして、システムの進化に応じてシステムを測定するためのツールをどのタイミングで作成できるのか、に注意しておく必要があります。
最初のステップは、継続的に測定および監視する必要がある重要な項目の概要を説明することです。これらのいくつかは、部分的に実装された機能のみを実行して測定する単純な測定、検証から始めることができます。まずは、これらを既存のテストフレームワークに組み込むことができます。最初は単純な測定を行っているだけかもしれませんが、それらをダッシュボードに組み込まないと、可視化することはできません。そこで、これらの測定値をダッシュボードに組み込むことで、システムの進化に応じて重要な品質特性に関する継続的なフィードバックを提供することができるようになります。これが「継続的検査」の一形態です[MYGA]。
ダッシュボードをいつ構築するか、いつ購入する必要があるか？ ツールを選択するときには、セットアップがどれほど簡単か、すなわち、「すぐに使える」かどうかを知ることが重要です[FY98]。ツールが必要なすべてを提供し、比較的使いやすい場合は、ツールを使用します。ただし、強力な測定手段を提供する一部のツールは、費用がかかるか、使いにくい場合があります。そのため、強力なツールを購入するか、それほど強力ではないオープンソースのダッシュボードを使用するかを決定する必要があります。もう1つの考慮事項は、ダッシュボードが開発環境とどの程度うまく統合されるのかです。
ツールを購入するか構築するかに関わらず、どのような品質の側面を表示するものなのか、またそれらをどのような頻度で測定するかについて検討します。ダッシュボードは、ユーザーが指示したときに、ビルドまたは統合時に実行された品質関連のテストの結果を表示するものですか、または本番システムを監視するものですか？ ダッシュボードの内容を有用なものにするためにどれくらいの頻度で更新する必要がありますか？ また、測定値が許容可能な最低基準を下回るとどうなりますか？ 一部のダッシュボードツールでは、測定値がしきい値を超えたときにアラートと通知を設定できます。図1は、SonarCubeなどのシステムを監視するためのサードパーティのオープンソースツールの例です。
ダッシュボードは、実行中のプロセスのパフォーマンスなどのリアルタイムの結果を表示したり、チェックインまたはシステム構築の品質テスト中に測定された品質値を表示したりできます。これらのダッシュボードは、本番システムの運用ダッシュボードと重ねることができます。
チームが着陸ゾーンの再調整をする際には、新たに更新された値を含めるようにダッシュボードを調整することが重要です。
おわりに
連載の第7回では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集QA2AQから、アジャイルで重要な品質を特定するためのパターンをまとめた、分類「品質特性の特定」「品質の可視化」から3つのパターン、「着陸ゾーンの再調整（Recalibrate the Landing Zone）」「着陸ゾーンの合意（Agree on Quality Targets）」「システム品質ダッシュボード（System Quality Dashboard）」の和訳を提供しました。次回の連載では引き続き、分類「品質の可視化」から3つのパターンの和訳を提供する予定です。
参考文献
- [1] Joseph Yoder, Rebecca Wirfs-Brock, Ademar Aguilar, “QA to AQ: Patterns about transitioning from Quality Assurance to Agile Quality,” 3rd Asian onference on Patterns of Programming Languages (AsianPLoP 2014), Tokyo, Japan, 2014.
- [2] Joseph W. Yoder and Rebecca Wirfs-Brock, “QA to AQ Part Two: Shifting from Quality Assurance to Agile Quality,” 21st Conference on Pattern Languages of Programs (PLoP 2014), Monticello, Illinois, USA, 2014.
- [3] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Three – Shifting from Quality Assurance to Agile Quality – Tearing Down the Walls,” 10th Latin American Conference on Pattern Languages of Programs (SugarLoafPLoP 2014), Pousada Armação dos Ventos, Brazil, 2014.
- [4] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Four - Shifting from Quality Assurance to Agile Quality - Prioritizing Qualities and Making them Visible,”22nd Conference on Pattern Languages of Programs (PLoP 2015), Pittsbirgh, USA, 2015.
- [5] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Five,” 5th Asian Conference on Pattern Languages of Programs (AsianPLoP 2016), February 24-26, 2016, Taipei, Taiwan.
- [6] Joseph W. Yoder, Rebecca WirfsBrock, Hironori Washizaki, “QA to AQ – Part Six – Being Agile at Quality,” 23rd Conference on Pattern Languages of Programs (PLoP 2016), Monticello, Illinois, USA, OCTOBER 24-26, 2016.
- [BCK] Bass, Len, Clements, Paul and Kazman, Rick, Software Architecture in Practice (2nd Edition), Addison-Wesley, 2003.
- [BBC] Bransford T., Brown A., and Cocking, R., How People Learn: Brain, Mind, Experience and School. National Academy Press, 2000.
- [Brown] Brown T., The hunt is on for the Renaissance Man of computing, in The Independent, September 17, 1991.
- [CH] Coplien J. and Harrison, N., Organizational patterns of agile software development. Wiley, 2004.
- [Duv] Duval, Paul. Continuous Integration: Patterns and Anti-Patterns. DZone, 2010.
- [GILB] Gilb, Tom. 2005. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Butterworth-Heinemann.
- [FY98] Foote B., and Yoder, J. 1998. The Selfish Class. Proceedings of the 3rd Conference on Pattern Languages of Programs (Monticello, Illinois). PLoP '96, Technical Report #WUCS-97-07, September 1996, Department of Computer Science, Washington University. Pattern Languages of Program Design 3 edited by Robert Martin, Dirk Riehle, and Frank Buschmann, Addison-Wesley, 1998
- [Knuth] Knuth, D., “Structured Programming With Go To Statements,” Computing Surveys, Vol 6, No 4, December 1974, pp. 261-301.
- [MR] Manns, M. L., and Rising, L. Fearless Change: Patterns for Introducing New Ideas. Addison-Wesley Professional, 2004.
- [MYGA] Merson P., Yoder J., Guerra E., and Aguilar A., “Continuous Inspection: A Pattern for Keeping your Code Healthy and Aligned to the Architecture,” 3rd Asian Conference on Patterns of Programming Languages (AsianPLoP), Tokyo, Japan, 2014.
- [W2011a] Wirfs-Brock R., (July 28, 2011). Agile Landing Zones,
- [W2011b] Wirfs-Brock R., (August 16, 2011). Who Defines (or Redefines) Landing Zone Criteria,
