Profesor : Hermón Alfaro F.  Hermon.alfaro@tm-mas.com    Curso Ingeniería de Software INFT.1 Universidad de  Los Lagos
<ul><li>Descripción de las actividades técnicas e ingenieriles que se llevan a cabo en  el ciclo de vida de un producto so...
Motivación
<ul><li>La Ingeniería del Software dentro del currículo de los ingenieros en informática aporta la primera aproximación a ...
¿Ingeniería? de Software
Ingeniería vs Métodos Tradicionales
<ul><li>Retraso respecto al potencial de hardware </li></ul><ul><li>Insatisfacción de la demanda </li></ul><ul><li>Bajo cu...
Percepciones de la Disciplina <ul><li>Ineficiencia Altos costos </li></ul><ul><li>Baja confiabilidad </li></ul><ul><li>Esc...
Crisis del Software <ul><li>Origina la disciplina “Ingeniería de Software” en los  60s </li></ul><ul><li>Síntomas típicos ...
Crisis del Software <ul><li>Algunas causas potenciales  </li></ul><ul><ul><li>carácter lógico del software  </li></ul></ul...
Crisis del Software <ul><li>Algunos mitos bastantes arraigados también  </li></ul><ul><ul><li>estándares y procedimientos ...
Ingeniería de Software <ul><li>“  Establecimiento y uso de principios con caracteres de ingeniería apropiados para  obtene...
Ingeniería de Software <ul><li>Objetivos  </li></ul><ul><ul><li>maximizar calidad  </li></ul></ul><ul><ul><li>maximizar pr...
Ingeniería de Software <ul><li>Implicancias  </li></ul><ul><ul><li>mejores técnicas de control de calidad  </li></ul></ul>...
<ul><li>Proceso de Software Para Gestionar Riesgos </li></ul>
Proceso de Software Análisis Diseño Construcción y  Pruebas  Unitarias Pruebas Operación Mantención Desarrollo de software...
Riesgos de Software <ul><li>Categorías - Top 10 </li></ul><ul><ul><li>Métricas inadecuadas </li></ul></ul><ul><ul><li>Medi...
Proceso de Software <ul><li>Proveer un producto o un servicio, siempre consiste  en seguir una secuencia de pasos, para ll...
Proceso de Software <ul><li>Es importante, pues impone consistencia y  estructura al conjunto de actividades </li></ul><ul...
Un poco de Historia <ul><li>El modelo usado era de codificar-corregir:  </li></ul><ul><ul><li>Escribir el código.  </li></...
Un poco de Historia <ul><li>Aparece un problema aún mayor: había que  mantener los sistemas. </li></ul><ul><li>Esto escapó...
Un poco de Historia <ul><li>Además, ahora el desarrollo se convierte en una  actividad de grupo, lo cual demanda planifica...
Un poco de Historia <ul><li>El proceso a la antigua, como “caja negra”. </li></ul>
Modelos de Proceso de Software <ul><li>En la Ingeniería de Software se describen muchos  Modelos de Proceso. </li></ul><ul...
Algunos Modelos de Proceso de Software <ul><li>Modelo en Cascada. </li></ul><ul><li>Modelo en V. </li></ul><ul><li>Modelo ...
Modelo en Cascada  <ul><li>Es el más antiguo. </li></ul><ul><li>Debe completarse un estado antes de  comenzar el siguiente...
Modelo en Cascada
Modelo en Cascada <ul><li>Análisis de Requerimientos:   </li></ul><ul><ul><li>Se centra e intensifica especialmente en el ...
Modelo en Cascada <ul><li>Prueba (unitario, integración, sistema, aceptación):   </li></ul><ul><ul><li>una vez que se ha g...
Modelo V
Modelo V <ul><li>La primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e in...
Modelo de Prototipación <ul><li>Permite la construcción rápida del sistema (o parte  de éste). </li></ul><ul><li>Usuario y...
Modelo en Espiral <ul><li>Se combinan las actividades de desarrollo con  Análisis de Riesgo. </li></ul><ul><li>El modelo e...
Modelo en Espiral
RUP – Rational Unified Process  <ul><li>Su objetivo es asegurar la producción de software de calidad dentro de plazos  y p...
RUP – Rational Unified Process
Mapa Conceptual de RUP
<ul><li>Se establece la oportunidad y alcance el proyecto. </li></ul><ul><li>Se identifican todas las entidades externas c...
<ul><li>Un documento de visión general: </li></ul><ul><ul><li>Requerimientos generales del proyecto </li></ul></ul><ul><ul...
Inicio Elaboración Construcción Transición Objetivos del  Ciclo de Vida <ul><li>Las partes interesadas deben acordar el al...
<ul><li>Objetivos: </li></ul><ul><ul><li>Analizar el dominio del problema </li></ul></ul><ul><ul><li>Establecer una arquit...
<ul><li>Es la parte más crítica del proceso: </li></ul><ul><ul><li>Al final toda la ingeniería “dura” está hecha </li></ul...
Fases de RUP: Elaboración <ul><li>Modelo de casos de uso (80% completo) con descripciones detalladas. </li></ul><ul><li>Ot...
<ul><li>Condiciones de éxito de la elaboración: </li></ul><ul><ul><li>¿Es estable la visión del producto? </li></ul></ul><...
<ul><li>En esta fase todas las componentes restantes se desarrollan e incorporan al producto. </li></ul><ul><li>Todo es pr...
<ul><li>El producto de software integrado y corriendo en la plataforma adecuada. </li></ul><ul><li>Manuales de usuario. </...
Fases de RUP: Construcción <ul><li>Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayore...
<ul><li>El objetivo es traspasar el software desarrollado a la comunidad de usuarios. </li></ul><ul><li>Una vez instalado ...
<ul><li>Obtener autosuficiencia de parte de los usuarios. </li></ul><ul><li>Concordancia en los logros del producto de par...
Métodos Ágiles  <ul><li>Interés creciente en los métodos ágiles (inicialmente  llamados ligeros, lightweight) en los últim...
Métodos Ágiles  <ul><li>Algunas características de los métodos ágiles </li></ul><ul><ul><li>Documentación mínima </li></ul...
Métodos Ágiles  <ul><li>El proceso de Desarrollo XP </li></ul><ul><ul><li>Fase inicial de captura de requerimientos es eli...
Métodos Ágiles  <ul><li>El proceso de desarrollo XP </li></ul><ul><ul><li>Fase de Exploración </li></ul></ul><ul><ul><li>F...
Métodos Ágiles
Principales Métodos Ágiles  <ul><li>Extreme Programming, XP </li></ul><ul><li>Scrum </li></ul><ul><li>Crystal Family </li>...
Agilidad vs. Proceso <ul><li>Ultimamente, distintos trabajos han investigado la  relación entre modelos de proceso y métod...
Bibliografía <ul><li>Pressman Roger. “Ingeniería del Software”. Tercera </li></ul><ul><li>Software Engineering: Theory and...
Anexos
Arquitectura de Sistemas Computacionales Estructuración de los Procesos Estructuración de las Comuni caciones Estructuraci...
Arquitectura de Sistemas Computacionales Datos Función Comunicaciones Nivel Conceptual (Esquema del Negocio) Nivel Lógico ...
 
