Ingeniería de Software Clase 2 Análisis de Riesgo JAD ( Joint Application Development)

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


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



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



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


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ó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



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

Lista de comprobación de riesgos 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 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



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.


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 financieros 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



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 excelente2 bueno3 promedio4 mediocre5 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 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



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.



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.


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.


¿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

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.


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


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.


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.


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

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



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



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



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

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?


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


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.


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.


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


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


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


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


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


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


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



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


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

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

Documents

Ingeniería de Software Clase 2 Análisis de Riesgo JAD ( Joint Application Development)