1 Introducción a la Ingeniería de Software. 2 Concepto de Ingeniería de Sistemas n Concepto de sistema, conjunto de cosas que ordenadamente relacionadas.

Presentación del tema: "1 Introducción a la Ingeniería de Software. 2 Concepto de Ingeniería de Sistemas n Concepto de sistema, conjunto de cosas que ordenadamente relacionadas."— Transcripción de la presentación:

1 1 Introducción a la Ingeniería de Software

2 2 Concepto de Ingeniería de Sistemas n Concepto de sistema, conjunto de cosas que ordenadamente relacionadas entre sí contribuyen a un determinado objeto. De forma recursiva, las partes de un sistema pueden ser consideradas como nuevos sistemas (subsistemas). n Los sistemas informáticos están compuestos por ordenadores y sus periféricos. Entre ellos podemos distinguir dos tipos de subsistemas: u Sistemas Hardware, son los elementos materiales, los que se pueden tocar. u Sistemas Software, los programas que gobiernan el funcionamiento del computador. n El objetivo de los sistemas informáticos es el tratamiento de la información: almacenamiento, elaboración y presentación de datos. De esta forma se automatizan determinadas acciones. n En la concepción del sistema informático no solo se decide el trabajo a realizar, sino también cómo ha de ser utilizado por los usuarios.

3 3 Concepto de Ingeniería del Software n Características del software (lo contrario para el hardware): u No se desgasta ni envejece, y por este motivo no requiere reparaciones ocasionales u Su duplicación es poco costosa, lo caro es el desarrollo u Puede ser modificado fácilmente, tanto que es necesario un control de versiones n La Ingeniería del Software comprende las técnicas y procedimientos ingenieriles para el desarrollo del software. n La IS no se plantea solo una actividad de programación, previamente son necesarias las fases de análisis y diseño y posteriormente la integración y la verificación, incluso el manteniendo cuando el producto ya está en explotación. (CICLO DE VIDA). n Inicialmente la tarea de desarrollo era realizada individualmente por hábiles creativos, de forma poco disciplinada. El trabajo en equipo supone la división y organización del trabajo utilizando metodologías de desarrollo. n En los 70 y los 80 empiezan a usarse herramientas CASE (Computer Aided Software Engineering). En los 90 IPSE e ICASE.

4 4 La crisis del Software n Se produce cuando surge la necesidad de desarrollar aplicaciones software demasiado complejas, a mediados de los 60. n Para superar la crisis: u Aparición de metodologías concretas de desarrollo u Concepción de la Ingeniería del Software como disciplina u Trabajo en equipo y especialización (analistas, programadores,...) n No se ha llegado a una situación estable, sino a una evolución permanente con avances continuos en la IS, forzados por el rápido abaratamiento y aumento de capacidad del hardware.

5 5 Mitos del Software n El hardware es mucho más importante que el software n El software es fácil de desarrollar n El software consiste exclusivamente en programas ejecutables n El desarrollo del software es sólo una labor de programación n Es natural que el software contenga errores

6 6 Formalización del proceso de desarrollo n La ingeniería supone la existencia de procesos bien establecidos para la realización de actividades de desarrollo, construcción, fabricación, etc. n El ciclo de vida es el proceso de desarrollo y mantenimiento del software. Según el modelo elegido se describen un conjunto de actividades para llevar a cabo el ciclo de vida, n Los modelos clásicos: u MODELO EN CASCADA u MODELO EN V n Prácticamente identifican actividades similares y sólo se diferencian en la forma de presentación.

7 7 MODELO EN CASCADA

