Líneas Base

Una línea base es el compromiso, negociado y aceptado, que se alcanza con el cliente para que este comprenda que hemos de poner un alto en la captación de necesidades con miras a enfocarnos por unos días, en construir aquello nos ha pedido hasta el día de hoy.

Como estrategia de organización del proyecto, su principal virtud es la de permitir la gestión de requerimientos, al introducir pausas regulares en las exigencias del cliente, con miras a ver primero el logro de las primeras ideas, antes de introducir nuevas variaciones.

Al contar con las líneas base como estrategia de gestión de requisitos, es posible disminuir el riesgo que representan para los proyectos las especificaciones incompletas: simplemente no vamos a aspirar a tener todas las cartas en la mano, vamos a trabajar con lo que tenemos hasta un punto y luego, alcanzados los primeros objetivos, volver a recoger lo que se nos haya escapado la primera vez.

Por lo mismo, es posible también reducir el riesgo de desorden en los requisitos del proyecto. Hay una disciplina en el equipo del trabajo, que se le puede explicar al cliente. Dicho de otra forma, es una forma educada de pedirle paciencia.

¿Qué son las llamadas Mejores Prácticas?

Las mejores prácticas son características reconocibles de los procesos de las organizaciones de éxito. Suelen ser conductas observables, llenas de sentido común; que al estar presentes en las mejores empresas de cada sector, se piensa que son parte del éxito de dichas empresas. Por supuesto, se piensa también que de asumirse, toda empresa se puede beneficiar, por lo que la predica en pos de las mejores prácticas es parte importante de la planificación a largo plazo de las organizaciones que desean mejorar y crecer.

A nivel personal, podemos establecer un símil con los consejos más comunes sobre como llevar una vida sana y exitosa. Consejos tales como «pensar antes de actual» o bien el elemental «dormir lo suficiente cada noche» son el equivalente de las mejores prácticas, aplicadas a como conducir la propia vida.

En el caso de las empresas, se confía en los institutos de investigación de cada sector, quienes identifican sistemáticamente las prácticas en uso, con el objetivo de publicar catálogos de mejores prácticas, que sean apropiadas para el sector industrial que se este considerando. Dichos catálogos suelen ser de acceso libre y son conocidos bajo diferentes denominaciones, como si se estuviera hablando de cosas diferentes en cada sector. Pero no hay confusión que valga: para todo sector valen distintas mejores prácticas, pero llámense como se quieran llamar, todas son mejores prácticas y poco más.

Cuando se esta diseñando un proceso empresarial, es útil considerar las mejores prácticas conocidas del sector o actividad en la que el proceso vive. Dado que existen gran cantidad de sectores, el analista de procesos puede beneficiarse de conocer que se considera como una buena idea, dando entonces una base sistemática para identificar objetivos de diseño para los procesos, más allá de cubrir las necesidades inmediatas demandadas por los clientes.

He de hacer notar también, que muchas de las mejores prácticas pueden ser apoyadas por sistemas de información apropiados; o dicho de otra forma, que hoy en día existen gran cantidad de sistemas de información, muchos de ellos construidos para dar cumplimiento a una o más de las mejores prácticas de sector destino del sistema.

Así que el asunto de las prácticas conviene tenerlo en mente.

Prácticas: Gestión de Proveedores

Dado que en un esfuerzo de desarrollo no todo puede ser resuelto con los recursos propios, es probable que nos encontremos en la posición de tener que adquirir insumos, servicios y productos a terceros; por lo cual, es necesario extender a estos proveedores todo lo que podamos en cuanto a control de calidad y buenas prácticas pues de lo contrario estaríamos comprometiendo nuestra propia capacidad de asegurar el nivel de calidad requerido por nuestros clientes.

Esta práctica la llamamos Gestión de Proveedores e involucra:

• Determinar los servicios y productos a adquirir.
• Determinar el nivel de servicio requerido (cantidad, tiempo, precio, calidad).
• Seleccionar los proveedores según su capacidad de cumplir con el nivel de servicio.
• Establecer contratos de suministro y nivel de servicio con los proveedores.
• Ejecutar la adquisición del servicio o producto.
• Evaluar (cuando sea requerido) los productos requeridos contra el nivel de servicio solicitado.
• Aceptar las entregas de los productos adquiridos.
• Distribuir lo adquirido al lugar en que se necesita.

Como cabe esperar, esta práctica se relaciona con Seguimiento y Control de Proyectos y con Gestión de Requisitos. La primera por cuanto los suministros deben de llegar oportunamente (básicamente pero hay otras razones) en tanto que la segunda por cuanto lo que se ha adquirido se va a integrar en el producto final y de ahí, que sus características deban guardar relación con los requisitos impuestos al proyecto.

