Análisis Semántico M.C. Juan Carlos Olivares Rojas Noviembre 2009.
Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.
-
Upload
emygdio-tesoro -
Category
Documents
-
view
218 -
download
0
Transcript of Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.
![Page 1: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/1.jpg)
Análisis del Proyecto
M.C. Juan Carlos Olivares Rojas
Marzo 2010
![Page 2: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/2.jpg)
• Específica: aplica técnicas de análisis para mitigar los riesgos y mejorar la calidad del software.
• Genéricas• Instrumentales: Capacidad de análisis y
síntesis, Capacidad de organizar y planificar, Conocimientos básicos de la carrera, Comunicación oral y escrita en su propia lengua, Habilidades de gestión de información, Solución de problemas, Toma de decisiones.
Competencias
![Page 3: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/3.jpg)
• Interpersonales: Capacidad crítica y autocrítica, Capacidad de trabajar en equipo interdisciplinario, Capacidad de comunicarse con profesionales de otras áreas, Compromiso ético.
• Sistémicas: Habilidades de investigación, Capacidad de adaptarse a nuevas situaciones, Capacidad de generar nuevas ideas (creatividad), Liderazgo, Capacidad para diseñar y gestionar proyectos, Iniciativa y espíritu emprendedor, Preocupación por la calidad, Búsqueda del logro.
Competencias
![Page 4: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/4.jpg)
• Análisis de Riesgos* (visto al final de la unidad 2)
• Control de Calidad
• Metodología OpenUP (Proceso Unificado)
• Técnicas de Análisis
Saberes
![Page 5: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/5.jpg)
• 10% Actividades realizadas en el salón de clases evaluables
• 30% Desarrollo del proyecto (seguimiento de actividades en base a su planeación)
• 60% Actividad de Evaluación Final (Teórico-Práctico)
Evidencias
![Page 6: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/6.jpg)
Otra categoría de riesgos
Riesgos conocidos
Riesgos predecibles
Riesgos impredecibles
*Los riesgos se deben identificar y tratar de minimizarlos**Se deben priorizar los riesgos
Tipos de
Riesgos
Son aquellos que se pueden descubrir con una cuidadosa evaluación del plan del proyecto de su entorno técnico
Son aquellos que podemos extrapolar de proyectos anteriores o de nuestra experiencia
Son extremadamente difíciles de identificar
![Page 7: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/7.jpg)
Ejemplo de RiesgosRiesgo Tipo de riesgo
Rotación del personal Proyecto
Cambio de administración Proyecto
Hardware indisponible Proyecto
Cambio de requerimientos
Proyecto y producto
Retrasos en la especificación
Proyecto y producto
Subestimación del tamaño
Proyecto y producto
Bajo desempeño de la herramienta CASE
Producto
Cambio de tecnología Negocio
Competencia del producto
Negocio
![Page 8: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/8.jpg)
Ejemplo de RiesgosTIPO DE RIESGO EJEMPLOS DE POSIBLES RIESGOS
Tecnología: se derivan de tecnología de SW o HW
o la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba
o los componentes de software a reutilizar tienen defectos que limitan su funcionalidad
Personal: asociadas al equipo de desarrollo
o imposible contratar personal con los conocimientos requeridoso personal clave enfermo o no disponible en momentos críticos
Organizacionales: al entorno donde se desarrolla el
software
o la organización se reestructura y una nueva administración se responsabiliza del proyecto
o los problemas financieros de la organización reducen el presupuesto del proyecto
Herramientas: asociado a herramientas case y de
apoyo
o las herramientas CASE generan código ineficienteo las distintas herramientas CASE no se pueden integrar
Requerimientos: derivado de los cambios requeridos
por el cliente
o cambios de requerimientos que precisan modificaciones en el diseñoo los clientes no comprenden el impacto de los cambios en los
requerimientos
Estimación: derivado de los estimados
administrativos y los recursos requeridos
o el tiempo requerido para desarrollar el software está subestimadoo la tasa de reparación de defectos está subestimadao el tamaño del software está subestimado
![Page 9: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/9.jpg)
Riesgos en OpenUP
Riesgos técnicos
Riesgos No técnicos
1. Riesgos relacionados con nuevas tecnologías.
2. Riesgos relativos a la arquitectura.
3. Riesgos relativos a construir el sistema adecuado, es decir, que cumpla con su objetivo y con sus usuarios.
4. Riesgos relativos al rendimiento.1. Gente sin experiencia en el proyecto2. El calendario propuesto del cliente
es muy corto.3. El cliente no realiza las aprobaciones
en el tiempo establecido 4. Existan terceras personas
subcontratadas con las que no se ha trabajado antes.
![Page 10: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/10.jpg)
Control de RiesgosRiesgo Estrategia
Problemas financieros de la organización
Preparar un documento breve para la dirección de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio
Problemas de reclutamientoorganizar cursos de capacitación para el personal ya existente, investigar
la posibilidad de contratar en otras regiones o países
Enfermedad del personalreorganizar el equipo de tal forma que se solapen el trabajo y los
miembros del equipo comprendan el trabajo de los demás
Componentes defectuososreemplazar los componentes defectuosos con los comprados de
fiabilidad conocida
Cambios en los requerimientosrastrear la información para valorar el impacto de los requerimientos,
maximizar la información oculta en ellos
Reestructuración organizativapreparar un documento breve para la dirección de la empresa que
muestra que el proyecto hace contribuciones muy importantes a las metas del negocio
Rendimiento de la base de datos
investigar la posibilidad de comprar una base de datos con el rendimiento preciso
Tiempo de desarrollo subestimado
alertar al cliente de las dificultades potenciales y las posibilidades de retraso
![Page 11: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/11.jpg)
• ¿Qué tiene más calidad?
Los dos tienen la misma
calidad siempre y cuando
cumplan con sus
requerimientos
Para ello debemos
probar sus especificacione
s
![Page 12: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/12.jpg)
Calidad del software• La calidad es un concepto muy asbtracto
de definir.
• Algunas definiciones básicas de calidad:
• Cualidad o conjunto de cualidades de una persona o cosa que permiten compararla con otras de su especie.
• Enfocadas al cumplimiento de los requerimientos.
Introducción
![Page 13: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/13.jpg)
Calidad del software• Orientados hacia la satisfacción del
cliente.• Orientados hacia la productividad (0
defectos)• Tipos de Calidad
Introducción
GESTIÓN DE LA CALIDAD
![Page 14: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/14.jpg)
Calidad del software• Algunos ejemplos de falta de calidad en
el software:
• El programa no está probado
• El sistema operativo está incompleto
• No están escritos los requisitos
• Estamos fuera de tiempo en un proyecto
Introducción
![Page 15: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/15.jpg)
• Es una actividad que se debe desarrollar a lo largo del proceso de desarrollo de software, el cual incluye:– Políticas de calidad– Métodos y herramientas de software efectivo– Revisiones Técnicas Formales– Prueba Multiescalares– Documentación– Manejo de métricas e indicadores– etc.
Control de Calidad
![Page 16: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/16.jpg)
• La calidad debe de ser mensurable.
• La garantía o aseguramiento de la calidad (QA , Quality Assurance) sólo se puede realizar a través de un proceso de seguimiento, por lo tanto la calidad también se planea en el sentido de las técnicas que se usarán para lograr el éxito del proyecto.
• La calidad como todo proceso tiene costo, pero es más costoso no tener calidad.
Control de Calidad
![Page 17: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/17.jpg)
• El proceso más básico de control de calidad es la inspección, que en el área de desarrollo de software son los RTF.
• Los RTF sirven de filtro para detectar y corregir defectos. Generalmente se aplican en la etapa de diseño que es donde hay más errores de desarrollo (50-60%).
• Se debe de revisar al producto no al personal.
Control de Calidad
![Page 18: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/18.jpg)
• El proceso más básico de control de calidad es la inspección, que en el área de desarrollo de software son los RTF.
• Los RTF sirven de filtro para detectar y corregir defectos. Generalmente se aplican en la etapa de diseño que es donde hay más errores de desarrollo (50-60%).
• Se debe de revisar al producto no al personal.
Control de Calidad
![Page 19: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/19.jpg)
• Se debe tener una agenda (plan de trabajo)
• Se deben evitar impugnaciones• Los problemas se enuncian más no se
resuelven en ese momento• Deben existir reuniones periódicas
• El control de calidad por excelencia es el control estadístico.
Control de Calidad
![Page 20: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/20.jpg)
• Originado como resultado de la compra de Rational creador de RUP por parte de IBM.
• UP es toda una metodología para el desarrollo de software:
• Se caracteriza por ser una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo).
OpenUP
Requisitos del usuario Sistema de softwareProceso de desarrollode software
![Page 21: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/21.jpg)
• Su objetivo es Asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones).
• También es considerado un producto:• Desarrollado y mantenido por la comunidad
libre• Actualizado constantemente para tener en
cuenta las mejores prácticas de acuerdo con la experiencia.
OpenUP
![Page 22: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/22.jpg)
• Aumenta la productividad de los desarrolladores mediante acceso a:• Base de conocimiento, plantillas y herramientas.
• Se centra en la producción y mantenimiento de modelos del sistema más que en producir documentos.
• UP es una guía de cómo usar UML de la forma más efectiva.
• Existen herramientas de apoyo a todo el proceso: Modelamiento visual, programación, pruebas, etc.
OpenUP
![Page 23: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/23.jpg)
• UP pretende implementar las mejores prácticas actuales en ingeniería de software:
• Desarrollo iterativo del software• Administración de requerimientos• Uso de arquitecturas basadas en componentes• Modelamiento visual del software• Verificación de la calidad del software• Control de cambios
OpenUP
![Page 24: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/24.jpg)
• Desarrollo Iterativo:
• El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada.
• Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema.
• UP sigue un modelo iterativo que aborda las tareas más riesgosas primero. Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.
OpenUP
![Page 25: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/25.jpg)
• Administración de Requerimientos:
• Obtener los requerimientos
• Organizarlos
• Documentar requerimientos de funcionalidad y restricciones
• Rastrear y documentar decisiones
• Captar y comunicar requerimientos del negocio
OpenUP
![Page 26: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/26.jpg)
• Arquitectura basada en Componentes:
• El proceso se basa en diseñar tempranamente una arquitectura base ejecutable.
• La arquitectura debe ser:• Flexible• Fácil de modificar• Intuitivamente comprensible• Promueve la reutilización de componentes
OpenUP
![Page 27: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/27.jpg)
• Modelamiento visual de la estructura y el comportamiento de la arquitectura y los componentes.
• Bloques de construcción:• Ocultan detalles• Permiten la comunicación en el equipo de
desarrollo• Permiten analizar la consistencia:• entre las componentes• entre diseño e implementación
OpenUP
![Page 28: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/28.jpg)
• Verificación de cualidades:
• No sólo la funcionalidad es esencial, también el rendimiento y la confiabilidad.
• UP ayuda a planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen estas cualidades.
• El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.
OpenUP
![Page 29: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/29.jpg)
• Control de Cambios:
• Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto.
• UP indica como controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo.
OpenUP
![Page 30: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/30.jpg)
• UP divide el proceso de desarrollo en ciclos, teniendo un producto al final de cada ciclo.
• Cada ciclo se divide en cuatro Fases:• Inicio• Elaboración• Construcción• Transición
• Cada fase concluye con un hito bien definido donde deben tomarse ciertas decisiones.
OpenUP
![Page 31: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/31.jpg)
• Fases de UP
OpenUP
![Page 32: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/32.jpg)
• Fase de Inicio
• Se establece la oportunidad y alcance el proyecto.
• Se identifican todas las entidades externas con las que se trata (actores) y se define la interacción a un alto nivel de abstracción:
• Identificar todos los casos de uso• Describir algunos en detalle
OpenUP
![Page 33: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/33.jpg)
• La oportunidad del negocio incluye:• Criterios de éxito• Identificación de riesgos• Estimación de recursos necesarios• Plan de las fases incluyendo hitos
– Productos:– Un documento de visión general:
• Requerimientos generales del proyecto• Características principales• Restricciones• Modelo inicial de casos de uso (10% a 20 % listos).• Glosario.
OpenUP
![Page 34: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/34.jpg)
• Caso de negocio:• Contexto• Criterios de éxito• Pronóstico financiero• Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.
OpenUP
![Page 35: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/35.jpg)
• Hito:
– Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo.
– Comprensión de los requerimientos plasmados en casos de uso.
OpenUP
Inicio Elaboración Construcción Transición
Objetivos del Ciclo de Vida
![Page 36: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/36.jpg)
• Fase de Elaboración
• Objetivos:• Analizar el dominio del problema• Establecer una arquitectura base sólida• Desarrollar un plan de proyecto• Eliminar los elementos de mayor riesgo para el
desarrollo exitoso del proyecto
• Visión de “una milla de amplitud y una pulgada de profundidad” porque las decisiones de arquitectura requieren una visión global del sistema.
OpenUP
![Page 37: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/37.jpg)
• Productos:
• Es la parte más crítica del proceso• Se puede decidir si vale la pena seguir adelante
• A partir de aquí la arquitectura, los requerimientos y los planes de desarrollo son estables.
• Ya hay menos riesgos y se puede planificar el resto del proyecto con menor incertidumbre.
OpenUP
![Page 38: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/38.jpg)
• Se construye una arquitectura ejecutable que contemple:
• Los casos de uso críticos• Los riesgos identificados
• Modelo de casos de uso (80% completo) con descripciones detalladas.
• Otros requerimientos no funcio-nales o no asociados a casos de uso.
• Descripción de la Arquitectura del Software.
OpenUP
![Page 39: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/39.jpg)
• Un prototipo ejecutable de la arquitectura.
• Lista revisada de riesgos y del caso de negocio.
• Plan de desarrollo para el resto del proyecto.
• Un manual de usuario preliminar.
OpenUP
![Page 40: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/40.jpg)
• Hito:
• Condiciones de éxito de la elaboración:• ¿Es estable la visión del producto?• ¿Es estable la arquitectura?• ¿Las pruebas de ejecución demuestran que los
riesgos han sido abordados y resueltos?• ¿Es el plan del proyecto algo realista?• ¿Están de acuerdo con el plan todas las
personas involucradas?
OpenUP
Concepción Elaboración Construcción Transición
Arquitectura de Ciclo de Vida
![Page 41: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/41.jpg)
• Construcción:
• En esta fase todas las componentes restantes se desarrollan e incorporan al producto. Todo es probado en profundidad.
• El énfasis está en la producción eficiente y no ya en la creación intelectual.
• Puede hacerse construcción en paralelo, pero esto exige una planificación detallada y una arquitectura muy estable.
OpenUP
![Page 42: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/42.jpg)
• Productos:
• El producto de software integrado y corriendo en la plataforma adecuada.
• Manuales de usuario.
• Una descripción del “release” actual.
OpenUP
![Page 43: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/43.jpg)
• Hito:
• Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito:• ¿El producto está maduro y estable para
instalarlo en el ambiente del cliente?• ¿Están los interesados listos para recibirlo?
OpenUP
Concepción Elaboración Construcción Transición
CapacidadOperacional
![Page 44: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/44.jpg)
• Transición:
• El objetivo es traspasar el software desarrollado a la comunidad de usuarios.
• Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos).
• Incluye:• Pruebas Beta para validar el producto con las
expectativas del cliente• Ejecución paralela con sistemas antiguos
OpenUP
![Page 45: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/45.jpg)
• Conversión de datos• Entrenamiento de usuarios• Distribuir el producto
• Los objetivos de la fase de transición:
• Obtener autosuficiencia de parte de los usuarios.
• Concordancia en los logros del producto de parte de las personas involucradas.
• Lograr el consenso cuanto antes para liberar el producto al mercado.
OpenUP
![Page 46: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/46.jpg)
• Hito:
• En esta etapa se obtiene el software final.
OpenUP
Concepción Elaboración Construcción Transición
Producto
![Page 47: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/47.jpg)
• Definiciones:
• Un trabajador define el comportamiento y las responsabilidades de un individuo.
• Es como un “sombrero” que la persona usa durante el proyecto:
• Una persona puede tener varios sombreros• Es el rol que desempeña en un momento dado• Responsabilidades:• Hacer una serie de actividades• Ser el responsable de una serie de artefactos
OpenUP
![Page 48: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/48.jpg)
• Actividades:
• Una actividad es una unidad de trabajo que se asigna a un trabajador. Ej.:• Crear o modificar un artefacto
• Una actividad lleva entre un par de horas y un par de días, involucra un solo trabajador y un número pequeño de artefactos.
OpenUP
![Page 49: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/49.jpg)
• Las actividades se consideran en la planificación y evaluación del progreso del proyecto.
• Ejemplos:• Planificar una iteración - Administrador de
proyecto• Encontrar actores y casos de uso - Analista• Revisar el diseño - Revisor de diseño• Ejecutar pruebas de performance - Ing. de
pruebas de performance
OpenUP
![Page 50: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/50.jpg)
• Asignación de Actividades:
OpenUP
Recurso Trabajador Actividad
Pablo Diseñador Diseño de Objetos
María Autor de Casos de Uso Detallar un Caso de Uso
José Diseñador de Casos de Uso Diseñar un Caso de Uso
Silvia Revisor de Diseño Revisar el Diseño
Eduardo Arquitecto Análisis de Arquitectura Diseño de Arquitectura
![Page 51: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/51.jpg)
• Artefactos:
• Elementos de información producidos, modificados o usados por el proceso.
• Son los productos tangibles del proyecto.
• Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades.
OpenUP
![Page 52: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/52.jpg)
• Flujos de Trabajo:
• Una lista de actividades, trabajadores y artefactos constituye un proceso.
• Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso.
• No siempre es posible representar flujos de trabajo.
OpenUP
![Page 53: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/53.jpg)
• Flujos de Trabajo:
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
![Page 54: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/54.jpg)
• Flujos de Trabajo Esenciales:
OpenUP
Flujos de Trabajode Ingeniería
Flujos de Trabajode Apoyo
![Page 55: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/55.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Existen habitualmente problemas de comunicación entre ingenieros de software e ingenieros de negocios.
• UP proporciona un lenguaje y proceso común para estos dos ámbitos.
• Para el modelamiento del negocio se usan “business use cases” (casos de uso del negocio):
• La forma en que el software dará apoyo al negocio.
![Page 56: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/56.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Requerimientos:
• Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer:
• Relevar requerimientos• Documentar funcionalidad y restricciones• Documentar decisiones• Identificar actores• Identificar casos de uso
![Page 57: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/57.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Los casos de uso describen la funcionalidad.
• Los requerimientos no funcionales se incluyen en una especificación complementaria.
Cliente Reciclar
Imprimir Informe
Operador
Administrar Depósito
![Page 58: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/58.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Análisis y Diseño:
• Descripción de cómo se implementará el sistema: un plano
• Debe:• Ejecutar las tareas y funciones descritas
en los casos de uso• Satisfacer todos los requerimientos• Flexible a cambios
![Page 59: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/59.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• El diseño se centra en la noción de arquitectura.
• Diseñar y validar la arquitectura es una tarea esencial.
• El modelo de diseño consta de • Clases estructuradas en paquetes• Diseños de subsistemas con interfaces
definidas (componentes)• Forma de colaboración entre las clases.
![Page 60: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/60.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Implementación
• Propósito:
• Definir la organización del código• Implementar clases y objetos en forma de
componentes (fuente, ejecutables, etc.)• Probar las componentes desarrolladas• Integrar las componentes en un sistema
ejecutable
![Page 61: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/61.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Pruebas:
• Propósito:• Verificar la interacción entre los objetos• Verificar la integración apropiada de
componentes• Verificar que se satisfacen los
requerimientos• Identificar los defectos y corregirlos antes
de la instalación
![Page 62: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/62.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• UP describe como planear y ejecutar estas pruebas.
• UP propone probar las componentes desde el principio:
• Confiabilidad, funcionalidad y performance
• Las pruebas de regresión son importantes en desarrollos iterativos.
![Page 63: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/63.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Distribución:
• Producir un producto y hacerlo llegar a sus usuarios finales.
• Incluye varias actividades:• Producir un “release”• Empaquetar el software• Distribuir el software• Instalar el software• Apoyar a los usuarios
![Page 64: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/64.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Administración de Proyectos:
• Es el arte de balancear objetivos contrarios, manejar riesgos y producir software que satisface a clientes y usuarios.
• UP incluye:
• Un framework para manejo de proyectos de software
![Page 65: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/65.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Guías para planificación, provisión de personal, ejecución y monitoreo de planes
• Un framework para manejar riesgos
• Administración de Configuración y del Cambio:
• Forma de controlar los artefactos producidos por las personas que trabajan en el proyecto.
![Page 66: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/66.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Algunos problemas habituales:• Actualizaciones simultáneas• Múltiples versiones
• UP da guías para:• Desarrollos en paralelo• Automatizar la construcción• Administrar defectos
![Page 67: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/67.jpg)
OpenUP
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Ambiente:
• Ambiente y herramientas de desarrollo que harán posible llevar a cabo el proyecto.
• UP guía en la configuración de un ambiente de proceso apropiado a cada proyecto.
![Page 68: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/68.jpg)
Modelado
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Es la primera fase creativa del desarrollo de proyectos. Se compone de lo qué es análisis y diseño.
• El modelado parte de lo que es la Ingeniería de Requerimientos y devuelve un modelo que puede ser construido (implantable a través de lenguajes de programación).
![Page 69: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/69.jpg)
Modelado
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• En análisis estructurado se utiliza la técnica de Diagrama de Flujo para especificar procesos, Diagrama Entidad-Relación para especificar datos y diagramas de transición de estados para control. Diagramas de contexto o de Flujo de Datos Nivel 1 para indicar arquitectura.
• Para el modelado de datos se recomienda definir todos los objetos (entidades) y definir sus atributos.
![Page 70: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/70.jpg)
Modelado
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• El diseño es la primera parte del desarrollo de cualquier proyecto.
• Etimológicamente significa componer, por lo que se obtiene la solución que habrá de implantarse.
• Todas las cosas siempre tienen primero una creación mental.
![Page 71: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/71.jpg)
Modelado
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• El diseño en proyectos informáticos presenta cuatro apartados: datos, arquitectura, interfaz y procedimientos.
• El diseño de datos se encarga de transformar el modelo de información obtenido en el proceso de análisis en estructuras de datos. Se pueden utilizar diagramas entidad-relación pero especificados a mayor detalle.
![Page 72: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/72.jpg)
Modelado
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• El diseño arquitectónico tiene la finalidad de comprobar las relaciones con los diferentes módulos o macrorequisitos del sistema (subsistemas).
• El diseño de interfaz define como se comunica el software consigo mismo y hacia el exterior.
![Page 73: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/73.jpg)
Modelado
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• El diseño procedimental o basado en componentes consiste en la traducción de cada uno de los elementos obtenidos en la especificación de procesos, datos y transición hacia elementos implantables a través de computadoras.
![Page 74: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/74.jpg)
Modelado
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• El proceso de diseño sirve de base para la codificación del sistema. Se deben seguir algunas recomendaciones para su mejor desarrollo como las siguientes:
• Se deben especificar todos los elementos explícitos e implícitos del modelo de análisis.
![Page 75: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/75.jpg)
Modelado
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• El diseño deber servir de guía para que cual integrante del proyecto pueda construir y entender el software.
• El diseño debe de dar una completa idea de lo que es el software.
• El diseño debe presentar uniformidad e integración. Se deben definir reglas y estilos que deben seguir los miembros del equipo.
![Page 76: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/76.jpg)
Modelado
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• El diseño debe estar estructurado, de tal forma que permita cambios.
• El diseño no es escribir código, ni codificar es diseñar.
• Al diseñar se deben tomar en cuenta Factores de Calidad Externos (velocidad, Fiabilidad, utilidad) y Factores de Calidad Interno (abstracción, refinamiento, modularidad).
![Page 77: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/77.jpg)
UML
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• UML (Unified Modelling Language), lenguaje de modelado unificado. Fue desarrollado en 1997 al fusionar las metodologías de Ivar Jacobson, Jame Rumbaugh y Grady Booch.
• Es un lenguaje visual, su premisa básica radica en que una imagen vale más que 1,000 líneas de código.
![Page 78: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/78.jpg)
UML
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Al ser UML un lenguaje posee gramáticas y alfabetos que definen como deben de estructurarse cada una de las palabras válidas del lenguaje.
• Un modelo es una representación de la realidad. No sólo se modela software sino prácticamente cualquier actividad.
![Page 79: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/79.jpg)
UML
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Es el lenguaje estándar para modelar proyectos de software.
• La versión más actual del lenguaje es la 2.2 definida en 2009.
• Los métodos que se fusionaron para crear UML fueron OMT (Rumbaugh), Objectory (Jacobson) y el método Booch.
![Page 80: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/80.jpg)
UML
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Casi el 80% de los proyectos de software fallan.
• Nadie construye una casa sin un plano.
• Actualmente existen muchas herramientas que auxilian el proceso de modelado como Visio, ArgoUML, Rational Rose, Together, etc.
![Page 81: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/81.jpg)
Modelos
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Los modelos deben ser más baratos que la realidad.
• Es más fácil para una persona entender un diagrama que las líneas de código fuente de un programa.
• Los diagramas al igual que el texto consumen tiempo.
![Page 82: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/82.jpg)
Modelos
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Se deben construir modelos que sean representativos para que sean útiles (imaginense hacer un documento de 100 hojas que nadie va a leeer)
• UML define varios tipos de diagramas los cuales pueden ser extensibles.
![Page 83: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/83.jpg)
UML
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• UML tiene 5 diferentes vistas con diferentes diagramas en cada una de ellas.
• Vista usuario: representa el sistema (producto) desde la perspectiva del usuario. Se suele utilizar diagramas de casos de uso.
![Page 84: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/84.jpg)
UML
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Vista estructural: modela los datos y la funcionalidad del sistema; es decir, la estructura estática (clases y relaciones).
• Vista de implementación: Los aspectos estructurales y de comportamiento se representan aquí tal y como van a ser implementados. (Diagrama de actividades y estados)
![Page 85: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/85.jpg)
UML
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Vista del comportamiento: representa los aspectos dinámicos o de comportamiento del sistema. También muestra las interacciones o colaboraciones entre los diversos elementos estructurales descritos en vistas anteriores.
• Vista del entorno: aspectos estructurales de comportamiento en el que el sistema a implementar se representa (diagramas de componentes y despliegue).
![Page 86: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/86.jpg)
UML
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Los diagramas más utilizados en UML son:
• Diagramas de casos de uso• Diagramas de actividades• Diagramas de clases• Diagramas de interacción
– Diagramas de secuencia– Diagramas de colaboración
![Page 87: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/87.jpg)
UML
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Diagramas de estado• Diagramas de componentes• Otros diagramas
– Diagrama de topología del despliegue
• Los diagramas deben de reflejar lo que se pretende modelar
![Page 88: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/88.jpg)
Preguntas Frecuentes
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• ¿Cuántos diagramas debo crear? No existe una respuesta específica.
• ¿Debo hacer diagramas de todo tipo? No, sólo se deben utilizar los diagramas que mejor reflejen el modelado de la problemáticao.
![Page 89: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/89.jpg)
Preguntas Frecuentes
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• ¿Qué tan grande debe de ser un diagrama? Entre más grande sea un diagrama mayor es la confusión. Se deben realizar diagramas bien detallados, pero no tan detallados.
• ¿Cuánto texto debe complementar el modelo? Entre menos texto mejor, son como los comentarios del código fuente: pocos pero claros.
![Page 90: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/90.jpg)
Recomendaciones
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Algunas recomendaciones para el modelado de software son:
• No tenga a los programadores esperando los modelos.
• Trabajar de una macrovista a una microvista(enfoque Top-Down).
![Page 91: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/91.jpg)
Recomendaciones
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Se debe documentar en forma económica.
• Si es obvio no se debe de modelar.
• Hacer hincapié en la especialización.
• Utilizar patrones de diseño.
• Refactorizar.
![Page 92: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/92.jpg)
Recomendaciones
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Es la primera fase creativa del desarrollo de proyectos. Se compone de lo qué es análisis y diseño.
• El modelado parte de lo que es la Ingeniería de Requerimientos y devuelve un modelo que puede ser construido (implantable a través de lenguajes de programación).
![Page 93: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/93.jpg)
Software
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• Se necesita de una aplicación para móviles que permita la captura de requerimientos a través de casos de uso.
• La aplicación deberá de funcionar en múltiples dispositivos móviles y deberá tener una interfaz de usuario amigable que minimicé el uso del teclado o del stylus o dedo.
![Page 94: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/94.jpg)
Software
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• La aplicación deberá integrarse al sistema existente de requerimientos de la empresa a través de Internet.
• Al momento de establecer un nuevo caso de uso se deberá especificar el nombre en forma textual. La descripción del escenario se hará a través de grabación de audio o bien a través de texto utilizando una interfaz acotada de comandos en lenguaje natural (por ejemplo en la funcionalidad)
![Page 95: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/95.jpg)
Software
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
• La aplicación deberá generar el modelado visual del caso de uso donde el usuario deberá seleccionar componente actor y darle su nombre así como agregar de la descripción textual los casos de uso y las relaciones de dependencia.
• Se puede contar a su vez con una descripción gráfica del caso de uso.
![Page 96: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/96.jpg)
Diseño Modular Efectivo• La independencia funcional se mide en
base a dos criterios: cohesión y acoplamiento.
• Cohesión: es una extensión del principio de ocultamiento de información, es deseable tener una alta cohesión. Esta se obtiene cuando un módulo realiza una tarea sencilla sin depender de otros módulos
![Page 97: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/97.jpg)
Diseño Modular Efectivo• El acoplamiento es una medida de
interconexión de los módulos. Es necesario tener un bajo acoplamiento. El acoplamiento se mide en las relaciones que guardan los módulos con sus interfaces de entrada y salida.
• Hay tres tipos de acoplamiento: común, de datos y control.
![Page 98: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/98.jpg)
Diseño Arquitectónico• El concepto de Arquitectura de Software
tiene mucho tiempo de antigüedad, pero no fue hasta la década de los 1990s que comenzó a utilizarse de manera formal.
• Analizando los sistemas se puede observar que existen patrones que se repiten conformando lo que se conoce como estilos arquitectónicos.
![Page 99: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/99.jpg)
Diseño Arquitectónico• Un estilo arquitectónico define un
conjunto de familias de patrones de software con una determinada estructura y restricciones.
• Generalmente los patrones de diseño y arquitectura definen soluciones para medios repetitivos.
• La arquitectura de software es una abstracción del sistema que nos permite ver su estructura y su relaciones.
![Page 100: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/100.jpg)
Diseño Arquitectónico• La Arquitectura Centrada en Datos tiene
como componente principal un repositorio, del cual surgen los demás componentes.
• Las Arquitecturas Estratificadas son de las más utilizadas en la actualidad, dado que dividen las actividades y responsabilidades de sistemas por capas.
• El software más elaborado como los sistemas operativos, software de base, sistemas distribuidos y otros maneja variantes de esta arquitectura.
![Page 101: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/101.jpg)
Diseño Arquitectónico• Se definen las estructuras de datos
generales y globales.
• Se anotan todas las limitaciones/restricciones del sistema.
• Se debe refinar el diseño hasta que esté completo. Se recomienda completar la arquitectura con el Diseño de Interfaces.
![Page 102: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/102.jpg)
Diseño de Interfaz de Usuario• El diseño de interfaces se refiere al
estudio de las relaciones entre los usuarios y las computadoras para que un sistema se pueda ejecutar.
• El diseño de una interfaz puede definir el éxito de cualquier proyecto, ya que la utilización de cualquier interfaz de usuario depende de factores humanos.
![Page 103: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/103.jpg)
Diseño de UI• Existen algunas reglas de oro para el
buen diseño de Interfaces de Usuario:
• Dar el control al usuario
• Reducir la carga de memoria del usuario
• Construir una interfaz consecuente
![Page 104: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/104.jpg)
Diseño Procedimental• Se pueden utilizar mecanismos como los
diagramas de flujo, los diagramas de caja (NS-Chapin), Lenguaje de Diseño de Programación (Pseudocódigo).
• El diseño procedimental debe de ser:
• Simple (leer, usar y entender)• Modular• Fácil de editar
![Page 105: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/105.jpg)
Documentación del Diseño• Diseño de Datos:
– Objetos de Datos– Estructuras de archivos y base de datos
(estructura lógica, métodos de acceso, datos)
• Diseño arquitectónico:– Revisión de datos y flujos de control– Estructura del Programa
![Page 106: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/106.jpg)
Documentación del Diseño• Diseño de Interfaz:
– Especificación HMI– Normas de diseño de la HMI– Diseño de la interfaz externa (con datos y
sistemas externos)– Normas de diseño de la interfaz interna.
• Diseño procedimental:– Los pasos siguientes se deben hacer para
cada módulo.
![Page 107: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/107.jpg)
Documentación del Diseño– Descripción del proceso– Descripción de la interfaz– Descripción del lenguaje de diseño– Módulos usados– Estructuras de datos internas
• Referencias cruzadas de requisitos: esta sección es opcional, sirve para llevar el control de donde se están satisfaciendo los requerimientos del modelo de análisis.
![Page 108: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/108.jpg)
Documentación del Diseño• Recursos de prueba:
– Directrices para las pruebas– Estrategias de integración– Consideraciones especiales
• Notas especiales:– Apéndices
![Page 109: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/109.jpg)
Diagramas de actividades• Es la versión UML de un diagrama de
flujo.
• Se usan para analizar los procesos y realizar la ingeniería de los mismos.
• Es una excelente herramienta para analizar problemas.
![Page 110: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/110.jpg)
Diagramas de actividades• Son diagramas que representan las
carácterísticas de los procesos.
• Estos diagramas deben facilitar la implementación del sistema.
• Van enfocados a los expertos del dominio (programadores y analistas).
![Page 111: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/111.jpg)
Diagrama de actividades• Pueden modelar procesos lineales y
paralelos.
• Los diagramas deben ser más simples que detallados.
• Los elementos principales son: nodo inicial, flujo, actividades, conectores.
![Page 112: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/112.jpg)
Diagramas de actividades• Se pueden utilizar clavijas para conectar
dos nodos de acción.
• Los nodos de decisión son importantes para bifurcar el flujo de actividades.
• Los nombres y los verbos nos sirven para determinar las clases y los métodos.
![Page 113: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/113.jpg)
Diagramas de actividades• Los casos de uso son candidatos a
desarrollar diagramas de actividades.
• Las condiciones previas y posteriores se manejan con el uso de guardianes.
• Los nodos de decisión también sirven para fusionar diversos flujos en uno solo.
![Page 114: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/114.jpg)
Diagramas de actividades• Los carriles sirven para delimitar quien es
el responsable de una serie de actividades.
• Los carriles formalmente se llaman partición de actividades y puede haber varios siempre y cuando no se encimen.
• Se puede modelar el tiempo a través de señales.
![Page 115: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/115.jpg)
Diagramas de Actividades
![Page 116: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/116.jpg)
Diagramas de clases• Se usan para mostrar las clases de un
sistema y las relaciones entre ellas.
• Muestran la vista estática del sistema; no describen los comportamientos ni la forma en como interactuan las clases del sistema.
![Page 117: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/117.jpg)
Diagramas de clases• Los elementos del lenguaje son unos
rectángulos denominados clases y los conectores representan las relaciones.
• Las clases pueden tener comportamientos y atributos. Lo difícil no es encontrar las clases sino definir sus relaciones
![Page 118: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/118.jpg)
Diagramas de clases• Un diagrama de objetos es similar a un
diagrama de clases pero representa un comportamiento dinámico.
• Los objetos se distinguen al subrayar el nombre de la clase.
• Las interfaces son clases abstractas puras.
![Page 119: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/119.jpg)
Diagramas de clases• Las interfaces se usan cuando las partes
de las cosas tienen facetas semánticamente similares pero no tienen genealogía relacionada.
• Se utiliza el estereotipo interface. Los tipos de datos pueden variar dependiendo de la implementación.
![Page 120: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/120.jpg)
Diagramas de clases• El símbolo + se usa para describir datos
públicos. El símbolo - para datos privados y # un dato no es ni público ni privado (protegido).
• Para acceder a datos privados y/o protegidos se deben utilizar métodos get/set
![Page 121: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/121.jpg)
Diagramas de clases• Los atributos funcionan como asociación.
La multiplicidad de las relaciones es importante.
• Si los valores superiores e inferiores de las relaciones son iguales (1..1) se pone un solo número (1).
![Page 122: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/122.jpg)
Diagramas de clases• Es común hablar de elementos
opcionales, obligatorios, de un solo valor y valores múltiples.
• El 80% de los diagramas de clase utilizan relaciones simples.
• Si existe una flecha en la asociación se dice que ésta es dirigida o direccional.
![Page 123: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/123.jpg)
Diagramas de clase• La agregación se representa con un
diamante hueco; mientras que la composición es un diamante relleno.
• La generalización o herencia se refiere a una relación del tipo es un.
• En una relación de herencia la clase hijo hereda las carácterísticas de la clase padre.
![Page 124: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/124.jpg)
Diagramas de clase• Las relaciones de realización se utilizan
en interfaces para definir que la clase hija implementará esa interfaz. Se utiliza una línea punteada con un diamante parecido a la herencia.
• Las relaciones de dependencia se dan entre dos clases denominadas cliente y proveedor. Se representa con una línea punteada con flecha sencilla.
![Page 125: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/125.jpg)
Diagramas de clase• Los paquetes tienen la apariencia de una
carpeta de archivos. Se usa para representar un nivel más avanzado de abstracción. Se utilizan para organizar las clases, generalmente representan un espacio de nombres.
• Los espacios de nombres solucionan el problema de tener clases diferentes con el mismo nombre.
![Page 126: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/126.jpg)
Diagramas de clase• Algunas herramientas soportan la
documentación del modelo, pero no forma parte del estándar.
• UML tiene datos primitivos: Integer, Boolean, String y UnlimitedNatural, pero se pueden utilizar otros tipos de datos definidos por el estereotipo primitivo, solo hay que definir sus componentes y sus operadores.
![Page 127: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/127.jpg)
Diagramas de clases• Los espacios de nombre se anteponen al de la
clases con el operador de alcance: ::
• Existen dos modalidades para el desarrollo de software orientado a objetos: consumo (Visual Basic) y Producción (Visual C++).
• La técnica de nombres son clases, verbos son métodos sólo funciona en el 20% de los casos.
![Page 128: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/128.jpg)
Diagramas de clases• Se recomienda realizar un análisis de
dominio ya que nos ayuda a encontrar clases frontera, de control y entidad.
• Las clases frontera interconectan elementos del exterior con elementos del interior. Las clases de entidad representan datos (generalmente persistentes). Las clases de control representan interacciones entre el sistema.
![Page 129: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/129.jpg)
Diagramas de clases• La refactorización y los patrones de
diseño ayudan a mejorar los diagramas de clases.
• La herencia múltiple se puede modelar en UML pero no es recomendable hacerlo. Es mejor usar la composición o herencia de interfaces.
• “El mal se encuentra en los detalles”.
![Page 130: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/130.jpg)
Diagramas de Clases
![Page 131: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/131.jpg)
Diagramas de secuencia• Muestran la parte dinámica del sistema.
• Muestran los mensajes que se envían las clases con respecto al tiempo.
• Los diagramas de secuencia muestran un orden a través del tiempo.
• Un diagrama de secuencia es más fácil de leer que uno de colaboración.
![Page 132: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/132.jpg)
Diagramas de secuencia• Existen muchos diagramas en UML que resultan
redundantes, ya que dicen exactamente lo mismo pero en diferente forma.
• Los elementos esenciales son las líneas de vida y los mensajes.
• La línea de vida representa un ejemplo de clase
![Page 133: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/133.jpg)
Diagramas de secuencia• Las líneas de vida pueden ser actores u
objetos.
• La activación de una línea de vida se hace a través de un rectangulo sobre la línea de vida. Un objeto puede crearse y destruirse varias veces dentro de la ejecución de un sistema.
![Page 134: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/134.jpg)
Diagramas de secuencia• Los mensajes forman una parte
importante de este diagrama. Si se tiene una flecha triangular representa un mensaje síncrono, si se tiene una flecha abierta se representa un mensaje asíncrono, los mensajes de retorno se representan con flechas punteadas, mientras que un mensaje anidado inicia y termina en la misma línea de vida.
![Page 135: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/135.jpg)
Diagramas de secuencia• Los marcos de interacción o fragmentos
combinados son nuevos en UML 2.
• Son regiones rectangulares que se usan para organizar los diagramas de interacción.
• Los marcos de interacción más comunes son: alt, bucle, neg, opt, par, ref, regio rod
![Page 136: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/136.jpg)
Diagramas de secuencia• En un futuro no tan lejano, los diseños
deberán ser tan detallados como los circuitos eléctricos.
• En algunos casos es mejor usar diagramas de colaboración, debido a la sencillez de su diseño.
![Page 137: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/137.jpg)
Diagramas de Secuencia
![Page 138: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/138.jpg)
Diagramas de interacción• También muestran la parte dinámica del
sistema.
• Organizan las clases y los mensajes en forma espacial. Como no lleva ordenación del tiempo los mensajes se enumeran.
• Los diagramas de secuencia e interacción son complementarios y en algunos casos no es aconsejable utilizar ambos.
![Page 139: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/139.jpg)
Diagramas de colaboración• También se les llama diagrama de
comunicación en UML 2.
• Los elementos son un rectángulo llamado papel clasificador que representa los objetos, conectores y una secuencia que indica los mensajes. En UML la secuencia se numera como 1, 1.1, 1.2, … en lugar de 1, 2, 3
![Page 140: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/140.jpg)
Diagramas de colaboración• Un diagrama de interacción se puede
pasar a código. Los objetos son instancias de clases y los mensajes son métodos, los cuales se codifican en la clase del receptor no del llamador.
• En diagramas donde existen muchos mensajes se necesitan de más notas para poder explicar el diagrama.
![Page 141: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/141.jpg)
Diagramas de colaboración
![Page 142: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/142.jpg)
Diagramas de estado• Muestra el estado cambiante de un
objeto.
• UML es un lenguaje relativamente sencillo ya que utilizando poco vocabulario se puede realizar la mayoría del modelado de un sistema.
![Page 143: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/143.jpg)
Diagramas de estado• Sirven para representar máquinas de
estados (e.g. autómatas).
• Son ideales para representar procesos de red y de tiempo real.
• La creación de diagramas de interfaces gráficas de usuarios no es parte del estándar UML.
![Page 144: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/144.jpg)
Diagramas de estado• Los diagramas de estado y actividades
comparten mucha de la simbología por lo que se les suele confundir con frecuencia.
• Los estados son activos cuando se ejecutan su actividad de entrada. Se vuelven inactivos después de ejecutar su actividad de salida
![Page 145: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/145.jpg)
Diagramas de estado• Las actividades comunes son algo que
sucede de manera instantánea; mientras que una actividad inicia con el prefijo “hacer/” es una actividad de hacer.
• Un estado simple no está dividido en regiones. En un estado compuesto cada región representa una subactividad.
![Page 146: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/146.jpg)
Diagramas de estado• Las transacciones son líneas dirigidas que
conectan estados. Pueden ocurrir en base a algún mecanismo de disparo.
• Las máquinas de estado de protocolo se utilizan para describir interfaces.
![Page 147: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/147.jpg)
Diagramas de estado
![Page 148: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/148.jpg)
Diagramas de componentes• Muestra los subsistemas del producto
final.
• No es un diagrama ampliamente utilizado en UML.
• Existen dos métodos para el diseño basado en componentes: diseño componentes-interfaz (arriba abajo) y a partir de clases.
![Page 149: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/149.jpg)
Diagramas de componentes• El símbolo de componente cambió en
UML 2 a un diagrama más simple.
• Se utiliza generalmente para modelar sistemas muy grandes.
• Sistemas basados en red y distribuidos pueden modelarse bien con este diagrama.
![Page 150: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/150.jpg)
Diagrama de despliegue• Se utiliza para modelar la forma en como
lucirá el sistema cuando se ponga en uso.
• Los nodos representan componentes físicos que pueden ser computadoras, sistemas operativos, entornos, servidores, etc.
• Ayudan al proceso de instalación de un sistema
![Page 151: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/151.jpg)
Diagrama de despliegue• Los artefactos son las cosas que se están
desplegando. Usan el estereotipo artefacto y pueden ser achivos exe, dll, HTML, .jar, scripts, etc.
• Dentro de cada nodo se suele describir algunas carácterísticas propias.
![Page 152: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/152.jpg)
• (ITM 2007) Material de Libro de Texto de la materia de Planificación y Modelado, Instituto Tecnológico de Morelia.
• (Sánchez, M. 2009) Material del Curso de Planificación y Modelado.
Referencias
![Page 153: Análisis del Proyecto M.C. Juan Carlos Olivares Rojas Marzo 2010.](https://reader035.fdocument.pub/reader035/viewer/2022062409/5665b4661a28abb57c9133a4/html5/thumbnails/153.jpg)
Dudas