Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Transcripción

1 Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos

2 Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software Ubicación del Proceso del Análisis y expresión de Algortimso dentro de lo que se llama ciclo de vida del software en el desarrollo de sistemas. Metodologia del Análisis y Diseño del Software Prof. Oscar Adolfo Vallejos

3 Ingeniría del Software Definición La Ingeniería del Software es el área de la ciencia Informática que trata el análisis, diseño e implementación de Sistemas de Software. Un conjunto de programas relacionados, orientados a resolver un problema del mundo real que, por su complejidad y tamaño, requieren para su solución un equipo de especialistas. Programación de una Aplicación Tarea individual Ingeniería del Software Desarrollo en equipo Un Sistema de Software se concibe su aplicación durante un tiempo prolongado, con lo que posteriores modificaciones, correcciones o ampliaciones al sistema pueden ser realizadas por un equipo de especialistas diferente del original. Ingeniería del Software se asocia con la existencia de una metodología de producción.

4 Evolución del Software Década de los 50 Orientación por lotes; Distribución limitada; Software a medida. Desde 1960 hasta mediado de los años 70. Multiprogramación, Multiusuario; Tiempo real; Bases de datos; Producción software. Desde mitad de los 70 hasta mitad de los 80. Sistemas distribuidos; Inteligencia empotrada; Hardware de bajo coste; Impacto en el consumidor. Desde mitad de los años 80 hasta nuestros días. Sistemas expertos; Máquinas de I.A; Arquitecturas paralelas.

5 Crisis del Software La crisis del software es una serie de problemas que hacen que el software no alcance las expectativas u objetivos esperados por desarrolladores, gestores, clientes, etc. Problemas fundamentales. La sofisticación del hardware no esta acompañada de la del software. Demanda creciente. Mantenimiento difícil. Problemas de los expertos. Planificación y precios imprecisos. La productividad de la gente del software no se corresponde con la demanda. La calidad muchas veces no es la adecuada. Motivos de estos problemas No hay tiempo para recoger los datos para el proceso de desarrollo. Falta comunicación con el cliente. Calidad cuestionable. Dificultad en el mantenimiento.

6 Fases Genéricas de la IS

7 Ciclo de Vida clásico de un Sistema de Software

8 Ciclo de Vida clásico de un Sistema de Software Análisis y Especificación de requerimientos Objetivo: relevar, documentar y especificar los requerimientos del sistema de software, teniendo especialmente en cuenta el contexto y el enfoque del usuario. Incluye los estudios de factibilidad, riesgo del proyecto y análisis de costo del Sistema.

