1 Ingeniería de SoftwareIngenieria de Software y Proceso de Software Asignatura: Ingeniería de Software Curso Actualización : 2012 Profesor: Ernesto Gómez Vargas Facultad de Ingenieria Universidad Distrital Francisco José de Caldas

2 Introducción a los Métodos de Desarrollo de Software.Ingeniería de Software Que es el Software? Proceso de Software Definición de Métodos de desarrollo. Beneficios de usar Métodos. Características deseables. Clasificación. Ejemplos de métodos.

3 Ingeniería de SoftwareLas economías de los países desarrollados dependen en gran parte del software. Mas y más sistemas son actualmente controlados por software. La Ingeniería de Software concierne a teorías, métodos y herramientas para el desarrollo profesional de software. El gasto en La Ingeniería de Software, representa un alto porcentaje del PIB de los países desarrollados

4 Ingeniería de SoftwareQue es la Ingenieria de Software ? Cual es la diferencia entre un programador y un Ingeniero de Software? Cual es la diferencia entre la Ingeniería de Software y la Ingeniera de Sistemas? Cual es la diferencia entre la Ingenieria de Software y la Computación ? Que es el software ? Que es un proceso de software ?

5 Que es la Ingeniería de SoftwareLa Ingeniería de Software es una disciplina de la Ingeniería que concierne a todos los aspectos de la producción de software Los Ingenieros de Software adoptan un enfoque sistemático para llevar a cabo su trabajo y utilizan las herramientas y técnicas necesarias para resolver el problema planteado, de acuerdo a las restricciones de desarrollo y recursos disponibles.

6 Diferencia entre Ingenieria de Software y ComputaciónLa computación concierne a la teoría y fundamentos de cualquier sistema de computo, sea de hardware o de software. La Ingenieria de software concierne solo al desarrollo de sistemas o productos de software La Ingeniería de Software todavía esta lejos de ser una ciencia como los son la Química o la Física.

7 Ingenieria de Sistemas e Ingenieria de SoftwareLa Ingeniería de Sistemas concierne a todos los aspectos del desarrollo de sistemas basados en cómputo, que incluyen hardware, software y el proceso de Ingeniería. La Ingeniería de Software es solo parte de este proceso

8 Que es el Software ? Programas de cómputo y su documentación asociada.Productos genéricos. Productos que son producidos por una organización para ser vendidos al mercado. Productos hechos a medida. Sistemas que son desarrollados bajo pedido a un desarrollador específico. La mayor parte del gasto del software es en productos genéricos, pero hay más esfuerzo en el desarrollo de los sistemas hechos a medida.

9 Características de los Productos de SoftwareMantenibles. Debe ser posible que el software evolucione y que siga cumpliendo con sus especificaciones. Confiabilidad. El software no debe causar danos físicos o económicos en el caso de fallos. Eficiencia. El software no debe desperdiciar los recursos del sistema. Utilización adecuada. El software debe contar con una interfaz de usuario adecuada y su documentación.

10 Costos del Software Costo Directo: Es el que se paga por adquirir el software, se puede adquirir en un negocio de computación, por Internet o Software a la medida. Costo Indirecto: Incluye Capacitación, Instalación, soporte técnico. Costo Oculto: Ocasionado principalmente por las fallas del software a diferencia de los costos directos e indirectos los cuales son previsibles, los costos ocultos son difíciles de prever.

11 Costos del Software Las consecuencias por fallas del software se pueden clasificar en: Consecuencias inmediatas y efectos directos: Son los prejuicios ocasionados mientras dura la caída de los sistemas. Estos costos son relativamente predecibles dado que dependen directamente del tiempo que dure la transacción. Consecuencias a mediano y largo plazo y efectos indirectos. Son los prejuicios posteriores a la caída del sistema. Las consecuencias varían desde la restauración de los datos, servicios de emergencia, propaganda negativa, perdida de clientes y hasta posible accidentes

12 Costos del Software Los costos del software a menudo dominan al costo del sistema. El costo del software en un PC es a menudo mas caro que la PC. Cuesta mas mantener el software que desarrollarlo. Para sistemas con una larga vida, este costo se multiplica. La Ingeniería de Software concierne a un desarrollo efectivo en cuanto a costos del software.

13 Importancia de las características del productoLa importancia relativa de las características depende en el tipo de producto y en el ambiente en el que será utilizado. En algunos casos, algunos atributos pueden dominar. En sistemas de seguridad críticos de tiempo real, los atributos clave pueden ser la confiabilidad y la eficiencia. Los costos tienden a crecer exponencialmente si son requeridos altos niveles de alguna característica.

14 Que tipos de software hay ?Por su estructura: Funcionales. Orientados a objetos. Por su funcion: Programas o Sistemas de Usuario Interfaces Hombre-Maquina. Herramientas de Software. Librerías. Sistemas de uso genérico: Compiladores, S.O’s, Procesadores de Texto, etc. Bases de Datos. Sistemas basados en Web.

