ALGUNAS PREGUNTAS SOBRE LA GESTIÓN DE REQUERIMIENTOS

Se suele decir que un buen código tiene en el fondo un buen diseño, sin embargo, un buen diseño solamente se puede verificar teniendo claros los objetivos del producto cuyo desarrollo ha sido emprendido. ¿Quiere decir esto que las únicas características susceptibles de ser medidas están asociadas directamente al dominio de los problemas que dicho desarrollo soluciona?  De no ser así, ¿existe un mínimo de características de naturaleza subyacente que emerge de manera implícita en cada uno de los requerimientos del desarrollo?

Para ponerlo en términos mas simples, cuando decidimos construir software por ejemplo un editor de texto un requisito puede estas asociado a la capacidad del sistema para escribir contenidos por parte de un usuario.  Sin embargo, un requerimiento funcional de este tipo no puede estar completo de ninguna manera sin  tener en cuenta el numero de palabras que deben ser escritas en un tiempo de referencia.  Es decir. No nos sirve que se puedan escribir palabras si cada letra se demora un minuto en procesarse, seria en la practica un sistema completamente inútil.

Si acordamos entonces que existen requerimientos subyacentes a este primero nuestra especificación crecería notablemente y nada sería capaz de garantizarnos que nuevos requerimientos no presenten la misma situación recurrentemente y hasta el infinito.  ¿Cuál seria entonces la granularidad de los requerimientos de manera tal que sea viable establecer con exactitud las caracteristicas funcionales del producto y todos los requerimientos hijos relevantes?  Pareciera que la respuesta se encuentra en las bases mismas del lenguaje. Nada que sea lo suficientemente claro de manera general debe ser reformulado con el fin de esclarecer detalles redundantes.  Los requerimientos técnicos comunes deben plantearse de manera no redundante para poder alcanzar la completitud y la sencillez de manera sensata en nestras definiciones.

Si vieramos una especificacion de un sistema como un arbol donde los nodos de dicho arbol son requerimientos . ¿podriamos construir un algoritmo para construir dicho arbol minimizando el numero de niveles y maximizando la descripcion del problema?  ¿Podríamos realizar una clasificación automática sobre los conjuntos de tipos de requisitos técnicos generales que son comunes a un subconjunto de requerimientos?  Probablemente basados en la experiencia previa algunos algoritmos existentes de clasificación y optimización podrían afinar con precisión cada vez mayor en el tiempo las predicciones de asociaciones o relaciones entre requisitos funcionales y técnicos, logrando una mayor robustez en las definiciones y los objetivos de nuestros desarrollos.

Otra pregunta que podríamos hacernos sería, ¿Existe alguna forma de poder detectar en un esquema evolutivo de los requerimientos aquellas tareas que al final del ciclo de vida del desarrollo no habrán generado valor alguno en el producto final?  Resolver este tipo de interrogantes pueden representar mejoras significativas en la productividad de los equipos, sin embargo, algunas parecen estar asociadas con la visión estratégica de la gestión de los proyectos y otras parecen estar relacionadas con la forma en la que crecen las expectativas a medida que avanzamos en la construcción de los conceptos fundamentales del sistema en cuestión.

Seria interesante poder armar un modelo sencillo con las premisas esperadas con el fin de poder determinar si este tipo de interrogantes sobre la gestión de los requisitos puede abordarse de manera general o si estamos destinados a lidiar sin ninguna generalización clara con las dependencias aparentemente aleatorias entre los criterios que determinarán la calidad del software entregado.  Espero que esto se analice en una entrada posterior.

Profiling de aplicaciones

Profiling de aplicaciones

El profiling de aplicaciones es un estilo de análisis dinámico de software en el cual una herramienta llamada comunmente profiler recolecta información sobre el tiempo utilizado durante la ejecución de un programa por parte de los componentes a evaluar con el ánimo de identificar demoras o situaciones que puedan representar problemas de rendimiento de la aplicación. De manera general lo que se busca con este tipo de pruebas es identificar los tiempos o el uso de los componentes que conforman nuestra aplicación. 

