Política de resolução de defeitos relatados pelo cliente

ccppmop1571
HID_release_info_resolution_policy
Política do Clarity PPM do BlueOfficial
20190125-POLICY.png
Essa política de resolução de defeitos padrão se aplica a todas as releases ativas do Clarity PPM (anteriormente denominadas CA PPM), incluindo edições locais, edições sob demanda ou SaaS, além de aplicativos secundários, como o CA Open Workbench e o CA Mobile Time Manager.
Este documento fornece uma política de resolução padrão para defeitos relatados pelo cliente. As resoluções são feitas por ordem, atribuindo-se uma gravidade e prioridade relativas a cada defeito. Este documento descreve os critérios para a atribuição de gravidade, os métodos de entrega de correções e os SLOs (Service Level Objectives - Objetivos de Nível de Serviço).
2
Critérios usados para atribuir gravidade técnica a defeitos
Depois que o suporte da CA verifica um problema, ele é encaminhado à equipe de desenvolvimento de software do Clarity PPM para determinar se o comportamento é um defeito do produto. Se o problema for determinado como um defeito no produto, ele será atribuído a uma gravidade técnica e revisado para determinar se e quando uma correção será entregue. Se um defeito for resolvido, a correção é fornecida em um pacote definido de acordo com o nível de gravidade técnica e a complexidade. Os níveis de gravidade técnica são definidos da seguinte maneira:
S1: crítico
Um defeito de gravidade 1 (S1) refere-se a um travamento do sistema, vazamento de memória considerável, corrompimento ou perda de dados irrecuperáveis, deficiência funcional grave sem solução alternativa, falha na instalação ou atualização de aplicativos, prevenção de testes de recursos adicionais na mesma área ou itens considerados ofensivos no software, na interface do usuário ou na documentação.
S2: alto
Um defeito de gravidade 2 (S2) refere-se a uma deficiência funcional grave, corrompimento ou perda de dados recuperáveis, documentação ou mensagens de erro que podem fazer com que os usuários executem ações incorretas, uma significativa degradação do desempenho, problema na localização ou globalização que torne os recursos inutilizáveis por aqueles que não são falantes do inglês e vulnerabilidades de segurança de aplicativos web pelas quais os hackers podem explorar dados do aplicativo. Problemas de gravidade 2 podem ou não ter uma solução alternativa.
S3: médio
Um defeito de gravidade 3 (S3) diz respeito a deficiências em recursos com uma solução alternativa razoável, pequenos erros na documentação, usabilidade ou problemas de acessibilidade, provocando inconveniência secundária, degradação do desempenho insignificante, desinstalação incompleta/incorreta do aplicativo ou mensagens de erro incorretas.
S4: baixo
Um defeito de gravidade 4 (S4) refere-se a um problema que não afeta o uso diário do aplicativo, como pequenos erros superficiais e de baixa visibilidade ou inconsistências.
Métodos de entrega padrão para resolução de defeitos
O método de entrega para um defeito resolvido depende de sua gravidade técnica e da viabilidade de uma correção. Isso é determinado com base na complexidade, no risco e na gravidade técnica. Três métodos estão disponíveis para a entrega de correções para defeitos relatados pelo cliente. A correção para um defeito resolvido é fornecida:
  • na próxima release;
  • no próximo service pack;
  • ou no próximo patch de manutenção (no caso de problemas graves).
