IngSW U2 Ing Requisitos

Fundamentos de Ingeniería de

Software

Unidad 2 –Ingeniería de Requisitos

Ingeniería de Requisitos


• “Lo más difícil en la construcción de un sistema software es decidir precisamente qué construir...”

• “No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal...”

• “Ninguna otra tarea es tan difícil de rectificar a posteriori...”

• Frederick Phillips Brooks, Jr., 1987


• La evidencia empírica demuestra que:

– Los requisitos contienen demasiados errores

– Muchos de estos errores no se detectan al principio

– Muchos de estos errores podrían ser detectados al principio.


• La evidencia empírica demuestra que:

– No detectar estos errores incrementará los costes (tiempo, dinero) de forma exponencial

– Además, los programadores obedecen los requisitos (cuando existen).


• Consecuencias

– El sistema resultante no satisfará a los usuarios

– Se producirán desacuerdos entre usuarios y desarrolladores

– Puede ser imposible demostrar si el software cumple, o no, los requisitos

– Se gastará tiempo y dinero en construir el sistema equivocado


• Complejidad

– No estamos hablando de sistemas de 15 ó 30 requisitos. También hay:

• Sistemas de cientos de requisitos

• Sistemas de miles de requisitos

• Sistemas de 5.000 requisitos

• Sistemas de más de 10.000

• Sistemas de incluso 60.000 (!) requisitos


• 1995/2001: The Chaos Report

– http://www.standishgroup.com

– Gasto anual en EEUU: $250 mil millones en unos 175.000 proyectos.

• 31,1% (23%) son cancelados

• 52,7% (49%) cuestan un 190% más de lo estimado

• Un 16,2% (28%) será finalizado a tiempo y dentro del presupuesto, pero el producto final poseerá (aprox.) la mitad de los requisitos iniciales

http://www.standishgroup.com/

http://www.standishgroup.com/


• La crisis del software y los requisitos – Boehm, 1975: 45% de los errores tienen su orígen en

los requisitos y en el diseño preliminar.

– DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto Sw. Se deben a una mala Especificación de Requisitos

– Chaos Report: Los factores principales que conducen al fracaso en los proyectos Sw. Son: • Falta de comunicación con los usuarios

• Requisitos incompletos

• Cambios a los requisitos


• Acumulación de errores

Prog. basados en la Especificación

Errónea

Errores Ocultos Errores

Incorregibles

Prog. basados en un Diseño Erróneo

Diseño basado en una Especificación

Errónea

Errores Corregibles

Programas Erróneos

Diseño Erróneo

Especificación Incorrecta

Funciones Correctas

Problema

Especificación Correcta

Diseño Correcto

Programas Correctos

PRODUCTOS IMPERFECTOS

PRUEBA

IMPLE-MENTA-

CIÓN

DISEÑO

ESP. REQUI-SITOS


• ¿Solución? – No se ha encontrado solución universalmente válida

– Hay serias dudas acerca de si dicha solución existe • Nos movemos en la frontera socio-técnica de los sistemas:

borrosa, voluble e inconsistente

• Los requisitos es donde lo formal se encuentra con lo informal (M. Jackson)

• Los requisitos están vivos: emergen, interactúan, cambian, desaparecen...

– Desconfía de quien ofrezca la solución definitiva a estos problemas !!!


• ¿Qué es? – “La Ingeniería de Requisitos ayuda a los ingenieros de

software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software.” • Pressman, 2006: 155

– “La Ingeniería de Requisitos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema.” • Sommerville, 2005: 82


• ¿Qué son los requisitos?

– “Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo”

– “Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal”

• Std 610.12-1900, IEEE: 62


• Tipos de requisitos:

– Funcionales

• Describe los servicios (funciones) que se esperan del sistema.

• Definen las funciones que el sistema realizará.

• Describen el ¿qué?, no el ¿Cómo?.

• Se convertirán en algoritmos, reglas de negocio y código del sistema.

– Ejemplo:

• El sistema aceptará pagos con VISA


• Tipos de requisitos:

– No funcionales

• Son restricciones sobre los requisitos funcionales.

• Son características que limitan al sistema en rendimiento, interfaces de usuario, fiabilidad, mantenimiento, seguridad, portabilidad, etc.

– Ejemplo:

• El sistema aceptará pagos con VISA – de forma segura y con un tiempo de respuesta menor de 5

segundos


• Características:

• Como todo contrato o acuerdo entre ambas partes.

Especificado por escrito

• Si un requisito no se puede comprobar, ¿cómo se sabe si se cumplió con él o no?

Posible de probar o verificar

• Es fácil de leer y entender.

• Redacción simple y clara para su futuro.

Conciso


• Características:

• No se necesita ampliar detalles en su redacción.

Completo

• No es contradictorio con otro requisito.

Consistente

• Tiene una sola interpretación.

No ambiguo


• Dificultades para definir:

– Los requisitos no son obvios y vienen de distintas maneras.

– Son difíciles de expresar con palabras.

– La cantidad de requisitos en un proyecto es demasiado grande.

– Un requisito puede cambiar a los largo del ciclo de desarrollo.


• Dificultades para definir:

– El usuario no puede explicar bien lo que quiere.

– Hablan de lo que no funciona.

– Los usuarios y clientes tienen distinto vocabulario que los desarrolladores.

2.1. TAREAS DE LA INGENIERÍA DE REQUISITOS

2.1. Tareas de la Ingeniería de Requisitos

• Lizka Johany Herrera:

1. Extracción

• Es el descubrimiento de los requisitos del sistema.

• Analistas deben trabajar de cerca al cliente para descubrir:

– El problema que el sistema va a resolver.

– Los servicios que el sistema va a prestar.

