Clase 2 Iesgos

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
 Clasificación
 Identificación, Proyección, Supervisión y Gestión del
Riesgo
 Plan de Riesgo
 Estudio de Casos
 Propuesta del SEI
 JAD (joint application development)
 Definición
 Actores
 Desarrollo
UNPSJB -2005 Ingeniería de Software - Clase 2 2

Contenido Clase 2
 Bibliografía utilizada
 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

A.Riesgo - Introducción
 Qué es el Riesgo?
 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”

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

A.Riesgo - Clasificación
 Características del Riesgo:
 Incertidumbre: ocurrencia o no del caso
 Pérdida: si se hace realidad consecuencias no
deseadas que llevan a eventuales pérdidas.
 Primer clasificación de riesgos
 riesgos del proyecto. Característica:
 amenazan la existencia del proyecto
 afectan la planificación temporal, retrasos y

aumento de costos

 Riesgos técnicos.  Que puede ocurrir:

Características:  hacer un software
excelente que nadie use
 amenazan la calidad y
(de mercado)
planificación temporal
 hacer un software que no
 afecta la realización del sirva al cliente
proyecto (haciéndolo (estratégico)
eventualmente inviable)  Hacer un software que no
 Riesgos del negocio. se pueda vender
 perder apoyo del cliente
Características:
ante un cambio en la
 amenazan la viabilidad del dirección de la compañía
software a construir (de dirección)
 ponen en peligro el proyecto  perder presupuesto o
o el producto. personal asignado (de
presupuesto)

 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 Proyecto El hard esencial para el proyecto no será

hardware entregado a tiempo
Cambio de requerimientos Proyecto y Habrá más cambios en los requerimientos

producto que lo anticipado
Retraso en la especificación Proyecto y Las especificaciones de las interfaces

producto 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 Producto La- herramienta
Ingeniería de Software Clase 2 CASE no tiene el 8
herramienta CASE desempeño anticipado
 Segunda clasificación  Tercer clasificación:

 riesgos conocidos. Se pueden  Jones caracteriza los
determinar con: 60 casos de riesgo
 evaluación del plan de  Comunes y serios
proyecto
 Desarrollaremos
 evaluación del entorno
técnico y comercial posteriormente
 otras fuentes de información
 Riesgos predecibles: utiliza

experiencia de proyectos
anteriores.
 Riesgos Impredecibles.

A.Riesgo - Plan de riesgo
 4 etapas del plan de riesgo
 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

 El proceso de administración de
riesgos en forma gráfica
Identificación Análisis de planeación de Supervisión de

de riesgos riesgos Riesgos riesgos
Anulación de
Listado de riesgos Listado de priori- Valoración de
riesgos y planes
potenciales zación de riesgos riesgos
de contintencia

 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

 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
 tamaño estimado del producto en LDC o PF?
 Grado de seguridad de la estimación de
tamaño
 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
 Riesgos del impacto en el negocio
genéricos
 efecto del producto en los ingresos de la
compañía

 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:

 Necesidades diferentes, personalidades diferentes,
se contradicen muy a menudo.
 Lista de comprobación de riesgos genéricos
 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

 Riesgos del proceso
 SEI propone un cuestionario que evalúa
 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.
 Aspectos técnicos
 se técnicas de especificación de aplicaciones
para ayudar a la comunicación cliente-

desarrollador
 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,..

 Riesgos tecnológicos
 Lista de comprobación de riesgos genéricos
 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?

 Riesgos del entorno de desarrollo
genéricos
 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
 Riesgos asociados con la plantilla
genéricos
 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é?
 Proyección del riesgo

 actividades
 establecer una escala de probabilidad de
ocurrencia
 examinar el impacto del 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.

tabla de Bohem
Rendimiento Soporte Costo Plan Temporal

