Ingeniería de Requerimientos

Transcripción

1 Ingeniería de Estableciendo lo que el cliente requiere de un Sistema de Software. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 1 Objetivos Introducción a la Noción de Ingeniería de. Explicación de los diferentes niveles de detalle de requerimientos que se necesiten. Describir como deben ser organizados los documentos de un Sistema de. Describir la validación del Proceso de. Explicar porque los se involucran durante el tiempo de vida de un sistema. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 2 1

2 Tópicos El Proceso de Ingeniería de Los Documentos de de software Validación de Evolución de Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 3 Ingeniería de El proceso de establecer los servicios que el cliente requiere de un sistema y los limites bajo los cuales opera y se desarrolla. Los pueden ser Funcionales o No- Funcionales Los funcionales describen servicios o funciones Los No-funcionales son un límite en el sistema o en el proceso de desarrollo. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 4 2

3 Qué es un Requerimiento? Es un rango de instrucciones abstractas de alto nivel de un servicio ii o de un sistema, it limitado itd a detallar dtll una especificación funcional matemática. Así es inevitable como los pueden servir en una función dual Puede ser la base para una declaración de un contrato, por lo tanto, deber estar abierto a interpretación. Puede ser la base para el contrato en sí, por lo tanto, debe ser definido en detalle. Ambas declaraciones serán llamadas. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 5 Definición/Especificación Definición de Una declaración en un Lenguaje Natural incluye los diagramas de los servicios del sistema y sus límites operacionales. Escrito para clientes. Especificación de Un documento estructurado con descripción o detalle de los servicios del sistema. Escrito como un contrato entre el cliente y el contratista. Especificación de Software Descripción detallada de software, la cual, puede servir como una base para diseño o implementación. Escrito para desarrolladores. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 6 3

4 Definiciones y Especificaciones Definición de 1. El Software proporciona significado de representación y acceso a archivos externos creados por otras herramientas. Especificación de 1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos. 1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será aplicada para el archivo. 1.3 Cada tipo de archivo externo será representado como un icono específico mostrado al usuario. 1.4 Las facilidades proporcionadas para la representación del icono en un tipo de archivo externo será definido por el usuario. 1.5 Cuando un usuario selecciona una representación de icono de un archivo externo, el efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo externo al archivo representado por la selección del icono. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 7 Lectores de Definición de Gerencia de Cliente Usuarios Finales del Sistema Ingenieros de Clientes Gerencia de Contratistas Arquitectos del Sistema Especificación de Usuarios Finales del Sistema Ingenieros de Cliente Arquitectos del Sistema Desarrolladores de Software Especificación de Software (Quizá) Ingenieros de Clientes Arquitectos del Sistema Desarrolladores de Software Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 8 4

5 Problemas Desagradables Sistemas de Software grandes con problemas de direccionamiento. i i Problemas de tal manera complejos que puede ser que nunca se comprendan completamente y donde los desarrolladores van comprendiendo el sistema durante su desarrollo Por lo tanto, los requerimientos i son normalmente incompletos e inconsistentes. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 9 Razones de Inconsistencia Los sistemas de software grandes deben mejorar su actual situación. Es difícil anticipar los efectos que el sistema tendrá en la organización. Usuarios diferentes tienen requerimientos y prioridades diferentes. Hay constantemente compromiso de cambios en los requerimientos. Los usuarios finales del sistema s y la organización que paga por el sistema tienen requerimientos diferentes. El prototipado es requerido para clarificar requerimientos Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 10 5

6 Proceso de Ingeniería de Estudio de Factibilidad Encuentran los usuarios actuales que sus necesidades d son satisfechas dada la tecnología y el presupuesto disponible? Análisis de Encontrar que el sistema requiere del mantenimiento de intereses. Definición de Definir los requerimientos en una forma comprensible para el cliente. Especificación de Define los requerimientos en detalle. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 11 El Proceso de Ingeniería de Estudio de Factibilidad Análisis de Reporte de Factibilidad Definición de Modelos del Sistema Especificación de Documento de Definición de Especificación de Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 12 6

