Crisis del software La crisis del software se fundamentó en el tiempo de creación de software, ya que en la creación del mismo no se obtenían los resultados.

Presentación del tema: "Crisis del software La crisis del software se fundamentó en el tiempo de creación de software, ya que en la creación del mismo no se obtenían los resultados."— Transcripción de la presentación:

1 Crisis del software La crisis del software se fundamentó en el tiempo de creación de software, ya que en la creación del mismo no se obtenían los resultados deseados, además de un gran costo y poca flexibilidad. Término informático acuñado en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software, de la cual nació formalmente la rama de la ingeniería de software. El término se adjudica a F. L. Bauer, previamente utilizado por Edsger Hijastra en su obra The Humble Programmer. La crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas son, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios.

2 Crisis del software No existen todavía herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa. Este hecho provoca que la mayoría de las veces no sea posible estimar cuánto tiempo llevará un proyecto, ni cuánto personal será necesario. Cuando se fijan plazos normalmente no se cumplen por este hecho. Del mismo modo, en muchas ocasiones el personal asignado a un proyecto se incrementa con la esperanza de disminuir el plazo de ejecución. Por último, las aplicaciones de hoy en día son programas muy complejos, inabordables por una sola persona. En sus comienzos se valoró como causa también la inmadurez de la ingeniería de software, aunque todavía hoy en día no es posible realizar estimaciones precisas del coste y tiempo que necesitará un proyecto de software.

3 Crisis del software Englobó a una serie de sucesos que se venían observando en los proyectos de desarrollo de software: Los proyectos no terminaban en plazo. Los proyecto no se ajustaban al presupuesto inicial. Baja calidad del software generado. Software que no cumplía las especificaciones. Código inmantenible que dificultaba la gestión y evolución del proyecto. Aunque se han propuesto diversas metodologías para intentar subsanar los problemas mencionados, lo cierto es que todavía hoy no existe ningún método que haya permitido estimar de manera fiable el coste y duración de un proyecto antes de su comienzos.

4 Características del SW
1.-El software se desarrolla o construye; no se manufactura en el sentido clásico. A pesar de que existen similitudes entre el desarrollo del software y la manufactura del hardware, las dos actividades serian diferentes en lo fundamental. En ambas la alta calidad se alcanza por medio del buen diseño, la fase de manufactura del hardware puede incluir problemas de calidad existentes en el software. 2. El software no se desgasta. El software es inmune a los males ambientales que desgasten el hardware. Por lo tanto la curva de tasas de fallas para el software debería tener la forma de la “curva idealizada”. Los defectos sin descubrir causan tasas de fallas altas en las primeras etapas de vida de un programa. Sin embargo, los errores se corrigen y la curva se aplana: el software no se desgasta, pero si se deteriora. 3. A pesar de que la industria tiene una tendencia hacia la construcción por componentes, la mayoría del software aun se construye a la medida. Un componente de software se debe diseñar e implementar de forma que puede utilizarse en muchos programas diferentes. Los componentes reutilizables modernos encapsulan tanto los datos como el proceso se aplican a estos, lo que permite al ingeniero de software crear nuevas aplicaciones nuevas a partir de partes reutilizables.

5 Características del SW

6 Mitos del Software Los mitos del software-creencias acerca del software y de los procesos empleados para construirlo- se pueden rastrear hasta los primeros días de la computación. Los mitos tienen ciertos atributos que los convierten en insidiosos. Mitos de la administración Los gestores con responsabilidad sobre el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir las propuestas, hacer que no se retrase el proyecto y mejorar la calidad. Un gestor de software se agarra frecuentemente a un mito del software. Mito: Si se falla en la planificación, se puede añadir mas programadores y adelantar el tiempo perdido.

7 Mitos del Software Mitos del cliente Mitos de los desarrolladores
En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores de software hacen muy poco para corregir la mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el desarrollador del software. Mito: Si los requisitos del proyecto cambian continuamente, los cambios pueden acomodarse fácilmente, ya que el software es flexible. Mitos de los desarrolladores Los mitos en los que aun creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática. Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir. Mito: Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.

8 Componentes de Software
Un componente de software tiene las siguientes características: Es una unidad ejecutable que puede ser implantada independientemente (esto de implantado es que puede ser instalado, en ingles deployment). Puede ser sujeto de composición por terceras partes, es decir, una compañía o un desarrollador puede llegar y tomar el componente y agregarlo a lo que esté haciendo, o sea haría una composición de componentes. Un componente no tiene estado (al menos externamente visible) Se puede tomar a los componentes de software como una analogía a los componentes electrónicos, la idea de esto es tener diversos componentes que puedan ser tomados para hacer un sistema más grande, así como tomar procesadores, integrados, memorias, etc. para hacer una computadora por ejemplo. Existen diversos modelos de componentes, los más conocidos son .NET, EJB (Enterprise Java Beans) y CCM (CORBA Component Model). El paradigma de desarrollo orientado a componentes es un campo emergente.

