LOGO

UNIVERSIDAD NACIONAL DEL CENTRO DEL PER Facultad de Ingeniera de Sistemas

EL REA PROBLEMTICA Y SU DEFINICIN

Anlisis y Diseo de Software INGENIERIA DE REQUERIMIENTOS

Mg. Richard Mercado Rivas

Algunas de estas situaciones son familiares

Algunas de estas situaciones son familiares

- Voy a ver qu quiere el cliente, el resto empezad a programar!

PERFECTO lo voy a probar!

Esto no me vale!

FUNCIONA!

Cliente

- Sus requisitos de usuario incluyen 400 funcionalidades. - Es consciente de que ningn ser humano podr utilizar un producto tan complejo? - Buena observacin! Debera aadir fcil de utilizar
Desarrollador

Diferencia de expectativas

pero funciona!

tiempo

Un requisito es
Requisitos son una especificacin de lo que debera ser implementado. []
-- Ian Sommerville & Pete Sawyer

Qu es la Ingeniera de Requisitos?
una especificacin que el sistema o producto debe cumplir
Es la disciplina utilizada para descubrir los requisitos, analizarlos, entenderlos, especificarlos y validarlos de forma colaborativa, gestionando los cambios a lo largo del ciclo de vida. Permite alinear a los stakeholders en: Una visin compartida Unos objetivos Unas expectativas. Reduce el riesgo de que un sistema sea rechazado por los usuarios una vez desarrollado Una Gestin y Definicin de Requisitos eficiente permite: Mostrar un nivel de disciplina en el proceso de desarrollo Dar un mejor soporte a la Gestin de Cambios Ganar una mayor eficiencia en las pruebas Reducir los problemas de mantenimiento.

Una condicin o capacidad necesaria para un usuario para solucionar un problema o alcanzar un objetivo []
[IEEE Std 610.12, IEEE Standard Glossary of Software Engineering Terminology]

Lo que un usuario quiere no es necesariamente lo que necesita!

Los Requisitos son ... El principal criterio de xito del equipo de proyecto La base de las tareas del equipo de proyecto La base para el diseo, codificacin y las pruebas

Requisitos
RDM
Gestin y Definicin de Requisitos
INGENIERA DE REQUISITOS
DEFINICIN DE REQUISITOS Captura de requisitos Anlisis de requisitos Especificacin de requisitos Validacin de requisitos GESTIN DE REQUISITOS

La realidad de los proyectos software

En 2004, el Chaos Report de Standish Group vaticinaba una mejora continuada en el nmero de proyectos software que terminaban con xito.

Pero qu ha ocurrido en realidad?

Nota: Standish Group, en su Chaos Report considera como variables de xito la entrega en tiempo y coste, la calidad de los sistemas entregados, y el cumplimiento de las necesidades del usuario (alcance)

La realidad de los proyectos software

1.

La realidad de los proyectos software

En los ltimos 15 aos se han introducido importantes mejoras en el desarrollo de software, especialmente en las etapas de gestin de proyectos, codificacin y pruebas:
Uso de modelos estadsticos en la Gestin de Proyectos Uso de metodologas giles y evolutivas. Lenguajes de programacin ms potentes y multiplataforma Herramientas de desarrollo rpido Aplicacin de tcnicas de ingeniera maduras
Patrones de diseo Reutilizacin Model Driven Development Anlisis esttico de cdigo

Evolucin de los resultados del anlisis Chaos Report.

En 2004, diferentes analistas ya predecan este comportamiento:

Automatizacin de pruebas funcionales y de rendimiento

2.
Fuente: TynerBlain.com

Pero la mayor fuente de defectos sigue siendo los Requisitos!!

Se contina siendo artesano en lugar de aplicar tcnicas maduras de Ingeniera de Requisitos.

Algunos datos interesantes

Causas de los defectos
Requirements Errors (82%)

Algunos datos interesantes

Esfuerzo dedicado a corregir los defectos
Design Errors (13%)

Coste relativo de solucionar un defecto

Other Errors (4%) Coding Errors (1%)
200 180 160

La importancia de los Requisitos

Project Analyzed 0- 5% invested in Req. Management results in 80-200% overcost 8-14% invested in Req. Management results in 0-60% overcost

% Overcost

140 120 100 80 60 40 20 0 0 5 10

15

20

25

Fuentes: James Martin, Barry Boehm

Fuentes: James Martin, Barry Boehm

% Requirements Management Cost compared to total project cost