Em alguns casos, um defeito não pode ser resolvido fora de uma release.
Em geral, os aprimoramentos do produto não são entregues em patches e, em vez disso, são reservados para releases e service packs.
Releases do produto
A qualidade é importante para nós. Em geral, as releases do produto são geradas a cada 6 (seis) meses e é dada ênfase na resolução de defeitos relatados pelo cliente como parte dessas releases. Nosso principal mecanismo de entrega para defeitos relatados pelo cliente é pelo ciclo de da release do produto.
As releases do produto incluem aprimoramentos e recursos destacados, além de correções de defeitos relatados pelo cliente. Ao fornecer correções juntamente com esses aprimoramentos, garantimos o fornecimento de um produto bem testado e de alta qualidade para nossos clientes.
Durante o ciclo de lançamento de um produto, o foco específico é fornecido a problemas S2 e S3 de
alto impacto
. Um defeito S3 de alto impacto afeta vários clientes ou inclui uma solução que pode não ser aproveitada prontamente. A CA fará todo o possível para resolver os defeitos S3 de baixo impacto, mesmo se houver uma solução alternativa disponível. Em alguns casos, com base em uma revisão do defeito e os clientes afetados, pode-se determinar que o defeito não seja corrigido.
A resolução dos defeitos de gravidade baixa (S4) será considerada caso a caso, assim que o problema for confirmado como sendo de fato um defeito. Todos os casos vinculados a falhas S4 serão fechados após a confirmação do problema. Os defeitos S4 serão revisados apenas para releases, e a CA envidará esforços comerciais razoáveis para incorporar as correções a uma determinada release do produto. Com base nos relatórios do cliente, a área da funcionalidade e outras considerações, podemos decidir que um defeito não será corrigido. Nesse caso, o cliente será notificado pelo nosso processo de suporte padrão ou pelo site da comunidade online do CA PPM.
Service packs
Como parte de nossos esforços para melhorar continuamente o CA PPM, os service packs serão lançados aproximadamente três meses após uma grande release do produto. Os service packs, em geral, incluem aprimoramentos da funcionalidade existente e correções para os defeitos relatados. Os service packs seguem a mesma metodologia no que se refere à inclusão de correções de defeitos nas releases do produto.
Releases de patch
Os patches abordam um conjunto específico de problemas críticos que afetam nossos clientes e não podem aguardar tecnicamente para serem corrigidos na próxima release.
Escopo
Se um problema for crítico (S1 ou S2 de alto impacto), podemos considerar a entrega de uma correção em um patch.
Corrigiremos os problemas apenas pelo mecanismo de patches das versões GA e GA-1, aproximadamente a cada dois meses (por exemplo, GA em Janeiro, GA-1 em fevereiro, GA em março, e assim por diante). Essa política nos permite concentrar nossos esforços na produção de patches de melhor qualidade, a fim de ajudar a garantir que as implementações dos clientes sejam bem-sucedidas.
As correções fornecidas em patches serão incluídas na release do produto que estiver em desenvolvimento no momento (que não seja GA/próxima release X.X.0 ou service pack X.X.1). As releases que não são GA têm, como parte do ciclo de vida, uma data de congelamento do código. Se um patch for lançado após a data de congelamento do código para a versão em desenvolvimento no momento, essas correções serão incluídas no primeiro patch programado imediatamente depois que a nova versão se tornar GA. Por exemplo, o patch 15.7.1.1 incluiria as resoluções de defeito entregues após a data de congelamento do código para a release 15.7.1 do produto.
Alinhadas às nossas políticas de EOS (End of Service - Descontinuação do Serviço) e EOL (End of Life - Fim da Vida Útil), as correções não serão geradas depois de ser anunciado o status EOL para uma versão específica do produto.
Exclusões
Algumas correções que, de outra forma, atendem aos critérios de resolução por patch talvez não sejam viáveis para serem entregues dessa forma devido à complexidade, ao risco e ao impacto sobre outros clientes. Além disso, os defeitos nas áreas abaixo não são candidatos a um patch e estão reservados somente a releases ou service packs:
  • Defeitos que exigem uma mudança de esquema
  • Atualizações em aplicativos cliente, como o OWB, o MSP ou o Mobile Time Manager
  • Defeitos que exigem uma grande alteração na interface do usuário
  • Defeitos em integrações, como o Rally (antes conhecido como CA Agile Central), e em conectores, como o Microsoft Project
  • Alterações na pilha da arquitetura do produto (compatibilidades) e na localização
  • Aplicativos personalizados criados com o uso de nossas APIs REST
  • Defeitos na funcionalidade beta (a funcionalidade beta não é suportada em ambientes de produção)
    Outras áreas também podem se enquadrar na categoria
    sem patch
    .