– Las restricciones que se pueden presentar.

• Aceptación del sistema ligada con la satisfacción del cliente en los requisitos descubiertos.

• Obtener requisitos: a través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus expectativas.



2. Análisis

• Descubrir problemas encontrados en los requisitos.

• Actividades para esto: – Leer, limitarlos, investigar, intercambiar ideas, resaltar

problemas grandes, buscar alternativas y soluciones.

– Por último se reúne con el cliente para discutir los requisitos refinados.

• Analizar requisitos detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseño.



3. Especificación

• Se documentan los requisitos acordados con el cliente en un nivel apropiado de detalle.

• “Pasar en limpio” el análisis y acotamiento de requisitos.

• Se utilizan estándares y/o técnicas de documentación: – Casos de uso

– Obtención de requisitos basada en casos de uso.

• Documentar requisitos igual que todas las etapas, los requisitos deben estar debidamente documentados.



4. Validación

• Ratificar los requisitos.

• Asegurarse que los requisitos representan una descripción aceptable del sistema a desarrollar.

• Requisitos consistentes y completos.

• Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicación.

• Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.


• Ejemplo de lo que podemos encontrar en un documento de

“requisitos” 1. El sistema mantendrá la temperatura de la caldera entre 70º y 80º 2. El sistema mantendrá un registro de todos los materiales de la

biblioteca, incluyendo libros, periódicos, revistas, videos y CDRoms

3. El sistema permitirá a los usuarios realizar una búsqueda por título, autor o ISBN

4. El interfaz de usuario se implementará sobre un navegador Web 5. El sistema deberá soportar al menos 20 transacciones por

segundo 6. El sistema permitirá que los nuevos usuario se familiaricen con su

uso en menos de 15 minutos.

2.2. TÉCNICAS DE LA INGENIERÍA DE REQUISITOS

2.2. Técnicas de la Ingeniería de Requisitos

• Existen distintas técnicas para la obtención de requisitos.

• Sólo hablaremos de las más utilizadas:

– Entrevistas y cuestionarios

– Sistemas existentes

– Lluvia de ideas

– Prototipos

– Casos de uso


• Entrevistas y cuestionarios

– Se emplean para reunir información de personas o grupos.

– La entrevista: conversación entre el analista y el encuestado.

– El cuestionario: serie de preguntas relacionadas con varios aspectos del sistema.

– El éxito de esta técnica depende de la habilidad del entrevistador y de la preparación para la misma.


• Sistemas existentes

– Consiste en analizar distintos sistemas relacionados con el sistema a ser construido.

– Se analiza:

• Interfaces de usuario.

• Entradas de datos.

• Salidas de resultados.


• Lluvia de ideas

– Usado para generar ideas.

– Objetivo generar la máxima cantidad de requisitos posibles.

– No pensar si el requisito es bueno o malo.

– Al tener una gran cantidad ir eliminando según importancia o prioridad.


• Prototipos

– Simulaciones del posible producto.

– Se utilizan al no tener clara la idea de algún requisito.

– Se construye y se presenta con el cliente.

– Se obtiene una importante retroalimentación.

– Etapas: • Captura de requisitos.

• Definición de objetivos globales entre cliente y analistas.

• Se profundiza en las áreas del software de mayor interés.

• Se presenta al cliente y se retroalimenta.


• Casos de uso

– Son utilizados para especificar el comportamiento del sistema.

– Permiten describir la posible secuencia de interacciones entre el sistema y los actores.


• Casos de uso

– Descripción de un conjunto de escenarios, donde un escenario es un evento provocado por un actor.

– El autor Sommerville los define como una técnica que se basa en escenarios para la obtención de requerimientos.

2.3. MODELADO DE REQUISITOS

2.3. Modelado de requisitos

• Casos de uso – El diagrama de casos de uso representa la forma en

como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).

– Un diagrama de casos de uso consta de los siguientes elementos: • Actor.

• Casos de Uso.

• Relaciones de Uso, Herencia y Comunicación.


• Casos de uso

– Actor:

• Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema.

• Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.


• Casos de uso

– Caso de uso

• Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.


• Casos de uso

– Relaciones:

• Asociación – Es el tipo de relación más básica que indica la invocación desde un

actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

• Dependencia o Instanciación – Es una forma muy particular de relación entre clases, en la cual

una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.


• Casos de uso – Relaciones:

• Generalización – Este tipo de relación es uno de los más utilizados, cumple una

doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

– Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

» extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

» uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.


• Casos de uso – Como ejemplo esta el caso de una Máquina

Recicladora: • Sistema que controla una máquina de reciclamiento de

botellas, tarros y jabas.

• El sistema debe controlar y/o aceptar: – Registrar el número de ítemes ingresados.

– Imprimir un recibo cuando el usuario lo solicita:

» Describe lo depositado

» El valor de cada item

» Total

– El usuario/cliente presiona el botón de comienzo


• Casos de uso – Como ejemplo esta el caso de una Máquina

Recicladora: • El sistema debe controlar y/o aceptar:

– Existe un operador que desea saber lo siguiente:

» Cuantos ítemes han sido retornados en el día.

» Al final de cada día el operador solicita un resumen de todo lo depositado en el día.

– El operador debe además poder cambiar:

» Información asociada a ítemes.

» Dar una alarma en el caso de que:

• Item se atora.

• No hay más papel.


• Casos de uso

– Como una primera aproximación identificamos a los actores que interactuan con el sistema:


• Casos de uso

– Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:


• Casos de uso

– Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.


• Casos de uso

– Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.


• Casos de uso

– Entonces, el diseño completo del diagrama Use Case es:

2.4. HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS

Resumen

IngSW U2 Ing Requisitos

Documents

Transcript of IngSW U2 Ing Requisitos