ingeniería de software clase 2
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
Ingeniería de SoftwareClase 2
Análisis de Riesgo JAD ( Joint Application Development)
2Ingeniería de Software - Clase 2UNPSJB -2005
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
3Ingeniería de Software - Clase 2UNPSJB -2005
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
4Ingeniería de Software - Clase 2UNPSJB -2005
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”
5Ingeniería de Software - Clase 2UNPSJB -2005
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
6Ingeniería de Software - Clase 2UNPSJB -2005
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
7Ingeniería de Software - Clase 2UNPSJB -2005
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.
Que puede ocurrir: 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)
8Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Clasificación
Riesgos posibles, ejemplosRiesgo 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 desempeño de la herramienta CASE
Producto La herramienta CASE no tiene el desempeño anticipado
9Ingeniería de Software - Clase 2UNPSJB -2005
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.
Tercer clasificación: Jones caracteriza los 60
casos de riesgo Comunes y serios Desarrollaremos
posteriormente
10Ingeniería de Software - Clase 2UNPSJB -2005
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
11Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
El proceso de administración de riesgos en forma gráfica
Identificaciónde riesgos
Supervisión deriesgos
planeación deRiesgos
Análisis deriesgos
Listado de riesgospotenciales
Valoración deriesgos
Anulación deriesgos y planesde contintencia
Listado de priori-zación de riesgos
12Ingeniería de Software - Clase 2UNPSJB -2005
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
13Ingeniería de Software - Clase 2UNPSJB -2005
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
tamaño estimado del producto en LDC o PF? Grado de seguridad de la estimación de tamaño
14Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
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
Lista de comprobación de riesgos genéricos efecto del producto en los ingresos de la
compañía
15Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
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:
16Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
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
17Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
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.
18Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
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,..
19Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
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?
20Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
Riesgos del entorno de desarrollo Lista de comprobación de riesgos 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 Lista de comprobación de riesgos genéricos
21Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
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
22Ingeniería de Software - Clase 2UNPSJB -2005
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.
23Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo tabla de Bohem
Rendimiento Soporte Costo Plan Temporal
Catastró-fico
Degradación que lleva a no alcan-zar rendimiento técnico
El software no responde o no admite soporte
Recortes finan- cieros duros pre-supuesto excedi-do
Fecha de entrega inalcanzable
Crítico Alguna reducción en el rendimiento técnico
Pequeños retrasos en modificacio-nes de software|
Algún recorte en rec. Financieros, posibles excesos en presupuesto
Posibles retrasos de la fecha de entrega.
Marginal De mínima a pe-queña reducción en el rendimiento técnico
El soporte del software respon-de
Recursos finan-cieros suficien-tes
Planificación temporal realis-ta, alcanzable
Despre-ciable
No hay reducción en el rendimiento técnico
Software fácil de dar soporte
Psible superávit de presupuesto
Fecha de entrega fácilmente alcan-zable
24Ingeniería de Software - Clase 2UNPSJB -2005
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
25Ingeniería de Software - Clase 2UNPSJB -2005
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
26Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
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
27Ingeniería de Software - Clase 2UNPSJB -2005
A.Riesgo - Plan de riesgo
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
28Ingeniería de Software - Clase 2UNPSJB -2005
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:
29Ingeniería de Software - Clase 2UNPSJB -2005
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
30Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Valoración de proyectos
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
31Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Valoración de proyectos
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
32Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Valoración de proyectos
Escala de influencia (similar a CMM)1 excelente2 bueno3 promedio4 mediocre5 pobre
Datos “duros” obtenidos tamaño de las especificaciones y
documentaciones PF totales del proyecto
33Ingeniería de Software - Clase 2UNPSJB -2005
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.)
34Ingeniería de Software - Clase 2UNPSJB -2005
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
35Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Estudio de Riesgos
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%)
36Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Estudio de Riesgos
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%)
37Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Estudio de Riesgos
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%)
38Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Estudio de Riesgos
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
39Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Estudio de Riesgos
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)
40Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Estudio de Riesgos
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
41Ingeniería de Software - Clase 2UNPSJB -2005
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
42Ingeniería de Software - Clase 2UNPSJB -2005
A.R. - Estudio de Riesgos
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
43Ingeniería de Software - Clase 2UNPSJB -2005
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
evaluar otros riesgos afectados.
44Ingeniería de Software - Clase 2UNPSJB -2005
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
Impacto en los costos Métodos de prevención Métodos de control Efectividad de
soluciones conocidas Costo de estas
soluciones Pronostico a largo
plazo
45Ingeniería de Software - Clase 2UNPSJB -2005
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
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.
46Ingeniería de Software - Clase 2UNPSJB -2005
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.
Causas raíces: son varias 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
Problemas asociados: 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.
47Ingeniería de Software - Clase 2UNPSJB -2005
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.
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.
48Ingeniería de Software - Clase 2UNPSJB -2005
¿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.
49Ingeniería de Software - Clase 2UNPSJB -2005
¿Qué es JAD?
La sesión involucra: Agenda detallada. Ayuda visual. Facilitador. Escritor (llamado Notario).
El resultado es un Documento final.
50Ingeniería de Software - Clase 2UNPSJB -2005
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
51Ingeniería de Software - Clase 2UNPSJB -2005
Fases del JAD
JAD se divide en cinco fases:Definición del proyecto.Investigación.Preparación.La sesión.El documento final.
52Ingeniería de Software - Clase 2UNPSJB -2005
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.
Mas atención a sus negocios. Enfoque en reingeniería de
procesos de negocio 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.
53Ingeniería de Software - Clase 2UNPSJB -2005
¿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.
54Ingeniería de Software - Clase 2UNPSJB -2005
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 facilitador sin entrenar. (Ya que el facilitador es el eje del proyecto).
Abandonar su propia autoridad.
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.
55Ingeniería de Software - Clase 2UNPSJB -2005
Los 10 mandamientos de JAD
1. El éxito de JAD depende del empeño administrativo.
2. Los participantes deben asistir a la sesión entera.
3. El éxito de JAD requiere un facilitador entrenado.
4. Asegurarse de tener a las personas correctas en la sesión
5. Todos los participantes son iguales.
6. La preparación es tan importante como la sesión.
7. Hacer una buena agenda y adherirse a ella.
8. Usar técnicas y herramientas apropiadas en la sesión.
9. Mantener la jerga técnica al mínimo.
10. Producir un documento final rápido y de calidad.
56Ingeniería de Software - Clase 2UNPSJB -2005
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.
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.
57Ingeniería de Software - Clase 2UNPSJB -2005
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.
58Ingeniería de Software - Clase 2UNPSJB -2005
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.
59Ingeniería de Software - Clase 2UNPSJB -2005
Equipo de JAD y como seleccionarlo
Coordinador Ejecutivo 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
60Ingeniería de Software - Clase 2UNPSJB -2005
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.
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
61Ingeniería de Software - Clase 2UNPSJB -2005
Equipo de JAD y como seleccionarlo
NOTARIO: Registra todas las
decisiones. Necesita una gran
capacidad analítica. Mantiene las
“memorias” del grupo.
Funciones 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
62Ingeniería de Software - Clase 2UNPSJB -2005
Equipo de JAD y como seleccionarlo
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.
63Ingeniería de Software - Clase 2UNPSJB -2005
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.
64Ingeniería de Software - Clase 2UNPSJB -2005
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.
Posibles preguntas ¿Como se origino el
proyecto? ¿Cuales son sus
principales problemas? ¿Qué beneficios desea
obtener con el proyecto?
¿Qué limitaciones deberíamos considerar?
65Ingeniería de Software - Clase 2UNPSJB -2005
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).
66Ingeniería de Software - Clase 2UNPSJB -2005
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
67Ingeniería de Software - Clase 2UNPSJB -2005
Fases del JAD
Documentar Requerimientos
Identificar los grupos de datos usados en el área de trabajo.
Definir los nombres y descripciones de los datos elementales.
Definir relaciones. Definir una estructura
correcta para los datos.
Documentar proceso de trabajo
Define las reglas para usar los datos.
Se puede usar diagramas de descomposición, diagramas dependientes o matrices.
Para capturar los procesos de trabajo se usan los DFD.
68Ingeniería de Software - Clase 2UNPSJB -2005
Fases del JAD
Fase 3: PreparaciónCompilar 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.
69Ingeniería de Software - Clase 2UNPSJB -2005
Fases del JAD
Documento Debe tener la
información recogida para ser usado en la sesión.
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.
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.
70Ingeniería de Software - Clase 2UNPSJB -2005
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.
71Ingeniería de Software - Clase 2UNPSJB -2005
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.
72Ingeniería de Software - Clase 2UNPSJB -2005
Fases del JAD
Abriendo la sesión Al principio se debe
exponer: 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.
“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.
73Ingeniería de Software - Clase 2UNPSJB -2005
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.
Requerimientos de datos
Puede ir desde un completo modelo de datos a definir solo unos nuevos elementos de datos.
DER general, guiado
74Ingeniería de Software - Clase 2UNPSJB -2005
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.
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
75Ingeniería de Software - Clase 2UNPSJB -2005
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.
Se entrega un formulario a los participantes para evaluarlos después de la sesión.
Cerrando al sesión, se debe1. Determinar quien recibirá al
doc. final (se crea la “lista de distribución final”.)
2. Discutir como los participantes van a revisar el documento (que le revisen para ver si lo quieren modificar).
3. Dar algunos puntos de cierre (palabras de agradecimiento hacia los participantes.)
76Ingeniería de Software - Clase 2UNPSJB -2005
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.
77Ingeniería de Software - Clase 2UNPSJB -2005
Fases del JAD
Qué debe tener el documento final
Se usan tablas para presentar la información.
Como ser: 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).
Como debe escribirse
Se mira del lado del que lo va a leer preguntando:
Lo entenderá? Está en español
claro?, etc.
78Ingeniería de Software - Clase 2UNPSJB -2005
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.
79Ingeniería de Software - Clase 2UNPSJB -2005
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.
80Ingeniería de Software - Clase 2UNPSJB -2005
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
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.
81Ingeniería de Software - Clase 2UNPSJB -2005
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.
82Ingeniería de Software - Clase 2UNPSJB -2005
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
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.
83Ingeniería de Software - Clase 2UNPSJB -2005
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:
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.
Mantenimiento Correctivo Perfectivo Adaptativo Hay que entender las
nuevas necesidades
84Ingeniería de Software - Clase 2UNPSJB -2005
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.
85Ingeniería de Software - Clase 2UNPSJB -2005
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:
86Ingeniería de Software - Clase 2UNPSJB -2005
Midiendo JAD, resultados de productividad
5.2
2.5
0
1
2
3
4
5
6
Horaspor PF
Proyectos
NO uso JADUso JAD
UNPSJB -2005 Ingeniería de Software - Clase 2 87
Ejercicios para la clase próxima
Investigar sobre RAD Brainstorming Análisis de Riesgo
Dos alumnos sobre cada tema
Leer el paper T