En esta práctica se ve que para asegurar un desarrollo eficiente los procesos de la empresa se deben estructurar correctamente mucho más allá que simplemente poner orden en el departamente técnico. En este caso, se debe implantar algún sistema de gestión de requisiciones que permita centralizar las compras en un departamento que pueda hacer el seguimiento a los proveedores, desde su selección pasando por su contratación hasta la ejecución del servicio.

Prácticas: Medición y Análisis

El propósito de la práctica conocida como Medición y Análisis, es desarrollar la capacidad de la organización para reunir información objetiva (medición) con el fin de dar soporte a la dirección y gerencia.

De acuerdo con CMMi, esta capacidad de medición involucra lo siguiente:

• Especificar los objetivos de medición y análisis tales que sean necesarios para dar soporte a las metas y necesidades de la organización.
• Especificar las magnitudes, las técnicas de análisis y los medios para la recolección, y manipulación de las mediciones.
• Implementar los procedimientos necesarios para la recolección, registro y reporte de la data relacionada con las mediciones.
• Proveer resultados objetivos de las mediciones, tales que puedan servir de base para la toma de decisiones.

En otras palabras: proveer la infraestructura necesaria para la recolección de información estadistica cualitativa y de ser posible cuantitativa sobre los aspectos del proceso que se descubran relevantes para la toma de decisiones, así como la detección y corrección de desviaciones.

Dado su propósito amplio, la práctica de Medición y Análisis debe integrarse en forma distribuida a lo largo del proceso de desarrollo. En el caso ideal, cada actividad y tarea realizada en la organización ha de generar algún tipo de información útil que sirva para determinar su rendimiento, situación objetiva y la calidad de los resultados.

Si bien es cierto que un programa de metrica a gran escala es una propuesta ambisiosa, no es necesario tener un gran esfuerzo de recolección de metricas en el desarrollo para establecer la práctica de la que aquí hablamos. Basta con determinar en puntos clave del proceso definido que se sigue, estadisticas que sean significativas y que de ser posible, sean resultados naturales de las tareas ejecutadas.

Es decir, que contrario a lo que podría parecer, un programa bien establecido de medición no es una operación burocratica a gran escala, sino por el contrario es la reutilización inteligente de la información sobre el proceso que ya de forma natural, se este generando en la organización.

Varios ejemplos de medidas utiles me vienen a la mente:

• Horas de esfuerzo por tarea o actividad.
• Número de componentes diseñados o implantados.
• Número de páginas de documentación solicitadas y redactadas.
• Cantidad de veces que una actividad se repite.

Estas son estadisticas que ya en forma natural deberan existir en la organización, solo es cuestión de definir cuales son útiles para la gestión del proceso y establecer entonces formas de recolectar y utilizar esta data.

Finalmente, dado que con esta práctica estamos detectando desviaciones y proveyendo información útil para la gerencia, es obvio que estamos en presencia de una práctica relacionada con la Planificación de Proyectos así como con el Seguimiento y Control de Proyectos.

Selección de Artefactos de Requisitos

Dado que son muchos los posibles artefactos a incluir en un proyecto, es imperativo el desarrollar una visión de conjunto que nos permita escoger solo aquellos que son realmente capaces de otorgar valor al desarrollo. Esto es, necesitamos tener una visión o mapa estructural de todos los artefactos, para luego saber cual incluir en el desarrollo y cual dejar por fuera.

En este artículo analizaremos los artefactos de la disciplina de requisitos.

Primero tenemos los documentos básicos: El Documento de Visión del Sistema y El Glosario de Requisitos. Estos documentos son tan importantes que simplemente los tendremos siempre en nuestros desarrollos. En ellos tendremos el vocabulario del cliente así como la captura de las necesidades y las características de alto nivel de la solución propuesta. Ambos forman una suerte de paraguas que cobija a los restantes artefactos del proceso, tanto si son de requisitos como si son de otras disciplinas.

Para el resto de los artefactos de requisitos tenemos tres enfoques: el tradicional, los casos de uso y el dual o mixto.

El enfoque tradicional esta representado por el documento de Especificación de Requisitos del Sistema, que contiene los requisitos en un formato estilo «el sistema debe…». En este enfoque, no dividimos los requisitos en funcionales y no funcionales, por lo que nos basta con un solo documento.

