SISTEMAS DE INFORMACIÓN II (IF202)
Contents
1. o de un prototipo inicial el cual explora que se considera que son las reas de alto riesgo El esfuerzo de prototipeo durante el Inicio debe de estar limitado a ganar confianza que una soluci n es posible la soluci n es realizada durante la Elaboraci n y la Construcci n Ing Manuel Pe aloza Figueroa t Preparar el entorno para el proyecto gt valorando el proyecto y la organizaci n gt seleccionando las herramientas gt decidiendo cuales partes del proceso mejorar 3 1 4 Hito Objetivos del Ciclo de vida El hito Objetivos del Ciclo de vida evalua la viabilidad b sica del proyecto En este punto se examina los objetivos del ciclo de vida del proyecto y se decide si proseguir con el proyecto o cancelarlo Criterio de Evaluaci n Concurrencia de los interesados sobre la definici n del alcance y los estimados de costo cronograma F Acuerdo que el conjunto correcto de requerimientos han sido capturados y que hay un entendimiento compartidos de estos requerimientos FP Acuerdo que a gt gt los estimados de costo cronograma prioridades riesgos y proceso de desarrollo son apropiados Todos los riesgos han sido identificados y una estrategia de mitigaci n existe para cada una El proyecto puede ser abortado o considerablemente re pensado si falla en alcanzar este hito 3 1 5 Artefactos l Artefactos esenciales Estado en el hito en or2. Gasto de recursos actual Vs gasto planificado son aceptables El proyecto puede ser abortado o considerablemente re pensado si se falla en alcanzar este hito El sistema flaco evoluciona para volverse el sistema completamente desarrollado tal vez con algunos cambios menores a la estructura y al Ing Manuel Pe aloza Figueroa comportamiento e Los cambios son menores por que Al final de la Elaboraci n o iteraciones arquitecturales se tiene por definici n una arquitectura estable de otra manera La fase de Elaboraci n tiene que continuar hasta que se sepa que esta meta ha sido lograda e Hay un modo sistem tico de hacer esto Al final de la fase de Elaboraci n 3 2 5 Artefactos E gt se han desarrollado modelos del sistema que representan los casos de uso m s importantes y sus realizaciones desde la perspectiva de la arquitectura gt se han decidido t con que est ndares se cuenta t que software del sistema y que middleware utilizar t que sistema heredados reutilizar Artefactos Esenciales en orden de importancia Estado en el hito RUP Prototipos Uno o m s prototipos arquitecturales ejecutables han sido creados para explorar gt funcionalidad cr tica gt y escenarios arquitecturalmente significantes Lista de Riesgos Actualizado y revisado e Nuevos riesgos son probablemente ser arquitecturales en naturaleza en primer lugar relacionaldos al manejo de reque
3. los criterios de aceptaci n para el producto final Ing Manuel Pe aloza Figueroa P Planificar y preparar un caso de negocio Evaluando alternativas para gt gt administraci n del riesgo la provisi n dotacion de personal plan de proyecto y los intercambios de una cosa a cambio de otra tradeoffs entre costo cronograma rentabilidad Caso de Negocio El Caso de Negocio provee la informaci n necesaria desde un punto de vista del negocio para determinar si o no en el proyecto vale la pena invertir Para un producto de software comercial el Caso de Negocio debe de incluir un conjunto de suposiciones acerca del proyecto y el orden de magnitud del Retorno de Inversi n ROT si esas suposicones son ciertas e Por ejmplo el ROI ser de una magnitud de 5 si completado en un a o 2 si completado en 2 a os y un n mero negativo despu s de eso e Estas supociones son chequeadas de nuevo al final de la fase de Elaboraci n cuando el alcance y el plan est n definidos con m s exactitud Sintetizar una arquitectura candidata evaluando trade offs gt en el dise o y en el hacer comprar reusar de modo que gt el costo gt el cronograma y los recursos puedan ser estimados La intenci n prop sito aqu es demostrar viabilidad factibilidad a trav s de alguna clase de prueba de conceptos Esto puede tomar la forma gt de un modelo el cual simula que es requerido
4. organizaci n Incluye detalles como e que actividades y artefactos opcionales ser n usado y cuales ser n exclu dos e el cronometraje relativo de actiidades para cada fase e que herramientas ser n usudas e el nivel de formalidad a ser aplicado 3 2 4 Hito Arquitectura del Ciclo de Vida El hito Arquitectura del Ciclo de Vida gt establece una l nea de base administrada por la arquitectura del sistema gt y habilita al equipo del proyecto a escalar durante la fase de Construcci n En este punto se examina gt los objetivos detallados del sistema y el alcance gt la selecci n de la arquitectura gt y la resoluci n de los mayores riesgos Criterio de Evaluaci n El producto Visi n y los requerimientos son estables La arquitectura es estable Los enfoques claves a ser usados en la prueba y evaluaci n est n probados La prueba y evaluaci n de prototipos ejecutables han demostrado que los mayores elementos de riesgo han sido abordados y han sido cre blemente resueltos Los planes de iteraci n para la fase de Construcci n son de suficiente detalle y fidelidad para permitir que el trabajo prosiga Los planes de iteraci n para la fase de Construcci n est n soportados por estimados creibles Todos los interesados est n de acuerdo que la visi n actual puede ser satisfecha si el plan en curso es ejecutado para desarrollar el sistema completo en el contexto de la arquitectura actual
5. problema gt entender las necesidades de los interesados gt definir el sistema gt y gestionar managing los requerimientos a medida que ellos cambian An lisis 8 Dise o gt definir una arquitectura candidata Usar Arquitecturas gt refinar la arquitectura de Componentes gt analizar el comportamiento gt y dise ar componentes del sistema Implementaci n gt Incrementalmente construir los Desarrollar componentes del sistema Iterativamente Pruebas gt probar los componentes del sistema Desarrollar Iterativamente UPEDU RUP gt administrar y controlar el alcance del Controlar Cambios Configuraci n y proyecto a medida que los cambios Administraci n del ocurren a lo largo del ciclo de vida del Cambio proyecto mientras manteniendo la meta de considerar todas las necesidades de los interesados y meeting those to whatever extent possible Ing Manuel Pe aloza Figueroa 27 RUP Entorno gt adaptar un proceso para el proyecto 28 Ing Manuel Pe aloza Figueroa
6. sido identificados gt y la mayor parte de las descripciones de caso de uso captura de requerimientos han sido desarrollados Especificaciones Suplementarias Requerimientos suplementarios capturando los requierimientos no funcionales est n documentados y revisados RUP Suite de Pruebas smoke Pruebas implementadas y ejecutadas para validar la test estabilidad del build para cada uno de los releases ejecutables creados durante la fase de Elaboraci n 2777 RUP Arquitectura de Una composici n con base de linea de varios Automatizaci n de Pruebas Test Automation Architecture mecanismos y elementos de software claves que plasman las caracter sticas fundamentales del sistema de software de automatizaci n de pruebas Artefactos Opcionales Estado en el hito RUP Caso de Negocio Actualizado si investigaciones arquitecturales destapan cuestiones que cambien fundamentales suposiciones del proyecto RUP Modelo de An lisis Puede ser desarrollado como un artefacto formal ni frecuentemente ni formalmente mantenido evolucionando en una primera versi n del Modelo de Dise o m s bien RUP Material de Soporte del Usuario Final Manuales de Usuario y otros materials de entrenamiento e Preliminarmente borrador basado en casos de uso e Puede ser necesitado si el sistema tiene un fuerte aspecto de interfase del usuario Ing Manuel Pe aloza Fig
7. SISTEMAS DE INFORMACI N II 1F202 UN APUNTE PRELIMINAR Separata 3 Fases Ing Manuel A Pe aloza Figueroa Departamento Acad mico de Inform tica Universidad Nacional de San Antonio Abad del Cusco Cusco Per Ing Manuel Pe aloza Figueroa Ing Manuel Pe aloza Figueroa En Inform tica nada es absoluto todo es relativo Leunam Ing Manuel Pe aloza Figueroa Ing Manuel Pe aloza Figueroa 3 FASES Fase es esencialmente un lapso de tiempo entre 2 hitos milestones mayores o importantes durante el cual gt un conjunto bien definido de objetivos es satisfecho gt artefactos son completados gt y decisiones son tomadas para moverse o no dentro de la siguiente fase t Al final de cada fase una valoraci n es llevada a cabo para determinar si los objetivos de la fase han sido satisfechos t Una valoraci n satisfactoria permite al proyecto moverse a la siguiente fase Fases e Hitos Elaboraci n Construcci n i Transici n hito hito hito hito Objetivos del Arquitectura del Capacidad Release del Ciclo de vida Ciclo de vida Operativa Producto 2 Inicial 1 tiempo USDP 1 Funcionalidad Operativa Inicial 2 Versi n del Producto Figura PU Fases e hitos de un proyecto Planificando las Fases Todas las fases no son id nticas en t rminos de cronograma y esfuerzo Esto var a considerablemente dependiendo del proyecto Un ciclo de desarrollo t pico inicial para un pr
8. ar el costo y el cronograma para la conclusi n completion del desarrollo Para la mayor parte de los proyectos pasar este hito tambi n corresponde a la transici n desde una operaci n ligera y r pida de bajo riesgo a una operaci n de alto costo y alto riesgo con sustancial inercia organizacional Abordar todos los riesgos arquitecturalmente significantes del proyecto Establecer una arquitectura con l nea de base derivada a partir de abordar los escenarios arquitecturalmente significantes los cuales t picamente exponen sacan a la luz los riesgos t cnicos m s altos del proyecto Producir un prototipo evolutivo de componentes de calidad de producci n as como posiblemente uno o m s prototipos exploratorios desechables descartables para mitigar riesgos espec ficos tales como trade offs de dise o requerimientos reuso de componentes viabilidad del producto demostraciones a gt los inversionistas gt los clientes gt y usuarios finales Ing Manuel Pe aloza Figueroa 13 j Demostrar que la arquitectura con l nea de base soportar lo requerimientos del sistema a un costo razonable y en un tiempo razonable Establecer un entorno de soporte A fin de lograr estos objetivos primarios es igualmente importante set up el entorno de soporte para el proyecto Esto incluye gt crear un caso de desarrollo gt crear plantillas gt l neas de gu a 5 y setting up herramientas 3 2 3 A
9. bre los objetivos del ciclo de vida para el proyecto La fase de Inicio es de significaci n primariamente para nuevos esfuerzos de desarrollo en los cuales hay significantes riesgos de negocio y requerimientos los cuales tienen que ser abordados antes de que el proyecto pueda proseguir e Para proyectos enfocados sobre mejoramientos a un sistema existente la fase de Inicio es m s breve pero est todav a enfocado en asegurar que el proyecto tanto vale hacer como que es posible hacerlo 3 1 2 Objetivos Objetivos primarios Establecer el alcance de software del proyecto y las condiciones de limite Incluyendo gt una visi n operativa gt criterios de aceptaci n gt y que est intentado estar en el producto y lo que no esta t Discriminar los casos de uso cr ticos del sistema y los escenarios primarios de operaci n que conducir n los mayores trade offs de dise o F Mostrar al menos una arquitectura candidata contra alguno de los escenarios primarios Estimar el costo global y el cronograma para el proyecto entero y estimados m s detallados en la fase de Elaboraci n que inmediatamente sigue Estimar riesgos potenciales las fuentes de impredicibilidad t Preparar el entorno de soporte para el proyecto 3 1 3 Actividades esenciales bh Formular el alcance del proyecto Esto involucra capturar el contexto y los m s importantes requerimientos y restricciones hasta el punto de que se puede derivar
10. ctividades esenciales j Definir validar y desarrollar la l nea de base baselining de la arquitectura tan r pidamente como pr ctica Refinar la Visi n basado sobre nueva informaci n obtenida durante la fase estableciendo un entendimiento s lido de los m s cr ticos casos de uso que conducen las decisiones arquitecturales y de planificaci n Crear y desarrollar la l nea de base para los planes de iteraci n detallados para la fase de Construcci n Refinar el caso de desarrollo y colocar en el lugar el entorno de desarrollo incluyendo el proceso el soporte de herramientas y automatizaci n requeridos para soportar al equipo de construcci n Refinar la arquitectura y seleccionar componentes Componentes potenciales son evaluados y las decisiones de hacer comprar reusar suficientemente entendidas para determinar el costo y cronograma de la fase de Construcci n con confianza confidence Los componenentes arquitecturales seleccionados son integrados y valorados contra los escenarios primarios Lecciones aprendidas desde estas actividades pueden bien resultar en un redise o de la arquitecura tomando en consideraci n dise os alternativos o reconsideraci n de los requerimientos Caso de Desarrollo El Caso de Desarrollo describe el proceso de desarrollo que se ha elegido para seguir el proyecto El Caso de Desarrollo describe como el proceso es aplicado para un proyecto Ing Manuel Pe aloza Figueroa 14 espec fico
11. den de importancia Visi n gt los requerimientos core gt las caractere sticas claves gt y las restricciones principales del proyecto est n documentados RUP Caso de Negocio Definido y aprobado Lista de Riesgos Riesgos iniciales del proyecto identificados Ing Manuel Pe aloza Figueroa RUP Plan de Desarrollo de Software Fases iniciales gt su duraci n gt y objetivos identificados e Estimados de recursos especificamente el tiempo staff y costos del entorno de desarrollo en particular en el Plan de Desarrollo de Software tienen que ser consistentes con el Caso de Negocio El estimado de recursos puede abarcar el proyecto entero a trav s de entregables solo un estimado de recursos necesitados para ir a trav s de la fase de Elaboraci n e Estimados de los recursos requeridos para el proyecto entero deben de ser vistos como muy vagos aproximados un calculo al ojo en este punto e Este estimado es actualizado en cada fase y cada iteraci n y se vuelve m s preciso con cada iteraci n Dependiendo de las necesidades del proyecto uno o m s de los artefactos del Plan adjuntado pueden estar condicionalmente completados e Un inicial Plan de Aceptaci n del Producto debe de ser revisado y con l nea de base e El Plan de Aceptaci n del Producto es refinado en teraciones subsecuentes a medida que requerimientos adicionales son descubiertos Adem s los arte
12. e hay inter relaciones espec ficas entre conceptos que son esenciales capturar RUP Prototipos Uno o m s prototipos de prueba de conceptos para gt soportar la Visi n y el Caso de Negocio gt y abordar riesgos muy espec fcos Parte de este artefacto se encuentra en el artefacto del RUP Infraestructura de desarrollo Depositario del Proyecto El Depositario del Proyecto almacena todas las versiones de archivos y directorios del proyecto e Tambi n almacena todos los datos derivados y meta datos asociados con los archivos y directorios Ing Manuel Pe aloza Figueroa 12 3 2 Fase Elaboraci n 3 2 1 Meta La meta del la fase de Elaboraci n es gt desarrollar la l nea de base de la arquitectura del sistema para proveer una base estable para el grueso del esfuerzo de dise o e implementaci n en la fase de Construcci n La arquitectura evoluciona m s alla de gt una consideraci n de los m s significantes requerimientos aquellos que tienen un gran impacto sobre la arquitectura del sistema gt y de una valoraci n del riesgo La estabilidad de la arquitectura es evaluada a trav s de uno o m s prototipos arquitecturales 3 2 2 Objetivos Los objetivos primarios de la fase de Elaboraci n incluyen Asegurar que la arquitectura requerimientos y planes son lo suficientemente estables y los riesgos suficientemente mitigados para poder predeciblemente determin
13. entadas y ejecutadas para validar la estabilidad del build para cada uno de los releases de ejecutable creados durante la fase de Construcci n RUP Material de Soporte para elj Manuales de Usuario y otros materiales de Usuario Final entrenamiento e Un borrador preliminar basado sobre los casos de uso puede ser necesitado si el sistema tiene un fuerte aspecto de IU Plan de Iteraci n Plan de iteraci n para la fase de Transici n completada y revisada Modelo de Dise o y todos los artefactos Actualizado con nuevos elementos de dise o consituyentes identificados durante la compleci n de todos los requerimientos RUP Proceso de Desarrollo El proceso de desarrollo incluyendo el caso de desarrollo y cualquier l neas de gu a y Ing Manuel Pe aloza Figueroa 21 templates ha sido refinado basado sobre la experiencia del proyecto y est suficientemente definida para la siguiente fase prosiga RUP Infraestructura de Desarrollo El entorno de desarrollo para la transidci n esta en su lugar incluyendo todas las herramientas y soporte de automatizaci n para el proceso RUP Modelo de Datos Actualizado con todos los elementos necesitados para soportar la implementaci n ndices de la persistencia e g tablas mapeamientos objeto a relacional etc Artefactos opcionales Especificaciones Suplementarias Actualizado con nuevos r
14. equerimientos si los hubiera descubiertos durante la fase de Construcci n Model de Caso de Uso Actores Casos de Uso Actualizado con nuevos casos de uso si los hubiera descubiertos durante la fase de Construcci n Ing Manuel Pe aloza Figueroa 22 m y 3 4 Fase Transici n 3 4 1 Meta El foco de la Fase de Transici n es asegurar que el software est disponible para sus usuarios finales La fase de Transici n puede abarcar varias iteraciones e incluye gt probar el producto en preparaci n para el release gt y hacer ajustes menores basado en la realimentaci n del usuario e En este punto en el ciclo de vida la realimentaci n debe de enfocarse principalmente sobre gt afinamiento del producto gt configuraci n gt instalaci n gt y temas de usabilidad todos las mayores temas estructurales deben de haber sido resueltos mucho mas antes en el ciclo de vida del proyecto 3 4 2 Objetivos Por el final de la Fase de Transici n los objetivos del ciclo de vida deben de haber sido satisfechos y el proyecto debe de estar en una posici n para ser cerrado e En algunos casos el final del ciclo de vida actual puede coincidir con el arranque de otro ciclo de vida del mismo producto guiando la siguiente generaci n o versi n del producto e Para otros proyectos el final de la Transici n puede coincidir con una completa entrega de los artefactos a una tercera parte
15. factos L neas de gu a adjuntados est n t picamente en al menos una forma de borrador Plan de Iteraci n El plan de iteraci n para la primera iteraci n de Elaboraci n completado y revisado RUP Proceso de Desarrollo Adaptaciones y extensions al RUP documentadas y revisadas e Esto t picamente incluye l neas de gu a y Ing Manuel Pe aloza Figueroa 11 plantillas as como un caso de desarrollo para documentar decisiones de personalizaci n adaptaci n espec ficas al proyecto RUP Infraestructura de Desarrollo Todas las herramientas para soportar el proyecto son seleccionadas e Las herramientas necesarias para trabajar en Inicio est n instaladas En particular el entorno de Administraci n de la Configuraci n debe de estar set up Glosario T rminos importantes definidos glosario revisado Modelo de Caso de Uso Actores y Casos de Uso gt Actores y casos de uso importantes identificados gt y flujo de eventos esbozados para solo los m s cr ticos casos de uso UPEDU Depositario del Proyecto Petici n Request de Cambio El entorno de Administraci n de la Configuraci n debe de estar set up Artefactos Opcionales RUP Modelo de Dominio Modelo de An lisis de Negocio a k a Los conceptos claves siendo usados en el sistema documentados y revisados e Usado como una extension al Glosario en casos dond
16. lementaci n gt y probar el software Ing Manuel Pe aloza Figueroa Decidir si gt el software gt los sites y los usuarios est n todos listos para que la aplicaci n sea desplegada t Conseguir alg n grado de paralelismo en el trabajo de los equipos teams de desarrollo A n en proyectos m s peque os hay t picamente componentes que pueden ser desarrollados independientemente uno del otro dejando un margen para paralelismo natural entre equipos teams resources permitting Este paralelismo puede acelerar las actividades de desarrollo significativamente pero tambi n incrementa gt la complejidad de la gesti n de recursos gt y la sincronizaci n del flujo de trabajo Una arquitectura robusta es esencial si alg n paralelismo significante est por ser conseguida 3 3 3 Actividades Esenciales Las actividades esenciales de la fase de Construcci n incluyen b Gesti n Administraci n de recursos control y optimizaci n del proceso Completar desarrollo de componentes y pruebas contra los criterios de evaluaci n definidos Valoraci n de releases del producto contra criterios de aceptaci n para la visi n 3 3 4 Hito Capacidad Operativa Inicial El hito Capacidad Operativa Inicial determina si el producto est listo para ser desplegado dentro un entorno de prueba beta El producto es listo para ser transferido al Equipo Team de transici n Toda la funcionalidad ha sido desa
17. mponentes arquitecturales seleccionados son integrados y valorados contra los escenarios primarios e Lecciones aprendidas a partir de estas actividades resultar en un redise o de la pueden bien arquitectura tomando en consideraci n dise os alternativos O reconsideraci n de los requerimientos RUP Modelo de Datos Definido y con l nea de base e Los mayores elementos del modelo de datos e g entidades importantes interrelaciones tablas definidos y revisados Modelo de Implementaci n y todos los artefactos constituyentes incluyendo Componentes Elementos de Implementaci n Estructura inicial creada y mayores components identificados y prototipeados Visi n Refinado basado sobre nueva informaci n obtenida durante la fase estableciendo un entendimiento s lido de los m s cr ticos casos de uso que conducen las decisiones arquitecturales y de planificaci n RUP Plan de Desarrollo de Software Actualizado y expandido para cubrir las fases de Construcci n y de Transici n Plan de Iteraci n Plan de iteraci n para la fase de Construcci n Ing Manuel Pe aloza Figueroa 17 completado y revisado Modelo de Caso de Uso Actores Casos de Uso Un modelo de caso de uso aproximadamente 80 completo gt todos los casos de uso habiendo sido identificados en la encuesta survey del modelo de caso de uso gt todos los actores habiendo
18. oyecto de mediano tama o debe de anticipar la siguiente distribuci n entre esfuerzo y cronograma Inicio Elaboraci n Construcci n Transici n Esfuerzo m5 20 65 10 Cronograma 10 30 50 10 Ing Manuel Pe aloza Figueroa El cual puede ser descrito gr ficamente como Recurso tiempo Inicio Elaboraci n Construcci n Transici n Artefactos de Requerimientos planificados Disciplina Artefacto l E C T Responsable R Modelo de l M Analista de Sistemas Caso de Uso Prototipo IU l Dise ador IU Especificaciones M Analista de Sistemas Suplementarias Visi n l M Analista de Sistemas l E T Modelo del Dominio l F Modelo del Negocio l F Requerimientos l F An lisis l F Arquitectura l A F Lista de Riesgos l A A 1 Fuente Adaptado de Software Development for Small Teams A RUP Centric Approach Gary Pollice Liz Augustine Chris Lowe amp Jas Madhur Chapter 4 Getting Started The Project Members Become a Team pp 48 Ing Manuel Pe aloza Figueroa Casos de Uso Plan para la fase de E Caso del Negocio Plan de Administraci n del Proyecto Manuales Release Ing Manuel Pe aloza Figueroa 3 1 Fase Inicio 3 1 1 Meta La meta primordial de la fase de Inicio es Lograr la coincidencia entre todos los interesados so
19. quien puede ser responsable por gt las operaciones gt el mantenimiento gt y mejoras del sistema entregado Esta Fase de Transici n oscila desde ser muy sencillo directo a extremadamente complejo dependiendo de la clase del producto e Un nuevo release de un producto desktop existente puede ser muy simple mientras que el reemplazo de un Sistema de Control de Tr fico aereo de una naci n puede ser extremadamente complejo Ing Manuel Pe aloza Figueroa 23 Actividades realizadas llevadas a cabo durante una interaci n en la Fase de Transici n dependen de la meta Ejemplos Cuando arreglando fijando bugs implementaci n y pruebas son usualmente suficientes Si sin embargo nuevas caracter sticas tienen que ser agregadas la iteraci n es similar a uno en la fase de Construcci n requiriendo an lisis dise o etc La Fase de Transici n es entrada cuando una l nea de base es lo suficiente madura para ser desplegada en el dominio del usuario final e Esto t picamente requiere que alg n subconjunto usable del sistema ha sido completado con aceptabale nivel de calidad y documentaci n usuaria de modo que la transici n al usuario provee resultados positivos para todas las partes Los objetivos primarios de la Fase de Transici n incluyen Pruebas beta para validar el nuevo sistema contra las expectativas del usuario Pruebas beta y operaci n paralela relativos a un sistema legacy que ello es
20. rimientos no funcionales RUP Proceso de Desarrollo El proceso de desarrollo incluyendo cualesquier l neas de gu a y plantillas espec ficos al proyecto han sido refinados basados en la experiencia de los primeros proyectos y est suficientemente definido para la fase de Construcci n proseguir RUP Infraestructura de Desarrollo El entorno de desarrollo para construcci n est en su lugar incluyendo todas las herramientas y soporte de automatizaci n para el proceso Ing Manuel Pe aloza Figueroa 16 Documento de Arquitectura del Software Creado y con l nea de base incluyendo descripciones detalladas para los casos de uso arquitecturalmente significantes vista de caso de uso identificaci n de mecanismos claves y elementos de dise o vista l gica m s la definici n de la vista del proceso y la vista de desplegamiento si el sistema est distribu do o tiene que tratar con temas de concurrencia Modelo de Dise o y todos los artefactos constituyentes Definido y con l nea de base e Realizaciones de Caso de uso para escenarios arquitecturalmente significantes han sido definidos y comportamiento requerido ha sido asignado a los elementos de dise o apropiados e Componentes han sido identificados y las desiciones de hacer comprar reusar suficientemente entendidas para determinar el costo y el cronograma de la fase de Construcci n con confianza e Los co
21. rio final en gt aprender gt usar gt operar gt y mantener el producto debe de estar completo de acuerdo con los requerimientos RUP Elementos de Implementaci n La implementaci n es completa y con l nea de base y los elementos desplegables han sido incorporados en el producto final Artefactos opcionales Estado en el Hito RUP Suite de Pruebas Smoke test El suite de prueba desarrollado para validar la estabilidad de cada build puede ser proporcionado prove do en la situaci n donde el cliente desea ejecutar un nivel b sico de una prueba on site RUP Empaquetamiento del Producto Shrinkwrap En el caso de crear un producto shrinkwrap el contratista necesitar los necesarios artefactos de empaquetamiento para ayudar a vender al por menor el producto Ing Manuel Pe aloza Figueroa 26 3 46 Resultado La iteraci n final en la fase de Transici n culmina en la entrega al cliente de un sistema completo y artefactos de soporte auxiliares con la funcionalidad y performance como especificado y demostrador en el test de aceptaci n El cliente toma propiedad del software despu s de un test de aceptaci n exitoso Disciplina esencia de gt Mejor Pr ctica Requerimientos Desarrollar Administrar gt una clara visi n Requerimientos gt y un conjunto entendible de requerimientos e Esto involucra gt analizar el
22. rrollada y todas las prueba alpha si alguna ha sido completada Adem s al software un manual de usuario ha sido desrarrollado y hay una descripci n del release actual Criterio de Evaluaci n El criterio de evaluaci n para la fase de Construcci n involucra las respuestas a esta cuetiones b Es el release del producto estable y suficiente maduro para ser desplegado en la Ing Manuel Pe aloza Figueroa 20 comunidad de usuarios Pb Est n todos los interesados listos para la transici n dentro de la comunidad de usuarios Son los actuales gastos de recursos VS lo planificado todav a aceptables La transici n tiene que ser pospuesta en un release si el proyecto falla alcanzar este hito 3 3 5 Artefactos C Artefactos esenciales en orden de Estado al milestone importancia El Sistema El sistema ejecutable mismo listo para comenzar una prueba beta RUP Plan de Desarrollo Versi n inicial desarrollada revisada y con base de l nea e En proyectos m s peque os esto puede esta encastrado incrustado en el Plan de Desarrollo de Software Modelo de Implementaci n Expandido desde que creado durante la fase y todos los artefactos consitutuyentes de Elaboraci n todos los elementos de incluyendo los Elementos de Implementaci n implementaci n creados para el final de la Componentes fase de Construcci n RUP Suite de Prueba prueba de humo Pruebas implem
23. t reemplazando Convertir BD s operacionales Entrenamiento de usuarios y personal de mantenimiento Extender las fuerzas de marketing distribuci n y ventas Y Y FY Y Ingenier a de desplegamiento espec fica tal como gt cutover gt empaquetamiento y producci n comercial gt ventas roll out z3 entrenamiento de personal de campo F Sintonizar activades tal como arreglar fijar bugs gt mejoramiento para performance y usabilidad b Valoraci n de las l neas de base de desplegamiento contra la visi n completa y los criterios de aceptaci n para el producto Pb Conseguir auto soportabilidad del usuario Conseguir concurrencia de los interesados que las l neas de base de desplegamiento Ing Manuel Pe aloza Figueroa 24 gt est n completas Conseguir concurrencia de los interesados que las l neas de base son consistentes con los criterios de la visi n 3 4 3 Actividades esenciales Las actividades esenciales de la fase de Transici n incluyen gt T YOY Y vv Ejecutar planes de desplegamiento Finalizar el material de soporte del usuario final Probar el producto entregable en el site de desarrollo Crear un release del producto Obtener realimentaci n del usuario Sintonizar finamente el producto basado en la realimentaci n Hacer el producto disponible a los usuarios finales 3 4 4 Hito Release del Producto El Hito Release del Producto es donde se decide si los objetivos del proyec
24. to fueron satisfechos y si se debe de arrancar otro ciclo de desarrollo En algunos casos este hito puede coincidir con el fin de la fase de Inicio para el siguiente ciclo El Hito Release del Producto es el resultado de la revisi n y aceptaci n por parte del cliente de los entregables del proyecto ver Actividad Revisar Aceptaci n del Proyecto Activity Project Acceptance Review Purpose For the customer to formally review and accept the project deliverables Steps Schedule Project Acceptance Review Meeting Distribute Meeting Materials Conduct Project Acceptance Review Meeting Record Decision Criterio de Evaluaci n El criterio de evaluaci n primario para la fase de Transici n involucra las respuestas a estas cuestiones b Est el usuario satisfecho Ing Manuel Pe aloza Figueroa 25 Son los gastos de recursos actuales VS los gastos planificados aceptables En el Hito Release del Producto el producto est en producci n y el ciclo de mantenimiento post release comienza Esto puede involucrar arrancar un nuevo ciclo o alg n release de mantenimiento adicional 3 4 5 Artefactos T Artefactos esenciales en orden de importancia Estado al milestone El Build del Producto Completa de acuerdo con los requerimientos del producto e El producto final debe de ser usable por el cliente RUP Material de Soporte para el Usuario Final Materiales que asisten al usua
25. ueroa 18 3 3 3 3 1 Fase Construcci n Meta La meta de la fase de construcci n es gt clarificar los requerimientos restantes gt y completar el desarrollo del sistema basado sobre la arquitectura con l nea de base La fase de Construcci n es en alg n sentido un manufacturaci n donde nfasis es colocado sobre gt la administraci n de recursos gt y el control de las operaciones para optimizar gt costos gt cronogramas schedules gt y calidad proceso de e En este sentido el esquema mental de la administraci n sufre experimenta una transici n desde el desarrollo de propiedad intelectual durante el Inicio y la Elaboraci n al desarrollo de productos desplegables durante Construcci n y Transici n 3 3 2 Objetivos Objetivos primarios P Minimizar los costos de desarrollo con optimizar recursos y evitar innecesario scrap y retrabajo Conseguir lograr adecuada calidad tanto r pidamente como pr ctica Conseguir lograr versiones tiles alpha beta y otros releases de prueba tanto r pidamente como pr ctica Completar el an lisis dise o desarrollo y prueba de toda la funcionalidad requerida Iterativamente e incrementalmente desarrollar un producto completo que est listo para transici n a su comunidad de usuarios Esto implica gt describir los casos de uso restantes y otros requerimientos gt elaborar el dise o gt completar la imp
Download Pdf Manuals
Related Search