Transcript clase2

Ingeniería de Software
Clase 2
Análisis de Riesgo
JAD ( Joint Application Development)
Contenido Clase 2

Análisis de Riesgo



Definición
Estrategias
Riesgos del Software





Identificación, Proyección, Supervisión y Gestión del
Riesgo
Plan de Riesgo
Estudio de Casos


Propuesta del SEI
JAD (joint application development)



UNPSJB -2005
Identificación
Clasificación
Definición
Actores
Desarrollo
Ingeniería de Software - Clase 2
2
Contenido Clase 2

Bibliografía utilizada







UNPSJB -2005
Ingeniería de Soft (Pressman)
Ingeniería de Soft (Sommerville)
Valoración de Riesgos (Jones)
JAD (August)
Ingeniería de Requerimientos
(Locoupulous)
Ingeniería de Requerimientos (Davis)
Papers varios
Ingeniería de Software - Clase 2
3
A.Riesgo - Introducción

Qué es el Riesgo?




UNPSJB -2005
Afecta acontecimientos futuros
Resultado de nuestras acciones pasada
Implica cambios y elecciones
 opiniones, acciones, lugares, etc.
“Mientras es inútil intentar eliminar el
riesgo y cuestionable poder minimizarlo,
es esencial que los riesgos que se tomen
sean los riesgos adecuados”
Ingeniería de Software - Clase 2
4
A.Riesgo - Introducción

Riesgos Reactivos y proactivos

reactivo: reaccionar ante el problema


Gestión de crisis
proactivo: estrategias de tratamiento
identificar riesgos
 valorar su impacto y probabilidad de
ocurrencia
 prioridad de tratamiento

UNPSJB -2005
Ingeniería de Software - Clase 2
5
A.Riesgo - Clasificación

Características del Riesgo:



Primer clasificación de riesgos

UNPSJB -2005
Incertidumbre: ocurrencia o no del caso
Pérdida: si se hace realidad consecuencias no
deseadas que llevan a eventuales pérdidas.
riesgos del proyecto. Característica:
 amenazan la existencia del proyecto
 afectan la planificación temporal, retrasos y
aumento de costos
Ingeniería de Software - Clase 2
6
A.Riesgo - Clasificación

Riesgos técnicos.
Características:





amenazan la calidad y
planificación temporal
afecta la realización del
proyecto (haciéndolo
eventualmente inviable)
Riesgos del negocio.
Características:


amenazan la viabilidad del
software a construir
ponen en peligro el proyecto
o el producto.
UNPSJB -2005
Que puede ocurrir:




Ingeniería de Software - Clase 2
hacer un software
excelente que nadie use
(de mercado)
hacer un software que no
sirva al cliente
(estratégico)
Hacer un software que no
se pueda vender
perder apoyo del cliente
ante un cambio en la
dirección de la compañía
(de dirección)
perder presupuesto o
personal asignado (de
presupuesto)
7
A.Riesgo - Clasificación

Riesgos posibles, ejemplos
Riesgo
Tipo de Riesgo
Descripción
Rotación del personal
Proyecto
Personal con experiencia abandona el
proyecto antes de que finalice
Cambio de administración
Proyecto
Habrá un cambio de administración
organizacional con diferentes prioridades
No disponibilidad de
hardware
Proyecto
El hard esencial para el proyecto no será
entregado a tiempo
Cambio de requerimientos
Proyecto y
producto
Habrá más cambios en los requerimientos
que lo anticipado
Retraso en la especificación
Proyecto y
producto
Las especificaciones de las interfaces
esenciales no estarán a tiempo
Cambio de tecnología
Negocio
La tecnología fundamental sobre la que se
construye el sistema se sustituye por
nueva
Bajo UNPSJB
desempeño
-2005 de la
herramienta CASE
Producto
La- herramienta
CASE no tiene el
Ingeniería de Software
Clase 2
desempeño anticipado
8
A.Riesgo - Clasificación

Segunda clasificación



riesgos conocidos. Se pueden
determinar con:
 evaluación del plan de
proyecto
 evaluación del entorno
técnico y comercial
 otras fuentes de información
Riesgos predecibles: utiliza
experiencia de proyectos
anteriores.
Riesgos Impredecibles.
UNPSJB -2005

Tercer clasificación:



Ingeniería de Software - Clase 2
Jones caracteriza los
60 casos de riesgo
Comunes y serios
Desarrollaremos
posteriormente
9
A.Riesgo - Plan de riesgo

4 etapas del plan de riesgo




UNPSJB -2005
identificación del riesgo: reconocer los
riesgos
proyección del riesgo: evaluar su
impacto y probabilidad de ocurrencia
reducción y supervisión: evaluar el
estado del riesgo en función del
proyecto
gestión del riesgo: llevar a cabo planes
de contingencia
Ingeniería de Software - Clase 2
10
A.Riesgo - Plan de riesgo

El proceso de administración de
riesgos en forma gráfica
Identificación
de riesgos
Listado de riesgos
potenciales
UNPSJB -2005
Análisis de
riesgos
Listado de priorización de riesgos
planeación de
Riesgos
Anulación de
riesgos y planes
de contintencia
Ingeniería de Software - Clase 2
Supervisión de
riesgos
Valoración de
riesgos
11
A.Riesgo - Plan de riesgo

Identificación del riesgo.

Dos tipos de riesgo
genérico: amenaza potencial para el
proyecto
 específico del producto: evaluables por
