O sistema entregue serve ao que foi contratado? A perícia responde lendo o repositório, o banco de dados e o ambiente de testes, com evidência datada.
Num projeto de software que deu errado, o contratante diz que o sistema não funciona. O fornecedor diz que entregou e que o atraso veio de mudanças pedidas pelo cliente. O juiz ou o árbitro precisa de outra coisa: o que foi feito, quando, e por que falhou.
Essa resposta está nos registros do próprio projeto. O repositório de código guarda cada alteração (cada commit) com data e autor. O banco de dados mostra o que o sistema gravou. O sistema de chamados mostra quem pediu o quê. O ambiente de homologação mostra o que estava pronto para teste.
A perícia em software preserva esses registros antes de qualquer análise, com hash e cadeia de custódia, e reconstrói o projeto a partir deles. Esta página trata do exame do software em si. A visão geral de contratos de TI e de implantações de ERP está em Segurança da Informação e Compliance. A escolha entre processo judicial, arbitragem e mediação está em Arbitragem e Mediação em TI.
"Não funciona" precisa virar fato: qual funcionalidade, em qual ambiente, com qual dado e com que resultado. A perícia executa os fluxos em disputa e mede o comportamento contra o que foi especificado. As características de qualidade da ISO/IEC 25010, como adequação funcional, confiabilidade e eficiência de desempenho, dão às duas partes um vocabulário comum.
Quem atrasou? A linha do tempo cruza commits, versões publicadas, chamados, aprovações e pedidos de mudança. Ela separa o atraso de desenvolvimento do atraso causado por dependências do contratante, como acesso, dados e aprovações, e das mudanças de escopo que entraram sem aditivo.
O que estava pronto na data da rescisão? A perícia compara o código dos repositórios com a versão em homologação até aquela data. Separa o que estava entregue, o que estava em desenvolvimento e o que nunca começou.
O fornecedor reaproveitou código de outro cliente, ou o sistema novo copia o antigo? A perícia compara as bases de código, identifica a origem de cada componente e mostra quem escreveu cada parte. O tema tem página própria em Propriedade Intelectual, Segredo de Negócio e Concorrência Desleal.
Chega uma notificação de contrafação ou uma auditoria de licenciamento movida pelo fabricante. A perícia preliminar de licenciamento levanta, com imagem forense dos equipamentos, o que está instalado e o que está licenciado, antes de a empresa responder. Na ação, a atuação é na defesa da empresa auditada ou, em outros processos, como perito nomeado em ações movidas por fabricantes.
Quando uma falha em produção gera multa, a pergunta é de onde ela veio: defeito do código, configuração do ambiente, mudança mal gerida ou incidente de segurança. Logs do banco de dados, registros da gestão de mudanças e o processo de testes, que tem referência na ISO/IEC/IEEE 29119, mostram a causa e quem respondia por ela. Muitas falhas não são incidente cibernético. São falha de processo.
01 · Preservação. Cópia dos repositórios com o histórico completo, do banco de dados e dos ambientes, com hash. Nada é examinado no ambiente em uso.
02 · Linha do tempo. Commits, versões, chamados, atas e e-mails ordenados numa única cronologia.
03 · Confronto. O que o contrato, a proposta e os requisitos pediam, contra o que o código e o sistema fazem.
04 · Testes. Quem testou, o que testou e com que resultado. Os testes de cada parte são medidos separadamente.
05 · Ambiente espelho. Quando o ambiente original mudou ou não está disponível, a perícia monta um ambiente equivalente para reproduzir as falhas e testar hipóteses concorrentes.
06 · Laudo. Achados, hipóteses testadas, limites declarados e anexos que as duas partes conseguem verificar.
Preço e prazo de software se discutem melhor com uma medida. A análise de pontos de função mede o tamanho funcional do sistema pelo que ele faz para o usuário, sem depender da linguagem ou da tecnologia. É um método padronizado internacionalmente (ISO/IEC 20926) e amplamente usado nas contratações de software do governo federal, segundo o Roteiro de Métricas de Software do SISP, o sistema que reúne os órgãos de TI da administração federal.
Na perícia, a contagem serve para comparar o tamanho do que foi contratado com o do que foi entregue, ou para avaliar se um preço tem base técnica. Já foi aplicada, por exemplo, para um cliente que precisava justificar numa licitação o valor que cobrava e mostrar por que ele se diferenciava do de outros participantes (caso descrito em Licitações, Contratos Públicos e Infraestrutura).
Um contrato de desenvolvimento foi rescindido com as partes em desacordo sobre o que tinha sido entregue e sobre a causa das falhas do sistema.
Os repositórios do projeto foram preservados com o histórico completo, e os commits foram comparados com a versão de homologação até a data da rescisão. A perícia reconstruiu um ambiente espelho e examinou a hipótese de que as falhas vinham do proxy (o servidor intermediário) da rede corporativa, e não do código.
O laudo delimitou, em evidência datada, o que estava pronto na rescisão e de onde vinham as falhas.
Uma empresa contrata o desenvolvimento de um aplicativo com prazo de seis meses. Nove meses depois, ele ainda não está em produção. O fornecedor diz que o cliente mudou o escopo e demorou a liberar o acesso aos sistemas. O cliente diz que o código chegava com erro.
A perícia monta uma linha do tempo com os commits, os chamados e os e-mails de aprovação. Ela mostra quantas funcionalidades entraram depois da assinatura, quanto tempo cada pedido de acesso ficou parado e quantas entregas voltaram da homologação com defeito.
Com essa cronologia, o atraso deixa de ser versão contra versão. Cada parte vê a parcela que lhe cabe, e a negociação, a arbitragem ou o processo partem de fatos.
Consulte também
Arbitragem e Mediação em TI → Segurança da Informação e Compliance → Propriedade Intelectual, Segredo de Negócio e Concorrência Desleal → Perícia Judicial e Extrajudicial → Licitações, Contratos Públicos e Infraestrutura → Direito Digital e Tecnologia →
Antes de decidir, vale ver o que já passou por este laboratório: casos descritos sem identificar as partes, no formato desafio, método e resultado.
O canal de controle do invasor estava gravado em contratos inteligentes. A perícia decodificou o que ele havia apagado e entregou às autoridades os caminhos de identificação.
Ver o caso Prova negativaA perícia oficial havia concluído pela participação. O reexame demonstrou que os vínculos eram falsos positivos, e a pessoa acusada foi inocentada.
Ver o caso