Archivos para 29 septiembre 2007

Glosario del Proyecto

Un Glosario contiene las definiciones de los términos propios de un proyecto o actividad. Este artefacto es importante, ya que es la base para lograr un vocabulario común entre los grupos relacionados con el desarrollo del proyecto.

Hay que recordar que aunque nuestra lengua posee un diccionario que la resume, cada quien da connotaciones diferentes a las palabras, por lo que los términos en uso, sufren de un proceso de deriva que los aleja de su significado común. Por otro lado, en muchas profesiones se da el fenómeno de utilizar palabras extranjeras, a las que se le otorga un significado preciso muchas veces de gran importancia.

Difícilmente podremos encontrar un proyecto en que no se justifique mantener un Glosario completo y detallado. Las palabras tienen un gran poder de síntesis, por lo que nuestros clientes podrán darse a entender más fácilmente si saben que les oímos en sus propios términos. Pero también es cierto que las palabras poseen un gran poder de análisis por lo que ser capaces de modelar el vocabulario del proyecto es un paso importante para modelar el dominio del problema y hallar el diseño de una solución.

Las palabras correctas muchas veces son en si mismas, el diseño correcto. Durante miles de años los seres humanos nos hemos esforzado en darnos a entender con palabras, por lo que nuestras mentes ya vienen equipadas con poderosos instrumentos de abstracción los cuales podemos ahora reutilizar con miras al desarrollo de aplicaciones.

De hecho, una de las heurísticas más simples para encontrar clases en un desarrollo orientado a objeto es precisamente el análisis[1] sujeto/verbo/predicado hecho sobre las sentencias del enunciado del problema. Una técnica sencilla y efectiva en ocasiones, que no nos pide mucho para mantenerla en la mira.

¿Son necesarias más razones para justificar el esfuerzo invertido en un Glosario? Veamos un resumen de sus ventajas:

  • Define un vocabulario común con el cliente
  • Delimita una suerte de mapa mental que sirve para el análisis
  • Da pistas sobre conceptos importantes que son candidatos a clases

Así llegamos a la conclusión: en todo proceso de desarrollo conviene mantener un Glosario. Muy bien, ¿como lo hacemos?

A partir de la plantilla Documento del Proceso elaboramos una nueva llamada Glosario, en la cual tendremos la familiar estructura de Entrada/Acepción a la que nos tiene acostumbrados todos los diccionarios.

En adición a la simple definición del término, debemos mantener una lista de sinónimos y homónimos para cada una de ellas, de manera de agilizar el uso del Glosario manteniendo referencias entre las entradas.

Los sinónimos, palabras diferentes que tienen igual significado, son causa de confusiones cuando uno entiende cosas ligeramente diferentes con cada uno de ellos, por lo que normalizamos el vocabulario poniendo sobre aviso a todos los involucrados sobre cuales sinónimos se encuentran en uso dentro del proyecto. Por ejemplo, una entrada del Glosario podría indicar que como sinónimo al término Departamento de Ventas se suele utilizar las siglas DV.

Pero mucho más peligrosos son los homónimos, palabras con significado diferente que suenan o se escriben igual. Las confusiones que los homónimos generan son mucho más graves y en realidad nos conviene mantenernos alejados de ellas.

Si para uno o más términos no se encuentran sinónimos u homónimos, coloquemos Ninguno o quizás No Aplica, como prueba de haber considerado estas entradas habiendo decidido con consciencia de lo que se hacía, que no hay algo que sea pertinente colocar. Por otro lado dejar en blanco estas secciones es ambiguo: quizás es que se nos olvidó, quizás es algo intencional.

Eso es todo. Como parte de su proceso de captura de requisitos es necesario ejercer la actividad de desarrollar un vocabulario común para lo cual es imprescindible un Glosario. Afortunadamente este es un documento fácil de crear y mantener, que en adición a lo anterior nos ayudará en el análisis e incluso en el diseño. Toda una ganga que no podemos dejar pasar.

Anuncios

, ,

3 comentarios

Documento del Proceso (II)

Según las practicas comunes en cada lugar u organización, los elementos comunes de los documentos vienen dispuestos en distintos lugares del mismo. Un ejemplo de esto es el Indice de Contenido, el cual suele colocarse de primero o en las primeras páginas del documento en Venezuela y otros países de habla española, en tanto que en USA muchas veces es colocado de ultimo.

