Ingenieria de Software Introducción a los Conceptos Basicos

Ingenieria de Software

1. INGENIERÍA DE SOFTWARE Ing. Jorge Hernando Mongui Naranjo Esp . Gerencia Informática Esp . Soluciones cableadas e inalámbricas [email protected]

2. HISTORIA Este término fue introducido a finales de los 60 a raíz de la crisis del software. Esta crisis fue el resultado de la introducción de la tercera generación del hardware. El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y mejoro la calidad y eficiencia en el software producido La crisis se caracterizo por los siguientes problemas: Imprecisión en la planificación del proyecto y estimación de los costos.

3. HISTORIA Baja calidad del software. Dificultad de mantenimiento de programas con un diseño poco estructurado, etc. Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la compra. También se requiere una serie de características como fiabilidad, facilidad de mantenimiento y de uso, eficiencia, etc.

4. Ingeniería de software es la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad.

5. Ingeniería de software Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por el Comité de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968.

6. Ingeniería de software Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:

7. Autores 1 - Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978). 2 - Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software (Bohem, 1976).

8. 3 - Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972). 4 - Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

9. Objetivos de la ingeniería de software En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software.

10. Mejorar la calidad de los productos de software Aumentar la productividad y trabajo de los ingenieros del software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.

11. OBJETIVOS Para que los objetivos se cumplan las empresas emprenden proyectos por las siguientes razones: "Las cinco C”.

12. razones Capacidad Costo C ontrol Comunicación Competitividad

13. Capacidad Las actividades de la organización están influenciadas por la capacidad de ésta para procesar transacciones con rapidez y eficiencia.

14. Costo Vigilancia de los costos : Para determinar si la compañía evoluciona en la forma esperada, de acuerdo con lo presupuestado, se debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y gastos generales.

15. control Llevar una estadística que permita darle al usuario tranquilidad es muy difícil sin contar con la ayuda de una computadora.

16. Comunicación La falta de comunicación es una fuente común de dificultades que afectan tanto a cliente como a empleados. Sin embargo, los sistemas de información bien desarrollados amplían la comunicación y facilitan la integración de funciones individuales.

17. Competitividad Los sistemas de información computacionales son un arma estratégica, capaz de cambiar la forma en que la compañía compite en el mercado, en consecuencia éstos sistemas mejoran la organización y la ayudan a ganar "ventaja competitiva", sin embargo, si los competidores de la compañía tienen capacidades mas avanzadas para el procesamiento de información, entonces los sistemas de información pueden convertirse en una "desventaja competitiva ".

18. Etapas del proceso La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes :

19. Análisis de requisitos Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I Asimismo, se define un diagrama de entidad, en el que se plasman las principales entidades que participarán en el desarrollo del software.

20. Especificación Es la tarea de describir detalladamente el software a ser escrito, en una forma matemáticamente rigurosa. En la realidad, la mayoría de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son más importantes para las interfaces externas, que deben permanecer estables.

21. Diseño y arquitectura Se refiere a determinar como funcionará de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los casos de uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos.

22. Programación Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado .

23. Documentación Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc.; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema .

24. Mantenimiento Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o Bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento .

25. El Proceso Unificado El Proceso Unificado "es un proceso de desarrollo de software configurable que se adapta a través de los proyectos variados en tamaños y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología orientada a objetos en el desarrollo de software de misión crítica en una variedad de industrias por la compañía Rational", donde confluyen 'los tres amigos' como se llaman a sí mismos o los tres grandes: Grady Booch, James Rumbaugh e Ivar Jacobson .

26. Proceso Unificado y MSF; complementos tecnológicos Según "más que una metodología, Microsoft Solutions Framework MSF. Es una serie de modelos flexibles interrelacionados que guían a una organización sobre como ensamblar los recursos, el personal y las técnicas necesaria para asegurar que su infraestructura tecnológica y sus soluciones cumplan los objetivos de negocio. MSF mantiene una relación clara entre los objetivos de negocio y las implementaciones tecnológicas".

27. "MSF se puede utilizar por sí mismo o con otras herramientas y técnicas como el Proceso Rational [Proceso Unificado] para planear, construir y administrar el desarrollo de soluciones de negocio a la medida“ "El proceso Unificado es un proceso de desarrollo de software configurable que se adapta a proyectos que varían en tamaño y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología de objetos en el desarrollo de software de misión crítica en una variedad de industrias. Uno de los componentes clave es el UML"

28. El Proceso Unificado ha adoptado un enfoque que se caracteriza por : Interacción con el usuario continua desde un inicio Mitigación de riesgos antes de que ocurran Liberaciones frecuentes Aseguramiento de la calidad Involucramiento del equipo en todas las decisiones del proyecto Anticiparse al cambio de requerimientos

29. El Proceso Unificado y MSF se enfocan en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de reuso. MSF considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa

30. Arquitectura de Negocios - Describe como opera un negocio. Desarrolla una imagen clara de los procesos de flujo de trabajo de la organización y de cómo son apoyados por una infraestructura tecnológica basada en servicios.

31. Arquitectura de Aplicación – Adopta un modelo de aplicación de toda la empresa para diseñar y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor.

32. Arquitectura de Información – Define qué información es necesaria para apoyar el proceso de negocios, cómo poner esa información eficientemente en manos de quienes la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes.

33. Arquitectura Tecnológica – Define los estándares y guías para la adquisición y despliegue de herramientas, bloques de construcción de aplicaciones, servicios de infraestructura, componentes de conectividad de red y plataformas cliente servidor.

34. Modelos de desarrollo de software La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos: Modelo en cascada o Clásico (modelo tradicional) Modelo en espiral (modelo evolutivo) Modelo de prototipos Desarrollo por etapas Desarrollo iterativo y creciente o Iterativo Incremental RAD (Rapid Application Development)

35. Modelo en cascada o Clásico (modelo tradicional) es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software , de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

36. Modelo en cascada o Clásico Un ejemplo de una metodología de desarrollo en cascada es: Análisis de requisitos Diseño del Sistema Diseño del Programa Codificación Pruebas Implantación Mantenimiento

37. De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

38. Desventajas En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso. Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases. Los resultados y/o mejoras no son visibles, el producto se ve recién cuando este esté finalizado, lo cual provoca una gran inseguridad por parte del cliente que anda ansioso de ver avances en el producto. Esto también implica toparse con requerimientos que no se habían tomado en cuenta, y que surgieron al momento de la implementación, lo cual provocara que se regrese nuevamente a la fase de requerimientos.

39. Ventajas Se tiene todo bien organizado y no se mezclan las fases. Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar

40. Desarrollo en espiral El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

41. El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios. Se caracteriza principalmente por: Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo. Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

42. En cada vuelta o iteración hay que tener en cuenta Los Objetivos: Que necesidad debe cubrir el producto. Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser: Características: experiencia del personal, requisitos a cumplir, etc. Formas de gestión del sistema. Riesgo asumido con cada alternativa. Desarrollar y Verificar: Programar y probar el software.

43. principios básicos: El modelo espiral captura algunos principios básicos: Decidir qué problema se quiere resolver antes de viajar a resolverlo. Examinar tus múltiples alternativas de acción y elegir una de las más convenientes. Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.

44. Modelo en espiral se divide en un número de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.

45. Comunicación con el cliente : las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos. Análisis de riesgos : las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto. I ngeniería : las tareas requeridas para construir una o más representaciones de la aplicación. Construcción y adaptación : las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluación el cliente : las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.

46. Modelo de prototipos En Ingeniería de software el desarrollo con prototipación , también llamado modelo de prototipos que pertenece a los modelos de desarrollo evolutivo , se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido).

47. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

48. Ventajas Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

49. Inconvenientes El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo , pero partiendo de un estado poco recomendado.

50. Inconvenientes En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

51. Desarrollo rápido de aplicaciones Rapid application development ( RAD ) es un proceso de desarrollo de software (en inglés, software development process ), desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

52. Ventajas y desventajas El desarrollo rápido tiene dos ventajas primarias: Velocidad del desarrollo: Los aumentos de la velocidad son debido al uso de la herramienta CASE. Calidad: según lo definido por el RAD, es el grado al cual un uso entregado resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta calidad con la implicación del usuario en las etapas del análisis y del diseño.

53. Ventajas y desventajas El RAD tiene dos desventajas primarias: Características reducidas. Escalabilidad reducida: debido a que el RAD se desarrolló como prototipo

54. Proceso unificado El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo

55. Características Es un conjunto de actividades necesarias para transformar los requerimientos de un usuario en un sistema de software. Proceso Unificado es un marco de trabajo de proceso genérico que puede especializarse para cada clase de sistemas de software, para diferentes áreas de aplicación, tipo de organizaciones, niveles de competencia y tamaños de proyecto. Proceso de Desarrollo de Software --- requerimientos---- Sistema de Software Basado en componentes, significa que está hecho de componentes de software interconectados con interfaces. Usa el Lenguaje de Modelado Unificado (UML)

56. CENTRADO EN LA ARQUITECTURA Concepto similar a la arquitectura de un edificio Varios planos con diferentes aspectos del edificio Tener una imagen completa del edificio antes que comience la construcción Arquitectura en software Diferentes vistas del sistema: estructural, funcional, dinámico, etc. Plataforma en la que va a operar Determina la forma del sistema Arquitectura: determina la forma del sistema Casos de uso: Determinan la función del sistema

57. Aspectos que distinguen al PU Manejado por Caso de Uso Centrado en Arquitectura Iterativo e Incremental

58. PU es Manejado por Caso de Uso Un usuario representa a alguien o algo que Interactúa con el sistema En respuesta, el sistema realiza una secuencia de Acciones que proporcionan al usuario un Resultado de valor una interacción de este tipo es un caso de uso

59. INTERACTIVO E INCREMENTAL Descomposición de un proyecto grande en mini-proyectos Cada mini-proyecto es una iteración Las iteraciones deben estar controladas Cada iteración trata un conjunto de casos de uso

60. VENTAJAS DEL ENFOQUE ITERATIVO Detección temprana de riesgos Administración adecuada del cambio Mayor grado de reutilización Mayor experiencia para el grupo de desarrollo

61. Caso de uso

62. HISTORIA En 1986, Ivar Jacobson, importante contribuyente al desarrollo de los modelos de UML y proceso unificado, creó el concepto de caso de uso.

63. Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Un diagrama muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo.

64. Una metodología de desarrollo de software es dirigida por casos de uso, si cada una de las actividades o disciplinas de su proceso (análisis de requerimientos, diseño, implementación y prueba) es dirigida en su ejecución por los casos de uso. Esto quiere decir que el ingeniero de software especifica los requerimientos por medio del modelo de casos de uso, el cual sirve como referente principal para la construcción del modelo de diseño, representado básicamente por medio de los diagramas de clase y de secuencia