Guía para la evaluación y selección de soluciones de software

OBJETIVO

Las recomendaciones contenidas en este documento tienen como propósito brindar una guía de ayuda para los procesos de análisis y la toma de decisiones en relación con la evaluación y selección de software, estableciendo un proceso consistente que permita incorporar aplicaciones de software confiables, seguras y funcionales que apoyen los procesos estratégicos, tácticos y operativos dentro de las entidades y dependencias de la UNAM, eliminando juicios y criterios subjetivos en el proceso de evaluación y selección de alternativas.

La importancia de este documento radica en tomar decisiones informadas, oportunas y justificadas de acuerdo con la naturaleza y escenario de cada proyecto a evaluar.

ALCANCE

Las recomendaciones de esta guía son de uso general para todas las áreas universitarias que emprendan un proyecto para incorporar software en cumplimiento de las funciones y actividades sustantivas y que deseen aplicar prácticas formales al proceso de selección de los productos disponibles como pueden ser los que existen dentro de la Universidad, o suscribirse a uno como servicio (SaaS) o bien aquel software de tipo comercial o libre.

Este documento describe las actividades que los responsables administrativos y técnicos deberán realizar conjuntamente para determinar la opción de mayor valor para el área universitaria en la adquisición de un software, mediante el estudio y evaluación de alternativas, de acuerdo con el establecimiento y v

aloración de los criterios que se empleen durante este proceso de evaluación y selección.

INTRODUCCIÓN

Es relevante mencionar que la decisión de un proceso de incorporación de software, no solamente involucra aspectos técnicos, sino que además depende en gran medida de los procesos internos y la estructura orgánica del área involucrada, de la madurez y competencias en materia de Tecnologías de la Información y Comunicación (TIC) del personal de la propia área, en concordancia con la claridad y alineación del objetivo del proyecto o servicio a resolver con respecto al valor mismo de la solución que se está evaluando.

Para fines de una optimización institucional de recursos y costos, es importante analizar si la incorporación de una aplicación de software dará solución exclusivamente a una problemática detectada en un área universitaria o si ésta se pudiera constituir como una herramienta de utilidad en toda la Universidad, o bien, si la necesidad de incorporar el software están asociadas a oportunidades o mejoras en los procesos internos relativos a: definición de actividades, mejoras académicas y/o administrativas, descripción de roles, asignación de responsabilidades, comp-3 mb-2 bg-secondary text-whitetableunicación organizacional y/o capacitación; de identificarse que alguno de estos últimos es el caso, se recomienda evaluar el proyecto considerando a las opciones tecnológicas como un medio para obtener dichas ventajas y mejoras al área universitaria y no, como un fin por sí mismas.

Proceso para la identificación, evaluación y selección de aplicaciones de software

Es fundamental realizar un análisis acerca de las alternativas viables, determinando cuál será la opción más conveniente para el área universitaria, tomando en cuenta los recursos humanos, financieros, tecnológicos y de tiempo disponibles para realizar con éxito el proyecto.

Por lo anterior, se recomienda llevar a cabo las siguientes actividades para tener la suficiente claridad en la definición de las necesidades y una adecuada selección de alternativas de solución.

A) Análisis de las necesidades

Con el fin de comprender las necesidades que dan origen a la incorporación de una nueva aplicación de software, se sugiere:

1. Elaborar la matriz de involucrados/interesados que permita identificarlos y gestionarlos de manera adecuada durante el desarrollo del proyecto o simplemente para mantener una referencia de consulta en caso de que se requiera (Anexo 1).

   Esto es particularmente útil, como ejemplo no limitativo, para cuando el alcance y la complejidad del proyecto de incorporación del software tiene fronteras más allá de la propia área universitaria, lo que hace que sea un gran número de personas involucradas a las que se deban gestionar en términos de establecer una comunicación efectiva con todos ellos. Además, ayudará a disminuir los riesgos referentes a fallas en esta gestión que pudieran generar una mala ejecución del proyecto o en el peor de los casos hasta en el fracaso del mismo.

2. Definir los aspectos principales de la solución que se requiere, con la finalidad de contar con la visión/misión de la misma, para que sean el referente del alcance y poder cumplir los objetivos del área universitaria. Para recopilar y documentar los puntos principales de la solución se presenta una propuesta para la definición del proyecto (Anexo 2). Para realizar la definición se tienen que analizar los siguientes aspectos que permitan comprender la situación actual del área universitaria:

   1. la problemática actual,
   2. los procesos, áreas y actores involucrados,
   3. los objetivos que se pretenden lograr,
   4. los beneficios e impactos esperados,
   5. así como las restricciones de tiempo y presupuesto.
       

   Este análisis se puede llevar a cabo a través de la aplicación de entrevistas o hacer reuniones de trabajo con todos los involucrados (el área usuaria, directivos, técnicos u otras áreas que se vean impactadas de manera directa o indirecta).

3. Documentar una matriz de requerimientos (Anexo 3) que describa a detalle las características requeridas para el nuevo sistema de información o aplicación, indicando si estas características son obligatorias o deseables, incluyendo al menos lo siguiente:
   1. Identificador.
   2. Requerimientos funcionales o no funcionales. Se han de considerar los criterios de calidad requeridos en el(los) producto(s) de software (también denominados requerimientos no funcionales) tomando en cuenta que la prioridad o enfoque entre estos criterios puede cambiar significativamente de acuerdo con los fines del sistema o aplicación. Para determinar los criterios que ha de tener la solución, se presenta una guía para la especificación de requerimientos no funcionales (Anexo 4):
       
      • 1.1. Seguridad
      • 1.2. Eficiencia
      • 1.3. Compatibilidad
      • 1.4. Usabilidad
      • 1.5. Mantenimiento
      • 1.6. Interoperabilidad
      • 1.7. Confiabilidad
      • 1.8. Portabilidad
      • 1.9. Restricciones de diseño y construcción
      • 1.10 Documentación y capacitación necesaria, entre otros.
   3. Propósito.
   4. Clasificación
   5. Área(s) solicitante(s).
4. Validar la matriz de requerimientos mencionada en el punto anterior con los involucrados del proyecto, servicio o proceso que puedan confirmar la necesidad, impacto y valor de cada rubro, las características que son obligatorias, así como aquellas características que pueden clasificarse como opcionales o deseables. Este es un punto objetivo debido a que en la medida en que se cumpla con los puntos de esta relación, se podrán cubrir los objetivos organizacionales. Esta verificación de requerimientos es una parte relevante del proceso para eliminar la subjetividad al mismo.
5. Realizar la ponderación de la matriz de requerimientos para determinar la prioridad de cada uno de ellos (Anexo 5).

b) Identificación de alternativas

Una vez que se realizó el análisis de las características requeridas por la nueva aplicación y se validó que éstas responden a los requerimientos y expectativas de los diferentes involucrados en el proyecto, es recomendable que el área universitaria realice un ejercicio de evaluación completo de las diversas opciones para satisfacer dichas necesidades.

Es conveniente considerar las siguientes opciones:

1. La existencia de sistemas de información similares desarrollados a la medida en alguna otra área universitaria que puedan ser compartidos o reutilizados. Tomar en cuenta la experiencia que otras áreas universitarias tienen en el tema. Para ello se recomienda revisar las posibles alternativas existentes dentro del inventario de software y desarrollos actuales dentro de la misma Universidad, el cuál proporcionará una primera posibilidad de solución a las necesidades.
2. La posibilidad de suscribirse por un tiempo definido a un servicio de software para usarlo de manera remota ya sea conectándose a los servidores del proveedor o a la nube de este último, usualmente con un pago mensual o anual.
3. La existencia de herramientas (comerciales o libres) que cumplan con las características requeridas, que puedan ser fácilmente adaptadas y que requieran una curva de aprendizaje baja.
4. La conveniencia de fortalecer el sistema desarrollado a la medida que se encuentra actualmente en uso evaluando la alternativa de modificar o crear algunos módulos de un sistema. Privilegiar en este fortalecimiento la visión de uso institucional por otras entidades o áreas universitarias, multientidad.
5. La posibilidad de realizar una migración por medio de herramientas automáticas que conserven la funcionalidad actual de un software desarrollado a la medida hacia una nueva versión o tecnologías usadas. Esto puede ser necesario cuando las tecnologías que fueron usadas para el desarrollo ya se encuentran obsoletas o sin soporte del proveedor, algunos ejemplos son:
   • Actualizar el código fuente de PHP 5.4 a PHP 8.
   • Migrar la aplicación desarrollada a la medida de Visual Basic .Net a la tecnología .Net
