El diseño de aplicaciones conjuntas ( JAD ) es un proceso que se utiliza en el área del ciclo de vida del método de desarrollo de sistemas dinámicos (DSDM) para recopilar los requisitos comerciales mientras se desarrollan nuevos sistemas de información para una empresa. "El proceso JAD también incluye enfoques para mejorar la participación de los usuarios, acelerar el desarrollo y mejorar la calidad de las especificaciones". Consiste en un taller donde "los trabajadores del conocimiento y los especialistas en TI se reúnen, a veces durante varios días, para definir y revisar los requisitos comerciales del sistema". [1]Los asistentes incluyen funcionarios de gestión de alto nivel que se asegurarán de que el producto proporcione los informes y la información necesarios al final. Esto actúa como "un proceso de gestión que permite a los departamentos de Servicios de Información Corporativa (SI) trabajar de manera más eficaz con los usuarios en un período de tiempo más corto". [2]
A través de los talleres de JAD, los trabajadores del conocimiento y los especialistas en TI pueden resolver las dificultades o diferencias entre las dos partes con respecto al nuevo sistema de información. El taller sigue una agenda detallada para garantizar que se cubran todas las incertidumbres entre las partes y ayudar a prevenir cualquier error de comunicación. Las malas comunicaciones pueden tener repercusiones mucho más graves si no se abordan hasta más adelante en el proceso. (Consulte a continuación los participantes clave y los pasos clave para un JAD eficaz). Al final, este proceso dará como resultado un nuevo sistema de información que es viable y atractivo tanto para los diseñadores como para los usuarios finales.
"Aunque el diseño de JAD es ampliamente aclamado, en realidad se sabe poco sobre su eficacia en la práctica". Según el Journal of Systems and Software , se realizó un estudio de campo en tres organizaciones que utilizan las prácticas de JAD para determinar cómo JAD influyó en los resultados del desarrollo del sistema. Los resultados del estudio sugieren que las organizaciones lograron una mejora modesta en los resultados del desarrollo de sistemas mediante el uso del método JAD. El uso de JAD fue más efectivo en proyectos pequeños y claramente enfocados y menos efectivo en proyectos grandes y complejos. Desde 2010, la Asociación Internacional de Facilitadores (IAF) ha medido la importancia de los talleres facilitados, a la JAD, y ha encontrado un valor significativo. [3]
Origen
Aplicación conjunta es un término utilizado originalmente para describir un proceso de desarrollo de software iniciado y desplegado con éxito a mediados de la década de 1970 por el Centro de Desarrollo de Sistemas de la Compañía Telefónica de Nueva York bajo la dirección de Dan Gielan. Tras una serie de implementaciones notablemente exitosas de esta metodología, Gielan dio numerosas conferencias en varios foros sobre la metodología, sus beneficios y mejores prácticas. Arnie Lind, entonces ingeniero de sistemas sénior en IBM Canadá en Regina, Saskatchewan, creó y nombró el diseño de aplicaciones conjuntas en 1974. Esta fue una mejora de los métodos existentes, que implicó que los desarrolladores de aplicaciones pasaran meses aprendiendo los detalles de un departamento o función de trabajo en particular y luego desarrollar una aplicación para la función o departamento. Además de los importantes retrasos en el desarrollo, este proceso provocó que las aplicaciones tardaran años en desarrollarse y, a menudo, los usuarios de la aplicación no las aceptaran por completo.
La idea de Arnie Lind era simple: en lugar de que los desarrolladores de aplicaciones aprendan sobre los trabajos de las personas, ¿por qué no enseñar a las personas que realizan el trabajo cómo escribir una aplicación? Arnie presentó el concepto al vicepresidente de IBM Canadá, Carl Corcoran (más tarde presidente de IBM Canadá), y Carl aprobó un proyecto piloto. Arnie y Carl llamaron juntos a la metodología JAD, un acrónimo de diseño de aplicaciones conjuntas, después de que Carl Corcoran rechazara el acrónimo JAL, o logística de aplicaciones conjuntas, al darse cuenta de que las iniciales de Arnie Lind eran JAL (John Arnold Lind).
El proyecto piloto fue un proyecto de sala de emergencias para el gobierno de Saskatchewan. Arnie desarrolló la metodología JAD y organizó un seminario de una semana en el que participaron principalmente enfermeras y administradores de la sala de emergencias, pero también parte del personal de desarrollo de aplicaciones. El proyecto fue un gran éxito, ya que el seminario de una semana produjo un marco de aplicación detallado, que luego se codificó e implementó en menos de un mes, en comparación con un promedio de 18 meses para el desarrollo de aplicaciones tradicionales. Y debido a que los propios usuarios diseñaron el sistema, inmediatamente adoptaron y les gustó la aplicación. Después del proyecto piloto, IBM apoyó mucho la metodología JAD, ya que la vieron como una forma de implementar aplicaciones informáticas más rápidamente, ejecutándose en hardware de IBM.
Arnie Lind pasó los siguientes 13 años en IBM Canadá continuando desarrollando la metodología JAD y viajando alrededor del mundo realizando seminarios JAD y capacitando a los empleados de IBM en los métodos y técnicas de JAD. Los JAD se realizaron ampliamente en IBM Canadá, y la técnica también se extendió a IBM en los Estados Unidos. Arnie Lind capacitó a varias personas en IBM Canadá para realizar JAD, incluidos Tony Crawford y Chuck Morris. Arnie Lind se retiró de IBM en 1987 y continuó enseñando y realizando JAD como consultor en Canadá, Estados Unidos y Asia.
El proceso JAD fue formalizado por Tony Crawford y Chuck Morris de IBM a fines de la década de 1970. Luego se implementó en Canadian International Paper. JAD se utilizó en IBM Canadá durante un tiempo antes de ser devuelto a los EE. UU. Inicialmente, IBM usó JAD para ayudar a vender e implementar un programa de software que vendieron, llamado COPICS. Se adaptó ampliamente a muchos usos (requisitos del sistema, diseño de elevadores de granos, resolución de problemas, etc.). Tony Crawford más tarde desarrolló JAD-Plan y luego JAR (requisitos de aplicación conjunta). En 1985, Gary Rush escribió sobre JAD y sus derivaciones - Técnicas de especificación de aplicaciones facilitadas (FAST) - en Computerworld. [4]
Originalmente, JAD fue diseñado para reunir a desarrolladores de sistemas y usuarios de diferentes antecedentes y opiniones en un entorno productivo y creativo. Las reuniones fueron una forma de obtener requisitos y especificaciones de calidad. El enfoque estructurado ofrece una buena alternativa a las tradicionales entrevistas en serie realizadas por analistas de sistemas. Desde entonces, JAD se ha expandido para cubrir el trabajo de TI más amplio, así como el trabajo que no es de TI (lea sobre Técnicas de especificación de aplicaciones facilitadas - FAST - creado por Gary Rush en 1985 para expandir la aplicabilidad de JAD. [5]
Participantes clave
Patrocinador ejecutivo : el ejecutivo que funda el proyecto, el propietario del sistema. Deben ser lo suficientemente altos en la organización para poder tomar decisiones y proporcionar la estrategia, planificación y dirección necesarias.
Expertos en la materia : estos son los usuarios comerciales, los profesionales de SI y los expertos externos que se necesitarán para un taller exitoso. Este grupo es la columna vertebral de la reunión; ellos impulsarán los cambios.
Facilitador / Líder de sesión : se reúne y dirige el tráfico manteniendo al grupo en la agenda de la reunión. El facilitador es responsable de identificar los problemas que se pueden resolver como parte de la reunión y los que deben asignarse al final de la reunión para la investigación de seguimiento y la resolución. El facilitador atiende a los participantes y no aporta información a la reunión.
Escribano / Modelador / Registrador / Experto en documentación : Registra y publica las actas de la reunión y no aporta información a la reunión.
Observadores : generalmente miembros del equipo de desarrollo de aplicaciones asignados al proyecto. Deben sentarse detrás de los participantes y observar en silencio los procedimientos.
9 pasos clave
- Identificar los objetivos y las limitaciones del proyecto : es vital tener objetivos claros para el taller y para el proyecto en su conjunto. Las actividades previas al taller, la planificación y el alcance, establecen las expectativas de los patrocinadores y participantes del taller. El alcance identifica las funciones comerciales que están dentro del alcance del proyecto. También trata de evaluar tanto el diseño del proyecto como la complejidad de la implementación. Se debe evaluar la sensibilidad política del proyecto. ¿Se ha intentado esto en el pasado? ¿Cuántos comienzos en falso hubo? ¿Cuántas fallas de implementación hubo? El tamaño es importante. Para obtener los mejores resultados, los proyectos de sistemas deben dimensionarse de modo que se pueda diseñar un diseño completo, hasta las pantallas y los menús, en 8 a 10 días de taller.
- Identificar los factores críticos de éxito : es importante identificar los factores críticos de éxito tanto para el proyecto de desarrollo como para la función empresarial que se está estudiando. ¿Cómo sabremos que los cambios planeados han sido efectivos? ¿Cómo se medirá el éxito? La planificación de la evaluación de resultados ayuda a juzgar la eficacia y la calidad del sistema implementado durante toda su vida operativa.
- Definir los entregables del proyecto : en general, los entregables de un taller son la documentación y un diseño. Es importante definir la forma y el nivel de detalle de la documentación del taller. ¿Qué tipos de diagramas se proporcionarán? ¿Qué tipo o forma de narrativa se proporcionará? Es una buena idea comenzar a usar una herramienta CASE para el soporte de diagramación desde el principio. La mayoría de las herramientas disponibles tienen capacidades de diagramación de buenas a excelentes, pero su soporte narrativo es generalmente débil. La narrativa se produce mejor con su software de procesamiento de texto estándar.
- Definir el cronograma de actividades del taller : Los talleres varían en duración de uno a cinco días. El taller inicial de un proyecto no debe ser inferior a tres días. A los participantes les toma la mayor parte del primer día sentirse cómodos con sus roles, entre ellos y con el medio ambiente. El segundo día se dedica a aprender a entenderse y a desarrollar un lenguaje común con el que comunicar problemas e inquietudes. Al tercer día, todos están trabajando juntos en el problema y se logra una productividad real. Después del taller inicial, se ha realizado la formación de equipos. Se pueden programar talleres más breves para las fases posteriores del proyecto, por ejemplo, para verificar un prototipo. Sin embargo, a los participantes les llevará de una a tres horas restablecer la psicología de equipo del taller inicial.
- Seleccione los participantes : estos son los usuarios comerciales, los profesionales de TI y los expertos externos que se necesitarán para un taller exitoso. Estos son los verdaderos "huesos" de la reunión que impulsarán los cambios.
- Preparar el material del taller : Antes del taller, el gerente de proyecto y el facilitador realizan un análisis y construyen un diseño preliminar o un hombre de paja para enfocar el taller. El material del taller consta de documentación, hojas de trabajo, diagramas e incluso accesorios que ayudarán a los participantes a comprender la función empresarial que se investiga.
- Organice las actividades y los ejercicios del taller : el facilitador debe diseñar los ejercicios y las actividades del taller para proporcionar entregables intermedios que contribuyan al resultado final del taller. Las actividades previas al taller ayudan a diseñar esos ejercicios de taller. Por ejemplo, para un análisis de área empresarial, ¿qué contiene? ¿Un diagrama de descomposición? ¿Un diagrama entidad-relación de alto nivel? ¿Un modelo de datos normalizado? ¿Un diagrama de transición de estado? ¿Un diagrama de dependencia? ¿Todo lo anterior? ¿Ninguna de las anteriores? Es importante definir el nivel de diagramación técnica que sea apropiado para el entorno. Lo más importante de un diagrama es que debe ser entendido por los usuarios. Una vez que se elige el diagrama, el facilitador diseña ejercicios en la agenda del taller para que el grupo desarrolle esos diagramas. Un taller combina ejercicios que están orientados en serie para construirse unos sobre otros y ejercicios paralelos, con cada sub-equipo trabajando en una parte del problema o trabajando en lo mismo para un área funcional diferente. Los ejercicios de alta intensidad dirigidos por el facilitador energizan al grupo y lo dirigen hacia un objetivo específico. Los ejercicios de baja intensidad permiten discusiones detalladas antes de tomar decisiones. Las discusiones pueden involucrar a todo el grupo o los equipos pueden resolver los problemas y presentar un número limitado de sugerencias para que todo el grupo las considere. Para integrar a los participantes, el facilitador puede emparejar personas con experiencia similar de diferentes departamentos. Para ayudar a los participantes a aprender unos de otros, el facilitador puede combinar la experiencia. Depende del facilitador mezclar y combinar a los miembros del sub-equipo para lograr los objetivos organizacionales, culturales y políticos del taller. Un taller opera tanto en el nivel técnico como en el político. El trabajo del facilitador es generar consenso y comunicaciones, para forzar los problemas a salir temprano en el proceso. No hay necesidad de preocuparse por la implementación técnica de un sistema si los problemas comerciales subyacentes no se pueden resolver.
- Preparar, informar, educar a los participantes del taller : Todos los participantes del taller deben ser conscientes de los objetivos y limitaciones del proyecto y de los resultados esperados del taller. La sesión informativa de los participantes debe tener lugar de 1 a 5 días antes del taller. Esta sesión informativa puede ser teleconferencia si los participantes están muy dispersos. El documento informativo puede denominarse Guía de familiarización, Guía informativa, Definición del alcance del proyecto o Guía de definición de gestión, o cualquier otra cosa que parezca apropiada. Es un documento de ocho a doce páginas, y proporciona una definición clara del alcance del proyecto para los participantes. La sesión informativa en sí dura de dos a cuatro horas. Proporciona la preparación psicológica que todos necesitan para avanzar en el taller.
- Coordinar la logística del taller : los talleres deben realizarse fuera del sitio para evitar interrupciones. Deben prepararse proyectores, pantallas, PC, mesas, marcadores, cinta adhesiva, notas adhesivas y muchos otros accesorios. Qué instalaciones y accesorios específicos se necesitan depende del facilitador. Pueden variar desde simples rotafolios hasta pizarrones electrónicos. En cualquier caso, la distribución de la sala debe favorecer la comunicación y la interacción de los participantes.
Ventajas
- JAD reduce el tiempo y los costos asociados con el proceso de obtención de requisitos. Durante 2-4 semanas, no solo se recopila información, sino que se identifican los requisitos acordados por varios usuarios del sistema. La experiencia con JAD permite a las empresas personalizar sus procesos de análisis de sistemas en procesos aún más dinámicos como Double Helix , una metodología para trabajos de misión crítica.
- Las sesiones de JAD ayudan a reunir a los expertos, dándoles la oportunidad de compartir sus puntos de vista, comprender los puntos de vista de los demás y desarrollar el sentido de propiedad del proyecto.
- Los métodos de implementación de JAD son bien conocidos, ya que es "la primera técnica de diseño acelerado disponible en el mercado y probablemente la más conocida", y puede ser aplicada fácilmente por cualquier organización.
- La fácil integración de las herramientas CASE en los talleres de JAD mejora la productividad de la sesión y proporciona a los analistas de sistemas modelos discutidos y listos para usar.
Desafíos
- Sin una preparación multifacética para una sesión de JAD, el valioso tiempo de los profesionales se puede perder fácilmente. Si los organizadores de la sesión de JAD no estudian los elementos del sistema que se está evaluando, se podría abordar un problema incorrecto, se podría invitar a personas incorrectas a participar y se podrían utilizar recursos inadecuados para la resolución de problemas.
- Los participantes del taller de JAD deben incluir empleados capaces de proporcionar información sobre la mayoría, si no todas, las áreas pertinentes del problema. Es por eso que se debe prestar especial atención durante la selección de los participantes. El grupo debe constar no solo de empleados de varios departamentos que interactuarán con el nuevo sistema, sino de diferentes jerarquías de la escala organizativa. Los participantes pueden tener puntos de vista contradictorios, pero la reunión permitirá a los participantes ver los problemas desde diferentes puntos de vista. JAD saca a la luz un mejor esquema de modelo con una mejor comprensión de los procesos subyacentes.
- El facilitador tiene la obligación de garantizar que todos los participantes, no solo los más expresivos, tengan la oportunidad de ofrecer sus opiniones, ideas y pensamientos.
Referencias
- ^ Haag, Stephen; Cummings, Maeve; McCubbrey, Donald J. (2006). "Fase 2: Análisis". Sistemas de gestión de la información para la era de la información . McGraw-Hill Ryerson. ISBN 978-0-07-281947-2.
- ^ Jennerich, Bill (noviembre de 1990). "Diseño de aplicaciones conjuntas: análisis de requisitos comerciales para una reingeniería exitosa" . Archivado desde el original el 21 de febrero de 2009 . Consultado el 6 de febrero de 2009 .
- ^ Gary Rush, 2013, "¿Qué importancia tiene el valor de la facilitación?" [1]
- ^ "Una forma RÁPIDA de definir los requisitos del sistema", por Gary Rush, Computerworld, Volumen 19 Número 40, En profundidad, páginas ID / 11 a ID / 16 (páginas 47 a 52), 7 de octubre de 1985. Transcripción aquí .
- ^ JAD | RÁPIDO | Técnica de facilitación estructurada FoCuSeD ™ [2] .)
Bibliografía
- Yatco, Mei C. (1999). "Diseño / Desarrollo de Aplicaciones Conjuntas" . Universidad de Missouri-St. Louis . Consultado el 6 de febrero de 2009 .
- Soltys, romano; Anthony Crawford (1999). "JAD para planes y diseños de negocio" . Archivado desde el original el 13 de marzo de 2009 . Consultado el 6 de febrero de 2009 .
- Dennis, Alan R .; Hayes, Glenda S .; Daniels, Robert M., Jr. (primavera de 1999). "Modelado de procesos de negocio con sistemas de soporte grupal" . Revista de Sistemas de Información de Gestión . 15 (4): 115-142. doi : 10.1080 / 07421222.1999.11518224 . Consultado el 14 de mayo de 2015 .
- Botkin, John C. "La participación del cliente como parte del proceso de desarrollo de la aplicación" . Archivado desde el original el 1 de diciembre de 1998 . Consultado el 9 de noviembre de 1999 . Verifique los valores de fecha en:
|accessdate=
( ayuda ) - Moeller, Walter E. "Sesiones de recopilación de información facilitada: una técnica de ingeniería de la información" . Consultado el 22 de marzo de 2010 .
- Bill Jennerich "Diseño de aplicaciones conjuntas: análisis de requisitos comerciales para una reingeniería exitosa". 18:50, 26 de junio de 2006 (UTC) [3] Se desconoce la hora de la última actualización. Consultado el 14 de noviembre de 1999.
- Gary Rush "JAD - Su historia y evolución - Boletín informativo de MGR Consulting". Julio de 2006 [4]
- Gary Rush, "JAD Project Aids Design", Computerworld, Volumen 18 Número 52, páginas 31 y 38, 24 de diciembre de 1984. [5]
- Davidson, EJ (1999). Diseño de aplicaciones conjuntas (JAD) en la práctica. Revista de sistemas y software, 45 (3), 215-223. Obtenido de Science Direct Database. [6]
- Gottesdiener, Ellen; Requisitos por colaboración: talleres para definir necesidades , Addison-Wesley, 2002, ISBN 0-201-78606-0 .
- Wood, Jane y Silver, Denise; Desarrollo de aplicaciones conjuntas , John Wiley & Sons Inc, ISBN 0-471-04299-4