MICROSOFT SOLUTION FRAMEWORK (MSF) El desarrollo de software no es una tarea fcil.

Prueba de ello, es que existen numerosas propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte, aquellas propuestas ms tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarn. Estas propuestas han demostrado ser efectivas y necesarias en un gran nmero de proyectos, pero tambin han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo ms actividades, ms artefactos y ms restricciones, basndose en los puntos dbiles detectados. Sin embargo, el resultado final sera un proceso de desarrollo ms complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. MSF es un compendio de las mejores prcticas en cuanto a administracin de proyectos se refiere. Ms que una metodologa rgida de administracin de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnologa de informacin. Todo proyecto es separado en 5 principales fases: Visin y Alcances. Planificacin. Desarrollo. Estabilizacin. Implantacin.

FIGURA 2.

MODELO DE EQUIPO DE MSF

Visin y Alcances: La fase de visin y alcances trata uno de los requisitos ms fundamentales para el xito del proyecto, la unificacin del equipo detrs de una visin comn. El equipo debe tener una visin clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en trminos que motivarn a todo el equipo y al cliente. Se definen los lderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas ltimas se deben respetar durante la ejecucin del proyecto en su totalidad, y se realiza la evaluacin inicial de riesgos del proyecto. Planificacin: Es en esta fase es cuando la mayor parte de la planeacin para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseo de la solucin, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto. Desarrollo: Durante esta fase se realice la mayor parte de la construccin de los componentes (tanto documentacin como cdigo), sin embargo, se puede realizar algn trabajo de desarrollo durante la etapa de estabilizacin en respuesta a los resultados de las pruebas. La infraestructura tambin es desarrollada durante esta fase. Estabilizacin: En esta fase se conducen pruebas sobre la solucin, las pruebas de esta etapa enfatizan el uso y operacin bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solucin para el lanzamiento. Implantacin: Durante esta fase el equipo implanta la tecnologa base y los componentes relacionados, estabiliza la instalacin, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobacin final del cliente. Modelo de roles El modelo de equipos de MSF (MSF team model) fue desarrollado para compensar algunas de las desventajas impuestas por las estructuras jerrquicas de los equipos en los proyectos tradicionales. Los equipos organizados bajo este modelo son pequeos y multidisciplinarios, en los cuales los miembros comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que estn desarrollando. Comparten una visin comn del proyecto y se enfocan en implementar la solucin, con altos estndares de calidad y deseos de aprender. 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 ms personas, la estructura circular del modelo, con valos del mismo tamao para todos los roles, muestra que no es un

modelo jerrquico 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 comunicacin se pone en el centro del crculo para mostrar que est integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicacin efectiva y es esencial para el funcionamiento del mismo.

Ejemplo de metodologa MSF aplicada Como ejemplo de una aplicacin de metodologa MSF a un proyecto en Factor xito Publicidad C.A, a continuacin se describe el contenido de cada una de las fases y, en la medida de lo posible, un detalle de acciones concretas y estimacin de carga de trabajo en trminos de jornadas, nmero de personas implicadas y perfil de las mismas. El proyecto ejemplo se trata de una implantacin de infraestructuras, en concreto, migracin a Windows 2000 de una red de servidores. Fase 1 - Estrategia y alcance: En esta fase deberan tener lugar los siguientes trabajos: Elaboracin y aprobacin del Documento de Alcance y Estrategia definitivo: debe ser un documento de consenso con la participacin del mayor nmero de agentes implicados en el proyecto. En este documento quedarn definitivamente reflejadas las funcionalidades y servicios que, ineludiblemente, debe ofrecer la solucin a implantar. Formacin del Equipo de Trabajo y distribucin de competencias y responsabilidades: generalmente se definen como reas principales la de Diseo de Arquitectura, Pruebas de Laboratorio, Documentacin, Logstica y Coordinacin. Elaboracin del Plan de Trabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. Los mecanismos y protocolos de intercambio de informacin y coordinacin deben quedar suficientemente bien establecidos y consensuados. Elaboracin de la matriz de Riesgos y Plan de Contingencia: los principales riesgos detectados deben tener un plan de mitigacin y actuacin y revisarse con periodicidad.

Para un proyecto de migracin a Windows 2000 podra estimarse que los trabajos indicados pueden requerir en torno a 20 jornadas de trabajo y la intervencin de un Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner.