El análisis realizado al utilizar la información recolectada durante la ejecución de la aplicación en cuestión estará relacionado directamente con el método utilizado para obtener los datos, por lo que el tipo de herramienta utilizada se vuelve de vital importancia para tener una buena idea de la calidad o resolución de los datos obtenidos.  Como regla podríamos decir que a medida que obtengamos mayor exactitud en los datos recolectados, mayor será el impacto en el rendimiento de la aplicación monitoreada. A continuación se describen los tipos más comunes de profilers según la forma utilizada para monitorear la ejecución y se presentan adicionalmente algunas ventajas y desventajas de los mismos.

Basados en eventos

Este tipo de herramientas permiten la verificación de la mayoría de los tipos de evento presentados durante la ejecución de la aplicación objetivo, por ejemplo, el inicio de un llamado a una función o la carga de una biblioteca dinamica.  Dado que la información se relaciona directamente los eventos producidos, este tipo de aplicaciones puede impactar el performance de la aplicación de manera general, por lo que es usual que se utilice en ambientes de desarrollo y pruebas de investigación pero no en escenarios donde afectar el rendimiento del sistema pueda representar un riesgo como en el ambiente de producción.  La resolución de este tipo de herramientas es por lo general mejor que la de otro tipo de profilers por la cantidad de datos recolectados pues no tienen pérdidas significativas de información relacionada con los eventos interceptados.

Profilers estadísticos

Los profilers estadísticos por otra parte funcionan recolectando muestras periódicas, es decir, interrumpiendo la ejecución de la aplicación analizada y verificando la tarea realizada en el momento de la interrupción.  Típicamente este tipo de profilers utilizan llamados a funciones del sistema operativo para suspender los procesos y obtener el valor del program counter o puntero a instrucción (EIP, RIP) periodicamente y realizar un recorrido llamado stackwalk en el que se identifican las funciones en la pila de llamados a partir de la navegación entre cada uno de los frames en la pila del hilo en ejecución.  Numéricamente los valores obtenidos con este tipo de herramientas son de una precisión inferior a los obtenidos con los profilers basados en eventos y esto se debe a que la información analizada corresponde únicamente a la obtenida para los puntos de ejecución muestreados, sin embargo, una cualidad de este tipo de herramientas radica en su bajo impacto en el rendimiento de la aplicación, logrando que el programa objetivo funcione más cerca de su velocidad real.

Profilers de instrumentación

Otro tipo de herramientas abordan el problema de obtención de datos modificando la aplicación que se desea analizar, al código agregado se le denomina instrumentación y dependiendo de los puntos instrumentados (por ejemplo si decidiéramos instrumentar todo el código) dentro de la aplicación puede suponer un gran impacto en el rendimiento de la aplicación medida.  Para que las pruebas sean efectivas y correctas este tipo de herramientas dependen en gran medida de lo específica que sea la instrumentación realizada y no brindan gran flexibilidad sobre el impacto en la aplicación.  Desafortunadamente para la identificación de problemas suele requerir que se tenga una idea de los componentes implicados en la situación para poder instrumentarlos, hecho que no siempre es evidente.

Salida de profilers

Según el tipo de salida generada los profiler peden clasificarse en dos categorías, la primera corresponde a aquellas herramientas que únicamente calculan el tiempo promedio por llamado sin preocuparse de diferenciar entre el tiempo propio del método o función involucrada y el tiempo consumido por los llamados a otros métodos por parte de dicha función, a este tipo de herramientas se les conoce como profilers planos o flat profilers.   La segunda categoría está asociada con las herramientas cuya salida contemplan en su análisis las diferentes rutas del código y el contexto de la ejecución y pueden diferenciar entre el tiempo própio consumido por una función del tiempo consumido por cada uno de sus llamados, a estas herramientas se les conoce como profilers de gráfos de llamadas y son más detallados y elaborados que los profilers planos.