6. La opción de realizar un desarrollo completo a la medida, ya sea de manera interna en el área universitaria o subcontratando a un proveedor externo. En este caso debe estimarse el esfuerzo, tiempos, implicaciones y los riesgos del nuevo sistema de información o aplicación, en términos del proceso de desarrollo, de implantación, de mantenimiento, por mencionar algunas dimensiones. Es imprescindible considerar la visión de uso institucional por otras entidades o áreas universitarias, multientidad en el diseño del nuevo sistema.

Derivado de este análisis se resumen las siguientes cinco alternativas:

1. Adopción de algún software ya existente en una entidad universitaria u organización con un proceso similar.
2. Software como un servicio (Software as a Service, SaaS).
3. Adquisición de soluciones comerciales o de software libre.
4. Fortalecimiento o migración de versión o tecnología de algún sistema hecho a la medida ya existente en la entidad o dependencia universitaria.
5. Desarrollo de software a la medida.

Las tres primeras involucran obtener un producto de software existente ya sea comercial, libre o de otro tipo de licencia o bien para suscribirse y hacer uso de un software. Por lo tanto, pueden seguir un procedimiento específico de adquisición de software; las siguientes dos opciones implican realizar un esfuerzo de desarrollo a la medida o una actualización o migración de versión y/o tecnología, por lo que en caso de elegir la alternativa IV o V puede seguirse un procedimiento específico distinto al sugerido en esta guía, aunque pueden apoyarse en el proceso general de adquisición de software cuando sea necesario.

Es importante señalar que ninguna de las opciones es mejor que otra por sí misma, sino que la elección de una alternativa depende en gran medida de las necesidades del área universitaria.

Cada una de las alternativas se explica más ampliamente en la sección Alternativas para la selección de aplicaciones de software.

C. Evaluación de alternativas

1. Identificar aquellas alternativas que cumplan con la mayor cantidad de características definidas como indispensables, obligatorias, así como la mayor parte de las deseables indicadas en la matriz de requerimientos al realizar un ejercicio de valoración (Anexo 6).
2. Realizar un análisis costo-beneficio (Anexo 7) de las alternativas, tomando en cuenta los recursos humanos, financieros y de tiempo disponibles para realizar el proyecto.
3. Concentrar la información y presentar un resumen de los resultados obtenidos de la evaluación que apoye la toma de decisiones de los directivos (Anexo 8).

Alternativas para la selección de aplicaciones de software

La creencia generalizada dicta que toda organización es única y que es improbable que encuentre una solución existente que se ubique implantada en otra organización que le pudiera resultar de utilidad y cubrir sus necesidades. La experiencia práctica en procesos formales relacionada con procesos de adquisición de software indica que realizar un estudio completo propicia la obtención de resultados favorables; no únicamente en términos de costo y tiempo, sino en diversos criterios de calidad de software, empezando por la propia funcionalidad que ofrece un producto determinado.

Para realizar la evaluación es necesario contar con la matriz de los requerimientos indicada en el cuarto y quinto punto del apartado Proceso para la identificación, evaluación y selección de aplicaciones de software.

Primera alternativa: Adopción de algún software desarrollado a la medida ya existente en otra área universitaria u organización con un proceso similar

Algunas organizaciones crean una barrera para aceptar esta alternativa dado que tienen la creencia de que son únicas y que es improbable que pueda utilizarse una solución que está en otra organización. También es importante mencionar que dentro de la Universidad existen procedimientos que deben ser llevados de manera estandarizada en diversas dependencias y debido a ello se sugiere tomar en cuenta está alternativa para poder tomar una correcta decisión, en este sentido se ha de evaluar la posibilidad de adoptar algún software existente en algún área afín en la propia Universidad o en otra organización donde se encuentren similitudes en la funcionalidad del producto. Existe una gran cantidad de procesos que son transversales (de manera común en diversas entidades) o, verticales que se asocian a una función de la organización, donde por lo anterior, algunas veces “tocando las puertas adecuadas” y haciendo las preguntas correctas se pueden encontrar estas importantes similitudes y oportunidades para adquirir la solución esperada y requerida.

La ventaja de adquirir una solución existente usualmente es muy significativa en cuestión de reducir los tiempos de implementación para tener la solución operando, en costos de adquisición (en contraste directo contra el desarrollo a la medida y en comparación con la adquisición de soluciones comerciales, en donde se toma en cuenta los costos de desarrollo, de recursos de hardware y humanos), en el aprovechamiento de los recursos de la Universidad, disminución de riesgos al cubrir la mayor cantidad de requerimientos, rapidez en el tiempo de capacitación y aprendizaje de utilización de los usuarios, así como en la evolución del software.

Para el análisis de esta alternativa se sugieren los siguientes pasos:

1. Revisar el inventario de software y desarrollos actuales dentro de la misma Universidad para identificar las posibles alternativas ya existentes que proporcionan una primera posibilidad de solución a las necesidades. Un paso importante que se recomienda realizar, si es el caso, es identificar el área universitaria que de manera lógica o por su naturaleza solicita ciertos requerimientos o procesos que dieron origen a la necesidad a cubrir, para verificar si podría proporcionar una solución institucional (generalizada para adaptarla a cada entidad o dependencia).
2. Obtener o elaborar la relación de la funcionalidad que ofrece la solución que se encuentra implementada en otra área u organización para poder hacer una evaluación ponderada que permita eliminar subjetividades.
3. Es relevante evaluar:
   1. La flexibilidad de la solución.
   2. La portabilidad y madurez de la misma en operación.
   3. Nivel de similitud de los procesos que maneja la solución con los procesos que desea automatizar la dependencia adoptante.
   4. Las necesidades de infraestructura, entorno y mantenimiento requerido, para determinar si el área universitaria que desea hacer uso de la solución, puede adquirir la plataforma e infraestructura tecnológica en que se recomienda opere, y en su caso, determinar también si cuenta con el personal requerido para la operación y/o mantenimiento de la solución.

      Las soluciones de software que se pueden encontrar dentro de la Universidad suelen ser adquiridas a través de alguno de los dos modelos de adopción que a continuación se mencionan:

      • Adoptar un sistema transferible. En este modelo, el área universitaria que adopta al software suele recibir una copia del código fuente y de la documentación que complementa a la solución. Esto permite adaptar o modificar el software (respetando los derechos morales) a requerimientos que podrían ser más específicos. Se sugiere analizar qué tanto cubre la solución transferible para tomar la decisión de adoptarla tal cual, o adaptarla en ciertas funcionalidades o, si es viable, complementar con algunos módulos de otra solución o bien modificar el proceso del área universitaria que está evaluando las soluciones para adoptar la solución completa.
        Sin embargo, al mismo tiempo, el área universitaria adoptante adquiere la responsabilidad de contar con la infraestructura y los recursos necesarios para operar y mantener el software por sí misma.
      • Usar un sistema operado por un área universitaria. En este otro modelo, existe un área universitaria que se encarga de operar, actualizar y mantener un desarrollo continuo del software, además de ofrecer a las otras áreas universitarias interesadas la posibilidad de usarlo a través de la suscripción de usuarios, teniendo siempre en cuenta la importancia de mantener privados los datos de cada una de las áreas que están suscritas.
        
        En este segundo modelo, el área universitaria adoptante tiene la ventaja de no requerir infraestructura, personal especializado ni invertir tiempo adicional para poner en funcionamiento la solución, gracias a que el uso del software puede llegar a estar disponible en pocas horas y en algunos casos hasta en minutos, una vez que se formaliza la adopción. A pesar de estas ventajas, es importante considerar que la flexibilidad para adaptar y modificar una solución de este tipo a las necesidades de una sola área puede ser un poco más limitada, sin embargo, esto no quiere decir que no sea posible realizar estas adecuaciones por el área encargada de mantener el software.
        
        Es importante no confundir este modelo de adopción con la segunda alternativa de selección de software que se menciona en esta guía, a saber, Software como Servicio (SaaS) externo, en donde básicamente la diferencia es que un tercero ajeno a la Universidad ofrece el servicio de usar el software en la mayoría de los casos por un pago obligatorio.

         