Diferencias como la anterior no nos deben llamar a la admiración ni constituire en un problema. De todos modos, cada artefacto del proceso, e incluso el proceso mismo de cada organización debe ser adaptado a sus propias necesidades y costumbres, por lo que tener el indice en un lugar distinto al sugerido en metodologías como RUP es algo muy natural.

Por otro lado, si bien la disposición de los elementos comunes puede variar, debería tenerlos en algún sitio bien definido de sus documentos, ya que recogen información útil sobre los pasos del proceso.

Finalmente, una lista parcial de elementos para que los tenga en consideración:

  • Identificación del documento: Título, Proyecto y Versión.
  • Identificación del autor: Nombre e información de contacto.
  • Identificación de quien aprueba, en caso de requerirse una aprobación.
  • Historial de versiones del documento.
  • Glosario de términos utilizados.
  • Glosario visual de los iconos utilizados.
  • Alcance del documento, esto es, identificar que parte del proceso o del sistema que se cubre en el documento. Por ejemplo Arquitectura del Sistema: Módulo de Atención al Cliente.
  • Artefactos tomados como entrada, indicando nombre y versión.
  • Artefactos generados como derivados, indicando nombre.
  • Anexos.
  • Indice de Contenido.
  • Indice de Figuras.
  • Indice de Tablas.

De la lista anterior, tome lo que considere que se justifica para su organización. Es importante que mantenga el alcance del documento, así como la relación de artefactos en entrada y salida, ya que esta información le ayuda más adelante con las trazas de requisitos.

Coloque los nombres de las secciones y escriba pequeñas secciones de introducción a cada sección. Añada además las notas e indicaciones para los futuros usuarios de su plantilla. Recuerde que estas plantillas serán llenadas por seres humanos, por lo que las indicaciones en cuanto a estructura, forma y contenido que pueda ir planificando desde ahora le harán la vida más sencilla en un futuro. Todo esto será de utilidad cuando intente en realidad hacer su trabajo con ayuda de la documentación que produzca.

, ,

Deja un comentario

Documento del Proceso

A diferencia del Documento en Blanco, este nuevo artefacto posee una estructura visible. No solo se han utilizado aquí los margenes y estilos definidos en la plantilla de base -la de Documento en Blanco, tengamos presente- sino que se han añadido elementos que serán comunes a todos nuestros documentos a lo largo y ancho de nuestra organización.

Sugiero que las plantillas sean vistas como una jerarquía de clases de documentos. De esta forma, Documento en Blanco seria el objeto raíz dependiente de plataforma y la plantilla Documento del Proceso sería nuestra raíz independiente de la plataforma pero definida enteramente para las necesidades del proceso.

Me explico: la plantilla Documento en Blanco tendrá opciones propias del editor de textos que utilicemos, fijadas de forma tal que todos los documentos que se escribamos sobre está tengan un aspecto uniforme. Por tener en su diseño consideraciones del procesador de textos, le llamo a esta plantilla “dependiente de la plataforma”.

Por otra parte, la plantilla de Documento del Proceso es diseñada pensando exclusivamente en la organización común de los documentos a desarrollar en la organización. Ahora las opciones exactas de formato no son nuestro problema. En su lugar nuestro objetivo es enteramente la estructura del documento y la forma en que se utilizará. Esto es, la plantilla es “dependiente del proceso”.

Según cuales sean nuestras influencias metodológicas, la estructura de este documento puede cambiar. Sin embargo parece razonable que deberá incluir información de identificación suficiente, quizás un historial, y anexos tales como un glosario.

Fije usted toda esta estructura en la plantilla. De ser necesario coloque pequeños comentarios sobre el propósito de cada sección. A estas indicaciones las hemos de colorear o adornar de forma tal que nadie dude que son comentarios para el redactor de documentos, y que por tanto no deben estar presentes en ningún documento entregado.

Suerte en este nuevo artefacto, a partir de aquí los documentos comenzarán a tener un estructura que refleje nuestra manera de trabajar, así que nos tendremos que poner un poco más formales y sugerir organizaciones precisadas en mayor detalle.

Estaremos en contacto.

, ,

3 comentarios

Documento en Blanco

El joven Johannes se levantó aquel día como todos los días. Con la obligación de ir al trabajo, pero con un peso del alma tan grande, que a duras penas pudo bajar a la cocina a tomar el desayuno.

Su madre le advirtió “come toda tu comida, o las brujas se la llevarán” broma con que siempre le animaba a comer antes de ir a lo que él imaginaba como un horrible trabajo: un centro de copiado de libros. Ahí la labor era pesada y solo la tradición familiar junto a la necesidad de comer, le lograban convencer de ir.

