Desempenho, Defeitos e Aderência Funcional: Avaliação Forense de Sistemas Corporativos

Propósito do artigo

A avaliação forense de sistemas corporativos busca examinar, de forma técnica e documentada, se determinado software apresenta desempenho compatível com sua finalidade, se os defeitos alegados são tecnicamente demonstráveis e se as funcionalidades entregues correspondem aos requisitos, contratos, expectativas documentadas ou critérios de uso aplicáveis.

Em disputas B2B, esse tipo de análise é frequente em controvérsias envolvendo ERPs, CRMs, sistemas financeiros, plataformas acadêmicas, sistemas de gestão documental, aplicações web, soluções SaaS, integrações por API, sistemas de automação, ferramentas de BI e aplicações desenvolvidas sob encomenda.

A controvérsia raramente se limita à afirmação de que “o sistema não funciona”. Em geral, é necessário compreender o que se entende por funcionamento adequado, quais requisitos eram aplicáveis, quais defeitos foram identificados, quais evidências os demonstram, qual o impacto operacional e se há nexo técnico entre a falha apontada e o dano alegado.

1. Três dimensões da avaliação técnica

A avaliação forense de sistemas corporativos pode ser organizada em três dimensões principais: desempenho, defeitos e aderência funcional.

1.1 Desempenho

O desempenho refere-se à capacidade do sistema de operar com tempos de resposta, disponibilidade, estabilidade, escalabilidade e consumo de recursos compatíveis com o uso esperado.

A análise pode envolver:

• tempo de carregamento de telas;
• tempo de execução de consultas;
• processamento de relatórios;
• volume de transações;
• estabilidade sob carga;
• disponibilidade;
• consumo de CPU, memória, rede ou banco de dados;
• comportamento em horários de pico;
• latência em integrações;
• degradação progressiva;
• erros por timeout;
• filas de processamento;
• capacidade de atender múltiplos usuários simultâneos.

O ponto central não é apenas medir se o sistema está “rápido” ou “lento”, mas verificar se o desempenho observado é compatível com os requisitos, com o ambiente contratado, com a arquitetura adotada e com as condições reais de operação.

1.2 Defeitos

Defeitos são comportamentos incompatíveis com o funcionamento esperado do sistema. Podem decorrer de erro de código, configuração inadequada, parametrização incorreta, falha de integração, inconsistência de dados, limitação de infraestrutura, uso inadequado ou requisito mal especificado.

A análise de defeitos busca responder:

• o problema é reproduzível?
• em que condições ocorre?
• qual mensagem de erro é registrada?
• quais usuários ou perfis são afetados?
• quais módulos estão envolvidos?
• há logs ou tickets relacionados?
• o defeito surgiu após atualização, configuração ou mudança de ambiente?
• há relação com dados específicos?
• a falha é sistêmica ou pontual?
• o comportamento viola requisito documentado?

A existência de reclamações de usuários não basta, por si só, para caracterizar defeito técnico. É necessário examinar evidências, contexto e condições de reprodução.

1.3 Aderência funcional

A aderência funcional consiste na comparação entre o que o sistema entrega e o que deveria entregar segundo requisitos, contrato, documentação, processos de negócio, especificações ou critérios de aceite.

A análise pode verificar:

• funcionalidades previstas e entregues;
• funcionalidades ausentes;
• funcionalidades parciais;
• funcionalidades entregues com comportamento divergente;
• regras de negócio implementadas;
• fluxos de aprovação;
• permissões;
• relatórios;
• integrações;
• cadastros;
• validações;
• cálculos;
• parametrizações;
• restrições operacionais.

A aderência funcional deve ser examinada com base em evidências documentais e técnicas, e não apenas em expectativas posteriores das partes.

2. Critérios para uma avaliação tecnicamente defensável

Uma avaliação forense de sistema corporativo deve adotar critérios claros. Sem critérios, a análise tende a se transformar em opinião subjetiva.

2.1 Critério contratual

Verifica-se o que foi contratado, incluindo proposta, anexos técnicos, escopo, requisitos, níveis de serviço, limites de uso, responsabilidades e critérios de aceite.

2.2 Critério funcional

Examina-se se o sistema realiza as funções necessárias para os processos de negócio documentados ou acordados entre as partes.

2.3 Critério técnico

Considera-se arquitetura, infraestrutura, banco de dados, código, configurações, integrações, logs, desempenho e condições de operação.

2.4 Critério operacional

