Ingeniería de Software Clase 2

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

Ingeniería de Software - Clase 2
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) Actores Desarrollo UNPSJB -2005 Ingeniería de Software - Clase 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 UNPSJB -2005 Ingeniería de Software - Clase 2

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” Se intenta definir el concepto de riesgo. Para ello hay que tener en cuenta una serie de factores que se detallan: a priori intentamos “ver” el futuro cuando el futuro se convierte en presente nos valemos en lo que oportunamente previmos para solucionar situaciones extremas en cada caso, ante un “peligro” necesitamos hacer cambios y elecciones. UNPSJB -2005 Ingeniería de Software - Clase 2

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 La estrategia de riesgo puede ser reactiva: en este caso se reacciona ante un problema. El jefe del proyecto junto con los demás integrantes supervisan el proyecto en previsión de posibles riesgo. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas reales. El equipo de software no hace nada hasta que el riesgo se transforma en real. En ese momento el equipo “vuela” para corregir (o al menos intentar) el problema. Cuando lo anterior falla, la gestión de crisis entra en acción y el proyecto se encuentra en peligro real. Proactiva: se hace un gerenciamiento del riesgo, obviamente a priori. Estudiaremos el tratamiento proactivo del riesgo, debido a que el otro carece de política. UNPSJB -2005 Ingeniería de Software - Clase 2

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 Los riesgos del proyecto amenazan básicamente la planificación realizada. Traen problemas potenciales en: presupuesto planificación temporal personal (asignación y organización) recursos clientes y requisitos UNPSJB -2005 Ingeniería de Software - Clase 2

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) Los riesgos técnicos pueden afectar la realización del software. Si necesitamos de determinados elementos que no se encuentran disponibles por costo o sencillamente por que aún no existen pueden llevar al fracaso total del proyecto de software. Los riesgos técnicos identifican problemas potenciales de diseño implementación interfaz verificación y mantenimiento. UNPSJB -2005 Ingeniería de Software - Clase 2

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 Habrá un cambio de administración organizacional con diferentes prioridades No disponibilidad de hardware 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 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 UNPSJB -2005 Ingeniería de Software - Clase 2

Tercer clasificación: Jones caracteriza los 60 casos de riesgo Comunes y serios Desarrollaremos posteriormente Segunda clasificación riesgos conocidos. Se pueden determinar con: evaluación del plan de proyecto evaluación del entorno técnico y comercial otras fuentes de información Riesgos predecibles: utiliza experiencia de proyectos anteriores. Riesgos Impredecibles. UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

El proceso de administración de riesgos en forma gráfica UNPSJB -2005 Ingeniería de Software - Clase 2

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 La identificación del riesgo consiste en especificar las amenazas al plan del proyecto. Cada categoría de riesgo presentada en la primer categorización presenta riesgos: genéricos específicos La lista de comprobación se utiliza para identificar riesgos y enfocarse en subconjuntos de riesgos conocidos y predecibles tamaño del producto: a construir o modificar impacto en el negocio: limitaciones de gestión o mercado características del cliente: sofisticación y habilidad y posibilidad de comunicarse UNPSJB -2005 Ingeniería de Software - Clase 2

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 definición del proceso: grado de definición y seguimiento que se realiza entorno de desarrollo: disponibilidad y calidad de las herramientas disponibles. Lugares físicos de trabajo. Tecnología a construir: tecnología de punta que contiene el sistema y complejidad del mismo tamaño y experiencia de la plantilla de gente que desarrolla. UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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: Tres comentarios: sofisticación del usuario final es de gran importancia, se puede hacer un software excelente pero el usuario final del mismo puede no estar capacitado en el uso de deteminados elementos. Además, los elementos utilizados son inviables en el contexto de trabajo del usuario. Documentación: los proyectos militares exigen una determinada cantidad de palabras de documentación por línea de código si no se cumple el proyecto se cancela. Limitaciones legales: relacionado con informática legal. UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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. Proceso estandart tiene que ver con CVC, Espiral, prototipos etc. La calidad abarca todos los aspectos conocidos siguiendo los preceptos de ISO o CMM. UNPSJB -2005 Ingeniería de Software - Clase 2

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,.. UNPSJB -2005 Ingeniería de Software - Clase 2

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? UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

