お客様が報告した障害の解決ポリシー

ccppmop158
HID_release_info_resolution_policy
BlueOfficial Clarity PPM ポリシー
20190125-POLICY.png
この標準障害解決ポリシーは、Clarity PPM (旧称: CA PPM)のオンプレミス エディション、オンデマンドまたは SaaS エディションと、CA Open Workbench や CA Mobile Time Manager アプリなどのセカンダリ アプリケーションを含む、すべてのアクティブなサポート対象リリースに適用されます。
このドキュメントでは、お客様から報告された障害の標準的な解決ポリシーについて説明します。 障害の解決は、各障害に相対的な重大度と優先度を割り当てて順番に行われます。 このドキュメントでは、重大度を割り当てる基準、修正を提供する方法、およびサービス レベル目標(SLO)について説明します。
2
技術的な重大度を障害に割り当てるための基準
CA サポートが問題を確認した後、その問題は Clarity PPM ソフトウェア開発チームに送られ、その動作が製品の障害であるかどうかが判断されます。 問題が製品の障害であると判断された場合は、技術的な重大度を割り当てて、修正を提供するかどうかがレビューを通じて判断されます。 障害が解決されると、技術的な重大度のレベルと複雑さに応じて、定義済みのパッケージで修正が提供されます。 技術的な重大度のレベルは、以下のように定義されています。
S1: 重要
重大度 1 (S1)の障害は、システム クラッシュ、重大なメモリ リーク、回復不可能なデータの破損や損失、回避策がない主要な機能上の欠陥、アプリケーションのインストールまたはアップグレードの失敗、同じ領域内での追加の機能テストの実施不可、ソフトウェア、UI、またはドキュメントでの不適切な項目に関連したものです。
S2: 高
重大度 2 (S2)の障害は、主要な機能上の欠陥、回復可能なデータの破損または損失、操作を誤る可能性のあるドキュメントの内容やエラー メッセージ、パフォーマンスの大幅な低下、英語以外のユーザが機能を使用できなくなるローカライゼーションやグローバリゼーションの問題、ハッカーがアプリケーション データを悪用できるようになる Web アプリケーションのセキュリティに関する脆弱性に関連したものです。 重大度 2 の問題には回避策がない場合があります。
S3: 中
重大度 3 (S3)の障害は、妥当な回避策がある機能上の欠陥、ドキュメントの軽微な問題、操作がわずかに不便になるユーザビリティやアクセシビリティの問題、重大でないパフォーマンスの低下、アプリケーションの不完全/不適切なアンインストール、不正なエラーメッセージに関連したものです。
S4: 低
重大度 4 (S4)の障害は、表示に関する軽微なエラーや不整合など、アプリケーションの通常の使用に影響しない問題に関連したものです。
障害の解決策の標準的な提供方法
障害の解決策を提供する方法は、障害の技術的な重大度と修正の実現可能性によって異なります。 複雑さ、リスク、および技術的な重大度に基づいて判断されます。 お客様から報告された障害の修正は、3 つの方法で提供されます。 解決された障害の修正は、以下の方法で次回に提供されます。
  • リリース、または
  • サービス パック、または
  • メンテナンス パッチ(重要な問題の場合)