7 Documento de Es la declaración oficial de lo que es requerido para que el sistema sea desarrollado. d Incluye la definición y especificación de requerimientos. No es un documento de diseño. Tanto como sea posible, es un conjunto de lo que es el sistema y como lo hará. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 13 del Documento de Especificación de la conducta externa del sistema. it Especificar los límites de la implementación. Fácil de cambiar. Sirve como una herramienta de referencia para mantenimiento. Recuerda el ciclo de vida del sistema, esto es, predice cambios. Proporciona respuestas características a un evento no esperado. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 14 7

8 Estructura del Documento de Introducción. Describe la necesidad d de crear el sistema y cuales son sus objetivos. Glosario. Define los términos técnicos usados. Modelos del Sistema. Define los modelos que muestran los componentes del sistema y las relaciones entre ellos. Definición de Funcionales. Define los servicios que serán proporcionados. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 15 Estructura del Documento de Definición de No-funcionales. Definir las limitantes del sistema y el proceso de desarrollo. Evolución del Sistema. Definir las suposiciones fundamentales en las cuales el sistema se basa y se anticipan los cambios. Especificación de. Especificación detallada de los requerimientos funcionales del sistema. Apéndices. Descripción de la plataforma de Hardware del Sistema. de la base de Datos (quizá como un modelo ER) Indice. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 16 8

9 Identificación de Requisitos Preguntar al cliente, a los usuarios y a los que están involucrados en los objetivos del sistema o producto y sean expertos, investigar como los sistemas o productos se ajustan a las necesidades del negocio, y finalmente, cómo el sistema o producto va a ser utilizado en el día a día. Una relación de necesidades y características Un informe del alcance del sistema Una lista de clientes, usuarios y otros intervinientes Prototipos para definir mejor los requisitos Escenarios que permiten ver al sistema o producto bajo diferentes condiciones operativas. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 17 Identificación de Requisitos La técnica de obtención de requisitos mas usada es llevar a cabo una reunión o entrevista preliminar.» Preguntas de contexto libre : Se enfocan sobre el cliente, los objetivos generales y los beneficios esperados.» Preguntas de identificación de participantes y beneficios medibles.» Preguntas dirigidas a la eficacia de la reunión Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 18 9

10 Técnicas para facilitar las especificaciones de la aplicación Directrices básicas : La reunión se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores. Se establecen normas de preparación y de participación Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes, pero informal para el libre flujo de ideas Un coordinador que controle la reunión Mecanismos de definición (carteles, pizarras, hojas de trabajo..) El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 19 Despliegue de la función de calidad Es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnicos del software Hace énfasis en entender lo que resulta valioso para el cliente y después desplegar estos valores a lo largo del proceso de ingeniería. Utiliza observaciones y entrevistas con el cliente, emplea encuestas y examina datos históricos. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 20 10

11 Despliegue de la función de calidad Requisitos Normales Se declaran objetivos y metas para un producto o sistema. Si los requisitos están presentes, el cliente quedará satisfecho. Requisitos Esperados Son implícitos al producto o sistema y son tan fundamentales que el cliente no los declara. Su ausencia sería motivo de una insatisfacción significativa. Requisitos Innovadores Van mas allá de las espectativas del cliente y suelen ser muy satisfactorias Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 21 Análisis y Negociación de Requisitos Una vez recopilados, los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto. Utilizando un proceso iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 22 11

12 Análisis de requerimientos Métodos de análisis. Características comunes. Realizan una abstracción de las características del sistema, es decir, consisten en desarrollar un modelo del mismo. Representan el sistema de forma jerárquica, basándose en mecanismos de partición del problema y estableciendo varios niveles de detalle. Definen cuidadosamente las interfaces del sistema, tanto las interfaces externas, que relacionan el sistema con su entorno, como de las internas, las que se establecen entre los distintos módulos definidos. Sirven de base para las etapas posteriores de diseño y de implementación. Distinguen entre requisitos esenciales y de implementación. No prestan demasiada atención a la representación de las restricciones o de criterios de validación (exceptuando los métodos formales). Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 23 Validación de Demostración de que los requerimientos que definen el sistema son lo que el cliente realmente quiere. Los costos de errores en los requerimientos son altos, por lo cual, la validación es muy importante. Fijar un error de requerimiento después del desarrollo puede resultar en un costo 100 veces mayor que fijar un error en la implementación. El Prototipado es una técnica importante de la validación de requerimientos. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 24 12

