Anexos

GUÍA PARA LA EVALUACIÓN Y SELECCIÓN DE SOLUCIONES DE SOFTWARE

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.

A) 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.

B) 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.

Al hablar de prototipos nos referimos a crear algo para probar, explorar, o comunicar ideas acerca de las cosas que han de crearse.

GUÍA PARA LA EVALUACIÓN Y SELECCIÓN DE SOLUCIONES DE SOFTWARE

Cuestionario para la definición del proyecto

1. Objetivo general del proyecto. ¿Cuál es el propósito del proyecto?, ¿qué se quiere lograr?

2. Beneficios esperados. ¿Para qué se quiere realizar el proyecto?, ¿en qué se ayudará al área universitaria?

3. Describa el flujo de información o procedimiento que se desea automatizar. Explique la secuencia de pasos y actividades generales que se contemplan.

4. Identifique los roles involucrados en las actividades antes descritas. ¿Quién participa durante un flujo de trabajo normal?

5. Identifique las actividades que ocurren en el mundo físico y qué pasos se quieren realizar en el sistema.

6. Describa 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?

7. Indique las metas que ha establecido el área universitaria al respecto del presente proyecto.

8. Señale el nombre de los perfiles no técnicos que estarán involucrados de manera cotidiana en las actividades del proyecto para la evaluación de alternativas.

Anexo 3. Plantilla para la Matriz de requerimientos

 

Funcionales / No funcionales
Id	Requerimiento	Propósito	Clasificación	Área(s) solicitante(s)

 

No funcionales
Id	Requerimiento	Propósito	Clasificación	Área(s) solicitante(s)

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. Propósito (Objetivo de negocio / Necesidad / Oportunidad). El propósito nos ayuda a saber por qué o para qué queremos cierta característica (requerimiento) en el sistema. De acuerdo con la identificación de los requerimientos que han realizado, es esencial saber cuál es el propósito de cada requerimiento.

• 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.
• Oportunidad. Se refiere a las características deseables u opcionales (no obligatorias) que puede tener el sistema y que son solicitados por áreas o usuarios.

5. 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.

• Obligatorias: serán aquellas cuyo cumplimiento es obligado y que pueden servir para eliminar o descartar las opciones que no cumplan con las mismas
• Deseables: aquellas que no necesariamente tienen que ser cumplidas por las opciones a considerar pero que se aspiran que estén presenten en algunas opciones y se cumplan total o parcialmente de acuerdo con esto serán ponderadas o valoradas.

6. Á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.

GUÍA PARA LA EVALUACIÓN Y SELECCIÓN DE SOLUCIONES DE SOFTWARE

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.1. Seguridad de Acceso

Indicar cómo se controlará el acceso y privilegios de los usuarios, 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.

1.2. Integridad Revisar que tanto el código como las bases de datos, módulos o componentes del software no permitan accesos o modificaciones no autorizados.

1.3. No repudio Mantener un registro de las operaciones del software (logs del Sistema Operativo, Bases de Datos, Funciones del software, etc.), para poder identificar las acciones o eventos que sufrieron repudio o denegación del servicio y evitar que no se repita.

1.4. Autenticidad Capacidad de demostrar la identidad de una persona o un recurso.

1.5. Transferencia de información En su caso 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.

1.6. Almacenamiento de información Indicar la forma en que la información será almacenada, por ejemplo: En claro o cifrada. Además, identificar si se requiere algún mecanismo de protección para la base de datos.

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

1.8. Seguridad de la aplicación Aspectos en general de protección de las aplicaciones como, por ejemplo: evitar la inyección de código malicioso.

2. Eficiencia Mide el desempeño (comportamiento) del software bajo determinadas condiciones de carga (usuarios conectados simultáneamente, recursos usados, velocidad de la red o transmisión de datos, etc.), se debe considerar:

A) Comportamiento temporal. Los tiempos de respuesta y procesamiento y los ratios de throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones determinadas en relación con un banco de pruebas establecido (benchmark).

B) 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)

C) Capacidad. Grado en que los límites máximos de un parámetro de un producto o sistema software cumplen con los requisitos.

D) Volúmenes a soportar. Indicar con la mayor precisión posible los volúmenes esperados en cuanto a las siguientes cuatro dimensiones: Usuarios, Información, Transacciones y Volúmenes de información por transacción.

2.1. Usuarios Si es necesario, clasificar usuarios por perfil.

Total de Usuarios	Usuarios Concurrentes	Incremento/Periodo (Anual | Mensual)
Cuantificar el universo de usuarios que podrán acceder al sistema a determinada fecha.	Cuantificar el total de usuarios que podrán acceder al sistema al mismo tiempo.	En su caso, indicar la cantidad o porcentaje de crecimiento de usuarios en un periodo determinado.

2.2. Volúmenes de información esperados