expertos en el desarrollo.


Lista de comprobación de riesgos:
tamaño del producto
 impacto en el negocio
 características del cliente

UNPSJB -2005
Ingeniería de Software - Clase 2
12
A.Riesgo - Plan de riesgo
definición del proceso
 entorno de desarrollo
 tecnología a construir
 tamaño y experiencia de la plantilla


Riesgos asociados al tamaño del
producto
riesgo del proyecto directamente
proporcional a su tamaño.
 Lista de comprobación de riesgos
genéricos



UNPSJB -2005
tamaño estimado del producto en LDC o PF?
Grado de seguridad de la estimación de
tamaño
Ingeniería de Software - Clase 2
13
A.Riesgo - Plan de riesgo






Riesgos del impacto en el negocio

Lista de comprobación de riesgos
genéricos

UNPSJB -2005
Tamaño estimado del producto en número de
programas, archivos y transacciones.
Tamaño de la base de datos creada o
empleada por el producto
número de usuarios del producto
número de cambios previstos en el software,
antes, durante y luego de la entrega
(Asociado con requerimientos)
cantidad de software reutilizado
efecto del producto en los ingresos de la
compañía
Ingeniería de Software - Clase 2
14
A.Riesgo - Plan de riesgo









UNPSJB -2005
Viabilidad de este producto para los gestores
expertos
fecha límite de entrega: razonable?
Sofisticación del usuario final
cantidad y calidad de la documentación del
producto que debe entregarse al usuario final
limitaciones legales en la construcción del
software
costos asociado por el retraso en la entrega
costos asociados con un producto defectuoso
número de productos con los que se tendrá
interoperación
Riesgos relacionados con el cliente
 Clientes vs. usuarios. Características:
Ingeniería de Software - Clase 2
15
A.Riesgo - Plan de riesgo


Lista de comprobación de riesgos genéricos








UNPSJB -2005
Necesidades diferentes, personalidades diferentes,
se contradicen muy a menudo.
se ha trabajado anteriormente con el cliente
sabe el cliente lo que necesita, lo ha escrito
acepta realizar todas las reuniones necesarias
para la evaluación de requerimientos (ej JAD)
está dispuesto a trabajar en las revisiones
está dispuesto a tener comunicación fluida
entiende del problema que especifica
está dispuesto a delegar acciones en usuarios
adecuados
conoce algo del proceso del software
Ingeniería de Software - Clase 2
16
A.Riesgo - Plan de riesgo

Riesgos del proceso

SEI propone un cuestionario que evalúa

UNPSJB -2005
aspectos del proceso
 proceso estándar de desarrollo
 están todos de acuerdo con el proceso a
utilizar
 se conoce bien el funcionamiento del
proceso
 el personal de desarrollo conoce:
estándares a seguir, documentaciones a
completar.
 se hacen RTF del todo el proceso y se
documentan adecuadamente
 calidad se trata adecuadamente: gestión
de configuración.
Ingeniería de Software - Clase 2
17
A.Riesgo - Plan de riesgo

UNPSJB -2005
Aspectos técnicos
 se técnicas de especificación de aplicaciones
para ayudar a la comunicación clientedesarrollador
 se emplean métodos específicos para AR, y
diseño
 código se escribe en lenguaje de alto nivel
 se documenta adecuadamente el código
 se emplean herramientas adecuadas para:
gestión de configuración, análisis y diseño,
creación de prototipos, soporte de
documentación, etc.
 Se han establecido las métricas a seguir:
calidad, productividad,..
Ingeniería de Software - Clase 2
18
A.Riesgo - Plan de riesgo

Riesgos tecnológicos
 Lista de comprobación de riesgos genéricos







UNPSJB -2005
hemos desarrollado anteriormente este tipo de
software
el software interactúa con hardware nuevo o no
probado
interactúa el software a construir con nuevos
software aún no probados. (incluyendo nuevas
BD)
los requisitos demandan alguna interfaz especial
tenemos que utilizar nuevas técnicas de análisis,
diseño, codificación o prueba.
Consideraciones de rendimiento muy restrictivas?
La funcionalidad solicitada por el cliente es real?
Ingeniería de Software - Clase 2
19
A.Riesgo - Plan de riesgo

Riesgos del entorno de desarrollo

Lista de comprobación de riesgos
genéricos





Riesgos asociados con la plantilla

UNPSJB -2005
tenemos las herramientas necesarias para la
construcción del software (para cada etapa)
existen las herramientas necesarias
existen expertos disponibles en el uso de las
herramientas que puedan ayudarnos si es
necesario
es adecuada la ayuda en línea y la
documentación de cada herramienta
Lista de comprobación de riesgos
genéricos
Ingeniería de Software - Clase 2
20
A.Riesgo - Plan de riesgo







Proyección del riesgo

UNPSJB -2005
disponemos de la mejor gente y de la gente
suficiente
tiene el el personal conocimientos adecuados
se ha asignado personal para toda la duración del
proyecto
el personal solo trabaja en este proyecto
tiene la información adecuada
el movimiento del personal como se prevé?
actividades
 establecer una escala de probabilidad de
ocurrencia
 examinar el impacto del riesgo
Ingeniería de Software - Clase 2
21
A.Riesgo - Plan de riesgo
definir las consecuencias del riesgo en el
proyecto y el producto
 generar la tabla de riesgo