4. Tomar en cuenta como parte de la valoración, la recopilación de información y entrevistas con la organización que emplea el producto que se desea adquirir, para recopilar testimonios de las áreas usuarias, resultados logrados, documentación existente, así como indicadores y métricas, en caso de existir. Entendiendo las diferencias propias de procesos, culturas y alguna funcionalidad específica, usualmente esta información es muy valiosa para la toma de decisión final conforme a esta alternativa.
5. Acordar un periodo de prueba de uso del producto (30, 60 o 90 días comúnmente) en que se pueda hacer uso del producto en un ambiente controlado y hacer una prueba real para determinar en qué medida el producto cumple con la especificación inicial de requerimientos. En caso de ser factible, y más en el caso entre entidades y dependencias universitarias o con instituciones de educación superior.
6. Asimismo, se vuelve muy importante negociar en un primer acercamiento con el área universitaria o la organización que cuente con los derechos patrimoniales e industriales del producto, si es factible realizar la transferencia de uso del producto bajo la modalidad legal correspondiente o de compartir el servicio. El proceso pudiese incluir alguna formalización para el licenciamiento o autorización de uso, cesión de derechos u otra figura, ya sea que se determine o no, algún pago o apoyo de recuperación.

Al realizar los pasos anteriores se obtendrán los siguientes resultados:

• El grado de compatibilidad del proceso a atender con el de la solución existente en función de los resultados de cumplimiento de la matriz de requerimientos.
• Los recursos necesarios para materializar la adopción (tecnológicos, infraestructura, humanos, capacitación de usuarios, etc.).
• Las acciones y tareas adicionales una vez que la adopción del software sea concretada como pueden ser: la reingeniería de procesos, adaptación de módulos o incluso la creación de nuevos módulos completos.
• Estimación del tiempo para poner en funcionamiento el software adoptado.

El análisis de los resultados determinará de una manera más precisa la decisión final de esta alternativa considerando el cruce con las necesidades de la dependencia que desea realizar la adopción.

Finalmente, es importante remarcar la relevancia de que la primera alternativa de adquisición que se presenta en esta guía sea la adopción de un software interno de la UNAM; esto es porque son muy altas las probabilidades de encontrar soluciones de software ya existentes en toda la extensión de la Universidad que apoyan en las actividades diarias y que resuelven necesidades que son encontradas en otras áreas universitarias que son análogas a aquellas que dieron origen a la solución de software. Para conocer y analizar las diferentes opciones que ofrece la Universidad es recomendable que visite el inventario de software de la UNAM en la dirección https://informaciontic.unam.mx.

Segunda alternativa: Software como servicio (Software as a Service SaaS) externo

El proveedor proporciona el uso de un Software por medio del pago de una suscripción durante un periodo de tiempo, por ejemplo: por medio de un pago (mensual o anual) o sin pago, mientras que sea necesario el servicio. El software es usado a través de una conexión en internet a los servidores o nube del proveedor.

El suscriptor no gestiona ni controla la infraestructura fundamental del software tales como la red, servidores, sistemas operativos, almacenamiento o incluso capacidades de aplicaciones individuales, podría existir la excepción de aplicar ajustes específicos de configuración del usuario, pero limitados en las aplicaciones.

El proceso de adquisición de esta alternativa es similar al utilizado para el software comercial (tercera alternativa de la presente sección donde se detalla el proceso a seguir):

1. Definir por cuánto tiempo se estima que se requiere la solución. Considerar las normatividades que apliquen, por ejemplo: las restricciones de tiempo para poder hacer el contrato del servicio.
2. Identificar y comparar las alternativas de soluciones de software.
3. Evaluar las ofertas y los proveedores, considerando que dichas propuestas estén alineadas con la normatividad UNAM y marcos jurídicos aplicables, como son la Normatividad en Materia de Adquisiciones, Arrendamientos y Servicios de la UNAM, Ley General de Protección de Datos Personales, Normas Complementarias sobre Medidas de Seguridad Técnicas, Administrativas y Físicas para la Protección de Datos Personales en Posesión de la Universidad, entre otros (Anexo 9).
4. Validar para comprobar que la alternativa cumpla con las necesidades del área universitaria con base en la matriz de requerimientos. Elaborar la relación de la funcionalidad que ofrecen las opciones de solución para poder hacer una evaluación ponderada y eliminando subjetividades.
5. Comprobar si existe documentación de la solución, por ejemplo manuales de usuario, en este caso no habrá guías de instalación o similares debido a que no se instalará en máquinas del comprador, sino que se usará el servicio disponible en la nube o en los servidores del proveedor.
6. Revisar el contrato, y en caso de que el contenido sea desfavorable, se sugiere tratar de negociar el contenido del mismo, aunque en el caso del Software como servicio, generalmente estas licencias de uso no son modificables, en este caso se necesitaría considerar si se acepta el contrato tal y como se encuentra o se rechaza y se busca otra alternativa de software. Debe acompañarse de las áreas jurídicas de la entidad o dependencia.
7. Para mayor referencia de este punto, se sugiere apoyarse en el estándar IEEE 41062:2019 Recommended Practice for Software Acquisition, como guía para realizar este proceso, el cual incluye formatos que apoyan la definición y seguimiento del proceso de adquisición (Anexo 10).

Tercera alternativa: Adquisición de soluciones de pago o de software libre

El proceso de adquisición de software provee una estructura de los pasos más importantes aplicados en la adquisición de cualquier elemento de software y en el uso de software libre. Se espera que las actividades utilizadas en este proceso den como resultado la entrega de productos de alta calidad y bien documentados.

Para iniciar un proceso de adquisición de soluciones de pago o de software libre, se recomienda:

1. Identificar publicaciones de terceros independientes calificados (como casas consultoras, estadistas, revistas especializadas, por mencionar algunas), que hagan referencias de las características positivas y negativas del producto, el servicio, el respaldo del proveedor, el costo/beneficio de valor y propiedad del producto, como algunos puntos a considerar.
2. Si se decide adquirir una solución deben evaluarse diversas ofertas de proveedores y seleccionar al más adecuado, considerando la normatividad aplicable (Anexo 9) y al menos los siguientes criterios:
   1. Cumplimiento de los requerimientos solicitados (obligatorios y deseables)
   2. Experiencia del proveedor en el mercado
   3. Tipo de licenciamiento (por procesador, por usuarios designados, perpetua, temporal, creative commons, entre otros)
   4. Soporte (tipo, vigencia, tiempos de respuesta y actualizaciones al software) y garantía (duración y aplicación)
   5. Capacitación
   6. Vigencia tecnológica de la solución
   7. Uso de estándares abiertos
   8. Plataforma necesaria para su funcionamiento
   9.  Forma de entrega del software (medios ópticos o descarga de la red)
   10. Documentación de la solución. Solicitar u obtener (en el caso de software libre) la documentación necesaria para operar y mantener el sistema, incluyendo como mínimo el Manual de Usuario y el Manual Técnico para la operación.
   11. Precio
3. Asegurar que el contrato propuesto o licencia de uso, precise el alcance, tiempo, entregables, criterios de aceptación, tipo de licenciamiento, tipo, forma y cobertura del soporte, duración y procedimiento en que aplica la garantía y compromisos de ambas partes, así como dar seguimiento puntual a éste.
4. Realizar pruebas de validación para asegurar que la solución entregada cumpla con todos los requerimientos acordados en el contrato y que dicha validación quede especificada dentro de los criterios de aceptación.
5. Para mayor referencia de este punto, se sugiere apoyarse en el estándar IEEE 41062:2019 Recommended Practice for Software Acquisition (Anexo 10), como guía para realizar este proceso, el cual cuenta con formatos que apoyan la definición y seguimiento del proceso de adquisición. El estándar recomienda realizar las siguientes fases:

   
   El proceso de adquisición de software debe adaptarse o simplificarse en la mayor medida posible tomando el riesgo en consideración. El proceso debe ser coherente con la madurez técnica, los requisitos validados, y el nivel esperado de esfuerzo y financiación.

 

Cuarta alternativa: Fortalecer o migrar de versión o tecnología algún sistema desarrollado a la medida ya existente en el área universitaria

El proceso dinámico inherente a las Tecnologías de Información y a las plataformas tecnológicas que soportan a los sistemas, en conjunto con el ciclo de vida propio de un aplicativo de software, crean la necesidad con el tiempo, de abordar un proceso de adquisición de un producto de software. En el caso del software comercial, esta exigencia podría solucionarse de manera más inmediata mediante la adquisición de una nueva versión del producto, o bien la actualización de algún componente de software o de hardware.

En este caso, la evaluación se realiza para conocer si algún sistema existente en el área universitaria, el cual fue realizado a la medida y que actualmente se encuentra en operación (usualmente con varios años en operación), es factible fortalecerlo o migrarlo a una nueva versión o tecnología. En este caso es importante partir de si el cambio debe realizarse debido a:

