04 Ingenieria Requerimientos

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
- Es consciente de que ningn ser humano podr utilizar un producto tan

complejo?
Diferencia de
expectativas
- Sus requisitos de usuario incluyen 400 funcionalidades.

Desarrollador
pero funciona!
- Buena observacin! Debera aadir fcil de utilizar
tiempo
Un requisito es
Requisitos son una especificacin de lo
que debera ser implementado. []
-- Ian Sommerville & Pete Sawyer
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]
Qu es la Ingeniera de Requisitos?
una
especificacin
que el sistema o
producto debe
cumplir
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
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.
Requisitos
La realidad de los proyectos software
RDM
En 2004, el Chaos Report de Standish Group vaticinaba una mejora

continuada en el nmero de proyectos software que terminaban con xito.
Gestin y Definicin de Requisitos

INGENIERA DE REQUISITOS
DEFINICIN DE REQUISITOS
GESTIN DE REQUISITOS
Captura de requisitos
Anlisis de requisitos
Especificacin de requisitos
Validacin de requisitos
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)

1.
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:
Evolucin de los resultados del anlisis Chaos Report.
En 2004, diferentes analistas ya predecan este comportamiento:
2.
Patrones de diseo
Reutilizacin
Model Driven Development
Anlisis esttico de cdigo
Automatizacin de pruebas funcionales y de rendimiento
Pero la mayor fuente de defectos sigue siendo los Requisitos!!
Fuente: TynerBlain.com
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
Se contina siendo artesano en lugar de aplicar tcnicas maduras de Ingeniera

de Requisitos.
Algunos datos interesantes
Algunos datos interesantes
Causas de los defectos

Esfuerzo dedicado a corregir los defectos
Requirements
Errors
(82%)
Design Errors
(13%)
Coste relativo de solucionar un defecto
La importancia de los Requisitos

Other Errors (4%)
Coding Errors (1%)

200
Project Analyzed
180
0- 5% invested in Req.
Management results in 80-200%
overcost
8-14% invested in Req.
Management results in 0-60%
overcost
% Overcost
160
140
120
100
80
60
40
20
0
0
Fuentes: James Martin, Barry Boehm
Fuentes: James Martin, Barry Boehm
10
15
20
25
% 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.
Mg. Richard Y. Mercado Rivas
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.
Ing. Richard Y. Mercado Rivas
Procesos de Ingeniera Software
Un Proceso es el conjunto total de

actividades de ingeniera necesarias para
transformar dentro de software los
requerimientos de usuarios
De dnde provienen los requerimientos?

Especificaciones Reqs.
Planes de Negocio
Metas de Personal
Socios
Clientes
Analistas
Usuarios
Reporte de Problemas
Req. De Cambio
Dominio del Problema

Expertos Dominio
Analistas Industria
Visitas al WEB
Modelo de Negocios
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.
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.
Managing the Process, Humphrey, 1989

Ej. Sistema de Biblioteca

1. El usuario deber tener la posibilidad de buscar
referencias bibliogrficas en el conjunto inicial
de la base de datos o seleccionar un sub
conjunto de ella.
2. El sistema deber proveer visores adecuados
para que el usuario lea documentos en el
almacn de documentos.
3. A cada pedido se le deber asignar un
identificador nico que el usuario podr copiar al
rea de almacenamiento permanente de la
cuenta.
MTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO

FUNCIONALES
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.
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).
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
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?
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.
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
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.
1) Entrevistas y Cuestionarios
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
- 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:
1) Entrevistas y Cuestionarios
Ejemplos de Preguntas Abiertas:
1
2
3
4
5
Leer los antecedentes.

Establecer los objetivos de la entrevista.
Decidir a quin entrevistar.
Preparar al entrevistado.
Decidir el tipo de pregunta y la estructura.
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
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
Tipos de prototipos:
Prototipo rpido:
Mecanismo para lograr validacin pre-compromiso

Es una tctica para que antes del diseo e implementacin
aparezcan requerimientos:
desconocidos
mal entendidos
nuevos
Iteracin para poner el prototipo a punto