Las responsabilidades de Johannes incluían el tallado de los tipos, pequeñas fichas con la forma de las letras. También se encargaba, cuando su tío el jefe estaba de buen humor, de montar las páginas para su impresión. “Ojalá me permita imprimir hoy” era un pensamiento cotidiano pero que pocas veces se lograba convertir en realidad. Solo los talladores más experimentados podían recibir la confianza suficiente como para arriesgar todo ese precioso trabajo de crear los tipos en la impresión de una hoja de texto. Corria el siglo XV y los libros eran cosa muy delicada.

Así Johannes dedico la mayor parte de su vida a una labor pesada de la que no gustaba. Su sueño fue siempre lograr una forma simple de hacer su trabajo. No podía dedicarse a nada más, así que siguió su instinto e inventiva y termino dando al mundo un objeto de lo más transcendental: la imprenta.

Johannes Gutenberg diseño la imprenta de tipos móviles luego de años de esfuerzo y desarrollo. Todo lo que invirtió en ella le pareció poca cosa, al lado del esfuerzo extraordinario que demandaba el copiado de un libro en sus días.

Cada letra tallada por separado, cada página compuesta a mano, cada folio impreso con cuidado y esmero, y sin embargo todo ese esfuerzo se perdía en poco tiempo dada la fragilidad de los tipos utilizados. La gran novedad de la imprenta no era la técnica en si misma, sino la posibilidad de agilizar el trabajo al simplificar la creación de las letras y la composición de las páginas. Gutenberg utilizo metal para los tipos y pequeños moldes que le permitían crear todas las letras que quisiera con un poco menos de trabajo manual.

Es admirable lo mucho que ha avanzado la tecnología. Hoy en día generamos documentos en pocos minutos, dedicando poca atención a toda la infraestructura que es necesaria para lograr tener una hoja de papel con nuestro pensamiento plasmado en ella.

Quizás las opciones de formato de un procesador de texto moderno no sean tan difíciles de usar como una imprenta de los tiempos de Gutenberg, pero es una irresponsabilidad el pensar que solo por esa facilidad nadie debe ocuparse de los detalles detrás de cada documento.

Es mi tesis aquí, que incluso una humilde hoja en blanco -con sus opciones de margenes, estilos de edición predeterminados, cabezas y pies de página- debe ser objeto de cuidadoso diseño.

No solo para respetar la memoria del joven Johannes y de todas esas comidas que las brujas no se comieron, sino para lograr también, que nuestros documentos tengan un aspecto uniforme y que a lo largo del tiempo, sea más fácil el leerlos.

Recuerde: los procesadores de palabras modernos tienen muchas opciones de formato, no querrá que sus proyectos tengan aspectos diferentes para sus documentos ni mucho menos, que esto pase dentro de un mismo desarrollo.

Así que vaya ahora mismo, y comience a definir como es para su organización, un documento en blanco.

, ,

2 comentarios

En Rumbo a un Proceso Definido (II)

Sin duda alguna, la creación de un sistema de información es la construcción de uno o más programas. Y como tal, la actividad de crear programas es conocida por todos los estudiantes de programación e informática del mundo. De hecho, el primer impulso del novato es intentar crear el sistema, armado únicamente con la secuencia simple de pasos que aprendió en sus cursos de programación básicos: Editar, Compilar y Probar.

Hay que reconocer dos virtudes de este enfoque: es fácil de entender y es iterativo. De momento, pese a que más tarde hablaremos de sus limitaciones, utilizaremos el Proceso Trivial de Desarrollo como caso de ejemplo de Proceso Definido.

Después de todo, de definir un proceso pues este puede ser uno cualquiera. Idealmente uno va a definir un buen proceso, pero vale el ejemplo de momento, con un proceso trivial.

Flujo de Trabajo Trivial

Fig 1. Esquema de Trabajo Trivial

Lo anterior es un Flujo de Trabajo. Tiene un punto de inicio y otro de fin, representados por los puntos de arriba y abajo, respectivamente. En medio, las actividades se indican con cuadros conectados con líneas, siguiendo el orden de los sucesos. Los pequeños rombos representan decisiones que modifican el flujo: aquí, según si el programa está completo o no, se repite el ciclo entero. Por ultimo, los cuadros azules representan documentos o artefactos del mundo real, que son intercambiados como parte del flujo de actividad.

