Tags:

A visão da MATERA sobre qualidade de software

A MATERA tem feito, ao longo dos anos, investimentos crescentes em iniciativas para melhorar a qualidade dos seus produtos e serviços. No dia-a-dia, isso se reflete na adoção de práticas de desenvolvimento de software consideradas “best of breed” e no uso de ferramentas que dão suporte a todo o processo.

O nosso “Mapa de Qualidade” é uma representação visual da abordagem que temos para o assunto. Ele deve ser “lido” do centro para as bordas: representada pela letra “Q”, temos a Qualidade como objetivo principal, que será buscada com base em princípios, que determinam a escolha das práticas, por sua vez suportadas por ferramentas. O objetivo do mapa é representar as relações entre todos esses componentes.

A seguir, vamos comentar rapidamente os princípios que norteiam as nossas ações voltadas para a qualidade.

Testes não são uma fase

Na visão mais tradicional (e antiga), a “fase de testes” era a etapa do processo de desenvolvimento onde o software era testado depois de pronto, para verificar sua conformidade com a especificação. Essa visão está superada, na medida em que temos uma filosofia de testes dando suporte a todas as etapas do processo de desenvolvimento, desde o levantamento dos requisitos até a entrega final. Dentro desse conceito, entendemos como “testes” todas as atividades realizadas para atestar que todos os produtos do processo, sejam intermediários ou final, foram produzidos com qualidade; isso serve não só para programas como também para especificações, protótipos, roteiros de implantação etc.

 

Feedback mais rápido

À medida que uma equipe produz software, algumas atividades podem ser realizadas para verificar a qualidade do software produzido; dentre tais atividades, podemos citar a revisão de código, checagem automática por ferramentas e outras, mas principalmente a execução do software entregue para verificar os resultados obtidos. Então tais resultados são passados para a equipe que desenvolveu o software, para corrigir eventuais problemas. Esse processo é chamado ciclo de feedback, medindo o tempo entre a produção do software e o feedback para o desenvolvedor. Quanto mais curto for esse ciclo, melhor: os erros são detectados mais precocemente e o impacto desses erros é minorado.

 

Pronto é pronto

Qualquer item produzido no processo de software só pode ser considerado pronto quando estiver 100% liberado para a próxima etapa e não existe mais absolutamente nenhum trabalho a ser feito sobre esse item. Ou seja: uma especificação só está pronta quando tiver sido aprovada pelo usuário; um componente de software (tela, relatório ou processo) só está pronto depois de ter passado nos testes; e um sistema só está pronto quando todas as verificações internas quanto à sua qualidade já foram cumpridas e ele pode ser instalado no ambiente do cliente. Um requisito fundamental para a definição de “pronto” é o critério de aceite: quais as condições a serem avaliadas para determinar, sem margem de dúvida, se algo está realmente pronto.

 

Ferramentas integradas

As atividades do processo de desenvolvimento devem ser apoiadas por um conjunto consistente e integrado de ferramentas, que facilitem o encaixe das atividades (em termos de entradas e saídas) e sejam utilizadas pelo time para ajudar cada um no desempenho das suas tarefas. Essas ferramentas devem ser selecionadas, implantadas e configuradas de acordo com a sua capacidade de alavancar a produtividade da equipe e a qualidade do produto final. Uma infraestrutura integrada pode assim trazer benefícios como facilitar a comunicação dentro da equipe, automatizar tarefas repetitivas, oferecer acesso facilitado às informações do projeto, dentre outros.

 

Todos são responsáveis

A Qualidade de um produto não é algo a ser obtido apenas por um time de testes ou de garantia da qualidade: é algo que deve ser construído por toda a equipe no decorrer de todo o projeto. Deve ser um compromisso de todo o time com as regras estipuladas dentro do projeto, cujo cumprimento é responsabilidade compartilhada por todos os membros da equipe, independente do papel de cada um. Como exemplos dessas responsabilidades podemos citar: garantir a aplicação integral das práticas de desenvolvimento; recusar os itens que não estejam de acordo com os critérios de aceite; cumprir os prazos e demais condições de entrega.

 

Por MATERA SYSTEMS

Postado em: 29 de março de 2012

Confira outros artigos do nosso blog

Nova diretoria de Inovação e Negócios da MATERA busca parcerias

20 de abril de 2017

Vania Hoshii

Páscoa Feliz 2017

18 de abril de 2017

Tamiris Fernanda Cella

Hackathon Internet Banking: UI/UX + APIs

15 de março de 2017

Pedro Farci

Three laws that enable agile software development

09 de março de 2017

Celso Gonçalves Junior

Deixe seu comentário