INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE Javier Martín Centro Asociado de Móstoles / Tres Cantos UNED

Introducción • JAVIER MARTIN (jmartin@escet.urjc.es) • TUTORIAS: JUEVES/VIERNES de 7 a 9 • PLAN DE TRABAJO • Exposición de los temas y mediante transparencia, abundando en los puntos más importantes. • Resolución de dudas • Propuesta y resolución de ejercicios y problemas INGENIERÍA DEL SOFTWARE Javier Martín

Temas • INTRODUCCIÓN • ESPECIFICACIÓN DEL SOFTWARE • FUNDAMENTOS DEL DISEÑO SOFTAWARE • TÉCNICAS GENERALES DE DISEÑO SOFTWARE • CODIFICACIÓN Y PRUEBAS • AUTOMATIZACIÓN Y PROCESO DE DESARROLLO INGENIERÍA DEL SOFTWARE Javier Martín

Tema 1: INTRODUCCIÓN INGENIERÍA DEL SOFTWARE Javier Martín

Concepto de Ingeniería de Sistemas • 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). • Los sistemas informáticos están compuestos por ordenadores y sus periféricos. Entre ellos podemos distinguir dos tipos de subsistemas: • Sistemas Hardware, son los elementos materiales, los que se pueden tocar. • Sistemas Software, los programas que gobiernan el funcionamiento del computador. • 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. • 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. INGENIERÍA DEL SOFTWARE Javier Martín

Concepto de Ingeniería del Software • Características del software (lo contrario para el hardware): • No se desgasta ni envejece, y por este motivo no requiere reparaciones ocasionales • Su duplicación es poco costosa, lo caro es el desarrollo • Puede ser modificado fácilmente, tanto que es necesario un control de versiones • La Ingeniería del Software comprende las técnicas y procedimientos ingenieriles para el desarrollo del software. • 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). • 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. • En los 70 y los 80 empiezan a usarse herramientas CASE (Computer Aided Software Engineering). En los 90 IPSE e ICASE. INGENIERÍA DEL SOFTWARE Javier Martín

La crisis del Software • Se produce cuando surge la necesidad de desarrollar aplicaciones software demasiado complejas, a mediados de los 60. • Para superar la crisis: • Aparición de metodologías concretas de desarrollo • Concepción de la Ingeniería del Software como disciplina • Trabajo en equipo y especialización (analistas, programadores, ...) • 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. INGENIERÍA DEL SOFTWARE Javier Martín

Mitos del Software • El hardware es mucho más importante que el software • El software es fácil de desarrollar • El software consiste exclusivamente en programas ejecutables • El desarrollo del software es sólo una labor de programación • Es natural que el software contenga errores INGENIERÍA DEL SOFTWARE Javier Martín

Formalización del proceso de desarrollo • La ingeniería supone la existencia de procesos bien establecidos para la realización de actividades de desarrollo, construcción, fabricación, etc. • 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, • Los modelos clásicos: • MODELO EN CASCADA • MODELO EN V • Prácticamente identifican actividades similares y sólo se diferencian en la forma de presentación. INGENIERÍA DEL SOFTWARE Javier Martín

MODELO EN CASCADA INGENIERÍA DEL SOFTWARE Javier Martín

MODELO EN CASCADA • ANÁLISIS, determinar qué debe hacer el software -> especificación • DISEÑO, descomponer y organizar el sistema para que los módulos puedan ser desarrollados por separado • CODIFICACIÓN, escribir el código fuente de cada módulo y realizar sobre ellos las pruebas necesarias • INTEGRACIÓN, combinar todos los módulos y probar el sistema completo antes de pasar a su explotación • MANTENIMIENTO, durante la explotación es necesario realizar cambios ocasionales bien para corregir errores o para introducir mejoras, • 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. INGENIERÍA DEL SOFTWARE Javier Martín

MODELO EN CASCADA AMPLIADO INGENIERÍA DEL SOFTWARE Javier Martín

MODELO EN CASCADA • Cada fase debe generar una información de salida precisa y suficiente: • DOCUMENTOS DE REQUISITOS DEL SOFTWARE (SRD), es una especificación precisa y completa a partir de los requisitos establecidos por el cliente. • 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. • CÓDIGO FUENTE, el programa debidamente comentado (documentación interna). • SISTEMA SOFTWARE, el ejecutable producto dela fase de integración y la documentación de las pruebas realizadas. • DOCUMENTOS DE CAMBIOS, después de cada modificación realizada en la fase de mantenimiento: problema detectado y solución adoptada INGENIERÍA DEL SOFTWARE Javier Martín

