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