Introducción a la Ingeniería de Software (Presentación Powerpoint) (página 2)

12 MODELO EN V 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. VERIFICACIÓN, comprobación de que una parte del sistema cumple con sus especificaciones. VALIDACIÓN, comprobación de que un elmento satisface las necesidades del usuario identificadas durante el análisis.

13 PROTOTIPOS 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. PROTOTIPO, es un sistema auxiliar que permite probar experimentalmente soluciones parciales a los requisitos del sistema Para que el coste de desarrollo del prototipo sea bajo en relación al del sistema final podemos: Limitar las funciones Limitar su capacidad Limitar su eficiencia Evitar limitaciones de diseño, utilizando un hardware más potente que el que ejecutará el sistema final Reducir la parte a desarrollar

14 PROTOTIPOS RÁPIDOS 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. El sistema final se codifica totalmente partiendo de cero, no se aprovecha el código del prototipo Lo importante de estos prototipos es que se desarrollen en poco tiempo.

15 PROTOTIPOS RÁPIDOS

16 PROTOTIPOS EVOLUTIVOS 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. Se realizan fases de análisis y diseño parcial, que se van ampliando hasta construir el sistema final mediante adiciones sucesivas. Se puede considerar un modelo en cascada en bucle, de manera que en cada iteración se va avanzando en el desarrollo. 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. En el desarrollo de prototipos es clave la reutilización de software.

17 PROTOTIPOS EVOLUTIVOS

18 MODELO EN ESPIRAL 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. En la dimensión radial se representa el esfuerzo realizado en el desarrollo (siempre creciente) En cada iteración 4 fases: PLANIFICACIÓN, determina que parte del desarrollo se abordará en ese ciclo. ANALISIS DE RIESGO, evaluar diferentes alternativas para esa parte del desarrollo seleccionando la más ventajosa y tomando precauciones para evitar los posibles inconvenientes. INGENIERÍA, las actividades de los modelos clásicos EVALUACIÓN, se analizan los resultados de la fase de ingeniería.

19 MODELO EN ESPIRAL

20 MANTENIMIENTO DEL SOFTWARE 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. MANTENIMIENTO CORRECTIVO, su finalidad es corregir errores que no fueron detectados en el desarrollo del producto. MANTENIMIENTO ADAPTATIVO, modificar una aplicación para adaptarla a las nuevas necesidades del entorno. MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo versiones mejoradas del producto

21 GESTIÓN DE CAMBIOS El mantenimiento supone la realización de una serie de cambios sucesivos Si afectan a la mayor parte del sistema se puede plantear como un nuevo desarrollo. Cada cambio debe ser documentado con: INFORME DEL PROBLEMA, que ocasiona el cambio. Suele ser propuesto por el cliente. INFORME DE CAMBIO, describe la solución dada al problema y el cambio realizado 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.

22 GARANTÍA DE CALIDAD 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. McCall propone un esquema basado en valoraciones a 3 niveles: FACTORES, valoración significativa de la calidad en base a los criterios establecidos CRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidad MÉTRICAS, mediciones puntuales de determinadas características del producto. Entre los factores de calidad tenemos: CORRECCIÓN, grado en que cumple con las especificaciones FIABILIDAD, grado de ausencia de fallos EFICIENCIA, reilación entre la cantidad de resultados y los recursos requeridos SEGURIDAD, dificultad para el acceso a datos por personas no autorizadas FACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la aplicación MANTENIBILIDAD. Facilidad para corregir el producto en caso necesario. FLEXIBILIDAD, facilidad para modificar el producto FACILIDAD DE PRUEBA, depende del esfuerzo requerido para comprobar su corrección o fiabilidad TRANSPORTABILIDAD, facilidad para adaptar el producto a otra plataforma REUSABILIDAD, facilidad para usar partes del producto en otros desarrollos INTEROPERATIVIDAD, facilidad del producto para trabajar con otros

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

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

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

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

27 NORMAS Y ESTÁNDARES IEEE, Institute of Electrical and Electronics Engineer de USA [IEEE93] DoD, Departament od Defense de USA [DoD88] ESA, Agencia Europea del Espacio [ESA91] ISO, organismo internacional de normalización (International Standars Organization). En España AENOR. 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.