Três coisas que você deveria exigir do seu prestador de serviços de TI

(Openclippart.org - liftarn)

Você paga um bom dinheiro para o seu Prestador de serviços de TI, certo? Então, tem direito de exigir pelo menos três coisas dele, por exemplo, provas de que o software desenvolvido funciona a contento. É a mesma coisa que você faz quando compra um Gadget eletrônico: pede ao vendedor que o teste. Vamos ver quais são essas três coisas, que sempre fazem os Consultores "fecharem a cara" imediatamente.

O custo do desenvolvimento de um software é muito alto. As empresas prestadoras de serviços não sabem fazer "Contabilidade Gerencial", logo, embutem mais custos na sua fatura, do que "enchimento de linguiça". Você acaba pagando até pelo cafezinho que é servido aos Desenvolvedores. 

Então, você tem todo direito de exigir três coisas do seu "Consultor": 

1 - Que ele entregue TODO o código fonte

O Código fonte é seu. A não ser que você esteja usando algum tipo de SaaS, você pagou pelo código fonte, incluindo o código de teste, logo, você tem que receber tudo isso, e tem que ter provas de que o "executável" foi criado a partir do código fonte que você recebeu. 

Não é difícil para o Prestador cumprir essa exigência. Coisas simples, como assinar automaticamente o código fonte, de preferência no processo de Integração Contínua que gerou o executável, podem ser feitas e podem garantir que você está recebendo o código fonte correto. Mas não bastam os arquivos que implementam as funções... É necessário que você receba TUDO, incluindo: 

• Código funcional;
• Páginas HTML;
• Arquivos de Help;
• Build scripts;
• Configuração do ambiente, de preferência incluindo o provisionamento;
• Log do último build, que gerou o pacote final;
• Maven site;
• Código de teste.

Ele não vai gostar nada disso... Mas então, eu te pergunto: Como você pode ficar seguro que tem a última versão do código fonte? Como pode ter certeza de que vai conseguir recompilar o Projeto? Essa é a única maneira!

2 - Que ele lhe entregue um código fonte de qualidade

Certamente, seu Prestador de serviços vai alegar que emprega um processo de software que garante a qualidade. Mais provavelmente, vai dizer que usa um "Método ágil", e talvez até lhe mostre um "Kanban" (Deus, como eu ODEIO KANBAN!) Mas será que isso é prova de qualidade? 

Seguir um processo é condição necessária, mas não suficiente para garantir a qualidade do software. É necessário provar que o software tem qualidade, e isso pode ser feito através de uma análise de Dívida técnica. Você pode incluir algumas métricas de qualidade, e pedir para ter acesso às métricas durante o desenvolvimento. Várias ferramentas, como o SonarQube, permitem traçar um quadro evolutivo, através do qual você pode acompanhar, em tempo real, como anda a qualidade do software.

Alguns exemplos do que você pode pedir e que, certamente, fará seu Prestador "subir pelas paredes": 

• Complexidade ciclomática por método e por classe máxima de 5;
• Cobertura de testes por classe mínima de 80%;
• Nenhuma classe com LCOM4 > 1;
• RFC das classes menor que 50;
• Pacotes com Distância da Sequência Principal máxima de 30%;
• Aderência às regras PMD, Checkstyle e Findbugs mínima de 80% do código entregue.

3 - Exigir provas de que tudo o que foi pedido foi feito e devidamente testado

Como você pode saber se TODOS os seus requisitos foram incluídos no que está sendo entregue? Se o seu Prestador usa algum tipo de processo SÉRIO (e não um Kanban), então ele negociou com você o que vai entrar em cada "release" do software, certo? E ele deve ter alguma ferramenta que permita rastrear os requisitos até o código fonte. É seu direito e dever exigir isso, essa prova! Várias ferramentas implementam rastreabilidade, incluindo algumas ferramentas livres. Mas isso tem que ser combinado com o Prestador ANTES de assinar o contrato!

Além de provar que tudo o que foi pedido e combinado está sendo entregue, é necessário provar que foi devidamente TESTADO. 

A única prova de que um software foi testado é a presença de casos de teste IDEMPOTENTES E AUTOMATIZADOS junto com o "build script". Estes casos podem ser verificados com ferramentas livres, ou seja, podemos rodar o "build" e analisar a real cobertura de testes do código fonte entregue. 

Testes de aceitação manuais, geralmente conduzidos pelos desenvolvedores, são "historinhas para boi dormir"! Coisa de amadores!

É claro que você também pode exigir que os testes FUNCIONAIS sejam automatizados. Seu Prestador certamente conhece várias ferramentas, como: FEST ou SELENIUM, que permitem automatizar este tipo de teste. 

Conclusão

Se você exigir essas três coisas, fazendo-as constar no Contrato, terá um software com qualidade, ou, pelo menos, saberá dos problemas. Sem isso, você estará apenas jogando dinheiro no lixo! E, caso seja um Prestador de serviços de TI, é hora de mudar! Se você começar a vender essas três coisas para os seus Clientes, certamente terá uma vantagem competitiva sobre os outros, que ainda vendem sistemas Clipper como se fossem coisa do outro mundo!