Introducción

En esta época de avances tecnológicos, la informática, la cibernética y la computación no son materias al margen de las ciencias jurídicas. La contratación de proyectos de desarrollo de software, la piratería de programas y de la información, y los derechos de autor sobre productos de software, son algunas de las actividades y eventos regulados por el derecho informático o donde la informática se aplica al derecho. No obstante, esta es aún una rama del derecho incompleta y en proceso de extensión permanente. El avance impetuoso del desarrollo tecnológico y su aplicación directa en la vida, ha motivado que el derecho esté desfasado respecto a estos fenómenos que también debe regular. En la informática aún puede palparse un sentimiento de inseguridad, por falta de regulación específica y de un control efectivo respecto de todas las actividades que inciden en la materia en Cuba.

En el año 2002 y como resultado del acelerado desarrollo de las Tecnologías de la Información y las Comunicaciones (TIC), surge la Universidad de las Ciencias Informáticas (en lo adelante, UCI) en La Habana, Cuba; que como expresara Fidel Castro Ruz, en el Discurso de Clausura del VIII Congreso de la Unión de Jóvenes Comunistas; «va obteniendo rápidamente significativos logros en la enseñanza y en la actividad productiva» (^{Castro, 2004}, p. 23). Sus misiones, que son las de formar profesionales, comprometidos con su Patria, altamente calificados en la rama de la informática y producir software y servicios informáticos sirviendo de soporte a la industria informática, a partir de la vinculación estudio-trabajo-investigación como modelo de formación, constituyen los pilares de las actividades que en esta institución se desarrollan. Es un centro creado para hacer realidad la idea de convertir las producciones intelectuales en uno de los principales renglones de la economía cubana.

La UCI, fue concebida y constituida como un centro docente-productor de software, con un modelo de formación desde la actividad laboral-investigativa en el área de las ciencias informáticas, en la que se forma un capital humano especializado, investigando y produciendo aplicaciones y servicios informáticos para la sociedad cubana y para el mundo. En ese marco y en cumplimiento de su encargo social, la institución ejecuta en la actualidad, importantes proyectos asociados a las TIC. En dicha universidad, el proceso productivo¹ anualmente ejecuta; según los Informes del balance de esta actividad, disponibles en (UCI-VRP, 2014) (UCI-VRP, 2015); más de 100 proyectos de desarrollo de aplicaciones y/o servicios informáticos, donde más del 40 por ciento de estos, tienen carácter comercial a través de la firma de contratos con clientes externos.

Con la ejecución de estos proyectos, la actividad legal adquiere una importancia vital, por cuanto sirve de soporte a sus procesos de negociación, ejecución y cierre, estando presente, por tanto, en todo momento del ciclo de vida del proyecto. El desarrollo de los mencionados proyectos, obliga y da la conveniencia de contar con una adecuada gestión legal para el cumplimiento del régimen jurídico establecido en el país e internacionalmente. Esto permitiría, con el uso correcto de las normas y regulaciones, lograr minimizar incumplimientos o violaciones de la legalidad que puedan darse lugar como parte de la actividad de desarrollo de software.

A partir de la documentación revisada de los proyectos productivos del período 2006-2017 en la universidad, así como el intercambio con los asesores legales y especialistas que se han desempeñado como jefes de proyectos; que participan en el desarrollo de software y servicios informáticos, se hizo necesario conocer el nivel de conocimiento para una adecuada gestión legal de los proyectos, todo esto con independencia de la metodología de desarrollo de software que sea seleccionada para guiar el proceso.

Proceso, proyecto, producto y persona en la industria de software

Proceso, proyecto, producto y persona son reconocidos por la literatura como componentes de la producción de software y se les conoce en la comunidad científico-profesional de las ciencias informáticas como «las cuatro “P”», tal y como se muestra en la figura 1. (^{Sommerville, 2011}), (^{Pressman & Maxim, 2015}), (^{Alami, 2016}), (^{Ciudad, 2016}) (PMBOK, 2017), (^{Radujkovića & Sjekavicab, 2017}), (^{González, 2017}), (^{Gellweiler, 2017}), (^{Iden & Bygstad, 2018}) y (^{Keegan, Ringhofer, & Huemann, 2018}) analizan en sus trabajos estos componentes.

El proceso de software es conceptualizado como aquella «secuencia de actividades que conducen a la elaboración de un producto de software». (^{Sommerville, 2011}, p. 9), y un proyecto es definido como «aquel esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único». (PMBOK, 2017, p. 4). Las personas son los principales autores de un proyecto de desarrollo de software en los diferentes roles como arquitectos, desarrolladores, analistas y el personal de gestión, mientras que el producto puede concebirse como aquellos artefactos que se crean durante el ciclo de vida del proyecto, que pueden ser genéricos, personalizados (o a la medida). (^{Sommerville, 2011}, p. 6-7).

(^{Pressman & Maxim, 2015}, p. 685) plantean que la “organización eficaz de la gestión de proyectos de software se enfoca sobre las cuatro P: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que olvida que el trabajo de ingeniería del software es una empresa altamente humana nunca tendrá éxito en la gestión de proyectos. Un gestor que fracasa en alentar la comunicación amplia con los participantes en etapas tempranas de la evolución de un proyecto se arriesga a construir una solución elegante para el problema equivocado. El gestor que presta poca atención al proceso corre el riesgo de colocar métodos y herramientas técnicos competentes en el vacío. El gestor que se embarca sin un plan de proyecto sólido arriesga el éxito del producto.”

Figura 1. Interacción de «las cuatro “P”» en la producción de software. 

Fuente: Modificado a partir de (^{González, 2017})

(^{Mantei, 1981}) utiliza siete “propiedades” para determinar la estructura del equipo de proyecto y el enfoque de comunicación que dicho equipo debe utilizar, a saber: (1) dificultad (del problema a resolver y por consiguiente del proyecto como organización para resolverlo), (2) tamaño (del programa que resolverá el problema), (3) duración (del equipo de proyecto como organización social de solución del problema), (4) modularidad (de las tareas a ejecutar para solucionar el problema, lo que versa igualmente sobra la modularidad de la solución del problema y del problema en sí mismo), (5) fiabilidad (hacia los miembros del equipo de proyecto en el cumplimiento de las diferentes tareas), (6) tiempo (requerido para completar una tarea), y (7) sociabilidad (interna entre los miembros del equipo de proyecto y de este equipo con actores externos relacionados con la solución del problema que se resuelve en el producto que se construye).

