Archivos para 29 febrero 2008

Centrado en la Arquitectura

Un Proceso Definido es una construcción mental; que organiza un conjunto complejo de conceptos. No es de sorprender entonces que sea útil el construir este Proceso en torno a una serie de conceptos o principios, que hagan más fácil la comprensión del todo.

Uno de los principios claves del método definido al que llamamos UP, es la declaración que dice: Centrado en la Arquitectura. Es este uno de los tres principios rectores del método, por lo que no debemos menospreciar su importancia.

Entendemos por Arquitectura los elementos centrales del diseño de un sistema. Pueden ser las abstracciones comunes, los fundamentos en código o la tecnología central utilizada. Sea cual sea el caso, la arquitectura es esa parte del sistema que describe lo fundamental de este, y que por tanto, mantenemos esencialmente inalterada pese a las adiciones y modificaciones que tenga el software.

Dicho formalmente, como para el glosario:

Arquitectura del Software: conjunto de elementos esenciales del diseño, que sientan la estructura común a todo el sistema y determinan sus posibilidades técnicas con miras a satisfacer los requisitos con un mínimo de riesgo técnico y con un uso apropiado de los recursos disponibles.

Es durante la Fase de Elaboración que se desarrolla la arquitectura, no solo por medio del diseño en un UML, sino que también se prueba, se implanta y se documenta. De todo esto se encarga la llamada Disciplina de Diseño.

El método lucha en todo momento por establecer y mantener una arquitectura viable, por lo que la conservamos durante la fase de construcción. La idea de arquitectura es de hecho tan importante, que es posible incluso argumentar que el riesgo tecnológico queda disminuido gracias a que una buena arquitectura nos da bases para evitar muchos problemas e incluso, para hacer factible técnica y económicamente a un proyecto.

Notemos que la arquitectura es uno de los principales puntos a ser sometidos al proceso de Revisión por Pares, dado su rol central en la obtención de un software de calidad; no solo para el esquema tradicional de características de calidad, sino también para el enfoque de concordancia que manejo en el blog.

Finalmente recordemos que los otros dos principios básicos son Iterativo Incremental y Guiado por Riesgos y Requisitos.

Anuncios

, , , ,

Deja un comentario

La Iteración Inicial

En muchas ocasiones ocurre que las ideas de proyectos fluyen entre las organizaciones -o dentro de ellas- de una manera más informal que formal. Esto es natural, ya que todos acostumbramos a hablar mucho de nuestras cosas con los amigos y compañeros, así como de recurrir a los aliados a la hora de intentar comprender algo. Y sin duda, los proyectos que “están en el tintero” son objeto de conversación en estas reuniones.

Así la cosa, es probable que las primeras acciones de un proyecto sean tomadas mucho antes de contar con un acuerdo formal sobre el modelo de negocio, el método de desarrollo o las condiciones de contratación. Todos estos, aspectos muy importantes a la hora de definir el Caso de Desarrollo y el Caso de Negocio que sustentan en ultimada instancia el proceso de desarrollo.

Entonces surge la pregunta: ¿como dar cabida a este proceso de discusión de proyectos en un Proceso Definido? Pues bien, la solución que planteo es la de definir una Iteración Inicial.

Llamo así, a todo el tiempo que transcurre desde la primera mención de la idea de un proyecto, hasta el inicio de su primera iteración “oficial” o planificada tal y como se entiende dentro del método de desarrollo. Esta iteración inicial puede abarcar desde días hasta meses, y esta orientada a permitir registrar el avance de la idea en la medida en que esta va demandando trabajo.

Entonces, en el Plan de Desarrollo vamos a tener una Fase de Inicio formada por cuando menos, dos iteraciones. Una -la inicial- que tiene fecha de inicio indeterminada y la otra -la primera formal- que dura lo que todas nuestras iteraciones y que esta definida en un Plan de Iteración en términos precisos.

Nos estamos viendo.

, , , , ,

Deja un comentario

Como dar inicio a un Proyecto

Acostumbro a pensar -así, a título personal- que un proyecto se arranca con los siguientes tres simples pasos:

  1. Escuchar a los Grupos de Decisión –Stakeholders– del Proyecto.
  2. Capturar lo que se sabe en Artefactos iniciales del Proyecto.
  3. Ejecutar el método de desarrollo.

En un primer momento, el Proyecto solo existe en la mente del cliente y de los restantes grupos de decisión, por lo que espero que sea natural para todos que el escuchar sea una primera actividad bien aceptada. Sin embargo, el escuchar tiene su truco. No es lo mismo compartir una mesa de reunión, que el escuchar atentamente y entender lo que se dice.

Con todo, si se han asumido buenas practicas, como el desarrollo de un glosario, seguro que este primer paso puede ser dado sin mayores tropiezos.

Luego de esto, es necesario realizar un Caso de Desarrollo con el objetivo de establecer los soportes -documentos y artefactos- donde vamos a hacer registro de lo que hemos captado al escuchar a los Grupos de Decisión. Este paso es el punto de inicio del Proceso Definido, y debe ser visto como el ultimo momento en que el proyecto puede existir sin una estructura definida.

