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.

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.