15 El Proceso de Software Conjunto estructurado de actividades requeridas para desarrollar un sistema de software. Especificación Diseño Desarrollo Validación Mantenimiento Evolución Las actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse. Debe estar explícitamente modelado si va a ser bien administrado.

16 El Proceso de Software

17 Proceso Genérico de SoftwareEspecificación - establecer los requerimientos y restricciones del sistema Diseño - Producir un modelo en papel del sistema Manufactura - construir el sistema Prueba - verificar que el sistema cumpla con las especificaciones requeridas Instalación - entregar el sistema al usuario y asegurar su operacionalidad Mantenimiento - reparar fallos en el sistema cuando sea descubiertos

18 Características del procesoEntendible: Se encuentra el proceso bien definido. Soportable: Puede el proceso ser soportado por herramientas CASE. Aceptable: El proceso es aceptado por aquellos involucrados en el. Confiable: Los errores del proceso son descubiertos antes de que se conviertan en errores del producto. Robusto: Puede continuar el proceso a pesar de problemas inesperados. Mantenible: Puede el proceso evolucionar para cumplir con los objetivos organizacionales. Rapidez: Que tan rápido puede producirse el sistema.

19 Modelos del proceso de softwareUn modelo de proceso software es una descripción del proceso, desde un punto de vista particular Un modelo es siempre una simplificación del proceso software, una abstracción del proceso real Ejemplos: Un modelo de flujo de trabajo – representa la sucesión de actividades (acciones humanas) en el proceso, en conjunción con sus entradas, salidas y dependencias Un modelo de flujo de datos – representa un conjunto de actividades, cada una produciendo alguna transformación en los datos; los actividades son de menor nivel que las de un modelo de flujo de trabajo y pueden representar acciones humanas o de las computadoras Un modelo de rol/acción – representa los roles de la gente involucrada en el proceso de software y las actividades del cual son responsables

20 Modelos del proceso de softwareLos modelos generales del proceso de software (paradigmas del proceso software) son abstracciones útiles para explicar diferentes enfoques para el desarrollo de software Para desarrollar un sistema muy complejo, se pueden utilizar diferentes procesos de software para diversas partes del sistema

21 El modelo de cascada El primero modelo de proceso de desarrollo de software, derivado de otros procesos de ingeniería (Royse, 1970) Se denomina también como ciclo de vida del software Representa como fases separadas del proceso las actividades fundamentales de este. El modelo se denomina “cascada” debido a la cascada de una fase a otra

22 El modelo de cascada Operación y Mantenimiento Definición deRequerimientos Diseño del Software y del Sistema Implementación y Prueba de unidades Integración y Prueba del Sistema Operación y Mantenimiento

23 El modelo de cascada Análisis y definición de requerimientos – los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios, en detalles, sirviendo como una especificación del sistema Diseño de sistemas y de software – el diseño de sistemas divide los requerimientos en sistemas de hardware o de software y establece una arquitectura completa del sistema; el diseño de software identifica y describe las abstracciones fundamentales del sistema de software y sus relaciones Implementación y prueba de unidades – se obtiene un conjunto o unidades de programas; cada una de las unidades debe cumplir su especificación Integración y prueba del sistema – las unidades individuales se integran y prueban como un sistema completo, que debe cumplir los requerimientos del software Operación y mantenimiento – el sistema se instala y pone en uso práctico; se corigen los errores no descubiertos en las etapas anteriores, se mejora la implementación de las unidades, los servicios del sistema, si se establecen nuevos requerimientos

24 El modelo de cascada El modelo de cascada es inflexible en dividir el proyecto en las etapas mencionadas Refleja la practica de la ingeniería, por lo tanto se siguen utilizando para el desarrollo de software, particularmente cuando éste es parte de proyectos grandes de ingeniería de sistemas En la practica: Las etapas interaccionan y intercambian informaciones El proceso no es un modelo lineal simple, sino que implica una serie de iteraciones de las actividades de desarrollo

25 El modelo de cascada Las iteraciones son costosas e implican rehacer el trabajo, por lo tanto es normal congelar partes del desarrollo después de un numero reducido de iteraciones El congelamiento prematuro de requerimientos puede implicar que el sistema no va a hacer lo que los usuarios desean, o que se obtiene un sistema mal estructurado También puede aparecer la necesidad de repetir algunos (o todas las) etapas previas del proceso, debido a los errores y omisiones que se descubren, o a la necesidad de nuevas funcionalidades