Este pequeño dibujo incluye otra característica que quiero resaltar ahora. Dado que la decisión del final –¿está completo el programa?– genera una repetición completa del ciclo de desarrollo, hablaremos de este y de la línea de flujo que sube al principio, como Lazo de Iteración. Una idea que mencionamos aquí como referencia futura.

Como sea que el propósito es contar con un Proceso Definido, lo siguiente que debemos hacer es identificar a nuestros trabajadores e indicar sus responsabilidades. Esto lo podemos hacer con ayuda del siguiente dibujo:

 Programador

Fig 2. Definición de las tareas del Programador

En el Proceso Trivial de Desarrollo, el único Trabajador es el Programador. Por esto nos basta de momento con su definición. En la figura 2, se ve que él está encargado de las tareas de Editar, Compilar y Probar. Las mismas que han sido presentadas en el Flujo de Trabajo de la figura 1, ahora organizadas según quien las realiza – en nuestro caso, todo lo hace el programador.

Incluso podemos avanzar e indicar el detalle de cada una de las Actividades o Tareas del Programador. Esto lo hacemos indicando las entradas y salidas de la actividad, como se ha hecho en la siguiente figura.

Detalles de la Tarea Compilar

Fig 3. Detalles de la Tarea Compilar

En la figura 3, la sección de la izquierda indica las entradas, la derecha las salidas, y la central señala con precisión que actividad va a ser realizada y quien es su responsable.

Claramente para realizar la actividad de compilar, el programador necesitará de algunas herramientas. Entre otras:

  • Computador con sistema operativo instalado.
  • Compilar del lenguaje utilizado en el proyecto.
  • Paquetes de las bibliotecas utilizadas.
  • Herramientas de construcción.

Para cada uno de estos puntos se hace referencia a productos concretos, que deben ser licenciados e instalados antes de poder ser utilizados. La idea es saber que herramienta en especifico se va a utilizar y tenerla a mano para cuando se necesite.

Lo anterior es solo un ejemplo, pero si incluimos convenientes plantillas y recursos de ayuda a las actividades, habremos definido para el así llamado Proceso Trivial de Desarrollo los cuatro componentes de un Proceso Definido: Trabajadores, Herramientas, Flujos de Trabajo y Plantillas.

¿Es esto todo lo que es un Proceso Definido? En esencia, así es. Tenemos un enfoque sobre como hacer el trabajo, lo hemos normalizado con un flujo explicito, lo alimentamos con herramientas y plantillas, y hemos asignado las actividades involucradas a un trabajador con un rol y misión bien definidos.

Cuando una organización ha definido sus procesos en una forma similar a la anterior, se encuentra en la capacidad de disfrutar de muchas virtudes, por ejemplo:

  • Puede adquirir las herramientas más idóneas.
  • Puede mejorar sus practicas de entrenamiento.
  • Puede reproducir casos de éxito en otros proyectos.
  • Puede identificar recursos útiles para proyectos siguientes.

Entre otras posibles ventajas.

Realmente nos conviene contar con procesos bien definidos en nuestras organizaciones de desarrollo de software. Sin embargo una advertencia: un proceso definido no es necesariamente un buen proceso. Uno puede definir e incluso automatizar un proceso ineficiente o limitado. Tal cosa nos conduciría a una especie de ineptitud organizada, no a una organización eficiente.

Entonces finalmente, ¿qué es lo malo con el Proceso Trivial? Pensemos en algunas de sus limitaciones y en el futuro próximo definiremos mejores procesos que nos ayuden a superarlas. He aquí, una lista breve de problemas con el Proceso Trivial:

  • No es escalable. Contempla un solo Programador. No hay indicaciones sobre Equipos de Programadores.
  • No hay gestión de requisitos. De alguna manera, en este proceso son los programadores quienes interpretan los requisitos del cliente y son ellos también quienes visualizan una forma de atenderlos.
  • No hay un manejo de la Arquitectura. La aplicación es construida como una colección de pequeños aportes más o menos independientes. No hay actividades orientadas a definir y mantener un diseño a gran escala.
  • No hay forma de medir la duración. No hay una forma clara de saber cuanto tiempo se va a llevar el proyecto. ¿Una semana? ¿Un mes? ¿Un año? No hay ningún soporte previsto para esto.

Entre otros mucho problemas. La lista podría seguir y seguir por docenas de puntos problemáticos. En alguna forma, espero poder atacar todos estos problemas con ayuda de procesos más robustos, que sin llegar a ser pesados en exceso nos puedan dar una plataforma cierta y estable para atacar proyectos complejos. Proyectos complejos como los de hoy en día.

