Policy di risoluzione delle anomalie segnalate dai clienti di Clarity PPM

ccppmop1561
Criterio di Clarity PPM BlueOfficial
HID_release_info_resolution_policy
20190125-POLICY.png
Il presente criterio standard di risoluzione dei difetti è valido per tutte le release attive supportate di Clarity PPM (noto in precedenza come CA PPM), incluse le versioni on-premise, on demand o SaaS, e per le applicazioni secondarie, come CA Open Workbench e l'app CA Mobile Time Manager.
Di seguito è illustrato il criterio di risoluzione standard per i difetti segnalati dai clienti. Ai fini della risoluzione, viene assegnata a ciascun difetto una gravità e una priorità relativa. Questo documento descrive i criteri per l'assegnazione della gravità, le modalità con cui vengono fornite le correzioni e gli obiettivi del livello di servizio (SLO).
2
Criteri utilizzati per l'assegnazione della gravità tecnica ai difetti
Dopo che il Supporto tecnico di CA ha verificato l'esistenza di un problema, interviene il team di sviluppo software di Clarity PPM per capire se il comportamento è dovuto a un difetto del prodotto. Se si stabilisce che il problema è un difetto del prodotto, si assegna un livello di gravità tecnica e il problema viene esaminato per determinare se e quando fornire una correzione. Se il difetto viene risolto, la correzione verrà fornita in un pacchetto definito in base al livello di gravità tecnica e alla complessità. I livelli di gravità tecnica si distinguono in:
S1: Critico
Con difetto di gravità 1 (S1) si fa riferimento a: arresto anomalo del sistema, perdita della memoria principale, danneggiamento o perdita di dati irreversibile, grave malfunzionamento senza soluzione alternativa, impossibilità di installare o aggiornare l'applicazione, impossibilità di effettuare ulteriori test delle funzionalità nella stessa area o elementi considerati offensivi nel software, nell'interfaccia utente o nella documentazione.
S2: Alta
Con difetto di gravità 2 (S2) si fa riferimento a: grave malfunzionamento, danneggiamento o perdita di dati reversibile, documenti o messaggi di errore che potrebbero determinare azioni errate, riduzione significativa delle prestazioni, problemi di localizzazione o internazionalizzazione che rendono le funzionalità inutilizzabili per gli utenti non di lingua inglese e vulnerabilità di sicurezza dell'applicazione Web che permettono agli hacker di sfruttare i dati dell'applicazione. I problemi di gravità 2 possono disporre o meno di una soluzione alternativa.
S3: Media
Con difetto di gravità 3 (S3) si fa riferimento a: difetto di funzionalità con una soluzione alternativa accettabile, errori minori nella documentazione, problemi di usabilità o accessibilità che causano piccoli inconvenienti, riduzione trascurabile delle prestazioni, disinstallazione incompleta/errata dell'applicazione o messaggi di errore incorretti.
S4: Bassa
Con difetto di gravità 4 (S4) si fa riferimento a un problema privo di conseguenze sull'uso quotidiano dell'applicazione, quali errori estetici o incongruenze con scarsa visibilità.
Modalità standard per rendere disponibili le correzioni dei difetti
La correzione di un difetto risolto viene fornita a seconda della gravità tecnica e della sua fattibilità. La decisione viene presa in base a complessità, rischio e gravità tecnica. Le correzioni per i difetti segnalati dai clienti vengono rese disponibili in tre modi. La correzione di un difetto risolto viene fornita:
  • nella release successiva; oppure
  • nel Service Pack successivo; oppure
  • nella patch di manutenzione successiva (problemi critici).