26 El desarrollo evolutivo (construcción de prototipos)Se desarrolla una implementación inicial, exponiéndola a los comentarios del usuario y redefiniéndola a través de las diferentes versiones Las actividades de especificación, desarrollo y validación se llevan a cabo concurrentemente, y tienen realimentación rápida a lo largo del proceso Un primer sistema se desarrolla rápidamente, a partir de especificaciones abstractas, y se refina después, con la ayuda del cliente

27 El desarrollo evolutivoUn enfoque evolutivo para el desarrollo de software es más efectivo que el de cascada, porque cumple con las necesidades inmediatas de los clientes La especificación se puede desarrollar de forma creciente El mejor entendimiento de los usuarios por su problema se reflejará en el sistema software

28 El desarrollo evolutivoDesde una perspectiva de ingeniería y administración, el desarrollo evolutivo pone tres problemas: El proceso no es visible – si los sistemas se desarrollan rápidamente, es muy costoso producir documentos que reflejan cada versión del sistema frecuentemente los sistemas tienen una estructura deficiente – los cambios continuos tienden a corromper la estructura del software se requieren herramientas y técnicas especiales – incompatibles con herramientas y técnicas habituales, relativamente pocas personas teniendo habilidades necesarias para utilizarlas

29 El desarrollo evolutivoEsquema de la descripción Especificación Desarrollo Validación Versión inicial Versiones intermedias Versión final

30 El desarrollo evolutivoMás adecuado para sistemas pequeños o medianos, con un periodo de vida relativamente corto Para sistemas grandes, con un periodo de vida largo, es más eficiente un proceso mixto, que reúna las mejores características del modelo de cascada y el de desarrollo evolutivo: Las partes del sistema bien comprendidas, se especifican y desarrollan utilizando un proceso basado en el modelo de cascada Las partes difíciles de especificar por adelantado (la interfaz de usuario, por ejemplo) se desarrollan utilizando un enfoque de programación exploratoria

31 El desarrollo formal Enfoque parecido al modelo de cascada, pero el proceso de desarrollo se basa en la transformación matemática formal de una especificación del sistema a un programa ejecutable El desarrollo de software es incremental, cada etapa se desarrolla y verifica utilizando un enfoque formal

32 El desarrollo formal Definición de requerimientosEspecificación formal Transformación formal Integración y prueba del sistema

33 El desarrollo formal La especificación formal se refina a través de una serie de transformaciones, hasta llegar a un programa La representación matemática formal del sistema se convierte sistemáticamente en una representación mas detallada, matemáticamente correcta, cada paso agregando mas detalles

34 El desarrollo formal La distancia entre cada transformación es menor que la distancia entre una especificación y un programa, por lo tanto un enfoque por transformaciones compuesto de una serie de pasos pequeños es mas adecuado para sistemas de gran escala Por este tipo de sistemas las pruebas son muy largas y pocas practicas El problema que aparece en el caso del desarrollo formal es de elegir qué transformación aplicar y probar la correspondencia entre transformaciones

35 El desarrollo basado en reutilizaciónSe basa en la existencia de un numero significante de componentes reutilizables, cuales se integran en el sistema, más que desarrollarlos desde cero Aunque en la mayoría de los proyectos software existe algo de reutilización de software, habitualmente esta es una reutilización informal, “empírico” Las personas que trabajan en el proyecto buscan diseños o códigos similares para modificarlos a lo requerido y incorporarlos en el sistema El enfoque orientado a reutilización se compone de un gran numero de componentes de software reutilizable, así como de marcos de trabajos para estos

36 El desarrollo basado en reutilizaciónDefinición de requerimientos Análisis de componentes Modificación de requerimientos Diseño de sistemas con reutilización Desarrollo e integración Validación del sistema

37 El desarrollo basado en reutilizaciónLa primera y la ultima etapa del proceso son similares con otros procesos, pero las etapas intermedias son distintas: Análisis de componentes – se buscan componentes para implementar la especificación de requerimientos Modificación de requerimientos – los requerimientos se modifican para reflejar los componentes disponibles; si eso no es posible, se buscan soluciones alternativas Diseño de sistemas con reutilización – se diseña o se reutiliza un marco de trabajo para el sistema, tomando en cuenta los componentes disponibles; si no hay componentes adecuados, se diseñan otros nuevos Desarrollo e integración – los componentes disponibles se compran, los componentes no-disponibles se desarrollan y todos los componentes y los sistemas se integran

38 El desarrollo basado en reutilizaciónEl modelo orientado a reutilización reduce la cantidad de software a desarrollarse, los costos y los riesgos El proceso es mas rápido Los compromisos en los requerimientos son inevitables, existiendo el peligro de obtener un sistema que no cumple las necesidades reales de los usuarios

39 Modelos de iteración de procesosCada modelo de proceso de software tiene ventajas y desventajas Cada uno es más o poco adecuado para un proceso especifico Para sistemas grandes, complejos, generalmente deben utilizarse enfoques distintos para distintas parte del sistema Por eso se deben utilizar modelos híbridos

