Universidad Nacional Autónoma de México
Dirección General de Servicios de Cómputo Académico
Año 7 Núm. 74, Publicación Mensual, 27 de Noviembre de 2008

ARTÍCULOS

 

Año 5, Número 45, Enero de 2006

Sugerencias para la elaboración de contratos informáticos
para el desarrollo de software

Marcela Peñaloza Báez

 

El éxito en los proyectos de desarrollo de software a la medida depende, en gran medida, de que el trabajo entre el cliente y el desarrollador se encuentre debidamente normado. En este sentido, es un factor reconocido de éxito para estos proyectos formalizar los acuerdos entre ambos, las especificaciones del trabajo por desarrollar, precios, términos y condiciones, entre otros elementos. Cuando el cliente y el desarrollador forman parte de organizaciones distintas, normalmente se firma un contrato informático ad hoc. En este artículo presentaremos algunos aspectos y características especiales por considerar en la elaboración de este tipo de contratos.

Comencemos por revisar las principales ventajas de cuidar la elaboración de un buen contrato informático para el desarrollo de proyectos de software:

  • Describe técnica y legalmente las actividades por desarrollar, de manera que un buen contrato debe evitar que dichas actividades queden sujetas a la interpretación de cualquiera de las dos partes: el cliente y el desarrollador. En esta descripción debe emplearse, en el mayor número de aspectos, mecanismos cuantitativos, para que la evaluación del cumplimiento pueda ser objetiva.
  • Promueve la definición más exacta posible del producto a desarrollar, pues un buen contrato debe incluir relaciones completas y claras de los requerimientos y especificaciones del software que se construirá, así como mecanismos de control tales como los criterios para su aceptación a la entrega final, y el plan de pruebas para corroborar su funcionamiento.
  • Documenta los acuerdos verbales tomados por las partes, antes de la firma del instrumento legal, y proporciona un marco de actuación para los acuerdos que deban tomarse durante el desarrollo del contrato. De esta manera, dichos acuerdos y los compromisos asumidos no podrán ser cambiados ni por el tiempo ni ante eventos futuros, a menos que el mismo contrato indique cómo puede haber modificaciones. Esto es particularmente útil para el caso de tareas de cuya terminación dependa el desempeño de la otra parte; por ejemplo, de la aprobación de un diseño formal por parte del cliente depende el inicio de las actividades de programación por parte del desarrollador.
  • Ayuda a proteger tanto al cliente como al desarrollador ante cualquier “desastre” potencial, lo que previene eventos y riesgos desde la negociación inicial y la definición del producto por desarrollar. Ejemplos de estos sucesos son los cambios de personal clave para el proyecto, por cualquiera de las partes, casos de fuerza mayor, desastres naturales, huelgas, cambios en los requerimientos o especificaciones, terminación anticipada, en fin, situaciones que pudieran enrarecer el proceso de desarrollo e implementación del software.
  • Define la forma en que se dará por terminado este proyecto y, por lo tanto, la relación legal entre el cliente y el desarrollador, cualquiera que sea el resultado y la forma de finalización (normal o anormal), protegiendo el interés común, y aún incluyendo sanciones por incumplimiento de cualquiera de las partes.
  • Promueve la participación, comunicación e involucramiento de ambas partes para el desahogo y seguimiento de actividades durante el desarrollo del proyecto, y previene la manera de resolverse los posibles conflictos entre el cliente y el desarrollador.

En este orden de ideas, es sumamente conveniente hacer las siguientes preguntas para comprobar que un contrato de desarrollo de software cumple con las características deseables en instrumentos de esta naturaleza, particulares a este tipo de proyectos:

  • ¿Se incluyeron requerimientos y especificaciones detalladas como parte del contrato, o serán construidas y validadas como parte del proyecto contratado? ¿Se hicieron explícitas las exclusiones, esto es, lo que no incluirá el producto final, o lo que no se contemplará durante el desarrollo del proyecto?
  • ¿Qué productos de trabajo, además del sistema de información, van a ser generados? ¿Están amparados por el contrato? ¿Cuál será su contenido? ¿Cuál será el procedimiento para aceptar cada uno de los productos? ¿Cómo se comprobará que cumplen con lo comprometido?
  • ¿Se establecieron en el contrato controles para los cambios en requerimientos y especificaciones?
  • ¿Se dividió el proyecto en fases y se elaboró un calendario de actividades?
  • ¿Bajo qué mecanismos y procedimientos, y con qué frecuencia, se dará seguimiento conjunto al proyecto?
  • ¿Se estableció quién retiene la propiedad del código fuente “original”, creado para el proyecto? ¿Quién retiene la propiedad del código que el desarrollador incluye en el producto, pero que forma parte de sus librerías, y si es el caso, si le va a proporcionar al cliente documentación de esa parte?
  • Si el desarrollador se hace responsable de la corrección de defectos, ofreciendo algún tipo de garantía, ¿se especifican en el contrato los escenarios para las correcciones, y el tiempo comprometido para hacerlas?
  • ¿Quién será el responsable de la instalación, y en general, de las actividades de implantación del sistema? ¿Dónde residirá el sistema en las instalaciones del cliente, en qué servidor y bajo qué condiciones para la operación del software?
  • ¿Quién será el responsable del mantenimiento al sistema? ¿En su caso, contará el cliente con los elementos suficientes y necesarios para poder abordar las tareas de mantenimiento?
  • ¿Quién será el responsable de la operación del sistema? ¿Contará con los elementos suficientes y necesarios para realizar sus tareas?
  • ¿Se firmarán acuerdos de confidencialidad? ¿Cuáles son las implicaciones para el desarrollador y cuáles para el cliente?
  • ¿Se ha protegido la relación laboral con el personal de cada una de las partes, y las posibles contrataciones de miembros del equipo del desarrollador, por parte del cliente?
  • ¿Se han definido las pruebas a que será sometido el producto final? ¿Quién las llevará a cabo?
  • ¿Cuáles son los criterios para aceptar el producto final? ¿Quién es el responsable de determinar si se cumplen o no? ¿Qué mecanismos protegen tanto al cliente como al desarrollador de los posibles desacuerdos al determinar el cumplimiento de los criterios de aceptación?
  • ¿Se estableció un plan de pagos acorde con la programación de entregas de productos parciales y finales?

Confío en que los elementos presentados en este artículo sirvan como base para que el lector pueda hacer una reflexión sobre la importancia de establecer un marco legal y normativo adecuado, que permita tanto al cliente como al desarrollador, alcanzar el éxito en el desarrollo del proyecto de software. El mejor contrato siempre está sobre la mesa para guiar ya sea al cliente o al desarrollador hacia la terminación exitosa del proyect o; un mal contrato casi siempre sale a la luz cuando hay conflictos, y generalmente, no contribuye a solucionarlos.

Inicio | Contacto |