Qu es un Requerimiento ? Un requerimiento es una condicin o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede ser definido como : Una capacidad del software necesaria por el usuario para resolver un problema o alcanzar un objetivo. Una capacidad del software que debe ser reunida o poseda por un sistema o componente del sistema para satisfacer un contrato, especificacin, estndar, u otra documentacin formal.
Anlisis y Diseo de Software Mg. Richard Y. Mercado Rivas

De dnde provienen los requerimientos?

Especificaciones Reqs. Planes de Negocio Metas de Personal

Socios

Clientes

Analistas Reporte de Problemas Req. De Cambio Dominio del Problema Expertos Dominio Analistas Industria Visitas al WEB Modelo de Negocios
Mg. Richard Y. Mercado Rivas

Usuarios

Anlisis y Diseo de Software

Rol de Requerimientos
Si un producto no es lo que el cliente o los usuarios quieren, entonces la calidad de la construccin es irrelevante. El rol clave de los requerimientos es mostrar a los desarrolladores y usuarios que se necesita de un sistema. Proveer los requerimientos forma parte de un lenguaje que todos comprenden, ya que todos estn involucrados, incluyendo los clientes. El primer y bsico rol de los requerimientos es por lo tanto la comunicacin.

Cmo identificamos los Requerimientos ? Los Requerimientos toman vida desde que realizamos nuestro primer encuentro de interlocucin con usuarios o clientes. Este puede desarrollarse utilizando cualquiera de una variedad de tcnicas como entrevistas para intercambiar opiniones, brainstorming, prototipeo, cuestionarios, etc. Cuando los requerimientos se logran redactar a un significativo nivel de detalle, tendremos listo el documento denominado Especificacin de Requerimientos.

Procesos de Ingeniera Software

Requerimientos Funcionales
Describen la funcionalidad o los servicios que se espera proveer el sistema. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etc.

Un Proceso es el conjunto total de actividades de ingeniera necesarias para transformar dentro de software los requerimientos de usuarios Managing the Process, Humphrey, 1989

Ejemplo

Requerimientos No Funcionales Son aquellos requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema, como la capacidad de los dispositivos de entrada/salida y la representacin de datos que se utiliza en las interfaces del sistema. Sin embargo, estos requerimientos no siempre se refieren al sistema de software a desarrollar.
Anlisis y Diseo de Software Ing. Richard Y. Mercado Rivas

MTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO FUNCIONALES

Ejemplo

Identificacin de Requerimientos y Reglas del Negocio

Para identificar los requerimientos correctos del negocio primero debemos de comprender como funciona, es decir cuales son las reglas del negocio. Mientras ms complejo es el sistema una mayor cantidad de vistas del mismo son necesarias para comprender su funcionamiento. Las distintas vistas del negocio pueden conseguirse a travs de un mapeo de la situacin actual (AS-IS) utilizando a un alto nivel: El Diagrama de descomposicin funcional o mapeo de procesos. Las cadenas de responsabilidad para la atencin de los requerimientos Los Diagramas de Actividad Los Diagramas de Colaboracin Los Diagramas de Interaccin de Roles Casos de Uso del Negocio

Cadena de Responsabilidades Es la cadena funcional que se establece para la atencin de un requerimiento. Una cadena involucra las interacciones producto de los requerimientos de un actor externo al negocio (cliente o proveedor) con las responsabilidades de un trabajador de negocio.

CADENA DE RESPONSABILIDADES

La cadena eslabona a las unidades organizacionales de los trabajadores de negocio, que intervienen como consecuencia de las responsabilidades de cada uno y a travs de la interaccin entre ellos (cumpliendo un rol) y de estos con el actor de negocio externo (cliente o proveedor).

Casos de Uso de Negocio Un caso de uso es la cadena de interacciones entre un actor de negocio (cliente, proveedor o trabajador) y el sistema (la empresa, una unidad organizacional o un proceso del negocio) con la finalidad de satisfacer un requerimiento o alcanzar un objetivo. Una secuencia de acciones que produce un resultado de valor para un particular actor de negocio.

Actividades de la Ingeniera de Requerimientos

Actividades varan en nmero, nombre y orden Podemos identificar 5 actividades: Anlisis del problema Evaluacin y negociacin Especificacin Validacin Evolucin No son estrictamente secuenciales

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

Anlisis del problema

Comprender el problema Identificar afectados (y sus necesidades) Considerar el problema desde varias perspectivas (explorar soluciones) Definir limites y restricciones Vocabulario comn