definir las consecuencias del riesgo en el proyecto y el producto generar la tabla de riesgo Estudio del impacto del riesgo catastrófico: cancelación del proyecto crítico: reducción de rendimiento, retrasos en la entrega, excesos importante en costo. marginal: reducciones mínimas de rendimiento, posibles retrasos, exceso en costo despreciable: incidencia mínima en el desarrollo. UNPSJB -2005 Ingeniería de Software - Clase 2

A.Riesgo - Plan de riesgo tabla de Bohem
UNPSJB -2005 Ingeniería de Software - Clase 2

Tabla de riesgo primer fase: construcción de la tabla lista de riesgos categoría probabilidad de ocurrencia impacto segunda fase: clasificación por impacto y probabilidad de ocurrencia tercer fase: línea de corte cuarta fase: plan de contingencia UNPSJB -2005 Ingeniería de Software - Clase 2

Factores que afectan el riesgo naturaleza alcance cuando ocurre Reducción y supervisión reducción del riesgo reunirse con la plantilla y determinar las causas actuar para reducir las causas que estén al alcance del control UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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: La idea es que la metodología SPR o del SEI permiten evaluar un proyecto de software usando una serie de pasos o preceptos y en un plazo de uno a tres meses (basados en el tamaño de la empresa y en la dispersidad geográfica de sus unidades) hacer una estimación de los riesgos corrido en el desarrollo. El desarrollo de la propuesta del SPR se realizó basados en estudios de proyectos por más de 5 años, estudiando todos los casos presentados en proyectos desarrollados en EEUU. La metodología involucra una serie de actividades que se pueden aplicar en cualquier proyecto de software: militar software comercial clásico software de venta masiva software específico (tiempo real, SO, etc.) Los factores que inciden en un proyecto de software en más de1% son tenidos en cuenta, lo que hace que se lleven adelante en la evaluación más de 400. UNPSJB -2005 Ingeniería de Software - Clase 2

Política de precios, de la compañía en función de los competidores de mercado. Cultura corporativa de trabajo Política y objetivos corporativos Factores tácticos: influyen en proyectos particulares. Casos: métodos y herramientas utilizadas (análisis, diseño, programación) producción de documentos estructura de la organización del proyecto UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

A.R. - Estudio de Riesgos Cantidad de código fuente en todos los lenguajes utilizados Actividades y tareas llevadas a cabo Actividades de mantenimiento, Implicación del usuario, costos, etc. Resultados obtenidos Categorizaciones de proyectos Sistemas de administración de información Software de sistemas(SO, telecomunicaciones, etc.) UNPSJB -2005 Ingeniería de Software - Clase 2

A.R. - Estudio de Riesgos Software comercial (desde juegos a sistemas IA o expertos pero de venta masiva) Software militar Software subcontratado o externo. Software desarrollado para usuarios finales Categorización de riesgos comunes serios UNPSJB -2005 Ingeniería de Software - Clase 2

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%) UNPSJB -2005 Ingeniería de Software - Clase 2

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%) UNPSJB -2005 Ingeniería de Software - Clase 2

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%) UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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) UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

A.R. - Estudio de Riesgos Baja satisfacción del usuario: mejora con GUI, ayudas en línea, documentación acorde, etc. Fricción entre clientes y desarrolladores usos legales costos de litigio. 10 riesgos más serios evaluados por SPR métricas inadecuadas: LDC, PF mediciones inadecuadas: no evaluar correctamente los “gastos” del software UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

A.R. - Estudio de Riesgos 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 Que evalúa SPR y Jones? Define el riesgo Estudia Severidad Frecuencia Ocurrencia Susceptibilidad y resistencia Causas que lo originan Problemas asociados UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

¿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. UNPSJB -2005 Ingeniería de Software - Clase 2

¿Qué es JAD? La sesión involucra: Agenda detallada. Ayuda visual. Facilitador. Escritor (llamado Notario). El resultado es un Documento final. UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

Fases del JAD JAD se divide en cinco fases: Definición del proyecto. Investigación. Preparación. La sesión. El documento final. UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

¿En que usan las compañías JAD?
Reingeniería de procesos de negocio. Modelado de datos. Diseño de nuevos sistemas. Modificaciones a un sistema existente. Automatización de procesos manuales. Conversiones. Adquisiciones. UNPSJB -2005 Ingeniería de Software - Clase 2