Este artículo continua En Rumbo a un Proceso Definido (III), puede ver el comienzo de la serie En Rumbo a un Proceso Definido.

Por ultimo, menciono que los gráficos han sido elaborados utilizando la herramienta Dia y retocados en menor grado con Gimp. Todos los gráficos son esencialmente compatibles con UML si bien han sido sometidos a un proceso conocido como estereotipado, ya que aquí y allá he utilizado iconos alternativos. Ambas herramientas utilizadas son proyectos de software libre y están disponibles para todas las plataformas en uso corriente.

,

2 comentarios

Definimos Iterativo Incremental como…

Qué fue primero: ¿el huevo o la gallina?

Anónimo

Se dice que Charles Darwin hizo una de las más grandes colaboraciones al pensamiento occidental cuando dio al conocimiento publico su ahora famosa Teoría del Huevo y la Gallina. En ella, nuestro amigo ingles nos explica que las estructuras complejas, tales como los seres vivos, pueden ir variando en el tiempo, sometidos como están a presiones de selección, con lo cual “unos ganan y sobreviven, y otros encuentran potenciales obstáculos en su camino. Unos viven y se reproducen y otros mueres y son olvidados”. De esta forma, no hubo un primer huevo ni una primera gallina, existieron seres anteriores que ni nacieron del huevo ni mucho menos fueron gallinas, que cambiaron poco a poco en el tiempo hasta que un día, despertar con que eran gallinas ponedoras de huevos.

También encontró el amigo Darwin, que bajo el nombre de Teoría del Huevo y la Gallina su propuesta no iba a encontrar el apoyo deseado, por lo cual cambió el nombre de esta por el de Teoría del Cambio por Dar Vueltas e Incrementar cada vez. Un nombre quizás muy largo, pero que expresaba que siempre que se daba una nueva generación (o iteración) el avance no esta asegurado, sino que en su lugar lo que se logra es una variación del concepto original, quizás mejor, quizás peor.

Finalmente se decidió por el nombre de Evolución, tomando prestadas las técnicas de formación de palabras de las lenguas clásicas como el Latín. Sin embargo hay que recordar que algo evoluciona cuando da vueltas sobre algo, y que este movimiento circular da lugar a la mejora solo como un efecto secundario.

Reconozco que lo dicho hasta aquí es solo un trabajo de ficción, pero es que me es muy fácil imaginar a la Evolución como una técnica de trabajo en la construcción de sistemas complejos. Se parte de una idea simple, fácil de implantar, y se va variando esta, dando vueltas y más vueltas sobre el concepto deseado, hasta ver que uno se ha acercado al objetivo tanto como para darse por satisfecho.

Con todo, lo anterior no tiene nada de específicamente biológico. De hecho, es una aproximación enteramente valida al problema de la construcción de sistemas software; donde el resultado es más complejo que lo que podemos construir con una sola pasada por nuestros procesos de análisis y diseño de aplicaciones.

Considerando todo lo anterior, estamos listos entonces para definir Proceso Iterativo Incremental.

Proceso Iterativo: se dice que un proceso es iterativo cuando sus pasos se repiten una y otra vez, como en un ciclo. Al dar por concluido el ultimo paso, se procede con el proceso entero desde el comienzo.

Y por tanto:

Proceso Iterativo Incremental: se dice que un proceso es iterativo incremental cuando en cada iteración de sus pasos se alcanza una mayor cercania con los objetivos finales. Esto es, se añade algo nuevo de valor en cada iteración.

Siempre que estamos ante la construcción de un sistema complejo, vale de mucho recordar al problema del Huevo y la Gallina. La naturaleza nos ofrece un sistema complejo, auto definido, como lo es la relación huevo – gallina, puesto a funcionar casi en forma mágica, y en el que prácticamente no quedan referencias a como fue construido.

¿Quieren una receta para el éxito? Copiemos a la naturaleza. Ha venido funcionando desde hace millones de años y tal parece que no necesita administración ni mantenimiento. Por esto, construyamos nuestros sistemas software complejos, siguiente la simple receta de ser Iterativo e Incremental, tal y como lo son el huevo y la gallina.

En dos frases: comenzar con algo sencillo, repetir los pasos de análisis y diseño, incrementar el código. Repita tantas veces como sea necesario hasta alcanzar los objetivos de su proyecto. Eso debe ser suficiente.

