Capítulo 3: Planificación de la Fase: Creación de su diseño de la solución y Arquitectura, los planes del proyecto, y el Proyecto de Calendario En este capítulo se presentan los antecedentes y la información técnica necesaria para completar la fase de planificación de un proyecto de migración. En esta página Introducción a la fase de planificación La fase de planificación es el momento en que el equipo del proyecto se traduce la visión / alcance inicial de la fase de previsión en planes prácticos sobre la manera de lograrlo. El propósito de la fase de planificación es definir la solución en detalle junto con el plan del proyecto aprobado y horario. Este trabajo incluye la creación de una especificación funcional, el desarrollo de la arquitectura y el diseño de la solución, y la preparación de las estimaciones de costos. Los miembros del equipo basan en su experiencia para crear planes detallados individuales, como el plan de desarrollo, plan de pruebas, y el plan de despliegue, así como los horarios de todos los aspectos del proyecto. Gestión de Programas combina estos planes y programas individuales y los sincroniza para crear el plan y horarios proyecto principal. La fase de planificación culmina en el Milestone Aprobado Planes Proyecto. Pasando este hito indica que el cliente, el equipo del proyecto, y todas las partes están de acuerdo en los detalles de los planes, incluyendo lo que se construye, cómo se construye, cuándo va a ser entregado, y lo que costará. Planificación de Tareas de la Fase Las principales tareas de migración realizadas durante la fase de planificación se resumen en la siguiente lista. Ellos se describirán con más detalle en las secciones subsiguientes. Desarrollar el diseño de la solución y la arquitectura. El equipo de desarrollo comienza el proceso de diseño con el diseño de la solución y la arquitectura y culmina con un documento de diseño que se convierte en parte de la especificación funcional. La validación de la tecnología. El equipo de desarrollo también valida tecnologías para asegurar que cumplen con las necesidades de negocio de la solución específica. Creación de la especificación funcional. El equipo del proyecto y gestión de programas, clases, crean una especificación funcional que describe los requisitos de la solución, la arquitectura y el diseño detallado de todas las características. Esto representa el contrato entre el equipo del proyecto y cliente. El desarrollo de los planes del proyecto. El papel de Gestión de Programas y los diferentes equipos que componen el equipo del proyecto a desarrollar un conjunto de planes para definir las tareas para las seis funciones del equipo de MSF, y gestión de programas les consolida en un plan de proyecto maestro. La creación de los programas del proyecto. El papel de Gestión de Programas y los diversos equipos crean horarios hito impulsado para cada rol individual del equipo, y gestión de programas les consolida en el calendario del proyecto principal. Configuración del entorno de desarrollo y pruebas. Los equipos de desarrollo y prueba crean entornos de desarrollo y pruebas que son independientes del entorno de producción para desarrollar y probar la solución. Cierre la fase de planificación. El equipo del proyecto se completa la fase de planificación, con el proceso de aprobación para el Milestone Aprobado Planes Proyecto. Nota Aunque la lista secuencialmente, muchas de estas actividades se pueden realizar al mismo tiempo. Planificación Entregables Fase Las actividades de la Fase de Planificación culminan en un hito importante, el Milestone Planes proyecto aprobado. Al final de la fase de planificación, el equipo del proyecto y todas las partes interesadas (otros miembros de la organización que se verán afectados por el proyecto) debería haber acordado la especificación funcional, tecnología para la solución, y los planes del proyecto y cronograma. Estas prestaciones incluyen: Identifica los riesgos potenciales y estrategias de mitigación. Un documento de instrucciones sobre la configuración de los entornos de desarrollo y pruebas de que: Crea un adecuado desarrollo y entorno de pruebas para la solución sin afectar el sistema de producción. Identifica los requisitos de hardware y de infraestructura para el medio ambiente. Juntos, estos productos contienen una descripción de diseño de alto nivel y el plan del proyecto que sirvan de base para las fases posteriores. Por lo tanto, el documento de especificación funcional, sobre todo, debe ser vista como un documento vivo que va cambiando, sujeta a cambios de control. Las entregas pueden sufrir numerosas iteraciones antes de que el equipo del proyecto, a los clientes, y de las partes interesadas llegar a un consenso final. Nota Para discusiones más detalladas sobre cómo estas tareas y entregables pueden ser abordados y las responsabilidades asignadas para ellos, consulte la Guía de Unix Migración de proyectos (UMPG) a Las instrucciones para configurar los entornos de desarrollo y pruebas se explican en el capítulo 4, "Planificación: Configuración del Desarrollo y Prueba Ambientes" de este volumen. Planificación Fase Actividades Las siguientes secciones detallan las diferentes actividades involucradas en la fase de planificación del modelo de proceso de MSF y cómo estas actividades se refieren específicamente a un proyecto de migración. Desarrollar el Diseño y Arquitectura de la solución El desarrollo del diseño de la solución y la arquitectura comienza con un proceso de diseño, los resultados de los cuales se convierten en la especificación funcional. El proceso de diseño ayuda a identificar la estructura del equipo del proyecto y las responsabilidades del equipo para la próxima fase de desarrollo. El fundamento del proceso de diseño es la visión que el equipo desarrolló y los objetivos de negocio que se reunieron durante la fase de ideación. El diseño arquitectónico describe cómo las características y funciones operan juntos para formar la solución. Identifica los componentes específicos de la solución y sus relaciones. El documento de diseño contiene detalles de la arquitectura y los componentes que intervienen en la construcción de la solución. Para los proyectos de migración de UNIX a Windows, la arquitectura de la solución sigue siendo la misma; sin embargo, para incluirlo en el documento de diseño asegura la exhaustividad. Esto ayuda al equipo a trabajar de una manera sistemática, desde conceptos abstractos en el documento de visión / ámbito a detalles técnicos específicos en el proceso de diseño. También ayuda a mantener la correlación entre los requisitos y las características de la solución. Diseño conceptual La etapa de diseño conceptual incluye el proceso de análisis y priorización de negocios y usuarios perspectivas del problema y la solución, y luego la creación de una representación de alto nivel de la solución. Esta etapa ayuda en la cartografía de la funcionalidad asociada con cada uno de los requisitos. Un diseño conceptual es un medio para entender las expectativas de negocio y requerimientos de las aplicaciones que incluyen tanto los requisitos técnicos y de infraestructura en términos de negocio, el usuario, el sistema y los requisitos operativos. El diseño formula la solución a desarrollar, teniendo en cuenta los usuarios finales y los requerimientos del negocio. Por tanto, es esencial para responder a todas las preguntas en la lista de verificación de evaluación previsto con esta guía. Esto ayuda a evaluar la situación actual y definir con mayor precisión el alcance del proyecto se desarrolló durante la fase de previsión a fin de obtener una clara comprensión de la funcionalidad necesaria para generar la solución. El diseño conceptual sienta las bases para el desarrollo de la solución y se ocupa de los requisitos por los que describe el diseño y la arquitectura de sus componentes. Para los proyectos de migración, el diseño conceptual es generalmente idéntica a la funcionalidad original de la aplicación actual o componente de infraestructura. No obstante, es importante articular el diseño existente en la especificación funcional para el proyecto de migración porque el concepto real del componente actual puede haberse desplazado desde su concepción inicial. Incluso si ese diseño conceptual se ha mantenido constante, sirve como una piedra de toque para las fases de diseño posteriores. El siguiente ejemplo demuestra lo que se entiende por diseño conceptual. Ejemplo de Diseño Conceptual Consideremos una aplicación de gráficos de ingeniería desarrollado en UNIX que es utilizado por el personal de diseño dentro de una organización. Debido a la evolución de los requerimientos del negocio y un entorno globalizado, la organización ahora quiere hacer uso de la capacidad de sus socios externos para proporcionar soluciones de diseño utilizando la misma aplicación. Para lograr esto, la aplicación tiene que estar disponible en la plataforma Microsoft® Windows®, que la mayoría de sus proveedores ya han estandarizado. Migración de esta aplicación para la plataforma de Windows le permite ser compartida con los socios, lo que resulta en un mayor grado de colaboración entre los usuarios que utilizan la aplicación, tanto dentro de la organización como fuera. El diseño conceptual debe documentar cualquier requerimientos únicos que surgirían en este nuevo entorno y verificar que la arquitectura de la solución propuesta satisface estos requisitos. Diseño Lógico Durante la etapa de diseño lógico, cada parte del diseño conceptual se asigna a una función específica dentro de la arquitectura de la solución. Proporciona una visión clara de la solución desde el punto de vista funcional. Un diseño lógico identifica y define todos los objetos y sus comportamientos, atributos, y las relaciones dentro del alcance de la solución. El diseño de la aplicación se divide en tres niveles: presentación, negocios, y la capa de datos. Para un proyecto de migración, debe documentar el diseño lógico existente, así como el diseño lógico de la aplicación o infraestructura componente migrado y hacer hincapié en las áreas de cambio, si procede. También es importante para mostrar cómo el proyecto de migración afecta a los otros componentes fuera del alcance del proyecto. Ejemplo de Diseño Lógico Siguiendo con el mismo ejemplo de aplicación de ingeniería, el diseño lógico documenta los nuevos componentes arquitectónicos existentes, así como se requieren para realizar el diseño conceptual. La capa de presentación puede lograrse mediante una interfaz de Windows de usuario (UI) en lugar de la interfaz de usuario basada en X-Motif existente. La capa de comunicación se puede lograr mediante Winsock o mensajes en lugar de las tomas de corriente UNIX llamadas existentes. También puede ser necesario para mostrar cómo las aplicaciones migradas interactúan con otros componentes fuera del alcance del proyecto de migración. Por ejemplo, es posible que las aplicaciones en el lado del socio para el intercambio de datos con la aplicación migrada en Windows. Diseño físico El diseño físico de la solución identifica las piezas del diseño lógico que debe encajar en la arquitectura física. El diseño físico identifica la arquitectura física infraestructura y topología. Se crea un conjunto de modelos de diseño físico, incluyendo el diseño del componente, diseño de interfaz de usuario, y un diseño de base de datos física para las aplicaciones. El diseño físico debe incluir métricas anticipado para evaluar las metas de desempeño, metas de tiempo de actividad, y los hitos para escribir el código de la solución. Por ejemplo, el diseño físico podría incluir métricas de tiempo de transacción y los requisitos de rendimiento para las transacciones antes de la implementación. Métricas de producción para los escenarios de implementación particulares también deben establecerse. El diseño físico es un diseño completo de implementación, en forma de una especificación técnica, que el equipo de desarrollo utiliza para generar la solución. Para un proyecto de migración, el diseño físico debe incluir también el proceso de implementación de la infraestructura y los detalles paso a paso de cómo implementar la aplicación migrada, teniendo en cuenta los hitos actuales de la aplicación. También debe cubrir cómo la nueva aplicación satisface los requisitos de negocio, sin violar los acuerdos en curso de nivel de servicio (SLA). Ejemplo de Diseño físico El diseño físico de la aplicación podría describir los componentes que en cada una de las capas (presentación, negocios, y datos) necesitan ser cambiados en una de las siguientes maneras: Portado recompilar y arreglar los problemas que se plantean. Reescrito si no hay biblioteca correspondiente o componente disponible en Windows. Reemplazado si una biblioteca equivalente está disponible en Windows. Compradas si la biblioteca o componente es ser comprado a proveedores de terceros. También podría proporcionar una cartografía detallada de la fuente de UNIX arquitectura a la arquitectura de Windows de destino, donde cada componente / biblioteca de la aplicación UNIX se asigna a uno que ofrece una funcionalidad equivalente en Windows. Validación de la Tecnología A menudo, en conjunto con el proceso de diseño, su equipo puede también validar las tecnologías que se utilizan en la solución. En el proceso de validación de la tecnología, el equipo evalúa los productos o tecnologías para asegurarse de que funcionan de acuerdo con las especificaciones proporcionadas por sus proveedores y que se dirigen a las necesidades del negocio para el escenario de solución específica. La validación de la tecnología es un paso esencial en un proyecto de migración de UNIX a Windows, ya que las herramientas, software y hardware en el nuevo entorno de Windows deben trabajar juntos para producir el mismo o mejor efecto que el producido en el entorno UNIX. Por ejemplo, si la aplicación UNIX utiliza una biblioteca de terceros y si una versión de Windows de que también está disponible, sería una buena idea para comprobar si el equivalente de Windows de las obras de la biblioteca de acuerdo con las especificaciones requeridas. Prueba de Concepto Técnico Después de la validación de las tecnologías, el equipo hace un primer intento de crear un modelo de la tecnología que se implementará. Esto produce una prueba de concepto. El modelo inicial de prueba de concepto a menudo produce ambas respuestas y preguntas adicionales para el equipo acerca de los problemas que puedan surgir con la tecnología durante la fase de desarrollo. Esta información ayuda en el proceso de gestión de riesgos e identifica los cambios generales de diseño que deben ser incorporados en las especificaciones. Las distintas bibliotecas o módulos en la aplicación de UNIX se pueden enumerar en el documento de especificación funcional, como se muestra en la tabla siguiente prueba de concepto de identificación para una aplicación de solución de banca muestra. Tabla 3.1. Muestra de prueba de concepto de identificación
No comments:
Post a Comment