Identificar afectados
Para determinar quienes se vern afectados por el sistema, debemos realizar algunas preguntas.
Quin usar el sistema que se va a construir? Quin desarrollar el sistema? Quin probar el sistema? Quin documentar el sistema? Quin dar soporte al sistema? Quin dar mantenimiento al sistema? Quin mercadear, vender, y/o distribuir el sistema? Quin se beneficiar por el retorno de inversin del sistema?

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

Anlisis y Diseo de Software

Mg. Richard Y. Mercado Rivas

Perspectivas y soluciones
Necesidad: "El cliente se queja mucho por la enorme fila que debe formar para realizar una transaccin bancaria". Perspectiva: del cliente = Prdida de tiempo del banco = Posibles prdidas de clientes Posibles soluciones:
determinar por qu demoran los cajeros colocar una nueva caja (implica contratacin de nuevos cajeros) abrir una nueva sucursal (involucra personal nuevo y estudio de mercado) realizar transacciones por otros medios (telfono, internet, mediante cajeros automticos, autobancos, etc).

Evaluacin y negociacin de Requerimientos

Asegurar que se cumplan las caractersticas de los requerimientos. Clasificacin de los requerimientos (Prioridad) Determinar cuales se incluyen en cuanto al costo, complejidad, etc. Comunicacin entre el equipo de desarrollo y los afectados

Especificacin de requisitos de software (SRS)

Generacin del documento de requerimientos. En el se describe: requerimiento de hardware y software requerimiento funcionales y no funcionales alcance del sistema diagramas e informacin que sirva de soporte y gua para fases posteriores Utilizado como fuente de comunicacin SRS posee las mismas caractersticas de los requerimientos

Utilizacin del SRS

Clientes y usuarios: Comparacin entre requerimientos y necesidades. Analistas y programadores: Determinar el producto a desarrollar. Personal de pruebas: elaborar las pruebas. Administrador del proyecto: referencia y control de la evolucin del sistema.

Validacin Evitar elevados costos de mantenimiento Validar requerimientos definidos y del cliente Verificar caractersticas del SRS Diferencias entre Evaluacin y Validacin

Verificar caractersticas del SRS

Estn incluidas todas las funciones requeridas por el cliente? (completa) Tiene alguno de los requerimientos ms de una interpretacin? (no ambigua) Est cada requerimiento claramente representado? (entendible) Pueden los requerimientos ser implementados con la tecnologa y el presupuesto disponible? (factible) Est la SRS escrita en un lenguaje apropiado? (clara) Est claramente definido el origen de cada requisito? (rastreable) Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)

Evolucin
Comprender y controlar los cambios en los req. Propuesta de cambio o problema identificado Anlisis de costos (rastreo y modificaciones) Razones del cambio: Porque al analizar el problema no se hacen las preguntas correctas a las personas correctas Porque los usuarios cambiaron su forma de pensar o sus perspectivas etc.

Tcnicas utilizadas en las actividades de IR Su objetivo es obtener los requisitos Se eligen segn el proyecto a desarrollarse 1) 2) 3) 4) Entrevistas y Cuestionarios Tormenta de Ideas Prototipos Casos de Uso

1) Entrevistas y Cuestionarios
- Consiste en que el analista formule preguntas relacionadas con varios aspectos de sistemas. - En general a: usuarios de sistemas existentes futuros usuarios gerentes empleados - Son tiles las Preguntas Abiertas

Hay cinco pasos que deben realizarse para preparar la entrevista:

Leer los antecedentes. Establecer los objetivos de la entrevista. Decidir a quin entrevistar. Preparar al entrevistado. Decidir el tipo de pregunta y la estructura.

1 2 3 4 5

1) Entrevistas y Cuestionarios
Ejemplos de Preguntas Abiertas:
Del Usuario Quin es el cliente? Quin es el usuario? Son sus necesidades diferentes? Cules son sus habilidades, capacidades, ambiente? Del Proceso Cul es la razn por la que se quiere resolver este problema? Cul es el valor de una solucin exitosa? Cmo usted resuelve el problema actualmente? Qu retrasos ocurren o pueden ocurrir? Del Producto Qu problemas podra causar este producto en el negocio? En qu ambiente se usar el producto? Cules son sus expectativas para los conceptos fcil de usar, confiable, rendimiento? Qu obstculos afectan la eficiencia del sistema?

2) Tormentas de ideas (Brainstonrm):

Principios: No realizar crticas hasta agotar ideas La cantidad produce la calidad Mejor en grupo que individual Una idea que alguien la percibe diferente => genera otras ideas Equipo: - Director - Secretario - Personas involucradas en el proyecto

2) Tormentas de ideas (Brainstonrm):