40 Modelos de iteración de procesosEl diseño y la implementación del sistema deben rehacerse para reflejar los cambios de los requerimientos del sistema, por lo tanto son necesarios iteraciones de procesos La esencia de los procesos iterativos es que la especificación se desarrolla junto con el software En el enfoque incremental no existe una especificación completa del sistema hasta que la parte final se especifica: Esto puede crear conflictos en organizaciones donde la especificación completa del sistema es parte del contrato para el desarrollo del mismo El enfoque incremental requiere un nuevo tipo de contrato, que a los algunos clientes les es difícil de aceptar

41 Modelos de iteración de procesosExisten dos principales modelos híbridos que permiten el uso de diferentes enfoques de desarrollo apoyando la iteración de procesos: El desarrollo incremental – la especificación, el diseño y la implementación del software se dividen en una serie de incrementos los cuales se desarrollan uno a uno El desarrollo en espiral – el desarrollo gira en espiral hacia fuera, empezando con un esbozo inicial y terminando con el desarrollo final del sistema

42 El modelo incremental El desarrollo incremental:sugerido por Mills (1980) un enfoque intermedio que combina las ventajas del modelo en cascada con las ventajas del modelo de desarrollo evolutivo combina el modelo lineal secuencial con la filosofía interactiva de construcción de prototipos

43 El modelo incremental El modelo de desarrollo en cascada:Se administra fácilmente y su separación en el diseño y la implementación conduce a sistemas robustos, susceptibles a cambios Los cambios de requerimientos durante el desarrollo implican rehacer el trabajo de captura de estos, de diseño e implementación El modelo de desarrollo evolutivo: Permite que los requerimientos y las decisiones de diseño se retrasen Conduce a un sistema débilmente estructurado y difícil de mantener

44 El modelo incremental El modelo incremental:Reduce la repetición del trabajo en el proceso de desarrollo Proporciona a los clientes oportunidades para retrasar las decisiones en los requerimientos detallados, hasta que adquieren cierta experiencia con el sistema Los clientes identifican, de forma somera, los servicios que proveerá el sistema, y la importancia de estos servicios Se definen varios incrementos en donde cada uno proporciona un subconjunto de funcionalidad del sistema Los servicios de prioridad más alta se entregan primero al cliente

45 El modelo incremental Los requerimientos para los servicios que se van a entregar en el primer incremento se definen en detalle y éste se desarrolla utilizando el proceso mas apropiado Una vez que un incremento se completa, no se aceptan cambios en los requerimientos para el incremento en cuestión A diferencia de la construcción de prototipos, los clientes pueden ponerlo en servicio, pudiendo utilizar parte de la funcionalidad del sistema (le permite también clarificar sus requerimientos para los incrementes posteriores) Tan pronto como se implementan los nuevos incrementos, se integran a los existentes, de tal forma que la funcionalidad del sistema mejora con cada incremento No es necesario utilizar el mismo proceso de desarrollo por cada incremento Habitualmente se usa un modelo de cascada si los servicios en un incremento tienen una especificación bien definida, o un modelo de desarrollo evolutivo si la especificación no es clara

46 El modelo incremental Diseñar la arquitectura del sistemaDefinir esquema de requerimientos Asignar requerimientos a los incrementos Desarrollar incrementos del sistema Validar incrementos Integrar incrementos Validar sistema Sistema final

47 El modelo incremental Ventajas:Los clientes no tienen que esperar hasta que el sistema completo se entregue, cada incremento es una versión de sistema disponible para su uso inmediato Los incrementos iniciales pueden ser utilizados como prototipos para obtener experiencia sobre los requerimientos de los incrementos posteriores El riesgo de falla en el proyecto total es bajo, especialmente en las partes mas importantes del sistema, que se entregan primeras (por lo tanto a los servicios mas importantes del sistema les haga más pruebas)

48 El modelo incremental Problemas:Los incrementos (que cada uno debe entregar alguna funcionalidad del sistema) deben ser relativamente pequeños (menos de líneas de código) y, consecuentemente, puede ser difícil adaptar los requerimientos del cliente a incrementos de tamaño apropiado Es difícil de identificar los recursos comunes que requerían todos los incrementos

49 El modelo en espiral El modelo en espiral:Propuesto originalmente por Boehm (1988), es un modelo centrado en actividad Se desarrollo para resolver la debilidad del modelo de cascada El desarrollo gira hacia fuera, empezando con una esquema inicial y terminando con el desarrollo final del sistema Se basa en las mismas actividades que el modelo de cascada, pero añade varias tareas: Administración de riesgo Reutilización Elaboración de prototipos