Estudio del impacto del riesgo
 catastrófico: cancelación del proyecto
 crítico: reducción de rendimiento, retrasos
en la entrega, excesos importante en
costo.
 marginal: reducciones mínimas de
rendimiento, posibles retrasos, exceso en
costo
 despreciable: incidencia mínima en el
desarrollo.


UNPSJB -2005
Ingeniería de Software - Clase 2
22
A.Riesgo - Plan de riesgo
tabla de Bohem
Rendimiento
Soporte
Catastró Degradación que
lleva a no alcan-fico
Costo
Recortes financieros duros prezar rendimiento
supuesto exceditécnico
do
Alguna reducción Pequeños retrasos Algún recorte en
Crítico
en el rendimiento en modificaciorec. Financieros,
técnico
nes de software| posibles excesos
en presupuesto
Recursos finanMarginal De mínima a pe- El soporte del
queña reducción software respon- cieros suficienen el rendimiento de
tes
técnico
Despre- No hay reducción Software fácil de Psible superávit
en el rendimiento dar soporte
de presupuesto
ciable
técnico
UNPSJB -2005
El software no
responde o no
admite soporte
Ingeniería de Software - Clase 2
Plan Temporal
Fecha de entrega
inalcanzable
Posibles retrasos
de la fecha de
entrega.
Planificación
temporal realista, alcanzable
Fecha de entrega
fácilmente alcanzable
23
A.Riesgo - Plan de riesgo

Tabla de riesgo

primer fase: construcción de la tabla





lista de riesgos
categoría
probabilidad de ocurrencia
impacto
segunda fase: clasificación

por impacto y probabilidad de ocurrencia
tercer fase: línea de corte
 cuarta fase: plan de contingencia

UNPSJB -2005
Ingeniería de Software - Clase 2
24
A.Riesgo - Plan de riesgo

Factores que afectan el riesgo
naturaleza
 alcance
 cuando ocurre


Reducción y supervisión

reducción del riesgo
reunirse con la plantilla y determinar las
causas
 actuar para reducir las causas que estén
al alcance del control

UNPSJB -2005
Ingeniería de Software - Clase 2
25
A.Riesgo - Plan de riesgo




UNPSJB -2005
Organizar los equipos del proyecto de manera
que la información sobre cada actividad esté
dispersa.
Definir los estándares de documentación.
Convocar a reuniones de revisión.
Factores de supervisión
 grado de compenetración del equipo
 relaciones interpersonales entre miembros del
equipo
 disponibilidad de empleo dentro y fuera de la
compañía
Ingeniería de Software - Clase 2
26
A.Riesgo - Plan de riesgo

Gestión del riesgo


UNPSJB -2005
evaluar las situaciones que se dan a lo
largo del proceso de desarrollo
actuar con los planes de contingencia
ante situaciones problemáticas
Ingeniería de Software - Clase 2
27
A.R. - Valoración de proyectos


Metodología SRP (software
productivity research)
Tipos de proyecto valorables


Factores a evaluar

UNPSJB -2005
militares, comerciales, expertos, etc.
Factores estratégicos: impactan en
toda la empresa, relacionados con las
políticas corporativas. Casos:
Ingeniería de Software - Clase 2
28
A.R. - Valoración de proyectos
Política de precios, de la compañía en
función de los competidores de mercado.
 Cultura corporativa de trabajo
 Política y objetivos corporativos


Factores tácticos: influyen en proyectos
particulares. Casos:
métodos y herramientas utilizadas
(análisis, diseño, programación)
 producción de documentos
 estructura de la organización del proyecto

UNPSJB -2005
Ingeniería de Software - Clase 2
29
A.R. - Valoración de proyectos




Factores de satisfacción de usuario: no solo de
comunicación. Casos:
 el producto resuelve su problema
 el producto es vital para su actividad
Estructura del proceso de valoración SPR

UNPSJB -2005
Espacio disponible en las oficinas de trabajo
métodos de comunicación (workflows,
groupware)
Actividades
 recolección de datos
Ingeniería de Software - Clase 2
30
A.R. - Valoración de proyectos





UNPSJB -2005
Administración de las entrevistas
análisis individual de cada proyecto
comparaciones, análisis agregados e
interpretaciones
reporte de medidas obtenidas y mejoras de
oportunidades.
Integrantes del grupo de valoración
 líder, facilitador, etc.
 valoradores
 miembros del grupo de desarrollo de cada
proyecto
Ingeniería de Software - Clase 2
31
A.R. - Valoración de proyectos

Escala de influencia (similar a CMM)
1
2
3
4
5

excelente
bueno
promedio
mediocre
pobre
Datos “duros” obtenidos
tamaño de las especificaciones y
documentaciones
 PF totales del proyecto

UNPSJB -2005
Ingeniería de Software - Clase 2
32
A.R. - Estudio de Riesgos
Cantidad de código fuente en todos los
lenguajes utilizados
 Actividades y tareas llevadas a cabo
 Actividades de mantenimiento,
 Implicación del usuario, costos, etc.


Resultados obtenidos

Categorizaciones de proyectos
Sistemas de administración de
información
 Software de sistemas(SO,
telecomunicaciones, etc.)

UNPSJB -2005
Ingeniería de Software - Clase 2
33
A.R. - Estudio de Riesgos
Software comercial (desde juegos a
sistemas IA o expertos pero de venta
masiva)
 Software militar
 Software subcontratado o externo.
 Software desarrollado para usuarios
finales


