品質エンジニアリング

品質工学は、製品とサービスの品質保証と管理の原則と実践に関わる工学の分野です。^{[1]ソフトウェア開発では、高品質の基準を備えたITシステムと}エンタープライズアーキテクチャの管理、開発、運用、保守を指します。^[2]^[3]^[4]

説明

品質工学は、製品開発や生産、ソフトウェア開発における品質保証の戦略を立案し実行する工学の分野です。^[5]

品質エンジニアは、W. エドワーズデミングが次のように定義した製品品質の最適化に重点を置いています。

{\text{品質}}={\frac {\text{作業努力の結果}}{\text{総コスト}}}

品質工学の知識体系には以下が含まれる: ^[6]

マネジメントとリーダーシップ
品質システム
品質システムの要素
製品およびプロセス設計
品質特性の分類
設計入力とレビュー
設計検証
信頼性と保守性
製品およびプロセス管理
継続的な改善
品質管理ツール
品質管理および計画ツール
継続的改善技術
是正措置
予防措置
統計的プロセス制御 (SPC)
リスク管理

役割

監査人：品質エンジニアは、自社またはサプライヤーがISO9000やAS9100などの国際品質規格に準拠しているかどうかを監査する責任を負う場合があります。また、監査機関の下で独立した監査人となる場合もあります。^[7]

プロセス品質：品質エンジニアは、バリューストリームマッピングと統計的プロセス制御を担当し、プロセスが不良品を生み出す可能性があるかどうかを判断します。また、完了前に不良品を確実に検出できるように、検査計画と基準を作成することもあります。^[8]

サプライヤーの品質: 品質エンジニアは、サプライヤーの監査、サプライヤーの施設での根本原因の究明と是正措置の実行、または不良品の配送を防ぐためのそのような活動の監督を担当する場合があります。

ソフトウェア

IT サービスは、サイバーフィジカルシステム、B2B ワークフロー、クラウドサービスの使用時など、プラットフォーム境界、デバイス境界、組織境界を越えたワークフローでますます相互にリンクされています。このような状況では、品質エンジニアリングによって、品質属性の必要な包括的な考慮が容易になります。

このような状況では、管理から運用まで品質を「エンドツーエンド」で見ることが不可欠です。品質エンジニアリングは、エンタープライズアーキテクチャ管理、ソフトウェア製品管理、IT サービス管理、ソフトウェアエンジニアリングとシステムエンジニアリング、ソフトウェア品質管理と情報セキュリティ管理の方法とツールを統合します。つまり、品質エンジニアリングは、管理上の問題 (ビジネスおよび IT 戦略、リスク管理、ビジネスプロセスビュー、知識と情報の管理、運用パフォーマンス管理など)、設計上の考慮事項 (ソフトウェア開発プロセス、要件分析、ソフトウェアテストを含む)、運用上の考慮事項 (構成、監視、IT サービス管理など) を統合するため、ソフトウェアエンジニアリング、情報セキュリティ管理、ソフトウェア製品管理の従来の分野を超えています。品質エンジニアリングが使用される多くの分野では、法的要件やビジネス要件、契約上の義務、標準への準拠と密接に関連しています。品質属性に関する限り、 IT サービスの信頼性、セキュリティ、安全性が重要な役割を果たします。

品質エンジニアリングでは、品質目標は共同プロセスで実装されます。このプロセスでは、さまざまな情報源に基づく知識を持つ、ほぼ独立した関係者の相互作用が必要です。

品質目標

品質目標は、ソフトウェア品質の基本要件を記述する。品質工学では、品質目標は可用性、セキュリティ、安全性、信頼性、パフォーマンスなどの品質属性を扱うことが多い。ISO/IEC 25000などの品質モデルや目標質問メトリックアプローチなどの方法の助けを借りて、品質目標にメトリックを割り当てることができる。これにより、品質目標の達成度を測定できる。これは品質工学プロセスの重要な要素であると同時に、継続的な監視と制御の前提条件でもある。品質目標を効果的かつ効率的に測定するには、手動で特定されたコア数値（専門家の見積もりやレビューなど）と自動的に特定されたメトリック（ソースコードの統計分析や自動回帰テストなど）を統合して意思決定の根拠とすることが望ましい。^[9]

俳優

品質エンジニアリングに対するエンドツーエンドの品質管理アプローチには、さまざまな責任とタスク、さまざまな専門知識、組織への関与を持つ多数の関係者が必要です。

品質エンジニアリングに関わるさまざまな役割:

ビジネスアーキテクト、
ITアーキテクト、
警備員、
要件エンジニア、
ソフトウェア品質マネージャー、
テストマネージャー、
プロジェクトマネージャー、
プロダクトマネージャーと
セキュリティアーキテクト。

通常、これらの役割は地理的および組織的な境界を越えて分散しています。したがって、品質エンジニアリングにおけるさまざまな役割の異種タスクを調整し、タスクの遂行に必要なデータと情報を統合および同期し、適切な形式で各関係者が利用できるようにするために、適切な対策を講じる必要があります。

ナレッジマネジメント

知識管理は品質工学において重要な役割を果たします。^[10]品質工学の知識ベースは、コードリポジトリから要件仕様、標準、テストレポート、エンタープライズアーキテクチャモデル、システム構成、ランタイムログに至るまで、多様な構造化データと非構造化データで構成されています。ソフトウェアとシステムモデルは、この知識をマッピングする上で重要な役割を果たします。品質工学の知識ベースのデータは、地理的、組織的、技術的に分散したコンテキストで、手動とツールベースの両方で生成、処理され、利用可能になります。最も重要なのは、品質保証タスク、リスクの早期認識、関係者のコラボレーションの適切なサポートに重点を置くことです。

この結果、品質エンジニアリング知識ベースには次の要件が課せられます。

知識は、要求された品質で利用できます。重要な品質基準には、知識が一貫性があり、最新であること、また、適切な関係者のタスクに関する粒度の点で完全かつ適切であることが含まれます。
知識は、アクター間の相互作用をサポートし、データの分析を容易にするために、相互接続され、追跡可能です。このような追跡可能性は、異なる抽象化レベル間のデータの相互接続性 (要件とそれを実現するサービスとの接続など) だけでなく、適切なバージョン管理の概念が存在する場合にのみ可能な、期間にわたる追跡可能性にも関連しています。データは、手動でも (半) 自動でも相互接続できます。
情報は、適切なアクターのドメイン知識と一致する形式で利用可能でなければなりません。したがって、知識ベースは、情報の変換 (集約など) と視覚化のための適切なメカニズムを提供する必要があります。RACIコンセプトは、品質エンジニアリング知識ベースの情報にアクターを割り当てるための適切なモデルの例です。
異なる組織やレベルの関係者が相互にやり取りする状況では、品質エンジニアリングの知識ベースは機密性と整合性を確保するためのメカニズムを提供する必要があります。
品質エンジニアリング知識ベースは、関係者の品質管理タスクをサポートするために、分析と情報検索のさまざまな可能性を提供します。

共同作業のプロセス

品質エンジニアリングプロセスは、選択されたコンテキストにおける品質特性を特定、実現、測定するために、手動および (半) 自動で実行されるすべてのタスクで構成されます。このプロセスは、互いに独立して行動する関係者の相互作用を必要とするという意味で、非常に協調的なプロセスです。

品質エンジニアリングプロセスでは、 IT サービス管理などの高度に構造化されたプロセスや、アジャイルソフトウェア開発などの構造が限定されたプロセスを含む既存のサブプロセスを統合する必要があります。もう 1 つの重要な側面は、変更主導の手順です。この手順では、変更された要件などの変更イベントが、そのような変更によって影響を受ける情報とアクターのローカルコンテキストで処理されます。この前提条件は、変更の伝播と変更処理をサポートする方法とツールです。

効率的な品質エンジニアリングプロセスの目的は、自動化された品質保証タスクと手動の品質保証タスクを調整することです。コードレビューや品質目標の抽出は手動タスクの例であり、回帰テストやコードメトリックの収集は自動的に実行されるタスクの例です。品質エンジニアリングプロセス (またはそのサブプロセス) は、チケットシステムやセキュリティ管理ツールなどのツールによってサポートできます。

参照

協会

外部リンク

Txture は、テキストによる IT アーキテクチャのドキュメント化と分析のためのツールです。
mbeddr は、組み込みソフトウェアエンジニアリング用の統合された拡張可能な言語のセットと、統合開発環境 (IDE) です。
qeunit.comはQEに関するブログです
TMAP.netはSogetiの知識体系です

参考文献

