I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón L

Transcripción

1 I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón L REFERE CIA AL SISTEMA EDUCATIVO ACTUAL. Los contenidos de este tema, están enfocados a introducir al alumno en el concepto de Ingeniería del Software. Estos contenidos, según determina el Decreto 132/1995 por el que se establece el currículo del ciclo formativo de grado superior de Desarrollo de Aplicaciones Informáticas, se corresponden al módulo de Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión. Puede ser tomado como tema inicial del módulo porque ofrece una panorámica general del concepto de Ingeniería del Software, el ciclo de vida del software así como las distintas metodologías que se utilizan en el desarrollo de aplicaciones. 1.- I TRODUCCIÓ A LA I GE IERÍA DEL SOFTWARE Software: instrucciones que cuando se ejecutan proporcionan la función deseada. Sus características principales son: a) es intangible, no es algo físico. b) se desarrolla, no se fabrica. El desarrollo implica que hasta que no llegan las fases finales no vemos el resultado. c) el software no se estropea Seguro?: Fallos del hardware en función del tiempo. (Vida normal de cualquier hardware). En un principio la proporción de fallos del hardware 1) es alta debido a defectos en el diseño o en la fabricación. Posteriormente la proporción de fallos se estabiliza 2) y en un plazo más lejano vuelven a aumentar los fallos como consecuencia del deterioro de los componentes 3). Esta es la llamada curva de bañera. Si nos fijamos ahora en los fallos del software en función del tiempo, podemos observar una primera línea que parte de una gran cantidad de fallos 1) debido a fallos en el desarrollo o en el diseño. Después se estabiliza 2) debido a la resolución de los fallos, aunque rápidamente aparecen nuevos fallos tanto en el mantenimiento como en el Fallo s Fallo s 1) 1) 2) 2) 3) 3 ) 3 ) 2 ) 3) Tiempo Tiempo

2 nuevo desarrollo de software 3) que aunque se solucionan, pronto vuelven a aparecer otros que también se solucionan 3 ) 3 )... pero contribuyen al deterioro definitivo del software. En un principio podríamos pensar que la gráfica seguiría la línea 2 ) debido a que el software no se estropea, pero la realidad es, que aunque no se pueda deteriorar físicamente, si lo hace en el ámbito de mantenimiento, siguiendo la pauta de la anterior gráfica que se puede simplificar en la siguiente: Fallo s Tiempo Además, cuando un hardware se estropea, se sustituye por una pieza de repuesto, pero no hay piezas de repuesto para el software. Cada fallo en el software implica errores en el diseño o en el proceso de traducción de ese diseño al código ejecutable, por tanto el mantenimiento del software es mucho más complicado que el del hardware. d) La mayoría del software se construye a medida, es decir, adaptado a las necesidades del cliente en vez de ensamblar componentes existentes. Todavía está por conseguir la reusabilidad del software. Definiciones de Ingeniería del Software: 1) Es la disciplina que intenta obtener productos de calidad del software. 2) Es una disciplina tecnológica-administrativa dedicada a la producción sistemática de productos de programación, que se han desarrollado y modificado a tiempo y dentro de un presupuesto definido. La Ingeniería del Software está compuesta por tres elementos claves: 1- Técnicas ó Métodos: proporcionan las normas a seguir al construir software (MER, DFD, ) 2- Herramientas: sirven de soporte a las técnicas; hoy se habla de Herramientas CASE (ingeniería del software asistida por computadora) como una gran ayuda en el análisis y diseño de aplicaciones. 3- Procedimientos: Definen la secuencia en la que se aplican las técnicas.

3 2.-CO CEPTOS BÁSICOS. Sistema: Conjunto de componentes, que ordenadamente relacionados entre sí, contribuyen a un determinado objetivo. Sistemas de Información: Sistema que me proporciona información para la toma de decisiones. Sistema Informático: Es un sistema de información basado en ordenadores. Aplicación Informática: También llamado proyecto software y es el conjunto de programas que resuelven un determinado problema. Estas aplicaciones se desarrollan siguiendo un esquema que recibe el nombre de ciclo de vida de una aplicación (paradigma). Un sistema informático sería el conjunto de elementos necesarios para la realización y utilización de aplicaciones informáticas. 3.-ETAPAS DEL CICLO DE VIDA DE U A APLICACIÓ I FORMÁTICA. Ciclo de vida se define como el conjunto de fases que transcurren desde que surge la idea de construir una aplicación, hasta que la aplicación deja de tener validez y se desecha. Etapas fundamentales en el ciclo de vida de todo proyecto: PLANIFICACIÓN DESARROLLO MANTENIMIENTO - Planificación: En esta fase se hace imprescindible conocer el sistema de información o informático, en el que va a estar inmerso el software que voy a desarrollar, determinar los objetivos a cumplir, definir un plan de acción (proyecto a desarrollar y calendario que se va a seguir), evaluar los recursos necesarios y determinar un plan de seguimiento con mecanismos de evaluación adecuados. (Técnicas de Análisis Coste/Beneficio) - Desarrollo: Se divide en cuatro etapas: Análisis: Consiste en responder a la siguiente pregunta: Qué es lo que tenemos que hacer? Se trata de conocer los datos a manejar, el conjunto de entradas que necesita el sistema, el conjunto de salidas que van a producirse y los procesos que