Para as releases GA e GA-1, avaliaremos quais correções no lado do cliente serão incluídas nos patches uma vez por trimestre. Os critérios de correção padrão do risco e da complexidade são aplicados.
SaaS
Ao solicitar um aplicativo de patch a qualquer instância no SaaS, será aplicado o nível de patch mais recente para essa release.
Regularidade
Os patches são liberados a um curto intervalo com testes mais limitados do que os testes realizados para uma release. Os patches produzidos para as versões GA e GA-1 são lançados aproximadamente a cada dois meses (por exemplo, GA em janeiro, GA-1 em fevereiro, GA em março, e assim por diante) para fornecer uma resolução rápida para problemas críticos.
Qualidade
Os patches destinam-se a resolver um ou mais problemas específicos e incluirão correções acumuladas de patches anteriores (os patches são cumulativos). Todos os patches passam pelo teste de QA, mas o escopo do teste é limitado apenas ao seguinte:
  • Verificação da correção específica resolvida no patch
  • Cobertura de teste de regressão e integração limitada apenas às áreas afetadas do produto
Não executamos testes de regressão e desempenho completos em cada patch. Como os patches são cumulativos, quando há conteúdo suficiente para garantir testes completos de regressão e desempenho, ou se houver um defeito específico que garanta a execução de testes especiais, faremos tais testes conforme apropriado. A validação de QA estendida inclui testes de regressão, testes de desempenho e testes de PAS seletivo, conforme necessário. Qualquer patch que tenha sido testado quanto ao desempenho e à regressão terá as observações associadas anotadas no arquivo LEIAME do patch.
Os clientes devem estar cientes de que um patch pode ter consequências inesperadas em relação ao desempenho ou à funcionalidade do software no ambiente do cliente.
Os clientes não devem aplicar os patches diretamente nos sistemas de produção sem primeiro testá-los em um ambiente de teste, o que representa o sistema de produção em termos de configuração e volumes de dados.
Defeitos em produtos de terceiros
Para produtos como o MSP (Microsoft Project), executamos testes genéricos em atualizações recém-lançadas uma vez a cada dois meses, com uma meta de esforço melhor para testar mensalmente. Com base no resultado desses testes, é possível que um determinado nível de atualização seja aplicado para uso com o
Clarity PPM
.
Se encontrarmos um defeito na atualização do MSP que afete nossa integração e não forneça uma experiência de qualidade para nossos clientes, não iremos recomendar nem oferecer suporte a esse nível de atualização para uso com o produto PPM lançado. Forneceremos uma lista atualizada de atualizações suportadas do MSP no site de suporte da CA.
Para o JasperSoft, as datas do patch estão mais sujeitas à variação devido a vários fatores, no entanto, geralmente planejamos uma regularidade trimestral.
Outros aplicativos da CA
Outros aplicativos da CA que funcionam com o
Clarity PPM
, como o Mobile Time Manager, lançado inicialmente com o
Clarity PPM
13.3, ou o
Clarity PPM
Mobile 3.0, lançado inicialmente
Clarity PPM
15.5, seguem os mesmos procedimentos descritos anteriormente quanto ao escopo e à prioridade. Correções para esses produtos podem ocorrer no lado do servidor ou do cliente do aplicativo da CA da funcionalidade em questão.
  • Se um problema afetar somente a funcionalidade do servidor, qualquer correção fornecida será entregue na release principal em desenvolvimento ou em um patch GA ou GA-1 do CA PPM. Também pode ser decidido que o problema não será corrigido.
  • Se um problema afetar somente a funcionalidade no lado do aplicativo, a correção pode ser incluída na release principal do aplicativo em desenvolvimento no momento. Também pode ser decidido que o problema não será corrigido.
  • Se um problema afetar tanto o servidor quanto o aplicativo, qualquer correção específica seria entregue somente na release principal. Também pode ser decidido que o problema não será corrigido.
Objetivo de nível de serviço para a entrega de defeitos relatados pelo cliente
Os defeitos corrigidos como parte de um patch também serão incluídos na próxima release disponível. Os detalhes serão publicados como parte das notas da versão de uma determinada versão, incluindo as correções em nível de patch incluídas. O método de entrega varia de acordo com a gravidade:
  • S1
    : patch
  • S2
    : patch ou release do produto
  • S3
    : futura release do produto ou encerrado
  • S4
    : possível futura release do produto ou encerrado