50 Modelo de Proceso de EspiralEvalúe alternativas, identifique y resuelva riesgos Determine objetivos alternativas y restricciones Análisis de Riesgos Análisis de Riesgos Análisis de Riesgos Prototipo Operacional Prototipo 3 Análisis de Riesgos Prototipo 2 Proto tipo 1 REVISIÓN Simulaciones, modelos Plan de requerimientos Plan del ciclo de vida Concepto de Operación Requeri mientos de SW Diseño del Producto Diseño Detallado Plan de Desarrollo Validación de Requerimientos Codificación Prueba de Unidades Plan de Integración y Prueba Prueba de Integración Prueba de Aceptación Planea la siguiente fase Desarrolla y verifica el siguiente nivel del producto Servicio

51 El modelo en espiral Cada ciclo de la espiral se divide en cuatro sectores: Definición de objetivos – se identifican las restricciones del proceso y el producto, se estipula un plan detallado de administración, se identifican los riesgos y, dependiente de estos, se planean estrategias alternativas Evaluación de alternativas y reducción de riesgos – se hace un análisis detallado para cada uno de los riesgos del proyecto, definiéndose los pasos para reducir dichos riesgos Desarrollo y validación – se elige un modelo apropiado por el desarrollo del sistema, según los riesgos identificados Planeación – Se revisa el proyecto y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral, en este caso planeándose la siguiente fase

52 El modelo en espiral Cada ciclo de la espiral sigue el modelo de cascada e incluye las siguientes actividades: Determinar objetivos Especificar restricciones Generar alternativas Identificar riesgos Resolver riesgos Desarrollar y verificar el producto del siguiente nivel Planear

53 El modelo en espiral A diferencia de otros modelos, el desarrollo en espiral toma en cuenta de una forma explicita el riesgo La disminución de riesgos es una actividad muy importante en la administración del proyecto, ya que estos pueden causar problemas graves, como la calendarización y excesos de costos En el modelo en espiral no existen fases fijas, como la de especificación o diseño El modelo puede contener otros modelos

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

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

56 Proceso unificado de desarrollo de softwarePropuesto por Booch, Jacobson, Rumbaugh Similar al modelo espiral, el proceso consta de varios ciclos Cada ciclo termina con la entrega de un producto al cliente

57 Proceso unificado de desarrollo de softwareCada ciclo consta de cuatro fases: Inicio – se define una necesidad o idea y se evalúa su factibilidad Elaboración – se planea el proyecto, se define el sistema, se le asignan los recursos Construcción – desarrollo Transición – instalación y posdesarrollo Cada iteración trata un conjunto de casos de uso relacionados o resuelve un riesgo identificado al inicio de la iteración

58 Proceso unificado de desarrollo de softwareA diferencia de otros modelos, enfatiza el escalonamianto de recursos Asume que las actividades clásicas (análisis, diseño, implementación, pruebas) participan en cada una de las iteraciones, pero en porcentajes distintas, según las características de la etapa

59 Proceso unificado de desarrollo de softwareSe utiliza un conjunto de modelos relacionadas: Modelo de casos de uso – captura los requerimientos Modelo de análisis – describe el sistema como un conjunto de clases Modelo de diseño – define la estructura del sistema como un conjunto de subsistemas e interfaces Modelo de implementación - establece la correspondencia entre clases y componentes Modelo de pruebas – verifica que el sistema ejecutable proporcione la funcionalidad necesaria

60 Proceso unificado de desarrollo de softwareModelo de casos de uso Especificado por Modelo de análisis Realizado por Distribuido por Modelo de diseño Implementado por Verificado por Modelo de distribución Modelo de implementación Modelo de pruebas

61 Proceso unificado de desarrollo de softwareEl mantenimiento de las dependencias entre los modelos se puede realizar por: Ingeniería hacia delante – los modelos de analisis y diseño se establecen a partir del modelo de casos de uso, los modelos de implementación y pruebas se generan luego, a partir de estos Ingeniería inversa – los modelos de análisis y diseño se extraen o actualizan mediante el código existente Ingeniería de viaje redondo – combinacion de ingeniería hacia delante e inversa, dependiente de cuál modelo esté sufriendo la mayor cantidad de cambios

62 Perspectivas centradas en actividades y perspectivas centradas en entidadesModelos centrados en actividades: Representan de manera explicita las actividades del proceso Los participantes se enfocan en la manera de crear los productos de trabajo Modelos centrados en problemas: Representan de manera explicita los productos de trabajo Los participantes se enfocan en el contenido y estructura de los productos de trabajo

63 El modelo basado en problemasEsta centrado en entidades Esta orientado al manejo de los cambios frecuentes Se puede utilizar si el tiempo entre cambios es significativamente más pequeño que la duración de una actividad Cada proyecto empieza con la identificación de un conjunto de problemas Todos los problemas están guardados en una base de problemas a la que tienen acceso todos los participantes en el proyecto