No olvides la escalabilidad

¿Qué es escalabilidad?

La escalabilidad se puede definir informalmente como la posibilidad que posee un sistema para incrementar su capacidad de atención a medida que el número de solicitudes o usuarios se incrementa.   Es en otras palabras la forma en la cual un sistema puede adaptarse a los cambios potenciales en la demanda sin perder calidad en el servicio prestado.   De esta manera, se debe considerar la escalabilidad al momento de adquirir y producir aplicaciones informáticas, por ejemplo, suponga que usted administra una universidad y para efectos administrativos se necesita un sitio web donde se puedan publicar las notas de cada uno de los estudiantes, inicialmente la institución educativa tendrá 1000 estudiantes y se adquiere un software capaz de manejar 500 usuarios por minuto, como todos los estudiantes no entran al mismo tiempo a consultar sus notas, es probable que el sistema adquirido cumpla con la capacidad, sin embargo a medida que la institución adquiere prestigio en su entorno, el número de estudiantes se incrementa digamos que a unos 5000, es muy probable que durante periodos de entregas de notas estos nuevos estudiantes logren superar la capacidad permitida por la aplicación usada para la administración. Una primera solución es encontrar otra aplicación que supla la necesidad, sin embargo, si la tendencia en crecimiento se mantiene para el siguiente año se tendrá nuevamente el mismo problema.  Este sencillo ejemplo nos sugiere que las aplicaciones deberían poder adaptarse  a los cambios en la demanda de los servicios prestados por las mismas, y este tipo de situaciones son las que hacen necesario que las empresas productoras de software  deban evaluar lo que se define como escalabilidad para cada una de las aplicaciones que se producen de tal manera que siempre exista un mecanismo claro  que pueda ser utilizado para aumentar su capacidad y conservar la calidad y los niveles de servicios adecuados para las operaciones realizadas. 

En la mayoría de las ocasiones dicho mecanismo estará relacionado con agregar nuevo hardware a la infraestructura de operación, por ejemplo agregando mas máquinas o mejor hardware.  Teniendo en cuenta que ambas opciones pueden generar un incremento de la capacidad, la escalabilidad de aplicaciones puede clasificarse a partir de las siguientes categorías.

Escalabilidad Vertical

La escalabilidad vertical es la manera de conseguir mayores niveles de atención incrementando las capacidades de los recursos específicos consumidos por las aplicaciones, por ejemplo, aumentando el tamaño de la memoria principal, el número de CPUs de una máquina, el espacio en disco  o agregando tarjetas de red más potentes.

Aunque es cierto que en primera instancia esta puede ser una forma sencilla de aumentar la capacidad de los servicios prestados por nuestras aplicaciones, el sentido común nos indica que existe un límite asociado con el hardware que podemos actualizar, es decir, si nuestras tendencias de crecimiento están acordes con la ley de Moore, no debería haber ningún problema, pues todos los años contaríamos con componentes de hardware superiores a los del año anterior, pero ¿que ocurre si estamos creciendo por encima de la velocidad a la cual crece la capacidad del nuevo hardware?  Esta es una pregunta que puede llegar a ser un poco molesta, porque plantea aspectos del diseño de las aplicaciones que debieron ser considerados mucho antes de poder identificar que este tipo de problemas se podrían presentar, dependeremos entonces de la posibilidad de que nuestra aplicación pueda escalar horizontalmente.

Escalabilidad Horizontal

Como se mencionó anteriormente la escalabilidad vertical tiene un límite, y este se produce cuando ya no existe el hardware que necesitamos para proveer con la misma calidad a nuestro creciente número de usuarios dentro de la operación.  Si pensamos en la escalabilidad vertical como el hecho de aumentar el tamaño de un tanque de agua utilizado para suministrar un fluido a una población, podríamos visualizar la escalabilidad horizontal como el incremento del fluido suministrado agregando cada vez mas tanques de manera tal que la escalabilidad horizontal nos proporcionará un mecanismo repetible indefinidamente a medida que el número de usuarios se incremente, logrando que la capacidad del sistema se adapte cada vez a la nueva demanda.