Finalmente, dado que los artefactos tienen un momento en el Ciclo de Vida, y su desarrollo esta regido por actividades bien conocidas, es posible entonces dejar que el proceso cobre su propia vida y se ejecute en sus propios términos. Ya sabe, en los términos del Proceso Definido que hemos adoptado.

, , , , , , ,

Deja un comentario

El Ciclo de Vida: Fase de Concepción

Ya sea que la llamemos Inicio o Concepción, esta fase del ciclo de vida del proyecto es la que dedicamos a determinar los objetivos del mismo. Tanto a nivel de Gerencia del Proyecto, como de sus requisitos.

De esto se desprende la siguiente definición:

Fase de Concepción: También llamada fase de Inicio, establece el qué del proyecto. Fija por tanto, su interés en las disciplinas de Gestión del Proyecto y de Requisitos.

Esta fase involucra muchos artefactos, si bien en su mayoría no superan el grado de borradores de trabajo. El objetivo de tenerlos en su primera versión es la de avanzar en los estudios de factibilidad técnica y económica. La excepción la tenemos con aquellos artefactos orientados a la captura de requisitos, los cuales si son desarrollados en detalle.

Son entonces, típicos objetivos del ciclo de vida propios de esta fase los siguientes:

  • Documento de Visión[1] aprobado.
  • Modelo de Casos de Uso[2] y Documento de Requisitos Suplementarios aprobado.
  • De usarse, Documento de Especificación de Requisitos del Sistema (ERS).
  • Caso de Negocio viable y aprobado.
  • Estudio de Factibilidad Técnica viable y aprobado.

Para alcanzar estos objetivos, la idea no es crear documentos complejos, sino análisar la información disponible de manera de lograr que en todo el equipo de desarrollo y en la mente del cliente exista una visión clara del proceso a seguir.

Se observará que artefactos interesantes como el Plan de Riesgo no lo he mencionado entre los objetivos del ciclo de vida. La idea es que aún en el caso de tenerlo, es mi opinión que la reducción de riesgos solo es posible cuando se ha considerado el detalle de como se va a desarrollar el proyecto, solución técnica incluida; y esta información no esta disponible durante la fase de Inicio. En general, muchos de estos artefactos interesantes -recapitulando- bien pueden iniciarse, pero su utilidad aún no se vería en una fase tan temprana del esfuerzo de desarrollo.

Finalmente, en cuanto a su duración, sería típico imaginar no más de dos iteraciones[3] en esta fase. De hecho es probable que no dedicamos más que unas semanas al esfuerzo completo de lograr los objetivos de ciclo de vida de la Fase de Concepción.

4 comentarios

Plan de Documentación

Un Plan de Documentación describe los medios que se pondrán a disposición del esfuerzo de documentación del proyecto de desarrollo. Entre otros medios, podemos imaginarnos recursos tales como plantillas, redactores técnicos, guías de estilo, procesadores de texto, etc.

Es sin duda un plan simple, en el sentido en que puede considerarse completo con relativamente poca extensión. Sin embargo es también un típico plan dejado solo para las organizaciones más maduras, ya que muchos simplemente dejan a su esfuerzo de documentación sin planificación alguna.

La creación de documentos completos y útiles no es un arte; es una práctica esencial de la ingeniería y como tal, debe ser vista como algo rutinario, sistematizado con herramientas y en la medida de lo posible, agilizado.

En el espíritu de la agilidad, lo mejor es planificar medios para documentar los aspectos técnicos del proyecto en herramientas de modelado UML[1], prefiriendo estas a los reportes tradicionales que obligan a un mayor trabajo de edición. También es interesante explorar la posibilidad de utilizar técnicas alternativas de documentación, como las Wikis que permitan crear y utilizar la documentación en formas más rápidas.

Otro aspecto a documentar aquí, es el formato de archivo o formatos, que se van a utilizar. Quizás una organización pueda preferir tener sus documentos en formato ODT[2] de OpenOffice, o bien el formato RTF, o quizás en HTML; entre otras muchas posibilidades. La elección puede facilitar mucho el trabajo y sin duda tendremos problemas si hay alguien que no la respete.

No es ilógico tampoco, planificar aquí, que los documentos estarán disponibles en determinada dirección o bien, que tendrán copias actualizadas en formato PDF. La política de propiedad de los documentos así como el responsable de centralizar la publicación de estos, son también aspectos interesantes dignos de contar con una palabra o dos.

Los planes de documentación también guardan relación con el Plan de Mejoramiento del Proceso, ya que al planificar la creación de plantillas, o la actualización de un repositorio de documentos, es posible identificar elementos reutilizables que redunden en una mejora del método de desarrollo con miras a futuros desarrollos.

Por ultimo, he de indicar, que por lo breve de su extensión, es posible que este plan lo mantengamos como parte del documento llamado Plan de Desarrollo de Software, con lo que en realidad podríamos no tener un documento por separado con esta información.

, ,

Deja un comentario