archivo

Archivo de la etiqueta: requisito

Parece políticamente incorrecto en el mundo ágil la utilización de la palabra requisito. También, aunque algo menos, la palabra especificación. El motivo principal es su asociación a los desarrollos en cascada y a un modelo de desarrollo basado, yéndonos a un extremo, al dicto, interpreto/apunto, construyo.

Parece que el concepto de historia de usuario se asocia más a la colaboración que es la base en la que se sustenta la agilidad y el enfoque de desarrollo iterativo incremental (os recuerdo que un enfoque o ciclo de vida concreto de desarrollo no es en esencia ágil ya que depende de la actitud con que se aborde).

Estoy de acuerdo en que en determinados momentos usar la palabra adecuada puede ser importante pero tampoco se pierde valor si el fondo realmente dice lo que queremos transmitir. Lo realmente importante, independientemente del nombre que le demos, es que en los ciclos de vida clásicos se piensa en el producto, por encima de analizar y trabajar sobre los problemas reales que se quieren resolver y esto es así, entre otras cosas, porque los desarrollos en cascada piensan en los productos en términos finalistas y en los enfoques evolutivos en términos de valor ganado en aproximaciones sucesivas hacia una determinada solución.

Llega un momento en la evolución de un producto o en un proyecto de desarrollo de software donde echamos en falta todo ese esfuerzo que no se ha aprovechado de manera adecuada, ¿por qué? lo necesitamos ahora o prevemos que lo vamos a necesitar pronto y ya ha desaparecido.

Una de las causas que hacen que el aprovechamiento del esfuerzo no sea óptimo es trabajar con historias de usuario, requisitos o especificaciones que no están claros y en los que existe una probabilidad importante que la solución implementada requiera ser modificada de manera sensible más adelante.

Es mejor invertir el esfuerzo en aquellas tareas donde el retorno de la inversión sea más probable, en donde el efecto sobre el valor del producto sea más inmediato.

Lo que no esté claro debe tratar de solventarse hasta donde se pueda ya que de esta manera se desarrollará con una mayor intención y los ajustes posteriores serán de menor entidad.

Tampoco podemos estar paralizando indefinidamente el desarrollo de una funcionalidad que sea crítica o importante para el sistema pero sí podemos esperar hasta el último momento posible para tratar de que esté lo mejor definida posible.

El responsable funcional siempre va a querer incrementar el valor del producto que se está desarrollando y/o con el que está trabajando, para ello lo evolucionará buscando incrementar la eficiencia y productividad en su utilización y para ello modificará funcionalidades ya implementadas, eliminará algunas que no tengan utilidad o desarrollará otras nuevas.

Ese incremento del valor será consecuencia de una inversión y tendrá como objetivo obtener un retorno de la misma traducido como una reducción de costes y/o una ventaja competitiva con respecto a la competencia.

No hay que esperar a tener una versión más o menos estable del producto, el responsable funcional conforme vaya viendo y trabajando con versiones del mismo, ya sea en producción (preferentemente) o en un entorno de demo, buscará incrementar ese valor (lo hará incluso cuando trabaje con prototipos de pantallas en la definición de una historia de usuario), por lo que los requisitos, las especificaciones, las mismas historias de usuario, siempre deben estar abiertos a una modificación y esa será la realidad con la que nos encontremos en cualquier sistema de información, hasta que termine su ciclo de vida.

Sobre esto, Roy Miller realizó la siguiente reflexión: “Los requisitos son una conversación que nunca termina”.

En el nivel 3 de CMMI estamos analizando diferentes áreas de proceso que lo que hacen es especificar un marco de trabajo para la realización de determinadas tareas dentro del proceso de desarrollo de software.

Esta estrategia a nivel organizativo para la obtención de productos software requiere de procesos que se encarguen de verificar la calidad y adecuación a su finalidad de los diferentes artefactos intermedios que se vayan obteniendo así como el resultado final, es decir, no se trata solo de definir los caminos que se pueden elegir a la hora realizar el desarrollo, sino también de determinar los controles a realizar para comprobar si las diferentes piezas utilizadas en el proceso de ingeniería del software y de construcción (al fin y al cabo una parte más del mismo proceso de ingeniería) cumplen su propósito y los requisitos establecidos.

Los citados en el anterior párrafo, son los objetivos fundamentales de este área de proceso. La diferencia respecto al área de proceso de validación, que trataremos más adelante, es que en la verificación comprobamos si el estamos desarrollando (construyendo) el producto de manera adecuada (es decir, este artefacto, ¿está construido cómo debe?) y en la validación se comprueba si se está desarrollando el producto correcto (que no es lo mismo). Ambas áreas de proceso van de la mano, aunque tengan finalidades distintas.

Una organización es madura si es capaz de detectar desviaciones lo más cerca posible de la causa o causas que lo provocan, ya que cuanto más nos alejemos del foco y/o más tardemos en realizar acciones correctoras, más esfuerzo se requerirá para invertir esta tendencia.

En este área de proceso se debe establecer:

– Los artefactos que se deben verificar, pudiendo llegar a definirse (como en las otras areas de proceso) diferentes escenarios en función del tipo de proyecto o incluso establecer las condiciones que debe cumplir un artefacto para ser verificado.

– El entorno de verificación, es decir, dónde y qué medios se van a aplicar para realizar las diferentes verificaciones.

– Los procedimientos de verificación, es decir, cómo y que criterios se van a seguir para determinar si un artefacto cumple con su finalidad. La metodología determina que el procedimiento debe basarse en un mecanismo de revisión por pares en cual se suele incluir el análisis de los resultados de la verificación y la determinación de las acciones correctoras.

