Processos sobre implantação de sistemas corporativos convergem, quase sempre, para a mesma pergunta mal formulada: o sistema funciona? A pergunta é ruim porque não é testável. Cada parte responde com a sua própria escala, e o juízo recebe duas afirmações contraditórias sem nenhum critério externo que permita decidir entre elas. O deslocamento produtivo é anterior ao mérito: antes de perguntar se funciona, é preciso fixar segundo qual critério se está avaliando.
Considere-se um comportamento específico, documentado com frequência nesses litígios: uma rotina de processamento é executada, conclui sem qualquer mensagem de erro, sem alerta e sem bloqueio, e devolve ao operador indicação de execução bem-sucedida — mas produz um resultado incorreto. Num caso examinado, uma rotina de cálculo processou apenas os lançamentos de débito e ignorou os de crédito, afetando algumas centenas de pessoas; a correção exigiu trabalho manual noturno de uma equipe, e a própria rotina não admitia manutenção em massa.
A designação técnica desse comportamento é falha silenciosa. E é importante distingui-la do erro de cálculo. Um sistema que calcula errado e sinaliza o erro produz um problema localizado, imediatamente perceptível e corrigível no ponto. Um sistema que calcula errado e sinaliza sucesso produz um problema difuso: ele só será descoberto adiante, por outro meio, e até lá terá contaminado tudo o que dependa daquele resultado. A gravidade é proporcional à criticidade da rotina e à distância temporal entre a falha e a sua percepção. Do ponto de vista de engenharia, não se trata de imprecisão de cálculo, mas de ausência de duas coisas: validação de entrada e sinalização de insucesso.
A expressão "falha silenciosa" não é terminologia normativa, e é honesto dizê-lo. O comportamento que ela descreve, porém, é endereçado por atributos expressos da ISO/IEC 25010 — Systems and software engineering — SQuaRE — Product quality model. Três interessam aqui.
O primeiro é a correção funcional (functional correctness): o grau em que o produto fornece resultados corretos, com o grau de precisão necessário. Uma rotina que devolve indicação de sucesso e produz valor incorreto em base de cálculo descumpre esse atributo de modo direto, e — ponto relevante — independentemente da causa técnica subjacente. O atributo descreve o resultado, não a sua origem.
O segundo é a autodescritividade (self-descriptiveness): o sistema deve tornar compreensível ao operador o seu próprio estado e o resultado da operação executada. É precisamente o que falta quando a execução termina informando sucesso sobre um processamento incompleto.
O terceiro é um conjunto, aplicável às frentes de indisponibilidade: ausência de defeitos, tolerância a falhas, disponibilidade e recuperabilidade, reunidos sob a característica de confiabilidade.
Há uma cautela metodológica que costuma decidir o ponto em litígios longos: verificar se os atributos invocados constavam da edição da norma vigente ao tempo dos fatos. Quando constavam, com denominação equivalente, a conclusão técnica não se altera conforme a edição adotada — e essa observação, feita antes da objeção, retira do adversário um argumento fácil.
O limite é igualmente importante. A ISO/IEC 25010 é modelo de qualidade de produto. Ela não define — nem lhe caberia definir — o conceito jurídico de vício ou de defeito. Sua função no processo é fornecer critério técnico objetivo, de origem não vinculada a qualquer das partes, para aferir se o comportamento documentado corresponde ao funcionamento esperado. A partir daí, a qualificação jurídica é do juízo, à luz do contrato, do Código Civil e, quando aplicável, do Código de Defesa do Consumidor.
Duas ressalvas completam a análise, e a sua ausência costuma ser o que enfraquece pareceres nesta matéria. A primeira: nem toda inconsistência de resultado decorre de defeito do produto — cadastro incorreto, parametrização inadequada e regra de funcionamento documentada são hipóteses concorrentes, e distinguir erro de cadastro de defeito de rotina é justamente objeto da verificação pericial. A segunda: quando o fornecedor, respondendo a um chamado, descreve como a rotina opera, ele está descrevendo uma regra, não confessando um defeito; a aderência dessa regra ao resultado contratado depende de confronto com os documentos de especificação.
O ganho prático de ancorar o quesito em atributo nomeado de norma internacional é retirar a discussão do terreno da opinião. Dois quesitos rendem particularmente bem: a rotina sinalizava insucesso ao operador, ou concluía com indicação de sucesso? E existe registro do fornecedor — nota de versão, chamado interno, ata — reconhecendo o comportamento e a respectiva correção, com data? Esse segundo quesito é o de maior alcance: quando há nota de versão do fabricante descrevendo a correção, a controvérsia se desloca de "existe defeito?" para "desde quando ele era conhecido?". O intervalo entre o primeiro reporte formal e a liberação da correção é fato datável, verificável em documentos das duas partes. O efeito jurídico desse intervalo — mora, inadimplemento, dever de informar — é matéria do juízo.
A engenharia de software oferece ao processo algo que ele raramente aproveita: vocabulário preciso e critérios aferíveis para descrever o comportamento de um produto. Usá-los não transfere ao perito a decisão sobre vício ou defeito, e não deveria. Usá-los apenas garante que, quando o juízo decidir, esteja decidindo sobre um fato descrito com precisão — e não escolhendo entre duas narrativas.
8 min de leitura