9 Ciclo de Vida clásico de un Sistema de Software Diseño y Especificación de Sistema Dos niveles de diseño del SS. La concepción de la arquitectura del sistema (definición del soporte físico de contexto y la subdivisión funcional del sistema en módulos. El diseño detallado que refina la especificación de cada uno de los módlos y su interfaz de comunicación intra módulos y con el usuario.

10 Ciclo de Vida clásico de un Sistema de Software Codificación y verificación de los módulos La producción efectiva del código da cada uno de los módulos y la prueba funcional de los mismos con datos que representen la operatoria normal del sistema constituyen el núcleo de esta etapa.

11 Ciclo de Vida clásico de un Sistema de Software Integración y prueba global del Sistema Los módulos desarrollados y probados independientemente deben acoplarse en un sistema único y realizar un prueba funcional con el sistema en su ambiente real, a fin de llegar a la entrega definitiva del sistema al usuario. Relación de la prueba global con el documento de requerimientos inicial.

12 Ciclo de Vida clásico de un Sistema de Software Mantenimiento del Sistema Un concepto de calidad lleva a suponer que una vez desarrollado, el sistema debería ser estable y libre de errores. (El producto que se ha entregado es un producto definitivo y que su tarea ha concluido). Una vez entregado el SS comienza la etapa tal vez más compleja. Los sistemas fallan, se modifican y crecen. Tres aspectos : Errores de la concepción y/o desarrollo del sistema Modificaciones a pedido del usuario Crecimientos de especificaciones iniciales

13 Ciclo de Vida clásico de un Sistema de Software

14 Ciclo de Vida clásico de un Sistema de Software Tiempos y costos requeridos por las etapas del ciclo de vida Los costos dependen del tipo de sistema. Los errores y modificaciones se hacen mas costosos a medida que estamos mas avanzados en el desarrollo de sistema. En la etapa tradicional de programación y prueba, difícilmente se invierta mas del 15% del tiempo y costo de desarrollo. La actividad creativa es el diseño. (25 %). Es imprescindible contar con equipos multidisciplinarios y con gran capacidad de comprensión del ambiente y actividad del usuario en la etapa del análisis de requerimientos. El usuario debe participar efectivamente tanto de la especificación de requerimientos como de pruebas parciales y finales del sistema. La etapa de mantenimiento de los sistemas de software es costosa y de costo creciente en el tiempo (35 %).

15 Ciclo de Vida clásico de un Sistema de Software Especificación, codificación y prueba de algoritmos El costo y el tiempo de la actividad de codificación es relativamente pequeño, dentro de sistemas complejos. Objetivo: desarrollar programas eficientes y verificables. Verificar la corrección controlando el cumplimiento de las especificaciones realizadas. Actualmente se esta haciendo un gran esfuerzo por lograr la automatización en la generación del código.

16 Ciclo de Vida clásico de un Sistema de Software Método de refinamiento sucesivos Primero se modeliza el problema del mundo real. Se analizan las estructura global del sistema y los datos que representan el problema. Se descompone la solución en partes (modularización). Se desarrolla cada uno de los módulos básicos y se los prueba. Si es necesario se sigue refinando cada módulo en sus partes elementales. Desde el punto de vista formativo, el criterio de abstraer lo general y derivar lo particular es muy útil. En la concepción de software de alta productividad muchas veces se utilizan módulos previamente desarrollados (reusabilidad).

17 Ciclo de Vida clásico de un Sistema de Software Noción de paradigma de programación Paradigma procedural (imperativo) Paradigma de Lógica y Funcional Paradigma Orientados a Objetos (?) Paradigmas Orientados a Eventos.

18 Ciclo de Vida clásico de un Sistema de Software El rol del especialista en software Analizar el problema del mundo real, abstrayendo sus requerimientos Diseñar la posible solución de los mismos (c/htas informáticas). Establecer métodos de verificación y prueba de los sistemas de software desarrollados. Mantener los sistemas asimilando las modificaciones y ampliaciones solicitadas por el usuario. Tener capacidad de elección entre los recursos que ofrece la tecnología que sean las mejores para resolver el problema.

19 Ciclo de Vida clásico de un Sistema de Software Aspectos importantes de los Sistemas de Software Cualidades de software que son deseables. Algunas de éstas se aplican tanto al producto como al proceso usado para producir el producto. El usuario quiere que el producto de software sea confiable, eficiente y fácil de usar. El productor del software quiere que sea verificable, mantenible, portable y extensible. El director del proyecto de software quiere que el proceso de desarrollo del software sea productivo y fácil de controlar. Cualidades Externas Versus Internas Las externas son visibles a los usuarios del sistema Las cualidades internas son aquellas que incumben a los que desarrollan el sistema.

20 Cualidades de Producto y de Proceso Cualidades al proceso Requiere una planificación cuidadosa de los datos de prueba del programa antes de comenzar cualquier diseño y desarrollo del sistema, la confiabilidad del producto aumentará. Algunas cualidades, tales como la eficiencia, se aplican a ambos (al producto y al proceso). Un producto se refiere a lo que es entregado al cliente. (perspectiva del cliente). Un Producto no solo es código y manuales, sino, requerimientos, diseño, arquitectura, configuración, etc. (perspectiva del developer) La gestión de configuración es la parte del proceso de producción del software que se ocupa de mantener y controlar la relación entre todas las piezas relacionadas de las diferentes, diversas versiones de un producto.

21 Corrección Un programa es funcionalmente correcto si se comporta de acuerdo a la especificación de las funciones que debería proveer (especificaciones de requerimientos funcionales). La definición de corrección asume que una especificación del sistema está disponible y que es posible determinar sin ambigüedad si el programa satisface o no las especificaciones. Claramente, la corrección es una propiedad conveniente, aconsejable para los sistemas de software. La corrección es una propiedad matemática que establece la equivalencia entre el software y su especificación. La corrección se puede evaluar a través de una variedad de métodos. La corrección también puede ser aumentada usando herramientas adecuadas. Puede ser mejorada usando algoritmos estándar o usando bibliotecas de módulos estándar, en lugar de inventar otros nuevos.

22 Confiabilidad Informalmente, el software es confiable si el usuario puede contar con él. Formalmente, confiabilidad del software es la probabilidad de que el software va a funcionar como debe en un intervalo de tiempo especificado. La corrección es una cualidad absoluta: cualquier desviación de los requerimientos hace que el sistema sea incorrecto, sin tener en cuenta cuan menor o grave sea la consecuencia de la desviación. La noción de confiabilidad es, por otro lado, relativa: si la consecuencia de un error del software no es grave, el software incorrecto puede aún ser confiable. Se espera de los productos de ingeniería que sean confiables. Este es uno de los síntomas más sorprendentes de la inmadurez del campo de la ingeniería de software como una disciplina de ingeniería. [Dijkstra, 1989, el término bug que a menudo usan los ingenieros de software, es falta de profesionalismo]. Los errores de diseño de software son tratados como inevitables. (Se espera que ocurran). La ingeniería de software será una disciplina de la ingeniería sólo cuando podamos lograr confiabilidad del software.

23 Robustez Un producto es robusto si se comporta razonablemente, aún en circunstancias que no fueron previstas en las especificaciones de requerimientos. La robustez es una cualidad difícil de definir; si pudiéramos establecer con precisión lo que deberíamos hacer para conseguir que una aplicación sea robusta, seríamos capaces de especificar su comportamiento razonable completamente. Así, la robustez se convertiría en equivalente a corrección (o confiabilidad, en el sentido de la Figura). La cantidad de código dedicado a robustez depende del área de aplicación. La robustez y la corrección, están plenamente relacionadas, sin una línea divisoria definida entre ellas. Si colocamos un requerimiento en la especificación, su logro se convierte en una cuestión de corrección; si lo dejamos fuera de la especificación, puede convertirse en una cuestión de robustez. Por último, la confiabilidad interviene porque no todos los comportamientos incorrectos indican problemas igualmente graves; algunos comportamientos incorrectos pueden, de hecho, ser tolerados. La corrección, la robustez y la confiabilidad se aplican también al proceso de producción del software.

24 Amigabilidad [User Friendliness] La interfaz con el usuario es un componente importante de la amigabilidad. Por Ej.: un sistema de software embebido [embedded] no tiene una interacción con un usuario humano. En lugar de eso, interactúa con el hardware y quizás otros sistemas de software. En este caso la amigabilidad se refleja en la facilidad con la cual el sistema puede ser configurado y adaptado al ambiente del hardware. En general, la amigabilidad de un sistema depende de la consistencia de las interacciones de su usuario y operador. La corrección y performance, afectan a la amigabilidad. La amigabilidad también es tratada bajo el tema factores humanos. La importante actividad actual de investigación y desarrollo en el área de interacción estándar con el usuario para sistemas de software llevará al desarrollo de sistemas más amigables en el futuro.

25 Verificabilidad Un sistema de software es verificable si sus propiedades pueden ser verificables fácilmente. Por ejemplo, la corrección o la perfomance de un sistema de software, son propiedades que son interesantes de ser verificadas. Diseño modular, práctica de codificación disciplinado y el uso de un apropiado lenguaje de programación, todo esto contribuye a la verificabilidad. La verificabilidad es usualmente una cualidad interna, aunque algunas veces se vuelve una cualidad externa. El alto nivel del estándar de seguridad para un sistema de computadora creíble, requiere de la verificabilidad del kernel del sistema operativo.

26 Maintainability Mantenimiento de software: se referirse a las modificaciones que se hacen a un sistema de software después de su versión inicial. El mantenimiento ha sido usado bug fixing y fue afligente descubrir cuanto esfuerzo se ha gastado en corregir los defectos. Mantenimiento: No es apropiado usarlo con el sofware. 1ro. En esencia es, modificaciones por la evolución del software. 2do. El usar el término mantenimiento con software da una connotación errónea debido a que el software no se desgasta. El costo de mantenimiento excede el 60% del total del costo del software. Para analizar los factores que afectan dichos costos, es necesario dividir el mantenimiento del software en tres categorías: mantenimiento correctivo, adaptativo y perfectivo.

27 Maintainability Mantenimiento correctivo: tiene que hacer en todo aquello que se hace para remover los errores residuales presentes en el producto cuando se liberó, como también los errores introducidos dentro del software durante su mantenimiento. Mantenimientos adaptativo y perfectivo son las fuentes reales de cambio en el software; ellos motivan la introducción de la evolucionabilidad como una calidad fundamental del software y la anticipación del cambio como un principio general que deberá guiar al ingeniero de software. Los costos de mantenimiento adaptativo son cercanas a otro 20% de los costos de mantenimiento mientras que más del 50% es absorbido por el mantenimiento perfectivo. El mantenimiento adaptativo involucra ajustes en la aplicación de cambios en el medio ambiente. Finalmente, el mantenimiento perfectivo involucra cambios en el software para mejorar algunas de estas cualidades.

28 Reusabilidad La reusabilidad está emparentado con la evolucionabilidad. En la evolución del producto, modificamos un producto para construir una nueva versión del mismo producto: en el reuso de un producto, nosotros lo usamos al producto para producir otro producto. La reusabilidad aparece como más aplicable a los componentes de software que a un producto completo pero ciertamente parece posible construir productos que son reusables. Las bibliotecas científicas son los más conocidos componentes reusables. La reusabilidad es difícil de lograr a posteriori, sin embargo, uno debería esforzarse por la reusabilidad cuando los componentes del software son desarrollados. (ADOO, POO). La reusabilidad aplicada en el proceso de software es buena. Los distintos modelos de ciclo de vida hacen también el intento del reuso de los procesos de alto nivel La reusabilidad es el factor clave que caracteriza la madurez del campo industrial. El bajo grado de reusabilidad en el software es un claro indicador que el campo debe evolucionar para conseguir el status de una bien establecida disciplina ingenieril.

29 Portabilidad. El software es portable si puede correr en diferentes ambientes. (plataforma de hardware o un ambiente de software así como un sistema operativo particular). Una forma de conseguir portabilidad dentro de una arquitectura de una máquina es tener un sistema de software que asuma una configuración mínima tan lejos como la capacidad de memoria que es involucrada y use un subconjunto de las facilidades de la máquina que son garantizadas para que estén disponibles sobre todos los modelos de la arquitectura. Necesitamos usar técnicas que permitan que el software determine las capacidades del hardware y que se adapte a ellas. La portabilidad se refiere a la habilidad de correr un sistema sobre diferentes plataformas de hardware. En tanto crezca la relación de dinero gastado sobre las ganancias de software versus hardware, la portabilidad gana más importancia. Para muchas aplicaciones, es importante ser portable a través de los sistemas operativos. O, mirándolo de otra forma, el sistema operativo provee la portabilidad a través de las plataformas de hardware.

30 El ciclo de vida clásico de un Sistema de Software