La ingeniería de rendimiento abarca las técnicas que se aplican durante el ciclo de vida del desarrollo de un sistema para garantizar que se cumplan los requisitos no funcionales de rendimiento (como el rendimiento , la latencia o el uso de la memoria ). También se la puede denominar ingeniería de rendimiento de sistemas dentro de la ingeniería de sistemas e ingeniería de rendimiento de software o ingeniería de rendimiento de aplicaciones dentro de la ingeniería de software .
A medida que la conexión entre el éxito de las aplicaciones y el éxito empresarial sigue ganando reconocimiento, en particular en el ámbito móvil, la ingeniería del rendimiento de las aplicaciones ha asumido un papel preventivo y perfeccionador [1] dentro del ciclo de vida del desarrollo de software. Como tal, el término se utiliza normalmente para describir los procesos, las personas y las tecnologías necesarias para probar eficazmente los requisitos no funcionales, garantizar el cumplimiento de los niveles de servicio y optimizar el rendimiento de las aplicaciones antes de la implementación.
El término ingeniería de rendimiento abarca más que solo el software y la infraestructura de soporte, y como tal, el término ingeniería de rendimiento es preferible desde una perspectiva general. El cumplimiento de los requisitos no funcionales también se valida después de la implementación mediante el monitoreo de los sistemas de producción. Esto es parte de la gestión de servicios de TI (consulte también ITIL ).
La ingeniería de rendimiento se ha convertido en una disciplina independiente en varias grandes corporaciones, con tareas independientes pero paralelas a la ingeniería de sistemas. Es omnipresente e involucra a personas de múltiples unidades organizacionales, pero predominantemente dentro de la organización de tecnología de la información .
Debido a que esta disciplina se aplica dentro de múltiples metodologías, las siguientes actividades se llevarán a cabo dentro de fases específicas diferentes. Sin embargo, si se utilizan las fases del proceso unificado racional (RUP) como marco, las actividades se llevarán a cabo de la siguiente manera:
Durante la primera fase conceptual de un programa o proyecto, se identifican los procesos empresariales críticos . Normalmente, se clasifican como críticos en función del valor de los ingresos, los ahorros de costes u otro valor empresarial asignado. Esta clasificación la realiza la unidad de negocio, no la organización de TI. En este momento se identifican y describen los riesgos de alto nivel que pueden afectar al rendimiento del sistema. Un ejemplo podrían ser los riesgos de rendimiento conocidos para un sistema de un proveedor en particular. Por último, se identifican las actividades de rendimiento, los roles y los resultados para la fase de elaboración. Las actividades y la carga de recursos se incorporan a los planes del proyecto de la fase de elaboración.
Durante esta fase de definición, los procesos empresariales críticos se descomponen en casos de uso críticos . Los casos de prueba se descompondrán aún más, según sea necesario, en transiciones de una sola página (pantalla). Estos son los casos de uso que se someterán a pruebas de rendimiento basadas en scripts .
Los tipos de requisitos relacionados con la ingeniería de rendimiento son los requisitos no funcionales o NFR. Mientras que un requisito funcional se relaciona con las operaciones comerciales que se deben realizar, un requisito no funcional relacionado con el rendimiento se relacionará con la velocidad con la que se realiza esa operación comercial en circunstancias definidas.
Al comienzo de esta fase se requieren una serie de actividades relacionadas con las herramientas de rendimiento, entre ellas:
El equipo de pruebas de rendimiento normalmente no ejecuta pruebas de rendimiento en el entorno de desarrollo, sino en un entorno de preimplementación especializado que está configurado para ser lo más parecido posible al entorno de producción planificado. Este equipo ejecutará pruebas de rendimiento en relación con los casos de prueba , validando que los casos de uso críticos se ajusten a los requisitos no funcionales especificados. El equipo ejecutará pruebas de carga en relación con una carga esperada normalmente (mediana), así como una carga máxima. A menudo, ejecutarán pruebas de estrés que identificarán los cuellos de botella del sistema. Los datos recopilados y el análisis se enviarán al grupo que realiza el ajuste del rendimiento . Cuando sea necesario, se ajustará el sistema para que las pruebas no conformes se ajusten a los requisitos no funcionales.
Si se ha aplicado la ingeniería de rendimiento correctamente en cada iteración y fase del proyecto hasta este punto, es de esperar que esto sea suficiente para permitir que el sistema reciba la certificación de rendimiento. Sin embargo, si por alguna razón (quizás no se aplicaron las prácticas de trabajo adecuadas de ingeniería de rendimiento) hay pruebas que no se pueden ajustar para cumplir con los requisitos, será necesario devolver partes del sistema al desarrollo para su refactorización. En algunos casos, el problema se puede resolver con hardware adicional, pero agregar más hardware conduce rápidamente a rendimientos decrecientes.
Durante esta fase final, el sistema se implementa en el entorno de producción. Se requieren una serie de pasos preparatorios, entre ellos:
Una vez implementado el nuevo sistema, las operaciones en curso retoman actividades de rendimiento, incluyendo:
En el dominio operativo (implementación posterior a la producción), la ingeniería de rendimiento se centra principalmente en tres áreas: gestión del nivel de servicio , gestión de la capacidad y gestión de problemas .
En el área de gestión de niveles de servicio, la ingeniería de rendimiento se ocupa de los acuerdos de niveles de servicio y de la supervisión de sistemas asociados que sirve para validar el cumplimiento de los niveles de servicio, detectar problemas e identificar tendencias. Por ejemplo, cuando se implementa la supervisión de usuarios reales, es posible garantizar que las transacciones de los usuarios se ejecuten de conformidad con los requisitos no funcionales especificados. El tiempo de respuesta de las transacciones se registra en una base de datos de modo que se puedan ejecutar consultas e informes en relación con los datos. Esto permite realizar análisis de tendencias que pueden resultar útiles para la gestión de la capacidad. Cuando las transacciones de los usuarios se salen de los límites, los eventos deben generar alertas para que se pueda prestar atención a la situación.
En el caso de la gestión de la capacidad, la ingeniería de rendimiento se centra en garantizar que los sistemas se mantengan dentro del cumplimiento de las normas de rendimiento. Esto significa ejecutar análisis de tendencias en los datos generados por el seguimiento histórico, de modo que se pueda predecir el momento en que se produzcan incumplimientos en el futuro. Por ejemplo, si un sistema muestra una tendencia a la ralentización del procesamiento de transacciones (que puede deberse a un aumento del tamaño de los conjuntos de datos, a un aumento de la cantidad de usuarios simultáneos o a otros factores), en algún momento el sistema dejará de cumplir los criterios especificados en los acuerdos de nivel de servicio. La gestión de la capacidad se encarga de garantizar que se añada capacidad adicional antes de ese punto (más CPU, más memoria, nueva indexación de bases de datos, etc.) de modo que las líneas de tendencia se restablezcan y el sistema se mantenga dentro del rango de rendimiento especificado.
En el ámbito de la gestión de problemas, las prácticas de ingeniería de rendimiento se centran en resolver la causa raíz de los problemas relacionados con el rendimiento. Por lo general, esto implica ajustar el sistema, cambiar los parámetros del sistema operativo o del dispositivo o incluso refactorizar el software de la aplicación para resolver el bajo rendimiento debido a un diseño deficiente o malas prácticas de codificación.
Para garantizar que exista una retroalimentación adecuada que valide que el sistema cumple con las métricas de rendimiento especificadas por el NFR, cualquier sistema importante necesita un subsistema de monitoreo. La planificación, el diseño, la instalación, la configuración y el control del subsistema de monitoreo se especifican mediante un proceso de monitoreo definido adecuadamente. Los beneficios son los siguientes:
El componente de análisis de tendencias de este sistema no se puede subestimar. Esta funcionalidad, correctamente implementada, permitirá predecir cuándo una aplicación determinada que soporta cargas de usuarios en aumento gradual y conjuntos de datos cada vez mayores superará los requisitos de rendimiento no funcional especificados para un caso de uso determinado. Esto permite una gestión adecuada del presupuesto, la adquisición y la implementación de los recursos necesarios para mantener el sistema funcionando dentro de los parámetros de los requisitos de rendimiento no funcional.