04 Oct Qué analiza un perito informático cuando un proyecto de software termina en juicio
Cuando un proyecto de software termina en conflicto, las discusiones suelen centrarse en preguntas como estas: ¿se entregó lo contratado?, ¿el programa funcionaba correctamente?, ¿los retrasos fueron responsabilidad del proveedor o del cliente?, ¿existían errores graves?, ¿se modificó el alcance durante el proyecto?
En un procedimiento judicial, responder a estas cuestiones requiere algo más que revisar correos electrónicos o contratos. Es necesario analizar técnicamente qué ocurrió durante el desarrollo del proyecto y relacionarlo con las obligaciones asumidas por cada parte.
Ahí entra en juego el perito informático.
1. El alcance real del proyecto
Uno de los primeros aspectos que debe analizarse es qué se contrató exactamente.
El perito revisa contratos, anexos técnicos, propuestas, especificaciones funcionales, actas de reuniones, presupuestos y cualquier documento que permita determinar cuál era el alcance inicial.
Este punto es fundamental porque muchos conflictos aparecen cuando las partes tienen interpretaciones diferentes sobre lo que debía entregarse.
También se estudian las modificaciones posteriores. Si durante el proyecto se añadieron nuevas funcionalidades, integraciones o requisitos, habrá que determinar si esos cambios estaban incluidos en el contrato inicial o suponían una ampliación del alcance.
2. El grado de cumplimiento de los requisitos
Una vez definido qué debía hacer el software, el siguiente paso consiste en comprobar qué se entregó realmente.
El análisis puede incluir funcionalidades, integraciones, procesos, módulos, informes y cualquier requisito técnico o funcional incluido en el proyecto.
No basta con afirmar que una determinada función “no funciona”. En un informe pericial es necesario identificar el problema, reproducirlo cuando sea posible y explicar su impacto.
Además, debe diferenciarse entre un fallo relevante y una incidencia menor que no impida el uso normal del sistema.
3. Los errores y defectos del software
Los errores pueden tener distintos niveles de gravedad.
Un fallo puede afectar únicamente a una pantalla concreta o impedir completamente un proceso esencial para la empresa.
El perito puede analizar, entre otros aspectos:
- errores funcionales;
- problemas de rendimiento;
- fallos de integración;
- pérdida o corrupción de datos;
- problemas de seguridad;
- errores de configuración;
- incidencias repetitivas;
- funcionalidades incompletas.
También resulta importante comprobar si los defectos fueron comunicados, cuándo se detectaron y si el proveedor tuvo oportunidad de corregirlos.
4. Los retrasos y sus causas
Los retrasos son uno de los motivos más habituales de conflicto en proyectos tecnológicos.
Sin embargo, determinar quién es responsable no siempre es sencillo.
Un proyecto puede retrasarse porque el proveedor incumplió el calendario, pero también porque el cliente tardó en entregar información, modificar procesos, validar desarrollos o facilitar acceso a determinados sistemas.
El análisis pericial debe reconstruir la evolución temporal del proyecto y estudiar qué incidencias afectaron realmente a cada fase.
Para ello pueden revisarse cronogramas, tickets, correos electrónicos, actas, entregas y herramientas de gestión de proyectos.
5. La participación del cliente
El éxito de un proyecto de software no depende exclusivamente del desarrollador.
En muchas implantaciones el cliente debe participar activamente proporcionando datos, definiendo procesos, validando configuraciones o realizando pruebas.
Si esas tareas no se realizaron a tiempo, pueden haber contribuido al retraso o a determinados problemas posteriores.
Por eso, una pericial informática debe estudiar las obligaciones y actuaciones de ambas partes.
6. Las pruebas realizadas
Las pruebas son especialmente importantes para determinar si un software estaba preparado para entrar en producción.
El perito puede analizar si existieron planes de pruebas, qué escenarios se comprobaron, qué incidencias aparecieron y cuáles quedaron pendientes antes de la puesta en marcha.
También puede estudiar si existieron validaciones formales por parte del cliente.
Una aceptación documentada puede tener una importancia considerable, aunque siempre debe interpretarse teniendo en cuenta el contexto técnico del proyecto.
7. La documentación y la trazabilidad
En un conflicto tecnológico, la documentación puede marcar una diferencia importante.
El perito analiza si existen registros suficientes para reconstruir qué ocurrió.
Entre las fuentes habituales se encuentran los sistemas de tickets, repositorios de código, registros de cambios, documentación funcional, correos electrónicos, actas de reuniones, versiones de software y evidencias de las pruebas realizadas.
Cuanta mayor trazabilidad exista, más sencillo será determinar responsabilidades.
El objetivo de una pericial no es decidir quién tiene razón
El perito informático no sustituye al juez ni realiza una valoración jurídica del conflicto.
Su función consiste en aportar una explicación técnica objetiva sobre lo ocurrido: qué se contrató, qué se desarrolló, qué problemas existieron, cómo evolucionó el proyecto y qué impacto tuvieron las decisiones tomadas por cada parte.
En proyectos tecnológicos complejos, convertir cientos de documentos, incidencias y decisiones técnicas en conclusiones comprensibles puede ser determinante para que un tribunal pueda valorar adecuadamente el conflicto.
Por eso, cuando un proyecto de software termina en juicio, una buena pericial debe basarse en evidencias, metodología y trazabilidad, no simplemente en opiniones.
Contáctanos en luis@luisvilanova.es