Este sitio hace Parte de INETA.org MSF , metodología aplicada ]
...Sin Metodología no hay software de calidad ...                                                          Madrid (España) / 15-08-2k3

 

 

 

Microsoft Solution Framewrok

A continuación se describen los pasos que debería cumplir un proyecto según la metodología de desarrollo de proyectos de  MSF

 

Ejemplo de metodología MSF aplicada

 

Como ejemplo de una aplicación de metodología MSF a un proyecto, 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 carga de trabajo en términos de jornadas, número de personas implicadas y perfil de las mismas. El proyecto ejemplo se 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ían 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 número de agentes implicados en el proyecto. En este documento quedarán 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: generalmente se definen como áreas principales la de Diseño de Arquitectura, Pruebas de Laboratorio, Documentación, Logística y Coordinación.

  • Elaboración del Plan de Trabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. Los mecanismos y protocolos de intercambio de información y coordinación deben quedar suficientemente bien establecidos y consensuados.

  • Elaboración de la matriz de Riesgos y Plan de Contingencia: los principales riesgos detectados deben tener un plan de mitigación y actuación y revisarse con periodicidad.

Para un proyecto de migración a Windows 2000 podría estimarse que los trabajos indicados pueden requerir en torno a 20 jornadas de trabajo y la intervención de un Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner.

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, donde se describen en detalle 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. Si en el curso de las fases sucesivas fuera necesario revisar estos contenidos, se deberá hacer por acuerdo y conocimiento de todo el equipo de trabajo y se llevará un registro de versiones que permita hacer un seguimiento adecuado de estas revisiones.
  • Documento de Plan de Laboratorio - Prueba de Concepto: la descripción del contenido del 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 documento. Es un documento dinámico, en el que se recoge la idea y la experiencia práctica al llevarla a cabo en entorno controlado y aislado. La etapa de prueba de laboratorio concluye cuando la maqueta ofrece todos los servicios y funciones descritos en el Documento de Alcance y Estrategia, y su grado de estabilidad y rendimiento es considerado como "suficiente".

Habitualmente, en las propuestas de preventa no se pueden indicar con precisión parámetros como el esfuerzo técnico, tiempo o coste definitivo que puede suponer esta fase. De otras experiencias anteriores se puede obtener una relación de trabajos sólo a título orientativo, y que debe ser revisado y acordado por todas las partes:

Fase Jornadas Personas (mínimo) Contenido Documento
Servicios Básicos de Red, diseño de sites y Active Directory

10

El Partner: 2 El cliente: 1 Instalación de la plataforma Windows 2000 Definición de parámetros y puesta en servicio de SBR: Active Directory, DHCP y DDNS Documento de instalación de Windows 2000 y Servicios Básicos de Red
Seguridad y Accesos

10

El Partner: 2 El cliente: 2 Definición de grupos de usuarios. Nomenclatura Modelo de seguridad de acceso. Pruebas con MSCHAP, Kerberós y Smart Card (si está disponible). Documento de definición del método de validación y seguridad lógica.
Administración

15

El Partner: 2 El cliente: 1 Definición de las tareas administrativas relevantes: mantenimiento de usuarios y grupos, copia de seguridad, uso de auditoría, recuperación de máquinas, reinstalación de software, etcDefinición de perfiles y políticas de usuario y grupo Documento guía de administración.Documento Plan de Contingencias (Disaster & Recovery Plan)
Servicios y aplicaciones corporativas

10

El Partner: 2 El cliente: 2 Instalación de servicios y aplicaciones corporativas en la nueva plataforma y procedimientos para conseguirlo: Configuración de recursos compartidos (File & Print)Distribución de Software Documento de migración e implantación de aplicaciones y servicios corporativos (estrategia e implantacion)
Alta Disponibilidad y tolerancia a fallos

10

El Partner: 2 El cliente: 1 Escenarios de operación 24x7 y balanceo de carga con Windows 2000 AS. Documento de pruebas de Alta Disponibilidad
Conectividad y modalidades de acceso remoto

5

El Partner: 2 El cliente: 1 Configuración de la DMZ, firewalls, proxys y medios físicos de acceso Documento de configuración de la Infraestructura de Acceso Remoto
Windows Terminal Server

5

El Partner: 2 El cliente: 2 Instalación y configuración de Terminal Server. Configuración del perfil de acceso administrativo y aplicaciones Documento de Instalación, configuración y escenarios de uso de W2000TS.
Servicios web y provisión de contenidos por la red

5

