Capítulo 4 Etapa de planificación

La etapa de planificación comienza una vez terminada la de conceptualización y visión. En esta se define que se construirá, como se construirá y quien lo construirá. Además se prepara la especificación funcional, planes de trabajo, estimaciones de costo y se agendan entregables.

En esta etapa se profundiza lo conseguido en la etapa de conceptualización. Lo que en la etapa antes eran requerimientos de alto nivel pasan a ser requerimientos detallados, los escenarios de alto nivel a escenarios detallados de uso la solución coneptual a una especificación funcional.

Es importante, para el éxito del proyecto saber elegir hasta que punto ha de ahondarse lo conseguido en la etapa de conceptualización. Si se ahonda poco, la información recabada puede resultar insuficiente y resultar un producto inútil a las reales necesidades pero demasiada información puede generar atrasos atascando al equipo en análisis superfluos.

En esta etapa se crean los procesos de diseño conceptual, lógico y físico.

Estos procesos no se realizan en paralelo sino secuencialmente en este orden:

1. Conceptual : Ve el problema desde la perspectiva del usuario y el negocio. Define el problema y solución en terminos de escenarios de uso.
2. Lógico : Ve la solución desde la perspectiva del equipo de proyecto. Define la solución como un conjunto de lógico de servicios cooperativos.
3. Físico : Ve la solución desde la perspectiva de los desarrolladores. Define los servicios y tecnologías de la solución.

Si bien el equipo trabaja como un todo, cada rol en el equipo iene diferentes responsabilidades en la etapa de planificación.

• Product Management : Asegura que el plan cumple con las necesidades del cliente. Este rol es responsable de refinar los requerimientos, analizar el actual estado del negocio, optimizar la conceptualización del negocio y crear el diseño conceptual.
• Program Management : Asegura que los recursos pueden cubrir el plan de proyecto. Este rol es responsable de todo el diseño, con especial énfasis en el diseño lógico y la especificación funcional. El program Management crea los las planificaciones y agendas del proyecto y es responsable de completar la etapa de planificación.
• Desarrollo : Asegura que el plan es técnicamente factible. Este rol es responsable de crear el diseño lógico y físico y agregar esto a la especificación funcional. Este equipo determina el tiempo y esfuerzo requerido para desarrollar y estabilizar la solución.
• Testing : Asegura que el plan cumple con los requerimientos. Eset rol es responsable de evaluar el diseño y determinar las características que pueden ser testeadas y establecer una agenda para el testeo de estas.
• Release Management : Evalúa el diseño para una fácil implementación, administración y soporte. Además, este rol determina agendas para la implementación de la solución.
• User Experience : Asegura que los usuarios estarán capacitados para usar el producto. Este rol es responsable de analizar las necesidades de los ususarios y crear estrategias de soporte acorde, y de evaluar el diseño en cuanto a usabilidad. Este rol tambien estima el tiempo y esfuerzo necesario para desarrollar sistemas de soporte y conducir el testing de usabilidad para todas las interfaces de usuario entregables.

La etapa de planificación culmina en el hito de planificación aprobada, que es el punto en que el equipo de proyecto, el cliente y los sponsors están de acuerdo respecto de los entregables del proyecto y en que el plan cumple con los requerimientos.

Los entregables finales en este hito son:

• Especificación funcional : Representa lo que el proyecto será.
• Plan maestro de proyecto : Es la colección de los planes que dirigirán las acciones llevadas a cabo por cada uno de los seis roles para cumplir con lo propuesto en la especificación funcional. Documenta las estrategias a utilizar.
• Agenda maestra de proyecto : Es el documento que sincroniza las agendas de todos y cada uno de los equipos.
• Documento actualizado de riesgos de proyecto : Este documento, desarrollado en la etapa de conceptualización, es revisado y actualizado regularmente y especialmente en los hitos y describe los riesgos asociados a la solución. Comúnmente se manejan varios documentos y se priorizan los riesgos con mayor incidencia.

Todos estos, son documentos vivos, que evolucionan a lo largo del proyecto, pero cada cambio realizado en estos debe ser primero aprobado por un comité de usuarios y sponsors.