Por otra parte, en el enfoque de casos de uso, es necesario contar con algún tipo de documento para capturar los requisitos no funcionales, ya que los casos de uso como es sabido por todos, solo nos ayudan con los requisitos funcionales. El rol del documento de Requisitos Suplementarios es justamente este: complementar los casos de uso y documentar cualquier requisito no funcional al lado de cualquier requisito funcional que sea general a todo el sistema.

El ultimo enfoque es el dual. Es simplemente mantener tanto un documento tradicional de requisitos como un modelo de casos de uso. En este enfoque surge un nuevo artefacto: El Cruce de Requisitos; con cuya ayuda mantendremos el control de la duplicidad de cada requisito: una vez en el documento de especificación y otra en el modelo de casos de uso.

El siguiente diagrama muestra las relaciones entre estos artefactos, organizados en lo que llamamos un Artifacflow o Flujo de Artefactos. En este diagrama vemos la forma en que la información viaja desde la visión hacía los restantes documentos. Los rombos representan las decisiones que tomamos durante la creación del Caso de Desarrollo y el criterio de decisión.

Fig. 1 – Flujo de Artefactos de la Disciplina de Requisitos

Las decisiones son simples de plantear, aunque no necesariamente fáciles de contestar. ¿Debemos utilizar casos de uso o un enfoque tradicional? ¿Quizás debamos optar por el enfoque mixto? Finalmente, de utilizar casos de uso ¿vale la pena mantener un documento de requisitos suplementarios? ¿No es todo esto simplemente mucho trabajo?

La verdad es que si es un proyecto pequeño, tomar todos los artefactos es demasiado. De hecho, en un proyecto pequeño lo mejor es aprovecharse de un detalle interesante: en ciertas condiciones los artefactos se pueden combinar.

Un ejemplo de esto es el Documento de Visión. Dado que este incluye secciones suficientes para documentar requisitos no funcionales y considerando también que podemos hacer un anexo que cubra el glosario, es simple obtener un conjunto de artefactos combinados que resulten apropiados para un proyecto pequeño.

La situación es planteada en el siguiente diagrama:

Fig. 2 – Flujo de Artefactos de la Disciplina de Requisitos
para un Proyecto Pequeño

En el caso planteado, es de esperar que los costos de construir y mantener estos artefactos sean mucho menores que en el caso de tener documentos separados. Así que han de resultar mucho más adecuados para un proyecto de pequeñas dimensiones.

El Ciclo de Vida: Objetivos de Fase

Cada Fase del Ciclo de Vida debe terminar cuando se alcanzan un conjunto bien identificado de objetivos, definidos en términos de productos concretos o eventos acordados con los stakeholders. Según lo que se haya indicado en la planificación del proyecto durante la Fase de Concepción.

Esto es, llamamos Objetivos del Ciclo de Vida a las metas concretas que marcan el éxito de una fase, según lo que se haya planificado inicialmente.

Según la fase del proyecto en la que nos encontremos, los objetivos van a ser diferentes. Algunos ejemplos son:

• Objetivos del Ciclo de Vida de la Fase de Concepción: Documento Visión, Modelo de Casos de Uso, Documento de Requisitos Suplementarios.
• Objetivos del Ciclo de Vida de la Fase de Elaboración: Documento de Arquitectura del Sistema, Prototipo de Interfaz de Usuario, Prototipo Técnico de la Arquitectura del Software.
• Objetivos del Ciclo de Vida de la Fase de Construcción: Versión Beta del Software en ejecución en ambiente de pruebas, Documentación de Usuario, Soporte de Entrenamiento de Usuarios, etc.

Un objetivo del ciclo debe ser concreto, verificable, planificado de antemano, bien conocido y aceptado por todos los stakeholders del proyecto. Veremos cada criterio uno a uno:

Concreto: Cada objetivo del ciclo de vida debe estar bien enunciado. No se aceptar definiciones vagas o que no se comprendan plenamente por todos los stakeholders involucrados. Se tienen por concreto a los artefactos del proceso cuando estos son aprobados por el cliente y este entiende el significado y rol técnico del producto que esta aprobando.

Verificable: Tanto el cliente como el equipo de Control de Calidad del Software van a estar interesados en comprobar que el objetivo se ha alcanzado. Esto es, la ocurrencia del evento debe poder ser observada por terceros de forma así de garantizar que el éxito en alcanzar el objetivo del ciclo de vida no es resultado de una evaluación subjetiva más sujeta al capricho o la premura que a la realidad.