(^{Sommerville, 2005}), (^{Sommerville, 2007}) y (^{Sommerville, 2011}), considera que la gestión del personal en el proyecto de software está influenciada y debe tomar en consideración un conjunto de “factores críticos”, como son: (1) consistencia, (2) respeto, (3) inclusión y (4) honestidad. Posteriormente, abunda que también influyen un conjunto de “factores genéricos”, a saber: (1) las personas en el grupo de proyecto, (2) la organización grupal y (3) las comunicaciones técnicas y administrativas. Luego argumenta que la comunicación dentro del equipo de trabajo, está determinada por otro grupo de “factores”, como son: (1) tamaño del grupo, (2) estructura del grupo, (3) composición del grupo, (4) el ambiente laboral físico y (5) los canales de comunicación disponibles.

Por su parte (^{Pressman, 2005}), (^{Pressman, 2010}), así como (^{Pressman & Maxim, 2015}), son del criterio que diferentes “variables” influyen en el costo del producto y en el esfuerzo empleado para desarrollarlo, como son: (1) humanas, (2) técnicas, (3) ambientales y (4) políticas. Estos autores consideran a su vez que lo planteado por (^{Mantei, 1981}), ha servido de basamento a los modelos y técnicas actuales ingenieriles para la organización, planeación y estimación de los proyectos de desarrollo de software y del personal involucrados en estos.

La Guía de los Fundamentos para la Dirección de Proyectos en su tercera edición, disponible en (PMBOK, 2004) hace alusión a un conjunto de “factores ambientales” referidos a la empresa, pero relativos a elementos tangibles e intangibles, internos y externos, que determinan e influyen en el éxito de un proyecto. En la cuarta edición de esta obra, disponible en (PMBOK, 2008) se utiliza un enfoque estándar para hacer referencia a estos factores, sumando un total de doce (12) y haciendo referencia a cuestiones de personal, de infraestructura, políticas, de mercado, riesgo, comunicación y de las tecnologías. En su quinta edición, disponible en (PMBOK, 2013), se adiciona un nuevo factor, llegando a un total de trece (13) y referido este último a la distribución geográfica de los recursos e instalaciones utilizados en un proyecto. En su sexta edición, (PMBOK, 2017) adiciona un nuevo factor referido al ambiente psicológico.

Sistematizando lo planteado por (^{Mantei, 1981}), (^{Pressman, 2005}), (Pressman, 2010), (^{Sommerville, 2005}), (^{Sommerville, 2007}), (^{Sommerville, 2011}), (PMBOK, 2004) y (PMBOK, 2008), entendido por estos autores en forma de “propiedades”, “factores” o “variables”; (^{Ciudad, 2011}) propuso una organización de los aspectos que pudieran influenciar en la “estructura” y “dinámica” de un proyecto de desarrollo de software, los que denomina “factores” y los clasifica en “ambientales” y “técnicos”, tal y como se muestra en la figura 2 que sigue.

Figura 2. Factores que influyen en la estructura y dinámica de un proyecto de software. 

Fuente: (^{Ciudad, 2011})

Tanto la comprensión que toma este último autor como fundamento teórico, como su propia propuesta; hacen posible aludir el carácter “irrepetible” y “único” de cada proyecto de desarrollo de software, pero a su vez permite hacer comparaciones entre estos, de ser deseado en un estudio científico.

Se hace necesario entonces, comprender la interrelación que se crea entre la organización, el proyecto y el producto con respecto a la actividad legal presente en cada uno de esos niveles, tal como se muestra en la figura 3. Como se observa, el contrato engloba a juicio de los autores, a la gestión de los aspectos legales del proyecto y a la asistencia jurídica especializada que se ha de brindar, sobre los cuales estaremos planteando nuestras tesis en el presente trabajo.

Figura 3. Interrelación Producto - Proyecto - Organización. 

El tratamiento jurídico a los componentes de la producción de software.

Existen diversas consideraciones y teorías para el tratamiento de los aspectos de la informática desde el derecho. Se puede conceptualizar al derecho informático como “un conjunto ordenado y sistemático de principios y normas, que regulan las conductas, comportamientos, relaciones y los efectos jurídicos consecuencia de la actividad informática, usos, aplicaciones e implicancias legales.” (^{Rodríguez, 2013}, p. 29)

Lo anterior, ha sido analizado por (^{Amoroso, 1994}), (^{Rosenoer, CyberLaw, 1997}), (^{Téllez, 2006}), (^{Hernández, 2006}), (^{Delpiazzo, 2008}), (^{Olivera, 2010}), (^{Rodríguez, 2013}), (^{Fernández, 2014}) y (^{Reusser, 2015}), quienes coinciden en elementos de la anterior definición.

(^{Lourido, 2008}, p. 1) expresó que el derecho, “debido a su talante dinámico y regulador de la vida social, no puede permanecer ajeno a este hecho, y a pesar de que las viejas instituciones jurídicas, capaces de perdurar a través de los siglos asimilando nuevas técnicas y nuevas costumbres, se resquebrajen por momentos ante el fenómeno informático. (…)”. Se coincide en este punto con el análisis de (^{López-Ibor Mayor & García, 1994}, p. 647) al reflexionar que los especialistas tanto de las ciencias jurídicas como de las ciencias informáticas, se encuentran “ante un Derecho nuevo, con un grado incipiente de desarrollo y, por tanto, estamos en presencia de un marco jurídico en vías de formación”. cuestión que los autores sistematizados plantean que persiste hasta la actualidad.

El caso de la legislación y la doctrina jurídica cubana no son ajenas a este fenómeno y a su estado actual, como ha sido planteado desde sus aristas por (^{Amoroso, 1994}), (^{Bencomo, 2008}), (^{Hernández, 2006}), (MIC, 2011), (^{Rodriguez Silva, 2012}), (^{Formentín, 2013}) (^{Amoroso, 2017}) y (^{MINCOM, 2017}).

