MICROSOFT SOLUTIONS FRAMEWORK

MICROSOFT SOLUTIONS FRAMEWORK 3.0

Este modelo se basa principalmente en los modelos espiral y cascada. El objetivo de MSF 3.0 es crear un modelo estructurado basado en una estructura de trabajo en desarrollo de software.

Tiene como principios fundamentales:

·         La comunicación entre clientes y usuarios y entre el equipo de trabajo.

·         La capacitación de personas, es decir que cumple con el proceso de formación de personal.

·         Es un trabajo versionado, es decir que se deben crear versiones para el negocio de cada cliente.

·         Establecer responsabilidades claras y compartidas

·         Focalizarse en agregar valor al negocio

·         Permanecer ágil y esperar los cambios.

·         Inversión en la calidad.

·         Aprender de todas las experiencias.

MSF se compone de 2 modelos y 3 disciplinas:

Modelo de Equipo

Modelo de Proceso

Disciplina de administración de proyecto

Disciplina  administración de riesgos

Disciplina administración de la preparación

MICROSOFT SOLUTIONS FRAMEWORK 4.0 (cambios)

MSF 4.0 aparte de los principios fundamentales de MSF 3.0 presenta otros 2:

Una vinculación muy estrecha con los clientes.

Que todos los productos sean entregables.

Utiliza frameworks descriptivos, similares a MSF 3.0, con la diferencia de que incluye dos metodologías:

MSF para el desarrollo de metodologías agiles

MSF para el proceso de mejora CMM

Al igual que MSF 3.0 se define un equipo de trabajo, pero la gran ventaja es que aumenta ala agilidad. 

VENTAJAS

o   Como es un modelo que esta completamente desarrollado en Microsoft se tiene mayor soporte y mantenimiento por parte de la empresa.

o   Por se Microsoft los usuarios finales ya están familiarizados con el producto.

o   Es utilizado para grandes y pequeños proyectos

o   Gran disciplina en el manejo de riesgos.

o   Incentiva el trabajo de equipo y la colaboración.

o   Este modelo cuenta con plantillas que nos ayudan con la documentación

o   MSF es menos abultado que RUP.

DESVENTAJAS

o   Hay que hacer mucha documentación por cada fase. Todo lo que se haga debe de estar muy bien documentado.

o   El análisis de riesgos es necesario, pero si se hace muy largo, este puede demorar o frenar el avance del proyecto.

o   Al ser desarrollado por Microsoft obliga a usar todas las herramientas desarrollados por ellos.

o   Al ser privativo se necesita de licencia

A continuación unos diagramas de los modelos que utiliza MSF.

  

MODELO DE PROCESO PARA EL DESARROLLO DE APLICACIONES:

MODELO DE EQUIPOS

       

EJEMPLO DE LA UTILIZACION DE MICROSOFT SOLUTION FRAMEWORK

A continuación se describe el contenido de cada una de las fases y, en la medida de lo posible un detalle, de acciones concretas y estimación de la carga de trabajo en términos de jornadas, número de personas implicadas, y perfil de las mismas. El proyecto ejemplo de trata de una implantación de infraestructuras, en concreto, migración a Windows 2000 de una red de servidores.

FASE 1 –Estrategia y alcance

En esta fase debería tener lugar los siguientes trabajos:

§  Elaboración y aprobación del documento de alcance y estrategia definitivo: debe ser un documento de consenso con la participación del mayor numero de agentes implicados en el proyecto.  En este documento quedaran definitivamente reflejadas las funcionalidades y servicios que, ineludiblemente, debe ofrecer la solución a implantar.

§  Formación del Equipo de trabajo y distribución de competencias y responsabilidades.

§  Elaboración del plan de trabajo: deben marcarse fechas y contenidos para esta fase y las siguientes.

§  Elaboración de la matriz de Riesgos y plan de contingencia: Identificar los principales riesgos detectados y estos deben de tener un plan de mitigación y actuación y revisarse con periodicidad.

FASE 2 –Planificación y Prueba de concepto

Deben alcanzarse los siguientes objetivos e hitos:

§  Documento de planificación y diseño de arquitectura: Es el documento principal, en donde se describen detalles de los aspectos funcionales y operativos de la nueva plataforma. La aprobación de este documento es el hito principal de esta fase, y supone la directriz última de todos los trabajos técnicos, que a partir de ese momento deben ser consistentes con esta guía.

§  Documento de Plan de Laboratorio –Prueba de concepto: La descripción del contenido de laboratorio de prueba de concepto, los diversos escenarios a simular, los criterios de validez, el control de incidencias y las métricas de calidad son objetivos a cubrir en este momento.

FASE 3 Estabilización

La solución implantada en la maqueta se pasa a un entorno real de explotación, restringido en numero de usuarios y condiciones tales que se pueda llevar un control efectivo de la situación. Los hitos y objetivos fundamentales en esta fase son:

§  Selección del entorno de prueba piloto: Se acordara la composición y ubicación del conjunto de maquinas y usuarios que entraran en la prueba. Esta selección se recomienda que se haga atendiendo a la mayor variedad posible de casos, de manera que pueda aflorar el máximo de incidentes potenciales en el menor tiempo posible.

§  Gestión de Incidencias: aunque esta labor se habrá iniciado en la fase anterior, el éxito de prueba piloto dependerá de que se forme un sistema de recogida de incidentes, de atención al usuario y de resolución de problemas y documentación de los mismos.

§  Revisión de la documentación final de Arquitectura: El documento de planificación y Diseño de Arquitectura se puede ver alterado parcialmente como resultado de esta fase. El documento final, aprobado por consenso, se supone el principal documento del proyecto y la culminación de los trabajos de diseño, al menos en sus líneas principales.

§  Elaboración de la documentación de Formación y Operaciones: Con vistas al soporte post proyecto y los programas de formación a usuarios y administradores, en esta fase deben elaborarse las guías de usuario, de administración, las “paso-a-paso”, y otros cuyos contenidos deben acordarse previamente

§  Elaboración del Plan de despliegue: Se deben consensuar la fecha de finalización de la fase piloto, y las condiciones de la calidad que debe cumplir la solución final para iniciar el despliegue.

§  Elaboración del plan de formación: Con anterioridad al despliegue definitivo, debe haberse aprobado el plan de formación orientado a los usuarios finales y administradores,  y debe hacerse compatible con los ritmos acordados en el plan de despliegue.

FASE 4 –Despliegue

Se llevaran a cabo en esta fase los planes diseñados en la anterior, principalmente el de despliegue y el de formación. Los principales trabajos e hitos a conseguir son, en este caso, además de los obvios los siguientes:

§  Continuación con las labores de recepción de incidencias, clasificación, tratamiento, resolución, distribución de faxes o intervención on-site

§  Registro de mejoras y sugerencias, funcionalidades no cubiertas y novedades a incorporar en sucesivas versiones de la plataforma incluyendo mejoras aportadas por los fabricantes de software.

§  Revisión de las guías y manuales de usuario, rectificación de errores y obtención de los documentos de formación definitivos.

§  Entrega de los documentos definitivos acordados como “deliverales” en la fase de Visión Scope.

§  Revisión de la matriz de riesgos, las métricas de calidad y establecimiento de los estándares de calidad y SLA definitivos.

§  Finalmente la entrega del proyecto y cierre del mismo, con o sin apertura e nuevo proyecto en base a la información y experiencia obtenidas.