Facilita la comprensin del desarrollador.
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
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).
Representacin:
Sistema de ventas
Buscando
datos de
producto
Usa
Ingresando
Pedido
Empleado
de Ventas
Usa
Obteniendo
Ventas
Hereda
Sistema de
Estadsticas
Hereda
Buscador de datos del Producto

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

de Ingeniera de Software
MODELO
Oliver and Steiner

1996
EIA / IS-632
IEEE Std 1220- 1994
CMM nivel Repetitivo

(2)
RUP
Evaluar la informacin
disponible
Anlisis de
requerimientos
Anlisis de
Requerimientos
Identificacin de
requerimientos
Anlisis del Problema
Definir mtricas
efectivas
Anlisis funcional
Estudio de los
requerimientos
Identificacin de
restricciones del
sistema a
desarrollar
Comprender las
necesidades de
los involucrados
Crear un modelo del

comportamiento
del sistema
Sntesis
Validacin de
requerimientos
Anlisis de los
requerimientos
Definir el sistema
Crear un modelo de
los objetos
Anlisis y control del

sistema
Tcnicas utilizadas en las etapas de la Ingeniera de

Requerimientos.
Tcnica
Entrevistas y Cuestionarios
Actividades
Ventajas
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.
Es necesaria una buena compenetracin del grupo

participante.
Ayudan a validar y desarrollar nuevos requerimientos.

Permite comprender aquellos requerimientos que no
estn muy claros y que son de alta volatilidad.
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
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 funcional
Representacin de los
requerimientos
Analizar el alcance del

proyecto
Evaluacin y estudio
de funciones
Comunicacin de los
requerimientos
Modificar la definicin
del sistema
Crear un plan
secuencial de
construccin y
pruebas
Verificacin de
funciones
Validacin de
requerimientos
Administrar los
cambios de
requerimientos
Prototipos
Casos de Uso
Sntesis
Desventajas
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.
Lluvia de Ideas
Ejecutar el anlisis
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.
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.
Estudio y evaluacin
del diseo
Verificacin fsica
Control
Tcnicas que pueden ser utilizadas en las diferentes

actividades de la IR.
Anlisis del
Problema
Entrevistas y
Cuestionarios
Evaluacin y
negociacin
Especificacin
de
Requisitos
Evolucin
Lluvia de Ideas
Herramientas automatizadas para la

Administracin de Requerimientos
X
X
Prototipos
Documentos:
Anlisis Jerrquico
Casos de Uso
Validacin
X
X
X
X
Herramientas automatizadas
RequisitePro: De IBM Rational Software
Herramientas:
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
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
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
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
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.
5.
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.
Tener a las personas correctas en el saln

Algunas preguntas
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.
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.
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.
Fases del JAD
Fases del JAD
Se diferencian 5 fases:
1.
2.
3.
4.
5.
Fase 1: Definicin del proyecto

Antes que nada, necesitamos
saber que quiere la empresa.
Con esto podemos producir la
Gua de Definiciones de la
Empresa, seleccionar el equipo de
JAD y programar las sesiones
Se debe entrevistar al Coordinador
Ejecutivo y los jefes de las reas
de negocios involucradas con el
proyecto.
Definicin del proyecto.

Investigacin.
Preparacin.
La Sesin.
El Documento Final.
Posibles preguntas
Como se origino el
proyecto?
Cuales son sus
principales problemas?
Qu beneficios desea
obtener con el proyecto?
Qu limitaciones
deberamos considerar?
57
Fases del JAD
Fases del JAD
Definicin de la empresa
Fase 2: Investigacin
Desde la perspectiva de la empresa.

Posee el propsito, alcance y objetivos del proyecto.
Programando la sesin
El tiempo depende del proyecto. Por lo gral., de 3 a 5
das.
Pueden ser sesiones de medio da o de da entero
(hace el proyecto mas corto).
Familiarizarnos con el rea de trabajo de la empresa.