Como se planteara en la Estrategia de Exportación del entonces Ministerio de Informática y las Comunicaciones, hoy Ministerio de Comunicaciones², es aún latente “la ausencia de un esquema jurídico sólido asociado a la industria de las aplicaciones informáticas, lo que constituye un problema de vital importancia que está en el trasfondo del resto de los aspectos que obstaculizan la consolidación e internacionalización de la industria. Las normativas jurídicas que se aplican a este sector se han quedado rezagadas con relación al desarrollo alcanzado por el mismo en los últimos años.” (MIC, 2011, p. 44).

Por ello en función de lograr un sistema jurídico que armónicamente responda a las necesidades de la industria, se ha planteado por el (^{MINCOM, 2017}, p. 11-12) la tarea de perfeccionar el marco legal, regulatorio y normativo que sustente el desarrollo de las TIC en Cuba, cuestiones en las que actualmente se trabaja.

Por otro lado, desde la visión legal ha sido una preocupación especial de las ciencias jurídicas, la atención a la regulación del proceso de desarrollo de software. Es así que tan temprano como en 1989, el Dr. Téllez Valdés, planteó que “en virtud de la necesaria regulación de los programas de cómputo, por ser considerados estos como verdaderos bienes, ello ha provocado que en la actualidad el problema haya rebasado el estado puramente técnico para convertirse en un problema de índole económica, que amerita la intervención de un régimen normativo provisto por el derecho, a fin de ofrecer un soporte protector conveniente y brindar la seguridad buscada,” (^{Téllez, 1989}, p. 18).

Otras acciones han sido dirigidas a teorizar sobre temáticas relacionadas con la contratación informática, los nombres de dominios, el comercio electrónico, las páginas web, los contenidos y la información; o sea, los datos. Siguiendo la clasificación de (^{Téllez, 1989}, p. 9-11), algunos de los principales aspectos en materia de derecho informático son, entre otros, los contratos informáticos, la protección jurídica del software, bases de datos, multimedia y portales web; la regulación jurídica de la información; la protección jurídica de los datos personales y los delitos informáticos.

Todos estos bienes, se presentan en mayor o menor grado en un proceso de producción de software que se emprenda. Es por ello, que el derecho informático, como rama general del derecho trata de dar soluciones y respuestas a todas las actividades asociadas a las TIC, incluido el proceso de desarrollo. El contrato por su parte, se convierte en una norma individualizada para el desarrollo de un proyecto, mientras que existen normas jurídicas especiales para la atención a los bienes que se crean como producto de los proyectos ejecutados en un proceso de desarrollo de software, tal como se muestra en la figura 4.

Figura 4. Relación aspectos legales con elementos de la producción de software. 

Las principales insuficiencias de estas teorías, residen en no lograr ahondar en los aspectos técnicos del proceso de desarrollo, convirtiéndose la mayor parte de la doctrina en elementos que no pueden ser incorporados por los equipos de proyectos para el desarrollo de su gestión. Es así entonces, que no es posible, para los líderes y otros especialistas de la industria informática lograr una gestión que prevea eficazmente los necesarios aspectos legales, al no contar estos con una formación jurídica ni con herramientas desde lo legal para asegurar su integración al proyecto de desarrollo de software.

Los contratos informáticos: norma “individualizada” para el proyecto de desarrollo de software.

Uno de los elementos de mayor importancia en la gestión legal lo constituyen los llamados contratos informáticos, que han sido tratados desde la teoría jurídica por autores como (^{Peres Soler & Otros, 2004}), (^{Téllez, 2006}), (^{Hernández, 2006}), (^{Chávez, 2009}), (^{Loredo, 2011}), (^{Fernández, 2014}) y (^{Reusser, 2015}).

Aspectos como su compleja estructura, sus tipologías, sus fuentes, la especificidad de los aspectos técnicos que son tratados, la imprecisión del vocabulario técnico-jurídico, la necesaria fase precontractual o de negocios; son objeto de sus estudios, en los que buscan lograr la combinación de los conocimientos jurídico e informático de tal forma que se logren concentrar convenientemente en un contrato informático.

Un contrato, puede ser resumido, como el acuerdo de dos o más voluntades para crear, transmitir, modificar o extinguir derechos y obligaciones. Cuando el objeto de esos derechos y obligaciones incide en dar, hacer o no hacer algunas de las modalidades de los bienes o servicios informáticos, puede hablarse de contratos informáticos.

Del análisis realizado, se puede comentar que es cierto que se les aplican las reglas generales de los contratos, ya sean civiles o mercantiles, siendo difícil hablar de reglas que deban aplicarse de manera específica, a esta materia; pero que existen, como son:

Es claro que para la elaboración de los contratos es necesaria la asesoría jurídica especializada, pero es vital que los jefes de proyectos conozcan los elementos del negocio o producto a crear y, que esto quede escrito en detalles en los documentos técnicos y comerciales relacionados con el proyecto. Por tanto, para lograr una actividad legal que responda de forma rápida y eficaz a las necesidades de los equipos de desarrollo, se debe lograr la mayor definición de elementos tales como:

Objeto del proyecto: Qué es lo que se quiere hacer o dar al cliente.

Alcance del proyecto: Hasta dónde llegará el proyecto, en función de las definiciones que den los analistas.

Obligaciones de las Partes: Qué debe hacer el cliente y qué debe hacer el equipo de desarrollo. Pueden ser por cada una de las fases de desarrollo del software y en el despliegue del producto resultante.

Es importante resaltar aquí como expresa (^{Peres & Otros, 2004}, p. 289), que la “principal obligación de la empresa de software es la elaboración e instalación en condiciones de funcionamiento del programa o programas de ordenador dentro del plazo pactado y cumpliendo con los requerimientos pactados.” Asimismo, deben identificarse las obligaciones accesorias.

Duración del proyecto: Ofrece la vigencia del contrato y está en función de las diferentes etapas que se identifiquen por el equipo de desarrollo. La vigencia siempre debe ser mayor que el tiempo estimado del ciclo de vida del proyecto.

Confidencialidad: Define el tratamiento que se le dará al contrato y a los documentos, informaciones, hechos o datos que se relacionen en el presente o futuro con éste.

Protección de datos de carácter personal: En aquellos casos donde se tenga acceso a este tipo de datos, se deben tomar en cuenta las medidas para su protección y no divulgación o utilización por terceros no autorizados.

Asimismo, describir si el sistema permite el tratamiento de este tipo de datos, pues tal como expresa (^{Sáez Peña, 2011}, p. 50) debe “(…) quedar constancia en su descripción técnica de que el sistema permite el tratamiento de datos personales cumpliendo con las medidas de seguridad del nivel exigido.”

