El documento describe los conceptos fundamentales de la Ingeniería de Software, incluyendo los problemas que llevaron a su creación, sus objetivos de maximizar la calidad y productividad, y la importancia de los procesos de software para gestionar riesgos. También introduce varios modelos de proceso como el modelo en cascada, en V, de prototipación, en espiral y RUP, así como métodos ágiles.

1. Profesor : Hermón Alfaro F. Hermon.alfaro@tm-mas.com Curso Ingeniería de Software INFT.1 Universidad de Los Lagos

3. Motivación

5. ¿Ingeniería? de Software

6. Ingeniería vs Métodos Tradicionales

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, ……….

27. Modelo en Cascada

30. Modelo V

34. Modelo en Espiral

36. RUP – Rational Unified Process

37. Mapa Conceptual de RUP

54. Métodos Ágiles

58. Anexos

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. 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) . . . .

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.

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.