Peritaje informático de incumplimiento de contratos en proyectos software

Cuando un perito informático afronta un peritaje informático relativo al incumplimiento de un contrato en el desarrollo de un proyecto software, es vital el enfoque en dos aspectos: el propio contrato de prestación de servicios (o de obra, según se explicará posteriormente) y el documento o documentos de la Especificación de Requisitos del Software (que no siempre existe, aunque es un anexo fundamental para la comprensión del proyecto, ya que en él se especifican todas las características que debe tener el software, dejando en el cuerpo del contrato los aspectos legales). La realización de un peritaje informático sobre el incumplimiento de un contrato en un proyecto software, es una tarea muy compleja para la que se debe contar con toda la documentación posible relativa al proyecto, siendo estos dos documentos la base fundamental del desarrollo de cualquier proyecto software.

 

En el contrato de desarrollo de un proyecto software deben especificarse aspectos relevantes como el periodo para la toma de requisitos, el plazo para la construcción e implantación del proyecto, los hitos del desarrollo del mismo, las entregas (conocidas en la jerga como artefactos) que la empresa desarrolladora del proyecto debe realizar al cliente así como el alcance de éstas (es decir, el conjunto de funcionalidades que contendrán), los pagos que el cliente debe realizar a la empresa de desarrollo, el plazo para la implantación del proyecto, el periodo de garantía del mismo en el que la empresa de desarrollo se compromete a resolver las incidencias del sistema como parte del contrato, el periodo de formación a los usuarios, el sometimiento del contrato a la legislación vigente, etc. Es importante también dejar claro en el contrato si, en caso de discrepancias en el cumplimiento del mismo por alguna de las partes, el litigio quedará sometido a arbitraje con o sin perjuicio de acudir a la vía judicial ordinaria y, en tal caso, qué Corte Arbitral se encargará de resolver el conflicto, recomendando siempre que, para proyectos informáticos, sea la Corte Arbitral del Colegio de Ingenieros o Ingenieros Técnicos en Informática de la Comunidad Autónoma donde se firme el contrato, la encargada de asignar a un perito informático colegiado el litigio. El perito informático, actuando como árbitro, emitirá en ese caso, una vez oídas las partes y estudiado el caso en su conjunto, lo que se conoce como laudo arbitral.

Un aspecto fundamental de cualquier proyecto software y absolutamente clave para el éxito del mismo es la toma de requisitos. La toma de requisitos del software debe ser un proceso continuado en el tiempo, es decir, debe comenzar antes que el resto de las fases del desarrollo del proyecto, pero debe continuarse en paralelo una vez han comenzado las mismas. Cuando se afronta un proyecto software complejo es necesario saber qué necesitan los usuarios, lo que únicamente se consigue con el equipo de ingenieros que van a desarrollar el proyecto estableciendo contacto directo con los propios usuarios, desarrollando prototipos con funcionalidades limitadas que los usuarios puedan utilizar y con los que puedan interactuar, etc. Una ausencia o mala planificación de la fase de toma de requisitos en un proyecto software, es garantía casi segura de un fracaso en el mismo, puesto que los usuarios estarán descontentos con el sistema y sus funcionalidades, ya que es extremadamente difícil que los ingenieros puedan comprender las necesidades de los usuarios para poder trasladar posteriormente las mismas a lenguaje informático, por lo que se requiere de un trabajo muy exhaustivo en esta fase. La fase de toma de requisitos, por tanto, debe quedar totalmente especificada y desglosada en el contrato de desarrollo del proyecto software.

 

Es necesario diferenciar entre el contrato de realización de un proyecto software propiamente dicho y los anexos al mismo. Un anexo a un contrato es un documento que desglosa ciertos aspectos del contrato y que es demasiado extenso y específico para incluirse en el cuerpo del contrato. Éste es el caso del documento de Especificación de Requisitos del Software, que también es conocida como pliego. La Especificación de Requisitos del Software o pliego es un documento en el que deben especificarse, de forma absolutamente desglosada, los requisitos funcionales y no funcionales del software, anexándose al contrato.

Un requisito funcional es conocido también en la literatura informática como un caso de uso, es decir, una acción o funcionalidad concreta que pueden ejecutar uno o varios usuarios y que consiste en una consulta sobre el estado del sistema o produce un cambio en el estado del sistema. Los requisitos funcionales se componen de varias acciones secuenciales, es decir, de una sucesión de pasos que el usuario debe ejecutar para conseguir llevar a cabo la acción del caso de uso. Los requisitos funcionales deben tener un código alfanumérico que los identifique de forma unívoca en el documento de Especificación de Requisitos del Software.