Gestión de cambios: Cómo se gestionarán los cambios en el desarrollo del proyecto, dejando claro que, dentro de lo posible, no impliquen requisitos funcionales adicionales.

Es importante precisar estos cambios y su impacto pues coincidimos aquí con el análisis de (^{Peres & Otros, 2004}, p. 37) al plantear que “el impacto de los cambios varía según el momento en que se deseen introducir. Si los cambios se introducen al inicio del desarrollo, podrían acomodarse con relativo poco impacto en el coste del proyecto, contrariamente a si son introducidos hacia el final del mismo. Cuando los cambios se solicitan una vez iniciado el desarrollo del software, el impacto en el coste crece rápidamente.”

Comité de Control, Chequeo o Seguimiento: Cómo quedará constituido el mismo, integrado siempre por ambas partes y la forma en que se le dará seguimiento a la gestión del proyecto

Pruebas: Cómo se realizarán las pruebas, las condiciones para el desarrollo de los pilotos, si hubieran, y su validación.

Entrega y aceptación: Cómo se desarrollará la entrega de las aplicaciones y la aceptación por parte del cliente.

Propiedad intelectual: Tratamiento que se dará a los activos intangibles que se darán lugar por el desarrollo del proyecto, especificando a nombre de quienes se producirá el registro de estos productos.

Es vital establecer desde el principio a quien corresponde la titularidad de los desarrollos y los derechos que le acompañan. ^{(Peres & Otros, 2004}) y (^{Mendoza, 2015}).

Licencias de uso: Precisar el uso legal que se le podrá dar al software creado y las limitaciones en caso de haber utilizado herramientas de terceros.

Contenidos: Precisar el respecto a los derechos de terceros en el uso de herramientas y/o contenidos que no sean de la titularidad de la entidad.

Se debe ser consciente como plantea (^{Stella Rodríguez, 2000}, p. 98) que “el software que esté protegido por derecho de autor o patentes no puede ser utilizado sin el permiso del propietario y, más probablemente, sin abonar los derechos correspondientes.”

Limitación de la responsabilidad: Constituye la limitación de la responsabilidad con las aplicaciones cuando a éstas se hagan cambios, modificaciones u otras alteraciones como la ingeniería inversa en el código fuente de la misma.

Despliegue: Cuáles son las condiciones mínimas que deben existir para la implantación del software desarrollado.

Acompañamiento, Entrenamiento y Transferencia: Determinar los elementos a transferir al cliente, siendo casi siempre el código fuente y toda la documentación asociada. En este particular es necesario precisar la realización o no de acciones de entrenamiento en el uso y explotación de la aplicación y los términos para el acompañamiento al cliente luego del despliegue.

Garantías: Se deberá precisar el período de tiempo de la misma y cuándo comienza a correr una vez instalada la aplicación, en la que el proveedor deberá atender cualquier fallo existente en la misma, sin costo alguno para el cliente.

Servicio de mantenimiento y/o soporte técnico: Cómo se ejecutará el servicio de soporte técnico a las aplicaciones desarrolladas. Debe dejarse claridad del procedimiento a ejecutar para la prestación de este servicio, así como el inicio y duración del mismo.

Son estos sólo algunos de los elementos que se deben tomar en cuenta en la elaboración de los documentos contractuales del proyecto y en los que el equipo de desarrollo, que debe ser convocado, debe aportar con claridad. El contrato es, por tanto, unos de los primeros elementos a considerar en el tratamiento jurídico a los elementos del proceso de software, no obstante, no ser el único. En él se deberán conjugar los elementos jurídicos y técnicos de forma que el desarrollo del proyecto tenga al mismo como una norma jurídica individualizada.

El producto del desarrollo de software y los bienes intangibles

(^{Núñez, 2002}, p. 2) expresó que “el software, las páginas web, los nombres de dominio, la firma electrónica, los domicilios virtuales, agentes automatizados, entre otros son bienes inmateriales o intangibles. Al igual que los demás bienes a los que se les denomina inmateriales, son la expresión de una idea, fruto de la mente humana, que se plasma en objetos corpóreos, pero con ciertas peculiaridades que es necesario resaltar.”

La teoría desde las ciencias jurídicas en referencia a los bienes intangibles o productos resultantes del proceso y el proyecto de desarrollo de software ha sido prolífera. El software, las bases de datos, las multimedia y los portales web, constituyen algunos de esos bienes. Autores como (^{Amoroso, 1994}), (^{Peñaranda, 2006}), (^{Delgado & Telléz, 2006}), (^{Lessig, 2006}) (^{Ringenbach, 2007}), (^{Téllez, 2009}), (^{Bain & Partners, 2009}), (^{Zalazar, Gonnet, & Leone, 2014}), (^{Reusser, 2015}) y (^{Amoroso, 2017}) han dado tratamiento a los diversos aspectos de estos bienes.

El software y las bases de datos son protegidos y tutelados por el derecho de autor, mismo régimen que se aplica a las multimedia y los portales web. Esta es la solución acogida por la casi totalidad de las legislaciones de Iberoamérica; a saber, Brasil, Ecuador, Panamá, Perú, Argentina, Bolivia, Venezuela, México, y España, entre otras naciones.

En Cuba, gracias al carácter enunciativo del objeto de protección, regulado en el artículo 7 de la Ley 14 de 1977, Ley de Derecho de Autor (ANPP, 1977) y su Decreto Ley 156 modificativo (CE, 1994), los autores de programas de computación y las bases de datos han encontrado los principios generales de tutela de sus derechos. No obstante, debido a la necesidad de contar con disposiciones específicas para estos tipos de obras, fue dictada la Resolución Conjunta No. 1, de 21 de junio de 1999 entre el Ministerio de Cultura y el entonces Ministerio de la Industria Sideromecánica y la Electrónica³ (MINCULT-SIME, 1999), la cual estableció el reglamento para la protección de los programas de computación y bases de datos, en cuanto a su creación, concertación de contratos, así como su explotación comercial. Esta normativa contiene las regulaciones más específicas en la materia, extiende la protección no sólo a los programas originales, sino también a las versiones sucesivas y los programas derivados; y establece las reglas de autoría y titularidad para los autores de estos tipos de obras que realicen sus creaciones de forma independiente, por encargo, o en el marco de un empleo.