Factores de incidencia en una sesión
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. 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. UNPSJB -2005 Ingeniería de Software - Clase 2

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

Tener a las personas correctas en el salón
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. Algunas preguntas ¿Cuáles con las consecuencias de no tener a las personas adecuadas en la sesión? Va en contra del concepto de JAD  Se debe cambiar la planificación. ¿Qué pasaría si falta alguien? Se debe crear una lista con las preguntas para esa persona. UNPSJB -2005 Ingeniería de Software - Clase 2

Como manejar los conflictos
Hay conflictos ventajosos  son productivos y no deben reprimirse. Conflictos de estancamiento  la discusión va a un callejón sin salida. Y conflictos dogmáticos  cuando el ego está por encima de la discusión. Es necesario eliminarlos o la sesión fracasará. Los conflictos entre los usuarios y los IS deben manejarse distinto. El foco está en quien está en el conflicto en lugar de que es el conflicto. Se deben sofocar las conversaciones de subgrupos. La integridad del grupo se disuelve cuando emergen los subgrupos. UNPSJB -2005 Ingeniería de Software - Clase 2

Equipo de JAD y como seleccionarlo
El éxito depende de los participantes. Hay dos etapas: Seleccionar el Facilitador y el Coordinador Ejecutivo. Seleccionar los otro miembros del grupo. UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

Fases del JAD Se diferencian 5 fases: Definición del proyecto. Investigación. Preparación. La Sesión. El Documento Final. UNPSJB -2005 Ingeniería de Software - Clase 2

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

Fases del JAD Definición de la empresa Desde la perspectiva de la empresa. Posee el propósito, alcance y objetivos del proyecto. Programando la sesión El tiempo depende del proyecto. Por lo gral., de 3 a 5 días. Pueden ser sesiones de medio día o de día entero (hace el proyecto mas corto). UNPSJB -2005 Ingeniería de Software - Clase 2

Fases del JAD Fase 2: Investigación Familiarizarnos con el área de trabajo de la empresa. Documentar requerimientos de datos. Documentar procesos de trabajo. Recolectar información preliminar. Repasar la agenda de la sesión. Familiarisarse con la empresa Obtener puntos de vista más técnicos, Consultas con personal externo que sirva de ayuda UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

Fases del JAD Fase 3: Preparación Compilar toda la información obtenida en un documento (el documento de trabajo) Entrenar al Notario. Crear ayudas visuales. Realizar una reunión de pre-sesión. Montar la sala para la sesión. UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

Fases del JAD Fase 4: Sesión Es el principal evento del proceso JAD. Para toda la sesión vamos a usar una agenda que tiene: Discutir suposiciones. Definir requerimientos de datos. Diseñar procesos de trabajo. Diseñar pantallas. Resolver discusiones abiertas. UNPSJB -2005 Ingeniería de Software - Clase 2

Fases del JAD “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. 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. UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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 debe Determinar quien recibirá al doc. final (se crea la “lista de distribución final”.) Discutir como los participantes van a revisar el documento (que le revisen para ver si lo quieren modificar). Dar algunos puntos de cierre (palabras de agradecimiento hacia los participantes.) UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

Ideas para aplicar con JAD
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. Prototipos ¿Como se adaptan al proceso de JAD? Son una pareja perfecta. Por ej., una vez definidas la pantallas, menús y diálogos en la sesión de JAD, se le dice a los IS que construyan en el prototipo. Usando herramientas de prototipo el desarrollador traduce los requisitos en un sistema que este funcionando. Se puede hacer otra sesión para refinarlo UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

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 UNPSJB -2005 Ingeniería de Software - Clase 2

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. UNPSJB -2005 Ingeniería de Software - Clase 2

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: UNPSJB -2005 Ingeniería de Software - Clase 2

Midiendo JAD, resultados de productividad
UNPSJB -2005 Ingeniería de Software - Clase 2

Ejercicios para la clase próxima
Investigar sobre RAD Brainstorming Análisis de Riesgo Dos alumnos sobre cada tema Leer el paper T UNPSJB -2005 Ingeniería de Software - Clase 2

Ingeniería de Software Clase 2

Presentaciones similares

Presentación del tema: "Ingeniería de Software Clase 2"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Ingeniería de Software Clase 2

Presentaciones similares

Presentación del tema: "Ingeniería de Software Clase 2"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback