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.

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.

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.

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.

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.

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.

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.

Definimos Riesgo como…

Entenderemos por riesgo cualquier situación posible que de ocurrir perjudique al proyecto en alguna forma. Un riesgo puede ser desde que un avión se caiga hasta que las líneas de crédito del proyecto no sean aprobadas por el banco. Todo lo que pueda ocurrir, si es malo, es un riesgo.

Riesgo hace referencia a toda situación posible que de verificarse, hace daño al proyecto o incide negativamente sobre el desempeño del mismo.

Cualquier administrador de proyectos hace bien en identificar una lista de riesgos y en evaluar si estos son más o menos inminentes. Dicha revisión conviene hacerla en cada oportunidad que se tenga, sobre todo, en las reuniones de avance del proyecto. Es buena practica mantener un documento que liste los riesgos identificados, junto con su probabilidad de aparecer, y el costo o magnitud del daño que harían en tal caso.

En este caso, a la hora de identificar riesgos conviene trabajar un poco de más y tener una enumeración más larga de la necesaria. Eso es mucho mejor que dejarse sorprender por una situación negativa.

Visión del Sistema

Anteriormente habíamos definido a la visión, como la capacidad de prever los detalles de un sistema o proceso desde antes del inicio del mismo.

Dicha capacidad depende de la experiencia y naturaleza de cada quien, por lo que no nos debe sorprender que cada persona relacionada con el proyecto pueda tener una visión enteramente diferente sobre el mismo.

Probablemente quienes tengan formación en Administración de Empresas, tendrán una visión operativa sobre el proyecto, preocupándose por temas de presupuesto y gestión contable.

Quizás, aquellos que tengan una formación en el área de informática y sistemas, tenderán a verlo todo como una aplicación de base de datos con un determino requisito de interfaz de usuario y generación de reportes.

También es probable, que los usuarios del futuro sistema se preocupen por la facilidad de uso y por la conveniencia que el nuevo desarrollo les brindara en sus actividades diarias.

Estas y todas las demás visiones del sistema son correctas. Claramente son diferentes, pero son todas ciertas y correctas al mismo tiempo, ya que el sistema a desarrollar debe responder a las necesidades y requisitos de cada uno de sus usuarios y grupos de decisión.

Es de vital importancia que nuestro proceso de levantamiento de requisitos incluya la captura de estas visiones particulares. A partir de estas opiniones es que se dará forma a los requisitos del sistema y en definitiva, al sistema en si.

Notemos que en este grupo de visiones debemos incluir la nuestra. Nosotros, que somos quienes guiamos el proceso y ejecutamos el desarrollo de lo solicitado, tenemos un visión sobre lo que se va a hacer, y es una opinión tan valida e interesante como la de aquel que ha firmado la orden de compra del proyecto.

Todas estas visiones deben, si me permiten recapitular, ser recogidas en un documento, al que para no pecar de originales, llamaremos Visión del Sistema.

Este es uno de los artefactos claves del Proceso Unificado de Desarrollo (UP), y una vez que le tengamos confianza y le conozcamos mejor le llamaremos simplemente Visión.

El documento de Visión no se queda ahí. Enumerar los puntos de vista de los grupos de decisión es en si algo muy importante, pero es que hay espacio para ejecutar algo mucho más extenso. Desarrollaremos como parte del documento, la seguidilla de los siguientes puntos:

• Enumeración de los Grupos de Decisión. Identificando claramente quien es el representante de cada quien y cual es el rol o misión que este asumirá dentro del proyecto.

• Declaración de la visión de cada Grupo de Decisión identificado, incluyéndonos a nosotros mismos como desarrolladores del sistema.

• Enunciado de los problemas actuales y de las oportunidades que se perciben como posibles a la luz de lo prometido por el proyecto.

• Elaboración de un listado de macro-características que atacan a los problemas observados.

• Elaboración de un listado de características individuales que refinan lo dicho en las macro-características.

• Identificación de los requisitos no funcionales más importantes: tales como consideraciones sobre el entorno de explotación, documentación requerida o ideas sobre el impacto ambiental y social del proyecto.

Considerando que este documento es una plantilla derivada de documento del proceso, veremos que ya tenemos muchos puntos que organizar en alguna forma para generar un documento con sentido. Procuremos utilizar siempre que nos sea posible plantillas profesionalmente desarrolladas como punto de partida de las nuestras. Seguramente podemos hacer un gran trabajo por nosotros mismos, pero es mucho mejor si nos permitimos el tomar provecho de la experiencia acumulada por toda la industria de tecnología de la información.

Un ejemplo de plantilla para documento de visión puede ser encontrada en aquí.

Nos estaremos viendo.

Definimos Grupos de Decisión como…

En idioma inglés, existe la palabra stakeholder, que hace referencia a cualquier grupo o persona que tenga interés sobre el devenir de un proyecto, o bien, que tenga una opinión que sea relevante para la definición del sistema.

Aunque es un término de muy difícil traducción al español, nosotros intentaremos acostumbrarnos a decir algún aforismo en nuestro querido idioma, tal como Grupo de Decisión.

Por esto, podemos concluir que nuestra definición de Grupo de Decisión es la de aquellos grupos de personas, o bien individuos por si mismos, cuya opinión es fuente de requisitos para el sistema, y que por tanto nos conviene tener identificados, ubicados y bien atendidos.

Es práctica sana y si se quiere imprescindible, el identificar y gestionar correctamente a los grupos de decisión de los proyectos. Rutinariamente nos preguntaremos si los hemos identificado a todos, principalmente durante nuestra fase de concepción, en la cual los requisitos se encuentran en rápida evolución.

El precio de no hacer lo aquí recomendado es muy alto: un fracaso más que probable.

Si no tenemos bien identificados a todos aquellos que influyen sobre los requisitos del proyecto, entonces seguramente ellos vendrán por si mismos en algún punto del mismo, probablemente cerca del final, y dejarán caer alguna joya, como que por ejemplo, el sistema no será aceptado por el cliente si no cumple con algún requisito de su propia cosecha… y que es nuevo para nosotros y que puede que nos obligue a rediseñar una gran parte de nuestra base de código.

Tengamos cuidado… los stakeholders sueltos son peligrosos. Mejor tenerlos identificados desde un principio para poder satisfacer sus exigencias poco a poco, durante la vida del proyecto.

Considérese advertido.