4 tengo que implantar. Siempre dependiendo de las especificaciones marcadas por el cliente. (MER,MR,DFD) Diseño: Consiste en responder a la siguiente pregunta: Cómo lo tenemos que hacer? Se trata de cómo los programas van a conseguir los objetivos con los datos disponibles. (DE,DTE) Codificación: Consiste en traducir los resultados del diseño a un lenguaje de programación. Pruebas: Consiste en verificar y validar la solución obtenida. Existen pruebas unitarias, que comprueban el funcionamiento de cada componente individual y pruebas de integración que comprueban que componentes probados individualmente funcionan bien de forma conjunta. - Mantenimiento: aquí me pregunto cómo se gestiona el cambio una vez que el sistema está en explotación. Mantenimiento Correctivo: Consiste en la corrección de errores que aparezcan con el uso normal de los programas. Mantenimiento Adaptativo: Consiste en modificar los programas existentes, a causa de un cambio en el entorno físico y lógico en el que están implantados. Mantenimiento Perfectivo: Consiste en realizar mejoras y ampliaciones que el cliente solicite sobre la aplicación. Los tipos de mantenimiento adaptativo y perfectivo reinician el ciclo de vida. 4.-TIPOS DE CICLO DE VIDA DE U A APLICACIÓ I FORMÁTICA. Ciclo de Vida Clásico También es llamado ciclo de vida en cascada o "modelo de ciclo de vida tradicional". Consiste en ir desarrollando cada una de las etapas secuencialmente, hasta la fase de implantación del sistema. En este tipo de ciclo hay que esperar a que termine una etapa para poder empezar la siguiente. Definición Análisis Diseño Codificación Prueba Mantenimiento

5 Este ciclo de vida está anticuado y es muy criticado porque no tiene vuelta atrás, no se ve el producto hasta la etapa final (el usuario debe tener mucha paciencia) y tampoco posibilita la realimentación. La secuencialidad no es real. Ciclo de Vida en cascada con vuelta atrás Introduce mejoras al ciclo anterior. Definición Análisis Diseño Codificación Prueba Mantenimiento Este es el ciclo de vida más conocido y experimentado. En muchos casos, una etapa del CV no puede ser completada del todo por falta de detalles en la definición del problema. En estas situaciones, se hace necesario dejar dicha etapa sin terminar y pasar a las siguientes, para regresar más tarde a completarla. En otras ocasiones, las decisiones tomadas en etapas posteriores obligan a modificar otras ya dadas por terminadas y definitivas. O bien se descubren errores en etapas ya superadas. Este ciclo contempla la posibilidad de volver atrás desde cualquier etapa. También se le llama ciclo de realimentación. Ciclo de Refinamiento de Prototipos FINAL Producto ingeniería Recogida y refinamiento de requisitos COMIENZO Refinamiento prototipo Diseño rápido Evaluación prototipo Construcción prototipo

6 Entendemos por prototipo un modelo evolutivo de la solución software final. Poco a poco se irá refinando para adaptarlo a las necesidades del proyecto. Dentro de los inconvenientes de este ciclo encontramos: - Posible incorporación al producto final de deficiencias asumidas en la construcción del prototipo, ya que se continúa a partir del prototipo y no se empieza de nuevo. - Ralentiza el proceso de desarrollo. - Se debe contar con la participación activa del cliente, mediante entrevistas, sesiones de demostración,...etc. Ventajas: - Genera un producto más seguro, en cuanto a satisfacción de las necesidades del cliente. Ciclo de Vida en Espiral Trata de aunar las ventajas de los modelos anteriores, incorporando el análisis de riesgos, con lo que ganan importancia los factores económicos del proyecto. Se distribuye en 4 etapas: Planificación, análisis de riesgos, ingeniería y evaluación. Recibe su nombre por la forma circular y creciente en que se va pasando de cada etapa a la siguiente: en cada vuelta del CV cada etapa es más compleja, comprende más trabajo y consume más recursos (tiempo, dinero,...), pero está más cercana a la solución final. De esta manera el proceso global de construcción del producto software es claramente evolutivo (a la manera de los prototipos), mientras que en cada vuelta del ciclo, este proceso es lineal (como el modelo en cascada). Aquí el proyecto se comienza desde el primer instante, no como en el de prototipos. Planificación Análisis de riesgo Evaluación del cliente Ingeniería El análisis de riesgo es una etapa donde nos preguntamos si es conveniente seguir con el proyecto. Esto suele producirse a partir de la segunda versión.

