stringtranslate.com

Diseño de aplicaciones conjuntas

El término "diseño conjunto de aplicaciones" se utilizó originalmente para describir un proceso de desarrollo de software que se inició y se implementó a mediados de los años 70 en el Centro de Desarrollo de Sistemas de la New York Telephone Company bajo la dirección de Dan Gielan. Después de una serie de implementaciones de esta metodología, Gielan dio conferencias extensas en varios foros sobre la metodología y sus prácticas. Arnie Lind, entonces ingeniero de sistemas sénior en IBM Canadá en Regina, Saskatchewan, creó y bautizó el diseño conjunto de aplicaciones en 1974. Sin embargo, los métodos existentes implicaban que los desarrolladores de aplicaciones pasaran meses aprendiendo los detalles de un departamento o función laboral en particular y luego desarrollaran una aplicación para la función o el departamento. Además de los retrasos en el desarrollo, este proceso dio como resultado que las aplicaciones demoraran años en desarrollarse y, a menudo, no fueran completamente aceptadas por los usuarios de la aplicación.

La idea de Arnie Lind era que, en lugar de que los desarrolladores de aplicaciones aprendieran sobre los trabajos de las personas, se les pudiera enseñar a las personas que hacían el trabajo cómo escribir una aplicación. Arnie presentó el concepto al vicepresidente de IBM Canadá, Carl Corcoran (posteriormente presidente de IBM Canadá), y Carl aprobó un proyecto piloto. Arnie y Carl juntos llamaron a la metodología JAD, un acrónimo de diseño conjunto de aplicaciones, 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 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, frente a un promedio de 18 meses para el desarrollo de aplicaciones tradicionales. Y como los propios usuarios diseñaron el sistema, adoptaron la aplicación de inmediato y les gustó. Después del proyecto piloto, IBM apoyó mucho la metodología JAD, ya que la vieron como una forma de implementar más rápidamente aplicaciones informáticas, que se ejecutaban en hardware IBM.

Arnie Lind pasó los siguientes 13 años en IBM Canadá continuando con el desarrollo de la metodología JAD, viajando por todo el mundo realizando seminarios JAD y capacitando a 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 finales de los años 70. Luego se implementó en la Canadian International Paper. JAD se utilizó en IBM Canadá durante un tiempo antes de volver a Estados Unidos. Inicialmente, IBM utilizó JAD para ayudar a vender e implementar un programa de software que vendían, llamado COPICS. Se adaptó ampliamente a muchos usos (requisitos del sistema, diseño de elevadores de granos, resolución de problemas, etc.). Tony Crawford desarrolló más tarde JAD-Plan y luego JAR (requisitos de aplicación conjunta). En 1985, Gary Rush escribió sobre JAD y sus derivaciones – Facilitated Application Specification Techniques (FAST) – en Computerworld. [1]

Originalmente, JAD fue diseñado para reunir a desarrolladores de sistemas y usuarios de diferentes 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 en serie tradicionales realizadas por analistas de sistemas. Desde entonces, JAD se ha ampliado para cubrir 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]

Participantes clave

Patrocinador ejecutivo
El ejecutivo que pone en marcha el proyecto, el propietario 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
Se trata de los usuarios empresariales, los profesionales de sistemas de información y los expertos externos que serán necesarios para que el taller sea un éxito. Este grupo es la columna vertebral de la reunión; ellos impulsarán los cambios.
Facilitador/Líder de la sesión
reunión y dirige el tráfico manteniendo al grupo informado sobre 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 su posterior investigación y resolución. El facilitador atiende a los participantes y no aporta información a la reunión.
Escribano/Modelista/Registrador/Experto en documentación
Registra y publica las actas de la reunión y no aporta información a la misma.
Observadores
Generalmente son miembros del equipo de desarrollo de la aplicación asignados al proyecto. Se sientan detrás de los participantes y observan en silencio el desarrollo de la actividad.