9 Ingeniería de SW La Ingeniería del Software es una disciplina o área de la informática o ciencias de la computación, que ofrece método y técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Cada vez mas frecuente la consideración de la Ingeniería del Software como un nueva área de la ingeniería El Ingeniero del Software comienza a ser una profesión implantada en el mundo laboral. La Ingeniería del Software trata áreas muy diversas de la informática y de las ciencias de la computación.

10 Ingeniería de SW Definición del Termino “Ingeniería del Software”
El Termino Ingeniería se define en el DRAE(Diccionario de la Real Academia Española de la Lengua) como: Conjunto de conocimientos y técnicas que permiten aplicar el saber científico a la utilización de la materia y de las fuentes de energia Profesión y ejercicio del “Ingeniero” y el termino Ingeniero se define como: Persona que profesa o ejerce la ingeniería. De igual modo la Real Academia de la Ciencias Exactas, Fisicas y Naturales de España define el termino Ingeniería como: Conjunto de conocimientos y tecnicas cuya aplicacion permite la utilizacion racional de los materiales y de los recursos naturales, mediante invenciones, construcciones u otras realizaciones provechosas para el hombre”.

11 Ingeniería de SW Evidentemente, si la Ingeniería del Software es una nueva ingeniería parece lógico que reúna las propiedades citadas en las definiciones anteriores. Sin embargo, ni el DRAE ni la Real Academia Española de Ciencias ha incluido todavía el termino en sus ultimas ediciones; en consecuencia vamos a recurrir para su definición mas precias a algunos de los autores mas acreditados que comenzaron en sus momento a utilizar el termino o bien en las definiciones dadas por organizaciones internacionales profesionales de prestigio tales como IEEE o ACM.

12 Ingeniería de SW Definición 1 Ingenieria del Software es el estudio de los principios y metodologias para desarrollo y mantenimiento de sistemas de software. [Zelkovitz, 1978] Definición 2 Ingenieria del Software es la aplicacion practica del conocimiento cientifico en el diseño y construccion de programas de computadora y la documentacion asociada requerida para desarrollar y operar(funcionar) y mantenerlos. Asi como tambien desarrollo de software o produccion de software. [Bohem 1976] Definición 3 Ingenieria del software trata del establecimiento de los principios y metodos de la ingenieria a fin de obtener software de modo rentable que sea fiable y trabaje en maquinas reales. [Bauer, 1972]

13 Ingeniería de SW Definición 4 La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo operación(funcionamiento) y mantenimiento del software: es decir, El estudio de enfoques con en la aplicación de ingeniería al software. [IEEE, 1993] Tomando como base la referencia de estas definiciones seleccionadas, se produce de inmediato la pregunta: ¿Cuales son las Actividades que se encuadran hoy en día en el mundo de la ingeniería del software?

14 Ingeniería de SW La respuesta a esta pregunta se manifiesta de muy diversas formas pero tal vez las fuentes mas objetivas sean las conferencias, congresos, eventos y acontecimientos mas relevantes realizados en estos últimos años. En estos congresos y en algunas otras fuentes como revistas de ACM/IEEE y otras de tipo profesional o comercial especificas de ingeniería de software he analizado sus programas, tutoriales, talleres de trabajo, contenidos, etc y se ha seleccionado una lista con los temas mas candentes del actual estado de arte de la Ingenieria del Software. Los temas mas sobresaliente son:

15 Ingeniería de SW Inspección de Software Critico
Software de Tecnologías de Procesos de Negocios Arquitecturas de Software Distribuido UML (Lenguaje Unificado de Modelado de Booch, Rumbaugch y Jacobson) Control Tecnico de Proyectos de Software Marcos de Trabajo (FrameWorks) de empresa orienta a objetos CORBA (Estándar para objetos distribuidos) Estrategias de Ingeniería Inversa para migración de software Ingeniería de Objetos Modelado y Análisis de Arquitectura de Software Objetos Distribuidos Sistemas Cliente Servidor Reingeniería CASE Análisis y Diseño Orientado a Objetos Reutilización de Software Ingeniería de Bases de Datos Datawarehousing Datamining Ingeniería Web Metodología Agiles Entre Otros