En el nivel 2 de CMMI, en el área de proceso: Gestión de requisitos, se pretendía principalmente:

– Inventariar/Catalogar los requisitos.
– Asegurarse de que las partes involucradas en el proyecto compartían una visión común de los mismos.
– Establecer un mecanismo para que esté controlado el proceso de cambio en los requisitos de manera que solo un grupo reducido de personas tenían la posibilidad de autorizar las modificaciones en los mismos (estando abierto a cualquiera la posibilidad de realizar solicitudes de cambio).
– Asegurar la coherencia entre los artefactos del proyecto ante las modificaciones que se aprueben utilizando como mecanismo facilitador la existencia de una trazabilidad bidireccional entre requisitos y artefactos (pudiendo ser directa o indirecta).

Se puede considerar por tanto que efectivamente lo que se pretendía era una gestión o administración de los requisitos.

En el nivel 3 se considera superado lo anterior y se centra en el proceso de obtención de los requisitos (desde la recogida y análisis de las expectativas del cliente), la asignación de los mismos al producto software y sus componentes y en su validación, por tanto se hace un enfoque en las técnicas y estrategias necesarias, con el objetivo de hacerlas repetibles entre diferentes proyectos y equipos, permitiendo la posibilidad de compartir herramientas, experiencias, disminuyendo la curva de adaptación a nuevos proyectos y propiciando un entorno orientado a la mejora continua.

La planificación del proyecto supone la base para la realización del mismo, por lo que es habitual que la mayor parte de las tareas que lo componen se realicen de una manera más o menos formal: Determinar un alcance inicial (aunque sea a alto nivel), hacer un análisis de riesgos, hacer una estimación del coste/esfuerzo, de los recursos en materia de personal (¿quiénes van a participar?, ¿cuándo?, ¿con qué dedicación?, ¿necesitan algún tipo de formación antes de enfrentarse al proyecto?) y materiales (software y hardware), definir el ciclo de vida/metodología a utilizar, proponer un cronograma, definir los hitos, las personas que los apruebas, etc…

Buena parte de la suerte del proyecto se juega al principio, una mala negociación, una mala estimación, en general, una mala planificación puede condicionar negativamente el proyecto, hasta tal punto de que si no hay posibilidad de enmendar la situación a tiempo puede afectar incluso a su viabilidad.

La incorporación de esta tarea y darle un grado de formalidad en los proyectos software, resulta por tanto, lógica en el nivel 2 de CMMI.

Es decir, a partir de ahora y en cada proyecto, es necesario que esas tareas preparatorias del proyecto se realicen, siguiendo un proceso, una estrategia, un plan. Se entiende que de esta manera las decisiones que se tomen se harán siguiendo una lógica que vendrá definida por las distintas soluciones y técnicas que se utilicen para realizar las diferentes actividades del mismo (estimación de proyecto, análisis de riesgos, etc…), si bien, la existencia de un proceso de guíe a la definición del plan de proyecto no asegura nada si la ejecución no es buena (ya sea por un incorrecto desempeño del que la realiza y/o porque la información que tiene para realizar la planificación no es adecuada o válida).

Se entiende que este área de proceso debería tomar como partida los requisitos del área de proceso “Gestión de requisitos”, sin embargo esto no va a ser siempre posible. Es cierto que es deseable conocer el mayor detalle posible antes de realizar por ejemplo una estimación de costes, pero también lo es que no siempre se van dar las condiciones para poder realizar esta tarea ya que la contratación del servicio de desarrollo de software se puede realizar en base a un pliego de condiciones técnicas o incluir dentro del mismo las tareas de análisis.

A lo anterior hay que sumar la volatilidad de los requisitos, ya que lo mismo la estimación se ha realizado teniendo en cuenta unos, pero después cambian las condiciones y se rompen los esquemas.

Dependerá de la organización tomar parte o no en un proyecto en función del grado de incertidumbre existente, de las características del cliente y de la propia cultura y experiencia de la misma.

Desde mi punto de vista la planificación inicial del proyecto es muy importante, independientemente del grado de incertidumbre y es importante que todas las partes entiendan que se trata de un plan inicial que se deberá ir ajustando a la evolución real del proyecto.

Rebecca Parsons es la actual CTO de la empresa ThoughtWorks, dedicada a la consultoría y al desarrollo de software utilizando metodologías ágiles. Con anterioridad desarrolló su trabajo como profesora universitaria y colaboradora en diversas instituciones y comités. Sus trabajos se centraron en los campos de la inteligencia artificial, computación distribuida y los lenguajes de programación. En totalidad son más de veinte años lo que lleva dedicada a este negocio.

El rendimiento es una requisito no funcional, una variable en el proceso de desarrollo de software a la que no se le suele prestar demasiada atención pero que hace daño cuando el producto se encuentra en una fase avanzada de su construcción (porque requerirá esfuerzo corregirla) y todavía más en producción porque a ese coste hay que sumarle la pérdida de eficiencia y productividad de los usuarios en el uso de la herramienta y la disminución de la confianza de los mismos en el producto, lo que afectará negativamente a los gestores funcionales y técnicos del proyecto.

Es cierto que una buena arquitectura, codificación, diseño del modelo de datos, afectan implícitamente al rendimiento, sin embargo, no solemos prestar la atención que se merece a un aspecto que tiene incidencia en la calidad final del producto, pese a que Rebecca Parsons tiene razón cuando comenta que: “Nunca es demasiado pronto para pensar en el rendimiento”.