Antes de continuar, he de mencionar queel material exppuesto acá lo he ido investigando en un excelente libro de Microsoft llamado Analyzing Requirements and Defining Microsoft .NET Solutions Architectures, que es el texto de preparación para el examen Microsoft 70-300, afortunadamente en mi instituto lo tienen y he podido leerlo aunque fuese en inglés, en español no lo he visto.
-----------------
Capítulo 6 - Creando el diseño físico
La etapa de diseño físico es el último paso en la fase de planificación de el modelo de proceso de MSF. El equipo de proyecto procede al diseño físico después que todos los miembros asumen que ellos tienen la información suficiente desde el diseño lógico para comenzar con la etapa del diseño físico. En el diseño físico, el equipo aplica consideraciones técnicas y restricciones a los diseños conceptuales y lógicos. Porque el diseño físico evoluciona desde el diseño lógico y conceptual, su éxito depende de la certeza de los diseños previos.
El diseño físico es la tercera actividad en la etapa de planificación del modelo de proceso del MSF. El diseño físico es el proceso que describe los componentes, servicios y tecnologías de la solución desde la perspectiva de los requerimientos de desarrollo.
Mientras trabaja en el diseño físico, el equipo crea, basado en diseños previos, y refina la arquitectura de solución que ha sido creada hasta el momento.
Las entradas del diseño físico son los artefactos que han sido creados hasta el momento.
En la etapa de diseño físico, el equipo reduce la brecha entre el diseño lógico de la solución y la implementación por la definición de la solución en términos de detalles de implementación.
Al final del diseño físico, el equipo entrega especificaciones para un conjunto de componentes, ensamblados .NET, binarios y librerías enlazadas; detalles de la interfaz de usuario para la solución; El esquema de bases de datos; Objetos de bases de datos como Triggers, índices y procedimientos almacenados.
Espectro del diseño físico
En el diseño físico, el equipo de proyecto desarrolla las especificaciones de componente y topología de desarrollo con la cual el equipo trabajará para crear la solución.
El diseño físico no implica codificar, pero permite crear especificaciones detalladas para el desarrollo y determinar donde los componentes podrían ser ubicados.
Tampoco es implementación de tecnología, pero permite identificar las tecnologías que serían necesarias para desarrollar la aplicación.
Metas del diseño físico
Identificar las tecnologías apropiadas para el desarrollo.
Transformar el diseño lógico en modelos de diseño lógico.
Proveer una línea base para el proceso de desarrollo.
Definir cuando el hito del plan de proyecto ha sido alcanzado.
Responsabilidades de los roles del equipo en esta etapa
El administrador del producto, gestionará las expectativas del cliente y creará el plan de comunicación, además preparará la implementación de la solución.
El administrador del programa, gestionará el proceso de diseño físico y creará la especificación funcional, además definirá e plan de proyecto, incluyendo recursos, agendas y riesgos.
Los desarrolladores diseñarán los entregables físicos: modelos de diseño, planes de desarrollo, agendas y estimados de desarrollo, además evaluarán las tecnologías, construirán prototipos (de ser necesario) y prepararán los entornos de desarrollo.
Los testeadores, evaluarán y validarán la funcionalidad y consistencia de los diseós físicos contra los escenarios de uso. Además, definirán planes detallados de testing y prepararán los entornos de testing y aseguramiento de calidad.
User experience, evaluará diseños físicos contra requerimientos de usuario y diseñará soluciones de ayuda, además definirá el plan de capacitación.
Administración de entrega, evaluará las implicancias de infraestructura del diseño físico, además definirá la infraestructura, requerimientos de operaciones y soluciones de implementación.
Entregables
Al final del diseño físico, el equipo de proyecto tiene suficiente documentación de diseño completa para empezar a crear la solución. La documentación específica puede variar de solución a solución. Algunos de los entregables al final de la etapa de diseño físico incluyen:
- Diagrama de clases de la solución
- Modelos de componentes, diagramas de secuencia o diagramas de actividades de la solución
- Esquema de base de datos de la solución.
- Línea de base del modelo de implementación, el que provee:
o Topología de red, que indica ubicaciones de hardware e interconexiones.
o Topología de datos y componentes, que indica las ubicaciones de los componentes de la solución, servicios y almacenes de información respecto a la topología de red.
- Especificaciones de componentes que incluyen la estructura interna de los componentes y las interfaces de los componentes.
- Estrategia de packaging y distribución, que identifica los componentes que han de empaquetarse juntos en un componente y especifica como los componentes serán distribuidos a través de la topología de red propuesta.
- Modelo de programación, que identificará las elecciones respecto a la implementación, desarrollo y documentación.
Pasos del diseño físico
Los pasos del diseño lógico son 4 y en ellos el equipo realiza las siguientes tareas:
1. Investigación
a. Determinar las restricciones físicas y de requerimientos.
b. Identificar cualquier cambio de infraestructura.
2. Análisis,
a. Desarrollar un modelo preliminar de implementación.
b. Seleccionar las tecnologías a utilizar en el desarrollo de la solución.
3. Racionalización
a. Determinar una estrategia de packaging y distribución.
b. Empaquetar componentes y servicios
c. Distribuir componentes sobre la topología de red propuesta.
4. Implementación
a. Determinar un modelo de programación
b. Especificar interfaces de componente, atributos y servicios.
Entregables del proceso de diseño físico
Los entregables del paso de investigación describen la infraestructura actual del negocio y proveen los cimientos para los pasos de análisis, racionalización y especificación del diseño físico. Los entregables del paso de investigación incluyen:
a. Topología actual de redes
b. Topología actual de datos
c. Topología actual de componentes
d. Requerimientos físicos sobre la aplicación
e. Actualización de riesgos y planes de mitigación
Identificación de requerimientos y restricciones
A través del proceso de diseño. Se recopila información sobre los requerimientos y restricciones del negocio. En el diseño físico, se enfatiza en los requerimientos físicos y restricciones que afectan al desarrollo de la solución.
Entre los requerimientos típicos a cualquier solución encontraremos:
- Desempeño
- Costo y beneficio
- Facilidad de uso
- Facilidad de implementación
- Facilidad de soporte
- Robustez
- Reusabilidad
A la par, tenemos restricciones comunes a cualquier solución:
- Presupuesto
- Tiempo
- Topología de redes
- Topología de datos
- Topología de componentes
- Directrices de seguridad
Ahora lo que resta es sopesar y determinar que requerimientos han de ponderarse por sobre las restricciones y viceversa.
En ocasiones, el equipo podrá tomar medidas paliativas a las restricciones y conseguir cumplir con los requerimientos, pero en algunos casos se necesitará del apoyo s de un sponsor o del cliente. Ya sea aumentando presupuesto, restando o optimizando requerimientos, etc.
Establecida esta línea base, ya es posible entrar al paso de análisis, donde han de crearse los modelos UML que contendrán nuestro negocio (diagramas de clases, secuencia, colaboración, etc), y nuestro entorno (diagramas de topología).
Con estos modelos y habiendo salvado el obstáculo de los requisitos y requerimientos, en el paso de racionalización ya se puede determinar la mas óptima de las distribuciones de los componentes de la solución. Ya a esta altura estará claro, por ejemplo, si es necesario un cluster de servidores de datos (paso análisis) y si es posible implementarlo (Investigación) por las restricciones que pudieran existir por presupuesto, conocimiento técnico o la topología de redes y datos existente, y según eso hacer los ajustes a la .distribución de los componentes de manera que calcen con la realidad de la organización, el presupuesto existente, el conocimiento técnico a disposición y la tecnología existente., entre otros factores
Finalmente en la etapa de implementación (nda Implementation, no Deployment), se determina el modelo de programación a utilizar. Acá se define como se llevará el manejo de errores, de objetos, factorización de métodos, capas, etc. Aquí es donde los programadores se pelean para elegir si desarrollan en 3 capas, en ene capas, con MVC(Model View Controller), con MVP(Model View Presenter), si usarán multihebras o no, como manejraán la seguridad y todas aquellas calamidades por las que los programadores dejan de hablarse.
lunes, 7 de junio de 2010
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.
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.
Capítulo 2 - Reuniendo y analizando información
Lección 1
Al reunir información respecto a la empresa se busca definir la arquitectura de la empresa, que es un modelo que busca alinear los distintos grupos de tecnologías y procesos con los objetivos de la organización.
Para reunir la información de forma sistemática, se establecen 4 áreas: Negocio, Aplicación, Operaciones y Tecnología.
Negocio :
Describe como funciona el negocio. Desde información de alto nivel, como los objetivos de la empresa hasta un análisis mas detallado a nivel de procesos, jerarquías, actividades.
Aplicación :
Describe como funciona la organización, como se organizan los equipos, las dependencias entre estos, las herramientas (informáticas o no) que utilizan y los procesos que realizan.
Operaciones :
Describe lo que la organización necesita saber para ejecutar sus procesos de negocio y operaciones. Esta categoría incluye modelos standard de datos, políticas de manejo de datos y descripciones de los patrones de consumo de información y producción en el negocio.
Determina los creadores, responsables y consumidores de la información.
Tecnología :
Determina la infraestructura tecnológica necesaria para la ejecución y soporte del negocio.
Técnicas de recopilación de información
Se indican 6 técnicas
Hacer sombra :
Consiste en acompañar a los usuarios en su quehacer diario y preguntar respecto a las tareas realizadas.
Es útil, esencialmente en las tareas de nivel operativo.
Entrevista :
Mientras hacer sombra es útil a nivel operativo, en niveles jerárquicos mas altos es más útil la entrevista personal.
Focus Group :
El focus Group es una técnica de recopilación de información basada en grupos. Se plantea un tema específico y un facilitador ha de capturar las impresiones del grupo en cuestión.
Encuesta :
Son conjuntos de preguntas para obtener información. Ejemplos de esto son los formularios de registro y las encuestas de satisfacción del cliente.
Instrucción de usuario :
En este escenario, el usuario le entrena en las tareas que él desempeña. De este modo puede ver los pasos requeridos en una tarea desde el punto de vista del usuario.
Prototipado :
En esta técnica, se simula un escenario productivo. Se pueden utilizar cámaras para monitorear la interacción entre el usuario y el prototipo, programas que capturen pulsaciones de teclado y Mouse, entre otras herramientas. Lo esencial es capturar la percepción del usuario objetivo respecto del prototipo.
Fuentes de información
Se establecen 3 categorías:
Artefactos :
Es un ítem disponible físicamente en el ámbito del negocio y que describe un elemento o núcleo de un proceso de negocio.
Manuales, planillas de cálculo, medios de software, estudios de mercado y cualquier elemento utilizado en la ejecución del negocio que aporte información del mismo son los elementos a estudiar.
Sistemas :
No son necesariamente informáticos, un sistema es un conjunto de procesos que cumplen un fin determinado. Por ejemplo, dentro de una organización, los procesos de almacenamiento y despacho pueden conformar el sistema de bodega.
Gente :
Las personas vinculadas al negocio son fuente de valiosa información.
Es importante detectar sus roles dentro de cada proceso para extraer la información mas fidedigna y útil de la forma mas efectiva posible.
Lección 3 – Usando notaciones de modelado
Los modelos facilitan la descripción de la situación actual y la propuesta con una terminología común, sencillamente incluso en los procesos complejos y facilitando el consenso en el equipo de proyecto en la comprensión de la problemática del negocio, los requerimientos del cliente y usuarios y la información que debe ser recopilada.
La notación mas común es UML
UML (Lenguaje de modelado unificado) :
Está compuesto por un conjunto de símbolos y modelos o vistas de sistema que buscan analizar el sistema desde distintas aristas.
Tenemos diagramas de clases, que representan los objetos; de casos de uso que buscan describir la operación del negocio; de estados, que describen los estados por los que pasan los objetos del negocio, etc.
Al reunir información respecto a la empresa se busca definir la arquitectura de la empresa, que es un modelo que busca alinear los distintos grupos de tecnologías y procesos con los objetivos de la organización.
Para reunir la información de forma sistemática, se establecen 4 áreas: Negocio, Aplicación, Operaciones y Tecnología.
Negocio :
Describe como funciona el negocio. Desde información de alto nivel, como los objetivos de la empresa hasta un análisis mas detallado a nivel de procesos, jerarquías, actividades.
Aplicación :
Describe como funciona la organización, como se organizan los equipos, las dependencias entre estos, las herramientas (informáticas o no) que utilizan y los procesos que realizan.
Operaciones :
Describe lo que la organización necesita saber para ejecutar sus procesos de negocio y operaciones. Esta categoría incluye modelos standard de datos, políticas de manejo de datos y descripciones de los patrones de consumo de información y producción en el negocio.
Determina los creadores, responsables y consumidores de la información.
Tecnología :
Determina la infraestructura tecnológica necesaria para la ejecución y soporte del negocio.
Técnicas de recopilación de información
Se indican 6 técnicas
Hacer sombra :
Consiste en acompañar a los usuarios en su quehacer diario y preguntar respecto a las tareas realizadas.
Es útil, esencialmente en las tareas de nivel operativo.
Entrevista :
Mientras hacer sombra es útil a nivel operativo, en niveles jerárquicos mas altos es más útil la entrevista personal.
Focus Group :
El focus Group es una técnica de recopilación de información basada en grupos. Se plantea un tema específico y un facilitador ha de capturar las impresiones del grupo en cuestión.
Encuesta :
Son conjuntos de preguntas para obtener información. Ejemplos de esto son los formularios de registro y las encuestas de satisfacción del cliente.
Instrucción de usuario :
En este escenario, el usuario le entrena en las tareas que él desempeña. De este modo puede ver los pasos requeridos en una tarea desde el punto de vista del usuario.
Prototipado :
En esta técnica, se simula un escenario productivo. Se pueden utilizar cámaras para monitorear la interacción entre el usuario y el prototipo, programas que capturen pulsaciones de teclado y Mouse, entre otras herramientas. Lo esencial es capturar la percepción del usuario objetivo respecto del prototipo.
Fuentes de información
Se establecen 3 categorías:
Artefactos :
Es un ítem disponible físicamente en el ámbito del negocio y que describe un elemento o núcleo de un proceso de negocio.
Manuales, planillas de cálculo, medios de software, estudios de mercado y cualquier elemento utilizado en la ejecución del negocio que aporte información del mismo son los elementos a estudiar.
Sistemas :
No son necesariamente informáticos, un sistema es un conjunto de procesos que cumplen un fin determinado. Por ejemplo, dentro de una organización, los procesos de almacenamiento y despacho pueden conformar el sistema de bodega.
Gente :
Las personas vinculadas al negocio son fuente de valiosa información.
Es importante detectar sus roles dentro de cada proceso para extraer la información mas fidedigna y útil de la forma mas efectiva posible.
Lección 3 – Usando notaciones de modelado
Los modelos facilitan la descripción de la situación actual y la propuesta con una terminología común, sencillamente incluso en los procesos complejos y facilitando el consenso en el equipo de proyecto en la comprensión de la problemática del negocio, los requerimientos del cliente y usuarios y la información que debe ser recopilada.
La notación mas común es UML
UML (Lenguaje de modelado unificado) :
Está compuesto por un conjunto de símbolos y modelos o vistas de sistema que buscan analizar el sistema desde distintas aristas.
Tenemos diagramas de clases, que representan los objetos; de casos de uso que buscan describir la operación del negocio; de estados, que describen los estados por los que pasan los objetos del negocio, etc.
Lección 1: Introducción al diseño de soluciones de negocios.
El Microsoft Solutions Framework, MSF o “Marco de trabajo para soluciones de Microsoft” es un conjunto de modelos, principios y directrices para diseñar y desarrollar soluciones informáticas de envergadura empresarial.
Para hacerse cargo de este tipo de proyectos, el marco de trabajo establece 2 líneas base:
1. Provee las metodologías para asegurar que todos los elementos de un proyecto (personas, procesos, herramientas, etc.) puedan ser exitosamente administradas.
2. Provee las metodologías para planificar, diseñar, desarrollar e implementar exitosamente soluciones empresariales.
El modelo de proceso
El modelo de proceso describe el ciclo de vida del proceso de desarrollo. Existen diversos modelos, algunos se caracterizan por ser estáticos y otros por ser flexibles.
Los estáticos, habitualmente requieren de una mayor etapa de análisis y diseño previo (RUP, Cascada), mientras que los flexibles (espiral) carecen de este análisis previo tan extenso pues van profundizando el análisis a la par que desarrollan.
El modelo propuesto por MSF busca unir las mejores características de ambos tipos de modelos.
Plantea 5 fases:
1. Visión
2. Planificación
3. Desarrollo
4. Estabilización
5. Implementación
Cada fase conforma un hito. Una vez completado un ciclo de 5 fases es posible, desde este nuevo escenario volver a evaluar, planificar, desarrollar, estabilizar e implementar la siguiente iteración.
De este modo, no es necesario todo el análisis previo requerido en las metodologías cascada, pero tampoco deja el crecimiento del sistema bajo libre albedrío sino que desde un principio debe estar claro el límite y objetivo de la presente iteración (visión, planificación).
El modelo de equipo
Respecto a la organización de los equipos de trabajo, MSF hace énfasis en la importancia de tener acotados los roles, responsabilidades y metas de cada integrante del equipo.
La flexibilidad del modelo permite adaptarlo al espectro del proyecto, el tamaño del equipo y las destrezas de los miembros del equipo.
Roles en el modelo de equipo MSF
• Product management.
o Es el encargado de mantener el contacto con el cliente. En la etapa de diseño es quien levanta requerimientos, posteriormente es quien representa al equio de cara al cliente, ha de entregarle reportes, resumenes, manejar sus expectativas, etc..
• Program management.
o Es el responsable del proceso de desarrollo. Su meta es entregar la solución al cliente dentro de las condiciones establecidas para el proyecto.
• Development.
o Es el responsable de desarrollar la solución tecnológica acorde a las especificaciones entregadas por el Program Manager.
• Testing.
o Responsable de gestionar los asuntos relacionados con errores e inconsistencias entre lo desarrollado y lo solicitado. Es quien aprueba y certifica la calidad del producto desarrollado.
• Release management.
o Responsable de la implementación y la reducción del impacto producido por la misma.
• User experience.
o Analiza las necesidades y asuntos de soporte de usuario.
En un proyecto pequeño, un integrante puede adquirir mas de un rol. Hay que considerar que la combinación de roles introduce riesgo a los proyectos.
Tabla de combinación de roles
Role Product management Program management Development Testing User experience Release management
Product management N N P P U
Program management N N U U P
Development N N N N N
Test P U N P P
User experience P U N P U
Release management U P N P U
Legend:
P: Possible
U: Unlikely
N: Not recommended
Existen roles adicionales a estos y son:
1. Project sponsor
2. Customer( or Business Sponsor )
3. End User
4. Operations
Disciplinas del MSF
Las disciplinas que contempla MSF son Gestión de riesgo, gestión de proyecto y
Lección 2: Fases en el modelo de proceso de MSF
Como se definió en la lección 1, el modelo de proceso de MSF está basado en hitos y consiste de 5 fases: Conceptualización, planificación, desarrollo, estabilización e implementación. Durante cada fase, el equipo de proyecto desempeña un conjunto de actividades. En esta lección, usted aprenderá sobre las varias fases en detalle. Usted aprenderá también sobre hitos y entregables de cada fase.
Después de esta lección, usted será capaz de
Describir las tareas, hitos y entregables de la conceptualización, planificación, desarrollo, estabilización e implementación.
¿Qué es la fase de conceptualización?
El proceso MSF comienza con la fase de conceptualización. Conceptualización (envisioning) puede ser definida como la creación de una descripción amplia de las metas y restricciones del proyecto. En esta fase, usted identificará el equipo y lo que el equipo debe cumplir para con el cliente. El propósito de la fase de conceptualización es construir una visión compartida del proyecto entre los actores del proyecto.
Durante la fase de conceptualización, el equipo de administración del programa (Program management team) identifica las tareas y entregables acordes a los requerimientos y metas del proyecto. Esta fase culmina en un hito Vision/Scope Approved. Este hito indica que el cliente y el equipo llegan a acuerdo sobre el propósito y dirección del proyecto.
Proceso de Conteptualización
El equipo realiza las siguientes tareas en la fase de conceptualización:
• Definir el Equipo
o Creación de un equipo de proyecto que represente los roles del modelo de equipos de MSF (MSF Team Model). (La persona que crea este equipo es usualmente definido como Senior Management.) Cuando se define el equipo, es importante considerar las destrezas, experiencia y nivel de desempeño de los miembros del equipo. En adición, existen consideraciones como la disponibilidad de recursos y el presupuesto del proyecto.
• Definir la estructura del proyecto
o Identificación de una estructura administrativa para el equipo de proyecto y los estándares para la administración del proyecto.
• Definir las metas del negocio
o Análisis de los problemas y oportunidades del negocio para identificar los objetivos de la solución.
• Estimación de la situación actual
o Evaluación de la situación actual y análisis de la diferencia entre esta y la situación esperada. El propósito de esta evaluación es crear y definir la dirección del proyecto.
• Creación de una declaración de visión y definición del espectro del proyecto
Para hacerse cargo de este tipo de proyectos, el marco de trabajo establece 2 líneas base:
1. Provee las metodologías para asegurar que todos los elementos de un proyecto (personas, procesos, herramientas, etc.) puedan ser exitosamente administradas.
2. Provee las metodologías para planificar, diseñar, desarrollar e implementar exitosamente soluciones empresariales.
El modelo de proceso
El modelo de proceso describe el ciclo de vida del proceso de desarrollo. Existen diversos modelos, algunos se caracterizan por ser estáticos y otros por ser flexibles.
Los estáticos, habitualmente requieren de una mayor etapa de análisis y diseño previo (RUP, Cascada), mientras que los flexibles (espiral) carecen de este análisis previo tan extenso pues van profundizando el análisis a la par que desarrollan.
El modelo propuesto por MSF busca unir las mejores características de ambos tipos de modelos.
Plantea 5 fases:
1. Visión
2. Planificación
3. Desarrollo
4. Estabilización
5. Implementación
Cada fase conforma un hito. Una vez completado un ciclo de 5 fases es posible, desde este nuevo escenario volver a evaluar, planificar, desarrollar, estabilizar e implementar la siguiente iteración.
De este modo, no es necesario todo el análisis previo requerido en las metodologías cascada, pero tampoco deja el crecimiento del sistema bajo libre albedrío sino que desde un principio debe estar claro el límite y objetivo de la presente iteración (visión, planificación).
El modelo de equipo
Respecto a la organización de los equipos de trabajo, MSF hace énfasis en la importancia de tener acotados los roles, responsabilidades y metas de cada integrante del equipo.
La flexibilidad del modelo permite adaptarlo al espectro del proyecto, el tamaño del equipo y las destrezas de los miembros del equipo.
Roles en el modelo de equipo MSF
• Product management.
o Es el encargado de mantener el contacto con el cliente. En la etapa de diseño es quien levanta requerimientos, posteriormente es quien representa al equio de cara al cliente, ha de entregarle reportes, resumenes, manejar sus expectativas, etc..
• Program management.
o Es el responsable del proceso de desarrollo. Su meta es entregar la solución al cliente dentro de las condiciones establecidas para el proyecto.
• Development.
o Es el responsable de desarrollar la solución tecnológica acorde a las especificaciones entregadas por el Program Manager.
• Testing.
o Responsable de gestionar los asuntos relacionados con errores e inconsistencias entre lo desarrollado y lo solicitado. Es quien aprueba y certifica la calidad del producto desarrollado.
• Release management.
o Responsable de la implementación y la reducción del impacto producido por la misma.
• User experience.
o Analiza las necesidades y asuntos de soporte de usuario.
En un proyecto pequeño, un integrante puede adquirir mas de un rol. Hay que considerar que la combinación de roles introduce riesgo a los proyectos.
Tabla de combinación de roles
Role Product management Program management Development Testing User experience Release management
Product management N N P P U
Program management N N U U P
Development N N N N N
Test P U N P P
User experience P U N P U
Release management U P N P U
Legend:
P: Possible
U: Unlikely
N: Not recommended
Existen roles adicionales a estos y son:
1. Project sponsor
2. Customer( or Business Sponsor )
3. End User
4. Operations
Disciplinas del MSF
Las disciplinas que contempla MSF son Gestión de riesgo, gestión de proyecto y
Lección 2: Fases en el modelo de proceso de MSF
Como se definió en la lección 1, el modelo de proceso de MSF está basado en hitos y consiste de 5 fases: Conceptualización, planificación, desarrollo, estabilización e implementación. Durante cada fase, el equipo de proyecto desempeña un conjunto de actividades. En esta lección, usted aprenderá sobre las varias fases en detalle. Usted aprenderá también sobre hitos y entregables de cada fase.
Después de esta lección, usted será capaz de
Describir las tareas, hitos y entregables de la conceptualización, planificación, desarrollo, estabilización e implementación.
¿Qué es la fase de conceptualización?
El proceso MSF comienza con la fase de conceptualización. Conceptualización (envisioning) puede ser definida como la creación de una descripción amplia de las metas y restricciones del proyecto. En esta fase, usted identificará el equipo y lo que el equipo debe cumplir para con el cliente. El propósito de la fase de conceptualización es construir una visión compartida del proyecto entre los actores del proyecto.
Durante la fase de conceptualización, el equipo de administración del programa (Program management team) identifica las tareas y entregables acordes a los requerimientos y metas del proyecto. Esta fase culmina en un hito Vision/Scope Approved. Este hito indica que el cliente y el equipo llegan a acuerdo sobre el propósito y dirección del proyecto.
Proceso de Conteptualización
El equipo realiza las siguientes tareas en la fase de conceptualización:
• Definir el Equipo
o Creación de un equipo de proyecto que represente los roles del modelo de equipos de MSF (MSF Team Model). (La persona que crea este equipo es usualmente definido como Senior Management.) Cuando se define el equipo, es importante considerar las destrezas, experiencia y nivel de desempeño de los miembros del equipo. En adición, existen consideraciones como la disponibilidad de recursos y el presupuesto del proyecto.
• Definir la estructura del proyecto
o Identificación de una estructura administrativa para el equipo de proyecto y los estándares para la administración del proyecto.
• Definir las metas del negocio
o Análisis de los problemas y oportunidades del negocio para identificar los objetivos de la solución.
• Estimación de la situación actual
o Evaluación de la situación actual y análisis de la diferencia entre esta y la situación esperada. El propósito de esta evaluación es crear y definir la dirección del proyecto.
• Creación de una declaración de visión y definición del espectro del proyecto
Bienvenida
Hola
Como ya ha pasado otras veces, me he visto en la necesidad de investigar un tema, en este caso el Microsoft Solutions Framework, aka MSF, aka Marco de Trabajo de Microsoft para el Desarrollo de Soluciones.
Si bien, incluye la palabra Framework en su nombre, no se trata de una tecnología específica, como el Framework .NET o el glorioso Framework XNA, no, en este caso framework(marco de trabajo) refiere a un conjunto de prácticas, métodos que independiente de la tecnología utilizada de fondo debiese, sino garantizar el éxito, al menos reducir los riesgos que acarrea el desarrollo de soluciones de envergadura empresarial.
Consideremos, por ejemplo, un software que gestiona el transporte público, los trenes subterraneos, una torre de control de aeropuerto, son sistemas con donde un yerro puede tener implicancias enormes, incluso fatales, ¿Quieres tú como, desarrollador hacerte, cargo de una catástrofe en el tren subterráneo?, ¿Ser culpable del aumento de enfermedades en invierno porque los niños no pueden tomar un bus al colegio?,¿Culpable de que tu selección de futbol pierda el avión a sudáfrica 2010?. Me imagino que no, y ningún programador no sicópata lo querría, por ello, otros no sicópatas, se han hecho cargo de estudiar un conjunto de buenas prácticas en la gestión de proyectos informáticos y han metido todas estas dentro de este marco de trabajo.
E lo largo de estos posts, trataré, como siempre, ir volcando de la forma mas clara posible los conceptos que este encierra para que luego intenten aplicarlos en sus respectivos equipos de trabajo y así entretodos hagamos mejor software y con ello una sociedad mejor.
Saludos
Manuel Gatica Holtmann
Como ya ha pasado otras veces, me he visto en la necesidad de investigar un tema, en este caso el Microsoft Solutions Framework, aka MSF, aka Marco de Trabajo de Microsoft para el Desarrollo de Soluciones.
Si bien, incluye la palabra Framework en su nombre, no se trata de una tecnología específica, como el Framework .NET o el glorioso Framework XNA, no, en este caso framework(marco de trabajo) refiere a un conjunto de prácticas, métodos que independiente de la tecnología utilizada de fondo debiese, sino garantizar el éxito, al menos reducir los riesgos que acarrea el desarrollo de soluciones de envergadura empresarial.
Consideremos, por ejemplo, un software que gestiona el transporte público, los trenes subterraneos, una torre de control de aeropuerto, son sistemas con donde un yerro puede tener implicancias enormes, incluso fatales, ¿Quieres tú como, desarrollador hacerte, cargo de una catástrofe en el tren subterráneo?, ¿Ser culpable del aumento de enfermedades en invierno porque los niños no pueden tomar un bus al colegio?,¿Culpable de que tu selección de futbol pierda el avión a sudáfrica 2010?. Me imagino que no, y ningún programador no sicópata lo querría, por ello, otros no sicópatas, se han hecho cargo de estudiar un conjunto de buenas prácticas en la gestión de proyectos informáticos y han metido todas estas dentro de este marco de trabajo.
E lo largo de estos posts, trataré, como siempre, ir volcando de la forma mas clara posible los conceptos que este encierra para que luego intenten aplicarlos en sus respectivos equipos de trabajo y así entretodos hagamos mejor software y con ello una sociedad mejor.
Saludos
Manuel Gatica Holtmann
Suscribirse a:
Comentarios (Atom)