16 Procesos Métodos Herramientas
Los métodos de la ingeniería del software indican " Cómo" construir técnicamente el software. Los métodos abarca un amplio espectro de tareas que incluyen: planificación y estimación de proyectos, análisis de los requisitos del sistema y del software, diseño de estructuras de datos, arquitecturas de programas y procedimientos algorítmicos, prueba y mantenimiento. Los métodos de la ingeniería de software introducen frecuentemente una notación especial orientada a un lenguaje o gráfica y un conjunto de criterios para la calidad del software.

17 Procesos Métodos Herramientas
Las herramientas de la ingeniería del software suministran un soporte automático o semiautomático para los métodos. Hoy existen herramientas para soportar cada uno de los métodos mencionados. Cuando se integran las herramientas de forma que la información creada por una herramienta pueda ser usada por otra, se establece un sistema para el soporte de desarrollo del software, llamado ingeniería del software asistida por computadora (en inglés, CASE) . CASE combina software, hardware y bases de datos sobre la ingeniería del software (una estructura de datos que contenga la información relevante sobre el análisis , diseño, codificación y prueba) para crear un entorno de ingeniería del software análogo al diseño/ingeniería asistido por computadora, CAD/CAE para el hardware.

18 Procesos Métodos Herramientas
Los procesos de la ingeniería del software son el pegamento que junta los métodos y las herramientas y facilita un desarrollo racional y oportuno del software de computadora. Los procesos definen la secuencia en la que se aplican los métodos, las entregas (documentos, informes, formas, etc) que se requieren, los controles que ayudan a asegurar la calidad y coordinar los cambios y las directrices que ayudan a los gestores del software a evaluar el progreso. La ingeniería del software está compuesta por una serie de pasos que abarcan los métodos, las herramientas y los procedimiento antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería del software. La elección de un paradigma para la ingeniería del software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos y herramientas a usar y los controles y entregas requeridos.

19 Paradigmas La ingeniería de software esta compuesta por una serie de pasos de abarcan los métodos, las herramientas y los procedimientos antes mencionados. estos pasos se denominan frecuentemente paradigmas de la ingeniería de software. La elección de un paradigma para la ingeniería de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los controles y entregas requeridos. Gama de paradigmas de la ingeniería de software:

20 Paradigmas

21 Actividades protectoras
Se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación: Seguimiento y control de proyecto de software. Revisiones técnicas formales. Garantía de calidad del software. Gestión de configuración del software. Preparación y producción de documentos. Gestión de reutilización. Mediciones. Gestión de riesgos.

22 Modelos de proceso software
Sommerville define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.” Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Modelos : Codificar y corregir Modelo en cascada Desarrollo evolutivo Desarrollo formal de sistemas Desarrollo basado en reutilización Desarrollo incremental Desarrollo en espiral

23 Codificar y corregir (Code-and-Fix)
Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos: Escribir código. Corregir problemas en el código. Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento. Este modelo tiene tres problemas principales : Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos. Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara. El código es difícil de reparar por su pobre preparación para probar y modificar.

24 Modelo en cascada El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería . Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases: Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.

25 Modelo en cascada Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.

26 Modelo en cascada En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son: Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos. Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases. Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante. Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto. Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos. Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.

27 Desarrollo evolutivo La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

28 Desarrollo evolutivo Existen dos tipos de desarrollo evolutivo:
Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario. Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos. Entre los puntos favorables de este modelo están: La especificación puede desarrollarse de forma creciente. Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software. Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

29 Desarrollo evolutivo Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas: Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema. Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento. Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar. Este modelo es efectivo en proyectos pequeños (menos de líneas de código) o medianos (hasta líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión. Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.

30 Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación). Observaciones sobre el desarrollo formal de sistemas: Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias. Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes. Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

31 Desarrollo formal de sistemas

32 Desarrollo basado en reutilización
Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4 Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1). Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada. Las ventajas de este modelo son: Disminuye el costo y esfuerzo de desarrollo. Reduce el tiempo de entrega. Disminuye los riesgos durante el desarrollo.

33 Desarrollo basado en reutilización
Desventajas de este modelo: Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente. Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.

34 Desarrollo incremental
Mills sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinación del Modelo de Cascada y Modelo Evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

35 Desarrollo incremental
Entre las ventajas del modelo incremental se encuentran: Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento. Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema. Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento. Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos. Algunas de las desventajas identificadas para este modelo son: Cada incremento debe ser pequeño para limitar el riesgo (menos de líneas). Cada incremento debe aumentar la funcionalidad. Es difícil establecer las correspondencias de los requisitos contra los incrementos. Es difícil detectar las unidades o servicios genéricos para todo el sistema.

36 Desarrollo incremental

37 Desarrollo en espiral El modelo de desarrollo en espiral es actualmente uno de los más conocidos y fue propuesto por Boehm . El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de desarrollo se divide en cuatro fases: Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.

38 Desarrollo en espiral El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

39 Desarrollo en espiral