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

ccppmop159
HID_release_info_resolution_policy
A política de resolução de defeitos da Broadcom se aplica a todas as releases ativamente suportadas do Clarity, incluindo edições locais ou SaaS, além de aplicativos secundários, como o CA Open Workbench e o CA Mobile.
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 atribuição de gravidade, métodos de entrega de correções e 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 Broadcom verifica um problema, ele é encaminhado à equipe de desenvolvimento de software do Clarity, que determina se o comportamento é um defeito do produto. Se o problema for apontado como um defeito no produto, ele receberá uma gravidade técnica e será revisado para determinação de quando e se receberá uma correção. Se um defeito deve ser resolvido, a correção será 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. Uma 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, 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 doze (12) 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 recursos de letreiro, aprimoramentos e correções de defeitos relatados pelo cliente. Ao fornecer correções 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 Broadcom 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 Broadcom empregará 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.
Service packs
Como parte do nosso esforço para melhorar continuamente a experiência do cliente, os service packs serão lançados trimestralmente até a próxima release principal do produto. Os service packs, em geral, incluem novos recursos, aprimoramentos das funcionalidades existentes e correções para os defeitos relatados pelo cliente. Os service packs seguem a mesma metodologia para incluir defeitos como releases de 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 entregues 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.
A Broadcom apenas corrigirá ativamente os problemas e fornecerá correções por meio de patches para GA e versões mais recentes do service pack para GA-1. Por exemplo, com a release do
15.9.0
, corrigiremos apenas a release 15.8.1, que é o Service Pack mais recente que representa o GA-1. Da mesma forma, com o futuro lançamento da release 16.0.0, corrigiremos apenas a release 15.9.3, o que constituirá o GA-1. Essa política nos permite concentrar nossos esforços na produção de patches de melhor qualidade, a fim de garantir que as implementações dos clientes sejam bem-sucedidas.
As correções fornecidas em patches são incluídas automaticamente em Service Packs e/ou nas principais releases de 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 a seguir não são candidatos a um patch e estão reservados para releases ou service packs.
  • Defeitos que exigem uma mudança de esquema
  • Atualizações para aplicativos cliente, como OWB, MSP ou Clarity Mobile Application (CA PPM)
  • 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
As correções para os defeitos relatados pelo cliente podem ser fornecidas por meio de atualizações para as principais releases e service packs do produto de acordo com a programação de atualização de SaaS publicada aqui.
Regularidade
A Broadcom determina o intervalo de liberação do patch.
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
A Broadcom não realiza testes de regressão e desempenho completos em cada patch. Os patches são cumulativos. No entanto, se houver 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 testes adicionais 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 de software diretamente nos sistemas de produção sem primeiro verificá-los em um ambiente de teste que represente 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 a meta de testar mensalmente. Com base nos resultados desses testes, podemos ou não recomendar que um determinado nível de atualização seja aplicado para uso com o aplicativo.
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 recomendaremos nem ofereceremos suporte a esse nível de atualização para uso com o produto lançado. Forneceremos uma lista atualizada de atualizações suportadas do MSP no site de suporte da Broadcom.
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.
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 no próximo service pack ou release disponível. Os detalhes serão publicados como parte das notas da versão de uma determinada versão, incluindo as correções no 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