リリース以外では障害を解決できない場合もあります。
通常、製品の拡張機能はパッチでは提供されず、リリースおよびサービス パックで予定されています。
製品リリース
弊社では品質を重視しています。 製品リリースは通常、6 か月ごとに作成され、それらのリリースの一環として、お客様から報告された障害を解決することに重点を置いています。 お客様から報告された障害に対処する基本的な手順は、弊社の製品リリース サイクルに基づきます。
製品リリースには、お客様から報告された障害の修正に加えて、拡張機能や注目の機能が含まれています。 これらの拡張機能と一緒に修正を提供することで、高品質で十分にテストされた製品をお客様に確実に提供できるようにしています。
製品のリリース サイクル中には、S2 の問題と
影響が大きい
S3 の問題に注目します。 影響が大きい S3 障害では、複数のお客様に影響するか、その回避策をすぐに利用できない可能性があります。 CA では、回避策を利用できる場合でも、影響の少ない S3 の障害を解決するために合理的な努力を行います。 障害とその影響を受けるお客様についてレビューした結果、障害を修正しないと判断する場合があります。
重大度が低い(S4)障害は、問題が障害として確認された場合にケースバイケースで解決策が検討されます。 S4 障害に関連付けられたケースは、問題が確認されるとクローズされます。 S4 の障害は、リリースでの修正のみを対象としてレビューされます。CA は特定の製品リリースに修正を組み込むために合理的な業務努力を行います。 お客様のレポート、機能の領域、およびその他の考慮事項に基づいて、障害を修正しないと判断する場合があります。 この場合、標準のサポート プロセスまたは CA PPM オンライン コミュニティの Web サイトを通じてお客様に通知されます。
サービス パック
CA PPM を継続的に改善する取り組みの一環として、主要な製品リリースの約 3 か月後にサービス パックがリリースされます。 通常、サービス パックには、既存機能の拡張と報告された障害の修正が含まれます。 サービス パックに障害の修正を含める方法は、製品リリースと同じです。
パッチ リリース
パッチでは、技術的に次のリリースまで修正を待つことができない、お客様に影響を与える特定の重要な問題に対処します。
スコープ
問題が重要(S1 または影響が高い S2)である場合、その問題の修正をパッチで提供することが検討される場合があります。
CA では、GA (15.8)および GA-1 (15.7.1)バージョンに対するパッチを通じて、ほぼ 1 か月おきに問題を積極的に修正して配信します(たとえば、1 月に GA、2 月に GA-1、3 月に GA など)。 このポリシーにより、お客様の環境で製品を正常に運用できるように最高品質のパッチを作成する取り組みに専念できます。
パッチで提供された修正は、現在開発中の製品リリース(GA 以外/次回の X.X.0 リリース、または X.X.1 サービス パック)に含まれます。 GA 以外のリリースには、ライフサイクルの一環として、コードのフリーズ日が含まれています。 現在開発中のバージョンのコード フリーズ日の後にパッチをリリースする必要がある場合、これらの修正は、新しいバージョンが GA になった直後にスケジュールされる最初のパッチに含まれます。 たとえば、15.8.0.1 パッチには、15.8 製品リリースのコード フリーズ日の後に提供された障害の修正が含まれています。
サービス終了(EOS)および有効期限終了(EOL)ポリシーにあわせて、特定の製品バージョンの EOL ステータスが発表された後は、修正が作成されません。
例外
一部の修正は、パッチで解決する条件を満たしていても、複雑さ、リスク、および他のお客様への影響が理由で、パッチ形式では提供できない場合があります。 さらに、以下の領域の障害はパッチでは解決されず、リリースまたはサービス パックでのみ解決されます。
  • スキーマの変更が必要な障害
  • OWB、MSP、Mobile Time Manager などのクライアント アプリケーションの更新
  • 主要なユーザ インターフェースの変更が必要な障害
  • Rally (以前の CA Agile Central)のような統合や Microsoft Project のようなコネクタの障害
  • 製品のアーキテクチャ スタック(互換性)およびローカライゼーションの変更
  • REST API を使用して構築されたカスタム アプリケーション
  • ベータ機能の障害(ベータ機能は、本番環境ではサポートされていません)
    その他の領域も、
    パッチなし
    のカテゴリに分類される場合があります。