Categorización de riesgos
comunes
 serios

UNPSJB -2005
Ingeniería de Software - Clase 2
34
A.R. - Estudio de Riesgos

Riesgos comunes por tipo de proyectos

Sistemas de información






Software de sistemas


UNPSJB -2005
obtener los requerimientos de usuario (80%)
esquemas excesivamente presionantes
(65%)
baja calidad (60%)
sobrepaso en costos (55%)
inadecuada configuración de control (50%)
esquemas largos (70%)
estimación de costos inadecuada (65%)
Ingeniería de Software - Clase 2
35
A.R. - Estudio de Riesgos




Software comercial






documentación de usuario inadecuada (70%)
baja satisfacción del usuario (55%)
tiempo de marketing excesivo (50%)
acciones adversas de la competencia (45%)
gastos de litigios (30%)
Software militar

UNPSJB -2005
Excesivo papeleo (60%)
módulos proclives a error (50%)
proyectos cancelados (35%)
papeleo excesivo (90%)
Ingeniería de Software - Clase 2
36
A.R. - Estudio de Riesgos





Software subcontratado





UNPSJB -2005
Baja productividad (85%)
esquemas largos (75%)
obtención de requerimientos de usuario
(70%)
software no usado o no usable (45%)
Altos costos de mantenimiento (60%)
fricción entre el contratista y los
desarrolladores (50%)
obtención de requerimientos de usuario
(45%)
criterios de aceptación no definidos (30%)
problemas legales relativos a la propiedad
legal del software (20%)
Ingeniería de Software - Clase 2
37
A.R. - Estudio de Riesgos

Software para usuarios finales






prevención y control de riesgos
comunes

UNPSJB -2005
aplicaciones no transferibles (80%)
errores ocultos (65%)
software imposible de mantener (60%)
aplicaciones redundante (50%)
problemas legales relativos a la propiedad
legal del software (20%)
obtención de requerimientos de usuario:
JAD, prototipación rápida
Ingeniería de Software - Clase 2
38
A.R. - Estudio de Riesgos

Esquemas largos, esquemas presionantes,
excesivo tiempo de marketing





Exceso en los costos: similar a problemas con
es esquema (excederse en tiempo). Medir
mejor
Baja de calidad y módulos que concentran
errores:


UNPSJB -2005
hacer mejor la planificación y estimación usando
mejores herramientas
reducir la duración del esquema
reutilizar, métodos OO, CASE
mejorar la estimación de calidad y confiabilidad
métodos de prevención de defectos (mejores
pruebas)
Ingeniería de Software - Clase 2
39
A.R. - Estudio de Riesgos



Grandes costos de mantenimiento



UNPSJB -2005
Métodos de remoción de defectos
Programas para medir calidad
solo se incluye mantenimiento correctivo
hacer el software mejor, o utilizar mejores
herramientas
factores de riesgos comunes resistentes al
control:
 excesivo papeleo: se puede reducir en
proyectos civiles, imposible en militares
 documentación de usuario inadecuada:
herramientas multimediales
Ingeniería de Software - Clase 2
40
A.R. - Estudio de Riesgos
Baja satisfacción del usuario: mejora con
GUI, ayudas en línea, documentación
acorde, etc.
 Fricción entre clientes y desarrolladores
 usos legales costos de litigio.


10 riesgos más serios evaluados por
SPR
métricas inadecuadas: LDC, PF
 mediciones inadecuadas: no evaluar
correctamente los “gastos” del software

UNPSJB -2005
Ingeniería de Software - Clase 2
41
A.R. - Estudio de Riesgos

Esquemas excesivamente presionantes.







UNPSJB -2005
Esquema original decretado
requerimientos cambiantes sin limitaciones
mala práctica en el gerenciamiento
estimaciones de costos inapropiadas
(COCOMO) (clase 5)
síndrome de la bala de plata: tengo un CASE
que soluciona todo
obtención en los requerimientos de usuario
baja calidad
Ingeniería de Software - Clase 2
42
A.R. - Estudio de Riesgos
baja productividad
 proyectos cancelados


SPR: estudio de 60 casos,
importante




alcance de cada caso
forma de prevenirlo
método de control
planes de contingencia

UNPSJB -2005
evaluar otros riesgos afectados.
Ingeniería de Software - Clase 2
43
A.R. - Estudio de Riesgos

Que evalúa SPR y
Jones?


Define el riesgo
Estudia
 Severidad
 Frecuencia
 Ocurrencia
 Susceptibilidad y
resistencia
 Causas que lo originan
 Problemas asociados
UNPSJB -2005
Impacto en los
costos
 Métodos de
prevención
 Métodos de control
 Efectividad de
soluciones conocidas
 Costo de estas
soluciones
 Pronostico a largo
Ingeniería de Software - Clase 2 plazo
44

A.R. - Estudio de Riesgos
Algunos

ejemplos

Proyectos cancelados


proyectos que son terminados
antes de llegar al usuario final
Severidad: la severidad
promedio de proyectos
cancelados es 2.5



Severidad 1: proyecto cancelado
durante la fase final de testeo
Severidad 2: proyecto cancelado
durante la última etapa de
codificación y primera de test
Severidad 3: proyecto cancelado
durante la última etapa diseño y
primera de codificación
UNPSJB -2005