9 pasos clave

  1. Identificar los objetivos y las 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 el alcance, establecen las expectativas de los patrocinadores y los participantes del taller. El alcance identifica las funciones empresariales que están dentro del alcance del proyecto. También intenta 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ántos fracasos de implementación hubo? El tamaño es importante. Para obtener mejores resultados, los proyectos de sistemas deben tener un tamaño tal 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 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 planificados han sido eficaces? ¿Cómo se medirá el éxito? La planificación de la evaluación de los resultados ayuda a juzgar la eficacia y la calidad del sistema implementado a lo largo de toda su vida operativa.
  3. Definir los entregables del proyecto : En general, los entregables de un taller son la documentación y el 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 utilizar una herramienta CASE para el soporte de diagramación desde el principio. La mayoría de las herramientas disponibles tienen capacidades de diagramación buenas o excelentes, pero su soporte narrativo es generalmente débil. La narrativa se produce mejor con su software de procesamiento de texto estándar.
  4. 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 durar menos de tres días. Los participantes dedican la mayor parte del primer día a familiarizarse con sus roles, con los demás y con el entorno. El segundo día se dedica a aprender a entenderse entre sí y a desarrollar un lenguaje común con el que comunicar los problemas y las preocupaciones. Para el 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 cortos para las fases posteriores del proyecto, por ejemplo, para verificar un prototipo. Sin embargo, los participantes necesitarán entre una y tres horas para restablecer la psicología de equipo del taller inicial.
  5. Seleccionar a los participantes : estos son los usuarios empresariales, los profesionales de TI y los expertos externos que serán necesarios para que el taller sea exitoso. Ellos son los verdaderos "pilares" de la reunión que impulsarán los cambios.
  6. Preparar el material del taller : Antes del taller, el director del proyecto y el facilitador realizan un análisis y construyen un diseño preliminar o modelo para enfocar el taller. El material del taller consta de documentación, hojas de trabajo, diagramas e incluso elementos de apoyo que ayudarán a los participantes a comprender la función empresarial que se investiga.
  7. Organizar actividades y ejercicios de taller : El facilitador debe diseñar ejercicios y actividades de taller para proporcionar entregables provisionales 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 de negocios, ¿qué contiene? ¿Un diagrama de descomposición? ¿Un diagrama de relación de entidad de alto nivel? ¿Un modelo de datos normalizado? ¿Un diagrama de transición de estados? ¿Un diagrama de dependencia? ¿Todo lo anterior? ¿Ninguno de los 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 los usuarios deben comprenderlo. 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 complementarse entre sí y ejercicios paralelos, en los que 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 realizar debates detallados antes de tomar decisiones. Los debates 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 reunir a personas con experiencia similar de diferentes departamentos. Para ayudar a los participantes a aprender unos de otros, el facilitador puede mezclar la experiencia. Depende del facilitador mezclar y combinar a los miembros del subequipo para lograr los objetivos organizativos, culturales y políticos del taller. Un taller funciona tanto a nivel técnico como político. Es el trabajo del facilitador generar consenso y comunicaciones, para forzar la aparición de los problemas al principio del proceso. No hay necesidad de preocuparse por la implementación técnica de un sistema si los problemas comerciales subyacentes no se pueden resolver.
  8. Preparar, informar y educar a los participantes del taller : todos los participantes del taller deben conocer los objetivos y limitaciones del proyecto y los resultados esperados del taller. La reunión informativa con los participantes debe realizarse de 1 a 5 días antes del taller. Esta reunión informativa puede realizarse por teleconferencia si los participantes están muy dispersos. El documento informativo puede llamarse 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 reunión informativa en sí dura de dos a cuatro horas. Proporciona la preparación psicológica que todos necesitan para avanzar en el taller.
  9. Coordinar la logística de los talleres : Los talleres deben realizarse fuera del lugar de celebración para evitar interrupciones. Se deben preparar proyectores, pantallas, computadoras, mesas, marcadores, cinta adhesiva, notas adhesivas y muchos otros elementos. El facilitador decidirá qué instalaciones y elementos específicos se necesitarán. Pueden variar desde simples rotafolios hasta pizarrones electrónicos. En cualquier caso, la disposición de la sala debe promover la comunicación y la interacción de los participantes.

Ventajas

Desafíos

Referencias

  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í.
  2. ^ JAD | FAST | Técnica de facilitación estructurada FoCuSeD™[1].)

Bibliografía