Em 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]