Los 13 Mandamientos en el Proceso de Definición  de Requisitos   Entonces Jehovah dijo al Analista Funcional: —  Escribe e...
Los 13 Mandamientos en el Proceso de Definición  de Requisitos   Entonces Jehovah dijo al Analista Funcional: —  Escribe e...
Próxima SlideShare
Cargando en…5
×

Curso ingeniería de software parte i

1.096 visualizaciones

Publicado el

Publicado en: Tecnología
0 comentarios
1 recomendación
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
1.096
En SlideShare
0
De insertados
0
Número de insertados
18
Acciones
Compartido
0
Descargas
26
Comentarios
0
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.

Curso ingeniería de software parte i

  1. 1. Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas.com Curso Ingeniería de Software INFT.1 Universidad de Los Lagos
  2. 2. <ul><li>Descripción de las actividades técnicas e ingenieriles que se llevan a cabo en el ciclo de vida de un producto software </li></ul><ul><li>Descripción de los problemas, principios, métodos y tecnologías asociadas con la Ingeniería del Software </li></ul><ul><li>Presentación de la importancia de los requisitos en el ciclo de vida del software </li></ul><ul><li>Introducción a las técnicas básicas de elicitación, documentación, especificación y prototipado de los requisitos de un sistema software </li></ul><ul><li>Introducción a los métodos de análisis/diseño estructurado, y los métodos de análisis/diseño orientado a objetos </li></ul><ul><li>Estudio y comprensión de los fundamentos del diseño de sistemas software </li></ul><ul><li>Aplicar de forma práctica los conceptos teóricos sobre el desarrollo estructurado y orientado a objetos </li></ul>Objetivos
  3. 3. Motivación
  4. 4. <ul><li>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 </li></ul><ul><ul><li>Proyectos realizados por equipos de desarrollo </li></ul></ul><ul><ul><li>Programación a gran escala (programming in large) </li></ul></ul><ul><ul><li>Obtención (elicitación) de los requisitos </li></ul></ul><ul><ul><li>Modelos de ciclo de vida </li></ul></ul><ul><ul><li>Gestión de la configuración </li></ul></ul><ul><ul><li>Calidad del software </li></ul></ul><ul><ul><li>Mantenimiento </li></ul></ul><ul><ul><li>…… </li></ul></ul>
  5. 5. ¿Ingeniería? de Software
  6. 6. Ingeniería vs Métodos Tradicionales
  7. 7. <ul><li>Retraso respecto al potencial de hardware </li></ul><ul><li>Insatisfacción de la demanda </li></ul><ul><li>Bajo cumplimiento de compromisos – costos, plazos </li></ul><ul><li>Baja calidad y satisfacción de clientes/usuarios </li></ul><ul><li>Mantención de sistemas legados </li></ul>Grandes Problemas Históricos
  8. 8. Percepciones de la Disciplina <ul><li>Ineficiencia Altos costos </li></ul><ul><li>Baja confiabilidad </li></ul><ul><li>Escasa ingeniería </li></ul>
  9. 9. Crisis del Software <ul><li>Origina la disciplina “Ingeniería de Software” en los 60s </li></ul><ul><li>Síntomas típicos </li></ul><ul><ul><li>funcionalidad incorrecta </li></ul></ul><ul><ul><li>costos y plazos excedidos </li></ul></ul><ul><ul><li>insatisfacción de clientes y usuarios </li></ul></ul><ul><ul><li>poca o nula visibilidad de lo que ocurre </li></ul></ul>
  10. 10. Crisis del Software <ul><li>Algunas causas potenciales </li></ul><ul><ul><li>carácter lógico del software </li></ul></ul><ul><ul><li>formación profesional (o falta de) </li></ul></ul><ul><ul><li>entrenamiento y actualización </li></ul></ul><ul><ul><li>resistencia al cambio </li></ul></ul><ul><li>Solución potencial </li></ul><ul><ul><li>incorporar enfoque ingenieril en la forma de un proceso de software … </li></ul></ul>
  11. 11. Crisis del Software <ul><li>Algunos mitos bastantes arraigados también </li></ul><ul><ul><li>estándares y procedimientos bastan </li></ul></ul><ul><ul><li>tecnología de punta basta </li></ul></ul><ul><ul><li>más gente para ponerse al día </li></ul></ul><ul><ul><li>programación inmediata </li></ul></ul><ul><ul><li>fácil acomodo de los cambios </li></ul></ul><ul><ul><li>programación: fin del trabajo </li></ul></ul><ul><ul><li>calidad: sólo del ejecutable </li></ul></ul><ul><ul><li>código es el único producto </li></ul></ul>
  12. 12. Ingeniería de Software <ul><li>“ 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 “ </li></ul><ul><li>Concepto se acuñó en 1968, en Conferencia de la OTAN en Alemania , con la intención de </li></ul><ul><li>que mediante el uso de filosofías y paradigmas de disciplinas ingenieriles establecidas se </li></ul><ul><li>resolviera la denominada crisis del software </li></ul>
  13. 13. Ingeniería de Software <ul><li>Objetivos </li></ul><ul><ul><li>maximizar calidad </li></ul></ul><ul><ul><li>maximizar productividad </li></ul></ul><ul><ul><li>minimizar riesgos </li></ul></ul>
  14. 14. Ingeniería de Software <ul><li>Implicancias </li></ul><ul><ul><li>mejores técnicas de control de calidad </li></ul></ul><ul><ul><li>mejores herramientas y métodos </li></ul></ul><ul><li>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) </li></ul>
  15. 15. <ul><li>Proceso de Software Para Gestionar Riesgos </li></ul>
  16. 16. Proceso de Software Análisis Diseño Construcción y Pruebas Unitarias Pruebas 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, ……….
  17. 17. Riesgos de Software <ul><li>Categorías - Top 10 </li></ul><ul><ul><li>Métricas inadecuadas </li></ul></ul><ul><ul><li>Medición inadecuada </li></ul></ul><ul><ul><li>Presión excesiva de tiempo </li></ul></ul><ul><ul><li>Malas prácticas de gestión </li></ul></ul><ul><ul><li>Estimación imprecisa de costos </li></ul></ul><ul><ul><li>Síndrome del “silver bullet” </li></ul></ul><ul><ul><li>Requerimientos Baja calidad </li></ul></ul><ul><ul><li>Baja productividad </li></ul></ul><ul><ul><li>Cancelación de proyectos </li></ul></ul>
  18. 18. Proceso de Software <ul><li>Proveer un producto o un servicio, siempre consiste en seguir una secuencia de pasos, para llevar a cabo un conjunto de tareas </li></ul><ul><li>Las tareas se ejecutan usualmente en el mismo orden todas las veces </li></ul><ul><li>Un proceso es una serie de pasos que involucran actividades, restricciones y recursos, que producen una salida esperada, de algún tipo. </li></ul><ul><li>Un proceso involucra usualmente un conjunto de herramientas y técnicas. </li></ul>
  19. 19. Proceso de Software <ul><li>Es importante, pues impone consistencia y estructura al conjunto de actividades </li></ul><ul><li>Es más que un procedimiento, es un conjunto organizado de éstos. </li></ul><ul><li>La estructura del proceso guía la acción, permitiendo examinar, entender, controlar y mejorar las actividades comprendidas por éste. </li></ul><ul><li>También es importante pues permite capturar y transmitir la experiencia, a proyectos futuros </li></ul><ul><li>Cada proceso puede ser descrito por una combinación de diferentes medios. </li></ul>
  20. 20. Un poco de Historia <ul><li>El modelo usado era de codificar-corregir: </li></ul><ul><ul><li>Escribir el código. </li></ul></ul><ul><ul><li>Revisar y eliminar los errores o mejorar/aumentar la funcionalidad. </li></ul></ul><ul><li>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. </li></ul><ul><li>Se incursionó en áreas donde los problemas no eran tan bien acotados (ej. administrativos) y el desarrollo se tornó más complejo. </li></ul>
  21. 21. Un poco de Historia <ul><li>Aparece un problema aún mayor: había que mantener los sistemas. </li></ul><ul><li>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. </li></ul><ul><li>Se incorporan tópicos organizacionales y psicológicos, así como también la demanda por mayor calidad y confiabilidad. </li></ul>
  22. 22. Un poco de Historia <ul><li>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”. </li></ul><ul><li>La comunicación entre humanos (usuario- desarrollador y desarrollador-desarrollador) se convierte en un problema. </li></ul><ul><li>Se hace necesario definir un “Proceso </li></ul>
  23. 23. Un poco de Historia <ul><li>El proceso a la antigua, como “caja negra”. </li></ul>
  24. 24. Modelos de Proceso de Software <ul><li>En la Ingeniería de Software se describen muchos Modelos de Proceso. </li></ul><ul><ul><li>Unos son prescriptivos: establecen la forma en que debería progresar el proceso de software. </li></ul></ul><ul><ul><li>Otros son descriptivos: dicen la forma en que el proceso de software progresa en la realidad. </li></ul></ul>
  25. 25. Algunos Modelos de Proceso de Software <ul><li>Modelo en Cascada. </li></ul><ul><li>Modelo en V. </li></ul><ul><li>Modelo de Prototipación. </li></ul><ul><li>Modelo en Espiral. </li></ul><ul><li>RUP Métodos Ágiles. </li></ul>
  26. 26. Modelo en Cascada <ul><li>Es el más antiguo. </li></ul><ul><li>Debe completarse un estado antes de comenzar el siguiente. </li></ul><ul><li>Es útil para que el desarrollador visualice lo que va a hacer. </li></ul><ul><li>Su principal problema es que no refleja la realidad.. </li></ul>
  27. 27. Modelo en Cascada
  28. 28. Modelo en Cascada <ul><li>Análisis de Requerimientos: </li></ul><ul><ul><li>Se centra e intensifica especialmente en el software </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><li>Diseño (sistema y programa): </li></ul><ul><ul><li>Se enfoca en cuatro atributos: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><li>Codificación: </li></ul><ul><ul><li>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 </li></ul></ul>
  29. 29. Modelo en Cascada <ul><li>Prueba (unitario, integración, sistema, aceptación): </li></ul><ul><ul><li>una vez que se ha generado el código comienza la prueba del programa. </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><li>Mantenimiento: </li></ul><ul><ul><li>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 </li></ul></ul>
  30. 30. Modelo V
  31. 31. Modelo V <ul><li>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. </li></ul><ul><li>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. </li></ul>
  32. 32. Modelo de Prototipación <ul><li>Permite la construcción rápida del sistema (o parte de éste). </li></ul><ul><li>Usuario y desarrollador tienen una visión común. </li></ul><ul><li>Se reduce el riesgo y lo incierto del desarrollo </li></ul>
  33. 33. Modelo en Espiral <ul><li>Se combinan las actividades de desarrollo con Análisis de Riesgo. </li></ul><ul><li>El modelo es de tipo iterativo: </li></ul><ul><ul><li>Planificación -> Análisis de Riesgo -> Ingeniería -> Evaluación -> Planificación -> </li></ul></ul><ul><li>..En cada iteración, se evalúan las diferentes alternativas y se elige una. </li></ul><ul><li>Los gestores del proyecto intentan eliminar o minimizar el riesgo. </li></ul>
  34. 34. Modelo en Espiral
  35. 35. RUP – Rational Unified Process <ul><li>Su objetivo es asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. </li></ul><ul><li>Dirigido por casos de uso , centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones) </li></ul><ul><li>Cada ciclo de vida del software abarca 4 fases en el siguiente orden: concepción/planificación, elaboración, construcción y transición </li></ul><ul><li>La esencia de RUP es la iteración, y cada iteración resulta en un entregable preferentemente ejecutable </li></ul>
  36. 36. RUP – Rational Unified Process
  37. 37. Mapa Conceptual de RUP
  38. 38. <ul><li>Se establece la oportunidad y alcance el proyecto. </li></ul><ul><li>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: </li></ul><ul><ul><li>Identificar todos los casos de uso </li></ul></ul><ul><ul><li>Describir algunos en detalle </li></ul></ul><ul><li>La oportunidad del negocio incluye: </li></ul><ul><ul><li>Criterios de éxito </li></ul></ul><ul><ul><li>Identificación de riesgos </li></ul></ul><ul><ul><li>Estimación de recursos necesarios </li></ul></ul><ul><ul><li>Plan de las fases incluyendo hitos </li></ul></ul>Fases de RUP: Inception (Inicio)
  39. 39. <ul><li>Un documento de visión general: </li></ul><ul><ul><li>Requerimientos generales del proyecto </li></ul></ul><ul><ul><li>Características principales </li></ul></ul><ul><ul><li>Restricciones </li></ul></ul><ul><li>Modelo inicial de casos de uso (10% a 20 % listos). </li></ul><ul><li>Glosario. </li></ul><ul><li>Caso de negocio: </li></ul><ul><ul><li>Contexto </li></ul></ul><ul><ul><li>Criterios de éxito </li></ul></ul><ul><ul><li>Pronóstico financiero </li></ul></ul><ul><li>Identificación inicial de riesgos. </li></ul><ul><li>Plan de proyecto. </li></ul><ul><li>Uno o más prototipos. </li></ul>Fases de RUP: Inception (Inicio) Productos:
  40. 40. Inicio Elaboración Construcción Transición Objetivos del Ciclo de Vida <ul><li>Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo. </li></ul><ul><li>Comprensión de los requerimientos plasmados en casos de uso. </li></ul>Fases de RUP: Inception ( Inicio) Hito:
  41. 41. <ul><li>Objetivos: </li></ul><ul><ul><li>Analizar el dominio del problema </li></ul></ul><ul><ul><li>Establecer una arquitectura base sólida </li></ul></ul><ul><ul><li>Desarrollar un plan de proyecto </li></ul></ul><ul><ul><li>Eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto </li></ul></ul><ul><li>Visión de “una milla de amplitud y una pulgada de profundidad” porque las decisiones de arquitectura requieren una visión global del sistema. </li></ul>Fases de RUP: Elaboración
  42. 42. <ul><li>Es la parte más crítica del proceso: </li></ul><ul><ul><li>Al final toda la ingeniería “dura” está hecha </li></ul></ul><ul><ul><li>Se puede decidir si vale la pena seguir adelante </li></ul></ul><ul><li>A partir de aquí la arquitectura, los requerimientos y los planes de desarrollo son estables. </li></ul><ul><li>Ya hay menos riesgos y se puede planificar el resto del proyecto con menor incertidumbre. </li></ul><ul><li>Se construye una arquitectura ejecutable que contemple: </li></ul><ul><ul><li>Los casos de uso críticos </li></ul></ul><ul><ul><li>Los riesgos identificados </li></ul></ul>Fases de RUP: Elaboración Productos:
  43. 43. Fases de RUP: Elaboración <ul><li>Modelo de casos de uso (80% completo) con descripciones detalladas. </li></ul><ul><li>Otros requerimientos no funcio-nales o no asociados a casos de uso. </li></ul><ul><li>Descripción de la Arquitectura del Software. </li></ul><ul><li>Un prototipo ejecutable de la arquitectura. </li></ul><ul><li>Lista revisada de riesgos y del caso de negocio. </li></ul><ul><li>Plan de desarrollo para el resto del proyecto. </li></ul><ul><li>Un manual de usuario preliminar. </li></ul>Productos:
  44. 44. <ul><li>Condiciones de éxito de la elaboración: </li></ul><ul><ul><li>¿Es estable la visión del producto? </li></ul></ul><ul><ul><li>¿Es estable la arquitectura? </li></ul></ul><ul><ul><li>¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y resueltos? </li></ul></ul><ul><ul><li>¿Es el plan del proyecto algo realista? </li></ul></ul><ul><ul><li>¿Están de acuerdo con el plan todas las personas involucradas? </li></ul></ul>Inicio Elaboración Construcción Transición Arquitectura de Ciclo de Vida Fases de RUP: Elaboración Hito:
  45. 45. <ul><li>En esta fase todas las componentes restantes se desarrollan e incorporan al producto. </li></ul><ul><li>Todo es probado en profundidad. </li></ul><ul><li>El énfasis está en la producción eficiente y no ya en la creación intelectual. </li></ul><ul><li>Puede hacerse construcción en paralelo, pero esto exige una planificación detallada y una arquitectura muy estable. </li></ul>Fases de RUP: Construcción
  46. 46. <ul><li>El producto de software integrado y corriendo en la plataforma adecuada. </li></ul><ul><li>Manuales de usuario. </li></ul><ul><li>Una descripción del “release” actual. </li></ul>Fases de RUP: Construcción Productos:
  47. 47. Fases de RUP: Construcción <ul><li>Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos. </li></ul><ul><li>Condiciones de éxito: </li></ul><ul><ul><li>¿El producto está maduro y estable para instalarlo en el ambiente del cliente? </li></ul></ul><ul><ul><li>¿Están los interesados listos para recibirlo? </li></ul></ul>Inicio Elaboración Construcción Transición Capacidad Operacional Hito:
  48. 48. <ul><li>El objetivo es traspasar el software desarrollado a la comunidad de usuarios. </li></ul><ul><li>Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos). </li></ul><ul><li>Incluye: </li></ul><ul><ul><li>Pruebas Beta para validar el producto con las expectativas del cliente </li></ul></ul><ul><ul><li>Ejecución paralela con sistemas antiguos </li></ul></ul><ul><ul><li>Conversión de datos </li></ul></ul><ul><ul><li>Entrenamiento de usuarios </li></ul></ul><ul><ul><li>Distribuir el producto </li></ul></ul>Fases de RUP: Transición
  49. 49. <ul><li>Obtener autosuficiencia de parte de los usuarios. </li></ul><ul><li>Concordancia en los logros del producto de parte de las personas involucradas. </li></ul><ul><li>Lograr el concenso cuanto antes para liberar el producto al mercado. </li></ul>Inicio Elaboración Construcción Transición Producto Fases de RUP: Transición Objetivos:
  50. 50. Métodos Ágiles <ul><li>Interés creciente en los métodos ágiles (inicialmente llamados ligeros, lightweight) en los últimos años </li></ul><ul><ul><li>enfrentamiento de requerimientos cambiantes </li></ul></ul><ul><ul><li>tiempos de desarrollo escasos </li></ul></ul><ul><ul><li>clientes y usuarios cada vez más exigentes </li></ul></ul><ul><li>Caracterizados alternativamente como </li></ul><ul><ul><li>antídoto a la burocracia (métodos planificados, pesados) </li></ul></ul>
  51. 51. Métodos Ágiles <ul><li>Algunas características de los métodos ágiles </li></ul><ul><ul><li>Documentación mínima </li></ul></ul><ul><ul><li>Ciclos iterativos breves </li></ul></ul><ul><ul><li>Reacción rápida ante los cambios </li></ul></ul><ul><ul><li>Estrecha relación con el cliente </li></ul></ul><ul><ul><li>Diseño simple </li></ul></ul><ul><ul><li>Satisfacción de necesidades inmediatas </li></ul></ul><ul><ul><li>Foco en las personas </li></ul></ul><ul><ul><li>Organización libre </li></ul></ul><ul><ul><li>Procesos adaptables, no predictivos </li></ul></ul>
  52. 52. Métodos Ágiles <ul><li>El proceso de Desarrollo XP </li></ul><ul><ul><li>Fase inicial de captura de requerimientos es eliminada </li></ul></ul><ul><ul><li>El ciclo de desarrollo de XP se divide en liberaciones cada una de las cuales es medida en historias de usuario </li></ul></ul><ul><ul><ul><li>Historia de usuario: unidad funcional en un proyecto XP, debe ser entendible tanto para el cliente como para los desarrolladores, verificable y pequeña </li></ul></ul></ul>
  53. 53. Métodos Ágiles <ul><li>El proceso de desarrollo XP </li></ul><ul><ul><li>Fase de Exploración </li></ul></ul><ul><ul><li>Fase de Planificación </li></ul></ul><ul><ul><li>Fase de Iteraciones y Entregas </li></ul></ul><ul><ul><li>Fase de Producción </li></ul></ul><ul><ul><li>Fase de Mantenimiento </li></ul></ul><ul><ul><li>Fase de Muerte </li></ul></ul>
  54. 54. Métodos Ágiles
  55. 55. Principales Métodos Ágiles <ul><li>Extreme Programming, XP </li></ul><ul><li>Scrum </li></ul><ul><li>Crystal Family </li></ul><ul><li>Feature-Driven Design </li></ul><ul><li>Adaptive Software Development </li></ul><ul><li>DSDM </li></ul><ul><li>Otros </li></ul>
  56. 56. Agilidad vs. Proceso <ul><li>Ultimamente, distintos trabajos han investigado la relación entre modelos de proceso y métodos ágiles, observando lo siguiente </li></ul><ul><ul><li>CMM/CMMI y XP pueden complementarse (foco en aspectos de gestión vs. técnicos) </li></ul></ul><ul><ul><li>Métodos ágiles calzan con la esencia del mejoramiento de procesos bajo una interpretación menos literal (que CMMI, por ejemplo) </li></ul></ul><ul><ul><li>Métodos ágiles apuntan a gestión de proyectos, no a gestión de procesos </li></ul></ul>
  57. 57. Bibliografía <ul><li>Pressman Roger. “Ingeniería del Software”. Tercera </li></ul><ul><li>Software Engineering: Theory and Practice (2nd Ed.) Shari Pfleeger, Prentice Hall (2001), Cap. 1&2 </li></ul><ul><li>The Software-Research Crisis. Robert L. Glass, IEEE Software, Noviembre 1994 </li></ul><ul><li>Using Risk to Balance Agile and Plan-Driven Methods Barry Boehm, Richard Turner, IEEE Computer, Junio 2003 </li></ul><ul><li>Agile Alliance§ http://www.agilealliance.com/ </li></ul><ul><li>What is extreme programming? http://www.xprogramming.com/ </li></ul>
  58. 58. Anexos
  59. 59. Arquitectura de Sistemas Computacionales Estructuración de los Procesos Estructuración de las Comuni caciones Estructuración de los Datos Ingeniería de las comunicaciones Ingeniería de la Información Ingeniería de Software
  60. 60. Arquitectura de Sistemas Computacionales Datos Función Comunicaciones Nivel Conceptual (Esquema del Negocio) Nivel Lógico (S.I.A) Nivel Físico (Implementa ción Compu tacional) . . . .
  61. 62. Los 13 Mandamientos en el Proceso de Definición de Requisitos   Entonces Jehovah dijo al Analista Funcional: — Escribe estas palabras, porque conforme a ellas he hecho pacto contigo y con el Equipo de Desarrollo. El Analista Funcional estuvo allí con Jehovah cuarenta días y cuarenta noches. No comió pan ni bebió agua. Y en las tablas escribió las palabras del pacto, los trece mandamientos: No pensarás el cómo, tan sólo el qué y el por qué. No te pronunciarás en tiempos condicionales; en todo caso, te pronunciarás en tiempos imperativos. Evitarás recoger Detalles de Diseño. No te pronunciarás con expresiones vagas en significado, como “generalmente …”,“comúnmente …” Evitarás recoger opcionalidad en la descripción de un Requisito. Si existen distintas opciones en un Requisito, las modelarás como atributos del Requisito o en nuevos Requisitos, pero nunca en el mismo Requisito. Detallarás en un Requisito cada necesidad, de forma individual. Muchos verbos concentrados en un Requisito dificultan su comprensión y su posterior trazabilidad. Evitarás el exceso de términos y de verbos en cada Requisito. Las necesidades o informaciones se mezclarán si se proporciona demasiado detalle; ese detalle se indicará en Casos de Uso, refinando los Requisitos. No recurrirás a los Acrónimos, salvo que se recojan en Glosarios u Ontologías de Términos y previamente se haya aprobado su uso. Respetarás el equilibrio entre la necesidad a describir y el número de sílabas por palabra y el de palabras por frase, usando  “,”  y  “;”  apropiadamente en la descripción de los Requisitos para fomentar la legibilidad de los mismos. No usarás pronombres. No usarás pseudocódigo: “si fecha es mayor que …”, “iterar sobre …”, etc. No usarás términos como accesible, amigable, rápido y eficiente, entre otros; son difíciles de medir. En su lugar usarás unidades físicas para medir, por ejemplo, cómo de rápido debe rendir un Requisito, o WAI AA, para especificar claramente cómo de accesible ha de ser el Requisito. Verificarás que las aserciones puedan ser medidas de forma sencilla. Como contraejemplo, abstente de expresiones del tipo “sin sobrecargar demasiado el servidor”. Estos diez mandamientos se encierran en dos: Amarás a la  desambiguación  y a lo  axiomático  sobre todas las cosas y a las 3 C´s ( concisión, claridad y concreción)  como a ti mismo.
  62. 63. Los 13 Mandamientos en el Proceso de Definición de Requisitos   Entonces Jehovah dijo al Analista Funcional: — Escribe estas palabras, porque conforme a ellas he hecho pacto contigo y con el Equipo de Desarrollo. El Analista Funcional estuvo allí con Jehovah cuarenta días y cuarenta noches. No comió pan ni bebió agua. Y en las tablas escribió las palabras del pacto, los trece mandamientos: No pensarás el cómo, tan sólo el qué y el por qué. No te pronunciarás en tiempos condicionales; en todo caso, te pronunciarás en tiempos imperativos. Evitarás recoger Detalles de Diseño. No te pronunciarás con expresiones vagas en significado, como “generalmente …”,“comúnmente …” Evitarás recoger opcionalidad en la descripción de un Requisito. Si existen distintas opciones en un Requisito, las modelarás como atributos del Requisito o en nuevos Requisitos, pero nunca en el mismo Requisito. Detallarás en un Requisito cada necesidad, de forma individual. Muchos verbos concentrados en un Requisito dificultan su comprensión y su posterior trazabilidad. Evitarás el exceso de términos y de verbos en cada Requisito. Las necesidades o informaciones se mezclarán si se proporciona demasiado detalle; ese detalle se indicará en Casos de Uso, refinando los Requisitos. No recurrirás a los Acrónimos, salvo que se recojan en Glosarios u Ontologías de Términos y previamente se haya aprobado su uso. Respetarás el equilibrio entre la necesidad a describir y el número de sílabas por palabra y el de palabras por frase, usando  “,”  y  “;”  apropiadamente en la descripción de los Requisitos para fomentar la legibilidad de los mismos. No usarás pronombres. No usarás pseudocódigo: “si fecha es mayor que …”, “iterar sobre …”, etc. No usarás términos como accesible, amigable, rápido y eficiente, entre otros; son difíciles de medir. En su lugar usarás unidades físicas para medir, por ejemplo, cómo de rápido debe rendir un Requisito, o WAI AA, para especificar claramente cómo de accesible ha de ser el Requisito. Verificarás que las aserciones puedan ser medidas de forma sencilla. Como contraejemplo, abstente de expresiones del tipo “sin sobrecargar demasiado el servidor”. Estos diez mandamientos se encierran en dos: Amarás a la  desambiguación  y a lo  axiomático  sobre todas las cosas y a las 3 C´s ( concisión, claridad y concreción)  como a ti mismo.

×