GA および GA-1 リリースでは、四半期に 1 回、パッチに含めるクライアント側の修正が評価されます。 リスクと複雑さに関する標準の修正基準が適用されます。
SaaS
SaaS チームが SaaS 内のインスタンスにパッチを適用する場合、そのリリースの最新のパッチ レベルが適用されます。
パッチの頻度
パッチは、リリースに対して実施されるテストよりも限定的なテストを行い、短期間でリリースされます。 GA および GA-1 バージョン用に作成されたパッチは、ほぼ 1 か月おきにリリースされ(たとえば、1 月に GA、2 月に GA-1、3 月に GA など)、重要な問題を迅速に解決できるようになっています。
品質
パッチは、特定の問題や複数の問題を解決することを目的としており、以前のパッチからロールアップされた修正が含まれます(パッチは累積的です)。 すべてのパッチで QA テストが実施されますが、テストの範囲は以下に限定されます。
  • パッチで解決された修正箇所の検証
  • 影響を受ける製品領域に限定された回帰テストと統合テスト
各パッチについて、完全な回帰テストとパフォーマンス テストを実施することはありません。 このパッチは累積的であるため、修正の量が多いために完全な回帰テストとパフォーマンス テストが求められる場合、または特別なテストが必要な障害がある場合は、必要に応じてテストを実施します。 詳細な QA 検証には、必要に応じて、回帰テスト、パフォーマンス テスト、および選択された PAS テストが含まれます。 パッチのパフォーマンス テストと回帰テストが実施されている場合、パッチの README に記載されています。
お客様は、自身の環境におけるソフトウェアのパフォーマンスや機能に関して、ソフトウェア パッチが予期しない悪影響をもたらす可能性があることに注意してください。
ソフトウェア パッチを本稼働システムに直接適用する前に、設定およびデータ量の面で本稼働システムの代わりとなるテスト環境でパッチを確認してください。
サードパーティ製品の障害
Microsoft Project (MSP)のような製品については、新しくリリースされた更新に対して 2 か月に 1 回、高レベルのテストを実施し、毎月のテスト実施というベストエフォートの目標を設定しています。 これらのテストの結果に基づいて、CA では、
Clarity PPM
で使用するために特定の更新レベルを適用することを推奨する場合があります。
MSP に障害が見つかり、PPM 製品との統合に悪影響があるか、お客様に一定の品質のエクスペリエンスを提供できない場合、CA では、リリースされている PPM 製品でその MSP の更新レベルを使用することを推奨せず、サポートしません。 CA サポートの Web サイトで、サポート対象の MSP 更新の最新のリストを提供します。
Jaspersoft については、多くの要因によってパッチの日付が変動する傾向にありますが、一般的には、四半期ごとのパッチ提供を予定しています。
その他の CA アプリケーション
Clarity PPM
13.3 で最初にリリースされた Mobile Time Manager や、
Clarity PPM
15.5 で最初にリリースされた
Clarity PPM
Mobile 3.0 など、
Clarity PPM
と共に動作するその他の CA アプリケーションは、上記と同じスコープおよび優先度の手順に従います。 これらの製品の修正は、サーバ側または CA アプリケーションのクライアント側の機能で実行される場合があります。
  • 問題がサーバ側の機能のみに影響する場合、修正は、開発中のメイン リリースまたは CA PPM の GA/GA-1 パッチのいずれかで提供されます。 問題を修正しないことを決定する場合もあります。
  • 問題がアプリケーション側の機能のみに影響する場合、その時点で開発中のメイン アプリケーション リリースに修正プログラムが含まれる可能性があります。 問題を修正しないことを決定する場合もあります。
  • 問題がサーバとアプリケーションの両方に影響する場合、修正はメイン リリースでのみ提供されます。 問題を修正しないことを決定する場合もあります。
お客様が報告した障害に対する修正提供のサービス レベル目標
パッチに含まれる障害の修正は、今後公開されるリリースにも含まれます。 パッチ レベルの修正を含むバージョンのリリース ノートには、修正の詳細が記載されます。 提供方法は重大度によって異なります。
  • S1
    : パッチ
  • S2
    : パッチまたは製品リリース
  • S3
    : 将来の製品リリース、またはクローズ
  • S4
    : 将来の製品リリース(見込み)、またはクローズ