El ánalis funcional en los contratos de software

Imagen compartida por Christian Ferrari (Italia)

El análisis funcional es el documento en el que se detallan las especialidades del programa de ordenador o página web cuyo desarrollo es contratado.

La principal ventaja de contar con un análisis funcional adecuado es la de minimizar las divergencias en estética y funcionalidades que puedan surgir entre cliente y desarrollador. Sin embargo, elaborar un análisis funcional correcto es complejo y requiere de una alta cualificación técnica, recursos y tiempo, por lo que el desarrollador deberá conocer en qué casos y en qué momento es conveniente elaborar y entregar al cliente este documento.

Condicionan el momento y la entrega al cliente de un análisis funcional los siguientes factores:

  • Complejidad del proyecto: A pesar de que siempre es recomendable contar con un análisis funcional, éste cobra especial importancia en desarrollos complejos y en aquellos que exigen la personalización nuclear del resultado, debiendo en estos casos realizarse la entrega del documento con carácter previo a la perfección del contrato. La elaboración del análisis funcional debe ser fruto del trabajo conjunto y colaborativo de ambas partes.
  • Precio del encargo: Este factor no debería ser condicionante de la entrega de un análisis funcional. Sin embargo es habitual y comprensible que en desarrollos a cambio de precio reducido se omita el análisis funcional sustituyéndolo por una colaboración contractual entre cliente y desarrollador, limitando el alcance del desarrollo a un tipo o especie determinado de programa ajustado al precio pactado. No obstante, puede pactarse que, definido el objeto, el desarrollo concreto del análisis funcional se lleve a cabo tras el acuerdo de voluntades pudiendo ser entonces el cliente el que declare los detalles de sus pretensiones y el desarrollador quien limite las acciones al presupuesto acordado (artículo 1255 del Código Civil, en adelante, CC). Estas limitaciones sobre el desarrollo habrán de fijarse de mutuo acuerdo, si así se ha establecido en el contrato, y no podrán versar sobre el núcleo del mismo en sentido estricto sino en detalles de elaboración, aun cuando estos detalles sean necesarios para el desarrollo del objeto en alguna de sus fases (art 1273 CC). De no haberse pactado dicho consenso post-contractual, la determinación de detalles podría llevarse a cabo unilateralmente por el desarrollador puesto que aquellos no afectan de forma esencial al objeto del contrato; sin embargo, la buena fe contractual y la necesidad de actuar conforme las indicaciones del cliente hacen preciso un mínimo de consenso para el buen fin del contrato. Por último, en caso de que la precisión de detalles sea de absoluta y vital relevancia y condicionara de forma irremediable el cumplimiento del objeto del acuerdo de voluntades precisamente por constituir parte esencial de dicho objeto, no habría contrato hasta alcanzar dicho consenso como consecuencia de la falta de concurrencia efectiva de objeto y, por ende, de consentimiento, siendo ambos requisitos sine qua non para la existencia de contrato, junto con la causa (art 1261 CC).
  • Tipo de contrato: La contratación de horas de programación no requerirá, por lo general, la elaboración de un análisis funcional. Cosa distinta es la contratación de desarrollos informáticos.

La ausencia o imprecisión del análisis funcional provocan un número elevado de conflictos entre clientes y desarrolladores: retrasos en los plazos de entrega, programas o páginas incompletas, funcionalidades distintas a las queridas… y, en general, malestar y frustración en ambas partes.

Para aquellos casos en los que el análisis funcional falte o sea impreciso, los límites del desarrollo pueden fijarse conforme los parámetros que se indican a continuación:

  1. Contrato – Precio: La contratación de servicios de programación puede hacerse por horas o por objetivos. En caso de contratación por objetivos, si éstos son difusos se podrá atender a las conversaciones precontractuales para fijar el alcance del objeto del contrato (art 1282 CC). Y si por medio de éstas tampoco fuese posible determinar el alcance real del encargo, se entenderá que el resultado debe ser acorde con el precio, según los usos y costumbres del sector (art 1167 CC). Por tanto, un encargo de 50.000€ para la realización de un advergaming para el cual no hayan sido fijadas las claves de producción con carácter previo ni simultáneo a la celebración del contrato debe dar como resultado un advergaming de 50.000€ (art. 1283 CC), valorado según los usos y costumbres del mercado (art 1287 CC). Con posterioridad, el cliente puede señalar las líneas deseadas de desarrollo pudiendo el desarrollador limitar su producción a aquella que corresponda con el precio pactado. Como he referido más arriba, estas limitaciones habrán de fijarse de mutuo acuerdo.
  2. Objeto del contrato: El objeto de un contrato de desarrollo de software puede contemplar la realización de un software genérico que cumpla especificaciones básicas queridas por el cliente o, por el contrario, ser otorgado para la ejecución y consecución de un determinado programa informático con características muy específicas y para una finalidad única. En el primero de los casos bastaría con una hoja de encargo básica (arts. 1262 y 1278 CC) o un correo electrónico para que pudiera ser exigido al desarrollador el cumplimiento del contrato (art. 23 de la Ley 34/2002); en cambio, si el resultado requiere de una especialización y una precisión superior a la genérica, tal y como sucede con programas de simulación destinados a la formación de personal, el cliente está necesariamente obligado a aportar todas las indicaciones y claves que desee lograr con el programa (art 1278 CC). En este segundo caso de desarrollo personalizado, la falta de entrega de instrucciones precisas y concretas por parte del cliente supone un incumplimiento del contrato (art 1091 CC) que probablemente impedirá al desarrollador ejecutar en tiempo y forma el encargo (art 1129 CC); en ciertos supuestos podrá suponer la nulidad del contrato por falta de objeto o por la imposibilidad de resolver las dudas por medio de reglas de interpretación (art. 1289), sin perjuicio de las indemnizaciones extracontractuales que se deban satisfacer, en su caso.
  3. Ejecución de encargo personalizado sin haber recibido claves: En caso de que el desarrollo solicitado por el cliente sea de tipo personalizado, desde el inicio del plazo de desarrollo concedido y mientras no se reciban las claves queridas en el resultado, se exige al desarrollador diligencia en el cumplimiento de sus obligaciones contractuales, entendida ésta como el inicio del desarrollo de aquellas partes del programa informático no supeditadas a las claves tales como el núcleo del programa, preparación del entorno de programación y análisis previos (art 1258 CC). El cliente deberá entregar las claves del desarrollo bien en el acto de contratación, bien en un breve plazo posterior al acuerdo de voluntades que permita de forma razonable el cumplimiento en plazo del objeto del contrato.