Catastró Degradación que El software no Recortes finan- Fecha de entrega
-fico lleva a no alcan- responde o no cieros duros pre- inalcanzable
zar rendimiento admite soporte supuesto excedi-
técnico do
Crítico Alguna reducción Pequeños retrasos Algún recorte en Posibles retrasos
en el rendimiento en modificacio- rec. Financieros, de la fecha de
técnico nes de software| posibles excesos entrega.
en presupuesto
Marginal De mínima a pe- El soporte del Recursos finan- Planificación
queña reducción software respon- cieros suficien- temporal realis-
en el rendimiento de tes ta, alcanzable
técnico
Despre- No hay reducción Software fácil de Psible superávit Fecha de entrega
ciable en el rendimiento dar soporte de presupuesto fácilmente alcan-
técnico zable

 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

 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

 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

 Gestión del riesgo

 evaluar las situaciones que se dan a lo
largo del proceso de desarrollo
 actuar con los planes de contingencia
ante situaciones problemáticas

A.R. - Valoración de proyectos
 Metodología SRP (software

productivity research)
 Tipos de proyecto valorables
 militares, comerciales, expertos, etc.
 Factores a evaluar
 Factores estratégicos: impactan en
toda la empresa, relacionados con las
políticas corporativas. Casos:

 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

 Espacio disponible en las oficinas de trabajo
 métodos de comunicación (workflows,
groupware)
 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

 Actividades
 recolección de datos

 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

 Escala de influencia (similar a CMM)
1 excelente
2 bueno
3 promedio
4 mediocre
5 pobre
 Datos “duros” obtenidos
 tamaño de las especificaciones y
documentaciones
 PF totales del proyecto

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.)

 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

 Riesgos comunes por tipo de proyectos
 Sistemas de información
 obtener los requerimientos de usuario (80%)
 esquemas excesivamente presionantes
(65%)
 baja calidad (60%)
 sobrepaso en costos (55%)
 inadecuada configuración de control (50%)
 Software de sistemas
 esquemas largos (70%)
 estimación de costos inadecuada (65%)

 Excesivo papeleo (60%)
 módulos proclives a error (50%)
 proyectos cancelados (35%)
 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
 papeleo excesivo (90%)

 Baja productividad (85%)
 esquemas largos (75%)
 obtención de requerimientos de usuario
(70%)
 software no usado o no usable (45%)
 Software subcontratado
 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%)

 Software para usuarios finales
 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%)
 prevención y control de riesgos
comunes
 obtención de requerimientos de usuario:
JAD, prototipación rápida

 Esquemas largos, esquemas presionantes,
excesivo tiempo de marketing
 hacer mejor la planificación y estimación usando
mejores herramientas
 reducir la duración del esquema
 reutilizar, métodos OO, CASE
 Exceso en los costos: similar a problemas con
es esquema (excederse en tiempo). Medir
mejor
 Baja de calidad y módulos que concentran
errores:
 mejorar la estimación de calidad y confiabilidad
 métodos de prevención de defectos (mejores
pruebas)

 Métodos de remoción de defectos
 Programas para medir calidad
 Grandes costos de mantenimiento
 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

 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

 Esquemas excesivamente presionantes.

 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

 baja productividad
 proyectos cancelados
 SPR: estudio de 60 casos,

importante
 alcance de cada caso
 forma de prevenirlo
 método de control
 planes de contingencia
 evaluar otros riesgos afectados.

 Que evalúa SPR y

Jones?
 Define el riesgo  Impacto en los
 Estudia costos
 Severidad  Métodos de
 Frecuencia
prevención
 Métodos de control
 Ocurrencia
 Efectividad de
 Susceptibilidad y
resistencia soluciones conocidas
 Costo de estas
 Causas que lo originan
soluciones
 Problemas asociados
 Pronostico a largo
UNPSJB -2005 Ingeniería de Software - Clase 2 plazo 44

Algunos ejemplos  Severidad 4: proyecto cancelado

durante las etapas tempranas o
 Proyectos cancelados intermedias de diseño.
 proyectos que son terminados  Severidad 5: proyecto cancelado
antes de llegar al usuario final durante la última etapa de
 Severidad: la severidad requerimiento y la primera de
promedio de proyectos diseño.
cancelados es 2.5  Frecuencia: está correlacionado
 Severidad 1: proyecto cancelado con el tamaño del proyecto (a
durante la fase final de testeo
mayor PF por proyecto mayor la
 Severidad 2: proyecto cancelado
durante la última etapa de probabilidad de cancelación).
codificación y primera de test  Ocurrencia: muy común en
 Severidad 3: proyecto cancelado proyectos militares y proyectos de