Planificado: El objetivo de ciclo de vida es una meta; por lo que no puede ser alcanzado solo por casualidad. El objetivo ha de haber sido señalado como meta desde un principio y no puede en ningún caso, ser presentado como aquello que se ha salvado de un proceso malogrado de desarrollo. La planificación también es importante para permitir con el suficiente tiempo, la elaboración de estrategias de evaluación que permitan la verificación del objetivo.

Bien Conocido: El objetivo del ciclo de vida debe ser un artefacto o evento reconocido en el sector de desarrollo, de forma tal que exista un acuerdo profesional sobre lo que este significa y de los eventuales criterios de aceptación y demás características del objetivo. Por ejemplo, el Documento de Visión es bien conocido ya que esta difundido en la profesión el contenido esperado de este documento así como en el propósito que persigue.

Aceptado: Todos, tanto los clientes como los desarrolladores, deben haber aceptado el objetivo del ciclo de vida y sentir compromiso por conseguirlo. El objetivo de ciclo de vida debe ser aceptado como un elemento que señala un avance significativo del proyecto que aporte valor real al desarrollo y que debe ser apoyado y buscado con energías. Esto debe ser algo sincero, ya que un objetivo del ciclo de vida no puede ser percibido como un alcabala o requisito burocrático: muy por el contrario, debe ser un artefacto o evento de valor para todos los involucrados.

Prácticas: Seguimiento y Control de Proyectos

El propósito del Seguimiento y Control de Proyectos es el de proveer una visión objetiva del estado actual del proyecto y determinar las posibles desviaciones a fin de tomar las correcciones del caso. Es en este sentido en el cual le llamamos Seguimiento a la evaluación rutinaria del estado en tanto que llamamos Control a la toma de los correctivos.

Esta práctica guarda intima relación con la Planificación de Proyectos tal como cabe esperar, ya que solo donde la planificación se encuentra correctamente documenta es posible verificar su cumplimiento.

El producto mínimo de esta práctica es el Cierre de Iteración, un documento o artefacto, donde anotamos los resultados de la evaluación de una iteración; de momento sin decir las correcciones a tomar.

Una vez determinada las desviaciones, es necesario que el equipo determine oportunamente la corrección requerida y la lleve a cabo durante la siguiente iteración o en el momento en que sea oportuno. Finalmente es necesario que la corrección planteada sea a su vez, objeto de seguimiento – lo que implica que la planificación debe ser actualizada para que refleje las acciones que se han determinado necesarias para corregir la desviación.

A la hora de realizar las reuniones de seguimiento del proyecto, es útil contar con unos momentos para discutir y revisar el Plan de Riesgos, a fin de verificar la ocurrencia de alguno de estos eventos negativos; además – si bien es una práctica avanzada – debe considerarse la posibilidad de calcular alguna forma de medida o métrica que aplicada al proyecto de desarrollo sirva de indicador sobre el estado del mismo. Esto con el objeto de obtener una evaluación lo más completa y objetiva posible de la salud del proyecto.

Otros factores que deben ser objeto de seguimiento incluyen el presupuesto en tiempo y dinero del proyecto y el cumplimiento de los hitos señalados como objetivos del ciclo de vida.

El Ciclo de Vida: Fase de Elaboración

La fase de elaboración es la encargada de determinar la solución técnica del proyecto. Así como durante la fase de inicio se determino el qué, ahora es necesario el como. Es esta fase durante la cual elaboramos los requisitos al nivel del diseño y por tanto, nos pone en posición de saber si el proyecto es técnicamente viable así como conocer la tecnología que vamos a utilizar durante la construcción.

El foco de la fase de elaboración se encuentra en las disciplinas de Diseño y Análisis; ya que estas son las encargadas de dar con la solución técnica. Aunque también hay un importante papel para la Gerencia del Proyecto, dado que en la fase de Elaboración es el punto donde debemos haber disminuidos y controlados los riesgos principales que pudieran dar al traste con el proyecto.

Es también la Fase de Elaboración el punto de no retorno para el proyecto. Una vez que dejemos atrás a esta fase y entremos en la construcción, los gastos serán tan elevados que se tendrá que tener muy en claro el alcance de la apuesta económica; es mejor detener un proyecto aquí, cuando se ha ejecutado menos del 25% del presupuesto que más adelante, donde los gastos son mucho mayores.

Típicos objetivos para esta fase son:

• Documento de Arquitectura del Sistema revisado y aceptado.
• Prueba de Concepto exitosa de todas las tecnologías novedosas a utilizar.
• Prototipo de la Arquitectura del sistema.
• Plan de Riesgos con los riesgos principales identificados y controlados.

