28 Feb Peritaje informático entre partner y cliente por portal web
En este artículo quería hablar de la intensidad cuando preparo un peritaje para un juicio, especialmente en aquellos casos donde estamos trabajando algún proyecto web, software, app, erp, crm etc que ha fracasado entre partner y cliente ya que la empresa es mi terreno natural y la ingeniería de software uno de los conceptos que más experiencia y valor aporto a mis clientes, ya sean empresas finales, partners, abogados o jueces. Estamos ante un Peritaje informático entre partner y cliente.
Peritaje informático entre partner y cliente por portal web
Hoy entrego un informe que describe la situación de un importante proyecto para un partner de Bilbao que desarrolla portales web de gestión a medida para sus clientes. En uno de ellos el proyecto ha fracasado, por diferentes motivos, encontrándome en este momento firmando el informe pericial que defenderé en sala judicial.
Desarrollar un informe de esta magnitud, con más de 200 páginas de un contenido muy denso y técnico, pero explicado con evidencias sencillas para que las partes profanas generalmente en software (juez y letrados) lo entiendan es verdaderamente apasionante.
Escribir cada párrafo pensando en las preguntas que juez y abogados me harán, donde estoy diciendo una verdad completa o estoy cometiendo un error al declarar una evidencia encontrada, como toda la pericial debe ser consistente y no puede haber ni juicios de valor sino verdades probadas con evidencias.
Uno de los temas que en esta pericial de una web fallida me ha hecho otra vez tomar conciencia de los puntos diferenciales es lo que denomino error sustancial o error bloqueante.
Error sustancial o bloqueante en un proyecto informático
En un proyecto informático adecuadamente ejecutado la tasa de errores es alta al principio y cae con la estabilización del mismo y el paso del tiempo, como puede verse en la curva inferior, nunca siendo cero.
En ocasiones, con la aparición de nuevas versiones o nuevos desarrollos los errores pueden aparecer. Estos errores son lógicamente aceptables siempre y cuando no afecten al núcleo o core del sistema, interrumpiendo su servicio en un tiempo prolongado; impidiendo su funcionamiento en aspectos clave, etc.
En este sentido podemos decir que un proyecto de software se estabiliza cuando un gran porcentaje de las necesidades globales y errores se subsanan (siempre con la colaboración de ambas partes), siendo normal que las incidencias o mejoras acompañen al proyecto conforme dicho proyecto evoluciona, la estrategia de la empresa cambia, se aprovechan nuevas funcionalidades que derivan en otras o en informes nuevos que inicialmente no se habían planteado, etc.
En el caso que nos ocupa, tras la revisión que he realizado de los módulos desarrollados, así como del código fuente entregado no he apreciado que exista ningún error grave o que impida el normal y lógico uso del software.
El concepto de error bloqueante es importante en esta pericial. En el campo de la Ingeniería de Software se considera que un error es bloqueante si cumple los siguientes requisitos:
- No tiene solución o, al menos, no se puede resolver en un periodo corto de tiempo.
- Afecta al normal funcionamiento del software en tal magnitud que el cliente no puede utilizarlo de forma global o en procesos que son clave para el normal funcionamiento de su empresa.
Es por ello que este concepto es altamente potente para determinar si un proyecto, técnica o funcionalmente debe ser abandonado o cancelado y es fácil de explicar en sala judicial. Creo que es clave para muchos juicios donde el software, mercantil, es el objetivo principal del mismo.
Luis Vilanova Blanco. Perito informático colaborador con la justicia.
606954593
madrid@leyesytecnologia.com