Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas
description
Transcript of Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas
![Page 1: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/1.jpg)
Profesor : Hermón Alfaro F. [email protected]
Curso Ingeniería de SoftwareINFT.1
Universidad de Los Lagos
![Page 2: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/2.jpg)
Descripción de las actividades técnicas e ingenieriles que se llevan a cabo en el ciclo de vida de un producto software
Descripción de los problemas, principios, métodos y tecnologías asociadas con la Ingeniería del Software
Presentación de la importancia de los requisitos en el ciclo de vida del software
Introducción a las técnicas básicas de elicitación, documentación, especificación y prototipado de los requisitos de un sistema software
Introducción a los métodos de análisis/diseño estructurado, y los métodos de análisis/diseño orientado a objetos
Estudio y comprensión de los fundamentos del diseño de sistemas software
Aplicar de forma práctica los conceptos teóricos sobre el desarrollo estructurado y orientado a objetos
Objetivos
![Page 3: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/3.jpg)
3
Motivación
![Page 4: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/4.jpg)
La Ingeniería del Software dentro del currículo de los ingenieros en informática aporta la primera aproximación a la práctica real del desarrollo de software
Proyectos realizados por equipos de desarrollo Programación a gran escala (programming in large) Obtención (elicitación) de los requisitos Modelos de ciclo de vida Gestión de la configuración Calidad del software Mantenimiento ……
![Page 5: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/5.jpg)
5
¿Ingeniería? de Software
![Page 6: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/6.jpg)
Ingeniería vs Métodos Tradicionales
![Page 7: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/7.jpg)
Retraso respecto al potencial de hardware Insatisfacción de la demanda Bajo cumplimiento de compromisos – costos, plazos Baja calidad y satisfacción de clientes/usuarios Mantención de sistemas legados
Grandes Problemas Históricos
![Page 8: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/8.jpg)
Percepciones de la Disciplina
Ineficiencia Altos costos Baja confiabilidad Escasa ingeniería
![Page 9: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/9.jpg)
Crisis del Software
Origina la disciplina “Ingeniería de Software” en los 60s Síntomas típicos
funcionalidad incorrecta costos y plazos excedidos insatisfacción de clientes y usuarios poca o nula visibilidad de lo que ocurre
![Page 10: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/10.jpg)
Crisis del Software
Algunas causas potenciales carácter lógico del software formación profesional (o falta de) entrenamiento y actualización resistencia al cambio
Solución potencial incorporar enfoque ingenieril en la forma de un proceso de
software …
![Page 11: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/11.jpg)
Crisis del Software
Algunos mitos bastantes arraigados también estándares y procedimientos bastan tecnología de punta basta más gente para ponerse al día programación inmediata fácil acomodo de los cambios programación: fin del trabajo calidad: sólo del ejecutable código es el único producto
![Page 12: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/12.jpg)
Ingeniería de Software
“ Establecimiento y uso de principios con caracteres de ingeniería apropiados para obtener, eficientemente, software confiable, que opere eficaz y eficientemente en máquinas reales “
Concepto se acuñó en 1968, en Conferencia de la OTAN en Alemania , con la intención de
que mediante el uso de filosofías y paradigmas de disciplinas ingenieriles establecidas se
resolviera la denominada crisis del software
![Page 13: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/13.jpg)
Ingeniería de Software
Objetivos maximizar calidad maximizar productividad minimizar riesgos
![Page 14: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/14.jpg)
Ingeniería de Software
Implicancias mejores técnicas de control de calidad mejores herramientas y métodos
Todo en la forma de proceso de software adecuado al tipo de problema que se resuelve y que permitan gestionar de mejor manera los principales riesgos relevantes para todos los stakeholders (involucrados o afectados)
![Page 15: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/15.jpg)
Proceso de Software Para Gestionar Riesgos
![Page 16: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/16.jpg)
Proceso de Software
Análisis DiseñoConstrucción
y Pruebas
UnitariasPruebas
Operación
Mantención
Desarrollo de software
Procesos de apoyo: Gestión de proyectos,
Gestión de Configuración,
Gestión de Requerimientos,
Gestión de la Calidad, ……….
![Page 17: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/17.jpg)
Riesgos de Software
Categorías - Top 10 Métricas inadecuadas Medición inadecuada Presión excesiva de tiempo Malas prácticas de gestión Estimación imprecisa de costos Síndrome del “silver bullet” Requerimientos Baja calidad Baja productividad Cancelación de proyectos
![Page 18: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/18.jpg)
Proceso de Software
Proveer un producto o un servicio, siempre consiste en seguir una secuencia de pasos, para llevar a cabo un conjunto de tareas
Las tareas se ejecutan usualmente en el mismo orden todas las veces
Un proceso es una serie de pasos que involucran actividades, restricciones y recursos, que producen una salida esperada, de algún tipo.
Un proceso involucra usualmente un conjunto de herramientas y técnicas.
![Page 19: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/19.jpg)
Proceso de Software
Es importante, pues impone consistencia y estructura al conjunto de actividades
Es más que un procedimiento, es un conjunto organizado de éstos.
La estructura del proceso guía la acción, permitiendo examinar, entender, controlar y mejorar las actividades comprendidas por éste.
También es importante pues permite capturar y transmitir la experiencia, a proyectos futuros
Cada proceso puede ser descrito por una combinación de diferentes medios.
![Page 20: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/20.jpg)
Un poco de Historia
El modelo usado era de codificar-corregir: Escribir el código. Revisar y eliminar los errores o mejorar/aumentar la
funcionalidad. A medida que el hardware aumentó sus capacidades y
disminuyó sus costos, se amplió el ámbito de las aplicaciones y se masificó el uso de computadores.
Se incursionó en áreas donde los problemas no eran tan bien acotados (ej. administrativos) y el desarrollo se tornó más complejo.
![Page 21: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/21.jpg)
Un poco de Historia
Aparece un problema aún mayor: había que mantener los sistemas.
Esto escapó de las manos de los usuarios- programadores, quienes ya no pudieron controlar el proceso, pues sólo dominaban su especialidad, no el desarrollo de software.
Se incorporan tópicos organizacionales y psicológicos, así como también la demanda por mayor calidad y confiabilidad.
![Page 22: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/22.jpg)
Un poco de Historia
Además, ahora el desarrollo se convierte en una actividad de grupo, lo cual demanda planificar, organizar y estructurar el trabajo en torno a “proyectos”.
La comunicación entre humanos (usuario- desarrollador y desarrollador-desarrollador) se convierte en un problema.
Se hace necesario definir un “Proceso
![Page 23: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/23.jpg)
Un poco de Historia
El proceso a la antigua, como “caja negra”.
![Page 24: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/24.jpg)
Modelos de Proceso de Software
En la Ingeniería de Software se describen muchos Modelos de Proceso.
Unos son prescriptivos: establecen la forma en que debería progresar el proceso de software.
Otros son descriptivos: dicen la forma en que el proceso de software progresa en la realidad.
![Page 25: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/25.jpg)
Algunos Modelos deProceso de Software
Modelo en Cascada. Modelo en V. Modelo de Prototipación. Modelo en Espiral. RUP Métodos Ágiles.
![Page 26: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/26.jpg)
Modelo en Cascada Es el más antiguo. Debe completarse un
estado antes de comenzar el siguiente.
Es útil para que el desarrollador visualice lo que va a hacer.
Su principal problema es que no refleja la realidad..
![Page 27: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/27.jpg)
Modelo en Cascada
![Page 28: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/28.jpg)
Modelo en Cascada Análisis de Requerimientos:
Se centra e intensifica especialmente en el software El ingeniero de software debe comprender el ámbito de la información
del software, así como la función, el rendimiento y las interfaces requeridas
Diseño (sistema y programa): Se enfoca en cuatro atributos: la estructura de los datos, la
arquitectura del software, el detalle procedimental y la caracterización de la interfaz
El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación
Codificación: El diseño debe traducirse en una forma legible para la maquina. Si el
diseño se realiza de una manera detallada la codificación puede realizarse automáticamente
![Page 29: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/29.jpg)
Modelo en Cascada
Prueba (unitario, integración, sistema, aceptación): una vez que se ha generado el código comienza la prueba del
programa. La prueba se centra en la lógica interna del software, y en las funciones
externas, realizando pruebas que aseguren que la entrada definida produce los resultados requeridos
Mantenimiento: el software sufrirá cambios después de que se entrega al cliente, los
cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento
![Page 30: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/30.jpg)
Modelo V
![Page 31: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/31.jpg)
Modelo V
La primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integración asociado a cada una de las etapas de la mitad anterior.
Se puede identificar una ventaja principal con respecto al Modelo Cascada más simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada.
![Page 32: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/32.jpg)
Modelo de Prototipación
Permite la construcción rápida del sistema (o parte de éste). Usuario y desarrollador tienen una visión común. Se reduce el riesgo y lo incierto del desarrollo
![Page 33: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/33.jpg)
Modelo en Espiral
Se combinan las actividades de desarrollo con Análisis de Riesgo.
El modelo es de tipo iterativo: Planificación → Análisis de Riesgo → Ingeniería → Evaluación
→ Planificación → ..En cada iteración, se evalúan las diferentes alternativas y
se elige una. Los gestores del proyecto intentan eliminar o minimizar el
riesgo.
![Page 34: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/34.jpg)
Modelo en Espiral
![Page 35: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/35.jpg)
RUP – Rational Unified Process
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)
Cada ciclo de vida del software abarca 4 fases en el siguiente orden: concepción/planificación, elaboración, construcción y transición
La esencia de RUP es la iteración, y cada iteración resulta en un entregable preferentemente ejecutable
![Page 36: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/36.jpg)
RUP – Rational Unified Process
![Page 37: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/37.jpg)
37
Mapa Conceptual de RUP
![Page 38: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/38.jpg)
38
• 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
• La oportunidad del negocio incluye:– Criterios de éxito
– Identificación de riesgos
– Estimación de recursos necesarios
– Plan de las fases incluyendo hitos
Fases de RUP: Fases de RUP: Inception (Inicio)Inception (Inicio)
![Page 39: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/39.jpg)
39
• 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.
• Caso de negocio:– Contexto
– Criterios de éxito
– Pronóstico financiero
• Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.
Fases de RUP: Fases de RUP: Inception (Inicio)Inception (Inicio)
Productos:
![Page 40: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/40.jpg)
40
Inicio Elaboración Construcción Transición
Objetivos del Ciclo de Vida
• 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.
Fases de RUP: Fases de RUP: InceptionInception (Inicio)Inicio)
Hito:
![Page 41: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/41.jpg)
41
• 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.
Fases de RUP: ElaboraciónFases de RUP: Elaboración
![Page 42: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/42.jpg)
42
• Es la parte más crítica del proceso:– Al final toda la ingeniería
“dura” está hecha
– 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.
• Se construye una arquitectura ejecutable que contemple:– Los casos de uso críticos
– Los riesgos identificados
Fases de RUP: ElaboraciónFases de RUP: Elaboración
Productos:
![Page 43: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/43.jpg)
43
Fases de RUP: ElaboraciónFases de RUP: Elaboración
• 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.
• 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.
Productos:
![Page 44: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/44.jpg)
44
• 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?
Inicio Elaboración Construcción Transición
Arquitectura de Ciclo de Vida
Fases de RUP: ElaboraciónFases de RUP: Elaboración
Hito:
![Page 45: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/45.jpg)
45
• 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.
Fases de RUP: ConstrucciónFases de RUP: Construcción
![Page 46: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/46.jpg)
46
• El producto de software integrado y corriendo en la plataforma adecuada.
• Manuales de usuario.
• Una descripción del “release” actual.
Fases de RUP: ConstrucciónFases de RUP: Construcción
Productos:
![Page 47: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/47.jpg)
47
Fases de RUP: ConstrucciónFases de RUP: Construcción
• 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?
Inicio Elaboración Construcción Transición
CapacidadOperacional
Hito:
![Page 48: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/48.jpg)
48
• 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
– Conversión de datos
– Entrenamiento de usuarios
– Distribuir el producto
Fases de RUP: TransiciónFases de RUP: Transición
![Page 49: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/49.jpg)
49
• Obtener autosuficiencia de parte de los usuarios.
• Concordancia en los logros del producto de parte de las personas involucradas.
• Lograr el concenso cuanto antes para liberar el producto al mercado.
Inicio Elaboración Construcción Transición
Producto
Fases de RUP: TransiciónFases de RUP: Transición
Objetivos:
![Page 50: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/50.jpg)
Métodos Ágiles
Interés creciente en los métodos ágiles (inicialmente llamados ligeros, lightweight) en los últimos años
enfrentamiento de requerimientos cambiantes tiempos de desarrollo escasos clientes y usuarios cada vez más exigentes
Caracterizados alternativamente como antídoto a la burocracia (métodos planificados, pesados)
![Page 51: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/51.jpg)
Métodos Ágiles
Algunas características de los métodos ágiles Documentación mínima Ciclos iterativos breves Reacción rápida ante los cambios Estrecha relación con el cliente Diseño simple Satisfacción de necesidades inmediatas Foco en las personas Organización libre Procesos adaptables, no predictivos
![Page 52: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/52.jpg)
Métodos Ágiles
El proceso de Desarrollo XP
Fase inicial de captura de requerimientos es eliminada
El ciclo de desarrollo de XP se divide en liberaciones cada una de las cuales es medida en historias de usuario
Historia de usuario: unidad funcional en un proyecto XP, debe ser entendible tanto para el cliente como para los desarrolladores, verificable y pequeña
![Page 53: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/53.jpg)
Métodos Ágiles El proceso de desarrollo XP
Fase de Exploración Fase de Planificación Fase de Iteraciones y Entregas Fase de Producción Fase de Mantenimiento Fase de Muerte
![Page 54: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/54.jpg)
Métodos Ágiles
![Page 55: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/55.jpg)
Principales Métodos Ágiles
Extreme Programming, XP Scrum Crystal Family Feature-Driven Design Adaptive Software Development DSDM Otros
![Page 56: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/56.jpg)
Agilidad vs. Proceso
Ultimamente, distintos trabajos han investigado la relación entre modelos de proceso y métodos ágiles, observando lo siguiente
CMM/CMMI y XP pueden complementarse (foco en aspectos de gestión vs. técnicos)
Métodos ágiles calzan con la esencia del mejoramiento de procesos bajo una interpretación menos literal (que CMMI, por ejemplo)
Métodos ágiles apuntan a gestión de proyectos, no a gestión de procesos
![Page 57: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/57.jpg)
Bibliografía
Pressman Roger. “Ingeniería del Software”. Tercera Software Engineering: Theory and Practice (2nd Ed.) Shari
Pfleeger, Prentice Hall (2001), Cap. 1&2 The Software-Research Crisis. Robert L. Glass, IEEE
Software, Noviembre 1994 Using Risk to Balance Agile and Plan-Driven Methods Barry
Boehm, Richard Turner, IEEE Computer, Junio 2003 Agile Alliance§ http://www.agilealliance.com/ What is extreme programming? http://www.xprogramming.com/
![Page 58: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/58.jpg)
Anexos
![Page 59: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/59.jpg)
59
Arquitectura de Sistemas ComputacionalesArquitectura de Sistemas Computacionales
Estructuraciónde los Procesos
Estructuraciónde las Comunicaciones
Estructuraciónde los Datos
Ingenieríade lascomunicaciones
Ingenieríade la Información
Ingenieríade Software
![Page 60: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/60.jpg)
60
Arquitectura de Sistemas ComputacionalesArquitectura de Sistemas Computacionales
Datos Función Comunicaciones
NivelConceptual(Esquemadel Negocio)
NivelLógico
(S.I.A)
NivelFísico
(Implementación Computacional)
... .
![Page 61: Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas](https://reader036.fdocuments.ec/reader036/viewer/2022062422/56813b57550346895da44a11/html5/thumbnails/61.jpg)
61