8 8 n ANÁLISIS, determinar qué debe hacer el software -> especificación n DISEÑO, descomponer y organizar el sistema para que los módulos puedan ser desarrollados por separado n CODIFICACIÓN, escribir el código fuente de cada módulo y realizar sobre ellos las pruebas necesarias n INTEGRACIÓN, combinar todos los módulos y probar el sistema completo antes de pasar a su explotación n MANTENIMIENTO, durante la explotación es necesario realizar cambios ocasionales bien para corregir errores o para introducir mejoras, n Se trata de aislar cada fase de las otras, lo que facilita la especialización de los desarrolladores. Al final de cada fase se requiere un proceso de revisión`para evitar que los errores se propaguen a fases posteriores provocando la vuelta atrás.

9 9 MODELO EN CASCADA AMPLIADO

10 10 MODELO EN CASCADA n Cada fase debe generar una información de salida precisa y suficiente: u DOCUMENTOS DE REQUISITOS DEL SOFTWARE (SRD), es una especificación precisa y completa a partir de los requisitos establecidos por el cliente. u DOCUMENTO DE DISEÑO DEL SOFTWARE (SDD),descripción de la estructura global del sistema, especificación de qué debe hacer cada uno de los módulos y de cómo se combinan. u CÓDIGO FUENTE, el programa debidamente comentado (documentación interna). u SISTEMA SOFTWARE, el ejecutable producto dela fase de integración y la documentación de las pruebas realizadas. u DOCUMENTOS DE CAMBIOS, después de cada modificación realizada en la fase de mantenimiento: problema detectado y solución adoptada

11 11 MODELO EN V

12 12 MODELO EN V AMPLIADO

13 13 MODELO EN V n Incluye fases similares a las del modelo en cascada pero de forma jerárquica. En horizontal se representa el avance en el desarrollo y en vertical el nivel de detalle. n VERIFICACIÓN, comprobación de que una parte del sistema cumple con sus especificaciones. n VALIDACIÓN, comprobación de que un elmento satisface las necesidades del usuario identificadas durante el análisis.

14 14 PROTOTIPOS n En los modelos clásicos se insiste en las actividades de revisión de resultados al final de cada fase para evitar la vuelta atrás, que no se contempla de una forma organizada y resulta muy costosa. Están orientados a una forma de desarrollo lineal. n PROTOTIPO, es un sistema auxiliar que permite probar experimentalmente soluciones parciales a los requisitos del sistema n Para que el coste de desarrollo del prototipo sea bajo en relación al del sistema final podemos: u Limitar las funciones u Limitar su capacidad u Limitar su eficiencia u Evitar limitaciones de diseño, utilizando un hardware más potente que el que ejecutará el sistema final u Reducir la parte a desarrollar

15 15 PROTOTIPOS RÁPIDOS n Su finalidad es solo adquirir experiencia, no se aprovechan como producto (usar y tirar). Se denominan maquetas cuando su funcionalidad o capacidad es muy limitada. n El sistema final se codifica totalmente partiendo de cero, no se aprovecha el código del prototipo n Lo importante de estos prototipos es que se desarrollen en poco tiempo.

16 16 PROTOTIPOS RÁPIDOS

17 17 PROTOTIPOS EVOLUTIVOS n En este caso se intenta aprovechar al máximo el código del prototipo, y para ello se emplea el mismo hardware/software del sistema final. n Se realizan fases de análisis y diseño parcial, que se van ampliando hasta construir el sistema final mediante adiciones sucesivas. n Se puede considerar un modelo en cascada en bucle, de manera que en cada iteración se va avanzando en el desarrollo. n HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, se emplean lenguajes de 4ª generación, que son de alto nivel y de tipo declarativo. También se emplean lenguajes de especificación, como VDM y Z. Si disponemos del compilador correspondiente podemos obtener automáticamente el código del prototipo. n En el desarrollo de prototipos es clave la reutilización de software.

18 18 PROTOTIPOS EVOLUTIVOS

19 19 MODELO EN ESPIRAL n Puede considerarse como un refinamiento del modelo evolutivo general que introduce el análisis de riesgo como elemento fundamental para guiar la evolución del proceso de desarrollo. n En la dimensión radial se representa el esfuerzo realizado en el desarrollo (siempre creciente) n En cada iteración 4 fases: u PLANIFICACIÓN, determina que parte del desarrollo se abordará en ese ciclo. u ANALISIS DE RIESGO, evaluar diferentes alternativas para esa parte del desarrollo seleccionando la más ventajosa y tomando precauciones para evitar los posibles inconvenientes. u INGENIERÍA, las actividades de los modelos clásicos u EVALUACIÓN, se analizan los resultados de la fase de ingeniería.

20 20 MODELO EN ESPIRAL

21 21 MANTENIMIENTO DEL SOFTWARE n El mantenimiento no representa una actividad específica, sino que consiste en rehacer parte de las actividades correspondientes a las otras fases del desarrollo para introducir cambios sobre una aplicación ya en fase de explotación. n MANTENIMIENTO CORRECTIVO, su finalidad es corregir errores que no fueron detectados en el desarrollo del producto. n MANTENIMIENTO ADAPTATIVO, modificar una aplicación para adaptarla a las nuevas necesidades del entorno. n MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo versiones mejoradas del producto

22 22 GESTIÓN DE CAMBIOS n El mantenimiento supone la realización de una serie de cambios sucesivos n Si afectan a la mayor parte del sistema se puede plantear como un nuevo desarrollo. n Cada cambio debe ser documentado con: u INFORME DEL PROBLEMA, que ocasiona el cambio. Suele ser propuesto por el cliente. u INFORME DE CAMBIO, describe la solución dada al problema y el cambio realizado n REINGENIERÍA, es necesaria cuando el desarrollo de una aplicación no está documentado y se dispone solamente del código. Se llama también ingeniería inversa porque supone reconstruir y documentar las fases de análisis y diseño llegando a la estructura modular de la aplicación y las dependencias entre módulos y funciones. Estas actividades organizan y documentan un sistema deficiente.

23 23 GARANTÍA DE CALIDAD n Para evaluar la calidad son necesarias técnicas de aplicación de métricas precisas tanto sobre los productos software como a sus procesos de desarrollo. n McCall propone un esquema basado en valoraciones a 3 niveles: u FACTORES, valoración significativa de la calidad en base a los criterios establecidos u CRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidad u MÉTRICAS, mediciones puntuales de determinadas características del producto. n Entre los factores de calidad tenemos: u CORRECCIÓN, grado en que cumple con las especificaciones u FIABILIDAD, grado de ausencia de fallos u EFICIENCIA, reilación entre la cantidad de resultados y los recursos requeridos u SEGURIDAD, dificultad para el acceso a datos por personas no autorizadas u FACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la aplicación u MANTENIBILIDAD. Facilidad para corregir el producto en caso necesario. u FLEXIBILIDAD, facilidad para modificar el producto u FACILIDAD DE PRUEBA, depende del esfuerzo requerido para comprobar su corrección o fiabilidad u TRANSPORTABILIDAD, facilidad para adaptar el producto a otra plataforma u REUSABILIDAD, facilidad para usar partes del producto en otros desarrollos u INTEROPERATIVIDAD, facilidad del producto para trabajar con otros

24 24 PLAN DE GARANTÍA DE CALIDAD (SQAP) n Es un documento formal para organizar el proceso de desarrollo software de manera que se asegure la calidad del producto final. Debe contemplar: u Organización, dirección y seguimiento de los equipos de desarrollo u Modelo de ciclo de vida a seguir, detallando fases y actividades u Documentación requerida, determinando contenido y guión de cada documento u Revisiones y auditorias, para garantizar que las actividades y los documentos son correctos u Organización de las pruebas, a distintos niveles u Organización de la etapa de mantenimiento, determinando cómo gestionar la realización de cambios

25 25 REVISIONES n Consiste en inspeccionar el resultado de una actividad para determinar si es aceptable o contiene defectos que han de ser subsanados. n Las revisiones deben ser formalizadas y contempladas en el modelo de ciclo de vida: u Deben ser realizadas por un grupo de personas y no individualmente u El grupo de be ser reducido u Debe ser imparcial, nada que ver con los desarrolladores u Se debe revisar el producto, pero no el productor ni el proceso de producción u Se debe establecer de antemano una lista formal de comprobaciones u Se debe levantar acta de la reunión de revisión, recogiendo las decisiones tomadas

26 26 PRUEBAS n Consiste en hacer funcionar el producto o una parte de él y comprobar si los resultados son correctos. n No permite garantizar la calidad del producto. En general no es posible probar un producto de forma exhaustiva, debido a su complejidad.

27 27 GESTIÓN DE CONFIGURACIÓN n CONFIGURACIÓN, disposición de las partes que componen una cosa y le dan su peculiar figura. n La CONFIGURACÏÓN SOFTWARE se refiere a la manera en que diversos elementos se combinan para construir un producto software. n Se han de combinar todos los elementos que intervienen en el desarrollo: u Documentos del desarrollo u Código fuente u Programas, datos y resultado de las pruebas u Manuales de usuario u Documentos de mantenimiento, informes de problemas y cambios u Prototipos intermedios u Normas particulares del proyecto n Dado que los elementos software van evolucionando a lo largo del desarrollo se requiere: u Control de versiones, almacenar de forma organizada las sucesivas versiones de cada elemento de la configuración. u Control de cambios, garantizar que las diferentes configuraciones del software se componen de elementos compatibles entre sí (línea base).

28 28 NORMAS Y ESTÁNDARES n IEEE, Institute of Electrical and Electronics Engineer de USA [IEEE93] n DoD, Departament od Defense de USA [DoD88] n ESA, Agencia Europea del Espacio [ESA91] n ISO, organismo internacional de normalización (International Standars Organization). En España AENOR. n METRICA-2, desarrollada por el Consejo Superior de Informática del MAP. Se basa en la metodología de análisis y diseño de Yourdon/DeMarco.