durante la última etapa diseño y
primera de codificación comunicaciones.

 Susceptibilidad y  Problemas asociados:
resistencia: los  traen asociados
proyectos que tienden a fricciones con el usuario
irse fuera de control y con los directivos.
son los más peligrosos  Pueden bajar la moral
para su cancelación. de la empresa, de los
 Causas raíces: son varias empleados, etc.
 proyecto mal planeado, y  La cancelación es
estimado debido a factores como:
 el desarrollo tarda mala planificación,
demasiado, la situación de inadecuada estimación
negocios o técnica cambia de costos, esquemas
y hace el proyecto inviable perdidos, esquemas
 se comienzan dos o más largos, sobrepaso de
proyectos similares y solo costos, baja calidad y
el ganador sobrevive
productividad, etc.
 factores externos como la
venta del negocio

 Impacto de costos: es alarmante y  Efectividad de soluciones
serio. Cuanto más tarde se cancele conocidas: esquemas y
el proyecto mayor habrán sido los estimación de riesgo son las
gastos producidos mejores herramientas. Estas
 Métodos de prevención: un buen se pueden realizar con
plan de trabajo y cuidadosa software existentes en el
estimación, hay herramientas que mercado.
ayudan a esto.  Costo de soluciones
 Métodos de control: para proyectos conocidas: depende
de más de 5000 PF con mal directamente de la
relevamiento inicial de herramienta/s utilizada/s.
requerimientos es imposible el  Pronósticos de largo alcance:
control. El plan y la estimación es esperable que se sigan
solo para proyectos con cancelando proyectos, si bien
requerimientos estables la utilización de las
desarrollados en forma competente herramientas de predicción
usando una estructura tendrán como resultado una
metodológica. involucrado. reducción de dicho porcentaje.
¿Qué es JAD?
 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.

¿Qué es JAD?
 La sesión involucra:
 Agenda detallada.
 Ayuda visual.
 Facilitador.
 Escritor (llamado Notario).
 El resultado es un Documento final.

Diseño de sistemas usando JAD
 Esta metodología tiene como

características:
 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

Fases del JAD
 JAD se divide en cinco fases:

 Definición del proyecto.
 Investigación.
 Preparación.
 La sesión.
 El documento final.

Tendencia a usar JAD
 La compañías se vuelcan a
JAD por:
 Aparecen equipos  Mas atención a sus negocios.
 Jerarquías  Equipo.  Enfoque en reingeniería de
 Otro enfoque en calidad y procesos de negocio
productividad.  Se dejan los Sistemas y
 Usuarios más inteligentes: Funciones  se habla de la
 Mas dispuestos a
Información.
participar en el  Presupuesto ajustado.
desarrollo de  Demanda de desarrollo rápido.
aplicaciones.
 Abandono del ciclo de vida en
 Desplazamiento de la
tecnología a los negocios
cascada
 Menos problemas de
 Se necesita una metodología
tecnología. para identificar hitos.

¿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.

Factores de incidencia en una sesión
 Incidencia Negativa
 Ahorrar participantes.  Equivocarse en las
 Extender la duración de herramientas de alta
las sesiones. tecnología.
 Ignorar a las personas  Enredarse con modelados.
con menos autoridad. (Técnicas que confunden a los
(Cuando se nota la jerarquía participantes).
de la organización).
 Usar palabras que no
 Usar un facilitador sin entienden todos.
entrenar. (Ya que el
facilitador es el eje del  Tardar mucho en entregar el
proyecto). documento final.
 Abandonar su propia
autoridad.

Los 10 mandamientos de JAD
1. El éxito de JAD depende 6. La preparación es tan
del empeño importante como la
administrativo. sesión.
7. Hacer una buena agenda
2. Los participantes deben
y adherirse a ella.
asistir a la sesión entera.
8. Usar técnicas y
3. El éxito de JAD requiere herramientas apropiadas
un facilitador entrenado. en la sesión.
4. Asegurarse de tener a 9. Mantener la jerga técnica
las personas correctas al mínimo.
en la sesión 10. Producir un documento
5. Todos los participantes final rápido y de calidad.
son iguales.