64 El modelo basado en problemasEl estado de un problema puede ser: Cerrado – ha sido resuelto Abierto – se resuelven mediante conversaciones y negociaciones entre los participantes en el proyecto Un problema cerrado puede abrirse de nuevo si ocurren cambios Entre problemas existen dependencias

65 El modelo basado en problemasSe pueden establecer correspondencias entre los problemas y las actividades de otros modelos (paradigmas) En el modelo en cascada los desarrolladores resuelven por completo los problemas asociadas con una actividad antes de pasar a la siguiente En el modelo espiral los riesgos corresponden a problemas que están evaluados y se vuelven a abrir al inicio de cada ciclo El uso de problemas y sus dependencias permite que las actividades del ciclo de vida se lleven a cabo en forma concurrente La administración del proyecto es muy importante El administrador debe mantener la cantidad de problemas abiertos pequeña y manejable

66 El estándar para el desarrollo de procesos softwareEl estándar IEEE 1074: Describe el conjunto de actividades y procesos obligatorios para el desarrollo y mantenimiento del software Establece un marco común para el desarrollo de modelos de ciclo de vida Ofrece ejemplos de situaciones típicas

67 El estándar para el desarrollo de procesos softwareActividad – tarea o grupo de subactividades que se asignan a un equipo o a un participante del proyecto, para lograr un propósito específico Proceso – conjunto de actividades que se realiza para un propósito específico Grupo de procesos – conjunto de procesos agrupados en un nivel superior de abstracción Las tareas consuman recursos y crean un producto de trabajo Las actividades se descomponen en tareas específicas, se le dan fechas de inicio y fin, se asignan a un participante o a un equipo

68 El estándar para el desarrollo de procesos software (IEEE 1074)Grupo de procesos Procesos Modelado del ciclo de vida Selección de un modelo de ciclo de vida Administración del proyecto Inicio del proyecto Supervisión y control del proyecto Administración de la calidad del software Predesarrollo Exploración de conceptos Asignación del sistema Desarrollo Requerimientos Diseño Implementación Posdesarrollo Instalación Operación y soporte Mantenimiento Retiro Procesos integrales Verificación y validación Administración de la configuración del software Desarrollo de la documentación Entrenamiento

69 El modelo de madurez de capacidadesLas actividades y artefactos que se eligen para un proyecto específico no están definidos por el estándar El modelo de madurez de capacidades (CMM – Capability Maturity Model): Ofrece lineamientos para la selección de actividades del proceso software Asume que el proceso software es más predecible cuando se utilizan modelos de ciclo de vida bien estructurados, visibles para todos los participantes en el proyecto, y que se adaptan al cambio

70 El modelo de madurez de capacidadesCMM utiliza cinco niveles para caracterizar la madurez de una organización: Nivel 1: Inicial Nivel 2: Repetible Nivel 3: Definido Nivel 4: Administrado Nivel 5: Optimizado Para medir la madurez de una organización SEI (Software Engineering Institute) ha definido un conjunto de áreas de proceso claves Para alcanzar a un cierto nivel, la organización debe demostrar que maneja todas las áreas de proceso claves para ese nivel

71 El modelo de madurez de capacidadesNivel 1: Inicial Pocas actividades bien definidas Para asegurar el éxito de un proyecto son necesarios grandes esfuerzos y habilidades individuales El cliente no tiene una forma efectiva para interactuar con la administración del proyecto El modelo del ciclo de vida (si existe) es una caja negra para el cliente El cliente debe esperar hasta el fin del proyecto para inspeccionar el producto

72 El modelo de madurez de capacidadesNivel 2: Repetible Cada proyecto tiene un modelo de ciclo de vida bien definido Los modelos diferentes entre diferente proyectos bajan la posibilidad de reutilizar el conocimiento Los nuevos proyectos se basan en la experiencia de la organización con anteriores proyectos similares El éxito es predecible para proyectos en dominios de aplicación similares a los anteriores El cliente interactúa con la organización solamente en momentos bien definidos Son posibles algunas correcciones antes de la entrega

73 El modelo de madurez de capacidadesNivel 3: Definido Utiliza un modelo de ciclo de vida documentado para todas las actividades administrativas y técnicas por toda la organización Al inicio de cada proyecto se produce una versión personalizada del modelo general El cliente conoce el modelo estándar y el modelo específico para el proyecto en desarrollo

74 El modelo de madurez de capacidadesNivel 4: Administrado Define las medidas para las actividades y los productos a entregar El modelo de ciclo de vida puede entenderse y analizarse de modo cuantitativo Al cliente se le informa de los riesgos antes del comienzo del proyecto y conoce las medidas utilizadas por la organización

75 El modelo de madurez de capacidadesNivel 5: Optimizado Existe un mecanismo de retroalimentación en base a los datos de las mediciones, para mejorar el modelo de ciclo de vida El cliente, los administradores y los desarrolladores se comunican y trabajan juntos durante el desarrollo del proyecto

