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.
Mostrando entradas con la etiqueta msf. Mostrar todas las entradas
Mostrando entradas con la etiqueta msf. Mostrar todas las entradas
lunes, 7 de junio de 2010
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:
Entradas (Atom)