Por otra parte, la recopilación, integración, uso, modificación y difusión de los datos que tienen carácter personal están sujetos a la ley y han tenido también un amplio tratamiento en la doctrina jurídica. Siguen estos bienes intangibles una regulación distinta a los archivos y documentos en papel, a pesar de tener, en muchos casos, la misma información y ser igualmente válidos jurídicamente. Por solo mencionar algunos ejemplos, de países que han sido destacados en la emisión de legislaciones específicas reguladoras de este tema, tenemos a España (1993, 1998, 1999, 2003 y 2007), el Reino Unido (1998, 2000, 2002, 2003 y 2004) y Francia (1978, 2004, 2007, 2008 y 2009).

En Cuba no existe aún una legislación específica para su regulación (^{López, 2011}), cuestión que amerita el tratamiento por las instituciones gubernamentales. No obstante, es de vital importancia dejar claridad de la alta responsabilidad del equipo de proyecto al trabajar con este tipo de datos. Por esto, no debe permitirse el acceso de terceros no pertenecientes al proyecto a estos datos y mucho menos ajenos a la institución productora o creadora del software que los utiliza.

La mayoría de la doctrina jurídica se ha encuadrado en observar el desarrollo de software desde la forma contractual, precisando que en el contrato debe quedar todo establecido y por otra parte brindar el régimen legal a los bienes intangibles que se crean en dichos desarrollos. No obstante, no ofrece una vía para observar el cumplimiento de lo dispuesto en el contrato por personal que no sea jurista, ni tampoco ha sido exhaustiva en establecer alternativas a cuestiones que se producen en el proceso de desarrollo, tales como:

Asimilación de los aspectos legales desde la industria de software.

Como planteara (^{Piñero, 2007}, p. 24) “autores como (Pressman 2002; IEE-Computer-Society 2004; Project-Management-Institute 2004) declaran la necesidad del proceso de gestión de contratación dentro del proceso de desarrollo de software. Pressman (…) define roles necesarios para llevar adelante esta tarea entre cinco categorías a jugar dentro del proyecto para aquellos que participan en el proceso del software. Tres de estos se relacionan a continuación: Gestores superiores: que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto. Clientes: que especifican los requisitos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado. Usuarios finales, que interaccionan con el software una vez que se ha entregado para la producción.”

(^{Piñero, 2007}, p. 24) plantea además que “en general la mayoría de [los] modelos de calidad para el desarrollo de software solo hacen referencia a la gestión de contratación como un proceso centrado en momentos específicos del proceso productivo. Pero no se describe detalladamente como desarrollar el proceso a la par de la gestión de proyectos, ni los artefactos y herramientas para desarrollarlo. Aunque es reconocida o mencionada la necesidad de este proceso dentro del desarrollo del proyecto, no se define metodológicamente como llevarlo a cabo.”

(^{Špundak, 2014}), (^{Brioso, 2015}), (PMA, 2015), (^{Monteiro, Santosa, & Varajão, 2016}), (^{Mossalam, 2017}) y (^{Turner, 2018}) argumentan que son varios los modelos para la gestión de proyectos propuestos en el mundo científico.

(PMBOK, 2017) establece una guía que precisa pautas y principios para la gestión de los proyectos informáticos. (PMBOK, 2017, p. 38-41) define dentro del equipo de proyecto como expertos de apoyo “a aquellos que realizan actividades requeridas para desarrollar o ejecutar el plan para la dirección del proyecto. Entre ellas se pueden incluir roles tales como contratación, gestión financiera, logística, asuntos legales, seguridad, ingeniería, pruebas o control de calidad. Dependiendo del tamaño del proyecto y del nivel de apoyo requerido, los expertos de apoyo pueden asignarse para trabajar a tiempo completo o simplemente participar en el equipo cuando se requieren sus habilidades específicas.”

Esta guía, menciona las actividades legales necesarias a ejecutar, describe al área legal como una de las posibles a ser afectadas por el desarrollo del proyecto, introduce las implicaciones legales y contractuales como elementos que pueden incidir en la línea base del alcance y menciona la observancia de las disposiciones legales a la hora de negociar para adquirir el equipo de proyecto. Asimismo, indica la necesidad de asistirse por especialistas legales en las fases iniciales del proyecto o en la gestión de adquisiciones.

(PMBOK, 2017) también define el acuerdo o contrato como una de las entradas del proceso de desarrollar el acta de constitución del proyecto dentro del área del conocimiento de la gestión de la integración, precisando que su fin es el de definir las intenciones iniciales de un proyecto. De igual forma, es mencionado el instrumento legal como otros de los documentos que, aunque no forma parte del plan para la dirección del proyecto, son utilizados por esta para sus labores.

Según (PMBOK, 2017), una de las actividades resultante del proceso “Cerrar proyecto o fase” es la de “revisar la documentación de la fase anterior, la documentación de aceptación del cliente procedente del proceso Validar el Alcance (…) y el contrato (si corresponde) para asegurarse de que todos los requisitos del proyecto están completos antes de finalizar el cierre del proyecto.” Lo anterior evidencia que este documento no deja establecido con precisión qué camino recorrer desde el punto de vista legal, en las actividades que debe desarrollar el equipo del proyecto una vez firmado el contrato, por ejemplo, en lo relacionado con las medidas a tomar para proteger los bienes intangibles que se crean o el tratamiento a dar a las herramientas que se utilizan.

La metodología PRINCE2⁴, disponible en (^{Turley, 2011}), de amplio uso en el Reino Unido para diferentes tipos de proyectos, es “una metodología de gestión de proyectos que cubre la administración, control y organización de un proyecto” (^{Cazorla, 2010}, p. 13). Esta establece el contrato dentro del proceso “Comenzar el Proyecto” y lo visualiza como un elemento de importancia vital para el desarrollo de la gestión, haciendo mención a que el mismo instaura términos de obligado cumplimiento para el proyecto, pero no lo vincula directamente a la gestión del proyecto.

PRINCE2 derivó de la metodología PRINCE, estándar utilizado como modelo de referencia para la gestión de proyectos de TIC, desarrollado por la Agencia Central de Telecomunicaciones y Computación (CCTA)⁵ del gobierno británico y se ha convertido en un estándar de gestión de proyectos en ese y otros países.

