Peritajes & Peritos

Recientemente he terminado una pericial informática para un juicio Mercantil donde el cliente, localizado en Madrid, demanda al partner por un portal web con funcionalidades de gestión en el sector seguros. Hablamos de un Peritaje informático proyecto web. Las razones fundamentales que el cliente defiende y que me encargó demostrar fue que el proyecto ha fracasado fundamentalmente por dos cuestiones: Malas praxis del partner desarrollador, mala calidad del desarrollo lo que llevó a errores constantes en el intento de arranque y estabilización.

Estamos ante un proyecto típico de desarrollo a medida basado en un conjunto de funcionalidades previas que se acuerdan entre cliente y partner, firma de contrato y desarrollo del mismo.

Para analizar este proyecto he trabajado los siguientes aspectos:

  1. Timeline del proyecto. Esto es, analizar todas las conversaciones desde la toma de contacto, presentación de oferta por parte del partner, contrato y vida del proyecto hasta su arranque intento de estabilización y fracaso.
  2. Funcionalidades que no están implementadas y si estaban en el contrato inicial.
  3. Funcionalidades erróneas que No siéndolo en las pruebas unitarias si lo fueron en las pruebas de integración o en las pruebas de uso intensivo del sistema.

Respecto de este punto y para que el lector lo pueda entender, las funcionalidades desarrolladas a medida, por ejemplo, buscar el seguro que más se adapte a unas características, se deben testear por el usuario y por la empresa de desarrollo. Generalmente estas pruebas se realizan de forma unitaria y de conjunto.

Las pruebas unitarias corresponderían, en el ejemplo anterior, a proponer en un entorno de test que un usuario hiciera una búsqueda de un seguro concreto. Esa funcionalidad puede o no ser correcta pero la característica fundamental de este modo de prueba es que generalmente esta “aislada”, no hay más usuarios o si los hay no suelen interferir en el resultado del mismo.

Luego existen las pruebas de integración y/o de conjunto. Estas pruebas se suelen hacer en conjunto con otros usuarios que usan el sistema al mismo tiempo en esta u otras funcionalidades simultáneamente. En algunas ocasiones estas pruebas, por su complejidad, no se realizan, sino que se posponen para el propio arranque en productivo del sistema, formando parte, los errores que puedan surgir, de la estabilización del sistema informático, en este caso una web de seguros.

Es importante denotar que si las pruebas unitarias fueron correctas, en nuestro ejemplo el portal web nos mostró el seguro mas adecuada, pero no lo es cuando el sistema esta arrancado en un entorno con cientos o miles de usuarios simultáneamente utilizando el sistema, podemos evidenciar alguno o todos de los siguientes problemas:

  1. Errores de programación como fallos en la transaccionalidad de las acciones, bloqueos en bases de datos, consultas que generan timeout y bloquean recursos en los sistemas, etc
  2. Servicios de interconexión con sistemas externos que bloquean a los usuarios del propio sistema.
  3. Consultas pesadas internas que bloquean otras funcionalidades que hacen uso de los mismos recursos.
  4. Operaciones de rollback ante fallos o excepciones que de nuevo bloquean a otros usuarios.
  5. Malas prácticas en programación de toda índole, uso de sistemas Freeware mal configurados, configuradores de servidores inadecuados, anchos de banda de comunicaciones insuficientes, recursos hw insuficientes, …
  6. Problemas de seguridad, autenticación, roles, etc

Todas estas y otras razones pueden hacer que una funcionalidad de un sistema que ha sido testeada aislada o unitariamente, una vez puesto en marcha el sistema, estas fallen sin tener control exacto de la causa y sin haber podido ser detectadas en estas pruebas unitarias. Esto no elimina la responsabilidad del proveedor de desarrollo informático, ya que sin lugar a dudas estos fallos de integración/globales/conjunto son derivados de problemas del proyecto, a priori, en estos términos, del usuario que contrata el mismo.

Conclusiones

Peritaje informático proyecto web. En un juicio donde debemos aportar una pericial sobre un proyecto de desarrollo a medida, la experiencia como director de proyecto y consultor previo es fundamental, para poder entender la razón más objetiva posible de cada problema. Con una experiencia como consultor y perito informático de más de 25 años mis periciales demuestran objetivamente las evidencias que mis clientes necesitan en sala judicial.

Luis Vilanova Blanco

Fuente: Perito judicial informático - Luis Vilanova

Source