El objetivo central es solo uno: responder si el proyecto es técnicamente viable con la solución o diseño propuesto.

Entonces, ahora como para el glosario:

Fase de Elaboración: Establece el como del proyecto; es decir: determina la solución técnica del sistema y la demuestra a nivel de pruebas de concepto. La Fase de Elaboración también es el punto donde se deben de haber controlado los riesgos principales del proyecto.

Finalmente, en cuanto a su duración, considero como sano una fase de elaboración de dos o tres iteraciones. Esto debido a la necesidad de realizar y probar el diseño, lo que genera una carga de documentación y de programación sensiblemente mayores a las que teníamos durante la fase de concepción. Por otra parte, en un proyecto típico, el gasto realizado es de aproximadamente el 20% del total del costo del proyecto; por lo que la ejecución del presupuesto si contamos también a la fase de concepción rondará el 25%.

Prácticas: Gestión de Requisitos

Todos los proyectos tienen requisitos que cumplir. Todos los proyectos debieran contar por lo tanto, con una gestión profesional de dichos requisitos. Dicha gestión ha de contar con una descripción explicita y manejable de cada requisito elicitado, agrupados según el alcance y presentados en forma tal que sea posible contrastar en cualquier momento, el estado del proyecto en sus planes y artefactos, contra los susodichos requisitos.

La Gestión de Requisitos ha de capturar tanto los requisitos funcionales como los no-funcionales, así como los requisitos no técnicos, tales como las exigencias que sobre el proceso de desarrollo se deban cumplir. Además, la Gestión de Requisitos debe contar con medios para determinar en forma objetiva cuando un requisito a sido satisfecho y cuando en cambio, ha sido pasado por alto. Por ultimo, es necesario también contar con medios para elicitar nuevos detalles y resolver malos entendidos que puedan originarse.

En adición a lo anterior, dos puntos de suma importancia son: el seguimiento de los cambios en los requisitos y el control sobre las trazas que dan fe del fiel cumplimiento de lo requerido durante el desarrollo.

El control sobre los cambios en los requisitos demanda el mantener un buen control sobre las expectativas del cliente, así como de haber completado correctamente la identificación de las necesidades en etapas tempranas del proyecto. Cuando esto no se realiza apropiadamente, surgen «requerimientos urgentes e ineludibles» en las ultimas semanas del proyecto que lo alargan y pueden incluso, llevarlo al fracaso.

Por otro lado, el disponer de un sistema de trazas bidireccionales es necesario por cuanto en un enfoque iterativo, los artefactos iniciales que contienen los requisitos pueden sufrir actualizaciones en etapas posteriores, obligando a identificar los elementos del análisis y del diseño que deben ser revisados para satisfacer aquello que ha cambiado en el requisito.

La ultima faceta de la Gestión de Requisitos es quizás obvia: procurar el compromiso en torno a lo especificado. Es necesario que tanto el cliente como los restantes stakeholders del proyecto sientan que sus necesidades han sido identificadas y que van a ser satisfechas.

Prácticas: Gestión de Configuración

Todo proyecto de desarrollo produce más que solo el código del sistema final. Todo, desde las especificaciones iniciales a los planos de la solución técnica puede ser considerado como parte integral del sistema y en forma más simple, como un producto del trabajo útil realizado.

Ahora bien, si consideramos que nuestros productos -artefactos- son construidos con la información contenida en los artefactos previos, es natural que puedan surgir problemas si un artefacto anterior es actualizado y el cambio allí incorporado no se propaga apropiadamente en los derivados. A esta situación, que llamamos error de configuración la buscamos controlar y evitar en lo posible, con la práctica conocida como Gestión de Configuración.

Formalmente, el propósito de la Gestión de Configuración es la de establecer y mantener la integridad de los artefactos -productos de trabajo- por medio de la identificación de versiones, la gestión de actualización, el registro de líneas bases y las auditorías de configuración.

Bajo el control de la Gestión de Configuración se debe encontrar todos los documentos que se han entregados al cliente, los artefactos utilizados internamente en el proyecto y las herramientas utilizadas en la creación de dichos artefactos. En general, se deben incluir en este control cualquier ítem sometido a versiones, que pueda ser utilizado, consumido o producido en el proyecto y que de píe a la situación de un error de configuración.

Quizás las dos mayores herramientas con la que cuenta la Gestión de Configuración son: el registro maestro de documentos y las listas de distribución. Sin embargo, cuando se habla de documentos digitales como el código fuente de las aplicaciones, es posible utilizar sistemas de control de versiones automáticos, como CVS.