Coincidiendo con lo planteado por (^{Cazorla, 2010}, p. 139) en esta metodología “se asume que el proyecto funciona dentro del contexto de un contrato y no incluye esta actividad dentro del propio método. Sin embargo, se sugiere que, ya que las actividades de generar el contrato y obtenerlo son especializadas, pueden llevarse a cabo separadamente utilizando también el método”, cuestiones que permiten al autor aseverar las limitaciones en el uso para la gestión de los aspectos legales. Según (^{Matos & Lopes, 2013}) PRINCE2 se enfoca al producto final, especialmente a su desarrollo y calidad.

Algunos de los métodos ágiles, surgidos como alternativa a los modelos formales, que han sido incorporados por la industria del software bajo los principios del Manifiesto Ágil⁶ son: Agile Database Techniques (AD), Agile Modelling (AM), Adaptive Software Development (ASD), Agile Unified Process (AUP), Crystal, Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Lean Software Development Scrum, Test-Driven Design (TDD), XBreed y eXtreme Programming (XP). Todas ellas, según (^{Palacio, 2008}, p. 32) “han documentado y propagado las formas particulares en las que han implementado los principios de la agilidad en sus equipos de trabajo.”

Para el caso de ScrumManager, por mencionar un ejemplo, (^{Palacio, 2008}, p. 11) establece que es “un marco de gestión ágil, flexible y sistémico para organizaciones basadas en equipos.” Para esta metodología, (^{Palacio, 2007}, p. 50) plantea que el “contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, refleja cómo se han cerrado los requisitos, fechas y costes previstos, como referentes para posibles disputas contractuales entre cliente y proveedor.” Los análisis de (^{Kniberg, 2007}), (^{Martin, 2012}), (^{Špundak, 2014}) y (^{Pressman & Maxim, 2015}) apoyan la afirmación anterior.

En esencia, es una metodología o marco de trabajo, que busca centrar el esfuerzo en partes funcionales, no en procesos de conformidad con procedimientos, por lo que las formalidades de cumplimiento con el contrato, que no existe en la forma tradicional o al menos es bastante flexible, y las demás cuestiones legales se desarrollan aquí totalmente independientes del proceso.

Al revisar las Normas ISO, se ha podido determinar que (ISO 21500:2012(E), 2012), específicamente para establecer un sistema de gestión de la calidad en la industria de software, realiza mención a los elementos legales a cumplimentar en lo pactado con los clientes, en cuanto a requisitos y se precisan como elementos de entrada para el diseño y desarrollo, sin mencionar otro elemento.

En las revisiones realizadas a la documentación del modelo CMMI, (^{Beth, Konrad, & Shrum, 2009}), (SEI, 2010) y (^{Chavarría, Oré, & Pastor, 2016}), se establece que los elementos legales son aspectos que pueden dar como resultado oportunidades de mejora de procesos, cuestiones a observar en el desarrollo de los requisitos del cliente, ejemplos de requisitos y estándares para el empaquetado y la entrega del software y en las gestiones con los proveedores. Es importante mencionar que, en este modelo de trabajo, dentro de su área de proceso de gestión de acuerdos con proveedores que pertenece al Nivel de Madurez 2 considera que, con frecuencia, la gestión de los contratos reside fuera de la gestión de proyectos y asimismo declara que los instrumentos legales siempre deben ser revisados por asesores jurídicos o asesores del contrato antes de su aprobación.

Por otro lado, el área de proceso de CMMI dedicada a la Gestión Integrada del Proyecto (IPM⁷) no refleja en ninguna de sus metas y prácticas específicas cuestiones asociadas a los elementos objeto de análisis en este trabajo. El modelo CMMI, en resumen, hace alusión a la firma de instrumentos jurídicos, pero aun cuando es este un modelo exhaustivo en la definición de los procesos, tareas y documentos a elaborar en cada momento, no se hace mención explícita a los temas legales que se puedan presentar en el proceso de desarrollo del software, considerándolo un proceder externo a la gestión del proyecto.

Por otro lado, guías como las disponibles en (^{Fundación IBIT, 2007}) (INTECO, 2009), (Enlaces, 2011), (^{Luz & Otros, 2013}) y (^{Toro, 2013}) balancean su contenido en indicaciones para las gestiones a desarrollar desde la administración en la adquisición de un producto de software, en cuanto a la negociación, puesta en marcha, supervisión y control del trabajo, rendimiento del trabajo, actividades de gestión de cambios, la gestión de riesgos y el cierre; pero no ofrecen respuestas en lo referente a la gestión integrada de los temas legales al proceso de desarrollo de software.

Como se ha analizado, las diferentes metodologías, marcos de trabajo y guías propuestas por la industria, presentan la gestión de los aspectos legales como un elemento externo al proceso de desarrollo de software, necesario para la ejecución de las actividades, pero no integrado a estas; cuestión que constituye una limitación para el éxito en el desarrollo de software y servicios informáticos. Es necesario lograr un justo equilibrio entre ambos elementos: lo jurídico y lo técnico, de forma que el proceso de gestión tenga integrado los elementos legales necesarios para su mayor seguridad jurídica.⁸

El expediente del proyecto de desarrollo de software.

Las normas y estándares internacionales, accesibles en (ISO 21500:2012(E), 2012), (PMBOK, 2017), (SEI, 2010) y (^{Turley, 2011}); así como los estudios de autores como (^{Peres & Otros, 2004}), (^{Téllez Valdés, 2009}), (^{Delgado Martínez, 2010}), (^{Sommerville, 2011}), (^{Zandhuis & Stellingwerf, 2013}), (^{Alfonso & Mariño, 2013}), (^{Fernández, 2015}), (^{Pressman & Maxim, 2015}), (^{Varajão, Colomo & Silva, 2017}), analizan y valoran la importancia de la documentación asociada al proyecto de desarrollo de software y dedican especial atención al “expediente del proyecto”. Como precisa (^{Sommerville, 2011}, p. 24) “el software no es sólo un programa o programas, sino que también incluye documentación.”

(^{Delgado Martínez, 2010}, p. 33) estableció que “la documentación asociada a los proyectos de software y sistemas debe cumplir con algunos requisitos como son: servir como medio de comunicación entre los miembros del equipo; servir de repositorio de información que pueda ser utilizado por los ingenieros de sistemas; proveer información para el control de los planes, cronogramas e hitos en el proceso de desarrollo de software y definir quién hace y cómo hace las actividades específicas del desarrollo.”