Fases:
- Descubrir hechos: Comunicar con anticipacin los temas a tratar Explicar los principios de una tormenta de ideas Hablar unos 10 de temas sensillos y no comprometido Determinar y plantear el problema. Dividirlo en partes (si es complejo) - Producir ideas (la tormenta propiamente dicha) - Producir gran cantidad de ideas (segn los principios vistos) - Si se trabaja mucho sobre un tema => alejarse para producir asociaciones, combinaciones o mejoras de las anteriores - Fin de reunin y prxima reunin - Pedir que no abandonen el problema y que traigan las nuevas ideas que surjan para exponerlas en la prxima reunin - Descubrir soluciones: Elaborar una lista definitiva de ideas y seleccionar las mas interesantes Ponderar las ms tiles Clasificarlas Presentarlas de forma atractiva (ej: en soporte visual)

3) Prototipos
Es un modelo del Software que debe ser construido
Se capturan requerimientos Se definen los objetivos globales Se disea rapidamente, centrndose en la parte visible al usuario (ej: entradas y salidas) Se construye el prototipo Clientes y usuarios evalan el prototipo, refinando los requerimientos

Iteracin para poner el prototipo a punto Facilita la comprensin del desarrollador.

3) Prototipos
Tipos de prototipos:
Prototipo rpido:

4) Casos de Uso
- Un caso de uso es la especificacin del comportamiento del sistema y de algo externo (personas, hardware, otros software) que usa sus servicios. - Ej: en sistema de Ventas -Servicio: Permitir ingresar nuevos pedidos -Evento: Cliente hace pedido -Caso de Uso: Ingresando pedido (se ejecuta cuando se produce el evento).

Mecanismo para lograr validacin pre-compromiso Es una tctica para que antes del diseo e implementacin aparezcan requerimientos:
desconocidos mal entendidos nuevos

y se validen
Prototipo evolutivo:

Todo el ciclo de vida del un producto puede ser visto como una serie incremental de prototipos. Elimina la distincin entre desarrollo y mantenimiento (mantener un sistema es tomar como prototipo el ya desarrollado).

4) Casos de Uso
Representacin:
Sistema de ventas

Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniera de Software

MODELO
Oliver and Steiner 1996 Evaluar la informacin disponible Definir mtricas efectivas EIA / IS-632 Anlisis de requerimientos Anlisis funcional IEEE Std 1220- 1994 Anlisis de Requerimientos Estudio de los requerimientos CMM nivel Repetitivo (2) Identificacin de requerimientos Identificacin de restricciones del sistema a desarrollar Anlisis de los requerimientos Representacin de los requerimientos Comunicacin de los requerimientos Validacin de requerimientos RUP Anlisis del Problema Comprender las necesidades de los involucrados Definir el sistema

Buscando datos de producto

Usa
Actividades

Crear un modelo del comportamiento del sistema Crear un modelo de los objetos Ejecutar el anlisis

Sntesis

Validacin de requerimientos Anlisis funcional Evaluacin y estudio de funciones Verificacin de funciones

Anlisis y control del sistema

Analizar el alcance del proyecto Modificar la definicin del sistema Administrar los cambios de requerimientos

Usa

Ingresando Pedido

Empleado de Ventas
Hereda

Obteniendo Ventas

Crear un plan secuencial de construccin y pruebas

Sistema de Estadsticas
Hereda

Sntesis

Estudio y evaluacin del diseo Verificacin fsica

Buscador de datos del Producto

Control

Tcnicas utilizadas en las etapas de la Ingeniera de Requerimientos.

Tcnica Entrevistas y Cuestionarios Lluvia de Ideas Prototipos Ventajas Mediante ellas se obtiene una gran cantidad de informacin correcta a travs del usuario. Pueden ser usadas para obtener un pantallazo del dominio del problema. Son flexibles. Permiten combinarse con otras tcnicas. Los diferentes puntos de vista y las confusiones en cuento a terminologa, son aclaradas por expertos. Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto. Ayudan a validar y desarrollar nuevos requerimientos. Permite comprender aquellos requerimientos que no estn muy claros y que son de alta volatilidad. Desventajas La informacin obtenida al principio puede ser redundante o incompleta. Si el volumen de informacin manejado es alto, requiere mucha organizacin de parte del analista, as como la habilidad para tratar y comprender el comportamiento de todos los involucrados. Es necesaria una buena compenetracin del grupo participante.

Tcnicas que pueden ser utilizadas en las diferentes actividades de la IR.

Anlisis del Problema Evaluacin y negociacin Especificacin de Requisitos Validacin Evolucin

Entrevistas y Cuestionarios