Severidad 4: proyecto cancelado
durante las etapas tempranas o
intermedias de diseño.
Severidad 5: proyecto cancelado
durante la última etapa de
requerimiento y la primera de
diseño.
Frecuencia: está correlacionado
con el tamaño del proyecto (a
mayor PF por proyecto mayor la
probabilidad de cancelación).
Ocurrencia: muy común en
proyectos militares y proyectos de
comunicaciones.
Ingeniería de Software - Clase 2
45
A.R. - Estudio de Riesgos


Susceptibilidad y
resistencia: los
proyectos que tienden a
irse fuera de control
son los más peligrosos
para su cancelación.
Problemas asociados:


Causas raíces: son varias




UNPSJB -2005

proyecto mal planeado, y
estimado
el desarrollo tarda
demasiado, la situación de
negocios o técnica cambia
y hace el proyecto inviable
se comienzan dos o más
proyectos similares y solo
el ganador sobrevive
factores externos como la
venta del negocio
Ingeniería de Software - Clase 2

traen asociados
fricciones con el usuario
y con los directivos.
Pueden bajar la moral
de la empresa, de los
empleados, etc.
La cancelación es
debido a factores como:
mala planificación,
inadecuada estimación
de costos, esquemas
perdidos, esquemas
largos, sobrepaso de
costos, baja calidad y
productividad, etc.
46
A.R. - Estudio de Riesgos



Impacto de costos: es alarmante y
serio. Cuanto más tarde se cancele
el proyecto mayor habrán sido los
gastos producidos
Métodos de prevención: un buen
plan de trabajo y cuidadosa
estimación, hay herramientas que
ayudan a esto.
Métodos de control: para proyectos
de más de 5000 PF con mal
relevamiento inicial de
requerimientos es imposible el
control. El plan y la estimación
solo para proyectos con
requerimientos estables
desarrollados en forma competente
usando una estructura
metodológica. involucrado.
UNPSJB -2005



Efectividad de soluciones
conocidas: esquemas y
estimación de riesgo son las
mejores herramientas. Estas
se pueden realizar con
software existentes en el
mercado.
Costo de soluciones
conocidas: depende
directamente de la
herramienta/s utilizada/s.
Pronósticos de largo alcance:
es esperable que se sigan
cancelando proyectos, si bien
la utilización de las
herramientas de predicción
tendrán como resultado una
reducción de dicho porcentaje.
Ingeniería de Software - Clase 2
47
¿Qué es JAD?


UNPSJB -2005
Podemos entenderlo como:
Desarrollo compartido de
aplicaciones entre usuarios e
ingenieros de software.
El principal elemento es la sesión 
reunión de gente para planificar un
proyecto, diseñar un sistema o
tomar decisiones de negocio.
Ingeniería de Software - Clase 2
48
¿Qué es JAD?

La sesión involucra:





UNPSJB -2005
Agenda detallada.
Ayuda visual.
Facilitador.
Escritor (llamado Notario).
El resultado es un Documento final.
Ingeniería de Software - Clase 2
49
Diseño de sistemas usando JAD

Esta metodología tiene como
características:



UNPSJB -2005
Compromiso
 Los participantes están en la sesión por una
orden de la empresa para resolver un
problema.
Cohesión del grupo
 La convivencia hace que los participantes se
conozcan muy rápido  quieren trabajar
juntos.
Reuniones productivas
Ingeniería de Software - Clase 2
50
Fases del JAD
 JAD
se divide en cinco fases:
Definición del proyecto.
 Investigación.
 Preparación.
 La sesión.
 El documento final.

UNPSJB -2005
Ingeniería de Software - Clase 2
51
Tendencia a usar JAD
 La compañías se vuelcan a
JAD por:

Aparecen equipos
Jerarquías  Equipo.




Otro enfoque en calidad y
productividad.
Usuarios más inteligentes:
 Mas dispuestos a
participar en el
desarrollo de
aplicaciones.


Desplazamiento de la
tecnología a los negocios
 Menos problemas de
tecnología.
UNPSJB -2005
Enfoque en reingeniería de
procesos de negocio




Mas atención a sus negocios.
Se dejan los Sistemas y
Funciones  se habla de la
Información.
Presupuesto ajustado.
Demanda de desarrollo rápido.
Abandono del ciclo de vida en
cascada

Se necesita una metodología
para identificar hitos.
Ingeniería de Software - Clase 2
52
¿En que usan las compañías JAD?







Reingeniería de procesos de negocio.
Modelado de datos.
Diseño de nuevos sistemas.
Modificaciones a un sistema existente.
Automatización de procesos manuales.
Conversiones.
Adquisiciones.
UNPSJB -2005
Ingeniería de Software - Clase 2
53
Factores de incidencia en una sesión

Incidencia Negativa



Ahorrar participantes.
Extender la duración de
las sesiones.
Ignorar a las personas
con
menos
autoridad.
(Cuando se nota la jerarquía
de la organización).

Usar un
entrenar.
facilitador
proyecto).

