Etapas del Desarrollo de un Producto de Software

Los requerimientos no funcionales para una aplicación de negocio o servicio técnico incluyen algunos como robustez, escalabilidad, desempeño, operabilidad y otras características que la arquitectura debe soportar.

En el ciclo de desarrollo se debe resolver tempranamente los requerimientos de seguridad, regulaciones, cumplimiento y riesgos asociados.

En esta etapa se debe configurar los servicios y datos necesarios para la iteración actual del ciclo de vida del desarrollo de software. Esto significa registrar o actualizar los permisos y asignar los recursos técnicos necesarios para la operación (servidores, bases de datos, procesos de deployment, repositorios git, canales de comunicación, entre otros). También incluye la asignación de roles y datos de contacto actualizados del equipo, al igual que los datos de gestión del proyecto (creación de backlogs con herramientas de priorización de tareas y gestión de proyectos).

Validación que los requerimientos funcionales y los criterios de aceptación son los suficientemente comprehensivos, claros y estables para tomar decisiones de diseño y la creación de los planes de desarrollo.

Crear contratos de API de alta calidad que aseguren que las abstracciones que proporcionan ayuden a la evolución y mantención (alta cohesión, bajo acoplamiento), sean simples de usar (fácil adopción) y permitan que los desarrolladores las usen eficientemente.

Definir la arquitectura que guíe el desarrollo de la versión actual. De esta forma el desarrollo es coordinado y eficiente y los interesados (stakeholders) estén alineados con las decisiones técnicas tomadas por el equipo. Permitiendo que la organización cree planes de desarrollo y despliegue realistas y apropiados.

Los contratos de API son revisados y auditados para detectar posibles mejoras o problemas que no se tomaron en consideración. Normalmente son revisados por personas externas que no elaboraron los contratos inicialmente. Un grupo de interesados clave de múltiples ámbitos que permite validar la definición a implementar para que esté alineada con el alcance y estratégica técnica y la calidad esperada.

La definición de arquitectura es revisada y auditada para detectar posibles mejoras o problemas que no se tomaron en consideración. Normalmente es revisada por personas externas que no elaboraron los contratos inicialmente. Un grupo de interesados clave de múltiples ámbitos que permite validar la definición a implementar para que esté alineada con el alcance y estratégica técnica y la calidad esperada.

Las elecciones de tecnología y soluciones propuestas para completar un proyecto están influenciadas por diversas decisiones tomadas por los miembros del equipo involucrados en el proyecto durante la fase de desarrollo. Las ADR ayudan a nuevos integrantes del equipo a comenzar más rápido y a documentar los factores que jugaron un rol importante para llegar a una decisión, dando contexto y respondiendo las preguntas ¿Qué?, ¿Por qué?, ¿Cómo?, ¿Cuándo? y ¿Dónde? de cada decisión. Ver anexo Arquitecture Decision Records.

Se construye el artefacto con las herramientas adecuadas y autorizadas, sus repositorios y dependencias. Además de seguir un plan de versionamiento y obsolescencia acordado. Ver anexo Versionado y Política de Compatibilidad y Obsolescencia.

Los artefactos de código están almacenados y respaldados en un repositorio central, el cual tiene normas de higiene establecidas para asegurar la calidad del código que almacena. Siguiendo las buenas prácticas de Trunk Based Development. Ver anexo sobre Trunk Based Development.

Las pruebas unitarias son pruebas deterministas que prueban la ejecución de una unidad específica y discreta de la aplicación como una funcion, un método o componente de UI en total aislamiento del resto de componentes para determinar si se comporta como se espera.

Una prueba funcional o de contrato es una prueba determinista que verifica que los módulos de un sub sistema estén funcionado correctamente. Las pruebas funcionales deben evitar integrar con otros sub sistemas ya que esto reduce el determinismo. Ejemplos son probar el comportamiendo de una interfaz de usuario en la UI o probar la lógica de negocio de un servicio individual por medio de su API.

Las pruebas de integración es una unidad "sociable" de prueba que es determinista y usada para verificar como una unidad interactúa con otras unidades sin acceder directamente a los sub sistemas externos.