Analisa-se como o sistema se comporta em uso real, incluindo volume de dados, número de usuários, rotinas de trabalho, horários de pico, treinamento e suporte.

2.5 Critério histórico

Examina-se a evolução temporal: versões, atualizações, correções, incidentes, chamados, mudanças de escopo, homologações e entrada em produção.

2.6 Critério probatório

Avalia-se a suficiência, integridade e rastreabilidade das evidências utilizadas para sustentar conclusões.

Esses critérios podem ser combinados conforme a natureza da controvérsia.

3. Fontes de evidência

A avaliação de desempenho, defeitos e aderência funcional pode demandar diferentes fontes de evidência.

A confiabilidade da análise depende da qualidade dessas evidências. Registros incompletos, prints sem contexto, logs expirados ou ambientes alterados podem limitar conclusões.

4. Desempenho: medição e interpretação

A análise de desempenho deve ser conduzida com atenção ao ambiente. Um sistema pode apresentar lentidão por diferentes causas:

• código ineficiente;
• consultas mal estruturadas;
• ausência de índices em banco de dados;
• infraestrutura subdimensionada;
• rede instável;
• integração externa lenta;
• excesso de usuários simultâneos;
• volume de dados superior ao previsto;
• configuração inadequada;
• logs ou rotinas de auditoria excessivos;
• processos concorrentes;
• filas mal dimensionadas;
• limitações de arquitetura;
• problemas no navegador ou endpoint do usuário.

Por isso, a medição de desempenho deve considerar condições controladas e, quando possível, dados do ambiente real.

Perguntas úteis na análise de desempenho

Qual operação está lenta?
Uma tela específica, relatório, integração, login, consulta ou todo o sistema?

Qual é o tempo observado?
É necessário medir, não apenas relatar percepção.

Qual era o tempo esperado ou contratado?
Há SLA, requisito não funcional ou benchmark acordado?

A lentidão ocorre sempre ou em horários específicos?
Problemas intermitentes exigem análise de correlação temporal.

O problema afeta todos os usuários ou apenas perfis, regiões ou ambientes específicos?

Há relação com volume de dados, versão, atualização ou integração?

O ambiente utilizado corresponde ao ambiente previsto para a carga real?

Sem essas respostas, conclusões sobre desempenho podem ser frágeis.

5. Defeitos: classificação técnica

Nem toda falha tem a mesma gravidade. Para fins periciais, pode ser útil classificar defeitos segundo seu efeito.

Defeito crítico

Impede a operação essencial do sistema, compromete dados relevantes, bloqueia processos centrais ou causa indisponibilidade significativa.

Defeito relevante

Afeta funcionalidade importante, gera retrabalho, compromete eficiência ou causa inconsistência operacional, mas não impede totalmente o uso do sistema.

Defeito pontual

Afeta situação específica, perfil restrito, conjunto limitado de dados ou cenário de exceção.

Defeito cosmético ou de usabilidade

Não compromete diretamente a função principal, mas pode afetar clareza, experiência do usuário ou eficiência.

Defeito de integração

Surge na comunicação entre sistemas, APIs, bancos, filas, arquivos de troca ou serviços externos.

Defeito de parametrização

Resulta de configuração incorreta, incompleta ou incompatível com as regras de negócio.

Essa classificação deve ser fundamentada, não apenas declarada. A gravidade depende do contexto do negócio e do processo afetado.

6. Aderência funcional: comparação entre expectativa e entrega

A análise de aderência funcional exige uma matriz entre requisitos e funcionalidades. Essa matriz pode conter:

• requisito ou obrigação;
• fonte documental;
• funcionalidade correspondente;
• evidência de implementação;
• evidência de teste ou homologação;
• situação observada;
• divergência identificada;
• impacto técnico;
• limitação da análise.

Exemplo conceitual:

A matriz reduz ambiguidade e permite que as partes compreendam exatamente onde há aderência, divergência ou incerteza.

7. Testes e reprodução de falhas

Quando possível, a reprodução de falhas é um elemento importante da análise. Contudo, nem toda falha pode ser reproduzida posteriormente, especialmente quando o ambiente foi alterado, dados foram corrigidos, versões foram atualizadas ou logs expiraram.

A reprodução deve documentar:

• ambiente utilizado;
• versão do sistema;
• usuário ou perfil;
• dados de entrada;
• passos executados;
• resultado esperado;
• resultado obtido;
• mensagens de erro;
• evidências registradas;
• logs correlatos;
• limitações.

Nos casos em que a reprodução não é possível, a análise pode se basear em registros históricos, tickets, logs, vídeos, evidências de suporte, mensagens e documentos de época.

8. Sistemas SaaS e limitações de acesso

Em sistemas SaaS, a organização usuária nem sempre tem acesso ao código, banco de dados, infraestrutura ou logs internos. A análise pode depender de painéis administrativos, relatórios exportados, logs disponíveis ao cliente, documentação do fornecedor, SLA, registros de suporte e evidências de uso.

Essa limitação não impede a análise, mas altera o método. O relatório deve indicar claramente quais elementos estavam disponíveis e quais dependiam do fornecedor.

Em SaaS, pontos recorrentes incluem:

• indisponibilidade;
• performance percebida;
• limitações de plano contratado;
• divergência entre funcionalidade anunciada e funcionalidade disponível;
• problemas de integração;
• permissões;
• exportação de dados;
• logs insuficientes;
• dependência de suporte do fornecedor;
• alterações unilaterais de versão;
• mudanças em APIs.

A avaliação deve considerar os limites contratuais e técnicos do modelo SaaS.

9. Impacto operacional e nexo técnico

A existência de defeito ou baixa aderência funcional não demonstra automaticamente dano econômico. É necessário avaliar o nexo técnico entre a falha e os efeitos alegados.

A análise pode examinar:

• processos interrompidos;
• volume de transações afetadas;
• usuários impactados;
• período de ocorrência;
• retrabalho documentado;
• atrasos decorrentes;
• inconsistências geradas;
• necessidade de sistemas paralelos;
• custos de correção;
• perda de produtividade;
• relação com indicadores operacionais;
• medidas de contingência adotadas.

Essa avaliação pode servir de base para análises econômicas, contábeis ou financeiras posteriores, especialmente em casos de lucros cessantes, perdas operacionais ou indenizações.

10. Limitações comuns da avaliação

As principais limitações encontradas em avaliações forenses de sistemas corporativos incluem:

• ausência de requisitos documentados;
• escopo contratual ambíguo;
• logs não preservados;
• ambiente alterado após os fatos;
• versão atual diferente da versão discutida;
• ausência de base histórica;
• tickets incompletos;
• falhas não reproduzíveis;
• falta de acesso ao código-fonte;
• dependência de fornecedor SaaS;
• ausência de métricas de desempenho;
• dados de produção indisponíveis;
• ausência de critérios de aceite;
• homologação sem evidências;
• usuários sem registro de testes;
• documentação técnica insuficiente.

Essas limitações devem ser apresentadas no relatório, pois definem o grau de certeza possível.

11. Produtos técnicos possíveis

A avaliação de desempenho, defeitos e aderência funcional pode resultar em diferentes entregáveis:

• relatório técnico de avaliação de sistema;
• matriz de aderência funcional;
• relatório de desempenho;
• análise de defeitos;
• parecer sobre falhas operacionais;
• relatório de reprodução de erros;
• análise de logs de aplicação;
• parecer sobre impacto técnico;
• matriz de requisitos versus funcionalidades;
• relatório de limitações técnicas;
• subsídios técnicos para quesitos;
• assistência técnica em disputa judicial ou arbitral;
• nota técnica para negociação entre contratante e fornecedor;
• avaliação de continuidade ou substituição do sistema.

A escolha do produto depende do objetivo do exame e da qualidade das evidências disponíveis.

Considerações finais

A avaliação forense de desempenho, defeitos e aderência funcional é essencial em disputas envolvendo sistemas corporativos. Ela permite diferenciar percepção de usuário, falha operacional, defeito de software, problema de parametrização, limitação contratual, falha de infraestrutura, ausência de requisito e impacto efetivamente demonstrado.

Em ambientes B2B, essa análise deve ser conduzida com método, rastreabilidade e linguagem técnica compreensível. O relatório precisa demonstrar quais evidências foram examinadas, quais critérios foram utilizados, quais falhas foram confirmadas, quais hipóteses foram descartadas e quais limitações permanecem.

O valor da análise não está em afirmar genericamente que um sistema é adequado ou inadequado, mas em indicar, com base em evidências, onde há aderência, divergência, defeito, limitação ou insuficiência técnica. Essa abordagem contribui para decisões mais qualificadas em litígios, arbitragens, negociações, auditorias, investigações internas e processos de governança tecnológica.

Imagem: iStock.com/AndreyPopov