Especificación funcional

Durante la etapa de planificación, el enfoque del equipo de proyecto es el de convertir la definición de un problema en el diseño de una solución. Uno de los primeros entregables en este hito es la especificación funcional.

La especificación funcional define que será construido y cuando será construido.

La especificación funcional no es desarrollada 100% de forma inicial, generalmente, en la medida que los distintos equipos aportan sus puntos de vista sobre la solución, la especificación funcional inicial evolucionará.

La especificación funcional es el repositorio virtual del proyecto y los artefactos relacionados al diseño que son creados durante la etapa de planificación. Los artefactos son un resultado de las actividades realizadas en el diseño del proceso conceptual, lógico y físico. Dichos artefactos pueden incluir modelos UML como diagramas de casos, escenarios de uso, requerimientos candidatos, características candidato y varios modelos de información.

Es importante recordar que la especificación funcional es virtual por naturaleza. Muchos de los artefactos pueden estar almacenados en distintas bases de datos de distintas herramientas y ser de formas heterogéneas.

Algunas metas de una especificación funcional son las siguientes:

• Consolidar la comprensión del negocio y requerimientos de usuario.
• Dividir la solución de forma lógica para facilitar su comprensión.
• Proveer un marco de trabajo para planificar, agendar y construir la solución.
• Servir como un contrato entre el equipo y el cliente respecto a que será entregado.

No tener una especificación funcional acarrea riesgos, entre los que tenemos:
• El equipo desarrolla una solución que no apunta completamente los requerimientos del cliente.
• El equipo puede no tener suficiente detalle para validar y verificar que la solución cumple con las expectativas del cliente.
• El Project manager podría estimar erróneamente los esfuerzos y destrezas necesarias en e equipo y redundar esto en problemas de agenda.


Diseño conceptual

Es una profundización y refinamiento de lo hecho en la etapa de conceptualización.

El diseño conceptual no es una especificación funcional completa, pero ayuda a iniciarla.

No es tampoco una definición de componentes de sistema, pero ayuda a identificar las partes del problema del negocio que serán atendidas por eventuales componentes.

Tampoco es una solución tecnológica, pero ayuda a registrar las actividades de negocio y exponer sus límites y relaciones.

El proceso de diseño conceptual tiene 3 pasos:

- Investigación : Donde se atan los cabos que pudieran quedar sueltos en la etapa de conceptualización.
- Análisis : Donde se refinan los requerimientos candidatos y se documenta y modela el contexto, flujo de trabajo, secuencias, etc.
- Optimización : Donde se optimiza lo hecho en la etapa de conceptualización y se validan y testean procesos de negocio mejorados.



Construcción del diseño conceptual

A grandes rasgos, consiste esencialmente en la construcción de casos de uso, ya sean UML o conversacionales, y ejemplos prácticos de cómo sería atendido el problema en base al caso de uso expuesto en los distintos escenarios, con los distintos perfiles de usuario para cada uno de los requerimientos que aquí mismo se establece serán desarrollados.

Además se puede postular acá la arquitectura de solución a utilizar, para esto se dividen lógicamente las áreas a desarrollar y cada una de estas divisiones en servicios y se establece como cada uno estos diferentes servicios colaborarán entre si.

Por otra parte, los servicios han de organizarse acorde a la arquitectura propuesta para la aplicación. Ha de considerarse, por ejemplo si la arquitectura de solución será cliente servidor o no.


Optimización de procesos

Ya teniendo un primer diseño conceptual es posible evaluarlo, recorrerlo y analizarlo. Haciendo esto podremos detectar puntos ciegos, redundancias y cuellos de botella que podría presentar nuestra solución, lo que podría redundar en una mayor complejidad de uso, de desarrollo o mantención. Entonces, la tarea es factorizar casos de uso, eliminando o fusionando aquellos que redundan, dejando en evidencia los puntos omitidos y buscar soluciones alternativas a los cuellos de botella.

Para realizar este trabajo podemos prototipar, hacer role playing o recorridos sobre el diseño conceptual, documentar y en función de ello tomar las medidas pertinentes.