In alcuni casi, non è possibile correggere un difetto al di fuori di una release.
In genere, i miglioramenti apportati al prodotto non vengono inclusi nelle patch, bensì nelle release e nei Service Pack.
Release di prodotto
La qualità è importante per noi. In genere, le release di prodotto vengono rilasciate ogni sei (6) mesi, mettendo in evidenza se comprendono correzioni dei difetti segnalati dai clienti. Le correzioni dei difetti segnalati dai clienti vengono offerte principalmente tramite il ciclo di release del prodotto.
Le release di prodotto includono miglioramenti e funzionalità importanti oltre alle correzioni dei difetti segnalati. In questo modo i clienti avranno a disposizione un prodotto collaudato di alta qualità.
Durante un ciclo di release del prodotto, si presta particolare attenzione ai problemi S2 e S3 ad
alto impatto
. Un difetto S3 ad alto impatto interessa più clienti o prevede una soluzione alternativa che potrebbe non essere facilmente fruibile. CA farà tutto il possibile per risolvere i difetti S3 a basso impatto anche se è disponibile una soluzione alternativa. In alcuni casi, in base all'esame del difetto e dell'impatto sui clienti, si potrebbe decidere di non risolvere il problema.
I difetti del prodotto con gravità bassa (S4) vengono presi in considerazione per la risoluzione caso per caso, una volta accertati. Tutte le richieste collegate a difetti S4 verranno chiuse una volta accertato il problema. I difetti S4 verranno esaminati solo nei cicli di release. CA farà tutto il possibile per inserire la correzione in una release di prodotto. In base alle segnalazioni dei clienti, all'area interessata e ad altre considerazioni, si potrebbe decidere di non risolvere un difetto. In tal caso, il cliente verrà informato tramite la procedura di assistenza standard o il sito Web della community online di CA PPM.
Service Pack
Nell'ottica aziendale di migliorare costantemente CA PPM, dopo tre mesi circa da una release di prodotto principale vengono rilasciati i Service Pack. In genere, i Service Pack includono miglioramenti delle funzionalità esistenti e correzioni dei difetti segnalati. I Service Pack seguono la stessa procedura delle release di prodotto per includere le correzioni dei difetti.
Release di patch
Le patch risolvono un gruppo specifico di problemi critici che interessano i clienti e che tecnicamente devono essere risolti prima della prossima release.
Ambito
Se un problema è critico (S1 o S2 ad alto impatto), si può prendere in considerazione di fornire la correzione tramite patch.
I problemi vengono risolti in modo attivo tramite il meccanismo delle patch solo per le versioni GA e GA-1 grossomodo a mesi alterni (ad esempio, GA a gennaio, GA-1 a febbraio, GA a marzo e così via). Questa politica consente di dedicare il lavoro dei team alla creazione di patch ottimali per garantire il corretto funzionamento delle implementazioni dei clienti.
Le correzioni fornite nelle patch verranno incluse nella release di prodotto attualmente in fase di sviluppo (release X.X.0 non GA/successiva o prossimo Service Pack X.X.1). Il ciclo di vita delle release non GA prevede una data di blocco del codice. Se una patch viene rilasciata dopo la data di blocco del codice per la versione attualmente in fase di sviluppo, tali correzioni verranno incluse nella prima patch pianificata subito dopo la nuova versione GA. Ad esempio, la patch 15.6.1.1 includerebbe le correzioni dei difetti fornite dopo la data di blocco del codice per la release di prodotto 15.6.1.
In linea con i criteri di termine del servizio (EOS) e termine del ciclo di vita (EOL), le correzioni non verranno generate dopo l'annuncio dello stato EOL per una versione specifica del prodotto.
Esclusioni
Alcune correzioni che in altri casi soddisfano i criteri di risoluzione in una patch potrebbero non essere fattibili a causa della complessità, del rischio e dell'impatto sugli altri clienti. Inoltre, i difetti nelle seguenti aree non vengono inclusi in una patch, ma sono riservati solo alle release o ai Service Pack:
  • Difetti che richiedono una modifica dello schema
  • Aggiornamenti delle applicazioni client come OWB, MSP o Mobile Time Manager
  • Difetti che richiedono una modifica importante dell'interfaccia utente
  • Difetti delle integrazioni come CA Agile Central (Rally) e dei connettori come Microsoft Project
  • Stack dell'architettura del prodotto (compatibilità) e modifiche della localizzazione
  • Applicazioni personalizzate create utilizzando le API REST
  • Difetti della funzionalità beta (la funzionalità beta non è supportata negli ambienti di produzione)
    In questa categoria di
    esclusione dalle patch
    possono rientrare altre aree.