1. Un cambio en las reglas de los procesos de operación, negocio o normatividad, para ello se sugiere tomar en cuenta las siguientes recomendaciones:
   1. Determinar el impacto de los cambios para conocer si son ajustes o modificaciones que pueden resolverse mediante un proyecto de actualización a nivel de programación de ciertos componentes o módulos del sistema, que pudieran dar origen a una nueva versión del sistema a ser probada y liberada (por ejemplo liberar la versión 2.0 de un sistema); o si se trata de un cambio radical o de muy alto impacto en el proceso o metodología de operación que orienten la solución a alguna otra alternativa para sustituir el sistema actual que se venía operando.
      En el caso de un sistema operado por un área universitaria, al que tienen acceso otras áreas de la Universidad, los cambios podrían ser por:
      a. Nuevos requerimientos solicitados por los usuarios
      b. Cambios de versiones de la plataforma tecnológica derivado de la alta demanda de recursos por la cantidad de usuarios suscritos.
   2. En cualquier escenario, deben contemplarse los criterios de calidad acordados en el análisis para determinar por ejemplo la funcionalidad, flexibilidad y facilidad de mantenimiento de tomar esta opción. La dimensión de costo asociada al desarrollo e impacto de esta nueva versión debe ser un elemento de peso para la decisión, la cual debe fundamentarse también en si se determina desarrollarlo de manera interna (contando con los perfiles y competencias para ello) o si se decide gestionar que el desarrollo lo realice una organización externa de esta nueva versión.
      Es importante destacar que un sistema puede evolucionar a una nueva versión del mismo para responder a las necesidades de la universidad, sin implicar que se vuelva costoso o que su mantenimiento se vuelva complicado. Esto se debe resolver dentro de las consideraciones de diseño, si se decidiera actualizar un producto existente.
2. Por obsolescencia o problemas de mantenimiento de la plataforma tecnológica o de seguridad, para lo cual es importante:
   3. Asesorarse y contar con un panorama general de las plataformas tecnológicas disponibles, para poder determinar si es factible realizar la migración del producto a una versión más actualizada y vigente o es necesario contemplar alguna de las otras alternativas planteadas en el documento.
   4. Si la plataforma tecnológica que se está empleando está reconocida por la industria como obsoleta o no vigente, se debe evaluar si se realiza por medio de un desarrollo (adecuaciones al código) o validar si existe algún producto libre o comercial que permita realizar la migración del producto hacia una nueva plataforma por medio de herramientas automáticas que conserven la misma funcionalidad del sistema actual. Por ejemplo: de Visual Basic .Net a la tecnología .Net 5 (evaluando las implicaciones y costos del proceso) o si es necesario seleccionar alguna otra alternativa de adquisición y si es así realizar un proceso de documentación y cierre de la solución actual en cuanto se implante exitosamente la nueva solución. Dado el último escenario, pudiera ser necesario considerar una migración de datos de un modelo de datos a otro.
      Las herramientas “automatizadas” de migración de plataformas pueden incluir cambio de aplicaciones de usuarios únicos o multi-usuarios, de cliente servidor a un modelo vista controlador, de un lenguaje estructurado a un lenguaje orientado a objetos, por mencionar algunos ejemplos. Algo similar puede encontrarse en relación con ciertas bases de datos en el mercado. Cabe mencionar que hay herramientas maduras y probadas que pueden entregar resultados bastante favorables y que requieren ajustes posteriores mínimos.
   5. Es importante tratar de contemplar dentro de los planes de trabajo anuales de ser posible, la actividad de realizar actualizaciones de productos de software a nuevas versiones estables (liberadas y probadas) para evitar tener aplicaciones en versiones muy antiguas que sean muy difíciles de mantener, debido a la dinámica cambiante que se ha comentado en las plataformas tecnológicas.
   6. Por seguridad contemplar además cambios o ajustes necesarios con la finalidad de disminuir riesgos como: robo de información, pérdida de privacidad, perjuicio económico, suplantación de identidad.

Quinta alternativa: Desarrollo de software a la medida

Partiendo de que se ha realizado un estudio formal de todas las opciones para la incorporación de una solución de software, el desarrollo a la medida es una alternativa cuya factibilidad y ejecución se debe determinar de acuerdo con los recursos, restricciones y expectativas del área universitaria. En comparación con las alternativas anteriores, usualmente realizar un desarrollo a la medida es el que toma una dimensión en tiempo mayor.

1. Considerar las restricciones de tiempo, costo, calidad, alcance y satisfacción de las necesidades de los involucrados en el proyecto. Para este último punto, es fundamental realizar un análisis de requerimientos detallado con dichos involucrados que incluya puntos de validación considerando desglosar a un nivel mayor de detalle, la matriz de necesidades identificadas como obligatorias y/o deseables dentro del proceso de evaluación de alternativas.
2. Para realizar un proyecto de esta naturaleza, es necesario prever la conformación de un equipo de trabajo multidisciplinario con representantes tanto de las áreas de negocio y usuarias como del área de cómputo, liderados por un responsable del proyecto con la competencia y autoridad necesaria para coordinar la realización del mismo. Si bien los proyectos para incorporar un nuevo sistema de información o aplicación requieren en gran medida de aspectos tecnológicos, no deben ser considerados como proyectos de carácter meramente técnico en donde se transfiera toda la responsabilidad al área de informática o de tecnología, es muy importante que se involucre el personal de negocio para lograr los objetivos del software.
3. Considerar en el diseño del sistema la perspectiva de que el software pueda ser compartido (transferible o como servicio interno de la Universidad) con otras áreas universitarias.
4. Se recomienda, y es deseable, que el equipo de trabajo técnico cuente con conocimientos y tenga experiencia tanto en las tecnologías de desarrollo como en la aplicación de metodologías formales para su administración y desarrollo, especialmente en sistemas de alta complejidad y en consideración de las restricciones mencionadas anteriormente.

En el caso de la subcontratación para el desarrollo del aplicativo de software, se sugiere contemplar los siguientes puntos:

1. Se puede buscar la subcontratación con un tercero para el desarrollo de software cuando se determine que el costo es menor o si el área universitaria no cuenta con los recursos, competencias y/o experiencia necesarios para desarrollar y/o actualizar un nuevo sistema. Para ello es indispensable considerar prácticas para la administración de subcontratos que permitan asegurar el cumplimiento de los compromisos acordados.
2. Para la gestión de un servicio de subcontratación con un tercero o de colaboración entre entidades para el desarrollo del proyecto de software, es importante establecer los requerimientos funcionales y no funcionales, el alcance, criterios de aceptación, restricciones, factores a considerar y responsabilidades que adquiere la propia área universitaria en la participación, colaboración y gestión del proyecto para la generación del producto.
3. Para la selección del proveedor en su caso, es importante considerar:
   • Su experiencia en proyectos anteriores o similares.
   • Las competencias y experiencia de su personal.
   • El reconocimiento o certificaciones deseables.
   • Los derechos patrimoniales del producto.
   • La garantía.
   • La documentación a entregar.
   • Los estándares de control de calidad que se utilizan.
   • La capacitación y transferencia del conocimiento.
4. Como práctica probada, la plataforma tecnológica a seleccionar, debe considerar la compatibilidad con las plataformas actuales que tiene la propia área universitaria, así como las competencias y experiencia del personal con diferentes ambientes, sistemas operativos, lenguajes de programación, marcos de trabajo y bases de datos, por mencionar algunos. En este tema podría solicitarse orientación de expertos en el área para partir de una opinión objetiva de acuerdo con criterios base.

Para mayor detalle en este tema, se sugiere consultar marcos de referencia y metodologías de desarrollo de software internacionales, así como otras recomendaciones de prácticas probadas de desarrollo de software aplicadas en la industria o emitidas por la Universidad.

Glosario

Para consultar los términos empleados en el presente documento diríjase al documento de Glosario de términos TIC: https://www.red-tic.unam.mx/glosario

Referencias

Bayse, Gail. (2004). A Security Checklist for Web Application Design. Recuperado el 26 de mayo de 2021 de https://www.sans.org/reading-room/whitepapers/securecode/security-checklist-web-application-design-1389.

Estándares

Institute of Electrical and Electronics Engineers. (1998). Recommended Practice for Software Requirements Specifications (IEEE 830). Reaffirmed 9 December 2009.
https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/720574

Institute of Electrical and Electronics Engineers. (2016). Recommended Practice for Software Requirements Specifications in IEEE Std 1062-2015  (Revision of IEEE Std 1062-1993). 
https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/7419835

Institute of Electrical and Electronics Engineers. (2019). Software engineering — Recommended practice for software acquisition (ISO/IEC/IEEE 41062).
https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/8645777

Institute of Electrical and Electronics Engineers. (2013). Software and systems engineering --Software testing --Part 1: Concepts and definitions (ISO/IEC/IEEE 29119-1).
https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/6588537

