Subiendo de Nivel tu App Bancaria

 Mejora del Proceso basada en Modelos

Imagina que trabajas en el equipo de calidad de un banco. Para asegurar que la App de Banca Móvil no falle al hacer transferencias, no basta con probar por intuición; necesitamos un estándar. La mejora basada en modelos parte de una idea clave: si tu proceso de trabajo es bueno, el software final será de alta calidad.

¿Qué es un modelo de mejora?

Piensa en estos modelos como un "entrenamiento profesional" para equipos de software. En lugar de inventar el hilo negro, usamos marcos de trabajo como TMMi® o TPI NEXT®, que agrupan las mejores prácticas de la industria y las organizan por niveles.

El Modelo TMMi® en el Mundo Bancario

El TMMi® es el estándar más famoso y tiene 5 niveles de madurez:

1. Nivel 1: Las pruebas son caóticas y reactivas.
2. Niveles superiores: Aquí el banco ya tiene procesos definidos, como una planificación clara, medición de resultados y prevención de errores.

Si tu proyecto de "Pago con QR" está en un nivel bajo, podrías notar que siempre encuentran errores críticos justo antes del lanzamiento. Al aplicar el modelo, el equipo aprende a diseñar pruebas más inteligentes y a planificar mejor los recursos, subiendo de nivel y volviéndose más predecible.

Aplicación a tu Proyecto

No necesitas cambiar a todo el banco de golpe. Puedes aplicar estas mejoras solo a nivel de proyecto, enfocándote en lo que haces a diario: cómo diseñas tus casos de prueba o cómo reportas los fallos. Incluso si el equipo usa metodologías Ágiles, existen guías para adaptar estos modelos y asegurar que la app sea rápida, pero sobre todo, segura y confiable para el dinero de los clientes.

¡El Sello de Aprobación Final!

Pruebas de aceptación

¡Bienvenidos al último nivel de prueba antes de lanzar el producto! 

Imagina que has creado una nueva aplicación y ahora queremos asegurarnos de que cumpla con los estándares y necesidades de los usuarios antes de que llegue a sus manos.

Responsabilidades en la Prueba de Aceptación: ¡Clientes al Mando!

En este nivel, los clientes, usuarios de negocio, propietarios del producto o incluso los operadores del sistema son los que se encargan de la prueba de aceptación. Todos los interesados en el producto también pueden participar para asegurarse de que todo funcione correctamente.

La Prueba de Aceptación en Diferentes Momentos

La prueba de aceptación generalmente se considera el último paso en un ciclo de desarrollo secuencial. Sin embargo, puede ocurrir en otros momentos también:

Cuando instalamos o integramos un producto software comercial que se distribuye masivamente (COTS), antes de realizar la prueba de sistema, cuando queremos probar una nueva mejora o funcionalidad.

Prueba de Aceptación en el Desarrollo Iterativo

En un desarrollo iterativo, los equipos pueden realizar diferentes formas de prueba de aceptación. Por ejemplo, pueden centrarse en verificar que una nueva característica cumpla con los criterios de aceptación establecidos o validar que satisface las necesidades de los usuarios. También pueden realizar pruebas alfa y beta, que son como versiones preliminares para que los usuarios las prueben y ofrezcan su opinión.

Diferentes Enfoques de Prueba de Aceptación

En este nivel, hay diferentes enfoques para asegurarse de que todo esté listo para el lanzamiento:

• Prueba de Aceptación de Usuario: Los usuarios prueban el producto para ver si es fácil de usar y cumple con sus expectativas.
• Prueba de Aceptación Operativa: Se verifica que el producto funcione correctamente en el entorno operativo real.
• Prueba de Aceptación Normativa: Asegura que el producto cumpla con todas las normas y regulaciones establecidas.
• Prueba de Aceptación Contractual: Se verifica que el producto cumpla con los términos del contrato establecido.

El Ultimo Paso hacia el Éxito

La prueba de aceptación es el último paso antes de lanzar el producto al mundo. Aquí es donde todos los detalles se ponen a prueba para asegurarnos de que los usuarios estarán satisfechos. Si todo va bien, ¡el producto recibirá su sello de aprobación final y estará listo para ser utilizado y disfrutado por todos!

La importancia de los CVDS

 Modelos de ciclo de vida

El modelo de ciclo de vida de desarrollo de software que se utiliza depende de las necesidades del proyecto de desarrollo de software. Por ejemplo, si el proyecto es complejo y tiene muchos requisitos, es posible que se utilice un modelo en cascada. Si el proyecto es más pequeño y tiene requisitos menos complejos, es posible que se utilice un modelo iterativo o ágil.

Dependiendo del contexto del proyecto, puede ser necesario combinar o reorganizar los niveles de prueba y/o las actividades de prueba. Por ejemplo, para la integración de un producto de software comercial de distribución masiva (COTS por sus siglas en inglés) en un sistema más amplio, el comprador puede realizar pruebas de interoperabilidad a nivel de prueba de integración de sistemas (por ejemplo, integración en la infraestructura y otros sistemas) y a nivel de prueba de aceptación (funcional y no funcional, junto con la prueba de aceptación del usuario y la prueba de aceptación operativa). 

Además, se pueden combinar los propios modelos de ciclo de vida de desarrollo de software. Por ejemplo, un modelo en V puede ser usado para el desarrollo y prueba de los sistemas backend y sus integraciones, mientras que un modelo de desarrollo ágil puede ser usado para desarrollar y probar la interfaz de usuario (UI) y funcionalidad del front-end. El prototipado puede ser utilizado en las primeras etapas de un proyecto, adoptando un modelo de desarrollo incremental una vez finalizada la fase experimental.

Los sistemas de Internet de las Cosas (IoT por sus siglas en inglés), que consisten en muchos objetos diferentes, tales como dispositivos, productos y servicios, suelen aplicar modelos de ciclo de vida de desarrollo de software separados para cada objeto. Esto supone un reto especial para el desarrollo de las versiones de sistemas de Internet de las Cosas. Además, el ciclo de vida de desarrollo de software de dichos objetos pone un mayor énfasis en las fases posteriores del ciclo de vida de desarrollo de software después de que se hayan introducido para su uso operativo (por ejemplo, las fases de operación, actualización y retirada).