INFORMACIÓN	TOTAL ESTIMADO AL [FECHA]	INCREMENTO (ANUAL | MENSUAL)
Nombre del universo de información, por ejemplo: Expedientes, Pacientes, Solicitudes, etc.	Cantidad de registros estimados que se incorporarán al sistema a una fecha determinada.	Cantidad o porcentaje de crecimiento de los registros por periodo.

2.3. Transacciones estimadas

2.4. Volúmenes de información por transacción (Aplicable cuando una transacción en particular lleva asociado un volumen de información significativo).

TRANSACCIÓN	VOLUMEN MÁXIMO	VOLUMEN MÍNIMO	MODA
Descripción de la instancia de una transacción.	Cantidad máxima de registros que pueden tener asociada la transacción.	Cantidad mínima de registros que pueden tener asociada la transacción.	Cantidad frecuente de registros que conlleva la transacción. Puede ser un número o bien rango(s) modal(es).

3. Compatibilidad Capacidad de dos o más sistemas o componentes para intercambiar información y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno hardware o software. Considerar:

A) Coexistencia. Capacidad del producto para coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes sin detrimento.

B) Interoperabilidad. Capacidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada.

4. 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:

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

B) Facilidad de uso. Mediante una navegación clara, ayuda en línea o consulta de manuales entre otros, permite al usuario aprender de forma casi intuitiva el uso del software.

C) Protección contra errores de usuario. Capacidad para alertar al usuario sobre posibles errores de operación del software.

D) Apariencia y estilo. El diseño de la interfaz debe permitir una navegación sencilla, agradable visualmente y satisfacer la interacción con el usuario.

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

5. Mantenimiento 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 del mismo, se debe considerar:

A) Modularidad. Característica del diseño del software para funcionar por módulos o componentes con suficiente independencia para minimizar el impacto del cambio en los demás módulos o componentes.

B) Reusabilidad. Eficiencia o capacidad del software para reutilizar código para funciones similares.

C) 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.

D) Parametrización. Facilidad de configurar los parámetros de operación del sistema, sin modificar el código, introducir defectos o degradar el desempeño.

E) Capacidad para ser probado. Facilidad con la que se pueden establecer criterios de prueba para un sistema o componente y con la que se pueden llevar a cabo las pruebas para determinar si se cumplen dichos criterios.

6. 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

7. Confiabilidad Es opcional. Especificación del nivel de desempeño del software con respecto a la madurez, tolerancia a fallas y recuperación. Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

A) Madurez. Capacidad del sistema para satisfacer las necesidades de fiabilidad en condiciones normales.

B) Disponibilidad. Capacidad del sistema o componente de estar operativo y accesible para su uso cuando se requiere.

C) Tolerancia a fallos. Capacidad del sistema o componente para operar según lo previsto en presencia de fallos hardware o software.

D) 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.

8. 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:

A) Capacidad de instalación. Facilidad del software para instalarse y desinstalarse en diferentes ambientes o entornos de hardware, software y telecomunicaciones.

B) Reemplazabilidad. Capacidad del software para ser sustituido por otro producto de software con funciones y propósitos similares bajo condiciones y entornos específicos.

9. Restricciones de Diseño y Construcción Es opcional. Son requisitos que nos impone la naturaleza del dominio del problema. Estos 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.

10. Documentación y capacitación necesaria Tomar en cuenta la generación o actualización de los siguientes documentos técnicos y para el usuario 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:

• 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?

11. Legales y reglamentarios Es opcional. Necesidades impuestas por leyes, reglamentos, entre otros.

12. Soporte en la instalación Es opcional. 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.

13. 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).

14. Corrección de errores 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: A) Positivas. Son las pruebas para validar la funcionalidad total esperada.

B) Negativas. Son pruebas cuyo objetivo es romper la funcionalidad del software.

C) “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

15. Modificaciones, en caso de requerirse 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:

• Correcciones. Realizar un plan de acción que no afecte la operación del software en producción.
• Mejoras. Se recomienda aplicar cuando existe tiempo y no afecte en el cronograma y lanzamiento del software a producción.

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

• Confiabilidad. No existen vulnerabilidades explotables, maliciosas o insertadas no intencionalmente.
• Ejecución predecible. Confianza de que el software, cuando se ejecute, funcione como debe de hacerlo.
• Conformidad. Conjunto planeado y sistemático de funciones interrelacionadas que garanticen los procesos de software y cumplimiento de los requisitos, normas y procedimientos.

17. Nuevas liberaciones (releases) del software 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)

GUÍA PARA LA EVALUACIÓN Y SELECCIÓN DE SOLUCIONES DE SOFTWARE

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:

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, con la compra de un auto:

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.

Id	Características	Ponderación
	Admisión (ingreso) de pacientes	30