Institute of Electrical and Electronics Engineers. (2013). Software and systems engineering --Software testing --Part 2: Test processes (ISO/IEC/IEEE 29119-2).
https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/6588543

Institute of Electrical and Electronics Engineers. (2012). Standard for Configuration Management in Systems and Software Engineering. (IEEE 828).
https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/6170935

Institute of Electrical and Electronics Engineers. (2017). Systems and software engineering - Requirements for acquirers and suppliers of information for users (ISO/IEC/IEEE 26512).
https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/8288807

Institute of Electrical and Electronics Engineers. (2017). Systems and software engineering - Vocabulary (ISO/IEC/IEEE 24765).
https://ieeexplore-ieee-org.pbidi.unam.mx:2443/document/8288807
 

 

Créditos

Dr. Leonardo Lomelí Vanegas
Rector Dra. Diana Tamara Martínez Ruíz
Secretaria de Desarrollo Institucional Dr. Héctor Benítez Pérez
Director General de Cómputo y de Tecnologías de Información y Comunicación  

Coordinación

Dra. Marcela Peñaloza Báez  

Elaboración

Primera versión basada en el estándar IEEE 1062:1998 Susana Laura Corona Correa Alberto González Guízar Hugo Alonso Reyes Herrera María Teresa Ventura Miranda   Segunda versión basada en el estándar IEEE 1062:2015 Susana Laura Corona Correa Alberto González Guízar Heidi Alejandra Pérez Vera Hugo Alonso Reyes Herrera María Teresa Ventura Miranda   Tercera versión basada en el estándar IEEE 41062:2019 Ricardo Arroyo Mendoza - CUAIEED Susana Laura Corona Correa - DGTIC Francisco Dante Benítez Victoria – FES Aragón Jesús Esquivel Martínez – Facultad de Psicología Margarita González Trejo - DGTIC Alberto González Guizar - DGTIC Gerardo León Lastra – Filmoteca UNAM Leticia Martínez Calixto - DGTIC Esmeralda Martínez Montes - CISAN Hugo Alonso Reyes Herrera - DGTIC Irene Gabriela Sánchez García - DGTIC María de los Angeles I. Sánchez Zarazúa - DGTIC   Revisión José Luis Chávez Sánchez - DGTIC   Revisión a la tercera versión basada en el estándar IEEE 41062:2019 (2024) Leticia Martínez Calixto - DGTIC María de los Angeles I. Sánchez Zarazúa - DGTIC

Anexos

Anexo 1: Matriz de involucrados / interesados

​

La matriz para la gestión de interesados/involucrados se compone de la integración de 4 cuadrantes que se distribuyen entre dos ejes: Poder e Interés.

1. El poder se refiere a la facultad que las personas o entidades poseen de afectar positiva o negativamente el proyecto, ya sea de una forma directa o indirecta, por medio de cualquiera de sus acciones, omisiones o actitudes.
2. El interés por otro lado, se refiere al grado de involucramiento que tienen ciertas personas o entidades en el desarrollo del proyecto.

Cabe mencionar que la gestión de interesados/involucrados es una acción dinámica que debe revisarse y actualizarse en función de los cambios que se vayan generando en toda la vida del proyecto.

Las escalas para ambos ejes son: Bajo y Alto, y simplemente establecen el grado del valor de la referencia definida por cada eje.

Cada cuadrante se define y se ubica dentro de la matriz por la referencia de la escala de uno de los ejes, con respecto al otro. El resultado de lo anterior, son 4 cuadrantes que corresponden a la clasificación de interesados de la siguiente forma:

1. Interesados que tienen Bajo Poder y Bajo Interés. Para una adecuada gestión, a estos interesados se recomienda MONITOREARLOS.
2. Interesados que tienen Alto Poder y Bajo Interés. Para una adecuada gestión, a estos interesados se recomienda mantenerlos SATISFECHOS.
3. Interesados que tienen Bajo Poder y Alto Interés. Para una adecuada gestión, a estos interesados se recomienda mantenerlos INFORMADOS.
4. Interesados que tienen Alto Poder y Alto Interés. Para una adecuada gestión, a estos interesados se recomienda mantenerlos INVOLUCRADOS al máximo.

​

Anexo 2: Cuestionario para la definición del proyecto

El Tablero de Visión del Producto (Product Vision Board), es una herramienta que puede ayudar a tener una base clara de lo que se requiere mejorar o solucionar antes de iniciar un proyecto ya que permite capturar la visión y la estrategia del producto, contiene de manera concisa la información que responde a las diversas interrogantes que surgen al inicio de un proyecto, además permite comunicar y compartir con los involucrados la información relevante respecto al proyecto manteniendo un referente del alcance y objetivos que se buscan solucionar con el software en un área universitaria.

Esta herramienta fue creada por Roman Pichler: https://www.romanpichler.com/blog/the-product-vision-board/

En el contexto de la herramienta el producto equivale al software que se busca obtener.

Con el tablero se abordan las siguientes preguntas:

1. ¿Cuál es el propósito del producto?
2. ¿Qué se quiere lograr con el producto?
3. ¿A quién, a qué audiencia está destinado el producto?
4. ¿Para qué se quiere realizar el producto?
5. ¿Qué problema o problemas resuelve el producto? / ¿Qué necesidades satisface?
6. ¿Cuál es el valor añadido que como área universitaria se está ofreciendo?

El Tablero de Visión del Producto se compone de 5 secciones como se muestra enseguida:

​

Imagen obtenida el 24/08/2024 del sitio https://www.romanpichler.com/blog/the-product-vision-board/

1. Vision (Visión): Establece el objetivo general, es decir, la razón fundamental para crear el producto, el cambio positivo que se desea lograr. Cuando no se tiene un objetivo general, no se podrá decidir cuál es la mejor manera de llegar allí. Las siguientes secciones ayudan a capturar la estrategia para lograr el objetivo.
2. Target group (Grupo objetivo): Indica quién es probable que se beneficie del producto, es decir, quiénes son los usuarios y clientes que usarán el producto.
3. Needs (Necesidades): Describe la propuesta de valor del producto mediante la especificación del problema principal que se aborda y el beneficio principal que se obtendrá con el producto. Es importante que se deje claro el por qué el grupo objetivo querrá utilizar el producto, es decir, el cómo se ve el éxito del producto para los usuarios y clientes. En caso de que se identifiquen más de un elemento se recomienda priorizarlas.
4. Product (Producto): Resume en máximo cinco características que son fundamentales para el éxito del producto y/o que hacen que destaque de lo que ofrece la competencia. Los detalles del producto se registrarán en una etapa posterior.
5. Business goals (Objetivos de negocio): Explica por qué vale la pena que se invierta en el producto, qué beneficios obtendrá el área universitaria con el producto. Se recomienda priorizar los beneficios de tal forma que se puedan generar enfoques y objetivos específicos. Esto último ayudará a tener los indicadores por los que se pueda medir el rendimiento del producto.

El tablero permite evaluar las respuestas, refinarlas, agregar o descartar ideas sobre el producto, sin embargo al final indica el camino a seguir, es por ello que se recomienda que el ejercicio se realice con los involucrados (stakeholders).

Información adicional que puede surgir en esta etapa pero que se utilizará en una posterior:

1. Descripción del flujo de información o procedimiento que se desea automatizar. Explique la secuencia de pasos y actividades generales que se contemplan.
2. Identificación de los roles involucrados en las actividades antes descritas. ¿Quién participa durante un flujo de trabajo normal?
3. Identificación de las actividades que ocurren en el mundo físico y qué pasos se quieren realizar en el sistema.
4. Descripción de qué información será procesada con la solución a incorporar, de qué tipo y cantidad estimada que se gestionará, ¿actualmente cómo se encuentra almacenada?
5. Las metas que ha establecido el área universitaria al respecto del presente producto.
6. Los nombres de los perfiles no técnicos que estarán involucrados de manera cotidiana en las actividades del proyecto para la evaluación de alternativas (esto también se obtiene del análisis de involucrados que se menciona en el Anexo 1).

Anexo 3: Matriz de requerimientos

La matriz de requerimientos es una herramienta estructurada que ayuda a organizar los requerimientos y su información una representación visual de las relaciones entre los requerimientos y sus componentes de proyecto asociados. Este formato es muy eficaz para aclarar las conexiones entre los diferentes aspectos del proyecto. Es importante elaborarla por varias razones:

• Organizar la información: ayuda a los equipos a comprender la estructura y la jerarquía de los requerimientos del proyecto.
• Facilitar el análisis: permite la rápida identificación de elementos faltantes o inconsistencias con los objetivos del proyecto.
• Mejorar la comunicación: proporciona una forma clara y accesible para que todas las partes interesadas comprendan el alcance del proyecto.

