s04 - Paradigma de desarrollo fundamentado en modelado
1 recomendación1,592 vistas
El documento describe el Proceso Unificado (UP) y su metodología para el desarrollo de software, centrándose en la importancia de tener una estructura clara y razones para cada paso en el proceso. Destaca la necesidad de un desarrollo iterativo que permita la identificación y corrección temprana de errores, y detalla aspectos como la gestión de requisitos, modelado visual y control de cambios. Además, enfatiza la relevancia de la arquitectura basada en componentes y el uso de casos de uso para garantizar la satisfacción del cliente y la calidad del producto final.
s04 - Paradigma de desarrollo fundamentado en modelado
- 1. 10/09/2009Universidad del CaucaDepartamento de TelemáticaPROCESO UNIFICADO (UP)Ambientes de Desarrollo
- 2. Definición de MetodologíaEs una forma explícita de estructurar el pensamiento y las acciones.
- 3. Contienen modelos y reflejan perspectivas particulares de la realidad basándose en un conjunto de paradigmas filosóficos.
- 4. Debería señalarnos “qué” pasos tomar y “cómo” llevarlos a cabo, pero más importante es definir las razones del “por qué” esos pasos se deben tomar en ese orden.A tener en cuenta...Las metodologías siempre reflejan el punto de vista de sus creadores
- 5. Los usuarios de las metodologías las interpretan según su punto de vista
- 6. Un autor nunca menciona las debilidades de su creaciónRequisitos y AnálisisDiseñoImplementaciónPruebasMantenimientoModelos y estilos 1/4
- 7. Recoleccióny refinamiento derequisitosProductoDiseñorápidoRefinamientodel prototipoConstruccióndel prototipoEvaluación delprototipo porel clienteModelos y estilos 2/4
- 9. PROGRESOA TRAVÉSDETERMINAR OBJETIVOS,ALTERNATIVAS YRESTRICCIONESDE LAS ITERACIONESEVALUAR ALTERNATIVAS,IDENTIFICAR Y RESOLVER RIESGOSAnálisis de riesgosAnálisis de riesgosAnálisis de riesgosPrototipooperativoPrototipo 3An.Riesgo.Proto-tipo 1Prototipo 2-REVISIÓNPlan de requerimientosPlan de ciclo de vidaSimulaciones, modelos,pruebas comparativas.Concepto deoperaciónRequerimientosde softwareDiseño delproductoDiseñodetalladoPlan dedesarrolloValidación derequerimientosCodificarPlan de integracióny pruebaDiseño de validacióny verificaciónPrueba deunidadPLANIFICAR SIGUIENTEFASEPrueba deintegraciónPrueba deaceptación-ExplotaciónDESARROLLAR, VERIFICARPRODUCTO DE SIGUIENTE NIVELModelos y estilos 4/4
- 10. RUPProceso Unificado de RationalProceso de Desarrollo de Software soportado en el Lenguaje Unificado de Modelado, y que es iterativo, centrado en la arquitectura y dirigido por casos de uso
- 11. OrígenesMétodo EricssonMétodo de RationalProceso ObjectoryUMLOtras FuentesProceso Objectory de RationalProceso Unificado de Rational
- 12. Principios del RUPDesarrollo Iterativo del Software,
- 14. Uso de Arquitecturas Basadas en Componentes,
- 15. Modelado Visual del Software,
- 16. Verificación de la Calidad del Software,
- 17. Control de Cambios.Principios o mejores prácticas del RUPAdministración de requisitosDesarrolloiterativoModelamientovisualVerificación dela calidadArquitecturascon componentesControl de cambios
- 18. Desarrollo iterativode aplicacionesDada la complejidad de las aplicaciones y programas actuales, es posible hacer de manera secuencial la definición completa del problema, diseñar la solución completa, construir la aplicación y por probarla.El descubrimiento de faltas de conformidad con los requisitos en fases posteriores de diseño dan como resultado un aumento en los costos y/ó la cancelación del proyecto.El tiempo y dinero gastados en la implementación de undiseño fallido, son no recuperables.
- 19. RequisitosAnálisis y DiseñoImplementaciónEvaluaciónPruebasDesarrollo IterativoCada iteraciónproduce un producto ejecutable
- 20. Características deldesarrollo iterativoPermite un entendimiento incremental del problema a través de refinamientos sucesivos.Posibilita una fácil interacción y retroalimentación de usuario.Metas específicas permiten que el equipo de desarrollo mantenga su atención en producir resultados.El progreso es medido conforme avanzan las implementaciones.
- 21. Administración de RequisitosElicitar, organizar, y documentar la funcionalidad y restricciones requeridas.Llevar un registro y documentación de cambios y decisiones.Los requerimientos de negocio son fácilmente capturados y comunicados a través de casos de uso.Los casos de uso son instrumentos importantes de planeación.
- 22. Arquitectura basadaen componentesSe enfoca en el rápido desarrollo de una arquitectura ejecutable robusta, con las siguientes características:resistente al cambio mediante el uso de interfaces bien definidas,intuitivamente comprensible,promueve un reuso más efectivo de código,es derivada a partir de los casos de uso más importantes.
- 23. Modelación visualde aplicacionesCaptura la estructura y comportamiento de arquitecturas y componentes.Muestra cómo encajan de forma conjunta los elementos del sistema.Mantiene la consistencia entre un diseño y su implementación.Promueve una comunicación no ambigua entre participantes.
- 24. Verificación de la calidadde las aplicacionesCrea pruebas para cada escenario para asegurar que todos los requisitos están propiamente implementados.Verifica la calidad de la aplicación con respecto a los requisitos basados en la confiabilidad, funcionalidad, desempeño de la aplicación y del sistema.Prueba cada iteraciónLos problemas de las aplicaciones son de 200 a 500 veces más costosos de encontrar y reparar después del desarrollo.
- 25. Control de cambiosde las aplicacionesControlar, llevar un registro, y monitorear cambios para permitir un desarrollo iterativo.Establece espacios de trabajo seguros para cada desarrolladorProvee aislamiento de cambios hechos en otros espacios de trabajoControla todos los artefactos de software – modelos, código, documentos, etc…
- 26. CaracterísticasDirigido por Casos de UsoCentrado en ArquitecturaIterativo e incremental
- 27. Dirigido por Casos de Uso 1/2Se centra en la funcionalidad que el sistema debe poseer para satisfacer las necesidades de un usuario (persona, sistema externo, dispositivo) que interactúa con él
- 28. Casos de uso como el hilo conductor que orienta las actividades de desarrolloDirigido por Casos de Uso 2/2
- 29. Centrado en la Arquitectura 1/2Describe diferentes vistas del sistema en construcción
- 30. Incluye los aspectos estáticos y dinámicos más significativos
- 31. Plataforma en la que va a operar
- 33. Requisitos funcionales y no funcionalesCentrado en la Arquitectura 2/2
- 34. Relación Casos de Uso y ArquitecturaLa funciónCasos de UsoLa formaArquitectura
- 35. Registrarse al servicioVer VideoVisitanteBuscar VideosGestionar VideosSuscriptorAdministradorModificar InformaciónGestionar SuscriptoresEjemplo de Caso de Uso (SVV)
- 36. Java appletJMFjava.netBrowserHTML PagesHTTPJava Server PagesJServerJ2EEApacheWeb ServerOracle8iVideosBusiness objectsJava BeansEjemplo de Arquitectura (SVV)
- 37. Proceso Iterativo e IncrementalDescomposición de un proyecto grande en mini-proyectos
- 38. Cada mini-proyecto es una iteración
- 39. Las iteraciones deben estar controladas
- 40. Cada iteración trata un conjunto de casos de usoRUP - terminología 1/3Ciclo: cada ciclo una nueva versión del productoFase: Etapas de un ciclo que finalizan en un HITOIteración: Proceso de ingeniería sobre una funcionalidad limitada del sistema
- 41. RUP - terminología 2/3Rol: Definición del comportamiento y responsabilidades de los participantesActividad: Unidad de trabajo que puede ejecutar un individuo en un rol específicoArtefacto: Pieza de información producida, modificada y utilizada en un proceso
- 42. RUP - terminología 3/3Flujo de Trabajo: Forma de describir significativamente la secuencias de actividades que producen resultados y las interacciones entre cargosHito: Punto en el tiempo en donde se evalúan objetivos logrados y se pueden tomar decisiones críticas
- 43. Organización por ComponentesFlujos de trabajo yactividadesArtefactosTrabajadoresAgrupan las actividades de acuerdo a su naturalezaRepresentan la estructura del Proceso.Expresados en términos de:
- 44. Diseño deCasos de usoCaso de UsoPaquete deCaso de UsoIdea del procesoTrabajador¿Quién?Actividad¿Cómo?Describe una unidad de trabajo que puede ser asignada a un trabajador.Rol que puede ser desempeñado por un individuo o conjunto de individuos en la organización de desarrolloDiseñadorArtefacto¿Qué?responsable dePieza de información que es producida, modificada, ó utilizada por un proceso
- 45. 10/09/2009Organización porOrganización en el tiempoComponentesFASESCOMPONENTES DEL PROCESOModelado de la OrganizaciónCaptura de RequisitosGestaciónPreparaciónConstrucciónTransiciónAnálisisDiseñoImplementaciónPruebasPuesta en ServicioCOMPONENTES DE SOPORTEGestión de Configuración y CambiosGestión del ProyectoEntornoPrep.#1Prep.#2Const.#1Const.#2Const.#NTrans.#1Trans.#2InicialIteracionesFlujos de Trabajo 1/2
- 46. 10/09/2009SatisfacciónDel ClienteAlcances yObjetivosVersión BetaArquitecturaInicioElaboraciónConstrucciónTransiciónFases:IteraciónIteraciónIteraciónIteraciónIteraciones:RequerimientosAnálisis y DiseñoEntregasInternasCodificaciónDisciplinas:Prueba Admin. ProyectoGestión Configuracióny CambioFlujos de Trabajo 2/2
- 48. 10/09/2009RequisitosRequisitosAnálisisAnálisisDiseñoDiseñoRelación TemporalImplementaciónImplementaciónPruebasPruebasTrabajadores y flujos de trabajo 1/2Estructurar el Modelo de Casos de UsoPlanear pruebaDiseñar pruebaEvaluar pruebaEncontrar actores y casos de usoDetallar un caso de usoIntegrar sistemaConstruir prototipo de Interfaz de usuarioRealizar pruebas de integraciónPriorizar casos de usoImplementación de la arquitecturaAnalizar la arquitecturaRealizar pruebas de sistemaDiseño de la arquitecturaAnalizar un caso de usoDiseñar un caso de usoactividadesAnalizar una claseImplementar una claseImplementar pruebasDiseñar una claseDiseñar un subsistemaAnalizar un paqueteImplementar un subsistemaRealizar pruebas de unidad
- 49. 10/09/2009Estructurar el Modelo de Casos de UsoPlanear pruebaDiseñar pruebaEvaluar pruebaEncontrar actores y casos de usoAnalistaEspecificadorDiseñadorArquitectoCasos de UsoComponentesPruebasIntegradorIntegraciónSistemaDetallar un caso de usoIntegrar sistemaConstruir prototipo de Interfaz de usuarioRealizar pruebas de integraciónPriorizar casos de usoImplementación de la arquitecturaAnalizar la arquitecturaRealizar pruebas de sistemaDiseño de la arquitecturaAnalizar un caso de usoDiseñar un caso de usoRequisitosAnálisisAnalizar una claseImplementar una claseImplementar pruebasDiseñar una claseDiseñar un subsistemaDiseñoRelación TemporalImplementaciónAnalizar un paqueteImplementar un subsistemaRealizar pruebas de unidadactividadesPruebasTrabajadores y flujos de trabajo 2/2
- 51. 10/09/2009Herramientas de Apoyo al ProcesoGestión de Requisitos,
- 52. Modelado Visual,
- 54. Aseguramiento de la Calidad,
- 55. Control de versiones, gestión de la configuración, seguimiento de defectos, documentación, gestión del proyecto y automatización de procesos.Variantes del UP