(^{Sommerville, 2011}, p. 61) “estima que la documentación formal describe el sistema y, por lo tanto, facilita la comprensión a quienes cambian el sistema. Sin embargo, en la práctica, con frecuencia la documentación formal no se conserva actualizada y, por ende, no refleja con precisión el código del programa.” Por esto, es necesario e imprescindible, la emisión de indicaciones que precisen las formalidades a seguir en el acopio de la documentación del proyecto y la conformación del expediente de éste, elementos que validan el cumplimiento de las obligaciones contraídas en un contrato.

A partir de lo anterior, (^{Delgado, 2010}) propuso una estrategia para la estandarización de la documentación y las actividades para el desarrollo de software en la UCI, la que incluye un modelo de expediente para los proyectos.

Normativas en la UCI para la gestión de la producción de software y sus aspectos legales.

La UCI ejecuta cada año un importante grupo de proyectos de desarrollo de software. Estos proyectos pueden clasificarse en:

El desarrollo de estos proyectos ha tenido en la UCI dos momentos históricos importantes, matizados fundamentalmente por el modelo de gestión empleado en cada uno de ellos.

Un primer momento se enmarca a partir del año 2005 y hasta el año 2012, donde la UCI se vio incorporada a una fuerte actividad de desarrollo de software para el exterior, sustentada en un esquema empresarial. La UCI en este momento contó con varios proyectos y polos productivos⁹ que respondían a un dominio de aplicación, adscritos a las facultades y otras áreas y dirigidos desde la Infraestructura Productiva¹⁰. Existió un equipo administrativo que estableció las pautas generales para la negociación y gestión de los proyectos, realizó el proceso de gestión de cobros, dio asistencia legal a los equipos, para la firma de los contratos con los clientes e instrumentos jurídicos sucesivos y las precisiones para el archivo de la documentación generada en los proyectos y la ejecución.

Un segundo momento se establece desde el año 2013 y hasta el 2017. En este período bajo indicaciones gubernativas, la UCI comenzó a contratar directamente con sus clientes. La UCI ejecutó un proceso productivo acreditado con el estándar internacional CMMI en su Nivel 2, donde coexisten varios dominios tecnológicos y del conocimiento, agrupados en 14 centros de desarrollo, esencialmente adscritos a las facultades y otras áreas, los que conforman lo que se denomina y funciona como una Red Colaborativa de Centros de Desarrollo. Los proyectos productivos, tanto los nacionales como los de exportación, se realizaron a través de la Red mediante un trabajo colaborativo, en la que en una solución o producto pueden estar implicados varios centros y personal de más de un área institucional.

Contó la UCI aquí con un área para los negocios subordinada a la dirección universitaria, dedicada a la atención a la actividad comercial que reguló las pautas generales para la negociación y gestión de los proyectos, así como realizó el proceso de gestión de cobros. Asimismo, existió una Dirección de Producción de Software que aseguró el cumplimiento de las indicaciones técnicas, la calidad en el proceso y controló la ejecución de los proyectos que se contrataron a la UCI.

Es importante precisar además que, aun cuando han existido estos dos modelos de gestión de los proyectos en la UCI, este elemento no tiene impacto para el estudio que desde las ciencias se realiza en este trabajo sobre la gestión legal de los proyectos, por cuanto el trabajo de asistencia jurídica en ambos momentos ha tenido el mismo alcance en la organización en cuanto a los proyectos. No obstante, si trasciende para lo histórico y lo jurídico, más no trasciende con significado científico a considerar en el objeto que se estudia.

Para el desarrollo de los proyectos, en los años 2002, 2013 y actualizada en el año 2016 se han emitido indicaciones para el proceso, siendo la vigente la Indicación Nº 2 de la VRP de 2016, donde se precisó que la aplicación de la “metodología de desarrollo a emplearse en los proyectos productivos (…) se basa en una variación de la metodología “Proceso Unificado Ágil” (AUP por sus siglas en inglés) en unión con el modelo CMMI-DEV v1.3”, tal y como puede consultarse en (UCI-VRP-DCSW, 2016, p. 4). Según (UCI-VRP-DCSW, 2016, p. 5) alguna de las principales metodologías de desarrollo robustas y ágiles que se utilizan en la UCI son las siguientes: XP¹¹, Open Up¹², RUP¹³, KIMBALL¹⁴, SXP¹⁵, SCRUM¹⁶ y NOVA OpenUp¹⁷. Este mismo documento planteó la necesidad de adaptar una única metodología que estandarice las actividades de los centros de desarrollo de la UCI y los roles, ofrezca agilidad al proceso y garantice la calidad del software que se produce. Esta metodología, presentada con su variación para la UCI, si bien establece una estándar (AUP en este caso) para el proceso de producción y asimismo la vincula con un estándar de calidad (CMMI); no realiza ninguna alusión a la gestión de los aspectos legales, lo cual es una limitante para el desarrollo de esta actividad en los proyectos.

(^{Piñero Pérez, 2007}) propuso para la UCI una “metodología de trabajo para la ejecución de los procesos de gestión de contratación en los proyectos de desarrollo de software educativo”, la que al dirigirse solo a este tipo de proyectos limita su posibilidad de generalización y asimismo cuestiones como la gestión de la propiedad intelectual, son excluidas de la metodología propuesta. Por otro lado, (^{Pérez, 2010}) formuló “una guía que permita seleccionar la información necesaria para la elaboración de contratos informáticos” la que, si bien puede usarse para el fin que describe, deja fuera la gestión del proyecto integrando el tema legal.

Otros como (^{Martinez Chong, 2010}), (^{Santana Méndez, 2010}), (^{Muro, 2011}), (^{Castell González, 2012}), (^{Peña Abreu, 2012}), (^{Goñi, 2012}), (^{Pantoja, 2012}), (^{La Torre, 2013}), (^{González, 2013}), (^{Fernández, 2013}), (^{Torres, 2015}), (^{Fernández, 2015}), (^{Cantero Márquez, 2015}), (^{Marín, 2015}) y (^{Triana, 2015}) proponen diferentes modelos, metodologías y métodos para el proceso de desarrollo de software y/o su gestión para los diferentes dominios de aplicación de la UCI. En ninguno de los casos consultados, se integraron en sus propuestas elementos para la gestión de los aspectos legales del desarrollo de software en el proyecto que se analiza en este trabajo científico.

