MSF: MICROSOFT SOLUTION
FRAMEWORK
Nos ofrece orientación sobre cómo organizarnos como equipo, planificar los proyectos, construir e implementar con exito las soluciones que desarrollamos a nuestros clientes. Cabe destacar que no puede haber un solo proceso de desarrollo de software para todos los proyectos que ejecutemos. En eso consiste la filosofía principal que esconde Microsoft Solutions Framework.
Gracias a estas caracteristicas que tiene este modelo nos permite identificar muy bien y rapido todos los inconvenientes que podemos obtener y asi repararlos en su debido momento.
Microsoft Solutions Framework (MSF) es un enfoque personalizable para entregar correcta y más rápidamente soluciones tecnológicas, con menos personas y menos riesgo, pero con resultados de más calidad.
MSF ayuda a los equipos a resolver directamente las causas más comunes de error en el proyecto de tecnología, lo cual mejora los índices de buenos resultados, de calidad de la solución y de impacto comerciales.
MSF es una metodología flexible e interrelacionada con una serie de conceptos,
modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos.
Modelo de Equipo: Es un modelo que ha sido diseñado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto, asignando roles y responsabilidades a cada miembro del equipo con el objetivo de satisfacer los objetivos del proyecto. Puede ser escalado dependiendo del tamaño del proyecto y del equipo de personas disponibles. En publicaciones
posteriores se explicara con detalle la propuesta de Modelo de Equipo planteado por MSF.
Modelo de Proceso: Diseñado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberación de versiones y explicando su relación con el Modelo de equipo.
Disciplina Gestión del Riesgo: Diseñado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratégicas correctas y controlar las emergencias que puedan surgir.
Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar Disciplina Administración de Proyectos o Gerencia de Proyectos.
Es una disciplina que describe el rol de la gestión del proyecto que se basa en: Planificar sobre entregas cortas
Incorporar nuevas Caracteristicas sucesivamente
Identificar cambios ajustando el cronograma
MSF incluye modelos propios asociados a Proyectos de Desarrollo de Software los cuales se mencionan a continuación:
Modelo de Arquitectura del Proyecto: Diseñado para acortar la planificación del ciclo de vida. Este modelo define las pautas para construir proyectos empresariales a través del lanzamiento de versiones.
Modelo de Diseño de Proceso : Diseñado para distinguir entre los objetivos
empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseño eficiente y flexible a través de un enfoque iterativo.
Las fases de diseño conceptual, lógico y físico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores
Modelo de Aplicación: Diseñado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para diseñar y desarrollar aplicaciones software.
MODELO DE EQUIPO DE
MICROSOFT SOLUTION
FRAMEWORK (MSF)
Como Lideres de Proyectos, debemos buscar obtener una visión integral estudiando todo el ambiente que rodea las diversas actividades propuestas para un proyecto, analizando todos los actores que pueden intervenir, influir, estar interesados o ser considerados como propietarios del mismo.
Esto implica cualquier persona u organización que pueda estar activamente
involucrada, que pueda tomar una decisión que afecte significativamente los resultados o que sus intereses puedan variar para bien o para mal, como consecuencia de la relación de este proyecto.
Actores del Proyecto: Equipo del proyecto Clientes/Usuarios Proveedores
Competidores: Son individuos u organizaciones, internos o externos que verían sus intereses afectados como consecuencia del proyecto.
Complementadores: Son individuos u organizaciones, internos o externos, que pueden tener sinergia con el proyecto.
Sociedad: Representa el gran contingente de actores externos que pueden verse afectados por la realización del proyecto.
El modelo de equipo propuesto por MSF Microsoft ha propuesto un modelo de equipo de trabajo con la finalidad de que cada miembro del equipo que participe en un proyecto tenga roles y responsabilidades bien definidos. Cabe destacar que esto es un elemento fundamental para que un proyecto tenga éxito, garantizando que cada persona que interviene en el proyecto es conocida y valorada por el trabajo que desempeña.
Para generar el modelo se consideraron las siguientes premisas:
La satisfacción de los clientes. Los proyectos deben responder a las necesidades de los clientes y usuarios con el fin de tener éxito.
Es posible cumplir los objetivos de presupuesto y el tiempo, pero todavía no tener éxito si las necesidades del cliente no se han cumplido.
La entrega de la solución dentro de las limitaciones del proyecto.
Un objetivo fundamental para todos los equipos es entregar dentro de las limitaciones del proyecto.
Construcción de la especificación.
El documento de requerimientos describe en detalle cada escenario.
Todo el software se entrega para probar y corregir los defectos. Un objetivo clave es asegurar que los defectos son identificados y tratados antes de la entrega del mismo.
Para que un producto tenga éxito, debe mejorar la forma en que los usuarios ejecutan sus trabajos. Deberíamos velar por entregar un producto rico en características y contenido, que sea utilizado por los usuarios.
El modelo de equipo de MSF es un modelo para los equipos de proyecto de TI. Cuenta con seis grupos de función(comúnmente conocido como roles) que corresponden a los principales objetivos del proyecto y tienen la responsabilidad de ellos.
TAREAS, ESPONSABILIDADES
Y ÁREAS FUNCIONALES DEL
MODELO DE EQUIPO DE
TRABAJO MSF
Tareas, responsabilidades y áreas funcionales del Modelo de Equipo de Trabajo MSF.
Este modelo de equipo MSF no es rígido y puede ser escalado dependiendo del tamaño de los proyectos y de las personas disponibles. Cada papel que se presenta a
continuación contiene varias áreas funcionales estrechamente relacionados que apoyan el objetivo del rol que se este desempeñando.
El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. Cada rol puede estar compuestos por una o más personas, la estructura circular del modelo, con óvalos del mismo tamaño para todos los roles, muestra que no es un modelo jerárquico y que cada todos los roles son igualmente importantes en su aporte al proyecto. Aunque los roles pueden tener diferentes niveles de actividad durante las diversas etapas del proyecto, ninguno puede ser omitido.
La comunicación se pone en el centro del círculo para mostrar que está integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicación efectiva y es esencial para el funcionamiento del mismo
¿Como están estructurados los roles?
Seis funciones principales, donde cada funcion refleja sus areas funcionales.
Cada area funcional tiene responsabilidades especificas asociadas importantes para alcanzar el exito del proyecto.
A su vez, cada responsabilidad puede ser dividida en varias tareas necesarias para llevarla a cabo.
Si una funcion especifica es muy amplia para ser ejecutada por una sola persona, se permite dividir la funcion en varias personas especificando responsabilidades.
A continuación una breve descripcion de la funcion de cada integrante del modelo y sus areas funcionales:
1. Gerente del Proyecto:
Es responsable de entregar la solución dentro de las restricciones del proyecto (Tiempo, Alcance, Costos).
Áreas funcionales:
Administración del proyecto: las responsabilidades son el seguimiento y control del presupuesto del proyecto asi como la visión general del proyecto y el gantt general; conducir la gestión de riesgos, asignar tareas, recursos a los miembros del equipo, facilitar la comunicación dentro del equipo, seguimiento de progreso del proyecto, gestionar informenes de estado.
Arquitectura de la solución: Velar por la arquitectura de la solucion se visualice, desarrolle e implemente a cabalidad, en algunos equipos de proyecto el Gerente de Proyecto es la misma persona que trabaja como Arquitecto de Soluciones, en otros proyectos son personas diferentes donde el Arquitecto de Soluciones es el lider del equipo de desarrollo de software. Esta responsabilidad tambien gestiona el alcance de la solucion.
Servicios administrativos :
Implementación de procesos y equipo de soporte.
Gerente del Producto
Representa a los interesados (skateholders) del proyecto. Debe garantizar la Satisfacción a los clientes.
Áreas funcionales:
Identificar el Valor de negocio: definición de Metricas para medir el valor del negocio y definir la justificación del proyecto y el impacto sobre la organización.
Marketing: Promocion de la solución entre los miembros del equipo del proyecto resaltando el para que se esta ejecutando el proyecto.
Abogado del cliente: Maneja y comunica las expectativas del cliente, mantiene la comunicación entre el cliente y el equipo del proyecto.
Planeamiento del producto (roadmap) : Recoger, analizar y priorizar las necesidades del cliente y del negocio. Determinar métricas de negocio y criterios de éxito.
Identificar cuando ir liberando las versiones del producto segun el equipo de proyecto vaya entregando avances.
Desarrollador: Construye la solución de acuerdo con las especificaciones.
Áreas funcionales:
Consultoría tecnológica: El desarrollador tiene la responsabilidad de ejercer el rol de consultor tecnologico, participa activamente en los requerimientos funcionales. Diseño e implementación de la arquitectura: Mapea la arquitectura diseñada para la aplicación, implementa respetando el diseño fisico de la solución.
Desarrollo de la aplicación: Codifica segun el diseño logico que le es entregado. Depura el codigo y presta soporte.
Desarrollo de la infraestructura:
Desarrollo de documentación de implementación, los scripts para el despliegue automatizado, realización de revisiones de código, la realización de las pruebas unitarias.
Pruebas
Responsable de aprobar la versión solo luego de que todos los defectos de calidad son identificados y resueltos.
Áreas funcionales:
Planificación de pruebas: Elaborar diseño y especificaciones del plan de pruebas. Reportes de pruebas: Seguimiento de errores y comunicaciones, la finalidad es estar seguros de que todas las correcciones se han efectuado antes de liberar una versión.
Puesta en operación;
Planifica y ejecuta una puesta en operación sin tropiezos. Dar soporte a las peraciones. Áreas funcionales:
Soporte: Servicio de soporte técnico al cliente, establece niveles de atencion y registra las incidencias.
Logística: Administración de cuentas de usuario, logistica de operación. Custodia y Administración de versiones.
Experiencia de Usuario:
Mejora la efectividad del usuario. Áreas funcionales:
Generar material para entrenamiento y soporte, Investigación y pruebas de
“usabilidad”, Colaboración en definir el diseño de la interfaz de usuario, Abogado del usuario final.
PRINCIPIOS FUNDAMENTALES
APLICADOS A LA
ADMINISTRACIÓN DE
RIESGOS EN MSF
Definición de Riesgo y Administración del Riesgo
Antes de comenzar a desarrollar el tema sobre la administración del riesgo con MSF, es importante hacer una definición de riesgo, en este sentido cabe destacar que el riesgo es una situación de probabilidad de ocurrencia de un evento, una vulnerabilidad, una amenaza. Subrayo probabilidad porque así debemos enfocarlo, no es una certeza, en otras palabras la probabilidad de ocurrencia no puede ser 0 ni puede ser 1, ¿Por qué? Si es 0 es porque estamos seguros de que un evento jamás va a ocurrir entonces no hay riesgo y si es 1 es un evento seguro de que ocurrirá y allí estaríamos más bien preparados para el hecho.
Basándonos en la definición estricta del riesgo y analizando el momento que
planificamos las actividades de un proyecto, observaremos que no estamos seguros de que todas las actividades puedan ejecutarse, sin embargo no podríamos decir que todas las actividades del proyecto son un riesgo, ¿Por qué en la vida practica NO consideramos todas las actividades como un riesgo?, sencillo sabemos que existen actividades que tienen mayor probabilidad de ocurrencia que otras.
Continuando con el párrafo anterior, dentro del manejo de riesgo del proyecto ponemos aquellas actividades que tengan una probabilidad de afectar a nuestro proyecto en tiempo, costo y alcance más alta que otras.
Un riesgo es un evento que nos pueda afectar en tiempo, costo, alcance y calidad al proyecto. Es aquí donde surge la importancia de la Administración del Riesgo.
como una forma de abordar un problema desde un punto de vista gerencial para disminuir los riesgos inherentes al proyecto. La administración del riesgo pretende identificar, estudiar y eliminar las fuentes de riesgo antes de que comiencen a amenazar el éxito o la finalización exitosa de un proyecto
Principios Fundamentales Aplicados a la Administración de Riesgos en MSF. 1 Mantenernos Alertas y preparados para el cambio.
Como administradores del riesgo debemos desarrollar habilidades básicas para
mantenernos alertas, habilidades que nos permitan ejecutar un buen papel frente a los cambios que podemos estar haciendo durante todo el ciclo de vida del proyecto, producto del análisis de riesgos del mismo.
Estas habilidades son:
1. Identificar: Tenemos que tomar estándares o guías, que pueden ser propios del proyecto, del cliente, de la empresa donde laboramos, para aprender y visualizar que es un riesgo y que no.
2. Analizar: Es la habilidad más importante porque el análisis arroja sobre una actividad de riesgo su impacto en costo, tiempo y calidad.
3. Planear: Acciones concretas para contener el riesgo, poner en blanco y negro que hacer para que los riesgos se minimicen.
4. Controlar, administrar y monitorear los riesgos con todas las actualizaciones.
A menudo puede pasar que un riesgo que planeamos no se convierte en un evento, sin embargo el riesgo una vez que transcurre el proyectodesaparece y aparecen otros nuevos, es un proceso constante de identificación, análisis, evaluación y monitoreo de los riesgos, es importante estar pendiente hacia todos los riesgos que puedan ocurrir al principio del proyecto y durante todo el ciclo de vida.
Producto del constante monitoreo sobre los riesgos durante el ciclo de vida del proyecto puede originar cambios en las actividades del proyecto en momentos determinados con la finalidad de minimizar amenazas y aumentar la probabilidad de éxito.
Un enfoque proactivo permite al equipo aceptar el cambio y convertirlo en una oportunidad, y con ello evitar que el cambio pueda convertirse en una fuerza perturbadora, en algo negativo.
2 Promover una Comunicación Abierta en el Modelo de equipo de trabajo MSF.
MSF alienta una actitud de comunicación abierta hacia debatir los riesgos, tanto con los
miembros de equipo de trabajo como con los principales interesados externos del proyecto. Todos los miembros del equipo deben participar en la identificación de riesgos y en el análisis de los mismos.
Los jefes de equipo y la administración de riesgos deben apoyar y fomentar el desarrollo de una cultura de no culpar a ningún miembro del proyecto sobre la probabilidad de que ocurra un riesgo, al contrario, se debe promover una discusión franca y abierta de los riesgos del proyecto con todos los afectados por ese riesgo, para conducirnos a una mayor precisión en la evaluación del estado del proyecto y una mejor toma de decisiones, tanto dentro del equipo como en la dirección ejecutiva y los patrocinadores.
Como describimos en un artículo publicado anteriormente sobre el El Modelo de equipo MSF, este modelo se basa en la premisa de que cada función presenta una perspectiva única en el proyecto y que ninguna persona por sí misma puede representar de una manera satisfactoria todos los objetivos de calidad de todas las funciones. Sin
embargo, el cliente necesita una sola fuente de información que cuente con autoridad sobre el estado del proyecto, las acciones y los problemas actuales. Para resolver este dilema, el equipo de compañeros debe combinar una línea clara de responsabilidad hacia el cliente con la responsabilidad compartida con el fin de lograr el éxito en general.
Dentro del equipo, cada función es responsable de todas las actividades que son necesarias para lograr su propio objetivo de calidad.
Cada miembro del equipo es responsable del éxito general del proyecto y de la calidad de la solución y se espera que contribuya con ideas y observaciones que se deriven de su conocimiento incluso en áreas en las que no es responsable de una manera
personal.
En concreto, las funciones del equipo MSF comparten responsabilidad en muchos aspectos de la administración del proyecto, por ejemplo, la administración del riesgo, la administración del tiempo, la administración de la calidad, el planeamiento, la programación, la selección de los miembros del equipo y la administración de los recursos humanos.
Bajo esta premisa, no hay una sola persona que administre el riesgo dentro de MSF, cada integrante del equipo debe rendir cuentas claras sobre sus actividades actividades y la administración de riesgos.
Sin embargo es el área de Gerencia de Proyectos quien lidere en general la administración del riesgo. Es el Gerente de Proyecto el responsable general de la Administración del Riesgo.
4. Aprender de Todas las Experiencias
En todas las disciplinas, y dentro de la vida misma el aprendizaje continuo sobre las experiencias o hechos nos dan la condición de mejorar perennemente.
MSF nos invita a analizar constantemente las actividades del proyecto, los factores de éxito, los factores de riesgo, el conocimiento acumulado de un proyecto puede disminuir la incertidumbre en torno a la toma de decisiones.
EN SEIS PASOS:
ADMINISTRACIÓN DE
RIESGOS EN MSF
Identificar
El primer paso que debe considerar el Gerente de Proyectos como el responsable general de la Administración de Riesgos es identificar durante el proceso de
planificación del proyecto, aquellas actividades que tengan mayor probabilidad de no ejecución o con mas variables requeridas para una ejecución exitosa.
Durante la Planificación del Proyecto, cada miembro del equipo de MSF debe evaluar sus actividades, las variables asociadas a una exitosa ejecución como tiempo, recurso humano, alcance, capacidades técnicas y de conocimientos, clientes, proveedores, en fin, todo lo que interviene en cada actividad para que esta se ejecute.
Cada miembro colabora en la construcción de la lista de riesgos, como equipo se llega a consensos para poder continuar con la planificación del proyecto.
Durante la actividad de identificación de los riesgos en la fase de planificación del proyecto, es importantísimo el intercambio de ideas entre los miembros del equipo del proyecto, las reuniones e incluso talleres formales para la percepción real de los riesgos del proyecto.
A continuación las fuentes que pueden estimular la detección del riesgo:
2. Procesos: Presupuestos, horarios, costos, requerimientos del proyecto, diseño, construcción y pruebas.
3. Tecnología: Seguridad, desarrollo, entornos de prueba, herramientas de implementación.
4. Entorno: Leyes del país, reglamentos de la organización, el ambiente de negocios en la organización.
Analizar y Priorizar
El responsable de la Administración del riesgo, debe tomar la lista construida entre todos, analizar los elementos de riesgo y darle prioridad para la acción, tomando en cuenta que riesgos comprometen, por ejemplo recursos para su ejecución, una estrategia de negociación, entre otras.
Independientemente de la técnica que se utilice para cuantificar la probabilidad de riesgos, es importante reflejarlo al organizar el orden de prioridades de los riesgos, cada riesgo y su valoración de probabilidad de que ocurra debe ser validado en consenso por los miembros del equipo.
Debemos considerar también el impacto del riesgo, cuales son los costos asociados, efectos adversos.
Podemos construir una matriz de riesgos, reflejando la probabilidad y el impacto que tendría sobre el proyecto.
Planificar y programar Unas ves construidas la matriz de riesgo, su impacto y la probabilidad de que ocurra, debemos diseñar el plan de acción, se considera que es la tarea con mayor esfuerzo dentro de la administración del riesgo. Es desarrollar una lista de acciones y actividades a ejecutar para cada riesgo identificado. Este plan de acción se incluye en el cronograma del proyecto, se deben asignar responsables para su ejecución.
Es importante que el equipo entienda que las actividades de control de riesgos es una parte esperada del proyecto y no un conjunto adicional de las responsabilidades que podría hacerse en forma voluntaria. Todas las actividades de riesgo deben tenerse en cuenta en la programación de proyectos y el estado de presentación de informes.
Seguimiento y presentación de informes de estado de riesgo
Se considera que este es un punto fundamental en la administración del riesgo, hacer seguimiento para poder ejecutar los planes de manera eficaz. El seguimiento nos asegura que se ejecuten los planes de contingencia desarrollados para cada riesgo en el momento oportuno.
La presentación de informes de riesgos se presenta en dos niveles:
1. Plan general de Riesgo, con sus estados de avance de ejecución del proyecto, que actividad se ejecuto exitosamente, cuales son los próximos riesgos a considerar según el estatus de ejecución del proyecto, cuales se activaron y como se solucionaron, es un informe gerencial y se presenta en juntas de proyecto.
Control
Debemos hacer constante monitoreo constante de las tareas identificar, analizar, priorizar, hacer seguimiento. Como administradores del riesgo nos comprometemos a supervisar y evaluar el progreso en forma constante tomando en cuenta:
El Control de los planes de acción de riesgo. Corregir las variaciones de los planes.
Responder a los factores desencadenantes. Los resultados y las lecciones aprendidas de la ejecución de los planes de contingencia deben incorporarse al informe final del proyecto para que la información pase a formar parte del proyecto y la base de conocimiento de riesgos empresariales.
Aprender
Aprender es la sexta estrategia de la administración del riesgo con MSF. Aprender nos va a fortalecer como equipo, el aprendizaje es continuo nos va a ir alertando de acciones a tomar para resolver con éxito cualquier evento que se nos presente. Debemos promover el aprendizaje fomentando un ambiente que motive a la gente a aprender, valorando su conocimiento adquirido, nuevas ideas y nuevas relaciones como aspectos vitales de la creatividad que eso conduce a la innovacion, de igual forma incluyendo y acentuando aprender en planes estrategicos.
Se centra en los siguientes objetivos fundamentales:
Trabajo en equipo, valorando el aprendizaje por experiencias y lecciones.
Los planes se construyen para aprender en las practicas de la administracion del riesgo del proyecto.
Los resultados de la administración del riesgo se evaluan para apoyar la innovacion y la mejora continua del aprendizaje.
Las experiencias y las mejores practicas se comparten.
MSF resalta especialmente:
Proporcionar control de calidad sobre las actividades actuales de gestión de riesgo para que el equipo puede obtener información periódica. La captura de las lecciones
aprendidas, especialmente alrededor de la identificación de riesgos y estrategias exitosas de mitigación, en beneficio de otros equipos, lo que contribuirá a la base de conocimiento sobre los riesgos.
ESTABLECIENDO CICLO DE
VIDA DEL PROYECTO CON
MSF
Con el ciclo de vida del proyecto buscamos establecer el orden en el cual se deben realizar las actividades. El modelo de proceso MSF, aplica una estrategia iterativa que suministra una imagen clara del estado del proyecto en cada etapa sucesiva. De esta manera el equipo puede identificar con mayor facilidad el impacto de cualquier cambio y administrarlo efectivamente.
Este modelo consiste en cinco fases distintas (Visión, Planificación, Desarrollo,
Estabilización e Implementación). Cada fase del proceso culmina con un hito visible, tal como se describe a continuación:
Vision
Obtener la visión y el alcance del proyecto, el cual debe estar compartido, comunicado, entendido y alineado con los objetivos del negocio. En esta fase el equipo y el cliente integran el proyecto y definen los requerimientos funcionales, sus alcances y
Entregables
Documento de Visión y Alcance Matriz de Identificación de riesgos
Planificación:
El equipo del proyecto creará un borrador del plan maestro del proyecto, además de la especificación funcional del proyecto y un cronograma que identifica puntos de control específicos. Esta fase culmina con el hito Plan del Proyecto (Especificaciones y Cronograma) aprobado.
Entregables:
Minuta de reunión de Kick-off del proyecto Documento de Especificaciones
Cronograma del proyecto (establecimiento de línea base)
Documentos de proceso de licitación aprobados (de acuerdo a la Norma Operativa vigente
Desarrollo:
Involucrar la serie de releases internos o entregas parciales del producto, desarrollados por partes para medir su progreso y para asegurarse que todos sus módulos o partes están sincronizados y pueden integrarse. La fase culmina con el hito Alcance completo.
Entregables:
Código fuente y ejecutables (resguardados y etiquetados en VSS) Actas de aceptación de entregas parciales Plan de Pruebas Manual de Instalación y Operación
Documento de Arquitectura
Actas de control de cambios aprobadas (que justifican el ajuste al alcance, tiempo y/o costo del proyecto, de existir)
Estabilización
Centrarnos en probar el producto. El proceso de prueba hace énfasis en el uso y el funcionamiento del producto en las condiciones del ambiente real. La fase culmina con el hito Aceptación de Pruebas.
Entregables:
Acta de Aceptación de Pruebas Acta de capacitación a usuarios y Mesa de Servicios
Acta de Entrega (comité de proyectos) Implantación
En esta fase el equipo implanta la tecnología y los componentes utilizados por la solución, apoya el funcionamiento y la transición del proyecto, y obtiene la aprobación final del cliente.
En ocasiones en esta fase se ejecutan planes piloto de implementación La fase termina con el hito Cierre de la Entrega.
Entregables:
Acta de Implantación
MSF PROCESS MODEL. FASE I
VISIÓN
La primera fase es definitivamente la piedra angular del proyecto, de esta depende su éxito o fracaso, es como cuando construimos una casa, sus bases, las columnas de la construcción son vitales para garantizar una obra de calidad.
En la fase de Visión debemos identificar en primer lugar el propósito del proyecto, ¿qué vamos a realizar?, tomando en cuenta los objetivos específicos, estos deben ser edibles, alcanzables, relevantes con un tiempo determinado. Continuamos estableciendo los entregables, como vamos a ir entregando y los criterios de aprobación del cliente.
En este mismo orden es importante resaltar los requerimientos que van ligados a la calidad en cuanto al resultado final y satisfacción del cliente, en otras palabras debemos buscar satisfacer necesidades, desde la percepción del usuario.
En esta fase tenemos la oportunidad de relacionarnos con los stakeholders (actores) conocido en MSF como los Miembros del Equipo, para validar la aceptación de la propuesta.
¿Cómo construir el documento de Visión y Alcance? El Problema
Es importante efectuar un levantamiento de información mediante la observación del proceso, las encuestas y entrevistas con las personas involucradas, las investigaciones previas sobre lo que estamos analizando, de forma tal que hagamos un análisis certero, preciso de la problemática actual.
Debemos detectar las necesidades actuales, para obtener tanto las ventajas y beneficios que nos daría poner en marcha el proyecto, como los objetivos que deberíamos alcanzar con la propuesta que vamos a desarrollar.
La oportunidad establece la motivación para iniciar el proyecto, las direcciones de por qué quiere hacerlo y lo que quieres hacer. Se centra en un nivel de negocio. Puede incluir información adicional pertinente, tales como datos de mercado, análisis de la competencia, de los usuarios.
Declaración de Visión
Definir el objetivo de la propuesta, debemos establecer los requerimientos que se deben cubrir con el diseño e implementación de nuestra solución, donde se le dé un enfoque general de lo que deseamos alcanzar. En resumen es indicar propósito y objetivos del proyecto.
Análisis de Beneficios
Es importante determinar la conveniencia de la ejecución del proyecto, mediante la enumeración y valoración posterior en términos monetarios de todos los costes y beneficios derivados directa e indirectamente de dicho proyecto.
Concepto de Solución
Metas: representa el destino, o el estado al que se quiere llegar por medio de la propuesta.
Objetivos: consisten en desglosar las metas en componentes, con el fin de obtener el verdadero nivel de detalles de los fines que se persiguen con las propuesta, y lo que se debe hacer para llegar a ellos.
Supuestos: son aquellos factores, que se pueden expresar como elementos que esperan validación por parte de un tercero.
Requerimientos
Requerimientos de Negocio:
Se debe especificar que debe hacer el sistema a desarrollar sin explicar cómo hacerlo. Requerimientos de Usuario:
Cuáles son las expectativas del usuario en cuanto a lo que desea alcanzar con la implementación del proyecto.
Alcance:
Debemos tener claros cuales son los límites del proyecto, hasta donde vamos a llegar con él, y si surgen nuevos requerimientos en medio de desarrollo del proyecto, teniendo claro este punto se convertirían enparte de un nuevo proyecto, una nueva versión que se debe negociar para desarrollar más adelante.
Estrategia de Entrega de Versiones.
Fijar claramente cómo vamos a ir entregando el proyecto, en fases, en tiempo, en alcance para cada fase.
Por último establecer los Criterios de Aceptación del cliente, cuando podemos decir, fase cerrada con éxito, como nos vamos a medir.
MSF PROCESS MODEL. FASE II
PLANIFICACIÓN
La segunda Fase que MSF nos presenta es la Planificación del Proyecto, donde el equipo trabaja en articular una imagen más clara de la solución planteada. Se desarrolla una planificación en base al objetivo del proyecto y la arquitectura de la solución plasmada en la primera fase Visión y Alcance. Esta planificación generara la lista de actividades que se deberán ejecutar, los recursos asociados (humanos, técnicos, entre otros), responsabilidades y los costos.
Con la planificación preparamos al proyecto para alcanzar el éxito, detectamos en forma temprana los riesgos, tomamos medidas para enfrentarlos buscando siempre la solución óptima.
de la solución generando un diseño lógico y un diseño físico.
Con el diseño inicial de la solución debemos validar los requerimientos en cuanto a plataforma tecnológica para divisar viabilidad del proyecto, si se detecta alguna
necesidad de actualización, compra o debilidad debe plasmarse en los requerimientos y plan de riesgos para hacer correctivos en el momento oportuno durante la ejecución del proyecto.
Tanto el diseño lógico como el diseño físico del proyecto desarrollado inicialmente se valida y depura con las necesidades detectadas con los usuarios funcionales, hay que considerar también las sugerencias aportadas por patrocinadores empresariales y el grupo de trabajo.
Creando el Plan Maestro del proyecto:
El equipo prepara las especificaciones funcionales, realiza el proceso de diseño de la solución, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto. Cada miembro del equipo aportara su enfoque a la
planificación.
Funciones y responsabilidades durante la fase de planificación
realizar una validación final de todos los procedimientos y estrategias de implementación antes de implementar el sistema en el entorno de producción completo. Este tipo de prueba se centra más en las estrategias de aprendizaje,
comunicaciones y soporte técnico que en estrategias tecnológicas reales, aunque estas también reciben validación. El proyecto piloto está vinculado a la producción porque, si todo va bien, las tecnologías y los componentes agregados para el programa piloto pasan a ser los componentes usados en la producción completa.
Los requisitos mínimos que debemos considerar a la hora de Planificar:
1. Un plan de implementación, donde evaluaremos los recursos requeridos para implementar la solución y los planes de contingencia.
2. Plan piloto para probar los procesos de backup y recuperación.
3. Plan de Compras y Servicios que incluyen consideraciones de hardware y software. 4. El plan de pruebas que describe la estrategia que el equipo utilizará para probar la solución. Se incluye los tipos específicos de pruebas que se utilizan, las áreas
específicas de la prueba, criterios de prueba de éxito, y la información sobre los recursos (tanto hardware como personas) necesarios para la actividad.
5. Plan de Adiestramiento para los diversos actores que estarán interactuando con la aplicación desde el punto de vista Administrador, Usuario Final, u otro.
6. Plan de comunicaciones para crear conciencia de los clientes y usuarios de lo que está sucediendo, lo que les ayudara a prepararse para responder adecuadamente ante la nueva implementación.
7. El plan de capacidad para evaluar la capacidad de crecimiento, escalabilidad y performance de la aplicación con la plataforma que se tiene en la organización.
Importante:
Considerar el plan de pruebas. Al preparar el plan de pruebas, los miembros del grupo de trabajo de pruebas deben tener en cuenta varios aspectos del proceso de
implementación, entre los que se incluyen:
Los tipos de pruebas que son necesarios para las diferentes etapas de la
implementación de la solución y, específicamente, las responsabilidades del grupo de trabajo de pruebas en cada tipo de prueba.
La estrategia usada para la prueba en cada tipo de prueba.
Las distintas funciones de equipo para los miembros del grupo de trabajo de pruebas. Las actividades de requisitos previos necesarias para cada miembro del equipo.
Tipos de pruebas
La preparación de complejas soluciones tecnológicas implica varios tipos de pruebas.
Cada tipo tiene sus propios requisitos y estrategia de prueba. La solución se va perfeccionando conforme se avanza de un tipo de prueba a otro, hasta que se ha probado por completo y está lista para su introducción en el entorno de producción. Prueba de unidad. El primer tipo de prueba se centra en el análisis de un solo componente de la solución. Cuando se preparan para crear la solución general, los miembros del equipo de cada grupo de trabajo empiezan a analizar los componentes de los que son responsables. En este momento, a menudo instalan estos componentes en entornos aislados para validar las capacidades de los componentes.
Prueba funcional. Después que los equipos individuales se han familiarizado con los componentes tecnológicos de los que son responsables, pasan a la prueba funcional: la validación de que los productos y los componentes funcionan de la manera diseñada. La orientación para este tipo de prueba se deriva de las especificaciones funcionales del proyecto general.
Prueba de integración.
El siguiente tipo de prueba integra cada uno de los distintos componentes que componen la solución como un todo coherente. Esta prueba se lleva a cabo en el laboratorio de integración o de pruebas y está al cargo del propio grupo de trabajo de pruebas.
Prueba de ensayo.
La prueba de operación provisional o de ensayo es un tipo de prueba opcional que ofrece una validación final para los procedimientos usados en la implementación de la solución.
Aunque es posible que haya un margen de error en los tipos de pruebas anteriores, aquí no debe haber ninguno. Cuando se agrega una solución al entorno de producción, debe estar completamente libre de errores para garantizar su longevidad y su
compatibilidad a largo plazo.
MSF PROCESS MODEL. FASEIII
DESARROLLO
En la fase de planificación se define las funcionalidades de la aplicación y se plasma una propuesta con un orden incremental de desarrollo; esto debe contemplar desde lo más básico hasta los procesos más complejos.
It also verifies solution concepts from the designs within a live environment close to that of a production environment, and develops a testing infrastructure in which test cases are created.
Esta fase se hacen entregas parciales del producto, desarrollados por partes para medir su progreso y para asegurarse que todos sus módulos o partes están sincronizados y pueden integrarse. La fase culmina con el hito
Alcance completo.
Los Entregables para esta fase son:
Código fuente y ejecutables (resguardados y etiquetados en VSS) Actas de aceptación de entregas parciales
Plan de Pruebas
Manual de Instalación y Operación Documento de Arquitectura
Actas de control de cambios aprobadas (que justifican el ajuste al alcance, tiempo y/o costo del proyecto, de existir)
Una solución con éxito requiere del desarrollo de la infraestructura que requiere, el código de la aplicación, la documentación que se genera para los usuarios, y los resultados de las pruebas que se han ejecutado sobre cada funcionalidad.
Ejemplo de un Plan de Desarrollo tomado de un Proyecto de la Empresa donde laboro. Resumen
El presente documento establece los estándares de desarrollo propuestos por Noixno los cuales garantizan el empleo de las mejores prácticas de diseño y desarrollo, también se menciona brevemente las herramientas que intervienen en esta fase del proyecto junto con su debida justificación.
Objetivos de Desarrollo
Se desea tener una comunicación directa, en tiempo real con el servidor de la empresa TDAT, por parte del personal dedicado a la supervisión de ventas, haciendo uso de recepción y transmisión de datos por parte de la empresa OTROPROVEEDOR. El uso de éste mecanismo lo justifica el hecho de la necesidad de sólo acceder a un sector de la data almacenada en el servidor de la empresa TDAT, por ello la
incorporación de un sistema basado en un repositorio SQL Server 2005, por medio del uso del servicio web TDAT_XMLMobil.
1. Desarrollar modulo de administración y control de eventos ocurridos en las transacciones de datos
2. Proporcionar interfaz de control, agenda de transacciones, administración de usuarios y roles del sistema.
3. Crear procesos de extracción, consumo, e inserción de datos transaccionales 4. Proveer modulo de administración de respaldos.
Estrategia General de Entrega
Se utilizará un modelo de publicación incremental, es decir, se irán cargando en un directorio estándar, todas aquellas versiones que ya hayan sido probadas y validadas por parte de TDAT, tomando en cuenta que se hará una revisión previa por cada entregable que sea terminado.
evaluación puede ser un tope mínimo, o un promedio que se debe satisfacer para que la solución entregada pueda pasar al entorno productivo. (Extraído del documento de Visión/Alcance).
Puntos Claves del diseño
En esta sección se identifican las metas claves en el diseño de la aplicación y su prioridad.
1. Organizar la propuesta de desarrollo bajo el modelo SOA (Service Oriented Arquitecture).
2. Desarrollar capa de datos basada en stored procedures.
3. Crear modulo de extracción de datos de los repositorios Radar y Datamart haciendo uso de vistas indexadas.
4. Establecimiento de XML como estándar abierto de comunicación el cual permite a los servicios una comunicación neutral, independientemente de la plataforma de hardware, del sistema operativo y del lenguaje de programación en los que se implemente el servicio..
Entorno de desarrollo
En esta sección se ilustran los componentes que conforman la solución, los proyectos que serán implementados, y las herramientas con las cuales serán desarrollados.
Capa de Presentación: se creará un proyecto de tipo Aplicación Web Asp.Net, el nombre del mismo será XML_Mobil.Core.Interface, el lenguaje de programación será Visual C# 2.0
Capa de Servicios: será implementada con un proyecto de tipo Class Library, con Visual C# 2.0, esta es la encargada de servir de puente entre la capa de datos y la capa de presentación, el proyecto a cargo de llevarla a cabo será XML_Mobil.Core.EntityService.
Capa de Servicios (Entidades):
al igual que los servicios, la implementación consistirá en un proyecto de tipo Class Library con Visual C# 2.0, entendiéndose por entidad, una clase que represente una tabla de la base de datos, publicando cada uno de los campos por medio de
propiedades.
Capa de Datos: el motor de base de datos donde residirá la data manejada por el repositorio propuesto será SQL Server 2005 Enterprise Edition, y las consultas serán implementadas por medio de procedimientos almacenados.
Con respecto a las herramientas que implementarán los proyectos mencionados, por el lado del desarrollo se utilizará Visual Studio 2005 Professional Edition, y para
adminstrar todo lo correspondiente a SQL Server 2005, la herramienta será SQL Server Management Studio.
Guías y Estándares
En esta sección se proveen los estándares que Noixno, propone para llevar a cabo el desarrollo del proyecto, en primer lugar se encuentra la sección de nombramiento, es ahí donde se especifican los nombres que se deben asignar a las clases y a los objetos, luego aparece la sección de codificación, que es donde se muestran los nombres que se le deben proveer a los métodos, propiedades, enumeraciones y otros objetos.
Para objetos de base de datos: Stored Procedures:
sp_operacion_tabla, ejemplo:
sp_insercion_estvisitas.
Tablas: no aplica, porque se mantendrá el diccionario de datos que ha entregado TDAT.
Vistas: no aplica, porque se mantendrá el diccionario de datos que ha entregado TDAT
Triggers:
trg_operacion_tabla, ejemplo:
trg_actualizacion_estvis ita
Codificación
Para objetos de código:
Clases: se nombraran de acuerdo al propósito para el cual estén creadas, por ejemplo, si representan una tabla, llevarán el mismo nombre de la tabla (ejemplo: CTR_TRA). Objetos: se nombraran con m_ seguido del nombre de la clase al cual pertenezcan, ejemplo, si la clase se llama Prueba, el objeto será m_Prueba. Si para nombrar un objeto adecuadamente se necesitan dos o más palabras, se recomienda utilizar la primera letra de la primera palabra en minúscula al igual que el resto, seguido de la primera letra de la segunda palabra en mayúscula, y así sucesivamente, por ejemplo, envioCorreoElectronico.
Métodos: su nombre debe comenzar con letra mayúscula y deben ser expresados en verbos infinitivos en la medida de lo posible, ya que estos implementan una acción, por ejemplo:
InsertarRegistro( parámetros )
Parámetros: se nombran con el prefijo p_ seguido del nombre, por ejemplo si un parámetro es FEC_TRN, será declarado en el método como p_FEC_TRN
Elementos de Formulario: en este caso, es necesario basarse en prefijos, los elementos más comunes son:
Text Box: txtNombre Botón: btnNombre
Radio Button: rbtNombre, Radio Button List: rblNombre Check Box: chkNombre, Check Box List:chlNombre Drop DownList:ddlNombre Grid Views: grvNombre
Versionamiento y control de fuentes
Actualmente no se cuenta con un software controlador de versiones sin embargo, es conveniente resaltar lo que ya se ha escrito en el documento de estructura del proyecto, y es lo siguiente:
Para diferenciar las versiones entregadas a lo largo del desarrollo, se propone utilizar un estándar de nombramiento, que lleve consigo, el nombre del proyecto, seguido del número de la versión y la fecha de entrega, un ejemplo de este puede ser:
TDAT_XMLMobil v1 26-02-2010.”
Proceso diario de Compilación
Esta especificación provee las reglas de publicación, no de fuentes sino de releases, es decir, archivos ejecutables, y la única restricción que se asume, es el hecho de no subir a la carpeta compartida en el servidor archivos que no estén completamente operativos, y validados por TDAT
Orden de entrega
Esta sección provee las fechas estimadas para las cuales se plantea entregar los componentes que conforman la aplicación a desarrollar.
Componentes
Descripción de Componentes
1. Diseño Arquitectónico: esto simplemente es representar con elementos de software la arquitectura ilustrada en el documento de Visión/Alcance y Estructura del Proyecto. 2. Desarrollo: En esta sección simplemente se nombran los proyectos que conforman la solución, integrando todas las capas:
1. Capa de Presentación: XMLMobil.Core.Interface (ASP.Net 2.0) 2. Capa de Servicios:
1. XMLMobil.Core.Entities (Class Library) 2. XMLMobil.Core.EntityService (ClassLibrary) 1. Capa de Datos:
1. XMLMobil.Core.DataLoad (Sql Server Views) 2. XMLMobil.Core.Query (Sql Scripts Project)
Ajustes: La Herramienta de pruebas a utilizar es Visual Studio Team Suite, pero los ajustes necesarios deberán hacerse con las herramientas que hayan sido asignadas a un determinado componente en el desarrollo original.
Reporte de Cierre y Análisis Post-Proyecto: Este componente forma parte de la documentación, y únicamente expresa el estado en el que se deja el sistema
desarrollado al momento de entregarse, y el Análisis Post-Proyecto, es un conjunto de experiencias vividas a lo largo del desarrollo que se deben guardar a manera de documento, para que las mismas sirvan de guía en futuros desarrollos, relacionados con el repositorio propuesto para la aplicación, o con un proyecto vinculado a operaciones de intercambio de datos XML.
Adquisición de Componentes y desarrollo
No aplica, TDAT Centro cuenta con la infraestructura, y el software necesario para llevar a cabo el desarrollo de la nueva propuesta.
Calidad de Componentes Desarrollados
Este tópico consiste en dar una definición del método utilizado para evaluar la calidad del software, sin embargo, es conveniente acotar que implícitamente este trabajo se cumple por medio de los umbrales de aceptación, y dichos umbrales son los
siguientes:
El valor mínimo para asignar a la evaluación de un entregable es cero (0) puntos. El valor máximo para asignar a la evaluación de un entregable es diez (10) puntos. El tope mínimo de aceptación de un entregable es ocho (8) puntos.
