1 presentacion_1_-_ingenieria_de_software[1]

  • 2,137 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,137
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
74
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Ingeniería de Software Ingeniería de Software y Proceso de Software Asignatura: Ingeniería del Software Año 2010SENAModulo de introducción a sistemas
  • 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 Software Las 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 Software Que 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 Software La 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ón La 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 Software La 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 Software Mantenibles.  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 producto La 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 Software Especificació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 proceso Entendible: 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 software Un 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 software Los 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 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 cascada1. 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 sistema2. 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 relaciones3. Implementación y prueba de unidades – se obtiene un conjunto o unidades de programas; cada una de las unidades debe cumplir su especificación4. Integración y prueba del sistema – las unidades individuales se integran y prueban como un sistema completo, que debe cumplir los requerimientos del software5. 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 evolutivo Un 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 evolutivo Esquema de la descripciónEspecificación Desarrollo Validación Versión inicial Versiones intermedias Versión final
  • 30. El desarrollo evolutivo Má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 Especificación Transformación Integración yrequerimientos formal formal 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ón Se 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ón Definición derequerimientos 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ón con otros procesos,La primera y la ultima etapa del proceso son similares 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ón El 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 procesos Cada 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 procesos El 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 incrementalEl 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 incrementalEl 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ónEl 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 incrementalEl 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 Definir Asignar Diseñar la esquema de requerimientos a arquitectura delrequerimientos los incrementos sistema Desarrollar Validar Integrar Validar Sistemaincrementos incrementos incrementos sistema final del sistema
  • 47. El modelo incrementalVentajas: 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 incrementalProblemas: Los incrementos (que cada uno debe entregar alguna funcionalidad del sistema) deben ser relativamente pequeños (menos de 20.000 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 espiralEl 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 Espiral Evalúe alternativas,Determine objetivos identifique y resuelva alternativas y riesgos restricciones Análisis de Riesgos Análisis de Riesgos Análisis de Riesgos Prototipo Prototipo Operacional Análisis Prototipo 3 de Proto 2 REVISIÓN Riesgos tipo 1 Simulaciones, modelos Plan de requerimientos Concepto de Plan del ciclo de vida Operación Requeri mientos de Diseño Diseño SW del Detallado Plan de Validación de Producto Codificación Desarrollo Requerimientos Prueba de Plan de Integración Unidades Prueba de y Prueba Prueba de Integración Planea la Aceptación Desarrolla y verifica siguiente fase Servicio el siguiente nivel del producto
  • 51. El modelo en espiralCada 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 espiralCada 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 espiral Objetivos. Restricciones. Alternativas. Riesgos. Resolución de riesgos. Resultados. Planes. Garantías (commitments).
  • 55. Ventajas del Modelo de Espiral Centra su atención en la reutilización de componentes y eliminación de errores en información descubierta en fases iniciales. 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 software Propuesto 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 software Cada 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 software A 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 software Modelo de casos de uso Especificado por Modelo de Realizado por análisis Distribuido por Modelo de Implementado por diseño Modelo de Verificado por 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 entidades Modelos 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 problemas Esta 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 problemas El 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 problemas Se 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íficoProceso – conjunto de actividades que se realiza para un propósito específicoGrupo 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 Selección de un modelo de ciclo de vidaModelado del ciclo de vida Inicio del proyectoAdministración del proyecto Supervisión y control del proyecto Administración de la calidad del software Exploración de conceptosPredesarrollo Asignación del sistema RequerimientosDesarrollo Diseño Implementación InstalaciónPosdesarrollo Operacióny soporte Mantenimiento Retiro Verificacióny validaciónProcesos integrales Administración de la configuración del software Desarrollo de la documentación Entrenamiento
  • 69. El modelo de madurez de capacidades Las 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 capacidades CMM 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 computadora El 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 computadora Aunque 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 Software Conjunto 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.
  • 85. Métodos de desarrollo de software Es necesario establecer un enfoque disciplinado y sistemático para Método desarrollar un proyecto (metodología) de software 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.
  • 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 EjemploDescripciones Descripciones de los modelos del Modelos de objetos, de flujodel modelo del sistema que se desarrollará y la de datos, de máquina desistema notación utilizada para definir estos estado, etc. modelosReglas Restricciones que siempre aplican a Cada entidad de un modelo los modelos de sistemas de sistema debe tener un nombre únicoRecomenda- Seguir estas recomendaciones debe Ningún objeto debe tenerciones dar como resultado un modelo del más de 7 subobjetos sistema bien organizado. asociados a él.Guías en el Descripciones de las actividades que Los atributos de los objetosproceso deben seguirse para desarrollar los deben documentarse antes modelos del sistema y la de definir las operaciones organización de estas actividades. asociadas a un objeto.
  • 89. Métodos de desarrollo Beneficios Sistemas 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  Desarrollosmá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étodo No 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 deseables Existencia 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.
  • 92. Métodos de desarrollo Características deseables Herramientas 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ón Estructurados: 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  OO  De Marco 79  OMT (Rumbaugh et al. 91)  Gane & Sarson 79  Booch 94  Yourdon 89  Objectory/OOSE (Jacobson  SSADM 93)  Merise  FUSION (Coleman 94)  MÉTRICA 2.1  OOram (Reenskaug 96) Orientados a datos  Proceso Unificado (Jacobson  JSD Jackson et al. 99)  Warnier 74  Rational Unified Process (RUP) (Krutchen et al. 99)  Tiempo real  Ward & Mellor 85  Hatley & Pirbhay 87