X X X X X X

X X

Lluvia de Ideas El cliente puede llegar a pensar que el prototipo es una versin del software que ser desarrollado. A menudo, el desarrollador hace compromisos de implementacin con el objetivo de acelerar la puesta en funcionamiento del prototipo En sistemas grandes, toma mucho tiempo definir todos los casos de uso. El anlisis de calidad depende de la calidad con que se haya hecho la descripcin inicial.

Prototipos

Casos de Uso

Representan los requerimientos desde el punto de vista del usuario. Permiten representar ms de un rol para cada afectado. Identifica requerimientos estancados, dentro de un conjunto de requerimientos.

Anlisis Jerrquico

X X

Casos de Uso

Herramientas automatizadas Herramientas automatizadas para la Administracin de Requerimientos

Documentos:
Complejo para mantenerlos actualizados Cambios notificados manualmente Difcil de agregar links entre requerimientos Reutilizar un requerimiento es complejo Incmodo para modificar requerimientos si el grupo de trabajo esta distante geogrficamente

Herramientas:
Importar requerimientos de documentos Definir los atributos de los requerimientos Definir los valores de los atributos Definir links de seguimiento entre requerimientos Generar documentos en base a los requerimientos Crear grupos de usuarios con permisos para acceder a las diferentes funciones

Centradas en base de datos: Almacenan los requerimientos, atributos y seguimiento en una BD. Centradas en documentos: Usan un procesador de texto como contenedor y guardan datos en una BD

Herramientas automatizadas
RequisitePro: De IBM Rational Software
Integracin con Microsoft Word Infraestructura de base de datos Seguimiento y anlisis de requerimientos Acceso web Generacin de reportes Sealiza los requerimientos que cambiaron y los afectados por el cambio

Herramientas automatizadas
Doors: De Quality Systems and Software
Enlaces a reportes de cada requerimiento Identificacin de inconsistencias Permite compartir requerimientos entre proyectos Notificacin via mail cuando los requerimientos son revisados Estadsticas a traves de graficos Importa sus documentos a Office, HTML, texto, etc

Caliber RM: De Borland

Permite definir templates en Word Basado en Internet Repositorio centralizado de requerimientos Notificacin automtica de cambios Mltiples tipos de requerimientos y atributos ilimitados Enlace de documentos a los requerimientos

Qu es JAD?
Podemos entenderlo como: Desarrollo compartido de aplicaciones entre usuarios e ingenieros de software. El principal elemento es la sesin reunin de gente para planificar un proyecto, disear un sistema o tomar decisiones de negocio. La sesin involucra: Agenda detallada. Ayuda visual. Facilitador. Escritor (llamado Notario). El resultado es un Documento final.

Los 10 mandamientos de JAD

1. 2. 3. 4. El xito de JAD depende del empeo administrativo. Los participantes deben asistir a la sesin entera. El xito de JAD requiere un facilitador entrenado. Asegurarse de tener a las personas correctas en la sesin Todos los participantes son iguales. 6. La preparacin es tan importante como la sesin. 7. Hacer una buena agenda y adherirse a ella. 8. Usar tcnicas y herramientas apropiadas en la sesin. 9. Mantener la jerga tcnica al mnimo. 10. Producir un documento final rpido y de calidad.

5.

Tener a las personas correctas en el saln

Algunas preguntas
Cules con las consecuencias de no tener a las personas adecuadas en la sesin?
Va en contra del concepto de JAD Se debe cambiar la planificacin.

Fases del JAD

Se diferencian 5 fases:
1. 2. 3. 4. 5. Definicin del proyecto. Investigacin. Preparacin. La Sesin. El Documento Final.

Qu pasara si falta alguien?

Se debe crear una lista con las preguntas para esa persona.

Hay que asegurarse de incluir a las personas que usan los procesos (los que leen reportes, entran los datos y ven las pantallas). Cuntas personas deben asistir a la sesin?
Entre 7 y 15.

58

Medir xito de JAD

Es muy difcil porque no hay control de grupo para comparar los resultados. No hay un segundo conjunto de usuarios semejantes y programadores a los que les den el mismo desafo de diseo para que lo realicen en el modo tradicional. Se hicieron pruebas, estos son los resultados obtenidos:
5,2

LOGO

UNIVERSIDAD NACIONAL DEL CENTRO DEL PER Facultad de Ingeniera de Sistemas

6 5 4 Horas 3 por PF 2 1 0

2,5 NO uso JAD Uso JAD

Proyectos
Anlisis y Diseo de Software Mg. Richard Y. Mercado Rivas

10