Se debe escribir el código usando los lenguajes y frameworks autorizados, siguiendo los estándares y la definición de arquitectura y cumpliendo los criterios de aceptación de los requisitos funcionales y no funcionales. Refactorizando el código para mejorar su calidad, reducir la deuda técnicas y asegurar que el código fuente es mantenible, es decir, que sea simple de modificar en el tiempo siguiendo los principios de alta cohesión y bajo acoplamiento.

La prueba estática evalúa el código sin compilar o ejecutarlo. Esta pensada para validar las buenas prácticas y verificar la seguridad, estructura y otras posibles causas de fallas.

Un miembro del equipo revisa e inspecciona el código para identificar posibles mejoras o defectos a corregir, además de verificar la adherencia a los estándares de calidad de código acordados.

El sistema que se ha construido para la versión actual se compara con lo planificado y diseñado. Cualquier discrepancia es resuelta ya sea corrigiendo el artefacto o actualizando los diseños y planes iniciales.

Los sistemas utilizados por los equipos de operaciones para ejecutar todas las actividades operativas deben ser configurados y activados para el artefacto que será liberado. Esto incluye sistemas para monitoreo, alertas automáticas y administración de notificaciones para incidentes productivos.

Escribir documentación y desarrollar ejemplos para operar el artefacto liberado, en una forma consistente y metódica, incluyendo como manejar las tareas esperadas, realizar escalamiento horizontal/vertical, estrategias de mitigación de fallos y pasos para lograr alcanzar los objetivos operativos y de control de incidentes (Mean time to deploy, Mean time to escalate, Mean time to recover, entre otras métricas asociadas [atlassian-incidents-metrics-2024]).

Se deben completar todas las tareas relacionadas al despliegue (deploy) tales como:

Esta es la validación final de que todas las actividades obligatorias han sido completadas. Los procedimientos de liberación (release) y retrocesos (rollbacks) están en su lugar y habilitados, los procesos y auditorias necesarias para cumplir las normas legales y licencias están listos y funcionales. Finalmente todas los procesos de gestión del cambio están correctamente seguidos y auditados.

Las pruebas de humo (smoke test), o también conocidas como verificación de la construcción (build verification testing) o pruebas de confianza (confidence testing), es un tipo de estrategia para asegurar la calidad, el cual consiste en un conjunto no exhaustivo de pruebas enfocadas en asegurar que que las funciones más importantes del artefacto funcionan. El término "prueba de humo" viene de la industria del hardware donde al probar un artefacto por primera vez, si este no se prendía fuego y salía humo, se puede considerar como que su construcción fue un éxito. En la industria del software las pruebas de humo es una estrategia liviana y amplia donde todas las áreas de una aplicación (sin profundizar mucho) son probadas.

Una suite de pruebas de humo pueden ser automatizadas o en combinación con un proceso manual de pruebas. Pueden ser usadas para descubrir errores de alto nivel. Si una prueba de humo falla se espera que el artefacto construido se considere inestable para mayores pruebas, hasta que la prueba de humo sea exitosa.

Ejemplos:

Las pruebas punto a punto (E2E) prueban y validan que los componentes individuales y las dependencias externas del sistema funcionan adecuadamente para los casos productivos.

Las pruebas de desempeño son realizadas en un ambiente lo más similar a producción posible y se prueban varios tipos de interacciones con el sistema, los cuales permiten determinar cómo el sistema se comporta durante varias condiciones de carga y estrés. Son pensadas para validar que el sistema cumple con los requerimientos de desempeño a nivel de servicio.

Se recomienda realizar un análisis de mapa de calor en los periodos de uso del sistema productivo. Y realizar las pruebas en el ambiente productivo oficial, dentro de una hora de baja o nula utilización con datos apropiadamente marcados que permitan ser eliminados automáticamente una vez terminadas las pruebas.

Debido a sus características de servidor, no es obligatorio realizar pruebas de desempeño constantemente. Solo es recomendable hacerlas antes de cambios mayores en los sistemas o cuando se avecina una fecha especial que requiera mayores exigencias en los servidores (navidad, año nuevo, feriados nacionales). La periodicidad de estas pruebas dependerá de las necesidades de cada negocio.