13 Chequeando Validación. Provee al sistema las funciones que mejor soporten las necesidades idd del dlcliente? t? Consistencia. Existe cualquier conflicto en los requerimientos? Completo. Están incluidas todas las funciones requeridas por el cliente? Realismo. Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 25 Revisión de Una revisión regular puede ayudar mientras la definición i ió de requerimientos i está siendo hecha. h Tanto el cliente como el staff de contratistas deben estar involucrados en la revisión. La revisión debe ser formal (con los documentos completos) o informal. Una buena comunicación entre desarrolladores, d clientes y usuarios puede resolver problemas en las primeras etapas. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 26 13

14 Chequeo de la Revisión Verificabilidad. Es el Requerimiento realmente probable? bbl? Entendibilidad. Es el Requerimiento comprendido propiamente? Probabilidad. Es el origen de los requerimientos claramente establecido? Adaptabilidad. Puede el requerimiento ser cambiado sin causar un gran impacto en otros requerimientos? Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 27 Evolución de Los requerimientos siempre involucran como comprender mejor el desarrollo de las necesidades de los usuarios y como los objetivos de la organización pueden cambiar. Es esencial planear posibles cambios en los requerimientos cuando el sistema sea desarrollado y utilizado. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 28 14

15 Evolución de Comprensión Inicial del Problema Comprensión de los Cambios del Problema Iniciales Cambios en los Tiempo Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 29 Clases de Durables. Establecer requerimientos i derivados d de las actividades id d de la organización del cliente. Por ejemplo, un hospital siempre tendrá doctores, enfermeras, etc. Puede ser derivado de modelos de dominio. Volátiles. Los requerimientos cambian durante el desarrollo o cuando el sistema está en uso. En un hospital, los requerimientos se derivan de las políticas salud-cuidados. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 30 15

16 Clasificación de Cambiantes. Los requerimientos i que cambian por el ambiente del sistema. Surgimiento de los. que surgen como una comprensión del desarrollo del sistema. en Consecuencial. que resultan de la introducción del sistema a la computadora. Compatibles. que dependen de otros sistemas o de otros procesos de la organización. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 31 Cambios en el Documento de El documento de requerimientos debe ser organizado, de tal forma que los cambios en los requerimientos puedan ser hechos sin tener que re-escribir demasiado. Las referencias externas deben ser minimizadas y las secciones del documento deben ser tan modulares como sea posible. Los cambios son fáciles cuando se trata de un documento electrónico. Sin embargo, la falta de estándares para documentos electrónicos lo hace difícil. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 32 16

17 Evolución Controlada Cambio en los Documento VI de Cambio en los Documento V1 de Documento V2 De Implementación V1 del Sistema Implementación V2 del Sistema Implementación V1 del Sistema Implementación V2 del Sistema Inconsistencia de los y del Sistema Consistencia de los y del Sistema Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 33 Resumen Es muy difícil formular una especificación de requerimientos i completa y consistente. t Una definición de requerimientos, una especificación de requerimientos y una especificación de Software son una manera de especificar el Software para diferentes tipos de lectores. El Documento de es una descripción para clientes y desarrolladores. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 34 17

18 Resumen Los errores en los requerimientos son usualmente muy caros de corregir una vez desarrollado d el sistema. La revisión debe involucrar al cliente y al staff de contratistas para validar los requerimientos del sistema. El establecer requerimientos i está relacionado con las actividades del cliente para el Software. Los requerimientos volátiles dependen del contexto en que se use el sistema. Ian Sommerville 1995 Ingeniería de Software, 5a. edición Capitulo 4 Diapositiva 35 18