76 Técnicas de cuarta generación (T4G)Un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir algunas o todas de las siguiente herramientas: lenguajes no procedimentales de consulta a bases de datos, generación de informaciones, manejo de datos interacción y definición de pantallas generación de códigos capacidades graficas de alto nivel etc.

77 Técnicas de cuarta generación (T4G)El enfoque T4G comienza con la análisis de requerimientos El cliente describe los requisitos, que son a continuación traducidos directamente a un prototipo operativo En la practica, el dialogo cliente-desarrollador es esencial, al igual que por otros paradigmas

78 Técnicas de cuarta generación (T4G)A continuación se puede ir directamente al paso de implementación, usando un lenguaje de cuarta generación no procedimental (L4G), pero el uso de T4G sin diseño causará las mismas dificultades que en el caso de los enfoques convencionales (baja calidad, mantenimiento difícil etc.) La implementación mediante un lenguaje L4G permite centrarse en la representación de los resultados deseados, que es lo que se traduce automáticamente en un código fuente que produce dichos resultados Debe existir una estructura de datos con información relevante y a la que el L4G pueda acceder rápidamente

79 Técnicas de cuarta generación (T4G)Las otras etapas del proceso de desarrollo de software (validación, evolución) existen como por cualquier otro enfoque El modelo T4G reduce el tiempo de desarrollo del software y mejora la productividad, especialmente para aplicaciones pequeñas o de tamaño medio Para aplicaciones de alta complejidad, el tiempo que se ahorra mediante la eliminación de la codificación se pierde debido al hecho que se exige el mismo o más tiempo de análisis, diseño y prueba

80 Ingeniería de software asistida por computadoraEl software que se utiliza para ayudar a las actividades del proceso del software se denomina CASE (Computer-Aided Software Engineering) La tecnología CASE ayuda el proceso del software automatizando algunas de sus actividades, así como proporcionando información acerca del software en desarrollo Las herramientas CASE incluyen editores de diseño, diccionarios de datos, compiladores, depuradores, herramientas de construcción de sistemas etc.

81 Ingeniería de software asistida por computadoraAunque la tecnología CASE está disponible para muchas actividades rutinarias en el proceso del software y conduce a algunas mejoras en la calidad y productividad del software, esta tecnología no ha revolucionado a la ingeniería de software como se predijo Hay dos factores importantes que limitan la utilización de la tecnología CASE: los sistemas CASE automatizan actividades de rutina, pero la ingeniería de software es una actividad que se basa en la creatividad la ingeniería de software es una actividad de equipo, pero la tecnología CASE no facilita la interacción con los otros miembros del equipo

82 Ingeniería de software asistida por computadoraExistan varias formas de clasificar las herramientas CASE, cada una de las cuales proporciona una perspectiva diferente de esas herramientas: Una perspectiva funcional – clasifica las herramientas CASE de acuerdo con su función especifica Una perspectiva de proceso – clasifica las herramientas CASE de acuerdo con su ayuda a las actividades del proceso Una perspectiva de integración – clasifica las herramientas CASE de acuerdo con la forma en que están organizadas en unidades integradas, las cuales proporcionan ayuda a una o más actividades del proceso.

83 Que modelo utilizar ? Para sistemas bien comprendidos utiliza el Modelo de Cascada. La fase de análisis de riesgos es relativamente fácil. Con requerimientos estables y sistemas de seguridad críticos, utiliza modelos formales. Con especificaciones incompletas, utiliza el modelo de prototipado. Pueden utilizarse modelos híbridos en distintas partes del desarrollo.

84 Métodos (metodologías) de Desarrollo de SoftwareConjunto de pasos y procedimientos que deben seguirse para el desarrollo de software Cómo se debe dividir un proyecto en etapas. Qué tareas se llevan a cabo en cada etapa. Qué salidas se producen y cuándo se deben producir. Qué restricciones se aplican. Qué herramientas se van a utilizar. Cómo se gestiona y controla un proyecto. Vamos a ver un instrumento para conseguir el enfoque disciplinado al desarrollo de software que estamos buscando: las metodologías o métodos de desarrollo de software. (Existe confusión en cuanto al uso de los términos “método” y “metodología”.) Como tantas veces en ingeniería del software, no existe un consenso en cuanto a qué cosas deben formar parte de un método.

85 Métodos de desarrollo de softwareEs necesario establecer un enfoque disciplinado y sistemático para desarrollar un proyecto de software Método (metodología) Método  Notación Método  Técnica