Adicionalmente, contar con una matriz durante todo el proyecto, actúa como un lienzo donde se traza la historia de cada requerimiento, que permite rastrear su recorrido desde la concepción hasta la finalización.

A continuación, se presenta la plantilla de la matriz de requerimientos junto con el instructivo de llenado:

​

Instructivo de llenado:

1. Encabezado. Indicar si se trata de Funcionales o No funcionales.
2. Id. Se anotará un número consecutivo para tener un mejor control.
3. Requerimiento. Se refiere a la característica con la que debe contar el sistema.
4. Clasificación (Obligatorio / Deseable). Conocer el propósito nos ayudará a definir si un requerimiento es obligatorio (mínimo indispensable), o bien, es deseable (una característica de la cual podemos prescindir) en el sistema.
   • Obligatorios. Son aquellos cuyo cumplimiento es obligado y que pueden servir para eliminar o descartar las opciones que no cumplan con las mismas. Entre estas se encuentran:
     • Objetivo de negocio. Se refiere a objetivos concretos y estratégicos. En este caso al cumplimiento de Leyes, normas, entre otros, que sean de tipo mandatorio.
     • Necesidad. Se refiere a la necesidad que tienen las áreas involucradas de contar con cierta característica, o bien, de solicitudes que hacen los usuarios y que son relevantes para llevar a cabo sus actividades.
   • Deseables. Son aquellas que no necesariamente tienen que ser cumplidas, son las características deseables u opcionales (no obligatorias) que puede tener el sistema y que son solicitados por áreas o usuarios.
5. Área solicitante. Se debe mencionar si el requerimiento es de un área en específico de la institución o de una parte de un proceso en específico; así como también mencionar si dicha área será la responsable de validar la información manejada dentro de ese requerimiento.

Anexo 4: Guía para la especificación de requerimientos no funcionales

 1. Seguridad

Garantía de que la información y los procesos del sistema sólo sean accedidos por los usuarios o sistemas autorizados y para las funciones (lectura o modificación) determinados, se debe considerar:

1. Autenticación y autorización (Seguridad de Acceso)

   Indicar cómo se controlará el acceso y privilegios de los usuarios para controlar el acceso a la funcionalidad, por ejemplo, por medio de:

   • Usuario y contraseña.
   • Dispositivos físicos cómo: el código de barras o tarjetas.
   • Certificado digital, contraseña.
   • Elementos biométricos, entre otros.
2. Protección de datos

   Indicar la forma en que la información será almacenada, por ejemplo: En claro o cifrada. En el caso de los datos personales deben almacenarse de manera cifrada. Además, identificar si se requiere algún mecanismo de protección para la base de datos o bien si deben indicar si por la criticidad de la información, es necesario considerar algún mecanismo de seguridad o protocolo especial, por ejemplo: Transferencia en claro, SSL, HTTPS, SFTP, FTP.

3. Rastreo de transacciones

   Indicar si se requerirá un registro y seguimiento de las transacciones en el sistema para monitorear y detectar anomalías, por ejemplo, una bitácora (esto tendrá que ser especificado también como un requerimiento funcional).

2. Rendimiento

Capacidad del sistema en cuanto a la velocidad y carga.

1. Tiempo de respuesta

   Aquél que tarda el sistema en responder a una solicitud del usuario, por ejemplo: que la página tarde menos de 2 segundos en cargarse.

2. Capacidad de carga

   Es la cantidad máxima de usuario y/o transacciones que el sistema puede atender sin tener una degradación significativa, por ejemplo: el sistema debe soportar hasta 2500 usuarios concurrentes.

3. Eficiencia de recursos

El grado en el que el software utiliza de manera óptima los recursos del sistema.

1. Utilización de recursos

   Las cantidades y tipos de recursos utilizados cuando el software lleva a cabo su función bajo condiciones determinadas:

   • Cantidad de memoria RAM usada
   • Tiempo de respuesta del sistema (latencia de red, respuesta del servidor, respuesta de la base de datos y respuesta del código)
   • Cantidad de procesos que corre (uso de procesador)
   • Recursos de red usados (llamadas a la base de datos, paquetes generados en la red por cada transacción)
2. Consumo de Energía

   Consideraciones sobre el consumo energético de la computadora de escritorio o dispositivos, por ejemplo, el sistema debe estar optimizado para reducir el consumo energético en dispositivos móviles.

4. Interoperabilidad(es opcional)

Característica que describe si la aplicación debe compartir información o ser compatible con otras aplicaciones. Si se pretende interactuar con otro sistema indicar las formas de interoperabilidad, que en cuanto a intercambio de información pueden ser, por ejemplo:

• En línea
• En batch
• Por archivos de texto

5. Compatibilidad (es opcional)

Capacidad de ser utilizado en diferentes plataformas o dispositivos. Como que el sistema pueda utilizarse en los principales navegadores y dispositivos móviles.

6. Confiabilidad (es opcional)

Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados. Se consideran las siguientes subcaracterísticas:

1. Tiempo de actividad

   Capacidad del sistema para satisfacer las necesidades de fiabilidad en condiciones normales. Por ejemplo: el sistema debe tener un tiempo de actividad del 99% mensual.

2. Tolerancia a fallos

   Capacidad del sistema para continuar operando según lo previsto en presencia de fallos parciales de hardware o software.

3. Capacidad de recuperación

   Capacidad del producto software para recuperar los datos directamente afectados y restablecer el estado deseado del sistema en caso de interrupción o fallo catastrófico.

7. Usabilidad

Característica de la aplicación para facilitar la operación al usuario final, incluyendo aspectos estéticos de la misma, cuando se usa bajo determinadas condiciones. Considerar lo siguiente:

1. Capacidad de reconocimiento (Diseño intuitivo y fácil de usar)

   Los módulos, flujos, acciones y funciones deben permitir al usuario reconocer que el producto es adecuado para satisfacer sus necesidades.

2. Tiempo de aprendizaje

   Tiempo que es necesario para que los nuevos usuarios aprendan a usar el sistema mediante una navegación clara, ayuda en línea o consulta de manuales entre otros.

3. Accesibilidad

   Capacidad del software para permitir el uso por usuarios con determinadas características y capacidades diferentes.

4. Documentación y capacitación
   Disponibilidad de ayuda y documentación con la finalidad de contar con elementos que permitan la comprensión en el uso del sistema y su actualización, así como la capacitación de usuarios, tomando en cuenta los siguientes documentos técnicos y para el usuario:
   • Manuales de usuario
   • Manuales técnicos
   • Diagrama entidad relación
   • Infografías
   • Material audiovisual
   • ¿Se planea capacitar a los usuarios del sistema para que lo usen o capaciten a otros?
   • ¿Se planea realizar una prueba piloto de manera controlada?

8. Mantenibilidad (es opcional)

Descripción de los elementos que facilitan la comprensión y la realización de las modificaciones futuras del software, incluye características relacionadas con la evolución, corrección y perfección de este, se debe considerar:

1. Modularidad

   Diseño del software en módulos o componentes con suficiente independencia para minimizar el impacto del cambio en los demás módulos o componentes.

2. Auditabilidad

   Facilidad para evaluar el impacto de los cambios en el código, estructura de datos, ambiente, interfaz, etc. y su alcance sobre el resto del software.

3. Facilidad de actualización

   Mecanismos para implementar actualizaciones y parches, como: las actualizaciones deben poder aplicarse sin necesidad de reiniciar el sistema.

9. Portabilidad (es opcional)

Capacidad del código, estructura de datos, interfaz, modelo o entorno de operación (Framework) de los módulos o componentes del software para ser transferidos de forma efectiva y eficiente a otro entorno de hardware o software. Considerar lo siguiente:

1. Migración

   Facilidad para mover el software a diferentes entornos o plataformas, por ejemplo: el sistema debe ser capaz de migrar a un entorno de nube con la mínima reconfiguración. Capacidad del software para ser sustituido por otro producto de software con funciones y propósitos similares bajo condiciones y entornos específicos.

2. Capacidad de instalación

   Facilidad para instalarse y desinstalarse en diferentes ambientes o entornos de hardware, software y telecomunicaciones. Es decir, tener mínimas dependencias específicas del entorno.

10. Legales y reglamentarias (es opcional)

Necesidades impuestas por leyes, reglamentos, entre otros.

1. Regulaciones

   Cumplimiento del software de acuerdo con leyes y regulaciones relevantes que apliquen al contexto de este, por ejemplo: el sistema debe cumplir con los Lineamientos para la Protección de Datos Personales en posesión de la Universidad Nacional Autónoma de México para la protección de datos personales.

