Desenvolvimento

Ξ Deixe um comentário

Qualidade em TI – Aprendendo com as falhas

publicado por Paul Robert Bergami

Qualidade em TI – Aprendendo com as falhasEm nosso último texto falamos do processo de Prevenção de Falhas, de seus compromissos, dos envolvidos e dos passos a serem seguidos.

Agora vamos falar sobre a implantação deste processo e, para começar, precisamos de uma base. Por exemplo, de uma lista de falhas que possam ser priorizadas e assim atacadas.

Nunca podemos esquecer da definição de Qualidade em TI:  Qualidade em TI só é percebida pelo cliente, ou usuário final, como um produto ou serviço, que faz o que deve ser feito, explícita e implicitamente, e é entregue no prazo e ao custo combinado.

Significa que precisamos medir se o produto ou serviço faz o que deve ser feito e se é entregue ao custo e prazo combinado.

De saída temos aí alguns indicadores:

  • Fazer o que deve ser feito significa não apresentar falhas – é indicador de eficácia;
  • Entregue no prazo significa que foram combinados anteriormente datas e horas, ou mesmo tempos de resposta para a entrega do produto ou serviço – é outro indicador de eficácia; e,
  • Entregue no custo significa que há uma expectativa de gasto para a obtenção do produto ou serviço – é indicador de eficiência.

Medir antes de aplicar qualquer ação e assim obter a base de comparação em relação aos resultados destas.

Caso a organização já possua um processo de atendimento a ocorrências, do tipo Help Desk, ao qual os usuários ou clientes recorrem quando têm algum problema. Este processo faz o registo de ocorrências, formando uma base de dados de incidentes e problemas, que serão analisados e solucionados pelo suporte e/ou desenvolvimento.

Este registro com a lista de falhas, ou incidentes, é a base ao processo de Prevenção de Falhas.

A lista deve ser analisada de forma pragmática, classificando as falhas por tipo, origem, geografia, impacto em negócio ou serviço, urgência, etc. As informações devem ser consolidadas e a análise, em conjunto com as áreas de engenharia de software, devem indicar as ações de melhorias e controles a serem aplicados.

Para garantir que, uma vez identificadas e endereçadas, as falhas em software não voltem a ocorrer, as ações aplicadas e o conhecimento adquirido neste processo devem ser traduzidos em lições aprendidas.

Como fazer isso?

Transformamos as causas que provocaram incidentes e problemas em itens de verificação aos demais processos do ciclo de vida de software:

  • para a Elicitação de Requisitos – implica em um checklist mais completo quando da validação dos levantamentos de requisitos de usuários;
  • para os Requisitos Funcionais e Não Funcionais – implica em melhoria nas especificações funcionais e técnicas do software em definição e desenvolvimento;
  • para as Condições de Testes – implica em incremento dos testes com condições que anteriormente não eram verificadas;
  • para o processo de Homologação – implica em maior garantia de qualidade antes da decisão de implementação do software em produção;
  • para o processo de verificação da Conversão – implica em ampliação das condições de distribuição de software;
  • e, também em argumentos de pesquisa ao Código Legado – implica em permitir a varredura do código legado em busca destes defeitos e, assim, prevenir falhas provenientes deste tipo de causa.

Desta forma, condições que antes não eram previstas, passam a enriquecer todo o processo de desenvolvimento, manutenção e implantação de software. Incrementar a garantia através de itens que anteriormente não eram verificados.

Esta tradução deve ser cuidadosa, por exemplo, incluir a análise de tendências, que permita a um passo além, uma visão de futuro. É a fase preditiva do processo de Prevenção de Falhas, sem a qual, a organização não aprende com seus próprios erros.

Seguindo com a orientação que definimos para as ações, começando de trás para frente, no próximo texto vamos falar de: Qualidade em TI – As falhas na implantação.

[Crédito da Imagem: Falhas – ShutterStock]

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Professor de Qualidade de Software, Auditoria de Sistemas e MBA/TI, Economista pela FEA-USP com pós em Qualidade e Produtividade pela POLI-USP, especialista em qualidade de software para usuários e fornecedores de TI. Mais de 30 anos como Gestor em TI para Bancos, Consultorias, Marketing, Serviços e Governo. Focado em soluções pragmáticas de TI que aliam resultado e satisfação de clientes e acionistas, experiência internacional em London/UK no desenvolvimento de aplicativos bancários mundiais e Nova York/USA em consultoria para conformidade à Sarbanes & Oxley. br.linkedin.com/in/bergamipaul/

Paul Robert Bergami

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.