Diseño de aplicación conjunta

El diseño conjunto de aplicaciones (también conocido como desarrollo conjunto de aplicaciones o JAD) es un término que originalmente se utilizó para describir un proceso de desarrollo de software creado e implementado a mediados de la década de 1970 por el Centro de Desarrollo de Sistemas de la New York Telephone Company bajo la dirección de Dan Gielan. Tras varias implementaciones de esta metodología, Gielan impartió numerosas conferencias en diversos foros sobre la metodología y sus prácticas. Arnie Lind, entonces ingeniero sénior de sistemas en IBM Canadá en Regina, Saskatchewan, creó y denominó el diseño conjunto de aplicaciones en 1974. Sin embargo, los métodos existentes implicaban que los desarrolladores de aplicaciones dedicaran meses a aprender las particularidades de un departamento o función laboral específica, para luego desarrollar una aplicación para dicha función o departamento. Además de los retrasos en el desarrollo, este proceso provocaba que las aplicaciones tardaran años en desarrollarse y, a menudo, no fueran completamente aceptadas por los usuarios.

La idea de Arnie Lind era que, en lugar de que los desarrolladores de aplicaciones aprendieran sobre el trabajo de las personas, se podría enseñar a quienes realizaban dicho trabajo a escribir una aplicación. Arnie le presentó el concepto a Carl Corcoran, vicepresidente de IBM Canadá (quien más tarde sería presidente de IBM Canadá), y Carl aprobó un proyecto piloto. Juntos, Arnie y Carl bautizaron la metodología como JAD, acrónimo de Joint Application Design (diseño conjunto de aplicaciones), después de que Carl Corcoran rechazara el acrónimo JAL (Logística conjunta de aplicaciones) 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 enfermeros y administradores de la sala de emergencias, pero también personal de desarrollo de aplicaciones. El seminario de una semana produjo un marco de aplicación , 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 tradicional. Y como los propios usuarios diseñaron el sistema, lo adoptaron y les gustó de inmediato. Después del proyecto piloto, IBM apoyó firmemente la metodología JAD, ya que la consideró 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á, donde continuó desarrollando la metodología JAD, viajando por todo el mundo para impartir seminarios sobre JAD y capacitar a los empleados de IBM en sus métodos y técnicas. Las sesiones JAD se realizaron ampliamente en IBM Canadá, y la técnica también se extendió a IBM en Estados Unidos. Arnie Lind capacitó a varias personas en IBM Canadá para realizar sesiones JAD, entre ellas Tony Crawford y Chuck Morris. Arnie Lind se jubiló de IBM en 1987 y continuó impartiendo cursos y realizando sesiones JAD como consultor en Canadá, Estados Unidos y Asia.

El proceso JAD fue formalizado por Tony Crawford y Chuck Morris de IBM a finales de la década de 1970. Posteriormente, se implementó en Canadian International Paper. JAD se utilizó en IBM Canadá durante un tiempo antes de regresar a Estados Unidos. Inicialmente, IBM utilizó JAD para ayudar a vender e implementar un programa de software que comercializaban, llamado COPICS. Se adaptó ampliamente a diversos usos (requisitos del sistema, diseño de elevadores de grano , resolución de problemas, etc.). Tony Crawford desarrolló más tarde JAD-Plan y luego JAR (Joint Application Requirements). En 1985, Gary Rush escribió sobre JAD y sus derivados —FAST (Facilitated Application Specification Techniques)— en Computerworld . ^{[ 1 ]}

