Requisitos No Funcionales - Parte 1
Con la moda de arquitectura (aunque es indiscutiblemente necesario tener un arquitecto en la organización… jejeje), se ha tomado mas en serio el tema de los REQUISITOS NO FUNCIONALES (aunque no lo crean, se deben tener en cuenta al hacer software), hoy voy a dar unos primeros conceptos para estos requisitos no funcionales.
Según Somerville, los requisitos no funcionales definen propiedades y restricciones del sistema, - aunque la palabra restricciones puede ser ambigua, porque en otros textos, una restricción es algo impuesto por la organización, desde el punto de vista de software, pero sigamos con Somerville. Algunos ejemplos de estos requisitos no funcionales son: Tiempo de Respuesta, Requisitos de almacenamiento, confiabilidad.
Estos requisitos pueden ser mas críticos que los requisitos funcionales, ya que son normalmente a los que debe apuntar la arquitectura y si estos no son cumplidos, el software puede no funcionar o el cliente simplemente no acepta el producto (OJO: No se dejen meter goles con las definiciones de requisitos no funcionales).
Dentro de estos requisitos no funcionales encontramos una clasificación que nos permite identificarlos mas fácilmente (cuando se definen taxonomias de lo que sea lo que se busca es entender mejor el concepto, DIVIDE y CONQUISTARAS; y les puedo garantizar que una clasificación no acelera la terminación del proyecto, pero permite trabajar mejor). Podemos encontrar tres grupos de requisitos no funcionales. Los requisitos de producto, los cuales especifican que el producto debe comportarse de una forma en particular. Ej. Velocidad de ejecución, confiabilidad, escalabilidad y otras tantas que en la parte 2 de esta nota explicaré.
Los requisitos Organizacionales (y aquí nos empezamos a perder porque solo pensamos en bolear código), los cuales son consecuencia de políticas y procedimientos organizacionales. Ej. Delivery, Requisitos de Implementación, Estándares.
Y los requisitos Externos, y estos si se pierden por causa del “síndrome del estudiante” (Otro concepto que explicaré después, pero que tiene que ver con la teoría de los proyectos que dice mi amigo John, donde al principio del proyecto nos dormimos, para después estar apurados), estos requisitos emergen de factores que son externos a los sistemas y sus procesos de desarrollo. Ej. Interoperabilidad, Requisitos Legislativos (Privacidad y Seguridad), Requisitos ETICOS Y MORALES.
Los requisitos no funcionales pueden ser difíciles de encontrar y enunciar de forma precisa y los requisitos que son imprecisos son difíciles de verificar. Por eso se deben definir muy bien las metas (OJO, diferentes a los objetivos… yo creía que eran lo mismo… ahí que arreglar el Enterprise Architect, Ej: El objetivo es medible, la meta es un esfuerzo) porque estas ayudan a los desarrolladores a transmitir las intenciones de los usuarios del sistema y a verificar los requisitos no funcionales.
Podemos ver que las metas y los requisitos no funcionales toman la siguiente forma:
Meta: Intención general de usuario, tal como facilidad de uso.
Requisito no funcional verificable: Un enunciado usando alguna MEDIDA que pueda se objetivamente probada (Y AQUÍ ES DONDE SE METEN LOS GOLES).
Ejemplos:
Una meta del sistema: El sistema debe ser fácil de usar por controladores experimentados y debe estar organizado de tal manera que los errores de usuario sean minimizados (ASI LO ENTREGAN… increíble!!!!).
Un requisito no funcional verificable: Los controladores experimentados deben ser capaces de usar todas las funciones del sistema después de un total de dos horas de entrenamiento. Después de este entrenamiento, el número promedio de errores generados por estos usuarios experimentados no deberá exceder de 2 por día. (ASI LO DEBEMOS TRADUCIR)
Si lo ven bien, si cumplimos este requisito no funcional, indiscutiblemente podemos cumplir con la meta, y por otro lado tenemos una base para iniciar un TRADE-OFF (negociación) con el cliente. Para que se entienda mejor, los requisitos no funcionales pueden presentar conflictos entre ellos, algunas veces cumplir un requisito NF al 100% implica impactar otro requisito. Ej: Portabilidad - Performance. Escalabilidad – Administrabilidad.
Requisito NO FUNCIONAL MAL ESCRITO: El sistema debe ser escalable. (Cuidado con los goles).
Otros ejemplos:
Requisito NF de producto: La interfaz de usuario para el sistema X, debe ser implementada como HTML simple sin FRAMES o Applets de Java (Para que tengan en cuenta a los diseñadores también).
RQ NF Organizacional: El proceso de desarrollo del sistema y los documentos entregables deberán estar conforme al proceso y entregables definidos en XYZ_1234. (Uichhhh… este no lo he visto escrito en un catalogo de requisitos).
RQ NF Externo: El sistema no revelará información personal acerca de los clientes aparte de su nombre y número de referencia a los operadores del sistema. (Aquí es donde dicen, “pero eso es obvio”… claro que puede ser obvio… pero hay que escribirlo).
(NOTA ADICIONAL: Escribir requisitos como lo especifica el estándar IEEE 830-1998, es decir, empezando “El sistema deberá”, no nos permite escribirlos de forma fácil, porque nos lleva a pensar inmediatamente en el software (es decir, debemos trabajar sobre lo no construido) y no nos dan idea de lo que realmente necesita el usuario (Por eso se deben utilizar Casos de Uso o Historias de Usuario).
Tácticas de desempeño
El desempeño, que puede ser medido en términos de LATENCIA (cuanto tiempo toma un servicio desde que recibe la petición, hasta que la petición es completada), tiempo de respuesta o throughput como lo ve el usuario, es muy importante en todos los sistemas. A la fecha, existen muchas teorías para manejar el desempeño, tales como teoría de encolado, teorías de planeación en tiempo real, redes de petri, etc.Normalmente, se han usado en diseño de dispositivos de hardware, tales como switches. Con la llegada del desarrollo de software basado en componentes, la arquitectura de software, los ORBs, diseñar software para que tengan buen desempeño se ha convertido en un gran reto. Las tácticas del SEI para desempeño caen en 3 categorías: Demanda de recursos, Gestión de Recursos y Arbitramiento de Recursos.Para demanda de recursos, la primera táctica es incrementar la eficiencia computacional, esto no quiere decir comprar una maquina mas grande, sino mejorar los algoritmos en las áreas criticas (esto para no pelear con los clientes).La segunda táctica es reducir sobreesfuerzo computacional, ejemplo, usar llamados binarios en vez de RMI.La tercera táctica es manejar las tasas de eventos, por ejemplo, reducir la frecuencia de muestreo o por medio de cerrados parciales.La cuarta táctica es controlar la frecuencia de muestreo.Para la gestión de recursos la primera táctica es introducir concurrencia. La segunda táctica es mantener múltiples copias de los datos, por ejemplo, utilizando esquemas de caching.La tercera táctica es incrementar la cantidad de recursos disponibles, por ejemplo, procesadores más rápidos, procesadores adicionales, memoria adicional, y redes más rápidas. Para el arbitramiento de recursos, la táctica es definir políticas de planeación, como FIFO, planeamiento con prioridad fija, planeamiento estático. Cada una de estas tácticas puede ser resuelta por software, ej. Cuando se quiere reducir la tasa de eventos se puede crear un filtro que nos permita controlar las tasas de llegada de peticiones (aunque pueden perderse peticiones).
Cuales son los artefactos de SCRUM? El PRODUCT BACKLOG En SCRUM tenemos varios artefactos que se deben llevar, estos se utilizan en tarea especificas dentro del proceso de desarrollo.
Como todo en esta vida no es echar código, en una serie de correos les estaré empapando de estos temas.
Iniciemos con el Product Backlog
El dueño del producto (internamente son los directores de proyecto) deben articular la visión del producto. Esto se lleva a cabo listando las características requeridas, priorizadas en orden de que es de MAYOR VALOR PARA EL NEGOCIO (No empezando por los maestros), cual puede tener mayor ROI para la compañía (nota: Que no hagamos parte de las empresas clientes, no quiere decir que no sepamos que es de mayor valor para el negocio del cliente, y hacer propuestas). Esta priorización pone los ítems de mayor valor en el TOP. Si lo vemos desde el punto de vista de la mejora de procesos, esto es un proceso de toma de decisión para DESARROLLO DE REQUISITOS y SOLUCION TECNICA, desde el punto de vista de saber que componentes se van a desarrollar primero, es la forma de sustentar por que empezamos el proyecto por donde empezamos. Este listado priorizado debe quedar sustentado en el PRODUCT BACKLOG, el cual es un artefacto que debe existir en todo momento y evolucionar conforme el producto se va desarrollando. Ojo: Evolucionar para cambiar la priorización o para adicionar características.
Este PRODUCT BACKLOG incluirá una variedad de ítems, como características (“Permitir a todos los usuarios ingresar a la aplicación dependiendo del rol”), requisitos no funcionales (“Mejorar el procesos cache para que sea distribuible y escalable en cluster”, “Mejorar la consultas de base de datos para que utilicen el optimizador por ESTADISTICAS”, etc.), trabajo exploratorio (“Investigar soluciones para acelerar el llenado de la planilla con AJAX”), y bugs conocidos (“Diagnosticas y arreglar los errores de Javascript cuando se asigna un BUG en Mantis (BUG 1232) ”).
Uno de los errores que se comete cuando se definen ítems (no actividades, ni tareas, sino ítems) es no definir el detalle en el cual se escribirán. Mi recomendación es que en los primeros sprints se definen características y/o funcionalidades generales. Pero después se debe ir refinando para dar un mayor detalle a cada uno de los ítems. Sugerencia: Utilizar el menor espacio para dar el mayor detalle. Ej.:
1. Mejorar el procesos cache para que sea distribuible y escalable en cluster
2. Mejorar el procesos cache para que sea distribuible y escalable en cluster, soportar 500 transacciones simultaneas, Granja de 3 servidores OAS en cluster.
Se supone que este product backlog será partido en piezas mas pequeñas en las Sprint Planning Meetings.
Eres POLLO o CERDO? 
Una de las cosas principales para aplicar una metodología es que hay que ser puristas en la teoría y adaptar en la practica (Tailoring). Hoy, voy a ser un poco purista en cuanto a las metodologías ágiles, específicamente en scrum.
Scrum es un juego de CERDOS y POLLOS.
Esta caricatura de arriba representa 2 de los 4 roles de Scrum, El tercer rol no mencionado en la caricatura es el Scrum Master, del cual hablaremos después. Otro rol es el Product Owner, (que realmente es un PUERCO disfrazado... jejeje).
Los CERDOS son aquellos que están metidos de lleno en el cuento. Son aquellos que van a dar el “tocino”. En otras palabras, los CERDOS son considerados los miembros del equipo desarrollador, los que ejecutan. La gente que hace el trabajo….
Un POLLO es alguien que obtiene ganancias con lo que hacen los CERDOS, pero realmente, no contribuyen día a día a que las cosas se hagan. Sus aportes (Huevos) son recursos renovables. Son personas que están interesadas, pero que no están trabajando. El Scrum Team debe estar compuesto de máximo 6-9 miembros tipo PIG.
Los CERDOS, hablan en cada Scrum Meeting… Si… la reunioncita que hacen todos los días, que aunque no lo crean no es una reunión personal, es una reunión del equipo para mejorar la comunicación y no tener algo de lo que hablaba anteriormente INDISPENSABILIDAD EN LOS EQUIPOS DE TRABAJO. Estos CERDOS son contribuyentes a la solución.
Los POLLOS no están comprometidos con el proyecto y no son responsables en los entregables, no hablan en las reuniones. Son personan que son excesos en la reunión. Los POLLOS son los chismosos. Por donde quiera que se mire, son negativos porque tienden a disminuir la productividad. Son parásitos que viven del trabajo de los CERDOS. Lo siento mucho por los comentarios fuertes, pero si alguien ayuda a definir un eufenismo que pueda equilibrar el decirlo “agradablemente” y comunicar que los POLLOS deben minimizar el impacto en la productividad del equipo.
Se pueden identificar fácilmente, porque solo quieren saber que pasa en el Scrum porque impacta en su trabajo de alguna manera. No necesitan saber que pasa en el Daily Scrum. Solo necesitan conocer sus actividades, y al final del SPRINT (otra vez con T), el donde realmente son productivos, es decir, están involucrados, pero no comprometidos.
A los POLLOS les gusta ir a las reuniones solo para lloriquear porque no llegaron a las metas porque fueron a los Daily Scrum.
Los proyectos no pueden tener muchos POLLOS porque estos pueden hundir el barco. Pero pueden ser útiles si solo se les tiene en cuenta para el final del sprint para mostrar resultados sin tenerlos en cuenta en los Daily Scrum.
Tenemos que ser ARIDOS
Mientras que existen métodos para analizar y evaluar arquitecturas, tales como SAAM, ATAM, CBAM, QAW. Los diseñadores y arquitectos (y también los encargados de la calidad del software) necesitan hacer ZOOM a los diseños para revisar sin son viables estas estrategias tempranas de diseño.
Estas estrategias iniciales son pobremente documentadas y diagramadas, y presentan una falta de detalles importantes que indiscutiblemente surgirán en etapas posteriores (les parece conocido….. Es que en la vida no todo es bolear código). Eso sin contar con que la documentación solo se hace como para cumplir un requisito y no se mantiene una constante actualización que permita minimizar los tiempos de empalme y de “curva de aprendizaje” a la cual le tienen tanto miedo. Aunque no crean, en mi mas humilde opinión, el fracaso de la mayoría de los proyectos de desarrollo se debe al miedo al cambio, adopción de la tecnología adecuada (por la “curva de aprendizaje”) y a la indispensabilidad (o poca comunicación en el equipo de trabajo), esto ultimo se resume a una frase que ya he escuchado en varios proyectos y que es síntoma de una mala gestión y de una mala comunicación en el equipo, “Es que el único que sabe de eso es perengano”, o “Es que yo soy el único que puede hacer eso” (que pasa si se incapacita, se acaba el proyecto?).
Pero me desvié mucho del tema (La buena gestión de proyecto es otro tema mucho mas largo que discutir). Retomando la pobre documentación en el diseño inicial, la revisión del diseño en etapas tempranas puede descubrir importantes inconsistencias en donde una corrección temprana de estas puede ser invaluable para el proyecto. Si lo vemos en plata, es menos tiempo, pero yo lo veo mas como las trasnochadas de los desarrolladores, la mala fama ante los clientes, las inconformidades en las entregas y la mejora en la estimación de los SPRINTS (con T).
Para solventar este problema, el SEI (Software Engineering Institute) ha trabajado en un método llamado ARID (por Active Reviews for Intermediate Designs) complementario a las revisiones de arquitectura. Este permite asegurar diseño detallados de alta calidad en el desarrollo de software. Como lo cita el SEI en http://www.sei.cmu.edu/architecture/arid.html; “El método asegura participación activa de los revisores cuestionándolos a utilizar el diseño en una serie de ejercicios, mientras que se evitan las preguntas SI/NO que son fácilmente de contestar para el revisor con respuestas no muy claras y a la ligera”. Por esto, se prueba un diseño de forma real y no fingido.
Como una introducción a ARID, muestro estos 4 grandes pasos:
- Se deben identificar los revisores. Se recomienda que sean los encargados de utilizar el diseño, si son diferentes a los diseñadores.
- Se prepara una breve explicación del diseño (por parte del diseñador). Se presenta a los revisores y hace explicación completa de los ejercicios usando el diseño.
- Los revisores realizan una tormenta de ideas para usar el diseño para resolver los problemas que esperan enfrentar. Se priorizan los escenarios, y se define como se puede utilizar el diseño en el escenario. Si el diseño trabaja bien para los escenarios definidos, entonces se acuerda que el diseño ha pasado la revisión.
- Los revisores realizan pseudo-código donde usen servicios del diseño para los escenarios de mas alta prioridad. Y se almacenan los problemas, inconvenientes y lugares que son difíciles de pasar.
Igual a las sesiones JAD, este método puede ser difícil de implementar en empresas donde los proyectos son pequeños, donde no existen muchos revisores (Creo que por ese muro mental que se tienen a las revisiones en grupo). Y donde los diseños se saquen a la ligera por el afán de escribir código. Pero puede ser una herramienta fuerte para la detección de problemas tempranos, y sobre todo a ver si utilizamos el titulo de Ingenieros para algo diferente a bolear código.
SOA, cual es la realidad? Como cualquier nuevo paradigma tecnológico o de TI, SOA esta teniendo el mismo problema en el que generalmente siempre se empieza a trabajar con él desde la implementación, cometiéndose el error de querer implementar algo que no se tiene claro, de lo cual no se tiene conocimiento. Y es que el público en general cree que SOA es que la aplicación tenga un Web Service o que las aplicaciones expongan Web Services. Esto apoyado con la tarea de los grandes proveedores de software que prometen implementar SOA en todas las aplicaciones son haciendo clic.
Primero que todo, SOA inicia como una estrategia de arquitectura empresarial, esto quiere decir que, como toda estrategia empresarial debe tener el sponsorship de la alta gerencia (Quien es tu papá?), al fin y al cabo a ellos les interesa es el ROI (Soportar al negocio). Además de esto esta basado en servicios que hacen parte de un proceso, ya sea de soporte o de la cadena de valor, pero al fin y al cabo procesos, que deben ser definidos antes que todo para implementar SOA (Tener una visión).
Para poder definir los procesos organizacionales, se debe empezar a pensar en las labores de cada uno de los empleados de la compañía y a su vez para implementar SOA se debe tener un respaldo fuerte de los actores de los procesos, porque es muy probable que varios cargos o actividades se vean afectados por la nueva estrategia organizacional y tal vez puedan presentarse cambios de cargos, actividades o en ultima instancia despidos.
Ahora, SOA no cabe en todas las organizaciones, SOA es exitoso para compañías donde los procesos pueden tener puntos transversales comunes, se tengan long running process, no basta con querer que la nomina “hable” con el aplicativo de proveedores.
Y si esto no es suficiente, todos dicen, “Queremos que la aplicación tenga una arquitectura SOA”, aun sabiendo que las aplicaciones no tienen arquitectura SOA, es la estrategia de TI, las aplicaciones se pueden hacer SOA-Enabled, esto quiere decir, que expongan servicios y que puedan ser integradas (Definir proyectos alcanzables). Esto demanda una muy buena definición del negocio, una excelente definición de casos de uso, y algo a lo que no se esta muy acostumbrado. Una buena correlación entre casos de uso y componentes de negocio. Esto a su vez implica un cambio en los paradigmas de ventas y de gestión de los proyectos actuales. Ya que los componentes deben ser reutilizables, se requiere que se requiere mucho más tiempo en el diseño y en la documentación de las interfaces que en la implementación. Y esto debe ser un común denominador para todos los proyectos de software, porque al fin y al cabo “NO TODO EN LA VIDA ES ECHAR CÓDIGO”. Para esto se requieren INGENIEROS DE SOFTWARE o SISTEMAS y no PROGRAMADORES (Lo cual lastimosamente, parece que se nos está olvidando).
Ahora, hablando de que las aplicaciones deben ser SOA Enabled, quiere decir que exponen servicios (La flexibilidad ante todo), teniendo en cuenta que servicios no son Web Services y que Web Services no es SOA. Un servicio puede ser creado con cualquier tecnología de acceso remoto (http, RMI, COM+, DCOM, CORBA, Sockets) y los Web Services pueden ser creados con SOAP o con REST. Por otra parte, es difícil exponer servicios en un sistema legado COBOL, no es solo hacer clic como lo prometen.
Ya para concluir, desde el punto de vista de la compañía (nuestros clientes) no se puede estar pensando todavía que la implementación de estrategias de TI se empiezan con la compra de software, se debe empezar con la definición clara del panorama tecnológico organizacional y esto implica muchos cambios organizacionales y mucha inversión en reestructuración de la compañía y cambio en la mentalidad de los empleados (Perder el miedo al cambio). Y que desde el punto de empresa de desarrollo (Avansoft en este caso), no se puede hacer software solo con “código ventiao”, existen métodos, metodologías, patrones, artefactos, etc. Que deben ser ANALIZADOS y DISEÑADOS con mucho mas tiempo que el que gastamos mirando como lo hacemos en Java o .NET (y esa es otra discusión, es que el desarrollo de software no es solo decir que .NET es mejor que Java porque tiene menos código, o lo contrario). Ojo: Solo el 50% de los proyectos de TI son exitosos.
Una nota de Matt Hotle de Gartner, “para el 2008, el desarrollo de software se debe enfocar en Workflow (Y eso que es? Como se come?), funcionalidad y procesos (Procesos? Será que pensamos en eso? Y cuando boleamos código?), no aplicaciones tipo SILOS o CHIMENEAS. Los desarrolladores tendrán que escribir aplicaciones compuestas una vez y REUTILIZAR sus componentes muchas veces en todo el negocio”. Y continua “Una cultura de REUTILIZACIÓN será aceptada y el desarrollo de aplicaciones orientadas a servicios dominará” “El código será bien usado y los desarrolladores deben estar motivados para hacerlo”.Porque esperara hasta el 2008? No podemos empezar ya?.
