Ingenieria De Software
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Ingenieria De Software as PDF for free.
More details
- Words: 6,963
- Pages: 87
TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
Dr. José Ignacio Peláez Sánchez E.T.S.I. Informática de Sistemas. 3er Curso. Año 2004/2005
Visión General Importancia de la Ingeniería del Software. z Retraso en la llegada de la Ingeniería del Software 9 23 de febrero de 1984 la revista “Bussiness week software: the new driving force”. z Software un factor que marca diferencias. z Tareas de la Ingeniería del Software. 9 Análisis, Especificación, Planificación, Diseño, Codificación, Prueba y Mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
2 de 87
Sistemas Basados en Computadora Definición de sistema. Conjunto de elementos relacionados entre sí, de manera que todos juntos forman un todo. Definición de Sistema Basado en Computadora (SBC). Conjunto de elementos organizados para llevar a cabo algún método, procedimiento o control, mediante el procesamiento de la información. Elementos de los SBC. z Software, Hardware, Bases de Datos, Documentación, Gente,
Procedimientos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
3 de 87
Concepto de Software Definición de Software. Conjunto de instrucciones que cuando se ejecutan suministan la función y comportamiento adecuados, un conjunto de estructuras de datos que facilitan la manipulación adecuada de la información, y finalmente, los documentos que describen la operación y uso de los programas.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
4 de 87
Evolución del Software Decada de los 50. z Orientación por lotes; Distribución limitada; Software a medida.
Desde 1960 hasta mediado de los años 70. z Multiusuario; Tiempo real; Bases de datos; Producción software.
Desde mitad de los años 70 hasta mitad de los 80. z Sistemas distribuidos; Inteligencia empotrada; Hardware de bajo
coste; Impacto en el consumidor.
Desde mitad de los años 80 hasta nuestros días. z Sistemas expertos; Máquinas de I.A; Arquitecturas paralelas. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
5 de 87
Evolución y las Mismas Preguntas Preguntas de las programadores, ya sean programadores solitarios o grupos de programadores. z ¿Por qué lleva tanto tiempo terminar los programas? z ¿Por qué son tan elevados los costes de desarrollo? z ¿Por qué no podemos encontrar todos los errores antes de
entregar el software a nuestros clientes? z ¿Por qué nos resulta tan difícil constatar el progreso conforme se desarrolla el software?.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
6 de 87
Caracteristicas del Software El software es desarrollado y no fabricado en sentido clásico. El software no se deteriora en sentido hardware. No existen piezas de repuesto. Cada fallo indica un error de diseño o de traducción a código. El software se construye a medida y no ensamblando componentes.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
7 de 87
Caracteristicas del Software El software es desarrollado y no fabricado en sentido clásico. El software no se deteriora en sentido hardware. No existen piezas de repuesto. Cada fallo indica un error de diseño o de traducción a código. El software se construye a medida y no ensamblando componentes.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
8 de 87
Caracteristicas del Software El software no se deteriora en sentido hardware. INCREMENTO DEL ÍNDICE DE FALLOS POR EFECTOS LATERALES
MORTALIDAD INFANTIL
CAMBIO ÍNDICE DE FALLOS
ÍNDICE DE FALLOS
SE ESTROPEA
TIEMPO CURVA DE FALLOS HARDWARE
CURVA REAL CURVA IDEALIZADA
TIEMPO CURVAS DE FALLOS REAL E IDEALIZADA DEL SOFTWARE
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
9 de 87
Caracteristicas del Software El software es desarrollado y no fabricado en sentido clásico. El software no se deteriora en sentido hardware. No existen piezas de repuesto. Cada fallo indica un error de diseño o de traducción a código. El software se construye a medida y no ensamblando componentes.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
10 de 87
Aplicaciones del Software Sistemas de tiempo real. Sistemas. Gestión. Ingeniería y científico. Empotrado. Inteligencia artificial. Computadores personales. Basado en Web.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
11 de 87
Crisis del Software La crisis del software es una serie de problemas que hacen que el software no alcance las expectativas u objetivos esperados por desarrolladores, gestores, clientes, etc. Problemas fundamentales. z La sofisticación del hardware no esta acompañada de la del
software. z Demanda creciente. z Mantenimiento difícil.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
12 de 87
Crisis del Software SOLUCIÓN INGENIERÍA DEL SOFTWARE
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
13 de 87
Crisis del Software Problemas de los expertos. z Planificación y precios imprecisos. z La productividad de la gente del software no se corresponde con
la demanda. z La calidad muchas veces no es la adecuada.
Motivos de estos problemas z No hay tiempo para recoger los datos para el proceso de
desarrollo. z Falta comunicación con el cliente. z Calidad cuestionable. z Dificultad en el mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
14 de 87
Crisis del Software SOLUCIÓN INGENIERÍA DEL SOFTWARE
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
15 de 87
Mitos del Software Los mitos del software son frases hechas que propagan información errónea y confusa, en lugar de sabiduría y buen hacer
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
16 de 87
Mitos de Gestión Los gestores con responsabilidad en el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. Un gestor de software se agarra frecuentemente a un mito del software, aunque tal creeencia sólo disminuya la presión temporal.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
17 de 87
Mitos de Gestión ¿Por qué debemos cambiar nuestra forma de desarrollar software, si estamos haciendo el mismo tipo de programación que hace 10 años? ¡Tenemos un libro que esta lleno de estándares y procedimientos para construir software! ¡Nuestra gente tiene las mejores máquinas para el desarrollo! Si fallamos en la planificación, añadimos más programadores y adelantamos el tiempo perdido. (Horda Mongoliana).
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
18 de 87
Mitos del Cliente Un cliente que solicita un aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de ventas o una compañía exterior que solicita un software bajo contrato. En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del software hacen muy poco para corregir la mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el desarrollo del software. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
19 de 87
Mitos del Cliente Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. Podemos dar los detalles más adelante. Los requerimientos cambian continuamente, pero los cambios pueden acomodarse fácilmente ya que el software es flexible. ¿Cómo afecta un cambio en las diferentes fases del desarrollo del software? José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
20 de 87
Mitos del Cliente Impacto del Cambio. 60 – 100X
IMPACTO DEL CAMBIO 1,5-6X 1X
DEFINICIÓN
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
DESARROLLO
DESPUÉS DE LA ENTREGA
21 de 87
Mitos de los Realizadores Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática. Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
22 de 87
Mitos de los Realizadores No hay métodos para el análisis, diseño y prueba que funcionen bien, simplemente me voy al terminal y comienzo a codificar. Una vez que hacemos que el programa funcione, nuestro trabajo ha terminado. Hasta que no esté el programa terminado no puedo establecer su calidad. Lo único que se entrega al terminar el proyecto es el programa funcionando. Una vez que el software se está usando, el mantenimiento es mínimo y puede manejarse sobre la base de hacerlo como se pueda. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
23 de 87
Reflexión sobre los Mitos Muchos profesionales del software reconocen la falacia de los mitos descritos anteriormente. Lamentablemente, las actitudes y métodos habituales fomentan una pobre gestión y una mala aplicación de las técnicas, incluso cuando la realidad dicta un método mejor. El reconocimiento de las realidades del software es el primer paso hacia la formulación de soluciones prácticas para su desarrollo.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
24 de 87
Ingeniería del Software Definición de Ingeniería del Software (IS). La IS es una disciplina o área de la Informática o Ciencias de la Computación, que ofrece métodos y técnicas para desarrollar, mantener y documentar software de calidad qué, resuelve problemas de todo tipo, se ejecuta en máquinas reales y satisface las necesidades del cliente. La IS integra: Métodos, herramientas y procesos para el desarrollo del software bajo un enfoque de calidad.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
25 de 87
Métodos Los métodos indican cómo construir técnicamente el software. Tareas que componen los métodos. z Planificación; Estimación de proyectos. z Análisis de requerimientos del software y hardware. z Diseño de estructuras de datos, Arquitectura de los programas. z Procedimientos algorítmicos. z Codificación; Prueba; y Mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
26 de 87
Herramientas y Procesos Las herramietas son un soporte automático o semiautomático para el proceso y los métodos. z Microsoft Project (Planificación). z UML (Modelado). z RationalRose, visio (Modelado soportan UML). z Designer 2000. z Erwin (Bases de datos). z MAGERIT (Seguridad).
Los procesos son los encargados de integrar los métodos y herramientas, además de definir la secuencia en la que se aplican los métodos, las entregas que requieren, los controles de calidad y las guías para el desarrollo.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
27 de 87
Fases Genéricas de la IS Definición. Tareas que la componen: z Análisis del sistema. z Planificación del Proyecto. z Análisis de requisitos.
QUÉ
Desarrollo. Tareas que la componen: z Diseño del software. z Codificación. z Prueba del Software.
Mantenimiento. Tipos de cambios:
CÓMO
z Corrección. z Adaptación. z Mejora. z Prevención o Reingeniería.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
TIPO 28 de 87
Preguntas que debe Responder la IS ¿cuál es el problema a resolver? ¿Cuáles son las características de la entidad (solución) que se utiliza para resolver el problema? ¿Cómo se realizará la solución? ¿Cómo se construirá la entidad? ¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseño y en la construcción de la solución? ¿Cómo se apoyará la solución cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
29 de 87
Proceso del Software El proceso del software es un marco común para el proceso que define un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos con independencia de su tamaño o complejidad.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
30 de 87
Proceso del Software El proceso del software es un marco común para el proceso que define un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos con independencia de su tamaño o complejidad. Marco de trabajo común Actividades del marco de trabajo Conjunto de trabajo Tareas Hitos, entregas SQA=Puntos de garantía de calidad Seguridad
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
31 de 87
Paradigma de la IS El modelo de proceso o paradigma de la IS es la estrategía que comprenden métodos, herramientas y procesos. El ingeniero debe seleccionar un modelo de proceso para ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos, las herramientas a utilizar, y los controles y entregas que se requieren. Los diferentes paradigmas lo que intentan es ordenar las actividades en el desarrollo del software, de manera que no sean llevadas a cabo de manera caótica.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
32 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
33 de 87
Visión Generalizada de los Paradigmas
Definición
Desarrollo Mantenimiento
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
34 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
35 de 87
Modelo Lineal Secuencial Enfoque sistemático y secuencial Ingeniería de Sistemas
Codificación
Análisis
Prueba
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
Diseño
Mantenimiento
36 de 87
Modelo Lineal Secuencial Ingeniería de sistemas. Se establecen los requerimientos de los elementos del sistema y se realiza la asignación. Análisis de requerimientos. Se establece y documenta el dominio del software. Se revisa con el cliente. Diseño. Se traducen los requerimientos en estructuras. Codificación. Prueba. Mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
37 de 87
Problemas del Modelo Sec. Lineal Raramente los proyectos siguen este ciclo de vida. El cliente pocas veces establece todos los requerimientos al principio. El cliente no tiene un producto hasta el final.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
38 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
39 de 87
Ciclo de Vida del Prototipado
Recolección de Requerimientos
Diseño Rápido
Evaluar y Refinar los Requerimientos
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
Construcción del Prototipo
Producto Construido
40 de 87
Modelo de Construcción de Prototipos ¿Por qué se usa este Modelo? z El cliente no puede especificar todos los requerimientos al
principio.
z Existen dudas de alguna parte del sistema. z Facilita un modelo al programador.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
41 de 87
Tipos de Prototipos Totales. Parciales. z Interfaces. z Modelos. z Estructuras de datos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
42 de 87
Problemas del Prototipado
El cliente lo quiere, aunque no es un producto software Módulos ineficientes se convierten en partes del sistema.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
43 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
44 de 87
Modelo DRA El Modelo DRA consiste en un desarrollo rápido de aplicaciones basado en el modelo lineal secuencial, pero donde se enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a alta velocidad del modelo lineal secuencial, donde se puede aumentar la velocidad haciendo uso de componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional, dentro de periodos cortos de tiempo. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
45 de 87
Modelo DRA EQUIPO Nº 1
EQUIPO Nº 3
EQUIPO Nº 2
MODELADO DE GESTIÓN
MODELADO DE GESTIÓN
MODELADO DE GESTIÓN
MODELADO DE DATOS
MODELADO DE DATOS
MODELADO DE DATOS
MODELADO DE PROCESOS
MODELADO DE PROCESOS
MODELADO DE PROCESOS
GENERACIÓN DE APLICACIONES
GENERACIÓN DE APLICACIONES PRUEBAS Y ENTREGA
GENERACIÓN DE APLICACIONES PRUEBAS Y ENTREGA
PRUEBAS Y ENTREGA
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
46 de 87
Problemas del Modelo DRA Para proyectos grandes necesitamos de recursos suficientes para formar los equipos necesarios. Compromiso de colaboración entre desarrolladores y clientes. No todas las aplicaciones son susceptibles de aplicar este modelo. Cuando los riesgos técnicos son altos DRA no es apropiado. Cuando el grado de interoperatividad con programas ya existentes es alto, no es apropiado. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
47 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
48 de 87
Modelos Anteriores Modelo Lineal Secuencia. Diseñado para entregar un producto al final. Modelo de Construcción de Prototipos. Diseñado para que los clientes interactúen con los desarrolladores. Ninguno de los modelos anteriores se tiene en cuenta la naturaleza evolutiva del software. “Las empresas son entes vivos que van evolucionando con el tiempo”
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
49 de 87
Modelos Evolutivos Los modelos evolutivos se caracterizan porque permiten a los ingenieros del software, desarrollar de manera iterativa, nuevas versiones del software cada vez más completas. Los modelos que componen este tipo son: z Modelo Incremental. z Modelo en Espiral. z Modelo en Espiral Victoria-Victoria (WINWIN). z Modelo de Desarrollo Concurrente.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
50 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos ágiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
51 de 87
Modelo Incremental El modelo Incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos. INGENIERÍA DE SISTEMAS ANÁLISIS
CÓDIGO
DISEÑO
PRUEBA
ENTREGA 1ER INCREMENTO
INGENIERÍA DE SISTEMAS ANÁLISIS
DISEÑO
CÓDIGO
PRUEBA
ENTREGA 2ER INCREMENTO
INGENIERÍA DE SISTEMAS ANÁLISIS
DISEÑO
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
CÓDIGO
PRUEBA
ENTREGA 3ER INCREMENTO
52 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
53 de 87
Modelo en Espiral El Modelo en Espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Ideal para realizar versiones incrementales de manera rápida. El software se desarrolla en una serie de versiones incrementales.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
54 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
55 de 87
Modelo en Espiral Victoria-Victoria El modelo en espiral visto anteriormente, dispone de una actividad de comunicación con el cliente. Comunicación Ideal. El desarrollador pregunta al cliente y el cliente facilita suficiente información para continuar. Comunicación Real. El cliente y el desarrollador entran en un proceso de negociación, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otras características. Las mejores negociaciones se esfuerzan en obtener <>. Este modelo definido por Boehm, define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
56 de 87
Modelo en Espiral Victoria-Victoria
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
57 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos ágiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
58 de 87
Modelo de Desarrollo Concurrente El Modelo de Desarrollo Concurrente dado por Davis y Sitaram, se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas. El modelo Concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la Ingeniería del software. Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
59 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
60 de 87
Modelo Basado en Componentes La tecnología de objetos proporciona el marco de trabajo técnico para un modelo de proceso basado en componentes para la IS. El paradigma orientado a objetos enfatiza en la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se diseñan e implementan las clases correctamente, podrían ser reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadores.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
61 de 87
Modelo Basado en Componentes El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza y exige un enfoque iterativo para la creación de software. Configura aplicaciones desde componentes preparados de software. El modelo basado en componentes conduce a la reutilización del software, proporcionando beneficios a los ingenieros de software.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
62 de 87
Modelo Basado en Componentes La reutilización según estudios: z Reduce el ciclo de vida en un 70%. z Reduce el coste del proyecto en un 84%. z Aumenta la productividad.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
63 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
64 de 87
Modelo de Métodos Formales El Modelo de Métodos Formales comprende un conjunto de actividades que conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática. Con este modelo se consigue software libre de errores. Es difícil de aplicar, por diferentes motivos, pero para software de alta seguridad es muy adecuado. También se le conoce como Ingeniería del Software de Sala Limpia. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
65 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
66 de 87
Técnicas de 4ª Generación El término técnicas de cuarta generación abarca un amplio espectro de herramientas de software que tienen algo en común: Todas facilitan al ingeniero del software la especificación de algunas características del software de alto nivel. Las herramientas general el código automáticamente en base a las especificaciones del ingeniero. Herramientas de 4ª Generación. z Lenguajes no procedurales para consultas de BD. z Generación de Informes. z Manipulación de Datos. z Definición de pantallas y código. z Gráficos. z Hoja de cálculo.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
67 de 87
Ciclo de Vida de las Técnicas de 4 Gen. Recolección de Requerimientos
Implementación usando L4G
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
Estrategias de Diseño
Producto
68 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
69 de 87
Modelos Ágiles/Programación Extrema La idea de la Ingeniería de requisitos es conseguir un cuadro totalmente entendido de los requisitos antes de empezar a construir el software. Conseguir la firma del cliente sobre los requisitos y preparar los procedimientos para limitar los cambios después de la firma. El problema surge cuando se intenta añadir un nuevo requisito porque la estimación del coste es difícil. ¿Por qué es difícil esta tarea? Porque la actividad de desarrollo del software es una actividad de Diseño.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
70 de 87
Procesos Adaptables o Ágiles Si bien el desarrollo iterativo tiene sentido en los procesos predictivos, también lo es en los procesos adaptables porque este tipo de proceso necesita poder tratar con los cambios. Este estilo nos lleva a que los planes a largo plazo son adaptables y los únicos planes adaptables son los que se hacen a corto plazo. En un proceso adaptable el cliente tiene mucho control sobre el proceso de desarrollo, ya que en cada iteración puede interactuar como alterar la dirección del mismo. En este tipo de procesos se forma un verdadero equipo entre los desarrolladores y los clientes. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
71 de 87
Modelos Ágiles/Programación Extrema Se consigue un producto que funciona pronto con los beneficios que esto conlleva para el cliente, comprende el sistema y puede introducir mejoras que lo hacen eficaz. Un proyecto es bueno cuando se ajusta al plan. Sin embargo un proyecto ágil tiene que obtener mejores resultados que los que fueron establecidos inicialmente. El problema de los modelos ágiles es que requieren de un equipo eficaz de desarrollo, tanto a nivel individual como de equipo. En los proyectos tradicionales el personal puede ser reemplazado, sin embargo en los modelos ágiles esto varia, los desarrolladores pueden tomar todas las decisiones. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
72 de 87
Modelos Ágiles/Programación Extrema Los equipos ágiles tienen una gran comunicación tanto los desarrolladores como los expertos del negocio (cambios continuos en la tecnología). La Programación Extrema (XP) comienza con cuatro valores: Comunicación, Retroalimentación, Simplicidad y Coraje. La XP agrupas todas las técnicas y pone todo su énfasis en realizar pruebas, donde cada programador escribe sus pruebas conforme desarrolla software. La XP es un desarrollo evolutivo donde en cada iteración de consigue un producto final. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
73 de 87
Proceso Unificado de Desarrollo del Software El Proceso Unificado de Desarrollo del Software (PUDS) es un proceso basado en componentes que ha sido propuesto por la industria. El proceso unificado dispone de un Lenguaje de Modelado Unificado (UML), que es utilizado construir el sistema y las interfaces que conectarán los componentes. El PUDS combina un desarrollo incremental e iterativo, definiendo la función del sistema aplicando un enfoque basado en escenarios.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
74 de 87
Proceso Unificado de Desarrollo del Software El PUDS se puede decir que es un proceso: z Dirigido por los casos de uso. 9 Basándose en el modelo de casos de uso y en su análisis los
desarrolladores crean los modelos de diseño e implementación que llevan a cabo los casos de uso.
z Centrado en la arquitectura. 9 La arquitectura de un sistema software se describe mediante
diferentes vistas del sistema en construcción.
z Iterativo e Incremental. 9 El desarrollo de un proyecto se divide en iteraciones, encargadas de
pequeñas partes del trabajo y que dan como resultado un crecimiento del producto, incremento. Estas iteraciones se planifican y se prueban cada vez que terminan.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
75 de 87
Proceso Unificado ANÁLISIS
CÓDIGO
DISEÑO
ENTREGA 1 INCREMENTO
PRUEBA
Prototipo Exploratorio
ANÁLISIS
CÓDIGO
DISEÑO
ENTREGA 2 INCREMENTO
PRUEBA
Línea Base de la Arquitectura ANÁLISIS
DISEÑO
CÓDIGO
ENTREGA 3 INCREMENTO
PRUEBA
Versión Operativa Inicial ANÁLISIS
DISEÑO
CÓDIGO
PRUEBA
ENTREGA 4 INCREMENTO Entrega del Producto
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
76 de 87
Métrica 3 La metodología Métrica 3 es un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software. Contempla el desarrollo de sistemas de información para las distintas tecnologías que actualmente conviven. En la elaboración de Métrica 3 se han tenido en cuenta los métodos de desarrollo más extendidos, así como los últimos estándares de ingeniería del software y calidad, además de referencias especificas en cuanto a seguridad y gestión de proyectos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
77 de 87
Métrica 3 Cubre el desarrollo estructurado y orientado a objetos. Facilita los procesos de apoyo y de organización a través de interfaces: Gestión de proyectos; Gestión de configuración; Aseguramiento de calidad y seguridad. La automatización de sus actividades es posible ya que existe una amplia variedad de herramientas de ayuda al desarrollo. Existe una herramienta que adapta Métrica 3 a las condiciones especificas de cada proyecto, permitiendo el control y seguimiento desde diferentes perfiles. Posee un curso de formación. www.map.es/csi
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
78 de 87
¿Por que una Metodología de Desarrollo? La utilización de una metodología en el desarrollo de sistemas permite: z Disponer de un marco estratégico que permite conseguir los fines
de la organización.
z Dotar a la organización de productos software que satisfagan las
necesidades de los usuarios dando una mayor importancia al análisis de requisitos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
79 de 87
Metodología de Desarrollo z Mejorar la productividad de los departamentos de sistemas y
tecnologías de la información y las comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.
z Facilitar la comunicación y entendimiento entre los distintos
participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.
z Facilitar la operación, mantenimiento y uso de los productos
software obtenidos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
80 de 87
Metodología DUM DUM es una metodología evolutiva e incremental de desarrollo del software que ha sido creada en el departamento de Lenguajes y Ciencias de la Computación de la Universidad de Málaga. Basada en un enfoque iterativo incremental esta metodología realiza una especificación exhaustiva de todas las actividades y tareas que se realizan en las diferentes fases, prestado especial atención por alcanzar un nivel superior de madurez según el marco CMMI/Carnegie Mellon. Las fases en las que se subdivide la metodología DUM son las siguientes: fase preliminar, fase de Inicio, fase de elaboración, fase de construcción, fase de transición; y finalmente, una fase de mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
81 de 87
Metodología DUM Fase Preliminar z En la Fase Preliminar se llevan a cabo una serie de pasos previos en los
que se sientan las bases que permiten comenzar el proyecto. En esta fase el cliente proporciona los dos elementos básicos para comenzar un proyecto: una petición formal del mismo; y una definición del problema al que debe dar respuesta el Sistema a desarrollar. En base a estos dos elementos la organización de desarrollo definirá un primer equipo encargado del inicio del proyecto.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
82 de 87
Metodología DUM Fase de Inicio z En la Fase de Inicio se determina si el problema planteado tiene solución,
lo cual se hace desde un punto de vista genérico, es decir, no se tienen en cuenta posibles restricciones relacionadas con el cliente como costes económicos o plazos de entrega, sólo se tienen en cuenta restricciones que afecten al problema en sí como pueda ser la legalidad vigente. Si al final de la Fase de Inicio se determina que el problema tiene solución, DUM denominará el Sistema a desarrollar un Sistema Realizable. En fases posteriores se estudiará si el nuevo Sistema puede desarrollarse teniendo en cuenta las restricciones impuestas por el cliente, esto es lo que DUM denomina un Sistema Viable.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
83 de 87
Metodología DUM Fase de Elaboración z En la Fase de Elaboración se determina si es posible desarrollar el
Sistema teniendo en cuenta las restricciones impuestas por el cliente, y se obtiene un proyecto particular después de aplicarle las restricciones del cliente al proyecto genérico. z Puede considerarse que en las Fases de Inicio y Elaboración se realiza un trabajo en base a objetivos similares pero tratados a distinto nivel. Así, en la Fase de Inicio se trabaja con un proyecto basado en un problema genérico y se comprueba que dicho proyecto genérico se puede llevar a cabo, mientras que en la Fase de Elaboración se trabaja con una versión particular del proyecto genérico y se comprueba que dicho proyecto particular se puede llevar a cabo.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
84 de 87
Metodología DUM Fase de Construcción z Terminada la Fase de Elaboración se cuenta con un especificación
detallada de qué debe hacer el Sistema, de una arquitectura formada por los elementos del Sistema que guiará cómo cumplirá el Sistema con su cometido, y de una versión inicial del Sistema en base a su arquitectura que será la base sobre la que se construirá el resto del Sistema. z En la Fase de Construcción se completarán las labores de desarrollos pendientes para los casos de uso no incluidos en la arquitectura del Sistema de modo que al final de la fase se cuente con una versión completa del Sistema. Esta versión deberá satisfacer todos los requisitos indicados por el cliente y los criterios de calidad y seguridad establecidos por la organización de desarrollo, sin embargo, no será la versión definitiva del Sistema, será la denominada versión beta del Sistema.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
85 de 87
Metodología DUM Fase de Transición z Durante la Fase de Transición se realiza la prueba del Sistema con el fin
de adaptar el mismo a un entorno de producción realizándose las modificaciones que se estimen necesarias. Los usuarios encargados de probar el sistema (en adelante usuarios beta) recibirán instrucciones acerca de aquellos aspectos del Sistema en los que deben hacer especial hincapié y sobre el proceso a seguir para la proposición, estudio y resolución de propuestas de modificación. A este respecto será necesario desarrollar la estructura necesaria para facilitar en la medida de lo posible dicho proceso.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
86 de 87
Metodología DUM Fase de Mantenimiento z Tras la finalización del proyecto será necesario establecer un acuerdo
respecto al mantenimiento, que puede ser llevado a cabo por la misma organización de desarrollo o por otra distinta.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
87 de 87
Dr. José Ignacio Peláez Sánchez E.T.S.I. Informática de Sistemas. 3er Curso. Año 2004/2005
Visión General Importancia de la Ingeniería del Software. z Retraso en la llegada de la Ingeniería del Software 9 23 de febrero de 1984 la revista “Bussiness week software: the new driving force”. z Software un factor que marca diferencias. z Tareas de la Ingeniería del Software. 9 Análisis, Especificación, Planificación, Diseño, Codificación, Prueba y Mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
2 de 87
Sistemas Basados en Computadora Definición de sistema. Conjunto de elementos relacionados entre sí, de manera que todos juntos forman un todo. Definición de Sistema Basado en Computadora (SBC). Conjunto de elementos organizados para llevar a cabo algún método, procedimiento o control, mediante el procesamiento de la información. Elementos de los SBC. z Software, Hardware, Bases de Datos, Documentación, Gente,
Procedimientos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
3 de 87
Concepto de Software Definición de Software. Conjunto de instrucciones que cuando se ejecutan suministan la función y comportamiento adecuados, un conjunto de estructuras de datos que facilitan la manipulación adecuada de la información, y finalmente, los documentos que describen la operación y uso de los programas.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
4 de 87
Evolución del Software Decada de los 50. z Orientación por lotes; Distribución limitada; Software a medida.
Desde 1960 hasta mediado de los años 70. z Multiusuario; Tiempo real; Bases de datos; Producción software.
Desde mitad de los años 70 hasta mitad de los 80. z Sistemas distribuidos; Inteligencia empotrada; Hardware de bajo
coste; Impacto en el consumidor.
Desde mitad de los años 80 hasta nuestros días. z Sistemas expertos; Máquinas de I.A; Arquitecturas paralelas. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
5 de 87
Evolución y las Mismas Preguntas Preguntas de las programadores, ya sean programadores solitarios o grupos de programadores. z ¿Por qué lleva tanto tiempo terminar los programas? z ¿Por qué son tan elevados los costes de desarrollo? z ¿Por qué no podemos encontrar todos los errores antes de
entregar el software a nuestros clientes? z ¿Por qué nos resulta tan difícil constatar el progreso conforme se desarrolla el software?.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
6 de 87
Caracteristicas del Software El software es desarrollado y no fabricado en sentido clásico. El software no se deteriora en sentido hardware. No existen piezas de repuesto. Cada fallo indica un error de diseño o de traducción a código. El software se construye a medida y no ensamblando componentes.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
7 de 87
Caracteristicas del Software El software es desarrollado y no fabricado en sentido clásico. El software no se deteriora en sentido hardware. No existen piezas de repuesto. Cada fallo indica un error de diseño o de traducción a código. El software se construye a medida y no ensamblando componentes.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
8 de 87
Caracteristicas del Software El software no se deteriora en sentido hardware. INCREMENTO DEL ÍNDICE DE FALLOS POR EFECTOS LATERALES
MORTALIDAD INFANTIL
CAMBIO ÍNDICE DE FALLOS
ÍNDICE DE FALLOS
SE ESTROPEA
TIEMPO CURVA DE FALLOS HARDWARE
CURVA REAL CURVA IDEALIZADA
TIEMPO CURVAS DE FALLOS REAL E IDEALIZADA DEL SOFTWARE
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
9 de 87
Caracteristicas del Software El software es desarrollado y no fabricado en sentido clásico. El software no se deteriora en sentido hardware. No existen piezas de repuesto. Cada fallo indica un error de diseño o de traducción a código. El software se construye a medida y no ensamblando componentes.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
10 de 87
Aplicaciones del Software Sistemas de tiempo real. Sistemas. Gestión. Ingeniería y científico. Empotrado. Inteligencia artificial. Computadores personales. Basado en Web.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
11 de 87
Crisis del Software La crisis del software es una serie de problemas que hacen que el software no alcance las expectativas u objetivos esperados por desarrolladores, gestores, clientes, etc. Problemas fundamentales. z La sofisticación del hardware no esta acompañada de la del
software. z Demanda creciente. z Mantenimiento difícil.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
12 de 87
Crisis del Software SOLUCIÓN INGENIERÍA DEL SOFTWARE
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
13 de 87
Crisis del Software Problemas de los expertos. z Planificación y precios imprecisos. z La productividad de la gente del software no se corresponde con
la demanda. z La calidad muchas veces no es la adecuada.
Motivos de estos problemas z No hay tiempo para recoger los datos para el proceso de
desarrollo. z Falta comunicación con el cliente. z Calidad cuestionable. z Dificultad en el mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
14 de 87
Crisis del Software SOLUCIÓN INGENIERÍA DEL SOFTWARE
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
15 de 87
Mitos del Software Los mitos del software son frases hechas que propagan información errónea y confusa, en lugar de sabiduría y buen hacer
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
16 de 87
Mitos de Gestión Los gestores con responsabilidad en el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. Un gestor de software se agarra frecuentemente a un mito del software, aunque tal creeencia sólo disminuya la presión temporal.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
17 de 87
Mitos de Gestión ¿Por qué debemos cambiar nuestra forma de desarrollar software, si estamos haciendo el mismo tipo de programación que hace 10 años? ¡Tenemos un libro que esta lleno de estándares y procedimientos para construir software! ¡Nuestra gente tiene las mejores máquinas para el desarrollo! Si fallamos en la planificación, añadimos más programadores y adelantamos el tiempo perdido. (Horda Mongoliana).
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
18 de 87
Mitos del Cliente Un cliente que solicita un aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de ventas o una compañía exterior que solicita un software bajo contrato. En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del software hacen muy poco para corregir la mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el desarrollo del software. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
19 de 87
Mitos del Cliente Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. Podemos dar los detalles más adelante. Los requerimientos cambian continuamente, pero los cambios pueden acomodarse fácilmente ya que el software es flexible. ¿Cómo afecta un cambio en las diferentes fases del desarrollo del software? José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
20 de 87
Mitos del Cliente Impacto del Cambio. 60 – 100X
IMPACTO DEL CAMBIO 1,5-6X 1X
DEFINICIÓN
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
DESARROLLO
DESPUÉS DE LA ENTREGA
21 de 87
Mitos de los Realizadores Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática. Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
22 de 87
Mitos de los Realizadores No hay métodos para el análisis, diseño y prueba que funcionen bien, simplemente me voy al terminal y comienzo a codificar. Una vez que hacemos que el programa funcione, nuestro trabajo ha terminado. Hasta que no esté el programa terminado no puedo establecer su calidad. Lo único que se entrega al terminar el proyecto es el programa funcionando. Una vez que el software se está usando, el mantenimiento es mínimo y puede manejarse sobre la base de hacerlo como se pueda. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
23 de 87
Reflexión sobre los Mitos Muchos profesionales del software reconocen la falacia de los mitos descritos anteriormente. Lamentablemente, las actitudes y métodos habituales fomentan una pobre gestión y una mala aplicación de las técnicas, incluso cuando la realidad dicta un método mejor. El reconocimiento de las realidades del software es el primer paso hacia la formulación de soluciones prácticas para su desarrollo.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
24 de 87
Ingeniería del Software Definición de Ingeniería del Software (IS). La IS es una disciplina o área de la Informática o Ciencias de la Computación, que ofrece métodos y técnicas para desarrollar, mantener y documentar software de calidad qué, resuelve problemas de todo tipo, se ejecuta en máquinas reales y satisface las necesidades del cliente. La IS integra: Métodos, herramientas y procesos para el desarrollo del software bajo un enfoque de calidad.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
25 de 87
Métodos Los métodos indican cómo construir técnicamente el software. Tareas que componen los métodos. z Planificación; Estimación de proyectos. z Análisis de requerimientos del software y hardware. z Diseño de estructuras de datos, Arquitectura de los programas. z Procedimientos algorítmicos. z Codificación; Prueba; y Mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
26 de 87
Herramientas y Procesos Las herramietas son un soporte automático o semiautomático para el proceso y los métodos. z Microsoft Project (Planificación). z UML (Modelado). z RationalRose, visio (Modelado soportan UML). z Designer 2000. z Erwin (Bases de datos). z MAGERIT (Seguridad).
Los procesos son los encargados de integrar los métodos y herramientas, además de definir la secuencia en la que se aplican los métodos, las entregas que requieren, los controles de calidad y las guías para el desarrollo.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
27 de 87
Fases Genéricas de la IS Definición. Tareas que la componen: z Análisis del sistema. z Planificación del Proyecto. z Análisis de requisitos.
QUÉ
Desarrollo. Tareas que la componen: z Diseño del software. z Codificación. z Prueba del Software.
Mantenimiento. Tipos de cambios:
CÓMO
z Corrección. z Adaptación. z Mejora. z Prevención o Reingeniería.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
TIPO 28 de 87
Preguntas que debe Responder la IS ¿cuál es el problema a resolver? ¿Cuáles son las características de la entidad (solución) que se utiliza para resolver el problema? ¿Cómo se realizará la solución? ¿Cómo se construirá la entidad? ¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseño y en la construcción de la solución? ¿Cómo se apoyará la solución cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
29 de 87
Proceso del Software El proceso del software es un marco común para el proceso que define un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos con independencia de su tamaño o complejidad.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
30 de 87
Proceso del Software El proceso del software es un marco común para el proceso que define un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos con independencia de su tamaño o complejidad. Marco de trabajo común Actividades del marco de trabajo Conjunto de trabajo Tareas Hitos, entregas SQA=Puntos de garantía de calidad Seguridad
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
31 de 87
Paradigma de la IS El modelo de proceso o paradigma de la IS es la estrategía que comprenden métodos, herramientas y procesos. El ingeniero debe seleccionar un modelo de proceso para ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos, las herramientas a utilizar, y los controles y entregas que se requieren. Los diferentes paradigmas lo que intentan es ordenar las actividades en el desarrollo del software, de manera que no sean llevadas a cabo de manera caótica.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
32 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
33 de 87
Visión Generalizada de los Paradigmas
Definición
Desarrollo Mantenimiento
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
34 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
35 de 87
Modelo Lineal Secuencial Enfoque sistemático y secuencial Ingeniería de Sistemas
Codificación
Análisis
Prueba
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
Diseño
Mantenimiento
36 de 87
Modelo Lineal Secuencial Ingeniería de sistemas. Se establecen los requerimientos de los elementos del sistema y se realiza la asignación. Análisis de requerimientos. Se establece y documenta el dominio del software. Se revisa con el cliente. Diseño. Se traducen los requerimientos en estructuras. Codificación. Prueba. Mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
37 de 87
Problemas del Modelo Sec. Lineal Raramente los proyectos siguen este ciclo de vida. El cliente pocas veces establece todos los requerimientos al principio. El cliente no tiene un producto hasta el final.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
38 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
39 de 87
Ciclo de Vida del Prototipado
Recolección de Requerimientos
Diseño Rápido
Evaluar y Refinar los Requerimientos
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
Construcción del Prototipo
Producto Construido
40 de 87
Modelo de Construcción de Prototipos ¿Por qué se usa este Modelo? z El cliente no puede especificar todos los requerimientos al
principio.
z Existen dudas de alguna parte del sistema. z Facilita un modelo al programador.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
41 de 87
Tipos de Prototipos Totales. Parciales. z Interfaces. z Modelos. z Estructuras de datos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
42 de 87
Problemas del Prototipado
El cliente lo quiere, aunque no es un producto software Módulos ineficientes se convierten en partes del sistema.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
43 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
44 de 87
Modelo DRA El Modelo DRA consiste en un desarrollo rápido de aplicaciones basado en el modelo lineal secuencial, pero donde se enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a alta velocidad del modelo lineal secuencial, donde se puede aumentar la velocidad haciendo uso de componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional, dentro de periodos cortos de tiempo. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
45 de 87
Modelo DRA EQUIPO Nº 1
EQUIPO Nº 3
EQUIPO Nº 2
MODELADO DE GESTIÓN
MODELADO DE GESTIÓN
MODELADO DE GESTIÓN
MODELADO DE DATOS
MODELADO DE DATOS
MODELADO DE DATOS
MODELADO DE PROCESOS
MODELADO DE PROCESOS
MODELADO DE PROCESOS
GENERACIÓN DE APLICACIONES
GENERACIÓN DE APLICACIONES PRUEBAS Y ENTREGA
GENERACIÓN DE APLICACIONES PRUEBAS Y ENTREGA
PRUEBAS Y ENTREGA
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
46 de 87
Problemas del Modelo DRA Para proyectos grandes necesitamos de recursos suficientes para formar los equipos necesarios. Compromiso de colaboración entre desarrolladores y clientes. No todas las aplicaciones son susceptibles de aplicar este modelo. Cuando los riesgos técnicos son altos DRA no es apropiado. Cuando el grado de interoperatividad con programas ya existentes es alto, no es apropiado. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
47 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
48 de 87
Modelos Anteriores Modelo Lineal Secuencia. Diseñado para entregar un producto al final. Modelo de Construcción de Prototipos. Diseñado para que los clientes interactúen con los desarrolladores. Ninguno de los modelos anteriores se tiene en cuenta la naturaleza evolutiva del software. “Las empresas son entes vivos que van evolucionando con el tiempo”
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
49 de 87
Modelos Evolutivos Los modelos evolutivos se caracterizan porque permiten a los ingenieros del software, desarrollar de manera iterativa, nuevas versiones del software cada vez más completas. Los modelos que componen este tipo son: z Modelo Incremental. z Modelo en Espiral. z Modelo en Espiral Victoria-Victoria (WINWIN). z Modelo de Desarrollo Concurrente.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
50 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos ágiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
51 de 87
Modelo Incremental El modelo Incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos. INGENIERÍA DE SISTEMAS ANÁLISIS
CÓDIGO
DISEÑO
PRUEBA
ENTREGA 1ER INCREMENTO
INGENIERÍA DE SISTEMAS ANÁLISIS
DISEÑO
CÓDIGO
PRUEBA
ENTREGA 2ER INCREMENTO
INGENIERÍA DE SISTEMAS ANÁLISIS
DISEÑO
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
CÓDIGO
PRUEBA
ENTREGA 3ER INCREMENTO
52 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
53 de 87
Modelo en Espiral El Modelo en Espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Ideal para realizar versiones incrementales de manera rápida. El software se desarrolla en una serie de versiones incrementales.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
54 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
55 de 87
Modelo en Espiral Victoria-Victoria El modelo en espiral visto anteriormente, dispone de una actividad de comunicación con el cliente. Comunicación Ideal. El desarrollador pregunta al cliente y el cliente facilita suficiente información para continuar. Comunicación Real. El cliente y el desarrollador entran en un proceso de negociación, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otras características. Las mejores negociaciones se esfuerzan en obtener <
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
56 de 87
Modelo en Espiral Victoria-Victoria
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
57 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos ágiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
58 de 87
Modelo de Desarrollo Concurrente El Modelo de Desarrollo Concurrente dado por Davis y Sitaram, se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas. El modelo Concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la Ingeniería del software. Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
59 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
60 de 87
Modelo Basado en Componentes La tecnología de objetos proporciona el marco de trabajo técnico para un modelo de proceso basado en componentes para la IS. El paradigma orientado a objetos enfatiza en la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se diseñan e implementan las clases correctamente, podrían ser reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadores.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
61 de 87
Modelo Basado en Componentes El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza y exige un enfoque iterativo para la creación de software. Configura aplicaciones desde componentes preparados de software. El modelo basado en componentes conduce a la reutilización del software, proporcionando beneficios a los ingenieros de software.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
62 de 87
Modelo Basado en Componentes La reutilización según estudios: z Reduce el ciclo de vida en un 70%. z Reduce el coste del proyecto en un 84%. z Aumenta la productividad.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
63 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
64 de 87
Modelo de Métodos Formales El Modelo de Métodos Formales comprende un conjunto de actividades que conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática. Con este modelo se consigue software libre de errores. Es difícil de aplicar, por diferentes motivos, pero para software de alta seguridad es muy adecuado. También se le conoce como Ingeniería del Software de Sala Limpia. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
65 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
66 de 87
Técnicas de 4ª Generación El término técnicas de cuarta generación abarca un amplio espectro de herramientas de software que tienen algo en común: Todas facilitan al ingeniero del software la especificación de algunas características del software de alto nivel. Las herramientas general el código automáticamente en base a las especificaciones del ingeniero. Herramientas de 4ª Generación. z Lenguajes no procedurales para consultas de BD. z Generación de Informes. z Manipulación de Datos. z Definición de pantallas y código. z Gráficos. z Hoja de cálculo.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
67 de 87
Ciclo de Vida de las Técnicas de 4 Gen. Recolección de Requerimientos
Implementación usando L4G
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
Estrategias de Diseño
Producto
68 de 87
Paradigmas de la IS Paradigmas. z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en cascada. z Prototipos. z Modelo DRA (RAD. Rapid Application Development). z Modelos Evolutivos de Proceso 9 9 9 9
Incremental. Espiral. Espiral WINWIN. Modelo de desarrollo concurrente.
z Modelo basado en componentes. z Modelo basado en métodos formales. z Técnicas de cuarta generación. z Modelos agiles. Programación extrema. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
69 de 87
Modelos Ágiles/Programación Extrema La idea de la Ingeniería de requisitos es conseguir un cuadro totalmente entendido de los requisitos antes de empezar a construir el software. Conseguir la firma del cliente sobre los requisitos y preparar los procedimientos para limitar los cambios después de la firma. El problema surge cuando se intenta añadir un nuevo requisito porque la estimación del coste es difícil. ¿Por qué es difícil esta tarea? Porque la actividad de desarrollo del software es una actividad de Diseño.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
70 de 87
Procesos Adaptables o Ágiles Si bien el desarrollo iterativo tiene sentido en los procesos predictivos, también lo es en los procesos adaptables porque este tipo de proceso necesita poder tratar con los cambios. Este estilo nos lleva a que los planes a largo plazo son adaptables y los únicos planes adaptables son los que se hacen a corto plazo. En un proceso adaptable el cliente tiene mucho control sobre el proceso de desarrollo, ya que en cada iteración puede interactuar como alterar la dirección del mismo. En este tipo de procesos se forma un verdadero equipo entre los desarrolladores y los clientes. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
71 de 87
Modelos Ágiles/Programación Extrema Se consigue un producto que funciona pronto con los beneficios que esto conlleva para el cliente, comprende el sistema y puede introducir mejoras que lo hacen eficaz. Un proyecto es bueno cuando se ajusta al plan. Sin embargo un proyecto ágil tiene que obtener mejores resultados que los que fueron establecidos inicialmente. El problema de los modelos ágiles es que requieren de un equipo eficaz de desarrollo, tanto a nivel individual como de equipo. En los proyectos tradicionales el personal puede ser reemplazado, sin embargo en los modelos ágiles esto varia, los desarrolladores pueden tomar todas las decisiones. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
72 de 87
Modelos Ágiles/Programación Extrema Los equipos ágiles tienen una gran comunicación tanto los desarrolladores como los expertos del negocio (cambios continuos en la tecnología). La Programación Extrema (XP) comienza con cuatro valores: Comunicación, Retroalimentación, Simplicidad y Coraje. La XP agrupas todas las técnicas y pone todo su énfasis en realizar pruebas, donde cada programador escribe sus pruebas conforme desarrolla software. La XP es un desarrollo evolutivo donde en cada iteración de consigue un producto final. José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
73 de 87
Proceso Unificado de Desarrollo del Software El Proceso Unificado de Desarrollo del Software (PUDS) es un proceso basado en componentes que ha sido propuesto por la industria. El proceso unificado dispone de un Lenguaje de Modelado Unificado (UML), que es utilizado construir el sistema y las interfaces que conectarán los componentes. El PUDS combina un desarrollo incremental e iterativo, definiendo la función del sistema aplicando un enfoque basado en escenarios.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
74 de 87
Proceso Unificado de Desarrollo del Software El PUDS se puede decir que es un proceso: z Dirigido por los casos de uso. 9 Basándose en el modelo de casos de uso y en su análisis los
desarrolladores crean los modelos de diseño e implementación que llevan a cabo los casos de uso.
z Centrado en la arquitectura. 9 La arquitectura de un sistema software se describe mediante
diferentes vistas del sistema en construcción.
z Iterativo e Incremental. 9 El desarrollo de un proyecto se divide en iteraciones, encargadas de
pequeñas partes del trabajo y que dan como resultado un crecimiento del producto, incremento. Estas iteraciones se planifican y se prueban cada vez que terminan.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
75 de 87
Proceso Unificado ANÁLISIS
CÓDIGO
DISEÑO
ENTREGA 1 INCREMENTO
PRUEBA
Prototipo Exploratorio
ANÁLISIS
CÓDIGO
DISEÑO
ENTREGA 2 INCREMENTO
PRUEBA
Línea Base de la Arquitectura ANÁLISIS
DISEÑO
CÓDIGO
ENTREGA 3 INCREMENTO
PRUEBA
Versión Operativa Inicial ANÁLISIS
DISEÑO
CÓDIGO
PRUEBA
ENTREGA 4 INCREMENTO Entrega del Producto
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
76 de 87
Métrica 3 La metodología Métrica 3 es un instrumento para la sistematización de las actividades que dan soporte al ciclo de vida del software. Contempla el desarrollo de sistemas de información para las distintas tecnologías que actualmente conviven. En la elaboración de Métrica 3 se han tenido en cuenta los métodos de desarrollo más extendidos, así como los últimos estándares de ingeniería del software y calidad, además de referencias especificas en cuanto a seguridad y gestión de proyectos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
77 de 87
Métrica 3 Cubre el desarrollo estructurado y orientado a objetos. Facilita los procesos de apoyo y de organización a través de interfaces: Gestión de proyectos; Gestión de configuración; Aseguramiento de calidad y seguridad. La automatización de sus actividades es posible ya que existe una amplia variedad de herramientas de ayuda al desarrollo. Existe una herramienta que adapta Métrica 3 a las condiciones especificas de cada proyecto, permitiendo el control y seguimiento desde diferentes perfiles. Posee un curso de formación. www.map.es/csi
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
78 de 87
¿Por que una Metodología de Desarrollo? La utilización de una metodología en el desarrollo de sistemas permite: z Disponer de un marco estratégico que permite conseguir los fines
de la organización.
z Dotar a la organización de productos software que satisfagan las
necesidades de los usuarios dando una mayor importancia al análisis de requisitos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
79 de 87
Metodología de Desarrollo z Mejorar la productividad de los departamentos de sistemas y
tecnologías de la información y las comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.
z Facilitar la comunicación y entendimiento entre los distintos
participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.
z Facilitar la operación, mantenimiento y uso de los productos
software obtenidos.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
80 de 87
Metodología DUM DUM es una metodología evolutiva e incremental de desarrollo del software que ha sido creada en el departamento de Lenguajes y Ciencias de la Computación de la Universidad de Málaga. Basada en un enfoque iterativo incremental esta metodología realiza una especificación exhaustiva de todas las actividades y tareas que se realizan en las diferentes fases, prestado especial atención por alcanzar un nivel superior de madurez según el marco CMMI/Carnegie Mellon. Las fases en las que se subdivide la metodología DUM son las siguientes: fase preliminar, fase de Inicio, fase de elaboración, fase de construcción, fase de transición; y finalmente, una fase de mantenimiento.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
81 de 87
Metodología DUM Fase Preliminar z En la Fase Preliminar se llevan a cabo una serie de pasos previos en los
que se sientan las bases que permiten comenzar el proyecto. En esta fase el cliente proporciona los dos elementos básicos para comenzar un proyecto: una petición formal del mismo; y una definición del problema al que debe dar respuesta el Sistema a desarrollar. En base a estos dos elementos la organización de desarrollo definirá un primer equipo encargado del inicio del proyecto.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
82 de 87
Metodología DUM Fase de Inicio z En la Fase de Inicio se determina si el problema planteado tiene solución,
lo cual se hace desde un punto de vista genérico, es decir, no se tienen en cuenta posibles restricciones relacionadas con el cliente como costes económicos o plazos de entrega, sólo se tienen en cuenta restricciones que afecten al problema en sí como pueda ser la legalidad vigente. Si al final de la Fase de Inicio se determina que el problema tiene solución, DUM denominará el Sistema a desarrollar un Sistema Realizable. En fases posteriores se estudiará si el nuevo Sistema puede desarrollarse teniendo en cuenta las restricciones impuestas por el cliente, esto es lo que DUM denomina un Sistema Viable.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
83 de 87
Metodología DUM Fase de Elaboración z En la Fase de Elaboración se determina si es posible desarrollar el
Sistema teniendo en cuenta las restricciones impuestas por el cliente, y se obtiene un proyecto particular después de aplicarle las restricciones del cliente al proyecto genérico. z Puede considerarse que en las Fases de Inicio y Elaboración se realiza un trabajo en base a objetivos similares pero tratados a distinto nivel. Así, en la Fase de Inicio se trabaja con un proyecto basado en un problema genérico y se comprueba que dicho proyecto genérico se puede llevar a cabo, mientras que en la Fase de Elaboración se trabaja con una versión particular del proyecto genérico y se comprueba que dicho proyecto particular se puede llevar a cabo.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
84 de 87
Metodología DUM Fase de Construcción z Terminada la Fase de Elaboración se cuenta con un especificación
detallada de qué debe hacer el Sistema, de una arquitectura formada por los elementos del Sistema que guiará cómo cumplirá el Sistema con su cometido, y de una versión inicial del Sistema en base a su arquitectura que será la base sobre la que se construirá el resto del Sistema. z En la Fase de Construcción se completarán las labores de desarrollos pendientes para los casos de uso no incluidos en la arquitectura del Sistema de modo que al final de la fase se cuente con una versión completa del Sistema. Esta versión deberá satisfacer todos los requisitos indicados por el cliente y los criterios de calidad y seguridad establecidos por la organización de desarrollo, sin embargo, no será la versión definitiva del Sistema, será la denominada versión beta del Sistema.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
85 de 87
Metodología DUM Fase de Transición z Durante la Fase de Transición se realiza la prueba del Sistema con el fin
de adaptar el mismo a un entorno de producción realizándose las modificaciones que se estimen necesarias. Los usuarios encargados de probar el sistema (en adelante usuarios beta) recibirán instrucciones acerca de aquellos aspectos del Sistema en los que deben hacer especial hincapié y sobre el proceso a seguir para la proposición, estudio y resolución de propuestas de modificación. A este respecto será necesario desarrollar la estructura necesaria para facilitar en la medida de lo posible dicho proceso.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
86 de 87
Metodología DUM Fase de Mantenimiento z Tras la finalización del proyecto será necesario establecer un acuerdo
respecto al mantenimiento, que puede ser llevado a cabo por la misma organización de desarrollo o por otra distinta.
José Ignacio Peláez Sánchez Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación
87 de 87
Related Documents
Ingenieria De Software
May 2020 15
Ingenieria De Software
July 2020 16
Ingenieria De Software
April 2020 13
Ingenieria De Software
June 2020 13
Ingenieria De Requerimientos De Software
May 2020 12