Abandonar
autoridad.
UNPSJB -2005
facilitador
(Ya
que
es el eje
su
sin
el
del


Equivocarse en las
herramientas de alta
tecnología.
Enredarse con modelados.
(Técnicas que confunden a los
participantes).


Usar palabras que no
entienden todos.
Tardar mucho en entregar el
documento final.
propia
Ingeniería de Software - Clase 2
54
Los 10 mandamientos de JAD
1.
2.
3.
4.
5.
El éxito de JAD depende
del empeño
administrativo.
Los participantes deben
asistir a la sesión entera.
El éxito de JAD requiere
un facilitador entrenado.
Asegurarse de tener a
las personas correctas
en la sesión
Todos los participantes
son iguales.
UNPSJB -2005
6.
7.
8.
9.
10.
La preparación es tan
importante como la
sesión.
Hacer una buena agenda
y adherirse a ella.
Usar técnicas y
herramientas apropiadas
en la sesión.
Mantener la jerga técnica
al mínimo.
Producir un documento
final rápido y de calidad.
Ingeniería de Software - Clase 2
55
Tener a las personas correctas en
el salón

Algunas preguntas


¿Cuáles con las
consecuencias de no tener
a las personas adecuadas
en la sesión?
 Va en contra del concepto
de JAD  Se debe
cambiar la planificación.
¿Qué pasaría si falta
alguien?
 Se debe crear una lista
con las preguntas para
esa persona.
UNPSJB -2005


Hay que asegurarse de
incluir a las personas que
usan los procesos (los que
leen reportes, entran los
datos y ven las pantallas).
¿Cuántas personas deben
asistir a la sesión?
 Entre 7 y 15.
Ingeniería de Software - Clase 2
56
Como manejar los conflictos






Hay conflictos ventajosos  son productivos y no
deben reprimirse.
Conflictos de estancamiento  la discusión va a un
callejón sin salida.
Y conflictos dogmáticos  cuando el ego está por
encima de la discusión.
Es necesario eliminarlos o la sesión fracasará.
Los conflictos entre los usuarios y los IS deben
manejarse distinto. El foco está en quien está en el
conflicto en lugar de que es el conflicto.
Se deben sofocar las conversaciones de subgrupos.
La integridad del grupo se disuelve cuando emergen
los subgrupos.
UNPSJB -2005
Ingeniería de Software - Clase 2
57
Equipo de JAD y como seleccionarlo


El éxito depende de los
participantes.
Hay dos etapas:
1.
2.
UNPSJB -2005
Seleccionar el Facilitador y el
Coordinador Ejecutivo.
Seleccionar los otro miembros del
grupo.
Ingeniería de Software - Clase 2
58
Equipo de JAD y como seleccionarlo

Coordinador Ejecutivo




UNPSJB -2005
Controla el capital del
proyecto.
Da visión y dirección
al proyecto.
Autoriza a otras
personas a tomar
decisiones.
Debe tener autoridad
para tomar
decisiones y una
personalidad
correcta.

Funciones
 Antes de la sesión: Junto
con el facilitador definen el
propósito, finalidad,
objetivo y estrategias
totales del proyecto.
 Durante la sesión: Puede
estar presente o no. Si no
está, se lo debe poder
localizar.
 Después de la sesión: Lo
único que hace es firmar y
recibir copias de las
resoluciones
Ingeniería de Software - Clase 2
59
Equipo de JAD y como seleccionarlo

FACILITADOR:
 Debe ser imparcial y
objetiva.
 Guía al grupo a través
de todo el proceso.
 No se interesa en el
resultado sino en
trabajar eficazmente.
 Debería tener buena
comunicación, liderar
al grupo, etc.
UNPSJB -2005

Funciones



Antes de la sesión: Guía
entrevistas con el Coordinador y
con el área de negocios
relacionada. Prepara la agenda y
ayudas.
Durante la sesión: Guía a los
participantes de acuerdo a la
agenda y mantiene la sesión en
curso.
Después de la sesión: Revisa la
creación y distribución del
documento final
Ingeniería de Software - Clase 2
60
Equipo de JAD y como seleccionarlo

NOTARIO:



Registra todas las
decisiones.
Necesita una gran
capacidad analítica.
Mantiene las
“memorias” del grupo.

Funciones



UNPSJB -2005
Antes de la sesión: El
facilitador le comunica su
rol y que herramientas se
usarán.
Durante la sesión: El
facilitador le indica cuando
o que debe escribir.
Después de la sesión:
Revisa las notas con el
Facilitador y ayuda a
preparar el documento
final
Ingeniería de Software - Clase 2
61
Equipo de JAD y como seleccionarlo

Participantes Full-Time:



Participantes Part-Time:

UNPSJB -2005
Todos los involucrados en la toma de
decisiones del proyecto.
Estos son el vicepresidente,
programadores, supervisor, gerente, etc.
Son los que no tienen que estar en todas
las sesiones.
Ingeniería de Software - Clase 2
62
Fases del JAD

Se diferencian 5 fases:
1.
2.
3.
4.
5.
UNPSJB -2005
Definición del proyecto.
Investigación.
Preparación.
La Sesión.
El Documento Final.
Ingeniería de Software - Clase 2
63
Fases del JAD

Fase 1: Definición del
proyecto



Antes que nada, necesitamos
saber que quiere la empresa.
Con esto podemos producir la
“Guía 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.
UNPSJB -2005

Posibles preguntas
¿Como se origino el
proyecto?
 ¿Cuales son sus
principales problemas?
 ¿Qué beneficios desea
obtener con el
proyecto?
 ¿Qué limitaciones
deberíamos
considerar?

Ingeniería de Software - Clase 2
64
Fases del JAD

Definición de la empresa
Desde la perspectiva de la empresa.
 Posee el propósito, alcance y objetivos del
proyecto.


Programando la sesión
El tiempo depende del proyecto. Por lo
gral., de 3 a 5 días.
 Pueden ser sesiones de medio día o de
día entero (hace el proyecto mas corto).

UNPSJB -2005
Ingeniería de Software - Clase 2
65
Fases del JAD

Fase 2: Investigación
 Familiarizarnos con el área de trabajo de la
empresa.





Documentar requerimientos de datos.
Documentar procesos de trabajo.
Recolectar información preliminar.
Repasar la agenda de la sesión.
Familiarisarse con la empresa
Obtener puntos de vista más técnicos,
 Consultas con personal externo que sirva de
ayuda

UNPSJB -2005
Ingeniería de Software - Clase 2
66
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.
UNPSJB -2005

Documentar proceso
de trabajo
 Define las reglas
para usar los datos.
 Se puede usar
diagramas de
descomposición,
diagramas
dependientes o
matrices.
 Para capturar los
procesos de trabajo
se usan los DFD.
Ingeniería de Software - Clase 2
67
Fases del JAD

Fase 3: Preparación
 Compilar toda la información obtenida
en un documento (el documento de
trabajo)
 Entrenar al Notario.
 Crear ayudas visuales.
 Realizar una reunión de pre-sesión.
 Montar la sala para la sesión.
UNPSJB -2005
Ingeniería de Software - Clase 2
68
Fases del JAD

Documento
 Debe tener la
información recogida
para ser usado en la
sesión.


UNPSJB -2005

Es un punto de partida
para la toma de
decisiones.
No se debe confundir
con el documento final
ya que este documentc.
solo es propuesto.
Aunque debería estar en
el mismo formato que el
documento final.
Ingeniería de Software - Clase 2
El Notario debe
 Conocer su su
rol.
 Describirle el
proceso de JAD.
 Discutir el
proyecto.
 Describir la
sesión.
 Luego de cada
sesión hay que
encontrarse con
el notario para
revisar las notas.
69
Fases del JAD

Ayudas visuales
Ayudan a mantener a los participantes
enfocados y pueden clarificar las
decisiones tomadas.
 Ej:






UNPSJB -2005
Diagramas
Cañones
Proyectores.
Pizarrones
Digitalizadores, etc.
Ingeniería de Software - Clase 2
70
Fases del JAD

Fase 4: Sesión


Es el principal evento del proceso JAD.
Para toda la sesión vamos a usar una
agenda que tiene:
Discutir suposiciones.
 Definir requerimientos de datos.
 Diseñar procesos de trabajo.
 Diseñar pantallas.
 Resolver discusiones abiertas.

UNPSJB -2005
Ingeniería de Software - Clase 2
71
Fases del JAD

Abriendo la sesión
 Al principio se debe
exponer:




UNPSJB -2005
Items Administrativos:
Como será la sesión
(Horarios, habitaciones de
descanso, etc.)
Objetivos de la sesión:
Que se quiere lograr.
La agenda de la sesión:
Recorrer la agenda
explicando como se va a
manejar cada ítem.
Reglas fundamentales:
Habla uno por vez, etc.


Ingeniería de Software - Clase 2
“Vista panorámica” del
trabajo.
Guía de Definición de la
Empresa: Aunque los
participantes la
recibieron antes de la
sesión hay que revisar
los puntos mas
importantes.
72
Fases del JAD

Suposiciones
 Las suposiciones se
acumulan desde el
comienzo del JAD.
 Están todas listadas en
el documento de
trabajo.
 Se lee cada suposición
al grupo para discutirla,
pudiendo quedar como
está, ser revisada o se
convierte en una
discusión abierta.
UNPSJB -2005

Requerimientos de
datos
 Puede ir desde un
completo modelo de
datos a definir solo
unos nuevos
elementos de datos.
 DER general, guiado
Ingeniería de Software - Clase 2
73
Fases del JAD

Proceso de trabajo
 Antes de la sesión, se
los identifica y se
documentan con DFD,
pasando al doc. de trabajo
y a transparencias.
 En la sesión, se discuten
sin que, por lo general, se
produzcan grandes
cambios. Pero pueden
aparecer nuevos DFD que
pueden causar debate.
 Es importante definirlo en
pequeños grupos.
UNPSJB -2005

Pantallas
 Los puntos más
importantes son:





Flujo de pantalla.
Diseño de pantallas.
Diseño de pantallas
GUI.
Reportes
 Similar a las
pantallas
El objetivo es evaluar
la ES del sistema
Ingeniería de Software - Clase 2
74
Fases del JAD


Discusiones abiertas
 Sirven para profundizar
un tema
 No necesariamente hay
que seguir una agenda
predefinida
 Debe cuidarse de no irse
por las ramas
Evaluación de la sesión
 Se mide el suceso y la
satisfacción del los
participantes  Se usa
principalmente en los
primeros proyectos.
UNPSJB -2005


Se entrega un formulario a los
participantes para evaluarlos
después de la sesión.
Cerrando al sesión, se debe
1.
2.
3.
Determinar quien recibirá al
doc. final (se crea la “lista de
distribución final”.)
Discutir como los participantes
van a revisar el documento
(que le revisen para ver si lo
quieren modificar).
Dar algunos puntos de cierre
(palabras de agradecimiento
hacia los participantes.)
Ingeniería de Software - Clase 2
75
Fases del JAD

Fase 5: El documento final



En esta fase final del JAD se pasan todos lo
acuerdos de la sesión al documento final.
Se calcula que por cada día de sesión se
debe tomar de uno a un día y medio para
documentar lo hecho.
Por que el documento final es importante


UNPSJB -2005
Es un síntesis comprensiva de todo lo hecho.
Para los que no estuvieron en la sesión y
forman parte del proyecto, puede ser una de
los únicos elementos para juzgar al proyecto
después de la sesión.
Ingeniería de Software - Clase 2
76
Fases del JAD

Qué debe tener el
documento final
 Se usan tablas para
presentar la información.
 Como ser:



UNPSJB -2005

Tablas de decisión.
Tablas de procedimientos
(para cuando necesitamos
explicar como hacer algo).
Tablas de procesos
(además de como hacer
algo tiene quien hace cada
paso).
Ingeniería de Software - Clase 2
Como debe
escribirse
 Se mira del lado
del que lo va a
leer
preguntando:


Lo entenderá?
Está en español
claro?, etc.
77
Fases del JAD

La reunión de revisión
Se revisa el documento página por página.
 Puede surgir comentarios de todo tipo (que se
debería cambiar algo, que hay que agregar una
columna a un reporte, etc.)
 Al final de esta reunión se determina como se
manejan los cambios (si hay que reimprimir el
documento o no).


Obtener el OK final

UNPSJB -2005
Para esto se firma el formulario de
aprobación.
Ingeniería de Software - Clase 2
78
Ideas para aplicar con JAD

Brainstorming




UNPSJB -2005
Es una técnica de reuniones en grupo cuyo
objetivo es generar ideas en un ambiente libre
de criticas.
En las sesión suele haber entre 4 a 10
participantes (uno es el Facilitador).
Como técnica de obtención de requisitos,
puede ayudar a generar una gran variedad de
vistas del problema y a formularlo de
diferentes maneras
Hay que tener en cuenta que en la sesión, se
puede hacer un Brainstorming cuando se crea
conveniente y todas las veces que haga falta.
Ingeniería de Software - Clase 2
79
Ideas para aplicar con JAD

Prototipos


¿Como se adaptan al proceso
de JAD?




Son una pareja perfecta.
Por ej., una vez definidas
la pantallas, menús y
diálogos en la sesión de
JAD, se le dice a los IS que
construyan en el prototipo.
Usando herramientas de
prototipo el desarrollador
traduce los requisitos en
un sistema que este
funcionando.
Se puede hacer otra sesión
para refinarlo
UNPSJB -2005
Precauciones



No acortar el análisis y
diseño del sistema: Hay
que asegurarse que el
ciclo de vida este
completo. Si el diseño es
incompleto  el Prototipo
es incompleto.
Los prototipos no son el
sistema final (Puede crear
falsas expectativas en los
usuarios).
Saber cuando parar: No
se debe caer en un ciclo
de cambios que nos
impida ver el sistema real.
Ingeniería de Software - Clase 2
80
JAD a lo largo del ciclo de vida



UNPSJB -2005
A lo largo del ciclo de vida, se
puede utilizar JAD en cualquier
etapa de desarrollo.
No significa usar JAD para el
desarrollo de todos los sistemas
Generalmente las organizaciones
usan JAD en las primeras fases del
ciclo de vida.
Ingeniería de Software - Clase 2
81
JAD a lo largo del ciclo de vida
Donde aplicar JAD




Definición del proyecto

Se monta el
escenario para el
resto de las fases
del proyecto.
Requerimientos

Con las reuniones
definidas
Evaluación de
paquetes de soft
UNPSJB -2005

Diseño externo.



Define la “vista de
usuario” de la aplicación.
Incluye diseño de pantalla,
planes de prueba,
reportes, interfases, etc.
Codificación y prueba de
validación.

Los participantes buscan
posibles conflictos en el
código o datos y los
documentan en términos
métricos.
Ingeniería de Software - Clase 2
82
JAD a lo largo del ciclo de vida
 Evaluación
post implementación.
 Mide el éxito del sistema desde
dos puntos de vista: negocios y
IS.
 Pueden
analizar las
siguientes preguntas:

Mantenimiento
 Correctivo
 Perfectivo
 Adaptativo
 Hay que entender las
nuevas necesidades
Están las interfases en el lugar
correcto y funcionamiento
pleno?
 ¿Son adecuados los
procedimientos de backup?
 ¿Qué tan compatible es la
documentación?, etc.

UNPSJB -2005
Ingeniería de Software - Clase 2
83
Criterios de JAD

Por ejemplo, los criterios deberían
decir, JAD debería ser usado para
proyectos que:




UNPSJB -2005
Tengan una alta prioridad de trabajo.
Tengan un fuerte objetivo de datos.
Involucre requisitos complejos.
Impacte mas que un departamento.
Ingeniería de Software - Clase 2
84
Medir éxito de JAD



UNPSJB -2005
Es muy difícil 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 desafío de
diseño para que lo realicen en el modo
tradicional.
Se hicieron pruebas, estos son los
resultados obtenidos:
Ingeniería de Software - Clase 2
85
Midiendo JAD, resultados de
productividad
6
5.2
5
4
2.5
Horas
3
por PF
2
NO uso JAD
Uso JAD
1
0
Proyectos
UNPSJB -2005
Ingeniería de Software - Clase 2
86
Ejercicios para la clase próxima

Investigar sobre



RAD
Brainstorming
Análisis de Riesgo


UNPSJB -2005
Dos alumnos sobre cada tema
Leer el paper T
Ingeniería de Software - Clase 2
87