13 Sep Peritaje informático APP
En este artículo quería explicar algunas cuestiones de una de las últimas periciales informáticas que he realizado, Peritaje informático APP. Estamos ante un partner que es contratado para la realización de un proyecto en modalidad desarrollo ágil, en un proyecto de aproximadamente un año y llevando el mismo a éxito hasta prácticamente el 10 mes, donde el cliente decide no abonar el resto del proyecto por una serie de cuestiones que ahora nombrare.
Peritaje informático APP
Las app a desarrollar dependen de una capa de servicios web propiedad del cliente que estas app como capa de interfaz de usuario consumirán. Es decir, las app utilizan funcionalidad que el cliente ya tiene implementada. En este sentido si una funcionalidad que se necesita utilizar desde la app y que el cliente ya tiene desarrollado no funcionara, la responsabilidad seria del cliente.
En este caso mi labor, de parte del partner, supone analizar el timeline del proyecto, desde que el partner presenta la oferta, se contrata y se inicial, pasando por todos los sprints realizados a lo largo del proyecto, así como las causas que describe el cliente para finalizar y no abonar al partner el resto del proyecto.
Entendamos que un proyecto realizado en modalidad SCRUM se realiza de la siguiente manera a “grosso modo”:
- Cliente y partner pactan la idea del proyecto, las líneas funcionales básicas que se quieren abordar, estimando el partner una serie de jornadas que plantea como proyecto y por tanto como presupuesto al cliente.
- El proyecto se desarrolla en fases cortas (2-3-4 semanas) que se denominan sprints, donde de mutuo acuerdo partner y cliente deciden que se desarrollará. Se baja a detalle y se especifica exactamente que se realizara en esas semanas.
- Se desarrollan las funcionalidades pactadas y se plantea de nuevo que se realizara o en que se centrara el trabajo las siguientes semanas.
Este sistema de trabajo tiene muchas ventajas ya que:
- El cliente ve resultados a corto plazo.
- Si surgen cambios de requisitos el cliente puede introducirlos como prioridades en esas fases (sprints)
- El proyecto centra su esfuerzo en los más importante y urgente, según mutuo acuerdo.
Entendamos que cuando un cliente y un partner firman este tipo de colaboración tácitamente están firmando varias cuestiones que afectaran a la relación contractual del proyecto:
- La responsabilidad de lo que se va realizando es mutua. Ambos acuerdan las prioridades constantemente.
- Si alguna funcionalidad es superflua o cambia o deja de ser interesante se obvia y no se desarrolla, de nuevo de mutuo acuerdo.
- El proyecto no tiene una definición exacta desde el primer día, sino que se parte de una idea funcional básica y se va complementando y perfeccionando como se avanza el proyecto.
En este caso el cliente, desde mi punto de vista comete varios errores en las razones que esgrime al dejar de abonar las últimas facturas al partner, razones que quisiera seguidamente compartir:
- “Ciertas funcionalidades no se han desarrollado”. Por ejemplo, podríamos indicar en el funcional inicial que queremos una app con login con cuenta de Google, Facebook etc pero durante el desarrollo del proyecto no priorizar el login con cuenta de Facebook. Acabados las jornadas contratadas esta queda fuera porque de mutuo acuerdo en cada sprint no ha sido considerada como fundamental o como prioridad.
- “Existen bugs que deben resolverse” Debemos entender que la Ingeniería de Software describe que no existe ningún software recién realizado sin bugs o algún error. Si estos son mínimos o son contemplados en el contrato como garantía, así como se denota que el partner ha resuelto siempre todos los errores que han surgido, el cliente debería entender que la curva de desarrollo software tiene una cola relativa a bugs que tiene a cero en algún momento pero que no es cero.
- “La app tiene errores en las llamadas a la API” Entendamos que la API debe funcionar siempre, si no lo hace así el trabajo del partner se verá gravemente afectado. Por ejemplo, si el cliente expone una pasarela de pago que las App que desarrolla el partner deben utilizar pero presenta un funcionamiento intermitente, la responsabilidad de que esa pasarela de pago no funcione será del cliente no del partner.
Existen otras cuestiones que se encontraron en la pericial y que defenderé en sala judicial próximamente que, desde mi punto de vista, aclaran con contundencia las evidencias que demuestran que el partner trabajo siempre de forma profesional y colaborativamente con el cliente.
Luis Vilanova Blanco.
Perito informático colaborador con la justicia. www.ciberseguridad.com
606954593