Originalmente, JAD fue diseñado para reunir a desarrolladores de sistemas y usuarios de diversos orígenes y opiniones en un entorno productivo y creativo. Las reuniones eran una forma de obtener requisitos y especificaciones de calidad. El enfoque estructurado proporciona una buena alternativa a las entrevistas seriales tradicionales realizadas por analistas de sistemas. Desde entonces, JAD se ha expandido para abarcar trabajos de TI más amplios, así como trabajos no relacionados con TI (lea sobre las Técnicas de Especificación de Aplicaciones Facilitadas – FAST – creadas por Gary Rush en 1985 para ampliar la aplicabilidad de JAD. ^{[ 2 ]}

Patrocinador ejecutivo

El ejecutivo que autoriza el proyecto, el responsable del sistema. Debe ocupar un puesto lo suficientemente alto en la organización como para poder tomar decisiones y proporcionar la estrategia, la planificación y la dirección necesarias.

Expertos en la materia

Estos son los usuarios de negocio, los profesionales de TI y los expertos externos necesarios para el éxito del taller. Este grupo es la columna vertebral de la reunión; ellos impulsarán los cambios.

Facilitador/Líder de sesión

El facilitador dirige la reunión y mantiene al grupo centrado en la agenda. Es responsable de identificar los temas que pueden resolverse durante la reunión y aquellos que deben asignarse al finalizar para su posterior análisis y resolución. El facilitador está al servicio de los participantes y no aporta información a la reunión.

Escriba/Modelador/Registrador/Experto en documentación

Registra y publica las actas de la reunión y no aporta información a la misma.

Observadores

Generalmente, se trata de miembros del equipo de desarrollo de la aplicación asignados al proyecto. Deben sentarse detrás de los participantes y observar el desarrollo en silencio.

1. Identificar los objetivos y limitaciones del proyecto : Es fundamental tener objetivos claros para el taller y para el proyecto en su conjunto. Las actividades previas al taller, la planificación y la definición del alcance establecen las expectativas de los patrocinadores y participantes. La definición del alcance identifica las funciones empresariales que se encuentran dentro del alcance del proyecto. También busca evaluar la complejidad tanto del diseño como de la implementación del proyecto. Se debe evaluar la sensibilidad política del proyecto. ¿Se ha intentado esto en el pasado? ¿Cuántos intentos fallidos hubo? ¿Cuántos fallos de implementación hubo? El dimensionamiento es importante. Para obtener los mejores resultados, los proyectos de sistemas deben dimensionarse de manera que se pueda diseñar un diseño completo, hasta las pantallas y los menús, en 8 a 10 días de taller.
2. Identificar los factores críticos de éxito : Es fundamental 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 planificados han sido efectivos? ¿Cómo se medirá el éxito? Planificar la evaluación de resultados ayuda a juzgar la efectividad y la calidad del sistema implementado a lo largo de toda su vida útil.
3. Definir los entregables del proyecto : En general, los entregables de un taller son la documentación y el diseño. Es importante definir el formato y el nivel de detalle de la documentación del taller. ¿Qué tipos de diagramas se proporcionarán? ¿Qué tipo o formato de narración se incluirá? Es recomendable comenzar a usar una herramienta CASE para la creación de diagramas desde el principio. La mayoría de las herramientas disponibles ofrecen buenas o excelentes capacidades de diagramación, pero su soporte para la narración suele ser deficiente. La mejor manera de redactar la narración es con un procesador de texto estándar.
4. Defina 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 durar menos de tres días. Los participantes dedican la mayor parte del primer día a familiarizarse con sus roles, entre sí y con el entorno. El segundo día se dedica a aprender a comprenderse mutuamente y a desarrollar un lenguaje común para comunicar problemas e inquietudes. Para el tercer día, todos trabajan juntos en el problema y se alcanza una productividad real. Tras el taller inicial, se ha consolidado el trabajo en equipo. Se pueden programar talleres más cortos para fases posteriores del proyecto, por ejemplo, para verificar un prototipo. Sin embargo, los participantes necesitarán de una a tres horas para restablecer la dinámica de equipo del taller inicial.
5. Seleccionar a los participantes : Se trata de los usuarios de negocio, los profesionales de TI y los expertos externos necesarios para el éxito del taller. Son la columna vertebral de la reunión y quienes impulsarán los cambios.
6. Preparación del material del taller : Antes del taller, el director del proyecto y el facilitador realizan un análisis y elaboran un diseño preliminar o un modelo básico para enfocar el taller. El material del taller incluye documentación, hojas de trabajo, diagramas e incluso elementos visuales que ayudarán a los participantes a comprender la función empresarial que se está investigando.
7. Organizar actividades y ejercicios del taller : El facilitador debe diseñar ejercicios y actividades para proporcionar entregables intermedios que contribuyan al resultado final del taller. Las actividades previas al taller ayudan a diseñar esos ejercicios. Por ejemplo, para un Análisis de Área de Negocio, ¿qué incluye? ¿Un diagrama de descomposición? ¿Un diagrama de entidad-relación de alto nivel? ¿Un modelo de datos normalizado? ¿Un diagrama de transición de estados? ¿Un diagrama de dependencias? ¿Todo lo anterior? ¿Ninguno de los anteriores? Es importante definir el nivel de diagramación técnica apropiado para el entorno. Lo más importante de un diagrama es que debe ser comprensible para los usuarios. Una vez elegido el diagrama, el facilitador diseña ejercicios en la agenda del taller para que el grupo los desarrolle. Un taller combina ejercicios orientados en serie para construir unos sobre otros, y ejercicios paralelos, donde cada subequipo trabaja en una parte del problema o 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 bien, los equipos pueden abordar 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 a personas con experiencia similar de diferentes departamentos. Para ayudar a los participantes a aprender unos de otros, el facilitador puede combinar las diferentes especialidades. Es responsabilidad del facilitador combinar y emparejar a los miembros de los subequipos para lograr los objetivos organizacionales, culturales y políticos del taller. Un taller opera tanto a nivel técnico como político. Es tarea del facilitador generar consenso y comunicación, y abordar los problemas desde el principio del proceso. No hay necesidad de preocuparse por la implementación técnica de un sistema si no se pueden resolver los problemas empresariales subyacentes.
8. Preparar, informar y capacitar a los participantes del taller: Todos los participantes deben conocer los objetivos y limitaciones del proyecto, así como los resultados esperados. La sesión informativa debe realizarse entre 1 y 5 días antes del taller. Si los participantes se encuentran dispersos geográficamente, esta sesión puede realizarse por videoconferencia. 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 otro nombre que resulte apropiado. Consta de entre ocho y doce páginas y proporciona una definición clara del alcance del proyecto. La sesión informativa dura entre dos y cuatro horas y ofrece la preparación psicológica necesaria para el inicio del taller.
9. Coordinación logística del taller : Los talleres deben realizarse fuera de las instalaciones para evitar interrupciones. Se deben preparar proyectores, pantallas, ordenadores, mesas, rotuladores, cinta adhesiva, notas Post-it y otros materiales. El facilitador decidirá qué instalaciones y materiales específicos se necesitan. Estos pueden variar desde simples rotafolios hasta pizarras blancas electrónicas. En cualquier caso, la disposición de la sala debe favorecer la comunicación e interacción de los participantes.

• JAD reduce el tiempo y los costos asociados con el proceso de obtención de requisitos . Durante 2 a 4 semanas, no solo se recopila información, sino que también se identifican los requisitos acordados por los distintos usuarios del sistema. La experiencia con JAD permite a las empresas personalizar su proceso de análisis de sistemas para convertirlo en metodologías aún más dinámicas, como Double Helix , una metodología para trabajos de misión crítica.
• Las sesiones JAD ayudan a reunir a expertos, dándoles la oportunidad de compartir sus puntos de vista, comprender los de los demás y desarrollar un sentido de pertenencia al 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 cualquier organización puede aplicarla fácilmente.
• La fácil integración de las herramientas CASE en los talleres JAD mejora la productividad de las sesiones y proporciona a los analistas de sistemas modelos ya analizados y listos para usar.

• Sin una preparación integral para una sesión JAD, el valioso tiempo de los profesionales puede desperdiciarse fácilmente. Si los organizadores de la sesión JAD no estudian los elementos del sistema que se evalúa, podrían abordar un problema incorrecto, invitar a participar a personas inadecuadas y utilizar recursos insuficientes para la resolución de problemas.
• Los participantes del taller JAD deben incluir empleados capaces de aportar información sobre la mayoría, si no todas, las áreas relevantes del problema. Por ello, es fundamental prestar especial atención a la selección de participantes. El grupo debe estar compuesto no solo por empleados de distintos departamentos que interactuarán con el nuevo sistema, sino también por personas de diferentes niveles jerárquicos. Si bien los participantes pueden tener puntos de vista divergentes, la reunión les permitirá analizar los problemas desde diferentes perspectivas. JAD permite desarrollar un modelo más completo y comprender mejor 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.  

• Yatco, Mei C. (1999). "Diseño/Desarrollo Conjunto de Aplicaciones" . Universidad de Missouri-St. Louis . Recuperado el 6 de febrero de 2009 .
• Soltys, Roman; Anthony Crawford (1999). "JAD para planes y diseños de negocios" . Archivado del original el 13 de marzo de 2009. Recuperado 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 apoyo grupal" . Journal of Management Information Systems . 15 (4): 115– 142. doi : 10.1080/07421222.1999.11518224 . Recuperado el 14 de mayo de 2015 .
• Botkin, John C. "La participación del cliente como parte del proceso de desarrollo de aplicaciones" . Archivado del original el 1 de diciembre de 1998.
• Moeller, Walter E. "Sesiones facilitadas de recopilación de información: una técnica de ingeniería de la información" . Recuperado el 22 de marzo de 2010 .
• Bill Jennerich, "Diseño conjunto de aplicaciones: análisis de requisitos empresariales para una reingeniería exitosa". 18:50, 26 de junio de 2006 (UTC)Se desconoce la fecha 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.
• Gary Rush, "JAD Project Aids Design", Computerworld, Volumen 18, Número 52, páginas 31 y 38, 24 de diciembre de 1984.
• Davidson, EJ (1999). "Diseño conjunto de aplicaciones (JAD) en la práctica". Journal of Systems and Software . 45 (3). Elsevier BV: 215– 223. doi : 10.1016/s0164-1212(98)10080-8 . ISSN 0164-1212 . 
• Gottesdiener, Ellen; Requisitos mediante la colaboración: Talleres para definir necesidades , Addison-Wesley, 2002, ISBN 0-201-78606-0.
• Wood, Jane y Silver, Denise; Desarrollo conjunto de aplicaciones , John Wiley & Sons Inc, ISBN 0-471-04299-4