MODELO EN V INGENIERÍA DEL SOFTWARE Javier Martín

MODELO EN V AMPLIADO INGENIERÍA DEL SOFTWARE Javier Martín

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. INGENIERÍA DEL SOFTWARE Javier Martín

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 INGENIERÍA DEL SOFTWARE Javier Martín

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. INGENIERÍA DEL SOFTWARE Javier Martín

PROTOTIPOS RÁPIDOS INGENIERÍA DEL SOFTWARE Javier Martín

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. INGENIERÍA DEL SOFTWARE Javier Martín

PROTOTIPOS EVOLUTIVOS INGENIERÍA DEL SOFTWARE Javier Martín

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. INGENIERÍA DEL SOFTWARE Javier Martín

MODELO EN ESPIRAL INGENIERÍA DEL SOFTWARE Javier Martín

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 INGENIERÍA DEL SOFTWARE Javier Martín

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. INGENIERÍA DEL SOFTWARE Javier Martín

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 INGENIERÍA DEL SOFTWARE Javier Martín

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 INGENIERÍA DEL SOFTWARE Javier Martín

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 INGENIERÍA DEL SOFTWARE Javier Martín

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. INGENIERÍA DEL SOFTWARE Javier Martín

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). INGENIERÍA DEL SOFTWARE Javier Martín

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. INGENIERÍA DEL SOFTWARE Javier Martín

Tema 2: ESPECIFICACIÓN DE SOFTWARE INGENIERÍA DEL SOFTWARE Javier Martín

MODELADO DE SISTEMAS • El análisis y la definición de los requisitos debe dar lugar a la especificación software, en la que se concretan las necesidades que se desean cubrir y se fijan las restricciones con las que debe trabajar el software. • El modelado de los sistemas tiene como objetivo entender mejor el comportamiento requerido y facilitar la comprensión de los problemas planteados. Se trata de establecer modelos conceptuales que reflejen la organización de la información y las diversas transformaciones que se deben llevar a cabo con dicha información. • Las metodologías de análisis de requisitos tratan de facilitara obtención de uno o varios modelos que detallen el comportamiento deseado del sistema. INGENIERÍA DEL SOFTWARE Javier Martín

CONCEPTO DE MODELO • Un modelo conceptual es una abstracción lógico-matemática del mundo real que facilita la comprensión del problema a resolver. Se trata de ofrecer una visión de lato nivel, sin descender a explicar detalles concretos del mismo. Indica QUÉ hace el sistema y no CÓMO lo debe hacer. • Los OBJETIVOS a cubrir con los modelos son: • Facilitar la comprensión de l problema • Establecer un marco para la discusión que simplifique y sistematice el análisis • Fijar las base para el diseño • Facilitar la verificación del cumplimiento de los objetivos del sistema INGENIERÍA DEL SOFTWARE Javier Martín

TÉCNICAS DE MODELADO (I) • DESCOMPOSICIÓN. MODELO JERARQUIZADO, aplica el “divide y vencerás”, y así el problema queda dividido en un subconjunto de subproblemas. Se trata de una descomposición funcional que se denomina horizontal o bien se descompone tratando de detallar la estructura, de forma vertical. Para completar el modelado es necesario establecer los interfaces entre las partes del sistema para posibilitar el funcionamiento del sistema global. • APROXIMACIONES SUCESIVAS, podemos tomar como partida el modelo de un sistema similar, y luego mediante la experiencia del analista y el conocimiento del problema que proporciona el experto se irán proponiendo modelos intermedios, discutiendo sus ventajas e inconvenientes. • EMPLEO DE DIVERSAS ANOTACIONES, el lenguaje natural introduce imprecisiones, repeticiones e incluso incorrecciones en el modelo. Es recomendable emplear notaciones gráficas que sean entendibles por todos los que participan en el proyecto. Se suele recurrir a notaciones precisas que combinan texto, tablas, diagramas y gráficos. INGENIERÍA DEL SOFTWARE Javier Martín

