Archivos para 21 octubre 2007

En Rumbo a un Proceso Definido (III)

Anteriormente habíamos establecido a un Proceso Definido como un conjunto de Trabajadores, Herramientas, Plantillas y Flujos de Trabajo; de manera que en su conjunto facilitará el desarrollo de los sistemas y aplicaciones que se nos soliciten.

Ademas habíamos explorado al Proceso Trivial de Desarrollo, que si bien es definido peca por su poco alcance; lo cual le hace inadecuado para las tareas de desarrollo del mundo real.

Veremos que las deficiencias del Proceso Trivial de Desarrollo pueden ser atacadas si reorganizamos el proceso. Hemos de incluir algunas practicas que aquel deja por fuera y quizás, organizar el desarrollo en su conjunto en algún modelo de ciclo de vida. En este post, nos proponemos atacar este primer angulo, introduciendo la división del Proceso en un grupo de Disciplinas que por medio de su colaboración resuelven el proyecto de desarrollo en un marco de calidad, control y sentido de la profesionalidad.

Las Disciplinas que vamos a introducir resuelven el desarrollo por medio de un proceso en serie, esto es, una cascada de actividades que se ejecutan una luego de la otra. Recordemos que nuestra intención es contar con un Proceso Iterativo Incremental, por lo que nuestras disciplinas se ejecutan una vez por cada iteración y en múltiples pasadas van madurando los artefactos según los objetivos de ciclo de vida que se deseen alcanzar.

Por lo dicho hasta ahora, pasemos a definir nuestras disciplinas centrales de desarrollo:

Disciplina de Requisitos que ejecuta la identificación y captura de las necesidades que el proyecto debe cubrir con lo desarrollado.

Disciplina de Análisis (ver definición) que ordena en un esquema lógico lo que se ha implicado con los requisitos. Su principal producto son los llamados escenarios de análisis y las realizaciones de caso de uso. Todos artefactos que detallan el funcionamiento de un sistema (por ahora inexistente) que exhibe las funcionalidades solicitadas.

Disciplina de Diseño (ver definición) que encuentra una forma de sistema o código o arquitectura, que al momento de su puesta en ejecución da lugar a lo delineado en el análisis, siempre teniendo en foco los requisitos a cumplir.

Disciplina de Implementación que transforma en código maquina lo diseñado. También asume la redacción de los manuales de usuario y todos los demás artefactos que se definan como parte del sistema en explotación más que del proyecto.

Disciplina de Pruebas que define los esquemas de evaluación con los que se determinará si lo desarrollado cumple con los requisitos identificados.

Para cada una, tal y como corresponde a una disciplina, tendremos plenamente identificados los artefactos, trabajadores, herramientas y flujos de trabajo relacionados. En otras palabras: todos los que participan en una de estas disciplinas sabrán siempre que es lo que se espera de ellos, que actividades ejecutar y que artefactos producir.

Espero que en post siguientes podamos explorar el detalle de cada una de nuestras disciplinas centrales de desarrollo así como introducir tanto nuestro modelo de ciclo de vida como las llamadas disciplinas de soporte, las cuales nos ayudarán a tener control sobre el proceso así como a identificar formas de mejorarlo.

El comienzo de esta serie de artículos lo puede ver En Rumbo a un Proceso Definido.

, , , , , , ,

1 comentario

Definimos Ciclo de Vida como…

¿Qué le ocurre a un Sistema de Información exitoso? Es usado. Es ampliado y modificado por años. Eventualmente será reemplazado por una versión diferente. Eventualmente será puesto en retiro. Si el sistema tiene éxito, ¿cuanto tiempo pasa en todo este proceso?

La respuesta claro esta, es que los Sistemas de Información de éxito sobreviven por años, por lo cual adquieren una suerte de vida propia con su dinámica y su destino determinado por la utilidad que son capaces de prestar a sus usuarios y dueños.

Es por esto que podemos hablar de un Ciclo de Vida, todos esos años en los que un Sistema de Información va cambiando y adaptándose organizados como un modelo de etapas sucesivas de fácil comprensión.

Ciclo de Vida se refiere a las etapas que atraviesa un sistema en explotación, desde que es concebido inicialmente hasta que es retirado definitivamente.

Aquí la idea clave es la de etapa, una forma de organizar los eventos en el ciclo de vida de la aplicación según en donde se dirige el foco. Las etapas que más comúnmente se utilizan para hablar de ciclos de vida son:

  1. Concepción
  2. Elaboración
  3. Construcción
  4. Transición
  5. Mantenimiento
  6. Retiro

Según el Proceso Definido que adoptemos, el Ciclo de Vida tendrá más o menos etapas, un asunto de organización que exploraremos en su momento.