Un requisito no funcional es todo aquél que no describe información a almacenar ni acciones a ejecutar, es decir, que no consulta estados del sistema ni produce cambios en el mismo. Por tanto, un requisito no funcional describe una característica o atributo del sistema, como por ejemplo directrices sobre el rendimiento, la seguridad, la disponibilidad, la escalabilidad, la concurrencia, la portabilidad, el sistema gestor de base de datos que va a ser utilizado, el entorno tecnológico del proyecto, la metodología de desarrollo del mismo, etc. Los requisitos no funcionales deben quedar también totalmente identificados en el anexo de Especificación de Requisitos del Software.

 

Respecto a la forma del contrato y sus implicaciones jurídicas, existe una disyuntiva legal entre si el contrato de realización de un proyecto software debe ser considerado un contrato de prestación de servicios o un contrato de obra. Tradicionalmente, el contrato de realización de un proyecto software ha sido considerado un contrato de prestación de servicios, aunque recientemente y, debido a la Sentencia de 20 de enero de 2009 del Juzgado de Primera Instancia Número 5 de Vitoria, puede llegar a ser considerado como un contrato de obra. En este caso, se trataba de la implantación de un software ERP SAP de acuerdo a los procesos de negocio de la empresa cliente y conforme al resultado de la fase de análisis, por lo que se condenó a la empresa adjudicataria por considerarse que, en un contrato de obra, la ejecución de la misma debe estar orientada al resultado, por lo cual no se puede abandonar la obra hasta que ésta no haya concluido exitosamente, mientras que en un contrato de prestación de servicios, lo importante es el trabajo en sí, sin tener en cuenta el resultado que éste produce. Recientes sentencias del Tribunal Supremo consideran el contrato de realización de un proyecto software como un contrato mixto entre prestación de servicios y arrendamiento de obra, por lo que conviene a cada una de las partes (cliente y prestador de servicios) conocer con anterioridad y con el correcto asesoramiento técnico y legal, qué tipología de contrato es aplicable en cada parte del mismo.

Debido a la consideración, al menos en parte, del contrato de realización de un proyecto software como contrato de obra, la fase de implantación del proyecto es fundamental para la conclusión del mismo de forma exitosa. En la fase de implantación, se pone en servicio el software y se deja listo para que los usuarios puedan utilizarlo, por lo que es necesario que el equipo de despliegue lo instale y configure correctamente y, una vez concluida la instalación y la configuración del sistema y, comprobado que éste funciona correctamente después de la realización de las pruebas SAT, el responsable del proyecto en el cliente firme el documento de aceptación de la entrega del software. La firma de este documento no implica perjuicio alguno sobre las incidencias que pudiesen surgir en los primeros estadios de la utilización del sistema y que deben ser corregidas siempre de acuerdo al contrato de realización del proyecto software.

Es necesario dejar claro también, sobre todo de cara a un posible litigio en el que un perito informático deba verificar el incumplimiento del contrato por alguna de las partes, que un contrato de desarrollo de un proyecto software no es un contrato de mantenimiento. Es decir, en el contrato de desarrollo del proyecto software deberá especificarse un periodo de garantía en el cual se corregirán las incidencias detectadas, pero en ningún caso dicho mantenimiento deberá extenderse más allá del periodo de garantía, al igual que tampoco deberán realizarse en este periodo, bajo ningún concepto, modificaciones funcionales en el software que no hayan sido especificadas en el contrato. Por tanto, el mantenimiento de un proyecto software deberá realizarse siempre bajo el paraguas de otro contrato distinto al contrato de desarrollo.

 

Sí, aún tomadas todas las precauciones contractuales, se produce un litigio y una de las partes demanda a la otra por incumplimiento de contrato, el perito informático deberá estudiar en profundidad el contrato y sus anexos y, entre ellos, principalmente, el de Especificación de Requisitos del Software. Asimismo, el perito informático también deberá comprobar, siempre que sea posible, el funcionamiento del software implantado en el cliente, o en alguna máquina de pruebas del proveedor, en caso de que éste sea el demandante y el cliente demandado no permita al perito informático la realización de las pruebas al objeto de redactar el informe pericial informático. Es necesario tener en cuenta que, en caso de que el contrato y/o el anexo de Especificación de Requisitos del Software sean poco prolijos o este anexo ni siquiera exista, será muy probable que el perito informático deba realizar, en su informe pericial, una autentificación de los correos electrónicos mantenidos entre el cliente y el proveedor, para lo cual será, a su vez, muy probablemente necesaria, la clonación de los discos duros en los que se encuentren almacenados dichos correos electrónicos, encareciendo por tanto el coste final del peritaje informático.