Metricas y valores esperados

Métricas y valores esperados

Qué es una métrica y para qué sirve?

De manera sencilla una métrica se puede definir como una medida o un conjunto de medidas que determinan una característica de un sistema.  Por ejemplo, en un sistema de aprendizaje una métrica podría estar dada por el número de estudiantes reprobados en un curso, este valor nos dará una idea de una característica de nuestro sistema escolar por ejemplo para la metodología de los docentes.   Las métricas al igual que en el resto de disciplinas, se utiliza en el software para cuantificar aspectos de interés de modo que nos permita tener una visión clara y objetiva de lo que estamos midiendo y establecer mecanismos para mejorar dicha característica.  En esta entrada nos centraremos en las métricas de rendimiento de las aplicaciones, que como se espera nos ayudarán identificar problemas de rendimiento y poder tomar acciones sobre los mismos.  Dentro de los beneficios de proporciona la utilización de métricas en cualquier área del conocimiento y consecuentemente en el software tenemos:         

• Análisis: Podremos analizar y comprender las capacidades del sistema en cuestión de manera objetiva.

•  Control: Se pretende poder realizar ajustes utilizando la información de dichas métricas para mantener las características en los estados deseados.

•   Predicción: Una vez se ha iniciado un estudio con el uso de métricas sobre una característica de un sistema se hace más fácil predecir situaciones que de otra manera serían imposibles de entender.

•  Mejora: Las métricas nos proporcionan herramientas para mejorar las características que cuantificamos.  Si se manejan objetivamente, mejorar una métrica en la mayoría de los casos es equivalente a mejorar la característica en cuestión.

Es importante tener en cuenta que solamente aquellas características que son susceptibles de ser medidas podrán manejarse utilizando métricas, por suerte, en la evaluación del performance de las aplicaciones casi todas las características se pueden medir.  Aunque parezca extraña esta aclaración, existen aspectos de la vida que no se pueden medir, como la moral , la felicidad y muchos otros aspectos relacionados con cuestiones humanas, en términos generales lo medible está asociado a unidades físicas, como tiempo, espacio, memoria, etc.  Las métricas están basadas en conceptos medibles que son relaciones abstractas entre las características de las entidades medidas.

En la evaluación del software existen algunos objetos o entidades de interés particular en el estudio del comportamiento de las aplicaciones.  A continuación presentamos algunas:

•          Servicios
•          Productos
•          Procesos
•          Recursos

Las características o atributos según su cercanía con los usuarios pueden ser internos o externos, dependiendo de si los usuarios son conscientes de la existencia de la característica.  Dentro de las características que nos interesan medir para el performance de aplicaciones encontramos dos que suelen ser importantes.

•          Comportamiento en el tiempo
•          Utilización de recursos

Usualmente el comportamiento en el tiempo es afectado por la utilización de los recursos y los recursos son retenidos por problemas de lógica con un rendimiento pobre.  Por ejemplo si una aplicación web utiliza una base de datos y la aplicación tiene problemas de desempeño, dicha aplicación podría provocar bloqueos en los recursos de la base de datos, de la misma manera si los recursos no fueran suficientes en el servidor de bases de datos se podrían presentar pérdidas de rendimiento en la aplicación web que la usa.  Casi todas las métricas de performance están asociadas a cuantificar aspectos que se relacionan con el tiempo o con los recursos. 

Una métrica consta de un método de medición por ejemplo una formula y una escala para los valores obtenidos a partir de dicho método.   Las métricas pueden ser directas si solo dependen de la característica o atributo que se está midiendo o indirectas si dependen adicionalmente de otras métricas y se formalizan a partir de una función de medición.

Las métricas de rendimiento por lo general son independientes de los escenarios, de las plataformas, del hardware y de la lógica de negocio que se esté probando.