86 ¿Qué es un método de desarrollo de software?“Conjunto de procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a producir nuevo software”. Modelo de proceso (fases y subfases, actividades, tareas). Procedimientos que dan lugar a productos. Técnicas (gráficas, textuales) Herramientas. Puede acomodar varios ciclos de vida: Ciclo de vida: qué hay que producir, no cómo. Método: qué y cómo. Entre los componentes genéricos de un método, tenemos: Un modelo de proceso (fases y subfases, actividades, tareas). Un conjunto de procedimientos, que definen la forma de ejecutar las tareas. Un conjunto de técnicas, que permiten aplicar los procedimientos, y con las que se genera un conjunto de productos (artefactos). Con mucha frecuencia son gráficas con apoyos textuales formales. Una misma técnica se puede aplicar varias veces dentro de una metodología, o en metodologías diferentes (p.ej. DFDs en Métrica y en SSADM). Para usar una técnica, podemos apoyarnos en herramientas software que automatizan en mayor o menor grado su aplicación. Hay herramientas que dan soporte a más de una metodología (como System Architect).

87 ¿Qué es un método de desarrollo de software?Definición alternativa de (Sommerville 2002) “Un método de ingeniería de software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta calidad de una forma costeable.” . Todos los métodos se basan en la idea de modelos gráficos de desarrollo de un sistema y en el uso de estos modelos como un sistema de especificación o diseño.

88 ¿Qué es un método de desarrollo de software?Componentes Descripción Ejemplo Descripciones del modelo del sistema Descripciones de los modelos del sistema que se desarrollará y la notación utilizada para definir estos modelos Modelos de objetos, de flujo de datos, de máquina de estado, etc. Reglas Restricciones que siempre aplican a los modelos de sistemas Cada entidad de un modelo de sistema debe tener un nombre único Recomenda-ciones Seguir estas recomendaciones debe dar como resultado un modelo del sistema bien organizado. Ningún objeto debe tener más de 7 subobjetos asociados a él. Guías en el proceso Descripciones de las actividades que deben seguirse para desarrollar los modelos del sistema y la organización de estas actividades. Los atributos de los objetos deben documentarse antes de definir las operaciones asociadas a un objeto. Para (Sommerville 2002), los métodos contienen los componentes que refleja esta tabla.

89 Métodos de desarrollo BeneficiosSistemas de mayor calidad Pero el seguimiento de una metodología no basta! Proceso de desarrollo (modelo de procesos) definido  productos intermedios en cada fase  mejor planificación y gestión del proyecto Desarrollos más rápidos. Recursos adecuados. Proceso estándar en la organización  facilidad de cambios de personal.

90 Métodos de desarrollo Adaptación del métodoNo existe un método “universal” o “ideal” Métodos diferentes tienen distintas áreas donde son aplicables P.ej., los métodos OO son adecuados para sistemas interactivos, pero no para sistemas en tiempo real con requisitos severos (Sommerville 2002). El método está condicionado por el tamaño y estructura de la organización, y el tipo de aplicaciones. “No es razonable pensar que dos organizaciones utilicen la misma metodología sin realizar cambios sobre ella”.

91 Métodos de desarrollo Características deseablesExistencia de reglas predefinidas. Fases y subfases, tareas, productos intermedios, técnicas, herramientas, etc. Cobertura total del ciclo de desarrollo. Verificaciones intermedias. Planificación y control. Comunicación efectiva. Uso sobre un amplio abanico de proyectos. Fácil formación. Ver (Piattini et al. 96) p.72

92 Métodos de desarrollo Características deseablesHerramientas CASE. Debe contener actividades que mejoren el proceso de desarrollo. Soporte al mantenimiento. p.ej. Reingeniería. Soporte de la reutilización del software no sólo reutilización de código. Actualmente, se huye de métodos muy burocráticos o “monolíticos”.  Métodos “ágiles”.

93 Métodos. ClasificaciónEstructurados: representan los procesos, flujos y estructuras de datos, de una manera jerárquica, descendente Ven el sistema como entradas-proceso-salidas Orientados a procesos: Se centran en la parte proceso Miniespecificaciones de proceso. Orientados a datos: Se orientan más a las entradas y salidas Primero se definen los datos A partir de ellos, los componentes procedimentales Los datos son más estables

94 Métodos. Ejemplos Estructurados Orientados a datos OO Tiempo realDe Marco 79 Gane & Sarson 79 Yourdon 89 SSADM Merise MÉTRICA 2.1 Orientados a datos JSD Jackson Warnier 74 Una vez que has visto este tema, deberías ser capaz de poner varios ejemplos de métodos, que usen distintas técnicas y notaciones. OO OMT (Rumbaugh et al. 91) Booch 94 Objectory/OOSE (Jacobson 93) FUSION (Coleman 94) OOram (Reenskaug 96) Proceso Unificado (Jacobson et al. 99) Rational Unified Process (RUP) (Krutchen et al. 99) Tiempo real Ward & Mellor 85 Hatley & Pirbhay 87