Documentar requerimientos de datos.
Documentar procesos de trabajo.
Recolectar informacin preliminar.
Repasar la agenda de la sesin.
Familiarizarse con la empresa
Obtener puntos de vista ms tcnicos,
Consultas con personal externo que sirva de ayuda
59
60
10
Fases del JAD

Documentar Requerimientos
Identificar los grupos de
datos usados en el rea de
trabajo.
Definir los nombres y
descripciones de los datos
elementales.
Definir relaciones.
Definir una estructura
correcta para los datos.
Documentar proceso de
trabajo
Define las reglas para
usar los datos.
Se puede usar
diagramas de
descomposicin,
diagramas
dependientes o
matrices.
Para capturar los
procesos de trabajo se
usan los DFD.
Fases del JAD

Fase 3: Preparacin
Compilar toda la informacin
obtenida en un documento
(el documento de trabajo)
Entrenar al Notario.
Crear ayudas visuales.
Realizar una reunin de presesin.
Montar la sala para la
sesin.
Fases del JAD

Documento
Debe tener la
informacin recogida
para ser usado en la
sesin.
Es un punto de partida
para la toma de
decisiones.
No se debe confundir
con el documento final
ya que este documento.
solo es propuesto.
Aunque debera estar
en el mismo formato
que el documento final.
El Notario debe
Ayudas visuales
Conocer su su rol.
Ayudan a mantener a
los participantes
Describirle el
enfocados y pueden
proceso de JAD.
clarificar las decisiones
Discutir el
tomadas.
proyecto.
Describir la sesin. Ej:
Diagramas
Luego de cada
Caones
sesin hay que
encontrarse con el
Proyectores.
notario para
Pizarrones
revisar las notas.
Digitalizadores,
etc.
Fases del JAD

Suposiciones
Las suposiciones se
acumulan desde el
comienzo del JAD.
Estn todas listadas en el
documento de trabajo.
Se lee cada suposicin al
grupo para discutirla,
pudiendo quedar como
est, ser revisada o se
convierte en una discusin
abierta.
Requerimientos de datos
Puede ir desde un
completo modelo de
datos a definir solo
unos nuevos elementos
de datos.
DER general, guiado
Fases del JAD

Fase 4: Sesin
Abriendo la sesin
Al principio se debe exponer:
Es el principal evento del

proceso JAD.
Para toda la sesin vamos a
usar una agenda que tiene:
Discutir suposiciones.
Definir requerimientos de datos.
Disear procesos de trabajo.
Disear pantallas.
Resolver discusiones abiertas.
Items Administrativos: Como ser

la sesin (Horarios, habitaciones
de descanso, etc.)
Objetivos de la sesin: Que se
quiere lograr.
La agenda de la sesin: Recorrer
la agenda explicando como se va
a manejar cada tem.
Reglas fundamentales: Habla uno
por vez, etc.
Vista panormica del trabajo.
Gua de Definicin de la Empresa:
Aunque los participantes la
recibieron antes de la sesin hay
que revisar los puntos mas
importantes.
Fases del JAD

Proceso de trabajo
Antes de la sesin, se los
identifica y se documentan
con DFD, pasando al doc. de
trabajo y a transparencias.
En la sesin, se discuten sin
que, por lo general, se
produzcan grandes cambios.
Pero pueden aparecer nuevos
DFD que pueden causar
debate.
Es importante definirlo en
pequeos grupos.
Pantallas
Los puntos ms
importantes son:
Flujo de pantalla.
Diseo de pantallas.
Diseo de pantallas
GUI.
Reportes
Similar a las pantallas
El objetivo es evaluar la
ES del sistema
11
Fases del JAD
Fases del JAD
Discusiones abiertas
Se entrega un formulario a los

participantes para evaluarlos
Sirven para profundizar un
despus de la sesin.
tema
Cerrando al sesin, se debe
No necesariamente hay que
1. Determinar quien recibir al doc.
seguir una agenda
final (se crea la lista de distribucin
predefinida
final.)
Debe cuidarse de no irse por
2. Discutir como los participantes van
las ramas
a revisar el documento (que le
revisen para ver si lo quieren
Evaluacin de la sesin
modificar).
Se mide el suceso y la
3. Dar algunos puntos de cierre
satisfaccin del los
(palabras de agradecimiento hacia
participantes Se usa
los participantes.)
Fase 5: El documento final