Categorización de métricas

Según la cercanía con el usuario

•          Internas: La característica que evalúa la métrica depende únicamente de factores internos del diseño y los usuarios no tienen consciencia de su existencia.

•          Externas: Los Usuarios son conscientes o tienen un contacto directo con la característica que evalúa la métrica en cuestión y sus valores pueden depender de aspectos específicos de la lógica de negocio de la aplicación.

Según sus valores deseables

Las métricas de performance según los valores deseados se pueden categorizar en tres tipos:

•          Deseablemente decrecientes: Este tipo de métricas son aquellas en las cuales esperamos que un mejor comportamiento de la característica que pretende medir en el sistema esté asociado con la disminución del valor de dicha métrica, es decir, mientras menor sea el valor será mejor.  Un ejemplo de esta categoría es el tiempo de respuesta de una aplicación, se espera que mejoras en el rendimiento se reflejen en la disminución de los valores de dicha métrica.

•          Deseablemente crecientes: A diferencia de la categoría  anterior, a este conjunto de métricas pertenecen aquellas en las que un incremento de los valores obtenidos se asocia con una mejora en el rendimiento de la aplicación.  Como ejemplo podemos ver el throughput o la productividad del sistema mientras mayor sea su valor mayor mejor será el rendimiento del sistema.

•          Valores nominales deseables: En ocasiones existen características de nuestras aplicaciones cuyos indicadores o métricas asociadas no convienen que sean demasiado bajas o demasiado altas sino que se encuentren en lo que llamamos un valor nominal, el cual es el valor óptimo o deseado para la característica analizada.  Un ejemplo de este tipo de métricas es la utilización de la CPU, si el valor es muy bajo para un gran volumen de transacciones, puede deberse a problemas de rendimiento de la aplicación en cuestión desperdiciando el recurso específico y si el uso de CPU es muy alto, la aplicación podría estar impactando otros aspectos del servidor como la estabilidad del propio sistema operativo haciendo que todo fluya de manera más lenta y riesgosa.  Podríamos decidir de manera arbitraria que el valor nominal fuera un 50%.

Según el marco de referencia

Dependiendo de si una característica se evalúa en un solo contexto o si existen valores de referencia con los cuales se contrastan las mediciones, las métricas se pueden clasificar en las siguientes categorías:

•           Absolutas: Son aquellas métricas que dependen únicamente de mediciones realizadas en la aplicación que se está midiendo, por lo cual únicamente reflejan el comportamiento de la característica evaluada de manera individual o aislada. Un ejemplo de este tipo de métricas sería el tiempo de respuesta de un método en una clase.

•           Relativas: Las métricas pertenecientes a este grupo definen el comportamiento de la característica evaluada en relación a un comportamiento base que en muchos casos corresponde a una segunda aplicación de referencia, por ejemplo, la diferencia entre los tiempos de respuesta de dos aplicaciones.  Las métricas pueden ser relativas a otras métricas o a valores nominales.

Según la naturaleza de la medición

•          De recursos: La característica medida se relacionada con recursos del sistema, por ejemplo, el número de escrituras en disco debido a un evento dado.

•          De tiempo: La característica evaluada es una duración o un valora asociado al tiempo como el periodo o la frecuencia de un evento.

•          De complejidad: Este tipo de métricas pretende cuantificar la complejidad computacional del sistema, por ejemplo, para el número de ciclos en el código para una operación particular.  Aunque puede que estas no midan directamente temas de desempeño, puede que perdidas en el desempeño estén relacionadas directas o indirectamente con los aspectos medidos por las mismas.

•          De calidad: Encontramos en algunas ocasiones métricas que no miden ni recursos, ni tiempos, ni temas de complejidad, sin embargo, el mejoramiento de las mismas puede representar un mejoramiento en el rendimiento del sistema. Un ejemplo podría ser la tendencia en un comportamiento de la aplicación como la estabilidad o cualquier aspecto del diseño.