1	Dar de alta a los pacientes en el sistema	7
2	Control de pacientes por medio de un identificador único	4
3	Asignar clasificación de paciente y de precios	4
4	Realizar cargos a la cuenta de cada paciente	6
5	Cuenta total de cada paciente	4
6	Generar remisiones	3
7	Reportes y estadísticas (Indicar todos los campos con lo que se pueden generar reportes, así como el tipo de estadísticas)	2
	Administración hospitalaria	30
8	Registro de ocupación hospitalaria	3
9	Estado de las habitaciones	2
10	Ingreso de pacientes	3
11	Estancia de los pacientes	3
12	Egreso de los pacientes	3
13	Tablero de programación de camas y habitaciones	3
14	Reportes de camas por día	1
15	Reportes de camas por turno	1
16	Consumos hospitalarios por cada paciente	2
17	Reposición de inventarios en stock	2
18	Historia clínica de cada paciente	3
19	Notas de enfermería	1
20	Control de signos vitales (constantes de signos vitales) por paciente	2
21	Reportes y estadísticas (Indicar todos los campos con lo que se pueden generar reportes, así como el tipo de estadísticas)	1
	Administración y mantenimiento	19
22	Carga y modificación de catálogos	6
23	Alta de servicios	5
24	Listas de precios	4
25	Personalización de reportes	2
26	Configuración de Perfiles de los usuarios	2
	Requerimientos no funcionales	21
27	Evitar duplicidad de registros	7
28	El alta (admisión) de pacientes debe soportar al menos a 10 usuarios concurrentes	6
29	En caso de que ocurra una falla del sistema, éste deberá reanudar su servicio en un plazo no mayor a 10 minutos	8

Una vez que se asigna la valoración por cada característica, 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.

GUÍA PARA LA EVALUACIÓN Y SELECCIÓN DE SOLUCIONES DE SOFTWARE

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

1. Normatividad de adquisiciones, arrendamientos y servicios de la Universidad Nacional Autónoma de México http://abogadogeneral.unam.mx/PDFS/normatividad-adquisiciones-2015.pdf

2. Políticas y lineamientos de adquisición, arrendamientos y servicios de la Universidad Nacional Autónoma de México http://abogadogeneral.unam.mx/adquisiciones/consulta/ver/ver.html?adq_id=29

3. 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 2021.

4. 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 2021. https://www.gaceta.unam.mx/wp-content/uploads/2021/01/210128-Circulares-Secretaria-Administrativa.pdf

5. Circular 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 2021. https://www.red-tic.unam.mx/recursos/2021/2021_Circular_SADM_05_2021.pdf

6. Políticas y normas de operación presupuestal del año 2021. https://www.red-tic.unam.mx/recursos/2021/2021_Politica_UniversidadNacionalAutonomaMexico_01.pdf

GUÍA PARA LA EVALUACIÓN Y SELECCIÓN DE SOLUCIONES DE SOFTWARE

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.

Paso 1: Planeación de la estrategia de adquisición de software. Revisar los objetivos de adquisición y entrega con base en la estrategia de adquisición de software.

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.

Paso 2: Determinar los requerimientos de software. Comenzar a definir el software que se adquirirá, así como preparar los planes de calidad y mantenimiento para la aceptación del software proporcionado por el proveedor.

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).

Paso 3: Identificar proveedores potenciales. Seleccionar candidatos potenciales que proveen la documentación del software, con demostraciones del software y entregando propuestas formales. Cualquier falla en alguna de estas acciones, será tomada como base para el rechazo de este proveedor potencial. Revisar los datos de desempeño del proveedor de contratos anteriores.

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.

Paso 4: Preparar los requerimientos del contrato. Describir la calidad del trabajo hecho con base en términos de rendimiento aceptable y criterios de aceptación y preparar las disposiciones del contrato, de forma tal, que se vincule el pago con los productos entregables. Revisar el contrato con el área legal de la entidad universitaria.

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.

Paso 5: Evaluar las propuestas y seleccionar al proveedor. Evaluar las propuestas de los proveedores, seleccionar y calificar al proveedor y negociar el contrato. Negociar con un proveedor alterno si es necesario.

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.

Paso 6: Administración del rendimiento del proveedor. El monitoreo del progreso del proveedor debe asegurar que los hitos sean alcanzados y aprobar los avances del trabajo solicitado. Que el área universitaria proporcione los requerimientos de información o entregables, cuando lo requiera el proveedor.

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.

Paso 7: Aceptación del software. Realización adecuada de pruebas y establecimiento de un proceso para la certificación de que todas las discrepancias se han corregido; y que todos los criterios de aceptación están completamente satisfechos.

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.

Paso 8: Evaluación del proceso e identificación de oportunidades de mejora. Conducir un análisis de seguimiento del contrato de adquisición de software para registrar las lecciones aprendidas, evaluar las prácticas de contratación, y la satisfacción del usuario con el producto. La evaluación debe resultar en información utilizable para adquisiciones futuras.

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.