TÉCNICAS DE MODELADO (II) • CONSIDERAR DISITNTOS PUNTOS DE VISTA, en la elaboración del modelo es necesario adoptar un determinado punto de vista. Si así la descripción es insuficiente conviene adoptar más de uno. • REALIZAR UN ANÁLISIS DEL DOMINIO, es decir en campo de aplicación en que se enmarca el sistema a desarrollar. Hay que considerar: • Normativa que afecta al sistema • Otros sistemas semejantes • Estudios recientes en el campo de la aplicación, bibliografía, etc. • Las ventajas de realizar un modelos más general son: • Facilitar la comunicación entre el analista y el usuario del sistema, p.e. usando la misma terminología. • Creación de elementos realmente significativos del sistema, si se ajusta a la normativa específica establecida. • Reutilización posterior del software desarrollado. INGENIERÍA DEL SOFTWARE Javier Martín

ANÁLISIS DE REQUISITOS DE SOFTWARE • El análisis es la fase de definición del futuro sistema y tiene una importancia decisiva en el desarrollo de todas las etapas posteriores. • Con el análisis de requisitos se trata de caracterizar el problema a resolver. El “cliente” trabaja con el analista para elaborar las especificaciones y posteriormente se encargarán de verificar el cumplimiento de las mismas (contrato). • El análisis debe producir un modelo válido necesario y suficiente para recoger todas las necesidades y exigencias del sistema, así como las restricciones que los limiten. Para una especificación correcta se requiere: • Completo y sin omisiones • Conciso y sin trivialidades • Sin ambigüedades • Sin detalles de diseño o implementación • Fácilmente entendible por el cliente • Separando requisitos funcionales u no funcionales (capacidades mínimas y máximas, interfaces estándares, recursos necesarios, seguridad, fiabilidad, mantenimiento, etc. • División y jerarquía del modelo global, con el fin de simplificar su comprensión • Incluyendo los criterios de validación del sistema, para comprobar si se ajusta al contrato inicial. INGENIERÍA DEL SOFTWARE Javier Martín

TAREAS DEL ANÁLISIS • Dependiendo de las características y complejidad del sistema se podrán seguir los siguientes pasos: • ESTUDIO DEL SISTEMA EN SU CONTEXTO, análisis del dominio en un contexto globalizador • IDENTIFICACIÓN DE NECESIDADES, detectar necesidades de medios dentro de plazos y presupuestos • ANÁLISIS DE ALTERNATIVAS Y ESTUDIO DE VIABILIDAD, tanto técnica como económica • ESTABLECIMIENTO DEL MODELO DEL SISTEMA, para lo que podemos usar técnicas gráficas, texto, herramientas CASE, etc. • ELABORACIÓN DEL DOCUMENTO DE ESPECIFICACIÓN DE REQUISITOS, dónde se recogen las conclusiones del análisis y sirve de punto de partida para el diseñador. • REVISIÓN CONTINUADA DEL ANÁLISIS, a menudo en las etapas de diseño e implementación se hace necesaria la revisión de alguno de los requisitos, o bien por cambios de criterio del cliente INGENIERÍA DEL SOFTWARE Javier Martín

NOTACIONES PARA LA ESPECIFICACIÓN • La especificación es una descripción del modelo del sistema a desarrollar. • Se debe usar una notación fácil de entender por el cliente: • Lenguaje natural, utilizando explicaciones más o menos precisas y exhaustivas. Es posible limitar precisiones y ambigüedades si se establecen reglas de uso del lenguaje. • Diagramas de flujo de datos • Diagramas de transición de estados • Descripciones funcionales. Pseudocódigo. Se emplea un preciso lenguaje natural estructurado. No se debe detallar demasiado el cómo, pues esto corresponde a la fase de diseño, donde se usan lenguajes estructurados como PLD. • Descripción de datos, de trata de detallar la estructura interna de los datos que maneja el sistema. En la metodología Yourdon se conoce como diccionario de datos, incluyendo nombre de cada dato, utilización y estructura. • Diagramas de modelos de datos INGENIERÍA DEL SOFTWARE Javier Martín

DIAGRAMAS DE FLUJO DE DATOS (DFD) • Se trata de realizar un modelo gráfico para representar el flujo de datos que entra en el sistema, las transformaciones que debe realizar y la salida producida. También se representan las entidades externas la sistema que producen o consumen datos. El DFD inicial es el de contexto, posteriormente y de forma jerárquica se van desarrollando otros DFD’s que detallan las transformaciones, las entradas y salidas del diagrama detallado deben coincidir con el proceso correspondiente. • Recoge de forma estática los procesos, dónde en el último nivel de refinamiento se especifican en lenguaje natural estructurado, y su interrelación. INGENIERÍA DEL SOFTWARE Javier Martín

DIAGRAMAS DE TRANSICIÓN DE ESTADOS • Describe el comportamiento dinámico del sistema basándose en sus estados más importantes. • Al igual que en los autómatas de estados finitos, los eventos motiva el cambio de estado del sistema. INGENIERÍA DEL SOFTWARE Javier Martín

DIAGRAMAS DE MODELO DE DATOS • Se trata de organizar e interrelacionar los datos que utiliza el sistema. • El MODELO ENTIDAD-RELACIÓN permite definir todos los datos y establecer las relaciones que deben existir entre ellos. INGENIERÍA DEL SOFTWARE Javier Martín

DOC. DE ESPECIFICACIÓN DE REQUISITOS • El documento o la especificación de requisitos (SRD o SRS) recoge de forma integral los resultados del análisis. • Puede haber documentos previos al SRD, como estudios de viabilidad o de alternativas posibles. • El SRD debe ser revisado con cierta frecuencia durante el desarrollo y debe facilitar la varificación de las especificaciones (contrato). • Diversos organismos de estandarización hacen propuestas sobre la estructura del SRD: IEEE, DoD, etc. Vemos el modelo de SRD de la Agencia Espacial Europea. Dependiendo de las características y complejidad del proceso tal vez no sea necesario cubrir todos los apartados. INGENIERÍA DEL SOFTWARE Javier Martín

MODELO DE SRD • Introducción • Objetivo: objetivos, participantes, calendario,... • Ámbito, identificará y dará nombre al producto • Definiciones, siglas y abreviaturas • Referencias, la descripción bibliográfica de los documentos referenciados. • Panorámica del documento • Descripción general • Relación con otros proyectos, similares o complementarios • Relación con proyectos anteriores o posteriores • Objetivo y funciones • Consideraciones de entorno • Relaciones con otros sistemas, que utilicen entradas o salidas indirectas de información • Restricciones generales: metodologías, lenguajes, de hardware,... • Descripción del modelo, es el apartado más extenso y más importante. Se utilizan todas las notaciones y herramientas disponibles INGENIERÍA DEL SOFTWARE Javier Martín

MODELO DE SRD • Requisitos específicos, lista detallada y completa de los requisitos del sistema, indicando su grado de cumplimiento (obligatorio, recomendable, opcional. No incluir aspectos de diseño o desarrollo, ni tampoco soluciones particulares que no sean obligadas • Requisitos específicos, QUÉ debe hacer el sistema especificando el tratamiento de la información. • Requisitos de interfase, conexión con otros sistemas con los que interactúa (bases de datos, ficheros, SSOO,...). • Requisitos de operación, es decir, del interfaz de usuario • Requisitos de capacidad, volumen procesador, tiempo respuesta, tamaño ficheros. Se debe cuantificar para el peor, el mejor y el caso más habitual. • Requisitos de verificación, que debe cumplir el sistema para que se posible verificar su corrección • Requisitos de pruebas de aceptación • Requisitos de recursos, instalaciones y elementos necesarios para el funcionamiento del sistema • Requisitos de documentación • Requisitos de transportabilidad, para adaptalo a otras plataformas • Requisitos de calidad, que no hayan sido recogidos en otros apartados • Requisitos de fiabilidad, imponiendo un límite aceptable de fallos • Requisitos de mantenibilidad • Requisitos de seguridad, contra utilización indebida • Requisitos de salvaguarda, para evitar consecuencias graves en equipos o en personas • APENDICES, para complementar el contenido del documento INGENIERÍA DEL SOFTWARE Javier Martín

VIDEOJUEGO DE LAS MINAS INGENIERÍA DEL SOFTWARE Javier Martín

SISTEMA DE GESTIÓN DE BIBLIOTECA INGENIERÍA DEL SOFTWARE Javier Martín

INGENIERÍA DEL SOFTWARE