Tener a las personas correctas en
el salón
 Algunas preguntas
 ¿Cuáles con las
 Hay que asegurarse de
consecuencias de no tener incluir a las personas que
a las personas adecuadas usan los procesos (los que
en la sesión? leen reportes, entran los
 Va en contra del concepto datos y ven las pantallas).
de JAD  Se debe  ¿Cuántas personas deben
cambiar la planificación. asistir a la sesión?
 ¿Qué pasaría si falta  Entre 7 y 15.
alguien?
 Se debe crear una lista
con las preguntas para
esa persona.
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.

Equipo de JAD y como seleccionarlo
 El éxito depende de los

participantes.
 Hay dos etapas:
1. Seleccionar el Facilitador y el
Coordinador Ejecutivo.
2. Seleccionar los otro miembros del
grupo.

 Coordinador Ejecutivo
 Controla el capital del  Funciones
proyecto.  Antes de la sesión: Junto
 Da visión y dirección con el facilitador definen el
al proyecto. propósito, finalidad,
 Autoriza a otras objetivo y estrategias
personas a tomar totales del proyecto.
decisiones.  Durante la sesión: Puede
estar presente o no. Si no
 Debe tener autoridad
está, se lo debe poder
para tomar localizar.
decisiones y una
 Después de la sesión: Lo
personalidad
único que hace es firmar y
correcta.
recibir copias de las
resoluciones
 FACILITADOR:
 Debe ser imparcial y
 Funciones
objetiva.  Antes de la sesión: Guía
entrevistas con el Coordinador y
 Guía al grupo a través
con el área de negocios
de todo el proceso. relacionada. Prepara la agenda y
 No se interesa en el ayudas.
resultado sino en  Durante la sesión: Guía a los
trabajar eficazmente. participantes de acuerdo a la
 Debería tener buena
agenda y mantiene la sesión en
curso.
comunicación, liderar
al grupo, etc.  Después de la sesión: Revisa la
creación y distribución del
documento final
 NOTARIO:
 Registra todas las  Funciones
decisiones.  Antes de la sesión: El
facilitador le comunica su
 Necesita una gran rol y que herramientas se
capacidad analítica. usarán.
 Mantiene las  Durante la sesión: El
facilitador le indica cuando
“memorias” del grupo. o que debe escribir.
 Después de la sesión:
Revisa las notas con el
Facilitador y ayuda a
preparar el documento
final

 Participantes Full-Time:
 Todos los involucrados en la toma de
decisiones del proyecto.
 Estos son el vicepresidente,
programadores, supervisor, gerente, etc.
 Participantes Part-Time:
 Son los que no tienen que estar en todas
las sesiones.

Fases del JAD
 Se diferencian 5 fases:
1. Definición del proyecto.
2. Investigación.
3. Preparación.
4. La Sesión.
5. El Documento Final.

Fases del JAD
 Fase 1: Definición del
proyecto
 Antes que nada, necesitamos  Posibles preguntas
saber que quiere la empresa.  ¿Como se origino el
 Con esto podemos producir la proyecto?
“Guía de Definiciones de la
 ¿Cuales son sus
Empresa”, seleccionar el
equipo de JAD y programar las principales problemas?
sesiones  ¿Qué beneficios desea
 Se debe entrevistar al obtener con el
Coordinador Ejecutivo y los proyecto?
jefes de las áreas de negocios
involucradas con el proyecto.  ¿Qué limitaciones
deberíamos
considerar?
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).

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
Fases del JAD
 Documentar  Documentar proceso
Requerimientos de trabajo
 Identificar los grupos de  Define las reglas
datos usados en el área para usar los datos.
de trabajo.  Se puede usar
 Definir los nombres y diagramas de
descripciones de los descomposición,
datos elementales. diagramas
 Definir relaciones. dependientes o
matrices.
 Definir una estructura
correcta para los datos.  Para capturar los
procesos de trabajo
se usan los DFD.

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.

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

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.

Fases del JAD
 Abriendo la sesión
 “Vista panorámica” del
 Al principio se debe
trabajo.
exponer:
 Guía de Definición de la
 Items Administrativos:
Como será la sesión Empresa: Aunque los
(Horarios, habitaciones de participantes la
descanso, etc.) recibieron antes de la
 Objetivos de la sesión: sesión hay que revisar
Que se quiere lograr. los puntos mas
 La agenda de la sesión: importantes.
Recorrer la agenda
explicando como se va a
manejar cada ítem.
 Reglas fundamentales:
Habla uno por vez, etc.

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

Fases del JAD
 Proceso de trabajo  Pantallas
 Antes de la sesión, se  Los puntos más
los identifica y se importantes son:
documentan con DFD,  Flujo de pantalla.
pasando al doc. de trabajo  Diseño de pantallas.
y a transparencias.  Diseño de pantallas
 En la sesión, se discuten GUI.
sin que, por lo general, se  Reportes
produzcan grandes  Similar a las
cambios. Pero pueden pantallas
aparecer nuevos DFD que
pueden causar debate.
 Es importante definirlo en
 El objetivo es evaluar
pequeños grupos. la ES del sistema

Fases del JAD
 Discusiones abiertas  Se entrega un formulario a los
 Sirven para profundizar participantes para evaluarlos
un tema después de la sesión.
 No necesariamente hay  Cerrando al sesión, se debe
que seguir una agenda 1. Determinar quien recibirá al
predefinida doc. final (se crea la “lista de
 Debe cuidarse de no irse
distribución final”.)
por las ramas 2. Discutir como los participantes
van a revisar el documento
 Evaluación de la sesión (que le revisen para ver si lo
 Se mide el suceso y la quieren modificar).
satisfacción del los 3. Dar algunos puntos de cierre
participantes  Se usa (palabras de agradecimiento
principalmente en los hacia los participantes.)
primeros proyectos.

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
 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.

Fases del JAD
 Qué debe tener el  Como debe
documento final escribirse
 Se usan tablas para  Se mira del lado
presentar la información. del que lo va a
 Como ser: leer
 Tablas de decisión. preguntando:
 Tablas de procedimientos  Lo entenderá?
(para cuando necesitamos  Está en español
explicar como hacer algo). claro?, etc.
 Tablas de procesos
(además de como hacer
algo tiene quien hace cada
paso).

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
 Para esto se firma el formulario de
aprobación.

Ideas para aplicar con JAD
 Brainstorming
 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.

Ideas para aplicar con JAD
 Prototipos  Precauciones
 ¿Como se adaptan al proceso  No acortar el análisis y
de JAD? diseño del sistema: Hay
 Son una pareja perfecta. que asegurarse que el
ciclo de vida este
 Por ej., una vez definidas completo. Si el diseño es
la pantallas, menús y incompleto  el Prototipo
diálogos en la sesión de es incompleto.
JAD, se le dice a los IS que
construyan en el prototipo.  Los prototipos no son el
sistema final (Puede crear
 Usando herramientas de falsas expectativas en los
prototipo el desarrollador usuarios).
traduce los requisitos en
un sistema que este  Saber cuando parar: No
funcionando. se debe caer en un ciclo
de cambios que nos
 Se puede hacer otra sesión impida ver el sistema real.
para refinarlo

JAD a lo largo del ciclo de vida
 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.

 Donde aplicar JAD  Diseño externo.
 Definición del proyecto  Define la “vista de
 Se monta el usuario” de la aplicación.
escenario para el  Incluye diseño de pantalla,
resto de las fases planes de prueba,
del proyecto. reportes, interfases, etc.
 Codificación y prueba de
 Requerimientos
validación.
 Con las reuniones  Los participantes buscan
definidas posibles conflictos en el
 Evaluación de código o datos y los
documentan en términos
paquetes de soft métricos.

 Evaluación post implementación.  Mantenimiento

 Mide el éxito del sistema desde  Correctivo
dos puntos de vista: negocios y  Perfectivo
IS.  Adaptativo
 Pueden analizar las  Hay que entender las
siguientes preguntas: 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.
Criterios de JAD
 Por ejemplo, los criterios deberían

decir, JAD debería ser usado para
proyectos que:
 Tengan una alta prioridad de trabajo.
 Tengan un fuerte objetivo de datos.
 Involucre requisitos complejos.
 Impacte mas que un departamento.