El Partner: 2 El cliente: 2 Instalación y configuración de IIS5.0 para provisión de servicios on-line de Intranet (formación, documentación, etc) Documento de implantación y servicios de Intranet
Escalabilidad

5

El Partner: 2 El cliente: 2 Definición de los escenarios de crecimiento de la nueva arquitectura descrita y requerimientos de infraestructura, administración y seguridad Documento de pruebas de escalabilidad

El cómputo de jornadas para la relación de actividades descritas (que como se observa sólo recogen las relativas a la Planificación y Diseño, y deja aparte las necesarias para elaborar el plan de Migración), ofrecería este resultado:
Jornadas totales: 80 (aprox. 4 meses)
Jornadas / técnico del PARTNER: 150 jornadas (2 personas)
Jornadas / técnico del CLIENTE: 110 jornadas (max. 2 personas)

Fase 3 - Estabilización

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

  • Selección del entorno de prueba piloto: se acordará la composición y ubicación del conjunto de máquinas y usuarios que entrarán en la prueba. Esta selección se recomienda que se haga atendiendo a la mayor variedad posible de casos, de manera que puedan aflorar el máximo de incidentes potenciales en el menor tiempo posible. La dimensión de la muestra tiene también que calcularse, sin perder de vista que la prueba piloto no es el despliegue propiamente, sino una fase de observación en la que es absolutamente crítico establecer unos cauces efectivos de tratamiento de los errores.
  • Gestión de Incidencias: aunque esta labor se habrá iniciado en la fase anterior, el éxito de la prueba piloto dependerá de que se forme un sistema de recogida de incidentes (helpdesk o similar), de atención al usuario (formación, consultas) y de resolución de problemas y documentación de los mismos (versionado de la plataforma).
  • 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, supone el principal documento del Proyecto y la culminación de los trabajos de diseño, al menos en sus líneas principales. Este documento se considerará definitivo cuando la solución puesta en marcha se muestre estable y el número de incidencias graves (de intervención o de resolución) sea nulo y la cantidad de las consideradas leves quede por debajo de un límite establecido en las Métricas de Calidad.
  • 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 debe consensuar la fecha de finalización de la fase Piloto, y las condiciones de calidad que debe cumplir la solución final para inciiar el despliegue. En el Plan deben identificarse las fases, estrategia de implantación, fechas, tareas a realizar, procedimientos de validación y método de control de incidencias.
  • Elaboración del Plan de Formación: con anterioridad al despliegue definitivo, debe haberse aprobado el Plan de Formación orientado a usuarios finales y administradores, y debe hacerse compatible con los ritmos acordados en el Plan de Despliegue.

El tiempo necesario para abordar esta fase es variable y depende en parte de factores ajenos a la complejidad de la propia solución, como es la adecuada selección del entorno de prueba y el momento del año en que tenga lugar (evitando que coincida con periodos de vacaciones o puntas de trabajo críticas como Fin de Año). En proyectos de similar envergadura se ha llegado al momento "Error Free Version" en 30 jornadas de trabajo (aproximadamente mes y medio) con una muestra de 50 usuarios.

Fase 4 - Despliegue

Se llevarán 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 (implantación de la plataforma, puesta en servicio de todas las funciones, formación a los usuarios y administradores), los siguientes:

  • Continuación con las labores de recepción de incidencias, clasificación, tratamiento, resolución y distribución de fixes 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 (nuevas versiones o Service Packs, por ejemplo)
  • 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 "deliverables" en la fase de Vision Scope.
  • Revisión (si procede) de la matriz de riesgos, las métricas de calidad y establecimiento de los estándares de calidad y SLA definitivos.
  • Finalmente, entrega del Proyecto y cierre del mismo, con o sin apertura de nuevo proyecto en base a la información y experiencia obtenidos.

La duración fase de despliegue, puesto que debe planificarse, no puede establecerse a priori. Depende de numerosos factores externos al propio proyecto (incluyendo factores de oportunidad política o de negocio) que pueden retardar o acelerar la conclusión.

La experiencia demuestra que no hay una relación directa entre número de máquinas y tiempo necesario para el despliegue. Los factores más relevantes en el cálculo suelen ser la dispersión o concentración geográfica, la complejidad del proceso de migración, el grado de automatización alcanzado, la experiencia y nivel de los técnicos que realizan la operación y condicionantes de calendario, a menudo con restricciones no técnicas, sino de otros tipos (las fechas-objetivo suelen marcarse por criterios de oportunidad de negocio).