TEMA 2 : Introducción a la ingeniería del software Sistema de información Un Sistema de información es un subsistema dentro de la empresa que permite el uso y las transferencias de información entre los subsistemas y otros de la empresa Componentes de un sistema de información Recursos físicos: documentos, archivos, equipos informáticos, etc. Recursos humanos Reglas: protocolos, normas, etc. Sistema informático Cuando parte o toda la gestión de un sistema informático se realiza con ordenadores Están formados por: Los documentos almacenado en las bases de datos y los fichero informáticos El personal del departamento de informática y los usuarios 1
Tipos: Las normas, métodos y protocolos determinadas por el SO y demás software SI transaccionales: se ocupan de la automatización de las operaciones y transacciones que se realiza en la empresa Actividades que realizan los empleados SI de gestión: se ocupan de Los datos que se manejan en la empresa Su almacenamiento SI de soporte a la decisión: Su misión es ayudar a los directivos y personal con responsabilidad dentro de la empresa en la toma de decisiones estratégicas Para desarrollar estos sistemas informáticos con garantías de éxito, se hace necesario disponer: Tiempo y recursos materiales suficientes (financiación, equipamiento, documentación, ) Evaluación Planificación Equipo de informáticos formados por especialistas en la resolución de los distintos tipos de problemas que el desarrollador plantea. (jefes de proyecto, analistas, programadores, ) Métodos y técnicas de resolución de problemas: que ayudan a afrontar los distintos pasos por los que va a ir pasando el desarrollo del sistema. Ingeniería del software Antecedentes históricos de la Ingeniería del software 1ª Generación 2
Ausencia de una ingeniería del software Desarrollo del software Convencional Directo Apenas elaborado Aplicaciones más o menos planificada pero sin procesos de análisis y diseño 2ª Generación Aparición de las primeras metodologías Metodologías de programación estructuradas Jackson Warnier Metodologías orientadas al ciclo de vida Youdon Constantine El principio que anima este cambio es: Menos énfasis en la programación y más análisis del problema En esta etapa nace algunas técnicas clásicas: Modelado de datos Transiciones entre estados 3ª Generación Paradigma de la Orientación a Objetos Clases Objetos Métodos 3
Atributos Relaciones Programación más intuitivas Más cercana a la realidad Más natural Programación orientada a objetos Análisis orientado a objetos Diseño orientado a objetos Metodologías fundamentales en el desarrollo del software orientado a objetos La de Grady Booch: visión pura de los objetos La de James Rumbaugh y su OMT (Técnica de Modelización de Objetos) La de Ivar Jacobson y su método OOSE (Ingeniería del Software Orientada a Objetos) Recientemente estos tres autores se han unido para desarrollar el UML (Unified Modeling Lenguage) lenguaje gráfico 4ª Generación Viene marcada por la aparición e importancia en el desarrollo de software de las Herramientas CASE (Ingeniería de Software Asistida por Ordenador) Lenguajes de 4ª generación El lema de esta generación podría ser: usar software para desarrollar software dado que las herramientas CASE permiten realizar dentro del ordenador las tareas de análisis y diseño que hasta entonces venían haciéndose con lápiz y papel. Tanto las herramientas CASE como los lenguajes de 4ª generación comparten una aspiración característica de la generación de código aspecto éste que está empezando a hacerse realidad y a cobrar importancia. 4
Ciclo de Vida de desarrollo de software El Ciclo de Vida de una aplicación o proyecto informático es el conjunto de etapas y estados por los que pasa desde que se plantea como necesidad o problema, por parte de un cliente, hasta que se da por terminado y se considera como una solución completa, correcta y estable Especificación de requisitos Se persigue el conocimiento del problema a resolver Características Detalles Limitaciones Son propias de esta etapa las técnicas: Técnicas de las entrevistas 5
Análisis de costes y beneficios Que dan como resultado Estudio de Viabilidad Análisis Se descompone el problema en partes, hasta que se obtiene un conjunto de subproblemas lo suficientemente pequeños y sencillos como para que sean comprendidos y resueltos por una sola persona en un tiempo mínimo El interés se centra en el QUÉ y no en el CÓMO. Lo que interesa es identificar, con el nivel de detalle necesario, las funciones que el sistema debe realizar, sin que sea todavía el momento de escribir el algoritmo que resuelve cada subprograma. El análisis hace énfasis en la identificación de: Funciones Los datos Los eventos Técnicas para el análisis estructurado de procesos son: Diagramas de flujos de datos (DFDs) Especificaciones de procesos elementales (EFSs) Tablas y árboles decisión Diccionario de datos Técnicas para el análisis estructurado de datos son: Diagrama entidad/relación (E/R) Las técnicas para el análisis estructurado de eventos son: Catalogo de Eventos Historia de Vida de Entidades 6
Matriz de entidad/evento Diseño El objetivo es decidir cómo resolver cada uno de los subproblemas identificados por el análisis Cómo integrar todas las soluciones diseñadas en una solución global. El problema de la integración de soluciones parciales en una solución global resalta la importancia en esta etapa de dos aspectos de diseño: Modularidad: es la que hace que una unidad de software sea independiente y diferente del resto del sistema, por la función que realiza. La interfaz: La constituyen los datos de entrada y de salida que éste intercambia con el resto del sistema El diseño de la interface es un aspecto crucial a la hora de integrar las diferentes unidades que formarán parte de la solución final del problema En esta etapa el interés se centra en el CÓMO y no en el QUÉ Lo que interesa es describir, algorítmicamente hablando, cada unidad identifica como solucionadora de una parte o subproblema del proyecto Desde el punto de vista del diseño estructurado de procesos Diagramas de cuadros de Constantine 7
Desde el punto de vista del diseño estructurado de datos Paso a tablas del modelo relacional Implementación Fase de codificación, de la programación de la solución diseñada, en el lenguaje de programación elegido a tal efecto La implementación, a nivel de proceso, supone las técnicas de programación estructurada y modular, que ayudan y guían en el proceso de codificar el programa principal y los diferentes subprogramas que han de componer la aplicación En cuanto a los datos, es el momento de la creación física de las tablas y las consultas que componen la base de datos 8
Pruebas Con esta fase se pretende garantizar el correcto funcionamiento de las aplicaciones programadas, así como su adecuación a los requisitos y necesidades expresados por el cliente Dicho objetivo se plasma en dos aspectos complementarios: Pruebas (técnicas) La verificación de la solución: consiste en comprobar el correcto funcionamiento del código programado La validación de la solución: que persigue asegurar que la aplicación que se ha obtenido es el producto correcto Pruebas unitarias: comprueban el funcionamiento de un componente individual, aislado del resto del sistema Prueba de integración: cuya misión es comprobar que componentes probados individualmente, funcionan correctamente al hacerlos trabajar juntos Pruebas de subsistema y de sistema son pruebas de integración a mayor o menor escala Pruebas de caja negra: hacen hincapié en probar el funcionamiento de un componente software a través de su interfaz, sin entrar a ver su funcionamiento interno. Pruebas de caja blanca: indagan en la forma en que una pieza de software resuelve un determinado problema, atendiendo a los detalles internos de implementación Pruebas de carga: tienen por objetivo comprobar el efecto que sobre el rendimiento de la aplicación ya terminada tiene el uso de datos reales de ejecución, simulando el que será el entorno cotidiano de funcionamiento del sistema. Pruebas de aceptación: se realizan al finalizar esta fase para obtener el visto bueno del cliente sobre la calidad de funcionamiento del sistema desarrollado y probado 9
Instalación y Mantenimiento Consiste en la puesta en funcionamiento del sistema en su entorno real de explotación La instalación obliga a una última batería de pruebas, las pruebas de instalación A pesar de que llegados a esta fase, el proyecto oficialmente se cierra, el mantenimiento supone dejar la puerta abierta a seguir trabajando con el cliente Mantenimiento Corrección de errores, que pueden seguir apareciendo durante un cierto tiempo Mejoras y amplificaciones que el cliente solicite realizar sobre la aplicación Formación de los usuarios del sistema, que puede ser puntual, periódica o permanente Soporte técnico para la resolución de dudas y dificultades en el maejo cotidiano de la aplicación Procesos integrales de gestión del software Paralelamente a todas las etapas del ciclo de vida anteriores, se realizan una serie de actividades que abarcan desde el comienzo hasta el fin Se tratan de tareas complementarias que ayudan a garantizar la integridad y la coherencia de todo desarrollo, así como la terminación y la calidad del proyecto. Son imprescindibles para que el producto final sea fiable y se utilice el máximo de sus capacidades Procesos integrales de gestión del software (tareas) 10
Gestión de cambios: cuando en el desarrollo se produce un cambio, éste se propaga a lo largo de los distintas etapas del ciclo de vida Gestión de configuración: al comienzo del ciclo de vida se define una configuración inicial o básica de los recursos (hardware, software, ) necesarios que va evolucionando a lo largo del desarrollo Gestión de la documentación: agrupa a las actividades dedicadas a planificar, diseñar, editar, producir, distribuir y mantener los documentos necesarios para los desarrolladores y los usuarios Gestión de la calidad: está formada por un conjunto de técnicas y procedimientos que garantizan que el producto que se va construyendo no se aparta de los criterios y estándares de calidad adoptados en la planificación inicial y especificación de requisitos del sistema Tipos de Ciclos de Vida Las etapas de ciclos de vida se pueden entender y llevar a cabo de formas diferentes, según las condiciones concretas de cada proyecto Esto da lugar a distintos tipos de Ciclos de Vida 11
Ciclos de Vida Clásico o en Cascada Fases CV: Definición del problema, que incluye el análisis de requisitos del sistema y de requisitos de software Desarrollo, que abarca el diseño, la programación y las pruebas Mantenimiento Se llama diseño en cascada porque se va pasando de una fase a la siguiente de manera lineal Hasta que una fase no está completamente terminado no se pasa a la siguiente, no existiendo la posibilidad de volver atrás. 12
Ciclo de Vida en Cascada y con vuelta atrás En algunos casos una etapa del CV no puede ser completada del todo por falta de detalles en la definición del problema En esta situaciones, se hace necesario dejar dicha etapa sin terminar y pasar a las siguientes, para regresar más tare a completarla. En otras ocasiones, obligan a modificar otras ya dadas por terminadas y definitivas O bien se descubren errores cometidos en etapas ya superadas 13
Ciclo de Vida basado en prototipos Un prototipo es un modelo evolutivo de la solución software final. Al decir que es un modelo, se señala que el prototipo no es ya la solución, no es el producto que finalmente se obtiene Al decir evolutivo se hace referencia al hecho de que, en sucesivas pasadas, se irá refinando el prototipo para ir adaptándolo a las necesidades del cliente Entro los usos de los prototipos destacan dos situaciones: Aquellos sistemas caracterizados por una intensa interfaz hombre/máquina Prototipos de pantallas o maquetas: muestra la interfaz de la aplicación pero no procesa datos 14
Aquellos otros con una lógica compleja, formados por multitud de procesos interdependientes Prototipos funcionales evolutivos: desarrolla un comportamiento que satisface los requisitos y necesidades que se han entendido claramente Realiza un proceso real de datos, para contrastarlo con el usuario Cuando un prototipo de desarrollo con el sólo propósito de precisar mejor las necesidades del cliente y después no se va a aprovechar ni total ni parcialmente en la implementación del sistema final se habla de un prototipo desechable Para que la construcción de prototipos sea posible se debe contar con la participación activa del cliente y los usuarios, por medio de entrevistas, sesiones de demostración, etc. Ciclo de Vida en Espiral 15
Trata de aunar las ventajas de los modelos anteriores, incorporando además el análisis de riesgos, con lo que ganan importancia los factores económicos Se distribuye en cuatro grandes etapas: Planificación Análisis de riesgos Ingeniería Evaluación Recibe su nombre por la forma circular un creciente en que se va pasando de cada etapa a la siguiente: En cada etapa del CV Cada etapa es más compleja Comprende más trabajo Consume más recursos Está más cerca de la solución final El proceso global de construcción del producto software es claramente evolutivo (a la manera de los prototipos) En cada vuelta del ciclo, este proceso es lineal (como el modelo en cascada) 16
Ventajas del modelo en 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. Qué modelo usar? Existen unos criterios para ayudar a elegir el tipo de ciclo de vida más adecuado a cada proyecto: 17
Si se trata de un problema perfectamente conocido, el que el usuario define claramente los requisitos, y el equipo de desarrollo tiene amplia experiencia en la cuestión, se recomienda un ciclo de vida en cascada Si el desarrollo conlleva muchos riesgos, lo correcto sería elegir un CV en Espiral Si es importante ir probando el producto a medida que se desarrollo para demostrarle al usuario y al cliente su utilidad, se recomienda un CV basado en Prototipos Metodología de desarrollo software Metodologías de desarrollo de software 18
Define un estilo o una forma de guiar el proceso de desarrollo de un proyecto informático La metodología define una estructura jerárquica de pasos a seguir, organizados en fases, módulos, actividades, etapas, etc. Las metodologías dividen el proceso de desarrollo de un producto software en partes, según su CV que sigan o en el que inspiren La metodología lo que hace es detallar y concretar las ideas generales que caracterizan a los CV Cada una de las partes o pasos de una metodología suelen describir: El trabajo a desarrollar en él Los productos a obtener Las técnicas que se aconseja usar para generarlos. Las metodologías también establecen las responsabilidades y funciones de los miembros del equipo de desarrollo las de los clientes futuros usuarios el sistema La finalidad última de las metodologías es facilitar el desarrollo del proyecto, tratando de garantizar el éxito y la calidad de los resultados Trata de trazar un camino repetible que, si es seguido completamente y fielmente conduce de manera predecible a los objetivos buscados Metodologías de desarrollo de software más extendidas Métrica 3 (España) Merisse (Francia) SSADM (Reino Unido) En el campo de desarrollo de software orientado a objetos cabe citar el Proceso Unificado de Modelización (UML), fruto de la unión de esfuerzos de 19
Grady Booch, James Rumbaugh e Ivar Jacobson, que se está alzando como estándar Qué son las herramientas CASE? Son un conjunto de programas y ayudas que dan asistencia durante todos los pasos del Ciclo de Vida de desarrollo de un Software Conjunto de métodos, utilidades y técnicas que facilitan la automatización del CV del desarrollo de sistemas de información, completamente o en alguna de sus fases Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales. Evolución de las herramientas CASE Tecnología CASE 20
Supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información y se plantean los siguiente objetivos: Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones. Simplificar el mantenimiento de los programas Mejorar y estandarizar la documentación Aumentar la portabilidad de las aplicaciones Facilitar la reutilización de componentes software Permitir un desarrollo y un refinamiento visual de las aplicaciones mediante la utilización de gráficos 21