Medir éxito de JAD
 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:

Midiendo JAD, resultados de
productividad
5.2
6
5
4
Horas 2.5
3 NO uso JAD
por PF
Uso JAD
2
1
0
Proyectos

Ejercicios para la clase próxima
 Investigar sobre
 RAD
 Brainstorming
 Análisis de Riesgo
 Dos alumnos sobre cada tema
 Leer el paper T

Clase 2 Iesgos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 2 Iesgos

Cargado por

Copyright:

Formatos disponibles

Ingeniería de Software

UNPSJB -2005 Ingeniería de Software - Clase 2 2

UNPSJB -2005 Ingeniería de Software - Clase 2 3

 “Mientras es inútil intentar eliminar el

UNPSJB -2005 Ingeniería de Software - Clase 2 4

 Riesgos Reactivos y proactivos

UNPSJB -2005 Ingeniería de Software - Clase 2 5

 afectan la planificación temporal, retrasos y

UNPSJB -2005 Ingeniería de Software - Clase 2 6

 Riesgos técnicos.  Que puede ocurrir:

UNPSJB -2005 Ingeniería de Software - Clase 2 7

 Riesgos posibles, ejemplos

Rotación del personal Proyecto Personal con experiencia abandona el

Cambio de administración Proyecto Habrá un cambio de administración

No disponibilidad de Proyecto El hard esencial para el proyecto no será

Cambio de requerimientos Proyecto y Habrá más cambios en los requerimientos

Retraso en la especificación Proyecto y Las especificaciones de las interfaces

Cambio de tecnología Negocio La tecnología fundamental sobre la que se

 Segunda clasificación  Tercer clasificación:

 Riesgos predecibles: utiliza

UNPSJB -2005 Ingeniería de Software - Clase 2 9

UNPSJB -2005 Ingeniería de Software - Clase 2 10

Identificación Análisis de planeación de Supervisión de

UNPSJB -2005 Ingeniería de Software - Clase 2 11

 características del cliente

UNPSJB -2005 Ingeniería de Software - Clase 2 12

 tamaño y experiencia de la plantilla

 Riesgos asociados al tamaño del

UNPSJB -2005 Ingeniería de Software - Clase 2 14

UNPSJB -2005 Ingeniería de Software - Clase 2 15

UNPSJB -2005 Ingeniería de Software - Clase 2 16

 están todos de acuerdo con el proceso a

para ayudar a la comunicación cliente-

 se documenta adecuadamente el código

 se emplean herramientas adecuadas para:

gestión de configuración, análisis y diseño,

UNPSJB -2005 Ingeniería de Software - Clase 2 18

UNPSJB -2005 Ingeniería de Software - Clase 2 19

 Proyección del riesgo

UNPSJB -2005 Ingeniería de Software - Clase 2 21

UNPSJB -2005 Ingeniería de Software - Clase 2 22

Rendimiento Soporte Costo Plan Temporal

UNPSJB -2005 Ingeniería de Software - Clase 2 23

UNPSJB -2005 Ingeniería de Software - Clase 2 24

UNPSJB -2005 Ingeniería de Software - Clase 2 25

 relaciones interpersonales entre miembros del

UNPSJB -2005 Ingeniería de Software - Clase 2 26

 Gestión del riesgo

UNPSJB -2005 Ingeniería de Software - Clase 2 27

 Metodología SRP (software

UNPSJB -2005 Ingeniería de Software - Clase 2 28

 Política y objetivos corporativos

 Factores tácticos: influyen en proyectos

 estructura de la organización del proyecto

UNPSJB -2005 Ingeniería de Software - Clase 2 29

 el producto es vital para su actividad

 Estructura del proceso de valoración SPR

UNPSJB -2005 Ingeniería de Software - Clase 2 30

 miembros del grupo de desarrollo de cada

UNPSJB -2005 Ingeniería de Software - Clase 2 31

UNPSJB -2005 Ingeniería de Software - Clase 2 32

 Implicación del usuario, costos, etc.

UNPSJB -2005 Ingeniería de Software - Clase 2 33