En esta fase final del JAD se pasan todos lo acuerdos de
la sesin al documento final.
Se calcula que por cada da de sesin se debe tomar de
uno a un da y medio para documentar lo hecho.
Por que el documento final es importante
Es un sntesis comprensiva de todo lo hecho.
Para los que no estuvieron en la sesin y forman parte del
proyecto, puede ser una de los nicos elementos para juzgar
al proyecto despus de la sesin.
principalmente en los
primeros proyectos.
Fases del JAD

Qu debe tener el documento
final
Fases del JAD
Como debe escribirse

Se mira del lado del
que lo va a leer
preguntando:
Se usan tablas para presentar

la informacin.
Como ser:
Obtener el OK final
Para esto se firma el formulario de aprobacin.
LOGO
Medir xito de JAD
Se revisa el documento pgina por pgina.

Puede surgir comentarios de todo tipo (que se debera
cambiar algo, que hay que agregar una columna a un
reporte, etc.)
Al final de esta reunin se determina como se manejan
los cambios (si hay que reimprimir el documento o no).
Lo entender?
Est en espaol
claro?, etc.
Tablas de decisin.
Tablas de procedimientos
(para cuando necesitamos
explicar como hacer algo).
Tablas de procesos (adems
de como hacer algo tiene
quien hace cada paso).
La reunin de revisin
UNIVERSIDAD NACIONAL DEL CENTRO DEL PER

Facultad de Ingeniera de Sistemas
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
5
4
Horas
3
por PF
2
2,5
NO uso JAD
Uso JAD
1
0
Proyectos
12

04 Ingenieria Requerimientos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04 Ingenieria Requerimientos

Uploaded by

Copyright:

Available Formats

LOGO

UNIVERSIDAD NACIONAL DEL CENTRO DEL PER

EL REA PROBLEMTICA Y SU DEFINICIN

Anlisis y Diseo de Software

Algunas de estas situaciones son familiares

Algunas de estas situaciones son

- Es consciente de que ningn ser humano podr utilizar un producto tan

- Sus requisitos de usuario incluyen 400 funcionalidades.

- Buena observacin! Debera aadir fcil de utilizar

Una condicin o capacidad necesaria para

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

Es la disciplina utilizada para descubrir los requisitos, analizarlos,

La realidad de los proyectos software

En 2004, el Chaos Report de Standish Group vaticinaba una mejora

Gestin y Definicin de Requisitos

Pero qu ha ocurrido en realidad?

La realidad de los proyectos software

La realidad de los proyectos software

En los ltimos 15 aos se han introducido importantes mejoras en el

Evolucin de los resultados del anlisis Chaos Report.

En 2004, diferentes analistas ya predecan este comportamiento:

Automatizacin de pruebas funcionales y de rendimiento

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

Uso de modelos estadsticos en la Gestin de Proyectos

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

Algunos datos interesantes

Algunos datos interesantes

Causas de los defectos

Coste relativo de solucionar un defecto

La importancia de los Requisitos

Coding Errors (1%)

Fuentes: James Martin, Barry Boehm

Fuentes: James Martin, Barry Boehm

% Requirements Management Cost compared to total project cost

Mg. Richard Y. Mercado Rivas

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

Procesos de Ingeniera Software

Un Proceso es el conjunto total de

De dnde provienen los requerimientos?

Anlisis y Diseo de Software

Dominio del Problema

Cmo identificamos los Requerimientos ?

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

Managing the Process, Humphrey, 1989

Ing. Richard Y. Mercado Rivas

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

Ej. Sistema de Biblioteca

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

MTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO

Ing. Richard Y. Mercado Rivas

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

Anlisis y Diseo de Software

Ing. Richard Y. Mercado Rivas

La cadena eslabona a las unidades organizacionales de