, , , , , , ,

2 comentarios

Definimos Disciplina como…

Diremos que estamos frente a una Disciplina cuando tengamos en claro un único Flujo de Trabajo, con Trabajadores, Artefactos, Herramientas y Actividades claramente identificadas; todos trabajando en conjunto para la consecución de unos fines específicos.

En otras palabras, una Disciplina es un Proceso Definido (o parte de uno) cuyo objetivos no son en si mismos, el desarrollo solicitado por el cliente.

Puede sonar extraño que nosotros entremos a definir Procesos Definidos que no son directamente la respuesta a lo que el cliente nos ha pedido, pero lo que ocurre es que la experiencia demuestra que no es posible desarrollar el programa simplemente escribiendo el código. Es por esto, que a través de los años los procesos de desarrollo han ido asumiendo practicas intermedias entre la solicitud del proyecto, el código, y el programa o sistema que se entrega al cliente.

Entonces, es hora de definir Disciplina con un poco más de formalidad:

Disciplina se refiere al cuerpo de actividades de creación, actualización y consumo de artefactos, que son ejecutadas por los trabajadores del proyecto por medio de un Flujo de Trabajo bien definido.

Cada Disciplina tiene un objetivo especifico, que colabora en el avance del proyecto en una forma clara y especificada en el Proceso que se siga.

Aunque son muchas las posibles disciplinas de desarrollo, veremos que nos resultan conocidas pues asumen nombres que asociamos a las antiguas etapas de un proceso de desarrollo en cascada. Entre otras: Disciplina de requisitos, disciplina de análisis y diseño, disciplina de pruebas. En su momento veremos de que tratan estas y todas las demás disciplinas.

Nos estamos viendo.

1 comentario

Plan de Finiquito del Proyecto

Como parte del llamado Plan de Desarrollo de Software, se incluye la planificación de las actividades y pasos a realizar para dar por concluido el proyecto. Algo que por puntual, es evidencia de cuan detallado puede llegar a ser la planificación y gestión de un proyecto de software.

Veamos: el Plan de Finiquito y Cierre del Proyecto es típico que solo tenga unos pocos párrafos, explicando lo siguiente:

  • Formalidades para dar el finiquito al proyecto. En otras palabras, que documento ha de estar firmado por que representante de las organizaciones cliente y de desarrollo.
  • Procedimientos de devolución de equipos y recursos asignados al proyecto, tales como computadoras, manuales, etc.
  • Propagar el fin de proyecto al fin de los contratos de arrendamiento de oficinas, fin de la relación con los profesionales contratados, etc.
  • Procedimiento administrativo en la organización cliente para concretar el pago del proyecto.
  • Re asignación de los profesionales que han participado en el proyecto, indicando con quien han de reportarse.
  • Cualquier otra consideración que se considere pertinente.

En resumen: este plan es de pocos párrafos de extensión, y se suele incluir como parte del Plan de Desarrollo de Software. Simple, rápido y fácil, pero detallado y un signo de estar haciendo las cosas correctamente al planificar los detalles del proyecto; incluyendo su final.

Nos estamos viendo.

, , , ,

Deja un comentario

Guiado por Requisitos y Riesgos

Idealmente todo Proceso Definido tendría una declaración de los principios detrás de las decisiones que se tomaron durante su diseño y puesta en punto. Esta declaración de principios resumiría en unas pocas frases todo el cuerpo metodológico del proceso.

En nuestro caso, tomamos la frase “Guiado por Requisitos y Riesgos” del Proceso Unificado de Desarrollo de Software, más conocido por las siglas UP.

Ser guiado por algo, significa que ese algo se tomará en cuenta en cada reunión de avance, para que las acciones siguientes estén moldeadas a la luz de este concepto guía. Tal como cabría esperar, el proceso UP define que su avance será planificado según los requisitos del proyecto y se cuidará siempre de los riesgos identificados.

Poniendo esto en forma más clara, tendríamos dos puntos:

Primero: UP es guiado por requisitos, lo cual quiere decir que es según estos como se expresa tanto la división del proyecto en subproyectos, como la planificación de las tareas a abarcar en una iteración dada. Si tenemos un Paquete de Requisitos con una organización racional, veremos que UP recomienda basarse en esta división para ir cubriendo los requisitos en una forma ordenada y sistemática, atendiendo sus dependencias y maximizando en todo momento el valor de negocio entregado por las actividades.

Segundo: UP es guiado por riesgos, lo cual en forma análoga a la anterior, significa que en cada iteración se incluirán actividades y tareas que busquen atacar los riesgos, según orden el de importancia con que se registraron estos en el Plan de Riegos del proyecto.