7 En general: Si el problema es perfectamente conocido, en el que el usuario define claramente los requisitos, y el equipo de desarrollo tiene amplia experiencia en la cuestión Si el desarrollo conlleva muchos riesgos Si es importante ir probando el producto a medida que se desarrolla para demostrarle al usuario y al cliente su utilidad CV en cascada CV en espiral CV basado en prototipos En la vida real, no se da ninguna de estas situaciones en estado puro, sino mezcladas entre sí. Por este motivo, el criterio y la experiencia de los jefes de proyecto y de los analistas son cruciales para realizar una buena elección del tipo de ciclo de vida a seguir. 5.-METODOLOGÍAS DE DESARROLLO DE SOFTWARE. Definimos metodología como un conjunto de pasos y procedimientos, que deben seguirse para el desarrollo del software. Los enfoques metodológicos han ido evolucionando a lo largo del tiempo. Inicialmente se identifica un período de desarrollo convencional, durante el cual las prácticas de desarrollo eran totalmente artesanales y en el que no había metodologías definidas, lo que acarreaba multitud de problemas. Posteriormente surge el desarrollo estructurado partiendo de la programación estructurada y que sigue con los métodos de análisis y diseño estructurado, hasta llegar a metodologías estructuradas que cubren el ciclo de vida completo. En la actualidad aparece el paradigma de la orientación a objetos, como un nuevo enfoque en la ingeniería del software. Desarrollo Convencional: en los años 50, no existían metodologías de desarrollo. Las personas que desarrollaban los sistemas eran programadores más enfocados en la tarea de codificar, que en la de recoger y comprender las necesidades de los usuarios. Estos, a menudo, no quedaban satisfechos con el sistema, porque sus necesidades no estaban definidas con claridad en una fase de análisis previo. Ante esta perspectiva se vio la importancia del análisis y del diseño en el desarrollo de un sistema. Ahora se empieza a hablar de analistas programadores y analistas de sistemas. Problemas: 1) Los resultados finales son impredecibles. 2) No hay forma de controlar lo que está sucediendo en el proyecto. El director de proyecto, al no existir fases establecidas y productos intermedios concretos sobre los que realizar verificaciones, no puede saber cuál es el estado actual del proyecto; lo que influye en su toma de decisiones.

8 Esto lleva también a una detección tardía de defectos, que se pueden presentar cuando se está probando el código o aún peor, cuando el sistema ya esté en explotación, con lo que los costes se disparan. Para controlar lo que está sucediendo en un proyecto, es necesario establecer puntos de control donde se verifique que el desarrollo avanza de forma adecuada; donde se confirme que los defectos detectados son corregidos y que en su corrección no se produzcan nuevos errores. 3) Falta de documentación estandarizada y actualizada adecuadamente. Desarrollo Estructurado: el nacimiento de las técnicas estructuradas se puede considerar un punto de partida en el que se pasa de la construcción de programas de forma artesanal, a una que sigue unos métodos de ingeniería, sentando las bases para un desarrollo automatizado (herramientas CASE). - Programación Estructurada: el enfoque de desarrollo estructurado comenzó con la programación para determinar como se debía ver un programa de forma que fuera lo más comprensible posible. Empieza a usarse a finales de los 60. Consiste en establecer normas para la aplicación de las estructuras de datos y de control. Tipos de estructuras de control: secuencial, repetitiva (bucle), y alternativas. Tipos de estructuras de datos: vectorial, matricial, listas,... - Diseño Estructurado: a mediados de los 70, el enfoque estructurado se extiende a la fase de diseño. Se define un nivel de abstracción más amplio utilizando el módulo de programa como componente básico de construcción. - Análisis Estructurado: hasta la aparición de los primeros conceptos sobre el análisis estructurado, en la mayoría de los proyectos se hacía una especificación narrativa de los requisitos tal y como los percibía el analista. Estas especificaciones tenían varios problemas: (1) Eran monolíticas, es decir había que leer la especificación de requisitos completamente para poder entenderla. (2) Eran redundantes, es decir, frecuentemente se repetía la misma información en partes diferentes del documento. Esto implica que si se cambia algún requisito del usuario, se debía modificar dicha especificación en varios lugares, para evitar inconsistencias. (3) Eran ambiguas, es decir, un informe detallado de los requisitos se interpretaba de forma diferente por usuarios, analistas y diseñadores, por esto se produce un movimiento gradual hacia las especificaciones funcionales gráficas (aquellas compuesta por variedad de diagramas, apoyados con técnicas textuales detalladas, que sirven de referencia a la especificación. Ej: diagrama de flujo de datos), particionadas (aquellas que permiten que se puedan leer porciones independientes de la especificación) y mínimamente redundantes. Este enfoque se conoce como análisis estructurado o también análisis descendente o Top-Down. Desarrollo Orientado a Objetos: el paradigma orientado a objetos, a diferencia del enfoque estructurado trata los procesos y los datos de forma conjunta, es decir, modulariza tanto la información como el procesamiento. La orientación a

9 objetos empieza con los lenguajes de programación orientados a objetos; en estos lenguajes los problemas del mundo real se representan como un conjunto de objetos para los que se adjuntan un conjunto de operaciones. Ej: C++, Java. En España, la metodología utilizada en la Administración pública es METRICA V3 ( También existen otras para distintos países de Europa como MERISSE en Francia y SSADM en el Reino Unido.