Per le release GA e GA-1, verranno valutate le correzioni lato client incluse nelle patch una volta ogni trimestre. Vengono applicati i criteri di correzione standard di rischio e complessità.
SaaS
Quando si richiede l'applicazione di una patch per qualsiasi istanza all'interno dell'ambiente SaaS, verrà applicato il livello di patch più recente per la release in questione.
Frequenza
Le patch vengono rilasciate in un breve intervallo con test più limitati rispetto ai test eseguiti per le release. Le patch generate per le versioni GA e GA-1 vengono rilasciate grossomodo a mesi alterni (ad esempio, GA a gennaio, GA-1 a febbraio, GA a marzo e così via) per fornire una risoluzione rapida a problemi critici.
Qualità
Le patch sono destinate a risolvere uno o più problemi specifici e includono correzioni raggruppate dalle patch precedenti (le patch sono cumulative). Tutte le patch vengono sottoposte a test di QA, ma i test sono limitati solo a:
  • Verifica della correzione specifica risolta nella patch
  • Copertura dei test di regressione e integrazione limitata all'area di prodotto interessata
Non vengono eseguiti test di regressione e prestazioni completi su ciascuna patch. Poiché le patch sono cumulative, quando i contenuti sono sufficienti per garantire il testing completo di regressione e prestazioni oppure in caso di un difetto specifico che richiede test speciali, verranno eseguiti i test appropriati. La convalida QA estesa include i test di regressione, delle prestazioni e PAS selettivi necessari. Nel file LEGGIMI della patch vengono annotate tutte le patch testate a livello di regressione e prestazioni.
I clienti devono essere consapevoli che una patch software potrebbe avere conseguenze indesiderate in termini di prestazioni o funzionamento software nel proprio ambiente.
Si consiglia di non applicare le patch software direttamente ai sistemi di produzione, ma di verificarle prima in un ambiente di test che rappresenti quello di produzione in termini di configurazione e volumi di dati.
Difetti del prodotto di terze parti
Per prodotti come Microsoft Project (MSP), vengono eseguiti test avanzati sugli aggiornamenti appena rilasciati ogni due mesi, con l'obiettivo di arrivare a eseguire test mensili. In base all'esito di questi test verrà consigliato o meno l'utilizzo di un determinato livello di aggiornamento con
Clarity PPM
.
Se si riscontra un difetto nell'aggiornamento di MSP che influisce sull'integrazione e sull'esperienza d'uso per i clienti, tale livello di aggiornamento non sarà consigliato né supportato per l'utilizzo con il prodotto PPM rilasciato. Sul sito Web del Supporto tecnico di CA verrà fornito l'elenco aggiornato degli aggiornamenti di MSP supportati.
Per Jaspersoft, le date delle patch possono essere più variabili per diversi fattori, ma in genere è prevista una frequenza trimestrale.
Altre applicazioni CA
Le altre applicazioni CA che interagiscono con
Clarity PPM
, come Mobile Time Manager, rilasciata con
Clarity PPM
13.3, seguono le stesse procedure di ambito e priorità descritte sopra. Le correzioni per questi prodotti possono avvenire lato server o lato client dell'applicazione CA.
  • Se un problema interessa solo la funzionalità lato server, le correzioni verranno fornite nella release principale in fase di sviluppo o in una patch GA o GA-1 di CA PPM. Si potrebbe anche decidere di non risolvere il problema.
  • Se un problema influisce solo sulla funzionalità lato applicazione, la correzione potrebbe essere inclusa nella release principale dell'applicazione in fase di sviluppo in quel momento. Si potrebbe anche decidere di non risolvere il problema.
  • Se un problema interessa sia il server che l'applicazione, le correzioni verranno fornite solo nella release principale. Si potrebbe anche decidere di non risolvere il problema.
Obiettivo del livello di servizio per la correzione dei difetti segnalati dai clienti
Nella prossima release disponibile verranno inclusi anche i difetti risolti nell'ambito di una patch. Nelle Note di rilascio verranno pubblicati i dettagli per una determinata versione, incluse le correzioni a livello di patch. Le modalità con cui vengono fornite le correzioni variano in base alla gravità:
  • S1
    : patch
  • S2
    : patch o release di prodotto
  • S3
    : release di prodotto futura o chiusura
  • S4
    : eventuale release di prodotto futura o chiusura