Cada caso es distinto y deberá ser analizado de forma individualizada; sin embargo, siempre es posible encontrar criterios basados en Derecho que permitan resolver el conflicto sin que sea necesario llegar a tribunales, ya sea por mediante transacción, ya a través de mediador.

La elaboración de un análisis funcional debe llevarse a cabo por un profesional con experiencia en el desarrollo solicitado. Por tanto, el índice que facilito a continuación es meramente orientativo:

ÍNDICE DE ANÁLISIS FUNCIONAL

  1. Introducción
    1. Empresa desarrolladora
      1. Quién es
      2. Servicios que ofrece
      3. Acreditaciones, credenciales, sellos de calidad, garantías
    2. Definición práctica del proyecto. Indicación de entregables.
    3. Recursos destinados al proyecto. Tipos, disponibilidad y plazos.
      1. Recursos propios
      2. Recursos de terceros (externalizados)
      3. Recursos exigidos al cliente
    4. Requisitos técnicos
      1. Servidor del cliente
      2. Usuarios del cliente
    5. Garantía
  2. Análisis funcional
    1. Definición técnica del producto
    2. Elementos técnicos
      1. Indicación básica del modelo técnico de funcionamiento del programa
      2. Tipología potencial de archivos y bases de datos
      3. Peso aproximado del proyecto total
      4. Tiempos de carga máximos garantizados
    3. Elementos estéticos.
      1. Propiedad intelectual e industrial: Origen potencial de las creaciones y elementos integrados e integrantes
    4. Elementos funcionales:
      1. Secciones y áreas
      2. Mapa de navegación
    5. Experiencia de usuario
      1. Diseño y arte conceptual.
        1. Look & feel de cara al usuario
          1. Portal web
          2. Plantillas
        2. Usabilidad
      2. Accesibilidad
      3. Carga y navegación
    6. Administración
      1. Seguimiento y monitorización de la navegación del usuario
      2. Control y gestión de cuentas
      3. Seguridad de la información
      4. Look & feel de cara al administrador
    7. Integración, capacidades adicionales y desarrollo a futuro
      1. APIs para desarrolladores
      2. Integración bidireccional con redes sociales
      3. Capacidad de crecimiento
      4. Documentación
    8. Cronograma:
      1. Fases de desarrollo y de tareas a desarrollar en cada fase
      2. Plazos
        1. Desarrollo
        2. Implementación:
          1. Adecuación
          2. Implantación
          3. Pruebas de garantía
    9. Detalle del presupuesto

El profesional encargado de la elaboración del análisis funcional sabrá qué puntos del análisis funcional debe desarrollar y con qué extensión, en función de su experiencia, el cliente, el proyecto, el precio pactado y otra serie de factores prácticos que valorará en cada caso.

Nota: Por un fallo en la red he tenido que escribir este artículo entero dos veces…

Donate Dogecoins: D6FeXYibky3XY5Pq8ig5BPdM9RECthAmQw Whats This?
Dejar un comentario?

1 Comentarios.

  1. Recientemente un cliente nos ha solicitado el desarrollo de una aplicación para móviles que no representa nada novedoso, pero nos ha hecho firmar un contrato con la siguiente cláusula: ” Entregar a la finalización del sistema informático desarrollado, las fuentes correspondientes de el mismo, pasando a ser propiedad exclusiva del cliente”
    Por la inexperiencia y las prisas lo firmamos, pero nos encontramos que para realizar esta aplicación utilizamos librerías que son comunes y de código abierto, código que utilizamos normalmente en todos nuestros proyectos como el backoffice, etc…
    Mi pregunta sería la siguiente:
    Con tan sólo incluir esta cláusula sin más explicación todos los derechos de propiedad pasan a ser del cliente? Y en el caso de las partes del código que utilizamos habitualmente en todos los proyectos, como gestión de usuarios, catálogo de productos, etc… tendremos un problema para continuar utilitzando?
    La verdad es que nos ha dejado preocupados el tema. Alguien nos puede aconsejar?
    Gracias

Deja un comentario