En la revisión realizada a los Libros de Procesos de CMMI para la producción de la UCI en el Nivel 2: (CMMI 2-UCI-CM, 2014), (CMMI 2-UCI-REQM, 2014), (CMMI 2-UCI-MA, 2014), (CMMI 2-UCI-PPQA, 2014) y (CMMI 2-UCI-PMC, 2016) y (CMMI 2-UCI-PP, 2016), coordinados todos desde la DCSW de la UCI; sólo el libro dedicado a la planificación del proyecto (CMMI 2-UCI-PP, 2016) hace mención a los aspectos legales al asignar como responsabilidades de la alta gerencia y del cliente, la legalización del proyecto y la firma de los documentos legales.

Por otro lado, del análisis de los Libros de Procesos conformados en la UCI para la implantación en el proceso productivo del Nivel 3 de CMMI: (CMMI 3-UCI-RD, 2016), (CMMI 3-UCI-PPQA, VER & VAL, 2016), (CMMI 3-UCI-DAR, 2016), (CMMI 3-UCI-OPD y OPF, 2016) (CMMI 3-UCI-RSMK, 2016) y (CMMI 3-UCI-OT, 2016), se pudo constatar que se mantiene la misma situación descrita con respecto al Nivel 2, en lo que a la gestión legal compete.

Con respecto a los expedientes de proyectos, tomando como base la propuesta realizada por (^{Delgado Martínez, 2010}) se emitió la indicación No. 5 de 2013 desde la VRP- UCI actualizada por la Indicación No. 2 de 2016 para la conformación de dicho expediente, llegando el expediente de desarrollo a la versión 5.0 que integra aspectos establecidos en el modelo de CMMI (SEI, 2010) e ISO (ISO 21500:2012(E), 2012). Este expediente contiene una subdivisión destinada a los aspectos legales, pero no establece ninguna precisión sobre la gestión y así tampoco expresa asuntos relacionados con la obtención de ISBN de los documentos o programas desarrollados según lo dispuesto en (^{International ISBN Agency, 2012}, p. 13-16).

La gestión de la integración y los aspectos legales

El área de la gestión de la integración es definida por (PMBOK, 2017, p. 69) como aquella que “incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los diversos procesos y actividades de dirección del proyecto dentro de los Grupos de Procesos de la Dirección de Proyectos. En el contexto de la dirección de proyectos, la integración incluye características de unificación, consolidación, comunicación y acciones integradoras cruciales para que el proyecto se lleve a cabo de manera controlada, de modo que se complete, que se manejen con éxito las expectativas de los interesados y se cumpla con los requisitos. La Gestión de la Integración del Proyecto implica tomar decisiones en cuanto a la asignación de recursos, equilibrar objetivos y alternativas contrapuestas y manejar las interdependencias entre las Áreas de Conocimiento de la dirección de proyectos.”

Según define el propio (PMBOK, 2017, p. 79) “los activos de los procesos de la organización que pueden influir en el proceso Dirigir y Gestionar el Trabajo del proyecto incluyen, entre otros: las guías e instrucciones de trabajo estandarizadas.”

Como bien expresa (^{Piñero 2007}, p. 39) “la gestión de contratación deberá ser un proceso integrado a la gestión integral del proyecto y en total sintonía con los objetivos del proyecto en cada momento de su desarrollo como un mecanismo más de garantía de su éxito”, argumento que desde esta memoria se comparte y suscribe.

Durante todo el proyecto de desarrollo de software, se dan lugar diversas manifestaciones jurídicas, como pueden ser: el deber de información al cliente no profesional de las TIC; bienes intangibles que se utilizan para crear otros productos originales o derivados; tratamientos de datos personales; cambios que producen ajustes en el acuerdo o contrato firmado inicialmente; información denominada confidencial que se maneja o; las licencias a emitir para el uso del sistema que se crea.

Dichas manifestaciones pueden ser anticipadas y atendidas por el propio equipo de proyecto, de contar con el conocimiento para ello e incorporar a su gestión, actos que permitan el aseguramiento legal de las actividades que desarrollan a lo largo del proyecto.

Basado en lo anterior y considerando la actividad legal como un elemento que está presente en todo momento de la ejecución, así como su influencia en todas las áreas del ciclo de vida del proyecto, se considera que es en esta área de la gestión de la integración, donde se debe incorporar alguna guía o procedimiento que estandarice e integre la gestión de los aspectos legales en la producción de software de la UCI, al ser esta la que realiza el control e interdependencias entre todas las áreas de conocimiento del ciclo de vida del proyecto.

Conclusiones

Como ha sido analizado, son varias las teorías y trabajos que han sido publicados en relación con los aspectos legales asociados a las TIC. Al concluir el análisis, puede considerarse que:

Los elementos legales relacionados con la TIC en su mayoría, son abordados en la doctrina jurídica, desde la arista de la contratación de los proyectos; no obstante, son vistos sólo como una cuestión que garantiza la formalidad de las relaciones a establecer entre el proveedor y el cliente.

La doctrina jurídica ha sido exhaustiva en el tratamiento a los bienes intangibles que se crean como producto del proceso de desarrollo de software, pero no ha logrado integrarse al proceso de gestión de este, de manera que se garantice su protección desde el nacimiento de los mismos.

Los modelos de calidad y estándares visualizan la actividad legal como una entrada necesaria pero no la manejan integrada al proceso de desarrollo, sino que pueden tener presencia en algunas de sus fases.

Como lógica influencia de las tendencias expuestas en el artículo, el derecho informático en Cuba no ha tenido un tratamiento sistemático ni ordenado; por esto el desarrollo de los proyectos de la UCI, en su mayoría, ha adolecido de una gestión de los aspectos legales desde dichas estructuras organizativas.

En la UCI se han desarrollado investigaciones que enfocan temas legales de este tipo de bienes, pero son aún insuficientes para dar respuesta a todas las manifestaciones que de tipo legal se dan en el proceso de ejecución de un proyecto de desarrollo de software.

Se hace necesario un instrumento teórico-práctico para incorporar al área de la gestión de la integración, de manera que ofrezca respuestas concretas a la gestión de los aspectos legales del proyecto de desarrollo de software que los jefes de proyectos y especialistas deben manejar.