2. Licencias

   Uso adecuado de software y componentes de terceros, por ejemplo: el sistema debe utilizar bibliotecas y componentes bajo licencias compatibles con el software.

11. Restricciones de Diseño y Construcción (es opcional)

Son requisitos que impone la naturaleza del dominio del problema, éstos pueden ser:

• Ajuste a estándares o lineamientos (p.e. una determinada manera de codificar un dato)
• Limitaciones hardware (por los equipos disponibles).
• Seguridad (por los distintos niveles de acceso a la información que deben tener los usuarios).
• Mantenimiento (se debe tener en cuenta la ampliación del sistema).
• Adaptación al entorno.
• Tecnologías a utilizar.
• Políticas de borrado.

12. Corrección de errores (es opcional)

Para detectar errores y su corrección se realizan pruebas que también ayudan a realizar mejoras, determinar la calidad del software, durabilidad y garantía, analizar el rendimiento, estabilidad, funcionalidad y eficacia. Se pueden realizar tres tipos de prueba:

1. Positivas

   Son las pruebas para validar la funcionalidad total esperada.

2. Negativas

   Son pruebas cuyo objetivo es romper la funcionalidad del software.

3. “Happy path”

   Son las pruebas para revisar si la funcionalidad es la esperada, no exhaustivas y sobre el flujo ideal del sistema. Para la realización de pruebas tomar en cuenta los siguiente:

   • Objetivo de las pruebas a realizar.
   • ¿Cómo se va a probar?; esquema de pruebas.
   • Duración de las pruebas.
   • Planes de acción para:
   • Corrección de errores detectados
     • Mejoras detectadas

13. Modificaciones, en caso de requerirse (es opcional)

Identificar las vías para realizar las modificaciones (ambiente de desarrollo y posterior integración o correcciones en producción con ventanas de mantenimiento alto riesgo). Dos de las principales razones por las cuales pueden existir modificaciones de software:

1. Correcciones

   Realizar un plan de acción que no afecte la operación del software en producción.

2. Mejoras

   Se recomienda aplicar cuando existe tiempo y no afecte en el cronograma y lanzamiento del software a producción.

14. Nuevas liberaciones (releases) del software (es opcional)

Las nuevas versiones se refieren a todas aquellas mejoras o nuevos alcances (requerimientos) identificados a lo largo de la operación del Software. En las nuevas versiones no se deberían incluir corrección de errores. Se deben considerar:

• Periodicidad programada de la liberación de versiones.
• Identificar previamente el contenido de cada versión.
• Definir un esquema de implementación (liberación) de cada versión (pilotaje)

15. Soporte (es opcional)

1. Soporte en la instalación

   Describe el esquema de apoyo para el proceso de instalación y puesta en marcha del software, tomar en cuenta si:

   • Existe un equipo técnico que apoye durante la instalación.
   • Se cuenta con manuales o tutoriales que documente los posibles problemas y soluciones que pueden presentarse.
   • Existen documentos que detallen la infraestructura o software complementarios para llevar a cabo la instalación.
2. Soporte posterior a la instalación

   Describe el tipo y esquemas de apoyo que pueden darse una vez que el software se encuentra en operación, como son:

   • Se cuenta con soporte técnico y cuál es el procedimiento para solicitar el soporte.
   • Alcance del soporte (asesoría, configuración directa en la aplicación).
   • Medios de contacto (Telefónico, en sitio, correo electrónico, acceso remoto).

16. Garantía del software (es opcional)

Nivel de certeza de que el software está libre de vulnerabilidades y funcione como se tiene previsto. Se debe observar lo siguiente:

1. Confiabilidad.

   No existen vulnerabilidades explotables, maliciosas o insertadas no intencionalmente.

2. Ejecución predecible.

   Confianza de que el software, cuando se ejecute, funcione como debe de hacerlo.

3. Conformidad.

   Conjunto planeado y sistemático de funciones interrelacionadas que garanticen los procesos de software y cumplimiento de los requisitos, normas y procedimientos.

Anexo 5: Ponderación

Una vez que se tiene la matriz de requerimientos validada y que ya se seleccionaron las alternativas a evaluar. Entonces el siguiente paso es analizar cada característica respecto a su cumplimiento en las alternativas consideradas. Antes de realizar la ponderación, se sugiere que la lista de requerimientos se identifique grupos de características con base en la naturaleza de las mismas, estos pasos se pueden realizar cuando se genere la lista de requerimientos.

Paso 1. Identificación de categorías, identificar bloques, estructuras o módulos del cual vamos a partir para agrupar los requerimientos, por ejemplo para la selección de una solución para la gestión de un hospital, para fines de la guía solo se toman 4 categorías:

​

Paso 2. Clasificación, clasificar de manera ordenada y de acuerdo con cada categoría que se haya identificado una o varias características. Por ejemplo:

• Admisión (ingreso) de pacientes
  • Dar de alta a los pacientes en el sistema
  • Control de pacientes por medio de un identificador único
  • Asignar clasificación de paciente y de precios
  • Realizar cargos a la cuenta de cada paciente
  • Cuenta total de cada paciente
  • Generar remisiones
  • Reportes y estadísticas (Indicar todos los campos con lo que se pueden generar reportes, así como el tipo de estadísticas)
• Administración hospitalaria
  • Registro de ocupación hospitalaria
  • Estado de las habitaciones
  • Ingreso de pacientes
  • Estancia de los pacientes
  • Egreso de los pacientes
  • Tablero de programación de camas y habitaciones
  • Reportes de camas por día
  • Reportes de camas por turno
  • Consumos hospitalarios por cada paciente
  • Reposición de inventarios en stock
  • Historia clínica de cada paciente
  • Notas de enfermería
  • Control de signos vitales (constantes de signos vitales) por paciente
  • Reportes y estadísticas (Indicar todos los campos con lo que se pueden generar reportes, así como el tipo de estadísticas)
• Administración y mantenimiento
  • Carga y modificación de catálogos
  • Alta de servicios
  • Listas de precios
  • Personalización de reportes
  • Configuración de Perfiles de los usuarios
• Requerimientos no funcionales
  • Evitar duplicidad de registros
  • El alta (admisión) de pacientes debe soportar al menos a 10 usuarios concurrentes.
  • En caso de que ocurra una falla del sistema, éste deberá reanudar su servicio en un plazo no mayor a 10 minutos.

Ahora bien, lo siguiente es realizar la ponderación para ello se sugiere utilizar algún método, a continuación se presentan dos:

Método 1

Asignar un valor relativo al nivel de cumplimiento del requerimiento en cada alternativa. Utilizando una escala del 0 al 5, donde 0 es no cumple y 5 es cumple totalmente. Donde el 100% será si en todas las características se tiene un valor de 5. Por ejemplo, en una solución para la gestión de un hospital:

Método 2

Asignar un peso a cada categoría identificada, de acuerdo con la relevancia que se le asigne a cada categoría. El peso total de las categorías tendrá que dar 100. Por ejemplo solución para la gestión de un hospital:

​

Valoración

Una vez que se ha ponderado, se prioriza cada categoría, es decir, al inicio se colocará la categoría que tenga mayor valor y así sucesivamente hasta el de menor valor. De acuerdo con la ponderación realizada, se asigna un valor a cada característica. La suma de las características por categoría tendrá que dar el valor asignado en la ponderación.

Anexo 6: Valoración por cada alternativa de solución

Ahora bien, una vez que se asigna la ponderación de las características (ver Anexo 5) se debe calificar cada alternativa según los criterios establecidos dependiendo del método utilizado: método 1 o 2.

Posteriormente, hay que realizar el cálculo para todas las alternativas y comparar las puntuaciones finales para tomar una decisión informada.

Es importante revisar el proceso y los valores asignados. Asegurado que reflejen adecuadamente las prioridades de las características.

 

Método 1

Se asigna un valor relativo al nivel de cumplimiento del requerimiento en cada alternativa, utilizando una escala del 0 al 5. Por ejemplo quedaría:

Método 2

Una vez que se asigna la valoración por cada característica de acuerdo con la priorización, se evalúan con las alternativas indicando el nivel de cumplimiento que va desde 0 cuando no cumple hasta el valor máximo que se asignó a la característica cuando si cumple totalmente. Por ejemplo la valoración de cada alternativa quedaría:

 

Anexo 9: Normatividad universitaria en materia de adquisiciones

Normatividad universitaria en materia de adquisiciones, arrendamientos y servicios de la UNAM