, , ,

2 comentarios

En Rumbo a un Proceso Definido

A la pregunta, ¿qué es un proceso definido?[1] siempre le sigue ¿como asumimos un proceso así?. Ambas son preguntas muy lógicas, que intentaremos responder a la medida en que avancemos con este blog.

Veamos de cerca la primera: ¿Qué es un Proceso Definido?. Anteriormente habíamos intentado una definición, ahora hagamos una aproximación gráfica, con ayuda de unos inocentes dibujos.

Proceso Definido - Paquete

Fig 1. Paquete UML que representa un Proceso Definido

La Figura 1 representa una visión de conjunto, sin detalles por el momento, de un Proceso Definido. Veamos luego con detalle lo que esto representa, pero de momento hagamos la siguiente abstracción: un proceso definido es un conjunto de cosas -un paquete- que se manejan como un conjunto y que se asume como practica diaria.

Puede resultar interesar observar que existen infinitos posibles Procesos Definidos de desarrollo del software. De hecho, cada organización que asuma este método de desarrollo en cierta medida tendrá que crear su propio Proceso.

Hoy por hoy, el Proceso Unificado se erige como el método de desarrollo de software por Proceso Definido, más importante. De este método hablaremos en detalle a lo largo de la vida de este blog, ya que es la referencia número uno en esta forma de pensar sobre el trabajo de desarrollar aplicaciones y sistemas software.

Del Proceso Unificado (UP) existen numerosas variaciones, siendo la más conocida la variación comercial RUP. Un punto de partida para conocer de esto es la Wikipedia, como siempre, una fuerte de información general invaluable.

Veamos ahora un poco del contenido de nuestro paquete Proceso Definido.

Proceso Definido - Contenido

Fig 2. Contenido del Proceso Definido

En una primera aproximación, un Proceso Definido ha de incluir una visión detallada de entre otras cosas, lo siguiente:

  1. Trabajadores. Identificando sus responsabilidades y habilidades requeridas. Es tentador llamar Rol a esta idea, ya que un mismo ser humano puede desempeñarse como varios Trabajadores del Proceso, pero es que en UML la palabra rol ya fue reservada para algo bastante especifico.
  2. Herramientas. Enumerando cuales están a disposición de los trabajadores y cual función cumple cada una. Como parte de las herramientas se debe contar con todo el equipo, licencias, manuales, y demás elementos físicos que son necesarios para llevar a cabo las actividades de los Trabajadores.
  3. Flujos de Trabajo. Del inglés workflow, se detalla la forma y el momento en que el Proceso fluye de una actividad a la otra. Los pasos de estos flujos son ejecutados por los Trabajadores utilizando las Herramientas, aunque quizás con algo de apoyo de los Clientes.
  4. Plantillas. De manera de no comenzar un trabajo desde cero. Después de todo, no es la primera vez que se hace un proyecto de esta naturaleza, por lo que es factible tener plantillas con todo lo que es común a cada producto del Proceso. Llámese documento, código, diagrama, o cualquier otra cosa.

Así la cosa, para que una organización asuma un Proceso de desarrollo bien definido, vale mucho comenzar por precisar cuales trabajadores, herramientas y plantillas integran el proceso, así como pensar claramente en la secuencia de pasos que se han de dar para cumplir con lo pautado en los proyectos. Esto es, conviene pensar en definir las cosas en lugar de dejarlas para el día a día.

Cuando una organización adquiere un Proceso Definido de un proveedor, lo que en realidad compra es un conjunto de directrices, plantillas, manuales, herramientas, asesoría y recomendaciones, que han sido pensadas como un todo orgánico, y que en su conjunto permiten a la organización destino, desarrollar software.

Y es que, guerra avisada no mata a soldado. Siempre y cuando este vaya con la suficiente preparación. Esa es la filosofía detrás de todo Proceso Definido. Dejar por fuera la improvisación y dar la bienvenida a todo lo que nos ayude a conocer los detalles del camino por seguir.

Este artículo continua en En rumbo a un Proceso Definido (II).

Por ultimo, los gráficos de este post son compatibles con UML 1.4, y fueron obtenidos utilizando la herramienta ArgoUML. Un proyecto de software libre que elabora un modelador de UML. Aunque es cierto que existen muchas otras herramientas de mayor poder, ArgoUML se destaca por ser sencillo, multiplataforma y libre. Vale la pena darle una mirada y considerar su uso. Al menos en proyectos sencillos.

, , ,

3 comentarios