¿El sistema entregado sirve para lo que fue contratado? El peritaje responde leyendo el repositorio, la base de datos y el entorno de pruebas, con evidencia fechada.
En un proyecto de software que salió mal, el contratante dice que el sistema no funciona. El proveedor dice que entregó y que el atraso vino de cambios pedidos por el cliente. El juez o el árbitro necesita otra cosa: qué se hizo, cuándo, y por qué falló.
Esa respuesta está en los registros del propio proyecto. El repositorio de código guarda cada modificación (cada commit) con fecha y autor. La base de datos muestra lo que el sistema grabó. El sistema de tickets muestra quién pidió qué. El entorno de homologación muestra lo que estaba listo para pruebas.
El peritaje en software preserva esos registros antes de cualquier análisis, con hash y cadena de custodia, y reconstruye el proyecto a partir de ellos. Esta página trata del examen del software en sí. La visión general de contratos de TI y de implantaciones de ERP está en Seguridad de la Información y Compliance. La elección entre proceso judicial, arbitraje y mediación está en Arbitraje y Mediación en TI.
"No funciona" necesita convertirse en hecho: qué funcionalidad, en qué entorno, con qué dato y con qué resultado. El peritaje ejecuta los flujos en disputa y mide el comportamiento contra lo que fue especificado. Las características de calidad de la ISO/IEC 25010, como adecuación funcional, fiabilidad y eficiencia de desempeño, dan a las dos partes un vocabulario común.
¿Quién atrasó? La línea de tiempo cruza commits, versiones publicadas, tickets, aprobaciones y pedidos de cambio. Separa el atraso de desarrollo del atraso causado por dependencias del contratante, como accesos, datos y aprobaciones, y de los cambios de alcance que entraron sin adenda.
¿Qué estaba listo en la fecha de la rescisión? El peritaje compara el código de los repositorios con la versión en homologación hasta aquella fecha. Separa lo que estaba entregado, lo que estaba en desarrollo y lo que nunca comenzó.
¿El proveedor reutilizó código de otro cliente, o el sistema nuevo copia al antiguo? El peritaje compara las bases de código, identifica el origen de cada componente y muestra quién escribió cada parte. El tema tiene página propia en Propiedad Intelectual, Secreto Empresarial y Competencia Desleal.
Llega una notificación por contrafacción o una auditoría de licenciamiento promovida por el fabricante. El peritaje preliminar de licenciamiento releva, con imagen forense de los equipos, qué está instalado y qué está licenciado, antes de que la empresa responda. En la acción, la actuación es en la defensa de la empresa auditada o, en otros procesos, como perito designado por el juzgado en acciones promovidas por fabricantes.
Cuando una falla en producción genera una multa, la pregunta es de dónde vino: defecto del código, configuración del entorno, cambio mal gestionado o incidente de seguridad. Los logs de la base de datos, los registros de la gestión de cambios y el proceso de pruebas, que tiene referencia en la ISO/IEC/IEEE 29119, muestran la causa y quién respondía por ella. Muchas fallas no son un incidente cibernético. Son falla de proceso.
01 · Preservación. Copia de los repositorios con el historial completo, de la base de datos y de los entornos, con hash. Nada se examina en el entorno en uso.
02 · Línea de tiempo. Commits, versiones, tickets, actas y correos ordenados en una única cronología.
03 · Confrontación. Lo que el contrato, la propuesta y los requisitos pedían, contra lo que el código y el sistema hacen.
04 · Pruebas. Quién probó, qué probó y con qué resultado. Las pruebas de cada parte se miden por separado.
05 · Entorno espejo. Cuando el entorno original cambió o no está disponible, el peritaje monta un entorno equivalente para reproducir las fallas y poner a prueba hipótesis concurrentes.
06 · Dictamen. Hallazgos, hipótesis probadas, límites declarados y anexos que las dos partes pueden verificar.
El precio y el plazo del software se discuten mejor con una medida. El análisis de puntos de función mide el tamaño funcional del sistema por lo que hace para el usuario, sin depender del lenguaje ni de la tecnología. Es un método estandarizado internacionalmente (ISO/IEC 20926) y ampliamente usado en las contrataciones de software del gobierno federal brasileño, según el Roteiro de Métricas de Software del SISP, el sistema que reúne a los órganos de TI de la administración federal.
En el peritaje, el conteo sirve para comparar el tamaño de lo que fue contratado con el de lo que fue entregado, o para evaluar si un precio tiene base técnica. Ya fue aplicado, por ejemplo, para un cliente que necesitaba justificar en una licitación el valor que cobraba y mostrar por qué se diferenciaba del de otros participantes (caso descrito en Licitaciones, Contratos Públicos e Infraestructura).
Un contrato de desarrollo fue rescindido con las partes en desacuerdo sobre lo que había sido entregado y sobre la causa de las fallas del sistema.
Los repositorios del proyecto fueron preservados con el historial completo, y los commits fueron comparados con la versión de homologación hasta la fecha de la rescisión. El peritaje reconstruyó un entorno espejo y examinó la hipótesis de que las fallas venían del proxy (el servidor intermediario) de la red corporativa, y no del código.
El dictamen delimitó, con evidencia fechada, lo que estaba listo en la rescisión y de dónde venían las fallas.
Una empresa contrata el desarrollo de una aplicación con plazo de seis meses. Nueve meses después, todavía no está en producción. El proveedor dice que el cliente cambió el alcance y demoró en liberar el acceso a los sistemas. El cliente dice que el código llegaba con errores.
El peritaje monta una línea de tiempo con los commits, los tickets y los correos de aprobación. Muestra cuántas funcionalidades entraron después de la firma, cuánto tiempo quedó parado cada pedido de acceso y cuántas entregas volvieron de la homologación con defectos.
Con esa cronología, el atraso deja de ser versión contra versión. Cada parte ve la porción que le corresponde, y la negociación, el arbitraje o el proceso parten de hechos.
Consulte también
Arbitraje y Mediación en TI → Seguridad de la Información y Compliance → Propiedad Intelectual, Secreto Empresarial y Competencia Desleal → Peritaje Judicial y Extrajudicial → Licitaciones, Contratos Públicos e Infraestructura → Derecho Digital y Tecnología →
Antes de decidir, vale ver lo que ya pasó por este laboratorio: casos descritos sin identificar a las partes, en el formato desafío, método y resultado.
El canal de control del intruso estaba grabado en contratos inteligentes. El peritaje decodificó lo que había borrado y entregó a las autoridades los caminos de identificación.
Ver el caso Prueba negativaEl peritaje oficial había concluido que participó. El reexamen demostró que los vínculos eran falsos positivos, y la persona acusada fue absuelta.
Ver el caso