1. Acuerdo por el que se modifican las políticas y lineamientos de adquisiciones, arrendamientos y servicios de la Universidad Nacional Autónoma de México, 2022 https://www.red-tic.unam.mx/content/acuerdo-modificacion-politicas-y-lineamientos-de-adquisiciones-arrendamientos
2. Acuerdo que modifica y adiciona la normatividad de adquisiciones, arrendamientos y servicios de la UNAM, 2020. https://www.red-tic.unam.mx/content/acuerdo-que-modifica-y-adiciona-la-normatividad-de-adquisiciones-arrendamientos-y-servicios
3. Normatividad de adquisiciones, arrendamientos y servicios de la Universidad Nacional Autónoma de México, 2015. http://abogadogeneral.unam.mx/PDFS/normatividad-adquisiciones-2015.pdf
4. Políticas y lineamientos de adquisición, arrendamientos y servicios de la Universidad Nacional Autónoma de México, 2015. http://abogadogeneral.unam.mx/adquisiciones/consulta/ver/ver.html?adq_id=29
5. Acuerdo por el que se establecen los Lineamientos para la Protección de Datos Personales en posesión de la Universidad Nacional Autónoma de México. https://www.gaceta.unam.mx/index/wp-content/uploads/2019/02/190225-convocatorias.pdf

Para cada ejercicio anual se establecen ciertas disposiciones aplicables a la adquisición, arrendamiento y servicios de la UNAM. A continuación, se presentan las disponibles para el año 2024.

6. Disposiciones aplicables para los procedimientos de adquisiciones y arrendamientos de bienes muebles, así como las contrataciones de servicios de cualquier naturaleza, excepto los relacionados con la obra, durante el ejercicio presupuestal 2024. https://www.red-tic.unam.mx/disposiciones-adquisiciones-2024
7. Políticas y normas de operación presupuestal del año 2024. https://www.red-tic.unam.mx/content/politicas-y-normas-de-operacion-presupuestal-2024

Consideraciones en el uso y desarrollo de soluciones de software en la UNAM

8. Lineamientos generales y políticas sobre almacenamiento e información compartida entre los sistemas existentes, 2023. https://www.red-tic.unam.mx/content/lineamientos-politicas-almacenamiento-informacion-compartida
9. Lineamientos y recomendaciones para la administración de bases de datos, 2021. https://www.red-tic.unam.mx/lineamientos-bases
10. Marco legal o normativo para la compartición y almacenamiento de información en la UNAM, 2021. https://www.red-tic.unam.mx/marco-legal
11. Prácticas para el desarrollo de software, 2022. https://www.red-tic.unam.mx/node/731
12. Principios del software libre y código abierto en la UNAM, 2024. https://www.red-tic.unam.mx/principios-software-libre-2024
13. Recomendaciones generales de calidad de datos (2° versión), 2023. https://www.red-tic.unam.mx/recomendaciones-generales-calidad-datos-segunda-version
14. Recomendaciones para el almacenamiento de información, 2022. https://www.red-tic.unam.mx/recomendaciones-almacenamiento

Anexo 10: Pasos propuestos para la adquisición de software basados en la recomendación IEEE 41062:2019

En esta sección se presenta un resumen ejecutivo de los pasos propuestos por la Práctica recomendada para la adquisición de software basada en la IEEE 41062:2019. Además, se incluyen los controles recomendados y algunos factores críticos para realizar el proceso exitosamente. 

​

Puntos de control:

• Desarrollar el alcance del proceso de planeación.
• Determinar las características de calidad que el software debe cumplir, las cuales ayudarán a alcanzar los objetivos de la organización.

Factores críticos de éxito:

• Integrar un equipo que realice el trabajo de planeación y revise los objetivos de la organización.
• Identificar a los responsables y los roles involucrados con las fases de planeación, implementación, soporte, evaluación, negociación y adquisición.

Puntos de control:

• Documentar claramente los requerimientos funcionales (especificaciones de lo que debe hacer el software) y no funcionales (características de la plataforma, desempeño, disponibilidad, seguridad, mantenimiento, facilidad de uso, entre otras) del software.
• Establecer estándares de evaluación para las propuestas de solución entregadas por el proveedor.
• Identificar las características que debe tener el software y generar un listado de posibles proveedores que posean este tipo de soluciones.
• Incluir dentro de los requerimientos del software los costos asociados a instalación, migración, capacitación, operación y mantenimiento.

Factores críticos de éxito:

• Definición clara de los contratos y obligaciones del proveedor.
• Definición clara del plan de pruebas a realizarse al software.
• Consideración de todos los costos asociados a la operación y mantenimiento (conocido como TCO Total Cost of Ownership).

Puntos de control:

• Obtener información actualizada de los productos de software disponibles de cada proveedor potencial.
• Obtener información sobre antecedentes del proveedor: garantías, tiempo de respuesta, calidad de los productos y calidad del servicio, soporte.
• Solicitud de software de demostraciones para evaluar su desempeño (en caso de que aplique).
• Solicitud al proveedor de instalación del software por un periodo de prueba para evaluar su funcionalidad (en caso de que aplique).
• Evaluación de los procesos, funcionalidad, capacidad de configuración y de administración.

Factores críticos de éxito:

• Disponibilidad de infraestructura para la realización de las demostraciones.
• Seguimiento a las demostraciones realizadas por el proveedor.
• Documentación del cumplimiento y capacidades del software.

Puntos de control:

• Determinar los requerimientos de desempeño, calidad y criterios de aceptación que debe cumplir el producto o servicio.
• Definir y documentar en el contrato el desempeño requerido, así como las especificaciones funcionales y no funcionales, las cuales fueron determinadas en el Paso 2.
• Definir la forma y periodos de pago en caso de hacerse en parcialidades.

Factores críticos de éxito:

• Especificar claramente si es posible hacer cambios al contrato, quién es el responsable de hacer los cambios y quién autoriza dichos cambios.
• Especificar la forma, fecha y cantidad que se va a pagar para hacer las disposiciones o programar la autorización de los pagos en la fecha prevista.
• Revisar los términos legales del contrato. Evaluar las propuestas y seleccionar al proveedor.

Puntos de control:

• Utilización de criterios de evaluación de las propuestas de los proveedores considerando respuestas a los requerimientos funcionales y no funcionales, garantías, soporte, entre otros.
• Visita a las instalaciones de los proveedores.
• Negociación y firma del contrato con el proveedor seleccionado.

Factores críticos de éxito:

• Definición y difusión previa de los criterios de ponderación para evaluar las propuestas.
• Selección del proveedor que obtenga la mejor calificación y no al de menor precio.

Puntos de control:

• Plan de entregas en donde se especifique el momento en que el proveedor debe proporcionar los objetos requeridos.
• Utilización de métricas de calidad especificadas en el contrato para evaluar el desempeño del proveedor.

Factores críticos de éxito:

• Línea de comunicación abierta con el proveedor.
• Contar con personal dedicado al seguimiento, preferentemente el personal que estuvo involucrado desde el principio con el proveedor.

Puntos de control:

• Criterios de aceptación proporcionados como parte de un estándar de desempeño del proveedor.
• Las evaluaciones y pruebas deben ser realizadas para detectar diferencias entre las condiciones existentes y requeridas y evaluar las características del software.
• Los criterios de aceptación finales deben incluir los resultados de las pruebas para verificar el desempeño y la calidad del software en ambiente de usuario.
• Los planes de calidad y mantenimiento desarrollados para el proyecto deben ser usados para evaluar y aceptar el software, así como los servicios proporcionados por el proveedor.

Factores críticos de éxito:

• Definición de criterios de aceptación, pruebas de evaluación y planes de calidad por escrito y como anexos del contrato.
• El proveedor debe tener un rol en el proceso de pruebas.

Puntos de control:

• Identificación de prácticas débiles y que necesitan ser cambiadas.
• Identificación y conservación de prácticas que producen buenos resultados.
• Identificación de prácticas adicionales que necesitan ser desarrolladas e implementadas.
• Evaluación de la satisfacción del consumidor con el software.
• Registrar la cantidad de trabajo que se tiene que invertir al software, por ejemplo: el mantenimiento o configuración necesaria para que esté listo para su utilización.

Factores críticos de éxito:

• Involucrar al usuario final para la supervisión y aceptación del software.
• Involucrar al proveedor para la puesta a punto y liberación del software.

Esta práctica recomendada se puede aplicar a software que funciona en cualquier sistema informático sin importar el tamaño, complejidad, o criticidad del software. Cada dependencia universitaria deberá identificar sus necesidades y seleccionar las características y las actividades específicas que necesitan incluirse dentro del proceso de adquisición.