Fase 2 - Planificacin y Prueba de Concepto: Documento de Planificacin y Diseo de Arquitectura: es el documento principal, donde se describen en detalle los aspectos funcionales y operativos de la nueva plataforma. La aprobacin de este documento es el hito principal de esta fase, y supone la directriz ltima de todos los trabajos tcnicos, que, a partir de ese momento, deben ser consistentes con esta Gua. 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 descripcin del contenido del laboratorio de prueba de concepto, los diversos escenarios a simular, los criterios de validez, el control de incidencias y las mtricas de calidad son objetivos a cubrir en este documento. Es un documento dinmico, en el que se recoge la idea y la experiencia prctica 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 precisin parmetros como el esfuerzo tcnico, tiempo o coste definitivo que puede suponer esta fase. De otras experiencias anteriores se puede obtener una relacin de trabajos slo a ttulo orientativo, y que debe ser revisado y acordado por todas las partes: Fase 3 Estabilizacin: La solucin implantada en la maqueta se pasa a un entorno real de explotacin, restringido en nmero de usuarios y en condiciones tales que se pueda llevar un control efectivo de la situacin. Los objetivos fundamentales de esta fase son: Seleccin del entorno de prueba piloto: se acordar la composicin y ubicacin del conjunto de mquinas y usuarios que entrarn en la prueba. Esta seleccin se recomienda que se haga atendiendo a la mayor variedad posible de casos, de manera que puedan aflorar el mximo de incidentes potenciales en el menor tiempo posible. La dimensin de la muestra tiene tambin que calcularse, sin perder de vista que la prueba piloto no es el despliegue propiamente, sino una fase de observacin en la que es absolutamente crtico establecer unos cauces efectivos de tratamiento de los errores. Gestin 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 atencin al usuario (formacin, consultas) y de resolucin de problemas y documentacin de los mismos (versionado de la plataforma). Revisin de la documentacin final de Arquitectura: el documento de Planificacin y Diseo 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 culminacin de los trabajos de diseo, al menos en sus lneas principales. Este documento se considerar definitivo cuando la solucin puesta en marcha se muestre estable y el nmero de incidencias graves (de intervencin o de resolucin) sea nulo y la cantidad de las consideradas leves quede por debajo de un lmite establecido en las Mtricas de Calidad. Elaboracin de la documentacin de Formacin y Operaciones: con vistas al soporte post proyecto y los programas de formacin a usuarios y administradores, en esta fase deben elaborarse las Guas de Usuario, de Administracin, las paso-a-paso, y otros cuyos contenidos deben acordarse previamente. Elaboracin del Plan de Despliegue: se debe consensuar la fecha de finalizacin de la fase Piloto, y las condiciones de calidad que debe cumplir la solucin final para iniciar el despliegue. En el Plan deben identificarse las fases, estrategia de implantacin, fechas, tareas a realizar, procedimientos de validacin y mtodo de control de incidencias. Elaboracin del Plan de Formacin: con anterioridad al despliegue definitivo, debe haberse aprobado el Plan de Formacin 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 solucin, como es la adecuada seleccin del entorno de prueba y el momento del ao en que tenga lugar (evitando que coincida con periodos de vacaciones o puntas de trabajo crticas como Fin de Ao). Fase 4 Despliegue: Se llevarn a cabo en esta fase los planes diseados en la anterior, principalmente el de despliegue y el de formacin. Los principales trabajos e hitos a conseguir son, en este caso, adems de los obvios (implantacin de la plataforma, puesta en servicio de todas las funciones, formacin a los usuarios y administradores), los siguientes: Continuacin con las labores de recepcin de incidencias, clasificacin, tratamiento, resolucin y distribucin de faxes o intervencin 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). Revisin de las Guas y manuales de usuario, rectificacin de errores y obtencin de los documentos de formacin definitivos.

Entrega de los documentos definitivos acordados como "deliverables" en la fase de Visin Scope. Revisin de la matriz de riesgos, las mtricas de calidad y establecimiento de los estndares de calidad y SLA definitivos. Finalmente, entrega del Proyecto y cierre del mismo, con o sin apertura de nuevo proyecto en base a la informacin y experiencia obtenidas.

La duracin fase de despliegue, puesto que debe planificarse, no puede establecerse a priori. Depende de numerosos factores externos al propio proyecto (incluyendo factores de oportunidad poltica o de negocio) que pueden retardar o acelerar la conclusin. Los factores ms relevantes en el clculo suelen ser la dispersin o concentracin geogrfica, la complejidad del proceso de migracin, el grado de automatizacin alcanzado, la experiencia y nivel de los tcnicos que realizan la operacin y condicionantes de calendario, a menudo con restricciones no tcnicas, sino de otros tipos (las fechas-objetivo suelen marcarse por criterios de oportunidad de negocio). Los mtodos giles, nacen como respuesta a los problemas detallados anteriormente y se basa en dos aspectos puntuales, el retrasar las decisiones y la planificacin adaptativa; permitiendo potencia an ms el desarrollo de software a gran escala. Como resultado de esta nueva teora se crea un Manifiesto gil cuyas principales ideas son: Los individuos y las interacciones entre ellos son ms importantes que las herramientas y los procesos empleados. Es ms importante crear un producto software que funcione que escribir documentacin exhaustiva. La colaboracin con el cliente debe prevalecer sobre la negociacin de contratos. La capacidad de respuesta ante un cambio es ms importante que el seguimiento estricto de un plan.

Estas metodologas ponen de relevancia que la capacidad de respuesta a un cambio es ms importante que el seguimiento estricto de un plan.