You are on page 1of 84

UNIVERSIDAD TECNOLÓGICA NACIONAL

Regional La Plata Dto. Sistemas

1.- Introducción a la Ingeniería del Software

Ingeniería del Software 2010

Introducción Ingeniería del Software Desarrollo del hardware
Aparición de procesadores que cada dos años doblan la capacidad de sus antecesores[1] 1946 ENIAC: Superficie de 160 m2 - 30 TM - capacidad de proceso de 30 KOPS. En 2002 El microprocesador Pentium IV a 2 Ghz ocupa una superficie de 217 mm2 y tiene una capacidad de proceso de 5.300 MTOPS En la actualidad son cuatro los factores que imprimen un ritmo acelerado a la industria del hardware. •Ley de Moore: •Incremento constante de la capacidad de operación •Miniaturización •Reducción de costes para la producción de hardware

•Avance de las comunicaciones entre sistemas.
Consecuencia obvia: ordenadores potentes, de bolsillo, en permanente conexión con grandes sistemas, redes de comunicación públicas, sistemas de localización GPS, etc. Estas cuatro líneas de avance han extendido el ámbito de aplicación del hardware, e incrementado al mismo ritmo exponencial la complejidad de los sistemas en los que se integra. Los ordenadores ya no son máquinas útiles sólo para la banca o el ejército. Se encuentran presentes en todos los ámbitos, por su capacidad de proceso y de comunicación pueden ofrecer soluciones a sistemas cada vez más complejos. Este es el escenario creado por la industria del hardware, y que en las tres últimas décadas ha implicado a los desarrolladores de software en retos los que no han sabido responder con solvencia.

[1] Ley de Moore

Introducción Ingeniería del Software Desarrollo del hardware
Desde 1965 la Ley de Moore rige la evolución de los microprocesadores
100.000.000 Pentium IV Pentium III 10.000.000 Pentium 486 DX 1.000.000 386 286 100.000 8086 10.000 8080 4004 8008 1970 1975 1980 1985 1990 1995 2000 Pentium II

Factores que imprimen aceleración al ritmo de crecimiento del hardware: •Incremento de la capacidad de operación. Consecuencias de la ley de Moore •Incremento de la miniaturización. •Reducción de costes en la producción. Comunicaciones entre sistemas

Transistores

Crisis de software Proyectos para el desarrollo de sistemas de software
Fracaso 2004 2000 19% 23% 28% 40% Problemático 53% 49% 46% 33% Éxito 29% 28% 26% 27%

Introducción Ingeniería del Software

1998
1995 1994

31%

53%

16%

El proyecto se aborta o el sistema no se llega a utilizar Desbordamiento de agendas o costes. Las funcionalidades no cubren las expectativas. Problemas funcionales Proyecto realizado en el tiempo previsto, con los costes previstos, con la funcionalidad esperada y ofreciendo un funcionamiento correcto.
Fuente: Standish Group Survey,

La primera publicación sobre programación estructurada no vio la luz hasta 1974. año en el que la NATO desarrolló la primera conferencia sobre desarrollo de software.  C. para la  En 1968 los programadores se debatían entre el uso de la sentencia GoTo. El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb. Böhm y G. y la nueva idea de programación estructurada. e “ingeniería del software” para describir el conjunto de conocimientos que existían en aquel estado inicial. ese era el caldo de cultivo en el que Edsger Dijkstra escribió su famosa carta “GoTo Statement Considered Harmful” en 1968. Jacopini publicaron en 1966 el documento que creaba una fundación eliminación de “GoTo” y la creación de la programación estructurada. y en la que se acuñaron los términos “crisis del software” para definir a los problemas que surgían en el desarrollo de sistemas de software. Glenford Myers y Wayne Stevens. publicada por Larry Constantine. Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en 1968 son:  En 1962 se publicó el primer algoritmo para búsquedas binarias.Crisis del software Introducción Ingeniería del Software Este problema se identificó por primera vez en 1968. El primero sobre análisis de requisitos apareció en 1979    .

IEEE 1993 . esto es. Otras definiciones “Disciplina para producir software de calidad desarrollado sobre las agendas y costes previstos y satisfaciendo los requisitos”. 1968 (conferencia NATO) “Establecimiento y uso de principios de ingeniería para obtener software económico que trabaje de forma eficiente en máquinas reales”. Software Engineering “(1) La aplicación de métodos sistemáticos. (2) El estudio de (1)”. operación y mantenimiento de software. S. la aplicación de la ingeniería al software. Schach 1990.Ingeniería del software Definición original: Introducción Ingeniería del Software Fritz Baver. disciplinados y cuantificables para el desarrollo.

mantenimiento y operación de los sistemas de software. IEEE. Los esfuerzos se han encaminado en tres direcciones principales.    Identificación de los factores clave que determinan la calidad del software. ha creado una cultura de la programación heroica. introduciendo métodos y formas de trabajo sistemáticos. y por organismos de estandarización (SEI. La forma de trabajo de programadores individuales surgida por la necesidad de los primeros programas. Identificación de los procesos necesarios para producir y mantener software. y en la actualidad una de las principales resistencias a la implantación de técnicas de ingeniería para el desarrollo de sistemas . Acotación. para el desarrollo de software que es la principal causa de los problemas apuntados.Ingeniería del software Introducción Ingeniería del Software Desde 1968 hasta la fecha han sido muchos los esfuerzos realizados por los departamentos de informática de las universidades. ISO) para identificar las causas del problema y definir pautas estándar para la producción y mantenimiento del software. disciplinados y cuantificables. El resultado ha sido la necesidad de profesionalizar el desarrollo. estructuración y desarrollo de la base de conocimiento necesaria para la producción y mantenimiento de software.

Ingeniería del software Características deseables de los Productos de Software • Mantenible. • Fácil de Usar  El software debe contar con una interfaz de usuario adecuada y su documentación. • Confiable  El software no debe causar danos físicos o económicos en el caso de fallos.  Debe ser posible que el software evolucione y que siga cumpliendo con sus especificaciones. • Eficiente  El software no debe desperdiciar los recursos del sistema. .

– Proporcionan un marco para implementar procedimientos de aseguramiento de la calidad. . mantenimiento y operación del software  De las mejores prácticas. – Proporcionan continuidad y entendimiento entre el trabajo de personas y organizaciones distintas. pruebas. • Los estándares son útiles porque: Agrupan lo mejor y más apropiado de las buenas prácticas y usos del desarrollo de software.Estándares y modelos Introducción Ingeniería del Software : •La Ingeniería del Software es una ingeniería muy joven que necesitaba  Definirse a sí misma: ¿Cuáles son las áreas de conocimiento que la comprenden?  Definir los procesos que intervienen en el desarrollo. extraer modelos de cómo ejecutar esos procesos para evitar los problemas de la “crisis del software”  Definir criterios unificadores para las tareas de requisitos. gestión de la configuración. etc . – Engloban los “conocimientos”.

y reconocimiento de la Ingeniería del software a: ISO.Introducción Ingeniería del Software Principales organizaciones de estandarización Desde la identificación del fenómeno “crisis del software”. normativos o estándares de procesos o prácticas necesarias para abordar el desarrollo. departamentos de defensa. han sido muchas las organizaciones que han abordado. por sus trabajos y esfuerzos realizados para la normalización. sociedades de profesionales. el análisis de problemas en el desarrollo de sistemas de software. con mayor o menor rigor. .Computer Society y SEI. departamentos de calidad y procesos de empresas los que han ido generando normas y estándares. IEEE. Sus trabajos se han encaminado a la localización de las causas. mantenimiento y operación con las mayores garantías de éxito. y a la exposición en textos didácticos. Este compendio considera como entidades de mayor reconocimiento internacional. Han sido muchos los departamentos de universidades. organismos de normalización o investigación nacionales o internacionales.