^ Juran, JM (1988)。「付録 IV 品質システム用語」。Juran, JM (編)。Juranの品質管理ハンドブック。McGraw-Hill Book Company。pp. 2–3。ISBN 0-07-033176-6。
^ Ruth Breu、Annie Kuntzmann- Combelles、Michael Felderer (2014 年 1 月 - 2 月)。「ソフトウェア品質に関する新しい視点」(PDF)。IEEEソフトウェア。31 (1)。IEEE コンピュータソサエティ: 32 - 38。doi :10.1109/MS.2014.9。2014年4 月 2 日閲覧。
^ Ruth Breu、Berthold Agreiter、Matthias Farwick、Michael Felderer、Michael Hafner、Frank Innerhofer-Oberperfler (2011)。「Living Models - Ten Principles for Change-Driven Software Engineering」( PDF)。International Journal of Software and Informatics。5 (1–2) 。ISCAS : 267–290 。 2014年4月16日閲覧。
^ Michael Felderer、Christian Haisjackl、Ruth Breu、Johannes Motz (2012)。「リスクベーステストのための手動および自動リスク評価の統合」。ソフトウェア品質。ソフトウェア開発におけるプロセス自動化(PDF)。ビジネス情報処理の講義ノート。第 94 巻。Springer Berlin Heidelberg。pp. 159–180。doi : 10.1007 / 978-3-642-27213-4_11。ISBN 978-3-642-27212-7. 2014年4月16日閲覧。
^ 「品質エンジニアとは何か - 何をするのか、どうすればなれるのか?」 2017年2月17日。 2018年10月2日閲覧。
^ 「Certified Quality Engineer Certification Preparation - ASQ」。asq.org 。 2018年10月2日閲覧。
^ 「ISO 9001 Auditing Practices Group」. Committee.iso.org . 2019年3月29日時点のオリジナルよりアーカイブ。2018年9月7日閲覧。
^ 「プロセス品質エンジニア」。automotiveengineeringhq.com 2014年12月17日。 2018年9月7日閲覧。
^ Michael Kläs、Frank Elberzhager、Jürgen Münch、Klaus Hartjes、Olaf von Graevemeyer (2010 年 5 月 2 ～ 8 日)。「欠陥予測のための専門家データと測定データの透過的な組み合わせ: 産業ケーススタディ」(PDF)。第32回 ACM/IEEE 国際ソフトウェア工学会議の議事録。2。ACMニューヨーク、米国: 119 ～ 128。2014年4 月 8 日閲覧。
^ Jacek Czerwonka、Nachiappan Nagappan、Wolfram Schulte、Brendan Murphy (2013 年 7 月～8 月)。「CODEMINE: Microsoft でのソフトウェア開発データ分析プラットフォームの構築」(PDF)。IEEEソフトウェア。30 (4)。IEEE コンピューターソサエティ: 64～71。doi :10.1109/MS.2013.68。S2CID 32085825。2014年4月7 日閲覧。

[1] Juran, JM (1988)。「付録 IV 品質システム用語」。Juran, JM (編)。Juranの品質管理ハンドブック。McGraw-Hill Book Company。pp. 2–3。ISBN 0-07-033176-6。

[2] ^ Ruth Breu、Annie Kuntzmann- Combelles、Michael Felderer (2014 年 1 月 - 2 月)。「ソフトウェア品質に関する新しい視点」(PDF)。IEEEソフトウェア。31 (1)。IEEE コンピュータソサエティ: 32 - 38。doi :10.1109/MS.2014.9。2014年4 月 2 日閲覧。

[3] Ruth Breu、Berthold Agreiter、Matthias Farwick、Michael Felderer、Michael Hafner、Frank Innerhofer-Oberperfler (2011)。「Living Models - Ten Principles for Change-Driven Software Engineering」( PDF)。International Journal of Software and Informatics。5 (1–2) 。ISCAS : 267–290 。 2014年4月16日閲覧。

[4] Michael Felderer、Christian Haisjackl、Ruth Breu、Johannes Motz (2012)。「リスクベーステストのための手動および自動リスク評価の統合」。ソフトウェア品質。ソフトウェア開発におけるプロセス自動化(PDF)。ビジネス情報処理の講義ノート。第 94 巻。Springer Berlin Heidelberg。pp. 159–180。doi : 10.1007 / 978-3-642-27213-4_11。ISBN 978-3-642-27212-7. 2014年4月16日閲覧。

[5] 「品質エンジニアとは何か - 何をするのか、どうすればなれるのか?」 2017年2月17日。 2018年10月2日閲覧。

[6] 「Certified Quality Engineer Certification Preparation - ASQ」。asq.org 。 2018年10月2日閲覧。

[7] 「ISO 9001 Auditing Practices Group」. Committee.iso.org . 2019年3月29日時点のオリジナルよりアーカイブ。2018年9月7日閲覧。

[8] 「プロセス品質エンジニア」。automotiveengineeringhq.com 2014年12月17日。 2018年9月7日閲覧。

[9] Michael Kläs、Frank Elberzhager、Jürgen Münch、Klaus Hartjes、Olaf von Graevemeyer (2010 年 5 月 2 ～ 8 日)。「欠陥予測のための専門家データと測定データの透過的な組み合わせ: 産業ケーススタディ」(PDF)。第32回 ACM/IEEE 国際ソフトウェア工学会議の議事録。2。ACMニューヨーク、米国: 119 ～ 128。2014年4 月 8 日閲覧。

[10] Jacek Czerwonka、Nachiappan Nagappan、Wolfram Schulte、Brendan Murphy (2013 年 7 月～8 月)。「CODEMINE: Microsoft でのソフトウェア開発データ分析プラットフォームの構築」(PDF)。IEEEソフトウェア。30 (4)。IEEE コンピューターソサエティ: 64～71。doi :10.1109/MS.2013.68。S2CID 32085825。2014年4月7 日閲覧。