Existen dos principios más enunciados por UP como ideas centrales del proceso, pero las dejaremos para otro día. Por ahora, cuando planifique los próximos pasos de sus proyectos, cuide siempre que estas estén diseñadas tanto para satisfacer los requisitos por orden del valor de negocio que generan como para que ataquen los riesgos más importantes, todo según lo que se identifico en los documentos y demás artefactos relacionados con el manejo de requisitos y riesgos.

Deja un comentario

Requisitos vs. Requerimientos

En ocasiones se utiliza al diccionario como una suerte de autoridad para resolver dudas sobre las palabras de la lengua. Esto funciona bien la mayoría de las veces, pero falla en algunos casos borde donde las dos palabras en disputa están lo suficientemente difundidas como para tener un lugar dentro del diccionario.

Por otro lado, hay disputas entre palabras que son tan de vieja data que incluso cada una tiene una raíz que a su vez, se a visto en conflicto con la raíz de la otra. En otras palabras, se generaba discusión en Latín, y se sigue la misma en Español.

Un caso de estas disputas son la pareja de palabras Requisitos y Requerimiento. En lo personal prefiero la primera, pues me parece una forma correcta, corta y suave de utilizar como sustantivo la idea de algo que es requerido. Si se requiere, es un requisito.

Así tenemos que el uso de requisito denota algo que se espera cumplir. Si lo que queremos es indicar que este hecho de requerir se ha dado, se ha transferido de manos, la gente espontaneamente opta por utilizar la palabra Requerimiento.

Por tanto, un requerimiento se da o se indica para que otro lo tenga como requisito. En tanto que si uno identifica algo que es necesario cumplir, lo anota como un requisito desde el principio.

La disputa surge sobre cuando utilizar cada una. Tal parece que en lugar de darle un lugar a cada palabra lo que hace mucha gente es redactar teniendo solo uno de los dos puntos de vista en mente, con lo cual se logran redacciones de poca flexibilidad. O por decirlo de manera menos diplomática, se degrada la redacción con la excusa de estar elaborando un documento técnico.

Yo tengo en cuanta lo dicho aquí, por lo que en forma uniforme uso la expresión Requisito. La forma de Requerimiento no me gusta en realidad y la evito siempre que es posible. Por esto el proceso que propongo incluye actividades como Identificación de Requisitos y artefactos como Paquete de Requisitos. Los nombres análogos que utilizan requerimiento están en uso también, pero espero que no se dejen ver en este blog.

Quizás sea cuestión de uso o estilos, pero de alguna manera me resisto a creer que la ligera diferencia entre una y otra se deje pasar por alto sin afectar la claridad de los documentos.

11 comentarios

Como combatir los riesgos

Existen tres formas básicas de combatir los riesgos: eliminación, cobertura y diversificación. Estas estrategias son sencillas y de aplicación universal, en cuanto valen como posibles alternativas ante cualquier tipo de riesgo. Veremos si las podemos explicar con ayuda de un ejemplo deportivo.

Digamos que hay dos equipos de fútbol en la liga, que tienen mucha competencia entre ellos. Nosotros estamos en posición de apostar… y como perder es algo que no queremos entonces estamos frente a nuestro riesgo ya definido: “perder nuestra apuesta”.

Como tal, este riesgo tiene una probabilidad de ocurrencia del 50%… estadística que bien puede variar en función de los equipos en cuestión. Este porcentaje es la probabilidad de ocurrencia del evento.  50% significa que el asunto es como tirar una moneda: puede que se gane, puede que se pierda.

Vamos a trabajar este riesgo con la primera alternativa. La Eliminación de Riesgos es el acto de tomar decisiones que los hacen imposibles de ocurrir. En nuestro caso: decidir no apostar.

En cuanto a la segunda alternativa, si apostamos no a uno solo sino a los dos equipos… pues uno de ellos necesariamente ganará… cierto? A esta estrategia la llamamos Cobertura de Riesgos. Ante un riesgo dado, su cobertura será un evento necesariamente opuesto que ocurre al presentarte el problema y que hemos dispuesto que nos compense por el daño recibido.

Finalmente tenemos La Diversificación de Riesgos. Esta es simplemente no apostar tan solo en el partido de nuestro ejemplo, sino que también vamos a atrevernos a apostar en otros. De esta forma, perderemos en algunos y ganaremos en otros. A la larga, una buena política de diversificación puede hacernos ganar incluso si hemos perdido una fracción importante de los encuentros.

Los riesgos son parte de la vida… así que hay que prepararse contra ellos y para cada uno escoger una de las políticas básicas: Eliminación, Cobertura y Diversificación.

, , , , , ,

6 comentarios