El contrato decía que el sistema se aceptaría "tras una homologación satisfactoria". Dos años después, cada parte tiene su idea de lo satisfactorio, y el juez le pregunta al perito lo que el contrato no definió.
Aceptación, SLA, escrow, entrega, logs, incidentes y datos en la rescisión desde la óptica del peritaje: los puntos técnicos que la cláusula debe cubrir.
En un proyecto de software que salió mal, el contratante dice que el sistema no funciona y el proveedor dice que lo entregó. El peritaje lee el repositorio, la base de datos, los tickets de soporte y la homologación para decir qué se hizo, cuándo y por qué falló. Lo que no puede hacer es medir contra un criterio que el contrato no escribió.
La prueba se pierde en el propio contrato: aceptación sin criterio, SLA sin fuente de medición, entrega en archivos sueltos, escrow nunca verificado, logs que nadie guarda, entornos apagados el día de la rescisión.
El curso recorre las cláusulas que más terminan en peritaje: qué debe ser medible, quién guarda el registro y cómo se verifica. La redacción es del abogado. El curso entrega los puntos técnicos.
Elija cuantos cursos quiera: quedan guardados y llegan marcados en el formulario de inscripción.
Un contrato de desarrollo se rescindió en desacuerdo sobre lo que se había entregado y sobre la causa de las fallas. Los repositorios se preservaron con el historial completo, y los commits se compararon con la homologación hasta la rescisión. En un entorno espejo, el peritaje examinó la hipótesis de que las fallas venían del proxy de la red corporativa, y no del código. El dictamen delimitó lo que estaba listo y de dónde venían las fallas.
Contratante y desarrolladora se disputaban un proyecto entregado en parte, y cada una culpaba a la otra. El análisis técnico del alcance, de las entregas y de las dependencias de cada parte demostró responsabilidades compartidas. La negociación sobre los hechos llevó a un acuerdo de entrega parcial, sin litigio judicial.
Una empresa recibió de su proveedor de nube un cobro adicional que no reconocía. Con los registros de la cuenta, el peritaje reconstruyó la creación de máquinas virtuales no autorizadas y las separó del uso legítimo. El cobro adicional fue cancelado.
Los grupos reciben fragmentos ficticios de un contrato de software, redactados a propósito sin criterio técnico. En 15 minutos, señalan en cada fragmento lo que un perito necesitaría medir, lo que falta y quién guardaría el registro. Entregan la lista de puntos técnicos que la redacción debe cubrir.
Normas y decisiones analizadas
Ley 9.609/1998, art. 4º (Ley de Software brasileña) · LGPD, arts. 16, 39 y 42, § 1º, I (ley brasileña de protección de datos) · CPC, art. 381 (Código Procesal Civil brasileño) · Roteiro de Métricas de Software del SISP, versión 3.0 (guía de métricas del Gobierno Federal de Brasil)
Consulte también
Peritaje en Software y Proyectos de Desarrollo → Arbitraje y Mediación en TI → Seguridad de la Información y Compliance → Peritaje en Derecho Digital y Tecnología → Ver todos los cursos →