incluyendo microprocesadores y equipos. Integrado en la Universidad Carnegie Mellon.sei. (SEI http://www. La misión del JTC1 es la “estandarización en el campo de campo de los sistemas de tecnologías de la información.edu/). y por tanto fiabilidad de resultados previsibles de una organización de software. En 1987 la Organización Internacional para la Estandarización (ISO) y la Comisión Internacional Electrotécnica (IEC).Principales organizaciones de estandarización Introducción Ingeniería del Software  ISO Organización Internacional para la Estandarización.cmu. que en sus casi 15 años de implantación efectiva en entornos de producción de software han demostrado su efectividad en las dos finalidades que cubren: como marco de referencia para mejora de procesos. . establecieron un Comité Internacional (JTC1) para las Tecnologías de la Información. siendo la aportación más significativa los modelos de madurez de las capacidades: CMM y CMMI. y como criterio de evaluación para determinar la madurez. Fundada en 1947 Son miembros 87 países. Los estándares o instrucciones técnicas más importantes para la Ingeniería del Software:  SEI   ISO/IEC 12207 ISO/IEC TR 15504 Instituto de Ingeniería del software. Los trabajos y aportaciones realizadas por el Instituto de Ingeniería del Software a la Ingeniería del software son también referente mundial de primer orden.

cursos de formación. Std.Principales organizaciones de estandarización Introducción Ingeniería del Software  IEEE Computer Society IEEE Es el Instituto de Ingenieros en electricidad y electrónica (Institute of Electrical and Electronics Engineers). Su finalidad es avanzar en la teoría. Realiza conferencias. 830 Prácticas recomendadas para las especificaciones de software. Algunos de ellos. publicaciones.org) es una sociedad integrada en IEEE.000 miembros en todo el mundo. Estándares para la Ingeniería del Software IEEE ha desarrollado estándares para todas las áreas de Ingeniería del Software. investigar y promover la información de las tecnologías eléctricas y electrónicas. Std. La IEEE Computer Society (www. Su misión es preservar. Surgió en 1963 con la fusión del AIEE (Instituto Americano de Ingenieros Eléctricos) y el Instituto de Ingenieros de Radio (IRE). y desarrolla estándares. 1362 Guía para la especificación del documento de requisitos “ConOps” 1063 Estándar para la documentación de usuario de software. 1012 Estándar para la verificación y validación de software. correspondientes a las principales áreas específicas de la Ingeniería del Software son: IEEE IEEE IEEE IEEE IEEE Std. práctica y aplicación de las tecnologías de la información. 1219 Estándar para el mantenimiento del software . Std. formada en la actualidad por más de 100. Std.computer.

gestión de la configuración. mantenimiento y operación del software •ISO/IEC 12207: Procesos del ciclo de vida del software  De las mejores prácticas. •IEEE 830 .ISO/IEC 14764 … . pruebas. etc. extraer modelos de cómo ejecutar esos procesos para evitar los problemas de la “crisis del software” •CMM / CMMI •ISO/IEC TR 15504  Definir estándares menores para dibujar criterios unificadores en requisitos.IEEE 1362 .Principales estándares y modelos Introducción Ingeniería del Software •SWEBOK: Software Engineering Body of knowledge •La Ingeniería del Software es una ingeniería muy joven que necesitaba:  Definirse a sí misma: ¿Cuáles son las áreas de conocimiento que la comprenden?  Definir los procesos que intervienen en el desarrollo.

org). 1 Software. Roger Pressman e Ian Sommerville. El cuerpo de conocimiento identificado por el proyecto SWEBOK se ha configurado como el estudio más relevante y como la referencia de más autoridad en toda la comunidad informática para la acotación y descripción de los conocimientos que configuran la Ingeniería del software. Universidad de Québec (Montreal) Empresas y organizaciones como: Rational. MITRE. Las fuentes de información para la identificación de las áreas de conocimiento han sido los índices de textos genéricos sobre la Ingeniería del Software. Comisión creada por IEEE Computer Society y ACM (Association for Computer Machinery) para definir el cuerpo de la Ingeniería del Software . los curricula para licenciatura y postgrado en Ingeniería de Software. SAP. Boeing. Raytheon. y los criterios de admisión que se utilizan en el postgrado.swebok. Los autores de las tres principales obras de Ingeniería del Software: Steve Mc Connell. En el proyecto también están representados: los dos principales organizaciones de estandarización en Ingeniería del Software: IEEE e ISO/IEC JTC1/SC/.Introducción Ingeniería del Software SWEBOK El proyecto SWEBOK (Software Engineering Body of Knowledge) comenzó sus actividades de manera efectiva dentro del SWECC1 en 1997 (aunque el comité SWECC se creó en 1993). Todos estos datos se han organizado siguiendo el estándar ISO/IEC 12207. Construx. En 2001 el proyecto publicó ya una definición consensuada del cuerpo de conocimiento aceptado en la ingeniería del software (http://www. Engineering Coordinating Comitee”.

Así por ejemplo. el área de conocimiento de requisitos. y no hay un consenso sobre el contenido de su currículo. bases de datos relacionales o redes o tecnología de redes y comunicaciones. Por supuesto que un Ingeniero de Software debe conocer las técnicas de cada momento. tales como lenguajes específicos de programación. El proyecto parte de la suposición de que es necesario establecer cuál es el cuerpo de conocimiento que deben conocer los ingenieros del software. y en su desarrollo ha agrupado este conocimiento en 10 áreas      Requisitos Diseño Construcción Pruebas Mantenimiento      Gestión de la configuración Gestión Procesos Herramientas y métodos Calidad Es importante resaltar que estas áreas no incluyen aspectos importantes de las tecnologías de la información. pero la definición de procesos y metodología de trabajo es la “esencia” de la profesión. Los problemas que pueden derivarse en un proyecto por una mala obtención o gestión de los requisitos son indistintos del hardware o lenguaje de programación empleado.SWEBOK Introducción Ingeniería del Software SWEBOK da el primer paso necesario para constituir a la Ingeniería del Software como profesión: la delimitación del cuerpo de conocimiento que comprende la profesión. . Esta es una consecuencia de la distinción que entre “esencia” y “accidente” se establece desde un enfoque de ingeniería. sí que puede considerarse como “esencia” de la profesión. Sin esta delimitación no es posible validar de forma universal exámenes de licenciatura. no es posible la preparación para acceder a la profesión. y todo nos hace suponer que seguirán siendo idénticos dentro de otros cuatro lustros. Eran los mismos hace dos décadas que ahora.

controlar y mejorar el marco Como base de referencia para el trabajo e intercambio entre organizaciones de software Ciclo de vida del software Periodo de tiempo que comienza al concebir la idea de un nuevo sistema de software. desarrollo. proporcionando un marco y un lenguaje común en la disciplina del software • Establece un marco común para el ciclo de vida del software para – – – Adquisición. . y termina cuando este se retira y deja de funcionar. suministro.ISO 12207: Propósito Introducción Ingeniería del Software Establecer un estándar para evitar una situación de Torre de Babel en la gestión e ingeniería del software. operación y mantenimiento del software Gestionar.

•El estándar sirve de referencia desde dos perspectivas diferentes: •Para la adquisición de sistemas y servicios de software. Métodos concretos para el desarrollo. mantenimiento y operación de productos de software. Define el QUÉ.Introducción Ingeniería del Software ISO 12207: Propósito • El estándar no prescribe: – – – Que deba emplearse ningún tipo de documentación específica. actividades y tareas implicados en el desarrollo. •Para el suministro. No se trata de un estándar de certificación. sino de un estándar para la normalización. mantenimiento u operación del software. asentando un marco estándar de referencia internacional. desarrollo. . pero no se ocupa ni prescribe técnicas específicas. mantenimiento y operación de los sistemas de software. no el CÓMO. tipo ISO 9000. •El estándar no cubre el desarrollo de productos de software para distribución comercial masiva (productos “enlatados”). Dice cuáles son los procesos. Que deba emplearse un tipo específico de ciclo de desarrollo.

2 Infraestructura 7. Procesos organizacionales 7.1 Adquisición 5.1 Gestión 7.2 Gestión de la configuración 6.5 Validación 6.7 Auditoría 6.3 Desarrollo 5.3 Control de calidad 5.Procesos de soporte 6.3 Mantenimiento 6.1 Documentación 6.2 Suministro 6.6 Reuniones 6..3 Mejora 7.4 Formación . Procesos primarios 5.4 Verificación 6.3 Operación 5.8 Resolución de problemas 7.Introducción Ingeniería del Software ISO 12207: Procesos 5.

ISO 12207 Introducción Ingeniería del Software Actividad 1 Tarea 1 Proceso 1 Tarea 2 … ISO 1227 define los procesos que componen el ciclo de vida del software Tarea n … Proceso N Actividad n Ciclo de vida Concepto Retirada … Tarea 1 Tarea 2 … Tarea n .

ISO 12207 Introducción Ingeniería del Software PROCESO ACTIVIDAD 1 ••• ACTIVIDAD n  Un proceso está compuesto por actividades. asignaciones… ACT Problemas y acciones correctivas PROCESO DO Ejecución de planes y tareas CHECK Evaluación y medición FIN . TAREA 1 ••• TAREA X TAREA 1  La descomposición del proceso en actividades y tareas se realiza sobre el concepto de ciclo de mejora PDCA “Plan – Do – Chek – Act” (Planificación. ejecución. medición y mejora) INICIO PLAN Tareas. agenda.  Una actividad está compuesta de tareas.

¿Qué es un sistema? “Colección de componentes organizados para cumplir una función o conjunto de funciones específicas”. Pressman 1982 . Desde esta perspectiva se establece a la Ingeniería de sistemas como fundamento de la Ingeniería del Software. Sistema de Entrada IEEE Standard 610.12-1990 Elemento del sistema Sistema Elemento del sistema Elemento del sistema Elemento del sistema Sistema de Salida “Colección de elementos relacionados de forma que puedan realizar un objetivo tangible”.INGENIERÍA DE SISTEMAS  Introducción Ingeniería del Software  ISO 12207 establece un nexo con la Ingeniería de sistemas al considerar al software como parte de un sistema.

Ingeniería de sistemas El término “Ingeniería de sistemas” surgió por primera vez en 1956. procedimientos. software. En cuyo caso se trata en realidad de un “sub-sistema de software”. porque el sistema es prácticamente software. Un sistema de software puede ser también una parte de un sistema mayor. P ej: El sistema SW de un avión de combate es en realidad un subsistema de SW del avión. Hitch. y fue propuesto por H. . Sistema de Software Sistema o sub-sistema formado por una colección de programas y documentación que de forma conjunta satisfacen unos determinados requisitos. herramientas y otros factores organizativos. o el programa de misiles balísticos USAF/USN. organizados para llevar a cabo un objetivo común. presidente del departamento de Ingeniería Aeronaútica de la Universidad de Pensilvania. personas. Los principios de Ingeniería de sistemas desarrollados en los 60 y 70 se aplicaron en programas como el Apolo. etc. realiza su objetivo en un ordenador independiente. A este tipo de sistemas se les denomina también “sistema intensivo de software”. por ejemplo.Introducción Ingeniería del Software INGENIERÍA DE SISTEMAS Sistema Conjunto de elementos de hardware. para intentar desarrollar una disciplina de ingeniería que pudiera abarcar el desarrollo de grandes sistemas que empleaban diversas disciplinas de ingenierías específicas: construcción de bombarderos. submarinos. Un sistema de software puede ser en sí mismo un sistema independiente que.

1985 La principal función de la ingeniería de sistemas es garantizar que el sistema satisface los requisitos durante todo el ciclo de vida.INGENIERÍA DE SISTEMAS Algunas definiciones Introducción Ingeniería del Software Ingeniería de sistemas comprende la función de gestionar todo el esfuerzo de desarrollo para conseguir un balance óptimo entre todos los elementos del sistema. tanto de hardware como de software. . consigue un balance óptimo de todos sus componentes. que con un ciclo de vida optimizado. Todas las demás consideraciones se alinean sobre esta función. Es el proceso que transforma la necesidad operacional en la descripción de los parámetros del sistema. Defense Systems Management College. 1989 Los procesos de ingeniería de sistemas integran las secuencias de actividades y decisiones que transforman la definición de una necesidad en un sistema. USAF. Identifica el ciclo de desarrollo y los procesos que será necesario aplicar. Desde la Ingeniería de Sistemas se desarrolla la línea base técnica para todo el desarrollo. e integra esos parámetros para mejorar la eficiencia general del sistema. Wymore 1993 La ingeniería de sistemas define el plan para gestionar las actividades técnicas del proyecto.

cuando corresponda. Estudiar y analizar las posibles soluciones. utilidad. pruebas.  Control de los procesos: Determinar los métodos para controlar las actividades técnicas del proyecto y los procesos. inspecciones… . Trabaja cerca del cliente para establecer las necesidades operacionales. opciones de implementación.  Evaluación del producto: Determinar la calidad y cantidad de los productos elaborados. el esfuerzo requerido para cada una. a través de evaluaciones. necesidades y restricciones obtenidas y analizadas en los requisitos del sistema. revisión de los productos intermedios y ejecución de las acciones correctivas. su prioridad y los riesgos que implican para el proyecto. análisis. sopesando las necesidades inmediatas. la medición del progreso. evolución del sistema…  Planificación de los procesos: Determinar los grupos de tareas técnicas que se deben realizar.  Análisis de la solución: Determinar las opciones posibles para satisfacer los requisitos y las restricciones. Seleccionar la mejor.INGENIERÍA DE SISTEMAS Introducción Ingeniería del Software Funciones de la Ingeniería de sistemas  Definición del problema: Determinación de las expectativas hacia el producto.

Ingeniería del software Codificación Pruebas unitarias .Introducción Ingeniería del Software INGENIERÍA DE SISTEMAS Ingeniería de sistemas – Ingeniería de sistemas de software – Ingeniería del software Análisis del sistema Pruebas del sistema Pruebas de integración del sis Diseño del sistema Ingeniería de sistemas Ingeniería de sistemas de software Análisis de requisitos del sw Pruebas del sistema de sw Diseño de la arquitectura del sw Pruebas de integración del sw Ingeniería del software Diseño detallado del software Pruebas del subsistema de SW.

INGENIERÍA DE SISTEMAS Introducción Ingeniería del Software Gestión de Proyectos Ingeniería de sistemas – Gestión de proyectos – Ingeniería del Soft.      Planificación Organización Personal Dirección Control Ingeniería de Sistemas Ingeniería del Software      Definición del problema Análisis de la solución Planificación de procesos Control de procesos Evaluación del producto     Diseño del software Codificación Pruebas unitarias Integración del subsistema de software .

tales como constantes de compiladores. La Ingeniería del Software trata de áreas muy diversas de la informática y de las ciencias computacionales. que ofrece métodos o técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. sistemas operativos o desarrollos de Internet. . • Es una disciplina o área de la información o ciencias de la computación.Definición de Ingeniería de Software.

1965  Orientación por lotes  Distribución limitada  Software a medida 1975 .Características y evolución del software • un poco de historia – Primeras décadas: • Desarrollar el hardware • Reducir costes de procesamiento y almacenamiento – Década de los ochenta: • Desarrollo de la microelectrónica • Mayor potencia de cálculo y reducción de costes – Objetivo actual: mejorar la calidad de las soluciones software.1989  Potentes sistemas de sobremesa  Tecnología de objetos  Sistemas expertos  Redes neuronales  Cliente/servidor  Tecnologías de Internet. 1989 - AUMENTAN los problemas del desarrollo de software:  Subexplotación del potencial del hardware  Incapacidad de atender a la demanda  Incapacidad de mantener el software existente .1975  Multiusuario  Tiempo real  Bases de datos  Software como producto  Mayores gastos de mantenimiento  Sistemas distribuidos  Inteligencia Artificial  Hardware de bajo coste  Impacto en el consumo  Redes area local y global  Gran demanda 1959 . 1965 .

control de procesos de fabricación. procesadores de texto.. • la organización controla la especificación – Productos Personalizados • desarrollados específicamente para un cliente • aplicaciones de negocio. • el cliente controla la especificación de la aplicación • ...Características y Evolución del Software • Software – programas – archivos de configuración – documentación de la estructura del sistema – manuales de instalación y uso – sitios web con información y actualizaciones Tipos de Software – productos genéricos • sistemas producidos por una organización y que se venden en el mercado abierto • sistemas gestores de bases de datos.... paquetes gráficos. sistemas de control de tráfico aéreo.

Características y Evolución del Software • El software desde una perspectiva industrial – El valor del software: de “elemento añadido” a principal elemento de coste – El desarrollo del software: – Algunas preguntas: • ¿Por qué se tarda tanto? (y casi siempre más de lo previsto) • ¿Por qué la productividad es tan baja? • ¿Por qué cuesta tanto? • ¿Por qué siempre quedan errores sin localizar? .

Naturaleza y Problemas del Desarrollo de Software • El software como elemento lógico. – Se desarrolla. Sin tiempo para recoger datos históricos Planificación y estimaciones imprecisas Dificultad de mantener el software existente Insatisfacción del cliente Calidad Baja productividad • . no se fabrica: • Calidad del diseño. • Costes más importantes en la ingeniería • Gestión especial de los proyectos – Se “deteriora” con el mantenimiento – Desarrollo a medida (ausencia de componentes) La “crisis” del software: problemas que aparecen en el desarrollo del software al desarrollar. mantener y atender la demanda de nuevas aplicaciones.

.Uso de herramientas – Mitos del software: .Entrega al cliente: programa funcionando MITOS DEL CLIENTE .Calidad = el programa se ejecuta sin errores .Naturaleza y Problemas del Desarrollo de Software • Causas de la crisis del software – Naturaleza lógica del software – Mala gestión de los proyectos ( ausencia de datos.Flexibilidad del software ante los cambios .. ingenieros de software) .) – Ausencia de entrenamiento formal en nuevas técnicas (programadores MITOS DE GESTIÓN vs. deficiente comunicación.Requisitos establecidos como una declaración general de objetivos .Uso de estándares – Resistencia al cambio .Mala planificación: aumento de programadores MITOS DE LOS DESARROLLADORES .Programa funcionando = fin del trabajo . .

La Ingeniería del Software • Definiciones – establecimiento y uso de principios de ingeniería robustos. métodos y herramientas para solucionar problemas. y teniendo en cuenta restricciones financieras y organizativas • “todos los aspectos de producción”: comprende procesos técnicos del desarrollo y actividades como la administración de proyectos. orientados a obtener software económico. desarrollo de herramientas. fiable. métodos y teorías – Actividad de • modelado • solución de problemas • adquisición de conocimiento • dirigida por una fundamentación . eficiente y que satisfaga las necesidades del usuario – disciplina que comprende todos los aspectos de la producción de software. desde las etapas iniciales hasta el mantenimiento: • “disciplina de ingeniería”: aplicación de teorías.

La Ingeniería del Software • Trata de ser la respuesta a la crisis del software • Combinación de elementos: métodos completos para todas las fases mejores técnicas de control de calidad mejores elementos de programación herramientas para automatizar los métodos filosofía de coordinación. control y buena gestión .

complicados o caros para tener una experiencia de primera mano – Permiten visualizar y comprender sistemas que no existen o que sólo se supone que existen – Ejemplos: • Biología: modelos de dinosaurios a partir de restos • Física: modelos que representan cómo se reúnen materia y energía en los niveles subatómicos más bajos • El sistema en el mundo real serían dinosaurios o partículas subatómicas modelos . pequeños.Modelado • • Modelado: método básico de la ciencia Modelo – Representación abstracta de un sistema que da respuesta a preguntas sobre el sistema – Útiles cuando se manejan sistemas grandes.

control de tráfico aéreo.Modelado – Los ingenieros de software necesitan • Comprender el ambiente de funcionamiento del sistema: construyen modelos del dominio del problema (sistemas de bolsa.. diagramas de UML) SIST EMA DE PAGOS Y FACT URACIÓN Solicitar bienes o servicios <<subsistema>> Sistema de visión Hojear facturas iniciador Confirmar pedido iniciador <<subsistema>> <<subsistema>> Controlador del brazo <<subsistema>> Controlador del asidero Enviar factura al comprador iniciador iniciador <<subsistema>> Sistema de identificación de objetos Vendedor Pagar factura Comprador <<extend>> iniciador Planificar pago factura Rechazar factura Realizar transacción Pagar recargo por saldo deudor <<subsistema>> Pagar factura en día vencimiento Sistema de cuentas bancarias <<subsistema>> Sistema de selección de embalajes <<subsistema>> <<subsistema>> Sistema de embalaje Controlador de cinta transportadora Enviar aviso .) • Comprender los distintos sistemas que podrían construir para evaluar alternativas: construyen modelos del dominio de la solución • Técnicas y herramientas para construir los modelos (por ejemplo...

implementación Otras actividades del desarrollo para evaluar la adecuación de los modelos – revisiones del análisis: el modelo del dominio del problema se compara con la realidad del cliente – revisiones del diseño: el modelo del dominio de la solución se compara con los objetivos del proyecto – pruebas: el sistema se valida contra el modelo del dominio de la solución – administración del proyecto: se compara el modelo del proceso de desarrollo (calendario y presupuesto) con la realidad (trabajos entregados y recursos gastados) • • . en varios pasos: 1. Analizar el problema 3. Formular el problema 2. Buscar soluciones 4. diseño del sistema 4. análisis 3. obtención de requerimientos 2.Solución de Problemas • Los ingenieros de software buscan una solución adecuada. Especificar la solución Actividades básicas del desarrollo 1. Decidir la solución más adecuada 5.

) – Gerente o director del proyecto: planifica y calcula el presupuesto. coordina a los desarrolladores y cliente – Usuarios finales: los que van a utilizar el sistema • Papel (rol) – Conjunto de responsabilidades en el proyecto o en el sistema – Asociado con un conjunto de tareas y se asigna a un participante – Un mismo participante puede cumplir varios papeles . diseñadores. programadores....Participantes y Papeles • Participantes: todas las personas involucradas en el proyecto – Cliente: encarga y paga el sistema – Desarrolladores: construyen el sistema (analistas.

.. resultados de pruebas para el gerente..) Actividades.) que pueden componerse de otras actividades – Tarea: unidad elemental de trabajo que puede ser administrada.. manual de usuario.. administración. equipamiento y recursos humanos • al planificar.) – Dos tipos: • Producto de trabajo interno: producto para el consumo interno del proyecto (por ejemplo. una revisión de la estructura de la base de datos. entrega. consumen recursos. fragmento de software. dan como resultado productos de trabajo y dependen de productos de trabajo producidos por otras tareas – Recursos: bienes que se utilizan para realizar el trabajo: • tiempo... producto final.. Tareas y Recursos – Actividad (o fase): conjunto de tareas que se realiza con un propósito específico (obtención de requisitos. el gerente divide el trabajo en tareas y les asigna recursos • • ..Otros Conceptos de la Ingeniería del Software • Sistemas y Modelos – Sistema: realidad subyacente – Modelo: cualquier abstracción de la realidad Productos de trabajo – Artefacto o elemento que se produce durante el desarrollo (documento..) • Entrega: producto de trabajo para un cliente (especificación de requisitos...

seguridad y bajo coste) que aumentan la complejidad del proyecto – Requerimientos • características que debe tener el sistema • requerimiento funcional: área de funcionalidad que debe soportar el sistema (por ejemplo. fiabilidad.. proporcionar billetes de tren en menos de un segundo) – Otras restricciones: por ejemplo. requerimientos y restricciones – Objetivos: • principios de alto nivel que se utilizan para guiar el proyecto • definen los atributos realmente importantes del sistema (seguridad. proporcionar billetes de tren) • requerimiento no funcional: restricción que se establece sobre el funcionamiento del sistema (por ejemplo.) • a veces hay conflicto entre objetivos (por ejemplo..Otros Conceptos de la Ingeniería del Software • Objetivos. de una determinada plataforma o de un sistema antiguo que el cliente no quiere retirar . utilización de un determinado lenguaje..

Otros Conceptos de la Ingeniería del Software • Notaciones. Unified Modelling Language. Métodos y Metodologías – Notación: conjunto de reglas gráficas o de texto para representar un modelo (UML.) . Proceso Unificado de Desarrollo. Por ejemplo: • un algoritmo de ordenación es un método para ordenar elementos en una lista • la administración de la configuración es un método para el seguimiento de los cambios – Metodología: colección de métodos para la resolución de una clase de problemas (OMT. Catalysis. metodología de Booch... es una notación gráfica orientada a objetos para representar modelos) – Método: técnica repetible para resolver un problema específico..

El DistribuidorDeBilletes muestra el precio del billete 4. El Viajero coge el billete y el cambio Requisitos especiales: Si la transacción no ser termina después de un minuto de inactividad. El Viajero inserta una cantidad de dinero que. El Viajero se para frente al distribuidor automático de billetes Flujo de eventos: 2. el DistribuidorDeBilletes devuelve todo el dinero insertado ingeniería de requerimientos – el cliente y los desarrolladores definen el propósito y objetivos del sistema – resultado: descripción del sistema en términos de participantes (actores) y funciones (casos de uso) • actores: entidades externas que interactúan con el sistema (incluyen roles como usuarios finales u otros sistemas con los que interactúa el sistema) • casos de uso: secuencias de eventos que describen todas las acciones posibles entre un actor y el sistema para una función específica. – se acuerdan requisitos no funcionales. El Viajero selecciona las estaciones de origen y destino 3. debe ser igual que el precio del billete 5. al menos.Actividades de Desarrollo • ReservaBilletes Viajero CompraBillete Anulación reserva Nombre del caso de uso: Actor participante: CompraBillete Iniciado por Viajero Precondición: 1. El DistribuidorDeBilletes emite el billete especificado al Viajero y devuelve el cambio si es necesario Postcondición: 6. Por ejemplo: • el distribuidor de billetes debe estar disponible al menos un 95% del tiempo • el distribuidor de billetes debe dar respuesta en menos de un segundo después de seleccionada la transacción .

Actividades de Desarrollo • Análisis – Se produce un modelo correcto. consistente. realista y verificable – Transformación de los casos de uso en un modelo que describe por completo el sistema y que se usará en el diseño – Descubrimiento y resolución con el cliente de ambigüedades e inconsistencias en el modelo de casos de uso Transacción da como resultado cantidad pagada BilleteTren Saldo válido para Moneda Papel Zona . claro. completo.

reestructuración del modelo de objetos para lograr los objetivos de diseño.. • Resultado: modelo de objetos detallado Procesamiento de facturas Planificador de pagos Gestor de pedidos Solicitud de pago Confirmación de pedidos Factura – Actividades del diseño • Diseño arquitectónico • Especificación de los subsistemas • Diseño de interfaz • Diseño de componentes • Diseño de la estructura de datos • Diseño procedimental (algoritmos) . optimización del modelo para mejorar el rendimiento. descomposición en subsistema IU Solicitud de pago Comprador Procesamiento de solicitudes de pago – Diseño de objetos: • Definición de objetos e interfaces de subsistemas.. almacenamiento de datos persistentes.. control de acceso.Actividades de Desarrollo • Gestión facturas comprador Gestión de planificación de pagos Gestión de cuentas Diseño – Diseño del sistema • Definición de los objetivos de diseño • Descomposición del sistema en subsistemas abordables por equipos • Selección de estrategias para la construcción (plataformas hardware y software.) • Resultado: descripción de las estrategias....

Actividades de Desarrollo <<subsystem>> Gestión Trabajos Externos <<subsystem>> Gestión Sistema <<subsystem>> Mantenimientos de Gestión <<subsystem>> Gestión Mantenimiento Correctivo <<subsystem>> Validación Usuarios <<subsystem>> Gestión Instalaciones <<subsystem>> Gestión Mantenimiento Preventivo <<subsystem>> Gestión Máquinas Subgrupo <<subsystem>> Gestión Subgrupos-Instalaciones .

Actividades de Desarrollo <<subsystem>> Gestión Trabajos Externos <<subsystem>> Gestión Sistema Alta Instalaciones <<subsystem>> Mantenimientos de Gestión <<include>> <<include>> Baja Instalaciones <<include>> <<subsystem>> Gestión Mantenimiento Correctivo <<subsystem>> Validación Usuarios <<subsystem>> Gestión Instalaciones Validar Usuario Administrador (from Validación Usuarios) <<include>> Modificación Instalaciones (from Validación Usuarios) <<subsystem>> Gestión Mantenimiento Preventivo <<subsystem>> Gestión Máquinas Subgrupo <<subsystem>> Gestión Subgrupos-Instalaciones Operario (from Validación Usuarios) Consulta Instalaciones <<subsystem>> Gestión Máquinas Alta Características-Maq <<include>> <<include>> Gestión Características Máquinas Gestión Tareas Máquinas Administrador (from Validación Usuarios) Baja Características-Maq <<include>> Validar Usuario <<include>> Modificación Características-Maq (from Validación Usuarios) Operario (from Validación Usuarios) Consulta Características-Maq .

Actividades de Desarrollo
Nombre Prioridad Actor Extends Includes Pre-Condiciones Post-Condiciones Alta Características Máquina Media Administrador Ninguno Validar Usuario 1. El usuario está identificado. 2. El usuario selecciona la opción de altas en el formulario. 1. Los datos de la nueva característica quedan guardados si el proceso finaliza correctamente. 2. Los datos de la nueva característica no quedan guardados si se produce algún error durante el proceso. 1. El sistema muestra el formulario de altas. 2. El usuario introduce los datos. 3. El sistema realiza la validación de los datos. 4. Si la característica ya existe [A]. 5. Si los datos no son correctos [B]. 6. El usuario selecciona la opción de Guardar. 7. El sistema guarda los datos. 8. Si se guarda correctamente se visualiza un mensaje, si hay algún problema el sistema avisa con un mensaje de error. El proceso se puede cancelar en cualquier momento. A. Si la característica ya existe se visualizan sus datos. B. Datos incorrectos, ir a punto 2.
: Administrador Opciones Frm Cliente CT RL Alta Instalación Form_Alta Validar Datos INST ALACION Resultado Alta MENSAJES Seleccionar Crea() Crea()

Descripción

Mostrar

Introducir Datos() Comprobar() Obtener Datos

Excepciones

...

Mostrar(Datos)

Si no Existe

Cubrir_Datos() Comprobar()

Alta Características-Maq

Datos Correctos Crear_Alta()

<<include>>
Construir

<<include>> Baja Características-Maq <<include>> Validar Usuario Administrador
(from Validación Usuarios)

Visualizar Resultado

Datos no Correctos

Construir

<<include>> Modificación Características-Maq

(from Validación Usuarios)

Visualizar Mensaje Fin Si Fin Si

Operario
(from Validación Usuarios)

Consulta Características-Maq

Actividades de Desarrollo
Nombre Prioridad Actor Extends Includes Pre-Condiciones Post-Condiciones Alta Características Máquina Media Administrador Ninguno Validar Usuario 1. El usuario está identificado. 2. El usuario selecciona la opción de altas en el formulario. 1. Los datos de la nueva característica quedan guardados si el proceso finaliza correctamente. 2. Los datos de la nueva característica no quedan guardados si se produce algún error durante el proceso. 1. El sistema muestra el formulario de altas. 2. El usuario introduce los datos. 3. El sistema realiza la validación de los datos. 4. Si la característica ya existe [A]. 5. Si los datos no son correctos [B]. 6. El usuario selecciona la opción de Guardar. 7. El sistema guarda los datos. 8. Si se guarda correctamente se visualiza un mensaje, si hay algún problema el sistema avisa con un mensaje de error. El proceso se puede cancelar en cualquier momento. A. Si la característica ya existe se visualizan sus datos. B. Datos incorrectos, ir a punto 2.
Sistema (from Validar Usuario) Administrador (from Alta Máquinas)

Administrador Validado

Descripción

Visualizar Formulario

Seleccionar Formulario

Comprobar Datos

Introducir Datos

Excepciones

Datos Incorrectos

Mensaje "Error Datos"

Datos Correctos

Comprobar Existencia de la Instalación

Si Exi ste

Visualizar Datos Instalación Seleccionar Guardar

No Existe

Alta Características-Maq

<<include>> <<include>>

Guardar Datos Instalación
Error al Guardar

Baja Características-Maq <<include>> Validar Usuario Administrador
(from Validación Usuarios)
Instalación Guardada

Mensaje "Error"

<<include>> Modificación Características-Maq

(from Validación Usuarios)

Mensaje "Instalación guardada"

Operario
(from Validación Usuarios)

Consulta Características-Maq

Actividades de Desarrollo
Registra-venta-de Descrita-por 1 n 0..1 LineaDeVenta cantidad 1..n Contenida-en Registra-completas 1 Venta fecha hora 1 Pagada-mediante 1 Pago cantidad n 1 1 Iniciada-por 1 Cliente 1 Cajero Capturada-en 1 CatalogoDe Productos Especificacion DelProducto Contiene descripción 1 1..n precio articuloID 1 Utilizado-por n Abastece 1 n Articulo 1..n

Tienda dirección nombre

1 Alberga 1..n Registro 1 1 1

Iniciado-por

1 Encargado

Registra-ventas-en

Actividades de Desarrollo

Servidor

ODBC

SGBD

TCP/IP

TCP/IP Cliente

Red Local

Impresora

TCP/IP

Cliente

Actividades de Desarrollo .

... y comparación con el modelo de requerimientos – Objetivo: descubrir la mayor cantidad posible de errores que se puedan reparar antes de entregar el sistema Mantenimiento – Mejoras en el sistema (nuevas funciones. del modelo de objetos) en código fuente – Incluye: • implementación de atributos y métodos de cada objeto • integración de todos los objetos para que funcionen como un solo sistema Pruebas – Pruebas de unidad: comparación del modelo de diseño con cada objeto y subsistema – Pruebas de integración: combinaciones de subsistemas y comparación con el modelo de diseño del sistema – Pruebas del sistema: ejecución de casos típicos y excepcionales...) – Actividad más costosa del ciclo de vida de un producto software • • . facilidad de uso.Actividades de Desarrollo • Implementación – Traducción del modelo de diseño (por ejemplo.) – Corrección de errores – Adaptación a cambios en el entorno (hardware.. software. legislación.

. informes de evolución y calidad.... plataformas hardware y software..Actividades de Desarrollo • Actividades de administración del desarrollo – Comunicación • Actividad crítica y costosa en tiempo • Intercambio de modelos y documentos. errores encontrados. – Administración del proyecto • Objetivo: asegurar la entrega de un sistema de alta calidad a tiempo y dentro del presupuesto • Planificación y presupuesto del proyecto • Contratación de desarrolladores y coordinación de equipos • Vigilancia de la evolución del proyecto • Detección de desviaciones e intervención .. mejoras del sistema. negociaciones. • Herramientas y notaciones – Gestión de la Configuración • Proceso que supervisa y controla los cambios en los productos de trabajo • Cambios: requerimientos. comunicación de decisiones.

El Proceso de Desarrollo .

– Hacer evolucionar hacia una cultura de: • Ingeniería del software.CMM (Capability Maturity Model) • Proporciona una Guía sobre como – controlar los procesos: • de desarrollo del software. . • de mantenimiento. • Gestión eficiente.

Evolución de las organizaciones según el CMM Control del Proceso Medición del Proceso Definición del Proceso Control Básico Mejorado Gestionado Definido Repetible Completa área Procesos Inicial Incompleto .

Correlación entre estimaciones y niveles de madurez .

la gestión de requisitos) aún no se realiza o todavía no alcanza todas las metas y objetivos definidos para el nivel 1 de capacidad. .Nivel Incompleto • El área del proceso (por ejemplo.

• Uso de herramientas informales. • El éxito depende del esfuerzo individual. • Poco formalizado.Nivel Inicial • Según las circunstancias utilizamos un proceso distinto. • Pocos procesos definidos. . (algunos caóticos) • A medida.

– Planificación. .Nivel Repetible • Se tiene procesos estables de desarrollo. – Funcionalidad. con control estadístico. • Uso de datos historicos • Establecimiento de procesos de gestión de proyecto. para hacer seguimiento de: – Coste.

• Bien documentado. • Todos los proyectos utilizan una versión documentada y aprobada de proceso.Nivel Definido • Proceso de desarrollo perfectamente definido y estandarizado. . • Integrado en la organización.

• Control cuantitativo de productos y proceso a través de – Mediciones del proceso comprensibles. – Mediciones de la calidad .Nivel Gestionado • Mejoras de calidad sustanciales.

Nivel Mejorado • A través de mediciones del proceso utilizando ideas y tecnologías innovadoras obtenemos: – Mejoras en calidad y cantidad. .

El Proceso: Modelos de Desarrollo • Proceso – Conjunto ordenado de tareas. se suele llamar ciclo de vida – Aportan consistencia y estructura sobre el conjunto de actividades. lo que permite realizar la misma tarea correctamente de forma repetida – Existen diferentes modelos de proceso Requisitos del usuario Proceso de desarrollo de Software Sistema software . que producen una salida determinada – Proceso de software: conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software – Características • Tiene una serie de actividades principales • Utiliza recursos. que permiten conocer cuando comienza y termina dicha actividad • Existen principios orientadores que explican las metas de cada actividad – Cuando implica la construcción de un producto. está sujeto a restricciones y genera productos intermedios y finales • Compuesto por subprocesos que se encadenan de alguna forma • Cada actividad tiene sus criterios de entrada y salida. restricciones y recursos. una serie de pasos que involucran actividades.

las etapas se solapan iteraciones de coste elevado y reelaboración del trabajo: tendencia a la congelación de partes del desarrollo (especificaciones..Modelo en Cascada Requerimentos y Análisis Diseño Implementación Pruebas Mantenimiento resultado de cada fase: uno o más documentos aprobados una fase comienza cuando la anterior termina en la práctica...) se retrasa la localización y corrección de errores pueden producir sistemas poco útiles para usuarios o mal estructurados inflexibilidad del modelo: dificultad para responder a cambios en los requerimientos .

.. sistema operativo.) estructura deficiente evolución del proceso difícil de gestionar herramientas y técnicas especiales poco adecuado para grandes sistemas .Desarrollo Evolutivo • Basado en: – Desarrollo de una implementación inicial – Exposición a comentarios y crítica del usuario – Refinamiento a través de diferentes versiones hasta llegar a un sistema adecuado Recolección y refinamiento de requisitos Producto Diseño rápido dos tipos: prototipado evolutivo: trabajo con cliente para explorar sus requerimientos y entregar un sistema final evolución continua del prototipo mediante la agregación de funciones y características propuestas por el cliente prototipos desechables comprensión de las necesidades del cliente desarrollo de una definición mejorada de los requerimientos del sistema prototipos centrados en la experimentación de requisitos poco claros o complejos problemas Refinamiento del prototipo Evaluación del prototipo por el cliente Construcción del prototipo prisas del cliente (utilización del prototipo como sistema final pasar elecciones debidas al prototipo a la implementación final (entorno..

Desarrollo Evolutivo Actividades Concurrentes Especificación Versión Inicial Descripción del sistema Desarrollo Versiones Intermedias Validación Versión Final .

Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida. . Alto riesgo debido a falta de visibilidad • Evolutivo  Alto riesgo debido a la necesidad de tecnología avanzada y habilidades del grupo desarrollador.Problemas y Riesgos con los Modelos • Cascada   Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño. • Prototipado   Bajo riesgo para nuevas aplicaciones debido a que las especificaciones y el diseño se llevan a cabo paso a paso.

Sommerville.. 6th ed. Software Engineering.Prototipado con Lenguajes Visuales Hypertext display component Date component File Edit Views Layout Options Help General Index 12th January 2000 Range checking script 3.2000 .876 Draw canvas component User prompt component + script Tree display component fuente: I.

según la prioridad (los más importantes se entregan antes) definición detallada de requerimientos del incremento y desarrollo con el proceso más adecuado congelación de requerimientos de incrementos desarrollados puesta en explotación de los incrementos completados y entregados Asignación de requerimientos a incrementos Diseño de la arquitectura del sistema Desarrollo de incrementos del sistema Validar incrementos ventajas puesta en marcha temprana los incrementos iniciales permiten refinar requerimientos de incrementos posteriores satisfacción del cliente (bajo riesgo de fallo) sistema final muy probado y con pocos fallos Integrar incrementos Validar sistema problemas sistema incompleto sistema completo incrementos relativamente pequeños adaptación de requerimientos a incrementos del tamaño apropiado Sistema final identificación de recursos comunes a todos los incrementos .Desarrollo Incremental Definición general de requerimientos pasos identificación y priorización de funciones y servicios definición de varios requerimientos que proporcionan parte de la funcionalidad.

.. VERIFICAR PRODUCTO DE SIGUIENTE NIVEL .Modelo en Espiral propuesto por Barry Boehm organización en ciclos primer ciclo: factibilidad segundo ciclo: requerimientos tercer ciclo: diseño . pruebas comparativas Plan de desarrollo Plan de integración y prueba Diseño del producto Diseño detallado Codificar Diseño de validación y verificación Prueba de unidad Prueba de integración Explotación Prueba de aceptación DESARROLLAR. Prototipo 1 Prototipo 3 Prototipo 2 DETERMINAR OBJETIVOS. Análisis de riesgos An.. ALTERNATIVAS Y RESTRICCIONES PROGRESO A TRAVÉS DE LAS ITERACIONES EVALUAR ALTERNATIVAS. plan de administración. evaluación y reducción de riesgos (por ejemplo. restricciones del producto y proceso.. si es así. se planifica la siguiente fase PLANIFICAR SIGUIENTE FASE REVISIÓN Plan de . mejor definición de requerimientos mediante prototipos) desarrollo y validación: elección de un modelo para el desarrollo planificación: el proyecto se revisa y se decide si se continúa con el siguiente ciclo. Riesgo.. requerimientos Plan de ciclo de vida Prototipo operativo Concepto de operación Requerimientos de software Validación de requerimientos Simulaciones. IDENTIFICAR Y RESOLVER RIESGOS Análisis de riesgos Análisis de riesgos cada ciclo se divide en 4 sectores definición de objetivos. modelos.

• Planeación.  Se revisa el proyecto y se trazan planes para la siguiente ronda del espiral. • Desarrollo y Validación. y la información sirve para minimizar los riesgos.Fases del Modelo de Espiral • Planteamiento de Objetivos  Se identifican los objetivos específicos para cada fase del proyecto. • Identificación y reducción de riesgos.  Se elige un modelo apropiado para la siguiente fase del desarrollo. .  Los riesgos clave se identifican y analizan.

Resultados. Restricciones. Alternativas. Planes. . Resolución de riesgos. Garantías (commitments).Plantilla para una ronda del Espiral • • • • • • • • Objetivos. Riesgos.

Ventajas del Modelo de Espiral • Centra su atención en la reutilización de componentes y eliminación de errores en información descubierta en fases iniciales. • Integra desarrollo con mantenimiento. • Los objetivos de calidad son el primer objetivo. . • Provee un marco de desarrollo de hardware/software.

. • Requiere de experiencia en la identificación de riesgos.Problemas con el Modelo de Espiral • El desarrollo contractual especifica el modelo del proceso y los resultados a entregar por adelantado. • Requiere refinamiento para uso generalizado.

 La necesidad de producir documentos restringe la iteración entre procesos. El modelo de cascada es aún el modelo basado en resultados mas utilizado.Visibilidad de Procesos • • Los sistemas de software son intangibles por lo que los administradores necesitan documentación para identificar el progreso en el desarrollo.  . • .  El tiempo planeado para entrega de resultados puede no coincidir con el tiempo necesario para completar una actividad.. Esto puede causar problemas.El tiempo para revisar y aprobar documentos es significativo.

Visibilidad del Modelo Modelo de Proceso Modelo de Cascada Visibilidad del Proceso Buena visibilidad. cada segmento y cada anillo del espiral debe producir un documento. Visibilidad moderada. cada actividad produce un documento o resultado Visibilidad pobre. Buena visibilidad. Desarrollo Evolutivo Modelos Formales Desarrollo orientado a la reutilización Modelo de Espiral . Buena visibilidad. muy caro al producir docuementos en cada iteración. Importante contar con documentación de componentes reutilizables. en cada fase deben producirse documentos.

El Proceso Unificado de Desarrollo • Proceso unificado de desarrollo – Propuesto por los autores de UML (lenguaje unificado de desarrollo) – Basado en componentes interconectados a través de interfaces – Utiliza UML para desarrollar los esquemas y diagramas de un sistema software – Principales aspectos definitorios • Dirigido por casos de uso • Centrado en la arquitectura • Iterativo e incremental Requisitos del usuario Proceso de desarrollo de Software Sistema software .

El Proceso Unificado: Dirigido por Casos de Uso • Para construir un sistema con éxito hay que conocer las necesidades y deseos de los futuros usuarios – Usuario • Personas que trabajan y necesitan el sistema • Otros sistemas que interactúan con el que estamos desarrollando – Interacción: • Usuario inserta tarjeta en cajero automático • Usuario responde sobre la pantalla a las preguntas que realiza el cajero • El usuario recibe una cantidad de dinero y su tarjeta – Una interacción así es un caso de uso • Fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante Utilidad Casos de Uso – Herramienta para especificar los requisitos de un sistema: representan los requisitos funcionales y juntos constituyen el modelo de casos de uso. implementación y prueba) • Basándose en el modelo de casos de uso. se crean modelos de diseño e implementación • Se revisa cada modelo para que sean conformes al modelo de casos de uso • Se prueba la implementación para garantizar que los componentes del modelo de implementación implementan correctamente los casos de uso – No sólo inician el proceso de desarrollo sino que éste sigue un hilo de trabajo que parte de los casos de uso Retirar dinero Cliente del banco Ingresar dinero Transferencia entre cuentas • . que describe la funcionalidad total del sistema – Guían el proceso de desarrollo (diseño.

se descubre más de la arquitectura. requisitos no funcionales. tal y como las conduce perciben los usuarios y clientes • Otros factores..El Proceso Unificado: Centrado en la Arquitectura casos de uso guía arquitectura La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcción – Influida por diversos factores • Necesidades de la empresa. sistema operativo. Capa específica de la aplicación – Hay una constante interacción entre los casos de uso y la arquitectura..... protocolos de comunicación.. que evolucionan en paralelo • Los casos de uso deben encajar en la arquitectura cuando se realizan Capa general de la • La arquitectura debe permitir el desarrollo de aplicación todos los casos de uso requeridos – El arquitecto • Realiza un esquema en borrador de la Capa arquitectura que no es específica de los casos intermedia de uso (por ejemplo. lo que a su vez lleva a la maduración de más casos de uso • Este proceso continúa hasta que se considera que se dispone de una arquitectura estable • . especificándolo en Capa de software detalle y realizándolo en términos de del sistema subsistemas. dejando los detalles de lado. como plataforma de explotación (arquitectura hardware. clases y componentes • A medida que los casos de uso se especifican y maduran. gestor de bases de datos.). – Es una vista del diseño completo con las características más importantes resaltadas. componentes reutilizables. la plataforma) • Trabaja con un subconjunto de los casos de uso principales del sistema. sistemas heredados.

el desarrollo continúa con la siguiente iteración. se revisan las decisiones previas y se adopta un nuevo enfoque – Ventajas del proceso iterativo controlado • Reducción del coste del riesgo a los costes de un solo incremento • Reducción del riesgo de no sacar al mercado el producto en el calendario previsto • Se acelera el ritmo del esfuerzo de desarrollo en su totalidad. para obtener resultados claros a corto plazo • Los requerimientos del usuario se van refinando en iteraciones sucesivas.El Proceso Unificado: Iterativo e Incremental • El trabajo se divide en partes más pequeñas o miniproyectos – Miniproyecto: una iteración que resulta en un incremento • Iteración: pasos en el flujo de trabajo • Incremento: crecimiento del producto • Las iteraciones están controladas y planificadas – Factores para seleccionar lo que se implementará en una iteración • La iteración se centra en un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahora • La iteración trata los riesgos más importantes – Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como quedaron al final de la última iteración • En las primeras fases del ciclo de vida los incrementos implican modificaciones • En las últimas fases los incrementos implican menos modificaciones y más añadidos a los modelos – Para cada iteración: • Identificación y especificación de los casos de uso relevantes • Creación de un diseño utilizando la arquitectura seleccionada como guía • Implementación del diseño mediante componentes • Verificación de que los componentes satisfacen los casos de uso • Si una iteración cumple con sus objetivos. Si no. por lo que se pueden acomodar mejor los cambios .

del modelo de implementación y modelo de despliegue – Al final se pueden planificar las actividades y estimar recursos necesarios para finalizar el proyecto • Construcción: – Se crea el producto añadiendo el software a la arquitectura – Al final se dispone de todos los casos de uso acordados para el desarrollo aunque puede incorporar defectos • Transición – Periodo durante el cual el producto se convierte en versión beta.La Vida del Proceso Unificado • El proceso unificado se repite a lo largo de una serie de ciclos – Cada ciclo concluye con una versión del producto y consta de cuatro fases • Inicio: descripción del producto final a partir de una idea inicial y análisis de negocio para el producto – Principales funciones del sistema y usuarios más importantes (modelo de casos de uso) – Posible arquitectura del sistema – Plan del proyecto. del modelo de diseño. en la que usuarios prueban el producto e informan de defectos y deficiencias – Se corrigen problemas e incorporan sugerencias – Incluye actividades como la formación del usuario. proporcionar una línea de ayuda y asistencia.. del modelo de análisis.. identificación y priorización de riesgos • Elaboración: – Se especifican en detalle los principales casos de uso – Se diseña la arquitectura del sistema: vistas arquitectónicas del modelo de casos de uso. – Cada fase se divide a su vez en iteraciones .. coste.

La Vida del Proceso Unificado Fases Flujos de trabajo fundamentales Requisitos una iteración en la fase de elaboración Inicio Elaboración Construcción Transición Análisis Diseño Implementación Prueba iter #1 iter #2 --- --- --- --- --- iter #n-1 iter #n Iteraciones .

. 1 y 2 Sommerville. cap.S. Un enfoque práctico..Bibliografía Bruegge. 1 Jacobson. Dutoit.. Ingeniería de Software... 1 Pressman. Ingeniería del Software. R. G.. Booch. I.. Ingeniería del Software Orientado a Objetos. 2 y 3 . J. A. cap. cap. I.H. El Proceso Unificado de Desarrollo de Software. 1. B. cap. Rumbaugh.