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.

Anuncios

,

  1. En Rumbo a un Proceso Definido (III) « Tecnología y Synergix
  2. En Rumbo a un Proceso Definido « Tecnología y Synergix

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: