Algunas organizaciones adquieren y adaptan soluciones empaquetadas compradas (también denominadas productos comerciales listos para usar, o COTS, por sus siglas en inglés) para satisfacer sus necesidades de software, en lugar de crear nuevos sistemas desde cero. Las soluciones de software como servicio (SaaS), o en la nube, también están cada vez más disponibles para satisfacer las necesidades de software. Ya sea que esté comprando un paquete como parte o la totalidad de la solución para un nuevo proyecto o implementando una solución en la nube, aún necesita requisitos. Los requisitos le permiten evaluar soluciones candidatas para que pueda seleccionar el paquete más apropiado y luego le permiten adaptar el paquete para satisfacer sus necesidades.
Algunos productos COTS se pueden implementar listos para usar sin necesidad de trabajo adicional para hacerlos utilizables. Sin embargo, la mayoría requiere cierta personalización. Esto podría tomar la forma de configurar el producto predeterminado, crear integraciones a otros sistemas o desarrollar extensiones para proporcionar funcionalidad adicional que no está incluida en el paquete COTS. Todas estas actividades exigen requisitos.
Si está buscando un paquete comercial para proporcionar una solución enlatada para una parte de las necesidades de procesamiento de información de su empresa, primero documente sus requisitos. No necesita especificar todos los detalles esenciales de la funcionalidad, pero considere los dominios de casos de uso o historias de usuarios, reglas comerciales, necesidades de datos y requisitos de atributos de calidad. A continuación, realice una investigación de mercado inicial para determinar qué paquetes son candidatos viables que merecen una mayor consideración. Luego puede usar los requisitos que identificó como criterios de evaluación en un proceso de selección de software COTS informado.
Un enfoque de evaluación incluye la siguiente secuencia de actividades:
- Pondera tus necesidades en una escala del 1 al 10 para distinguir su importancia.
- Califique cada paquete candidato en cuanto a qué tan bien satisface cada requisito. Use una calificación de 1 para satisfacción total, 0.5 para satisfacción parcial y 0 para no cobertura. Puede encontrar la información para realizar esta evaluación en la documentación del producto, la respuesta de un proveedor a una solicitud de propuesta (RFP) o el examen directo del producto. Tenga en cuenta que una RFP es una invitación a ofertar por un proyecto y es posible que no brinde información que refleje cómo pretende usar el producto. El examen directo es necesario para requisitos de alta prioridad.
- Calcule la puntuación de cada candidato según el peso que le dio a cada factor para ver qué productos parecen ajustarse mejor a sus necesidades.
- Evalúe el costo del producto, la experiencia y viabilidad del proveedor, el soporte del proveedor para el producto, las interfaces externas que permitirán la extensión y la integración, y el cumplimiento de cualquier requisito o restricción de tecnología para su entorno. El costo será un factor de selección, pero evalúe a los candidatos inicialmente sin considerar su costo.
Puede considerar qué requisitos no cumple ninguno de los paquetes candidatos y requerirá que desarrolle extensiones. Estos pueden agregar costos significativos a la implementación de COTS y deben ser considerados en el proceso de evaluación.
Recientemente, mi organización quería seleccionar una herramienta de administración de requisitos que, entre otras capacidades, permitiera a los usuarios trabajar sin conexión y sincronizar con la versión maestra de los requisitos cuando los usuarios volvieran a estar en línea. Sospechábamos que ninguna herramienta en el mercado ofrecería una buena solución para esto. Incluimos esta capacidad en nuestra evaluación para asegurarnos de descubrir cualquier solución que la ofreciera. Si no encontráramos uno, sabríamos que era una capacidad que tendríamos que implementar como una extensión del paquete seleccionado. Alternativamente, necesitaríamos cambiar nuestro proceso para editar los requisitos.
Otro enfoque de evaluación es determinar si el paquete permitirá que los usuarios realicen sus tareas, y qué tan bien, derivando pruebas de los casos de uso de alta prioridad. Incluya pruebas que exploren cómo el sistema maneja las condiciones de excepción significativas que puedan surgir. Recorra esas pruebas para ver cómo las manejan los paquetes candidatos. Un enfoque similar es ejecutar el producto COTS a través de un conjunto de escenarios que representan los patrones de uso esperados, lo que se denomina perfil operativo. Asegúrese de tener al menos una persona cuya participación abarque todas las evaluaciones que realice. De lo contrario, no hay garantía de que se hayan utilizado interpretaciones comparables de las características y puntuaciones.
El resultado del proceso de evaluación suele ser una matriz de evaluación con los requisitos de selección en las filas y las puntuaciones de varias soluciones para cada uno de esos requisitos en las columnas. La Figura 1 muestra parte de una matriz de evaluación de muestra para una herramienta de gestión de requisitos.
Figura 1. Una muestra de una matriz de evaluación de solución empaquetada para una herramienta de gestión de requisitos.
Cuando tenga muchos paquetes potenciales para elegir, planee realizar un proceso de evaluación de varias etapas. Cuando escribí los requisitos para seleccionar una herramienta de gestión de requisitos para que la usaran nuestros propios equipos de consultoría, trabajé con los equipos para identificar las clases de usuarios y los casos de uso de la herramienta. Aunque los usuarios principales eran analistas de negocios, también hubo algunos casos de uso para gerentes, desarrolladores y clientes. Definí casos de uso por nombre y usé mi familiaridad con los casos de uso para identificar las características deseadas. Creé una matriz de trazabilidad para minimizar la probabilidad de que se pasaran por alto casos de uso o características.
Comenzamos con 200 funciones y 60 opciones de proveedores, que eran demasiados para nuestro cronograma de evaluación. Hicimos una evaluación de primer paso para eliminar la mayoría de las herramientas candidatas. Nuestro primer paso consideró solo 30 características que consideramos las más importantes o las más probables para distinguir las herramientas entre sí. Esta evaluación inicial redujo nuestra búsqueda a 16 opciones de herramientas. Luego evaluamos esos 16 contra el conjunto completo de 200 características. Esta evaluación detallada de segundo nivel dio como resultado una lista de cinco herramientas estrechamente clasificadas, todas las cuales claramente satisfarían nuestras necesidades.
Además de un análisis objetivo, es una buena idea evaluar los paquetes candidatos utilizando un proyecto real, no solo el proyecto tutorial que viene con el producto. Terminamos agregando un tercer nivel de evaluación para probar cada una de esas cinco herramientas en proyectos reales para que pudiéramos ver cuál reflejaba mejor los puntajes de evaluación en la práctica. La tercera fase de la evaluación nos permitió seleccionar nuestra herramienta favorita entre las de mayor puntuación.
Con demasiada frecuencia, los paquetes de software comercial que seleccionamos resultan decepcionantes porque no satisfacen nuestras necesidades comerciales de una manera aceptable para los usuarios. Esto puede conducir a un costoso desarrollo personalizado necesario para que la solución funcione para usted. Para evitar sorpresas tan desagradables, realice una evaluación exhaustiva antes de escribirle al proveedor un cheque considerable.
Autores: Karl Wiegers y Joy Beatty
Karl Wiegers es consultor principal de Process Impact, www.processimpact.com. Joy Beatty es vicepresidenta de Seilevel, www.seilevel.com. Karl y Joy son coautores del libro premiado Requisitos de software, 3.ª edición, del que se adapta este artículo. El libro más reciente de Karl es Consultoría de análisis empresarial exitosa: estrategias y consejos para hacerlo solo.
